idnits 2.17.1 draft-josefsson-pkix-textual-00.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 (January 27, 2012) is 4470 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: Informational January 27, 2012 5 Expires: July 30, 2012 7 Text Encodings of Some Security Related Structures 8 draft-josefsson-pkix-textual-00 10 Abstract 12 This document describe and discuss the text encodings of Public-Key 13 Infrastructure using X.509 (PKIX) Certificates, PKIX Certificate 14 Revocation Lists (CRLs), PKCS #10 Certificate Request Syntax, PKCS #7 15 structures, and Attribute Certificates. The text encodings are well- 16 known, implemented by several applications and libraries, and is 17 widely deployed. This document is intended to articulate the de- 18 facto rules that existing implementations operate by, and to give 19 recommendations that will promote interoperability going forward. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 30, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. General Considerations . . . . . . . . . . . . . . . . . . . . 3 57 3. Text Encoding of PKIX Certificate . . . . . . . . . . . . . . 4 58 4. Text Encoding of PKIX CRLs . . . . . . . . . . . . . . . . . . 5 59 5. Text Encoding of PKCS #10 Certification Request Syntax . . . . 5 60 6. Text Encoding of PKCS #7 Cryptographic Message Syntax . . . . 6 61 7. Text Encoding of Attribute Certificates . . . . . . . . . . . 6 62 8. Non-comforming Examples . . . . . . . . . . . . . . . . . . . 7 63 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 66 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 68 12.2. Informative References . . . . . . . . . . . . . . . . . 10 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 Several security-related standards used on the Internet define data 74 formats that are normally encoded using Distinguished Encoding Rules 75 (DER) [CCITT.X690.2002], which is a binary data format. This 76 document is about text encodings of some of these formats. In 77 particular, we describe text encodings for the following formats. 79 1. Internet X.509 Public Key Infrastructure Certificate and 80 Certificate Revocation List (CRL) Profile [RFC5280], for both 81 Certificates and Certificate Revocation Lists (CRLs). 82 2. PKCS #10: Certification Request Syntax [RFC2986]. 83 3. PKCS #7: Cryptographic Message Syntax [RFC2315]. 84 4. An Internet Attribute Certificate Profile for Authorization 85 [RFC5755]. 87 One motivation for a text encoding is that a binary data format has 88 the disadvantage that it cannot be interchanged in textual 89 transports, such as e-mail or text documents. One advantage with 90 text encodings is that they are easy to modify without special- 91 purpose tools; for example, using a text editor you may concatenate 92 several certificates to form a certificate chain. 94 The exact history of the text encodings are unknown to the author of 95 this document, however the tradition within the RFC series can be 96 traced back to PEM [RFC1421] and OpenPGP [RFC2015]. These text 97 encodings are sometimes referred to as "PEM encodings". Peter 98 Gutmann's X.509 Style Guide [X509SG] contains a section "base64 99 Encoding" that describe the formats and contains suggestions similar 100 to what is in this document. 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in RFC 105 2119 [RFC2119]. 107 2. General Considerations 109 The structure of a text encoding is such that they begin with a line 110 starting with "-----BEGIN" and end with a line starting with 111 "-----END". Between these markers are Base64 [RFC4648] encoded data. 112 Data before the "-----BEGIN" and after the "-----END" marker are 113 permitted and MUST NOT cause parsers to malfunction. Further, 114 parsers MUST ignore whitespace and other non-alphabetic characters 115 and MUST handle different newline conventions. 117 The type of data encoded is labeled depending on the type label in 118 the "-----BEGIN" line. For example, the line may be "-----BEGIN 119 CERTIFICATE-----" to indicate that the content is a PKIX Certificate 120 (see further below). Generators MUST put the same label on the 121 "-----END" line as the corresponding "-----BEGIN" line. Parses MAY 122 disregard the label on the "-----END" lines instead of signalling an 123 error if there is a label mismatch. 125 The label type is not a guarantee that the encoded data follows the 126 implied syntax. Parsers MUST handle non-conforming data gracefully. 128 Files MAY contain multiple instances of the text encoded 129 representation. This is used, for example, when a file contains 130 several certificates. Whether the instances are ordered or unordered 131 depends on the context. 133 Generators MUST wrap the base64 encoded lines so that each line 134 consists of exactly 64 characters except for the final line which 135 will encode as much data is left (within the 64 character line 136 boundary). Parser MAY handle other line sizes. 138 3. Text Encoding of PKIX Certificate 140 PKIX Certificates are encoded using the "CERTIFICATE" label. The 141 encoded data MUST be a DER encoded ASN.1 "Certificate" structure as 142 described in section 4 of [RFC5280]. 144 -----BEGIN CERTIFICATE----- 145 MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G 146 A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y 147 aXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdudVRMUyBjZXJ0aWZpY2F0 148 ZSBhdXRob3JpdHkwHhcNMTEwNTIzMjAzODIxWhcNMTIxMjIyMDc0MTUxWjB9MQsw 149 CQYDVQQGEwJCRTEPMA0GA1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2Vy 150 dGlmaWNhdGUgYXV0aG9yaXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdu 151 dVRMUyBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkwWTATBgcqhkjOPQIBBggqhkjOPQMB 152 BwNCAARS2I0jiuNn14Y2sSALCX3IybqiIJUvxUpj+oNfzngvj/Niyv2394BWnW4X 153 uQ4RTEiywK87WRcWMGgJB5kX/t2no0MwQTAPBgNVHRMBAf8EBTADAQH/MA8GA1Ud 154 DwEB/wQFAwMHBgAwHQYDVR0OBBYEFPC0gf6YEr+1KLlkQAPLzB9mTigDMAoGCCqG 155 SM49BAMCA0gAMEUCIDGuwD1KPyG+hRf88MeyMQcqOFZD0TbVleF+UsAGQ4enAiEA 156 l4wOuDwKQa+upc8GftXE2C//4mKANBC6It01gUaTIpo= 157 -----END CERTIFICATE----- 159 Figure 1: Certificate Example 161 Historically the label "X509 CERTIFICATE" and also, less common, 162 "X.509 CERTIFICATE" have been used. Generators conforming to this 163 document MUST generate "CERTIFICATE" labels and MUST NOT generate 164 "X509 CERTIFICATE" or "X.509 CERTIFICATE" labels. Parsers are NOT 165 RECOMMENDED to treat "X509 CERTIFICATE" or "X.509 CERTIFICATE" as 166 equivalent to "CERTIFICATE", but a valid exception may be for 167 backwards compatibility (potentially together with a warning). 169 4. Text Encoding of PKIX CRLs 171 PKIX CRLs are encoded using the "X509 CRL" label. The encoded data 172 MUST be a DER encoded ASN.1 "CertificateList" structure as described 173 in section 5 of [RFC5280]. 175 -----BEGIN X509 CRL----- 176 MIIB9DCCAV8CAQEwCwYJKoZIhvcNAQEFMIIBCDEXMBUGA1UEChMOVmVyaVNpZ24s 177 IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT 178 PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYu 179 LExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEm 180 MCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxGDAWBgNVBAMU 181 D1NpbW9uIEpvc2Vmc3NvbjEiMCAGCSqGSIb3DQEJARYTc2ltb25Aam9zZWZzc29u 182 Lm9yZxcNMDYxMjI3MDgwMjM0WhcNMDcwMjA3MDgwMjM1WjAjMCECEC4QNwPfRoWd 183 elUNpllhhTgXDTA2MTIyNzA4MDIzNFowCwYJKoZIhvcNAQEFA4GBAD0zX+J2hkcc 184 Nbrq1Dn5IKL8nXLgPGcHv1I/le1MNo9t1ohGQxB5HnFUkRPAY82fR6Epor4aHgVy 185 b+5y+neKN9Kn2mPF4iiun+a4o26CjJ0pArojCL1p8T0yyi9Xxvyc/ezaZ98HiIyP 186 c3DGMNR+oUmSjKZ0jIhAYmeLxaPHfQwR 187 -----END X509 CRL----- 189 Figure 2: CRL Example 191 Historically the label "CRL" have been used, but today it is not 192 common and several popular tools do not understand the label. 193 Generators conforming to this document MUST generate "X509 CRL" 194 labels and MUST NOT generate "CRL" labels. Parsers are NOT 195 RECOMMENDED to treat "CRL" as equivalent to "X509 CRL". 197 5. Text Encoding of PKCS #10 Certification Request Syntax 199 PKCS #10 Certification Requests are encoded using the "CERTIFICATE 200 REQUEST" label. The encoded data MUST be a DER encoded ASN.1 201 "CertificationRequest" structure as described in [RFC2986]. 203 -----BEGIN CERTIFICATE REQUEST----- 204 MIIBWDCCAQcCAQAwTjELMAkGA1UEBhMCU0UxJzAlBgNVBAoTHlNpbW9uIEpvc2Vm 205 c3NvbiBEYXRha29uc3VsdCBBQjEWMBQGA1UEAxMNam9zZWZzc29uLm9yZzBOMBAG 206 ByqGSM49AgEGBSuBBAAhAzoABLLPSkuXY0l66MbxVJ3Mot5FCFuqQfn6dTs+9/CM 207 EOlSwVej77tj56kj9R/j9Q+LfysX8FO9I5p3oGIwYAYJKoZIhvcNAQkOMVMwUTAY 208 BgNVHREEETAPgg1qb3NlZnNzb24ub3JnMAwGA1UdEwEB/wQCMAAwDwYDVR0PAQH/ 209 BAUDAwegADAWBgNVHSUBAf8EDDAKBggrBgEFBQcDATAKBggqhkjOPQQDAgM/ADA8 210 AhxBvfhxPFfbBbsE1NoFmCUczOFApEuQVUw3ZP69AhwWXk3dgSUsKnuwL5g/ftAY 211 dEQc8B8jAcnuOrfU 212 -----END CERTIFICATE REQUEST----- 214 Figure 3: PKCS #10 Example 216 The label "NEW CERTIFICATE REQUEST" is also in wide use. Generators 217 conforming to this document MUST generate "CERTIFICATE REQUEST" 218 labels. Parsers MAY treat "NEW CERTIFICATE REQUEST" as equivalent to 219 "CERTIFICATE REQUEST". 221 6. Text Encoding of PKCS #7 Cryptographic Message Syntax 223 PKCS #7 Cryptographic Message Syntax structures are encoded using the 224 "PKCS7" label. The encoded data MUST be a DER encoded ASN.1 225 "ContentInfo" structure as described in [RFC2315]. 227 -----BEGIN PKCS7----- 228 MIHjBgsqhkiG9w0BCRABF6CB0zCB0AIBADFho18CAQCgGwYJKoZIhvcNAQUMMA4E 229 CLfrI6dr0gUWAgITiDAjBgsqhkiG9w0BCRADCTAUBggqhkiG9w0DBwQIZpECRWtz 230 u5kEGDCjerXY8odQ7EEEromZJvAurk/j81IrozBSBgkqhkiG9w0BBwEwMwYLKoZI 231 hvcNAQkQAw8wJDAUBggqhkiG9w0DBwQI0tCBcU09nxEwDAYIKwYBBQUIAQIFAIAQ 232 OsYGYUFdAH0RNc1p4VbKEAQUM2Xo8PMHBoYdqEcsbTodlCFAZH4= 233 -----END PKCS7----- 235 Figure 4: PKCS #7 Example 237 The label "CERTIFICATE CHAIN" has been in use to denote a 238 degenerative PKCS #7 structure that contains only a list of 239 certificates. Several modern tools do not support this label. 240 Generators MUST NOT generate the "CERTIFICATE CHAIN" label. Parsers 241 are NOT RECOMMENDED to treat "CERTIFICATE CHAIN" as equivalent to 242 "PKCS7". 244 7. Text Encoding of Attribute Certificates 246 Attribute certificates are encoded using the "ATTRIBUTE CERTIFICATES" 247 label. The encoded data MUST be a DER encoded ASN.1 248 "AttributeCertificate" structure as described in [RFC5755]. 250 -----BEGIN ATTRIBUTE CERTIFICATE----- 251 MIICKzCCAZQCAQEwgZeggZQwgYmkgYYwgYMxCzAJBgNVBAYTAlVTMREwDwYDVQQI 252 DAhOZXcgWW9yazEUMBIGA1UEBwwLU3RvbnkgQnJvb2sxDzANBgNVBAoMBkNTRTU5 253 MjE6MDgGA1UEAwwxU2NvdHQgU3RhbGxlci9lbWFpbEFkZHJlc3M9c3N0YWxsZXJA 254 aWMuc3VueXNiLmVkdQIGARWrgUUSoIGMMIGJpIGGMIGDMQswCQYDVQQGEwJVUzER 255 MA8GA1UECAwITmV3IFlvcmsxFDASBgNVBAcMC1N0b255IEJyb29rMQ8wDQYDVQQK 256 DAZDU0U1OTIxOjA4BgNVBAMMMVNjb3R0IFN0YWxsZXIvZW1haWxBZGRyZXNzPXNz 257 dGFsbGVyQGljLnN1bnlzYi5lZHUwDQYJKoZIhvcNAQEFBQACBgEVq4FFSjAiGA8z 258 OTA3MDIwMTA1MDAwMFoYDzM5MTEwMTMxMDUwMDAwWjArMCkGA1UYSDEiMCCGHmh0 259 dHA6Ly9pZGVyYXNobi5vcmcvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUFAAOBgQAV 260 M9axFPXXozEFcer06bj9MCBBCQLtAM7ZXcZjcxyva7xCBDmtZXPYUluHf5OcWPJz 261 5XPus/xS9wBgtlM3fldIKNyNO8RsMp6Ocx+PGlICc7zpZiGmCYLl64lAEGPO/bsw 262 Smluak1aZIttePeTAHeJJs8izNJ5aR3Wcd3A5gLztQ== 263 -----END ATTRIBUTE CERTIFICATE----- 265 Figure 5: Attribute Certificate Example 267 8. Non-comforming Examples 269 This section contains examples for the non-recommended label variants 270 described earlier in this document. As discussed earlier, supporting 271 these are not required and sometimes discouraged. Still, they can be 272 useful for interoperability testing and for easy reference. 274 -----BEGIN X509 CERTIFICATE----- 275 MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G 276 A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y 277 aXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdudVRMUyBjZXJ0aWZpY2F0 278 ZSBhdXRob3JpdHkwHhcNMTEwNTIzMjAzODIxWhcNMTIxMjIyMDc0MTUxWjB9MQsw 279 CQYDVQQGEwJCRTEPMA0GA1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2Vy 280 dGlmaWNhdGUgYXV0aG9yaXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdu 281 dVRMUyBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkwWTATBgcqhkjOPQIBBggqhkjOPQMB 282 BwNCAARS2I0jiuNn14Y2sSALCX3IybqiIJUvxUpj+oNfzngvj/Niyv2394BWnW4X 283 uQ4RTEiywK87WRcWMGgJB5kX/t2no0MwQTAPBgNVHRMBAf8EBTADAQH/MA8GA1Ud 284 DwEB/wQFAwMHBgAwHQYDVR0OBBYEFPC0gf6YEr+1KLlkQAPLzB9mTigDMAoGCCqG 285 SM49BAMCA0gAMEUCIDGuwD1KPyG+hRf88MeyMQcqOFZD0TbVleF+UsAGQ4enAiEA 286 l4wOuDwKQa+upc8GftXE2C//4mKANBC6It01gUaTIpo= 287 -----END X509 CERTIFICATE----- 289 Figure 6: Non-standard 'X509' Certificate Example 291 -----BEGIN X.509 CERTIFICATE----- 292 MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G 293 A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y 294 aXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdudVRMUyBjZXJ0aWZpY2F0 295 ZSBhdXRob3JpdHkwHhcNMTEwNTIzMjAzODIxWhcNMTIxMjIyMDc0MTUxWjB9MQsw 296 CQYDVQQGEwJCRTEPMA0GA1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2Vy 297 dGlmaWNhdGUgYXV0aG9yaXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdu 298 dVRMUyBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkwWTATBgcqhkjOPQIBBggqhkjOPQMB 299 BwNCAARS2I0jiuNn14Y2sSALCX3IybqiIJUvxUpj+oNfzngvj/Niyv2394BWnW4X 300 uQ4RTEiywK87WRcWMGgJB5kX/t2no0MwQTAPBgNVHRMBAf8EBTADAQH/MA8GA1Ud 301 DwEB/wQFAwMHBgAwHQYDVR0OBBYEFPC0gf6YEr+1KLlkQAPLzB9mTigDMAoGCCqG 302 SM49BAMCA0gAMEUCIDGuwD1KPyG+hRf88MeyMQcqOFZD0TbVleF+UsAGQ4enAiEA 303 l4wOuDwKQa+upc8GftXE2C//4mKANBC6It01gUaTIpo= 304 -----END X.509 CERTIFICATE----- 306 Figure 7: Non-standard 'X.509' Certificate Example 308 -----BEGIN NEW CERTIFICATE REQUEST----- 309 MIIBWDCCAQcCAQAwTjELMAkGA1UEBhMCU0UxJzAlBgNVBAoTHlNpbW9uIEpvc2Vm 310 c3NvbiBEYXRha29uc3VsdCBBQjEWMBQGA1UEAxMNam9zZWZzc29uLm9yZzBOMBAG 311 ByqGSM49AgEGBSuBBAAhAzoABLLPSkuXY0l66MbxVJ3Mot5FCFuqQfn6dTs+9/CM 312 EOlSwVej77tj56kj9R/j9Q+LfysX8FO9I5p3oGIwYAYJKoZIhvcNAQkOMVMwUTAY 313 BgNVHREEETAPgg1qb3NlZnNzb24ub3JnMAwGA1UdEwEB/wQCMAAwDwYDVR0PAQH/ 314 BAUDAwegADAWBgNVHSUBAf8EDDAKBggrBgEFBQcDATAKBggqhkjOPQQDAgM/ADA8 315 AhxBvfhxPFfbBbsE1NoFmCUczOFApEuQVUw3ZP69AhwWXk3dgSUsKnuwL5g/ftAY 316 dEQc8B8jAcnuOrfU 317 -----END NEW CERTIFICATE REQUEST----- 319 Figure 8: Non-standard 'NEW' PKCS #10 Example 321 -----BEGIN CERTIFICATE CHAIN----- 322 MIHjBgsqhkiG9w0BCRABF6CB0zCB0AIBADFho18CAQCgGwYJKoZIhvcNAQUMMA4E 323 CLfrI6dr0gUWAgITiDAjBgsqhkiG9w0BCRADCTAUBggqhkiG9w0DBwQIZpECRWtz 324 u5kEGDCjerXY8odQ7EEEromZJvAurk/j81IrozBSBgkqhkiG9w0BBwEwMwYLKoZI 325 hvcNAQkQAw8wJDAUBggqhkiG9w0DBwQI0tCBcU09nxEwDAYIKwYBBQUIAQIFAIAQ 326 OsYGYUFdAH0RNc1p4VbKEAQUM2Xo8PMHBoYdqEcsbTodlCFAZH4= 327 -----END CERTIFICATE CHAIN----- 329 Figure 9: Non-standard 'CERTIFICATE CHAIN' Example 331 9. Security Considerations 333 Data in this format is often originating from untrusted sources, thus 334 parsers must be prepared to handle unexpected data without causing 335 security vulnerabilities. 337 By having more than one canonical encoding of the same data, an 338 ambiguity is introduced. The first one is introduced by permitting 339 the text encoded representation instead of the binary DER encoding, 340 but further ambiguities arise when multiple labels are treated as 341 similar. Even further, variations of whitespace and non-base64 342 alphabetic characters can further create ambiguities. 343 Implementations that rely on canonical representation or the ability 344 to fingerprint a particular data format will need to take this into 345 account. Data encoding ambiguities also create opportunities for 346 side channels. 348 10. IANA Considerations 350 This document implies no IANA Considerations. 352 11. Acknowledgements 354 Peter Gutmann suggested to document labels for Attribute Certificates 355 and PKCS #7 messages, and to add examples for the non-standard 356 variants. 358 12. References 360 12.1. Normative References 362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 363 Requirement Levels", BCP 14, RFC 2119, March 1997. 365 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 366 Version 1.5", RFC 2315, March 1998. 368 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 369 Request Syntax Specification Version 1.7", RFC 2986, 370 November 2000. 372 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 373 Encodings", RFC 4648, October 2006. 375 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 376 Housley, R., and W. Polk, "Internet X.509 Public Key 377 Infrastructure Certificate and Certificate Revocation List 378 (CRL) Profile", RFC 5280, May 2008. 380 [RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet 381 Attribute Certificate Profile for Authorization", 382 RFC 5755, January 2010. 384 [CCITT.X690.2002] 385 International International Telephone and Telegraph 386 Consultative Committee, "ASN.1 encoding rules: 387 Specification of basic encoding Rules (BER), Canonical 388 encoding rules (CER) and Distinguished encoding rules 389 (DER)", CCITT Recommendation X.690, July 2002. 391 12.2. Informative References 393 [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic 394 Mail: Part I: Message Encryption and Authentication 395 Procedures", RFC 1421, February 1993. 397 [RFC2015] Elkins, M., "MIME Security with Pretty Good Privacy 398 (PGP)", RFC 2015, October 1996. 400 [X509SG] Gutmann, P., "X.509 Style Guide", WWW http:// 401 www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt. 403 Author's Address 405 Simon Josefsson 406 SJD AB 407 Johan Olof Wallins Vaeg 13 408 Solna 171 64 409 SE 411 Email: simon@josefsson.org 412 URI: http://josefsson.org/