Re: CA vs. EE cert processing

[Moshe Litvin <moshe@xxxxxxxxxxxxxxxxxxx>]

Steve,

<snip>

Stephen Kent wrote:

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

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

>
>
> >>
> >> <snip>
> >
> >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?
>
> See my comments above. I was referring to the verifier, not the CA.  Sorry
> for the ambiguity :-)!  The CA doesn't have a problem; verifiers have the
> problem we are trying to address.
>

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.

>
> <snip>
> >
> >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.
>
> No, it cannot!  So long as there are CAs following X.509 but not the 2459
> profile, verifiers would need heuristics to process certs without
> extensions issued by those CAs.

This is exatclty what I wrote.


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

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

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