search

davidben / merkle-tree-certs

Other
9 stars 4 forks source link

Resolve client certificate type negotiation issues #18

Open davidben opened 1 year ago

davidben commented 1 year ago

See https://www.ietf.org/archive/id/draft-davidben-tls-merkle-tree-certs-00.html#name-certificate-type-negotiatio

bwesterb commented 1 year ago

I like the second proposal best. What about putting CertificateType certificate_type at the end of the modified Certificate message?

davidben commented 1 year ago

If we're modifying the message, putting it at the front seems easier to parse. Otherwise you have to skip past the certificates to figure out how to interpret the CertificateEntry. (That's the main drawback with the first option.)

bwesterb commented 1 year ago

I agree that's best for the first proposal. I was thinking of the second proposal.

davidben commented 1 year ago

Hmm, maybe I'm confused. To make sure we're numbering the same, first = leaf CertificateEntry has a new_cert_type extension field and second = change syntax of Certificate message? I.e. first, in my mind, was to keep the Certificate message as-is and use its existing extensions scheme. Second was to change the syntax rather than smuggling something in an extension.

If we're using a modified syntax, seems to me we ought to make parsing as possible, i.e. put the type in front. The downside of the leaving the message as-is is the parsing is a little wonky: you have to dig in the extensions list before you can interpret the certificate bytes. That said, TLS stacks usually buffer the messages and reassemble them before parsing (I know of only one counter-example), so it's not a huge inconvenience.

bwesterb commented 1 year ago

We agree on the numbering of the proposals. My suggestion to put CertificateType certificate_type at the end of the modified Certificate message (instead of the start) for the second proposal doesn't make a huge difference. Let's just ignore it.

davidben commented 1 year ago

Ohh, is the idea that putting it in the end allows the receiver to figure out which format you've got, by seeing if there's trailing data? I figured, if we change the format, we'd do it a la RFC 8879 and allocate a new type. But whether there's appetite for that when we could just make the parser a little screwier with an extension, I dunno.