Re: [TLS] Certificate validation can of worms

[Santosh Chokhani <[e-mail]>]

Martin,

There are several misunderstandings on your part.

The EKU is generally only applies to the leaf certificate (per X.509 and RFC 5280) and is not involved in path processing.  I would think that if EKU is present at least a browser application will ensure that the certificate has server auth OID.

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.

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.  5280 and X.509 are pretty clear on how to implement them and I know of and have been involved in a few successful implementations.

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. 

Our time is better spent in implementing a well-designed RFC properly, addressing issues it has as opposed to justifying poor implementations.

We have enough problems implementing good specs.

-----Original Message-----
From: Martin Rex [mailto:[e-mail]] 
Sent: Monday, April 07, 2014 5:31 PM
To: Santosh Chokhani
Cc: [e-mail]; Watson Ladd; [e-mail]
Subject: Re: [TLS] Certificate validation can of worms

Santosh Chokhani wrote:
>
> 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.

There is *NO* such requirement (to look at EKU) anywhere in rfc5246 and rfc2818.  The EKU processing within the PKIX certificate path validation applies only to path certificates, not to the leaf certificate (because the certificate path validation is context-free, i.e. independent of the actual usage of the certificate.

KeyUsage is different, processing KeyUsage is explicitly described in rfc2246/rfc4346/rfc5246.

Did you notice that the id-kp-serverAuth that is defined in rfc5280 is strictly limited to HTTP-over-TLS anyway, so would not apply to XMPP-over-TLS, SIP-over-TLS, SMTP-over-TLS and whathaveyou.



>
> 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.

PolicyOIDs are completely meaningless for HTTP-over-TLS.
Is there *ANY* X-over-TLS specification that gives a meaning to any policy OIDs?


>
> Finally, name constraint is very relevant.

name constraints will be missing from a PKIX minimum requirements RP.
And considering how broken the _definitions_ are, and how broken
some of the CA software is that is creating them, simply ignoring
name constraints seems like the only sane behaviour.


>
> 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.

name constraints are a HUGE mess.  PKIX does not really describe
their processing at all, and neither gives an indication that when
*ANY* name constraints are used that name constraints on distinguished
names will have to be used as well, otherwise creating security problems
for the permissible CRL signer logic.

When looking at how X.509 describes processing of name constraints in
the example section, you may realize that it talks about iteratively
trying to build certification pathes and checking whether name constraints
work from them.  Ooops.  building a certification path is declared out
of scope by rfc5280, so logically, this spills the baby with the bathtub
and makes name constraints in PKIX/rfc5280 optional in its entirety,
because something that needs a feature that has been explicitly declared
out of scope can never be a mandatory part of the spec.


-Martin