draft-ietf-cose-rfc8152bis-struct-09.txt   draft-ietf-cose-rfc8152bis-struct-10.txt 
COSE Working Group J. Schaad COSE Working Group J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Obsoletes: 8152 (if approved) 14 May 2020 Obsoletes: 8152 (if approved) 2 June 2020
Intended status: Standards Track Intended status: Standards Track
Expires: 15 November 2020 Expires: 4 December 2020
CBOR Object Signing and Encryption (COSE): Structures and Process CBOR Object Signing and Encryption (COSE): Structures and Process
draft-ietf-cose-rfc8152bis-struct-09 draft-ietf-cose-rfc8152bis-struct-10
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. There is a need for the for small code size and small message size. There is a need for the
ability to have basic security services defined for this data format. ability to have basic security services defined for this data format.
This document defines the CBOR Object Signing and Encryption (COSE) This document defines the CBOR Object Signing and Encryption (COSE)
protocol. This specification describes how to create and process protocol. This specification describes how to create and process
signatures, message authentication codes, and encryption using CBOR signatures, message authentication codes, and encryption using CBOR
for serialization. This specification additionally describes how to for serialization. This specification additionally describes how to
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 15 November 2020. This Internet-Draft will expire on 4 December 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Terminology . . . . . . . . . . . . . . . . 5 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 6
1.2. Changes from RFC8152 . . . . . . . . . . . . . . . . . . 5 1.2. Changes from RFC8152 . . . . . . . . . . . . . . . . . . 6
1.3. Design Changes from JOSE . . . . . . . . . . . . . . . . 6 1.3. Design Changes from JOSE . . . . . . . . . . . . . . . . 6
1.4. CBOR Grammar . . . . . . . . . . . . . . . . . . . . . . 6 1.4. CBOR Grammar . . . . . . . . . . . . . . . . . . . . . . 7
1.5. CBOR-Related Terminology . . . . . . . . . . . . . . . . 8 1.5. CBOR-Related Terminology . . . . . . . . . . . . . . . . 8
1.6. Document Terminology . . . . . . . . . . . . . . . . . . 8 1.6. Document Terminology . . . . . . . . . . . . . . . . . . 9
2. Basic COSE Structure . . . . . . . . . . . . . . . . . . . . 9 2. Basic COSE Structure . . . . . . . . . . . . . . . . . . . . 9
3. Header Parameters . . . . . . . . . . . . . . . . . . . . . . 13 3. Header Parameters . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Common COSE Header Parameters . . . . . . . . . . . . . . 15 3.1. Common COSE Header Parameters . . . . . . . . . . . . . . 15
4. Signing Objects . . . . . . . . . . . . . . . . . . . . . . . 18 4. Signing Objects . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Signing with One or More Signers . . . . . . . . . . . . 18 4.1. Signing with One or More Signers . . . . . . . . . . . . 18
4.2. Signing with One Signer . . . . . . . . . . . . . . . . . 20 4.2. Signing with One Signer . . . . . . . . . . . . . . . . . 20
4.3. Externally Supplied Data . . . . . . . . . . . . . . . . 21 4.3. Externally Supplied Data . . . . . . . . . . . . . . . . 21
4.4. Signing and Verification Process . . . . . . . . . . . . 22 4.4. Signing and Verification Process . . . . . . . . . . . . 22
5. Counter Signatures . . . . . . . . . . . . . . . . . . . . . 24 5. Counter Signatures . . . . . . . . . . . . . . . . . . . . . 24
5.1. Full Counter Signatures . . . . . . . . . . . . . . . . . 25 5.1. Full Counter Signatures . . . . . . . . . . . . . . . . . 25
5.2. Abbreviated Counter Signatures . . . . . . . . . . . . . 25 5.2. Abbreviated Counter Signatures . . . . . . . . . . . . . 26
6. Encryption Objects . . . . . . . . . . . . . . . . . . . . . 26 6. Encryption Objects . . . . . . . . . . . . . . . . . . . . . 26
6.1. Enveloped COSE Structure . . . . . . . . . . . . . . . . 26 6.1. Enveloped COSE Structure . . . . . . . . . . . . . . . . 26
6.1.1. Content Key Distribution Methods . . . . . . . . . . 28 6.1.1. Content Key Distribution Methods . . . . . . . . . . 28
6.2. Single Recipient Encrypted . . . . . . . . . . . . . . . 29 6.2. Single Recipient Encrypted . . . . . . . . . . . . . . . 29
6.3. How to Encrypt and Decrypt for AEAD Algorithms . . . . . 29 6.3. How to Encrypt and Decrypt for AEAD Algorithms . . . . . 29
6.4. How to Encrypt and Decrypt for AE Algorithms . . . . . . 32 6.4. How to Encrypt and Decrypt for AE Algorithms . . . . . . 32
7. MAC Objects . . . . . . . . . . . . . . . . . . . . . . . . . 33 7. MAC Objects . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1. MACed Message with Recipients . . . . . . . . . . . . . . 34 7.1. MACed Message with Recipients . . . . . . . . . . . . . . 34
7.2. MACed Messages with Implicit Key . . . . . . . . . . . . 35 7.2. MACed Messages with Implicit Key . . . . . . . . . . . . 35
7.3. How to Compute and Verify a MAC . . . . . . . . . . . . . 35 7.3. How to Compute and Verify a MAC . . . . . . . . . . . . . 35
skipping to change at page 3, line 38 skipping to change at page 3, line 38
14. Implementation Status . . . . . . . . . . . . . . . . . . . . 55 14. Implementation Status . . . . . . . . . . . . . . . . . . . . 55
14.1. Author's Versions . . . . . . . . . . . . . . . . . . . 55 14.1. Author's Versions . . . . . . . . . . . . . . . . . . . 55
14.2. JavaScript Version . . . . . . . . . . . . . . . . . . . 56 14.2. JavaScript Version . . . . . . . . . . . . . . . . . . . 56
14.3. Python Version . . . . . . . . . . . . . . . . . . . . . 56 14.3. Python Version . . . . . . . . . . . . . . . . . . . . . 56
14.4. COSE Testing Library . . . . . . . . . . . . . . . . . . 57 14.4. COSE Testing Library . . . . . . . . . . . . . . . . . . 57
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
15.1. Normative References . . . . . . . . . . . . . . . . . . 57 15.1. Normative References . . . . . . . . . . . . . . . . . . 57
15.2. Informative References . . . . . . . . . . . . . . . . . 58 15.2. Informative References . . . . . . . . . . . . . . . . . 58
Appendix A. Guidelines for External Data Authentication of Appendix A. Guidelines for External Data Authentication of
Algorithms . . . . . . . . . . . . . . . . . . . . . . . 61 Algorithms . . . . . . . . . . . . . . . . . . . . . . . 61
Appendix B. Two Layers of Recipient Information . . . . . . . . 64 Appendix B. Two Layers of Recipient Information . . . . . . . . 65
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 66 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 66
C.1. Examples of Signed Messages . . . . . . . . . . . . . . . 67 C.1. Examples of Signed Messages . . . . . . . . . . . . . . . 67
C.1.1. Single Signature . . . . . . . . . . . . . . . . . . 67 C.1.1. Single Signature . . . . . . . . . . . . . . . . . . 67
C.1.2. Multiple Signers . . . . . . . . . . . . . . . . . . 68 C.1.2. Multiple Signers . . . . . . . . . . . . . . . . . . 68
C.1.3. Counter Signature . . . . . . . . . . . . . . . . . . 69 C.1.3. Counter Signature . . . . . . . . . . . . . . . . . . 69
C.1.4. Signature with Criticality . . . . . . . . . . . . . 70 C.1.4. Signature with Criticality . . . . . . . . . . . . . 70
C.2. Single Signer Examples . . . . . . . . . . . . . . . . . 71 C.2. Single Signer Examples . . . . . . . . . . . . . . . . . 71
C.2.1. Single ECDSA Signature . . . . . . . . . . . . . . . 71 C.2.1. Single ECDSA Signature . . . . . . . . . . . . . . . 71
C.3. Examples of Enveloped Messages . . . . . . . . . . . . . 72 C.3. Examples of Enveloped Messages . . . . . . . . . . . . . 72
C.3.1. Direct ECDH . . . . . . . . . . . . . . . . . . . . . 72 C.3.1. Direct ECDH . . . . . . . . . . . . . . . . . . . . . 72
skipping to change at page 5, line 25 skipping to change at page 5, line 25
* A starting set of attributes that apply to the different security * A starting set of attributes that apply to the different security
objects. objects.
This document does not contain the rules and procedures for using This document does not contain the rules and procedures for using
specific cryptographic algorithms. Details on specific algorithms specific cryptographic algorithms. Details on specific algorithms
can be found in [I-D.ietf-cose-rfc8152bis-algs] and [RFC8230]. can be found in [I-D.ietf-cose-rfc8152bis-algs] and [RFC8230].
Details for additional algorithms are expected to be defined in Details for additional algorithms are expected to be defined in
future documents. future documents.
One feature that is present in CMS [RFC5652] that is not present in COSE was initially designed as part of a solution to provide security
this standard is a digest structure. This omission is deliberate. to Constrained RESTful Environments (CoRE), and this is done using
It is better for the structure to be defined in each document as [RFC8613] and [I-D.ietf-core-groupcomm-bis]. However, COSE is not
different protocols will want to include a different set of fields as restricted to just these cases and can be used in any place where one
part of the structure. While an algorithm identifier and the digest would consider either JOSE or CMS [RFC5652] for the purpose of
value are going to be common to all applications, the two values may providing security services. The use of COSE, like JOSE and CMS, is
not always be adjacent as the algorithm could be defined once with only in store and forward or offline protocols, different solutions
would be appropriate for online protocols although one can use COSE
in an online protocol after having done some type of online key
establishment process. Any application which uses COSE for security
services first needs to determine what security services are required
and then select the appropriate COSE structures and cryptographic
algorithms based on those needs. Section 11 provides additional
information on what applications need to specify when using COSE.
One feature that is present in CMS that is not present in this
standard is a digest structure. This omission is deliberate. It is
better for the structure to be defined in each protocol as different
protocols will want to include a different set of fields as part of
the structure. While an algorithm identifier and the digest value
are going to be common to all applications, the two values may not
always be adjacent as the algorithm could be defined once with
multiple values. Applications may additionally want to define multiple values. Applications may additionally want to define
additional data fields as part of the structure. A common structure additional data fields as part of the structure. A common structure
is going to include a URI or other pointer to where the data that is is going to include a URI or other pointer to where the data that is
being hashed is kept, allowing this to be application-specific. being hashed is kept, allowing this to be application-specific.
[I-D.ietf-cose-hash-algs] contains one such possible structure along
with defining a set of digest algorithms.
1.1. Requirements Terminology 1.1. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. Changes from RFC8152 1.2. Changes from RFC8152
skipping to change at page 7, line 28 skipping to change at page 7, line 45
uint -- an unsigned integer (major type 0). uint -- an unsigned integer (major type 0).
Two syntaxes from CDDL appear in this document as shorthand. These Two syntaxes from CDDL appear in this document as shorthand. These
are: are:
FOO / BAR -- indicates that either FOO or BAR can appear here. FOO / BAR -- indicates that either FOO or BAR can appear here.
[+ FOO] -- indicates that the type FOO appears one or more times [+ FOO] -- indicates that the type FOO appears one or more times
in an array. in an array.
* FOO -- indicates that the type FOO appears zero or more times.
Two of the constraints defined by CDDL are also used in this Two of the constraints defined by CDDL are also used in this
document. These are: document. These are:
type1 .cbor type2 -- indicates that the contents of type1, usually type1 .cbor type2 -- indicates that the contents of type1, usually
bstr, contains a value of type2. bstr, contains a value of type2.
type1 .size integer -- indicates that the contents of type1 is type1 .size integer -- indicates that the contents of type1 is
integer bytes long integer bytes long
As well as the prose description, a version of a CBOR grammar is As well as the prose description, a version of a CBOR grammar is
skipping to change at page 13, line 41 skipping to change at page 13, line 41
not going to be included in a cryptographic computation. This not going to be included in a cryptographic computation. This
bucket is encoded in the message as a binary object. This value bucket is encoded in the message as a binary object. This value
is obtained by CBOR encoding the protected map and wrapping it in is obtained by CBOR encoding the protected map and wrapping it in
a bstr object. Senders SHOULD encode a zero-length map as a zero- a bstr object. Senders SHOULD encode a zero-length map as a zero-
length byte string rather than as a zero-length map (encoded as length byte string rather than as a zero-length map (encoded as
h'a0'). The zero-length binary encoding is preferred because it h'a0'). The zero-length binary encoding is preferred because it
is both shorter and the version used in the serialization is both shorter and the version used in the serialization
structures for cryptographic computation. After encoding the map, structures for cryptographic computation. After encoding the map,
the value is wrapped in the binary object. Recipients MUST accept the value is wrapped in the binary object. Recipients MUST accept
both a zero-length byte string and a zero-length map encoded in both a zero-length byte string and a zero-length map encoded in
the binary value. The wrapping allows for the encoding of the the binary value.
protected map to be transported with a greater chance that it will
not be altered in transit. (Badly behaved intermediates could Wrapping the encoding with a byte string allows for the protected
decode and re-encode, but this will result in a failure to verify map to be transported with a greater chance that it will not be
unless the re-encoded byte string is identical to the decoded byte altered accidentally in transit. (Badly behaved intermediates
string.) This avoids the problem of all parties needing to be could decode and re-encode, but this will result in a failure to
able to do a common canonical encoding. verify unless the re-encoded byte string is identical to the
decoded byte string.) This avoids the problem of all parties
needing to be able to do a common canonical encoding.
unprotected: Contains parameters about the current layer that are unprotected: Contains parameters about the current layer that are
not cryptographically protected. not cryptographically protected.
Only header parameters that deal with the current layer are to be Only header parameters that deal with the current layer are to be
placed at that layer. As an example of this, the header parameter placed at that layer. As an example of this, the header parameter
'content type' describes the content of the message being carried in 'content type' describes the content of the message being carried in
the message. As such, this header parameter is placed only in the the message. As such, this header parameter is placed only in the
content layer and is not placed in the recipient or signature layers. content layer and is not placed in the recipient or signature layers.
In principle, one should be able to process any given layer without In principle, one should be able to process any given layer without
skipping to change at page 18, line 37 skipping to change at page 18, line 37
includes a parameter identifying which structure is being used, the includes a parameter identifying which structure is being used, the
converted structure will fail signature validation. converted structure will fail signature validation.
4.1. Signing with One or More Signers 4.1. Signing with One or More Signers
The COSE_Sign structure allows for one or more signatures to be The COSE_Sign structure allows for one or more signatures to be
applied to a message payload. Header parameters relating to the applied to a message payload. Header parameters relating to the
content and header parameters relating to the signature are carried content and header parameters relating to the signature are carried
along with the signature itself. These header parameters may be along with the signature itself. These header parameters may be
authenticated by the signature, or just present. An example of authenticated by the signature, or just present. An example of
header a parameter about the content is the content type. Examples header a parameter about the content is the content type header
of header parameters about the signature would be the algorithm and parameter. Examples of header parameters about the signature would
key used to create the signature and counter signatures. be the algorithm and key used to create the signature and counter
signatures.
RFC 5652 indicates that: RFC 5652 indicates that:
| When more than one signature is present, the successful validation | When more than one signature is present, the successful validation
| of one signature associated with a given signer is usually treated | of one signature associated with a given signer is usually treated
| as a successful signature by that signer. However, there are some | as a successful signature by that signer. However, there are some
| application environments where other rules are needed. An | application environments where other rules are needed. An
| application that employs a rule other than one valid signature for | application that employs a rule other than one valid signature for
| each signer must specify those rules. Also, where simple matching | each signer must specify those rules. Also, where simple matching
| of the signer identifier is not sufficient to determine whether | of the signer identifier is not sufficient to determine whether
skipping to change at page 24, line 24 skipping to change at page 24, line 16
to verify with), alg (the algorithm used sign with), ToBeSigned to verify with), alg (the algorithm used sign with), ToBeSigned
(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.
5. Counter Signatures 5. Counter Signatures
A counter signature is normally defined as a second signature that
confirms a primary signature. A normal example of a counter
signature is the signature that a notary public places on a document
as witnessing that you have signed the document. Thus applying a
counter signature to either the COSE_Signature or COSE_Sign1 objects
match this traditional definition. This document extends the context
of a counter signature to allow it to be applied to all of the
security structures defined. It needs to be noted that the counter
signature needs to be treated as a separate operation from the
initial operation even if it is applied by the same user as is done
in [I-D.ietf-core-groupcomm-bis].
COSE supports two different forms for counter signatures. Full COSE supports two different forms for counter signatures. Full
counter signatures use the structure COSE_Countersign. This is same counter signatures use the structure COSE_Countersign. This is same
structure as COSE_Signature and thus it can have protected structure as COSE_Signature and thus it can have protected
attributes, chained counter signatures and information about attributes, chained counter signatures and information about
identifying the key. Abbreviated counter signatures use the identifying the key. Abbreviated counter signatures use the
structure COSE_Countersign1. This structure only contains the structure COSE_Countersign1. This structure only contains the
signature value and nothing else. The structures cannot be converted signature value and nothing else. The structures cannot be converted
between each other; as the signature computation includes a parameter between 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
will fail signature validation. will fail signature validation.
skipping to change at page 47, line 17 skipping to change at page 47, line 17
* The 'alg' header parameter MUST be present in the layer. * The 'alg' header parameter MUST be present in the layer.
* A header parameter identifying the recipient's key SHOULD be * A header parameter identifying the recipient's key SHOULD be
present. A header parameter identifying the sender's key SHOULD present. A header parameter identifying the sender's key SHOULD
be present. be present.
10. CBOR Encoding Restrictions 10. CBOR Encoding Restrictions
The document limits the restrictions it imposes on the CBOR Encoder The document limits the restrictions it imposes on the CBOR Encoder
needs to work. We have managed to narrow it down to the following needs to work.
restrictions:
* The restriction applies to the encoding of the Sig_structure, the * The restriction applies to the encoding of the Sig_structure, the
Enc_structure, and the MAC_structure. Enc_structure, and the MAC_structure.
* Encoding MUST be done using definite lengths and values MUST be * Encoding MUST be done using definite lengths and values MUST be
the minimum possible length. This means that the integer 1 is the minimum possible length. This means that the integer 1 is
encoded as "0x01" and not "0x1801". encoded as "0x01" and not "0x1801".
* Applications MUST NOT generate messages with the same label used * Applications MUST NOT generate messages with the same label used
twice as a key in a single map. Applications MUST NOT parse and twice as a key in a single map. Applications MUST NOT parse and
skipping to change at page 49, line 8 skipping to change at page 49, line 8
- Advertising in the certificate (capabilities extension) - Advertising in the certificate (capabilities extension)
[RFC4262]. [RFC4262].
- Minimum requirements for the S/MIME, which have been updated - Minimum requirements for the S/MIME, which have been updated
over time [RFC2633] [RFC5751] (note that [RFC2633] has been over time [RFC2633] [RFC5751] (note that [RFC2633] has been
obsoleted by [RFC5751]). obsoleted by [RFC5751]).
12. IANA Considerations 12. 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 only known action at this time processing of RFC 8152 [RFC8152]. The majority of the actions are to
is to update the references. update the references to point to this document.
12.1. CBOR Tag Assignment 12.1. CBOR Tag Assignment
IANA assigned tags in the "CBOR Tags" registry as part of processing IANA assigned tags in the "CBOR Tags" registry as part of processing
[RFC8152]. IANA is requested to update the references from [RFC8152] [RFC8152]. IANA is requested to update the references from [RFC8152]
to this document. to this document.
IANA is requested to register a new tag for the CounterSignature IANA is requested to register a new tag for the CounterSignature
type. type.
skipping to change at page 58, line 42 skipping to change at page 58, line 42
NIST.FIPS.186-4.pdf>. NIST.FIPS.186-4.pdf>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[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-07, 9 March 2020, draft-ietf-cose-rfc8152bis-algs-08, 14 May 2020,
<https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis- <https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-
algs-07>. algs-08>.
15.2. Informative References 15.2. Informative References
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
skipping to change at page 61, line 5 skipping to change at page 61, line 5
[PVSig] Brown, D. and D. Johnson, "Formal Security Proofs for a [PVSig] Brown, D. and D. Johnson, "Formal Security Proofs for a
Signature Scheme with Partial Message Recovery", Signature Scheme with Partial Message Recovery",
DOI 10.1007/3-540-45353-9_11, LNCS Volume 2020, June 2000, DOI 10.1007/3-540-45353-9_11, LNCS Volume 2020, June 2000,
<https://doi.org/10.1007/3-540-45353-9_11>. <https://doi.org/10.1007/3-540-45353-9_11>.
[W3C.WebCrypto] [W3C.WebCrypto]
Watson, M., "Web Cryptography API", W3C Recommendation, Watson, M., "Web Cryptography API", W3C Recommendation,
January 2017, <https://www.w3.org/TR/WebCryptoAPI/>. January 2017, <https://www.w3.org/TR/WebCryptoAPI/>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>.
[RFC8230] Jones, M., "Using RSA Algorithms with CBOR Object Signing [RFC8230] Jones, M., "Using RSA Algorithms with CBOR Object Signing
and Encryption (COSE) Messages", RFC 8230, and Encryption (COSE) Messages", RFC 8230,
DOI 10.17487/RFC8230, September 2017, DOI 10.17487/RFC8230, September 2017,
<https://www.rfc-editor.org/info/rfc8230>. <https://www.rfc-editor.org/info/rfc8230>.
[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-cose-hash-algs]
Schaad, J., "CBOR Object Signing and Encryption (COSE):
Hash Algorithms", Work in Progress, Internet-Draft, draft-
ietf-cose-hash-algs-04, 29 May 2020,
<https://tools.ietf.org/html/draft-ietf-cose-hash-algs-
04>.
[I-D.ietf-core-groupcomm-bis]
Dijk, E., Wang, C., and M. Tiloca, "Group Communication
for the Constrained Application Protocol (CoAP)", Work in
Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-
00, 30 March 2020, <https://tools.ietf.org/html/draft-
ietf-core-groupcomm-bis-00>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>.
Appendix A. Guidelines for External Data Authentication of Algorithms Appendix A. Guidelines for External Data Authentication of Algorithms
During development of COSE, the requirement that the algorithm During development of COSE, the requirement that the algorithm
identifier be located in the protected attributes was relaxed from a identifier be located in the protected attributes was relaxed from a
must to a should. There were two basic reasons that have been must to a should. There were two basic reasons that have been
advanced to support this position. First, the resulting message will advanced to support this position. First, the resulting message will
be smaller if the algorithm identifier is omitted from the most be smaller if the algorithm identifier is omitted from the most
common messages in a CoAP environment. Second, there is a potential common messages in a CoAP environment. Second, there is a potential
bug that will arise if full checking is not done correctly between bug that will arise if full checking is not done correctly between
the different places that an algorithm identifier could be placed the different places that an algorithm identifier could be placed
 End of changes. 21 change blocks. 
38 lines changed or deleted 85 lines changed or added

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