]> CBOR Simple Value for CSF Independent
Montpellier France anders.rundgren.net@gmail.com https://www.linkedin.com/in/andersrundgren/
Application Internet Engineering Task Force CBOR Deterministic Encoding Cryptography Embedded Signature This document defines two CBOR "simple" values to be used as unique labels in a CBOR map holding an embedded signature.
Introduction This document defines two CBOR "simple" values to be used as unique labels in conjunction with an embedded signature design. The purpose of the unique labels is to securely decouple application-specific labels from the signature container respectively data that should be excluded from the signature. In addition to eliminating the need for application-specific labels for embedded signatures, the net result includes simplified signature APIs as well.
Requirements Language 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 when, and only when, they appear in all capitals, as shown here.
Description and Rationale This section describes the problem and its possible solution. The CBOR examples are provided in "Extended Diagnostic Notation (EDN)" .
Current Solution The 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: 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).
Enhanced Solution Replacing the application-specific label with a CBOR simple value, yields the following: The advantages with using simple(99) include:
  • Eliminates the need for application-specific labels for signature containers.
  • Simplifies signature APIs: sign(applicationMap).
  • Using deterministic encoding (a prerequisite), CBOR simple types lexicographically follow after other CBOR elements (of the type normally used as labels). This makes sense for embedded signatures, since they usually "attest" the application data that is (list-wise), situated above the signature container, like in the example.
IANA Considerations In the registry , IANA is requested to allocate the simple value defined in . Simple Values
Value Semantics Reference
99 Unique label draft-rundgren-cbor-simple-4-csf-XX
100 Unique label draft-rundgren-cbor-simple-4-csf-XX
Security Considerations 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.
References Normative References Concise Binary Object Representation (CBOR) Simple Values Internet Assigned Numbers Authority Informative References CBOR Extended Diagnostic Notation (EDN) Universität Bremen TZI This document formalizes and consolidates the definition of the Extended Diagnostic Notation (EDN) of the Concise Binary Object Representation (CBOR), addressing implementer experience. Replacing EDN's previous informal descriptions, it updates RFC 8949, obsoleting its Section 8, and RFC 8610, obsoleting its Appendix G. It also specifies and uses registry-based extension points, using one to support text representations of epoch-based dates/times and of IP addresses and prefixes. // (This cref will be removed by the RFC editor:) The present // revision (–16) addresses the first half of the WGLC comments, // except for the issues around the specific way how to best achieve // pluggable ABNF grammars for application-extensions. It is // intended for use as a reference document for the mid-WGLC CBOR WG // interim meeting on 2025-01-08. CBOR Signature Format (CSF)
Document History
  • 00. First cut.
  • 01. simple(100) added.
Acknowledgements TBD