Subject: Re: CA vs. EE cert processing

From: [email-masked]
Date: Wed, 07 Apr 1999 13:38:19 GMT

Steve writes:

>This memo examines certificate processing with regard to determining
>whether a certificate is associated with a CA or an EE, to determine where
>the ambiguity lies and thus help clarify this discussion. Upon further
>analysis I discovered that the issue is more complex that I originally
>realized, and so my simple algorithm was oversimplified. However the
>suggestions put forth so far (as best I recall) also seem to miss the
>point, as explained below.
>
>First question: is this a v1 certificate or a v3 certificate?
> ...
>
>Second question: is there a basicConstraints extension present in the
>certificate? If not, then according to RFC 2459 this must be an EE cert,
>since CA certs MUST contain this extension. But, according to X.509, if
the
>constraint is absent (or present but marked non-critical and not
understood
>by the implementation), then it is up to the implementation to use other
>means of determining if the certificate is for a CA or an EE.  At this
>point we have ambiguity, based on examining only the presence or absence
of
>this constraint in a v3 cert.  X.509 does not specify what else should be
>done. So, not knowing if the certificate was issued by an RFC 2459
>compliant CA, or an X.509 compliant CA, we have to go to "Plan B."  Note
>that nothing we change in RFC 2459 can fix this problem as the ambiguity
is
>traceable to X.509.

There are two parts to "this ambiguity".  The one as stated where a PKIX
verifier encounters a certificate without a basicConstraints extension, and
another one where a non-PKIX verifier encounters such a certificate.
Leaving
the first one aside for the moment, PKIX would be a better player in the
broader X.509 world if it chose not to generate certificates that are
ambiguous to such a world.

>If we have a basicConstraints extension, [then everything's fine -
>no ambiguity (JCW)].
>
>Plan B:  We are here because we have a v3 certificate with no
>basicConstraints extension and because we don't know if the CA that issued
>the certificate was operating in compliance with either 2459 or X.509.  We
>now have to examine other fields of the certificate, or have some out of
>band mechanism to help.  X.509 provides no guidance on how to do this,
>which leaves implementers wondering.  RFC 2459 provides no guidance
because
>a CA complying with the RFC would not have this problem.
>
>So, how can we remove this residual ambiguity?  Well, it can't be removed
>by a change only to RFC 2459, because that standard is not the source of
>the ambiguity.  If one were to change X.509, to require that a compliant
CA
>include the basicConstraints extension (critical or not), when a
>certificate was issued to a CA, then the ambiguity would be removed at its
>source.  If this change were made to X.509, no change to 2459 would be
>required.  Specifically, changing 2459 to call for inclusion of this
>constraint for EE certificates (either as a SHOULD or MUST) would not
>address the ambiguity encountered above.

On the contrary, changing RFC 2459 to require the inclusion of the
basicConstraints extension on all certificates would help alleviate this
ambiguity, and in some cases could completely address it.  As you have
pointed out, there is only an ambiguity when processing a certificate
without a basicConstraints extension.  By constraining PKIX to avoid
generating such certificates, we would avoid any confusion in
certificates generated by PKIX systems, whether or not the verifier
is PKIX-compliant, and more importantly whether or not the verifier
knows that the issuing system was PKIX-compliant.

If RFC2459 were modified to require the extension, then it would
be permissible for a verifier to make its own decisions about how
to handle an ambiguous certificate (one without a basicConstraints
extension).  Reasonable options might include rejecting the
certificate, asking for user guidance, or applying site-specific
policy to determine how to treat it.  The way RFC2459 is currently
written, a PKIX verifier doesn't have these options - it must treat
such a certificate as an EE certificate, whether or not that's the
right thing to do (i.e. whether or not the issuing CA meant the
certificate to be an EE or a CA cert).

>Some have suggested that we should consider changes to 2459 to help
>alleviate problems resulting from CAs that do not comply with 2459.  The
>above analysis suggests that if the source of the certificate is an X.509
>compliant CA, the solution lies with a change to X.509.  If the CA is not
>assumed to comply with either 2459 or X.509, I do not see how fixing
either
>2459 or X.509 could possible help.

The PKIX working group doesn't have the ability to change X.509; we
only have control of the PKIX specs.  A change to RFC 2459 would allow
us to avoid stumbling into into this ambiguity in X.509, with the result
that:

i)  PKIX certificates would not be ambiguous to an X.509 verifier,

and ii) PKIX verifiers would be able to distinguish ambiguous non-PKIX
certs
from unambiguous certs, without having to know whether the certificate
issuer was PKIX-compliant.

John

---

From: Stephen Kent <[email-masked]>
Date: Wed, 7 Apr 1999 21:01:05 -0400

John,

<snip>

>ambiguous to such a world.

The ambiguity exists in ALL verifiers, PKIX or not.  Thus pointing the
finger at PKIX is not rational.

<snip>

>knows that the issuing system was PKIX-compliant.

Changing PKIX to mandate inclusion of basicConstrants would improve the
odds, but not fix the problem.  I don't view changes that have only
probabilistic improvements to be warranted, in general, and certainly not
here.

>certificate to be an EE or a CA cert).

What is needed is an algorithm for a verifier to use to determine whether a
cert is an EE cert or a CA cert. We do not have such an algorithm in the
face of certs that are generated in compliance with X.509, period.  I don't
want a heuristic improvement here, I want a fix.

<snip>

>issuer was PKIX-compliant.

As David Kemp pointed out, we can file a DR to address this problem.

Steve

---

From: Moshe Litvin <[email-masked]>
Date: Thu, 08 Apr 1999 12:05:06 +0300

Stephen Kent wrote:

<snip>

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

> probabilistic improvements to be warranted, in general, and certainly not

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?

> want a heuristic improvement here, I want a fix.

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.

> As David Kemp pointed out, we can file a DR to address this problem.

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.

Moshe

---

From: Stephen Kent <[email-masked]>
Date: Thu, 8 Apr 1999 20:47:47 -0400

Moseh,

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

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

<snip>
>Admittedly the verifier will have heuristics but the CA can ensure that they

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

>For some reason PKIX decided to ignore the recommendation and invent it's own

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.

Steve

---

From: Moshe Litvin <[email-masked]>
Date: Mon, 12 Apr 1999 12:32:01 +0300

Steve,

<snip>

Stephen Kent wrote:

> 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

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.

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

> extensions issued by those CAs.

This is exatclty what I wrote.

>  If we were willing to posit that no such

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.

> 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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 14 Apr 1999 09:26:12 -0400

Moshe,

<snip>

>certificate that it issues than no certificate that the CA issues needs

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

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

>the certificate as EE certificate and where it could have accepted it as a CA

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>

>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

---

From: Moshe Litvin <[email-masked]>
Date: Thu, 15 Apr 1999 09:23:58 +0300

Stephen Kent wrote:

<snip>

<snip>

Steve,

The problem is determining weather a certificate is eligible to be in a
certificate path prior to the terminal cert. That is, is it an EE certificate or a
CA certificate. And the problem is what to do if the certificate doesn't contain
the basicConstraints extension.

Moshe