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

[Stephen Kent <kent@xxxxxxxxxxx>]

Alan,

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

indefinate antecedent, error ...

>
>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.

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