Re: CA vs. EE cert processing

["Aram Perez" <aram@xxxxxxxxx>]

My two cents: I agree with John. Given that RFC2459 is not a "standard" yet
and thus no standard-compliant software exists out there, we should "fix"
RFC2459 to do the right thing for existing legacy software, and the new
RFC2459 compliant software.

Aram Perez
Apple Computer, Inc.

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