Professional Documents
Culture Documents
Josefsson
Request for Comments: 7468 SJD AB
Category: Standards Track S. Leonard
ISSN: 2070-1721 Penango, Inc.
April 2015
Abstract
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. General Considerations . . . . . . . . . . . . . . . . . . . 3
3. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Textual Encoding of Certificates . . . . . . . . . . . . . . 8
5.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Explanatory Text . . . . . . . . . . . . . . . . . . . . 9
5.3. File Extension . . . . . . . . . . . . . . . . . . . . . 9
6. Textual Encoding of Certificate Revocation Lists . . . . . . 10
7. Textual Encoding of PKCS #10 Certification Request Syntax . . 11
8. Textual Encoding of PKCS #7 Cryptographic Message Syntax . . 11
9. Textual Encoding of Cryptographic Message Syntax . . . . . . 12
10. One Asymmetric Key and the Textual Encoding of PKCS #8
Private Key Info . . . . . . . . . . . . . . . . . . . . . . 12
11. Textual Encoding of PKCS #8 Encrypted Private Key Info . . . 13
12. Textual Encoding of Attribute Certificates . . . . . . . . . 13
13. Textual Encoding of Subject Public Key Info . . . . . . . . . 14
14. Security Considerations . . . . . . . . . . . . . . . . . . . 14
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
15.1. Normative References . . . . . . . . . . . . . . . . . . 14
15.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Non-conforming Examples . . . . . . . . . . . . . . 17
Appendix B. DER Expectations . . . . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
The tradition within the RFC series can be traced back to Privacy-
Enhanced Mail (PEM) [RFC1421], based on a proposal by Marshall Rose
in Message Encapsulation [RFC934]. Originally called "PEM
encapsulation mechanism", "encapsulated PEM message", or (arguably)
"PEM printable encoding", today the format is sometimes referred to
as "PEM encoding". Variations include OpenPGP ASCII armor [RFC4880]
and OpenSSH key file format [RFC4716].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].
2. General Considerations
The label type implies that the encoded data follows the specified
syntax. Parsers MUST handle non-conforming data gracefully.
However, not all parsers or generators prior to this document behave
consistently. A conforming parser MAY interpret the contents as
another label type but ought to be aware of the security implications
discussed in the Security Considerations section. The labels
described in this document identify container formats that are not
specific to any particular cryptographic algorithm, a property
consistent with algorithm agility. These formats use the ASN.1
AlgorithmIdentifier structure as described in Section 4.1.1.2 of
[RFC5280].
Unlike legacy PEM encoding [RFC1421], OpenPGP ASCII armor, and the
OpenSSH key file format, textual encoding does *not* define or permit
headers to be encoded alongside the data. Empty space can appear
between the pre-encapsulation boundary and the base64, but generators
SHOULD NOT emit such any such spacing. (The provision for this empty
area is a throwback to PEM, which defined an "encapsulated header
portion".)
(0x0D), and LF (0x0A); "blank" means HT and SP; lines are divided
with CRLF, CR, or LF. The common ABNF production WSP is congruent
with "blank"; a new production W is used for "whitespace". The ABNF
in Section 3 is specific to US-ASCII. As these textual encodings can
be used on many different systems as well as on long-term archival
storage media such as paper or engravings, an implementer ought to
use the spirit rather than the letter of the rules when generating or
parsing these formats in environments that are not strictly limited
to US-ASCII.
Most extant parsers ignore blanks at the ends of lines; blanks at the
beginnings of lines or in the middle of the base64-encoded data are
far less compatible. These observations are codified in Figure 1.
The most lax parser implementations are not line-oriented at all and
will accept any mixture of whitespace outside of the encapsulation
boundaries (see Figure 2). Such lax parsing may run the risk of
accepting text that was not intended to be accepted in the first
place (e.g., because the text was a snippet or sample).
3. ABNF
base64pad = "="
eol = CRLF / CR / LF
laxtextualmsg = *W preeb
laxbase64text
posteb *W
4. Guide
-----------------------------------------------------------------------
id-pkixmod OBJECT IDENTIFIER ::= {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0)}
id-pkix1-e OBJECT IDENTIFIER ::= {id-pkixmod pkix1-explicit(18)}
id-acv2 OBJECT IDENTIFIER ::= {id-pkixmod mod-attribute-cert-v2(61)}
id-pkcs OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1)}
id-pkcs10 OBJECT IDENTIFIER ::= {id-pkcs 10 modules(1) pkcs-10(1)}
id-pkcs7 OBJECT IDENTIFIER ::= {id-pkcs 7 modules(0) pkcs-7(1)}
id-pkcs8 OBJECT IDENTIFIER ::= {id-pkcs 8 modules(1) pkcs-8(1)}
id-sm-mod OBJECT IDENTIFIER ::= {id-pkcs 9 smime(16) modules(0)}
id-aKPV1 OBJECT IDENTIFIER ::= {id-sm-mod mod-asymmetricKeyPkgV1(50)}
id-cms2004 OBJECT IDENTIFIER ::= {id-sm-mod cms-2004(24)}
5.1. Encoding
-----BEGIN CERTIFICATE-----
MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G
A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y
aXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdudVRMUyBjZXJ0aWZpY2F0
ZSBhdXRob3JpdHkwHhcNMTEwNTIzMjAzODIxWhcNMTIxMjIyMDc0MTUxWjB9MQsw
CQYDVQQGEwJCRTEPMA0GA1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2Vy
dGlmaWNhdGUgYXV0aG9yaXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdu
dVRMUyBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkwWTATBgcqhkjOPQIBBggqhkjOPQMB
BwNCAARS2I0jiuNn14Y2sSALCX3IybqiIJUvxUpj+oNfzngvj/Niyv2394BWnW4X
uQ4RTEiywK87WRcWMGgJB5kX/t2no0MwQTAPBgNVHRMBAf8EBTADAQH/MA8GA1Ud
DwEB/wQFAwMHBgAwHQYDVR0OBBYEFPC0gf6YEr+1KLlkQAPLzB9mTigDMAoGCCqG
SM49BAMCA0gAMEUCIDGuwD1KPyG+hRf88MeyMQcqOFZD0TbVleF+UsAGQ4enAiEA
l4wOuDwKQa+upc8GftXE2C//4mKANBC6It01gUaTIpo=
-----END CERTIFICATE-----
Many tools are known to emit explanatory text before the BEGIN and
after the END lines for PKIX certificates, more than any other type.
If emitted, such text SHOULD be related to the certificate, such as
providing a textual representation of key data elements in the
certificate.
Subject: CN=Atlantis
Issuer: CN=Atlantis
Validity: from 7/9/2012 3:10:38 AM UTC to 7/9/2013 3:10:37 AM UTC
-----BEGIN CERTIFICATE-----
MIIBmTCCAUegAwIBAgIBKjAJBgUrDgMCHQUAMBMxETAPBgNVBAMTCEF0bGFudGlz
MB4XDTEyMDcwOTAzMTAzOFoXDTEzMDcwOTAzMTAzN1owEzERMA8GA1UEAxMIQXRs
YW50aXMwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAu+BXo+miabDIHHx+yquqzqNh
Ryn/XtkJIIHVcYtHvIX+S1x5ErgMoHehycpoxbErZmVR4GCq1S2diNmRFZCRtQID
AQABo4GJMIGGMAwGA1UdEwEB/wQCMAAwIAYDVR0EAQH/BBYwFDAOMAwGCisGAQQB
gjcCARUDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDAzA1BgNVHQEE
LjAsgBA0jOnSSuIHYmnVryHAdywMoRUwEzERMA8GA1UEAxMIQXRsYW50aXOCASow
CQYFKw4DAh0FAANBAKi6HRBaNEL5R0n56nvfclQNaXiDT174uf+lojzA4lhVInc0
ILwpnZ1izL4MlI9eCSHhVQBHEp2uQdXJB+d5Byg=
-----END CERTIFICATE-----
Certificate Revocation Lists (CRLs) are encoded using the "X509 CRL"
label. The encoded data MUST be a BER (DER strongly preferred; see
Appendix B) encoded ASN.1 CertificateList structure as described in
Section 5 of [RFC5280].
Historically, the label "CRL" has rarely been used. Today, it is not
common and many popular tools do not understand the label.
Therefore, this document standardizes "X509 CRL" in order to promote
interoperability and backwards-compatibility. Generators conforming
to this document MUST generate "X509 CRL" labels and MUST NOT
generate "CRL" labels. Parsers SHOULD NOT treat "CRL" as equivalent
to "X509 CRL".
-----BEGIN PKCS7-----
MIHjBgsqhkiG9w0BCRABF6CB0zCB0AIBADFho18CAQCgGwYJKoZIhvcNAQUMMA4E
CLfrI6dr0gUWAgITiDAjBgsqhkiG9w0BCRADCTAUBggqhkiG9w0DBwQIZpECRWtz
u5kEGDCjerXY8odQ7EEEromZJvAurk/j81IrozBSBgkqhkiG9w0BBwEwMwYLKoZI
hvcNAQkQAw8wJDAUBggqhkiG9w0DBwQI0tCBcU09nxEwDAYIKwYBBQUIAQIFAIAQ
OsYGYUFdAH0RNc1p4VbKEAQUM2Xo8PMHBoYdqEcsbTodlCFAZH4=
-----END PKCS7-----
-----BEGIN CMS-----
MIGDBgsqhkiG9w0BCRABCaB0MHICAQAwDQYLKoZIhvcNAQkQAwgwXgYJKoZIhvcN
AQcBoFEET3icc87PK0nNK9ENqSxItVIoSa0o0S/ISczMs1ZIzkgsKk4tsQ0N1nUM
dvb05OXi5XLPLEtViMwvLVLwSE0sKlFIVHAqSk3MBkkBAJv0Fx0=
-----END CMS-----
10. One Asymmetric Key and the Textual Encoding of PKCS #8 Private Key
Info
Public keys are encoded using the "PUBLIC KEY" label. The encoded
data MUST be a BER (DER preferred; see Appendix B) encoded ASN.1
SubjectPublicKeyInfo structure as described in Section 4.1.2.7 of
[RFC5280].
15. References
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, November 2007,
<http://www.rfc-editor.org/info/rfc4880>.
[RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A.,
and M. Scott, "PKCS #12: Personal Information Exchange
Syntax v1.1", RFC 7292, July 2014,
<http://www.rfc-editor.org/info/rfc7292>.
Acknowledgements
Authors’ Addresses
Simon Josefsson
SJD AB
Johan Olof Wallins Vaeg 13
Solna 171 64
Sweden
EMail: simon@josefsson.org
URI: http://josefsson.org/
Sean Leonard
Penango, Inc.
5900 Wilshire Boulevard
21st Floor
Los Angeles, CA 90036
United States
EMail: dev+ietf@seantek.com
URI: http://www.penango.com/