Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)

[[e-mail] (Martin Rex)]

Ryan Sleevi wrote:
> On Tue, May 12, 2015 6:14 am, Martin Rex wrote:
> >  Huh?  I never described anything like that "normative checking".
> 
> "Up to 2013 our SSL implementation has been hard failing TLS handshakes
> with TLS peers that are sending garbled or incomplete chains."
> 
> This, in context, and combined with your follow-up qualifiers, suggested a
> level of checking beyond RFC 5280.

Actually, no, I never did suggest anything like that.
I'm simply following standards in an obvious and straightforward fashion.

 
The relevant snippets from PKIX rfc5280, section 6:

>From Section 6.2  Using the Path Validation Algorithm:

                             While each certification path begins with
   a specific trust anchor, there is no requirement that all
   certification paths validated by a particular system share a single
   trust anchor.  The selection of one or more trusted CAs is a local
   decision.  A system may provide any one of its trusted CAs as the
   trust anchor for a particular path.  The inputs to the path
   validation algorithm may be different for each path.

The inputs to the "Basic Path Validation" algorithm in rfc5280, section 6.1
are described with:
   https://tools.ietf.org/html/rfc5280#page-73

   To meet this goal, the path validation process verifies, among other
   things, that a prospective certification path (a sequence of n
   certificates) satisfies the following conditions:

      (a)  for all x in {1, ..., n-1}, the subject of certificate x is
           the issuer of certificate x+1;

      (b)  certificate 1 is issued by the trust anchor;

      (c)  certificate n is the certificate to be validated (i.e., the
           target certificate); and

      (d)  for all x in {1, ..., n}, the certificate was valid at the
           time in question.

   A certificate MUST NOT appear more than once in a prospective
   certification path.

   When the trust anchor is provided in the form of a self-signed
   certificate, this self-signed certificate is not included as part of
   the prospective certification path.  Information about trust anchors
   is provided as inputs to the certification path validation algorithm
   (Section 6.1.1).

Since the TLS Certificate handshake message is *REQUIRED* to supply
the certificate chain in order, it is only necessary to determine
whether any issuer(!) on that list of ordered certificates is recognized
as a locally available trust anchor, and then provide that trust
anchor plus the certificates up to the one issued by the recognized
trust anchor straight to the "Basic Path Validation" function.


> 
>>  rfc4158 is a pretty complex and dumb idea. AND, it is *NOT* a standard.
>>  It is explicitly ignored by PKIX (rfc5280).
> 
> Only to the extent that RFC 5280 Section 6 deals specifically with the
> validation of a given certification path, while leaving out of scope (but
> acknowledged rather extensively throughout the documentation, especially
> for extensions) the building/discovery of said paths.

X.509 would require an omniscient trusted directory to perform certificate
path discovery, and the Certificate Path Validation algorithm in
rfc5280 section 6.1 clearly rules out AIA chasing as a permissible
approach for certificate path discovery, because this approach would
be clearly insecure and irresponsible.


> 
> Indeed, Section 3.2 calls out some of the complexities and acknowledgement
> that inherent in the PKI is the possibility of multiple certification
> paths. Section 6.2 further acknowledges this.
> 
> Merely I think it's a mistake and misleading to suggest that RFC 4158 is
> an interesting side-note in the history of PKI, when in fact it describes
> the behaviour of some of the largest (by end-user) clients out there
> (Windows' CryptoAPI, Mozilla's NSS in various flavours, Java's
> JCA/CertPath APIs).

Sounds like plenty of security holes to exploit and many frantic patch
days to come.


-Martin