Hi Watson, Ilari,
Watson wrote:
Wait, I don't think the example's quite right (or maybe I'm just
confused). How can two intermediates sign the "same" leaf? Or is the
idea that we have L1' and L1 X509 Certificates with the same public
key presented in the chain but signed by different intermediates, and
the verifier figures out which one to use for the key exchange. (Yes,
this is really nitpicky, but there is a distinction between keys and
certs here that matters when counting bytes). Also the intermediates
aren't the roots, and I don't think we're relaxing that rule for
purposes of this discussion.
Yes, the L1, M1 and N1 are public keys rather than certificates in the
example I sketched. I was trying to explain more around how particular
signatures impacted the overall security (or didn't), rather than the
concrete use case in my initial message.
So in case (3) we'd send L1, M1, M1' where M1' is signed by the root
N1, and M1 by some PQ root. In case (2) I'm not sure how this would
work: the end entity cert must be first, but you're requiring two
different ones (with the same key), and I don't know a way to find M1
and N1 from that single cert.
Yeah, in case (2) in practice we'd want two intermediate certificates
rather than two end-entity certificates as I sketched in the first mail,
but I felt having the extra identical signature hop in both examples
might be confusing from the security perspective.
Anyway your point remains valid: cross-signing doesn't hurt clients
that only trust the new algorithm.
:-)
Just to make sure things are clear, I've laid out the certificate chains
from my initial message again.
We have a new PQC root X3, plus an existing classical root X2.
*Option 1*
We create a new PQC Public Key M1 and produce two intermediate
certificates for this public key, over X2 and X3 and use them to produce:
* L1 := User's Leaf key signed by M1.
* F1 := M1 signed by X3
* H1 := M1 signed by X2
The certificate chain is then: L1 + F1 + H1.
Benefits:
* PQ Security for clients that have X3
* Classical Security and backwards compatibility for clients that only
have X2
* Existing TLS Certificate Compression mechanisms like brotli will
compress out the excess bytes (the repetition of M1) so overall the
only size increase is the 32 byte ECDSA X2 signature.
Drawback: Relies on Clients doing the bare minimum of chain building.
Interestingly you can choose whether its PQ clients or classical clients
that need the chain building support by deciding whether to send F1 or
H1 first in the order.
*Option 2
*We cross sign X3 with X2 and use that to build a single longer chain:
* L1 := User's Leaf Key signed by M1
* F1 := M1 signed by X3
* X3' := X3 signed by X2.
The certificate chain is then L1 + F1 + X3'
Benefits:
* PQ security for clients that have X3
* Classical Security and backwards compatibility for clients that only
have X2
* No chain building support needed
Drawback: You need Abridged Certs or AIA chasing (already deployed in
Chrome) to avoid paying the byte cost of X3'.
@Ilari - I think the size increase is much less than you might think,
only 32 bytes for Option 1 and this is assuming no use of Abridged
Certs, which would make either option completely free. Assuming we
deployed Abridged Certs, then Option 2 has no size increase on today and
does not need any path building support in clients.
Best,
Dennis
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
