One document matched: draft-miller-jose-pkix-key-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<rfc category="std" docName="draft-miller-jose-pkix-key-01" ipr="trust200902">
<front>
<title abbrev="JWK for PKIX">JavaScript Object Notation (JSON) Web Key (JWK) for Public Key Infrastructure (X.509) (PKIX) Certificates</title>
<author initials="M." surname="Miller" fullname="Matthew Miller">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<phone>+1-303-308-3204</phone>
<email>mamille2@cisco.com</email>
</address>
</author>
<author initials="B." surname="Campbell" fullname="Brian Campbell">
<organization>Ping Identity Corp.</organization>
<address>
<email>brian.d.campbell@gmail.com</email>
</address>
</author>
<date month="February" day="21" year="2013"/>
<area>Security</area>
<workgroup>JOSE Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document defines a JavaScript Object Notation (JSON) Web Key (JWK) object to wrap Public Key Infrastructure (X.509) (PKIX) certificate chains, to allow for some interoperability between existing PKIX-based systems and newer JOSE-based systems.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>JavaScript Object Notation (JSON) Web Key (<xref target="JWK"/>) describes an abstract data structure to represent public keys using JSON <xref target="RFC4627"/>. The JSON Web Algorithms (<xref target="JWA"/>) define specific key representations for raw asymmetric key types, such as RSA <xref target="RFC3447"/> or Elliptic Curve <xref target="DSS"/>. However, there are times when it is desirable to represent a Public Key Infrastructure (X.509) (PKIX) certificate chain, such as to associate with a JSON Web Encryption (<xref target="JWE"/>) or JSON Web Signature (<xref target="JWS"/>) object. This document specifies an approach which encodes a chain of PKIX certificates as an array of strings within a JWK object.</t>
<t>PKIX certificates have a number of advantages, such as an established process of certification and attribution of entities. It is also sometimes desirable for JSON-based cryptographic operations to support the existing and widespread deployment of PKIX-based technologies.</t>
</section>
<section title="Terminology" anchor="terms">
<t>This document inherits JSON Web Algorithms (JWA)-related terminology from <xref target="JWA"/>, JSON Web Encryption (JWE)-related terminology from <xref target="JWE"/>, and JSON Web Key (JWK)-related terminology from <xref target="JWK"/>. Security-related terms are to be understood in the sense defined in <xref target="RFC4949"/>.</t>
<t>The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/>.</t>
</section>
<section title="PKIX Key Type" anchor="params">
<t>The "PKIX" key type is used to contain a chain of PKIX certificates. The following parameters are defined:</t>
<section title="'x5c' (X.509 Certificate Chain) Parameter" anchor="params-x5c">
<t>The REQUIRED "x5c" parameter contains a chain of one or more PKIX certificates <xref target="RFC5280"/>. The certificate chain is represented as an array of certificate value strings. Each string in the array is a DER <xref target="ITU.X690.1994"/> PKIX certificate encoded as base64 <xref target="RFC4648"/> (not base64url). The array MUST have at least one value, which MUST be the PKIX certificate of the actor (e.g., the singer of a <xref target="JWS"/>, or a recipient of a <xref target="JWE"/>). Each additional value of the array (if any) MUST be the PKIX certificate that certifies the previous certificate.</t>
</section>
</section>
<section title="Examples" anchor="examples">
<t>
The following is a non-normative example of a JWK Set containing a single JWK utilizing the PKIX Key Type ("kty") defined in this document.
</t>
<figure><artwork><![CDATA[
{"keys":[
{"kty":"PKIX",
"x5c":[
"MIIE3jCCA8agAwIBAgICAwEwDQYJKoZIhvcNAQEFBQAwYzELMAkGA1UEBhMCVVM
xITAfBgNVBAoTGFRoZSBHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR2
8gRGFkZHkgQ2xhc3MgMiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNjExM
TYwMTU0MzdaFw0yNjExMTYwMTU0MzdaMIHKMQswCQYDVQQGEwJVUzEQMA4GA1UE
CBMHQXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTEaMBgGA1UEChMRR29EYWR
keS5jb20sIEluYy4xMzAxBgNVBAsTKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYW
RkeS5jb20vcmVwb3NpdG9yeTEwMC4GA1UEAxMnR28gRGFkZHkgU2VjdXJlIENlc
nRpZmljYXRpb24gQXV0aG9yaXR5MREwDwYDVQQFEwgwNzk2OTI4NzCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMQt1RWMnCZM7DI161+4WQFapmGBWTt
wY6vj3D3HKrjJM9N55DrtPDAjhI6zMBS2sofDPZVUBJ7fmd0LJR4h3mUpfjWoqV
Tr9vcyOdQmVZWt7/v+WIbXnvQAjYwqDL1CBM6nPwT27oDyqu9SoWlm2r4arV3aL
GbqGmu75RpRSgAvSMeYddi5Kcju+GZtCpyz8/x4fKL4o/K1w/O5epHBp+YlLpyo
7RJlbmr2EkRTcDCVw5wrWCs9CHRK8r5RsL+H0EwnWGu1NcWdrxcx+AuP7q2BNgW
JCJjPOq8lh8BJ6qf9Z/dFjpfMFDniNoW1fho3/Rb2cRGadDAW/hOUoz+EDU8CAw
EAAaOCATIwggEuMB0GA1UdDgQWBBT9rGEyk2xF1uLuhV+auud2mWjM5zAfBgNVH
SMEGDAWgBTSxLDSkdRMEXGzYcs9of7dqGrU4zASBgNVHRMBAf8ECDAGAQH/AgEA
MDMGCCsGAQUFBwEBBCcwJTAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AuZ29kYWR
keS5jb20wRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NlcnRpZmljYXRlcy5nb2
RhZGR5LmNvbS9yZXBvc2l0b3J5L2dkcm9vdC5jcmwwSwYDVR0gBEQwQjBABgRVH
SAAMDgwNgYIKwYBBQUHAgEWKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5j
b20vcmVwb3NpdG9yeTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggE
BANKGwOy9+aG2Z+5mC6IGOgRQjhVyrEp0lVPLN8tESe8HkGsz2ZbwlFalEzAFPI
UyIXvJxwqoJKSQ3kbTJSMUA2fCENZvD117esyfxVgqwcSeIaha86ykRvOe5GPLL
5CkKSkB2XIsKd83ASe8T+5o0yGPwLPk9Qnt0hCqU7S+8MxZC9Y7lhyVJEnfzuz9
p0iRFEUOOjZv2kWzRaJBydTXRE4+uXR21aITVSzGh6O1mawGhId/dQb8vxRMDsx
uxN89txJx9OjxUUAiKEngHUuHqDTMBqLdElrRhjZkAzVvb3du6/KFUJheqwNTrZ
EjYx8WnM25sgVjOuH0aBsXBTWVU+4=",
"MIIE+zCCBGSgAwIBAgICAQ0wDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1Z
hbGlDZXJ0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIE
luYy4xNTAzBgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb
24gQXV0aG9yaXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8x
IDAeBgkqhkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMB4XDTA0MDYyOTE3MDY
yMFoXDTI0MDYyOTE3MDYyMFowYzELMAkGA1UEBhMCVVMxITAfBgNVBAoTGFRoZS
BHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR28gRGFkZHkgQ2xhc3MgM
iBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQADggEN
ADCCAQgCggEBAN6d1+pXGEmhW+vXX0iG6r7d/+TvZxz0ZWizV3GgXne77ZtJ6XC
APVYYYwhv2vLM0D9/AlQiVBDYsoHUwHU9S3/Hd8M+eKsaA7Ugay9qK7HFiH7Eux
6wwdhFJ2+qN1j3hybX2C32qRe3H3I2TqYXP2WYktsqbl2i/ojgC95/5Y0V4evLO
tXiEqITLdiOr18SPaAIBQi2XKVlOARFmR6jYGB0xUGlcmIbYsUfb18aQr4CUWWo
riMYavx4A6lNf4DD+qta/KFApMoZFv6yyO9ecw3ud72a9nmYvLEHZ6IVDd2gWMZ
Eewo+YihfukEHU1jPEX44dMX4/7VpkI+EdOqXG68CAQOjggHhMIIB3TAdBgNVHQ
4EFgQU0sSw0pHUTBFxs2HLPaH+3ahq1OMwgdIGA1UdIwSByjCBx6GBwaSBvjCBu
zEkMCIGA1UEBxMbVmFsaUNlcnQgVmFsaWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQK
Ew5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFsaUNlcnQgQ2xhc3MgMiBQb2x
pY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0dHA6Ly93d3cudm
FsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5jb22CA
QEwDwYDVR0TAQH/BAUwAwEB/zAzBggrBgEFBQcBAQQnMCUwIwYIKwYBBQUHMAGG
F2h0dHA6Ly9vY3NwLmdvZGFkZHkuY29tMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA
6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeS9yb290LmNybD
BLBgNVHSAERDBCMEAGBFUdIAAwODA2BggrBgEFBQcCARYqaHR0cDovL2NlcnRpZ
mljYXRlcy5nb2RhZGR5LmNvbS9yZXBvc2l0b3J5MA4GA1UdDwEB/wQEAwIBBjAN
BgkqhkiG9w0BAQUFAAOBgQC1QPmnHfbq/qQaQlpE9xXUhUaJwL6e4+PrxeNYiY+
Sn1eocSxI0YGyeR+sBjUZsE4OWBsUs5iB0QQeyAfJg594RAoYC5jcdnplDQ1tgM
QLARzLrUc+cb53S8wGd9D0VmsfSxOaFIqII6hR8INMqzW/Rn453HWkrugp++85j
09VZw==",
"MIIC5zCCAlACAQEwDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1ZhbGlDZXJ
0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNT
AzBgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb24gQXV0a
G9yaXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkq
hkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMB4XDTk5MDYyNjAwMTk1NFoXDTE
5MDYyNjAwMTk1NFowgbsxJDAiBgNVBAcTG1ZhbGlDZXJ0IFZhbGlkYXRpb24gTm
V0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNTAzBgNVBAsTLFZhbGlDZ
XJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb24gQXV0aG9yaXR5MSEwHwYDVQQD
ExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkqhkiG9w0BCQEWEWluZm9
AdmFsaWNlcnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOOnHK5a
vIWZJV16vYdA757tn2VUdZZUcOBVXc65g2PFxTXdMwzzjsvUGJ7SVCCSRrCl6zf
N1SLUzm1NZ9WlmpZdRJEy0kTRxQb7XBhVQ7/nHk01xC+YDgkRoKWzk2Z/M/VXwb
P7RfZHM047QSv4dk+NoS/zcnwbNDu+97bi5p9wIDAQABMA0GCSqGSIb3DQEBBQU
AA4GBADt/UG9vUJSZSWI4OB9L+KXIPqeCgfYrx+jFzug6EILLGACOTb2oWH+heQ
C1u+mNr0HZDzTuIYEZoDJJKPTEjlbVUjP9UNV+mWwD5MlM/Mtsq2azSiGM5bUMM
j4QssxsodyamEwCW/POuZ6lcg5Ktz885hZo+L7tdEy8W9ViH0Pd"],
"use":"sig",
"kid":"somekey"}]
}
]]></artwork></figure>
</section>
<section title="IANA Considerations" anchor="iana">
<section title="JSON Web Key Type Registration" anchor="iana-jwk-types">
<t>This document registers the following to the JSON Web Key Types registry:</t>
<t>
<list style="symbols">
<t>"kty" Paramater value: "PKIX"<vspace blankLines="1"/></t>
<t>Implementation Requirements: OPTIONAL<vspace blankLines="1"/></t>
<t>Change Controller: IETF<vspace blankLines="1"/></t>
<t>Specification Document(s): <xref target="params"/> of [[ this document ]]<vspace blankLines="1"/></t>
</list>
</t>
</section>
<section title="JSON Web Key Parameters Registration" anchor="iana-jwk-params">
<t>This document registers the following to the JSON Web Key Parameters registry:</t>
<t>
<list style="symbols">
<t>Parameter Name: "x5c"<vspace blankLines="1"/></t>
<t>Change Controller: IETF<vspace blankLines="1"/></t>
<t>Specification Document(s): <xref target="params-x5c"/> of [[ this document ]]<vspace blankLines="1"/></t>
</list>
</t>
</section>
</section>
<section title="Security Considerations" anchor="security">
<t>This document does not introduce any new considerations beyond those specified by <xref target="JWK"/>.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4627.xml' ?>
<reference anchor="DSS">
<front>
<title>Digital Signature Standard (DSS)</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="June" year="2009" />
</front>
<seriesInfo name="FIPS" value="PUB 186-3" />
<format target="http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf" type="PDF" />
</reference>
<reference anchor="ITU.X690.1994">
<front>
<title>Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
<author>
<organization>International Telecommunications Union</organization>
</author>
<date month="" year="1994" />
</front>
<seriesInfo name="ITU-T" value="Recommendation X.690" />
</reference>
<reference anchor="JWA">
<front>
<title>JSON Web Algorithms (JWA)</title>
<author initials="M." surname="Jones" fullname="Michael B. Jones">
<organization>Microsoft</organization>
<address>
<email>mjb@microsoft.com</email>
</address>
</author>
<date year="2012" month="December"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-jose-json-web-algorithms-08"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-algorithms-08.txt"/>
</reference>
<reference anchor="JWE">
<front>
<title>JSON Web Encryption (JWE)</title>
<author initials="M." surname="Jones" fullname="Michael B. Jones">
<organization>Microsoft</organization>
<address>
<email>mjb@microsoft.com</email>
</address>
</author>
<author initials="E." surname="Rescola" fullname="Eric Rescola">
<organization>RTFM, Inc.</organization>
<address>
<email>ekr@rtfm.com</email>
</address>
</author>
<author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
<organization>Cisco Systems, Inc.</organization>
<address>
<email>jhildebr@cisco.com</email>
</address>
</author>
<date year="2012" month="December"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-jose-json-web-encryption-08"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-encryption-08.txt"/>
</reference>
<reference anchor="JWS">
<front>
<title>JSON Web Signature (JWS)</title>
<author initials="M." surname="Jones" fullname="Michael B. Jones">
<organization>Microsoft</organization>
<address>
<email>mjb@microsoft.com</email>
</address>
</author>
<date year="2012" month="December"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-jose-json-web-signature-08"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-signature-08.txt"/>
</reference>
<reference anchor="JWK">
<front>
<title>JSON Web Key (JWK)</title>
<author initials="M." surname="Jones" fullname="Michael B. Jones">
<organization>Microsoft</organization>
<address>
<email>mjb@microsoft.com</email>
</address>
</author>
<date year="2012" month="December"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-jose-json-web-key-08"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-key-08.txt"/>
</reference>
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>+1 617 495 3864</phone>
</address>
</author>
<date month="March" year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:
<list><t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.</t></list>
</t>
<t>Note that the force of these words is modified by the requirement level of the document in which they are used.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
</reference>
<reference anchor="RFC4648">
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author initials="S." surname="Josefsson" fullname="S. Josefsson">
<organization/>
</author>
<date year="2006" month="October"/>
<abstract>
<t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4648"/>
<format type="TXT" octets="35491" target="http://www.ietf.org/rfc/rfc4648.txt"/>
</reference>
<reference anchor="RFC4949">
<front>
<title>Internet Security Glossary, Version 2</title>
<author initials="R." surname="Shirey" fullname="R. Shirey">
<organization/>
</author>
<date year="2007" month="August"/>
<abstract>
<t>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4949"/>
<format type="TXT" octets="867626" target="http://www.ietf.org/rfc/rfc4949.txt"/>
</reference>
<reference anchor="RFC5280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author initials="D." surname="Cooper" fullname="D. Cooper">
<organization/>
</author>
<author initials="S." surname="Santesson" fullname="S. Santesson">
<organization/>
</author>
<author initials="S." surname="Farrell" fullname="S. Farrell">
<organization/>
</author>
<author initials="S." surname="Boeyen" fullname="S. Boeyen">
<organization/>
</author>
<author initials="R." surname="Housley" fullname="R. Housley">
<organization/>
</author>
<author initials="W." surname="Polk" fullname="W. Polk">
<organization/>
</author>
<date year="2008" month="May"/>
<abstract>
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5280"/>
<format type="TXT" octets="352580" target="ftp://ftp.isi.edu/in-notes/rfc5280.txt"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC3447">
<front>
<title>Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1</title>
<author initials="J." surname="Jonsson" fullname="Jakob Jonsson">
<organization>Philipps-Universitaet Marburg</organization>
</author>
<author initials="B." surname="Kaliski" fullname="Burt Kaliski">
<organization>RSA Labratories</organization>
</author>
<date year="2003" month="February"/>
<abstract>
<t>This memo represents a republication of PKCS #1 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document is taken directly from the PKCS #1 v2.1 document, with certain corrections made during the publication process.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2898"/>
<format type="TXT" target="http://www.ietf.org/rfc/rfc2898.txt"/>
</reference>
</references>
<section title="Acknowledgements" anchor="acknowledgements">
</section>
<section title="Document History" anchor="history">
<t>
<list style="hanging">
<t hangText="-01">Minor typos and nits</t>
<t hangText="-00">Initial revision</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:51:24 |