Re: [TLS] Certificate validation can of worms

While I am still reading the cited paper , the EKU if present should be very relevant.  The client should reject the server certificate if server authentication or anhyExtendedKeyUsage is not present.  Similarly, certificate policies and policy constrains extensions should be processed by the client and if the require explicit policy state variable get turned on and the path is not valid for some policy, it must be rejected.  Finally, name constraint is very relevant.  The certificate must be rejected if any of the name forms in a certificate in the path violate name constraint state variable values at that point in the path.

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Rex
Sent: Monday, April 07, 2014 4:23 PM
To: Watson Ladd
Cc: tls@ietf.org
Subject: Re: [TLS] Certificate validation can of worms

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

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls