Re: [TLS] Update spec to match current practices for certificate chain order

[[e-mail] (Martin Rex)]

Ryan Sleevi wrote:
>
> If you're going to write a client that works on the Internet at large and
> is capable of moving at the speed of the Internet, the best I can say is
> "Cheer up and deal with it". Clients doing what you propose, rather than
> the thing you hate, hold Internet security back, so I'm not terribly
> sympathetic (e.g. https://access.redhat.com/articles/1413643 for the most
> recent example)

New 2048-bit rootCA certs have been around for several years, and the
transition from old 1024-bit rootCAs to 2048-bit rootCAs is a non-problem.

It definitely is *NOT* a problem for the existing requirements on
the Certificate handshake message.

Let's use the Web-Server above (https://access.redhat.com/) as example.

  (1) Server cert: (2048-bit RSA)
         Subject:  CN=access.redhat.com
         Issuer:   CN=VeriSign Akamai SureServer CA G14-SHA1
  (2) ServerCA cert: (2048-bit RSA)
         Subject:  CN=VeriSign Akamai SureServer CA G14-SHA1
         Issuer:   CN=Baltimore CyberTrust Root
  (3) CrossCA cert (2048-bit RSA, sha1WithRsaEncryption signature):
         Subject:  CN=Baltimore CyberTrust Root
         Issuer:   CN=GTE CyberTrust Global Root

  (4) (old) RootCA cert (1024-bit RSA)
         Subject:  CN=GTE CyberTrust Global Root
         Issuer:   CN=GTE CyberTrust Global Root

The server https://access.redhat.com sends (1)+(2)+(3) from the above
certificate path (and in the correct order), and is omitting only the
self-signed 1024-bit RootCA cert (4) from the end of the path in the
TLS Certificate Handshake message.

FireFox 34.0.5 is a little weird, because it verifies the above path
against the old 1024-bit RootCA, although it is in possession of the
new Baltimore 2048-bit rootCA Certificate:

  (3b) new Baltimore RootCA cert (2048-bit RSA)
         Subject:  CN=Baltimore CyberTrust Root
         Issuer:  CN=Baltimore CyberTrust Root

FireFox 37.0.1 seems to have been improved and properly recognize
that it only needs (1)+(2) from the Servers certificate handshake
message to verify the servers certificate against its (3b) trust anchor.


Would the server at https://access.redhat.com/ only be sending (1)+(2)
in the Certificate Handshake message, then old clients, which have the
old 1024-bit GTE CyberTrust Gobal Root in their trust anchor store
but not the new self-signed 2048-bit Baltimore Cybertrust Root, would
not be able to verify the server certificate (because of the lack
of that CrossCA cert).

New clients, which have the new self-signed 2048-bit Baltimore CyberTrust
Root should be able to recognize that they only need (1)+(2) from the
Server Certificate to chain against a known trust anchor.  FireFox 34.0.5
seems a little dense.  Given the above path, when the client has the
new 2048-bit Baltimore rootCA cert, then the client should always perform
the verification against the new RootCA when the server Certificate
handshake message starts with certificate (1)+(2), and independent of
whether the certificate handshake message futher includes (3) or (3)+(4)
or (3b).

Valid alternative forward paths for the server are:

  (a)  (1)+(2)
  (b)  (1)+(2)+(3)
  (c)  (1)+(2)+(3)+(4)
  (d)  (1)+(2)+(3b)

and (b) or (c) will have a higher likelyhood of interop that (a) or (d)
because of the legacy clients in the installed base.


Now in case that a client has (2) configured as a trust anchor,
it would only be using (1) from the Server certificate handshake message
(and ignore the other included certificates), and in case that a client
as (1) configured as a trust anchor, it would also only be looking
at certificate (1), determining that it has this certificate configured
as trust anchor, and perform all checks based on that local trust anchor.


-Martin