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

From: Peter Gutmann <[email-masked]>
Date: Thu, 7 May 2015 14:20:16 +0000

Martin Rex <[email-masked]> writes:
>Peter Gutmann wrote:
>> For example my code looks for a cert containing the site name
>> ("www.whatever.com") and then builds a chain up via the parent links until it
>> can't find any more useful certs.  That just works no matter what the other
>> side sends.
>
>Adding workarounds for clearly bogus behaviour is a very bad strategy,
>because it makes the situation worse for everyone in the long run.

In my case (and possibly others) it's not a workaround since the same code
that does PKCS #7/CMS also does TLS cert chains, in order to handle the more
open-ended PKCS #7 requirements it automatically deals with oddball TLS
chains.

Peter.

---

From: [email-masked] (Martin Rex)
Date: Thu, 7 May 2015 16:32:07 +0200 (CEST)

> open-ended PKCS #7 requirements it automatically deals with oddball TLS

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.

For the certificate path beyond the end entity certificate, the approach
may be similar.

-Martin