rfc2459.txt

PKIX的RFC英文文档

   series.  Such an implementation will recognize a superset of name
   matches recognized by the algorithm specified above.

4.1.2.5  Validity

   The certificate validity period is the time interval during which the
   CA warrants that it will maintain information about the status of the
   certificate. The field is represented as a SEQUENCE of two dates:
   the date on which the certificate validity period begins (notBefore)
   and the date on which the certificate validity period ends
   (notAfter).  Both notBefore and notAfter may be encoded as UTCTime or
   GeneralizedTime.

   CAs conforming to this profile MUST always encode certificate
   validity dates through the year 2049 as UTCTime; certificate validity
   dates in 2050 or later MUST be encoded as GeneralizedTime.





Housley, et. al.            Standards Track                    [Page 21]

RFC 2459        Internet X.509 Public Key Infrastructure    January 1999


4.1.2.5.1  UTCTime

   The universal time type, UTCTime, is a standard ASN.1 type intended
   for international applications where local time alone is not
   adequate.  UTCTime specifies the year through the two low order
   digits and time is specified to the precision of one minute or one
   second.  UTCTime includes either Z (for Zulu, or Greenwich Mean Time)
   or a time differential.

   For the purposes of this profile, UTCTime values MUST be expressed
   Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are
   YYMMDDHHMMSSZ), even where the number of seconds is zero.  Conforming
   systems MUST interpret the year field (YY) as follows:

      Where YY is greater than or equal to 50, the year shall be
      interpreted as 19YY; and

      Where YY is less than 50, the year shall be interpreted as 20YY.

4.1.2.5.2  GeneralizedTime

   The generalized time type, GeneralizedTime, is a standard ASN.1 type
   for variable precision representation of time.  Optionally, the
   GeneralizedTime field can include a representation of the time
   differential between local and Greenwich Mean Time.

   For the purposes of this profile, GeneralizedTime values MUST be
   expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e.,
   times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
   GeneralizedTime values MUST NOT include fractional seconds.

4.1.2.6  Subject

   The subject field identifies the entity associated with the public
   key stored in the subject public key field.  The subject name may be
   carried in the subject field and/or the subjectAltName extension.  If
   the subject is a CA (e.g., the basic constraints extension, as
   discussed in 4.2.1.10, is present and the value of cA is TRUE,) then
   the subject field MUST be populated with a non-empty distinguished
   name matching the contents of the issuer field (see sec. 4.1.2.4) in
   all certificates issued by the subject CA.  If subject naming
   information is present only in the subjectAltName extension (e.g., a
   key bound only to an email address or URI), then the subject name
   MUST be an empty sequence and the subjectAltName extension MUST be
   critical.






Housley, et. al.            Standards Track                    [Page 22]

RFC 2459        Internet X.509 Public Key Infrastructure    January 1999


   Where it is non-empty, the subject field MUST contain an X.500
   distinguished name (DN). The DN MUST be unique for each subject
   entity certified by the one CA as defined by the issuer name field. A
   CA may issue more than one certificate with the same DN to the same
   subject entity.

   The subject name field is defined as the X.501 type Name.
   Implementation requirements for this field are those defined for the
   issuer field (see sec.  4.1.2.4).  When encoding attribute values of
   type DirectoryString, the encoding rules for the issuer field MUST be
   implemented.  Implementations of this specification MUST be prepared
   to receive subject names containing the attribute types required for
   the issuer field.  Implementations of this specification SHOULD be
   prepared to receive subject names containing the recommended
   attribute types for the issuer field.  The syntax and associated
   object identifiers (OIDs) for these attribute types are provided in
   the ASN.1 modules in Appendices A and B.  Implementations of this
   specification MAY use these comparison rules to process unfamiliar
   attribute types (i.e., for name chaining). This allows
   implementations to process certificates with unfamiliar attributes in
   the subject name.

   In addition, legacy implementations exist where an RFC 822 name is
   embedded in the subject distinguished name as an EmailAddress
   attribute.  The attribute value for EmailAddress is of type IA5String
   to permit inclusion of the character '@', which is not part of the
   PrintableString character set.  EmailAddress attribute values are not
   case sensitive (e.g., "[e-mail]" is the same as
   "[e-mail]").

   Conforming implementations generating new certificates with
   electronic mail addresses MUST use the rfc822Name in the subject
   alternative name field (see sec. 4.2.1.7) to describe such
   identities.  Simultaneous inclusion of the EmailAddress attribute in
   the subject distinguished name to support legacy implementations is
   deprecated but permitted.

4.1.2.7  Subject Public Key Info

   This field is used to carry the public key and identify the algorithm
   with which the key is used. The algorithm is identified using the
   AlgorithmIdentifier structure specified in section 4.1.1.2. The
   object identifiers for the supported algorithms and the methods for
   encoding the public key materials (public key and parameters) are
   specified in section 7.3.






Housley, et. al.            Standards Track                    [Page 23]

RFC 2459        Internet X.509 Public Key Infrastructure    January 1999


4.1.2.8  Unique Identifiers

   These fields may only appear if the version is 2 or 3 (see sec.
   4.1.2.1).  The subject and issuer unique identifiers are present in
   the certificate to handle the possibility of reuse of subject and/or
   issuer names over time.  This profile recommends that names not be
   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.






Housley, et. al.            Standards Track                    [Page 24]

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.



Housley, et. al.            Standards Track                    [Page 25]

RFC 2459        Internet X.509 Public Key Infrastructure    January 1999


   The value of the keyIdentifier field SHOULD be derived from the
   public key used to verify the certificate's signature or a method
   that generates unique values.  Two common methods for generating key
   identifiers from the public key are described in (sec. 4.2.1.2). One
   common method for generating unique values isdescribed in (sec.
   4.2.1.2).  Where a key identifier has not been previously
   established, this specification recommends use of one of these
   methods for generating keyIdentifiers.

   This profile recommends support for the key identifier method by all
   certificate users.

   This extension MUST NOT be marked critical.

   id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 35 }

   AuthorityKeyIdentifier ::= SEQUENCE {
      keyIdentifier             [0] KeyIdentifier           OPTIONAL,
      authorityCertIssuer       [1] GeneralNames            OPTIONAL,
      authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }

   KeyIdentifier ::= OCTET STRING

4.2.1.2  Subject Key Identifier

   The subject key identifier extension provides a means of identifying
   certificates that contain a particular public key.

   To facilitate chain building, this extension MUST appear in all con-
   forming CA certificates, that is, all certificates including the
   basic constraints extension (see sec. 4.2.1.10) where the value of cA
   is TRUE.  The value of the subject key identifier MUST be the value
   placed in the key identifier field of the Authority Key Identifier
   extension (see sec. 4.2.1.1) of certificates issued by the subject of
   this certificate.

   For