Subject: [COSE] Draft review https://tools.ietf.org/html/draft-ietf-cose-hash-algs-00

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 1 Apr 2019 12:56:10 -0400

Hi Jim,

Thanks for your work on this draft!  I have a few editorial suggestions:

Section 2.1 - Deprecated is spelled incorrectly in several places,
including the table.

Section 2.3 - Typo
OLD:
 The SHA-3 hash algorithms have a significantly different structure
   than the SHA-3 hash algorithms.
NEW:
 The SHA-3 hash algorithms have a significantly different structure
   than the derived SHA-3 SHAKE hash algorithms.

For SHAKE, do you want to reference NIST SP 800-185 where the definitions
for SHA-3 derived functions are included?

And one technical:

How will this be included in the structure?  Would it be a separate layer
to join the object in the case #2 for the work (I imagine so)?  Is that
covered elsewhere, perhaps it's planned for RFC8152bis-struct?

Thanks!
-- 

Best regards,
Kathleen

---

From: Jim Schaad <[email-masked]>
Date: Mon, 1 Apr 2019 10:50:39 -0700

From: COSE <[email-masked]> On Behalf Of Kathleen Moriarty
Sent: Monday, April 1, 2019 9:56 AM
To: cose <[email-masked]>
Subject: [COSE] Draft review https://tools.ietf.org/html/draft-ietf-cose-hash-algs-00

Hi Jim,

Section 2.1 - Deprecated is spelled incorrectly in several places, including the table. 

[JLS] Will fix this

Section 2.3 - Typo

OLD:

NEW:

[JLS] I had noticed this, however the correct change I that is different from the SHA-2 algorithms.  

For SHAKE, do you want to reference NIST SP 800-185 where the definitions for SHA-3 derived functions are included?

And one technical:

How will this be included in the structure?  Would it be a separate layer to join the object in the case #2 for the work (I imagine so)?  Is that covered elsewhere, perhaps it's planned for RFC8152bis-struct?

[JLS] This is part of what I was asking in the F2F about defining some type of general COSE_Hash structure in this document.  There is some introductory text in the introduction of RFC8152bis-struct which I should copy into this document and there is a structure that is being used in the X.509 draft.   My general view is that this is frequently something that is very application specific.  One would expect an array of elements – but the exact set of elements beyond the hash algorithm identifier and the hash value may be variable.   Do you include a random value to make pre-image attacks harder?  Do you include a pointer to someplace else in the document or external with a URI or a manifest number (suit manifests)?  

Doing something in this document may be useful, but it also may be restrictive on others.

Jim

Thanks!

-- 

Best regards,

Kathleen

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 1 Apr 2019 20:02:33 +0200

> Doing something in this document may be useful, but it also may be restrictive on others.

I had wanted to speak up during the meeting, but I think didn’t see a need when I perceived that the discussion went into the direction of defining a structure that is explicitly given as an example — that may then be copied where it just drops in but would otherwise not be considered a requirement for the use of the hash algorithms registry.

Grüße, Carsten

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 3 Apr 2019 13:46:15 -0400

Replying to Jim as Carsten snipped too much :-)

On Mon, Apr 1, 2019 at 1:50 PM Jim Schaad <[email-masked]> wrote:

>
>
>
>
> *From:* COSE <[email-masked]> *On Behalf Of *Kathleen Moriarty
> *Sent:* Monday, April 1, 2019 9:56 AM
> *To:* cose <[email-masked]>
> *Subject:* [COSE] Draft review
> https://tools.ietf.org/html/draft-ietf-cose-hash-algs-00
>
>
>
> Hi Jim,
>
>
>

Thanks

> [JLS] This is part of what I was asking in the F2F about defining some
> type of general COSE_Hash structure in this document.  There is some
> introductory text in the introduction of RFC8152bis-struct which I should
> copy into this document and there is a structure that is being used in the
> X.509 draft.   My general view is that this is frequently something that is
> very application specific.  One would expect an array of elements – but the
> exact set of elements beyond the hash algorithm identifier and the hash
> value may be variable.   Do you include a random value to make pre-image
> attacks harder?  Do you include a pointer to someplace else in the document
> or external with a URI or a manifest number (suit manifests)?
>
>
>

I'd like it to be optional as I agree with your point, but do see it useful
to be able to associate the encrypted object with the hash.  Agreed that
the set of elements would be variable, even with similar use cases.  As for
pre-image attacks, SHA-1 is already discouraged.  From what I've read, it's
computationally difficult with SHA-256, but bitcoin decided to hash twice
(I don't think that's the best option here).  The pointer may be useful
with a URI or manifest number.

If there's not a lot of demand for this, leave it out as you have it now?

Best regards,
Kathleen

-- 

Best regards,
Kathleen