| Internet-Draft | CBOR Simple Value for CSF | April 2025 |
| Rundgren | Expires 21 October 2025 | [Page] |
This document defines a CBOR "simple" value to be used as a unique label for a container map holding an embedded signature.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 21 October 2025.¶
Copyright (c) 2025 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.¶
This document defines a CBOR [RFC8949] "simple" value to be used as unique labels (map keys) to containers holding embedded signature constructs [CSF]. The primary purpose of the unique label is to securely decouple application-specific labels from the signature container. In addition to eliminating the need for application-specific labels for embedded signature containers, the net result includes simplified signature APIs as well.¶
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.¶
This section describes the problem and its possible solution.¶
The CBOR examples are provided in "Extended Diagnostic Notation (EDN)" [I-D.ietf-cbor-edn-literals].¶
The [CSF] embedded signature scheme currently depends on an application-specific label holding the embedded signature container.¶
The following CBOR code shows a very simple example using an HMAC signature:¶
{
1: "data", # Application data
2: "more data", # Application data
-1: { # Embedded signature (CSF container)
1: 5,
6: h'4853d7730cc1340682b1748dc346cf627a5e91ce62c67fff15c40257ed2a37a1'
}
}¶
Having to define an application-specific ("custom") label for the embedded signature container is certainly not a showstopper, but it lacks "finesse". In addition, signature APIs need to deal with such labels like the following:¶
sign(signatureLabel, applicationMap).¶
Replacing the application-specific
label with a CBOR simple value,
would yield the following:¶
{
1: "data", # Application data
2: "more data", # Application data
simple(99): { # Embedded signature (CSF container)
1: 5,
6: h'237e674c7be1818ddd7eaacf40ca80415b9ad816880751d2136c45385207420c'
}
}¶
The advantages with using simple(99) include:¶
sign(applicationMap).¶
In the registry [IANA.cbor-simple-values], IANA is requested to allocate the simple value defined in Table 1.¶
| Value | Semantics | Reference |
|---|---|---|
| 99 * | Unique label | draft-rundgren-cbor-simple-4-csf-XX |
* TBD. The actual number is of no importance. The following are some musical inspirations:¶
The proposed enhanced solution does not reduce security compared to the current solution because duplicate labels SHOULD in both cases be rejected by conforming CBOR encoders and decoders.¶