Subject: Re: CA vs. EE cert processing

From: "David P. Kemp" <[email-masked]>
Date: Fri, 9 Apr 1999 14:05:43 -0400 (EDT)

> From: [email-masked]
> 
> 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)".

A verifier doesn't need to categorize a particular certificate,
it needs to validate a path.  You are proposing to change the
requirements on EE certs; CA certs are *unaffected* by the proposal.
It doesn't make any difference to the verifier whether the last
cert in a path is definitely an EE, definitely a CA, or unknown.
All that matters is that every cert but the last is definitely
a CA, and requiring a CA=false flag in every EE cert does not
affect the validity of the path.

Software which returns either "valid" or "invalid" when presented
with a path containing ambiguous certs will not change its behavior,
regardless of whether EE cert requirements are changed.

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

Why do you assume that putting the extension into CA certs in response to
a change in X.509 would take a long time, but that putting it into EE
certs in response to a change in PKIX would happen immediately?
There are a lot fewer of the former.  And though we might not wish to
believe it, there might be people out there who use X.509 but not the PKIX
profile :-).  Picking option (ii) would help everyone, not just those in
the Internet universe.

> It seems that in all cases, having PKIX generate certificates
> that are unambiguous under today's X.509 is worthwhile.

How much current software would be helped by changing the requirements
on EE certs (i.e. would magically start behaving differently if PKIX
were modified)?

  My answer: none.

How would changing PKIX affect the development of new verifying software
(i.e. what would new software do differently if PKIX is changed vs.
not changed, recognizing that up to 3 types of certs -
non-RFC2459 X.509, RFC2459, and new-modified-PKIX - will be around
for a while)?

  My answer: nothing.

---

From: Moshe Litvin <[email-masked]>
Date: Mon, 12 Apr 1999 16:04:51 +0300

David,

"David P. Kemp" wrote:

<snip>

> non-RFC2459 X.509, RFC2459, and new-modified-PKIX - will be around

You are asking the wrong questions. The correct questions are:

How much current software would be helped by an EE certificate that contains
the basicConstraint (i.e. won't consider it as a CA certificate in the path
validation process)

    My answer: Every PKIX compliant software(*) and I guess a lot of non PKIX
compliant X.509 software.

How would changing PKIX affect the development of new issuing software
(i.e. what would new software do differently if PKIX is changed vs.
not changed)

    My answer: I guess that most CA vendor that consider the internet as their
market would follow it.

Change to PKIX won't change the verifying software, but its behavior will be
changes as a result in the change of the certificate.

Moshe

(*) PKIX compliant verifier MUST recognize the basicConstraint extension.
Section 4.2 says:

   At a minimum, applications conforming to this profile MUST recognize
   the extensions which must or may be critical in this specification.
   These extensions are:  .... basic constraints (see sec. 4.2.1.10) ....