Loosen chain requirements about mls-protocol

[Bren2010]

I don't recall this ever being discussed. I think it was just added and nobody ever objected.

[kkohbrok]

@ekr can you elaborate a little bit? The way I read it the requirement is just that there is a valid signature chain, i.e. that one certificate signs the next and so on.

[bifurcation]

@ekr - I deliberately reverted to the original TLS level of strictness here, in hopes that in starting over with a new ecosystem we could reset things to a cleaner state. Do you think there are legitimate reasons for violating the strict rule, or is it just a common misconfiguration in TLS servers? I would not really be inclined to accommodate the latter.

@kkohbrok - I believe what @ekr is envisioning are cases where there are multiple valid chains, say via old and new versions of an intermediate certificate. So you might do something like provide a "chain" of the form (leaf, old_intermediate, new_intermediate), with the idea that the client could verify using whichever one makes it happy.

[tomleavy]

@bifurcation take a look at the comment I left on the PR. I can see your point about starting over as being valid, but one thing that also caught my eye in the TLS RFC was language around allowing a root CA to be left out of the chain since those could potentially already exist in a local trust store.

[kkohbrok]

I see. Thanks @bifurcation for the clarification. Maybe we can phrase it in such a way that whatever the credential includes (added intermediary certificates or left-out root certificates) in the end the local client MUST be able to create a continuous certificate chain from the leaf to the root. Do we need to define how the client does that? Since we're already pushing everything else related to authentication into the AS, I'm inclined to say no.