Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5280

Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

Pages: 151
Proposed Standard
Errata
Obsoletes:  328043254630
Updated by:  6818839883999549
Part 5 of 7 – Pages 95 to 109
First   Prev   Next

Top   ToC   RFC5280 - Page 95   prevText

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.
Top   ToC   RFC5280 - Page 96

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
Top   ToC   RFC5280 - Page 97
   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";
Top   ToC   RFC5280 - Page 98
      *  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.
Top   ToC   RFC5280 - Page 99
   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].
Top   ToC   RFC5280 - Page 100

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
Top   ToC   RFC5280 - Page 101
   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
Top   ToC   RFC5280 - Page 102
   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
Top   ToC   RFC5280 - Page 103
   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
Top   ToC   RFC5280 - Page 104
   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
Top   ToC   RFC5280 - Page 105
   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.
Top   ToC   RFC5280 - Page 106
   [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.
Top   ToC   RFC5280 - Page 107
   [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.
Top   ToC   RFC5280 - Page 108
   [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.
Top   ToC   RFC5280 - Page 109
   [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.


(next page on part 6)

Next Section