idnits 2.17.1 draft-josefsson-pkix-textual-05.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 3, 2014) is 3578 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) ** 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 (~~), 1 warning (==), 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 4, 2015 Penango, Inc. 6 July 3, 2014 8 Text Encodings of PKIX and CMS Structures 9 draft-josefsson-pkix-textual-05 11 Abstract 13 This document describes and discusses the text encodings of Public- 14 Key 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 4, 2015. 41 Copyright Notice 43 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. General Considerations . . . . . . . . . . . . . . . . . . . 3 60 3. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Text Encoding of PKIX Certificates . . . . . . . . . . . . . 6 62 4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . 8 67 7. Text Encoding of PKCS #7 Cryptographic Message Syntax . . . . 9 68 8. Text Encoding of Cryptographic Message Syntax . . . . . . . . 9 69 9. Text Encoding of PKCS #8 Private Key Info, and One Asymmetric 70 Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 10. Text Encoding of PKCS #8 Encrypted Private Key Info . . . . . 10 72 11. Text Encoding of Attribute Certificates . . . . . . . . . . . 10 73 12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 76 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 15.1. Normative References . . . . . . . . . . . . . . . . . . 12 78 15.2. Informative References . . . . . . . . . . . . . . . . . 12 79 Appendix A. Non-Conforming Examples . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 82 1. Introduction 84 Several security-related standards used on the Internet define data 85 formats that are normally encoded using Distinguished Encoding Rules 86 (DER) [CCITT.X690.2002], which is a binary data format. This 87 document is about text encodings of some of these formats: 89 1. Internet X.509 Public Key Infrastructure Certificate and 90 Certificate Revocation List (CRL) Profile [RFC5280], for both 91 Certificates and Certificate Revocation Lists (CRLs). 93 2. PKCS #10: Certification Request Syntax [RFC2986]. 95 3. PKCS #7: Cryptographic Message Syntax [RFC2315]. 97 4. Cryptographic Message Syntax [RFC5652]. 99 5. PKCS #8: Private-Key Information Syntax [RFC5208] and One 100 Asymmetric Key (in Asymmetric Key Package [RFC5958]). 102 6. An Internet Attribute Certificate Profile for Authorization 103 [RFC5755]. 105 A disadvantage of a binary data format is that it cannot be 106 interchanged in textual transports, such as e-mail or text documents. 107 One advantage with text encodings is that they are easy to modify 108 using common text editors; for example, a user may concatenate 109 several certificates to form a certificate chain with copy-and-paste 110 operations. 112 The tradition within the RFC series can be traced back to PEM 113 [RFC1421], based on a proposal by M. Rose in Message Encapsulation 114 [RFC0934]. Originally called "PEM encapsulation mechanism", 115 "encapsulated PEM message", or (arguably) "PEM printable encoding", 116 today the format is sometimes referred to as "PEM encoding". 117 Variations include OpenPGP ASCII Armor [RFC2015] and OpenSSH Key File 118 Format [RFC4716]. 120 For reasons that basically boil down to non-coordination or 121 inattention, many PKIX and CMS libraries implement a text encoding 122 that is similar to--but not identical with--PEM encoding. This 123 document specifies the "PKIX text encoding" format, articulates the 124 de-facto rules that most implementations operate by, and provides 125 recommendations that will promote interoperability going forward. 126 This document also provides common nomenclature for syntax elements, 127 reflecting the evolution of this de-facto standard format. Peter 128 Gutmann's X.509 Style Guide [X509SG] contains a section "base64 129 Encoding" that describes the formats and contains suggestions similar 130 to what is in this document. 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in RFC 135 2119 [RFC2119]. 137 2. General Considerations 139 PKIX text encoding begins with a line starting with "-----BEGIN " and 140 ends with a line starting with "-----END ". Between these lines, or 141 "encapsulation boundaries", are base64-encoded [RFC4648] data. Data 142 before the "-----BEGIN " and after the "-----END " encapsulation 143 boundaries are permitted and MUST NOT cause parsers to malfunction. 145 Furthermore, parsers MUST ignore whitespace and other non-base64 146 characters and MUST handle different newline conventions. 148 The type of data encoded is labeled depending on the type label in 149 the "-----BEGIN " line (pre-encapsulation boundary). For example, 150 the line may be "-----BEGIN CERTIFICATE-----" to indicate that the 151 content is a PKIX certificate (see further below). Generators MUST 152 put the same label on the "-----END " line (post-encapsulation 153 boundary) as the corresponding "-----BEGIN " line. Parsers MAY 154 disregard the label on the "-----END " line instead of signaling an 155 error if there is a label mismatch. 157 The label type implies that the encoded data follows the specified 158 syntax. Parsers MUST handle non-conforming data gracefully. 159 However, not all parsers or generators prior to this Internet-Draft 160 behave consistently. A conforming parser MAY interpret the contents 161 as another label type, but ought to be aware of the security 162 implications discussed in the Security Considerations section. 164 Unlike legacy PEM encoding [RFC1421], OpenPGP ASCII armor, and the 165 OpenSSH key file format, PKIX text encoding does *not* define or 166 permit attributes to be encoded alongside the PKIX or CMS data. 167 Whitespace MAY appear between the pre-encapsulation boundary and the 168 base64, but generators SHOULD NOT emit such whitespace. 170 Files MAY contain multiple PKIX text encoding instances. This is 171 used, for example, when a file contains several certificates. 172 Whether the instances are ordered or unordered depends on the 173 context. 175 Generators MUST wrap the base64 encoded lines so that each line 176 consists of exactly 64 characters except for the final line which 177 will encode the remainder of the data (within the 64 character line 178 boundary). Parsers MAY handle other line sizes. These requirements 179 are consistent with PEM [RFC1421]. 181 3. ABNF 183 The ABNF of the PKIX text encoding is: 185 pkixmsg ::= preeb 186 *eolWSP 187 base64text 188 posteb 190 preeb ::= "-----BEGIN " label "-----" eol 192 posteb ::= "-----END " label "-----" eol 194 base64char ::= ALPHA / DIGIT / "+" / "/" 196 base64pad ::= "=" 198 base64line ::= 1*base64char eol 200 base64finl ::= *base64char (base64pad eol base64pad / 201 *2base64pad) eol 202 ; ...AB= = is not good, but is valid 204 base64text ::= *base64line base64finl 205 ; we could also use from RFC 1421, which requires 206 ; 16 groups of 4 chars, which means exactly 64 chars per 207 ; line, except the final line, but this is more accurate 209 labelchar ::= %x21-2C / %x2E-%7E ; any printable character, 210 ; except hyphen 212 label ::= labelchar *(labelchar / labelchar "-" / SP) labelchar 214 eol ::= CRLF / CR / LF 216 eolWSP ::= WSP / CR / LF ; compare with LWSP 218 Figure 1: ABNF 220 pkixmsgstrict ::= preeb 221 strictbase64text 222 posteb 224 strictbase64finl ::= *15(4base64char) (4base64char / 3base64char 225 base64pad / 2base64char 2base64pad) eol 227 base64fullline ::= 64base64char eol 229 strictbase64text ::= *base64fullline strictbase64finl 231 Figure 2: ABNF (Strict) 233 This specification RECOMMENDS that new implementations emit the 234 strict format (Figure 2) specified above. 236 4. Text Encoding of PKIX Certificates 238 4.1. Encoding 240 PKIX certificates are encoded using the "CERTIFICATE" label. The 241 encoded data MUST be a DER encoded ASN.1 "Certificate" structure as 242 described in section 4 of [RFC5280]. 244 -----BEGIN CERTIFICATE----- 245 MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G 246 A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y 247 aXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdudVRMUyBjZXJ0aWZpY2F0 248 ZSBhdXRob3JpdHkwHhcNMTEwNTIzMjAzODIxWhcNMTIxMjIyMDc0MTUxWjB9MQsw 249 CQYDVQQGEwJCRTEPMA0GA1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2Vy 250 dGlmaWNhdGUgYXV0aG9yaXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdu 251 dVRMUyBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkwWTATBgcqhkjOPQIBBggqhkjOPQMB 252 BwNCAARS2I0jiuNn14Y2sSALCX3IybqiIJUvxUpj+oNfzngvj/Niyv2394BWnW4X 253 uQ4RTEiywK87WRcWMGgJB5kX/t2no0MwQTAPBgNVHRMBAf8EBTADAQH/MA8GA1Ud 254 DwEB/wQFAwMHBgAwHQYDVR0OBBYEFPC0gf6YEr+1KLlkQAPLzB9mTigDMAoGCCqG 255 SM49BAMCA0gAMEUCIDGuwD1KPyG+hRf88MeyMQcqOFZD0TbVleF+UsAGQ4enAiEA 256 l4wOuDwKQa+upc8GftXE2C//4mKANBC6It01gUaTIpo= 257 -----END CERTIFICATE----- 259 Figure 3: Certificate Example 261 Historically the label "X509 CERTIFICATE" and also, less common, 262 "X.509 CERTIFICATE" have been used. Generators conforming to this 263 document MUST generate "CERTIFICATE" labels and MUST NOT generate 264 "X509 CERTIFICATE" or "X.509 CERTIFICATE" labels. Parsers are NOT 265 RECOMMENDED to treat "X509 CERTIFICATE" or "X.509 CERTIFICATE" as 266 equivalent to "CERTIFICATE", but a valid exception may be for 267 backwards compatibility (potentially together with a warning). 269 4.2. Explanatory Text 271 Many tools are known to emit explanatory text before the BEGIN and 272 after the END lines for PKIX certificates, more than any other type. 273 If emitted, such text SHOULD be related to the certificate, such as 274 providing a textual representation of key data elements in the 275 certificate. 277 Subject: CN=Atlantis 278 Issuer: CN=Atlantis 279 Validity: from 7/9/2012 3:10:38 AM UTC to 7/9/2013 3:10:37 AM UTC 280 -----BEGIN CERTIFICATE----- 281 MIIBmTCCAUegAwIBAgIBKjAJBgUrDgMCHQUAMBMxETAPBgNVBAMTCEF0bGFudGlz 282 MB4XDTEyMDcwOTAzMTAzOFoXDTEzMDcwOTAzMTAzN1owEzERMA8GA1UEAxMIQXRs 283 YW50aXMwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAu+BXo+miabDIHHx+yquqzqNh 284 Ryn/XtkJIIHVcYtHvIX+S1x5ErgMoHehycpoxbErZmVR4GCq1S2diNmRFZCRtQID 285 AQABo4GJMIGGMAwGA1UdEwEB/wQCMAAwIAYDVR0EAQH/BBYwFDAOMAwGCisGAQQB 286 gjcCARUDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDAzA1BgNVHQEE 287 LjAsgBA0jOnSSuIHYmnVryHAdywMoRUwEzERMA8GA1UEAxMIQXRsYW50aXOCASow 288 CQYFKw4DAh0FAANBAKi6HRBaNEL5R0n56nvfclQNaXiDT174uf+lojzA4lhVInc0 289 ILwpnZ1izL4MlI9eCSHhVQBHEp2uQdXJB+d5Byg= 290 -----END CERTIFICATE----- 292 Figure 4: Certificate Example with Explanatory Text 294 4.3. File Extension 296 Although text encodings of PKIX structures can occur anywhere, many 297 tools are known to offer an option to encode PKIX structures in this 298 text encoding. To promote interoperability and to separate DER 299 encodings from text encodings, This Internet-Draft RECOMMENDS that 300 the extension ".crt" be used for this text encoding. Implementations 301 should be aware that in spite of this recommendation, many tools 302 still default to encode certificates in this text encoding with the 303 extension ".cer". 305 5. Text Encoding of PKIX CRLs 307 PKIX CRLs are encoded using the "X509 CRL" label. The encoded data 308 MUST be a DER encoded ASN.1 "CertificateList" structure as described 309 in Section 5 of [RFC5280]. 311 -----BEGIN X509 CRL----- 312 MIIB9DCCAV8CAQEwCwYJKoZIhvcNAQEFMIIBCDEXMBUGA1UEChMOVmVyaVNpZ24s 313 IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT 314 PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYu 315 LExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEm 316 MCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxGDAWBgNVBAMU 317 D1NpbW9uIEpvc2Vmc3NvbjEiMCAGCSqGSIb3DQEJARYTc2ltb25Aam9zZWZzc29u 318 Lm9yZxcNMDYxMjI3MDgwMjM0WhcNMDcwMjA3MDgwMjM1WjAjMCECEC4QNwPfRoWd 319 elUNpllhhTgXDTA2MTIyNzA4MDIzNFowCwYJKoZIhvcNAQEFA4GBAD0zX+J2hkcc 320 Nbrq1Dn5IKL8nXLgPGcHv1I/le1MNo9t1ohGQxB5HnFUkRPAY82fR6Epor4aHgVy 321 b+5y+neKN9Kn2mPF4iiun+a4o26CjJ0pArojCL1p8T0yyi9Xxvyc/ezaZ98HiIyP 322 c3DGMNR+oUmSjKZ0jIhAYmeLxaPHfQwR 323 -----END X509 CRL----- 325 Figure 5: CRL Example 327 Historically the label "CRL" has rarely been used. Today it is not 328 common and many popular tools do not understand the label. 329 Therefore, this document standardizes "X509 CRL" in order to promote 330 interoperability and backwards-compatibility. Generators conforming 331 to this document MUST generate "X509 CRL" labels and MUST NOT 332 generate "CRL" labels. Parsers are NOT RECOMMENDED to treat "CRL" as 333 equivalent to "X509 CRL". 335 6. Text Encoding of PKCS #10 Certification Request Syntax 337 PKCS #10 Certification Requests are encoded using the "CERTIFICATE 338 REQUEST" label. The encoded data MUST be a DER encoded ASN.1 339 "CertificationRequest" structure as described in [RFC2986]. 341 -----BEGIN CERTIFICATE REQUEST----- 342 MIIBWDCCAQcCAQAwTjELMAkGA1UEBhMCU0UxJzAlBgNVBAoTHlNpbW9uIEpvc2Vm 343 c3NvbiBEYXRha29uc3VsdCBBQjEWMBQGA1UEAxMNam9zZWZzc29uLm9yZzBOMBAG 344 ByqGSM49AgEGBSuBBAAhAzoABLLPSkuXY0l66MbxVJ3Mot5FCFuqQfn6dTs+9/CM 345 EOlSwVej77tj56kj9R/j9Q+LfysX8FO9I5p3oGIwYAYJKoZIhvcNAQkOMVMwUTAY 346 BgNVHREEETAPgg1qb3NlZnNzb24ub3JnMAwGA1UdEwEB/wQCMAAwDwYDVR0PAQH/ 347 BAUDAwegADAWBgNVHSUBAf8EDDAKBggrBgEFBQcDATAKBggqhkjOPQQDAgM/ADA8 348 AhxBvfhxPFfbBbsE1NoFmCUczOFApEuQVUw3ZP69AhwWXk3dgSUsKnuwL5g/ftAY 349 dEQc8B8jAcnuOrfU 350 -----END CERTIFICATE REQUEST----- 352 Figure 6: PKCS #10 Example 354 The label "NEW CERTIFICATE REQUEST" is also in wide use. Generators 355 conforming to this document MUST generate "CERTIFICATE REQUEST" 356 labels. Parsers MAY treat "NEW CERTIFICATE REQUEST" as equivalent to 357 "CERTIFICATE REQUEST". 359 7. Text Encoding of PKCS #7 Cryptographic Message Syntax 361 PKCS #7 Cryptographic Message Syntax structures are encoded using the 362 "PKCS7" label. The encoded data MUST be a DER encoded ASN.1 363 "ContentInfo" structure as described in [RFC2315]. 365 -----BEGIN PKCS7----- 366 MIHjBgsqhkiG9w0BCRABF6CB0zCB0AIBADFho18CAQCgGwYJKoZIhvcNAQUMMA4E 367 CLfrI6dr0gUWAgITiDAjBgsqhkiG9w0BCRADCTAUBggqhkiG9w0DBwQIZpECRWtz 368 u5kEGDCjerXY8odQ7EEEromZJvAurk/j81IrozBSBgkqhkiG9w0BBwEwMwYLKoZI 369 hvcNAQkQAw8wJDAUBggqhkiG9w0DBwQI0tCBcU09nxEwDAYIKwYBBQUIAQIFAIAQ 370 OsYGYUFdAH0RNc1p4VbKEAQUM2Xo8PMHBoYdqEcsbTodlCFAZH4= 371 -----END PKCS7----- 373 Figure 7: PKCS #7 Example 375 The label "CERTIFICATE CHAIN" has been in use to denote a 376 degenerative PKCS #7 structure that contains only a list of 377 certificates. Several modern tools do not support this label. 378 Generators MUST NOT generate the "CERTIFICATE CHAIN" label. Parsers 379 are NOT RECOMMENDED to treat "CERTIFICATE CHAIN" as equivalent to 380 "PKCS7". 382 PKCS #7 is an old standard that has long been superseded by CMS. 383 Implementations SHOULD NOT generate PKCS #7 when CMS is an 384 alternative. 386 8. Text Encoding of Cryptographic Message Syntax 388 Cryptographic Message Syntax structures are encoded using the "CMS" 389 label. The encoded data MUST be a DER encoded ASN.1 "ContentInfo" 390 structure as described in [RFC5652]. 392 -----BEGIN CMS----- 393 MIGDBgsqhkiG9w0BCRABCaB0MHICAQAwDQYLKoZIhvcNAQkQAwgwXgYJKoZIhvcN 394 AQcBoFEET3icc87PK0nNK9ENqSxItVIoSa0o0S/ISczMs1ZIzkgsKk4tsQ0N1nUM 395 dvb05OXi5XLPLEtViMwvLVLwSE0sKlFIVHAqSk3MBkkBAJv0Fx0= 396 -----END CMS----- 398 Figure 8: CMS Example 400 CMS is the IETF successor to PKCS #7. Section 1.1.1 of [RFC5652] 401 describes the changes since PKCS #7 v1.5. Implementations SHOULD 402 generate CMS when it is an alternative, promoting interoperability 403 and forwards-compatibility. 405 9. Text Encoding of PKCS #8 Private Key Info, and One Asymmetric Key 407 Unencrypted PKCS #8 Private Key Information Syntax structures 408 (PrivateKeyInfo), renamed to Asymmetric Key Packages 409 (OneAsymmetricKey), are encoded using the "PRIVATE KEY" label. The 410 encoded data MUST be a DER encoded ASN.1 "PrivateKeyInfo" structure 411 as described in PKCS #8, or a "OneAsymmetricKey" structure as 412 described in [RFC5958]. The two are semantically identical, and can 413 be distinguished by version number. 415 -----BEGIN PRIVATE KEY----- 416 MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgVcB/UNPxalR9zDYAjQIf 417 jojUDiQuGnSJrFEEzZPT/92hRANCAASc7UJtgnF/abqWM60T3XNJEzBv5ez9TdwK 418 H0M6xpM2q+53wmsN/eYLdgtjgBd3DBmHtPilCkiFICXyaA8z9LkJ 419 -----END PRIVATE KEY----- 421 Figure 9: PKCS #8 PrivateKeyInfo Example 423 10. Text Encoding of PKCS #8 Encrypted Private Key Info 425 Encrypted PKCS #8 Private Key Information Syntax structures 426 (EncryptedPrivateKeyInfo), called the same in [RFC5958], are encoded 427 using the "ENCRYPTED PRIVATE KEY" label. The encoded data MUST be a 428 DER encoded ASN.1 "EncryptedPrivateKeyInfo" structure as described in 429 PKCS #8 and [RFC5958]. 431 -----BEGIN ENCRYPTED PRIVATE KEY----- 432 MIHNMEAGCSqGSIb3DQEFDTAzMBsGCSqGSIb3DQEFDDAOBAghhICA6T/51QICCAAw 433 FAYIKoZIhvcNAwcECBCxDgvI59i9BIGIY3CAqlMNBgaSI5QiiWVNJ3IpfLnEiEsW 434 Z0JIoHyRmKK/+cr9QPLnzxImm0TR9s4JrG3CilzTWvb0jIvbG3hu0zyFPraoMkap 435 8eRzWsIvC5SVel+CSjoS2mVS87cyjlD+txrmrXOVYDE+eTgMLbrLmsWh3QkCTRtF 436 QC7k0NNzUHTV9yGDwfqMbw== 437 -----END ENCRYPTED PRIVATE KEY----- 439 Figure 10: PKCS #8 EncryptedPrivateKeyInfo Example 441 11. Text Encoding of Attribute Certificates 443 Attribute certificates are encoded using the "ATTRIBUTE CERTIFICATE" 444 label. The encoded data MUST be a DER encoded ASN.1 445 "AttributeCertificate" structure as described in [RFC5755]. 447 -----BEGIN ATTRIBUTE CERTIFICATE----- 448 MIICKzCCAZQCAQEwgZeggZQwgYmkgYYwgYMxCzAJBgNVBAYTAlVTMREwDwYDVQQI 449 DAhOZXcgWW9yazEUMBIGA1UEBwwLU3RvbnkgQnJvb2sxDzANBgNVBAoMBkNTRTU5 450 MjE6MDgGA1UEAwwxU2NvdHQgU3RhbGxlci9lbWFpbEFkZHJlc3M9c3N0YWxsZXJA 451 aWMuc3VueXNiLmVkdQIGARWrgUUSoIGMMIGJpIGGMIGDMQswCQYDVQQGEwJVUzER 452 MA8GA1UECAwITmV3IFlvcmsxFDASBgNVBAcMC1N0b255IEJyb29rMQ8wDQYDVQQK 453 DAZDU0U1OTIxOjA4BgNVBAMMMVNjb3R0IFN0YWxsZXIvZW1haWxBZGRyZXNzPXNz 454 dGFsbGVyQGljLnN1bnlzYi5lZHUwDQYJKoZIhvcNAQEFBQACBgEVq4FFSjAiGA8z 455 OTA3MDIwMTA1MDAwMFoYDzM5MTEwMTMxMDUwMDAwWjArMCkGA1UYSDEiMCCGHmh0 456 dHA6Ly9pZGVyYXNobi5vcmcvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUFAAOBgQAV 457 M9axFPXXozEFcer06bj9MCBBCQLtAM7ZXcZjcxyva7xCBDmtZXPYUluHf5OcWPJz 458 5XPus/xS9wBgtlM3fldIKNyNO8RsMp6Ocx+PGlICc7zpZiGmCYLl64lAEGPO/bsw 459 Smluak1aZIttePeTAHeJJs8izNJ5aR3Wcd3A5gLztQ== 460 -----END ATTRIBUTE CERTIFICATE----- 462 Figure 11: Attribute Certificate Example 464 12. Security Considerations 466 Data in this format often originates from untrusted sources, thus 467 parsers must be prepared to handle unexpected data without causing 468 security vulnerabilities. 470 Ambiguities are introduced by having more than one canonical encoding 471 of the same data. The first ambiguity is introduced by permitting 472 the text encoded representation instead of the binary DER encoding, 473 but further ambiguities arise when multiple labels are treated as 474 similar. Variations of whitespace and non-base64 alphabetic 475 characters can create further ambiguities. Implementations that rely 476 on canonical representation or the ability to fingerprint a 477 particular data format need to understand that this Internet-Draft 478 does not define canonical encodings. If canonical encodings are 479 desired, the encoded structure must be decoded and processed into a 480 canonical form (namely, DER encoding). Data encoding ambiguities 481 also create opportunities for side channels. 483 13. IANA Considerations 485 This document implies no IANA Considerations. 487 14. Acknowledgements 489 Peter Gutmann suggested to document labels for Attribute Certificates 490 and PKCS #7 messages, and to add examples for the non-standard 491 variants. 493 15. References 495 15.1. Normative References 497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 498 Requirement Levels", BCP 14, RFC 2119, March 1997. 500 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 501 Version 1.5", RFC 2315, March 1998. 503 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 504 Request Syntax Specification Version 1.7", RFC 2986, 505 November 2000. 507 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 508 Encodings", RFC 4648, October 2006. 510 [RFC5208] Kaliski, B., "Public-Key Cryptography Standards (PKCS) #8: 511 Private-Key Information Syntax Specification Version 1.2", 512 RFC 5208, May 2008. 514 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 515 Housley, R., and W. Polk, "Internet X.509 Public Key 516 Infrastructure Certificate and Certificate Revocation List 517 (CRL) Profile", RFC 5280, May 2008. 519 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 520 RFC 5652, September 2009. 522 [RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet 523 Attribute Certificate Profile for Authorization", RFC 524 5755, January 2010. 526 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 527 2010. 529 [CCITT.X690.2002] 530 International Telephone and Telegraph Consultative 531 Committee, "ASN.1 encoding rules: Specification of basic 532 encoding Rules (BER), Canonical encoding rules (CER) and 533 Distinguished encoding rules (DER)", CCITT Recommendation 534 X.690, July 2002. 536 15.2. Informative References 538 [RFC0934] Rose, M. and E. Stefferud, "Proposed standard for message 539 encapsulation", RFC 934, January 1985. 541 [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic 542 Mail: Part I: Message Encryption and Authentication 543 Procedures", RFC 1421, February 1993. 545 [RFC2015] Elkins, M., "MIME Security with Pretty Good Privacy 546 (PGP)", RFC 2015, October 1996. 548 [RFC4716] Galbraith, J. and R. Thayer, "The Secure Shell (SSH) 549 Public Key File Format", RFC 4716, November 2006. 551 [X509SG] Gutmann, P., "X.509 Style Guide", WWW 552 http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt, 553 October 2000. 555 Appendix A. Non-Conforming Examples 557 This section contains examples for the non-recommended label variants 558 described earlier in this document. As discussed earlier, supporting 559 these are not required and sometimes discouraged. Still, they can be 560 useful for interoperability testing and for easy reference. 562 -----BEGIN X509 CERTIFICATE----- 563 MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G 564 A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y 565 aXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdudVRMUyBjZXJ0aWZpY2F0 566 ZSBhdXRob3JpdHkwHhcNMTEwNTIzMjAzODIxWhcNMTIxMjIyMDc0MTUxWjB9MQsw 567 CQYDVQQGEwJCRTEPMA0GA1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2Vy 568 dGlmaWNhdGUgYXV0aG9yaXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdu 569 dVRMUyBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkwWTATBgcqhkjOPQIBBggqhkjOPQMB 570 BwNCAARS2I0jiuNn14Y2sSALCX3IybqiIJUvxUpj+oNfzngvj/Niyv2394BWnW4X 571 uQ4RTEiywK87WRcWMGgJB5kX/t2no0MwQTAPBgNVHRMBAf8EBTADAQH/MA8GA1Ud 572 DwEB/wQFAwMHBgAwHQYDVR0OBBYEFPC0gf6YEr+1KLlkQAPLzB9mTigDMAoGCCqG 573 SM49BAMCA0gAMEUCIDGuwD1KPyG+hRf88MeyMQcqOFZD0TbVleF+UsAGQ4enAiEA 574 l4wOuDwKQa+upc8GftXE2C//4mKANBC6It01gUaTIpo= 575 -----END X509 CERTIFICATE----- 577 Figure 12: Non-standard 'X509' Certificate Example 579 -----BEGIN X.509 CERTIFICATE----- 580 MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G 581 A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y 582 aXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdudVRMUyBjZXJ0aWZpY2F0 583 ZSBhdXRob3JpdHkwHhcNMTEwNTIzMjAzODIxWhcNMTIxMjIyMDc0MTUxWjB9MQsw 584 CQYDVQQGEwJCRTEPMA0GA1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2Vy 585 dGlmaWNhdGUgYXV0aG9yaXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdu 586 dVRMUyBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkwWTATBgcqhkjOPQIBBggqhkjOPQMB 587 BwNCAARS2I0jiuNn14Y2sSALCX3IybqiIJUvxUpj+oNfzngvj/Niyv2394BWnW4X 588 uQ4RTEiywK87WRcWMGgJB5kX/t2no0MwQTAPBgNVHRMBAf8EBTADAQH/MA8GA1Ud 589 DwEB/wQFAwMHBgAwHQYDVR0OBBYEFPC0gf6YEr+1KLlkQAPLzB9mTigDMAoGCCqG 590 SM49BAMCA0gAMEUCIDGuwD1KPyG+hRf88MeyMQcqOFZD0TbVleF+UsAGQ4enAiEA 591 l4wOuDwKQa+upc8GftXE2C//4mKANBC6It01gUaTIpo= 592 -----END X.509 CERTIFICATE----- 594 Figure 13: Non-standard 'X.509' Certificate Example 596 -----BEGIN NEW CERTIFICATE REQUEST----- 597 MIIBWDCCAQcCAQAwTjELMAkGA1UEBhMCU0UxJzAlBgNVBAoTHlNpbW9uIEpvc2Vm 598 c3NvbiBEYXRha29uc3VsdCBBQjEWMBQGA1UEAxMNam9zZWZzc29uLm9yZzBOMBAG 599 ByqGSM49AgEGBSuBBAAhAzoABLLPSkuXY0l66MbxVJ3Mot5FCFuqQfn6dTs+9/CM 600 EOlSwVej77tj56kj9R/j9Q+LfysX8FO9I5p3oGIwYAYJKoZIhvcNAQkOMVMwUTAY 601 BgNVHREEETAPgg1qb3NlZnNzb24ub3JnMAwGA1UdEwEB/wQCMAAwDwYDVR0PAQH/ 602 BAUDAwegADAWBgNVHSUBAf8EDDAKBggrBgEFBQcDATAKBggqhkjOPQQDAgM/ADA8 603 AhxBvfhxPFfbBbsE1NoFmCUczOFApEuQVUw3ZP69AhwWXk3dgSUsKnuwL5g/ftAY 604 dEQc8B8jAcnuOrfU 605 -----END NEW CERTIFICATE REQUEST----- 607 Figure 14: Non-standard 'NEW' PKCS #10 Example 609 -----BEGIN CERTIFICATE CHAIN----- 610 MIHjBgsqhkiG9w0BCRABF6CB0zCB0AIBADFho18CAQCgGwYJKoZIhvcNAQUMMA4E 611 CLfrI6dr0gUWAgITiDAjBgsqhkiG9w0BCRADCTAUBggqhkiG9w0DBwQIZpECRWtz 612 u5kEGDCjerXY8odQ7EEEromZJvAurk/j81IrozBSBgkqhkiG9w0BBwEwMwYLKoZI 613 hvcNAQkQAw8wJDAUBggqhkiG9w0DBwQI0tCBcU09nxEwDAYIKwYBBQUIAQIFAIAQ 614 OsYGYUFdAH0RNc1p4VbKEAQUM2Xo8PMHBoYdqEcsbTodlCFAZH4= 615 -----END CERTIFICATE CHAIN----- 617 Figure 15: Non-standard 'CERTIFICATE CHAIN' Example 619 Authors' Addresses 620 Simon Josefsson 621 SJD AB 622 Johan Olof Wallins Vaeg 13 623 Solna 171 64 624 SE 626 Email: simon@josefsson.org 627 URI: http://josefsson.org/ 629 Sean Leonard 630 Penango, Inc. 631 5900 Wilshire Boulevard 632 21st Floor 633 Los Angeles, CA 90036 634 USA 636 Email: dev+ietf@seantek.com 637 URI: http://www.penango.com/