Re: [TLS] Certificate validation can of worms

[[e-mail] (Martin Rex)]

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