Subject: RE: CA vs. EE cert processing

From: Alan Lloyd <[email-masked]>
Date: Wed, 14 Apr 1999 21:00:37 +1000

Comments 

Steve wrote:

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

I am also surprised that with the number of X.500 specialists on this
list that they are not saying that X.509 has errors.
I think most of think that X.509 is a standard that provides a
transition strategy to the use of extensions. And RFC 2450 is a profile
(hence its title) that determines how (repeat HOW) that standard is
used.
If the profile reflects an ambiguity (which is deemed by a few) in the
standard, then the profile document has failed.

Simple isnt it.

regards alan

---

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

Alan,

>standard, then the profile document has failed.

Simplie or simplistic :-).

Based on my quite a few years of experience in the IETF community, I'd say
that tone and duration of this message exchange have deterred many people
from joining in.  I have received several private messages expressing
support for the position I have stated, but these, and probably other
folks, don't want to become engaged in a protracted e-mail exchange of this
sort.

I've submitted a defect report to the X.509 editor and the matter will be
addressed at the meeting next week.  I suggest we not waste time on the
list until we hear from the X.509 folks.

steve

---

From: Russ Housley <[email-masked]>
Date: Thu, 15 Apr 1999 14:32:32 -0400

I have kept quiet on this thread.  I cannot hold it in any longer.

RFC 2459 has no ambiguity in this area.  If basicConstraints is present,
then the cA boolean tells whether the certificate belongs to a CA or an EE.
 If basicConstraints is absent, then the certificate belongs to an EE.  Period.

If an implementor wishes to support other profiles in addition to RFC 2459,
then the logic may be more complex.  Fine.  This was a market choice made
by the implementor.

I do not think that RFC 2459 should be altered to make support for multiple
profiles easier.

Russ

---

From: Moshe Litvin <[email-masked]>
Date: Sun, 18 Apr 1999 12:17:12 +0300

Russ,

>  If basicConstraints is absent, then the certificate belongs to an EE.  Period.

The term "ambiguity" is not the exact term. The problem is not ambiguity but
relying on out of band data. RFC 2459 is very clear as long as you know by out of
band data that the certificate was issued by RFC 2459 compliant CA.

> I do not think that RFC 2459 should be altered to make support for multiple

Why? do you think that whole world would choose adopt RFC 2459 and all the other
profiles (including the base X.509) will become obsolete?

Why would you force software designers to choose between two contradicting profiles
of the same standard when you can easily allow them to support both?

What is the compelling reason to prevent interpretability in that way?

Moshe

---

From: Russ Housley <[email-masked]>
Date: Mon, 19 Apr 1999 12:20:51 -0400

Moshe:

I will say is again.  There is not a problem with RFC 2459.  If an
implementor wishes to support more than one profile, then that implementor
must resolve any ambiguities that result.

As far as I am concerned, this issue has been thrashed to death, and we
should bring this thread to an end.

Russ

---

From: Moshe Litvin <[email-masked]>
Date: Mon, 19 Apr 1999 20:01:36 +0300

Russ Housley wrote:

> Moshe:
>
> I will say is again.  There is not a problem with RFC 2459.

What I tell you three times is true.

> If an