Re: [TLS] Certificate validation can of worms

[Watson Ladd <[e-mail]>]

On Apr 7, 2014 3:44 PM, "Martin Rex" <[e-mail]> wrote:
>
> 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 }
>
>

Well, are they? Short of a hex dump of a GoDaddy certificate+chapter and
verse of X509 I don't know how we are supposed to evaluate your claim.

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

This is really a problem with RFC2818. The whole idea of X509v3 is that you
should be able to issue certificates that have meaning beyond assertions of
identity, such as for use as code-signing. But because implementations
don't respect the PKIX standard, we can't do that. Instead you have to have
separate trust roots, and the whole thing becomes a giant mess for people
with lots of different keys to keep track of. (Imagine the janitor at a
large institution and his key ring. Now imagine that if he uses the wrong
key on a door, everything breaks. The poor sob isn't going to last long I'm
afraid).

It's particularly bad when you want to have a distributed agent-based
authentication and authorization system. You end up needing Kerberos, which
has a central server.

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

Remind me what svn is used for again? Oh right, it downloads the FreeBSD
ports tree. And what does the ports tree have? SHA256 hashes of all
software in the ports tree used for checking authenticity of mirrored
files. I can't imagine lacking necessary validation of certificates could
possibly go wrong there.

Now, Colin Percival developed a better way involving signed tarballs. I
don't know how MacPorts does it. I know Apple signs its updates, and most
people have realized that this is the way to go. (Especially given that you
can sign on a hardened machine.) But you still have the problem of needing
a PKI capable of expressing the policy you want to express.

Sincerely,

Watson Ladd

>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls