-----Original Message-----
From: COSE <cose-bounces@xxxxxxxx> On Behalf Of tom petch
Sent: Tuesday, May 19, 2020 2:36 AM
To: Last Call <last-call@xxxxxxxx>
Cc: ivaylo@xxxxxxx; cose-chairs@xxxxxxxx;
draft-ietf-cose-hash-algs@xxxxxxxx; cose@xxxxxxxx
Subject: Re: [COSE] Last Call: <draft-ietf-cose-hash-algs-03.txt> (CBOR
Object Signing and Encryption (COSE): Hash Algorithms) to Informational RFC
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.
[JLS] There is a reason why you are not seeing much of the IANA
Considerations that you believe should be present, it is because they are in
draft-ietf-cose-rfc8152bis-algs and draft-ietf-cose-rfc8152bis-struct. Most
of them are in the algorithm document. The presumption is that those two
documents are going to be processed by IANA before this document is. I will
make this explicit.
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.
[JLS] use the TBD placeholders is normal usage with the values being
assigned by IANA and replaced in the document. It would be possible to
refer to the early assignments, but I personally feel that this is a
decision for IANA to make. There may be reasons when the final assignment
is done that different values need to be used. (For example, incorrect
usage of existing values in the wild or collisions found during the
assignment process.) I have always made the assumption that the instruction
for the RFC Editor to replace them is implicit and does not need to be
explicit. I can make that change although I doubt it makes any difference.
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.
[JLS] I would disagree that this requires an update of RFC 8152 for two
reasons. First this is not a change in the COSE protocol in any manner and
thus would violate what I consider to be the letter of the law for updates.
Second, when this change is made RFC 8152 will have been obsoleted by a new
RFC and thus it does not really make sense to update it. This is an IANA
instruction not a protocol change.
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.
[JLS] This is done by a different document.
RFC8152 is Standards Track; this I-D which IMHO updates it is Informational.
[JLS] Given that it is updating the IANA sections and not the protocol I
would not consider that to be an issue.
The IANA registry entry gives a reference of 'RFC8152'; this I-D, which
changes the specification of the registry, needs adding to that reference.
[JLS] This make sense and I will do it.
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).
[JLS] I do not consider that pointing to a table in the document to fall
under the rubric of making IANA search for data. It is a direct pointer to
the information that is required. Having the same table appear multiple
times in a document is a recipe for making mistakes in terms of what the
data is. There is already the problem of trying to harmonize text and the
table with out adding another version of the table.
Abstract should be plain text -
[I-D.ietf-cose-rfc8152bis-struct]
does not look like plain text.
[JLS] This is not plain text and will be repaired by the RFC editor. Using
the reference structure makes it clearer that this is something that the RFC
editor is going to be required to update. This is not something I do for
documents which are already RFCs.
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:-)
[JLS] The other problem that you have not highlighted is the question of
when a bis document is created should the IANA instructions be propagated
forward into the new document despite the fact that IANA is not going to do
anything. That is what is going to happen with some of these registries.
It makes life even harder if duplicate or extraneous items are included.
Jim
Tom Petch
> ----- Original Message -----
> From: "IETF-Announce on behalf of The IESG"
> <ietf-announce-bounces@ietf.orgiesg-secretary@xxxxxxxx>
> To: <IETF-Announce>
> Cc: <draft-ietf-cose-hash-algs@xxxxxxxx>; <cose-chairs@xxxxxxxx>;
> <cose@xxxxxxxx>; <ivaylo@xxxxxxx>
> 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
>> last-call@xxxxxxxx mailing lists by 2020-05-26. Exceptionally,
> comments may
>> be sent to iesg@xxxxxxxx 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
>> IETF-Announce@xxxxxxxx
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>> =
_______________________________________________
COSE mailing list
COSE@xxxxxxxx
https://www.ietf.org/mailman/listinfo/cose
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
