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

[[e-mail] (Martin Rex)]

Peter Gutmann wrote:
> Martin Rex <[e-mail]> writes:
>> 
>>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'm sorry, but I fail to understand what you mean.  The TLS protocol
layer explicitly has no business whatsoever with names in certificates,
that has been spelled out clearly in all existing TLS specs.
A TLS client should not know or care about the hostname of the server
it is talking to, and there is no requirement what kind of stuff is
contained in the server's certificate.  Our TLS client does _not_ know
the server's hostname (it gets a connected socket).

  https://tools.ietf.org/html/rfc5246#page-5

                                 the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
*> exchanged are left to the judgment of the designers and implementors
*> of protocols that run on top of TLS.


As I said, it is impossible for the client to use the PKCS#7/CMS
approach to locate the client certificate.

The Definition of the TLS Certificate PDU has always contained this
paragraph:

  https://tools.ietf.org/html/rfc6101#section-5.6.2
  https://tools.ietf.org/html/rfc5246#page-48

   Note: PKCS #7 [PKCS7] is not used as the format for the certificate
   vector because PKCS #6 [PKCS6] extended certificates are not used.
   Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task
   of parsing the list more difficult.


Personally, I find it quite appalling how many broken TLS
implementations out there fail to properly encode an ordered list
of certificates into the Certificate handshake message.


-Martin