CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates
RFC 9360
| Document | Type |
RFC
- Proposed Standard
(February 2023)
Was
draft-ietf-cose-x509
(cose WG)
|
|
|---|---|---|---|
| Author | J. Schaad | ||
| Last updated | 2026-05-20 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Paul Wouters | |
| Send notices to | (None) |
RFC 9360
Internet Engineering Task Force (IETF) J. Schaad
Request for Comments: 9360 August Cellars
Category: Standards Track February 2023
ISSN: 2070-1721
CBOR Object Signing and Encryption (COSE): Header Parameters for
Carrying and Referencing X.509 Certificates
Abstract
The CBOR Object Signing and Encryption (COSE) message structure uses
references to keys in general. For some algorithms, additional
properties are defined 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 way that keys can be
identified and transported by providing attributes that refer to or
contain X.509 certificates.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9360.
Copyright Notice
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) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided 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
In the process of writing [RFC8152] and [RFC9052], the CBOR Object
Signing and Encryption (COSE) Working Group discussed X.509
certificates [RFC5280] and decided that no use cases were presented
that 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 implication, applications will need a documented
and consistent way to handle such certificates. This document
defines a set of attributes that will allow applications to transport
and refer to X.509 certificates in a consistent manner.
In some of these cases, a constrained device is being deployed in the
context of an existing X.509 PKI: for example, [Constrained-BRSKI]
describes a device enrollment solution that relies on the presence of
a factory-installed certificate on the device. [EDHOC] was also
written with the idea that long-term certificates could be used to
provide for authentication of devices and establish session keys.
Another possible 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 central authentication authority. Basing such
an application on public key certificates allows it to make use of
well-established key management disciplines.
1.1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. X.509 COSE Header Parameters
The use of X.509 certificates allows for an existing trust
infrastructure to be used with COSE. This includes the full suite of
enrollment protocols, trust anchors, trust chaining, and revocation
checking that have been defined over time by the IETF and other
organizations. The Concise Binary Object Representation (CBOR) key
structures [RFC8949] that have been defined in COSE currently do not
support all of these properties, although some may be found in CBOR
Web Tokens (CWTs) [RFC8392].
It is not necessarily expected that constrained devices themselves
will evaluate and process X.509 certificates: it is perfectly