RFC 9360

CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates

📅 published February 2023, from ietf

📜 RFC 9360 ✨ Part 1 of 4

Okay bestie, so this one is RFC 9360, and it's all about X.509 certificates in COSE headers 🎀 It's by J. Schaad at August Cellars, it's on the Standards Track (so it's real, official IETF stuff 💅), and it's dated February 2023. It doesn't obsolete anything, and it doesn't update anything either, so it's a fresh new addition to the COSE family 🌸

Here's the title, for the record: CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates 🦋

Abstract

COSE messages reference keys in general, and some algorithms come with extra properties that carry key-related parameters when needed 🔑 COSE Key is the structure used to move keys outside of COSE messages. This document levels up that whole situation by adding attributes that either point to or actually contain X.509 certificates 🧚

Status of This Memo

This is an Internet Standards Track document, so it's official 💖 It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 📚

Info about the current status, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc9360 🔗

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved 🌈

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, bestie, because they explain your rights and restrictions 🫶 Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Revised BSD License ⚖️

Table of Contents

1.  Introduction
  1.1.  Requirements Terminology
2.  X.509 COSE Header Parameters
3.  X.509 Certificates and Static-Static ECDH
4.  IANA Considerations
  4.1.  COSE Header Parameters Registry
  4.2.  COSE Header Algorithm Parameters Registry
  4.3.  Media Type application/cose-x509
5.  Security Considerations
6.  References
  6.1.  Normative References
  6.2.  Informative References
Acknowledgements
Author's Address

1. Introduction 🎀

Okay so the COSE Working Group was writing [RFC8152] and [RFC9052], and they talked about X.509 certificates [RFC5280] 💭 They decided no use cases had been presented that needed certificate support. Fast-forward, and a bunch of cases have shown up where X.509 support is necessary, which means apps need a documented, consistent way to handle these certs 😭 This document defines a set of attributes so apps can transport and refer to X.509 certificates in a consistent way. It's giving standardization arc ✨

Some of these cases involve a constrained device deployed inside an existing X.509 PKI. For example, [Constrained-BRSKI] describes a device enrollment solution that depends on a factory-installed certificate on the device 🏭 [EDHOC] was also written with the idea that long-term certificates could authenticate devices and establish session keys 🔐 Another possible scenario is using COSE as the base for a secure messaging app. That one assumes long-term keys and a central authentication authority 💌 Building an app on public key certificates lets it use well-established key management disciplines, which is honestly so smart 🧠💜

1.1. Requirements Terminology

Okay, the key words for this document are MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL. They're to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in ALL CAPS like that 💅 Otherwise they're just regular words 🙈

✨ Part 2 coming up next, so stay tuned, bestie! 🦋

2. X.509 COSE Header Parameters ✨

okay bestie, X.509 certificates let COSE plug into trust infrastructure that already exists 🔐 Think the whole enrollment protocol situation, trust anchors, trust chaining, and revocation checking that the IETF and other orgs have been building for ages 💅 The CBOR key structures [RFC8949] that COSE has defined so far don't support all of those properties yet, although a few of them show up in CBOR Web Tokens (CWTs) [RFC8392] 🌸

constrained devices don't have to evaluate and process X.509 certificates themselves 🦋 A constrained device can be provisioned with a certificate and hand it to a relying party along with a signature or encrypted message, on the assumption that the relying party isn't constrained and can do the required certificate evaluation and processing. It's also fine for a constrained device to have the hash of a certificate tied to a public key and use that public key for the thumbprint, without doing any certificate evaluation or even having the whole certificate 🫶 Either way, there still needs to be an entity in charge of handling possible certificate revocation 😭

Anyone who wants to rely on what a certificate says, no matter how they got it, still needs to validate it 💖 That validation can follow the PKIX rules in [RFC5280], or use a different trust structure, like a trusted certificate distributor for self-signed certificates 🎀 PKIX validation includes matching against the trust anchors configured for the application. These rules apply whether validation succeeds in a single step or certificate chains need to be built 🔥 If the application can't establish trust in the certificate, the public key inside it can't be used for cryptographic operations 🙈

Here are the header parameters defined in this document 👑

x5bag: This header parameter holds a bag of X.509 certificates. The certificates in it are unordered and may include self-signed certificates. There could be duplicate certificates too 💀 The bag can also hold certificates that are totally extraneous to the message. (For example, a signed message might be carrying a certificate with a key agreement key in it 🧚) Since the certificates are unordered, the party checking the signature needs to be able to build the certificate path when it's needed 🌈 That party also has to keep in mind that the bag might not have every certificate needed to build a given chain ✨

The trust mechanism MUST process any certificates in this parameter as untrusted input. The presence of a self-signed certificate in the parameter MUST NOT cause the update of the set of trust anchors without some out-of-band confirmation. Because the contents of this header parameter are untrusted input, it can sit in either the protected or unprotected header bucket. Putting it in the unprotected bucket lets an intermediary remove or add certificates 🍓

The end-entity certificate MUST be integrity protected by COSE. You can make that happen by sending the header parameter in the protected header, by sending an 'x5bag' in the unprotected header combined with an 'x5t' in the protected header, or by including the end-entity certificate in the external_aad 💅

This header parameter can carry either a single X.509 certificate or a whole bag of them 🌸

  • If a single certificate is conveyed, it goes in a CBOR byte string.
  • If multiple certificates are conveyed, a CBOR array of byte strings is used, with each certificate in its own byte string.

x5chain: This header parameter holds an ordered array of X.509 certificates 🔗 They should be ordered starting with the certificate that has the end-entity key, then the certificate that signed it, and so on up the line 💜 The whole chain doesn't have to be in the element if there's reason to believe the relying party already has the missing certificates or can locate them 🦋 That means the relying party still has to do path building, but this header parameter offers a candidate path to start from ✨

The trust mechanism MUST process any certificates in this parameter as untrusted input. The presence of a self-signed certificate in the parameter MUST NOT cause the update of the set of trust anchors without some out-of-band confirmation. Since the contents here are untrusted input too, this header parameter can be in either the protected or unprotected header bucket. Sending it in the unprotected bucket lets an intermediary remove or add certificates 😭

The end-entity certificate MUST be integrity protected by COSE. That can be done by sending the header parameter in the protected header, by sending an 'x5chain' in the unprotected header combined with an 'x5t' in the protected header, or by including the end-entity certificate in the external_aad 🎀

This header parameter can carry a single X.509 certificate or a chain of them 🌈

  • If a single certificate is conveyed, it goes in a CBOR byte string.
  • If multiple certificates are conveyed, a CBOR array of byte strings is used, with each certificate in its own byte string.

x5t: This header parameter identifies the end-entity X.509 certificate by a hash value, which is also called a thumbprint 🔐 The 'x5t' header parameter is an array of two elements. The first element is an algorithm identifier, either an integer or a string, containing the hash algorithm identifier that matches the Value column (integer or text string) of the algorithm registered in the "COSE Algorithms" registry (see <https://www.iana.org/assignments/cose/>) 💅 The second element is a binary string with the hash value computed over the DER-encoded certificate 🌸

This header parameter doesn't provide any trust on its own 🦋 So it can be in either a protected or unprotected header bucket ✨

The identification of the end-entity certificate MUST be integrity protected by COSE. You can do that by sending the header parameter in the protected header or by including the end-entity certificate in the external_aad 🫶

The 'x5t' header parameter can be used alone or together with the 'x5bag', 'x5chain', or 'x5u' header parameters to provide integrity protection for the end-entity certificate 💖

For interoperability, applications that use this header parameter MUST support the hash algorithm 'SHA-256' but can use other hash algorithms. This requirement lets different implementations be configured to use an interoperable algorithm, and it doesn't rule out using other algorithms by prior agreement 👑

x5u: This header parameter identifies an X.509 certificate by a URI [RFC3986] 🌐 It contains a CBOR text string. The referenced resource can be any of these media types 🧚

  • application/pkix-cert [RFC2585]
  • application/pkcs7-mime; smime-type="certs-only" [RFC8551]
  • application/cose-x509 (Section 4.3)
  • application/cose-x509; usage=chain (Section 4.3)

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 parameter "usage" is set to "chain", that sequence indicates a certificate chain 🌸

The end-entity certificate MUST be integrity protected by COSE. This can be done by sending the 'x5u' in the unprotected or protected header combined with an 'x5t' in the protected header, or by including the end-entity certificate in the external_aad. Since COSE already integrity protects the end-entity certificate, the URI doesn't need to provide any protection of its own 🦋

If a retrieved certificate doesn't chain to an existing trust anchor, that certificate MUST NOT be trusted unless the URI provides integrity protection and server authentication AND the server is configured as trusted to provide new trust anchors, OR an out-of-band confirmation can be received for trusting the retrieved certificate 🚨 If an HTTP or Constrained Application Protocol (CoAP) GET request is used to retrieve a certificate, TLS [RFC8446], DTLS [RFC9147], or Object Security for Constrained RESTful Environments (OSCORE) [RFC8613] SHOULD be used 🔥

Now, where do these header parameters show up? 👀

COSE_Signature and COSE_Sign1 objects: In these objects, the parameters identify the certificate to be used for validating the signature 💅

COSE_recipient objects: In this location, the parameters identify the certificate for the recipient of the message 🫶

The labels assigned to each header parameter are in Table 1 🎀

      +=========+=======+===============+=====================+
      | Name    | Label | Value Type    | Description         |
      +=========+=======+===============+=====================+
      | x5bag   | 32    | COSE_X509     | An unordered bag of |
      |         |       |               | X.509 certificates  |
      +---------+-------+---------------+---------------------+
      | x5chain | 33    | COSE_X509     | An ordered chain of |
      |         |       |               | X.509 certificates  |
      +---------+-------+---------------+---------------------+
      | x5t     | 34    | COSE_CertHash | Hash of an X.509    |
      |         |       |               | certificate         |
      +---------+-------+---------------+---------------------+
      | x5u     | 35    | uri           | URI pointing to an  |
      |         |       |               | X.509 certificate   |
      +---------+-------+---------------+---------------------+

                Table 1: X.509 COSE Header Parameters

Here's an equivalent Concise Data Definition Language (CDDL) description (see [RFC8610]) of everything above 🌈

COSE_X509 = bstr / [ 2*certs: bstr ]
COSE_CertHash = [ hashAlg: (int / tstr), hashValue: bstr ]

The contents of "bstr" are the bytes of a DER-encoded certificate 💜

3. X.509 Certificates and Static-Static ECDH ✨

okay so the header parameters from the last section are what identify the recipient certificates for the Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithms 🔐. this section is about the sender's side! we define the algorithm-specific parameters for identifying or carrying the sender's key for static-static key agreement algorithms 💜

these attributes work the same way as the ones in the previous section 🎀 there is no definition for the certificate bag, because the same attribute would be used for both the sender and recipient certificates, so why would we need two 🙈

x5chain-sender: This header parameter contains the chain of certificates starting with the sender's key exchange certificate. The structure is the same as x5chain.

x5t-sender: This header parameter contains the hash value for the sender's key exchange certificate. The structure is the same as x5t.

x5u-sender: This header parameter contains a URI for the sender's key exchange certificate. The structure and processing are the same as x5u.

Here's the table, bestie 📋✨

   +==============+=====+=============+===================+===========+
   |Name          |Label|Type         | Algorithm         |Description|
   +==============+=====+=============+===================+===========+
   |x5t-sender    |-27  |COSE_CertHash| ECDH-SS+HKDF-256, |Thumbprint |
   |              |     |             | ECDH-SS+HKDF-512, |for the    |
   |              |     |             | ECDH-SS+A128KW,   |sender's   |
   |              |     |             | ECDH-SS+A192KW,   |X.509      |
   |              |     |             | ECDH-SS+A256KW    |certificate|
   +--------------+-----+-------------+-------------------+-----------+
   |x5u-sender    |-28  |uri          | ECDH-SS+HKDF-256, |URI for the|
   |              |     |             | ECDH-SS+HKDF-512, |sender's   |
   |              |     |             | ECDH-SS+A128KW,   |X.509      |
   |              |     |             | ECDH-SS+A192KW,   |certificate|
   |              |     |             | ECDH-SS+A256KW    |           |
   +--------------+-----+-------------+-------------------+-----------+
   |x5chain-sender|-29  |COSE_X509    | ECDH-SS+HKDF-256, |static key |
   |              |     |             | ECDH-SS+HKDF-512, |X.509      |
   |              |     |             | ECDH-SS+A128KW,   |certificate|
   |              |     |             | ECDH-SS+A192KW,   |chain      |
   |              |     |             | ECDH-SS+A256KW    |           |
   +--------------+-----+-------------+-------------------+-----------+

                  Table 2: Static ECDH Algorithm Values

4. IANA Considerations 📚

4.1. COSE Header Parameters Registry

IANA has registered the new COSE Header parameters in Table 1 in the "COSE Header Parameters" registry 🗂️ The "Value Registry" field is empty for all of the items, and for each item the "Reference" field points to this document 🌸

4.2. COSE Header Algorithm Parameters Registry

IANA has registered the new COSE Header Algorithm parameters in Table 2 in the "COSE Header Algorithm Parameters" registry ✨ For each item, the "Reference" field points to this document 💖

4.3. Media Type application/cose-x509

okay this one is a whole vibe 🦋 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 parameter "usage" is set to "chain", that sequence means a certificate chain 🔗

IANA has registered the following media type [RFC6838]:

   Type name:  application

   Subtype name:  cose-x509

   Required parameters:  N/A

   Optional parameters:  usage

      *  Can be absent to provide no further information about the
         intended meaning of the order in the CBOR sequence of
         certificates.

      *  Can be set to "chain" to indicate that the sequence of data
         items is to be interpreted as a certificate chain.

   Encoding considerations:  binary

   Security considerations:  See the Security Considerations section of
      RFC 9360.

   Interoperability considerations:  N/A

   Published specification:  RFC 9360

   Applications that use this media type:  Applications that employ COSE
      and use X.509 as a certificate type.

   Fragment identifier considerations:  N/A

   Additional information:

      Deprecated alias names for this type:  N/A
      Magic number(s):  N/A
      File extension(s):  N/A
      Macintosh file type code(s):  N/A

   Person & email address to contact for further information:
      iesg@ietf.org

   Intended usage:  COMMON

   Restrictions on usage:  N/A

   Author:  COSE WG

   Change controller:  IESG

5. Security Considerations 🔒💀

okay, this section is seriously important bestie, so pay attention 🫶 establishing trust in a certificate is a vital part of processing 😭 a big piece of that is figuring out what your trust anchors are for the process. a brand-new self-signed certificate showing up on the client can NOT be the thing that changes your set of trust anchors, because a well-defined trust-establishment process is required 🚫 one common way a new trust anchor gets added to (or removed from) a device is a new firmware upgrade 🔧

in constrained systems, there's a trade-off between the order of checking the signature and checking the certificate for validity ⚖️ validating certificates can mean reaching out to the network for revocation information or to retrieve certificates during path building, and that network access can eat up power and network bandwidth 🔋 on the flip side, if you validate the certificates after the signature, an oracle can potentially be built by detecting those network resources, which only happens when the signature validation passes 👀 in any event, both the signature validation and the certificate validation MUST be completed successfully before acting on any requests 🛑

unless it is known that the Certificate Authority (CA) required proof of possession of the subject's private key to issue an end-entity certificate, the end-entity certificate MUST be integrity protected by COSE 🔏 without proof of possession, an attacker can trick the CA into issuing an identity-misbinding certificate with someone else's "borrowed" public key but a different subject 😱 then an on-path attacker can run an identity-misbinding attack by swapping the real end-entity certificate in COSE for that misbinding certificate 🙅‍♀️

end-entity X.509 certificates contain identities that a passive on-path attacker eavesdropping on the conversation can use to identify and track the subject 👁️ COSE doesn't provide identity protection by itself, and the x5t and x5u header parameters are just alternative permanent identifiers that can also be used to track the subject 🕵️‍♀️ to get identity protection, COSE can be sent inside another security protocol that provides confidentiality 🔐

before using the key in a certificate, the key MUST be checked against the algorithm you're going to use, and any algorithm-specific checks need to be made 🧐 those checks can include validating that points are on curves for elliptic curve algorithms, and that the sizes of RSA keys are within an acceptable range 📏 using unvalidated keys can lead to a loss of security or excessive consumption of resources (for example, using a 200K RSA key) 🥵

when you process the x5u header parameter, the security considerations of [RFC3986], and specifically those defined in Section 7.1 of [RFC3986], also apply 🚨

no matter where the certificate came from, certification path validation is a big part of establishing trust in it 🛤️ Section 6 of [RFC5280] gives guidance for path validation, and the security considerations of [RFC5280] are also important for using this document correctly 📖

protecting the integrity of the x5bag, x5chain, and x5t contents by putting them in the protected header bucket can help mitigate some risks of a misbehaving CA (cf. Section 5.1 of [RFC2634]) 🛡️

the security of the algorithm used for x5t doesn't affect the security of the system, because this header parameter just selects which certificate already on the system should be used. it doesn't provide any trust 💅

6. References 📚🎀

6.1. Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC8152]  Schaad, J., "CBOR Object Signing and Encryption (COSE)",
              RFC 8152, DOI 10.17487/RFC8152, July 2017,
              <https://www.rfc-editor.org/info/rfc8152>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", STD 94, RFC 8949,
              DOI 10.17487/RFC8949, December 2020,
              <https://www.rfc-editor.org/info/rfc8949>.

   [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Structures and Process", STD 96, RFC 9052,
              DOI 10.17487/RFC9052, August 2022,
              <https://www.rfc-editor.org/info/rfc9052>.

6.2. Informative References 📚✨

okay so these are the informative references, aka the extra reading list 🎀 they're not required to implement the spec, but they're the receipts that the rest of the doc points to 💅

Acknowledgements 🕊️

Jim Schaad passed away on 3 October 2020, and that's a huge loss 💜 This document is primarily his work, and Jim deserves all the credit for the technical content 🫶 After Jim's untimely death, Ivaylo Petrov stepped in as the document editor, mostly helping with the approval and publication processes 🌸

Author's Address 📮

Jim Schaad
August Cellars
📦 where this page comes from