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

[[e-mail] (Martin Rex)]

Ryan Sleevi wrote:
> 
> 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.

When looking at the above bug report, I agree with the particular
statement of [e-mail]'s bug report:

  This allows the 'proper' chain to be built (eg: through AIA fetching).
  However, such behaviour is not desirable for both performance reasons
  and because it may mask real configuration errors (eg: Issue 122500 ) 

Has adding the crossCA variant of the new Baltimore rootCA cert ever
been considered/tried?  I mean dropping the old 1024-bit rootCA should
become irrelevant when the the 2048-bit crossCA variant is added
as trust anchor.  There is no practical difference between the
self-signed variant and the crossCA variant of that trust-anchor.
And if the PKIX implemenation is a little dense and does not recognize
the equivalence all by itself, then configuring both variants as
trust anchors should do the necessary magic.

Did the supplier of the relevant PKIX implementation fix this implementation
shortcoming?

-Martin