Re: [TLS] Certificate validation can of worms

[[e-mail] (Martin Rex)]

Rob Stradling wrote:
> Martin Rex wrote:
>> 
>> 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.
> 
> Martin, how about RFC6125?
> 
> "Representation and Verification of Domain-Based Application Service
>   Identity within Internet Public Key Infrastructure Using X.509 (PKIX)
>       Certificates in the Context of Transport Layer Security (TLS)
> ...
> 1.4.  Applicability
> 
>     This document does not supersede the rules for certificate issuance
>     or validation provided in [PKIX].  Therefore, [PKIX] is authoritative
>     on any point that might also be discussed in this document.
>     Furthermore, [PKIX] also governs any certificate-related topic on
>     which this document is silent, including but not limited to
>     certificate syntax, certificate extensions such as name constraints
>     and extended key usage, and handling of certification paths."

I do not see any specific requirements listed in the quoted paragraph
(not even a MAY).   PKIX deals with the black box called "certificate
path validation" (within which EKU-processing is defined), and with
requirements for "conforming CAs" which issue X.509v3 certs (of which
there seem to exist very few, if any, considering how much junk
X.509v3 certificates are floating around.

Could it be that GoDaddy is issuing Server certs that aren't valid ASN.1 DER ?

Their ASN.1 DER encoder doesn't seen to implement "BOOLEAN DEFAULT FALSE"
correctly:

BasicConstraints ::= SEQUENCE {
     cA                      BOOLEAN DEFAULT FALSE,
     pathLenConstraint       INTEGER (0..MAX) OPTIONAL }



> 
> <snip>
> > 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.
> 
> You mean the "-- TLS WWW server authentication" comment in section 
> 4.2.1.12?  Or something else?
> 
> Would you be happier if "WWW " wasn't in that comment?


This isn't about happiness.  If this OID has any meaning at all, then this
limitation "TLS WWW server authentication" will be an integral part of it.

An implementation of TLS will be looking here:
  http://tools.ietf.org/html/rfc2246#page-38
when checking KeyUsage of the Server Certificate, and *NOT* in PKIX.

And a TLS client that implements rfc2818 (HTTP-over-TLS) will look
exactly at rfc2818 for any checks that the client will do on the
Server certificate, and again *NOT* in PKIX.


> 
> >> 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?
> 
> Yes.  The CA/Browser Forum EV SSL Guidelines and Baseline Requirements.

Ah--yes, the fancy Gui/chrome thingy for EV/OV/DV certs.
programmatic clients don't look at CAB Forum baseline requirements
(except maybe when looking for excuses to give to unhappy customers).


-Martin