| < draft-ietf-pkix-rfc3280bis-10.txt | draft-ietf-pkix-rfc3280bis-11.txt > | |||
|---|---|---|---|---|
| Network Working Group D. Cooper | Network Working Group D. Cooper | |||
| Internet-Draft NIST | Internet-Draft NIST | |||
| Obsoletes: 3280, 4325, 4630 (if approved) S. Santesson | Obsoletes: 3280, 4325, 4630 (if approved) S. Santesson | |||
| Expires: June 2008 Microsoft | Expires: August 2008 Microsoft | |||
| S. Farrell | S. Farrell | |||
| Trinity College Dublin | Trinity College Dublin | |||
| S. Boeyen | S. Boeyen | |||
| Entrust | Entrust | |||
| R. Housley | R. Housley | |||
| Vigil Security | Vigil Security | |||
| W. Polk | W. Polk | |||
| NIST | NIST | |||
| December 19, 2007 | February 4, 2008 | |||
| Internet X.509 Public Key Infrastructure | Internet X.509 Public Key Infrastructure | |||
| Certificate and Certificate Revocation List (CRL) Profile | Certificate and Certificate Revocation List (CRL) Profile | |||
| draft-ietf-pkix-rfc3280bis-10.txt | draft-ietf-pkix-rfc3280bis-11.txt | |||
| Status of this Memo | Status of this Memo | |||
| By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
| applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
| have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
| aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| skipping to change at page 1, line 46 ¶ | skipping to change at page 1, line 46 ¶ | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/1id-abstracts.html. | http://www.ietf.org/1id-abstracts.html. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (C) The IETF Trust (2007). | Copyright (C) The IETF Trust (2008). | |||
| Abstract | Abstract | |||
| This memo profiles the X.509 v3 certificate and X.509 v2 certificate | This memo profiles the X.509 v3 certificate and X.509 v2 certificate | |||
| revocation list (CRL) for use in the Internet. An overview of this | revocation list (CRL) for use in the Internet. An overview of this | |||
| approach and model are provided as an introduction. The X.509 v3 | approach and model are provided as an introduction. The X.509 v3 | |||
| certificate format is described in detail, with additional | certificate format is described in detail, with additional | |||
| information regarding the format and semantics of Internet name | information regarding the format and semantics of Internet name | |||
| forms. Standard certificate extensions are described and two | forms. Standard certificate extensions are described and two | |||
| Internet-specific extensions are defined. A set of required | Internet-specific extensions are defined. A set of required | |||
| skipping to change at page 2, line 34 ¶ | skipping to change at page 2, line 34 ¶ | |||
| 3 Overview of Approach . . . . . . . . . . . . . . . . . . 8 | 3 Overview of Approach . . . . . . . . . . . . . . . . . . 8 | |||
| 3.1 X.509 Version 3 Certificate . . . . . . . . . . . . . . 9 | 3.1 X.509 Version 3 Certificate . . . . . . . . . . . . . . 9 | |||
| 3.2 Certification Paths and Trust . . . . . . . . . . . . . 11 | 3.2 Certification Paths and Trust . . . . . . . . . . . . . 11 | |||
| 3.3 Revocation . . . . . . . . . . . . . . . . . . . . . . 13 | 3.3 Revocation . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 3.4 Operational Protocols . . . . . . . . . . . . . . . . . 14 | 3.4 Operational Protocols . . . . . . . . . . . . . . . . . 14 | |||
| 3.5 Management Protocols . . . . . . . . . . . . . . . . . 14 | 3.5 Management Protocols . . . . . . . . . . . . . . . . . 14 | |||
| 4 Certificate and Certificate Extensions Profile . . . . . 16 | 4 Certificate and Certificate Extensions Profile . . . . . 16 | |||
| 4.1 Basic Certificate Fields . . . . . . . . . . . . . . . 16 | 4.1 Basic Certificate Fields . . . . . . . . . . . . . . . 16 | |||
| 4.1.1 Certificate Fields . . . . . . . . . . . . . . . . . 17 | 4.1.1 Certificate Fields . . . . . . . . . . . . . . . . . 17 | |||
| 4.1.1.1 tbsCertificate . . . . . . . . . . . . . . . . . . 17 | 4.1.1.1 tbsCertificate . . . . . . . . . . . . . . . . . . 17 | |||
| 4.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . 17 | 4.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . 18 | |||
| 4.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . 18 | 4.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . 18 | |||
| 4.1.2 TBSCertificate . . . . . . . . . . . . . . . . . . . 18 | 4.1.2 TBSCertificate . . . . . . . . . . . . . . . . . . . 18 | |||
| 4.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . 18 | 4.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 4.1.2.2 Serial number . . . . . . . . . . . . . . . . . . . 19 | 4.1.2.2 Serial number . . . . . . . . . . . . . . . . . . . 19 | |||
| 4.1.2.3 Signature . . . . . . . . . . . . . . . . . . . . . 19 | 4.1.2.3 Signature . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 4.1.2.4 Issuer . . . . . . . . . . . . . . . . . . . . . . 19 | 4.1.2.4 Issuer . . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 4.1.2.5 Validity . . . . . . . . . . . . . . . . . . . . . 22 | 4.1.2.5 Validity . . . . . . . . . . . . . . . . . . . . . 22 | |||
| 4.1.2.5.1 UTCTime . . . . . . . . . . . . . . . . . . . . . 22 | 4.1.2.5.1 UTCTime . . . . . . . . . . . . . . . . . . . . . 23 | |||
| 4.1.2.5.2 GeneralizedTime . . . . . . . . . . . . . . . . . 23 | 4.1.2.5.2 GeneralizedTime . . . . . . . . . . . . . . . . . 23 | |||
| 4.1.2.6 Subject . . . . . . . . . . . . . . . . . . . . . . 23 | 4.1.2.6 Subject . . . . . . . . . . . . . . . . . . . . . . 23 | |||
| 4.1.2.7 Subject Public Key Info . . . . . . . . . . . . . . 25 | 4.1.2.7 Subject Public Key Info . . . . . . . . . . . . . . 25 | |||
| 4.1.2.8 Unique Identifiers . . . . . . . . . . . . . . . . 25 | 4.1.2.8 Unique Identifiers . . . . . . . . . . . . . . . . 25 | |||
| 4.1.2.9 Extensions . . . . . . . . . . . . . . . . . . . . 25 | 4.1.2.9 Extensions . . . . . . . . . . . . . . . . . . . . 25 | |||
| 4.2 Certificate Extensions . . . . . . . . . . . . . . . . 25 | 4.2 Certificate Extensions . . . . . . . . . . . . . . . . 26 | |||
| 4.2.1 Standard Extensions . . . . . . . . . . . . . . . . . 26 | 4.2.1 Standard Extensions . . . . . . . . . . . . . . . . . 27 | |||
| 4.2.1.1 Authority Key Identifier . . . . . . . . . . . . . 27 | 4.2.1.1 Authority Key Identifier . . . . . . . . . . . . . 27 | |||
| 4.2.1.2 Subject Key Identifier . . . . . . . . . . . . . . 28 | 4.2.1.2 Subject Key Identifier . . . . . . . . . . . . . . 28 | |||
| 4.2.1.3 Key Usage . . . . . . . . . . . . . . . . . . . . . 29 | 4.2.1.3 Key Usage . . . . . . . . . . . . . . . . . . . . . 29 | |||
| 4.2.1.4 Certificate Policies . . . . . . . . . . . . . . . 31 | 4.2.1.4 Certificate Policies . . . . . . . . . . . . . . . 31 | |||
| 4.2.1.5 Policy Mappings . . . . . . . . . . . . . . . . . . 34 | 4.2.1.5 Policy Mappings . . . . . . . . . . . . . . . . . . 34 | |||
| 4.2.1.6 Subject Alternative Name . . . . . . . . . . . . . 34 | 4.2.1.6 Subject Alternative Name . . . . . . . . . . . . . 35 | |||
| 4.2.1.7 Issuer Alternative Name . . . . . . . . . . . . . . 37 | 4.2.1.7 Issuer Alternative Name . . . . . . . . . . . . . . 38 | |||
| 4.2.1.8 Subject Directory Attributes . . . . . . . . . . . 38 | 4.2.1.8 Subject Directory Attributes . . . . . . . . . . . 38 | |||
| 4.2.1.9 Basic Constraints . . . . . . . . . . . . . . . . . 38 | 4.2.1.9 Basic Constraints . . . . . . . . . . . . . . . . . 38 | |||
| 4.2.1.10 Name Constraints . . . . . . . . . . . . . . . . . 39 | 4.2.1.10 Name Constraints . . . . . . . . . . . . . . . . . 39 | |||
| 4.2.1.11 Policy Constraints . . . . . . . . . . . . . . . . 42 | 4.2.1.11 Policy Constraints . . . . . . . . . . . . . . . . 42 | |||
| 4.2.1.12 Extended Key Usage . . . . . . . . . . . . . . . . 43 | 4.2.1.12 Extended Key Usage . . . . . . . . . . . . . . . . 43 | |||
| 4.2.1.13 CRL Distribution Points . . . . . . . . . . . . . 44 | 4.2.1.13 CRL Distribution Points . . . . . . . . . . . . . 45 | |||
| 4.2.1.14 Inhibit anyPolicy . . . . . . . . . . . . . . . . 47 | 4.2.1.14 Inhibit anyPolicy . . . . . . . . . . . . . . . . 47 | |||
| 4.2.1.15 Freshest CRL . . . . . . . . . . . . . . . . . . . 47 | 4.2.1.15 Freshest CRL . . . . . . . . . . . . . . . . . . . 47 | |||
| 4.2.2 Private Internet Extensions . . . . . . . . . . . . . 47 | 4.2.2 Private Internet Extensions . . . . . . . . . . . . . 48 | |||
| 4.2.2.1 Authority Information Access . . . . . . . . . . . 48 | 4.2.2.1 Authority Information Access . . . . . . . . . . . 48 | |||
| 4.2.2.2 Subject Information Access . . . . . . . . . . . . 50 | 4.2.2.2 Subject Information Access . . . . . . . . . . . . 51 | |||
| 5 CRL and CRL Extensions Profile . . . . . . . . . . . . . 52 | 5 CRL and CRL Extensions Profile . . . . . . . . . . . . . 53 | |||
| 5.1 CRL Fields . . . . . . . . . . . . . . . . . . . . . . 54 | 5.1 CRL Fields . . . . . . . . . . . . . . . . . . . . . . 54 | |||
| 5.1.1 CertificateList Fields . . . . . . . . . . . . . . . 55 | 5.1.1 CertificateList Fields . . . . . . . . . . . . . . . 55 | |||
| 5.1.1.1 tbsCertList . . . . . . . . . . . . . . . . . . . . 55 | 5.1.1.1 tbsCertList . . . . . . . . . . . . . . . . . . . . 55 | |||
| 5.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . 55 | 5.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . 56 | |||
| 5.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . 55 | 5.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . 56 | |||
| 5.1.2 Certificate List "To Be Signed" . . . . . . . . . . . 56 | 5.1.2 Certificate List "To Be Signed" . . . . . . . . . . . 56 | |||
| 5.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . 56 | 5.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . 57 | |||
| 5.1.2.2 Signature . . . . . . . . . . . . . . . . . . . . . 56 | 5.1.2.2 Signature . . . . . . . . . . . . . . . . . . . . . 57 | |||
| 5.1.2.3 Issuer Name . . . . . . . . . . . . . . . . . . . . 57 | 5.1.2.3 Issuer Name . . . . . . . . . . . . . . . . . . . . 57 | |||
| 5.1.2.4 This Update . . . . . . . . . . . . . . . . . . . . 57 | 5.1.2.4 This Update . . . . . . . . . . . . . . . . . . . . 57 | |||
| 5.1.2.5 Next Update . . . . . . . . . . . . . . . . . . . . 57 | 5.1.2.5 Next Update . . . . . . . . . . . . . . . . . . . . 58 | |||
| 5.1.2.6 Revoked Certificates . . . . . . . . . . . . . . . 58 | 5.1.2.6 Revoked Certificates . . . . . . . . . . . . . . . 58 | |||
| 5.1.2.7 Extensions . . . . . . . . . . . . . . . . . . . . 58 | 5.1.2.7 Extensions . . . . . . . . . . . . . . . . . . . . 58 | |||
| 5.2 CRL Extensions . . . . . . . . . . . . . . . . . . . . 58 | 5.2 CRL Extensions . . . . . . . . . . . . . . . . . . . . 59 | |||
| 5.2.1 Authority Key Identifier . . . . . . . . . . . . . . 58 | 5.2.1 Authority Key Identifier . . . . . . . . . . . . . . 59 | |||
| 5.2.2 Issuer Alternative Name . . . . . . . . . . . . . . . 59 | 5.2.2 Issuer Alternative Name . . . . . . . . . . . . . . . 59 | |||
| 5.2.3 CRL Number . . . . . . . . . . . . . . . . . . . . . 59 | 5.2.3 CRL Number . . . . . . . . . . . . . . . . . . . . . 60 | |||
| 5.2.4 Delta CRL Indicator . . . . . . . . . . . . . . . . . 60 | 5.2.4 Delta CRL Indicator . . . . . . . . . . . . . . . . . 60 | |||
| 5.2.5 Issuing Distribution Point . . . . . . . . . . . . . 63 | 5.2.5 Issuing Distribution Point . . . . . . . . . . . . . 63 | |||
| 5.2.6 Freshest CRL . . . . . . . . . . . . . . . . . . . . 65 | 5.2.6 Freshest CRL . . . . . . . . . . . . . . . . . . . . 65 | |||
| 5.2.7 Authority Information Access . . . . . . . . . . . . 65 | 5.2.7 Authority Information Access . . . . . . . . . . . . 66 | |||
| 5.3 CRL Entry Extensions . . . . . . . . . . . . . . . . . 66 | 5.3 CRL Entry Extensions . . . . . . . . . . . . . . . . . 67 | |||
| 5.3.1 Reason Code . . . . . . . . . . . . . . . . . . . . . 67 | 5.3.1 Reason Code . . . . . . . . . . . . . . . . . . . . . 68 | |||
| 5.3.2 Invalidity Date . . . . . . . . . . . . . . . . . . . 68 | 5.3.2 Invalidity Date . . . . . . . . . . . . . . . . . . . 68 | |||
| 5.3.3 Certificate Issuer . . . . . . . . . . . . . . . . . 68 | 5.3.3 Certificate Issuer . . . . . . . . . . . . . . . . . 69 | |||
| 6 Certification Path Validation . . . . . . . . . . . . . . 69 | 6 Certification Path Validation . . . . . . . . . . . . . . 69 | |||
| 6.1 Basic Path Validation . . . . . . . . . . . . . . . . . 69 | 6.1 Basic Path Validation . . . . . . . . . . . . . . . . . 70 | |||
| 6.1.1 Inputs . . . . . . . . . . . . . . . . . . . . . . . 72 | 6.1.1 Inputs . . . . . . . . . . . . . . . . . . . . . . . 73 | |||
| 6.1.2 Initialization . . . . . . . . . . . . . . . . . . . 74 | 6.1.2 Initialization . . . . . . . . . . . . . . . . . . . 75 | |||
| 6.1.3 Basic Certificate Processing . . . . . . . . . . . . 77 | 6.1.3 Basic Certificate Processing . . . . . . . . . . . . 77 | |||
| 6.1.4 Preparation for Certificate i+1 . . . . . . . . . . . 81 | 6.1.4 Preparation for Certificate i+1 . . . . . . . . . . . 82 | |||
| 6.1.5 Wrap-up procedure . . . . . . . . . . . . . . . . . . 84 | 6.1.5 Wrap-up procedure . . . . . . . . . . . . . . . . . . 85 | |||
| 6.1.6 Outputs . . . . . . . . . . . . . . . . . . . . . . . 86 | 6.1.6 Outputs . . . . . . . . . . . . . . . . . . . . . . . 87 | |||
| 6.2 Using the Path Validation Algorithm . . . . . . . . . . 86 | 6.2 Using the Path Validation Algorithm . . . . . . . . . . 87 | |||
| 6.3 CRL Validation . . . . . . . . . . . . . . . . . . . . 87 | 6.3 CRL Validation . . . . . . . . . . . . . . . . . . . . 88 | |||
| 6.3.1 Revocation Inputs . . . . . . . . . . . . . . . . . . 87 | 6.3.1 Revocation Inputs . . . . . . . . . . . . . . . . . . 88 | |||
| 6.3.2 Initialization and Revocation State Variables . . . . 87 | 6.3.2 Initialization and Revocation State Variables . . . . 88 | |||
| 6.3.3 CRL Processing . . . . . . . . . . . . . . . . . . . 88 | 6.3.3 CRL Processing . . . . . . . . . . . . . . . . . . . 89 | |||
| 7 Processing Rules for Internationalized Names . . . . . . 91 | 7 Processing Rules for Internationalized Names . . . . . . 92 | |||
| 7.1 Internationalized Names in Distinguished Names . . . . 92 | 7.1 Internationalized Names in Distinguished Names . . . . 93 | |||
| 7.2 Internationalized Domain Names in GeneralName . . . . . 93 | 7.2 Internationalized Domain Names in GeneralName . . . . . 94 | |||
| 7.3 Internationalized Domain Names in Distinguished Names . 94 | 7.3 Internationalized Domain Names in Distinguished Names . 95 | |||
| 7.4 Internationalized Resource Identifiers . . . . . . . . 94 | 7.4 Internationalized Resource Identifiers . . . . . . . . 95 | |||
| 7.5 Internationalized Electronic Mail Addresses . . . . . . 96 | 7.5 Internationalized Electronic Mail Addresses . . . . . . 97 | |||
| 8 References . . . . . . . . . . . . . . . . . . . . . . . 96 | 8 References . . . . . . . . . . . . . . . . . . . . . . . 97 | |||
| 9 Intellectual Property Rights . . . . . . . . . . . . . . 101 | 9 Intellectual Property Rights . . . . . . . . . . . . . . 102 | |||
| 10 Security Considerations . . . . . . . . . . . . . . . . 101 | 10 Security Considerations . . . . . . . . . . . . . . . . 102 | |||
| 11 IANA Considerations . . . . . . . . . . . . . . . . . . 106 | 11 IANA Considerations . . . . . . . . . . . . . . . . . . 107 | |||
| 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . 106 | 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . 107 | |||
| 13 Acknowledgments . . . . . . . . . . . . . . . . . . . . 107 | 13 Acknowledgments . . . . . . . . . . . . . . . . . . . . 108 | |||
| Appendix A. Pseudo-ASN.1 Structures and OIDs . . . . . . . 107 | Appendix A. Pseudo-ASN.1 Structures and OIDs . . . . . . . 108 | |||
| A.1 Explicitly Tagged Module, 1988 Syntax . . . . . . . . . 107 | A.1 Explicitly Tagged Module, 1988 Syntax . . . . . . . . . 108 | |||
| A.2 Implicitly Tagged Module, 1988 Syntax . . . . . . . . . 121 | A.2 Implicitly Tagged Module, 1988 Syntax . . . . . . . . . 122 | |||
| Appendix B. ASN.1 Notes . . . . . . . . . . . . . . . . . . 128 | Appendix B. ASN.1 Notes . . . . . . . . . . . . . . . . . . 129 | |||
| Appendix C. Examples . . . . . . . . . . . . . . . . . . . 131 | Appendix C. Examples . . . . . . . . . . . . . . . . . . . 132 | |||
| C.1 RSA Self-Signed Certificate . . . . . . . . . . . . . . 132 | C.1 RSA Self-Signed Certificate . . . . . . . . . . . . . . 133 | |||
| C.2 End Entity Certificate Using RSA . . . . . . . . . . . 135 | C.2 End Entity Certificate Using RSA . . . . . . . . . . . 136 | |||
| C.3 End Entity Certificate Using DSA . . . . . . . . . . . 138 | C.3 End Entity Certificate Using DSA . . . . . . . . . . . 139 | |||
| C.4 Certificate Revocation List . . . . . . . . . . . . . . 142 | C.4 Certificate Revocation List . . . . . . . . . . . . . . 143 | |||
| Full Copyright Statement . . . . . . . . . . . . . . . . . . 144 | Full Copyright Statement . . . . . . . . . . . . . . . . . . 145 | |||
| 1 Introduction | 1 Introduction | |||
| This specification is one part of a family of standards for the X.509 | This specification is one part of a family of standards for the X.509 | |||
| Public Key Infrastructure (PKI) for the Internet. | Public Key Infrastructure (PKI) for the Internet. | |||
| This specification profiles the format and semantics of certificates | This specification profiles the format and semantics of certificates | |||
| and certificate revocation lists (CRLs) for the Internet PKI. | and certificate revocation lists (CRLs) for the Internet PKI. | |||
| Procedures are described for processing of certification paths in the | Procedures are described for processing of certification paths in the | |||
| Internet environment. Finally, ASN.1 modules are provided in the | Internet environment. Finally, ASN.1 modules are provided in the | |||
| skipping to change at page 17, line 32 ¶ | skipping to change at page 17, line 32 ¶ | |||
| SubjectPublicKeyInfo ::= SEQUENCE { | SubjectPublicKeyInfo ::= SEQUENCE { | |||
| algorithm AlgorithmIdentifier, | algorithm AlgorithmIdentifier, | |||
| subjectPublicKey BIT STRING } | subjectPublicKey BIT STRING } | |||
| Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension | Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension | |||
| Extension ::= SEQUENCE { | Extension ::= SEQUENCE { | |||
| extnID OBJECT IDENTIFIER, | extnID OBJECT IDENTIFIER, | |||
| critical BOOLEAN DEFAULT FALSE, | critical BOOLEAN DEFAULT FALSE, | |||
| extnValue OCTET STRING } | extnValue OCTET STRING | |||
| -- contains the DER encoding of an ASN.1 value | ||||
| -- corresponding to the extension type identified | ||||
| -- by extnID | ||||
| } | ||||
| The following items describe the X.509 v3 certificate for use in the | The following items describe the X.509 v3 certificate for use in the | |||
| Internet. | Internet. | |||
| 4.1.1 Certificate Fields | 4.1.1 Certificate Fields | |||
| The Certificate is a SEQUENCE of three required fields. The fields | The Certificate is a SEQUENCE of three required fields. The fields | |||
| are described in detail in the following subsections. | are described in detail in the following subsections. | |||
| 4.1.1.1 tbsCertificate | 4.1.1.1 tbsCertificate | |||
| skipping to change at page 24, line 48 ¶ | skipping to change at page 25, line 7 ¶ | |||
| (c) TeletexString, BMPString, and UniversalString are included | (c) TeletexString, BMPString, and UniversalString are included | |||
| for backward compatibility, and SHOULD NOT be used for | for backward compatibility, and SHOULD NOT be used for | |||
| certificates for new subjects. However, these types MAY be used | certificates for new subjects. However, these types MAY be used | |||
| in certificates where the name was previously established, | in certificates where the name was previously established, | |||
| including cases in which a new certificate is being issued to an | including cases in which a new certificate is being issued to an | |||
| existing subject or a certificate is being issued to a new subject | existing subject or a certificate is being issued to a new subject | |||
| where the attributes being encoded have been previously | where the attributes being encoded have been previously | |||
| established in certificates issued to other subjects. Certificate | established in certificates issued to other subjects. Certificate | |||
| users SHOULD be prepared to receive certificates with these types. | users SHOULD be prepared to receive certificates with these types. | |||
| Legacy implementations exist where an RFC 822 name is embedded in the | Legacy implementations exist where an electronic mail address is | |||
| subject distinguished name as an emailAddress attribute [RFC 2985]. | embedded in the subject distinguished name as an emailAddress | |||
| The attribute value for emailAddress is of type IA5String to permit | attribute [RFC 2985]. The attribute value for emailAddress is of | |||
| inclusion of the character '@', which is not part of the | type IA5String to permit inclusion of the character '@', which is not | |||
| PrintableString character set. emailAddress attribute values are not | part of the PrintableString character set. emailAddress attribute | |||
| case-sensitive (e.g., "subscriber@example.com" is the same as | values are not case-sensitive (e.g., "subscriber@example.com" is the | |||
| "SUBSCRIBER@EXAMPLE.COM"). | same as "SUBSCRIBER@EXAMPLE.COM"). | |||
| Conforming implementations generating new certificates with | Conforming implementations generating new certificates with | |||
| electronic mail addresses MUST use the rfc822Name in the subject | electronic mail addresses MUST use the rfc822Name in the subject | |||
| alternative name extension (section 4.2.1.6) to describe such | alternative name extension (section 4.2.1.6) to describe such | |||
| identities. Simultaneous inclusion of the emailAddress attribute in | identities. Simultaneous inclusion of the emailAddress attribute in | |||
| the subject distinguished name to support legacy implementations is | the subject distinguished name to support legacy implementations is | |||
| deprecated but permitted. | deprecated but permitted. | |||
| 4.1.2.7 Subject Public Key Info | 4.1.2.7 Subject Public Key Info | |||
| skipping to change at page 26, line 18 ¶ | skipping to change at page 26, line 26 ¶ | |||
| extension MAY be ignored if it is not recognized, but MUST be | extension MAY be ignored if it is not recognized, but MUST be | |||
| processed if it is recognized. The following sections present | processed if it is recognized. The following sections present | |||
| recommended extensions used within Internet certificates and standard | recommended extensions used within Internet certificates and standard | |||
| locations for information. Communities may elect to use additional | locations for information. Communities may elect to use additional | |||
| extensions; however, caution ought to be exercised in adopting any | extensions; however, caution ought to be exercised in adopting any | |||
| critical extensions in certificates that might prevent use in a | critical extensions in certificates that might prevent use in a | |||
| general context. | general context. | |||
| Each extension includes an OID and an ASN.1 structure. When an | Each extension includes an OID and an ASN.1 structure. When an | |||
| extension appears in a certificate, the OID appears as the field | extension appears in a certificate, the OID appears as the field | |||
| extnID and the corresponding ASN.1 encoded structure is the value of | extnID and the corresponding ASN.1 DER encoded structure is the value | |||
| the octet string extnValue. A certificate MUST NOT include more than | of the octet string extnValue. A certificate MUST NOT include more | |||
| one instance of a particular extension. For example, a certificate | than one instance of a particular extension. For example, a | |||
| may contain only one authority key identifier extension (section | certificate may contain only one authority key identifier extension | |||
| 4.2.1.1). An extension includes the boolean critical, with a default | (section 4.2.1.1). An extension includes the boolean critical, with | |||
| value of FALSE. The text for each extension specifies the acceptable | a default value of FALSE. The text for each extension specifies the | |||
| values for the critical field for CAs conforming to this profile. | acceptable values for the critical field for CAs conforming to this | |||
| profile. | ||||
| Conforming CAs MUST support key identifiers (sections 4.2.1.1 and | Conforming CAs MUST support key identifiers (sections 4.2.1.1 and | |||
| 4.2.1.2), basic constraints (section 4.2.1.9), key usage (section | 4.2.1.2), basic constraints (section 4.2.1.9), key usage (section | |||
| 4.2.1.3), and certificate policies (section 4.2.1.4) extensions. If | 4.2.1.3), and certificate policies (section 4.2.1.4) extensions. If | |||
| the CA issues certificates with an empty sequence for the subject | the CA issues certificates with an empty sequence for the subject | |||
| field, the CA MUST support the subject alternative name extension | field, the CA MUST support the subject alternative name extension | |||
| (section 4.2.1.6). Support for the remaining extensions is OPTIONAL. | (section 4.2.1.6). Support for the remaining extensions is OPTIONAL. | |||
| Conforming CAs MAY support extensions that are not identified within | Conforming CAs MAY support extensions that are not identified within | |||
| this specification; certificate issuers are cautioned that marking | this specification; certificate issuers are cautioned that marking | |||
| such extensions as critical may inhibit interoperability. | such extensions as critical may inhibit interoperability. | |||
| skipping to change at page 32, line 43 ¶ | skipping to change at page 33, line 4 ¶ | |||
| implementation, the application software will have a notice file | implementation, the application software will have a notice file | |||
| containing the current set of notices for CertsRUs; the | containing the current set of notices for CertsRUs; the | |||
| application will extract the notice text from the file and display | application will extract the notice text from the file and display | |||
| it. Messages MAY be multilingual, allowing the software to select | it. Messages MAY be multilingual, allowing the software to select | |||
| the particular language message for its own environment. | the particular language message for its own environment. | |||
| An explicitText field includes the textual statement directly in | An explicitText field includes the textual statement directly in | |||
| the certificate. The explicitText field is a string with a | the certificate. The explicitText field is a string with a | |||
| maximum size of 200 characters. Conforming CAs SHOULD use the | maximum size of 200 characters. Conforming CAs SHOULD use the | |||
| UTF8String encoding for explicitText, but MAY use IA5String. | UTF8String encoding for explicitText, but MAY use IA5String. | |||
| Conforming CAs MUST NOT encode explicitText as VisibleString or | Conforming CAs MUST NOT encode explicitText as VisibleString or | |||
| BMPString. | BMPString. The explicitText string SHOULD NOT include any control | |||
| characters (e.g., U+0000 to U+001F and U+007F to U+009F). When | ||||
| the UTF8String encoding is used, all character sequences SHOULD be | ||||
| normalized according to Unicode normalization form C (NFC) [NFC]. | ||||
| If both the noticeRef and explicitText options are included in the | If both the noticeRef and explicitText options are included in the | |||
| one qualifier and if the application software can locate the notice | one qualifier and if the application software can locate the notice | |||
| text indicated by the noticeRef option, then that text SHOULD be | text indicated by the noticeRef option, then that text SHOULD be | |||
| displayed; otherwise, the explicitText string SHOULD be displayed. | displayed; otherwise, the explicitText string SHOULD be displayed. | |||
| Note: While the explicitText has a maximum size of 200 characters, | Note: While the explicitText has a maximum size of 200 characters, | |||
| some non-conforming CAs exceed this limit. Therefore, certificate | some non-conforming CAs exceed this limit. Therefore, certificate | |||
| users SHOULD gracefully handle explicitText with more than 200 | users SHOULD gracefully handle explicitText with more than 200 | |||
| characters. | characters. | |||
| skipping to change at page 35, line 9 ¶ | skipping to change at page 35, line 25 ¶ | |||
| The subject alternative name extension allows identities to be bound | The subject alternative name extension allows identities to be bound | |||
| to the subject of the certificate. These identities may be included | to the subject of the certificate. These identities may be included | |||
| in addition to or in place of the identity in the subject field of | in addition to or in place of the identity in the subject field of | |||
| the certificate. Defined options include an Internet electronic mail | the certificate. Defined options include an Internet electronic mail | |||
| address, a DNS name, an IP address, and a uniform resource identifier | address, a DNS name, an IP address, and a uniform resource identifier | |||
| (URI). Other options exist, including completely local definitions. | (URI). Other options exist, including completely local definitions. | |||
| Multiple name forms, and multiple instances of each name form, MAY be | Multiple name forms, and multiple instances of each name form, MAY be | |||
| included. Whenever such identities are to be bound into a | included. Whenever such identities are to be bound into a | |||
| certificate, the subject alternative name (or issuer alternative | certificate, the subject alternative name (or issuer alternative | |||
| name) extension MUST be used; however, a DNS name MAY be represented | name) extension MUST be used; however, a DNS name MAY also be | |||
| in the subject field using the domainComponent attribute as described | represented in the subject field using the domainComponent attribute | |||
| in section 4.1.2.4. | as described in section 4.1.2.4. Note that where such names are | |||
| represented in the subject field implementations are not required to | ||||
| convert them into DNS names. | ||||
| Because the subject alternative name is considered to be definitively | Because the subject alternative name is considered to be definitively | |||
| bound to the public key, all parts of the subject alternative name | bound to the public key, all parts of the subject alternative name | |||
| MUST be verified by the CA. | MUST be verified by the CA. | |||
| Further, if the only subject identity included in the certificate is | Further, if the only subject identity included in the certificate is | |||
| an alternative name form (e.g., an electronic mail address), then the | an alternative name form (e.g., an electronic mail address), then the | |||
| subject distinguished name MUST be empty (an empty sequence), and the | subject distinguished name MUST be empty (an empty sequence), and the | |||
| subjectAltName extension MUST be present. If the subject field | subjectAltName extension MUST be present. If the subject field | |||
| contains an empty sequence, then the issuing CA MUST include a | contains an empty sequence, then the issuing CA MUST include a | |||
| subjectAltName extension that is marked as critical. When including | subjectAltName extension that is marked as critical. When including | |||
| the subjectAltName extension in a certificate that has a non-empty | the subjectAltName extension in a certificate that has a non-empty | |||
| subject distinguished name, conforming CAs SHOULD mark the | subject distinguished name, conforming CAs SHOULD mark the | |||
| subjectAltName extension as non-critical. | subjectAltName extension as non-critical. | |||
| When the subjectAltName extension contains an Internet mail address, | When the subjectAltName extension contains an Internet mail address, | |||
| the address MUST be stored in the rfc822Name. The format of an | the address MUST be stored in the rfc822Name. The format of an | |||
| rfc822Name is an "addr-spec" as defined in [RFC 2822]. An addr-spec | rfc822Name is a "Mailbox" as defined in section 4.1.2 of [RFC 2821]. | |||
| has the form "local-part@domain". Note that an addr-spec has no | A Mailbox has the form "Local-part@Domain". Note that a Mailbox has | |||
| phrase (such as a common name) before it, has no comment (text | no phrase (such as a common name) before it, has no comment (text | |||
| surrounded in parentheses) after it, and is not surrounded by "<" and | surrounded in parentheses) after it, and is not surrounded by "<" and | |||
| ">". Rules for encoding Internet mail addresses that include | ">". Rules for encoding Internet mail addresses that include | |||
| internationalized domain names are specified in section 7.5. | internationalized domain names are specified in section 7.5. | |||
| When the subjectAltName extension contains a iPAddress, the address | When the subjectAltName extension contains a iPAddress, the address | |||
| MUST be stored in the octet string in "network byte order," as | MUST be stored in the octet string in "network byte order," as | |||
| specified in [RFC 791]. The least significant bit (LSB) of each | specified in [RFC 791]. The least significant bit (LSB) of each | |||
| octet is the LSB of the corresponding byte in the network address. | octet is the LSB of the corresponding byte in the network address. | |||
| For IP Version 4, as specified in RFC 791, the octet string MUST | For IP Version 4, as specified in RFC 791, the octet string MUST | |||
| contain exactly four octets. For IP Version 6, as specified in | contain exactly four octets. For IP Version 6, as specified in | |||
| [RFC 2460], the octet string MUST contain exactly sixteen octets. | [RFC 2460], the octet string MUST contain exactly sixteen octets. | |||
| When the subjectAltName extension contains a domain name system | When the subjectAltName extension contains a domain name system | |||
| label, the domain name MUST be stored in the dNSName (an IA5String). | label, the domain name MUST be stored in the dNSName (an IA5String). | |||
| The name MUST be in the "preferred name syntax," as specified by | The name MUST be in the "preferred name syntax," as specified by | |||
| [RFC 1034]. Note that while upper and lower case letters are allowed | section 3.5 of [RFC 1034] and as modified by section 2.1 of | |||
| [RFC 1123]. Note that while upper and lower case letters are allowed | ||||
| in domain names, no significance is attached to the case. In | in domain names, no significance is attached to the case. In | |||
| addition, while the string " " is a legal domain name, subjectAltName | addition, while the string " " is a legal domain name, subjectAltName | |||
| extensions with a dNSName of " " MUST NOT be used. Finally, the use | extensions with a dNSName of " " MUST NOT be used. Finally, the use | |||
| of the DNS representation for Internet mail addresses | of the DNS representation for Internet mail addresses | |||
| (subscriber.example.com instead of subscriber@example.com) MUST NOT | (subscriber.example.com instead of subscriber@example.com) MUST NOT | |||
| be used; such identities are to be encoded as rfc822Name. Rules for | be used; such identities are to be encoded as rfc822Name. Rules for | |||
| encoding internationalized domain names are specified in section 7.2. | encoding internationalized domain names are specified in section 7.2. | |||
| When the subjectAltName extension contains a URI, the name MUST be | When the subjectAltName extension contains a URI, the name MUST be | |||
| stored in the uniformResourceIdentifier (an IA5String). The name | stored in the uniformResourceIdentifier (an IA5String). The name | |||
| skipping to change at page 40, line 50 ¶ | skipping to change at page 41, line 17 ¶ | |||
| URIs). For example, ".example.com" indicates all the Internet mail | URIs). For example, ".example.com" indicates all the Internet mail | |||
| addresses in the domain "example.com", but not Internet mail | addresses in the domain "example.com", but not Internet mail | |||
| addresses on the host "example.com". | addresses on the host "example.com". | |||
| DNS name restrictions are expressed as host.example.com. Any DNS | DNS name restrictions are expressed as host.example.com. Any DNS | |||
| name that can be constructed by simply adding zero or more subdomains | name that can be constructed by simply adding zero or more subdomains | |||
| to the left hand side of the name satisfies the name constraint. For | to the left hand side of the name satisfies the name constraint. For | |||
| example, www.host.example.com would satisfy the constraint but | example, www.host.example.com would satisfy the constraint but | |||
| host1.example.com would not. | host1.example.com would not. | |||
| Legacy implementations exist where an RFC 822 name is embedded in the | Legacy implementations exist where an electronic mail address is | |||
| subject distinguished name in an attribute of type emailAddress | embedded in the subject distinguished name in an attribute of type | |||
| (section 4.1.2.6). When RFC 822 names are constrained, but the | emailAddress (section 4.1.2.6). When constraints are imposed on the | |||
| certificate does not include a subject alternative name, the RFC 822 | rfc822Name name form, but the certificate does not include a subject | |||
| name constraint MUST be applied to the attribute of type emailAddress | alternative name, the rfc822Name constraint MUST be applied to the | |||
| in the subject distinguished name. The ASN.1 syntax for emailAddress | attribute of type emailAddress in the subject distinguished name. | |||
| and the corresponding OID are supplied in appendix A. | The ASN.1 syntax for emailAddress and the corresponding OID are | |||
| supplied in appendix A. | ||||
| Restrictions of the form directoryName MUST be applied to the subject | Restrictions of the form directoryName MUST be applied to the subject | |||
| field in the certificate (when the certificate includes a non-empty | field in the certificate (when the certificate includes a non-empty | |||
| subject field) and to any names of type directoryName in the | subject field) and to any names of type directoryName in the | |||
| subjectAltName extension. Restrictions of the form x400Address MUST | subjectAltName extension. Restrictions of the form x400Address MUST | |||
| be applied to any names of type x400Address in the subjectAltName | be applied to any names of type x400Address in the subjectAltName | |||
| extension. | extension. | |||
| When applying restrictions of the form directoryName, an | When applying restrictions of the form directoryName, an | |||
| implementation MUST compare DN attributes. At a minimum, | implementation MUST compare DN attributes. At a minimum, | |||
| skipping to change at page 59, line 16 ¶ | skipping to change at page 59, line 45 ¶ | |||
| Conforming CRL issuers MUST use the key identifier method, and MUST | Conforming CRL issuers MUST use the key identifier method, and MUST | |||
| include this extension in all CRLs issued. | include this extension in all CRLs issued. | |||
| The syntax for this CRL extension is defined in section 4.2.1.1. | The syntax for this CRL extension is defined in section 4.2.1.1. | |||
| 5.2.2 Issuer Alternative Name | 5.2.2 Issuer Alternative Name | |||
| The issuer alternative name extension allows additional identities to | The issuer alternative name extension allows additional identities to | |||
| be associated with the issuer of the CRL. Defined options include an | be associated with the issuer of the CRL. Defined options include an | |||
| RFC 822 name (electronic mail address), a DNS name, an IP address, | electronic mail address (rfc822Name), a DNS name, an IP address, and | |||
| and a URI. Multiple instances of a name form and multiple name forms | a URI. Multiple instances of a name form and multiple name forms may | |||
| may be included. Whenever such identities are used, the issuer | be included. Whenever such identities are used, the issuer | |||
| alternative name extension MUST be used; however, a DNS name MAY be | alternative name extension MUST be used; however, a DNS name MAY be | |||
| represented in the issuer field using the domainComponent attribute | represented in the issuer field using the domainComponent attribute | |||
| as described in section 4.1.2.4. | as described in section 4.1.2.4. | |||
| Conforming CRL issuers SHOULD mark the issuerAltName extension non- | Conforming CRL issuers SHOULD mark the issuerAltName extension non- | |||
| critical. | critical. | |||
| The OID and syntax for this CRL extension are defined in section | The OID and syntax for this CRL extension are defined in section | |||
| 4.2.1.7. | 4.2.1.7. | |||
| skipping to change at page 78, line 4 ¶ | skipping to change at page 78, line 48 ¶ | |||
| policy information by performing the following steps in order: | policy information by performing the following steps in order: | |||
| (1) For each policy P not equal to anyPolicy in the | (1) For each policy P not equal to anyPolicy in the | |||
| certificate policies extension, let P-OID denote the OID for | certificate policies extension, let P-OID denote the OID for | |||
| policy P and P-Q denote the qualifier set for policy P. | policy P and P-Q denote the qualifier set for policy P. | |||
| Perform the following steps in order: | Perform the following steps in order: | |||
| (i) For each node of depth i-1 in the valid_policy_tree | (i) For each node of depth i-1 in the valid_policy_tree | |||
| where P-OID is in the expected_policy_set, create a child | where P-OID is in the expected_policy_set, create a child | |||
| node as follows: set the valid_policy to P-OID; set the | node as follows: set the valid_policy to P-OID; set the | |||
| qualifier_set to P-Q, and set the expected_policy_set to {P- | qualifier_set to P-Q, and set the expected_policy_set to | |||
| OID}. | {P-OID}. | |||
| For example, consider a valid_policy_tree with a node of | For example, consider a valid_policy_tree with a node of | |||
| depth i-1 where the expected_policy_set is {Gold, White}. | depth i-1 where the expected_policy_set is {Gold, White}. | |||
| Assume the certificate policies Gold and Silver appear in | Assume the certificate policies Gold and Silver appear in | |||
| the certificate policies extension of certificate i. The | the certificate policies extension of certificate i. The | |||
| Gold policy is matched but the Silver policy is not. This | Gold policy is matched but the Silver policy is not. This | |||
| rule will generate a child node of depth i for the Gold | rule will generate a child node of depth i for the Gold | |||
| policy. The result is shown as Figure 4. | policy. The result is shown as Figure 4. | |||
| +-----------------+ | +-----------------+ | |||
| skipping to change at page 96, line 6 ¶ | skipping to change at page 97, line 8 ¶ | |||
| * Step 5: If recognized, the implementation MUST perform scheme- | * Step 5: If recognized, the implementation MUST perform scheme- | |||
| based normalization as specified in section 5.3.3 of [RFC 3987]. | based normalization as specified in section 5.3.3 of [RFC 3987]. | |||
| Conforming implementations MUST recognize and perform scheme-based | Conforming implementations MUST recognize and perform scheme-based | |||
| normalization for the following schemes: ldap, http, https, and ftp. | normalization for the following schemes: ldap, http, https, and ftp. | |||
| If the scheme is not recognized, Step (5) is omitted. | If the scheme is not recognized, Step (5) is omitted. | |||
| When comparing URIs for equivalence, conforming implementations shall | When comparing URIs for equivalence, conforming implementations shall | |||
| perform a case-sensitive exact match. | perform a case-sensitive exact match. | |||
| Implementations should convert IRIs to Unicode before display. | Implementations should convert URIs to Unicode before display. | |||
| Specifically, conforming implementations should perform the | Specifically, conforming implementations should perform the | |||
| conversion operation specified in section 3.2 of [RFC 3987]. | conversion operation specified in section 3.2 of [RFC 3987]. | |||
| 7.5 Internationalized Electronic Mail Addresses | 7.5 Internationalized Electronic Mail Addresses | |||
| Electronic Mail addresses may be included in certificates and CRLs in | Electronic Mail addresses may be included in certificates and CRLs in | |||
| the subjectAltName and issuerAltName extensions, the name constraints | the subjectAltName and issuerAltName extensions, the name constraints | |||
| extension, authority information access extension, subject | extension, authority information access extension, subject | |||
| information access extension, issuing distribution point extension, | information access extension, issuing distribution point extension, | |||
| or CRL distribution points extension. Each of these extensions uses | or CRL distribution points extension. Each of these extensions uses | |||
| the GeneralName construct; GeneralName includes the rfc822Name | the GeneralName construct; GeneralName includes the rfc822Name | |||
| choice, which is defined as type IA5String. To accommodate email | choice, which is defined as type IA5String. To accommodate email | |||
| addresses with internationalized domain names using the current | addresses with internationalized domain names using the current | |||
| structure, conforming implementations MUST convert the addresses into | structure, conforming implementations MUST convert the addresses into | |||
| an ASCII representation. | an ASCII representation. | |||
| Where the host-part (the domain of the addr-spec) contains an | Where the host-part (the Domain of the Mailbox) contains an | |||
| internationalized name, the domain name MUST be converted from an IDN | internationalized name, the domain name MUST be converted from an IDN | |||
| to the ASCII Compatible Encoding (ACE) format as specified in section | to the ASCII Compatible Encoding (ACE) format as specified in section | |||
| 7.2. | 7.2. | |||
| Two email addresses are considered to match if: | Two email addresses are considered to match if: | |||
| 1) the local-part of each name is an exact match, AND | 1) the local-part of each name is an exact match, AND | |||
| 2) the host-part of each name matches using a case-insensitive | 2) the host-part of each name matches using a case-insensitive | |||
| ASCII comparison. | ASCII comparison. | |||
| Implementations should convert the host-part of internationalized | Implementations should convert the host-part of internationalized | |||
| email addresses specified in these extensions to Unicode before | email addresses specified in these extensions to Unicode before | |||
| display. Specifically, conforming implementations should perform the | display. Specifically, conforming implementations should perform the | |||
| conversion of the host-part in the addr-spec as described in section | conversion of the host-part of the Mailbox as described in section | |||
| 7.2. | 7.2. | |||
| 8 References | 8 References | |||
| Normative References | Normative References | |||
| [RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, | [RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, | |||
| September 1981. | September 1981. | |||
| [RFC 1034] Mockapetris, P., "Domain Names - Concepts and | [RFC 1034] Mockapetris, P., "Domain Names - Concepts and | |||
| Facilities", STD 13, RFC 1034, November 1987. | Facilities", STD 13, RFC 1034, November 1987. | |||
| [RFC 1123] Braden, R., Ed., "Requirements for Internet Hosts -- | ||||
| Application and Support", STD 3, RFC 1123, October 1989. | ||||
| [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
| [RFC 2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 | [RFC 2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 | |||
| (IPv6) Specification", RFC 2460, December 1998. | (IPv6) Specification", RFC 2460, December 1998. | |||
| [RFC 2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key | [RFC 2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key | |||
| Infrastructure: Operational Protocols: FTP and HTTP", RFC | Infrastructure: Operational Protocols: FTP and HTTP", RFC | |||
| 2585, May 1999. | 2585, May 1999. | |||
| [RFC 2616] Fielding, R., J. Gettys, J. Mogul, H. Frystyk, L. | [RFC 2616] Fielding, R., J. Gettys, J. Mogul, H. Frystyk, L. | |||
| Masinter, P. Leach and T. Berners-Lee, "Hypertext | Masinter, P. Leach and T. Berners-Lee, "Hypertext | |||
| Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. | |||
| [RFC 2797] Myers, M., X. Liu, J. Schaad and J. Weinstein, | [RFC 2797] Myers, M., X. Liu, J. Schaad and J. Weinstein, | |||
| "Certificate Management Messages over CMS", RFC 2797, | "Certificate Management Messages over CMS", RFC 2797, | |||
| April 2000. | April 2000. | |||
| [RFC 2822] Resnick, P., "Internet Message Format", RFC 2822, April | [RFC 2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC | |||
| 2001. | 2821, April 2001. | |||
| [RFC 3454] Hoffman, P. and M. Blanchet, "Preparation of | [RFC 3454] Hoffman, P. and M. Blanchet, "Preparation of | |||
| Internationalized Strings (stringprep)", RFC 3454, | Internationalized Strings (stringprep)", RFC 3454, | |||
| December 2002. | December 2002. | |||
| [RFC 3490] Falstrom, P., P. Hoffman and A. Costello, | [RFC 3490] Falstrom, P., P. Hoffman and A. Costello, | |||
| "Internationalizing Domain Names In Applications (IDNA)", | "Internationalizing Domain Names In Applications (IDNA)", | |||
| RFC 3490, March 2003. | RFC 3490, March 2003. | |||
| [RFC 3629] Yergeau, F., "UTF-8, a transformation format of ISO | [RFC 3629] Yergeau, F., "UTF-8, a transformation format of ISO | |||
| 10646", RFC 3629, November 2003. | 10646", STD 63, RFC 3629, November 2003. | |||
| [RFC 3986] Berners-Lee, T., R. Fielding and L. Masinter, "Uniform | [RFC 3986] Berners-Lee, T., R. Fielding and L. Masinter, "Uniform | |||
| Resource Identifier (URI): Generic Syntax", RFC 3986, | Resource Identifier (URI): Generic Syntax", STD 66, RFC | |||
| January 2005. | 3986, January 2005. | |||
| [RFC 3987] Duerst, M. and M. Suigard, "Internationalized Resource | [RFC 3987] Duerst, M. and M. Suigard, "Internationalized Resource | |||
| Identifiers (IRIs)", RFC 3987, January 2005. | Identifiers (IRIs)", RFC 3987, January 2005. | |||
| [RFC 4516] Smith, M. and T. Howes, "Lightweight Directory Access | [RFC 4516] Smith, M. and T. Howes, "Lightweight Directory Access | |||
| Protocol (LDAP): Uniform Resource Locator", RFC 4516, | Protocol (LDAP): Uniform Resource Locator", RFC 4516, | |||
| June 2006. | June 2006. | |||
| [RFC 4518] Zeilenga, K., "Lightweight Directory Access Protocol | [RFC 4518] Zeilenga, K., "Lightweight Directory Access Protocol | |||
| (LDAP): Internationalized String Preparation", RFC 4518, | (LDAP): Internationalized String Preparation", RFC 4518, | |||
| June 2006. | June 2006. | |||
| [RFC 4523] Zeilenga, K., "Lightweight Directory Access Protocol | [RFC 4523] Zeilenga, K., "Lightweight Directory Access Protocol | |||
| (LDAP) Schema Definitions for X.509 Certificates", June | (LDAP) Schema Definitions for X.509 Certificates", June | |||
| 2006. | 2006. | |||
| [RFC 4632] Fuller, V. and T. Li, "Classless Inter-domain Routing | [RFC 4632] Fuller, V. and T. Li, "Classless Inter-domain Routing | |||
| (CIDR): The Internet Address Assignment and Aggregation | (CIDR): The Internet Address Assignment and Aggregation | |||
| Plan", RFC 4632, August 2006. | Plan", BCP 122, RFC 4632, August 2006. | |||
| [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, | [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, | |||
| Information technology - Abstract Syntax Notation One | Information technology - Abstract Syntax Notation One | |||
| (ASN.1): Specification of basic notation. | (ASN.1): Specification of basic notation. | |||
| [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, | [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, | |||
| Information technology - ASN.1 encoding rules: | Information technology - ASN.1 encoding rules: | |||
| Specification of Basic Encoding Rules (BER), Canonical | Specification of Basic Encoding Rules (BER), Canonical | |||
| Encoding Rules (CER) and Distinguished Encoding Rules | Encoding Rules (CER) and Distinguished Encoding Rules | |||
| (DER). | (DER). | |||
| Informative References | Informative References | |||
| [ISO 8859] ISO/IEC 8859-1:1998. Information technology -- 8-bit | [ISO 8859] ISO/IEC 8859-1:1998. Information technology -- 8-bit | |||
| single-byte coded graphic character sets -- Part 1: Latin | single-byte coded graphic character sets -- Part 1: Latin | |||
| alphabet No. 1. | alphabet No. 1. | |||
| [ISO 10646] ISO/IEC 10646:2003. Information technology -- Universal | [ISO 10646] ISO/IEC 10646:2003. Information technology -- Universal | |||
| Multiple-Octet Coded Character Set (UCS). | 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/>. | ||||
| [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic | [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic | |||
| Mail: Part II: Certificate-Based Key Management," RFC | Mail: Part II: Certificate-Based Key Management," RFC | |||
| 1422, February 1993. | 1422, February 1993. | |||
| [RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and | [RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and | |||
| Languages", BCP 18, RFC 2277, January 1998. | Languages", BCP 18, RFC 2277, January 1998. | |||
| [RFC 2459] Housley, R., W. Ford, W. Polk and D. Solo, "Internet | [RFC 2459] Housley, R., W. Ford, W. Polk and D. Solo, "Internet | |||
| X.509 Public Key Infrastructure: Certificate and CRL | X.509 Public Key Infrastructure: Certificate and CRL | |||
| Profile", RFC 2459, January 1999. | Profile", RFC 2459, January 1999. | |||
| [RFC 2560] Myers, M., R. Ankney, A. Malpani, S. Galperin and C. | [RFC 2560] Myers, M., R. Ankney, A. Malpani, S. Galperin and C. | |||
| Adams, "Online Certificate Status Protocol - OCSP", June | Adams, "Online Certificate Status Protocol - OCSP", June | |||
| 1999. | 1999. | |||
| [RFC 2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, | ||||
| April 2001. | ||||
| [RFC 2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object | [RFC 2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object | |||
| Classes and Attribute Types Version 2.0", RFC 2985, | Classes and Attribute Types Version 2.0", RFC 2985, | |||
| November 2000. | November 2000. | |||
| [RFC 3161] Adams, C., P. Cain, D. Pinkas and R. Zuccherato, | [RFC 3161] Adams, C., P. Cain, D. Pinkas and R. Zuccherato, | |||
| "Internet X.509 Public Key Infrastructure Time-Stamp | "Internet X.509 Public Key Infrastructure Time-Stamp | |||
| Protocol (TSP)", RFC 3161, August 2001. | Protocol (TSP)", RFC 3161, August 2001. | |||
| [RFC 3279] Bassham, L., W. Polk and R. Housley, "Algorithms and | [RFC 3279] Bassham, L., W. Polk and R. Housley, "Algorithms and | |||
| Identifiers for the Internet X.509 Public Key | Identifiers for the Internet X.509 Public Key | |||
| skipping to change at page 99, line 38 ¶ | skipping to change at page 100, line 46 ¶ | |||
| [RFC 4210] Adams, C., S. Farrell, T. Kause and T. Mononen, "Internet | [RFC 4210] Adams, C., S. Farrell, T. Kause and T. Mononen, "Internet | |||
| X.509 Public Key Infrastructure Certificate Management | X.509 Public Key Infrastructure Certificate Management | |||
| Protocol (CMP)", RFC 4210, September 2005. | Protocol (CMP)", RFC 4210, September 2005. | |||
| [RFC 4325] Santesson, S. and R. Housley, "Internet X.509 Public Key | [RFC 4325] Santesson, S. and R. Housley, "Internet X.509 Public Key | |||
| Infrastructure Authority Information Access Certificate | Infrastructure Authority Information Access Certificate | |||
| Revocation List (CRL) Extension", RFC 4325, December | Revocation List (CRL) Extension", RFC 4325, December | |||
| 2005. | 2005. | |||
| [RFC 4491] Leontiev, S. and D. Shefanovski, "Using the GOST R | [RFC 4491] Leontiev, S., Ed., and D. Shefanovski, Ed., "Using the | |||
| 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 | GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 | |||
| Algorithms with the Internet X.509 Public Key | Algorithms with the Internet X.509 Public Key | |||
| Infrastructure Certificate and CRL Profile", RFC 4491, | Infrastructure Certificate and CRL Profile", RFC 4491, | |||
| May 2006. | May 2006. | |||
| [RFC 4510] Zeilenga, K., "Lightweight Directory Access Protocol | [RFC 4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol | |||
| (LDAP): Technical Specification Road Map", RFC 4510, June | (LDAP): Technical Specification Road Map", RFC 4510, June | |||
| 2006. | 2006. | |||
| [RFC 4512] Zeilenga, K., "Lightweight Directory Access Protocol | [RFC 4512] Zeilenga, K., Ed., "Lightweight Directory Access Protocol | |||
| (LDAP): Directory Information Models", RFC 4512, June | (LDAP): Directory Information Models", RFC 4512, June | |||
| 2006. | 2006. | |||
| [RFC 4514] Zeilenga, K., "Lightweight Directory Access Protocol | [RFC 4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol | |||
| (LDAP): String Representation of Distinguished Names", | (LDAP): String Representation of Distinguished Names", | |||
| RFC 4514, June 2006. | RFC 4514, June 2006. | |||
| [RFC 4519] Sciberras, A., "Lightweight Directory Access Protocol | [RFC 4519] Sciberras, A., Ed., "Lightweight Directory Access | |||
| (LDAP): Schema for User Applications", RFC 4519, June | Protocol (LDAP): Schema for User Applications", RFC 4519, | |||
| 2006. | June 2006. | |||
| [RFC 4630] Housley, R. and S. Santesson, "Update to DirectoryString | [RFC 4630] Housley, R. and S. Santesson, "Update to DirectoryString | |||
| Processing in the Internet X.509 Public Key | Processing in the Internet X.509 Public Key | |||
| Infrastructure Certificate and Certificate Revocation | Infrastructure Certificate and Certificate Revocation | |||
| List (CRL) Profile", RFC 4630, August 2006. | List (CRL) Profile", RFC 4630, August 2006. | |||
| [X.500] ITU-T Recommendation X.500 (2005) | ISO/IEC 9594-1:2005, | [X.500] ITU-T Recommendation X.500 (2005) | ISO/IEC 9594-1:2005, | |||
| Information technology - Open Systems Interconnection - | Information technology - Open Systems Interconnection - | |||
| The Directory: Overview of concepts, models and services. | The Directory: Overview of concepts, models and services. | |||
| skipping to change at page 101, line 26 ¶ | skipping to change at page 102, line 31 ¶ | |||
| Copies of IPR disclosures made to the IETF Secretariat and any | Copies of IPR disclosures made to the IETF Secretariat and any | |||
| assurances of licenses to be made available, or the result of an | assurances of licenses to be made available, or the result of an | |||
| attempt made to obtain a general license or permission for the use of | attempt made to obtain a general license or permission for the use of | |||
| such proprietary rights by implementers or users of this | such proprietary rights by implementers or users of this | |||
| specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository at | |||
| http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
| The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
| copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
| rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
| this standard. Please address the information to the IETF at ietf- | this standard. Please address the information to the IETF at | |||
| ipr@ietf.org. | ietf-ipr@ietf.org. | |||
| 10 Security Considerations | 10 Security Considerations | |||
| The majority of this specification is devoted to the format and | The majority of this specification is devoted to the format and | |||
| content of certificates and CRLs. Since certificates and CRLs are | content of certificates and CRLs. Since certificates and CRLs are | |||
| digitally signed, no additional integrity service is necessary. | digitally signed, no additional integrity service is necessary. | |||
| Neither certificates nor CRLs need be kept secret, and unrestricted | Neither certificates nor CRLs need be kept secret, and unrestricted | |||
| and anonymous access to certificates and CRLs has no security | and anonymous access to certificates and CRLs has no security | |||
| implications. | implications. | |||
| skipping to change at page 104, line 32 ¶ | skipping to change at page 105, line 37 ¶ | |||
| the same issuer name. As a means of reducing problems and security | the same issuer name. As a means of reducing problems and security | |||
| issues related to issuer name collisions, CA and CRL issuer names | issues related to issuer name collisions, CA and CRL issuer names | |||
| SHOULD be formed in a way that reduces the likelihood of name | SHOULD be formed in a way that reduces the likelihood of name | |||
| collisions. Implementers should take into account the possible | collisions. Implementers should take into account the possible | |||
| existence of multiple unrelated CAs and CRL issuers with the same | existence of multiple unrelated CAs and CRL issuers with the same | |||
| name. At a minimum, implementations validating CRLs MUST ensure that | name. At a minimum, implementations validating CRLs MUST ensure that | |||
| the certification path of a certificate and the CRL issuer | the certification path of a certificate and the CRL issuer | |||
| certification path used to validate the certificate terminate at the | certification path used to validate the certificate terminate at the | |||
| same trust anchor. | same trust anchor. | |||
| While the local-part of an RFC 822 name is case-sensitive [RFC 2821], | While the local-part of an electronic mail address is case-sensitive | |||
| emailAddress attribute values are not case-sensitive [RFC 2985]. As | [RFC 2821], emailAddress attribute values are not case-sensitive | |||
| a result, there is a risk that two different email addresses will be | [RFC 2985]. As a result, there is a risk that two different email | |||
| treated as the same address when the matching rule for the | addresses will be treated as the same address when the matching rule | |||
| emailAddress attribute is used, if the email server exploits the case | for the emailAddress attribute is used, if the email server exploits | |||
| sensitivity of mailbox local-parts. Implementers should not include | the case sensitivity of mailbox local-parts. Implementers should not | |||
| an email address in the emailAddress attribute if the email server | include an email address in the emailAddress attribute if the email | |||
| that hosts the email address treats the local-part of email addresses | server that hosts the email address treats the local-part of email | |||
| as case-sensitive. | addresses as case-sensitive. | |||
| Implementers should be aware of risks involved if the CRL | Implementers should be aware of risks involved if the CRL | |||
| distribution points or authority information access extensions of | distribution points or authority information access extensions of | |||
| corrupted certificates or CRLs contain links to malicious code. | corrupted certificates or CRLs contain links to malicious code. | |||
| Implementers should always take the steps of validating the retrieved | Implementers should always take the steps of validating the retrieved | |||
| data to ensure that the data is properly formed. | data to ensure that the data is properly formed. | |||
| When certificates include a cRLDistributionPoints extension with an | When certificates include a cRLDistributionPoints extension with an | |||
| https URI or similar scheme, circular dependencies can be introduced. | https URI or similar scheme, circular dependencies can be introduced. | |||
| The relying party is forced to perform an additional path validation | The relying party is forced to perform an additional path validation | |||
| skipping to change at page 114, line 4 ¶ | skipping to change at page 115, line 6 ¶ | |||
| utcTime UTCTime, | utcTime UTCTime, | |||
| generalTime GeneralizedTime } | generalTime GeneralizedTime } | |||
| UniqueIdentifier ::= BIT STRING | UniqueIdentifier ::= BIT STRING | |||
| SubjectPublicKeyInfo ::= SEQUENCE { | SubjectPublicKeyInfo ::= SEQUENCE { | |||
| algorithm AlgorithmIdentifier, | algorithm AlgorithmIdentifier, | |||
| subjectPublicKey BIT STRING } | subjectPublicKey BIT STRING } | |||
| Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension | Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension | |||
| Extension ::= SEQUENCE { | Extension ::= SEQUENCE { | |||
| extnID OBJECT IDENTIFIER, | extnID OBJECT IDENTIFIER, | |||
| critical BOOLEAN DEFAULT FALSE, | critical BOOLEAN DEFAULT FALSE, | |||
| extnValue OCTET STRING } | extnValue OCTET STRING | |||
| -- contains the DER encoding of an ASN.1 value | ||||
| -- corresponding to the extension type identified | ||||
| -- by extnID | ||||
| } | ||||
| -- CRL structures | -- CRL structures | |||
| CertificateList ::= SEQUENCE { | CertificateList ::= SEQUENCE { | |||
| tbsCertList TBSCertList, | tbsCertList TBSCertList, | |||
| signatureAlgorithm AlgorithmIdentifier, | signatureAlgorithm AlgorithmIdentifier, | |||
| signature BIT STRING } | signature BIT STRING } | |||
| TBSCertList ::= SEQUENCE { | TBSCertList ::= SEQUENCE { | |||
| version Version OPTIONAL, | version Version OPTIONAL, | |||
| skipping to change at page 131, line 46 ¶ | skipping to change at page 133, line 9 ¶ | |||
| Section C.4 contains an annotated hex dump of a CRL. The CRL is | Section C.4 contains an annotated hex dump of a CRL. The CRL is | |||
| issued by the CA whose distinguished name is | issued by the CA whose distinguished name is | |||
| cn=Example CA,dc=example,dc=com and the list of revoked certificates | cn=Example CA,dc=example,dc=com and the list of revoked certificates | |||
| includes the end entity certificate presented in C.2. | includes the end entity certificate presented in C.2. | |||
| The certificates were processed using Peter Gutmann's dumpasn1 | The certificates were processed using Peter Gutmann's dumpasn1 | |||
| utility to generate the output. The source for the dumpasn1 utility | utility to generate the output. The source for the dumpasn1 utility | |||
| is available at <http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c>. | is available at <http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c>. | |||
| The binaries for the certificates and CRLs are available at | The binaries for the certificates and CRLs are available at | |||
| <http://csrc.nist.gov/pki/pkixtools>. | http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/pkixtools. | |||
| In places in this appendix where a distinguished name is specified | In places in this appendix where a distinguished name is specified | |||
| using a string representation, the strings are formatted using the | using a string representation, the strings are formatted using the | |||
| rules specified in [RFC 4514]. | rules specified in [RFC 4514]. | |||
| C.1 RSA Self-Signed Certificate | C.1 RSA Self-Signed Certificate | |||
| This section contains an annotated hex dump of a 578 byte version 3 | This section contains an annotated hex dump of a 578 byte version 3 | |||
| certificate. The certificate contains the following information: | certificate. The certificate contains the following information: | |||
| skipping to change at page 135, line 25 ¶ | skipping to change at page 136, line 35 ¶ | |||
| (d) the subject's distinguished name is | (d) the subject's distinguished name is | |||
| cn=End Entity,dc=example,dc=com; | cn=End Entity,dc=example,dc=com; | |||
| (e) the certificate was valid from September 15, 2004 through March | (e) the certificate was valid from September 15, 2004 through March | |||
| 15, 2005; | 15, 2005; | |||
| (f) the certificate contains a 1024 bit RSA public key; | (f) the certificate contains a 1024 bit RSA public key; | |||
| (g) the certificate is an end entity certificate, as the basic | (g) the certificate is an end entity certificate, as the basic | |||
| constraints extension is not present; | constraints extension is not present; | |||
| (h) the certificate contains an authority key identifier extension | (h) the certificate contains an authority key identifier extension | |||
| matching the subject key identifier of the certificate in | matching the subject key identifier of the certificate in | |||
| appendix C.1; and | appendix C.1; and | |||
| (i) the certificate includes one alternative name - an RFC 822 | (i) the certificate includes one alternative name - an electronic | |||
| address of "end.entity@example.com". | mail address (rfc822Name) of "end.entity@example.com". | |||
| 0 625: SEQUENCE { | 0 625: SEQUENCE { | |||
| 4 474: SEQUENCE { | 4 474: SEQUENCE { | |||
| 8 3: [0] { | 8 3: [0] { | |||
| 10 1: INTEGER 2 | 10 1: INTEGER 2 | |||
| : } | : } | |||
| 13 1: INTEGER 18 | 13 1: INTEGER 18 | |||
| 16 13: SEQUENCE { | 16 13: SEQUENCE { | |||
| 18 9: OBJECT IDENTIFIER | 18 9: OBJECT IDENTIFIER | |||
| : sha1withRSAEncryption (1 2 840 113549 1 1 5) | : sha1withRSAEncryption (1 2 840 113549 1 1 5) | |||
| skipping to change at page 144, line 30 ¶ | skipping to change at page 145, line 42 ¶ | |||
| : 1F EE 90 17 A2 6F 60 E4 BD AA 8C 55 DE 8E 84 6F | : 1F EE 90 17 A2 6F 60 E4 BD AA 8C 55 DE 8E 84 6F | |||
| : 92 F8 9F 10 12 27 AF 4A D4 2F 85 E2 36 44 7D AA | : 92 F8 9F 10 12 27 AF 4A D4 2F 85 E2 36 44 7D AA | |||
| : A3 4C 25 38 15 FF 00 FD 3E 7E EE 3D 26 12 EB D8 | : A3 4C 25 38 15 FF 00 FD 3E 7E EE 3D 26 12 EB D8 | |||
| : E7 2B 62 E2 2B C3 46 80 EF 78 82 D1 15 C6 D0 9C | : E7 2B 62 E2 2B C3 46 80 EF 78 82 D1 15 C6 D0 9C | |||
| : 72 6A CB CE 7A ED 67 99 8B 6E 70 81 7D 43 42 74 | : 72 6A CB CE 7A ED 67 99 8B 6E 70 81 7D 43 42 74 | |||
| : C1 A6 AF C1 55 17 A2 33 4C D6 06 98 2B A4 FC 2E | : C1 A6 AF C1 55 17 A2 33 4C D6 06 98 2B A4 FC 2E | |||
| : } | : } | |||
| Full Copyright Statement | Full Copyright Statement | |||
| Copyright (C) The IETF Trust (2007). | Copyright (C) The IETF Trust (2008). | |||
| This document is subject to the rights, licenses and restrictions | This document is subject to the rights, licenses and restrictions | |||
| contained in BCP 78, and except as set forth therein, the authors | contained in BCP 78, and except as set forth therein, the authors | |||
| retain all their rights. | retain all their rights. | |||
| This document and the information contained herein are provided on an | This document and the information contained herein are provided on an | |||
| "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |||
| OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | |||
| THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | |||
| OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | |||
| End of changes. 55 change blocks. | ||||
| 132 lines changed or deleted | 154 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||