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 AttributeTypeHousley, 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