Re: CA vs. EE cert processing

[Moshe Litvin <moshe@xxxxxxxxxxxxxxxxxxx>]

Stephen Kent wrote:

<snip>

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

The ambiguity does exist in ALL verifiers, but it doesn't exist in all CA's. A
CA that follows PKIX creates ambiguous certificates. Only CA that does does
something that it SHOULD NOT do create unambiguous certificates. Here pointing
the finger at PKIX is very rational.

We cannot remove the possibility of ambiguity but we can generate certificates
that are not affected by it.

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

It is not probabilistic improvements. A CA that put the basicConstraints
extension is 100% not ambiguous. What probablistic about that?

Why discourage CA's from generating unambiguous certificates?

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

Adding the extension is not a heuristic improvement, a certificate with the
extension is certificate that doesn't need heuristics period.

Admittedly the verifier will have heuristics but the CA can ensure that they
won't be activated.

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

X.509 already addresses the problem and suggests:

   It is recommended that it be flagged critical, otherwise an entity which is
not
   authorized to be a CA may issue certificates and a certificate-using system
   may unwittingly use such a certificate.

For some reason PKIX decided to ignore the recommendation and invent it's own
private semantics.

Moshe

begin:vcard 
n:Litvin;Moshe
tel;fax:+972 3 5759256
tel;work:+972 3 7534601
x-mozilla-html:TRUE
org:Check Point Software Technologies Ltd.
adr:;;;;;;
version:2.1
email;internet:moshe@CheckPoint.com
fn:Moshe Litvin
end:vcard