rfc3280.txt

PKIX的RFC英文文档

   The Certificate is a SEQUENCE of three required fields.  The fields
   are described in detail in the following subsections.

4.1.1.1  tbsCertificate

   The field contains the names of the subject and issuer, a public key
   associated with the subject, a validity period, and other associated
   information.  The fields are described in detail in section 4.1.2;
   the tbsCertificate usually includes extensions which are described in
   section 4.2.

4.1.1.2  signatureAlgorithm

   The signatureAlgorithm field contains the identifier for the
   cryptographic algorithm used by the CA to sign this certificate.
   [PKIXALGS] lists supported signature algorithms, but other signature
   algorithms MAY also be supported.

   An algorithm identifier is defined by the following ASN.1 structure:

   AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }

   The algorithm identifier is used to identify a cryptographic
   algorithm.  The OBJECT IDENTIFIER component identifies the algorithm
   (such as DSA with SHA-1).  The contents of the optional parameters
   field will vary according to the algorithm identified.

   This field MUST contain the same algorithm identifier as the
   signature field in the sequence tbsCertificate (section 4.1.2.3).

4.1.1.3  signatureValue

   The signatureValue field contains a digital signature computed upon
   the ASN.1 DER encoded tbsCertificate.  The ASN.1 DER encoded
   tbsCertificate is used as the input to the signature function.  This




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


   signature value is encoded as a BIT STRING and included in the
   signature field.  The details of this process are specified for each
   of algorithms listed in [PKIXALGS].

   By generating this signature, a CA certifies the validity of the
   information in the tbsCertificate field.  In particular, the CA
   certifies the binding between the public key material and the subject
   of the certificate.

4.1.2  TBSCertificate

   The sequence TBSCertificate contains information associated with the
   subject of the certificate and the CA who issued it.  Every
   TBSCertificate contains the names of the subject and issuer, a public
   key associated with the subject, a validity period, a version number,
   and a serial number; some MAY contain optional unique identifier
   fields.  The remainder of this section describes the syntax and
   semantics of these fields.  A TBSCertificate usually includes
   extensions.  Extensions for the Internet PKI are described in Section
   4.2.

4.1.2.1  Version

   This field describes the version of the encoded certificate.  When
   extensions are used, as expected in this profile, version MUST be 3
   (value is 2).  If no extensions are present, but a UniqueIdentifier
   is present, the version SHOULD be 2 (value is 1); however version MAY
   be 3.  If only basic fields are present, the version SHOULD be 1 (the
   value is omitted from the certificate as the default value); however
   the version MAY be 2 or 3.

   Implementations SHOULD be prepared to accept any version certificate.
   At a minimum, conforming implementations MUST recognize version 3
   certificates.

   Generation of version 2 certificates is not expected by
   implementations based on this profile.

4.1.2.2  Serial number

   The serial number MUST be a positive integer assigned by the CA to
   each certificate.  It MUST be unique for each certificate issued by a
   given CA (i.e., the issuer name and serial number identify a unique
   certificate).  CAs MUST force the serialNumber to be a non-negative
   integer.






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


   Given the uniqueness requirements above, serial numbers can be
   expected to contain long integers.  Certificate users MUST be able to
   handle serialNumber values up to 20 octets.  Conformant CAs MUST NOT
   use serialNumber values longer than 20 octets.

   Note: Non-conforming CAs may issue certificates with serial numbers
   that are negative, or zero.  Certificate users SHOULD be prepared to
   gracefully handle such certificates.

4.1.2.3  Signature

   This field contains the algorithm identifier for the algorithm used
   by the CA to sign the certificate.

   This field MUST contain the same algorithm identifier as the
   signatureAlgorithm field in the sequence Certificate (section
   4.1.1.2).  The contents of the optional parameters field will vary
   according to the algorithm identified.  [PKIXALGS] lists the
   supported signature algorithms, but other signature algorithms MAY
   also be supported.

4.1.2.4  Issuer

   The issuer field identifies the entity who has signed and issued the
   certificate.  The issuer field MUST contain a non-empty distinguished
   name (DN).  The issuer field is defined as the X.501 type Name
   [X.501].  Name is defined by the following ASN.1 structures:

   Name ::= CHOICE {
     RDNSequence }

   RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

   RelativeDistinguishedName ::=
     SET OF AttributeTypeAndValue

   AttributeTypeAndValue ::= SEQUENCE {
     type     AttributeType,
     value    AttributeValue }

   AttributeType ::= OBJECT IDENTIFIER

   AttributeValue ::= ANY DEFINED BY AttributeType








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


   DirectoryString ::= CHOICE {
         teletexString           TeletexString (SIZE (1..MAX)),
         printableString         PrintableString (SIZE (1..MAX)),
         universalString         UniversalString (SIZE (1..MAX)),
         utf8String              UTF8String (SIZE (1..MAX)),
         bmpString               BMPString (SIZE (1..MAX)) }

   The Name describes a hierarchical name composed of attributes, such
   as country name, and corresponding values, such as US.  The type of
   the component AttributeValue is determined by the AttributeType; in
   general it will be a DirectoryString.

   The DirectoryString type is defined as a choice of PrintableString,
   TeletexString, BMPString, UTF8String, and UniversalString.  The
   UTF8String encoding [RFC 2279] is the preferred encoding, and all
   certificates issued after December 31, 2003 MUST use the UTF8String
   encoding of DirectoryString (except as noted below).  Until that
   date, conforming CAs MUST choose from the following options when
   creating a distinguished name, including their own:

      (a)  if the character set is sufficient, the string MAY be
      represented as a PrintableString;

      (b)  failing (a), if the BMPString character set is sufficient the
      string MAY be represented as a BMPString; and

      (c)  failing (a) and (b), the string MUST be represented as a
      UTF8String.  If (a) or (b) is satisfied, the CA MAY still choose
      to represent the string as a UTF8String.

   Exceptions to the December 31, 2003 UTF8 encoding requirements are as
   follows:

      (a)  CAs MAY issue "name rollover" certificates to support an
      orderly migration to UTF8String encoding.  Such certificates would
      include the CA's UTF8String encoded name as issuer and and the old
      name encoding as subject, or vice-versa.

      (b)  As stated in section 4.1.2.6, the subject field MUST be
      populated with a non-empty distinguished name matching the
      contents of the issuer field in all certificates issued by the
      subject CA regardless of encoding.

   The TeletexString and UniversalString are included for backward
   compatibility, and SHOULD NOT be used for certificates for new
   subjects.  However, these types MAY be used in certificates where the
   name was previously established.  Certificate users SHOULD be
   prepared to receive certificates with these types.



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


   In addition, many legacy implementations support names encoded in the
   ISO 8859-1 character set (Latin1String) [ISO 8859-1] but tag them as
   TeletexString.  TeletexString encodes a larger character set than ISO
   8859-1, but it encodes some characters differently.  Implementations
   SHOULD be prepared to handle both encodings.

   As noted above, distinguished names are composed of attributes.  This
   specification does not restrict the set of attribute types that may
   appear in names.  However, conforming implementations MUST be
   prepared to receive certificates with issuer names containing the set
   of attribute types defined below.  This specification RECOMMENDS
   support for additional attribute types.

   Standard sets of attributes have been defined in the X.500 series of
   specifications [X.520].  Implementations of this specification MUST
   be prepared to receive the following standard attribute types in
   issuer and subject (section 4.1.2.6) names:

      * country,
      * organization,
      * organizational-unit,
      * distinguished name qualifier,
      * state or province name,
      * common name (e.g., "Susan Housley"), and
      * serial number.

   In addition, implementations of this specification SHOULD be prepared
   to receive the following standard attribute types in issuer and
   subject names:

      * locality,
      * title,
      * surname,
      * given name,
      * initials,
      * pseudonym, and
      * generation qualifier (e.g., "Jr.", "3rd", or "IV").

   The syntax and associated object identifiers (OIDs) for these
   attribute types are provided in the ASN.1 modules in Appendix A.

   In addition, implementations of this specification MUST be prepared
   to receive the domainComponent attribute, as defined in [RFC 2247].
   The Domain Name System (DNS) provides a hierarchical resource
   labeling system.  This attribute provides a convenient mechanism for
   organizations that wish to use DNs that parallel their DNS names.
   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