-----Original Message----- From: Alvaro Retana via Datatracker <[email protected]> Sent: Tuesday, June 9, 2020 12:08 PM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; Matthew Miller <[email protected]> Subject: Alvaro Retana's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT)
Alvaro Retana has entered the following ballot position for draft-ietf-cose-rfc8152bis-algs-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-rfc8152bis-algs/ ---------------------------------------------------------------------- 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. [JLS] This was an error in the file and has been fixed. (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. [JLS] This comes from a number of different sources: * Pure personal opinion, I do not believe that one should be creating proposed standards if there is absolutely no intention to try and keep the document on track to some day make it a full standard. This is something that I generally do with my own documents and do not ever attempt to push it on others. * Historically when deal with the CMS algorithm documents, these have normally been information rather than standard track documents. While there is a difference between the algorithms which describe how to implement the algorithm and how to use the algorithm with the first always being informational and the second frequently being informational, this is a trend that I have normally tried to follow. * I have an expectation that over time cryptographic algorithms will be broken. My personal hope is that all standards track documents do not live in the world of this might become obsolete. I would note that we have not do any type of pass over documents such as RFC 3058 or RFC 3657 which at this time would no longer be considered to be state of the art and thus not be used but have never been marked as obsolete or some similar tagging. [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. [JLS] Done (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. [JLS] There is a race condition that is going on at the moment and this is weasel language to make sure that I can solve any problems that crop up. There are algorithms drafts such as the WebAuthn algorithm document and another one that I know of that is coming out of the lwig WG and one that was in the RFC Editor queue which as sense been cleaned up that did not define this field and would need to get it defined somehow. (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. [JLS] Originally I did all of the updates from RFC8152 to one of these two documents over in the struct document. I later broke that up and did not catch this point. That is deleted and the update from RFC 8152 to [[This Document]] is added. (5) I assume that this document (and not -struct) should also update the COSE Elliptic Curves registry. [JLS] Yes - Done. _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
