value    AttributeValue }

   AttributeType ::= OBJECT IDENTIFIER

   AttributeValue ::= ANY DEFINED BY AttributeType





 
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.




 
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