rfc9679xml2.original.xml | rfc9679.xml | |||
---|---|---|---|---|
<?xml version="1.0" encoding="UTF-8"?> | <?xml version="1.0" encoding="utf-8"?> | |||
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> | ||||
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.17 (Ruby 3. | ||||
0.2) --> | ||||
<!DOCTYPE rfc [ | <!-- pre-edited by ST 09/16/24 --> | |||
<!-- formatted by ST 10/07/24 --> | ||||
<!-- reference review by TH 10/07/24 --> | ||||
<!DOCTYPE rfc [ | ||||
<!ENTITY nbsp " "> | <!ENTITY nbsp " "> | |||
<!ENTITY zwsp "​"> | <!ENTITY zwsp "​"> | |||
<!ENTITY nbhy "‑"> | <!ENTITY nbhy "‑"> | |||
<!ENTITY wj "⁠"> | <!ENTITY wj "⁠"> | |||
]> | ]> | |||
<?rfc rfcedstyle="yes"?> | <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft | |||
<?rfc tocindent="yes"?> | -ietf-cose-key-thumbprint-06" number="9679" updates="" obsoletes="" submissionTy | |||
<?rfc strict="yes"?> | pe="IETF" category="std" consensus="true" tocInclude="true" sortRefs="true" symR | |||
<?rfc comments="yes"?> | efs="true" version="3" xml:lang="en" > | |||
<?rfc inline="yes"?> | ||||
<?rfc text-list-symbols="-o*+"?> | ||||
<?rfc docmapping="yes"?> | ||||
<rfc ipr="trust200902" docName="draft-ietf-cose-key-thumbprint-06" category="std " consensus="true" tocInclude="true" sortRefs="true" symRefs="true"> | ||||
<front> | <front> | |||
<title abbrev="COSE Key Thumbprint">CBOR Object Signing and Encryption (COSE ) Key Thumbprint</title> | <title abbrev="COSE Key Thumbprint">CBOR Object Signing and Encryption (COSE ) Key Thumbprint</title> | |||
<seriesInfo name="RFC" value="9679"/> | ||||
<author initials="K." surname="Isobe" fullname="Kohei Isobe"> | <author initials="K." surname="Isobe" fullname="Kohei Isobe"> | |||
<organization>SECOM CO., LTD.</organization> | <organization>SECOM CO., LTD.</organization> | |||
<address> | <address> | |||
<postal> | ||||
<country>Japan</country> | ||||
</postal> | ||||
<email>isobekohei@gmail.com</email> | <email>isobekohei@gmail.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig"> | <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig"> | |||
<organization abbrev="H-BRS">University of Applied Sciences Bonn-Rhein-Sie g</organization> | <organization abbrev="H-BRS">University of Applied Sciences Bonn-Rhein-Sie g</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<country>Germany</country> | <country>Germany</country> | |||
</postal> | </postal> | |||
<email>hannes.tschofenig@gmx.net</email> | <email>hannes.tschofenig@gmx.net</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author initials="O." surname="Steele" fullname="Orie Steele"> | <author initials="O." surname="Steele" fullname="Orie Steele"> | |||
<organization>Transmute</organization> | <organization>Transmute</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<country>United States</country> | <country>United States of America</country> | |||
</postal> | </postal> | |||
<email>orie@transmute.industries</email> | <email>orie@transmute.industries</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<date year="2024" month="October"/> | ||||
<area>SEC</area> | ||||
<workgroup>cose</workgroup> | ||||
<date year="2024" month="September" day="06"/> | <!-- [rfced] Please insert any keywords (beyond those that appear in | |||
the title) for use on https://www.rfc-editor.org/search. --> | ||||
<area>Security</area> | ||||
<workgroup>COSE</workgroup> | ||||
<keyword>Internet-Draft</keyword> | ||||
<abstract> | <abstract> | |||
<?line 69?> | ||||
<t>This specification defines a method for computing a hash value over a CBOR | <t>This specification defines a method for computing a hash value over a CBOR | |||
Object Signing and Encryption (COSE) Key. It specifies which fields within | Object Signing and Encryption (COSE) Key. It specifies which fields within | |||
the COSE Key structure are included in the cryptographic hash computation, | the COSE Key structure are included in the cryptographic hash computation, | |||
the process for creating a canonical representation of these fields, and how | the process for creating a canonical representation of these fields, and how | |||
to hash the resulting byte sequence. The resulting hash value, referred to | to hash the resulting byte sequence. The resulting hash value, referred to | |||
as a "thumbprint," can be used to identify or select the corresponding key.</t> | as a "thumbprint", can be used to identify or select the corresponding key.</t> | |||
</abstract> | </abstract> | |||
</front> | </front> | |||
<middle> | <middle> | |||
<?line 78?> | <section anchor="introduction"> | |||
<name>Introduction</name> | ||||
<section anchor="introduction"><name>Introduction</name> | <t>This specification defines a method for applying a cryptographic | |||
<t>This specification defines a method for applying a cryptographic | ||||
hash function to a CBOR Object Signing and Encryption (COSE) Key | hash function to a CBOR Object Signing and Encryption (COSE) Key | |||
structure <xref target="RFC9052"/>, resulting in a hash value known as a | structure <xref target="RFC9052"/>, resulting in a hash value known as a | |||
"thumbprint." To achieve this, the document specifies which fields | "thumbprint". To achieve this, the document specifies which fields | |||
in the COSE Key structure are included in the hash computation, the | in the COSE Key structure are included in the hash computation, the | |||
process for creating a canonical form of these fields, and how to | process for creating a canonical form of these fields, and how to | |||
hash the resulting byte sequence. One of the primary use cases for | hash the resulting byte sequence. One of the primary use cases for | |||
this thumbprint is as a naming scheme for identifying or selecting | this thumbprint is as a naming scheme for identifying or selecting | |||
the key, such as by using the COSE Key Thumbprint value as a "kid" | the key, such as by using the COSE Key Thumbprint value as a "kid" | |||
(key ID). Another key use case involves key derivation functions | (key ID). Another key use case involves key derivation functions | |||
that use the thumbprints of public keys from the endpoints, along | that use the thumbprints of public keys from the endpoints, along | |||
with other context, to derive a symmetric key.</t> | with other application context, to derive a symmetric key.</t> | |||
<t>This specification outlines how thumbprints of COSE Keys are generated | ||||
<t>This specification outlines how thumbprints of COSE Keys are generated | for both asymmetric and symmetric keys (see Sections <xref target="thumbprint" f | |||
for both asymmetric and symmetric keys (see <xref target="thumbprint"/> and | ormat="counter"/> and | |||
<xref target="required"/>). Additionally, it introduces a new CBOR Web Token | <xref target="required" format="counter"/>). Additionally, it introduces a new C | |||
(CWT) confirmation method, which is added to the IANA | BOR Web Token (CWT) confirmation method, which has been added to the IANA | |||
"CWT Confirmation Methods" registry established by <xref target="RFC8747"/>. | "CWT Confirmation Methods" registry established by <xref target="RFC8747"/>. | |||
For further details on the use of a confirmation claim in a CWT | For further details on the use of a confirmation claim in a CWT | |||
with a proof-of-possession key, refer to Section 3.1 of <xref target="RFC8747"/> | with a proof-of-possession key, refer to <xref target="RFC8747" sectionFormat="o | |||
.</t> | f" section="3.1"/>.</t> | |||
</section> | ||||
</section> | <section anchor="terminology"> | |||
<section anchor="terminology"><name>Terminology</name> | <name>Terminology</name> | |||
<t> | ||||
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL | |||
"OPTIONAL" in this document are to be interpreted as described in | NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14> | |||
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, th | RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", | |||
ey appear in all | "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to | |||
capitals, as shown here.</t> | be interpreted as | |||
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> | ||||
</section> | when, and only when, they appear in all capitals, as shown here. | |||
<section anchor="thumbprint"><name>COSE Key Thumbprint</name> | </t> | |||
<t>The thumbprint of a COSE Key MUST be computed as follows:</t> | ||||
<t><list style="numbers" type="1"> | </section> | |||
<t>Construct a COSE_Key structure (see Section 7 of <xref target="RFC9052"/>) | <section anchor="thumbprint"> | |||
containing | <name>COSE Key Thumbprint</name> | |||
only the required parameters representing the key as described in | <t>The thumbprint of a COSE Key <bcp14>MUST</bcp14> be computed as follows | |||
Section 4 of this document.</t> | :</t> | |||
<t>Apply the deterministic encoding described in Section 4.2.1 of <xref target | <ol spacing="normal" type="1"><li> | |||
="RFC8949"/> | <t>Construct a COSE_Key structure (see <xref target="RFC9052" | |||
to the representation constructed in step (1).</t> | sectionFormat="of" section="7"/>) containing only the required | |||
<t>Hash the bytes produced in step (2) with a cryptographic hash function H. | parameters representing the key as described in <xref | |||
target="required" format="default"/> of this document.</t> | ||||
</li> | ||||
<li> | ||||
<t>Apply the deterministic encoding described in <xref | ||||
target="RFC8949" sectionFormat="of" section="4.2.1"/> to the | ||||
representation constructed in step 1.</t> | ||||
</li> | ||||
<li> | ||||
<t>Hash the bytes produced in step 2 with a cryptographic hash functio | ||||
n H. | ||||
For example, SHA-256 <xref target="RFC6234"/> may be used as a hash function.</t > | For example, SHA-256 <xref target="RFC6234"/> may be used as a hash function.</t > | |||
</list></t> | </li> | |||
</ol> | ||||
<t>The details of this computation are further described in subsequent | <t>The details of this computation are further described in subsequent | |||
sections.</t> | sections.</t> | |||
<t>The SHA-256 hash algorithm <bcp14>MUST</bcp14> be supported; other algo | ||||
<t>The SHA-256 hash algorithm MUST be supported, other algorithms MAY be support | rithms <bcp14>MAY</bcp14> be supported.</t> | |||
ed.</t> | </section> | |||
<section anchor="required"> | ||||
</section> | <name>Required COSE Key Parameters</name> | |||
<section anchor="required"><name>Required COSE Key Parameters</name> | <t>Only the required parameters of a key's representation are used when | |||
<t>Only the required parameters of a key's representation are used when | ||||
computing its COSE Key Thumbprint value. This section summarizes the | computing its COSE Key Thumbprint value. This section summarizes the | |||
required parameters.</t> | required parameters.</t> | |||
<t>The "kty" (label: 1) element <bcp14>MUST</bcp14> be present for all key | ||||
<t>The "kty" (label: 1) element MUST be present for all key types, and the integ | types, and the integer | |||
er | value specified in the IANA "COSE Key Types" registry <bcp14>MUST</bcp14> be use | |||
value specified in the IANA COSE Key Types registry MUST be used. The tstr data | d. The tstr data | |||
type is not used with the kty element.</t> | type is not used with the "kty" element.</t> | |||
<t>Many COSE Key parameters are specific to the chosen key type. The follo | ||||
<t>Many COSE Key parameters are specific to the chosen key type. The following | wing | |||
subsections list the required parameters for commonly used key types.</t> | subsections list the required parameters for commonly used key types.</t> | |||
<section anchor="octet-key-pair-okp"> | ||||
<section anchor="octet-key-pair-okp"><name>Octet Key Pair (OKP)</name> | <name>Octet Key Pair (OKP)</name> | |||
<t>The required parameters for elliptic curve public keys that use the Oct | ||||
<t>The required parameters for elliptic curve public keys that use the OKP key t | et Key Pair (OKP) key type, | |||
ype, | ||||
such as X25519, are:</t> | such as X25519, are:</t> | |||
<ul spacing="normal"> | ||||
<li> | ||||
<t>"kty" (label: 1, data type: int, value: 1)</t> | ||||
</li> | ||||
<li> | ||||
<t>"crv" (label: -1, value: int)</t> | ||||
</li> | ||||
<li> | ||||
<t>"x" (label: -2, value: bstr)</t> | ||||
</li> | ||||
</ul> | ||||
<t>Further details are described in <xref target="RFC9053" sectionFormat | ||||
="of" section="7.1"/>.</t> | ||||
</section> | ||||
<section anchor="ecc"> | ||||
<t><list style="symbols"> | <name>Elliptic Curve Keys with X- and Y-Coordinates</name> | |||
<t>"kty" (label: 1, data type: int, value: 1)</t> | <t>The required parameters for elliptic curve public keys that use the E | |||
<t>"crv" (label: -1, value: int)</t> | C2 key type, such as NIST P-256, are:</t> | |||
<t>"x" (label: -2, value: bstr)</t> | <ul spacing="normal"> | |||
</list></t> | <li> | |||
<t>"kty" (label: 1, data type: int, value: 2)</t> | ||||
<t>Details can be found in Section 7.1 of <xref target="RFC9053"/>.</t> | </li> | |||
<li> | ||||
</section> | <t>"crv" (label: -1, data type: int)</t> | |||
<section anchor="ecc"><name>Elliptic Curve Keys with X- and Y-Coordinate Pair</n | </li> | |||
ame> | <li> | |||
<t>"x" (label: -2, data type: bstr)</t> | ||||
<t>The required parameters for elliptic curve public keys that use the EC2 key t | </li> | |||
ype, such | <li> | |||
as NIST P-256, are:</t> | <t>"y" (label: -3, data type: bstr)</t> | |||
</li> | ||||
<t><list style="symbols"> | </ul> | |||
<t>"kty" (label: 1, data type: int, value: 2)</t> | <t>Further details are described in <xref target="RFC9053" sectionFormat | |||
<t>"crv" (label: -1, data type: int)</t> | ="of" section="7.1"/>.</t> | |||
<t>"x" (label: -2, data type: bstr)</t> | <t>Note: <xref target="RFC9052"/> supports both compressed and uncompres | |||
<t>"y" (label: -3, data type: bstr)</t> | sed point | |||
</list></t> | ||||
<t>Details can be found in Section 7.1 of <xref target="RFC9053"/>.</t> | ||||
<t>Note: <xref target="RFC9052"/> supports both compressed and uncompressed poin | ||||
t | ||||
representations. For interoperability, implementations adhering to | representations. For interoperability, implementations adhering to | |||
this specification MUST use the uncompressed point representation. | this specification <bcp14>MUST</bcp14> use the uncompressed point representation . | |||
Therefore, the y-coordinate is expressed as a bstr. If an | Therefore, the y-coordinate is expressed as a bstr. If an | |||
implementation uses the compressed point representation, it | implementation uses the compressed point representation, it | |||
MUST first convert it to the uncompressed form for the purpose | <bcp14>MUST</bcp14> first convert it to the uncompressed form for the purpose | |||
of thumbprint calculation.</t> | of thumbprint calculation.</t> | |||
</section> | ||||
<section anchor="rsa-public-keys"> | ||||
<name>RSA Public Keys</name> | ||||
<t>The required parameters for an RSA public key are:</t> | ||||
<ul spacing="normal"> | ||||
<li> | ||||
<t>"kty" (label: 1, data type: int, value: 3)</t> | ||||
</li> | ||||
<li> | ||||
<t>"n" (label: -1, data type: bstr)</t> | ||||
</li> | ||||
<li> | ||||
<t>"e" (label: -2, data type: bstr)</t> | ||||
</li> | ||||
</ul> | ||||
</section> | ||||
<section anchor="symmetric-keys"> | ||||
<name>Symmetric Keys</name> | ||||
<t>The required parameters for a symmetric key are:</t> | ||||
<ul spacing="normal"> | ||||
<li> | ||||
<t>"kty" (label: 1, data type: int, value: 4)</t> | ||||
</li> | ||||
<li> | ||||
<t>"k" (label: -1, data type: bstr)</t> | ||||
</li> | ||||
</ul> | ||||
</section> | ||||
</section> | <section anchor="hss-lms"> | |||
<section anchor="rsa-public-keys"><name>RSA Public Keys</name> | <name>HSS-LMS Keys</name> | |||
<t>The required parameters for HSS-LMS keys are:</t> | ||||
<t>The required parameters for an RSA public key are:</t> | <ul spacing="normal"> | |||
<li> | ||||
<t><list style="symbols"> | <t>"kty" (label: 1, data type: int, value: 5)</t> | |||
<t>"kty" (label: 1, data type: int, value: 3)</t> | </li> | |||
<t>"n" (label: -1, data type: bstr)</t> | <li> | |||
<t>"e" (label: -2, data type: bstr)</t> | <t>"pub" (label: -1, data type: bstr)</t> | |||
</list></t> | </li> | |||
</ul> | ||||
</section> | </section> | |||
<section anchor="symmetric-keys"><name>Symmetric Keys</name> | <section anchor="others"> | |||
<name>Others</name> | ||||
<t>The required parameters for a symmetric key are:</t> | <t>As other key type values are defined, their defining specifications | |||
should be similarly consulted to determine which | ||||
<t><list style="symbols"> | ||||
<t>"kty" (label: 1, data type: int, value: 4)</t> | ||||
<t>"k" (label: -1, data type: bstr)</t> | ||||
</list></t> | ||||
</section> | ||||
<section anchor="hss-lms"><name>HSS-LMS</name> | ||||
<t>The required parameters for HSS-LMS keys are:</t> | ||||
<t><list style="symbols"> | ||||
<t>"kty" (label: 1, data type: int, value: 5)</t> | ||||
<t>"pub" (label: -1, data type: bstr)</t> | ||||
</list></t> | ||||
</section> | ||||
<section anchor="others"><name>Others</name> | ||||
<t>As other key type values are defined, the specifications | ||||
defining them should be similarly consulted to determine which | ||||
parameters, in addition to the "kty" element, are required.</t> | parameters, in addition to the "kty" element, are required.</t> | |||
</section> | ||||
</section> | </section> | |||
</section> | <section anchor="miscellaneous-considerations"> | |||
<section anchor="miscellaneous-considerations"><name>Miscellaneous Consideration | <name>Miscellaneous Considerations</name> | |||
s</name> | <section anchor="why-not-include-optional-cose-key-parameters"> | |||
<name>Why Not Include Optional COSE Key Parameters?</name> | ||||
<section anchor="why-not-include-optional-cose-key-parameters"><name>Why Not Inc | <t>Optional parameters of COSE Keys are intentionally not included in th | |||
lude Optional COSE Key Parameters?</name> | e | |||
<t>Optional parameters of COSE Keys are intentionally not included in the | ||||
COSE Key Thumbprint computation so that their absence or presence | COSE Key Thumbprint computation so that their absence or presence | |||
in the COSE Key does not alter the resulting value. The COSE Key | in the COSE Key does not alter the resulting value. The COSE Key Thumbprint is a | |||
Thumbprint is a digest of the essential parameters required to | digest of the ordered essential parameters needed to represent a COSE Key, with | |||
represent the key as a COSE Key, rather than any additional data | all other parameters excluded.</t> | |||
that might accompany the key.</t> | <t>By excluding optional parameters, the COSE Key Thumbprint consistentl | |||
y | ||||
<t>By excluding optional parameters, the COSE Key Thumbprint consistently | ||||
refers to the key itself, not to a key with additional attributes. | refers to the key itself, not to a key with additional attributes. | |||
Different application contexts may include various optional attributes | Different application contexts may include various optional attributes | |||
in the COSE Key structure. If these optional parameters were included | in the COSE Key structure. If these optional parameters were included | |||
in the thumbprint calculation, the resulting values could differ for | in the thumbprint calculation, the resulting values could differ for | |||
the same key depending on the attributes present. Including only the | the same key depending on the attributes present. Including only the | |||
required parameters ensures that the COSE Key Thumbprint remains | required parameters ensures that the COSE Key Thumbprint remains | |||
consistent for a given key, regardless of any additional attributes.</t> | consistent for a given key, regardless of any additional attributes.</t> | |||
<t>Different kinds of thumbprints could be defined by other specificatio | ||||
<t>Different kinds of thumbprints could be defined by other specifications | ns | |||
that might include some or all additional COSE Key parameters, if use | that might include some or all additional COSE Key parameters, if use | |||
cases arise where such different kinds of thumbprints would be useful.</t> | cases arise where such different kinds of thumbprints would be useful.</t> | |||
</section> | ||||
</section> | <section anchor="selection-of-hash-function"> | |||
<section anchor="selection-of-hash-function"><name>Selection of Hash Function</n | <name>Selection of Hash Function</name> | |||
ame> | <t>A specific hash function must be chosen by an application to compute | |||
<t>A specific hash function must be chosen by an application to compute | ||||
the hash value of the hash input. For instance, SHA-256 <xref target="RFC6234"/> | the hash value of the hash input. For instance, SHA-256 <xref target="RFC6234"/> | |||
may be used as the hash function. While SHA-256 is a good default | may be used as the hash function. While SHA-256 is a good default | |||
choice at the time of writing, the preferred hash function may evolve | choice at the time of writing, the preferred hash function may evolve | |||
as the cryptographic landscape develops.</t> | as the cryptographic landscape develops.</t> | |||
<t>In many cases, only the party that generates the key needs to be | ||||
<t>In many cases, only the party that generates the key needs to be | ||||
aware of the hash function used. For example, the key producer might | aware of the hash function used. For example, the key producer might | |||
use the thumbprint value as a "kid" (key ID). In such scenarios, the | use the thumbprint value as a "kid" (key ID). In such scenarios, the | |||
consumer of the "kid" treats it as an opaque value solely for key | consumer of the "kid" treats it as an opaque value solely for key | |||
selection.</t> | selection.</t> | |||
<t>However, when multiple parties are involved in reproducing and | ||||
<t>However, when multiple parties are involved in reproducing and | ||||
comparing the COSE Key Thumbprint, it is crucial that they know | comparing the COSE Key Thumbprint, it is crucial that they know | |||
and use the same hash function to ensure consistent results.</t> | and use the same hash function to ensure consistent results.</t> | |||
</section> | ||||
</section> | <section anchor="thumbprints-of-keys-not-in-cose-key-format"> | |||
<section anchor="thumbprints-of-keys-not-in-cose-key-format"><name>Thumbprints o | <name>Thumbprints of Keys Not in COSE Key Format</name> | |||
f Keys Not in COSE Key Format</name> | <t>Keys that are in other formats can be represented as COSE Keys. | |||
<t>Keys that are in other formats can be represented as COSE Keys. | ||||
Any party in possession of a key that is represented as a COSE Key can | Any party in possession of a key that is represented as a COSE Key can | |||
use the COSE Key Thumbprint.</t> | use the COSE Key Thumbprint.</t> | |||
</section> | ||||
</section> | <section anchor="relationship-to-digests-of-x509-values"> | |||
<section anchor="relationship-to-digests-of-x509-values"><name>Relationship to D | <name>Relationship to Digests of X.509 Values</name> | |||
igests of X.509 Values</name> | <t>COSE Key Thumbprint values are computed on the COSE Key object containing onl | |||
y essential parameters in a specific order. Thus, they are more analogous to ap | ||||
<t>COSE Key Thumbprint values are computed on the COSE Key object required to | plications that | |||
represent a key, rather than all parameters of a COSE Key that the key is | ||||
represented in. Thus, they are more analogous to applications that | ||||
use digests of X.509 Subject Public Key Info (SPKI) values, which are | use digests of X.509 Subject Public Key Info (SPKI) values, which are | |||
defined in Section 4.1.2.7 of <xref target="RFC5280"/>, than to applications tha t | defined in <xref target="RFC5280" sectionFormat="of" section="4.1.2.7"/>, than t o applications that | |||
use digests of complete certificate values, as the "x5t" (X.509 | use digests of complete certificate values, as the "x5t" (X.509 | |||
certificate SHA-1 thumbprint) <xref target="RFC9360"/> value defined for X.509 | certificate SHA-1 thumbprint) <xref target="RFC9360"/> value defined for X.509 | |||
certificate objects does. While logically equivalent to a digest of | certificate objects does. While logically equivalent to a digest of | |||
the SPKI representation of the key, a COSE Key Thumbprint is computed over | the SPKI representation of the key, a COSE Key Thumbprint is computed over | |||
the CBOR representation of that key, rather than over an ASN.1 | the CBOR representation of that key rather than over an ASN.1 | |||
representation of it.</t> | representation of it.</t> | |||
</section> | ||||
</section> | <section anchor="confirmation-method"> | |||
<section anchor="confirmation-method"><name>Confirmation Method</name> | <name>Confirmation Method</name> | |||
<t><xref target="RFC8747"/> introduces confirmation methods for use with | ||||
<t><xref target="RFC8747"/> introduced confirmation methods for use with CBOR | CWTs with the addition of the "cnf" claim. CWTs are defined in <xref target="RF | |||
Web Tokens (CWTs) with the addition of the "cnf" claim. CWTs have | C8392"/>. This specification adds a new | |||
been defined in <xref target="RFC8392"/>. This specification adds a new | ||||
confirmation method based on COSE Key Thumbprints.</t> | confirmation method based on COSE Key Thumbprints.</t> | |||
<t>The proof-of-possession key is identified using the "ckt" claim, | ||||
<t>The proof-of-possession key is identified using the "ckt" claim, | ||||
the COSE Key Thumbprint claim. This claim contains the value of | the COSE Key Thumbprint claim. This claim contains the value of | |||
the COSE Key Thumbprint encoded as a binary string. Instead of | the COSE Key Thumbprint encoded as a binary string. Instead of | |||
communicating the actual COSE Key only the thumbprint is conveyed. | communicating the actual COSE Key, only the thumbprint is conveyed. | |||
This approach assumes that the recipient is able to obtain the | This approach assumes that the recipient is able to obtain the | |||
identified COSE Key using the thumbprint contained in the "ckt" | identified COSE Key using the thumbprint contained in the "ckt" | |||
claim. In this approach, the issuer of a CWT declares that the | claim. In this approach, the issuer of a CWT declares that the | |||
presenter possesses a particular key and that the recipient | presenter possesses a particular key and that the recipient | |||
can cryptographically confirm the presenter's proof of possession | can cryptographically confirm the presenter's proof of possession | |||
of the key by including a "ckt" claim in the CWT.</t> | of the key by including a "ckt" claim in the CWT.</t> | |||
<t>The following example demonstrates the use of the "ckt" claim | <t>The following example demonstrates the use of the "ckt" claim | |||
in a CWT as part of the confirmation method (with line-breaks inserted | in a CWT as part of the confirmation method (with line breaks inserted | |||
for editorial reasons):</t> | for editorial reasons):</t> | |||
<figure><artwork><![CDATA[ | <sourcecode type="cbor-diag"><![CDATA[ | |||
{ | { | |||
/iss/ 1 : "coaps://as.example.com", | /iss/ 1 : "coaps://as.example.com", | |||
/aud/ 3 : "coaps://resource.example.org", | /aud/ 3 : "coaps://resource.example.org", | |||
/exp/ 4 : 1361398824, | /exp/ 4 : 1361398824, | |||
/cnf/ 8 : { | /cnf/ 8 : { | |||
/ckt/ [[TBD1]] : h'496bd8afadf307e5b08c64b0421bf9dc | /ckt/ 5 : h'496bd8afadf307e5b08c64b0421bf9dc | |||
01528a344a43bda88fadd1669da253ec' | 01528a344a43bda88fadd1669da253ec' | |||
} | } | |||
} | }]]></sourcecode> | |||
]]></artwork></figure> | ||||
<t><xref target="IANA"/> registers the "ckt" claim and the confirmation method. | <t><xref target="IANA"/> registers the "ckt" claim and the confirmation method. | |||
The "ckt" claim is expected to be used in the "cnf" claim.</t> | The "ckt" claim is expected to be used in the "cnf" claim.</t> | |||
</section> | ||||
</section> | <section anchor="cose-key-thumbprint-uris"> | |||
<section anchor="cose-key-thumbprint-uris"><name>COSE Key Thumbprint URIs</name> | <name>COSE Key Thumbprint URIs</name> | |||
<t>This specification defines Uniform Resource Identifiers (URIs) | ||||
<t>This specification defines Uniform Resource Identifiers (URIs) | ||||
to represent a COSE Key Thumbprint value. The design follows | to represent a COSE Key Thumbprint value. The design follows | |||
the work of the JSON Web Key (JWK) Thumbprint URIs, specified | the work of JSON Web Key (JWK) Thumbprint URIs, as specified | |||
in <xref target="RFC9278"/>. This enables COSE Key Thumbprints to be used, | in <xref target="RFC9278"/>. This enables COSE Key Thumbprints to be used, | |||
for example, as key identifiers in contexts requiring URIs. | for example, as key identifiers in contexts requiring URIs. | |||
This specification defines a URI prefix indicating that the | This specification defines a URI prefix indicating that the | |||
portion of the URI following the prefix is a COSE Key Thumbprint.</t> | portion of the URI following the prefix is a COSE Key Thumbprint.</t> | |||
<t>The following URI prefix is defined to indicate that the portion | ||||
<t>The following URI prefix is defined to indicate that the portion | ||||
of the URI following the prefix is a COSE Key Thumbprint:</t> | of the URI following the prefix is a COSE Key Thumbprint:</t> | |||
<figure><artwork><![CDATA[ | <t indent="3">urn:ietf:params:oauth:ckt</t> | |||
urn:ietf:params:oauth:ckt | ||||
]]></artwork></figure> | ||||
<t>To make the hash algorithm being used explicit in a URI, the prefix | <t>To make the hash algorithm being used explicit in a URI, the prefix | |||
is followed by a hash algorithm identifier and a COSE Key Thumbprint | is followed by a hash algorithm identifier and a COSE Key Thumbprint | |||
value, each separated by a colon character to form a URI representing | value, each separated by a colon character to form a URI representing | |||
a COSE Key Thumbprint.</t> | a COSE Key Thumbprint.</t> | |||
<t>Hash algorithm identifiers used in COSE Key Thumbprint URIs <bcp14>MU | ||||
<t>Hash algorithm identifiers used in COSE Key Thumbprint URIs MUST be values | ST</bcp14> be values from the "Hash Name String" column in the IANA "Named Infor | |||
from the "Hash Name String" column in the IANA "Named Information | mation Hash Algorithm Registry" <xref target="IANA.Hash.Algorithms"/>. COSE Key | |||
Hash Algorithm Registry" <xref target="IANA.Hash.Algorithms"/>. COSE Key Thumbpr | Thumbprint URIs with hash algorithm identifiers not found in this registry are n | |||
int URIs | ot | |||
with hash algorithm identifiers not found in this registry are not | considered valid, and applications <bcp14>MUST</bcp14> detect and handle this | |||
considered valid and applications MUST detect and handle this | ||||
error, should it occur.</t> | error, should it occur.</t> | |||
<t>Since the URN is encoded as a string, the output of the COSE Key | ||||
<t>Since the URN is encoded as a string, the output of the COSE Key | Thumbprint computation described in <xref target="thumbprint"/> <bcp14>MUST</bcp | |||
Thumbprint computation described in <xref target="thumbprint"/> MUST be base64ur | 14> be base64url encoded without padding.</t> | |||
l | <t><xref target="RFC7515"/> specifies base64url encoding as follows:</t> | |||
encoded without padding.</t> | <!-- [Quote] --> | |||
<blockquote>Base64 encoding using the URL- and filename-safe character s | ||||
<t><xref target="RFC7515"/> specifies Base64url encoding as follows:</t> | et | |||
defined in Section <xref target="RFC4648" section="5" | ||||
<t>"Base64 encoding using the URL- and filename-safe character set | sectionFormat="bare"></xref> of RFC 4648 <xref target="RFC4648"/>, with all trai | |||
defined in Section 5 of RFC 4648 <xref target="RFC4648"/>, with all trailing '=' | ling '=' | |||
characters omitted and without the inclusion of any line breaks, | characters omitted (as permitted by <xref target="RFC7515" sectionFormat="of" se | |||
ction="3.2"/>) and without the inclusion of any line breaks, | ||||
whitespace, or other additional characters. Note that the base64url | whitespace, or other additional characters. Note that the base64url | |||
encoding of the empty octet sequence is the empty string. | encoding of the empty octet sequence is the empty string. | |||
(See Appendix C of <xref target="RFC7515"/> for notes on implementing base64url | (See <xref target="RFC7515" sectionFormat="of" section="C"/> for notes on implem | |||
encoding without padding.)"</t> | enting base64url | |||
encoding without padding.)</blockquote> | ||||
<t>The base64url encoding of the thumbprint shown in <xref target="example"/> is | <!-- [End of quote] --> | |||
shown below (with a line-break added for readability purposes).</t> | <t>The base64url encoding of the thumbprint shown in <xref target="examp | |||
le"/> is | ||||
<figure><artwork><![CDATA[ | shown below (with a line break added for readability purposes).</t> | |||
SWvYr63zB-WwjGSwQhv53AFSijRKQ72oj63RZp2iU-w | ||||
]]></artwork></figure> | ||||
<t>The full example of a COSE Key Thumbprint URI is shown below, again | ||||
with a line-break added.</t> | ||||
<figure><artwork><![CDATA[ | ||||
urn:ietf:params:oauth:ckt:sha-256: | ||||
SWvYr63zB-WwjGSwQhv53AFSijRKQ72oj63RZp2iU-w | ||||
]]></artwork></figure> | ||||
</section> | <t indent="3">SWvYr63zB-WwjGSwQhv53AFSijRKQ72oj63RZp2iU-w</t> | |||
</section> | ||||
<section anchor="example"><name>Example</name> | ||||
<t>This section demonstrates the COSE Key Thumbprint computation for the | <t>The full example of a COSE Key Thumbprint URI is shown below (with a | |||
following example COSE Key containing an ECC public key.</t> | line break added for readability).</t> | |||
<t>For better readability, the example is first presented in CBOR diagnostic for | <t indent="3">urn:ietf:params:oauth:ckt:sha-256:</t> | |||
mat (with | <t indent="3">SWvYr63zB-WwjGSwQhv53AFSijRKQ72oj63RZp2iU-w</t> | |||
<t>Note that the use of oauth in the namespace is to align with JWK Thumbprint U | ||||
RIs as described in <xref target="RFC9278"/>; however, these URIs are intended f | ||||
or use with applications and specifications not necessarily related to OAuth.</t | ||||
> | ||||
</section> | ||||
</section> | ||||
<section anchor="example"> | ||||
<name>Example</name> | ||||
<t>This section demonstrates the COSE Key Thumbprint computation for the | ||||
following example COSE Key containing an Elliptic Curve Cryptography (ECC) publi | ||||
c key.</t> | ||||
<t>For better readability, the example is first presented in CBOR diagnost | ||||
ic format (with | ||||
the long line broken for display purposes only).</t> | the long line broken for display purposes only).</t> | |||
<figure><artwork><![CDATA[ | <sourcecode type="cbor-diag"><![CDATA[ | |||
{ | { | |||
/ kty set to EC2 = Elliptic Curve Keys / | / kty set to EC2 = Elliptic Curve Keys / | |||
1:2, | 1:2, | |||
/ crv set to P-256 / | / crv set to P-256 / | |||
-1:1, | -1:1, | |||
/ public key: x-coordinate / | / public key: x-coordinate / | |||
-2:h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c0 | -2:h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c0 | |||
8551d', | 8551d', | |||
/ public key: y-coordinate / | / public key: y-coordinate / | |||
-3:h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd008 | -3:h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd008 | |||
4d19c', | 4d19c', | |||
/ kid is bstr, not used in COSE Key Thumbprint / | / kid is bstr, not used in COSE Key Thumbprint / | |||
2:h'1decade2facade3' | 2:h'496bd8afadf307e5b08c64b0421bf9dc01528a344a43bda88fadd1669da2 | |||
} | 53ec' | |||
]]></artwork></figure> | }]]></sourcecode> | |||
<t>The example above corresponds to the following CBOR encoding | <t>The example above corresponds to the following CBOR encoding | |||
(with link breaks added for display purposes only):</t> | (with link breaks added for display purposes only):</t> | |||
<figure><artwork><![CDATA[ | <sourcecode type="test-vectors"><![CDATA[ | |||
A50102200121582065EDA5A12577C2BAE829437FE338701A10AAA375E1BB5B5DE108D | A50102200121582065EDA5A12577C2BAE829437FE338701A10AAA375E1BB5B5DE108D | |||
E439C08551D2258201E52ED75701163F7F9E40DDF9F341B3DC9BA860AF7E0CA7CA7E9 | E439C08551D2258201E52ED75701163F7F9E40DDF9F341B3DC9BA860AF7E0CA7CA7E9 | |||
EECD0084D19C0258246D65726961646F632E6272616E64796275636B406275636B6C6 | EECD0084D19C0258246D65726961646F632E6272616E64796275636B406275636B6C6 | |||
16E642E6578616D706C65 | 16E642E6578616D706C65]]></sourcecode> | |||
]]></artwork></figure> | ||||
<t>Not all of the parameters from the example above are used in the COSE Key | <t>Not all of the parameters from the example above are used in the COSE K | |||
Thumbprint computation since the required parameters of an elliptic curve | ey | |||
Thumbprint computation because the required parameters of an elliptic curve | ||||
public key are (as listed in <xref target="ecc"/>) "kty", "crv", "x", and "y".</ t> | public key are (as listed in <xref target="ecc"/>) "kty", "crv", "x", and "y".</ t> | |||
<t>The resulting COSE Key structure, in CBOR diagnostic format with | ||||
line breaks added for better readability, with the minimum parameters | ||||
in the correct order are:</t> | ||||
<t>The resulting COSE Key structure, in CBOR diagnostic format with | <sourcecode type="cbor-diag"><![CDATA[ | |||
line-breaks added for better readability, with the minimum parameters | ||||
in the correct order are.</t> | ||||
<figure><artwork><![CDATA[ | ||||
{ | { | |||
1:2, | 1:2, | |||
-1:1, | -1:1, | |||
-2:h'65eda5a12577c2bae829437fe338701a | -2:h'65eda5a12577c2bae829437fe338701a | |||
10aaa375e1bb5b5de108de439c08551d', | 10aaa375e1bb5b5de108de439c08551d', | |||
-3:h'1e52ed75701163f7f9e40ddf9f341b3d | -3:h'1e52ed75701163f7f9e40ddf9f341b3d | |||
c9ba860af7e0ca7ca7e9eecd0084d19c' | c9ba860af7e0ca7ca7e9eecd0084d19c' | |||
} | }]]></sourcecode> | |||
]]></artwork></figure> | ||||
<t>In CBOR encoding the result is (with line-breaks added for display | <t>In CBOR encoding, the result is (with line breaks added for display | |||
purposes only):</t> | purposes only):</t> | |||
<figure><artwork><![CDATA[ | <sourcecode type="test-vectors"><![CDATA[ | |||
A40102200121582065EDA5A12577C2BAE829437FE338701A10AAA375E1BB5B5DE | A40102200121582065EDA5A12577C2BAE829437FE338701A10AAA375E1BB5B5DE | |||
108DE439C08551D2258201E52ED75701163F7F9E40DDF9F341B3DC9BA860AF7E0 | 108DE439C08551D2258201E52ED75701163F7F9E40DDF9F341B3DC9BA860AF7E0 | |||
CA7CA7E9EECD0084D19C | CA7CA7E9EECD0084D19C]]></sourcecode> | |||
]]></artwork></figure> | ||||
<t>Using SHA-256, the resulting thumbprint is:</t> | ||||
<figure><artwork><![CDATA[ | ||||
496bd8afadf307e5b08c64b0421bf9dc01528a344a43bda88fadd1669da253ec | ||||
]]></artwork></figure> | ||||
</section> | <t>Using SHA-256, the resulting thumbprint is:</t> | |||
<section anchor="security-considerations"><name>Security Considerations</name> | ||||
<t>A COSE Key Thumbprint will only uniquely identify a particular key if a | <sourcecode type="test-vectors"><![CDATA[ | |||
single unambiguous COSE Key representation for that key is defined and | 496bd8afadf307e5b08c64b0421bf9dc01528a344a43bda88fadd1669da253ec]]></sourcecode> | |||
used when computing the COSE Key Thumbprint.</t> | ||||
<t>A COSE Key Thumbprint will only uniquely identify a particular key if a | </section> | |||
<section anchor="security-considerations"> | ||||
<name>Security Considerations</name> | ||||
<t>A COSE Key Thumbprint will only uniquely identify a particular key if a | ||||
single unambiguous COSE Key representation for that key is defined and | single unambiguous COSE Key representation for that key is defined and | |||
used when computing the COSE Key Thumbprint. Key identifiers are not | used when computing the COSE Key Thumbprint. Key identifiers are not | |||
included in the thumbprint calculation (similarly to other optional | included in the thumbprint calculation (similarly to other optional | |||
parameters in the COSE_Key structure). If the inclusion | parameters in the COSE_Key structure). If the inclusion | |||
of specific optional parameters in the thumbprint calculation is important | of specific optional parameters in the thumbprint calculation is important | |||
for a particular application, this specification would not be suitable.</t> | for a particular application, this specification would not be suitable.</t> | |||
<t>While thumbprint values are useful for identifying legitimate keys, | ||||
<t>While thumbprint values are useful for identifying legitimate keys, | ||||
comparing thumbprint values is not a reliable means of excluding the | comparing thumbprint values is not a reliable means of excluding the | |||
use of particular keys (or transformations thereof). The reason is | use of particular keys (or transformations thereof). The reason is | |||
that an attacker may supply a key that is a transformation of a key | because an attacker may supply a key that is a transformation of a key | |||
in order to have it appear to be a different key. For instance, if | in order for it to appear as a different key. For instance, if | |||
a legitimate RSA key uses a modulus value N and an attacker supplies | a legitimate RSA key uses a modulus value N and an attacker supplies | |||
a key with modulus 3*N, the modified key would still work about 1/3 | a key with modulus 3*N, the modified key would still work about 1/3 | |||
of the time, but would appear to be a different key.</t> | of the time, but it would appear to be a different key.</t> | |||
<t>Producing thumbprints of symmetric keys needs to be done with care. Dev | ||||
<t>Producing thumbprints of symmetric keys needs to be done with care. Developer | elopers | |||
s | <bcp14>MUST</bcp14> ensure that the symmetric key has sufficient entropy to prev | |||
MUST ensure that the symmetric key has sufficient entropy to prevent | ent | |||
attackers to precompute tables of symmetric keys with their corresponding | attackers from precomputing tables of symmetric keys with their corresponding | |||
hash values. This can be prevented if the symmetric key is a randomly | hash values. This can be prevented if the symmetric key is a randomly | |||
selected key of at least 128 bit length. Thumbprints MUST NOT be used | selected key of at least a 128-bit length. Thumbprints <bcp14>MUST NOT</bcp14> b e used | |||
with passwords or other low-entropy secrets. If a | with passwords or other low-entropy secrets. If a | |||
developer is unable to determine whether all symmetric keys used in an | developer is unable to determine whether all symmetric keys used in an | |||
application have sufficient entropy, then thumbprints of symmetric keys | application have sufficient entropy, then thumbprints of symmetric keys | |||
MUST NOT be used. In general, using thumbprints of symmetric keys should | <bcp14>MUST NOT</bcp14> be used. In general, using thumbprints of symmetric keys | |||
only be used in special applications. In most other deployment scenarios | should | |||
only be used in special applications. In most other deployment scenarios, | ||||
it is more appropriate to utilize a different naming scheme for key | it is more appropriate to utilize a different naming scheme for key | |||
identifiers.</t> | identifiers.</t> | |||
</section> | ||||
<section anchor="IANA"> | ||||
<name>IANA Considerations</name> | ||||
</section> | <t>IANA has added the following entry to the "CWT Confirmation | |||
<section anchor="IANA"><name>IANA Considerations</name> | Methods" registry <xref target="IANA-CWT"/> established by <xref target="RFC8747 | |||
"/>:</t> | ||||
<t>IANA is requested to add the following entry to the IANA "CWT Confirmation | <dl spacing="compact" newline="false"> | |||
Methods" registry established by <xref target="RFC8747"/>:</t> | <dt>Confirmation Method Name:</dt><dd>ckt</dd> | |||
<dt>Confirmation Method Description:</dt><dd>COSE Key SHA-256 Thumbpri | ||||
<t><list style="symbols"> | nt</dd> | |||
<t>Confirmation Method Name: ckt</t> | <dt>JWT Confirmation Method Name:</dt><dd>jkt</dd> | |||
<t>Confirmation Method Description: COSE Key SHA-256 Thumbprint</t> | <dt>Confirmation Key:</dt><dd>5</dd> | |||
<t>JWT Confirmation Method Name: jkt</t> | <dt>Confirmation Value Type(s):</dt><dd>binary string</dd> | |||
<t>Confirmation Key: [[TBD1]]</t> | <dt>Change Controller:</dt><dd>IETF</dd> | |||
<t>Confirmation Value Type(s): binary string</t> | <dt>Specification Document(s):</dt><dd>RFC 9679</dd> | |||
<t>Change Controller: IETF</t> | </dl> | |||
<t>Specification Document(s): [[This document]]</t> | ||||
</list></t> | ||||
<t>Furthermore, IANA is requested to add a value to the IANA "OAuth URI" registr | ||||
y | ||||
established with <xref target="RFC6755"/>:</t> | ||||
<t><list style="symbols"> | ||||
<t>URN: urn:ietf:params:oauth:ckt</t> | ||||
<t>Common Name: COSE Key Thumbprint URI</t> | ||||
<t>Change controller: IETF</t> | ||||
<t>Specification Document: [[This document]]</t> | ||||
</list></t> | ||||
</section> | ||||
<section anchor="acknowledgements"><name>Acknowledgements</name> | ||||
<t>We would like to thank the authors of <xref target="RFC7638"/> for their work | ||||
on the | ||||
JSON Web Key (JWK) Thumbprint specification. This document applies JWK | ||||
Thumbprints to COSE Key structures.</t> | ||||
<t>Additionally, we would like to thank Carsten Bormann, Ilari Liusvaara, | <t>Furthermore, IANA has added a value to the "OAuth URI" registry <xref t | |||
Laurence Lundblade, Daisuke Ajitomi, Michael Richardson, Michael B. Jones, | arget="IANA-OAuth"/> | |||
Mallory Knodel, Joel Jaeggli, Derrell Piper, Patrik Fältström, Warren Kumari, | established by <xref target="RFC6755"/>:</t> | |||
Deb Cooley and Brendan Moran for their feedback.</t> | <dl spacing="compact" newline="false"> | |||
<dt>URN:</dt><dd>urn:ietf:params:oauth:ckt</dd> | ||||
<dt>Common Name:</dt><dd>COSE Key Thumbprint URI</dd> | ||||
<dt>Change Controller:</dt><dd>IETF</dd> | ||||
<dt>Specification Document(s):</dt><dd>RFC 9679</dd> | ||||
</dl> | ||||
</section> | </section> | |||
</middle> | </middle> | |||
<back> | <back> | |||
<references> | ||||
<name>References</name> | ||||
<references anchor="sec-normative-references"> | ||||
<name>Normative References</name> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 | ||||
119.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | ||||
949.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | ||||
174.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | ||||
052.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | ||||
053.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | ||||
747.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 | ||||
392.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 | ||||
515.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 | ||||
648.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6 | ||||
755.xml"/> | ||||
</references> | ||||
<references anchor="sec-informative-references"> | ||||
<name>Informative References</name> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 | ||||
638.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6 | ||||
234.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5 | ||||
280.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | ||||
360.xml"/> | ||||
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 | ||||
278.xml"/> | ||||
<reference anchor="IANA.Hash.Algorithms" target="https://www.iana.org/as | ||||
signments/named-information"> | ||||
<front> | ||||
<title>Named Information Hash Algorithm Registry</title> | ||||
<author> | ||||
<organization>IANA</organization> | ||||
</author> | ||||
<date/> | ||||
</front> | ||||
</reference> | ||||
<references title='Normative References' anchor="sec-normative-references"> | <reference anchor="IANA-CWT" target="https://www.iana.org/assignments/cwt"> | |||
<front> | ||||
<reference anchor="RFC2119"> | <title>CWT Confirmation Methods</title> | |||
<front> | <author> | |||
<title>Key words for use in RFCs to Indicate Requirement Levels</title> | <organization>IANA</organization> | |||
<author fullname="S. Bradner" initials="S." surname="Bradner"/> | </author> | |||
<date month="March" year="1997"/> | <date/> | |||
<abstract> | </front> | |||
<t>In many standards track documents several words are used to signify the | </reference> | |||
requirements in the specification. These words are often capitalized. This docu | ||||
ment defines these words as they should be interpreted in IETF documents. This d | ||||
ocument specifies an Internet Best Current Practices for the Internet Community, | ||||
and requests discussion and suggestions for improvements.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="BCP" value="14"/> | ||||
<seriesInfo name="RFC" value="2119"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC2119"/> | ||||
</reference> | ||||
<reference anchor="RFC8949"> | ||||
<front> | ||||
<title>Concise Binary Object Representation (CBOR)</title> | ||||
<author fullname="C. Bormann" initials="C." surname="Bormann"/> | ||||
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/> | ||||
<date month="December" year="2020"/> | ||||
<abstract> | ||||
<t>The Concise Binary Object Representation (CBOR) is a data format whose | ||||
design goals include the possibility of extremely small code size, fairly small | ||||
message size, and extensibility without the need for version negotiation. These | ||||
design goals make it different from earlier binary serializations such as ASN.1 | ||||
and MessagePack.</t> | ||||
<t>This document obsoletes RFC 7049, providing editorial improvements, new | ||||
details, and errata fixes while keeping full compatibility with the interchange | ||||
format of RFC 7049. It does not create a new version of the format.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="STD" value="94"/> | ||||
<seriesInfo name="RFC" value="8949"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8949"/> | ||||
</reference> | ||||
<reference anchor="RFC8174"> | ||||
<front> | ||||
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> | ||||
<author fullname="B. Leiba" initials="B." surname="Leiba"/> | ||||
<date month="May" year="2017"/> | ||||
<abstract> | ||||
<t>RFC 2119 specifies common key words that may be used in protocol specif | ||||
ications. This document aims to reduce the ambiguity by clarifying that only UPP | ||||
ERCASE usage of the key words have the defined special meanings.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="BCP" value="14"/> | ||||
<seriesInfo name="RFC" value="8174"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8174"/> | ||||
</reference> | ||||
<reference anchor="RFC9052"> | ||||
<front> | ||||
<title>CBOR Object Signing and Encryption (COSE): Structures and Process</ti | ||||
tle> | ||||
<author fullname="J. Schaad" initials="J." surname="Schaad"/> | ||||
<date month="August" year="2022"/> | ||||
<abstract> | ||||
<t>Concise Binary Object Representation (CBOR) is a data format designed f | ||||
or small code size and small message size. There is a need to be able to define | ||||
basic security services for this data format. This document defines the CBOR Obj | ||||
ect Signing and Encryption (COSE) protocol. This specification describes how to | ||||
create and process signatures, message authentication codes, and encryption usin | ||||
g CBOR for serialization. This specification additionally describes how to repre | ||||
sent cryptographic keys using CBOR.</t> | ||||
<t>This document, along with RFC 9053, obsoletes RFC 8152.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="STD" value="96"/> | ||||
<seriesInfo name="RFC" value="9052"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC9052"/> | ||||
</reference> | ||||
<reference anchor="RFC9053"> | ||||
<front> | ||||
<title>CBOR Object Signing and Encryption (COSE): Initial Algorithms</title> | ||||
<author fullname="J. Schaad" initials="J." surname="Schaad"/> | ||||
<date month="August" year="2022"/> | ||||
<abstract> | ||||
<t>Concise Binary Object Representation (CBOR) is a data format designed f | ||||
or small code size and small message size. There is a need to be able to define | ||||
basic security services for this data format. This document defines a set of alg | ||||
orithms that can be used with the CBOR Object Signing and Encryption (COSE) prot | ||||
ocol (RFC 9052).</t> | ||||
<t>This document, along with RFC 9052, obsoletes RFC 8152.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="9053"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC9053"/> | ||||
</reference> | ||||
<reference anchor="RFC8747"> | ||||
<front> | ||||
<title>Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)</title> | ||||
<author fullname="M. Jones" initials="M." surname="Jones"/> | ||||
<author fullname="L. Seitz" initials="L." surname="Seitz"/> | ||||
<author fullname="G. Selander" initials="G." surname="Selander"/> | ||||
<author fullname="S. Erdtman" initials="S." surname="Erdtman"/> | ||||
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/> | ||||
<date month="March" year="2020"/> | ||||
<abstract> | ||||
<t>This specification describes how to declare in a CBOR Web Token (CWT) ( | ||||
which is defined by RFC 8392) that the presenter of the CWT possesses a particul | ||||
ar proof-of-possession key. Being able to prove possession of a key is also some | ||||
times described as being the holder-of-key. This specification provides equivale | ||||
nt functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs | ||||
)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rat | ||||
her than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs).</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="8747"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8747"/> | ||||
</reference> | ||||
<reference anchor="RFC8392"> | ||||
<front> | ||||
<title>CBOR Web Token (CWT)</title> | ||||
<author fullname="M. Jones" initials="M." surname="Jones"/> | ||||
<author fullname="E. Wahlstroem" initials="E." surname="Wahlstroem"/> | ||||
<author fullname="S. Erdtman" initials="S." surname="Erdtman"/> | ||||
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/> | ||||
<date month="May" year="2018"/> | ||||
<abstract> | ||||
<t>CBOR Web Token (CWT) is a compact means of representing claims to be tr | ||||
ansferred between two parties. The claims in a CWT are encoded in the Concise Bi | ||||
nary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) | ||||
is used for added application-layer security protection. A claim is a piece of | ||||
information asserted about a subject and is represented as a name/value pair con | ||||
sisting of a claim name and a claim value. CWT is derived from JSON Web Token (J | ||||
WT) but uses CBOR rather than JSON.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="8392"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8392"/> | ||||
</reference> | ||||
<reference anchor="RFC7515"> | ||||
<front> | ||||
<title>JSON Web Signature (JWS)</title> | ||||
<author fullname="M. Jones" initials="M." surname="Jones"/> | ||||
<author fullname="J. Bradley" initials="J." surname="Bradley"/> | ||||
<author fullname="N. Sakimura" initials="N." surname="Sakimura"/> | ||||
<date month="May" year="2015"/> | ||||
<abstract> | ||||
<t>JSON Web Signature (JWS) represents content secured with digital signat | ||||
ures or Message Authentication Codes (MACs) using JSON-based data structures. Cr | ||||
yptographic algorithms and identifiers for use with this specification are descr | ||||
ibed in the separate JSON Web Algorithms (JWA) specification and an IANA registr | ||||
y defined by that specification. Related encryption capabilities are described i | ||||
n the separate JSON Web Encryption (JWE) specification.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="7515"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC7515"/> | ||||
</reference> | ||||
<reference anchor="RFC4648"> | ||||
<front> | ||||
<title>The Base16, Base32, and Base64 Data Encodings</title> | ||||
<author fullname="S. Josefsson" initials="S." surname="Josefsson"/> | ||||
<date month="October" year="2006"/> | ||||
<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"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC4648"/> | ||||
</reference> | ||||
<reference anchor="RFC6755"> | ||||
<front> | ||||
<title>An IETF URN Sub-Namespace for OAuth</title> | ||||
<author fullname="B. Campbell" initials="B." surname="Campbell"/> | ||||
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/> | ||||
<date month="October" year="2012"/> | ||||
<abstract> | ||||
<t>This document establishes an IETF URN Sub-namespace for use with OAuth- | ||||
related specifications. This document is not an Internet Standards Track specifi | ||||
cation; it is published for informational purposes.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="6755"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC6755"/> | ||||
</reference> | ||||
</references> | ||||
<references title='Informative References' anchor="sec-informative-reference | ||||
s"> | ||||
<reference anchor="RFC7638"> | ||||
<front> | ||||
<title>JSON Web Key (JWK) Thumbprint</title> | ||||
<author fullname="M. Jones" initials="M." surname="Jones"/> | ||||
<author fullname="N. Sakimura" initials="N." surname="Sakimura"/> | ||||
<date month="September" year="2015"/> | ||||
<abstract> | ||||
<t>This specification defines a method for computing a hash value over a J | ||||
SON Web Key (JWK). It defines which fields in a JWK are used in the hash computa | ||||
tion, the method of creating a canonical form for those fields, and how to conve | ||||
rt the resulting Unicode string into a byte sequence to be hashed. The resulting | ||||
hash value can be used for identifying or selecting the key represented by the | ||||
JWK that is the subject of the thumbprint.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="7638"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC7638"/> | ||||
</reference> | ||||
<reference anchor="RFC6234"> | ||||
<front> | ||||
<title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</title> | ||||
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/> | ||||
<author fullname="T. Hansen" initials="T." surname="Hansen"/> | ||||
<date month="May" year="2011"/> | ||||
<abstract> | ||||
<t>Federal Information Processing Standard, FIPS</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="6234"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC6234"/> | ||||
</reference> | ||||
<reference anchor="RFC5280"> | ||||
<front> | ||||
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate | ||||
Revocation List (CRL) Profile</title> | ||||
<author fullname="D. Cooper" initials="D." surname="Cooper"/> | ||||
<author fullname="S. Santesson" initials="S." surname="Santesson"/> | ||||
<author fullname="S. Farrell" initials="S." surname="Farrell"/> | ||||
<author fullname="S. Boeyen" initials="S." surname="Boeyen"/> | ||||
<author fullname="R. Housley" initials="R." surname="Housley"/> | ||||
<author fullname="W. Polk" initials="W." surname="Polk"/> | ||||
<date month="May" year="2008"/> | ||||
<abstract> | ||||
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate re | ||||
vocation list (CRL) for use in the Internet. An overview of this approach and mo | ||||
del is provided as an introduction. The X.509 v3 certificate format is described | ||||
in detail, with additional information regarding the format and semantics of In | ||||
ternet name forms. Standard certificate extensions are described and two Interne | ||||
t-specific extensions are defined. A set of required certificate extensions is s | ||||
pecified. The X.509 v2 CRL format is described in detail along with standard and | ||||
Internet-specific extensions. An algorithm for X.509 certification path validat | ||||
ion is described. An ASN.1 module and examples are provided in the appendices. [ | ||||
STANDARDS-TRACK]</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="5280"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC5280"/> | ||||
</reference> | ||||
<reference anchor="RFC9360"> | ||||
<front> | ||||
<title>CBOR Object Signing and Encryption (COSE): Header Parameters for Carr | ||||
ying and Referencing X.509 Certificates</title> | ||||
<author fullname="J. Schaad" initials="J." surname="Schaad"/> | ||||
<date month="February" year="2023"/> | ||||
<abstract> | ||||
<t>The CBOR Object Signing and Encryption (COSE) message structure uses re | ||||
ferences to keys in general. For some algorithms, additional properties are defi | ||||
ned that carry parameters relating to keys as needed. The COSE Key structure is | ||||
used for transporting keys outside of COSE messages. This document extends the w | ||||
ay that keys can be identified and transported by providing attributes that refe | ||||
r to or contain X.509 certificates.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="9360"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC9360"/> | ||||
</reference> | ||||
<reference anchor="RFC9278"> | ||||
<front> | ||||
<title>JWK Thumbprint URI</title> | ||||
<author fullname="M. Jones" initials="M." surname="Jones"/> | ||||
<author fullname="K. Yasuda" initials="K." surname="Yasuda"/> | ||||
<date month="August" year="2022"/> | ||||
<abstract> | ||||
<t>This specification registers a kind of URI that represents a JSON Web K | ||||
ey (JWK) Thumbprint value. JWK Thumbprints are defined in RFC 7638. This enables | ||||
JWK Thumbprints to be used, for instance, as key identifiers in contexts requir | ||||
ing URIs.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="9278"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC9278"/> | ||||
</reference> | ||||
<reference anchor="IANA.Hash.Algorithms" target="https://www.iana.org/assignment | <reference anchor="IANA-OAuth" target="https://www.iana.org/assignments/oauth- | |||
s/named-information"> | parameters"> | |||
<front> | <front> | |||
<title>Named Information Hash Algorithm Registry</title> | <title>OAuth URI</title> | |||
<author > | <author> | |||
<organization></organization> | <organization>IANA</organization> | |||
</author> | </author> | |||
<date /> | <date/> | |||
</front> | </front> | |||
</reference> | </reference> | |||
</references> | ||||
</references> | </references> | |||
<section anchor="acknowledgements" numbered="false"> | ||||
<name>Acknowledgements</name> | ||||
<t>We would like to thank the authors of <xref target="RFC7638"/> for | ||||
their work on the JWK Thumbprint specification. This | ||||
document applies JWK Thumbprints to COSE Key structures.</t> | ||||
<t>Additionally, we would like to thank <contact fullname="Carsten | ||||
Bormann"/>, <contact fullname="Ilari Liusvaara"/>, <contact | ||||
fullname="Laurence Lundblade"/>, <contact fullname="Daisuke Ajitomi"/>, | ||||
<contact fullname="Michael Richardson"/>, <contact fullname="Michael | ||||
B. Jones"/>, <contact fullname="Mallory Knodel"/>, <contact | ||||
fullname="Joel Jaeggli"/>, <contact fullname="Derrell Piper"/>, <contact | ||||
fullname="Patrik Fältström"/>, <contact fullname="Warren Kumari"/>, | ||||
<contact fullname="Deb Cooley"/>, and <contact fullname="Brendan Moran"/> | ||||
for their feedback.</t> | ||||
</section> | ||||
</back> | </back> | |||
<!-- ##markdown-source: | ||||
H4sIAAAAAAAAA9Vc63IbuZX+zyq+A1b+YSlL0rxTYlVqQ91ijW3JEeV1sqlU | ||||
CuwGSYya3UyjKZnj0jzNPsO+QF5szwVAoynKnpnsn01NZSgSDRycy3euPc1m | ||||
s14rdJGosTg7vbkVN7MfVVSIqV6kOl0ImcbiIo3y7brQWSoOz26mF0findqK | ||||
u+VmNVvnOi3qNTmb5eoBdoBfn/0YZ1EqV7B/nMt50dSqmDejzKjmvdo2C7+w | ||||
2R7Wa5Es1CLLt2Nhirheq9f0Oh+LIt+Yottun7S7cFau5FhMVbTJdbGt1x6z | ||||
/H6RZ5s1H1+vwbbwXTwWV2mh8lQVzXM8GHczBdzn7zLJUiBnq0y9ttbjek2I | ||||
fB6p2BTbxH0vRJFF4Wedxiot/Dcmy4tczU35xXZV/bvIdVSuj7LVCp4vf9dp | ||||
otPgNPWlaCbaFE3YaJYlsLCZ/e7f8Sfg30qu1yANuxp4sCmWWY6UN3EF7gYP | ||||
vGuJK5PNFH/FPH+XLZUOv1YrqZOx0PjNPf74hwV+0wICeUGWwznTi7ObD8DP | ||||
VkO8vztv4ZmVo962xJ2JltlcpXoRnvdWpqkyz350CvK2eXo79efIVP8kUa/G | ||||
4lOqH1RuQKIim4vJep1oFYtppFUawX6nWZo2b4HatDnVym4aZZu0QF35o8pX | ||||
Mt1WLrgkQlqFJwTu+aUF2vDsLjctMS2USip8u8m1qnxdJfcul6lZbYoqUzN4 | ||||
6A+F+6kFKrNBNWAJB/TCZQu8XQHaTvJMM7hAARwgZby9POt2Oifu8/FJv/zc | ||||
GfXd55P2oBt87vk1o/7If+6d+DWjQWfgPveH/eMx2Vc63z17NOwdu8/Dbs+f | ||||
N+get/15vWH5uTvi9VeT60nrrTTL1iQBI9bFcmXGfHVhIebgGrgbg2XaUwFS | ||||
8AHhHxC3agFWkG8P3IMyXyiwo2VRrM34zZvHx8eWlqlsgUDeSGMAp8iw3qDc | ||||
4qYud7YbxMDksZjLxCi8cLPZBG2EE2REqnC31EaYtYr0XEdMUazmGpVYipUC | ||||
O4sFbIkGvN4UBImgW0Dyg0w2SmSgtfANQme99kuxE+y0cGfCOY9LHS0FfExi | ||||
+AO4oIH2YqlKOAVyN1GxyZUA9AOtjZJNDGzUqcBldEK2yOUaNmLimFq6ToP3 | ||||
WucZGJLhuwCE2qtEMs1SuHgicrXOlQFWMhPACuExoyxdDbrNMnuE3TI+A3eF | ||||
JzYJbTXbFkoY9Y8NGiygQ+XHkmEN+Hau8hyoLzIAMuTyQekEGgdIkZgpsTG0 | ||||
RGiEXT0HWMhh+wT5S3fOYA+zztIY9wfIbznhrnQcJyTqV+gB8iwG1pE6/HJh | ||||
A9wmW8ugkLn1Gt1kvklpS6RP/jq3iT7IyfLrV2vFT0+NgFkg1YqK3afZI3wF | ||||
JNZrAataB+IOjo+WWj0o4IkGGSFnwF1s0CJeUDA0efErlOuZOuG34De/p05o | ||||
hi8qEcn++0p0kyq7BaivXsl8i2oBhxhFJ6Nmg0BLnoBbI0YhiON+AP5qpYhI | ||||
p0f4tVcl+IOtAxSoIcwGuASPz/AYXFdhUxnSWLmw7t7rGKDqEDYQV+dHLTFJ | ||||
M3gsxx09scDLhyx5AKLx21jl+oGVzymSQSpkQQ/goeWNDDJgvZklYNnwMFw7 | ||||
z1a0RqXxOsMVwFUIaOAiCB2CT4+yFCOKBmoonQfkYogCOp7zTq0X7CHbFAkZ | ||||
BImpSofjhSFNWahU5QCuEKchg2dwMvDEn4GirpxoxKFRqPXlrk9PuKxe+/o1 | ||||
B6FrQIWnJ+RhHGskRiYJiEWDWK0dk52m6pFt7rOagQncKzDtw7PPd0d467l2 | ||||
foXNuWGVHxUjjhlSkHvoq8Cc4DFxFj71gZ4yB6CU7IeEgqAR2G+W8DBoBhkt | ||||
utinJ2DhJVx8vsmJ57EqIAoARrHhoCyBZ7JKVZRIvWITh7OtzCSiczZvwj/r | ||||
zIByG1xKOkloiURPFUNOr9XBbatkINbdQRCk0yzJFlsWLWm1wFDYiIMPn6Z3 | ||||
Bw3+t7i+oc+3F3/6dHV7cY6fp28n79/7D7wC+DN9e/PpvV2An8pHIT78cHF9 | ||||
zk/Dt2Lnqw+Tvxw0WLoHNx/vrm6uJ+8PGFRAFh6kUJHgdjO0EYjWwQVhZASm | ||||
FSsT5XpGQFSvnZ59FJ0+3xpjI1Ac5gDEQ/D5calSBpcsTbb2TxDCFpFcyZwY | ||||
niSYX6x1AaFAA48wSwRWEJ2yLNxn619fBerqGBsgDonYP0jsnSkLmHyTeZYk | ||||
2aOhcKvTQnVjxLXP/b2KwWQjTtgjL2p2E6TioGUpARdGpXhdxlC2H7GWOQRC | ||||
wEpTenSHZagPO6wVtI07r89wGwiIONNtUUTOJ8W4OWgaWAfYNQB1Ri64sqnf | ||||
r9UN1RUC2acnOtBa4U7METnW8C6mUGtx2DkiGnotjhTxMXQTBm0GISFY2j0S | ||||
1p72hETeab9tEQlouuqLXK0TCEpA65vdwZDpxKAXlGoltz4QIayvbNNyuuDN | ||||
3nIu8JWk3SU8BAwymxm7OYhBDTPL+B0dMXSe9JGx0y2zWa8h+1SAbQz2fokR | ||||
YHWVJVaxb512eEX9WKrJ11cefHH1zbdUirQd1Oi12ZUdXpVYhcYHhubDZQ2+ | ||||
40UnioEiuiCrL2azAi+vf1KGo4w9JHguHdwX2wNxmMiZgtSrcyTAoxOkOD5Z | ||||
8jigSxLS/mK7VjYMwSsi5iwUxBHs0V3E5IMf9BIB8fhw6RjcOXhrDngL+B7z | ||||
DQjU8CB0OhANWLagYpIRQoprSaW7fIDMtTwj4DVy1PlmZzCQzMKd/FX4WAYY | ||||
ggTSK1YngdWEFwVpU5oVAQgR6NnDOvNK3IAdFlZZdC4Ob959PHLMf2lLlSR6 | ||||
jbgQbXKIOcLApRLgwF7+wAaSzZHXn7uDQeekgVcnuGzuSrlB7KXHxii9BqsR | ||||
yp9WR/lDubrZ8T/DUl7wJfi563/GfJDudm6N2SYhc8jYK4A2CuAMc27nfV+J | ||||
C3fzM7o5RUkk8z83Sd3+0jzLwBXrFCImZujXVyqKnv6vOHpx1i05SqEsZVfX | ||||
V6CkHxFOfgtXuy9wtbp8L2eDJZa7sCY4tNnbt+Y3S+A6wyw/cJUOAw0HpohH | ||||
gAeE5bAhgHj5BYXRCDYhoJkWeQiKSrI1BLoznegCw1H0GCu/DMJKwGDysJnN | ||||
R6oBNcGEk9Lzc3dwtEXaAFFflivO57bNqFQc2F198RdBp4SMa4krwGVA3Spt | ||||
eKqx2fI3D8UYG4AICYVIFVADHPGDygsMvS3wVAin3A6VkzKzTQ5BK4A1OUAP | ||||
75ADRptEelcJJnI7nYiPrL9oHt/TfFAAfKLU+N+gwD3Wu/RF9S11U31Pf+kO | ||||
U5/R/KIrVDOg33CBPhN3/70LEHFvp9Pm+w/T71FllzGI/HqSBkwSyOUXEXWD | ||||
MQpxamJEmRuTg6Qd2dNxHSZmna9YEDxLP9oodoVx+yaJKc7RK53IHFwYho6b | ||||
pOAEz4WoipO/eq1kQINSAZtfOuXmm1unTDjpeWcDqA/aRIDEMlXZxlAIr2NM | ||||
fpk8uufn5VYACokrLqCImzWnsPtirv+gQMstqMZX1SQb8Sd1uTBFEzsFmnpt | ||||
X3AVBqEmY08Bi8HrSAgQ0khhDYQhIFLPS0Jxpjh0kcDSfKdI4wO38gHUt0oN | ||||
RsR6AYmzq94gbMAtqnf16onA6QEpTFTKxAoSYUmqAzcB+UHEJH2NwEVceMeV | ||||
XiyB6gjvj6vsZiTFU4i7viDvqAT0nPmNF+s9qFwQTAF1yRZJnSP5VneQVAhx | ||||
VTJvEMeoJEiJN2UiJZWyABiYQVKIAda5nsMmlABjqyPy+Q9WbQylHlbOwO5c | ||||
o9J5isuNvlHLI5fAtbc9VxWPKij1+W32w3djn/wxz0EjjOkirhgHFgkn2CrX | ||||
WnFx1tZDSrJdZN6ytsKLOOvYG/NDlmngTsbr8V4p5diFQXMsxWVBeKEflK+n | ||||
LGQeJ1i6xFymqkgVEYVCutdpbDO8siAWORSy0IXVIca3XfgKVNNJ1WQrskFM | ||||
TAIK9uQBgFhz9ORYvDAEltogsKEEKW6Ov03moyMT9phvEueMp1wA5Uo/ZdaX | ||||
NrMlqC4zj2ryvNqAVc98IgJXRnsMdBj03xY/WCHCXsm8rCjrFJa4EAvbstH+ | ||||
LLxe20nD/Q4+EQfk1UmZNRP8LLIsRrlI0Flg3DLTEWoga7leES2PkDOD6jVs | ||||
fdm1JXbuC6crKt5SOP283QI+ITaRXKMaPKgkW7PuXOGjoF0ks0ZZpwG5FlvW | ||||
Y1c/NR5HUqViw+UwOO0R8T/kmSeKM85KAcNtYYsiOatbvfa8ovysei3K4vVV | ||||
yioFzi5F2DG22k/edQW7WnL4uQLr/gaDRNwMFGkt/7GxTh0UPFFwZzTAe2p7 | ||||
OH0j9rzNHoFbeYOqBaBUgCxwDeKOVs7zEdvJz6F3wHvZ1gqXF2T+jRo9l43B | ||||
SAEP0e845NhSOwW4i0mA5Q1h1rPGDmNOgP0WAn1+fFctjpPLviYHXRJ0Sc1I | ||||
fOCdz9j4chYquFvp0x3vBlnZfSwAZ07SrdUeeDgoE7uSDG+uze4eQXUywhzB | ||||
3XoP01rCReqKod8s9Rp5cU7enK7559agfSL+k3wArn6xtMNS9IXQbMdTZdww | ||||
eyEIkBatQ6ef7EZKwc28YyB3bIKtSIFaAskzriYMdK0y7HcB5GYLdK7otUsQ | ||||
Y0Exq+Ldq083THmZyVA7WxxOP767OrJ3d20HOMpGr7uF0U6r2yrLu9hbxy4g | ||||
3fQXEYOMTYAVAoy9YGej/OEWqQ6+DAowb6IbbCZYiGDZCUDhyKbOvSGQYS3Y | ||||
kY0mvGcLFqChWBH4yyAM7MTuHxg+yhX2oYguCwNCdgvIrP0tZ5a83OvifXkV | ||||
FepB2ZiDmkH79gKdeKZG3LBPxWR63ersJv34mC6cge9pDOEvQeulbEzF+5pP | ||||
nG6h4CgY5CEB37UyArtW5qgsDfq8xMFslM4PuGXUwnaRAZRCRzRTKhWBVjFF | ||||
vZPu05MrqFZKELCvbZwRlO+SKWbSsIXu4XlZcH2hR4VCsc1VrJyWndOD6L6w | ||||
1Dd25hnC2JpvR1Rzc8y2OFiFXeTw8gbUgfDVEJ1ilxinbtIF+jNAbhnT81jt | ||||
3KTEEkughEg5jLm8ky52NC59UFtKBYlKsM08k1SwRKcYRKU5MH2tlc2BZgm1 | ||||
trIZ3ob9aMAnf2rJsKKSceBTZSWamAmXYG5d2TaaI4X9vwZ62EdTcxE0BJaH | ||||
YTO27RkUc+dBqKNKbhfDfU7NuTq+eyeMP9Nq8EOGbhXKRVG8/WvD6kLda68u | ||||
tkbEKD1zKQ5PDgTa4u4Md/DK52vcLuSB262oXeQjKNtw3VE9Sm6YH6AheFO3 | ||||
aJ8lHJItYgO8OYPo5t5gdKpy3+RWYKBZrmlcRho4/4iKJz///DP1lL7yzNEb | ||||
kMQb0RFjICSTNLYkTcsSjpN22FulhXITvxG9cCFwMNvkkfLLs3zhl6sv6zei | ||||
D8s7vWGnd3J83O27nwAq3ohj+MnSgF/dF2/EX/96d3re+dvf4Jfl6/7JcBYf | ||||
y7mM5732SA1m7eNo2J+1+93ObH4SR+7R8H/tDjgn2ev3Zb83i+XxMTwdd4bD | ||||
k1h2Bz0VvbYPcWPvyTIDYRK7J4CR3DChlLkqGt+G2SOJlm3yhFpBtU8V2SKP | ||||
ywm8gZRY6fB7D1p8ur0y35kE+pRqKnDeWkmIK2e1cIVD3OCIhqDCaOWbDS7U | ||||
VZxTc51gxjKcW3Wq+MP05prGGXCLwx8+vzvapblRNqdIo9ldd0fHHvIhYgfE | ||||
2dtrMwG/GlaRXeIgeShFB3fUQSWC4zO0O6Si9Z0RKlhDmZT+ApvEJdZ6+Mny | ||||
0L/h8tKwXRqGD5v9PN0DB+GRxjtFHBxjAlQJZfZ0j0K/+vjQ1jd5OsZR5jHF | ||||
pGac4UzuGNTVG8BdBingvSrzt7KVO1N4IqkvqDREejTjwgxsBJSAqN38ANcX | ||||
5O5OpdzImvaSbdubDaHQaxmFFBduvyhLsPK0lDgQyaMmpP0szHCEAJKmF2Xy | ||||
9iWqjDfSl6zR91EfbE7hJ5wOaFecGBVTcugHSO1mlVbas89HSi05e2ZKBYPS | ||||
7pAq2tDLYEEu4UW2c53Ut6nILfsWMWYa8LMtScUKEx24puYmVCXIJy5g4RoH | ||||
Q3BKDv4v4bm+ek3leQbJsi18g7JkUbTJifNTjdVcVudrwsgwHuJAiFUq2xQQ | ||||
OTvb21u6DcvGlXmFnaEtJzIMHIf9TZ4AifZY5BacBJ42Rs/e8hEzjh9jW85P | ||||
JZ66h8shkp1pmQNeUv5exkqfbt9zX3UOaQeO/jaNnKtAjw1Oeu/JvAbIACBH | ||||
4Ag0wyh+wuSLK7aQZkJQoRM86fXvX2P1yO4JeddKF4VtIbqL8hwBBDI+G4dE | ||||
HSMIwREEAC7kghCkrCXWuAB77dRGWfUrT4BECjuZJWbtcphqpbaovlrjtDx1 | ||||
6d3MpNAm+M2GwfXa4VQpHOHBiuwXcebTTisTdAigpopm13wPkQYy9xy/K+Gj | ||||
A4fKs+cStbQGoS1PXZFOWSeEeRQoOf8wUyB+G4fJIBKz43tIKvwZ23as6z4a | ||||
HhIi5J1+fvhLPuz9dNr8/PjjH6ePf1o+DHqTy6n+8fbdn0bd7Mdh7/a/1l39 | ||||
qflYYjX6lA2I3kWX1fJCFROQyQGx4EMXEofUXqC5pOxFnzE2S4nFy/Fvo/6V | ||||
uLBkf33leFoGOVbxn8XL3+sb2QYvxgu7sXdZUfLjaJhTX5ydBe1aujcWKWeq | ||||
QIsMxMaA5HZDH0dt57Bkw1l9rOUizWjSjOGdNYMjKJx6dZaGCTVRHGuzTmSp | ||||
GJTVBdpRBuk0iQMwgS4Ppyd+v3eG4w2v7oy7LtKGHOjBPUeTFW5NszPu+EUl | ||||
H8biS9jCd4u74+Xr4UDFciA73cFoFHVnUh13T/q90Vz1esejdkd22lLK3mig | ||||
OrPZYDaIVad9HKt+7yRq12vHg0Enfr33wO2+A3twYEcNuioeDWDzzrA3H81P | ||||
VL8dx/OTea/fmfXi6GQmj4dtOR+pdiRH8I86USqK2+3jeq0fd06i8sB7cGMg | ||||
Ouz1Nso5pxc8vSUCL92BvFTGqjuX+K8e5Q9PFUt0iiFn2UM46u+bbqVGkpY4 | ||||
tAGgc/nbvUXfADb2a0YZ000G7U672223O93O4LjbHg4uzieDCQnnrHs6uWDh | ||||
XF6wcCad9mQyAeFcdE5PB6eD8wsQznm9dgHiOWujcM67XdynczHoXpw7nl+O | ||||
Lk8u+u3z88uTS+D5ae/87OR0AjyfXI4u2meTEfxzcQLbXJydA9f75x3YDffp | ||||
D8+Hg1F3eDLsDPvDy2GvezHswt+d4cWwPzqBz4Nhb3jab7tPw7NhvUa/wsrB | ||||
6BhWno/a8O3AM/uaWryJH7IP5gT8mHlFFn7Kb6fx+GIUYXx48tI4Yboz4gRZ | ||||
QmXiQxxKnmVzkQhOTT0dcdO+wcNJDRw/4rG+g+2BzxLKnuXzBmnjGxjDEBNW | ||||
AUot2gdmvoCHY7GrzSq4ou+tkhZDbAdmic7fzhyTHBiQHMJ4FPlFCOEz9m9A | ||||
RQAUvwgE/J7fQAPGgnqtNNyrtGqMQdcYYeJ5ZeWZZaLkXzDN/r9ommAIYJz/ | ||||
kmnWa844Q9P01/9EoaltQu62zCsFxfJa3yvHfK/0EgQA7n3YPbMpk72A/KjR | ||||
7mn6M9UQPCbb8lWrZxVBPceXj/CGCY6CydVMLzY0CeN23qmjc+zA9fcwL6fm | ||||
nR8TDl6qe6kjRbr4//wO9HeYMfq0cPdlq/0DGOKwnHPCgjKlD26qIxxuClG5 | ||||
+lrBkZsHKVMVKoP4Lv++IZFvE4Vl/xWWVCRWGHjQImB5kNw2xJ6xSB5LwLCB | ||||
5tU1vmTDmMidpN2GtXG+B8L0Zy90JZBwF3qF0Q4OtTWqDeLdjexYtgSBJ5rK | ||||
9CslU/JG5YAQRb62pFzVJMAy1Ax8zdeXHCiizlU2P3KvPmJ1mNIa7vmmOFwi | ||||
o3vszEMMgsOpyXancSt3NvWtXXIi7Djo5UtwxLpwr7ZwaU+GYyD4hunOaIWe | ||||
Y/km4BOOVtp31OjlxyzegF7Yfss11ycCoolgepM5mG5yD/V+d82IB19wd4Pf | ||||
PEIJg18FI6ViJ4QQkDZ23vR8BQ5HMRpiBt/y4u9cCbXjox8E2Hk5bedds2CW | ||||
QsRZaltwETpecc6TGuSeqZRhe/0+665ObS7xXaHNHFSXejsKe35rMkXAiwdq | ||||
jTg+Gfut7VKKgmuyz8lzIYPOq6+y2tciWVNdW4xnA+xhiBbzPVSSAoH+xNkq | ||||
8fMWVhSoSAVIX0KS1ekei5nGv9JFsWxVysTu7TBfXLdJ7Voawy+S+fIFxN9N | ||||
xwlIMXNVGB5DxqqLZS/StEldIyycylRcAgHN2OGLCy5xUiEcKyKlfy4EUrv0 | ||||
26pgZRxcixpoPH6TNHxR6VvaxJU30Ft0NkHngTANJ8eCUh7tvsqw2V3wiz/r | ||||
JNvyK7lurgYsmkyexxCwiwdHU7E6E+BMEv1TVf+fv8/KsFA6FTuoym+sVGIA | ||||
8fUVdWIoSMOfNZf1lbGdFAgqdrIq5O42fFVSPHtTErj6K16VtCPGezrqVN8d | ||||
Cyqc719wToXINf+HF7x/deNeYZm7KX7Y/z6nPeTHPYe8w3zZNcme/UpzLvTi | ||||
z6E5Glfby7R4KdOFwmdAHZNE5WNxdXF3iT9NK+7u3L5PR9vAceE7dnhuvXbJ | ||||
74mtaPD/RTlJi9AV2dxMNmCkn26vSlnUa6EwyIi/fv03HKsbDQZeHp9ur8ff | ||||
bGUgO/AlIcvAlypiASuigBXf4QUs2MuJV2IS4ZRWouIFVSIpjP2srJNI9L29 | ||||
v4Q0nxr59J9DMWVZc9g7tmVNhljutdkm/LebbZUoxQJw+bYqO0FQs3dhxkuo | ||||
/zzFZJusvsz8uP8WZzLHGTNxir4/hYjpCoINLd7rjXmQIBWIaN5L2BKT6feb | ||||
NJ4lMgY1OZfabGCfyY+6yFa6IT7oaClVIm7x34DXGHy5705b4gdwhBgdfQBi | ||||
MlDkd2kWK4DAHzL4/QepFosENjnHQUiA5o96jSN6HyWo+724/Od/J/iC2z// | ||||
Z9UQnyUsAePZ4Ot6DXxrZwaakiV2euAUfozBa33IwCEFcpiDU56BowTG/C+x | ||||
7bnGeUgAAA== | ||||
</rfc> | </rfc> | |||
End of changes. 91 change blocks. | ||||
817 lines changed or deleted | 413 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |