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

[Viktor Dukhovni <[e-mail]>]

On Thu, May 07, 2015 at 02:43:45PM +0000, Peter Gutmann wrote:

> >PKCS#7/CMS uses a Issuer&Serial (or alternatively SKI) to clearly identify
> >the end-entity certificate.  In TLS, the identification is the first position
> >in certificate_list.  So it is not possible to "blindly reuse" the code with
> >respect to identifying the end-entity certificate.
> 
> Yes it is, as I mentioned in my previous message my code looks for the server
> FQDN/whatever and uses the cert that contains that as the leaf cert.  It's the
> same process that's used for IssuerAndSerialNumber, SCEP client IDs, and
> various other things, "find the cert for the identified party, then follow
> parent links to build the chain".

I don't see such an ad-hoc approach as a compelling reason to remove
the requirement that the end-entity certificate must come first.  The
MUST needs to stay.

The TLS layer does not always know which SAN value will be used to
authenticate the peer.  Certificate verification can be delayed
until the handshake is complete, and can be performed outside the
TLS stack.  The TLS stack needs the leaf certificate for key
agreement.

I summary, the only thing that could be tweaked is the requirement
to order the intermediate certificates.  The first MUST and final
MAY are correct as they stand.  And I think that the second MUST
is a fine example of Postel's principle.  Tolerance by many clients
of servers that ignore the requirement does not invalidate the
requirement.

-- 
	Viktor.