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 "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?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="December"/>
<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&nbsp;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.
The only prerequisites are that the COSE_Key representation
<t>Keys that are in other formats can be represented as COSE Keys. of the key be defined and the party creating the COSE Key Thumbprint
Any party in possession of a key that is represented as a COSE Key can be in possession of the necessary key material.</t>
use the COSE Key Thumbprint.</t> </section>
<section anchor="relationship-to-digests-of-x509-values">
</section> <name>Relationship to Digests of X.509 Values</name>
<section anchor="relationship-to-digests-of-x509-values"><name>Relationship to D <t>COSE Key Thumbprint values are computed on the COSE Key object containing onl
igests of X.509 Values</name> y essential parameters in a specific order. Thus, they are more analogous to ap
plications that
<t>COSE Key Thumbprint values are computed on the COSE Key object required to
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="relationship-JWT-thumbprints">
<section anchor="confirmation-method"><name>Confirmation Method</name> <name>Relationship to JSON Web Key Thumbprints</name>
<t>
The ckt of a COSE Key, as described in <xref target="RFC9052" sectionFormat="o
f" section="7"/>, and the jkt of a JSON Web Key, as described in <xref target="R
FC7517" sectionFormat="of" section="4"/>, are different even when
the underlying cryptographic key material is the same.</t>
<t>
This document does not register
a JWT confirmation method <xref target="RFC7800"/>
for using "ckt" as a confirmation method for a JWT
or a CWT confirmation method <xref target="RFC8747"/>
for using "jkt" as a confirmation method for a CWT.
</t>
</section>
<t><xref target="RFC8747"/> introduced confirmation methods for use with CBOR <section anchor="confirmation-method">
Web Tokens (CWTs) with the addition of the "cnf" claim. CWTs have <name>Confirmation Method</name>
been defined in <xref target="RFC8392"/>. This specification adds a new <t><xref target="RFC8747"/> introduces confirmation methods for use with
CWTs with the addition of the "cnf" claim. CWTs are defined in <xref target="RF
C8392"/>. 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" member of
<t>The proof-of-possession key is identified using the "ckt" claim, the CWT confirmation claim "cnf". This member 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 member. 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" CWT confirmation method member 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" member
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.
The "ckt" claim is expected to be used in the "cnf" claim.</t>
</section>
<section anchor="cose-key-thumbprint-uris"><name>COSE Key Thumbprint URIs</name>
<t>This specification defines Uniform Resource Identifiers (URIs) <t><xref target="IANA"/> registers the "ckt" CWT confirmation method mem
ber.
The "ckt" member is used in the "cnf" claim.</t>
</section>
<section anchor="cose-key-thumbprint-uris">
<name>COSE Key Thumbprint URIs</name>
<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
E439C08551D2258201E52ED75701163F7F9E40DDF9F341B3DC9BA860AF7E0CA7CA7E9
EECD0084D19C025820496BD8AFADF307E5B08C64B0421BF9DC01528A344A43BDA88FA
DD1669DA253EC]]></sourcecode>
<!--OLD
<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>(none)</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.75
17.xml"/>
<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.7
800.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. 92 change blocks. 
820 lines changed or deleted 447 lines changed or added

This html diff was produced by rfcdiff 1.48.