rfc3280.txt

RFC 的详细文档！

   This is not a replacement for the dNSName component of the




Housley, et. al.            Standards Track                    [Page 20]

RFC 3280        Internet X.509 Public Key Infrastructure      April 2002


   alternative name field.  Implementations are not required to convert
   such names into DNS names.  The syntax and associated OID for this
   attribute type is provided in the ASN.1 modules in Appendix A.

   Certificate users MUST be prepared to process the issuer
   distinguished name and subject distinguished name (section 4.1.2.6)
   fields to perform name chaining for certification path validation
   (section 6).  Name chaining is performed by matching the issuer
   distinguished name in one certificate with the subject name in a CA
   certificate.

   This specification requires only a subset of the name comparison
   functionality specified in the X.500 series of specifications.
   Conforming implementations are REQUIRED to implement the following
   name comparison rules:

      (a)  attribute values encoded in different types (e.g.,
      PrintableString and BMPString) MAY be assumed to represent
      different strings;

      (b) attribute values in types other than PrintableString are case
      sensitive (this permits matching of attribute values as binary
      objects);

      (c)  attribute values in PrintableString are not case sensitive
      (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and

      (d)  attribute values in PrintableString are compared after
      removing leading and trailing white space and converting internal
      substrings of one or more consecutive white space characters to a
      single space.

   These name comparison rules permit a certificate user to validate
   certificates issued using languages or encodings unfamiliar to the
   certificate user.

   In addition, implementations of this specification MAY use these
   comparison rules to process unfamiliar attribute types for name
   chaining.  This allows implementations to process certificates with
   unfamiliar attributes in the issuer name.

   Note that the comparison rules defined in the X.500 series of
   specifications indicate that the character sets used to encode data
   in distinguished names are irrelevant.  The characters themselves are
   compared without regard to encoding.  Implementations of this profile
   are permitted to use the comparison algorithm defined in the X.500
   series.  Such an implementation will recognize a superset of name
   matches recognized by the algorithm specified above.



Housley, et. al.            Standards Track                    [Page 21]

RFC 3280        Internet X.509 Public Key Infrastructure      April 2002


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.

   The validity period for a certificate is the period of time from
   notBefore through notAfter, inclusive.

4.1.2.5.1  UTCTime

   The universal time type, UTCTime, is a standard ASN.1 type intended
   for representation of dates and time.  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.





Housley, et. al.            Standards Track                    [Page 22]

RFC 3280        Internet X.509 Public Key Infrastructure      April 2002


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 (section 4.1.2.4) in
   all certificates issued by the subject CA.  If the subject is a CRL
   issuer (e.g., the key usage extension, as discussed in 4.2.1.3, is
   present and the value of cRLSign is TRUE) then the subject field MUST
   be populated with a non-empty distinguished name matching the
   contents of the issuer field (section 4.1.2.4) in all CRLs issued by
   the subject CRL issuer.  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.

   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 (section 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 Appendix A.  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]").



Housley, et. al.            Standards Track                    [Page 23]

RFC 3280        Internet X.509 Public Key Infrastructure      April 2002


   Conforming implementations generating new certificates with
   electronic mail addresses MUST use the rfc822Name in the subject
   alternative name field (section 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 (e.g., RSA, DSA, or Diffie-Hellman).  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 [PKIXALGS].

4.1.2.8  Unique Identifiers

   These fields MUST only appear if the version is 2 or 3 (section
   4.1.2.1).  These fields MUST NOT appear if the version is 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.

4.1.2.9  Extensions

   This field MUST only appear if the version is 3 (section 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  Certificate Extensions

   The extensions defined for X.509 v3 certificates provide methods for
   associating additional attributes with users or public keys and for
   managing a 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 is designated as either 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



Housley, et. al.            Standards Track                    [Page 24]

RFC 3280        Internet X.509 Public Key Infrastructure      April 2002


   certificates and standard locations for information.  Communities may
   elect to use additional extensions; however, caution ought to 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.  A certificate MUST NOT include more than
   one instance of a particular extension.  For example, a certificate
   may contain only one authority key identifier extension (section
   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.

   Conforming CAs MUST support key identifiers (sections 4.2.1.1 and
   4.2.1.2), basic constraints (section 4.2.1.10), key usage (section
   4.2.1.3), and certificate policies (section 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
   (section 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 following extensions: key usage (section 4.2.1.3), certificate
   policies (section 4.2.1.5), the subject alternative name (section
   4.2.1.7), basic constraints (section 4.2.1.10), name constraints
   (section 4.2.1.11), policy constraints (section 4.2.1.12), extended
   key usage (section 4.2.1.13), and inhibit any-policy (section
   4.2.1.15).

   In addition, applications conforming to this profile SHOULD recognize
   the authority and subject key identifier (sections 4.2.1.1 and
   4.2.1.2), and policy mapping (section 4.2.1.6) 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 th