idnits 2.17.1 draft-josefsson-pkix-textual-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 17, 2012) is 4294 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4648' is defined on line 546, but no explicit reference was found in the text == Unused Reference: 'RFC2015' is defined on line 584, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2315 ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Obsolete normative reference: RFC 5208 (Obsoleted by RFC 5958) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Josefsson 3 Internet-Draft SJD AB 4 Intended status: Standards Track S. Leonard 5 Expires: January 18, 2013 Penango, Inc. 6 July 17, 2012 8 Text Encodings of PKIX and CMS Structures 9 draft-josefsson-pkix-textual-01 11 Abstract 13 This document describes and discuss the text encodings of Public-Key 14 Infrastructure using X.509 (PKIX) Certificates, PKIX Certificate 15 Revocation Lists (CRLs), PKCS #10 Certification Request Syntax, PKCS 16 #7 structures, Cryptographic Message Syntax (CMS), PKCS #8 Private- 17 Key Information Syntax, and Attribute Certificates. The text 18 encodings are well-known, are implemented by several applications and 19 libraries, and are widely deployed. This document is intended to 20 articulate the de-facto rules that existing implementations operate 21 by, and to give recommendations that will promote interoperability 22 going forward. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 18, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. General Considerations . . . . . . . . . . . . . . . . . . . . 4 60 3. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Text Encoding of PKIX Certificates . . . . . . . . . . . . . . 5 62 4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.2. Explanatory Text . . . . . . . . . . . . . . . . . . . . . 6 64 4.3. File Extension . . . . . . . . . . . . . . . . . . . . . . 7 65 5. Text Encoding of PKIX CRLs . . . . . . . . . . . . . . . . . . 7 66 6. Text Encoding of PKCS #10 Certification Request Syntax . . . . 7 67 7. Text Encoding of PKCS #7 Cryptographic Message Syntax . . . . 8 68 8. Text Encoding of Cryptographic Message Syntax . . . . . . . . 9 69 9. Text Encoding of PKCS #8 Private Key Info, and One 70 Asymmetric Key . . . . . . . . . . . . . . . . . . . . . . . . 9 71 10. Text Encoding of PKCS #8 Encrypted Private Key Info . . . . . 9 72 11. Text Encoding of Attribute Certificates . . . . . . . . . . . 10 73 12. Non-Conforming Examples . . . . . . . . . . . . . . . . . . . 10 74 13. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 77 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 16.1. Normative References . . . . . . . . . . . . . . . . . . . 13 79 16.2. Informative References . . . . . . . . . . . . . . . . . . 13 80 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 83 1. Introduction 85 Several security-related standards used on the Internet define data 86 formats that are normally encoded using Distinguished Encoding Rules 87 (DER) [CCITT.X690.2002], which is a binary data format. This 88 document is about text encodings of some of these formats: 90 1. Internet X.509 Public Key Infrastructure Certificate and 91 Certificate Revocation List (CRL) Profile [RFC5280], for both 92 Certificates and Certificate Revocation Lists (CRLs). 93 2. PKCS #10: Certification Request Syntax [RFC2986]. 94 3. PKCS #7: Cryptographic Message Syntax [RFC2315]. 95 4. Cryptographic Message Syntax [RFC5652]. 96 5. PKCS #8: Private-Key Information Syntax [RFC5208] and One 97 Asymmetric Key (in Asymmetric Key Package [RFC5958]). 98 6. An Internet Attribute Certificate Profile for Authorization 99 [RFC5755]. 101 A disadvantage of a binary data format is that it cannot be 102 interchanged in textual transports, such as e-mail or text documents. 103 One advantage with text encodings is that they are easy to modify 104 using common text editors; for example, a user may concatenate 105 several certificates to form a certificate chain with copy-and-paste 106 operations. 108 The tradition within the RFC series can be traced back to PEM 109 [RFC1421], based on a proposal by M. Rose in Message Encapsulation 110 [RFC0934]. Originally called "PEM encapsulation mechanism", 111 "encapsulated PEM message", or (arguably) "PEM printable encoding", 112 today the format is sometimes referred to as "PEM encoding". 113 Variations include OpenPGP ASCII Armor and OpenSSH Key File Format. 115 For reasons that basically boil down to non-coordination (or gross 116 inattention), many PKIX and CMS libraries implement a text encoding 117 that is similar to--but not identical with--PEM encoding. This 118 Internet-Draft calls this format "PKIX text encoding", articulates 119 the de-facto rules that most implementations operate by, and provides 120 recommendations that will promote interoperability going forward. 121 Peter Gutmann's X.509 Style Guide [X509SG] contains a section "base64 122 Encoding" that describes the formats and contains suggestions similar 123 to what is in this document. 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in RFC 128 2119 [RFC2119]. 130 2. General Considerations 132 PKIX text encoding begins with a line starting with "-----BEGIN" and 133 ends with a line starting with "-----END". Between these lines, or 134 "encapsulation boundaries", are base64 [RFC4648]-encoded data. Data 135 before the "-----BEGIN" and after the "-----END" encapsulation 136 boundaries are permitted and MUST NOT cause parsers to malfunction. 137 Furthermore, parsers MUST ignore whitespace and other non-alphabetic 138 characters [DP1] and MUST handle different newline conventions. 140 The type of data encoded is labeled depending on the type label in 141 the "-----BEGIN" line (pre-encapsulation boundary). For example, the 142 line may be "-----BEGIN CERTIFICATE-----" to indicate that the 143 content is a PKIX certificate (see further below). Generators MUST 144 put the same label on the "-----END" line (post-encapsulation 145 boundary) as the corresponding "-----BEGIN" line. Parsers MAY 146 disregard the label on the "-----END" line instead of signaling an 147 error if there is a label mismatch. 149 The label type implies that the encoded data follows the specified 150 syntax. Parsers MUST handle non-conforming data gracefully. 151 However, not all parsers or generators prior to this Internet-Draft 152 behave consistently. A conforming parser MAY interpret the contents 153 as another label type, but ought to be aware of the security 154 implications discussed in the Security Considerations section. 156 Unlike PEM encoding, OpenPGP ASCII armor, and OpenSSH key file 157 format, PKIX text encoding does NOT define or permit attributes to be 158 encoded alongside the PKIX or CMS data. Whitespace MAY appear 159 between the pre-encapsulation boundary and the base64, but generators 160 SHOULD NOT emit such whitespace. 162 Files MAY contain multiple instances of the text encoded 163 representation. This is used, for example, when a file contains 164 several certificates. Whether the instances are ordered or unordered 165 depends on the context. 167 Generators MUST wrap the base64 encoded lines so that each line 168 consists of exactly 64 characters except for the final line which 169 will encode as much data is left (within the 64 character line 170 boundary). Parsers MAY handle other line sizes. These requirements 171 are consistent with PEM [RFC1421]. 173 3. ABNF 175 The ABNF of the PKIX text encoding is: 177 pkixmsg ::= preeb 178 *eolWSP 179 base64text 180 posteb 182 preeb ::= "-----BEGIN " label "-----" eol 184 posteb ::= "-----END " label "-----" eol 186 base64char ::= ALPHA / DIGIT / "+" / "/" 188 base64pad ::= "=" 190 base64line ::= 1*base64char eol 192 base64finl ::= *base64char *2base64pad eol ; implies that: 193 ; ...AB= = 194 ; is invalid. not sure 195 ; if this is a good idea 197 base64text ::= *base64line base64finl 198 ; we could also use from RFC 1421, 199 ; which requires 16 groups of 4 chars, which means 64 chars 200 ; exactly per line, except the final line 202 labelchar ::= %x21-2C / %x2E-%7E ; any printable character, 203 ; except hyphen 205 label ::= labelchar *(labelchar / labelchar "-" / SP) labelchar 207 eol ::= CRLF / CR / LF 209 eolWSP ::= WSP / CR / LF ; compare with LWSP 211 Figure 1: ABNF 213 4. Text Encoding of PKIX Certificates 215 4.1. Encoding 217 PKIX certificates are encoded using the "CERTIFICATE" label. The 218 encoded data MUST be a DER encoded ASN.1 "Certificate" structure as 219 described in section 4 of [RFC5280]. 221 -----BEGIN CERTIFICATE----- 222 MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G 223 A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y 224 aXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdudVRMUyBjZXJ0aWZpY2F0 225 ZSBhdXRob3JpdHkwHhcNMTEwNTIzMjAzODIxWhcNMTIxMjIyMDc0MTUxWjB9MQsw 226 CQYDVQQGEwJCRTEPMA0GA1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2Vy 227 dGlmaWNhdGUgYXV0aG9yaXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdu 228 dVRMUyBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkwWTATBgcqhkjOPQIBBggqhkjOPQMB 229 BwNCAARS2I0jiuNn14Y2sSALCX3IybqiIJUvxUpj+oNfzngvj/Niyv2394BWnW4X 230 uQ4RTEiywK87WRcWMGgJB5kX/t2no0MwQTAPBgNVHRMBAf8EBTADAQH/MA8GA1Ud 231 DwEB/wQFAwMHBgAwHQYDVR0OBBYEFPC0gf6YEr+1KLlkQAPLzB9mTigDMAoGCCqG 232 SM49BAMCA0gAMEUCIDGuwD1KPyG+hRf88MeyMQcqOFZD0TbVleF+UsAGQ4enAiEA 233 l4wOuDwKQa+upc8GftXE2C//4mKANBC6It01gUaTIpo= 234 -----END CERTIFICATE----- 236 Figure 2: Certificate Example 238 Historically the label "X509 CERTIFICATE" and also, less common, 239 "X.509 CERTIFICATE" have been used. Generators conforming to this 240 document MUST generate "CERTIFICATE" labels and MUST NOT generate 241 "X509 CERTIFICATE" or "X.509 CERTIFICATE" labels. Parsers are NOT 242 RECOMMENDED to treat "X509 CERTIFICATE" or "X.509 CERTIFICATE" as 243 equivalent to "CERTIFICATE", but a valid exception may be for 244 backwards compatibility (potentially together with a warning). 246 4.2. Explanatory Text 248 Many tools are known to emit explanatory text before the BEGIN and 249 after the END labels for PKIX certificates, more than any other type. 250 If emitted, such text SHOULD be related to the certificate, such as 251 providing a textual representation of key data elements in the 252 certificate. 254 Subject: CN=Atlantis 255 Issuer: CN=Atlantis 256 Validity: from 7/9/2012 3:10:38 AM UTC to 7/9/2013 3:10:37 AM UTC 257 -----BEGIN CERTIFICATE----- 258 MIIBmTCCAUegAwIBAgIBKjAJBgUrDgMCHQUAMBMxETAPBgNVBAMTCEF0bGFudGlz 259 MB4XDTEyMDcwOTAzMTAzOFoXDTEzMDcwOTAzMTAzN1owEzERMA8GA1UEAxMIQXRs 260 YW50aXMwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAu+BXo+miabDIHHx+yquqzqNh 261 Ryn/XtkJIIHVcYtHvIX+S1x5ErgMoHehycpoxbErZmVR4GCq1S2diNmRFZCRtQID 262 AQABo4GJMIGGMAwGA1UdEwEB/wQCMAAwIAYDVR0EAQH/BBYwFDAOMAwGCisGAQQB 263 gjcCARUDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDAzA1BgNVHQEE 264 LjAsgBA0jOnSSuIHYmnVryHAdywMoRUwEzERMA8GA1UEAxMIQXRsYW50aXOCASow 265 CQYFKw4DAh0FAANBAKi6HRBaNEL5R0n56nvfclQNaXiDT174uf+lojzA4lhVInc0 266 ILwpnZ1izL4MlI9eCSHhVQBHEp2uQdXJB+d5Byg= 267 -----END CERTIFICATE----- 268 Figure 3: Certificate Example with Explanatory Text 270 4.3. File Extension 272 Although text encodings of PKIX structures can occur anywhere, many 273 tools are known to offer an option to encode PKIX structures in this 274 text encoding. To promote interoperability and to separate DER 275 encodings from text encodings, This Internet-Draft RECOMMENDS that 276 the extension ".crt" be used for this text encoding. Implementations 277 should be aware that in spite of this recommendation, many tools 278 still default to encode certificates in this text encoding with the 279 extension ".cer". 281 5. Text Encoding of PKIX CRLs 283 PKIX CRLs are encoded using the "X509 CRL" label. The encoded data 284 MUST be a DER encoded ASN.1 "CertificateList" structure as described 285 in Section 5 of [RFC5280]. 287 -----BEGIN X509 CRL----- 288 MIIB9DCCAV8CAQEwCwYJKoZIhvcNAQEFMIIBCDEXMBUGA1UEChMOVmVyaVNpZ24s 289 IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT 290 PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYu 291 LExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEm 292 MCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxGDAWBgNVBAMU 293 D1NpbW9uIEpvc2Vmc3NvbjEiMCAGCSqGSIb3DQEJARYTc2ltb25Aam9zZWZzc29u 294 Lm9yZxcNMDYxMjI3MDgwMjM0WhcNMDcwMjA3MDgwMjM1WjAjMCECEC4QNwPfRoWd 295 elUNpllhhTgXDTA2MTIyNzA4MDIzNFowCwYJKoZIhvcNAQEFA4GBAD0zX+J2hkcc 296 Nbrq1Dn5IKL8nXLgPGcHv1I/le1MNo9t1ohGQxB5HnFUkRPAY82fR6Epor4aHgVy 297 b+5y+neKN9Kn2mPF4iiun+a4o26CjJ0pArojCL1p8T0yyi9Xxvyc/ezaZ98HiIyP 298 c3DGMNR+oUmSjKZ0jIhAYmeLxaPHfQwR 299 -----END X509 CRL----- 301 Figure 4: CRL Example 303 Historically the label "CRL" has rarely been used. Today it is not 304 common and many popular tools do not understand the label. 305 Therefore, this document standardizes "X509 CRL" in order to promote 306 interoperability and backwards-compatibility. Generators conforming 307 to this document MUST generate "X509 CRL" labels and MUST NOT 308 generate "CRL" labels. Parsers are NOT RECOMMENDED to treat "CRL" as 309 equivalent to "X509 CRL". 311 6. Text Encoding of PKCS #10 Certification Request Syntax 313 PKCS #10 Certification Requests are encoded using the "CERTIFICATE 314 REQUEST" label. The encoded data MUST be a DER encoded ASN.1 315 "CertificationRequest" structure as described in [RFC2986]. 317 -----BEGIN CERTIFICATE REQUEST----- 318 MIIBWDCCAQcCAQAwTjELMAkGA1UEBhMCU0UxJzAlBgNVBAoTHlNpbW9uIEpvc2Vm 319 c3NvbiBEYXRha29uc3VsdCBBQjEWMBQGA1UEAxMNam9zZWZzc29uLm9yZzBOMBAG 320 ByqGSM49AgEGBSuBBAAhAzoABLLPSkuXY0l66MbxVJ3Mot5FCFuqQfn6dTs+9/CM 321 EOlSwVej77tj56kj9R/j9Q+LfysX8FO9I5p3oGIwYAYJKoZIhvcNAQkOMVMwUTAY 322 BgNVHREEETAPgg1qb3NlZnNzb24ub3JnMAwGA1UdEwEB/wQCMAAwDwYDVR0PAQH/ 323 BAUDAwegADAWBgNVHSUBAf8EDDAKBggrBgEFBQcDATAKBggqhkjOPQQDAgM/ADA8 324 AhxBvfhxPFfbBbsE1NoFmCUczOFApEuQVUw3ZP69AhwWXk3dgSUsKnuwL5g/ftAY 325 dEQc8B8jAcnuOrfU 326 -----END CERTIFICATE REQUEST----- 328 Figure 5: PKCS #10 Example 330 The label "NEW CERTIFICATE REQUEST" is also in wide use. Generators 331 conforming to this document MUST generate "CERTIFICATE REQUEST" 332 labels. Parsers MAY treat "NEW CERTIFICATE REQUEST" as equivalent to 333 "CERTIFICATE REQUEST". 335 7. Text Encoding of PKCS #7 Cryptographic Message Syntax 337 PKCS #7 Cryptographic Message Syntax structures are encoded using the 338 "PKCS7" label. The encoded data MUST[mustshould1] be a DER encoded 339 ASN.1 "ContentInfo" structure as described in [RFC2315]. 341 -----BEGIN PKCS7----- 342 MIHjBgsqhkiG9w0BCRABF6CB0zCB0AIBADFho18CAQCgGwYJKoZIhvcNAQUMMA4E 343 CLfrI6dr0gUWAgITiDAjBgsqhkiG9w0BCRADCTAUBggqhkiG9w0DBwQIZpECRWtz 344 u5kEGDCjerXY8odQ7EEEromZJvAurk/j81IrozBSBgkqhkiG9w0BBwEwMwYLKoZI 345 hvcNAQkQAw8wJDAUBggqhkiG9w0DBwQI0tCBcU09nxEwDAYIKwYBBQUIAQIFAIAQ 346 OsYGYUFdAH0RNc1p4VbKEAQUM2Xo8PMHBoYdqEcsbTodlCFAZH4= 347 -----END PKCS7----- 349 Figure 6: PKCS #7 Example 351 The label "CERTIFICATE CHAIN" has been in use to denote a 352 degenerative PKCS #7 structure that contains only a list of 353 certificates. Several modern tools do not support this label. 354 Generators MUST NOT generate the "CERTIFICATE CHAIN" label. Parsers 355 are NOT RECOMMENDED to treat "CERTIFICATE CHAIN" as equivalent to 356 "PKCS7". 358 PKCS #7 is an old standard that has long been superseded by CMS. 359 Implementations SHOULD NOT generate PKCS #7 when CMS is an 360 alternative. 362 8. Text Encoding of Cryptographic Message Syntax 364 Cryptographic Message Syntax structures are encoded using the "CMS" 365 label. The encoded data MUST[mustshould2] be a DER encoded ASN.1 366 "ContentInfo" structure as described in [RFC5652]. 368 -----BEGIN CMS----- 369 MIGDBgsqhkiG9w0BCRABCaB0MHICAQAwDQYLKoZIhvcNAQkQAwgwXgYJKoZIhvcN 370 AQcBoFEET3icc87PK0nNK9ENqSxItVIoSa0o0S/ISczMs1ZIzkgsKk4tsQ0N1nUM 371 dvb05OXi5XLPLEtViMwvLVLwSE0sKlFIVHAqSk3MBkkBAJv0Fx0= 372 -----END CMS----- 374 Figure 7: CMS Example 376 CMS is the IETF successor to PKCS #7. Section 1.1.1 of RFC 5652 377 describes the changes since PKCS #7 v1.5. Implementations SHOULD 378 generate CMS when it is an alternative, promoting ineroperability and 379 forwards-compatibility. 381 9. Text Encoding of PKCS #8 Private Key Info, and One Asymmetric Key 383 The PrivateKeyInfo structure of PKCS #8 Private Key Information 384 Syntax, renamed to OneAsymmetricKey in [RFC5958], is encoded using 385 the "PRIVATE KEY" label. The encoded data SHOULD be a DER encoded 386 ASN.1 "PrivateKeyInfo" structure as described in PKCS #8, or the 387 "OneAsymmetricKey" structure as described in [RFC5958]. The two are 388 semantically identical, and can be distinguished by version number. 390 -----BEGIN PRIVATE KEY----- 391 MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgVcB/UNPxalR9zDYAjQIf 392 jojUDiQuGnSJrFEEzZPT/92hRANCAASc7UJtgnF/abqWM60T3XNJEzBv5ez9TdwK 393 H0M6xpM2q+53wmsN/eYLdgtjgBd3DBmHtPilCkiFICXyaA8z9LkJ 394 -----END PRIVATE KEY----- 396 Figure 8: PKCS #8 PrivateKeyInfo Example 398 10. Text Encoding of PKCS #8 Encrypted Private Key Info 400 The EncryptedPrivateKeyInfo structure of PKCS #8 Private Key 401 Information Syntax, called the same in [RFC5958], is encoded using 402 the "ENCRYPTED PRIVATE KEY" label. The encoded data SHOULD be a DER 403 encoded ASN.1 "EncryptedPrivateKeyInfo" structure as described in 404 PKCS #8 and [RFC5958]. 406 -----BEGIN ENCRYPTED PRIVATE KEY----- 407 MIHNMEAGCSqGSIb3DQEFDTAzMBsGCSqGSIb3DQEFDDAOBAghhICA6T/51QICCAAw 408 FAYIKoZIhvcNAwcECBCxDgvI59i9BIGIY3CAqlMNBgaSI5QiiWVNJ3IpfLnEiEsW 409 Z0JIoHyRmKK/+cr9QPLnzxImm0TR9s4JrG3CilzTWvb0jIvbG3hu0zyFPraoMkap 410 8eRzWsIvC5SVel+CSjoS2mVS87cyjlD+txrmrXOVYDE+eTgMLbrLmsWh3QkCTRtF 411 QC7k0NNzUHTV9yGDwfqMbw== 412 -----END ENCRYPTED PRIVATE KEY----- 414 Figure 9: PKCS #8 EncryptedPrivateKeyInfo Example 416 11. Text Encoding of Attribute Certificates 418 Attribute certificates are encoded using the "ATTRIBUTE CERTIFICATE" 419 label. The encoded data MUST be a DER encoded ASN.1 420 "AttributeCertificate" structure as described in [RFC5755]. 422 -----BEGIN ATTRIBUTE CERTIFICATE----- 423 MIICKzCCAZQCAQEwgZeggZQwgYmkgYYwgYMxCzAJBgNVBAYTAlVTMREwDwYDVQQI 424 DAhOZXcgWW9yazEUMBIGA1UEBwwLU3RvbnkgQnJvb2sxDzANBgNVBAoMBkNTRTU5 425 MjE6MDgGA1UEAwwxU2NvdHQgU3RhbGxlci9lbWFpbEFkZHJlc3M9c3N0YWxsZXJA 426 aWMuc3VueXNiLmVkdQIGARWrgUUSoIGMMIGJpIGGMIGDMQswCQYDVQQGEwJVUzER 427 MA8GA1UECAwITmV3IFlvcmsxFDASBgNVBAcMC1N0b255IEJyb29rMQ8wDQYDVQQK 428 DAZDU0U1OTIxOjA4BgNVBAMMMVNjb3R0IFN0YWxsZXIvZW1haWxBZGRyZXNzPXNz 429 dGFsbGVyQGljLnN1bnlzYi5lZHUwDQYJKoZIhvcNAQEFBQACBgEVq4FFSjAiGA8z 430 OTA3MDIwMTA1MDAwMFoYDzM5MTEwMTMxMDUwMDAwWjArMCkGA1UYSDEiMCCGHmh0 431 dHA6Ly9pZGVyYXNobi5vcmcvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUFAAOBgQAV 432 M9axFPXXozEFcer06bj9MCBBCQLtAM7ZXcZjcxyva7xCBDmtZXPYUluHf5OcWPJz 433 5XPus/xS9wBgtlM3fldIKNyNO8RsMp6Ocx+PGlICc7zpZiGmCYLl64lAEGPO/bsw 434 Smluak1aZIttePeTAHeJJs8izNJ5aR3Wcd3A5gLztQ== 435 -----END ATTRIBUTE CERTIFICATE----- 437 Figure 10: Attribute Certificate Example 439 12. Non-Conforming Examples 441 [DPncfex] This section contains examples for the non-recommended 442 label variants described earlier in this document. As discussed 443 earlier, supporting these are not required and sometimes discouraged. 444 Still, they can be useful for interoperability testing and for easy 445 reference. 447 -----BEGIN X509 CERTIFICATE----- 448 MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G 449 A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y 450 aXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdudVRMUyBjZXJ0aWZpY2F0 451 ZSBhdXRob3JpdHkwHhcNMTEwNTIzMjAzODIxWhcNMTIxMjIyMDc0MTUxWjB9MQsw 452 CQYDVQQGEwJCRTEPMA0GA1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2Vy 453 dGlmaWNhdGUgYXV0aG9yaXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdu 454 dVRMUyBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkwWTATBgcqhkjOPQIBBggqhkjOPQMB 455 BwNCAARS2I0jiuNn14Y2sSALCX3IybqiIJUvxUpj+oNfzngvj/Niyv2394BWnW4X 456 uQ4RTEiywK87WRcWMGgJB5kX/t2no0MwQTAPBgNVHRMBAf8EBTADAQH/MA8GA1Ud 457 DwEB/wQFAwMHBgAwHQYDVR0OBBYEFPC0gf6YEr+1KLlkQAPLzB9mTigDMAoGCCqG 458 SM49BAMCA0gAMEUCIDGuwD1KPyG+hRf88MeyMQcqOFZD0TbVleF+UsAGQ4enAiEA 459 l4wOuDwKQa+upc8GftXE2C//4mKANBC6It01gUaTIpo= 460 -----END X509 CERTIFICATE----- 462 Figure 11: Non-standard 'X509' Certificate Example 464 -----BEGIN X.509 CERTIFICATE----- 465 MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G 466 A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y 467 aXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdudVRMUyBjZXJ0aWZpY2F0 468 ZSBhdXRob3JpdHkwHhcNMTEwNTIzMjAzODIxWhcNMTIxMjIyMDc0MTUxWjB9MQsw 469 CQYDVQQGEwJCRTEPMA0GA1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2Vy 470 dGlmaWNhdGUgYXV0aG9yaXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdu 471 dVRMUyBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkwWTATBgcqhkjOPQIBBggqhkjOPQMB 472 BwNCAARS2I0jiuNn14Y2sSALCX3IybqiIJUvxUpj+oNfzngvj/Niyv2394BWnW4X 473 uQ4RTEiywK87WRcWMGgJB5kX/t2no0MwQTAPBgNVHRMBAf8EBTADAQH/MA8GA1Ud 474 DwEB/wQFAwMHBgAwHQYDVR0OBBYEFPC0gf6YEr+1KLlkQAPLzB9mTigDMAoGCCqG 475 SM49BAMCA0gAMEUCIDGuwD1KPyG+hRf88MeyMQcqOFZD0TbVleF+UsAGQ4enAiEA 476 l4wOuDwKQa+upc8GftXE2C//4mKANBC6It01gUaTIpo= 477 -----END X.509 CERTIFICATE----- 479 Figure 12: Non-standard 'X.509' Certificate Example 481 -----BEGIN NEW CERTIFICATE REQUEST----- 482 MIIBWDCCAQcCAQAwTjELMAkGA1UEBhMCU0UxJzAlBgNVBAoTHlNpbW9uIEpvc2Vm 483 c3NvbiBEYXRha29uc3VsdCBBQjEWMBQGA1UEAxMNam9zZWZzc29uLm9yZzBOMBAG 484 ByqGSM49AgEGBSuBBAAhAzoABLLPSkuXY0l66MbxVJ3Mot5FCFuqQfn6dTs+9/CM 485 EOlSwVej77tj56kj9R/j9Q+LfysX8FO9I5p3oGIwYAYJKoZIhvcNAQkOMVMwUTAY 486 BgNVHREEETAPgg1qb3NlZnNzb24ub3JnMAwGA1UdEwEB/wQCMAAwDwYDVR0PAQH/ 487 BAUDAwegADAWBgNVHSUBAf8EDDAKBggrBgEFBQcDATAKBggqhkjOPQQDAgM/ADA8 488 AhxBvfhxPFfbBbsE1NoFmCUczOFApEuQVUw3ZP69AhwWXk3dgSUsKnuwL5g/ftAY 489 dEQc8B8jAcnuOrfU 490 -----END NEW CERTIFICATE REQUEST----- 492 Figure 13: Non-standard 'NEW' PKCS #10 Example 494 -----BEGIN CERTIFICATE CHAIN----- 495 MIHjBgsqhkiG9w0BCRABF6CB0zCB0AIBADFho18CAQCgGwYJKoZIhvcNAQUMMA4E 496 CLfrI6dr0gUWAgITiDAjBgsqhkiG9w0BCRADCTAUBggqhkiG9w0DBwQIZpECRWtz 497 u5kEGDCjerXY8odQ7EEEromZJvAurk/j81IrozBSBgkqhkiG9w0BBwEwMwYLKoZI 498 hvcNAQkQAw8wJDAUBggqhkiG9w0DBwQI0tCBcU09nxEwDAYIKwYBBQUIAQIFAIAQ 499 OsYGYUFdAH0RNc1p4VbKEAQUM2Xo8PMHBoYdqEcsbTodlCFAZH4= 500 -----END CERTIFICATE CHAIN----- 502 Figure 14: Non-standard 'CERTIFICATE CHAIN' Example 504 13. Security Considerations 506 Data in this format often originates from untrusted sources, thus 507 parsers must be prepared to handle unexpected data without causing 508 security vulnerabilities. 510 Ambiguities are introduced by having more than one canonical encoding 511 of the same data. The first ambiguity is introduced by permitting 512 the text encoded representation instead of the binary DER encoding, 513 but further ambiguities arise when multiple labels are treated as 514 similar. Variations of whitespace and non-base64 alphabetic 515 characters can create further ambiguities. Implementations that rely 516 on canonical representation or the ability to fingerprint a 517 particular data format need to understand that this Internet-Draft 518 does not define canonical encodings. If canonical encodings are 519 desired, the encoded structure must be decoded and processed into a 520 canonical form (namely, DER encoding). Data encoding ambiguities 521 also create opportunities for side channels. 523 14. IANA Considerations 525 This document implies no IANA Considerations. 527 15. Acknowledgements 529 Peter Gutmann suggested to document labels for Attribute Certificates 530 and PKCS #7 messages, and to add examples for the non-standard 531 variants. 533 16. References 534 16.1. Normative References 536 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 537 Requirement Levels", BCP 14, RFC 2119, March 1997. 539 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 540 Version 1.5", RFC 2315, March 1998. 542 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 543 Request Syntax Specification Version 1.7", RFC 2986, 544 November 2000. 546 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 547 Encodings", RFC 4648, October 2006. 549 [RFC5208] Kaliski, B., "Public-Key Cryptography Standards (PKCS) #8: 550 Private-Key Information Syntax Specification Version 1.2", 551 RFC 5208, May 2008. 553 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 554 Housley, R., and W. Polk, "Internet X.509 Public Key 555 Infrastructure Certificate and Certificate Revocation List 556 (CRL) Profile", RFC 5280, May 2008. 558 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 559 RFC 5652, September 2009. 561 [RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet 562 Attribute Certificate Profile for Authorization", 563 RFC 5755, January 2010. 565 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 566 August 2010. 568 [CCITT.X690.2002] 569 International International Telephone and Telegraph 570 Consultative Committee, "ASN.1 encoding rules: 571 Specification of basic encoding Rules (BER), Canonical 572 encoding rules (CER) and Distinguished encoding rules 573 (DER)", CCITT Recommendation X.690, July 2002. 575 16.2. Informative References 577 [RFC0934] Rose, M. and E. Stefferud, "Proposed standard for message 578 encapsulation", RFC 934, January 1985. 580 [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic 581 Mail: Part I: Message Encryption and Authentication 582 Procedures", RFC 1421, February 1993. 584 [RFC2015] Elkins, M., "MIME Security with Pretty Good Privacy 585 (PGP)", RFC 2015, October 1996. 587 [X509SG] Gutmann, P., "X.509 Style Guide", WWW http:// 588 www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt, 589 October 2000. 591 Editorial Comments 593 [DP1] S.L.: Non-alphabetic characters is too broad. 594 Characters such as "+", "/", and "=" are valid base64; 595 characters such as "-" and "_" are alternate base64 596 characters but are not used in this specification. In 597 any event, any non-whitespace characters will cause 598 existing implementations to fail. 600 [DPncfex] S.L.: The utility of this section is questionable. We 601 can shorten up the RFC by removing this section. 603 [mustshould1] S.L.: SHOULD? 605 [mustshould2] S.L.: SHOULD? 607 Authors' Addresses 609 Simon Josefsson 610 SJD AB 611 Johan Olof Wallins Vaeg 13 612 Solna 171 64 613 SE 615 Email: simon@josefsson.org 616 URI: http://josefsson.org/ 618 Sean Leonard 619 Penango, Inc. 620 1215 K Street 621 17th Floor 622 Sacramento, CA 95814 623 USA 625 Email: dev+ietf@seantek.com 626 URI: http://www.penango.com/