-----Original Message-----
From: Robert Wilton via Datatracker <[email protected]>
Sent: Tuesday, June 9, 2020 9:43 AM
To: The IESG <[email protected]>
Cc: [email protected]; [email protected]; [email protected];
Ivaylo Petrov <[email protected]>; [email protected]
Subject: Robert Wilton's No Objection on draft-ietf-cose-hash-algs-04: (with
COMMENT)
Robert Wilton has entered the following ballot position for
draft-ietf-cose-hash-algs-04: 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-hash-algs/
----------------------------------------------------------------------
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"?
[JLS] Totally makes sense - done
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"?
[JLS] done
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.
[JLS] I don't think so, the algorithm is less efficient than SHA-512 on 64-bit
hardware but without making the relative statement it is less useful. I think
that we are making statements about efficiency in the next line is sufficiently
close.
3.3. SHAKE Algorithms
Would this be more clear to be titled as SHA-3 Algorithms?
[JLS] No I don't think so. The SHA-3 family defined SHA3-256 and SHAKE-256. I
think that using SHAKE in the title makes it clear we are not dealing with the
first group of hash functions.
JIM
Thanks,
Rob
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
