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 |