Subject: RE: Changes to RFC2459

From: Alex Deacon <[email-masked]>
Date: Tue, 23 Mar 1999 15:25:20 -0800

I agree that there are cases where basicConstraints and keyUsage extensions
in end entity certificates may be  redundant, however I also feel that CAs
should have the option of using an empty sequence to signify an end entity
cert.  The X.509 spec allows for this...

From section 12.4.2.1 of X.509, Note 2 "To constrain a certificate subject
to being only an end entity, i.e. not a CA, the issuer can include this
extension field containing only an empty SEQUENCE value. 

Other than possible redundant info, I cant think of any other reasons why
PKIX should explicitly not allow this.

Alex

> -----Original Message-----
> From: Brian Korver [mailto:[email-masked]]
> Sent: Tuesday, March 23, 1999 2:49 PM
> To: Jim Schaad (Exchange)
> Cc: IETF-PKIX (E-mail)
> Subject: Re: Changes to RFC2459
> 
> 
> "Jim Schaad (Exchange)" wrote:
> > 
> > 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.
> 
> 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.
> 
> 
> > 
> > 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: Stephen Kent <[email-masked]>
Date: Wed, 24 Mar 1999 05:52:55 -0500

Alex,

>extension field containing only an empty SEQUENCE value.

Well, that's a hack I hadn't noticed before! Guess one should always reed
the fine print. I assume the motivation was to produce a very small,
explicit marker for EE certs.  It is syntactically valid since the CA flag
has a DEFAULT specification of FALSE, and path length subcomponent of this
extension is marked OPTIONAL, and path length subcomponent of this
extension is marked OPTIONAL.  I think the rationale for 2459 strongly
discouraging use of this extension for EEs cert is to avoidthe confusion
sometimes associated with NULL encodings, and because it seems redundant,
irrespective of the presence of key usage.

Steve