1. Introduction
There has been an increased focus on small, constrained devices that make up the Internet of Things (IoT). One of the standards that has come out of this process is "Concise Binary Object Representation (CBOR)" [RFC8949]. CBOR extended the data model of the JavaScript Object Notation (JSON) [STD90] by allowing for binary data, among other changes. CBOR has been adopted by several of the IETF working groups dealing with the IoT world as their method of encoding data structures. CBOR was designed specifically to be small in terms of both messages transported and implementation size and to have a schema-free decoder. A need exists to provide message security services for IoT, and using CBOR as the message-encoding format makes sense.
A countersignature is a second signature that confirms the primary signature. During the process of advancing CBOR Object Signing and Encryption (COSE) to Internet Standard, it was noticed that the description of the security properties of countersignatures was incorrect for the COSE_Sign1 structure mentioned in Section 4.5 of [RFC8152]. To remedy this situation, the COSE Working Group decided to remove all of the countersignature text from [RFC9052], which obsoletes [RFC8152]. This document defines a new countersignature with the desired security properties.
The problem with the previous countersignature algorithm was that the cryptographically computed value was not always included. The initial assumption that the cryptographic value was in the third slot of the array was known not to be true at the time, but in the case of the Message Authentication Code (MAC) structures this was not deemed to be an issue. The new algorithm defined in this document requires the inclusion of more values for the countersignature computation. The exception to this is the COSE_Signature structure where there is no cryptographically computed value.
The new algorithm defined in this document is designed to produce the same countersignature value in those cases where the computed cryptographic value was already included. This means that for those structures the only thing that would need to be done is to change the value of the header parameter.
With the publication of this document, implementers are encouraged to migrate uses of the previous countersignature algorithm to the one specified in this document. In particular, uses of "CounterSignature" will migrate to "CounterSignatureV2", and uses of "CounterSignature0" will migrate to "CounterSignature0V2". In addition, verification of "CounterSignature" must be supported by new implementations to remain compatible with senders that adhere to [RFC8152], which assumes that all implementations will understand "CounterSignature" as header parameter label 7. Likewise, verification of "CounterSignature0" may be supported for further compatibility.
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.
1.2. CBOR Grammar
CBOR grammar in this document uses the Concise Data Definition Language (CDDL) [RFC8610].
The collected CDDL can be extracted from the XML version of this document via the XPath expression below. (Depending on the XPath evaluator one is using, it may be necessary to deal with > as an entity.)
//sourcecode[@type='cddl']/text()
CDDL expects the initial non-terminal symbol to be the first symbol in the file. For this reason, the first fragment of CDDL is presented here.
start = COSE_Countersignature_Tagged / Internal_Types
; This is defined to make the tool quieter:
Internal_Types = Countersign_structure / COSE_Countersignature0
The non-terminal Internal_Types is defined for dealing with the automated validation tools used during the writing of this document. It references those non-terminals that are used for security computations but are not emitted for transport.
1.3. Document Terminology
In this document, we use the following terminology.
"Byte" is a synonym for "octet".
The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use in constrained systems. It is defined in [RFC7252].
"Context" is used throughout this document to represent information that is not part of the COSE message. Information that is part of the context can come from different sources, including protocol interactions, associated key structures, and application configuration. The context to use can be implicit, identified using either the "kid context" header parameter defined in [RFC8613] or a protocol-specific identifier. Context should generally be included in the cryptographic construction; for more details, see Section 4.4 of [RFC9052].
The term "byte string" is used for sequences of bytes, while the term "text string" is used for sequences of characters.