Subject: Changes to RFC2459

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Tue, 23 Mar 1999 12:00:05 -0800

As RFC 2459 moves forward and we start to find problems, we are requested to
bring this to the list  One of the last arguments that I remember (but it
may have been partly in private) had to do with the BasicConstrants for
End-Entities and if the current text is correct.  Currently the RFC states
that the extensions SHOULD NOT be present for End-Entities and is MUST and
critical for CAs. 

Given that lack of information does not really imply that it is an entity.
I feel that CAs need to be given the option of putting the extension on for
all certificates and the SHOULD NOT needs to be changed to either SHOULD (my
preference) or MAY.

A second comment is that the text should be changed to address the question
of dates prior to 1950 as they are probably general time, but not explicitly
stated.  PLease change  in 4.1.2.5 to read "validity dates from the year
1950 through the year 2049 as UTCTime; certificates validtity prior to 1950
and in 2050 or later MUST be encoded as GeneralizedTime."

jim

---

From: Brian Korver <[email-masked]>
Date: Tue, 23 Mar 1999 14:48:36 -0800

> all certificates and the SHOULD NOT needs to be changed to either SHOULD (my

Jim,

I'm not totally against MAY, but I will note that there are cases 
where BasicConstraints in EE certificates is redundant.  For instance, 
if the KeyUsage extension is present, that provides sufficient information 
to determine whether it is a CA or EE certificate.  Similarly, if issuing
the CA certificate contains BasicConstraints with pathLenConstraint==0, 
then the subject certificate must be an EE certificate.

If SHOULD NOT is changed to SHOULD or MAY, I wouldn't mind seeing
text explaining when EE BasicConstraints may be redundant.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 24 Mar 1999 05:49:18 -0500

Jim,

>all certificates and the SHOULD NOT needs to be changed to either SHOULD (my

I don't understand the first part of your comment, assuming that it should
have ended with "an end entity" vs. "an entity."  Since the current spec
says that a CA MUST have the extension, any v3 cert without the extension
is an EE, right?  A cert with the extension is either explicitly marked as
a CA or is NULL and thus explicitly an EE. There is no ambiguity.

Steve

---

From: Moshe Litvin <[email-masked]>
Date: Wed, 24 Mar 1999 19:23:35 +0200

Steve,

There is no ambiguity as long as you know that the certificate issuer completely
obey RFC 2459, if you are not sure then the absence of the extension is
ambiguous. That is if you create a certificate and want to mark it as EE you have
two options:

1. You can go by RFC 2459 and not put the basic constraints extension. Every one
that read the fine prints of the RFC and know that you obey all the fine prints
will understand that this is an EE certificate.

2. You can put a basic constraints extension that explicitly says that the
certificate is not a CA certificate. Everyone that know how to parse the basic
extension will understand it (without assuming what X509 profile you are
following).

I think that the second option is better and should be encourage (if not
mandated).

Moshe

---

From: Stephen Kent <[email-masked]>
Date: Tue, 30 Mar 1999 18:05:30 -0500

Moseh,

>I think that the second option is better and should be encourage (if not

I agree that the second approach leaves less room for error, but then one
could make similar observations for many other aspects of this and other
standards.  For example, throughout X.509 we make use of default values
that result in NULL or non-present encodings.  In fact, the convention that
you suggest we adopt relies on the default value for the CA Boolean being
false, and thus encoded as NULL, right?  Would it not be better, in the
spirit you describe, to have an explicit flag for an EE?

I think this example points out that we have made a number of decisions of
this flavor in these standards.  We are not talking about fundamental
differences, just value judgements about when we want to save space and
rely on implicit values (not in the ASN.1 tagging sense) vs. putting in
explicit flags, version numbers, etc.   The authors of 2459 made a decision
and so far we have not seen a flood of sentiment that suggests we ought to
change this part of the standard.

Steve

---

From: Moshe Litvin <[email-masked]>
Date: Wed, 31 Mar 1999 09:53:42 +0200

Steve,

The main point wasn't about default values, but relying on inventing a PKIX way to
convey information where there was another way in the X.509 standards. By using the
PKIX  way you limit the number of implementations that can understand you correctly
(and you do it without giving them a clue that they misunderstand you).

Moshe