rfc9360xml2.original.xml   rfc9360.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!ENTITY nbsp "&#160;">
C.2119.xml"> <!ENTITY zwsp "&#8203;">
<!ENTITY RFC5280 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <!ENTITY nbhy "&#8209;">
C.5280.xml"> <!ENTITY wj "&#8288;">
<!ENTITY RFC8152 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8152.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC8949 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8949.xml">
<!ENTITY I-D.ietf-anima-constrained-voucher SYSTEM "https://xml2rfc.ietf.org/pub
lic/rfc/bibxml3/reference.I-D.ietf-anima-constrained-voucher.xml">
<!ENTITY I-D.ietf-lake-edhoc SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3
/reference.I-D.ietf-lake-edhoc.xml">
<!ENTITY I-D.ietf-tls-dtls13 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3
/reference.I-D.ietf-tls-dtls13.xml">
<!ENTITY RFC2585 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2585.xml">
<!ENTITY RFC2634 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2634.xml">
<!ENTITY RFC3986 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3986.xml">
<!ENTITY RFC6838 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6838.xml">
<!ENTITY RFC8392 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8392.xml">
<!ENTITY RFC8446 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8446.xml">
<!ENTITY RFC8551 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8551.xml">
<!ENTITY RFC8610 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8610.xml">
<!ENTITY RFC8613 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8613.xml">
]> ]>
<rfc submissionType="IETF" docName="draft-ietf-cose-x509-09" category="std" ipr=
"trust200902"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<!-- Generated by id2xml 1.5.0 on 2022-11-16T00:19:45Z --> std" consensus="true" docName="draft-ietf-cose-x509-09" number="9360" ipr="trust
<?rfc strict="yes"?> 200902" obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="true" toc
<?rfc compact="yes"?> Include="true" version="3">
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?> <!-- xml2rfc v2v3 conversion 3.15.2 -->
<?rfc sortrefs="yes"?> <!-- Generated by id2xml 1.5.0 on 2022-11-16T00:19:45Z -->
<?rfc text-list-symbols="**o+-"?>
<?rfc toc="yes"?>
<front> <front>
<title abbrev="CBOR Object Signing and Encryption (COSE">CBOR Object Sign <title abbrev="COSE X.509">CBOR Object Signing and Encryption (COSE): Header
ing and Encryption (COSE): Header parameters for carrying and referencing X.509 Parameters for Carrying and Referencing X.509 Certificates</title>
certificates</title> <seriesInfo name="RFC" value="9360"/>
<author initials="J." surname="Schaad" fullname="Jim Schaad"> <author initials="J." surname="Schaad" fullname="Jim Schaad">
<organization>August Cellars</organization> <organization>August Cellars</organization>
<address><email>ietf@augustcellars.com</email> </author>
</address> <date year="2023" month="February"/>
</author>
<date year="2022" month="November"/> <area>sec</area>
<abstract><t> <workgroup>cose</workgroup>
The CBOR Signing And Encrypted Message (COSE) structure uses references to
<abstract>
<t>
The CBOR Object Signing and Encryption (COSE) message structure uses referenc
es to
keys in general. For some algorithms, additional properties are defined keys in general. For some algorithms, additional properties are defined
which carry parameters relating to keys as needed. The COSE Key structure that carry parameters relating to keys as needed. The COSE Key structure
is used for transporting keys outside of COSE messages. This document is used for transporting keys outside of COSE messages. This document
extends the way that keys can be identified and transported by providing extends the way that keys can be identified and transported by providing
attributes that refer to or contain X.509 certificates.</t> attributes that refer to or contain X.509 certificates.</t>
</abstract>
</abstract> </front>
</front> <middle>
<section anchor="sect-1" numbered="true" toc="default">
<middle> <name>Introduction</name>
<section title="Introduction" anchor="sect-1"><t> <t>
In the process of writing <xref target="RFC8152"/>, the working group discuss In the process of writing <xref target="RFC8152" format="default"/> and <xref
ed X.509 target="RFC9052" format="default"/>, the CBOR Object Signing and Encryption (CO
certificates <xref target="RFC5280"/> and decided that no use cases were pres SE) Working Group discussed X.509
ented that certificates <xref target="RFC5280" format="default"/> and decided that no us
e cases were presented that
showed a need to support certificates. Since that time, a number of cases showed a need to support certificates. Since that time, a number of cases
have been defined in which X.509 certificate support is necessary, and by have been defined in which X.509 certificate support is necessary, and by
implication, applications will need a documented and consistent way to implication, applications will need a documented and consistent way to
handle such certificates. This document defines a set of attributes that handle such certificates. This document defines a set of attributes that
will allow applications to transport and refer to X.509 certificates in a will allow applications to transport and refer to X.509 certificates in a
consistent manner.</t> consistent manner.</t>
<t> <t>
In some of these cases, a constrained device is being deployed in the In some of these cases, a constrained device is being deployed in the
context of an existing X.509 PKI: for example, context of an existing X.509 PKI: for example,
<xref target="I-D.ietf-anima-constrained-voucher"/> describes a device enroll ment solution <xref target="Constrained-BRSKI" format="default"/> describes a device enroll ment solution
that relies on the presence of a factory-installed certificate on the that relies on the presence of a factory-installed certificate on the
device. The <xref target="I-D.ietf-lake-edhoc"/> draft was also written with device. <xref target="EDHOC" format="default"/> was also written with the id
the idea ea
that long term certificates could be used to provide for authentication of that long-term certificates could be used to provide for authentication of
devices, and uses them to establish session keys. Another possible devices and establish session keys. Another possible
scenario is the use of COSE as the basis for a secure messaging scenario is the use of COSE as the basis for a secure messaging
application. This scenario assumes the presence of long term keys and a application. This scenario assumes the presence of long-term keys and a
central authentication authority. Basing such an application on public key central authentication authority. Basing such an application on public key
certificates allows it to make use of well established key management certificates allows it to make use of well-established key management
disciplines.</t> disciplines.</t>
<section title="Requirements Terminology" anchor="sect-1.1"><t> <section anchor="sect-1.1" numbered="true" toc="default">
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <name>Requirements Terminology</name>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in BCP 14 "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they a "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
ppear in all capitals, as "<bcp14>SHOULD NOT</bcp14>",
shown here.</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
</section> are to be interpreted as described in BCP&nbsp;14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
</section> when, they appear in all capitals, as shown here.</t>
</section>
<section title="X.509 COSE Header Parameters" anchor="sect-2"><t> </section>
<section anchor="sect-2" numbered="true" toc="default">
<name>X.509 COSE Header Parameters</name>
<t>
The use of X.509 certificates allows for an existing trust infrastructure The use of X.509 certificates allows for an existing trust infrastructure
to be used with COSE. This includes the full suite of enrollment to be used with COSE. This includes the full suite of enrollment
protocols, trust anchors, trust chaining and revocation checking that have protocols, trust anchors, trust chaining, and revocation checking that have
been defined over time by the IETF and other organizations. The key been defined over time by the IETF and other organizations. The Concise Bina
structures that have been defined in COSE currently do not support all of ry Object Representation (CBOR) key structures <xref target="RFC8949" format="de
these properties, although some may be found in COSE Web Tokens (CWT) fault"/> that have been defined in COSE currently do not support all of
<xref target="RFC8392"/>.</t> these properties, although some may be found in CBOR Web Tokens (CWTs)
<xref target="RFC8392" format="default"/>.</t>
<t> <t>
It is not necessarily expected that constrained devices themselves will It is not necessarily expected that constrained devices themselves will
evaluate and process X.509 certificates: it is perfectly reasonable for a evaluate and process X.509 certificates: it is perfectly reasonable for a
constrained device to be provisioned with a certificate that it constrained device to be provisioned with a certificate that it
subsequently provides to a relying party - along with a signature or subsequently provides to a relying party -- along with a signature or
encrypted message - on the assumption that the relying party is not a encrypted message -- on the assumption that the relying party is not a
constrained device, and is capable of performing the required certificate constrained device and is capable of performing the required certificate
evaluation and processing. It is also reasonable that a constrained device evaluation and processing. It is also reasonable that a constrained device
would have the hash of a certificate associated with a public key and be would have the hash of a certificate associated with a public key and be
configured to use a public key for that thumbprint, but without performing configured to use a public key for that thumbprint, but without performing
the certificate evaluation or even having the entire certificate. In any the certificate evaluation or even having the entire certificate. In any
case, there still needs to be an entity that is responsible for handling case, there still needs to be an entity that is responsible for handling
the possible certificate revocation.</t> the possible certificate revocation.</t>
<t>
<t>
Parties that intend to rely on the assertions made by a certificate Parties that intend to rely on the assertions made by a certificate
obtained from any of these methods still need to validate it. This obtained from any of these methods still need to validate it. This
validation can be done according to the PKIX rules in <xref target="RFC5280"/ > or by using validation can be done according to the PKIX rules specified in <xref target= "RFC5280" format="default"/> or by using
a different trust structure, such as a trusted certificate distributor for a different trust structure, such as a trusted certificate distributor for
self-signed certificates. The PKIX validation includes matching against self-signed certificates. The PKIX validation includes matching against
the trust anchors configured for the application. These rules apply when the trust anchors configured for the application. These rules apply when
the validation succeeds in a single step as well as when certificate chains the validation succeeds in a single step as well as when certificate chains
need to be built. If the application cannot establish trust in the need to be built. If the application cannot establish trust in the
certificate, the public key contained in the certificate cannot be used for certificate, the public key contained in the certificate cannot be used for
cryptographic operations.</t> cryptographic operations.</t>
<t>
<t> The header parameters defined in this document are as follows:</t>
The header parameters defined in this document are:</t> <dl spacing="normal" newline="false">
<dt>x5bag:</dt><dd><t>This header parameter contains a bag of X.509 certifica
<t> tes. The set
x5bag: This header parameter contains a bag of X.509 certificates. The set
of certificates in this header parameter is unordered and may contain of certificates in this header parameter is unordered and may contain
self-signed certificates. Note that there could be duplicate certificates. self-signed certificates. Note that there could be duplicate certificates.
The certificate bag can contain certificates which are completely The certificate bag can contain certificates that are completely
extraneous to the message. (An example of this would be where a signed extraneous to the message. (An example of this would be where a signed
message is being used to transport a certificate containing a key agreement message is being used to transport a certificate containing a key agreement
key.) As the certificates are unordered, the party evaluating the key.) As the certificates are unordered, the party evaluating the
signature will need to be capable of building the certificate path as signature will need to be capable of building the certificate path as
necessary. That party will also have to take into account that the bag may necessary. That party will also have to take into account that the bag may
not contain the full set of certificates needed to build any particular not contain the full set of certificates needed to build any particular
chain.</t> chain.</t>
<t>
<t> The trust mechanism <bcp14>MUST</bcp14> process any certificates in this para
The trust mechanism MUST process any certificates in this parameter as meter as
untrusted input. The presence of a self-signed certificate in the untrusted input. The presence of a self-signed certificate in the
parameter MUST NOT cause the update of the set of trust anchors without parameter <bcp14>MUST NOT</bcp14> cause the update of the set of trust anchor s without
some out-of-band confirmation. As the contents of this header parameter some out-of-band confirmation. As the contents of this header parameter
are untrusted input, the header parameter can be in either the protected or are untrusted input, the header parameter can be in either the protected or
unprotected header bucket. Sending the header parameter in the unprotected unprotected header bucket. Sending the header parameter in the unprotected
header bucket allows an intermediary to remove or add certificates.</t> header bucket allows an intermediary to remove or add certificates.</t>
<t>
<t> The end-entity certificate <bcp14>MUST</bcp14> be integrity protected by COSE
The end-entity certificate MUST be integrity protected by COSE. This can . This can,
e.g. be done by sending the header parameter in the protected header, for example, be done by sending the header parameter in the protected header,
sending a x5bag in the unprotected header combined with a x5t in the sending an 'x5bag' in the unprotected header combined with an 'x5t' in the
protected header, or including the end-entity certificate in the protected header, or including the end-entity certificate in the
external_aad.</t> external_aad.</t>
<t>
<t>
This header parameter allows for a single X.509 certificate or a bag of This header parameter allows for a single X.509 certificate or a bag of
X.509 certificates to be carried in the message. X.509 certificates to be carried in the message.
</t>
<list style="symbols"> <ul spacing="normal">
<li>If a single certificate is conveyed, it is placed in a CBOR byte str
<t>If a single certificate is conveyed, it is placed in a CBOR byte string. ing.</li>
</t> <li>If multiple certificates are conveyed, a CBOR array of byte strings
is
<t>If multiple certificates are conveyed, a CBOR array of byte strings is used, with each certificate being in its own byte string.</li>
used, with each certificate being in its own byte string.</t> </ul>
</dd>
</list> <dt>x5chain:</dt><dd><t>This header parameter contains an ordered array of X.
</t> 509
<t>
x5chain: This header parameter contains an ordered array of X.509
certificates. The certificates are to be ordered starting with the certificates. The certificates are to be ordered starting with the
certificate containing the end-entity key followed by the certificate which certificate containing the end-entity key followed by the certificate that
signed it and so on. There is no requirement for the entire chain to be signed it, and so on. There is no requirement for the entire chain to be
present in the element if there is reason to believe that the relying party present in the element if there is reason to believe that the relying party
already has, or can locate the missing certificates. This means that the already has, or can locate, the missing certificates. This means that the
relying party is still required to do path building, but that a candidate relying party is still required to do path building but that a candidate
path is proposed in this header parameter.</t> path is proposed in this header parameter.</t>
<t>
<t> The trust mechanism <bcp14>MUST</bcp14> process any certificates in this para
The trust mechanism MUST process any certificates in this parameter as meter as
untrusted input. The presence of a self-signed certificate in the untrusted input. The presence of a self-signed certificate in the
parameter MUST NOT cause the update of the set of trust anchors without parameter <bcp14>MUST NOT</bcp14> cause the update of the set of trust anchor s without
some out-of-band confirmation. As the contents of this header parameter some out-of-band confirmation. As the contents of this header parameter
are untrusted input, the header parameter can be in either the protected or are untrusted input, the header parameter can be in either the protected or
unprotected header bucket. Sending the header parameter in the unprotected unprotected header bucket. Sending the header parameter in the unprotected
header bucket allows an intermediary to remove or add certificates.</t> header bucket allows an intermediary to remove or add certificates.</t>
<t>
<t> The end-entity certificate <bcp14>MUST</bcp14> be integrity protected by COSE
The end-entity certificate MUST be integrity protected by COSE. This can . This can,
e.g. be done by sending the header parameter in the protected header, for example, be done by sending the header parameter in the protected header,
sending a x5chain in the unprotected header combined with a x5t in the sending an 'x5chain' in the unprotected header combined with an 'x5t' in the
protected header, or including the end-entity certificate in the protected header, or including the end-entity certificate in the
external_aad as.</t> external_aad.</t>
<t>
<t>
This header parameter allows for a single X.509 certificate or a chain of This header parameter allows for a single X.509 certificate or a chain of
X.509 certificates to be carried in the message. X.509 certificates to be carried in the message.
</t>
<list style="symbols"> <ul spacing="normal">
<li>If a single certificate is conveyed, it is placed in a CBOR byte str
<t>If a single certificate is conveyed, it is placed in a CBOR byte string. ing.</li>
</t> <li>If multiple certificates are conveyed, a CBOR array of byte strings
is
<t>If multiple certificates are conveyed, a CBOR array of byte strings is used, with each certificate being in its own byte string.</li>
used, with each certificate being in its own byte string.</t> </ul>
</dd>
</list> <dt>x5t:</dt><dd><t>This header parameter identifies the end-entity X.509 cer
</t> tificate by a
<t>
x5t: This header parameter identifies the end-entity X.509 certificate by a
hash value (a thumbprint). The 'x5t' header parameter is represented as an hash value (a thumbprint). The 'x5t' header parameter is represented as an
array of two elements. The first element is an algorithm identifier which array of two elements. The first element is an algorithm identifier that
is an integer or a string containing the hash algorithm identifier is an integer or a string containing the hash algorithm identifier
corresponding to the Value column (integer or text string) of the algorithm corresponding to the Value column (integer or text string) of the algorithm
registered in the "COSE Algorithms" registry registered in the "COSE Algorithms" registry
<eref target="https://www.iana.org/assignments/cose/cose.xhtml#algorithms."/> (see <eref target="https://www.iana.org/assignments/cose/" brackets="angle"/>
The second ). The second
element is a binary string containing the hash value computed over the DER element is a binary string containing the hash value computed over the
encoded certificate.</t> DER-encoded certificate.</t>
<t>
<t>
As this header parameter does not provide any trust, the header parameter As this header parameter does not provide any trust, the header parameter
can be in either a protected or unprotected header bucket.</t> can be in either a protected or unprotected header bucket.</t>
<t>
<t> The identification of the end-entity certificate <bcp14>MUST</bcp14> be integ
The identification of the end-entity certificate MUST be integrity rity
protected by COSE. This can be done by sending the header parameter in the protected by COSE. This can be done by sending the header parameter in the
protected header or including the end-entity certificate in the protected header or including the end-entity certificate in the
external_aad.</t> external_aad.</t>
<t>
<t>
The 'x5t' header parameter can be used alone or together with the 'x5bag', The 'x5t' header parameter can be used alone or together with the 'x5bag',
'x5chain', or 'x5u' header parameters to provide integrity protection of 'x5chain', or 'x5u' header parameters to provide integrity protection of
the end-entity certificate.</t> the end-entity certificate.</t>
<t>
<t> For interoperability, applications that use this header parameter <bcp14>MUST
For interoperability, applications which use this header parameter MUST </bcp14>
support the hash algorithm 'SHA-256', but can use other hash algorithms. support the hash algorithm 'SHA-256' but can use other hash algorithms.
This requirement allows for different implementations to be configured to This requirement allows for different implementations to be configured to
use an interoperable algorithm, but does not preclude the use (by prior use an interoperable algorithm, but does not preclude the use (by prior
agreement) of other algorithms.</t> agreement) of other algorithms.</t>
</dd>
<t> <dt>x5u:</dt><dd><t>This header parameter provides the ability to identify an
RFC Editor please remove the following two paragraphs:</t> X.509
certificate by a URI <xref target="RFC3986" format="default"/>. It contains
<t> a CBOR text string. The
During AD review, a question was raised about how effective the previous
statement is in terms of dealing with a MTI algorithm. There needs to be
some type of arrangement between the parties to agree that a specific hash
algorithm is going to be used in computing the thumbprint. Making it a
MUST use would make that true, but it then means that agility is going to
be very difficult.</t>
<t>
The worry is that while SHA-256 may be mandatory, if a sender supports
SHA-256 but only sends SHA-512 then the recipient which only does SHA-256
would not be able to use the thumbprint. In that case both applications
would conform to the specification, but still not be able to inter-operate.</
t>
<t>
x5u: This header parameter provides the ability to identify an X.509
certificate by a URI <xref target="RFC3986"/>. It contains a CBOR text strin
g. The
referenced resource can be any of the following media types: referenced resource can be any of the following media types:
</t>
<list style="symbols"> <ul spacing="normal">
<li>application/pkix-cert <xref target="RFC2585" format="default"/></li>
<t>application/pkix-cert <xref target="RFC2585"/></t> <li>application/pkcs7-mime; smime-type="certs-only" <xref target="RFC855
1" format="default"/></li>
<t>application/pkcs7-mime; smime-type="certs-only" <xref target="RFC8551"/> <li>application/cose-x509 (<xref target="sect-4.3" format="default"/>)</
</t> li>
<li>application/cose-x509; usage=chain (<xref target="sect-4.3" format="
<t>application/cose-x509 <xref target="sect-4.3"/></t> default"/>)</li>
</ul>
<t>application/cose-x509; usage=chain <xref target="sect-4.3"/></t> <t>
</list>
</t>
<t>
When the application/cose-x509 media type is used, the data is a CBOR When the application/cose-x509 media type is used, the data is a CBOR
sequence of single-entry COSE_X509 structures (encoding "bstr"). If the sequence of single-entry COSE_X509 structures (encoding "bstr"). If the
parameter "usage" is set to "chain", this sequence indicates a certificate parameter "usage" is set to "chain", this sequence indicates a certificate
chain.</t> chain.</t>
<t>
<t> The end-entity certificate <bcp14>MUST</bcp14> be integrity protected by COSE
The end-entity certificate MUST be integrity protected by COSE. This can . This can,
e.g. be done by sending the x5u in the unprotected or protected header for example, be done by sending the 'x5u' in the unprotected or protected hea
combined with a x5t in the protected header, or including the end-entity der
combined with an 'x5t' in the protected header, or including the end-entity
certificate in the external_aad. As the end-entity certificate is certificate in the external_aad. As the end-entity certificate is
integrity protected by COSE, the URI does not need to provide any integrity protected by COSE, the URI does not need to provide any
protection.</t> protection.</t>
<t>
<t>
If a retrieved certificate does not chain to an existing trust anchor, that If a retrieved certificate does not chain to an existing trust anchor, that
certificate MUST NOT be trusted unless the URI provided integrity certificate <bcp14>MUST NOT</bcp14> be trusted unless the URI provides integr ity
protection and server authentication and the server is configured as protection and server authentication and the server is configured as
trusted to provide new trust anchors or if an out-of-band confirmation can trusted to provide new trust anchors or if an out-of-band confirmation can
be received for trusting the retrieved certificate. In case an HTTP or be received for trusting the retrieved certificate. If an HTTP or
CoAP GET request is used to retrieve a certificate, TLS <xref target="RFC8446 Constrained Application Protocol (CoAP) GET request is used to retrieve a cer
"/>, DTLS tificate, TLS <xref target="RFC8446" format="default"/>, DTLS
<xref target="I-D.ietf-tls-dtls13"/> or OSCORE <xref target="RFC8613"/> SHOUL <xref target="RFC9147" format="default"/>, or Object Security for Constrained
D be used.</t> RESTful Environments (OSCORE) <xref target="RFC8613" format="default"/> <bcp14>
SHOULD</bcp14> be used.</t>
<t> </dd>
</dl>
<t>
The header parameters are used in the following locations: The header parameters are used in the following locations:
</t>
<dl spacing="normal" newline="false">
<dt>COSE_Signature and COSE_Sign1 objects:</dt><dd>In these objects, the
parameters identify the
certificate to be used for validating the signature.</dd>
<dt>COSE_recipient objects:</dt><dd>In this location, the parameters ide
ntify the certificate
for the recipient of the message.</dd>
</dl>
<t>
The labels assigned to each header parameter can be found in <xref target="ta
b-1"/>.</t>
<list style="symbols"> <table anchor="tab-1">
<name>X.509 COSE Header Parameters</name>
<t>COSE_Signature and COSE_Sign1 objects: in these objects they identify th <thead>
e <tr>
certificate to be used for validating the signature.</t> <th>Name</th>
<th>Label</th>
<t>COSE_recipient objects: in this location they identify the certificate <th>Value Type</th>
for the recipient of the message.</t> <th>Description</th>
</tr>
</list> </thead>
</t> <tbody>
<tr>
<t> <td>x5bag</td>
The labels assigned to each header parameter can be found in the following <td>32</td>
table.</t> <td>COSE_X509</td>
<td>An unordered bag of X.509 certificates</td>
<!-- draft-ietf-cose-x509-09-manual.txt(301): Warning: Unexpected title: expecte </tr>
d <tr>
'Figure ...', found 'Table 1: X.509 COSE Header Parameters'. This looks like <td>x5chain</td>
a figure that has been entered as a texttable. The generated XML will need <td>33</td>
adjustment. --> <td>COSE_X509</td>
<td>An ordered chain of X.509 certificates</td>
<figure title="Table 1: X.509 COSE Header Parameters" anchor="Fig1"> </tr>
<artwork><![CDATA[ <tr>
<td>x5t</td>
+=========+=======+===============+=====================+ <td>34</td>
| Name | Label | Value Type | Description | <td>COSE_CertHash</td>
+=========+=======+===============+=====================+ <td>Hash of an X.509 certificate</td>
| x5bag | 32 | COSE_X509 | An unordered bag of | </tr>
| | | | X.509 certificates | <tr>
+---------+-------+---------------+---------------------+ <td>x5u</td>
| x5chain | 33 | COSE_X509 | An ordered chain of | <td>35</td>
| | | | X.509 certificates | <td>uri</td>
+---------+-------+---------------+---------------------+ <td>URI pointing to an X.509 certificate</td>
| x5t | 34 | COSE_CertHash | Hash of an X.509 | </tr>
| | | | certificate | </tbody>
+---------+-------+---------------+---------------------+ </table>
| x5u | 35 | uri | URI pointing to an |
| | | | X.509 certificate |
+---------+-------+---------------+---------------------+
]]></artwork></figure>
<t>
Below is an equivalent CDDL <xref target="RFC8610"/> description of the text
above.</t>
<figure><artwork><![CDATA[
COSE_X509 = bstr / [ 2*certs: bstr ]
COSE_CertHash = [ hashAlg: (int / tstr), hashValue: bstr ]
]]></artwork></figure>
<t>The content of the bstr are the bytes of a DER encoded certificate.</t>
</section> <t>
Below is an equivalent Concise Data Definition Language (CDDL) description
(see <xref target="RFC8610" format="default"/>) of the text above.</t>
<sourcecode name="" type="cddl"><![CDATA[
COSE_X509 = bstr / [ 2*certs: bstr ]
COSE_CertHash = [ hashAlg: (int / tstr), hashValue: bstr ]
]]></sourcecode>
<section title="X.509 certificates and static-static ECDH" anchor="sect-3 <t>The contents of "bstr" are the bytes of a DER-encoded certificate.</t>
"><t> </section>
<section anchor="sect-3" numbered="true" toc="default">
<name>X.509 Certificates and Static-Static ECDH</name>
<t>
The header parameters defined in the previous section are used to identify The header parameters defined in the previous section are used to identify
the recipient certificates for the ECDH key agreement algorithms. In this the recipient certificates for the Elliptic Curve Diffie-Hellman (ECDH) key a
section we define the algorithm specific parameters that are used for greement algorithms. In this
section, we define the algorithm-specific parameters that are used for
identifying or transporting the sender's key for static-static key identifying or transporting the sender's key for static-static key
agreement algorithms.</t> agreement algorithms.</t>
<t>
<t>
These attributes are defined analogously to those in the previous section. These attributes are defined analogously to those in the previous section.
There is no definition for the certificate bag, as the same attribute would There is no definition for the certificate bag, as the same attribute would
be used for both the sender and recipient certificates.</t> be used for both the sender and recipient certificates.</t>
<dl spacing="normal" newline="true">
<t> <dt>x5chain-sender:</dt><dd>This header parameter contains the chain of ce
x5chain-sender: This header parameter contains the chain of certificates rtificates
starting with the sender's key exchange certificate. The structure is the starting with the sender's key exchange certificate. The structure is the
same as 'x5chain'.</t> same as 'x5chain'.</dd>
<dt>x5t-sender:</dt><dd>This header parameter contains the hash value for the
<t> sender's
x5t-sender: This header parameter contains the hash value for the sender's key exchange certificate. The structure is the same as 'x5t'.</dd>
key exchange certificate. The structure is the same as 'x5t'.</t> <dt>x5u-sender:</dt><dd>This header parameter contains a URI for the sender's
key
<t> exchange certificate. The structure and processing are the same as 'x5u'.</d
x5u-sender: This header parameter contains a URI for the sender's key d>
exchange certificate. The structure and processing are the same as 'x5u'.</t </dl>
> <table anchor="tab-2">
<name>Static ECDH Algorithm Values</name>
<!-- draft-ietf-cose-x509-09-manual.txt(354): Warning: Unexpected title: <thead>
expected 'Figure ...', found 'Table 2: Static ECDH Algorithm Values'. <tr>
This looks like a figure that has been entered as a texttable. The <th>Name</th>
generated XML will need adjustment. --> <th>Label</th>
<th>Type</th>
<figure title="Static ECDH Algorithm Values" anchor="Fig2"> <th>Algorithm</th>
<artwork><![CDATA[ <th>Description</th>
+===============+=====+=============+===================+===========+ </tr>
|Name |Label|Type | Algorithm |Description| </thead>
+===============+=====+=============+===================+===========+ <tbody>
|x5t-sender |TBD |COSE_CertHash| ECDH-SS+HKDF-256, |Thumbprint | <tr>
| | | | ECDH-SS+HKDF-512, |for the | <td>x5t-sender</td>
| | | | ECDH-SS+A128KW, |sender's | <td>-27</td>
| | | | ECDH-SS+A192KW, |X.509 | <td>COSE_CertHash</td>
| | | | ECDH-SS+A256KW |certificate| <td>ECDH-SS+HKDF-256, ECDH-SS+HKDF-512, ECDH-SS+A128KW, ECDH-SS+A192KW, EC
+---------------+-----+-------------+-------------------+-----------+ DH-SS+A256KW</td>
|x5u-sender |TBD |uri | ECDH-SS+HKDF-256, |URI for the| <td>Thumbprint for the sender's X.509 certificate</td>
| | | | ECDH-SS+HKDF-512, |sender's | </tr>
| | | | ECDH-SS+A128KW, |X.509 | <tr>
| | | | ECDH-SS+A192KW, |certificate| <td>x5u-sender</td>
| | | | ECDH-SS+A256KW | | <td>-28</td>
+---------------+-----+-------------+-------------------+-----------+ <td>uri</td>
|x5chain-sender |TBD |COSE_X509 | ECDH-SS+HKDF-256, |static key | <td>ECDH-SS+HKDF-256, ECDH-SS+HKDF-512, ECDH-SS+A128KW, ECDH-SS+A192KW, EC
| | | | ECDH-SS+HKDF-512, |X.509 | DH-SS+A256KW</td>
| | | | ECDH-SS+A128KW, |certificate| <td>URI for the sender's X.509 certificate</td>
| | | | ECDH-SS+A192KW, |chain | </tr>
| | | | ECDH-SS+A256KW | | <tr>
+---------------+-----+-------------+-------------------+-----------+ <td>x5chain-sender</td>
]]></artwork></figure> <td>-29</td>
</section> <td>COSE_X509</td>
<td>ECDH-SS+HKDF-256, ECDH-SS+HKDF-512, ECDH-SS+A128KW, ECDH-SS+A192KW, EC
DH-SS+A256KW</td>
<td>static key X.509 certificate chain</td>
</tr>
</tbody>
</table>
<section title="IANA Considerations" anchor="sect-4"><section title="COSE </section>
Header Parameter Registry" anchor="sect-4.1"><t> <section anchor="sect-4" numbered="true" toc="default">
IANA is requested to register the new COSE Header parameters in Table 1 in <name>IANA Considerations</name>
<section anchor="sect-4.1" numbered="true" toc="default">
<name>COSE Header Parameters Registry</name>
<t>
IANA has registered the new COSE Header parameters in <xref target="tab-1"/>
in
the "COSE Header Parameters" registry. The "Value Registry" field is empty the "COSE Header Parameters" registry. The "Value Registry" field is empty
for all of the items. For each item, the 'Reference' field points to this for all of the items. For each item, the "Reference" field points to this
document.</t> document.</t>
</section>
</section> <section anchor="sect-4.2" numbered="true" toc="default">
<name>COSE Header Algorithm Parameters Registry</name>
<section title="COSE Header Algorithm Parameter Registry" anchor="sect-4. <t>
2"><t> IANA has registered the new COSE Header Algorithm parameters in
IANA is requested to register the new COSE Header Algorithm parameters in <xref target="tab-2"/> in the "COSE Header Algorithm Parameters" registry. F
Table 2 in the "COSE Header Algorithm Parameters" registry. For each item, or each item,
the 'Reference' field points to this document.</t> the "Reference" field points to this document.</t>
</section>
</section> <section anchor="sect-4.3" numbered="true" toc="default">
<name>Media Type application/cose-x509</name>
<section title="Media Type application/cose-x509" anchor="sect-4.3"><t> <t>
When the application/cose-x509 media type is used, the data is a CBOR When the application/cose-x509 media type is used, the data is a CBOR
sequence of single-entry COSE_X509 structures (encoding "bstr"). If the sequence of single-entry COSE_X509 structures (encoding "bstr"). If the
parameter "usage" is set to "chain", this sequence indicates a certificate parameter "usage" is set to "chain", this sequence indicates a certificate
chain.</t> chain.</t>
<t>
<t> IANA has registered the following media type <xref target="RFC6838" format="d
IANA is requested to register the following media type <xref target="RFC6838" efault"/>:</t>
/>:</t> <dl spacing="normal" newline="false">
<dt>Type name:</dt><dd><t>application</t></dd>
<t>Type name: application</t> <dt>Subtype name:</dt><dd><t>cose-x509</t></dd>
<dt>Required parameters:</dt><dd><t>N/A</t></dd>
<t>Subtype name: cose-x509</t> <dt>Optional parameters:</dt><dd><t>usage</t>
<ul spacing="normal">
<t>Required parameters: N/A</t> <li>Can be absent to provide no further information about the intended
meaning of the order in the CBOR sequence of certificates.</li>
<t>Optional parameters: usage</t> <li>Can be set to "chain" to indicate that the sequence of data items
is to be interpreted as a certificate chain.</li>
<t><list style="symbols"> </ul>
</dd>
<t>Can be absent to provide no further information about the intended <dt>Encoding considerations:</dt>
meaning of the order in the CBOR sequence of certificates.</t> <dd><t>binary</t></dd>
<dt>Security considerations:</dt>
<t>Can be set to "chain" to indicate that the sequence of data items <dd><t>See the Security Considerations section of RFC 9360.</t></dd>
is to be interpreted as a certificate chain.</t> <dt>Interoperability considerations:</dt>
<dd><t>N/A</t></dd>
</list> <dt>Published specification:</dt>
</t> <dd><t>RFC 9360</t></dd>
<dt>Applications that use this media type:</dt>
<t> <dd><t>Applications that employ COSE and use X.509 as a certificate typ
Encoding considerations: binary</t> e.</t></dd>
<dt>Fragment identifier considerations:</dt>
<t> <dd><t>N/A</t></dd>
Security considerations: See the Security Considerations section of <dt>Additional information:</dt><dd>
RFCthis.</t> <t><br/></t>
<dl spacing="compact">
<t> <dt>Deprecated alias names for this type:</dt><dd>N/A</dd>
Interoperability considerations: N/A</t> <dt>Magic number(s):</dt><dd>N/A</dd>
<dt>File extension(s):</dt><dd>N/A</dd>
<t> <dt>Macintosh file type code(s):</dt><dd>N/A</dd>
Published specification: RFCthis</t> </dl>
</dd>
<t> <dt>Person &amp; email address to contact for further information:</dt><dd
Applications that use this media type: Applications that employ COSE and ><br/>iesg@ietf.org</dd>
use X.509 as a certificate type.</t> <dt>Intended usage:</dt><dd>COMMON</dd>
<dt>Restrictions on usage:</dt><dd>N/A</dd>
<t> <dt>Author:</dt><dd>COSE WG</dd>
Fragment identifier considerations: N/A <dt>Change controller:</dt><dd>IESG</dd>
</dl>
<list style="hanging" hangIndent="24"> </section>
</section>
<t hangText="Additional information: Deprecated alias names for this type: <section anchor="sect-5" numbered="true" toc="default">
N/A"></t> <name>Security Considerations</name>
<t>
<t>Magic number(s): N/A</t>
<t>File extension(s): N/A</t>
<t>Macintosh file type code(s): N/A</t>
</list>
</t>
<t>
Person &amp; email address to contact for further information: iesg@ietf.org
Intended usage: COMMON</t>
<t>
Restrictions on usage: N/A</t>
<t>
Author: COSE WG</t>
<t>
Change controller: IESG</t>
<t>
Provisional registration? (standards tree only): no</t>
</section>
</section>
<section title="Security Considerations" anchor="sect-5"><t>
Establishing trust in a certificate is a vital part of processing. A major Establishing trust in a certificate is a vital part of processing. A major
component of establishing trust is determining what the set of trust component of establishing trust is determining what the set of trust
anchors are for the process. A new self-signed certificate appearing on anchors are for the process. A new self-signed certificate appearing on
the client cannot be a trigger to modify the set of trust anchors, because the client cannot be a trigger to modify the set of trust anchors, because
a well-defined trust-establishment process is required. One common way for a well-defined trust-establishment process is required. One common way for
a new trust anchor to be added (or removed) from a device is by doing a new a new trust anchor to be added to (or removed from) a device is by doing a ne w
firmware upgrade.</t> firmware upgrade.</t>
<t>
<t>
In constrained systems, there is a trade-off between the order of checking In constrained systems, there is a trade-off between the order of checking
the signature and checking the certificate for validity. Validating the signature and checking the certificate for validity. Validating
certificates can require that network resources be accessed in order to get certificates can require that network resources be accessed in order to get
revocation information or retrieve certificates during path building. The revocation information or retrieve certificates during path building. The
resulting network access can consume power and network bandwidth. On the resulting network access can consume power and network bandwidth. On the
other hand, if the certificates are validated after the signature is other hand, if the certificates are validated after the signature is
validated, an oracle can potentially be built based on detecting the validated, an oracle can potentially be built based on detecting the
network resources which is only done if the signature validation passes. network resources, which is only done if the signature validation passes.
In any event, both the signature and certificate validation MUST be In any event, both the signature validation and the certificate validation <b
cp14>MUST</bcp14> be
completed successfully before acting on any requests.</t> completed successfully before acting on any requests.</t>
<t>
<t> Unless it is known that the Certificate Authority (CA) required proof of poss
Unless it is known that the CA required proof-of-possession of the ession of the
subject's private key to issue an end-entity certificate, the end-entity subject's private key to issue an end-entity certificate, the end-entity
certificate MUST be integrity protected by COSE. Without certificate <bcp14>MUST</bcp14> be integrity protected by COSE. Without
proof-of-possession, an attacker can trick the CA to issue an proof of possession, an attacker can trick the CA into issuing an
identity-misbinding certificate with someone else's "borrowed" public-key identity-misbinding certificate with someone else's "borrowed" public key
but with a different subject. A MITM attacker can then perform an but with a different subject. An on-path attacker can then perform an
identity-misbinding attack by replacing the real end-entity certificate in identity-misbinding attack by replacing the real end-entity certificate in
COSE with such an identity-misbinding certificate.</t> COSE with such an identity-misbinding certificate.</t>
<t>
<t>
End-entity X.509 certificates contain identities that a passive on-path End-entity X.509 certificates contain identities that a passive on-path
attacker eavesdropping on the conversation can use to identify and track attacker eavesdropping on the conversation can use to identify and track
the subject. COSE does not provide identity protection by itself and the the subject. COSE does not provide identity protection by itself, and the
x5t and x5u header parameters are just alternative permanent identifiers 'x5t' and 'x5u' header parameters are just alternative permanent identifiers
and can also be used to track the subject. To provide identity protection, and can also be used to track the subject. To provide identity protection,
COSE can be sent inside another security protocol providing COSE can be sent inside another security protocol providing
confidentiality.</t> confidentiality.</t>
<t>
<t> Before using the key in a certificate, the key <bcp14>MUST</bcp14> be checked
Before using the key in a certificate, the key MUST be checked against the against the
algorithm to be used and any algorithm specific checks need to be made. algorithm to be used, and any algorithm-specific checks need to be made.
These checks can include validating that points are on curves for These checks can include validating that points are on curves for
elliptical curve algorithms, and that sizes of RSA keys are of an elliptical curve algorithms and that the sizes of RSA keys are within an acce
acceptable size. The use of unvalidated keys can lead either to loss of ptable range. The use of unvalidated keys can lead to either loss of
security or excessive consumption of resources (for example using a 200K security or excessive consumption of resources (for example, using a 200K
RSA key).</t> RSA key).</t>
<t>
<t> When processing the 'x5u' header parameter, the security considerations of
When processing the x5u header parameter the security considerations of <xref target="RFC3986" format="default"/>, and specifically those defined in
<xref target="RFC3986"/> and specifically those defined in Section 7.1 of <xr <xref target="RFC3986" sectionFormat="of" section="7.1"/>, also
ef target="RFC3986"/> also
apply.</t> apply.</t>
<t>
<t>
Regardless of the source, certification path validation is an important Regardless of the source, certification path validation is an important
part of establishing trust in a certificate. Section 6 of <xref target="RFC5 280"/> part of establishing trust in a certificate. <xref target="RFC5280" sectionF ormat="of" section="6"/>
provides guidance for the path validation. The security considerations of provides guidance for the path validation. The security considerations of
<xref target="RFC5280"/> are also important for the correct usage of this doc <xref target="RFC5280" format="default"/> are also important for the correct
ument.</t> usage of this document.</t>
<t>
<t> Protecting the integrity of the 'x5bag', 'x5chain', and 'x5t' contents by pla
Protecting the integrity of the x5bag, x5chain and x5t contents by placing cing
them in the protected header bucket can help mitigate some risks of a them in the protected header bucket can help mitigate some risks of a
misbehaving certificate authority (cf. Section 5.1 of <xref target="RFC2634" misbehaving CA (cf.&nbsp;<xref target="RFC2634" sectionFormat="of" section="5
/>).</t> .1"/>).</t>
<t>
<t>
The security of the algorithm used for 'x5t' does not affect the security The security of the algorithm used for 'x5t' does not affect the security
of the system as this header parameter selects which certificate that is of the system, as this header parameter selects which certificate that is
already present on the system should be used, but it does not provide any already present on the system should be used, but it does not provide any
trust.</t> trust.</t>
</section>
</middle>
<back>
</section> <references>
<name>References</name>
<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.5
280.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
152.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.8
949.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
052.xml"/>
</references>
<references>
<name>Informative References</name>
</middle> <!-- Constrained-BRSKI draft-ietf-anima-constrained-voucher (I-D Exists)
"Long way" to change "Van" to "van" and fix version number -->
<reference anchor="Constrained-BRSKI">
<front>
<title>Constrained Bootstrapping Remote Secure Key Infrastructure (BRSKI)</t
itle>
<author fullname="Michael Richardson" initials="M." surname="Richardson">
<organization>Sandelman Software Works</organization>
</author>
<author fullname="Peter van der Stok" initials="P." surname="van der Stok">
<organization>vanderstok consultancy</organization>
</author>
<author fullname="Panos Kampanakis" initials="P." surname="Kampanakis">
<organization>Cisco Systems</organization>
</author>
<author fullname="Esko Dijk" initials="E." surname="Dijk">
<organization>IoTconsultancy.nl</organization>
</author>
<date month="January" day="2" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-constrained-voucher-
19"/>
</reference>
<back> <!-- draft-ietf-lake-edhoc (Publication Requested)
<references title="Normative References"> Had to do "long way" for version # and J. Preuß Mattsson's name -->
&RFC2119; <reference anchor="EDHOC">
&RFC5280; <front>
&RFC8152; <title>Ephemeral Diffie-Hellman Over COSE (EDHOC)</title>
&RFC8174; <author fullname="Göran Selander" initials="G." surname="Selander">
&RFC8949; <organization>Ericsson AB</organization>
</references> </author>
<references title="Informative References"> <author fullname="John Preuß Mattsson" initials="J." surname="Preuß Mattsson
&I-D.ietf-anima-constrained-voucher; ">
&I-D.ietf-lake-edhoc; <organization>Ericsson AB</organization>
&I-D.ietf-tls-dtls13; </author>
&RFC2585; <author fullname="Francesca Palombini" initials="F." surname="Palombini">
&RFC2634; <organization>Ericsson AB</organization>
&RFC3986; </author>
&RFC6838; <date day="3" month="February" year="2023"/>
&RFC8392; </front>
&RFC8446; <seriesInfo name="Internet-Draft" value="draft-ietf-lake-edhoc-19"/>
&RFC8551; </reference>
&RFC8610;
&RFC8613;
</references>
</back>
</rfc> <!-- draft-ietf-tls-dtls13 (RFC 9147) -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
147.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
585.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
634.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
986.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
838.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.8
446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
551.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
610.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
613.xml"/>
</references>
</references>
<section anchor="acks" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>
Jim Schaad passed on 3 October 2020. This document is primarily his
work. Ivaylo Petrov served as the document editor after Jim's
untimely death, mostly helping with the approval and publication
processes. Jim deserves all credit for the technical content.
</t>
</section>
</back>
</rfc>
 End of changes. 73 change blocks. 
497 lines changed or deleted 462 lines changed or added

This html diff was produced by rfcdiff 1.48.