Re: CA vs. EE cert processing

[John_Wray@xxxxxxxx]

Steve Kent writes:

>>> 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.
>
>I agree that a CA could put the extension in all certs and thus be able to
>say "not my fault; I did what I could."  But this does not address the
>verifier problem in other than a heuristic fashion.  I want to
>deterministic solution to the problem, and the suggested change to 2459
>does not yield that.

It's purely deterministic.  If PKIX mandated the presence of the
basicConstraints extension, then a verifier could, without any
outside knowledge, immediately categorize a certificate as
"CA cert", "EE cert" or "Unknown (and not PKIX-compliant)".  For
certificates that fall into one of the first two categories,
the certificate would be processed accordingly; for a
certificate in the "unknown" category, the verifier gets to
chose whether to consider the cert as an EE or CA cert, possibly
based on out-of-band information, but may also chose to reject
it (if it is only interested in talking with PKIX-compliant
systems).

If PKIX doesn't mandate the presence of the basicConstraints extension,
then a verifier can't distinguish between a PKIX-complaint EE cert and
a non-PKIX compliant CA cert that has chosen not to use the extension.


Assuming that we file a DR against X.509, then as I see it the X.509
committee has several choices:

i)  Decide that X.509 is fine as-is, and make no change.

ii) Add clarifying text that defines that certificates without a
    basicConstraints extension should be considered to be EE certs.

iii) Mandate that EE certs omit the basicConstraints extension and that
     it is present and critical in CA certs.

iv) Mandate that the basicContraints extension be present in all certs.



If they pick (i), then changing PKIX to require the extension is the
only way to generate certs that are unambiguous to a verifier.
Reducing the impact of the ambiguity is progress, even if it can't
be eliminated altogether, and at least PKIX-compliant certificates
won't trigger it.

If they pick (ii), then PKIX would be fine whether or not we required
basicConstraints in EE certs, and the ambiguity would slowly vanish as
systems that generate un-extended CA certs come into compliance with
X.509.  However, even V1 certs haven't yet vanished from the world,
so I imagine this process is likely to take a long time, so having all
PKIX certs contain the extension is still a win as it eliminates the
ambiguity immediately.

If they pick (iii), the current PKIX spec will be fine (once newly
non-complaint X.509 certs vanish from the world), and a PKIX spec
that mandated the use of basicConstraints in EE certs would be
non-compliant.  However, this would be a non-backwards-compatible
change to X.509, and so if this option were taken, then it would
probably require an accompanying change to the certificate version
number.  For this reason alone, I think this option is unlikely to
be chosen.  A half-way position would be to recommend that EE certs
omit the extension, but to permit verifiers to accept EE certs with
the extension set.  In this case, either flavor of PKIX would be
fine, although having all PKIX certs contain the extension is still
a win as it eliminates the ambiguity immediately.

If they pick (iv), then the current PKIX profile will be non-compliant,
and PKIX will continue to generate certificates that X.509 deems to
be ambiguous.  The proposed change to PKIX would generate certificates
that are compliant with both current X.509 and the new X.509.



It seems that in all cases, having PKIX generate certificates
that are unambiguous under today's X.509 is worthwhile.


I must say, I'm suprised that there is disagreement over this, since
writing a profile to avoid ambiguous areas of its parent spec seems
so fundamental that I must be missing something.  The only down-side
I can see to requiring the extension in all certs is that it costs
a few extra bytes.  There's no significant number of deployed PKIX
systems, so compatibility isn't a major issue (and the proposed
change wouldn't break compatibility anyway, as verifiers would
still have the option of treating non-extended certs as EE certs).


John