One document matched: draft-josefsson-pkix-textual-00.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!--
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
-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1421 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1421.xml'>
<!ENTITY rfc2015 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2015.xml'>
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2986 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2986.xml'>
<!ENTITY rfc2315 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2315.xml'>
<!ENTITY rfc4648 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml'>
<!ENTITY rfc5280 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml'>
<!ENTITY rfc5755 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5755.xml'>
<!ENTITY x690 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml2/reference.CCITT.X690.2002.xml'>
]>
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<rfc category="info"
docName="draft-josefsson-pkix-textual-00"
ipr="trust200902">
<front>
<title abbrev="Security-Related Text Encodings">
Text Encodings of Some Security Related 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>
<date month="January" year="2012"/>
<abstract>
<t>This document describe and discuss the text encodings of
Public-Key Infrastructure using X.509 (PKIX) Certificates, PKIX
Certificate Revocation Lists (CRLs), PKCS #10 Certificate
Request Syntax, PKCS #7 structures, and Attribute Certificates.
The text encodings are well-known, implemented by several
applications and libraries, and is 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. In particular,
we describe text encodings for the following 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="RFC5755">An Internet Attribute Certificate
Profile for Authorization</xref>.</t>
</list></t>
<t>One motivation for a text encoding is that a binary data
format has the disadvantage 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
without special-purpose tools; for example, using a text editor
you may concatenate several certificates to form a certificate
chain.</t>
<t>The exact history of the text encodings are unknown to the
author of this document, however the tradition within the RFC
series can be traced back to <xref target="RFC1421">PEM</xref>
and <xref target="RFC2015">OpenPGP</xref>. These text encodings
are sometimes referred to as "PEM encodings". Peter Gutmann's
<xref target="X509SG">X.509 Style Guide</xref> contains a
section "base64 Encoding" that describe 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>The structure of a text encoding is such that they begin
with a line starting with "-----BEGIN" and end with a line
starting with "-----END". Between these markers are <xref
target="RFC4648">Base64</xref> encoded data. Data before the
"-----BEGIN" and after the "-----END" marker are permitted and
MUST NOT cause parsers to malfunction. Further, parsers MUST
ignore whitespace and other non-alphabetic characters and MUST
handle different newline conventions.</t>
<t>The type of data encoded is labeled depending on the type
label in the "-----BEGIN" line. 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 as the corresponding
"-----BEGIN" line. Parses MAY disregard the label on the
"-----END" lines instead of signalling an error if there is a
label mismatch.</t>
<t>The label type is not a guarantee that the encoded data
follows the implied syntax. Parsers MUST handle non-conforming
data gracefully.</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). Parser MAY handle other line
sizes.</t>
</section>
<section anchor="certificate"
title="Text Encoding of PKIX Certificate">
<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 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" have been used, but today it is
not common and several popular tools do not understand the
label. 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>
-----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="cms"
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 be a DER
encoded ASN.1 "ContentInfo" structure as described in <xref
target="RFC2315"/>.</t>
<figure anchor="pkcs7example" title="PKCS #7 Example">
<artwork>
-----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>
</section>
<section anchor="attrcert"
title="Text Encoding of Attribute Certificates">
<t>Attribute certificates are encoded using the "ATTRIBUTE
CERTIFICATES" 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>
-----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-comforming 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>
<section anchor="security"
title="Security Considerations">
<t>Data in this format is often originating from untrusted
sources, thus parsers must be prepared to handle unexpected data
without causing security vulnerabilities.</t>
<t>By having more than one canonical encoding of the same data,
an ambiguity is introduced. The first one 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. Even further, variations of whitespace
and non-base64 alphabetic characters can further create
ambiguities. Implementations that rely on canonical
representation or the ability to fingerprint a particular data
format will need to take this into account. 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;
&rfc5280;
&rfc5755;
&x690;
</references>
<references title="Informative References">
&rfc1421;
&rfc2015;
<reference anchor="X509SG">
<front>
<title>X.509 Style Guide</title>
<author initials="P." surname="Gutmann" fullname="P. Gutmann"/>
</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:17:36 |