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

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

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:	ietf-pkix@imc.org; list@seis.nc-forum.com
> Subject:	SEIS:  RE: Certificates, Directories, and Distinguished
> Names
> 
> --- Message on the SEIS mailing list (list@seis.nc-forum.com)
> 
> 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 (list@seis.nc-forum.com)
> Info about this list: http://www.nc-forum.com/seis
> SEIS Contact: info@seis.se