Skip to main content

CBOR Object Signing and Encryption (COSE): Initial Algorithms
draft-ietf-cose-rfc8152bis-algs-12

Revision differences

Document history

Date Rev. By Action
2024-01-26
12 Gunter Van de Velde Request closed, assignment withdrawn: Ron Bonica Last Call OPSDIR review
2024-01-26
12 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue
2022-08-17
12 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-07-13
12 (System) RFC Editor state changed to AUTH48
2021-05-10
12 (System) RFC Editor state changed to RFC-EDITOR from REF
2021-02-16
12 (System) RFC Editor state changed to REF from EDIT
2021-02-09
12 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2021-02-09
12 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2021-02-09
12 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-02-01
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-02-01
12 (System) IANA Action state changed to In Progress from On Hold
2021-02-01
12 (System) RFC Editor state changed to EDIT from MISSREF
2020-09-24
12 Jim Schaad New version available: draft-ietf-cose-rfc8152bis-algs-12.txt
2020-09-24
12 (System) New version accepted (logged-in submitter: Jim Schaad)
2020-09-24
12 Jim Schaad Uploaded new revision
2020-08-11
11 (System) IANA Action state changed to On Hold from In Progress
2020-08-10
11 (System) IANA Action state changed to In Progress from Waiting on Authors
2020-08-10
11 (System) IANA Action state changed to Waiting on Authors from In Progress
2020-08-06
11 (System) IANA Action state changed to In Progress from Waiting on Authors
2020-08-05
11 (System) IANA Action state changed to Waiting on Authors from In Progress
2020-07-30
11 (System) RFC Editor state changed to MISSREF
2020-07-30
11 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-07-30
11 (System) Announcement was received by RFC Editor
2020-07-30
11 (System) IANA Action state changed to In Progress
2020-07-30
11 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2020-07-30
11 Cindy Morgan IESG has approved the document
2020-07-30
11 Cindy Morgan Closed "Approve" ballot
2020-07-30
11 Cindy Morgan Ballot approval text was generated
2020-07-30
11 Barry Leiba IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2020-07-01
11 Jim Schaad New version available: draft-ietf-cose-rfc8152bis-algs-11.txt
2020-07-01
11 (System) New version accepted (logged-in submitter: Jim Schaad)
2020-07-01
11 Jim Schaad Uploaded new revision
2020-06-29
10 Benjamin Kaduk
[Ballot comment]
Thank you for addressing my Discuss point.

I guess I was expecting a little more text as well as the [HKDF] reference
in …
[Ballot comment]
Thank you for addressing my Discuss point.

I guess I was expecting a little more text as well as the [HKDF] reference
in Section 5.1, though I confess I am not entirely sure what I was expecting
such text to actually say...
2020-06-29
10 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2020-06-26
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-06-26
10 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-06-26
10 Jim Schaad New version available: draft-ietf-cose-rfc8152bis-algs-10.txt
2020-06-26
10 (System) New version accepted (logged-in submitter: Jim Schaad)
2020-06-26
10 Jim Schaad Uploaded new revision
2020-06-18
09 Jean Mahoney Closed request for Last Call review by GENART with state 'Overtaken by Events'
2020-06-12
09 Sabrina Tanamal IANA Experts State changed to Expert Reviews OK
2020-06-12
09 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2020-06-11
09 Jean Mahoney Assignment of request for Last Call review by GENART to Francis Dupont was marked no-response
2020-06-11
09 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2020-06-11
09 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2020-06-10
09 Murray Kucherawy
[Ballot comment]
As others have pointed out, the Abstract needs fixing.

I'm surprised none of my colleagues thought the document status and downrefs problem isn't …
[Ballot comment]
As others have pointed out, the Abstract needs fixing.

I'm surprised none of my colleagues thought the document status and downrefs problem isn't worthy of a DISCUSS, because it's important to get right.  But as one of the newbies of the group I'll go along with them and merely pile on by mentioning it again.

And lo, a bunch of editorial nits:

Section 1:
* "... small in terms of messages transport and implementation size ..." -- s/messages/message/

Section 1.4:
* Missing period at the end of the last sentence.

Section 2:
* "Part Section 9.1 of ..." -- remove "Part"

Section 2.1:
* "... collisions of this value leads to ..." -- s/leads/lead/
* "(2 coordinate elliptic curve)" -- suggest "two" instead of "2"

OLD:
  Other documents can define it to work with other curves and points in the future.
NEW:
  Future documents may extend support to include other curves and points.

Section 2.1.1:
* "... truncate a hash function down ..." -- "down" feels redundant here

Section 2.2.1:
* "... for this reason, they should not be used with the other algorithm." -- I don't understand what this is saying.

Section 3:
* "Part Section 9.2 of ..." -- remove "Part"
* "... such as MD5 has decreased over time; the security ..." -- s/;/,/

Section 3.2:
* Where is "IV" defined?

Section 3.2.1:
* "Cipher Block Chaining (CBC) mode, if the same key ..." -- maybe add "In" at the front?

Section 4:
* Errant "Part" at the front again.

Section 5:
* ... and again.

Section 5.1:
* I had to look up what a "bstr" is.  Is that definition assumed to be imported from somewhere?

Section 6:
* "Part" again.

Section 8:
* I don't understand the second paragraph of this section.

Section 10.2:
* "... this registration, if this is ..."  -- "If" should start a new sentence.
* "... then the DE should be ..." -- s/DE/Designated Expert/

Section 11:
* "One area that has been starting to get exposure is doing traffic ..." -- the word "doing" feels out of place here
2020-06-10
09 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2020-06-10
09 Benjamin Kaduk
[Ballot discuss]
I think we need to check the [MAC] reference; following links (and
chasing redirects) seems to only find a 1985 publication that talks …
[Ballot discuss]
I think we need to check the [MAC] reference; following links (and
chasing redirects) seems to only find a 1985 publication that talks
about DES, with no mention of AES-CBC-MAC.
2020-06-10
09 Benjamin Kaduk
[Ballot comment]
It's interesting that both -struct and -algs make the claim in the
Abstract that "this specification describes how to create and process
signatures, …
[Ballot comment]
It's interesting that both -struct and -algs make the claim in the
Abstract that "this specification describes how to create and process
signatures, message authentication codes, and encryption using CBOR for
serialization".  Shouldn't that only be true for one of them?

I'd really like to see a reference for the analysis of and
validity/safety of the deviations from RFC 5869 HKDF, in Section 5.1.

Section 1

Should we refer to RFC 8259 by its STD number (90)?

Section 1.3

We don't seem to use the "AE" term (just -struct does).

Section 2.1.1

  Note: Use of a deterministic signature technique is a good idea even
  when good random number generation exists.  Doing so both reduces the

Note the ongoing work in the CFRG on "deterministic signatures with
additional randomness" (the name has been changing a bit recently), and
fault attacks on deterministic signatures.

Section 2.2.1

  How public values are computed is not the same when looking at EdDSA
  and Elliptic Curve Diffie-Hellman (ECDH); for this reason, they
  should not be used with the other algorithm.

Just to check: the claim is that EdDSA and ECDH compute public values
differently (not EdDSA and ECDSA?), but that EdDSA keys should not be
used with algorithms other than EdDSA?

  If batch signature verification is performed, a well-seeded
  cryptographic random number generator is REQUIRED.  Signing and non-
  batch signature verification are deterministic operations and do not
  need random numbers of any kind.

RFC 8032 doesn't talk about "batch" at all, so a reference is probably
in order.

Section 3.1

  Some recipient algorithms transport the key, while others derive a
  key from secret data.  For those algorithms that transport the key
  (such as AES Key Wrap), the size of the HMAC key SHOULD be the same
  size as the underlying hash function.  For those algorithms that
  derive the key (such as ECDH), the derived key MUST be the same size
  as the underlying hash function.

"same size as the output of the underlying hash function", please --
hash functions can also have an internal block size that is larger.

Section 3.2.1

  *  A single key must only be used for messages of a fixed or known
      length.  If this is not the case, an attacker will be able to

What's an example of a known-but-not-fixed length message?  Just
something with internal framing?

Section 4.1

  The Galois/Counter Mode (GCM) mode is a generic authenticated
  encryption block cipher mode defined in [AES-GCM].  The GCM mode is
  combined with the AES block encryption algorithm to define an AEAD
  cipher.

GCM on its own is merely AE but AES-GCM is AEAD?  That doesn't seem to
add up...

Section 6.1.2

  If the salt/nonce value is generated randomly, then it is suggested
  that the length of the random value be the same length as the hash
  function underlying HKDF.  While there is no way to guarantee that it

"output length of the hash function", please.

Section 6.2, 6.3, 6.4

Why does Direct Key [encryption] get its own top-level subsection with
reference to -struct, but we jump straight into AES Key Wrap without a
wrapping "Key Wrap" subsection or -struct reference, and likewise for
"Direct Key Agreement" and "Key Agreement with Key Wrap"?  It feels like
Section 6.1 is the outlier here.

Section 6.3

      be unique for the pair of keys being used.  It is acceptable to
      use a global counter that is incremented for every static-static
      operation and use the resulting value.  When using static keys,

Perhaps say something strongly worded about storing the updated counter
value to permanent storage before using the resulting key?

Section 7.2

s/X25591/X25519/

Section 8

  The algorithm identifier is not part of the capabilities data as it
  should already be part of message structure.  There is a presumption
  in the way that this is laid out is that the algorithm identifier

nit: strike the last "is".

  itself is not needed to be a part of this as it is specified in a
  different location.

nit(?): "be a part of this" is a little vague/informal.

  capabilities.  This means that if one wishes to enumerate all of the
  capabilities for a device which implements ECDH, it requires multiple
  pairs of capability structures (algorithm, key) to deal with the
  different key types and curves that are supported.  For a key, the

An example of this would be pretty helpful.

Section 8.1

  *  OKP, EC2: The list of capabilities is:

      -  The key type value.  (1 for OKP or 2 for EC2.)

      -  One curve for that key type from the "COSE Elliptic Curve"
        registry.

Am I reading this right that the idea is to use capabilities to lock a
key down to a single curve?

  *  Symmetric: The list of capabilities is:

      -  The key type value (4).

but we're not using this opportunity to indicate whether a symmetric key
is for encryption vs. HMAC?

Section 8.2

  (from the "COSE Key Types" Registry).  It is expected future
  registered algorithms could have zero, one, or multiple elements.

nit: missing "that".

Section 10

Is [this document] going to be added as a reference on these registries?
Should it replace or augment 8152 in that role?

I think that the COSE Header Algorithm Parameters Registry updates need
to be in this document, not -struct.

Section 10.1, 10.2

Do we want to say anything about the encoded verson of the Capabilities
array being an array of integers?

Section 10.2

Why is the word "reserved" in the description for the IV-GENERATION
algorithm?

Section 11

I'm not 100% sure that we want the security considerations to be so
close to identical between -struct and -algs.

  One area that has been starting to get exposure is doing traffic
  analysis of encrypted messages based on the length of the message.

I think this may have graduated from "starting" to be more of a
mainstream thing :)

Section 12.1

Trying to chase [MAC] gives me a "reference has moved" notice.
I guess there's a newer version?

Section 12.2

I think RFC 8017 needs to be normative, since we use it for I2OSP

Acknowledgments

Göran could probably get his proper name, now.
2020-06-10
09 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2020-06-10
09 Amanda Baber IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2020-06-10
09 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-06-10
09 Éric Vyncke
[Ballot comment]
Thank you for the work on this document. To be honest, I had only time to quickly browse through: I am trusting the …
[Ballot comment]
Thank you for the work on this document. To be honest, I had only time to quickly browse through: I am trusting the security AD for the security considerations.

Not really important but I wonder why the security considerations are spread through all the document (sections 3.1.1, 3.2.1, ...). It obviously makes the text clearer and easier to read but may I suggest to rename those sections in something more specific (to avoid the comparaison with the well-know security considerations section of all I-D -- that is Section 11 in this document) : e.g., "Section 4.2.1 Security Considerations of AES CCM". I noted that this is used in "6.2.1.  Security Considerations for AES-KW" already, just be consistent ;-)

Hope this helps

-éric
2020-06-10
09 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-06-09
09 Martin Duke
[Ballot comment]
As everyone else has pointed out, the header needs to be fixed to indicate this is Informational, not Standards Track.

Section 1.
s/messages …
[Ballot comment]
As everyone else has pointed out, the header needs to be fixed to indicate this is Informational, not Standards Track.

Section 1.
s/messages transport/message transport
s/of the Javascript/of Javascript

Sec 1.3
In the definitions of “AE” and “AEAD”, I don’t understand the functional difference between authentication of “plaintext contents” (AE) and authentication of “non-encrypted data” (AEAD). AFAICT AE isn’t actually used in the document, so it might be easiest to simply delete it.

Sec 1.5. Replace the URL with a reference.

I actually read this whole document but got pretty lost by the end, not being an expert in this area.
2020-06-09
09 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2020-06-09
09 Alvaro Retana
[Ballot comment]
(1) I am concerned -- confused may be a better word -- about the status of this document for several reasons:

(a) The …
[Ballot comment]
(1) I am concerned -- confused may be a better word -- about the status of this document for several reasons:

(a) The header on this document still says that it is intended to remain in
    the Standards Track -- but the datatracker says that is should be
    Informational.  This is simply a nit.

(b) Except for a note when the publication was requested [1], I didn't find
    any other discussion in the mail archive.  Was the status discussed in
    the WG?

    The Shepherd writeup [2] does say that the status "marks the state of
    consensus at the time of publication, and allows for the flexibility to
    deprecate and obsolete in the future."  Except for potentially a higher
    bar when updating an Internet Standard, the process is the same...

(c) The fact that this document resulted from the split of rfc8152 confuses
    me even more: the "other half" (rfc8152bis-struct) is moving on as an
    Internet Standard and it includes a Normative reference to this document. 
    Note that the Normative reference makes sense, but the Informational
    status of this document doesn't...at least to me.  Even though we can
    use DownRefs, it seems unnecessary to "downgrade" this part of the
    document and end up with a downref to an Informational document...

This is a non-blocking comment...I simply don't understand.

[1] https://mailarchive.ietf.org/arch/msg/cose/tVDVZtfBhfYsKiqT0kCtkGoL_2U/
[2] https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/shepherdwriteup/


(2) §10.1/§10.2: The references should be changed from rfc8152 to this document.


(3) §10.2 (Changes to "COSE Algorithms" registry)

  IANA is requested to create a new column in the "COSE Algorithms"
  registry.  The new column is to be labeled "Capabilities".  The new
  column is populated with "[kty]" for all current, non-provisional,
  registrations.  It is expected that the documents which define those
  algorithms will be expanded to include this registration, if this is
  not done then the DE should be consulted before final registration
  for this document is done.

I am not sure what is the expectation here; a new column is added and all the entries are populated with "[kty]" -- so far so good.  What I don't understand is the part about other "documents...will be expanded to include this registration".  Does that mean that the other documents need to be updated?  What should the DE do if the work is not completed?  I am even more confused because this document doesn't seem to take an action related to that new column for the algorithms defined here, and the new row (in this same section) doesn't include the Capabilities column.


(4) §10.2: "Note to IANA: There is an action in [I-D.ietf-cose-rfc8152bis-struct] which also modifies data in the reference column."  I didn't see that action in the other document.


(5) I assume that this document (and not -struct) should also update the COSE Elliptic Curves registry.
2020-06-09
09 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-06-09
09 Robert Wilton
[Ballot comment]
Hi,

I've only reviewed the diff against RFC8152.  The vast majority of this document seemed to have only minimal changes and looked …
[Ballot comment]
Hi,

I've only reviewed the diff against RFC8152.  The vast majority of this document seemed to have only minimal changes and looked fine from what I could see.

A few minor comments that may help improve the document:

Abstract

  Concise Binary Object Representation (CBOR) is a data format designed
  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.
  This document defines the CBOR Object Signing and Encryption (COSE)
  protocol.  This specification describes how to create and process
  signatures, message authentication codes, and encryption using CBOR
  for serialization.  COSE additionally describes how to represent
  cryptographic keys using CBOR.

  In this specification the conventions for the use of a number of
  cryptographic algorithms with COSE.
 
First sentence of the second paragraph doesn't quite scan, and I wasn't convinced that the first paragraph is necessarily correct/accurate after the document split (in particular the "This document" and "This specification" bits).

Section 7.2

  x:  This contains the public key.  The byte string contains the
        public key as defined by the algorithm.  (For X25591, internally
        it is a little-endian integer.)

  d:  This contains the private key.
 
One minor thing that I noted, is that you define that the public key is defined by the algorithm, but don't say the same thing for the private key.  If you change this, then you might want to check other references to "private key" as well.

8.  COSE Capabilities

  The concept is being pulled forward and defined now for
  COSE.
 
Perhaps rephrase this to: "This document defines the same concept for COSE."


8.  COSE Capabilities

  The algorithm identifier is not part of the capabilities data as it
  should already be part of message structure.  There is a presumption
  in the way that this is laid out is that the algorithm identifier
  itself is not needed to be a part of this as it is specified in a
  different location.
 
I found the second sentence somewhat unclear and could probably be wordsmithed, in particular does "this" refer to the capabilities data or the message structure.

8.  COSE Capabilities

  Two different types of capabilities are defined: capabilities for
  algorithms and capabilities for key structures.  Once defined by
  registration with IANA, the list of capabilities is immutable.  If it
  is later found that a new capability is needed for a key type or an
  algorithm, it will require that a new code point be assigned to deal
  with that.  As a general rule, the capabilities are going to map to
  algorithm-specific header parameters or key parameters, but they do
  not need to do so.  An example of this is the HSS-LMS key
  capabilities defined below where the hash algorithm used is included.
 
Defining the capabilities list as immutable seemed like a misnomer to me because a new IANA registration would mutate the list.  Perhaps this sentence, and the one following it, could be removed?

  The capability structure is an array of values, the order being
  dependent on the specific algorithm or key.  For an algorithm, the
  first element should always be a key type value, but the items that
  are specific to a key should not be included in the algorithm
  capabilities.  This means that if one wishes to enumerate all of the
  capabilities for a device which implements ECDH, it requires multiple
  pairs of capability structures (algorithm, key) to deal with the
  different key types and curves that are supported.  For a key, the
  first element should also be a key type value.  While this means that
  this value will be duplicated if both an algorithm and key capability
  are used, the key type is needed in order to understand the rest of
  the values.
 
Should you be using RFC 2119 language here?  And should " key should not be included" be "MUST NOT"?

For the ECDH case, does that mean that the "algorithm" entry will be duplicated with different "key" entries?  If so, would it help clarify to explicitly state this?

Thanks,
Rob
2020-06-09
09 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-06-09
09 Roman Danyliw
[Ballot comment]
Thanks for the easy to read diff on a bis document, and for addressing the SecDir feedback.

** Section 8.  Per “For an …
[Ballot comment]
Thanks for the easy to read diff on a bis document, and for addressing the SecDir feedback.

** Section 8.  Per “For an algorithm, the first element should always be a key type value, but the items that are specific to a key should not be included in the algorithm capabilities” and later “For a key, the first element should also be a key type value” is there a reason for not making these “should” into normative MUSTs?

** Section 8.  I would have benefited from more text to understand how to parse a capabilities field.  IMO, it would have been helpful to say that the first element of the array maps to the Value column of the COSE Key Type registry.  The new Capabilities column of that corresponding entry describes the semantics of the second array element.

**  Editorial Nits:
-- The text in the header notes this document is standards track.  However, the datatracker and shepherd write-up note that it is informational.  I suspect it should be fixed in this document to be informational.

-- Abstract.  Please remove the explicit references from abstract (as they are not permitted to be there)

-- Abstraction.  Editorial.  The sentence “In this specification the conventions …” is incomplete.

-- Section 1.  Editorial.  “Additional algorithms beyond what are in this document are defined elsewhere”.  IMO, this sentence doesn’t appear to add anything.  Recommend removal.

-- Section 8.  Per ”There is a presumption in the way that this is laid out is that the algorithm identifier itself is not needed to be a part of this as it is specified in a different location”, I had trouble following this sentence from the previous one – what is the double reference to “this” here?

-- Section 8.3. Typo.  s/it is encodes/, they encode/

-- Section 10.2. Typo. s/rquested/requested/
2020-06-09
09 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-06-02
09 Cindy Morgan Placed on agenda for telechat - 2020-06-11
2020-06-02
09 Barry Leiba IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2020-06-02
09 Barry Leiba Ballot has been issued
2020-06-02
09 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2020-06-02
09 Barry Leiba Created "Approve" ballot
2020-06-02
09 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2020-06-02
09 Jim Schaad New version available: draft-ietf-cose-rfc8152bis-algs-09.txt
2020-06-02
09 (System) New version accepted (logged-in submitter: Jim Schaad)
2020-06-02
09 Jim Schaad Uploaded new revision
2020-05-29
08 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2020-05-28
08 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2020-05-28
08 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-cose-rfc8152bis-algs-08. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-cose-rfc8152bis-algs-08. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete.

First, in the COSE Key Types registry on the CBOR Object Signing and Encryption (COSE) registry page located at:

https://www.iana.org/assignments/cose/

the registry is to be changed by adding a new column to the registry. The new registry will be as follows:

Name Value Description Capabilities Reference
---------+------+-----------------------------------------------+-----------------+---------
Reserved 0 This value is reserved [RFC8152]
OKP 1 Octet Key Pair [kty(1), crv] [RFC8152]
EC2 2 Elliptic Curve Keys w/ x- and y-coordinate pair [kty(2), crv] [RFC8152]
RSA 3 RSA Key [kty(3)] [RFC8230]
Symmetric 4 Symmetric Keys [kty(4)] [RFC8152]
HSS-LMS 5 Public key for HSS/LMS hash-based [kty(5), [RFC8778]
digital signature hash algorithm]

IANA understands that no other changes are to be made to the registry.

Second, in the COSE Algorithms registry also on the CBOR Object Signing and Encryption (COSE) registry page located at:

https://www.iana.org/assignments/cose/

the registry is to be changed by creating a new column labelled "Capabilities".

The new column is populated with "[kty]" for all current, non-provisional, registrations.

All registrations in the "COSE Algorithms" registry will have [ RFC-to-be ] added as a reference for all rows where it is not already present.

IANA notes that there is an action in [I-D.ietf-cose-rfc8152bis-struct] which also modifies data in the reference column. IANA will apply that action to the registry prior to the changes in this action.

Third, also in the COSE Algorithms registry also on the CBOR Object Signing and Encryption (COSE) registry page located at:

https://www.iana.org/assignments/cose/

section 10.2 requests that a single new registration be made in the registry. The text from that section is as follows:

+----------+---------------+-------------+------------+-------------+
| Name | Value | Description | Reference | Recommended |
+==========+===============+=============+============+=============+
| IV | IV-GENERATION |Reserved for | [[THIS | No |
|Generation| | doing IV | DOCUMENT]] | |
| | | generation | | |
| | |for symmetric| | |
| | | algorithms. | | |
+----------+---------------+-------------+------------+-------------+

IANA Question --> IANA assumes that the authors intend to add the Capabilities column to this new registration. What should be the entry for Capabilities for this registration?

IANA Question --> Which range should this registration appear in on the COSE Algorithms registry? The registry has seven, distinct ranges to choose from.

Fourth, in the COSE Key Type Parameters registry also on the CBOR Object Signing and Encryption (COSE) registry page located at:

https://www.iana.org/assignments/cose/

the existing entry with "Key Type" of 2 and the "Name" of "x" will have its description changed from "x-coordinate" to "Public Key"

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2020-05-26
08 Nancy Cam-Winget Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Nancy Cam-Winget. Sent review to list.
2020-05-21
08 Jean Mahoney Request for Last Call review by GENART is assigned to Francis Dupont
2020-05-21
08 Jean Mahoney Request for Last Call review by GENART is assigned to Francis Dupont
2020-05-21
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Nancy Cam-Winget
2020-05-21
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Nancy Cam-Winget
2020-05-19
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Ron Bonica
2020-05-19
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Ron Bonica
2020-05-15
08 Amy Vezza IANA Review state changed to IANA - Review Needed
2020-05-15
08 Amy Vezza
The following Last Call announcement was sent out (ends 2020-05-29):

From: The IESG
To: IETF-Announce
CC: cose-chairs@ietf.org, cose@ietf.org, Matthew Miller , linuxwolf+ietf@outer-planes.net, …
The following Last Call announcement was sent out (ends 2020-05-29):

From: The IESG
To: IETF-Announce
CC: cose-chairs@ietf.org, cose@ietf.org, Matthew Miller , linuxwolf+ietf@outer-planes.net, barryleiba@gmail.com, draft-ietf-cose-rfc8152bis-algs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (CBOR Object Signing and Encryption (COSE): Initial Algorithms) to Informational RFC


The IESG has received a request from the CBOR Object Signing and Encryption
WG (cose) to consider the following document: - 'CBOR Object Signing and
Encryption (COSE): Initial Algorithms'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-05-29. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Concise Binary Object Representation (CBOR) is a data format designed
  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.
  This document defines the CBOR Object Signing and Encryption (COSE)
  protocol.  This specification describes how to create and process
  signatures, message authentication codes, and encryption using CBOR
  for serialization.  COSE additionally describes how to represent
  cryptographic keys using CBOR.

  In this specification the conventions for the use of a number of
  cryptographic algorithms with COSE.  The details of the structure of
  COSE are defined in [I-D.ietf-cose-rfc8152bis-struct].

  This document along with [I-D.ietf-cose-rfc8152bis-struct] obsoletes
  RFC8152.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/



No IPR declarations have been submitted directly on this I-D.




2020-05-15
08 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2020-05-15
08 Barry Leiba Ballot writeup was changed
2020-05-15
08 Barry Leiba Last call was requested
2020-05-15
08 Barry Leiba Last call announcement was generated
2020-05-15
08 Barry Leiba Ballot approval text was generated
2020-05-15
08 Barry Leiba Ballot writeup was generated
2020-05-15
08 Barry Leiba IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2020-05-14
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-05-14
08 Jim Schaad New version available: draft-ietf-cose-rfc8152bis-algs-08.txt
2020-05-14
08 (System) New version approved
2020-05-14
08 (System) Request for posting confirmation emailed to previous authors: Jim Schaad
2020-05-14
08 Jim Schaad Uploaded new revision
2020-05-14
07 Barry Leiba IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2020-05-11
07 Barry Leiba IESG state changed to AD Evaluation from Publication Requested
2020-05-11
07 Barry Leiba Shepherding AD changed to Barry Leiba
2020-03-31
07 Matthew Miller
# Summary

The document draft-ietf-rfc8152bis-algs is an update to CBOR Object Signing and Encryption (COSE) to addressing outstanding errata, make other clarifications and fixes.  This …
# Summary

The document draft-ietf-rfc8152bis-algs is an update to CBOR Object Signing and Encryption (COSE) to addressing outstanding errata, make other clarifications and fixes.  This is part of a set — this for the algorithms, the other detailing the structure and process — that together obsolete RFC 8152.

This work is a product of the COSE Working Group.  The document shepherd is Matthew Miller, and the responsible Area Director is Benjamin Kaduk.

# Differing Statuses

This -algs document is intended to be published as informational, rather than as Internet Standard as is its -struct counterpart.  This is intentional: cryptographic algorithms become obsolete over time as improvements in computing and mathematics can realize vulnerabilities and deficiencies not possible when first published.  Publishing as Information marks the state of consensus at the time of publication, and allows for the flexibility to deprecate and obsolete in the future. 

# Review and Consensus

This document received wide review from various implementers, including those used in real-world deployments.  There were a number of editorial comments and some substantive commentary, with consensus to publish.

Additional care during editing and review of this document and draft-ietf-cose-rfc8152bis-struct were taken to ensure as best as possible that various (internal) references made in the original RFC 8152 have proper (external) references.  All errata from RFC 8152 that is relevant to the COSE algorithms has been addressed therein.

# References

The CryptoForum Research Group (CFRG) published algorithm documents as Informational; the normative references are expected and exist in the Downref Registry.  The only exception is RFC 8439 (ChaCha20/Poly1035), which ought to be added to the Downref Registry.

The normatively referenced documents from NIST and SECG are the authoritative description for those algorithms; these "downrefs" are expected.

This document and draft-ietf-cose-rfc8152bis-algs are to be published in lockstep, and so references here to -struct (and references to this document in -struct) are expected to be updated as part of publication.  The referent to draft-ietf-cose-hash-sig, which is already in the RFC Editor's queue, is also expected to be updated as part of publication.

# Intellectual Property

The author, to the best of his knowledge, is unaware of any applicable IPR.  There are no substantive changes compared to RFC 8152, which also has no IPR notices submitted.

2020-03-31
07 Matthew Miller
# Summary

The document draft-ietf-rfc8152bis-algs is an update to CBOR Object Signing and Encryption (COSE) to addressing outstanding errata, make other clarifications and fixes.  This …
# Summary

The document draft-ietf-rfc8152bis-algs is an update to CBOR Object Signing and Encryption (COSE) to addressing outstanding errata, make other clarifications and fixes.  This is part of a set — this for the algorithms, the other detailing the structure and process — that together obsolete RFC 8152.

This work is a product of the COSE Working Group.  The document shepherd is Matthew Miller, and the responsible Area Director is Benjamin Kaduk.

# Differing Statuses

This -algs document is intended to be published as informational, rather than as Internet Standard as is its counterpart.  This is intentional: cryptographic algorithms become obsolete over time as improvements in computing and mathematics can realize vulnerabilities and deficiencies not possible when first published.  Publishing as Information marks the state of consensus at the time of publication, and allows for the flexibility to deprecate and obsolete in the future. 

# Review and Consensus

This document received wide review from various implementers, including those used in real-world deployments.  There were a number of editorial comments and some substantive commentary, with consensus to publish.

Additional care during editing and review of this document and draft-ietf-cose-rfc8152bis-struct were taken to ensure as best as possible that various (internal) references made in the original RFC 8152 have proper (external) references.  All errata from RFC 8152 that is relevant to the COSE algorithms has been addressed therein.

# References

The CryptoForum Research Group (CFRG) published algorithm documents as Informational; the normative references are expected and exist in the Downref Registry.  The only exception is RFC 8439 (ChaCha20/Poly1035), which ought to be added to the Downref Registry.

The normatively referenced documents from NIST and SECG are the authoritative description for those algorithms; these "downrefs" are expected.

This document and draft-ietf-cose-rfc8152bis-algs are to be published in lockstep, and so references here to -struct (and references to this document in -struct) are expected to be updated as part of publication.  The referent to draft-ietf-cose-hash-sig, which is already in the RFC Editor's queue, is also expected to be updated as part of publication.

# Intellectual Property

The author, to the best of his knowledge, is unaware of any applicable IPR.  There are no substantive changes compared to RFC 8152, which also has no IPR notices submitted.

2020-03-31
07 Matthew Miller Updating from Internet Standard to Information as it is is about algorithms.  An updated revision will be forthcoming to fully reflect this.
2020-03-31
07 Matthew Miller Intended Status changed to Informational from Internet Standard
2020-03-31
07 Matthew Miller
# Summary

The document draft-ietf-rfc8152bis-algs is an update to CBOR Object Signing and Encryption (COSE) to addressing outstanding errata, make other clarifications and fixes, and …
# Summary

The document draft-ietf-rfc8152bis-algs is an update to CBOR Object Signing and Encryption (COSE) to addressing outstanding errata, make other clarifications and fixes, and move it to Internet Standard.  This is part of a set — this for the algorithms, the other detailing the structure and process — that together obsolete RFC 8152.

This work is a product of the COSE Working Group.  The document shepherd is Matthew Miller, and the responsible Area Director is Benjamin Kaduk.

# Review and Consensus

This document received wide review from various implementers, including those used in real-world deployments.  There were a number of editorial comments and some substantive commentary, with consensus to publish.

Additional care during editing and review of this document and draft-ietf-cose-rfc8152bis-struct were taken to ensure as best as possible that various (internal) references made in the original RFC 8152 have proper (external) references.  All errata from RFC 8152 that is relevant to the COSE algorithms has been addressed therein.

# References

The CryptoForum Research Group (CFRG) published algorithm documents as Informational; the normative references are expected and exist in the Downref Registry.  The only exception is RFC 8439 (ChaCha20/Poly1035), which ought to be added to the Downref Registry.

The normatively referenced documents from NIST and SECG are the authoritative description for those algorithms; these "downrefs" are expected.

This document and draft-ietf-cose-rfc8152bis-algs are to be published in lockstep, and so references here to -struct (and references to this document in -struct) are expected to be updated as part of publication.  The referent to draft-ietf-cose-hash-sig, which is already in the RFC Editor's queue, is also expected to be updated as part of publication.

# Intellectual Property

The author, to the best of his knowledge, is unaware of any applicable IPR.  There are no substantive changes compared to RFC 8152, which also has no IPR notices submitted.

2020-03-31
07 Matthew Miller Responsible AD changed to Benjamin Kaduk
2020-03-31
07 Matthew Miller IETF WG state changed to Submitted to IESG for Publication from WG Document
2020-03-31
07 Matthew Miller IESG state changed to Publication Requested from I-D Exists
2020-03-31
07 Matthew Miller IESG process started in state Publication Requested
2020-03-31
07 Matthew Miller Changed consensus to Yes from Unknown
2020-03-31
07 Matthew Miller Intended Status changed to Internet Standard from None
2020-03-09
07 Jim Schaad New version available: draft-ietf-cose-rfc8152bis-algs-07.txt
2020-03-09
07 (System) New version accepted (logged-in submitter: Jim Schaad)
2020-03-09
07 Jim Schaad Uploaded new revision
2020-01-15
06 Matthew Miller
# Summary

The document draft-ietf-rfc8152bis-algs is an update to CBOR Object Signing and Encryption (COSE) to addressing outstanding errata, make other clarifications and fixes, and …
# Summary

The document draft-ietf-rfc8152bis-algs is an update to CBOR Object Signing and Encryption (COSE) to addressing outstanding errata, make other clarifications and fixes, and move it to Internet Standard.  This is part of a set — this for the algorithms, the other detailing the structure and process — that together obsolete RFC 8152.

This work is a product of the COSE Working Group.  The document shepherd is Matthew Miller, and the responsible Area Director is Benjamin Kaduk.

# Review and Consensus

This document received wide review from various implementers, including those used in real-world deployments.  There were a number of editorial comments and some substantive commentary, with consensus to publish.

Additional care during editing and review of this document and draft-ietf-cose-rfc8152bis-struct were taken to ensure as best as possible that various (internal) references made in the original RFC 8152 have proper (external) references.  All errata from RFC 8152 that is relevant to the COSE algorithms has been addressed therein.

# References

The CryptoForum Research Group (CFRG) published algorithm documents as Informational; the normative references are expected and exist in the Downref Registry.  The only exception is RFC 8439 (ChaCha20/Poly1035), which ought to be added to the Downref Registry.

The normatively referenced documents from NIST and SECG are the authoritative description for those algorithms; these "downrefs" are expected.

This document and draft-ietf-cose-rfc8152bis-algs are to be published in lockstep, and so references here to -struct (and references to this document in -struct) are expected to be updated as part of publication.  The referent to draft-ietf-cose-hash-sig, which is already in the RFC Editor's queue, is also expected to be updated as part of publication.

# Intellectual Property

The author, to the best of his knowledge, is unaware of any applicable IPR.  There are no substantive changes compared to RFC 8152, which also has no IPR notices submitted.

2019-11-21
06 Matthew Miller Notification list changed to Matthew Miller <linuxwolf+ietf@outer-planes.net>
2019-11-21
06 Matthew Miller Document shepherd changed to Matthew A. Miller
2019-11-04
06 Jim Schaad New version available: draft-ietf-cose-rfc8152bis-algs-06.txt
2019-11-04
06 (System) New version accepted (logged-in submitter: Jim Schaad)
2019-11-04
06 Jim Schaad Uploaded new revision
2019-09-11
05 Jim Schaad New version available: draft-ietf-cose-rfc8152bis-algs-05.txt
2019-09-11
05 (System) New version approved
2019-09-11
05 (System) Request for posting confirmation emailed to previous authors: Jim Schaad
2019-09-11
05 Jim Schaad Uploaded new revision
2019-08-18
04 Jim Schaad New version available: draft-ietf-cose-rfc8152bis-algs-04.txt
2019-08-18
04 (System) New version approved
2019-08-18
04 (System) Request for posting confirmation emailed to previous authors: Jim Schaad
2019-08-18
04 Jim Schaad Uploaded new revision
2019-06-10
03 Jim Schaad New version available: draft-ietf-cose-rfc8152bis-algs-03.txt
2019-06-10
03 (System) New version approved
2019-06-10
03 (System) Request for posting confirmation emailed to previous authors: Jim Schaad
2019-06-10
03 Jim Schaad Uploaded new revision
2019-03-25
02 Matthew Miller Added to session: IETF-104: cose  Tue-0900
2019-03-11
02 Jim Schaad New version available: draft-ietf-cose-rfc8152bis-algs-02.txt
2019-03-11
02 (System) New version approved
2019-03-11
02 (System) Request for posting confirmation emailed to previous authors: Jim Schaad
2019-03-11
02 Jim Schaad Uploaded new revision
2019-02-14
01 Jim Schaad New version available: draft-ietf-cose-rfc8152bis-algs-01.txt
2019-02-14
01 (System) New version approved
2019-02-14
01 (System) Request for posting confirmation emailed to previous authors: Jim Schaad
2019-02-14
01 Jim Schaad Uploaded new revision
2019-01-21
00 Matthew Miller This document now replaces draft-schaad-cose-rfc8152bis-algs instead of None
2019-01-21
00 Jim Schaad New version available: draft-ietf-cose-rfc8152bis-algs-00.txt
2019-01-21
00 (System) WG -00 approved
2019-01-21
00 Jim Schaad Set submitter to "Jim Schaad ", replaces to draft-schaad-cose-rfc8152bis-algs and sent approval email to group chairs: cose-chairs@ietf.org
2019-01-21
00 Jim Schaad Uploaded new revision