One document matched: draft-josefsson-pkix-textual-05.xml
<?xml version="1.0"?>
<!--
http://git.savannah.gnu.org/cgit/gnutls.git/tree/lib/gnutls_x509.h
http://bouncycastle.org/viewcvs/viewcvs.cgi/java/crypto/src/org/bouncycastle/openssl/PEMReader.java?view=markup
http://cvs.openssl.org/fileview?f=openssl/crypto/pem/pem.h
CryptBinaryToString: http://msdn.microsoft.com/aa379887
CryptStringToBinary: http://msdn.microsoft.com/aa380285
2014-07-03: updated to use verbatim (spanx verb) styling, and to use xml:space=default in key cases
it should also be emphasized that (5 dash)BEGIN etc. cannot be broken, but the - is a true hyphen, NOT a Unicode non-breaking hyphen!!!
-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC0934 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0934.xml'>
<!ENTITY rfc1421 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1421.xml'>
<!ENTITY rfc2015 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2015.xml'>
<!ENTITY rfc2119 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2986 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2986.xml'>
<!ENTITY rfc2315 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2315.xml'>
<!ENTITY rfc4648 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml'>
<!ENTITY rfc4716 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4716.xml'>
<!ENTITY RFC5208 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5208.xml'>
<!ENTITY rfc5280 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml'>
<!ENTITY RFC5652 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5652.xml'>
<!ENTITY rfc5755 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5755.xml'>
<!ENTITY RFC5958 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5958.xml'>
<!ENTITY x690 SYSTEM 'http://xml.resource.org/public/rfc/bibxml2/reference.CCITT.X690.2002.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes"?>
<rfc category="std"
docName="draft-josefsson-pkix-textual-05"
ipr="trust200902">
<front>
<title abbrev="pkix-textual">
Text Encodings of PKIX and CMS Structures
</title>
<author initials="S." surname="Josefsson" fullname="Simon Josefsson">
<organization>SJD AB</organization>
<address>
<postal>
<street>Johan Olof Wallins Väg 13</street>
<city>Solna</city>
<code>171 64</code>
<country>SE</country>
</postal>
<email>simon@josefsson.org</email>
<uri>http://josefsson.org/</uri>
</address>
</author>
<author fullname="Sean Leonard" initials="S.L." surname="Leonard">
<organization>Penango, Inc.</organization>
<address>
<postal>
<street>5900 Wilshire Boulevard</street>
<street>21st Floor</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90036</code>
<country>USA</country>
</postal>
<email>dev+ietf@seantek.com</email>
<uri>http://www.penango.com/</uri>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date day="3" month="July" year="2014"/>
<abstract>
<t>
This document describes and discusses the text encodings of
Public-Key Infrastructure using X.509 (PKIX) Certificates, PKIX
Certificate Revocation Lists (CRLs), PKCS #10 Certification
Request Syntax, PKCS #7 structures, Cryptographic Message Syntax (CMS),
PKCS #8 Private-Key Information Syntax,
and Attribute Certificates.
The text encodings are well-known, are implemented by several
applications and libraries, and are widely deployed. This
document is intended to articulate the de-facto rules that
existing implementations operate by, and to give recommendations
that will promote interoperability going forward.</t>
</abstract>
</front>
<middle>
<section anchor="intro"
title="Introduction">
<t>Several security-related standards used on the Internet
define data formats that are normally encoded using <xref
target="CCITT.X690.2002">Distinguished Encoding Rules
(DER)</xref>, which is a binary data format. This document is
about text encodings of some of these formats:</t>
<t><list style="numbers">
<t><xref target="RFC5280">Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile</xref>, for both Certificates and Certificate
Revocation Lists (CRLs).</t>
<t><xref target="RFC2986">PKCS #10: Certification Request
Syntax</xref>.</t>
<t><xref target="RFC2315">PKCS #7: Cryptographic Message
Syntax</xref>.</t>
<t><xref target="RFC5652">Cryptographic Message Syntax</xref>.
</t>
<t><xref target="RFC5208">PKCS #8:
Private-Key Information Syntax</xref> and
One Asymmetric Key (in
<xref target="RFC5958">Asymmetric Key Package</xref>).</t>
<t><xref target="RFC5755">An Internet Attribute Certificate
Profile for Authorization</xref>.</t>
</list></t>
<t>A disadvantage of a binary data
format is that it cannot be interchanged in
textual transports, such as e-mail or text documents. One
advantage with text encodings is that they are easy to modify
using common text editors; for example,
a user may concatenate several certificates to form a certificate
chain with copy-and-paste operations.</t>
<t>
The tradition within the RFC
series can be traced back to <xref target="RFC1421">PEM</xref>,
based on a proposal by
M.<!-- TODO: no double spacing! --> <!-- ok? -->Rose in
<xref target="RFC0934">Message Encapsulation</xref>.
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 <xref target="RFC2015">OpenPGP ASCII Armor</xref> and
<xref target="RFC4716">OpenSSH Key File Format</xref>.
</t>
<t>For reasons that basically boil down to non-coordination
or inattention, many PKIX and
CMS libraries implement a text encoding
that is similar to—but not identical with—PEM encoding.
This document specifies the "PKIX text encoding" format,
articulates the de-facto rules that most implementations operate by,
and provides recommendations that will promote interoperability
going forward. This document also provides common nomenclature
for syntax elements, reflecting the evolution of this de-facto standard format.
Peter Gutmann's
<xref target="X509SG">X.509 Style Guide</xref> contains a
section "base64 Encoding" that describes the formats and contains
suggestions similar to what is in this document.</t>
<t>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 <xref target="RFC2119">RFC 2119</xref>.</t>
</section>
<section anchor="general"
title="General Considerations">
<t>PKIX text encoding begins with a line starting with
<spanx style="verb">-----BEGIN </spanx> and ends with a line starting with
<spanx style="verb">-----END </spanx>.
Between these lines, or "encapsulation boundaries", are <xref
target="RFC4648">base64-encoded</xref> data. Data before the
<spanx style="verb">-----BEGIN </spanx> and after the <spanx style="verb">-----END </spanx> encapsulation boundaries
are permitted and MUST NOT cause parsers to malfunction.
Furthermore, parsers MUST ignore whitespace and other
non-base64 characters and MUST handle different newline
conventions.</t>
<t>The type of data encoded is labeled depending on the type
label in the <spanx style="verb">-----BEGIN </spanx> line (pre-encapsulation boundary).
For example, the line may be
<spanx style="verb">-----BEGIN CERTIFICATE-----</spanx> to indicate that the content is a
PKIX certificate (see further below). Generators MUST put the
same label on the <spanx style="verb">-----END </spanx> line (post-encapsulation boundary)
as the corresponding
<spanx style="verb">-----BEGIN </spanx> line. Parsers MAY disregard the label on the
<spanx style="verb">-----END </spanx> line instead of signaling an error if there is a
label mismatch.</t>
<t>
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 Internet-Draft 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 <xref target="security" format="title" /> section.
</t>
<t>Unlike <xref target="RFC1421">legacy PEM encoding</xref>,
OpenPGP ASCII armor, and the OpenSSH key file format,
PKIX text encoding does <spanx style="strong" xml:space="default">not</spanx> define or permit attributes
to be encoded alongside the PKIX or CMS data.
Whitespace MAY appear between the pre-encapsulation boundary
and the base64, but generators SHOULD NOT emit such whitespace.</t>
<t>Files MAY contain multiple PKIX text encoding instances.
This is used, for example, when a file
contains several certificates. Whether the instances are
ordered or unordered depends on the context.</t>
<t>Generators MUST wrap the base64 encoded lines so that each
line consists of exactly 64 characters except for the final
line which will encode the remainder of the data (within the 64
character line boundary). Parsers MAY handle other line
sizes. These requirements are consistent with
<xref target="RFC1421">PEM</xref>.</t>
</section>
<section anchor="abnf" title="ABNF">
<t>The ABNF of the PKIX text encoding is:</t>
<figure anchor="abnf-fig" title="ABNF">
<artwork><![CDATA[pkixmsg ::= preeb
*eolWSP
base64text
posteb
preeb ::= "-----BEGIN " label "-----" eol
posteb ::= "-----END " label "-----" eol
base64char ::= ALPHA / DIGIT / "+" / "/"
base64pad ::= "="
base64line ::= 1*base64char eol
base64finl ::= *base64char (base64pad eol base64pad /
*2base64pad) eol
; ...AB= <CRLF> = <CRLF> is not good, but is valid
base64text ::= *base64line base64finl
; we could also use <encbinbody> from RFC 1421, which requires
; 16 groups of 4 chars, which means exactly 64 chars per
; line, except the final line, but this is more accurate
labelchar ::= %x21-2C / %x2E-%7E ; any printable character,
; except hyphen
label ::= labelchar *(labelchar / labelchar "-" / SP) labelchar
eol ::= CRLF / CR / LF
eolWSP ::= WSP / CR / LF ; compare with LWSP]]></artwork></figure>
<figure anchor="abnf-strict-fig" title="ABNF (Strict)">
<artwork><![CDATA[pkixmsgstrict ::= preeb
strictbase64text
posteb
strictbase64finl ::= *15(4base64char) (4base64char / 3base64char
base64pad / 2base64char 2base64pad) eol
base64fullline ::= 64base64char eol
strictbase64text ::= *base64fullline strictbase64finl]]></artwork></figure>
<t>This specification RECOMMENDS that new implementations emit
<xref target="abnf-strict-fig">the strict format</xref> specified above.</t>
</section>
<section anchor="certificate"
title="Text Encoding of PKIX Certificates">
<section title="Encoding">
<t>PKIX certificates are encoded using the <spanx style="verb">CERTIFICATE</spanx> label.
The encoded data MUST be a DER encoded ASN.1 <spanx style="verb">Certificate</spanx>
structure as described in section 4 of <xref
target="RFC5280"/>.</t>
<figure anchor="certexample" title="Certificate Example">
<artwork>-----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-----</artwork>
</figure>
<t>Historically the label <spanx style="verb">X509 CERTIFICATE</spanx> and also, less
common, <spanx style="verb">X.509 CERTIFICATE</spanx> have been used. Generators
conforming to this document MUST generate <spanx style="verb">CERTIFICATE</spanx> labels
and MUST NOT generate <spanx style="verb">X509 CERTIFICATE</spanx> or <spanx style="verb">X.509 CERTIFICATE</spanx>
labels. Parsers are NOT RECOMMENDED to treat <spanx style="verb" xml:space="default">X509
CERTIFICATE</spanx> or <spanx style="verb">X.509 CERTIFICATE</spanx> as equivalent to
<spanx style="verb">CERTIFICATE</spanx>, but a valid exception may be for backwards
compatibility (potentially together with a warning).</t>
</section>
<section title="Explanatory Text">
<t>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.</t>
<figure anchor="certexplexample" title="Certificate Example with Explanatory Text">
<artwork><![CDATA[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-----]]></artwork></figure>
</section>
<section title="File Extension">
<t>Although text encodings of PKIX structures can occur
anywhere, many tools are known to offer an option to encode
PKIX structures in this text encoding.
To promote interoperability and to separate DER encodings
from text encodings,
<!-- TODO: should we put .crt in a verb (verbatim) spanx? -->
This Internet-Draft RECOMMENDS that the extension ".crt"
be used for this text encoding.
Implementations should be aware that in spite of this recommendation,
many tools still default to encode certificates in this text encoding
with the extension ".cer".</t>
</section>
</section>
<section anchor="crl"
title="Text Encoding of PKIX CRLs">
<t>PKIX CRLs are encoded using the <spanx style="verb">X509 CRL</spanx> label. The
encoded data MUST be a DER encoded ASN.1 <spanx style="verb">CertificateList</spanx>
structure as described in Section 5 of <xref
target="RFC5280"/>.</t>
<figure anchor="crlexample" title="CRL Example">
<artwork>-----BEGIN X509 CRL-----
MIIB9DCCAV8CAQEwCwYJKoZIhvcNAQEFMIIBCDEXMBUGA1UEChMOVmVyaVNpZ24s
IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT
PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYu
LExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEm
MCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxGDAWBgNVBAMU
D1NpbW9uIEpvc2Vmc3NvbjEiMCAGCSqGSIb3DQEJARYTc2ltb25Aam9zZWZzc29u
Lm9yZxcNMDYxMjI3MDgwMjM0WhcNMDcwMjA3MDgwMjM1WjAjMCECEC4QNwPfRoWd
elUNpllhhTgXDTA2MTIyNzA4MDIzNFowCwYJKoZIhvcNAQEFA4GBAD0zX+J2hkcc
Nbrq1Dn5IKL8nXLgPGcHv1I/le1MNo9t1ohGQxB5HnFUkRPAY82fR6Epor4aHgVy
b+5y+neKN9Kn2mPF4iiun+a4o26CjJ0pArojCL1p8T0yyi9Xxvyc/ezaZ98HiIyP
c3DGMNR+oUmSjKZ0jIhAYmeLxaPHfQwR
-----END X509 CRL-----</artwork>
</figure>
<t>Historically the label <spanx style="verb">CRL</spanx> has rarely been used. Today it is
not common and many popular tools do not understand the
label. Therefore, this document standardizes <spanx style="verb">X509 CRL</spanx>
in order to promote interoperability and backwards-compatibility.
Generators conforming to this document MUST generate
<spanx style="verb">X509 CRL</spanx> labels and MUST NOT generate
<spanx style="verb">CRL</spanx> labels. Parsers
are NOT RECOMMENDED to treat <spanx style="verb">CRL</spanx>
as equivalent to <spanx style="verb">X509 CRL</spanx>.</t>
</section>
<section anchor="crs"
title="Text Encoding of PKCS #10 Certification Request Syntax">
<t>PKCS #10 Certification Requests are encoded using the
<spanx style="verb">CERTIFICATE REQUEST</spanx> label. The encoded data MUST be a DER
encoded ASN.1 <spanx style="verb">CertificationRequest</spanx> structure as described in
<xref target="RFC2986"/>.</t>
<figure anchor="pkcs10example" title="PKCS #10 Example">
<artwork><![CDATA[-----BEGIN CERTIFICATE REQUEST-----
MIIBWDCCAQcCAQAwTjELMAkGA1UEBhMCU0UxJzAlBgNVBAoTHlNpbW9uIEpvc2Vm
c3NvbiBEYXRha29uc3VsdCBBQjEWMBQGA1UEAxMNam9zZWZzc29uLm9yZzBOMBAG
ByqGSM49AgEGBSuBBAAhAzoABLLPSkuXY0l66MbxVJ3Mot5FCFuqQfn6dTs+9/CM
EOlSwVej77tj56kj9R/j9Q+LfysX8FO9I5p3oGIwYAYJKoZIhvcNAQkOMVMwUTAY
BgNVHREEETAPgg1qb3NlZnNzb24ub3JnMAwGA1UdEwEB/wQCMAAwDwYDVR0PAQH/
BAUDAwegADAWBgNVHSUBAf8EDDAKBggrBgEFBQcDATAKBggqhkjOPQQDAgM/ADA8
AhxBvfhxPFfbBbsE1NoFmCUczOFApEuQVUw3ZP69AhwWXk3dgSUsKnuwL5g/ftAY
dEQc8B8jAcnuOrfU
-----END CERTIFICATE REQUEST-----]]></artwork>
</figure>
<t>The label <spanx style="verb">NEW CERTIFICATE REQUEST</spanx> is also in wide use.
Generators conforming to this document MUST generate
<spanx style="verb">CERTIFICATE REQUEST</spanx> labels.
Parsers MAY treat <spanx style="verb" xml:space="default">NEW
CERTIFICATE REQUEST</spanx> as equivalent to <spanx style="verb">CERTIFICATE REQUEST</spanx>.</t>
</section>
<section anchor="pkcs7"
title="Text Encoding of PKCS #7 Cryptographic Message Syntax">
<t>PKCS #7 Cryptographic Message Syntax structures are encoded
using the <spanx style="verb">PKCS7</spanx> label. The encoded data MUST be a DER
encoded ASN.1 <spanx style="verb">ContentInfo</spanx> structure as described in <xref
target="RFC2315"/>.</t>
<figure anchor="pkcs7example" title="PKCS #7 Example">
<artwork><![CDATA[-----BEGIN PKCS7-----
MIHjBgsqhkiG9w0BCRABF6CB0zCB0AIBADFho18CAQCgGwYJKoZIhvcNAQUMMA4E
CLfrI6dr0gUWAgITiDAjBgsqhkiG9w0BCRADCTAUBggqhkiG9w0DBwQIZpECRWtz
u5kEGDCjerXY8odQ7EEEromZJvAurk/j81IrozBSBgkqhkiG9w0BBwEwMwYLKoZI
hvcNAQkQAw8wJDAUBggqhkiG9w0DBwQI0tCBcU09nxEwDAYIKwYBBQUIAQIFAIAQ
OsYGYUFdAH0RNc1p4VbKEAQUM2Xo8PMHBoYdqEcsbTodlCFAZH4=
-----END PKCS7-----]]></artwork>
</figure>
<t>The label <spanx style="verb">CERTIFICATE CHAIN</spanx> has been in use to denote a
degenerative PKCS #7 structure that contains only a list of
certificates. Several modern tools do not support this label.
Generators MUST NOT generate the <spanx style="verb">CERTIFICATE CHAIN</spanx> label.
Parsers are NOT RECOMMENDED to treat <spanx style="verb">CERTIFICATE CHAIN</spanx> as
equivalent to <spanx style="verb">PKCS7</spanx>.</t>
<t>PKCS #7 is an old standard that has long been superseded
by <xref target="RFC5652" format="none">CMS</xref>.
Implementations SHOULD NOT generate PKCS #7 when CMS
is an alternative.</t>
</section>
<section anchor="cms"
title="Text Encoding of Cryptographic Message Syntax">
<t>Cryptographic Message Syntax structures are encoded using
the <spanx style="verb">CMS</spanx> label. The encoded data MUST be a DER encoded ASN.1
<spanx style="verb">ContentInfo</spanx> structure as described in <xref
target="RFC5652"/>.</t>
<figure anchor="cmsexample" title="CMS Example">
<artwork><![CDATA[-----BEGIN CMS-----
MIGDBgsqhkiG9w0BCRABCaB0MHICAQAwDQYLKoZIhvcNAQkQAwgwXgYJKoZIhvcN
AQcBoFEET3icc87PK0nNK9ENqSxItVIoSa0o0S/ISczMs1ZIzkgsKk4tsQ0N1nUM
dvb05OXi5XLPLEtViMwvLVLwSE0sKlFIVHAqSk3MBkkBAJv0Fx0=
-----END CMS-----]]></artwork>
</figure>
<t>CMS is the IETF successor to PKCS #7. Section 1.1.1
of <xref target="RFC5652" /> describes the changes since PKCS #7 v1.5. Implementations
SHOULD generate CMS when it is an alternative, promoting interoperability
and forwards-compatibility.</t>
</section>
<section anchor="pkcs8"
title="Text Encoding of PKCS #8 Private Key Info, and One Asymmetric Key">
<t>Unencrypted PKCS #8 Private Key Information Syntax structures
(<spanx style="vbare">PrivateKeyInfo</spanx>),
renamed to Asymmetric Key Packages
(<spanx style="vbare">OneAsymmetricKey</spanx>),
are encoded using the <spanx style="verb">PRIVATE KEY</spanx> label.
The encoded data MUST be a DER
encoded ASN.1 <spanx style="verb">PrivateKeyInfo</spanx> structure as described in
<xref target="RFC5208" format="none">PKCS #8</xref>,
or a <spanx style="verb">OneAsymmetricKey</spanx> structure as described in <xref
target="RFC5958"/>. The two are semantically identical, and can be distinguished
by version number.
</t>
<figure anchor="pkcs8example" title="PKCS #8 PrivateKeyInfo Example">
<artwork><![CDATA[-----BEGIN PRIVATE KEY-----
MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgVcB/UNPxalR9zDYAjQIf
jojUDiQuGnSJrFEEzZPT/92hRANCAASc7UJtgnF/abqWM60T3XNJEzBv5ez9TdwK
H0M6xpM2q+53wmsN/eYLdgtjgBd3DBmHtPilCkiFICXyaA8z9LkJ
-----END PRIVATE KEY-----]]></artwork>
</figure>
</section>
<section anchor="pkcs8enc"
title="Text Encoding of PKCS #8 Encrypted Private Key Info">
<t>Encrypted PKCS #8 Private Key Information Syntax structures
(<spanx style="vbare">EncryptedPrivateKeyInfo</spanx>),
called the same in <xref target="RFC5958" />,
are encoded using the <spanx style="verb">ENCRYPTED PRIVATE KEY</spanx> label.
The encoded data MUST be a DER
encoded ASN.1 <spanx style="verb">EncryptedPrivateKeyInfo</spanx> structure as described in
<xref target="RFC5208" format="none">PKCS #8</xref>
and <xref target="RFC5958"/>.
</t>
<figure anchor="pkcs8encexample" title="PKCS #8 EncryptedPrivateKeyInfo Example">
<artwork><![CDATA[-----BEGIN ENCRYPTED PRIVATE KEY-----
MIHNMEAGCSqGSIb3DQEFDTAzMBsGCSqGSIb3DQEFDDAOBAghhICA6T/51QICCAAw
FAYIKoZIhvcNAwcECBCxDgvI59i9BIGIY3CAqlMNBgaSI5QiiWVNJ3IpfLnEiEsW
Z0JIoHyRmKK/+cr9QPLnzxImm0TR9s4JrG3CilzTWvb0jIvbG3hu0zyFPraoMkap
8eRzWsIvC5SVel+CSjoS2mVS87cyjlD+txrmrXOVYDE+eTgMLbrLmsWh3QkCTRtF
QC7k0NNzUHTV9yGDwfqMbw==
-----END ENCRYPTED PRIVATE KEY-----]]></artwork>
</figure>
</section>
<section anchor="attrcert"
title="Text Encoding of Attribute Certificates">
<t>Attribute certificates are encoded using the <spanx style="verb" xml:space="default">ATTRIBUTE
CERTIFICATE</spanx> label. The encoded data MUST be a DER encoded
ASN.1 <spanx style="verb">AttributeCertificate</spanx> structure as described in <xref
target="RFC5755"/>.</t>
<figure anchor="attrcertexample" title="Attribute Certificate Example">
<artwork><![CDATA[-----BEGIN ATTRIBUTE CERTIFICATE-----
MIICKzCCAZQCAQEwgZeggZQwgYmkgYYwgYMxCzAJBgNVBAYTAlVTMREwDwYDVQQI
DAhOZXcgWW9yazEUMBIGA1UEBwwLU3RvbnkgQnJvb2sxDzANBgNVBAoMBkNTRTU5
MjE6MDgGA1UEAwwxU2NvdHQgU3RhbGxlci9lbWFpbEFkZHJlc3M9c3N0YWxsZXJA
aWMuc3VueXNiLmVkdQIGARWrgUUSoIGMMIGJpIGGMIGDMQswCQYDVQQGEwJVUzER
MA8GA1UECAwITmV3IFlvcmsxFDASBgNVBAcMC1N0b255IEJyb29rMQ8wDQYDVQQK
DAZDU0U1OTIxOjA4BgNVBAMMMVNjb3R0IFN0YWxsZXIvZW1haWxBZGRyZXNzPXNz
dGFsbGVyQGljLnN1bnlzYi5lZHUwDQYJKoZIhvcNAQEFBQACBgEVq4FFSjAiGA8z
OTA3MDIwMTA1MDAwMFoYDzM5MTEwMTMxMDUwMDAwWjArMCkGA1UYSDEiMCCGHmh0
dHA6Ly9pZGVyYXNobi5vcmcvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUFAAOBgQAV
M9axFPXXozEFcer06bj9MCBBCQLtAM7ZXcZjcxyva7xCBDmtZXPYUluHf5OcWPJz
5XPus/xS9wBgtlM3fldIKNyNO8RsMp6Ocx+PGlICc7zpZiGmCYLl64lAEGPO/bsw
Smluak1aZIttePeTAHeJJs8izNJ5aR3Wcd3A5gLztQ==
-----END ATTRIBUTE CERTIFICATE-----]]></artwork>
</figure>
</section>
<section anchor="security"
title="Security Considerations">
<t>Data in this format often originates from untrusted
sources, thus parsers must be prepared to handle unexpected data
without causing security vulnerabilities.</t>
<t>Ambiguities are introduced by having more than one canonical
encoding of the same data.
The first ambiguity is introduced by
permitting the text encoded representation instead of the binary
DER encoding, but further ambiguities arise when multiple labels
are treated as similar.
Variations of whitespace
and non-base64 alphabetic characters can create further
ambiguities. Implementations that rely on canonical
representation or the ability to fingerprint a particular data
format need to understand that this
Internet-Draft does not define canonical encodings.
If canonical encodings
are desired, the encoded structure must be decoded and processed
into a canonical form (namely, DER encoding).
Data encoding
ambiguities also create opportunities for side channels.</t>
</section>
<section anchor="iana"
title="IANA Considerations">
<t>This document implies no IANA Considerations.</t>
</section>
<section anchor="ack"
title="Acknowledgements">
<t>Peter Gutmann suggested to document labels for Attribute
Certificates and PKCS #7 messages, and to add examples for the
non-standard variants.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc2315;
&rfc2986;
&rfc4648;
&RFC5208;
&rfc5280;
&RFC5652;
&rfc5755;
&RFC5958;
&x690;
</references>
<references title="Informative References">
&RFC0934;
&rfc1421;
&rfc2015;
&rfc4716;
<reference anchor="X509SG">
<front>
<title>X.509 Style Guide</title>
<author initials="P." surname="Gutmann" fullname="P. Gutmann"/>
<date month="October" year="2000" />
</front>
<seriesInfo name="WWW"
value="http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt" />
</reference>
</references>
<section title="Non-Conforming Examples">
<t>This section contains examples for the non-recommended label
variants described earlier in this document. As discussed
earlier, supporting these are not required and sometimes
discouraged. Still, they can be useful for interoperability
testing and for easy reference.</t>
<figure anchor="certexample2"
title="Non-standard 'X509' Certificate Example">
<artwork>-----BEGIN X509 CERTIFICATE-----
MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G
A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y
aXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdudVRMUyBjZXJ0aWZpY2F0
ZSBhdXRob3JpdHkwHhcNMTEwNTIzMjAzODIxWhcNMTIxMjIyMDc0MTUxWjB9MQsw
CQYDVQQGEwJCRTEPMA0GA1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2Vy
dGlmaWNhdGUgYXV0aG9yaXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdu
dVRMUyBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkwWTATBgcqhkjOPQIBBggqhkjOPQMB
BwNCAARS2I0jiuNn14Y2sSALCX3IybqiIJUvxUpj+oNfzngvj/Niyv2394BWnW4X
uQ4RTEiywK87WRcWMGgJB5kX/t2no0MwQTAPBgNVHRMBAf8EBTADAQH/MA8GA1Ud
DwEB/wQFAwMHBgAwHQYDVR0OBBYEFPC0gf6YEr+1KLlkQAPLzB9mTigDMAoGCCqG
SM49BAMCA0gAMEUCIDGuwD1KPyG+hRf88MeyMQcqOFZD0TbVleF+UsAGQ4enAiEA
l4wOuDwKQa+upc8GftXE2C//4mKANBC6It01gUaTIpo=
-----END X509 CERTIFICATE-----</artwork>
</figure>
<figure anchor="certexample3"
title="Non-standard 'X.509' Certificate Example">
<artwork>-----BEGIN X.509 CERTIFICATE-----
MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G
A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y
aXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdudVRMUyBjZXJ0aWZpY2F0
ZSBhdXRob3JpdHkwHhcNMTEwNTIzMjAzODIxWhcNMTIxMjIyMDc0MTUxWjB9MQsw
CQYDVQQGEwJCRTEPMA0GA1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2Vy
dGlmaWNhdGUgYXV0aG9yaXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdu
dVRMUyBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkwWTATBgcqhkjOPQIBBggqhkjOPQMB
BwNCAARS2I0jiuNn14Y2sSALCX3IybqiIJUvxUpj+oNfzngvj/Niyv2394BWnW4X
uQ4RTEiywK87WRcWMGgJB5kX/t2no0MwQTAPBgNVHRMBAf8EBTADAQH/MA8GA1Ud
DwEB/wQFAwMHBgAwHQYDVR0OBBYEFPC0gf6YEr+1KLlkQAPLzB9mTigDMAoGCCqG
SM49BAMCA0gAMEUCIDGuwD1KPyG+hRf88MeyMQcqOFZD0TbVleF+UsAGQ4enAiEA
l4wOuDwKQa+upc8GftXE2C//4mKANBC6It01gUaTIpo=
-----END X.509 CERTIFICATE-----</artwork>
</figure>
<figure anchor="pkcs10example2"
title="Non-standard 'NEW' PKCS #10 Example">
<artwork>-----BEGIN NEW CERTIFICATE REQUEST-----
MIIBWDCCAQcCAQAwTjELMAkGA1UEBhMCU0UxJzAlBgNVBAoTHlNpbW9uIEpvc2Vm
c3NvbiBEYXRha29uc3VsdCBBQjEWMBQGA1UEAxMNam9zZWZzc29uLm9yZzBOMBAG
ByqGSM49AgEGBSuBBAAhAzoABLLPSkuXY0l66MbxVJ3Mot5FCFuqQfn6dTs+9/CM
EOlSwVej77tj56kj9R/j9Q+LfysX8FO9I5p3oGIwYAYJKoZIhvcNAQkOMVMwUTAY
BgNVHREEETAPgg1qb3NlZnNzb24ub3JnMAwGA1UdEwEB/wQCMAAwDwYDVR0PAQH/
BAUDAwegADAWBgNVHSUBAf8EDDAKBggrBgEFBQcDATAKBggqhkjOPQQDAgM/ADA8
AhxBvfhxPFfbBbsE1NoFmCUczOFApEuQVUw3ZP69AhwWXk3dgSUsKnuwL5g/ftAY
dEQc8B8jAcnuOrfU
-----END NEW CERTIFICATE REQUEST-----</artwork>
</figure>
<figure anchor="pkcs7example2"
title="Non-standard 'CERTIFICATE CHAIN' Example">
<artwork>-----BEGIN CERTIFICATE CHAIN-----
MIHjBgsqhkiG9w0BCRABF6CB0zCB0AIBADFho18CAQCgGwYJKoZIhvcNAQUMMA4E
CLfrI6dr0gUWAgITiDAjBgsqhkiG9w0BCRADCTAUBggqhkiG9w0DBwQIZpECRWtz
u5kEGDCjerXY8odQ7EEEromZJvAurk/j81IrozBSBgkqhkiG9w0BBwEwMwYLKoZI
hvcNAQkQAw8wJDAUBggqhkiG9w0DBwQI0tCBcU09nxEwDAYIKwYBBQUIAQIFAIAQ
OsYGYUFdAH0RNc1p4VbKEAQUM2Xo8PMHBoYdqEcsbTodlCFAZH4=
-----END CERTIFICATE CHAIN-----</artwork>
</figure>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 18:06:12 |