Re: [TLS] Certificate validation can of worms

[Santosh Chokhani <[e-mail]>]

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:[e-mail]] 
Sent: Tuesday, April 08, 2014 3:33 PM
To: Santosh Chokhani
Cc: [e-mail]; Watson Ladd; [e-mail]
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