Re: CA vs. EE cert processing

[Stephen Kent <kent@xxxxxxxxxxx>]

Moshe,

<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.
>
>Why? If a certificate contain the extension no heuristics are necessary for
>validating this certificate. If a CA put the basicConstraint extension in
>all the
>certificate that it issues than no certificate that the CA issues needs
>heuristics
>to process it.

I think you're veering away from the core problem here.  If we assume a
PKIX-only environment, then we have no ambiguity.  if we assume a mixed
2459 and X.509 environment, then we have ambuguity and a 2459 change cannot
unilaterally fix it.  (By the way, your last sentence should read "then the
certificate verifier ..." not "then the CA ...")

>> I want to
>> deterministic solution to the problem, and the suggested change to 2459
>> does not yield that.
>
>The suggested solution is not complete but it is very deterministic. If it
>will be
>accepted in its strongest form (MUST put basicConstraint in all the
>certificate)
>then no PKIX CA will issue a certificate that needs heuristics by X.509
>verifier
>(be it PKIX, other profile or raw X.509).
>
>A CA can create unambiguous certificates. We should encourage them to do so.

Again, we seem to be loosing track on the context.  Certs issued in
compliance with 2459 are unambiguous, relative to that standard.

<snip>
>
>The verifier has the ambiguity, but the CA can help him solve it. The
>verifier code
>will have some kind of heuristics but they won't be triggered if the CA will
>produce unambiguous certificates.

It can help, but a partial solution is not very satisfying and I am not
persuaded that we should change 2459 to address a problem that can be
solved by a change to another, equally newly issued standard.

<snip>

>>  If we were willing to posit that no such
>> CAs will exist, then we would not have a problem, because in a purely
>> 2459-compliant system (CAs and verifiers) there is not ambiguity.  You seem
>> to be switching perspectives in analyzing this issue.
>
>No my perspective is fixed. I think that a CA should assume as little as
>possible
>of a possible verifier namely:
>
>1. Correct DER decoding
>2. Correct handling of the basic X.509 fields.
>3. Considering a certificate as invalid if it cannot correctly handle a
>critical
>extension.
>
>A CA is not limited to creating certificates that can be validated by the
>minimal
>verifier but it should try to make sure that if the minimal verifier cannot
>correctly validate the certificate it will fail validation.  X.509
>provides the
>mechanism for doing so in the critical flag.
>
>With this model we can compare both options for basicConstraint. We have 3
>types of
>minimal verifiers with respect to the basicConstraint:
>
>A. Verifier that does not understand basicConstraint.
>B. A verifier that understand basicConstraint.
>C. A verifier that is PKIX compliant and knows by out of band means that
>so is the
>CA
>
>We also have 3 types of EE certificate:
>
>i. Without basicConstraint
>ii. With non-critical basicConstraint
>iii. With critical basicConstraint
>
>You can complete the table and see in which combination the verifier can
>identify
>the certificate as EE certificate and where it could have accepted it as a CA
>certificate.

As David pointed out, this analysis focuses on the wrong cert.  The problem
is NOT for EE certs, but for CA certs. We need to determine if a cert is or
is not a CA cert when we encounter it along a path prior to the terminal
cert.


<snip>

>> X.509 failed to solve this problem because it permits compliant CAs to
>> never include basicConstraints, thus creating the ambiguity.  The notes
>> fail to fix the problem, because they just "recommend" what to do.  In the
>> IETF we try to be very careful in our use of the magir words
>> MUST/SHOULD/MAY to avoid these problems.
>>
>
>I think that recommended is a similar to SHOULD, maybe to MAY. I don't
>think that
>it is "SHOULD NOT", but english isn't my mother's tongue.
>
>My question is still open - why PKIX chose to ignore the recommendation and
>invented private semantics?
>
>X.509 offered a standard syntax , if that wasn't enough we could use private
>syntax. But using private semantics is the worse option.

You are criticising PKIX for not following a recommendation of X.509, but
if 2459 had done so, and merely recommended inclusion of the extension in
EE certs, there would still be ambiguity because a compliant implementation
could still choose to not to include the extenstion for EE certs.  2459
fixed part of the ambiguity created in X.509, by mandating the extension in
CA certs, which are the certs that we have to establish are authorized to
be the issuer in subordinate certs.

X.509 created the ambiguity; this fact is not debatable and I do not plan
to spend any more time on arguments of this form.

steve