CBOR Object Signing and Encryption (COSE): Hash Algorithms
draft-ietf-cose-hash-algs-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2022-04-08
|
09 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-07-14
|
09 | (System) | RFC Editor state changed to AUTH48 |
2021-05-10
|
09 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2021-02-16
|
09 | (System) | RFC Editor state changed to REF from EDIT |
2021-02-12
|
09 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2021-02-11
|
09 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2021-02-11
|
09 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2021-02-02
|
09 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2021-02-02
|
09 | (System) | IANA Action state changed to In Progress from On Hold |
2021-02-01
|
09 | (System) | RFC Editor state changed to EDIT from MISSREF |
2020-09-16
|
09 | (System) | IANA Action state changed to On Hold from In Progress |
2020-09-14
|
09 | (System) | RFC Editor state changed to MISSREF |
2020-09-14
|
09 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-09-14
|
09 | (System) | Announcement was received by RFC Editor |
2020-09-14
|
09 | (System) | IANA Action state changed to In Progress |
2020-09-14
|
09 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2020-09-14
|
09 | Amy Vezza | IESG has approved the document |
2020-09-14
|
09 | Amy Vezza | Closed "Approve" ballot |
2020-09-14
|
09 | Amy Vezza | Ballot approval text was generated |
2020-09-14
|
09 | Murray Kucherawy | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2020-09-14
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-09-14
|
09 | Jim Schaad | New version available: draft-ietf-cose-hash-algs-09.txt |
2020-09-14
|
09 | (System) | New version approved |
2020-09-14
|
09 | (System) | Request for posting confirmation emailed to previous authors: Jim Schaad |
2020-09-14
|
09 | Jim Schaad | Uploaded new revision |
2020-08-11
|
08 | Murray Kucherawy | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup |
2020-07-29
|
08 | Jim Schaad | New version available: draft-ietf-cose-hash-algs-08.txt |
2020-07-29
|
08 | (System) | New version accepted (logged-in submitter: Jim Schaad) |
2020-07-29
|
08 | Jim Schaad | Uploaded new revision |
2020-07-29
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-07-29
|
07 | Jim Schaad | New version available: draft-ietf-cose-hash-algs-07.txt |
2020-07-29
|
07 | (System) | New version accepted (logged-in submitter: Jim Schaad) |
2020-07-29
|
07 | Jim Schaad | Uploaded new revision |
2020-07-11
|
06 | Murray Kucherawy | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup |
2020-07-10
|
06 | Benjamin Kaduk | [Ballot comment] Thanks for the past and pending updates to address my Discuss point. A few new comments on the -06: Section 2 attacks, … [Ballot comment] Thanks for the past and pending updates to address my Discuss point. A few new comments on the -06: Section 2 attacks, SHOULD NOT be used for a cryptographic purpose. The discovery of theoretical collision attacks against a given hash function SHOULD trigger a review of the continued suitability of the algorithm if alternatives are available and migration is viable. The It's not really clear who this SHOULD is binding upon. An example of a non-cryptographic use of a hash is for filtering from a collection of values to find a set of possible candidates, the candidates can then be check to see if they can successfully be used. This turned into a comma splice; I'd just make it use a semicolon (and independently do s/check/checked/) Section 3.1 this hash algorithm. Some of these situations are with historic HSMs where only SHA-1 is implemented, other situations are where the SHA-1 value is used for the purpose of filtering and thus the collision resistance property is not needed. nit: comma splice The COSE capabilities for these algorithms is an empty array. This went from "this algorithm" to "these algorithms" in the -05, but I missed why -- it's just the one SHA-1 algorithm, I thought. Section 3.2 * *SHA-256/64* provides a truncated hash. The length of the truncation is designed to allow for smaller transmission size. The trade-off is that the odds that a collision will occur increase proportionally. Use of this hash function needs analyze of the potential problems with having a collision occur, or must be limited to where the function of the hash is non-cryptographic. With the rest of the rewording, we have to go back to "analysis" from "analyze". (Sorry!) Section 3.3 The SHA-3 hash algorithms have a significantly different structure than the SHA-2 hash algorithms. One of the benefits of this difference is that when computing a shorter SHAKE hash value, the value is not a prefix of the result of computing the longer hash. (This last sentence is scheduled for removal.) |
2020-07-10
|
06 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2020-07-06
|
06 | Brian Weis | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Brian Weis. Sent review to list. |
2020-07-06
|
06 | Jim Schaad | New version available: draft-ietf-cose-hash-algs-06.txt |
2020-07-06
|
06 | (System) | New version accepted (logged-in submitter: Jim Schaad) |
2020-07-06
|
06 | Jim Schaad | Uploaded new revision |
2020-07-06
|
05 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-07-06
|
05 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-07-06
|
05 | Jim Schaad | New version available: draft-ietf-cose-hash-algs-05.txt |
2020-07-06
|
05 | (System) | New version accepted (logged-in submitter: Jim Schaad) |
2020-07-06
|
05 | Jim Schaad | Uploaded new revision |
2020-06-11
|
04 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2020-06-10
|
04 | Benjamin Kaduk | [Ballot discuss] In Section 3.3: The SHA-3 hash algorithms have a significantly different structure than the SHA-2 hash algorithms. One of the benefits … [Ballot discuss] In Section 3.3: The SHA-3 hash algorithms have a significantly different structure than the SHA-2 hash algorithms. One of the benefits of this differences is that when computing a shorter SHAKE hash value, the value is not a prefix of the result of computing the longer hash. I did not think this was the case -- the sponge construction seems to only use the 'd' parameter to truncate the output stream, but 'd' does not seem to otherwise cause the output stream to vary. Indeed, Section 4 of FIPS-202 concludes: % Note that the input d determines the number of bits that Algorithm 8 % returns, but it does not affect their values. Am I misunderstanding what the quoted statement is trying to convey? |
2020-06-10
|
04 | Benjamin Kaduk | [Ballot comment] Section 1 [CMS]. This omission was intentional as a structure consisting of just a digest identifier, the content, and a digest … [Ballot comment] Section 1 [CMS]. This omission was intentional as a structure consisting of just a digest identifier, the content, and a digest value does not by itself provide any strong security service. Additionally, an application is going to be better off defining this type of structure so that it can include any additional data that needs to be hashed, as well as methods of obtaining the data. (The "additionally" bits were also part of the original intentional omission's justification. I don't know that we need to make this clear specifically, though.) signature to be validated without first downloading all of the content associated with the signature. This capability can be of even greater importance in a constrained environment as not all of the content signed may be needed by the device. nit (I think this came up in Warren's comments, too?): we should clarify that this functionality is used when the content being signed is broken up into multiple chunks, each of which is represented as a hash value+hash algorithm -- for any individual signature output or hash value, the full plaintext must be processed, but the chunks that are not of interested do not need to be fetched+hashed -- only their contribution to the signature is processed. common. One of the primary things that has been identified by a hash function for secure message is a certificate. Two examples of this nit: the grammar doesn't look right; maybe "messages" plural? Section 2 signature or using the hash as part of the body to be signed. Other uses of hash functions do not require the same level of strength. This sounds like it's definitively saying that all other uses do not require this strength, which doesn't seem right. Maybe "may not require"? them. Applications should also make sure that the ability to change hash functions is part of the base design as cryptographic advances are sure to reduce the strength of a hash function. BCP 201 would be a great reference here :) A hash function is a map from one, normally large, bit string to a second, usually smaller, bit string. There are going to be collisions by a hash function. The trick is to make sure that it is difficult to find two values that are going to map to the same output side note: if I was writing this (but I'm not!), I'd say something like "because the output range has so many fewer possible configurations than the input domain, there will inherently be many collisions where different input strings produce the same output string". Section 2.1 * Additional data, this can be something as simple as a random value to make finding hash collisions slightly harder (as the value (Do we want to use the word "salt"?) handed to the application cannot have been selected to have a collision), or as complicated as a set of processing instructions I can't tell if this parenthetical is supposed to say "as long as the [salt] value handed to the application[...]" or "as the data handed to the application cannot have been selected to have a collision when combined with the unknown-at-the-time [salt] value". hashed be included. (Encoding as a CBOR array accomplished this requirement.) nit: s/accomplished/accomplishes/ COSE_Hash_V = ( 1 : int / tstr, # Algorithm identifier 2 : bstr, # Hash value 3 : tstr ?, # Location of object hashed 4 : any ? # object containing other details and things ) nit: the '?' goes before the optional element, not after. An alternative structure that could be used for situations where one is searching a group of objects for a match. In this case, the nit: sentence fragment. Section 3.1 Despite the above, there are still times where SHA-1 needs to be used and therefore it makes sense to assign a point for the use of this hash algorithm. Some of these situations are with historic HSMs nit: do you have a preference among "point", "code point", and "codepoint"? Because of the known issues for SHA-1 and the fact that is should no nit: s/is/it/ Section 3.2 * *SHA-256/64* provides a truncated hash. The length of the truncation is designed to allow for smaller transmission size. The trade-off is that the odds that a collision will occur increase proportionally. Locations that use this hash function Pedantically, "proportionally" would require some explanation (and possibly the word "exponentially". I don't insist on any changes here, though. need either to analysis the potential problems with having a nit: s/analysis/analyze/ collision occur, or where the only function of the hash is to narrow the possible choices. nit: the grammar of the "or where [...]" clause doesn't match up with the start of the sentence. The latter is the case for [I-D.ietf-cose-x509]. The hash value is used to select possible certificates and, if there are multiple choices then, each choice can be tested by using the public key. nit: maybe "multiple choices remaining"? Section 3.3 The family of SHA-3 hash algorithms [FIPS-202] was the result of a competition run by NIST. The pair of algorithms known as SHAKE-128 and SHAKE-256 are the instances of SHA-3 that are currently being standardized in the IETF. "But what about RFC 6931?" (Yes, I see RFC 8692 and RFC 8702 that only do the SHAKEs.) Unlike the SHA-2 hash functions, no algorithm identifier is created for shorter lengths. Applications can specify a minimum length for any hash function. A validator can infer the actual length from the hash value in these cases. In light of my disuss point, I think this claim needs some reconsiderations as well -- absent some other mechanism to detect modification (truncation), an attacker could truncate a longer output to a shorter one, undetected by the validator, since the one stream is a prefix of the other. |SHAKE128|TBD10|128-bit SHAKE| [] | [This | Yes | I'm not sure that we really want the description to just be "128-bit SHAKE" -- the 128 and 256 relate to the "capacity" of the sponge construction and are not tied to the output length. Also, I think we should consider having some "minimum output length" that has to be used in order to qualify for the "Recommended:Yes". Section 4.1 In addition, IANA is to add the value of 'Filter Only' to the set of legal values for the 'Recommended' column. This value is only to be used for hash functions and indicates that it is not to be used for purposes which require collision resistance. IANA is requested to add this document to the reference section for this table due to this addition. So the ordering is now "Yes, No, Filter Only, Deprecated"? Section 5 There are probably some considerations relating to the application's "additional data" used in a CBOR hash structure such as the (first) one in Section 2.1. Making sure that all the relevant attributes/parameters are bound into the computation/verification properly, etc. security all need to be included as part of this analysis. In many cases the value being hashed is a public value, as such pre-image resistance is not part of this analysis. nit: comma splice. Algorithm agility needs to be considered a requirement for any use of hash functions. As with any cryptographic function, hash functions (BCP 201 rears its head again) Section 6 It's not really going to work so great to have normative references to both RFC 8152 and the thing that obsoletes RFC 8152. Given the one place that we cite [COSE], moving it to informative seems reasonable. Section 7 RFC 3174, on the other hand, is needed to implement one of the hashes that we're allocating a codepoint for, so should probably be normative. (It's already on the downrefs registry, so that's not a concern.) Also, if we depend on the registry actions in 8152bis-algs, does that make it a normative dependency? (8152bis-struct will be taking care of any downref concerns already, I think, for what it's worth.) |
2020-06-10
|
04 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2020-06-10
|
04 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2020-06-10
|
04 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-06-10
|
04 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-06-10
|
04 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2020-06-09
|
04 | Erik Kline | [Ballot comment] [[ nits ]] [ section 2.1 ] * "suggested to it" -> "suggested that it" [ section 3.2 ] * "need either to … [Ballot comment] [[ nits ]] [ section 2.1 ] * "suggested to it" -> "suggested that it" [ section 3.2 ] * "need either to analysis" -> I couldn't come up with a good fix for this |
2020-06-09
|
04 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2020-06-09
|
04 | Robert Wilton | [Ballot comment] Hi, Thank you for this document, I found it easy to read and understand. A few minor comments: 1. Introduction Indirect signing … [Ballot comment] Hi, Thank you for this document, I found it easy to read and understand. A few minor comments: 1. Introduction Indirect signing of content is a paradigm where the content is not directly signed, but instead a hash of the content is computed and that hash value, along with the hash algorithm, is included in the content that will be signed. Doing indirect signing allows for a signature to be validated without first downloading all of the content associated with the signature. This capability can be of even greater importance in a constrained environment as not all of the content signed may be needed by the device. Would it be better to write "along with an identifier for the hash algorithm"? 1. Introduction The use of hashes to identify objects is something that has been very common. One of the primary things that has been identified by a hash function for secure message is a certificate. Two examples of this can be found in [ESS] and the newly defined COSE equivalents in [I-D.ietf-cose-x509]. Perhaps drop "newly defined"? 3.2. SHA-2 Hash Algorithms * *SHA-256* is probably the most common hash function used currently. SHA-256 is an efficient hash algorithm for 32-bit hardware. Is this intended to imply that SHA-256 is not an efficient hash algorithm when running on 64-bit hardware? If so, that might be worth explicitly stating, although it is implied by the description for SHA-512/256. 3.3. SHAKE Algorithms Would this be more clear to be titled as SHA-3 Algorithms? Thanks, Rob |
2020-06-09
|
04 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2020-06-08
|
04 | Roman Danyliw | [Ballot comment] Thanks for extending COSE for this additional use. ** I added my thoughts on the Section 2 language to the email thread of … [Ballot comment] Thanks for extending COSE for this additional use. ** I added my thoughts on the Section 2 language to the email thread of Barry’s ballot ** Per “To distinguish between these two cases, a new value in the recommended column of the COSE Algorithms registry is to be added. "Filter Only" indicates that the only purpose of a hash function should be to filter results and not those which require collision resistance”, I would recommend: NEW: To distinguish between these two cases, a new value in the recommended column of the COSE Algorithms registry is to be added. "Filter Only" indicates that the only purpose of a hash function should be to filter results and it is not intended for applications which require a cryptographically strong algorithm is needed. It doesn’t change the intent, but it does generalize to all the security properties we might want of a hash algorithm. ** Section 5. Since collision and second-preimage attacks are mentioned, for completeness it would be worth mentioning the need for preimage resistance for cryptographic usage too. ** Editorial nits: -- Abstract. Editorial. The abstract has an explicit reference, [I-D.ietf-cose-rfc8152bis-struct], which abstracts are not permitted to have. -- Section 2.1. Editorial. s/this could /This could/ -- Section 3.1. Editorial. s/assign a point/assign a code point/ -- Section 3.2. Editorial. OLD Locations that use this hash function need either to analysis the potential problems with having a collision occur, or where the only function of the hash is to narrow the possible choices. NEW Applications that use this hash function need either to analyze the potential impact with having a collision occur, or use it only where the function of the hash is to narrow the possible choices. -- Section 3.3. Per “The pair of algorithms known as SHAKE-128 and SHAKE-256 are the instances of SHA-3 that are currently being standardized in the IETF”, it isn’t clear this sentence will age well. -- Section 4. Typo. s/preseved/preserved/ |
2020-06-08
|
04 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2020-06-05
|
04 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-06-01
|
04 | Barry Leiba | [Ballot comment] — Abstract — There are however circumstances where hash algorithms are used, such as indirect signatures where the hash of … [Ballot comment] — Abstract — There are however circumstances where hash algorithms are used, such as indirect signatures where the hash of one or more contents are signed, and X.509 certificate or other object identification by the use of a fingerprint. I found this hard to parse, and had to read it a few times. How about this?: NEW There are, however, circumstances where hash algorithms are used, such as in indirect signatures, where the hash of some content is signed, and for fingerprinting of X.509 certificates or other objects. END — Introduction — This omission was intentional as a structure consisting of just a digest identifier, the content, and a digest value does not by itself provide any strong security service. Nit: this needs a few more commas... one after “intentional”, and one before and one after “by itself”. One of the primary things that has been identified by a hash function for secure message is a certificate. Another that I had trouble parsing. Maybe, “One of the primary things related to secure messages that has been identified by a hash function is a certificate.” — Section 2 — hash functions is part of the base design as cryptographic advances are sure to reduce the strength of a hash function. Nit: this needs a comma after “design”. The standard "Collision Attack" is one where an attacker can find two different messages that have the same hash value. If a collision attack exists, then the function SHOULD NOT be used for a cryptographic purpose. I’m uncomfortable with having this document give a brief tutorial on cryptographic hashing, as it has to be oversimplified... and it is. If it’s going to stay, I’d like to see ar least one minor change, though I’ll defer to the Sec ADs on this point: for any hash alg, it is always possible to encounter a collision, and the text isn’t clear about what “if a collision attack exists” really means. I think it means not to use it if a collision attack is practical, and maybe this is a better way to say it?: NEW A "collision attack" is one where an attacker can find two different messages that have the same hash value. A hash function that is susceptible to collision attacks, SHOULD NOT be used for cryptographic purposes. END checked to see if they are the correct one. “They are the correct one?” Oof. How about, “to find the correct one,” or (maybe better), “to see if they are suitable.”? If the fingerprint is used to verify that it is the correct certificate, then that usage is subject to a collision attack as above. If however, the fingerprint is used to sort through a collection of certificates “then that usage is a cryptographic one and is subject to the warning above about collision attacks.” And “however” also needs a comma before it, as well as after. In this case, one still needs to validate that the public key validates the signature Make the first “validate” say “confirm” instead, to avoid the awkward double use of “validate”. To distinguish between these two cases, a new value in the recommended column of the COSE Algorithms registry is to be added. "Filter Only" indicates that the only purpose of a hash function should be to filter results and not those which require collision resistance. Might it be better to have the new column be called “cryptographic use”, with values of “yes” and “no”? Hint: I think it would. Hint#2: this is a non-blocking comment, so you might disagree. — Section 2.1 — * Additional data, this can be something as simple as a random value Nit: make the comma a semicolon. appending to the content, but it is strongly suggested to it Nit: change “to it” to “that it”. — Section 3.1 — Because of the known issues for SHA-1 and the fact that is should no Nit: change “that is” to “that it”. — Section 3.2 — Locations that use this hash function need either to analysis the potential problems with having a collision occur, or where the only function of the hash is to narrow the possible choices. Locations? And do you mean to use “analysis” as a verb? Maybe this?: NEW Use of this hash function needs analysis of the potential problems with having a collision occur, or must be limited to where the function of the hash is non-cryptographic. END — Section 3.3 — One of the benefits of this differences is that when computing a shorter SHAKE hash value Nit: “difference”, singular. — Section 5 — that need the cryptographic properties, i.e. collision resistance, and properties that correspond to possible object identification. Collision resistance isn’t the only cryptographic property (there’s also, for example, preimage resistance), so change “i.e.” to “such as”. This is another example of the hazard of trying to explain hashing in a simple document such as this one. This is the difference between collision resistance and second pre-image resistance. If you have collision resistance, don’t you automatically have second preimage resistance? What’s he point of mentioning second preimage resistance here, when you don’t mention it nor need it anywhere else? are under constant attack and the strength of hash algorithms will be reduced over time. I would say “the cryptographic strength”. |
2020-06-01
|
04 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2020-06-01
|
04 | Warren Kumari | [Ballot comment] Thank you for writing this - it was an interesting read. I do have one issue, which I cannot tell if it is … [Ballot comment] Thank you for writing this - it was an interesting read. I do have one issue, which I cannot tell if it is simply me being dumb, or if the text needs more work. “ Doing indirect signing allows for a signature to be validated without first downloading all of the content associated with the signature. This capability can be of even greater importance in a constrained environment as not all of the content signed may be needed by the device.” I’m unclear how this works — itseems clear enough that I can verify that the signature matches the hash, but doesn’t the device need to still download and compute the hash over all of the content? Otherwise I could take a hash and signature from content A, and claim that it is for content B. Sure, if the signature **doens’t** match the hash I know not to bother downloading the content at all, but if the sig does match the hash I still need to download the content to check that the hash is for this content.... Please help educate me! Nit: “ A pointer to the value that was hashed. this could” — s/this/This/ |
2020-06-01
|
04 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2020-05-29
|
04 | Amy Vezza | Placed on agenda for telechat - 2020-06-11 |
2020-05-29
|
04 | Murray Kucherawy | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2020-05-29
|
04 | Murray Kucherawy | Ballot has been issued |
2020-05-29
|
04 | Murray Kucherawy | [Ballot Position Update] New position, Yes, has been recorded for Murray Kucherawy |
2020-05-29
|
04 | Murray Kucherawy | Created "Approve" ballot |
2020-05-29
|
04 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2020-05-29
|
04 | Jim Schaad | New version available: draft-ietf-cose-hash-algs-04.txt |
2020-05-29
|
04 | (System) | New version accepted (logged-in submitter: Jim Schaad) |
2020-05-29
|
04 | Jim Schaad | Uploaded new revision |
2020-05-28
|
03 | Jouni Korhonen | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Jouni Korhonen. Sent review to list. |
2020-05-26
|
03 | Murray Kucherawy | IESG state changed to Waiting for AD Go-Ahead::AD Followup from Waiting for AD Go-Ahead |
2020-05-26
|
03 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2020-05-22
|
03 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2020-05-22
|
03 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-cose-hash-algs-03. 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-hash-algs-03. 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 is a single action which we must complete. In the COSE Algorithms registry on the CBOR Object Signing and Encryption (COSE) registry page located at: https://www.iana.org/assignments/cose/ the following eight, new registrations are to be added to the registry: +-----------+-------------------------+-------------+--------------+-------------+-------------+ |Name |Value | Description | Capabilities | Reference | Recommended | +===========+=========================+=============+==============+=============+=============+ |SHA-1 | [ TBD-at-Registration ] | SHA-1 Hash | [] |[ RFC-to-be ]| Filter Only | | | | | | | | +-----------+-------------------------+-------------+--------------+-------------+-------------+ |SHA-256/64 |[ TBD-at-Registration ] | SHA-2 | [] |[ RFC-to-be ]| Filter Only | | | | 256-bit | | | | | | | Hash | | | | | | | truncated | | | | | | |to 64-bits | | | | +-----------+-------------------------+-------------+--------------+-------------+-------------+ | SHA-256 |[ TBD-at-Registration ] | SHA-2 | [] |[ RFC-to-be ]| Yes | | | | 256-bit | | | | | | | Hash | | | | +-----------+-------------------------+-------------+--------------+-------------+-------------+ | SHA-384 |[ TBD-at-Registration ] | SHA-2 | [] |[ RFC-to-be ]| Yes | | | | 384-bit | | | | | | | Hash | | | | +-----------+-------------------------+-------------+--------------+-------------+-------------+ | SHA-512 |[ TBD-at-Registration ] | SHA-2 | [] |[ RFC-to-be ]| Yes | | | | 512-bit | | | | | | | Hash | | | | +-----------+-------------------------+-------------+--------------+-------------+-------------+ |SHA-512/256|[ TBD-at-Registration ] | SHA-2 | [] |[ RFC-to-be ]| Yes | | | | 512-bit | | | | | | | Hash | | | | | | | truncated | | | | | | |to 256-bits | | | | +-----------+-------------------------+-------------+--------------+-------------+-------------+ |SHAKE128 |[ TBD-at-Registration ] |128-bit SHAKE| [] |[ RFC-to-be ]| Yes | | | | | | | | +-----------+-------------------------+-------------+--------------+-------------+-------------+ |SHAKE256 |[ TBD-at-Registration ] |256-bit SHAKE| [] |[ RFC-to-be ]| Yes | | | | | | | | +-----------+-------------------------+-------------+--------------+-------------+-------------+ IANA Question --> In section 4.1 of the current document, the author suggests that: "Many of the hash values produced are relatively long and as such the use of a two-byte algorithm identifier seems reasonable. SHA-1 is tagged as deprecated and thus a longer algorithm identifier is appropriate even though it is a shorter hash value." Which of the seven ranges in the COSE Algorithms registry should these eight new registrations be assigned to? The IANA Functions Operator understands that this is the only action 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-19
|
03 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jouni Korhonen |
2020-05-19
|
03 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jouni Korhonen |
2020-05-16
|
03 | Gyan Mishra | Request for Last Call review by GENART Completed: Ready. Reviewer: Gyan Mishra. Sent review to list. |
2020-05-14
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Gyan Mishra |
2020-05-14
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Gyan Mishra |
2020-05-14
|
03 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Brian Weis |
2020-05-14
|
03 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Brian Weis |
2020-05-12
|
03 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2020-05-12
|
03 | Amy Vezza | The following Last Call announcement was sent out (ends 2020-05-26): From: The IESG To: IETF-Announce CC: Ivaylo Petrov , superuser@gmail.com, ivaylo@ackl.io, draft-ietf-cose-hash-algs@ietf.org, … The following Last Call announcement was sent out (ends 2020-05-26): From: The IESG To: IETF-Announce CC: Ivaylo Petrov , superuser@gmail.com, ivaylo@ackl.io, draft-ietf-cose-hash-algs@ietf.org, cose-chairs@ietf.org, cose@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (CBOR Object Signing and Encryption (COSE): Hash 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): Hash 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-26. 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 The CBOR Object Signing and Encryption (COSE) syntax [I-D.ietf-cose-rfc8152bis-struct] does not define any direct methods for using hash algorithms. There are however circumstances where hash algorithms are used: Indirect signatures where the hash of one or more contents are signed. X.509 certificate or other object identification by the use of a fingerprint. This document defines a set of hash algorithms that are identified by COSE Algorithm Identifiers. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/ No IPR declarations have been submitted directly on this I-D. |
2020-05-12
|
03 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2020-05-12
|
03 | Amy Vezza | Last call announcement was changed |
2020-05-11
|
03 | Murray Kucherawy | Changed consensus to Yes from Unknown |
2020-05-11
|
03 | Murray Kucherawy | Ballot writeup was changed |
2020-05-11
|
03 | Murray Kucherawy | Last call was requested |
2020-05-11
|
03 | Murray Kucherawy | Ballot approval text was generated |
2020-05-11
|
03 | Murray Kucherawy | Ballot writeup was generated |
2020-05-11
|
03 | Murray Kucherawy | IESG state changed to Last Call Requested from AD Evaluation |
2020-05-11
|
03 | Murray Kucherawy | Last call announcement was changed |
2020-05-11
|
03 | Murray Kucherawy | IESG state changed to AD Evaluation from Publication Requested |
2020-05-11
|
03 | Murray Kucherawy | Shepherding AD changed to Murray Kucherawy |
2020-04-17
|
03 | Ivaylo Petrov | Answers to the questions: > (1) What type of RFC is being requested (BCP, Proposed Standard, Internet > Standard, Informational, Experimental, or Historic)? Why is … Answers to the questions: > (1) What type of RFC is being requested (BCP, Proposed Standard, Internet > Standard, Informational, Experimental, or Historic)? Why is this the proper > type of RFC? Is this type of RFC indicated in the title page header? I believe this document should be an Informational RFC as indicated in the title page. > (2) The IESG approval announcement includes a Document Announcement Write-Up. > Please provide such a Document Announcement Write-Up. Recent examples can be > found in the "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary: > > Relevant content can frequently be found in the abstract and/or introduction > of the document. If not, this may be an indication that there are > deficiencies in the abstract or introduction. This document defines a set of hash algorithms that are identified by COSE Algorithm Identifiers. It also provides two examples of structures for holding a hash value. > Working Group Summary: > > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or were > there decisions where the consensus was particularly rough? The document has had clear working group consensus for publication and it has been reviewed by a few working group participants since its adoption. > Document Quality: > > Are there existing implementations of the protocol? Have a significant number > of vendors indicated their plan to implement the specification? Are there any > reviewers that merit special mention as having done a thorough review, e.g., > one that resulted in important changes or a conclusion that the document had > no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or > other expert review, what was its course (briefly)? In the case of a Media > Type review, on what date was the request posted? John Mattsson has reviewed an early version of the document. Kathleen Moriarty did a review of a pre-working group last call version of the document. Ludwig Seitz and Ivaylo Petrov did a review on the working group last call version of the document. All the review issues have been addressed and no review comments or issues are currently pending. > Personnel: > > Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd: Ivaylo Petrov (COSE WG chair) AD: Benjamin Kaduk (Sec AD) > (3) Briefly describe the review of this document that was performed by the > Document Shepherd. If this version of the document is not ready for > publication, please explain why the document is being forwarded to the IESG. I completed a detailed review of the document. All of my remarks were processed and there are no remaining open issues. > (4) Does the document Shepherd have any concerns about the depth or breadth > of the reviews that have been performed? No, given the number of reviews and the relative shortness of the document, I believe it has had sufficient reviews. > (5) Do portions of the document need review from a particular or from broader > perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or > internationalization? If so, describe the review that took place. No. > (6) Describe any specific concerns or issues that the Document Shepherd has > with this document that the Responsible Area Director and/or the IESG should > be aware of? For example, perhaps he or she is uncomfortable with certain > parts of the document, or has concerns whether there really is a need for it. > In any event, if the WG has discussed those issues and has indicated that it > still wishes to advance the document, detail those concerns here. No concerns or issues. > (7) Has each author confirmed that any and all appropriate IPR disclosures > required for full conformance with the provisions of BCP 78 and BCP 79 have > already been filed. If not, explain why? Yes, the authors have confirmed that they are not aware of any IPR. > (8) Has an IPR disclosure been filed that references this document? If so, > summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR. > (9) How solid is the WG consensus behind this document? Does it represent the > strong concurrence of a few individuals, with others being silent, or does > the WG as a whole understand and agree with it? From my perspective the WG understands and agrees with the proposed draft without any other alternatives being provided. > (10) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in separate email > messages to the Responsible Area Director. (It should be in a separate email > because this questionnaire is publicly available.) No. > (11) Identify any ID nits the Document Shepherd has found in this document. > (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). > Boilerplate checks are not enough; this check needs to be thorough. From reading the document, there is section "Contributing to this document" that would need to be removed as indicated in the text. As this section is meant to be remove by the RFC editor, I believe they should not block the document from progressing. ID nits points out that - there is a reference to a document in the abstract, which should be replaced with textual description - two of the internet drafts that this document references have undergone a new revision I believe those issues will only require minor editorial changes, which does not seem as a sufficient reason to delay the progress of the document. > (12) Describe how the document meets any required formal review criteria, > such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. I am not aware of any formal review criteria that apply to this document. The hash algorithms for which it defines COSE Algorithm Identifiers have passed formal review. > (13) Have all references within this document been identified as either > normative or informative? Yes. > (14) Are there normative references to documents that are not ready for > advancement or are otherwise in an unclear state? If such normative > references exist, what is the plan for their completion? Only draft-ietf-cose-rfc8152bis-struct is a work in progress. It is past WGLC which made this feel acceptable. > (15) Are there downward normative references references (see RFC 3967)? If > so, list these downward references to support the Area Director in the Last > Call procedure. There are no downward normative references. > (16) Will publication of this document change the status of any existing > RFCs? Are those RFCs listed on the title page header, listed in the > abstract, and discussed in the introduction? If the RFCs are not listed in > the Abstract and Introduction, explain why, and point to the part of the > document where the relationship of this document to the other RFCs is > discussed. If this information is not in the document, explain why the WG > considers it unnecessary. No. > (17) Describe the Document Shepherd's review of the IANA considerations > section, especially with regard to its consistency with the body of the > document. Confirm that all protocol extensions that the document makes are > associated with the appropriate reservations in IANA registries. Confirm that > any referenced IANA registries have been clearly identified. Confirm that > newly created IANA registries include a detailed specification of the initial > contents for the registry, that allocations procedures for future > registrations are defined, and a reasonable name for the new registry has > been suggested (see RFC 8126). The document adds a number of values to COSE Algorithms Registry. For those all the necessary information is provided. > (18) List any new IANA registries that require Expert Review for future > allocations. Provide any public guidance that the IESG would find useful in > selecting the IANA Experts for these new registries. No new IANA registries. > (19) Describe reviews and automated checks performed by the Document Shepherd > to validate sections of the document written in a formal language, such as > XML code, BNF rules, MIB definitions, YANG modules, etc. There are only two instances of code snippets that are given as examples. There is no definition of the formal format that they follow and they are left for interpretation to the reader. The snippets seem compatible with CDDL as specified by RFC8610 and follow the same format as the snippets in RFC 8152. I believe a minor editorial change might be needed to explicitly state that, but this change does not need to delay the progress of this document. > (20) If the document contains a YANG module, has the module been checked with > any of the recommended validation tools > (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and > formatting validation? If there are any resulting errors or warnings, what is > the justification for not fixing them at this time? Does the YANG module > comply with the Network Management Datastore Architecture (NMDA) as specified > in RFC8342? No YANG modules are defined by this document. |
2020-04-17
|
03 | Ivaylo Petrov | Responsible AD changed to Benjamin Kaduk |
2020-04-17
|
03 | Ivaylo Petrov | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2020-04-17
|
03 | Ivaylo Petrov | IESG state changed to Publication Requested from I-D Exists |
2020-04-17
|
03 | Ivaylo Petrov | IESG process started in state Publication Requested |
2020-04-17
|
03 | Ivaylo Petrov | Intended Status changed to Informational from None |
2020-04-14
|
03 | Ivaylo Petrov | Answers to the questions: > (1) What type of RFC is being requested (BCP, Proposed Standard, Internet > Standard, Informational, Experimental, or Historic)? Why is … Answers to the questions: > (1) What type of RFC is being requested (BCP, Proposed Standard, Internet > Standard, Informational, Experimental, or Historic)? Why is this the proper > type of RFC? Is this type of RFC indicated in the title page header? I believe this document should be an Informational RFC as indicated in the title page. > (2) The IESG approval announcement includes a Document Announcement Write-Up. > Please provide such a Document Announcement Write-Up. Recent examples can be > found in the "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary: > > Relevant content can frequently be found in the abstract and/or introduction > of the document. If not, this may be an indication that there are > deficiencies in the abstract or introduction. This document defines a set of hash algorithms that are identified by COSE Algorithm Identifiers. It also provides two examples of structures for holding a hash value. > Working Group Summary: > > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or were > there decisions where the consensus was particularly rough? The document has had clear working group consensus for publication and it has been reviewed by a few working group participants since its adoption. > Document Quality: > > Are there existing implementations of the protocol? Have a significant number > of vendors indicated their plan to implement the specification? Are there any > reviewers that merit special mention as having done a thorough review, e.g., > one that resulted in important changes or a conclusion that the document had > no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or > other expert review, what was its course (briefly)? In the case of a Media > Type review, on what date was the request posted? John Mattsson has reviewed an early version of the document. Kathleen Moriarty did a review of a pre-working group last call version of the document. Ludwig Seitz and Ivaylo Petrov did a review on the working group last call version of the document. All the review issues have been addressed and no review comments or issues are currently pending. > Personnel: > > Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd: Ivaylo Petrov (COSE WG chair) AD: Benjamin Kaduk (Sec AD) > (3) Briefly describe the review of this document that was performed by the > Document Shepherd. If this version of the document is not ready for > publication, please explain why the document is being forwarded to the IESG. I completed a detailed review of the document. All of my remarks were processed and there are no remaining open issues. > (4) Does the document Shepherd have any concerns about the depth or breadth > of the reviews that have been performed? No, given the number of reviews and the relative shortness of the document, I believe it has had sufficient reviews. > (5) Do portions of the document need review from a particular or from broader > perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or > internationalization? If so, describe the review that took place. No. > (6) Describe any specific concerns or issues that the Document Shepherd has > with this document that the Responsible Area Director and/or the IESG should > be aware of? For example, perhaps he or she is uncomfortable with certain > parts of the document, or has concerns whether there really is a need for it. > In any event, if the WG has discussed those issues and has indicated that it > still wishes to advance the document, detail those concerns here. No concerns or issues. > (7) Has each author confirmed that any and all appropriate IPR disclosures > required for full conformance with the provisions of BCP 78 and BCP 79 have > already been filed. If not, explain why? Yes, the authors have confirmed that they are not aware of any IPR. > (8) Has an IPR disclosure been filed that references this document? If so, > summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR. > (9) How solid is the WG consensus behind this document? Does it represent the > strong concurrence of a few individuals, with others being silent, or does > the WG as a whole understand and agree with it? From my perspective the WG understands and agrees with the proposed draft without any other alternatives being provided. > (10) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in separate email > messages to the Responsible Area Director. (It should be in a separate email > because this questionnaire is publicly available.) No. > (11) Identify any ID nits the Document Shepherd has found in this document. > (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). > Boilerplate checks are not enough; this check needs to be thorough. From reading the document, there is section "Contributing to this document" that would need to be removed as indicated in the text. As this section is meant to be remove by the RFC editor, I believe they should not block the document from progressing. ID nits points out that - there is a reference to a document in the abstract, which should be replaced with textual description - two of the internet drafts that this document references have undergone a new revision I believe those issues will only require minor editorial changes, which does not seem as a sufficient reason to delay the progress of the document. > (12) Describe how the document meets any required formal review criteria, > such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. I am not aware of any formal review criteria that apply to this document. The hash algorithms for which it defines COSE Algorithm Identifiers have passed formal review. > (13) Have all references within this document been identified as either > normative or informative? Yes. > (14) Are there normative references to documents that are not ready for > advancement or are otherwise in an unclear state? If such normative > references exist, what is the plan for their completion? Only draft-ietf-cose-rfc8152bis-struct is a work in progress. It is past WGLC which made this feel acceptable. > (15) Are there downward normative references references (see RFC 3967)? If > so, list these downward references to support the Area Director in the Last > Call procedure. There are no downward normative references. > (16) Will publication of this document change the status of any existing > RFCs? Are those RFCs listed on the title page header, listed in the > abstract, and discussed in the introduction? If the RFCs are not listed in > the Abstract and Introduction, explain why, and point to the part of the > document where the relationship of this document to the other RFCs is > discussed. If this information is not in the document, explain why the WG > considers it unnecessary. No. > (17) Describe the Document Shepherd's review of the IANA considerations > section, especially with regard to its consistency with the body of the > document. Confirm that all protocol extensions that the document makes are > associated with the appropriate reservations in IANA registries. Confirm that > any referenced IANA registries have been clearly identified. Confirm that > newly created IANA registries include a detailed specification of the initial > contents for the registry, that allocations procedures for future > registrations are defined, and a reasonable name for the new registry has > been suggested (see RFC 8126). The document adds a number of values to COSE Algorithms Registry. For those all the necessary information is provided. > (18) List any new IANA registries that require Expert Review for future > allocations. Provide any public guidance that the IESG would find useful in > selecting the IANA Experts for these new registries. No new IANA registries. > (19) Describe reviews and automated checks performed by the Document Shepherd > to validate sections of the document written in a formal language, such as > XML code, BNF rules, MIB definitions, YANG modules, etc. There are only two instances of code snippets that are given as examples. There is no definition of the formal format that they follow and they are left for interpretation to the reader. The snippets seem compatible with CDDL as specified by RFC8610 and follow the same format as the snippets in RFC 8152. I believe a minor editorial change might be needed to explicitly state that, but this change does not need to delay the progress of this document. > (20) If the document contains a YANG module, has the module been checked with > any of the recommended validation tools > (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and > formatting validation? If there are any resulting errors or warnings, what is > the justification for not fixing them at this time? Does the YANG module > comply with the Network Management Datastore Architecture (NMDA) as specified > in RFC8342? No YANG modules are defined by this document. |
2020-03-09
|
03 | Jim Schaad | New version available: draft-ietf-cose-hash-algs-03.txt |
2020-03-09
|
03 | (System) | New version accepted (logged-in submitter: Jim Schaad) |
2020-03-09
|
03 | Jim Schaad | Uploaded new revision |
2020-02-18
|
02 | Ivaylo Petrov | Answers to the questions: > (1) What type of RFC is being requested (BCP, Proposed Standard, Internet > Standard, Informational, Experimental, or Historic)? Why is … Answers to the questions: > (1) What type of RFC is being requested (BCP, Proposed Standard, Internet > Standard, Informational, Experimental, or Historic)? Why is this the proper > type of RFC? Is this type of RFC indicated in the title page header? I believe this document should be an Informational RFC as indicated in the title page. > (2) The IESG approval announcement includes a Document Announcement Write-Up. > Please provide such a Document Announcement Write-Up. Recent examples can be > found in the "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary: > > Relevant content can frequently be found in the abstract and/or introduction > of the document. If not, this may be an indication that there are > deficiencies in the abstract or introduction. This document defines a set of hash algorithms that are identified by COSE Algorithm Identifiers. It also provides two examples of structures for holding a hash value. > Working Group Summary: > > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or were > there decisions where the consensus was particularly rough? The document has had clear working group consensus for publication and it has been reviewed by a few working group participants since its adoption. > Document Quality: > > Are there existing implementations of the protocol? Have a significant number > of vendors indicated their plan to implement the specification? Are there any > reviewers that merit special mention as having done a thorough review, e.g., > one that resulted in important changes or a conclusion that the document had > no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or > other expert review, what was its course (briefly)? In the case of a Media > Type review, on what date was the request posted? John Mattsson has reviewed an early version of the document. Kathleen Moriarty did a review of a pre-working group last call version of the document. Ludwig Seitz and Ivaylo Petrov did a review on the working group last call version of the document. All the review issues have been addressed and no review comments or issues are currently pending. > Personnel: > > Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd: Ivaylo Petrov (COSE WG chair) AD: Benjamin Kaduk (Sec AD) > (3) Briefly describe the review of this document that was performed by the > Document Shepherd. If this version of the document is not ready for > publication, please explain why the document is being forwarded to the IESG. I completed a detailed review of the document. All of my remarks were processed and there are no remaining open issues. > (4) Does the document Shepherd have any concerns about the depth or breadth > of the reviews that have been performed? No, given the number of reviews and the relative shortness of the document, I believe it has had sufficient reviews. > (5) Do portions of the document need review from a particular or from broader > perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or > internationalization? If so, describe the review that took place. No. > (6) Describe any specific concerns or issues that the Document Shepherd has > with this document that the Responsible Area Director and/or the IESG should > be aware of? For example, perhaps he or she is uncomfortable with certain > parts of the document, or has concerns whether there really is a need for it. > In any event, if the WG has discussed those issues and has indicated that it > still wishes to advance the document, detail those concerns here. No concerns or issues. > (7) Has each author confirmed that any and all appropriate IPR disclosures > required for full conformance with the provisions of BCP 78 and BCP 79 have > already been filed. If not, explain why? Yes, the authors have confirmed that they are not aware of any IPR. > (8) Has an IPR disclosure been filed that references this document? If so, > summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR. > (9) How solid is the WG consensus behind this document? Does it represent the > strong concurrence of a few individuals, with others being silent, or does > the WG as a whole understand and agree with it? From my perspective the WG understands and agrees with the proposed draft without any other alternatives being provided. > (10) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in separate email > messages to the Responsible Area Director. (It should be in a separate email > because this questionnaire is publicly available.) No. > (11) Identify any ID nits the Document Shepherd has found in this document. > (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). > Boilerplate checks are not enough; this check needs to be thorough. From reading the document, there are section "Contributing to this document" and "Open Issues" that would need to be removed as indicated in the text. As those sections are meant for the RFC editor, I believe they should not block the document from progressing. ID nits points out that - there is one line that is too long due to improper formatting of a code snippet - there is a reference to a document in the abstract, which should be replaced with textual description - two of the internet drafts that this document references have undergone a new revision I believe those issues will only require minor editorial changes, which does not seem as a sufficient reason to delay the progress of the document. > (12) Describe how the document meets any required formal review criteria, > such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. I am not aware of any formal review criteria that apply to this document. The hash algorithms for which it defines COSE Algorithm Identifiers have passed formal review. > (13) Have all references within this document been identified as either > normative or informative? Yes. > (14) Are there normative references to documents that are not ready for > advancement or are otherwise in an unclear state? If such normative > references exist, what is the plan for their completion? Only draft-ietf-cose-rfc8152bis-struct is a work in progress. It is past WGLC which made this feel acceptable. > (15) Are there downward normative references references (see RFC 3967)? If > so, list these downward references to support the Area Director in the Last > Call procedure. There are no downward normative references. > (16) Will publication of this document change the status of any existing > RFCs? Are those RFCs listed on the title page header, listed in the > abstract, and discussed in the introduction? If the RFCs are not listed in > the Abstract and Introduction, explain why, and point to the part of the > document where the relationship of this document to the other RFCs is > discussed. If this information is not in the document, explain why the WG > considers it unnecessary. No. > (17) Describe the Document Shepherd's review of the IANA considerations > section, especially with regard to its consistency with the body of the > document. Confirm that all protocol extensions that the document makes are > associated with the appropriate reservations in IANA registries. Confirm that > any referenced IANA registries have been clearly identified. Confirm that > newly created IANA registries include a detailed specification of the initial > contents for the registry, that allocations procedures for future > registrations are defined, and a reasonable name for the new registry has > been suggested (see RFC 8126). The document adds a number of values to COSE Algorithms Registry. For those all the necessary information is provided. > (18) List any new IANA registries that require Expert Review for future > allocations. Provide any public guidance that the IESG would find useful in > selecting the IANA Experts for these new registries. No new IANA registries. > (19) Describe reviews and automated checks performed by the Document Shepherd > to validate sections of the document written in a formal language, such as > XML code, BNF rules, MIB definitions, YANG modules, etc. There are only two instances of code snippets that are given as examples. There is no definition of the formal format that they follow and they are left for interpretation to the reader. The snippets seem compatible with CDDL as specified by RFC8610 and follow the same format as the snippets in RFC 8152. I believe a minor editorial change might be needed to explicitly state that, but this change does not need to delay the progress of this document. > (20) If the document contains a YANG module, has the module been checked with > any of the recommended validation tools > (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and > formatting validation? If there are any resulting errors or warnings, what is > the justification for not fixing them at this time? Does the YANG module > comply with the Network Management Datastore Architecture (NMDA) as specified > in RFC8342? No YANG modules are defined by this document. |
2020-01-28
|
02 | Ivaylo Petrov | Tag Doc Shepherd Follow-up Underway set. |
2019-11-21
|
02 | Ivaylo Petrov | Notification list changed to Ivaylo Petrov <ivaylo@ackl.io> |
2019-11-21
|
02 | Ivaylo Petrov | Document shepherd changed to Ivaylo Petrov |
2019-11-21
|
02 | Ivaylo Petrov | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2019-11-04
|
02 | Jim Schaad | New version available: draft-ietf-cose-hash-algs-02.txt |
2019-11-04
|
02 | (System) | New version accepted (logged-in submitter: Jim Schaad) |
2019-11-04
|
02 | Jim Schaad | Uploaded new revision |
2019-09-19
|
01 | Ivaylo Petrov | IETF WG state changed to In WG Last Call from WG Document |
2019-06-10
|
01 | Jim Schaad | New version available: draft-ietf-cose-hash-algs-01.txt |
2019-06-10
|
01 | (System) | New version approved |
2019-06-10
|
01 | (System) | Request for posting confirmation emailed to previous authors: Jim Schaad |
2019-06-10
|
01 | Jim Schaad | Uploaded new revision |
2019-03-25
|
00 | Matthew Miller | Added to session: IETF-104: cose Tue-0900 |
2019-03-11
|
00 | Matthew Miller | This document now replaces draft-schaad-cose-hash-algs instead of None |
2019-03-11
|
00 | Jim Schaad | New version available: draft-ietf-cose-hash-algs-00.txt |
2019-03-11
|
00 | (System) | WG -00 approved |
2019-03-11
|
00 | Jim Schaad | Set submitter to "Jim Schaad ", replaces to draft-schaad-cose-hash-algs and sent approval email to group chairs: cose-chairs@ietf.org |
2019-03-11
|
00 | Jim Schaad | Uploaded new revision |