rfc2459.txt

PKIX的RFC英文文档

        extnID      OBJECT IDENTIFIER,
        critical    BOOLEAN DEFAULT FALSE,
        extnValue   OCTET STRING  }

   The following items describe the X.509 v3 certificate for use in the
   Internet.

4.1.1  Certificate Fields

   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 may also include 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.
   Section 7.2 lists the supported signature algorithms.

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



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


   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. Section 7.2
   lists the supported algorithms for this specification.

   This field MUST contain the same algorithm identifier as the
   signature field in the sequence tbsCertificate (see sec. 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
   signature value is then ASN.1 encoded as a BIT STRING and included in
   the Certificate's signature field. The details of this process are
   specified for each of the supported algorithms in Section 7.2.

   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 may also include
   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, use X.509 version 3
   (value is 2).  If no extensions are present, but a UniqueIdentifier
   is present, use version 2 (value is 1).  If only basic fields are
   present, use version 1 (the value is omitted from the certificate as
   the default value).




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


   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 is an 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).

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 (see sec.
   4.1.1.2).  The contents of the optional parameters field will vary
   according to the algorithm identified.  Section 7.2 lists the
   supported signature algorithms.

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 2459        Internet X.509 Public Key Infrastructure    January 1999


   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 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 2459        Internet X.509 Public Key Infrastructure    January 1999


   In addition, many legacy implementations support names encoded in the
   ISO 8859-1 character set (Latin1String) but tag them as
   TeletexString.  The Latin1String includes characters used in Western
   European countries which are not part of the TeletexString charcter
   set.  Implementations that process TeletexString SHOULD be prepared
   to handle the entire ISO 8859-1 character set.[ISO 8859-1]

   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 also 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
   names: country, organization, organizational-unit, distinguished name
   qualifier, state or province name,  and common name (e.g., "Susan
   Housley").  In addition, implementations of this specification SHOULD
   be prepared to receive the following standard attribute types in
   issuer names: locality, title,  surname, given name, initials, 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 Appendices A and B.

   In addition, implementations of this specification MUST be prepared
   to receive the domainComponent attribute, as defined in [RFC 2247].
   The Domain (Nameserver) System (DNS) provides a hierarchical resource
   labeling system.  This attribute provides is 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
   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 Appendices A and
   B.

   Certificate users MUST be prepared to process the issuer
   distinguished name and subject distinguished name (see sec. 4.1.2.6)
   fields to perform name chaining for certification path validation
   (see 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.  The
   requirements for conforming implementations are as follows:




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


      (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 the profile
   are permitted to use the comparison algorithm defined in the X.500