Subject: [COSE] Alvaro Retana's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT)

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Tue, 09 Jun 2020 12:07:45 -0700

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.

(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.

---

From: Jim Schaad <[email-masked]>
Date: Mon, 15 Jun 2020 10:22:27 -0700

-----Original Message-----
From: Alvaro Retana via Datatracker <[email-masked]> 
Sent: Tuesday, June 9, 2020 12:08 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Matthew Miller <[email-masked]>
Subject: Alvaro Retana's No Objection on draft-ietf-cose-rfc8152bis-algs-09: (with COMMENT)

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.)

(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.

[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.

[JLS] 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.