Subject: RE: SEIS: RE: Certificates, Directories, and Distinguished Names

From: Alan Lloyd <[email-masked]>
Date: Fri, 9 Apr 1999 17:46:20 +1000

Thats the same as 509 or near enough. Its not too informative as its
abstract theory rather than operational policy. Oh well.

As a question on basic constrains why is the text in 509 different from
RFC 2459

X.509 - 12.4.2.1 Basic Constraints
This field indicates if the subject may act as a CA, with the certified
public key being used to verify certificate signatures. If so, a
certification path length constraint may also be specified. This field
is defined as follows....

rfc 2459 -4.2.1.10  Basic Constraints

   The basic constraints extension identifies whether the subject of the
   certificate is a CA and how deep a certification path may exist
   through that CA.
........

   This extension MUST appear as a critical extension in all CA
   certificates.  This extension SHOULD NOT appear in end entity
   certificates.

It strikes me that 2459 is ambigious simply because it did not embrase
the X.509 text re "certificate using system" and the fact 2459 uses
SHOULD NOT without actuallly defining the conditions if it is or is not
there in EE - as X.509 states.

regards alan

> -----Original Message-----
> From:	Stephen Kent 
> Sent:	Friday, April 09, 1999 10:30 AM
> To:	Alan Lloyd
> Cc:	[email-masked]; [email-masked]
> Subject:	SEIS:  RE: Certificates, Directories, and Distinguished
> Names
> 
> --- Message on the SEIS mailing list ([email-masked])
> 
> Alan,
> 
> >
> >In addition - who will own the root level key for all this PKIX
> >compliant stuff?
> 
> PKIX does not assume any single root CA in its model. See section 6.1
> of
> 2459 for its discussion of starting points for cert path validation.
> 
> Steve
> 
> 
> ----------------- SEIS mailing list ([email-masked])
> Info about this list: http://www.nc-forum.com/seis
> SEIS Contact: [email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Fri, 9 Apr 1999 16:29:10 -0400

Alan,

>abstract theory rather than operational policy. Oh well.

indefinate antecedent, error ...

>there in EE - as X.509 states.

Because 2459 requires inclusion of the extension in a CA cert, there is no
ambiguity.  If a CA chose to insert the extension in an EE cert, despite
the RFC's admonition, it would be redundant in the 2459 context, but not
cause an error.  You should refer to RFC 2119 to gain a better
understanding of the term "SHOULD" as used in RFCs.

steve