Subject: [Suit] Fwd: New Version Notification for draft-housley-suit-cose-hash-sig-03.txt

From: Russ Housley <[email-masked]>
Date: Sun, 1 Jul 2018 14:52:38 -0400

FYI

> From: [email-masked]
> Subject: New Version Notification for draft-housley-suit-cose-hash-sig-03.txt
> Date: July 1, 2018 at 2:14:52 PM EDT
> To: "Russ Housley" <[email-masked]>
> 
> 
> A new version of I-D, draft-housley-suit-cose-hash-sig-03.txt
> has been successfully submitted by Russ Housley and posted to the
> IETF repository.
> 
> Name:		draft-housley-suit-cose-hash-sig
> Revision:	03
> Title:		Use of the Hash-based Signature Algorithm with CBOR Object Signing and Encryption (COSE)
> Document date:	2018-07-01
> Group:		Individual Submission
> Pages:		11
> URL:            https://www.ietf.org/internet-drafts/draft-housley-suit-cose-hash-sig-03.txt
> Status:         https://datatracker.ietf.org/doc/draft-housley-suit-cose-hash-sig/
> Htmlized:       https://tools.ietf.org/html/draft-housley-suit-cose-hash-sig-03
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-housley-suit-cose-hash-sig
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-housley-suit-cose-hash-sig-03
> 
> Abstract:
>   This document specifies the conventions for using the Leighton-Micali
>   Signature (LMS) algorithm for digital signatures with the CBOR Object
>   Signing and Encryption (COSE) syntax.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Tony Putman <[email-masked]>
Date: Mon, 2 Jul 2018 09:53:42 +0000

Russ,

Thanks for the new version of the draft. It addresses all my comments fully except for the question of 'kid'. The point that I was trying to make there was the LMS public key (unlike other public keys) has a well-defined identity, called 'I' in [HASHSIG]. I agree that you can't be prescriptive about this, but I suggest strengthening your new bullet point at the end of section 4 to:
 "If the 'kid' field is present, then it MAY contain the identity of the public key (called 'I' in [HASHSIG])."

The situation that I'm thinking of here is one where the IoT device has more than one HSS/LMS public key as trust anchor. Because public key parameters 'I' and 'q' are integral parts of the verification steps, the device may have to attempt verification multiple times and anything which can improve the chances of picking the right public key first time saves computation (energy).

Tony

Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury, SN16 0RP, UK.
This message is intended solely for the addressee and may contain confidential information. If you have received this message in error, please immediately and permanently delete it, and do not use, copy or disclose the information contained in this message or in any attachment.
Dyson may monitor email traffic data and content for security & training.

---

From: Russ Housley <[email-masked]>
Date: Mon, 2 Jul 2018 10:25:20 -0400

Tony:
>  
> Thanks for the new version of the draft.. It addresses all my comments fully except for the question of 'kid'. The point that I was trying to make there was the LMS public key (unlike other public keys) has a well-defined identity, called 'I' in [HASHSIG]. I agree that you can't be prescriptive about this, but I suggest strengthening your new bullet point at the end of section 4 to:

I totally misunderstood your comment, and now that I do, I'm not sure that I agree.  That said, maybe I am still not fully understanding your point.

I think the kid would identify a tree, not a node in the tree.  The signature value itself contains the information necessary to locate the node within the tree.

Russ

---

From: Tony Putman <[email-masked]>
Date: Mon, 2 Jul 2018 15:59:57 +0000

Russ,

> I think the kid would identify a tree, not a node in the tree.  The signature value itself contains the information necessary to locate the node within the tree.

Which I fully agree with, so I guess my text was off. How about:
  "If the 'kid' field is present, then it MAY contain the identity of the top-level HSS tree. This is called 'I' in [HASHSIG] and is contained in the public key which corresponds to this tree."

Without this hint, the verifier would potentially have to try the verification step for each of the trust anchors that it knows of (though only as far as verifying the next public key in the chain); there is no direct way to obtain 'I' from the signature and it is a parameter in the verification process. 'I' is present in the public key, but you're right that it's not the identity of the key, but rather the identity of the tree as a whole. 

Tony

---

From: Russ Housley <[email-masked]>
Date: Mon, 2 Jul 2018 12:14:41 -0400

I think I understand now.

How about:

      o  If the 'kid' field is present, and it MAY be used to identify
           the top of the HSS tree.  In [HASHSIG], this identifier is
           called 'I', and it is the 16-byte identifier of the LMS
           public key for the tree.

Russ

> On Jul 2, 2018, at 11:59 AM, Tony Putman <[email-masked]> wrote:
> 
> Russ,
> 
> You say:

---

From: Tony Putman <[email-masked]>
Date: Mon, 2 Jul 2018 16:36:46 +0000

Sounds good to me. The "and" after the first comma seems odd to me, but that's an editorial nit.
-- Tony

-----Original Message-----
From: Suit [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: 02 July 2018 17:15
To: Tony Putman
Cc: suit
Subject: Re: [Suit] Fwd: New Version Notification for draft-housley-suit-cose-hash-sig-03.txt

How about:

Russ

> Dyson may monitor email traffic data and content for security & training.

_______________________________________________
Suit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/suit