Adoptions to supersede `server/client_certificate_type` extensions

[pohlm01]

Merkle Tree Certificates require the trust_anchors extension defined in this repository, as well as the server_certificate_type and client_certificate_type extensions defined in RFC 7250 (raw public keys).

The current draft says:

If the subscriber sends a certification path that matches the relying party’s trust_anchors extension, as described in Section 4.2, the subscriber MUST send an empty trust_anchors extension in the first CertificateEntry of the Certificate message.

If we change this to include the selected Trust Anchor instead, we would implicitly negotiate the certificate type as well and leave out the server_certificate_type and client_certificate_type extensions. I considered the following scenarios:

• For negotiating the server certificate type, the client sends the supported Trust Anchors, possibly covering multiple certificate types such as X509 and Bikeshed. The server sends back the selected trust anchor (if match found) as trust_anchors extension, with exactly one entry in the first CertificateEntry of the Certificate message. (As an optimization, we could introduce a separate extension only to be used in the CertificateEntry message that always contains exactly one entry. This would save two bytes for the length encoding.)
• For negotiating the client certificate type, the server sends the supported Trust Anchors in the CertificateRequest message and would again retrieve the selected one as part of the Certificate message.

This approach has a few implications:

• We need to have a unified representation of the certificate data in the CertificateEntry message to allow the application to interpret the data after it processed the extensions. See https://github.com/davidben/merkle-tree-certs/pull/95
• It does increase the size of the extension placed in the CertificateEntry message, as it transmits the TAI instead of an empty extension. We could think of sending the TAI only for certificate types that are not X509, but that might complicate things.
• It aligns server and client certificate type negotiation and therefore solves client certificate negotiation identified as a difficulty in Merkle Tree Certificates

[davidben]

Hmm. This does fall somewhat naturally from reusing the same TAI namespace between X.509 and Bikeshed (for completeness, we could have decided to just have a separate bikeshed_trust_anchors extension), but I suspect tying certificate format to trust anchor negotiation quite this tightly might be a bit too restrictive:

• We might end up with multiple negotiation mechanisms. I mean, I hope not, but we already had two points in the trade-off space and #64 explores another one.
• TAI's current design allows for the server to guess and for the client to retry if it's not happy. But if I see an unknown TAI, how do I know whether to check the contents (maybe it's an X.509 chain that I accept anyway) or not (maybe it's some non-X.509 format altogether)
• For X.509, the relying party may have trust anchors that don't participate in TAI, either for privacy reasons or because there just isn't a TAI allocated. That's unlikely for Merkle Tree Certificates due to its strong dependency on negotiation, but maybe other bikeshed proof types or other cert formats will care.

So I suspect it'll be simplest if we keep the type explicit.