Re: CA vs. EE cert processing

[John_Wray@xxxxxxxx]

Steve writes:

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

There are two parts to "this ambiguity".  The one as stated where a PKIX
verifier encounters a certificate without a basicConstraints extension, and
another one where a non-PKIX verifier encounters such a certificate.
Leaving
the first one aside for the moment, PKIX would be a better player in the
broader X.509 world if it chose not to generate certificates that are
ambiguous to such a world.

>If we have a basicConstraints extension, [then everything's fine -
>no ambiguity (JCW)].
>
>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.

On the contrary, changing RFC 2459 to require the inclusion of the
basicConstraints extension on all certificates would help alleviate this
ambiguity, and in some cases could completely address it.  As you have
pointed out, there is only an ambiguity when processing a certificate
without a basicConstraints extension.  By constraining PKIX to avoid
generating such certificates, we would avoid any confusion in
certificates generated by PKIX systems, whether or not the verifier
is PKIX-compliant, and more importantly whether or not the verifier
knows that the issuing system was PKIX-compliant.

If RFC2459 were modified to require the extension, then it would
be permissible for a verifier to make its own decisions about how
to handle an ambiguous certificate (one without a basicConstraints
extension).  Reasonable options might include rejecting the
certificate, asking for user guidance, or applying site-specific
policy to determine how to treat it.  The way RFC2459 is currently
written, a PKIX verifier doesn't have these options - it must treat
such a certificate as an EE certificate, whether or not that's the
right thing to do (i.e. whether or not the issuing CA meant the
certificate to be an EE or a CA cert).

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

The PKIX working group doesn't have the ability to change X.509; we
only have control of the PKIX specs.  A change to RFC 2459 would allow
us to avoid stumbling into into this ambiguity in X.509, with the result
that:

i)  PKIX certificates would not be ambiguous to an X.509 verifier,

and ii) PKIX verifiers would be able to distinguish ambiguous non-PKIX
certs
from unambiguous certs, without having to know whether the certificate
issuer was PKIX-compliant.


John