Re: [TLS] Certificate validation can of worms

[[e-mail] (Martin Rex)]

Watson Ladd wrote:
>
> https://www.cs.utexas.edu/~shmat/shmat_oak14.pdf contains tests of
> many TLS implementations. Interestingly all tested implementations
> contain errors, and all but OpenSSL erroneous accepts. Cryptlib was
> not tested, because it doesn't validate certificates.

That paper seems to contain a few flawed assumptions
on what characteristics is to be expected from implementations of
X.509 or PKIX, and on which specific checks a TLS client is supposed
to do.

As much as some may dislike this, the extendedKeyUsage in an end entity
certificate is completely irrelevant for TLS (rfc2246/rfc4346/rfc5246)
as well as HTTP-over-TLS (rfc2818).   I don't know whether there currently
exists _any_ X-over-TLS protocol specification that addresses EKU.

There seem to be very few protocols that specify requirements for the EKU
value in the end entity cert (such as OCSP: rfc2560 & bis) and timestamps
(rfc3161).

Similar for certificate policies and policy constraints.  They're completely
irrelevant for any X-over-TLS, and it would be unwise to assume that they
are not simply ignored.


Implementing name constraints (other than Distinguished Name) is
a mere option.  The usage of a subjectAltName name constraint alone
(i.e. without a Distinguished name name constraints to go with it)
as depicted in Fig. 1 can be a security problem for CRL checking
because any CRL signer whose certificate can be verified under the same
trust anchor is specified to be an acceptable CRL signer.


-Martin