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

[[e-mail] (Martin Rex)]

Ryan Sleevi wrote:
> On Tue, May 12, 2015 9:05 am, Martin Rex wrote:
>>  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.
> 
> I'm sorry, but I'm going to have to disagree with you again, because while
> this is the way the world looks on paper, it's not the way the world works
> in practice.
> 
> Your example (access.redhat.com) is one that we had to work around on OS X
> due to quirks of the client not supporting trust anchors (e.g.
> https://code.google.com/p/chromium/issues/detail?id=236112 ).
> 
> That is, if you supply your (b) or (c), for example, you'll break any
> application using Security.framework for certificate verification
> (including all those that use CFURL & friends). It seems that Safari has
> special logic not present in the OS to work around that issue.


If that particular client really goofs the certificate path validation
in presence of an unneeded crossCA (plus optional untrusted rootCA)
while succeeding certificate path validation when neither of these
additional certificates is present, then it is obviously defective
and ought to be fixed-- and this silly bug should have been found
and fixed a few years ago -- because several public CAs have been doing
this for years.

The straight forward workaround for such a defective client would have
been to import the crossCA certificate incarnation of the new Baltimore
RootCA certificate as additional trust anchor (since *ANY* certificate
can be declared a trust anchor, it does not need to be self-signed).


>
> Now, with respect to cross-certificates, it's a regular occurrence to see
> situations like
> 
> (1) Leaf-signed-by-(2)
> (2) Intermediate-signed-by-(3)
> (3a) Intermediate-signed-by-(4)
> (3b) Intermediate-signed-by-(5)
> (4) Root 1 [an existing root]
> (5) Root 2 [a new root applying for inclusion]
> 
> In this case, valid paths are
> [for old clients]
> (1)+(2)+(3a)+(4)
> 
> [for new clients]
> (1)+(2)+(3b)+(5)
> 
> As much as you might wish to yell that they shouldn't have done (3a)/(3b)
> like that, and instead (5) should have been certified by (4), there are a
> large number of reasons why that doesn't happen, and the above is actually
> quite common (I know of at least three different organizations who will
> have to go through the above flow right now to avoid issues)
> 
> The maximum compatibility with clients is
> (1)+(2)+(3a)+(4)+(3b)+(5)
> 
> As gross and as ugly as that may seem, when working with various clients'
> libraries, that config is what gets the most working. That's why I support
> the language relaxation, in its simplest form.

Myself, I have not seen any such Certificate handshake messages so far
(like in a customer support incident).  Do you have an example (URL)
of a server with such a configuration?  (I actually do not know how
the TLS client, for which I'm still doing maintenance, will handle this).

At least the above would be properly ordered up to and including
a self-signed rootCA certificate.  So clients that trust the old root
might be able to see the match to a known trust anchor and simply ignore
the trailing junk.

But for simple clients that trust only the newer root, this certificate
path is probably invalid (and in violation of the current requirements),
and there is no easy approach to make such a certificate_list comprehensible
to such a client (that only trusts the new root).


> 
> Now, if clients did AIA fetching ubiquitously, you might supply
> (1)+(2)+(3a) and have (2)'s AIA point to (3b). Clients that trust (4) will
> work "out of the box", while clients that trust (5) will do an AIA chase
> off (2) to get (3b). Over time, you might determine that more clients have
> (5) than (4), so then you invert it to (1)+(2')+(3b), where (2') is a
> version of 2 whose AIA points to (3a).

"AIA chasing" is obviously insecure and a huge security problem.
If you look at how the certificate path validation is designed in
PKIX (rfc5280) section 6.1+, it works from the trust anchor down
towards the end-entity certificate, and the algorithm will not use
any information from an untrusted certificate _unless_ an already trusted
certificate can be used to verify the signature on the still untrusted
certificate, and that verification has succeeded.

AIA chasing walks the chain in the opposite direction, and would use
information (a download-URL) from a still untrusted certificate to
perform a download.  As I previously said, this might look normal
for a browser, because browser do stupid things all the time,
but it would be definitely irresponsible for a PKIX implementation
to do something like this, and perform a download of an object with
an URL from an untrusted certificate provided by the communication peer.

The other problem here is inefficiency.  In a number of environments
performing network data exchanges during certificate path validation
is a complete non-starter.

To at least fix the security side of the problem, the publication of
additional certs would have to work strictly top down.  I.e. the trust anchor
cert will have to indicate the location where to obtain additional crossCA
certificates, and the serverCA cert would need to have additional
attributes added, enumerating the rootCAs under which the server certificate
will be alternatively verifiable.


-Martin