Subject: [COSE] Robert Wilton's No Objection on draft-ietf-cose-hash-algs-04: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Tue, 09 Jun 2020 09:42:33 -0700

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"?

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"?

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.

3.3.  SHAKE Algorithms

Would this be more clear to be titled as SHA-3 Algorithms?

Thanks,
Rob

---

From: Jim Schaad <[email-masked]>
Date: Tue, 9 Jun 2020 10:28:27 -0700

-----Original Message-----
From: Robert Wilton via Datatracker <[email-masked]> 
Sent: Tuesday, June 9, 2020 9:43 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Ivaylo Petrov <[email-masked]>; [email-masked]
Subject: Robert Wilton's No Objection on draft-ietf-cose-hash-algs-04: (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.)

Hi,

Thank you for this document, I found it easy to read and understand.  A few minor comments:

1.  Introduction

Would it be better to write "along with an identifier for the hash algorithm"?
[JLS] Totally makes sense - done

1.  Introduction

[JLS] done

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