CA vs. EE cert processing

[Stephen Kent <kent@xxxxxxx>]

Folks,

This memo examines certificate processing with regard to determining
whether a certificate is associated with a CA or an EE, to determine where
the ambiguity lies and thus help clarify this discussion. Upon further
analysis I discovered that the issue is more complex that I originally
realized, and so my simple algorithm was oversimplified. However the
suggestions put forth so far (as best I recall) also seem to miss the
point, as explained below.

First question: is this a v1 certificate or a v3 certificate?  If v1, there
was no way to mark the certificate as a CA or EE explicitly, so some other
information must be used. Nothing we say in 2459 is applicable here as we
deal only with v3 certs, and thus no changes in 2459 would change how an
implementation makes this determination for a v1 cert.  Whatever means an
implementation used to make this determination for v1 certs can still be
employed.  Thus v1 certs will not be addressed in the remainder of this
analysis, and I assume that software should be written to be sensitive to
whether it is dealing with v1 or v3 certificates.

Second question: is there a basicConstraints extension present in the
certificate? If not, then according to RFC 2459 this must be an EE cert,
since CA certs MUST contain this extension. But, according to X.509, if the
constraint is absent (or present but marked non-critical and not understood
by the implementation), then it is up to the implementation to use other
means of determining if the certificate is for a CA or an EE.  At this
point we have ambiguity, based on examining only the presence or absence of
this constraint in a v3 cert.  X.509 does not specify what else should be
done. So, not knowing if the certificate was issued by an RFC 2459
compliant CA, or an X.509 compliant CA, we have to go to "Plan B."  Note
that nothing we change in RFC 2459 can fix this problem as the ambiguity is
traceable to X.509.

If we have a basicConstraints extension, is it NULL or does it have the CA
flag set to TRUE.  If NULL, then it is an EE certificate according to both
RFC 2459 and X.509 (even though 2459 suggests that one not bother to
include the extension in this case). If the CA flag is TRUE, then it is a
CA certificate, according to both 2459 and X.509.  So, if we get to this
point, we have no ambiguity for either CA or EE certs.

Plan B:  We are here because we have a v3 certificate with no
basicConstraints extension and because we don't know if the CA that issued
the certificate was operating in compliance with either 2459 or X.509.  We
now have to examine other fields of the certificate, or have some out of
band mechanism to help.  X.509 provides no guidance on how to do this,
which leaves implementers wondering.  RFC 2459 provides no guidance because
a CA complying with the RFC would not have this problem.

So, how can we remove this residual ambiguity?  Well, it can't be removed
by a change only to RFC 2459, because that standard is not the source of
the ambiguity.  If one were to change X.509, to require that a compliant CA
include the basicConstraints extension (critical or not), when a
certificate was issued to a CA, then the ambiguity would be removed at its
source.  If this change were made to X.509, no change to 2459 would be
required.  Specifically, changing 2459 to call for inclusion of this
constraint for EE certificates (either as a SHOULD or MUST) would not
address the ambiguity encountered above.

Some have suggested that we should consider changes to 2459 to help
alleviate problems resulting from CAs that do not comply with 2459.  The
above analysis suggests that if the source of the certificate is an X.509
compliant CA, the solution lies with a change to X.509.  If the CA is not
assumed to comply with either 2459 or X.509, I do not see how fixing either
2459 or X.509 could possible help.