Re: [COSE] Last Call: <draft-ietf-cose-hash-algs-03.txt> (CBOR Object Signing and Encryption (COSE): Hash Algorithms) to Informational RFC

[tom petch <[e-mail]>]

I encounter a number of problems with this I-D.  Much of it is about IANA
Considerations and I note the absence of a reference to RFC8126 which
provides the basis for much of my comments.

RFC8126 specifies a two-tier structure for IANA, of Group name an
Registry name, which makes it easier to find data, now and in future.
This I-D makes no mention of the Group name; perhaps easy enough to
guess in this instance, but better specified.

The I-D contains references to some of TBD1 to TBD11, with no indication
of what to do with them.  Looking at the current registry it is apparent
that Early Allocation took place in 2018 and 2019.  The I-D makes no
reference to this.  Are all these values to be made permanent?  Some of
them? I expect the I-D to say.

The I-D adds the value 'filter only' to one of the columns.  The
registry was set up by RFC8152 which lists permitted values of which
this is not one.  This then constitutes an update to RFC8152 which the
I-D does not mention.

The registry has five columns; this I-D adds a new one, Capabilities,
another update to RFC8152.  What then happens to this column for
existing entries in the registry?  The I-D is silent.

RFC8152 is Standards Track; this I-D which IMHO updates it is
Informational.

The IANA registry entry gives a reference of 'RFC8152'; this I-D, which
changes the specification of the registry, needs adding to that
reference.

RFC8126 recommends that IANA Considerations be for IANA, that IANA does
not have to search the rest of the document for the data it needs.
Here, the relevant data appears in three other sections as well (and
there is much in the I-D that is not relevant to IANA, it is not one of
those I-D that is only about IANA).

Abstract should be plain text -
     [I-D.ietf-cose-rfc8152bis-struct]
does not look like plain text.

I have great faith in the ability of IANA to make sense of what they are
asked to do but do think that the more straightforward that is the
better.  And then there are those that come after, who want the RFC to
say what happened and why without digging into the e-mail archives (as I
see happening now and again:-)

Tom Petch

> ----- Original Message -----
> From: "IETF-Announce on behalf of The IESG"
> <[e-mail][e-mail]>
> To: <IETF-Announce>
> Cc: <[e-mail]>; <[e-mail]>;
> <[e-mail]>; <[e-mail]>
> Sent: Tuesday, May 12, 2020 4:26 PM
>
>> 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'
>>    <draft-ietf-cose-hash-algs-03.txt> 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
>> [e-mail] mailing lists by 2020-05-26. Exceptionally,
> comments may
>> be sent to [e-mail] 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.
>>
>>
>>
>>
>>
>> _______________________________________________
>> IETF-Announce mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>> =