Re: CA vs. EE cert processing

[Stephen Kent <kent@xxxxxxxxxxx>]

John,

<snip>

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

The ambiguity exists in ALL verifiers, PKIX or not.  Thus pointing the
finger at PKIX is not rational.

<snip>

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

Changing PKIX to mandate inclusion of basicConstrants would improve the
odds, but not fix the problem.  I don't view changes that have only
probabilistic improvements to be warranted, in general, and certainly not
here.

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

What is needed is an algorithm for a verifier to use to determine whether a
cert is an EE cert or a CA cert. We do not have such an algorithm in the
face of certs that are generated in compliance with X.509, period.  I don't
want a heuristic improvement here, I want a fix.

<snip>

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

As David Kemp pointed out, we can file a DR to address this problem.

Steve