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

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 <Brendan.Moran@arm.com> wrote:
> 
> 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-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>
> 
> 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 <ietf@augustcellars.com <mailto:ietf@augustcellars.com>> wrote:
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: Suit <suit-bounces@ietf.org <mailto:suit-bounces@ietf.org>> On Behalf Of Michael Richardson
>>> Sent: Wednesday, June 13, 2018 11:09 AM
>>> To: suit <suit@ietf.org <mailto:suit@ietf.org>>
>>> Subject: [Suit] draft-housley-suit-cose-hash-sig
>>> 
>>> 
>>> 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.
>> 
>> No - this are not CBOR structures they are pure binary strings
>> 
>>> 
>>> 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?
>> 
>> 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.
>> 
>>> 
>>> 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.
>> 
>> See the [HASHSIG] draft.  It is encoded into the signature structure and the
>> key type is in the public key structure.
>> 
>>> 
>>> 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.
>> 
>> We have that.  This is looking at a signature just like ECDSA would produce.
>> This is a different "ECDSA" replacement.
>> 
>>> 
>>> 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.
>> 
>> Always a good thing to have.
>> 
>> Jim
>> 
>>> 
>>> --
>>> ]               Never tell me the odds!                 | ipv6 mesh
>> networks [
>>> ]   Michael Richardson, Sandelman Software Works        | network
>> architect  [
>>> ]     mcr@sandelman.ca <mailto:mcr@sandelman.ca>  http://www.sandelman.ca/ <http://www.sandelman.ca/>        |   ruby on rails
>> [
>>> 
>>> --
>>> Michael Richardson <mcr+IETF@sandelman.ca <mailto:mcr+IETF@sandelman.ca>>, Sandelman Software Works
>>> -= IPv6 IoT consulting =-
>>> 
>>> 
>> 
>> 
>> _______________________________________________
>> Suit mailing list
>> Suit@ietf.org <mailto:Suit@ietf.org>
>> https://www.ietf.org/mailman/listinfo/suit <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.