Subject: Re: [TLS] Certificate validation can of worms

From: Peter Gutmann <[email-masked]>
Date: Sat, 5 Apr 2014 02:20:19 +0000

Watson Ladd <[email-masked]> writes:

>Dear all, 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.

... which is actually wrong, it does support certificate validation, it just
doesn't do it by default because in the large majority of situations where
cryptlib is used, users don't want to trust or not trust any arbitrary cert
just because it was bought from a commercial CA.  In other words cryptlib
isn't a web browser that blindly trusts anything that chains to a commercial
CA.  If you do want that behaviour (and I wouldn't recommend it), it's two
lines of code to implement.  I'll write to the authors in a minute asking them
to correct the statement in the paper.

Peter.

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 9 Apr 2014 15:01:33 +0000

Martin,

TLS probably is not a good forum to have this debate.  It seems like PKIX discussion.  We should drop it.  Here are my final comments on it.

On EKU, while the RFC may not say it, it seems to be a proper thing to do and the RFC for TLS should be revised.

On policies, as I mentioned, regardless of what the protocol or application does, there is a possibility of path not being valid.

On name constraints, Annex G is informative.  I also do not see why you need to mix path building and path validation  You can always have multiple paths even without name constraints and some of them will be valid and others will not be due to other reasons.

Inhibit policy mapping is a tool used to reject cross certificates.  The mechanism is useful when you only want to trust enterprise certificates.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, April 08, 2014 3:33 PM
To: Santosh Chokhani
Cc: [email-masked]; Watson Ladd; [email-masked]
Subject: Re: [TLS] Certificate validation can of worms

Santosh Chokhani wrote:
> 
> The EKU is generally only applies to the leaf certificate (per X.509 
> and RFC 5280) and is not involved in path processing.

EKU applies *ONLY* to higher layer protocols where the higher layer protocol specifies behaviour for a list of EKUs.  For TLS, such specification simply do not exist.

Potentially, there is something in the CABrowser Forum Baseline requirements.  But I'm not a Browser implementor, so I don't know and don't care.  I'm a maintainer of a TLS library and application level wrapper to TLS for programmatic use.

> 
> While TLS applications may or may not be able to set policies, the 
> interactions among policy related extensions and path validation state 
> machine can make the path invalid if the policy intersection is null 
> and the require explicit policy flag has been turned on.

Aside from what the CABForum & Browser folks may have defined to create fancy GUI chrome, I'm not currently aware of any X-over-TLS spec that gives meaning to policies.  So the easiest approach is to entirely ignore them -- during path validation as well as on the end entity certs.

> 
> Path building need not be tied to path validation.  That is your choice.
> Name constraints for the hierarchical name form types are not a mess 
> as you say.

To me, the idea behind X.509 11/2008 Appendix G.3.3 looks like a pretty big mess, and it requires an iterative approach of building a certification path, failing, building an alternative path and succeeding, and this is where the whole name constraints processing becomes out of scope of PKIX/rfc5280.

> 
> I see lot of misunderstandings and exaggerations about problems in 
> X.509 and RFC 5280 and folks with incorrect implementations having an axe to grind.

I see a huge amount of needless complexity

A while ago I had an inquiry from a governmental customer because our library rejected their "pretty" certificate chains on the TLS server cert.
They had a critical policy constraints extension in one of their path CA certs

  https://tools.ietf.org/html/rfc5280#section-4.2.1.11

with the field "inhibitPolicyMapping" present(!)

To me, this particular extension looks like a pretty stupid design flaw.

-Martin