One document matched: draft-josefsson-pkix-textual-01.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
-->
<!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 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-01"
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>1215 K Street</street>
<street>17th Floor</street>
<city>Sacramento</city>
<region>CA</region>
<code>95814</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 month="July" year="2012"/>
<abstract>
<t>
This document describes and discuss 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. 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 OpenPGP ASCII Armor and
OpenSSH Key File Format.
</t>
<t>For reasons that basically boil down to non-coordination
(or gross inattention), many PKIX and
CMS libraries implement a text encoding
that is similar to--but not identical with--PEM encoding.
This Internet-Draft calls this format "PKIX text encoding",
articulates the de-facto rules that most implementations operate by,
and provides recommendations that will promote interoperability
going forward.
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 "-----BEGIN" and ends with a line
starting with "-----END". Between these lines,
or "encapsulation boundaries",
are <xref
target="RFC4648">base64</xref>-encoded data. Data before the
"-----BEGIN" and after the "-----END"
encapsulation boundaries
are permitted and
MUST NOT cause parsers to malfunction. Furthermore, parsers MUST
ignore whitespace and other non-alphabetic characters
<cref anchor="DP1" source="S.L.">Non-alphabetic
characters is too broad. Characters such as "+", "/", and "=" are valid
base64; characters such as "-" and "_" are alternate base64 characters
but are not used in this specification. In any event,
any non-whitespace characters will cause
existing implementations to fail.</cref>
and MUST
handle different newline conventions.</t>
<t>The type of data encoded is labeled depending on the type
label in the "-----BEGIN" line (pre-encapsulation boundary).
For example, the line may be
"-----BEGIN CERTIFICATE-----" to indicate that the content is a
PKIX certificate (see further below). Generators MUST put the
same label on the "-----END" line (post-encapsulation boundary)
as the corresponding
"-----BEGIN" line. Parsers MAY disregard the label on the
"-----END" 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 PEM encoding, OpenPGP ASCII armor, and OpenSSH key file format,
PKIX text encoding does NOT 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 instances of the text encoded
representation. 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 as much data is left (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 *2base64pad eol ; implies that:
; ...AB= <CRLF> = <CRLF>
; is invalid. not sure
; if this is a good idea
base64text ::= *base64line base64finl
; we could also use <encbinbody> from RFC 1421,
; which requires 16 groups of 4 chars, which means 64 chars
; exactly per line, except the final line
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>
</section>
<section anchor="certificate"
title="Text Encoding of PKIX Certificates">
<section title="Encoding">
<t>PKIX certificates are encoded using the "CERTIFICATE" label.
The encoded data MUST be a DER encoded ASN.1 "Certificate"
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 "X509 CERTIFICATE" and also, less
common, "X.509 CERTIFICATE" have been used. Generators
conforming to this document MUST generate "CERTIFICATE" labels
and MUST NOT generate "X509 CERTIFICATE" or "X.509 CERTIFICATE"
labels. Parsers are NOT RECOMMENDED to treat "X509
CERTIFICATE" or "X.509 CERTIFICATE" as equivalent to
"CERTIFICATE", 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 labels 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,
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 "X509 CRL" label. The
encoded data MUST be a DER encoded ASN.1 "CertificateList"
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 "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
are NOT RECOMMENDED to treat "CRL" as equivalent to "X509
CRL".</t>
</section>
<section anchor="crs"
title="Text Encoding of PKCS #10 Certification Request Syntax">
<t>PKCS #10 Certification Requests are encoded using the
"CERTIFICATE REQUEST" label. The encoded data MUST be a DER
encoded ASN.1 "CertificationRequest" 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 "NEW CERTIFICATE REQUEST" is also in wide use.
Generators conforming to this document MUST generate
"CERTIFICATE REQUEST" labels. Parsers MAY treat "NEW
CERTIFICATE REQUEST" as equivalent to "CERTIFICATE REQUEST".</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 "PKCS7" label. The encoded data
MUST<cref anchor="mustshould1" source="S.L.">SHOULD?</cref>
be a DER
encoded ASN.1 "ContentInfo" 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 "CERTIFICATE CHAIN" 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 "CERTIFICATE CHAIN" label.
Parsers are NOT RECOMMENDED to treat "CERTIFICATE CHAIN" as
equivalent to "PKCS7".</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 "CMS" label. The encoded data
MUST<cref anchor="mustshould2" source="S.L.">SHOULD?</cref>
be a DER
encoded ASN.1 "ContentInfo" 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 RFC 5652 describes the changes since PKCS #7 v1.5. Implementations
SHOULD generate CMS when it is an alternative, promoting ineroperability
and forwards-compatibility.</t>
</section>
<section anchor="pkcs8"
title="Text Encoding of PKCS #8 Private Key Info, and One Asymmetric Key">
<t>
The PrivateKeyInfo structure of PKCS #8 Private Key Information Syntax,
renamed to OneAsymmetricKey in <xref target="RFC5958" />,
is encoded using the "PRIVATE KEY" label.
The encoded data SHOULD be a DER
encoded ASN.1 "PrivateKeyInfo" structure as described in
<xref target="RFC5208" format="none">PKCS #8</xref>,
or the "OneAsymmetricKey" 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>
The EncryptedPrivateKeyInfo structure of PKCS #8 Private Key Information Syntax,
called the same in <xref target="RFC5958" />,
is encoded using the "ENCRYPTED PRIVATE KEY" label.
The encoded data SHOULD be a DER
encoded ASN.1 "EncryptedPrivateKeyInfo" 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 "ATTRIBUTE
CERTIFICATE" label. The encoded data MUST be a DER encoded
ASN.1 "AttributeCertificate" 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 title="Non-Conforming Examples">
<t>
<cref anchor="DPncfex" source="S.L.">The utility of this section is questionable.
We can shorten up the RFC by removing this section.</cref>
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>
<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;
<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>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 18:02:54 |