draft-ietf-cose-countersign-04.txt   draft-ietf-cose-countersign-05.txt 
COSE Working Group J. Schaad COSE Working Group J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Updates: 8152 (if approved) R. Housley, Ed. Updates: 8152 (if approved) R. Housley, Ed.
Intended status: Standards Track Vigil Security Intended status: Standards Track Vigil Security
Expires: 20 November 2021 19 May 2021 Expires: 25 December 2021 23 June 2021
CBOR Object Signing and Encryption (COSE): Countersignatures CBOR Object Signing and Encryption (COSE): Countersignatures
draft-ietf-cose-countersign-04 draft-ietf-cose-countersign-05
Abstract Abstract
Concise Binary Object Representation (CBOR) is a data format designed Concise Binary Object Representation (CBOR) is a data format designed
for small code size and small message size. CBOR Object Signing and for small code size and small message size. CBOR Object Signing and
Encryption (COSE) defines a set of security services for CBOR. This Encryption (COSE) defines a set of security services for CBOR. This
document defines a countersignature algorithm along with the needed document defines a countersignature algorithm along with the needed
header parameters and CBOR tags for COSE. header parameters and CBOR tags for COSE.
Contributing to this document Contributing to this document
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 20 November 2021. This Internet-Draft will expire on 25 December 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 41 skipping to change at page 2, line 41
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5.1. CBOR Tag Assignment . . . . . . . . . . . . . . . . . . . 10 5.1. CBOR Tag Assignment . . . . . . . . . . . . . . . . . . . 10
5.2. COSE Header Parameters Registry . . . . . . . . . . . . . 11 5.2. COSE Header Parameters Registry . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 13
7.1. Author's Versions . . . . . . . . . . . . . . . . . . . . 14 7.1. Author's Versions . . . . . . . . . . . . . . . . . . . . 14
7.2. COSE Testing Library . . . . . . . . . . . . . . . . . . 14 7.2. COSE Testing Library . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 16
A.1. Use of Early Code Points . . . . . . . . . . . . . . . . 17 A.1. Use of Early Code Points . . . . . . . . . . . . . . . . 17
A.2. Examples of Signed Messages . . . . . . . . . . . . . . . 17 A.2. Examples of Signed Messages . . . . . . . . . . . . . . . 17
A.2.1. Countersignature . . . . . . . . . . . . . . . . . . 17 A.2.1. Countersignature . . . . . . . . . . . . . . . . . . 17
A.3. Examples of Signed1 Messages . . . . . . . . . . . . . . 18 A.3. Examples of Signed1 Messages . . . . . . . . . . . . . . 18
A.3.1. Countersignature . . . . . . . . . . . . . . . . . . 18 A.3.1. Countersignature . . . . . . . . . . . . . . . . . . 18
A.4. Examples of Enveloped Messages . . . . . . . . . . . . . 19 A.4. Examples of Enveloped Messages . . . . . . . . . . . . . 19
A.4.1. Countersignature on Encrypted Content . . . . . . . . 19 A.4.1. Countersignature on Encrypted Content . . . . . . . . 19
A.5. Examples of Encrypted Messages . . . . . . . . . . . . . 20 A.5. Examples of Encrypted Messages . . . . . . . . . . . . . 20
A.5.1. Countersignature on Encrypted Content . . . . . . . . 21 A.5.1. Countersignature on Encrypted Content . . . . . . . . 21
A.6. Examples of MACed Messages . . . . . . . . . . . . . . . 21 A.6. Examples of MACed Messages . . . . . . . . . . . . . . . 21
skipping to change at page 3, line 15 skipping to change at page 3, line 15
A.7. Examples of MAC0 Messages . . . . . . . . . . . . . . . . 22 A.7. Examples of MAC0 Messages . . . . . . . . . . . . . . . . 22
A.7.1. Countersignature on MAC0 Content . . . . . . . . . . 22 A.7.1. Countersignature on MAC0 Content . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
There has been an increased focus on small, constrained devices that There has been an increased focus on small, constrained devices that
make up the Internet of Things (IoT). One of the standards that has make up the Internet of Things (IoT). One of the standards that has
come out of this process is "Concise Binary Object Representation come out of this process is "Concise Binary Object Representation
(CBOR)" [I-D.ietf-cbor-7049bis]. CBOR extended the data model of the (CBOR)" [RFC8949]. CBOR extended the data model of the JavaScript
JavaScript Object Notation (JSON) [STD90] by allowing for binary Object Notation (JSON) [STD90] by allowing for binary data, among
data, among other changes. CBOR has been adopted by several of the other changes. CBOR has been adopted by several of the IETF working
IETF working groups dealing with the IoT world as their encoding of groups dealing with the IoT world as their encoding of data
data structures. CBOR was designed specifically both to be small in structures. CBOR was designed specifically both to be small in terms
terms of messages transported and implementation size and to be a of messages transported and implementation size and to be a schema-
schema-free decoder. A need exists to provide message security free decoder. A need exists to provide message security services for
services for IoT, and using CBOR as the message-encoding format makes IoT, and using CBOR as the message-encoding format makes sense.
sense.
During the process of advancing COSE to an Internet Standard, it was During the process of advancing COSE to an Internet Standard, it was
noticed the description of the security properties of noticed the description of the security properties of
countersignatures was incorrect for the COSE_Sign1 structure. Since countersignatures was incorrect for the COSE_Sign1 structure. Since
the security properties that were described, those of a true the security properties that were described, those of a true
countersignature, were those that the working group desired, the countersignature, were those that the working group desired, the
decision was made to remove all of the countersignature text from decision was made to remove all of the countersignature text from
[I-D.ietf-cose-rfc8152bis-struct] and create a new document to both [I-D.ietf-cose-rfc8152bis-struct] and create a new document to both
deprecate the old countersignature algorithm and to define a new one deprecate the old countersignature algorithm and to define a new one
with the desired security properties. with the desired security properties.
skipping to change at page 6, line 23 skipping to change at page 6, line 23
A countersignature is normally defined as a second signature that A countersignature is normally defined as a second signature that
confirms a primary signature. A normal example of a countersignature confirms a primary signature. A normal example of a countersignature
is the signature that a notary public places on a document as is the signature that a notary public places on a document as
witnessing that you have signed the document. Thus applying a witnessing that you have signed the document. Thus applying a
countersignature to either the COSE_Signature or COSE_Sign1 objects countersignature to either the COSE_Signature or COSE_Sign1 objects
match this traditional definition. This document extends the context match this traditional definition. This document extends the context
of a countersignature to allow it to be applied to all of the of a countersignature to allow it to be applied to all of the
security structures defined. It needs to be noted that the security structures defined. It needs to be noted that the
countersignature needs to be treated as a separate operation from the countersignature needs to be treated as a separate operation from the
initial operation even if it is applied by the same user as is done initial operation even if it is applied by the same user as is done
in [I-D.ietf-core-groupcomm-bis]. in [I-D.ietf-core-oscore-groupcomm].
COSE supports two different forms for countersignatures. Full COSE supports two different forms for countersignatures. Full
countersignatures use the structure COSE_Countersignature. This is countersignatures use the structure COSE_Countersignature. This is
same structure as COSE_Signature and thus it can have protected and same structure as COSE_Signature and thus it can have protected and
unprotected attributes, including chained countersignatures. unprotected attributes, including chained countersignatures.
Abbreviated countersignatures use the structure Abbreviated countersignatures use the structure
COSE_Countersignature0. This structure only contains the signature COSE_Countersignature0. This structure only contains the signature
value and nothing else. The structures cannot be converted between value and nothing else. The structures cannot be converted between
each other; as the signature computation includes a parameter each other; as the signature computation includes a parameter
identifying which structure is being used, the converted structure identifying which structure is being used, the converted structure
skipping to change at page 7, line 9 skipping to change at page 7, line 9
semantics are preserved. That is the countersignature makes a semantics are preserved. That is the countersignature makes a
statement about the existence of a signature and, when used as a statement about the existence of a signature and, when used as a
timestamp, a time point at which the signature exists. When done on timestamp, a time point at which the signature exists. When done on
a COSE_Sign, this is the same as applying a second signature to the a COSE_Sign, this is the same as applying a second signature to the
payload and adding a parallel signature as a new COSE_Signature is payload and adding a parallel signature as a new COSE_Signature is
the preferred method. When done on a COSE_Mac or COSE_Mac0, the the preferred method. When done on a COSE_Mac or COSE_Mac0, the
payload is included as well as the MAC value. When done on a payload is included as well as the MAC value. When done on a
COSE_Encrypt or COSE_Encrypt0, the existence of the encrypted data is COSE_Encrypt or COSE_Encrypt0, the existence of the encrypted data is
attested to. It should be noted that there is a big difference attested to. It should be noted that there is a big difference
between attesting to the encrypted data as opposed to attesting to between attesting to the encrypted data as opposed to attesting to
the unencrypted data. If the latter is what is desired, then one the plaintext data. Usually, the signer wishes to countersign the
needs to apply a signature to the data and then encrypt that. It is plaintext data, and then encrypt the data along with the
always possible to construct cases where the use of two different countersignature. This approach prevents an attacker from stripping
keys will appear to result in a successful decryption (the tag check countersignatures. In addition, this approach prevents an observer
success), but which produce two completely different plaintexts. from linking the public keys needed to verify the countersignatures
This situation is not detectable by a countersignature on the across different payloads. It is always possible to construct cases
encrypted data. where the use of two different keys will appear to result in a
successful decryption (the tag check success), but which produce two
completely different plaintexts. This situation is not detectable by
a countersignature on the encrypted data.
3.1. Full Countersignatures 3.1. Full Countersignatures
The COSE_Countersignature structure allows for the same set of The COSE_Countersignature structure allows for the same set of
capabilities as a COSE_Signature. This means that all of the capabilities as a COSE_Signature. This means that all of the
capabilities of a signature are duplicated with this structure. capabilities of a signature are duplicated with this structure.
Specifically, the countersigner does not need to be related to the Specifically, the countersigner does not need to be related to the
producer of what is being countersigned as key and algorithm producer of what is being countersigned as key and algorithm
identification can be placed in the countersignature attributes. identification can be placed in the countersignature attributes.
This also means that the countersignature can itself be This also means that the countersignature can itself be
skipping to change at page 10, line 29 skipping to change at page 10, line 33
(the value to sign), and sig (the signature to be verified). (the value to sign), and sig (the signature to be verified).
In addition to performing the signature verification, the application In addition to performing the signature verification, the application
performs the appropriate checks to ensure that the key is correctly performs the appropriate checks to ensure that the key is correctly
paired with the signing identity and that the signing identity is paired with the signing identity and that the signing identity is
authorized before performing actions. authorized before performing actions.
4. CBOR Encoding Restrictions 4. CBOR Encoding Restrictions
In order to always regenerate the same byte string for the "to be In order to always regenerate the same byte string for the "to be
signed" value, the deterministic encoding rules defined in signed" value, the core deterministic encoding rules defined in
Section 4.2 of [I-D.ietf-cbor-7049bis]. These rules match the ones Section 4.2.1 of [RFC8949]. These rules match the ones laid out in
laid out in Section 11 of [I-D.ietf-cose-rfc8152bis-struct]. Section 9 of [I-D.ietf-cose-rfc8152bis-struct].
5. IANA Considerations 5. IANA Considerations
The registries and registrations listed below were created during The registries and registrations listed below were created during
processing of RFC 8152 [RFC8152]. The majority of the actions are to processing of RFC 8152 [RFC8152]. The majority of the actions are to
update the references to point to this document. update the references to point to this document.
5.1. CBOR Tag Assignment 5.1. CBOR Tag Assignment
IANA is requested to register a new tag for the CounterSignature IANA is requested to register a new tag for the CounterSignature
skipping to change at page 15, line 25 skipping to change at page 15, line 25
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[I-D.ietf-cbor-7049bis] [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949,
Representation (CBOR)", Work in Progress, Internet-Draft, DOI 10.17487/RFC8949, December 2020,
draft-ietf-cbor-7049bis-16, 30 September 2020, <https://www.rfc-editor.org/info/rfc8949>.
<https://tools.ietf.org/html/draft-ietf-cbor-7049bis-16>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[I-D.ietf-cose-rfc8152bis-algs] [I-D.ietf-cose-rfc8152bis-algs]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", Work in Progress, Internet-Draft, Initial Algorithms", Work in Progress, Internet-Draft,
draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020,
<https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis- <https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-
skipping to change at page 16, line 28 skipping to change at page 16, line 24
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205, Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016, RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>. <https://www.rfc-editor.org/info/rfc7942>.
[RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence [RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence
Record Syntax (ERS)", RFC 4998, DOI 10.17487/RFC4998, Record Syntax (ERS)", RFC 4998, DOI 10.17487/RFC4998,
August 2007, <https://www.rfc-editor.org/info/rfc4998>. August 2007, <https://www.rfc-editor.org/info/rfc4998>.
[I-D.ietf-core-groupcomm-bis] [I-D.ietf-core-oscore-groupcomm]
Dijk, E., Wang, C., and M. Tiloca, "Group Communication Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P.,
for the Constrained Application Protocol (CoAP)", Work in and J. Park, "Group OSCORE - Secure Group Communication
Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- for CoAP", Work in Progress, Internet-Draft, draft-ietf-
03, 22 February 2021, <https://tools.ietf.org/html/draft- core-oscore-groupcomm-11, 22 February 2021,
ietf-core-groupcomm-bis-03>. <https://tools.ietf.org/html/draft-ietf-core-oscore-
groupcomm-11>.
[I-D.ietf-cose-rfc8152bis-struct] [I-D.ietf-cose-rfc8152bis-struct]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", Work in Progress, Internet-Draft, Structures and Process", Work in Progress, Internet-Draft,
draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021,
<https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis- <https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-
struct-15>. struct-15>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
 End of changes. 10 change blocks. 
35 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/