Subject: [Suit] draft-housley-suit-cose-hash-sig

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Jun 2018 14:09:11 -0400

I have read the -01 draft today.
I have not read [HASHSIG] yet.
I thought I'd try reading this first, to see what questions I had.

I have implemented COSE Sign1 with ECDSA in Ruby, so I have a grasp of
what we are trying to plug hash-sig *into*.

Suggestions:
1) would the structure show in section 3 be easier if it was described by
   CDDL?  I'm rather unclear about this.

2) I din't understand section 4, where it says:
      o  If the 'key_ops' field is present, it MUST include 'sign' when
                 creating a hash-based signature.

      o  If the 'key_ops' field is present, it MUST include 'verify'
                 when verifying a hash-based signature.

Clearly this is not something that travels over the network.  Is this
somehow indicating how to understand if one is dealing a public (verify) key
or a private (sign) key?

3) the variations: LMS_SHA256_M32_H20, and LMOTS_SHA256_N32_W2, etc. are
   listed, but I don't know if they need to be carried in the signature
   structure somehow.

4) I thought that perhaps we'd need CBOR or COSE specific way to transport
   the signatures.  I guess I shall read HASHSIG to find out what the
   signatures look like.

I understand draft-mcgrew-hash-sigs-11 is being advanced by CFRG.
I believe that SUIT should adopt this document, and should do so in the
current state.

I would like to have some examples in CBOR/COSE worked out with private keys
available in the appendices.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Russ Housley <[email-masked]>
Date: Wed, 13 Jun 2018 14:19:49 -0400

Michael:

Thanks for reading.  I think you need to look at [HASHSIG].  It uses XDR [RFC4506] to represent the signatures.  The XXDR structures are in Section 7 of [HASHSIG].

Russ

> On Jun 13, 2018, at 2:09 PM, Michael Richardson <[email-masked]> wrote:
> 
> 
> _______________________________________________
> Suit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit

---

From: Jim Schaad <[email-masked]>
Date: Wed, 13 Jun 2018 12:03:22 -0700

> -----Original Message-----
> From: Suit <[email-masked]> On Behalf Of Michael Richardson
> Sent: Wednesday, June 13, 2018 11:09 AM
> To: suit <[email-masked]>
> Subject: [Suit] draft-housley-suit-cose-hash-sig
> 
> 

No - this are not CBOR structures they are pure binary strings

> Clearly this is not something that travels over the network.  Is this
somehow
> indicating how to understand if one is dealing a public (verify) key or a
private
> (sign) key?

The key_ops field can be considered to potentially be transported over a
network.  It is part of the COSE_Key object rather than part of the
COSE_Sign1 object.

>    listed, but I don't know if they need to be carried in the signature

See the [HASHSIG] draft.  It is encoded into the signature structure and the
key type is in the public key structure.

>    the signatures.  I guess I shall read HASHSIG to find out what the

We have that.  This is looking at a signature just like ECDSA would produce.
This is a different "ECDSA" replacement.

> I would like to have some examples in CBOR/COSE worked out with private
> keys available in the appendices.

Always a good thing to have.

Jim

---

From: Brendan Moran <[email-masked]>
Date: Thu, 21 Jun 2018 15:11:18 +0000

I see that there are two current drafts for hash-based signatures:
https://tools.ietf.org/html/draft-mcgrew-hash-sigs-11
https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-signatures-12

I see that you have referenced the mcgrew draft rather than the IRTF/CFRG draft. Could you please explain what the difference is between these two drafts and why the mcgrew draft was a better choice than XMSS?

Thanks,
Brendan

On 13 Jun 2018, at 20:03, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:

-----Original Message-----
From: Suit <[email-masked]<mailto:[email-masked]>> On Behalf Of Michael Richardson
Sent: Wednesday, June 13, 2018 11:09 AM
To: suit <[email-masked]<mailto:[email-masked]>>
Subject: [Suit] draft-housley-suit-cose-hash-sig

Suggestions:

3) the variations: LMS_SHA256_M32_H20, and LMOTS_SHA256_N32_W2,
etc. are
  listed, but I don't know if they need to be carried in the signature
  structure somehow.

Jim

--
]               Never tell me the odds!                 | ipv6 mesh
networks [
]   Michael Richardson, Sandelman Software Works        | network
architect  [
]     [email-masked]<mailto:[email-masked]>  http://www.sandelman.ca/        |   ruby on rails
[

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works
-= IPv6 IoT consulting =-

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

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Russ Housley <[email-masked]>
Date: Thu, 21 Jun 2018 11:43:17 -0400

Brendan:

Yes, there are two CFRG algorithms for hash-based signatures.  I prefer the one McGrew's document, mostly because it is more straightforward.  There is some speed improvement for the additional complexity in XMSS at the cost of a larger signature value.  To me, the speed improvement is not big enough to justify the larger signature size.  Your mileage may vary.

This paper describes the difference between the two:

	https://eprint.iacr.org/2017/349.pdf

Russ

> On Jun 21, 2018, at 11:11 AM, Brendan Moran <[email-masked]> wrote:
> 
> https://tools.ietf.org/html/draft-mcgrew-hash-sigs-11 <https://tools.ietf.org/html/draft-mcgrew-hash-sigs-11>
> https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-signatures-12 <https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-signatures-12>
> 
>> On 13 Jun 2018, at 20:03, Jim Schaad <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 
>>> From: Suit <[email-masked] <mailto:[email-masked]>> On Behalf Of Michael Richardson
>>> To: suit <[email-masked] <mailto:[email-masked]>>
>>> ]     [email-masked] <mailto:[email-masked]>  http://www.sandelman.ca/ <http://www.sandelman.ca/>        |   ruby on rails
>> [
>>> 
>>> --
>>> Michael Richardson <[email-masked] <mailto:[email-masked]>>, Sandelman Software Works
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/suit <https://www.ietf.org/mailman/listinfo/suit>

---

From: Brendan Moran <[email-masked]>
Date: Thu, 21 Jun 2018 16:02:40 +0000

Hi Russ,
Thanks for the clarification. I agree that a larger signature is not what we need in SUIT. However, for the COSE draft, would it not make sense to provide for both LMS and XMSS? I don’t pretend to understand all COSE use cases.

Thanks,
Brendan

On 21 Jun 2018, at 16:43, Russ Housley <[email-masked]<mailto:[email-masked]>> wrote:

Brendan:

Russ

On Jun 21, 2018, at 11:11 AM, Brendan Moran <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Brendan

-----Original Message-----
From: Suit <[email-masked]<mailto:[email-masked]>> On Behalf Of Michael Richardson
Sent: Wednesday, June 13, 2018 11:09 AM
To: suit <[email-masked]<mailto:[email-masked]>>
Subject: [Suit] draft-housley-suit-cose-hash-sig

Suggestions:

Jim

---

From: Dave Thaler <[email-masked]>
Date: Thu, 21 Jun 2018 16:08:10 +0000

This is similar to a question I asked as well, whether the IETF only needs LMS or whether LMS is just an instance in a larger class that might be needed, and what the scope of the draft should be.

If the draft is not SUIT-only (e.g., allowing use in OSCORE, etc.) then it sounds like we might need the ability to support more than LMS for some use cases.

Dave

From: Suit <[email-masked]> On Behalf Of Brendan Moran
Sent: Thursday, June 21, 2018 9:03 AM
To: Russ Housley <[email-masked]>
Cc: suit <[email-masked]>
Subject: Re: [Suit] draft-housley-suit-cose-hash-sig

Hi Russ,

Thanks,
Brendan

Brendan:

https://eprint.iacr.org/2017/349.pdf<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feprint.iacr.org%2F2017%2F349.pdf&data=02%7C01%7Cdthaler%40microsoft.com%7C302d0f10626b454a732308d5d7907359%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651937771383092&sdata=zDGqR2NskjJzyVVcCEg8suPo3Lt9b6xLI1lxaYlWrbQ%3D&reserved=0>

Russ

I see that there are two current drafts for hash-based signatures:
https://tools.ietf.org/html/draft-mcgrew-hash-sigs-11<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-mcgrew-hash-sigs-11&data=02%7C01%7Cdthaler%40microsoft.com%7C302d0f10626b454a732308d5d7907359%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651937771393097&sdata=CTRx3BW3duXIREYxP4CyR%2BQY63qYgi2vqjnUM9uKqQM%3D&reserved=0>
https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-signatures-12<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-irtf-cfrg-xmss-hash-based-signatures-12&data=02%7C01%7Cdthaler%40microsoft.com%7C302d0f10626b454a732308d5d7907359%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651937771393097&sdata=pii%2Boa8SkTt7PLarq0P%2FKXL4WBVpNwLzGSIxEgZG5YU%3D&reserved=0>

Thanks,
Brendan

-----Original Message-----
From: Suit <[email-masked]<mailto:[email-masked]>> On Behalf Of Michael Richardson
Sent: Wednesday, June 13, 2018 11:09 AM
To: suit <[email-masked]<mailto:[email-masked]>>
Subject: [Suit] draft-housley-suit-cose-hash-sig

Suggestions:

(sign) key?

Jim

]     [email-masked]<mailto:[email-masked]>  http://www.sandelman.ca/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sandelman.ca%2F&data=02%7C01%7Cdthaler%40microsoft.com%7C302d0f10626b454a732308d5d7907359%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651937771403102&sdata=M7Tnkm9SzFy0ImJTiHRTBVDGfi3pR1vFixMCWskWmOo%3D&reserved=0>        |   ruby on rails
[

_______________________________________________
Suit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/suit<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=02%7C01%7Cdthaler%40microsoft.com%7C302d0f10626b454a732308d5d7907359%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651937771403102&sdata=AKEzjOXtE%2FPSc%2FbwKUP0ctCmYNL4CLWNuF9hh7IzOxE%3D&reserved=0>

---

From: Russ Housley <[email-masked]>
Date: Thu, 21 Jun 2018 15:43:50 -0400

I am advocating LMS. I think it would be appropriate for an advocate for XMSS to write a similar draft for that algorithm.

Russ

> On Jun 21, 2018, at 12:08 PM, Dave Thaler <[email-masked]> wrote:
> 
> From: Suit <[email-masked] <mailto:[email-masked]>> On Behalf Of Brendan Moran
> To: Russ Housley <[email-masked] <mailto:[email-masked]>>
> Cc: suit <[email-masked] <mailto:[email-masked]>>
> On 21 Jun 2018, at 16:43, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Brendan: 
>  
> https://eprint.iacr.org/2017/349.pdf <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feprint.iacr.org%2F2017%2F349.pdf&data=02%7C01%7Cdthaler%40microsoft.com%7C302d0f10626b454a732308d5d7907359%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651937771383092&sdata=zDGqR2NskjJzyVVcCEg8suPo3Lt9b6xLI1lxaYlWrbQ%3D&reserved=0>
>  
> Russ
>  
> 
> 
> On Jun 21, 2018, at 11:11 AM, Brendan Moran <[email-masked] <mailto:[email-masked]>> wrote:
>  
> https://tools.ietf.org/html/draft-mcgrew-hash-sigs-11 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-mcgrew-hash-sigs-11&data=02%7C01%7Cdthaler%40microsoft.com%7C302d0f10626b454a732308d5d7907359%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651937771393097&sdata=CTRx3BW3duXIREYxP4CyR%2BQY63qYgi2vqjnUM9uKqQM%3D&reserved=0>
> https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-signatures-12 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-irtf-cfrg-xmss-hash-based-signatures-12&data=02%7C01%7Cdthaler%40microsoft.com%7C302d0f10626b454a732308d5d7907359%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651937771393097&sdata=pii%2Boa8SkTt7PLarq0P%2FKXL4WBVpNwLzGSIxEgZG5YU%3D&reserved=0>
>  
> ]     [email-masked] <mailto:[email-masked]>  http://www.sandelman.ca/ <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sandelman.ca%2F&data=02%7C01%7Cdthaler%40microsoft.com%7C302d0f10626b454a732308d5d7907359%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651937771403102&sdata=M7Tnkm9SzFy0ImJTiHRTBVDGfi3pR1vFixMCWskWmOo%3D&reserved=0>        |   ruby on rails
> [
> 
> 
> --
> https://www.ietf.org/mailman/listinfo/suit <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=02%7C01%7Cdthaler%40microsoft.com%7C302d0f10626b454a732308d5d7907359%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651937771403102&sdata=AKEzjOXtE%2FPSc%2FbwKUP0ctCmYNL4CLWNuF9hh7IzOxE%3D&reserved=0>
>

---

From: Jim Schaad <[email-masked]>
Date: Thu, 21 Jun 2018 13:14:47 -0700

I have not looked in detail at the XMSS signature structure  and key structure and would want to do so before making any type of definitive statement.  However different drafts defining the different signature structures is what I would generally expect unless there is a huge overlap between them.  I would guess that the key structures are also different and thus would probably need to be identified differently.  This is based on the fact that a algorithm variant byte is placed at the start of both the key and signatures.

Doing this separately when we know they are going to be used (or potentially used) makes more sense to me.

Jim

From: Suit <[email-masked]> On Behalf Of Russ Housley
Sent: Thursday, June 21, 2018 12:44 PM
To: Dave Thaler <[email-masked]>; Brendan Moran <[email-masked]>
Cc: suit <[email-masked]>
Subject: Re: [Suit] draft-housley-suit-cose-hash-sig

Russ

On Jun 21, 2018, at 12:08 PM, Dave Thaler <[email-masked] <mailto:[email-masked]> > wrote:

Dave

From: Suit < <mailto:[email-masked]> [email-masked]> On Behalf Of Brendan Moran
Sent: Thursday, June 21, 2018 9:03 AM
To: Russ Housley < <mailto:[email-masked]> [email-masked]>
Cc: suit < <mailto:[email-masked]> [email-masked]>
Subject: Re: [Suit] draft-housley-suit-cose-hash-sig

Hi Russ, 

Thanks,

Brendan

On 21 Jun 2018, at 16:43, Russ Housley < <mailto:[email-masked]> [email-masked]> wrote:

Brendan: 

 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feprint.iacr.org%2F2017%2F349.pdf&data=02%7C01%7Cdthaler%40microsoft..com%7C302d0f10626b454a732308d5d7907359%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651937771383092&sdata=zDGqR2NskjJzyVVcCEg8suPo3Lt9b6xLI1lxaYlWrbQ%3D&reserved=0> https://eprint.iacr.org/2017/349.pdf

Russ

On Jun 21, 2018, at 11:11 AM, Brendan Moran < <mailto:[email-masked]> [email-masked]> wrote:

 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-mcgrew-hash-sigs-11&data=02%7C01%7Cdthaler%40microsoft.com%7C302d0f10626b454a732308d5d7907359%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651937771393097&sdata=CTRx3BW3duXIREYxP4CyR%2BQY63qYgi2vqjnUM9uKqQM%3D&reserved=0> https://tools.ietf.org/html/draft-mcgrew-hash-sigs-11

 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-irtf-cfrg-xmss-hash-based-signatures-12&data=02%7C01%7Cdthaler%40microsoft.com%7C302d0f10626b454a732308d5d7907359%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651937771393097&sdata=pii%2Boa8SkTt7PLarq0P%2FKXL4WBVpNwLzGSIxEgZG5YU%3D&reserved=0> https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-signatures-12

Thanks,

Brendan

On 13 Jun 2018, at 20:03, Jim Schaad < <mailto:[email-masked]> [email-masked]> wrote:

-----Original Message-----
From: Suit < <mailto:[email-masked]> [email-masked]> On Behalf Of Michael Richardson
Sent: Wednesday, June 13, 2018 11:09 AM
To: suit < <mailto:[email-masked]> [email-masked]>
Subject: [Suit] draft-housley-suit-cose-hash-sig

Suggestions:

somehow

private

(sign) key?

Jim

networks [

architect  [

]      <mailto:[email-masked]> [email-masked]   <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sandelman.ca%2F&data=02%7C01%7Cdthaler%40microsoft.com%7C302d0f10626b454a732308d5d7907359%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651937771403102&sdata=M7Tnkm9SzFy0ImJTiHRTBVDGfi3pR1vFixMCWskWmOo%3D&reserved=0> http://www.sandelman.ca/        |   ruby on rails

[

--
Michael Richardson < <mailto:[email-masked]> [email-masked]>, Sandelman Software Works
-= IPv6 IoT consulting =-

_______________________________________________
Suit mailing list
 <mailto:[email-masked]> [email-masked]
 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=02%7C01%7Cdthaler%40microsoft.com%7C302d0f10626b454a732308d5d7907359%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651937771403102&sdata=AKEzjOXtE%2FPSc%2FbwKUP0ctCmYNL4CLWNuF9hh7IzOxE%3D&reserved=0> https://www.ietf.org/mailman/listinfo/suit

---

From: Tony Putman <[email-masked]>
Date: Fri, 22 Jun 2018 08:13:22 +0000

As far as I can tell, it is not possible to tell from the signature whether it is LMS or XMSS (or indeed any other hash-based signature scheme). If this is the case, then I suggest that the algorithm identifiers in section 4 should be more specific (e.g. 'HSIG-LMS'), as should the COSE registry entries in section 7 (e.g. Name: HASHSIG-LMS, with corresponding expanded description).
-- Tony

From: Suit [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: 21 June 2018 20:44
To: Dave Thaler; Brendan Moran
Cc: suit
Subject: Re: [Suit] draft-housley-suit-cose-hash-sig

Russ

On Jun 21, 2018, at 12:08 PM, Dave Thaler <[email-masked]<mailto:[email-masked]>> wrote:

Dave

From: Suit <[email-masked]<mailto:[email-masked]>> On Behalf Of Brendan Moran
Sent: Thursday, June 21, 2018 9:03 AM
To: Russ Housley <[email-masked]<mailto:[email-masked]>>
Cc: suit <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Suit] draft-housley-suit-cose-hash-sig

Hi Russ,

Thanks,
Brendan

Brendan:

https://eprint.iacr.org/2017/349.pdf<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feprint.iacr.org%2F2017%2F349.pdf&data=02%7C01%7Cdthaler%40microsoft..com%7C302d0f10626b454a732308d5d7907359%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651937771383092&sdata=zDGqR2NskjJzyVVcCEg8suPo3Lt9b6xLI1lxaYlWrbQ%3D&reserved=0>

Russ

Thanks,
Brendan

-----Original Message-----
From: Suit <[email-masked]<mailto:[email-masked]>> On Behalf Of Michael Richardson
Sent: Wednesday, June 13, 2018 11:09 AM
To: suit <[email-masked]<mailto:[email-masked]>>
Subject: [Suit] draft-housley-suit-cose-hash-sig

Suggestions:

(sign) key?

Jim

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: Fri, 22 Jun 2018 05:17:33 -0400

I was assuming that LMS would use "HASHSIG", and XMSS would use "XMSS".  These labels align with the Internet-Draft file names.  In the long run, your suggestion is probably better.

Russ

> On Jun 22, 2018, at 4:13 AM, Tony Putman <[email-masked]> wrote:
> 
> From: Suit [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Russ Housley
> Sent: 21 June 2018 20:44
> On Jun 21, 2018, at 12:08 PM, Dave Thaler <[email-masked] <mailto:[email-masked]>> wrote:
>  
> https://eprint.iacr.org/2017/349.pdf <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feprint.iacr.org%2F2017%2F349.pdf&data=02%7C01%7Cdthaler%40microsoft..com%7C302d0f10626b454a732308d5d7907359%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651937771383092&sdata=zDGqR2NskjJzyVVcCEg8suPo3Lt9b6xLI1lxaYlWrbQ%3D&reserved=0>
>  
> Russ
>  
> 
> 
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 22 Jun 2018 05:41:06 -0400

I uses 'HSS-LMS' for the algorithm identifier.  The the updates in Sections 4 and 7...

Name:		draft-housley-suit-cose-hash-sig
Revision:	02
Title:		Use of the Hash-based Signature Algorithm with CBOR Object Signing and Encryption (COSE)
Document date:	2018-06-22
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/internet-drafts/draft-housley-suit-cose-hash-sig-02.txt <https://www.ietf.org/internet-drafts/draft-housley-suit-cose-hash-sig-02.txt>
Status:         https://datatracker.ietf.org/doc/draft-housley-suit-cose-hash-sig/ <https://datatracker.ietf.org/doc/draft-housley-suit-cose-hash-sig/>
Htmlized:       https://tools.ietf.org/html/draft-housley-suit-cose-hash-sig-02 <https://tools.ietf.org/html/draft-housley-suit-cose-hash-sig-02>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-housley-suit-cose-hash-sig <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-02 <https://www.ietf.org/rfcdiff?url2=draft-housley-suit-cose-hash-sig-02>

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.

> On Jun 22, 2018, at 5:17 AM, Russ Housley <[email-masked]> wrote:
> 
>> On Jun 22, 2018, at 4:13 AM, Tony Putman <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> https://eprint.iacr.org/2017/349.pdf <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feprint.iacr.org%2F2017%2F349.pdf&data=02%7C01%7Cdthaler%40microsoft...com%7C302d0f10626b454a732308d5d7907359%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636651937771383092&sdata=zDGqR2NskjJzyVVcCEg8suPo3Lt9b6xLI1lxaYlWrbQ%3D&reserved=0>
>>  
>> Russ
>>  
>> 
>> 
>>

---

From: Tony Putman <[email-masked]>
Date: Fri, 22 Jun 2018 16:47:03 +0000

Hi Russ,

Some further comments on your draft suit-cose-hash-sig:

In a number of places, starting in section 3, you limit this specification
to using SHA-256. As far as I can see, if a new RFC were issued updating
[HASHSIG} and using a different hash function, this specification would
not change due to the self-describing nature of the signature. So while
the restriction applies to [HASHSIG}, which is defining actual signatures,
I believe it does not apply to this draft, which is defining a way to
transport signatures.

Section 3.1: "Each signed public key is represented by the hash value at
the root of the tree": it also contains information about the tree
structure (type and otstype) and the identity I; but perhaps this detail
is not needed.

End of section 3.1: I find the text "lms_signature_on_public_key[0]"
(and so on) misleading because the signature is actually on public_key[1].
I feel it would be better to be a bit more verbose, and define:
  signature[k-1] = lms_signature_on_public_key_k_using_private_key[k-1]
  signed_public_key[k] = signature[k-1] || public_key[k]
Then the overall tree is just
  u32str(Nspk) ||
  signed_public_key[1] ||
  signed_public_key[2] ||
     ...
  signed_public_key[Nspk-1] ||
  signed_public_key[Nspk] ||
  lms_signature_on_message_using_private_key[Nspk]

Section 3.2, third paragraph: I suggest putting the elements in the same
order that they appear in the signature, namely:
  "An LMS signature consists of four elements: the number of the leaf
   associated with the LM-OTS signature, an LM-OTS signature as described
   in Section 3.3, a typecode indicating the particular LMS algorithm,
   and an array of values that is associated with the path through the
   tree from the leaf associated with the LM-OTS signature to the root."
It is probably worth noting here that the LM-OTS signature starts with
an ots-typecode, so that the signature can be easily parsed.

Section 3.3, last line: I suggest replacing the first element with
u32str(otstype) for clarity. It should be clear from context, but I think
it's worth emphasising.

Section 4, second paragraph: "The first four bytes of each LMS signature
value contains type code" is not correct. I suggest being less specific
and say something like "the LMS signature value is self-describing", as
parsing is a little more difficult to explain. Alternatively, reverse the
order of describing the parts, to that the self-parsing of the OTS
signature has already been explained before coming to the LMS signature.

Section 4: There is no mention of which kid to use. This may be a matter
of convention between sender and receiver, but if public keys are used
as trust anchors then the identity I of the public key could be sent in
the kid field. I think this should be mentioned at least as a MAY, to
facilitate interoperability.

Section 5.1, last paragraph: The generation of signatures also relies on
random numbers. Their generation is much less sensitive than the generation
of private keys, so don't lump them together in the same paragraph, but
it is worth a mention. As an aside, is there any investigation into a
deterministic signature, e.g. by setting C to a hash of all the private
keys?

Section 6: Some more idle speculation on my part. In software update,
the signed bundle *should* have a unique version number. If there were
a way to map version number to LMS node, this would provide a different
way to ensure that the same key was never reused. But I agree that such
a discussion doesn't belong in this document.

Section 7.1/7.2: Please update the "Description" to be more specific,
such as:
  "Description:  Hash-based digital signatures using HSS/LMS" and
  "Description: Public key of HSS/LMS hash-based digital signature"

Best regards,
Tony