Skip to main content

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

Document Type RFC - Proposed Standard (February 2023)
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
Show full document