Subject: Re: CA vs. EE cert processing

From: "Aram Perez" <[email-masked]>
Date: Wed, 07 Apr 1999 09:17:44 -0700

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 7 Apr 1999 21:03:33 -0400

Aram,

>RFC2459 compliant software.

The right thing is to avoid the ambiguity introduced by X.509; changing
2459 cannot fix that.  2459 is not broken, so please don't use the term
"fix" when referring to it.

Steve

---

From: Moshe Litvin <[email-masked]>
Date: Thu, 08 Apr 1999 11:47:58 +0300

Steve,

RFC2459 IS broken in the since the it recommends generating EE certificate that
require out of band information to to know that it not a CA certificate.

Moshe

---

From: Moshe Litvin <[email-masked]>
Date: Sun, 11 Apr 1999 10:33:36 +0300

Steve,

If PKIX mandated inclusion of basicConstraint then PKIX CA would issue
certificates that are unambiguous to every X.509v3 verifier. The verifier need
to know that the CA is a PKIX only if the certificate doesn't contain the
extension. Once the extension is in the certificate the ambiguity disappear.

PKIX chose to signal EE certificate by the absence of the extension, a way that
require out of band knowledge.

Based on this analyses I call PKIX broken. You can tell that it is X.509 fault,
but PKIX failed to fix it, when it could easily make things much better.

Mandating a basicConstraint is not the only way for removing that ambiguity.
PKIX can mandate inclusion of a keyUsage extension or of a policy OID that
specify that this is a PKIX certificate. Both of this solutions allows
processing of the certificate without out of band knowledge, but I think that
the basicConstraint way is simpler.

Moshe

Stephen Kent wrote:

> Moshe,
> I disagree. The ambiguity arises only because X.509 allows both EE and CA
> certs to not have this extension, as my analysis shows, and because the
> verifier does not know whether a PKIX or X.509 compliant CA issued the
> cert.
>
> Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 13 Apr 1999 19:20:03 -0400

Moshe,

>extension. Once the extension is in the certificate the ambiguity disappear.

Yes, all of our certs would be unambiguous, but, as I have said several
times before, the problem would exist for PKIX-compliant verifiers.  So, I
am not pursuing a partial solution.

>but PKIX failed to fix it, when it could easily make things much better.

But, that would be a wrong conclusion.  remember, what a verifier needs is
an ability to unambiguously identify CA certs, not EE certs, and we did
that. PKIX fixed the problem that X.509 presented in so far as making CA
certs unambiguous.

>the basicConstraint way is simpler.

Yes, we could trigger on other extensions, but I think that misses the
point, i.e., X.509 needs to be fixed.

Steve