Re: CA vs. EE cert processing

[Stephen Kent <kent@xxxxxxxxxxx>]

John,

<snip>

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

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

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

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.

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

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

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

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.

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

OK, let's igine this one.

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

>
>It seems that in all cases, having PKIX generate certificates
>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.

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

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