Re: [TLS] Certificate validation can of worms

[Nikos Mavrogiannopoulos <[e-mail]>]

On Mon, 2014-04-07 at 18:20 -0700, Watson Ladd wrote:

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

I think PKIX is far from being described as standard. It looks more than
a set of rules that the implementer is expected to distill and select
the relevant ones, as most of the described rules are legacy baggage
(e.g. DN comparison rules that assume that the DN is copied by a
secretary that introduces case changes and alters spaces, rather than a
memcpy).

PKIX's requirements are pretty strange to put it mildly. One example are
the key purposes that Martin described. Another is the name constraints
which is optional to implement for DNS or e-mails (that everyone uses),
and mandatory for DistinguishedNames (that no-one uses); then it becomes
an issue when people realize that no-one implements name constraints
(and the only certificates that I've seen that contained constraints,
had syntactical errors in them). There are much more issues in PKIX (and
Peter Gutmann is much better in providing a good overview). We certainly
need something better than rfc5280.

regards,
Nikos