Re: [TLS] Certificate validation can of worms

[[e-mail] (Martin Rex)]

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