7.  Processing Rules for Internationalized Names

   Internationalized names may be encountered in numerous certificate
   and CRL fields and extensions, including distinguished names,
   internationalized domain names, electronic mail addresses, and
   Internationalized Resource Identifiers (IRIs).  Storage, comparison,
   and presentation of such names require special care.  Some characters
   may be encoded in multiple ways.  The same names could be represented
   in multiple encodings (e.g., ASCII or UTF8).  This section
   establishes conformance requirements for storage or comparison of
   each of these name forms.  Informative guidance on presentation is
   provided for some of these name forms.

7.1.  Internationalized Names in Distinguished Names

   Representation of internationalized names in distinguished names is
   covered in Sections 4.1.2.4, Issuer Name, and 4.1.2.6, Subject Name.
   Standard naming attributes, such as common name, employ the
   DirectoryString type, which supports internationalized names through
   a variety of language encodings.  Conforming implementations MUST
   support UTF8String and PrintableString.  RFC 3280 required only
   binary comparison of attribute values encoded in UTF8String, however,
   this specification requires a more comprehensive handling of
   comparison.  Implementations may encounter certificates and CRLs with
   names encoded using TeletexString, BMPString, or UniversalString, but
   support for these is OPTIONAL.

   Conforming implementations MUST use the LDAP StringPrep profile
   (including insignificant space handling), as specified in [RFC4518],
   as the basis for comparison of distinguished name attributes encoded
   in either PrintableString or UTF8String.  Conforming implementations
   MUST support name comparisons using caseIgnoreMatch.  Support for
   attribute types that use other equality matching rules is optional.

   Before comparing names using the caseIgnoreMatch matching rule,
   conforming implementations MUST perform the six-step string
   preparation algorithm described in [RFC4518] for each attribute of
   type DirectoryString, with the following clarifications:

      *  In step 2, Map, the mapping shall include case folding as
         specified in Appendix B.2 of [RFC3454].

      *  In step 6, Insignificant Character Removal, perform white space
         compression as specified in Section 2.6.1, Insignificant Space
         Handling, of [RFC4518].

   When performing the string preparation algorithm, attributes MUST be
   treated as stored values.

   Comparisons of domainComponent attributes MUST be performed as
   specified in Section 7.3.

   Two naming attributes match if the attribute types are the same and
   the values of the attributes are an exact match after processing with
   the string preparation algorithm.  Two relative distinguished names
   RDN1 and RDN2 match if they have the same number of naming attributes
   and for each naming attribute in RDN1 there is a matching naming
   attribute in RDN2.  Two distinguished names DN1 and DN2 match if they
   have the same number of RDNs, for each RDN in DN1 there is a matching
   RDN in DN2, and the matching RDNs appear in the same order in both
   DNs.  A distinguished name DN1 is within the subtree defined by the

   distinguished name DN2 if DN1 contains at least as many RDNs as DN2,
   and DN1 and DN2 are a match when trailing RDNs in DN1 are ignored.

7.2.  Internationalized Domain Names in GeneralName

   Internationalized Domain Names (IDNs) may be included in certificates
   and CRLs in the subjectAltName and issuerAltName extensions, name
   constraints extension, authority information access extension,
   subject information access extension, CRL distribution points
   extension, and issuing distribution point extension.  Each of these
   extensions uses the GeneralName type; one choice in GeneralName is
   the dNSName field, which is defined as type IA5String.

   IA5String is limited to the set of ASCII characters.  To accommodate
   internationalized domain names in the current structure, conforming
   implementations MUST convert internationalized domain names to the
   ASCII Compatible Encoding (ACE) format as specified in Section 4 of
   RFC 3490 before storage in the dNSName field.  Specifically,
   conforming implementations MUST perform the conversion operation
   specified in Section 4 of RFC 3490, with the following
   clarifications:

      *  in step 1, the domain name SHALL be considered a "stored
         string".  That is, the AllowUnassigned flag SHALL NOT be set;

      *  in step 3, set the flag called "UseSTD3ASCIIRules";

      *  in step 4, process each label with the "ToASCII" operation; and

      *  in step 5, change all label separators to U+002E (full stop).

   When comparing DNS names for equality, conforming implementations
   MUST perform a case-insensitive exact match on the entire DNS name.
   When evaluating name constraints, conforming implementations MUST
   perform a case-insensitive exact match on a label-by-label basis.  As
   noted in Section 4.2.1.10, any DNS name that may be constructed by
   adding labels to the left-hand side of the domain name given as the
   constraint is considered to fall within the indicated subtree.

   Implementations should convert IDNs to Unicode before display.
   Specifically, conforming implementations should perform the
   conversion operation specified in Section 4 of RFC 3490, with the
   following clarifications:

      *  in step 1, the domain name SHALL be considered a "stored
         string".  That is, the AllowUnassigned flag SHALL NOT be set;

      *  in step 3, set the flag called "UseSTD3ASCIIRules";

      *  in step 4, process each label with the "ToUnicode" operation;
         and

      *  skip step 5.

   Note:  Implementations MUST allow for increased space requirements
   for IDNs.  An IDN ACE label will begin with the four additional
   characters "xn--" and may require as many as five ASCII characters to
   specify a single international character.

7.3.  Internationalized Domain Names in Distinguished Names

   Domain Names may also be represented as distinguished names using
   domain components in the subject field, the issuer field, the
   subjectAltName extension, or the issuerAltName extension.  As with
   the dNSName in the GeneralName type, the value of this attribute is
   defined as an IA5String.  Each domainComponent attribute represents a
   single label.  To represent a label from an IDN in the distinguished
   name, the implementation MUST perform the "ToASCII" label conversion
   specified in Section 4.1 of RFC 3490.  The label SHALL be considered
   a "stored string".  That is, the AllowUnassigned flag SHALL NOT be
   set.

   Conforming implementations shall perform a case-insensitive exact
   match when comparing domainComponent attributes in distinguished
   names, as described in Section 7.2.

   Implementations should convert ACE labels to Unicode before display.
   Specifically, conforming implementations should perform the
   "ToUnicode" conversion operation specified, as described in Section
   7.2, on each ACE label before displaying the name.

7.4.  Internationalized Resource Identifiers

   Internationalized Resource Identifiers (IRIs) are the
   internationalized complement to the Uniform Resource Identifier
   (URI).  IRIs are sequences of characters from Unicode, while URIs are
   sequences of characters from the ASCII character set.  [RFC3987]
   defines a mapping from IRIs to URIs.  While IRIs are not encoded
   directly in any certificate fields or extensions, their mapped URIs
   may be included in certificates and CRLs.  URIs may appear in the
   subjectAltName and issuerAltName extensions, name constraints
   extension, authority information access extension, subject
   information access extension, issuing distribution point extension,
   and CRL distribution points extension.  Each of these extensions uses
   the GeneralName type; URIs are encoded in the
   uniformResourceIdentifier field in GeneralName, which is defined as
   type IA5String.

   To accommodate IRIs in the current structure, conforming
   implementations MUST map IRIs to URIs as specified in Section 3.1 of
   [RFC3987], with the following clarifications:

      *  in step 1, generate a UCS character sequence from the original
         IRI format normalizing according to the NFC as specified in
         Variant b (normalization according to NFC);

      *  perform step 2 using the output from step 1.

   Implementations MUST NOT convert the ireg-name component before
   performing step 2.

   Before URIs may be compared, conforming implementations MUST perform
   a combination of the syntax-based and scheme-based normalization
   techniques described in [RFC3987].  Specifically, conforming
   implementations MUST prepare URIs for comparison as follows:

      *  Step 1: Where IRIs allow the usage of IDNs, those names MUST be
         converted to ASCII Compatible Encoding as specified in Section
         7.2 above.

      *  Step 2: The scheme and host are normalized to lowercase, as
         described in Section 5.3.2.1 of [RFC3987].

      *  Step 3: Perform percent-encoding normalization, as specified in
         Section 5.3.2.3 of [RFC3987].

      *  Step 4: Perform path segment normalization, as specified in
         Section 5.3.2.4 of [RFC3987].

      *  Step 5: If recognized, the implementation MUST perform scheme-
         based normalization as specified in Section 5.3.3 of [RFC3987].

   Conforming implementations MUST recognize and perform scheme-based
   normalization for the following schemes: ldap, http, https, and ftp.
   If the scheme is not recognized, step 5 is omitted.

   When comparing URIs for equivalence, conforming implementations shall
   perform a case-sensitive exact match.

   Implementations should convert URIs to Unicode before display.
   Specifically, conforming implementations should perform the
   conversion operation specified in Section 3.2 of [RFC3987].

7.5.  Internationalized Electronic Mail Addresses

   Electronic Mail addresses may be included in certificates and CRLs in
   the subjectAltName and issuerAltName extensions, name constraints
   extension, authority information access extension, subject
   information access extension, issuing distribution point extension,
   or CRL distribution points extension.  Each of these extensions uses
   the GeneralName construct; GeneralName includes the rfc822Name
   choice, which is defined as type IA5String.  To accommodate email
   addresses with internationalized domain names using the current
   structure, conforming implementations MUST convert the addresses into
   an ASCII representation.

   Where the host-part (the Domain of the Mailbox) contains an
   internationalized name, the domain name MUST be converted from an IDN
   to the ASCII Compatible Encoding (ACE) format as specified in Section
   7.2.

   Two email addresses are considered to match if:

      1)  the local-part of each name is an exact match, AND

      2)  the host-part of each name matches using a case-insensitive
          ASCII comparison.

   Implementations should convert the host-part of internationalized
   email addresses specified in these extensions to Unicode before
   display.  Specifically, conforming implementations should perform the
   conversion of the host-part of the Mailbox as described in Section
   7.2.

8.  Security Considerations

   The majority of this specification is devoted to the format and
   content of certificates and CRLs.  Since certificates and CRLs are
   digitally signed, no additional integrity service is necessary.
   Neither certificates nor CRLs need be kept secret, and unrestricted
   and anonymous access to certificates and CRLs has no security
   implications.

   However, security factors outside the scope of this specification
   will affect the assurance provided to certificate users.  This
   section highlights critical issues to be considered by implementers,
   administrators, and users.

   The procedures performed by CAs and RAs to validate the binding of
   the subject's identity to their public key greatly affect the
   assurance that ought to be placed in the certificate.  Relying

   parties might wish to review the CA's certification practice
   statement.  This is particularly important when issuing certificates
   to other CAs.

   The use of a single key pair for both signature and other purposes is
   strongly discouraged.  Use of separate key pairs for signature and
   key management provides several benefits to the users.  The
   ramifications associated with loss or disclosure of a signature key
   are different from loss or disclosure of a key management key.  Using
   separate key pairs permits a balanced and flexible response.
   Similarly, different validity periods or key lengths for each key
   pair may be appropriate in some application environments.
   Unfortunately, some legacy applications (e.g., Secure Sockets Layer
   (SSL)) use a single key pair for signature and key management.

   The protection afforded private keys is a critical security factor.
   On a small scale, failure of users to protect their private keys will
   permit an attacker to masquerade as them or decrypt their personal
   information.  On a larger scale, compromise of a CA's private signing
   key may have a catastrophic effect.  If an attacker obtains the
   private key unnoticed, the attacker may issue bogus certificates and
   CRLs.  Existence of bogus certificates and CRLs will undermine
   confidence in the system.  If such a compromise is detected, all
   certificates issued to the compromised CA MUST be revoked, preventing
   services between its users and users of other CAs.  Rebuilding after
   such a compromise will be problematic, so CAs are advised to
   implement a combination of strong technical measures (e.g., tamper-
   resistant cryptographic modules) and appropriate management
   procedures (e.g., separation of duties) to avoid such an incident.

   Loss of a CA's private signing key may also be problematic.  The CA
   would not be able to produce CRLs or perform normal key rollover.
   CAs SHOULD maintain secure backup for signing keys.  The security of
   the key backup procedures is a critical factor in avoiding key
   compromise.

   The availability and freshness of revocation information affects the
   degree of assurance that ought to be placed in a certificate.  While
   certificates expire naturally, events may occur during its natural
   lifetime that negate the binding between the subject and public key.
   If revocation information is untimely or unavailable, the assurance
   associated with the binding is clearly reduced.  Relying parties
   might not be able to process every critical extension that can appear
   in a CRL.  CAs SHOULD take extra care when making revocation
   information available only through CRLs that contain critical
   extensions, particularly if support for those extensions is not
   mandated by this profile.  For example, if revocation information is
   supplied using a combination of delta CRLs and full CRLs, and the

   delta CRLs are issued more frequently than the full CRLs, then
   relying parties that cannot handle the critical extensions related to
   delta CRL processing will not be able to obtain the most recent
   revocation information.  Alternatively, if a full CRL is issued
   whenever a delta CRL is issued, then timely revocation information
   will be available to all relying parties.  Similarly, implementations
   of the certification path validation mechanism described in Section 6
   that omit revocation checking provide less assurance than those that
   support it.

   The certification path validation algorithm depends on the certain
   knowledge of the public keys (and other information) about one or
   more trusted CAs.  The decision to trust a CA is an important
   decision as it ultimately determines the trust afforded a
   certificate.  The authenticated distribution of trusted CA public
   keys (usually in the form of a "self-signed" certificate) is a
   security critical out-of-band process that is beyond the scope of
   this specification.

   In addition, where a key compromise or CA failure occurs for a
   trusted CA, the user will need to modify the information provided to
   the path validation routine.  Selection of too many trusted CAs makes
   the trusted CA information difficult to maintain.  On the other hand,
   selection of only one trusted CA could limit users to a closed
   community of users.

   The quality of implementations that process certificates also affects
   the degree of assurance provided.  The path validation algorithm
   described in Section 6 relies upon the integrity of the trusted CA
   information, and especially the integrity of the public keys
   associated with the trusted CAs.  By substituting public keys for
   which an attacker has the private key, an attacker could trick the
   user into accepting false certificates.

   The binding between a key and certificate subject cannot be stronger
   than the cryptographic module implementation and algorithms used to
   generate the signature.  Short key lengths or weak hash algorithms
   will limit the utility of a certificate.  CAs are encouraged to note
   advances in cryptology so they can employ strong cryptographic
   techniques.  In addition, CAs SHOULD decline to issue certificates to
   CAs or end entities that generate weak signatures.

   Inconsistent application of name comparison rules can result in
   acceptance of invalid X.509 certification paths or rejection of valid
   ones.  The X.500 series of specifications defines rules for comparing
   distinguished names that require comparison of strings without regard

   to case, character set, multi-character white space substring, or
   leading and trailing white space.  This specification relaxes these
   requirements, requiring support for binary comparison at a minimum.

   CAs MUST encode the distinguished name in the subject field of a CA
   certificate identically to the distinguished name in the issuer field
   in certificates issued by that CA.  If CAs use different encodings,
   implementations might fail to recognize name chains for paths that
   include this certificate.  As a consequence, valid paths could be
   rejected.

   In addition, name constraints for distinguished names MUST be stated
   identically to the encoding used in the subject field or
   subjectAltName extension.  If not, then name constraints stated as
   excludedSubtrees will not match and invalid paths will be accepted
   and name constraints expressed as permittedSubtrees will not match
   and valid paths will be rejected.  To avoid acceptance of invalid
   paths, CAs SHOULD state name constraints for distinguished names as
   permittedSubtrees wherever possible.

   In general, using the nameConstraints extension to constrain one name
   form (e.g., DNS names) offers no protection against use of other name
   forms (e.g., electronic mail addresses).

   While X.509 mandates that names be unambiguous, there is a risk that
   two unrelated authorities will issue certificates and/or CRLs under
   the same issuer name.  As a means of reducing problems and security
   issues related to issuer name collisions, CA and CRL issuer names
   SHOULD be formed in a way that reduces the likelihood of name
   collisions.  Implementers should take into account the possible
   existence of multiple unrelated CAs and CRL issuers with the same
   name.  At a minimum, implementations validating CRLs MUST ensure that
   the certification path of a certificate and the CRL issuer
   certification path used to validate the certificate terminate at the
   same trust anchor.

   While the local-part of an electronic mail address is case sensitive
   [RFC2821], emailAddress attribute values are not case sensitive
   [RFC2985].  As a result, there is a risk that two different email
   addresses will be treated as the same address when the matching rule
   for the emailAddress attribute is used, if the email server exploits
   the case sensitivity of mailbox local-parts.  Implementers should not
   include an email address in the emailAddress attribute if the email
   server that hosts the email address treats the local-part of email
   addresses as case sensitive.

   Implementers should be aware of risks involved if the CRL
   distribution points or authority information access extensions of

   corrupted certificates or CRLs contain links to malicious code.
   Implementers should always take the steps of validating the retrieved
   data to ensure that the data is properly formed.

   When certificates include a cRLDistributionPoints extension with an
   https URI or similar scheme, circular dependencies can be introduced.
   The relying party is forced to perform an additional path validation
   in order to obtain the CRL required to complete the initial path
   validation!  Circular conditions can also be created with an https
   URI (or similar scheme) in the authorityInfoAccess or
   subjectInfoAccess extensions.  At worst, this situation can create
   unresolvable dependencies.

   CAs SHOULD NOT include URIs that specify https, ldaps, or similar
   schemes in extensions.  CAs that include an https URI in one of these
   extensions MUST ensure that the server's certificate can be validated
   without using the information that is pointed to by the URI.  Relying
   parties that choose to validate the server's certificate when
   obtaining information pointed to by an https URI in the
   cRLDistributionPoints, authorityInfoAccess, or subjectInfoAccess
   extensions MUST be prepared for the possibility that this will result
   in unbounded recursion.

   Self-issued certificates provide CAs with one automated mechanism to
   indicate changes in the CA's operations.  In particular, self-issued
   certificates may be used to implement a graceful change-over from one
   non-compromised CA key pair to the next.  Detailed procedures for "CA
   key update" are specified in [RFC4210], where the CA protects its new
   public key using its previous private key and vice versa using two
   self-issued certificates.  Conforming client implementations will
   process the self-issued certificate and determine whether
   certificates issued under the new key may be trusted.  Self-issued
   certificates MAY be used to support other changes in CA operations,
   such as additions to the CA's policy set, using similar procedures.

   Some legacy implementations support names encoded in the ISO 8859-1
   character set (Latin1String) [ISO8859] but tag them as TeletexString.
   TeletexString encodes a larger character set than ISO 8859-1, but it
   encodes some characters differently.  The name comparison rules
   specified in Section 7.1 assume that TeletexStrings are encoded as
   described in the ASN.1 standard.  When comparing names encoded using
   the Latin1String character set, false positives and negatives are
   possible.

   When strings are mapped from internal representations to visual
   representations, sometimes two different strings will have the same
   or similar visual representations.  This can happen for many
   different reasons, including use of similar glyphs and use of

   composed characters (such as e + ' equaling U+00E9, the Korean
   composed characters, and vowels above consonant clusters in certain
   languages).  As a result of this situation, people doing visual
   comparisons between two different names may think they are the same
   when in fact they are not.  Also, people may mistake one string for
   another.  Issuers of certificates and relying parties both need to be
   aware of this situation.

9.  IANA Considerations

   Extensions in certificates and CRLs are identified using object
   identifiers.  The objects are defined in an arc delegated by IANA to
   the PKIX Working Group.  No further action by IANA is necessary for
   this document or any anticipated updates.

10.  Acknowledgments

   Warwick Ford participated with the authors in some of the design team
   meetings that directed development of this document.  The design
   team's efforts were guided by contributions from Matt Crawford, Tom
   Gindin, Steve Hanna, Stephen Henson, Paul Hoffman, Takashi Ito, Denis
   Pinkas, and Wen-Cheng Wang.

11.  References

11.1.  Normative References

   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981.

   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1123]  Braden, R., Ed., "Requirements for Internet Hosts --
              Application and Support", STD 3, RFC 1123, October 1989.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2585]  Housley, R. and P. Hoffman, "Internet X.509 Public Key
              Infrastructure: Operational Protocols: FTP and HTTP", RFC
              2585, May 1999.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2797]  Myers, M., Liu, X., Schaad, J., and J. Weinstein,
              "Certificate Management Messages over CMS", RFC 2797,
              April 2000.

   [RFC2821]  Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC
              2821, April 2001.

   [RFC3454]  Hoffman, P. and M. Blanchet, "Preparation of
              Internationalized Strings ("stringprep")", RFC 3454,
              December 2002.

   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)",
              RFC 3490, March 2003.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66, RFC
              3986, January 2005.

   [RFC3987]  Duerst, M. and M. Suignard, "Internationalized Resource
              Identifiers (IRIs)", RFC 3987, January 2005.

   [RFC4516]  Smith, M., Ed., and T. Howes, "Lightweight Directory
              Access Protocol (LDAP): Uniform Resource Locator", RFC
              4516, June 2006.

   [RFC4518]  Zeilenga, K., "Lightweight Directory Access Protocol
              (LDAP): Internationalized String Preparation", RFC 4518,
              June 2006.

   [RFC4523]  Zeilenga, K., "Lightweight Directory Access Protocol
              (LDAP) Schema Definitions for X.509 Certificates", RFC
              4523, June 2006.

   [RFC4632]  Fuller, V. and T. Li, "Classless Inter-domain Routing
              (CIDR): The Internet Address Assignment and Aggregation
              Plan", BCP 122, RFC 4632, August 2006.

   [X.680]    ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
              Information technology - Abstract Syntax Notation One
              (ASN.1):  Specification of basic notation.

   [X.690]    ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
              Information technology - ASN.1 encoding rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER).

11.2.  Informative References

   [ISO8859]  ISO/IEC 8859-1:1998.  Information technology -- 8-bit
              single-byte coded graphic character sets -- Part 1: Latin
              alphabet No. 1.

   [ISO10646] ISO/IEC 10646:2003.  Information technology -- Universal
              Multiple-Octet Coded Character Set (UCS).

   [NFC]      Davis, M. and M. Duerst, "Unicode Standard Annex #15:
              Unicode Normalization Forms", October 2006,
              <http://www.unicode.org/reports/tr15/>.

   [RFC1422]  Kent, S., "Privacy Enhancement for Internet Electronic
              Mail: Part II: Certificate-Based Key Management", RFC
              1422, February 1993.

   [RFC2277]  Alvestrand, H., "IETF Policy on Character Sets and
              Languages", BCP 18, RFC 2277, January 1998.

   [RFC2459]  Housley, R., Ford, W., Polk, W., and D. Solo, "Internet
              X.509 Public Key Infrastructure Certificate and CRL
              Profile", RFC 2459, January 1999.

   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
              Adams, "X.509 Internet Public Key Infrastructure Online
              Certificate Status Protocol - OCSP", RFC 2560, June 1999.

   [RFC2985]  Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
              Classes and Attribute Types Version 2.0", RFC 2985,
              November 2000.

   [RFC3161]  Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
              "Internet X.509 Public Key Infrastructure Time-Stamp
              Protocol (TSP)", RFC 3161, August 2001.

   [RFC3279]  Bassham, L., Polk, W., and R. Housley, "Algorithms and
              Identifiers for the Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 3279, April 2002.

   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
              X.509 Public Key Infrastructure Certificate and
              Certificate Revocation List (CRL) Profile", RFC 3280,
              April 2002.

   [RFC4055]  Schaad, J., Kaliski, B., and R. Housley, "Additional
              Algorithms and Identifiers for RSA Cryptography for use in
              the Internet X.509 Public Key Infrastructure Certificate
              and Certificate Revocation List (CRL) Profile", RFC 4055,
              June 2005.

   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
              Kerberos Network Authentication Service (V5)", RFC 4120,
              July 2005.

   [RFC4210]  Adams, C., Farrell, S., Kause, T., and T. Mononen,
              "Internet X.509 Public Key Infrastructure Certificate
              Management Protocol (CMP)", RFC 4210, September 2005.

   [RFC4325]  Santesson, S. and R. Housley, "Internet X.509 Public Key
              Infrastructure Authority Information Access Certificate
              Revocation List (CRL) Extension", RFC 4325, December 2005.

   [RFC4491]  Leontiev, S., Ed., and D. Shefanovski, Ed., "Using the
              GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
              Algorithms with the Internet X.509 Public Key
              Infrastructure Certificate and CRL Profile", RFC 4491, May
              2006.

   [RFC4510]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
              (LDAP): Technical Specification Road Map", RFC 4510, June
              2006.

   [RFC4512]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
              (LDAP): Directory Information Models", RFC 4512, June
              2006.

   [RFC4514]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
              (LDAP): String Representation of Distinguished Names", RFC
              4514, June 2006.

   [RFC4519]  Sciberras, A., Ed., "Lightweight Directory Access Protocol
              (LDAP): Schema for User Applications", RFC 4519, June
              2006.

   [RFC4630]  Housley, R. and S. Santesson, "Update to DirectoryString
              Processing in the Internet X.509 Public Key Infrastructure
              Certificate and Certificate Revocation List (CRL)
              Profile", RFC 4630, August 2006.

   [X.500]    ITU-T Recommendation X.500 (2005) | ISO/IEC 9594-1:2005,
              Information technology - Open Systems Interconnection -
              The Directory: Overview of concepts, models and services.

   [X.501]    ITU-T Recommendation X.501 (2005) | ISO/IEC 9594-2:2005,
              Information technology - Open Systems Interconnection -
              The Directory: Models.

   [X.509]    ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005,
              Information technology - Open Systems Interconnection -
              The Directory: Public-key and attribute certificate
              frameworks.

   [X.520]    ITU-T Recommendation X.520 (2005) | ISO/IEC 9594-6:2005,
              Information technology - Open Systems Interconnection -
              The Directory: Selected attribute types.

   [X.660]    ITU-T Recommendation X.660 (2004) | ISO/IEC 9834-1:2005,
              Information technology - Open Systems Interconnection -
              Procedures for the operation of OSI Registration
              Authorities: General procedures, and top arcs of the ASN.1
              Object Identifier tree.

   [X.683]    ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002,
              Information technology - Abstract Syntax Notation One
              (ASN.1): Parameterization of ASN.1 specifications.

   [X9.55]    ANSI X9.55-1997, Public Key Cryptography for the Financial
              Services Industry: Extensions to Public Key Certificates
              and Certificate Revocation Lists, January 1997.