Subject: Re: [pkix] AD Review ofdraft-ietf-pkix-rfc5280-clarifications-03.txt

From: Martin Rex <[email-masked]>
Date: Thu, 22 Sep 2011 21:43:16 +0200 (MEST)

> -----Excerpts from Original Message deliberately rearranged -----
> 
> I didn't really follow the discussion on self-signed EE 
> certificates, so I don't really know what people believe 
> needs to be added to the PKIX profile.

First of all: is this about inventing new rules for future
new implementations, or, what I would hope, to describe how
to deal with the millions of self-signed non-CA certificates
that are actively being used in the installed base.

>
> What would it mean for something to be a self-signed 
> end-entity certificate.
> 
> X.509 also says:
> 
> * "An end-entity certificate is a certificate issued by a CA 
> to a subject that is not an issuer of other public-key certificates."
> * A Self-issued certificate "is a certificate where the 
> issuer and the subject are the same CA."
> * A Self-signed certificate "is a special case of self-issued 
> certificates...."

(reminder)
X.509 (en) available here http://www.itu.int/rec/T-REC-X.509/en

The two most important things to consider from X.509
on this topic are:

The Introduction of X.509 05/2008 (and similarily 08/2011)
clearly states:

  This fifth edition specifies versions 1, 2 and 3 of
  public-key certificates and versions 1 and 2 of certificate
  revocation lists. This edition also specifies version 2 of
  attribute certificates.

And this one:

  3.3.56 self-signed certificate:

  A special case of self-issued certificates where the
  private key used by the CA to sign the certificate
  corresponds to the public key that is certified within
  the certificate. A CA might use a self-signed certificate,
  for example, to advertise their public key or other
  information about their operations.

    NOTE – Use of self-issued certificates and self-signed
    certificates issued by other than CAs are outside the
    scope of this Recommendation | International Standard.

> 
> There are essentially two ways in which one can accept an 
> X.509 certificate:
> 
> 1) Make a strictly out-of-band decision to accept the certificate; or
> 
> 2) Accept the certificate based on the results of 
>    certification path validation,[...]
> 
> A self-signed certificate can only be accepted via method 
> (1).  Is this self-signed certificate a CA certificate or an 
> end-entity certificate?  Does it really matter?

A self-signed certificate that is MEANT TO BE a CA certificate
is fully covered by X.509v3 and profiled by rfc5280 and its
predecessors, so there is no need to (re)define how to
process them.

A self-signed certificate that is *NOT* meant to be a
CA certificate is an entirely different can of worms.

As X.509 3.3.56 clearly states, the processing of
self-signed non-CA certificates is *NOT* standardized
by X.509 and therefore neither by any profile based
on X.509, such as rfc5280.

There exist three distinct variants of self-signed non-CA
certificates in current widespread use:
 1) self-signed non-CA X.509v3 certs with BasicConstraints
    cA=TRUE that are indistinguishable from real CA certs
 2) self-signed non-CA X.509v3 certs with BasicConstraints
    cA=FALSE (or no BasicConstraints extension) that
    are clearly outside existing standards
 3) self-signed non-CA X.509v1 certs that are fully covered
    by existing standards, but could be confused with real CA
    certs because distinction would only possible through
    meta-knowledge (and processing of such meta-knowledge
    is unspecified).

Contrary to some claims, X.509 version 1 format is
a perfectly valid certificate format and *NOT*
deprecated form or fashion by X.509 (including 11/2008).

There is no explicit deprecation of X.509 in
rfc5280 either (it is simply not profiled there),
the only thing that could be interpreted as some
form of deprecation is this:

  http://tools.ietf.org/html/rfc5280#page-87

    (k)  If certificate i is a version 3 certificate, verify that the
         basicConstraints extension is present and that cA is set to
         TRUE.  (If certificate i is a version 1 or version 2
         certificate, then the application MUST either verify that
         certificate i is a CA certificate through out-of-band means
         or reject the certificate.  Conforming implementations may
         choose to reject all version 1 and version 2 intermediate
         certificates.)

but this is clearly scoped to the use of X.509 version 1 and version 2
certificates as **intermediate certificates**, and therefore does
neither apply to X.509 version 1 as self-signed RootCA certs, nor
to X.509 version 1 as self-signed non-CA (=end entity) cert.

Note that X.509 (including 11/2008) itself does not have this:

  10.5.1 Basic Certificate checks

  b) For an intermediate version 3 certificate, check that
  basicConstraints is present and that the cA component in the
  basicConstraints extension is TRUE. If the pathLenConstraint
  component is present, check that the current certification
  path does not violate that constraint (ignoring intermediate
  self-issued certificates).

Curious side observation: X.509 Certificate Processing in
section 10.5 is completely silent (ignorant?) about the
KeyUsage extension and its value!

rfc5280 seems better, but does _not_ require the presence of the
KeyUsage extension in a CA certificate (rfc5280,page 87) during
certificate processing--only for issuing by conforming CAs.

      (n)  If a key usage extension is present, verify that the
           keyCertSign bit is set.

> 
> So, in order for a self-signed end-entity certificate to 
> exist, the issuer must be both a CA and an end-entity.

That looks like a contradition in terms.

We probably should seperate semantics (wether an entity
is a CA or is not a CA) from syntax (whether a certificate,
from its attributes an encoding) will be considered a CA
certificate according to the Certificate Processing Rules.

>
> In particular, the issuer of the self-signed EE certificate 
> would have to be "an authority trusted by one or more users 
> to create and assign public-key certificates"

I'm much more interested in the real-world implications
for the installed base -- the "running code".

What the consequences will be based on the Certificate
Processing rules implemented in the installed base when
being faced with the certificates that people create
with the tools that were given to them -- based on
specifications with big holes in them that we gave
to the implementors.

It is about time that we (PKIX WG & IETF) come up
with a BCP for the creation and use of X.509
self-signed non-CA certificates and how those
that already exist are being processed and
which of that comprises the Best Current Practice.

>
> However, I believe that intent was that an entity would be 
> classified as either a CA or an end-entity, but not both, and 
> so I don't think X.509 intended to recognize self-signed EE 
> certificates.

Just as IPv4 was conceived as end-to-end, and real-world
requirements materialized in a solution called NAT.

> 
> But, again, does this really matter?  Any user can choose to 
> make an out-of-band decision to accept any key (a raw public 
> key, a public key in a self-signed certificate, or a 
> public-key in a non-self-signed certificate) for any purpose.

While this is true that users usually have that capability
and do that, it results in the situation that self-signed
non-CA certs and real CA certs get intermixed and processed
by "Certificate Processing rules" that really aren't 
designed to handle this situation.

>
> It may choose to accept the key for use as a trust anchor 
> for certification path validation, to verify signatures on 
> objects other than certificates, or both (or for purposes 
> other than signature verification).

We need provisions in the specification do deal sensibly
with non-CA self-signed certificate to limit their impact
on the security of the PKI-originating certificates.

And no, sticking our head in the sand will not help,
it did not make NAT go away either.

-Martin