PROXY  WHOIS  RQUOTE  TEXTS  SOFT  FOREX  BBOARD
 Music  Philosophy  Code  Literature  Russian

= ROOT|Technical|RFC|rfc2459.txt =

page 14 of 73



   reused for different entities and that Internet certificates not make
   use of unique identifiers.  CAs conforming to this profile SHOULD NOT
   generate certificates with unique identifiers.  Applications
   conforming to this profile SHOULD be capable of parsing unique
   identifiers and making comparisons.

4.1.2.9  Extensions

   This field may only appear if the version is 3 (see sec. 4.1.2.1).
   If present, this field is a SEQUENCE of one or more certificate
   extensions. The format and content of certificate extensions in the
   Internet PKI is defined in section 4.2.

4.2  Standard Certificate Extensions

   The extensions defined for X.509 v3 certificates provide methods for
   associating additional attributes with users or public keys and for
   managing the certification hierarchy.  The X.509 v3 certificate
   format also allows communities to define private extensions to carry
   information unique to those communities.  Each extension in a
   certificate may be designated as critical or non-critical.  A
   certificate using system MUST reject the certificate if it encounters
   a critical extension it does not recognize; however, a non-critical
   extension may be ignored if it is not recognized.  The following
   sections present recommended extensions used within Internet
   certificates and standard locations for information.  Communities may
   elect to use additional extensions; however, caution should be
   exercised in adopting any critical extensions in certificates which
   might prevent use in a general context.

   Each extension includes an OID and an ASN.1 structure.  When an
   extension appears in a certificate, the OID appears as the field
   extnID and the corresponding ASN.1 encoded structure is the value of
   the octet string extnValue.  Only one instance of a particular
   extension may appear in a particular certificate. For example, a
   certificate may contain only one authority key identifier extension
   (see sec. 4.2.1.1).  An extension includes the boolean critical, with
   a default value of FALSE.  The text for each extension specifies the
   acceptable values for the critical field.







 
RFC 2459        Internet X.509 Public Key Infrastructure    January 1999


   Conforming CAs MUST support key identifiers (see sec. 4.2.1.1 and
   4.2.1.2), basic constraints (see sec. 4.2.1.10), key usage (see sec.
   4.2.1.3), and certificate policies (see sec. 4.2.1.5) extensions. If
   the CA issues certificates with an empty sequence for the subject
   field, the CA MUST support the subject alternative name extension
   (see sec. 4.2.1.7).  Support for the remaining extensions is
   OPTIONAL. Conforming CAs may support extensions that are not
   identified within this specification; certificate issuers are
   cautioned that marking such extensions as critical may inhibit
   interoperability.

   At a minimum, applications conforming to this profile MUST recognize
   the extensions which must or may be critical in this specification.
   These extensions are:  key usage (see sec. 4.2.1.3), certificate
   policies (see sec. 4.2.1.5), the subject alternative name (see sec.
   4.2.1.7), basic constraints (see sec. 4.2.1.10), name constraints
   (see sec. 4.2.1.11), policy constraints (see sec. 4.2.1.12), and
   extended key usage (see sec. 4.2.1.13).

   In addition, this profile RECOMMENDS application support for the
   authority and subject key identifier (see sec. 4.2.1.1 and 4.2.1.2)
   extensions.

4.2.1  Standard Extensions

   This section identifies standard certificate extensions defined in
   [X.509] for use in the Internet PKI.  Each extension is associated
   with an OID defined in [X.509].  These OIDs are members of the id-ce
   arc, which is defined by the following:

   id-ce   OBJECT IDENTIFIER ::=  {joint-iso-ccitt(2) ds(5) 29}

4.2.1.1  Authority Key Identifier

   The authority key identifier extension provides a means of
   identifying the public key corresponding to the private key used to
   sign a certificate. This extension is used where an issuer has
   multiple signing keys (either due to multiple concurrent key pairs or
   due to changeover).  The identification may be based on either the
   key identifier (the subject key identifier in the issuer's
   certificate) or on the issuer name and serial number.

   The keyIdentifier field of the authorityKeyIdentifier extension MUST
   be included in all certificates generated by conforming CAs to
   facilitate chain building.  There is one exception; where a CA
   distributes its public key in the form of a "self-signed"
   certificate, the authority key identifier may be omitted.  In this
   case, the subject and authority key identifiers would be identical.


=14=

1.8|9|10|11|12|13| < PREV = PAGE 14 = NEXT > |15|16|17|18|19|20.73

UP TO ROOT | UP TO DIR | TO FIRST PAGE

Google
 


E-mail Facebook Google Digg del.icio.us BlinkList Fark Furl Ma.gnolia Netscape NewsVine Reddit Slashdot Spurl StumbleUpon Technorati YahooMyWeb LiveJournal Blogmarks TwitThis Live News2.ru BobrDobr.ru Memori.ru MoeMesto.ru

0.014369 wallclock secs ( 0.01 usr + 0.00 sys = 0.01 CPU)