Subject: Re: CA vs. EE cert processing

From: [email-masked]
Date: Fri, 09 Apr 1999 13:58:10 GMT

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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 13 Apr 1999 16:51:18 -0400

John,

<snip>

>it (if it is only interested in talking with PKIX-compliant

we define determinism differently.  the "else" at the end of your decision
tree is still where the problem arises.

>a non-PKIX compliant CA cert that has chosen not to use the extension.

or an X.509 compliant CA that has chosen not to innclue the extension; we
can't fix CAs that are non-compliant witgh both PKIX and X.509, and so I
don't worry about them in analyzing these problems; but it is X.509 that
creates the problem, all by itself, in the realm of compliant CAs.

>be eliminated altogether, and at least PKIX-compliant certificates

yes, it would be progress, but it is not a desirable end state.

>PKIX certs contain the extension is still a win as it eliminates the

yes, but our focus in PKIX is on v3 certs, as discussed before, and nothing
we can do in 2459 will fix that legacy problem.

>a win as it eliminates the ambiguity immediately.

OK, let's igine this one.

>that are compliant with both current X.509 and the new X.509.
yes.

>that are unambiguous under today's X.509 is worthwhile.
we don't reach the same conclusion, probably because "worthwhile" is
subjective and we've already determined that we have different values wrt
this debate.

>still have the option of treating non-extended certs as EE certs).

Itoo  am surprised that there is disagreement, but about the need to change
X.509, not to change 2459.  PKIX is new, but X.509 for v3 is essentially
just as new.  an argument based on deployed PKIX vs. X.509 v3 compliant
systems does not hold water. I object to the notion that we should change
2459 to compensate for what strikes me as an oversight in X.509.

Steve