Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7065A12F1A5 for ; Thu, 21 Jun 2018 08:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oZaD0Gxa83n for ; Thu, 21 Jun 2018 08:43:21 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E9F130EEC for ; Thu, 21 Jun 2018 08:43:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 82889300A08 for ; Thu, 21 Jun 2018 11:43:19 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 02sgv_B9Bmd7 for ; Thu, 21 Jun 2018 11:43:17 -0400 (EDT) Received: from new-host-4.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id 4046F30042A; Thu, 21 Jun 2018 11:43:17 -0400 (EDT) From: Russ Housley Message-Id: <697B1DC9-B1DE-48BA-ADC6-EF936208AFCE@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E7915BCC-9048-4898-8895-20C25B84A823" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Thu, 21 Jun 2018 11:43:17 -0400 In-Reply-To: <0CDB8D05-0214-4749-9907-5A1B0B4A2191@arm.com> Cc: suit To: Brendan Moran References: <31676.1528913351@localhost> <04f401d40349$33a58b10$9af0a130$@augustcellars.com> <0CDB8D05-0214-4749-9907-5A1B0B4A2191@arm.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Suit] draft-housley-suit-cose-hash-sig X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 15:43:26 -0000 --Apple-Mail=_E7915BCC-9048-4898-8895-20C25B84A823 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 = wrote: >=20 > 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 = >=20 > 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? >=20 > Thanks, > Brendan >=20 >=20 >> On 13 Jun 2018, at 20:03, Jim Schaad > wrote: >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: Suit > On = Behalf Of Michael Richardson >>> Sent: Wednesday, June 13, 2018 11:09 AM >>> To: suit > >>> Subject: [Suit] draft-housley-suit-cose-hash-sig >>>=20 >>>=20 >>> 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. >>>=20 >>> I have implemented COSE Sign1 with ECDSA in Ruby, so I have a grasp = of >>> what we are trying to plug hash-sig *into*. >>>=20 >>>=20 >>> Suggestions: >>> 1) would the structure show in section 3 be easier if it was = described by >>> CDDL? I'm rather unclear about this. >>=20 >> No - this are not CBOR structures they are pure binary strings >>=20 >>>=20 >>> 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. >>>=20 >>> o If the 'key_ops' field is present, it MUST include 'verify' >>> when verifying a hash-based signature. >>>=20 >>> 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? >>=20 >> 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. >>=20 >>>=20 >>> 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. >>=20 >> See the [HASHSIG] draft. It is encoded into the signature structure = and the >> key type is in the public key structure. >>=20 >>>=20 >>> 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. >>=20 >> We have that. This is looking at a signature just like ECDSA would = produce. >> This is a different "ECDSA" replacement. >>=20 >>>=20 >>> 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. >>>=20 >>> I would like to have some examples in CBOR/COSE worked out with = private >>> keys available in the appendices. >>=20 >> Always a good thing to have. >>=20 >> Jim >>=20 >>>=20 >>> -- >>> ] Never tell me the odds! | ipv6 mesh >> networks [ >>> ] Michael Richardson, Sandelman Software Works | network >> architect [ >>> ] mcr@sandelman.ca = http://www.sandelman.ca/ | ruby on = rails >> [ >>>=20 >>> -- >>> Michael Richardson >, Sandelman Software Works >>> -=3D IPv6 IoT consulting =3D- >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> Suit mailing list >> Suit@ietf.org >> 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. --Apple-Mail=_E7915BCC-9048-4898-8895-20C25B84A823 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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-irtf-cfrg-xmss-hash-based-sig= natures-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> wrote:



-----Original Message-----
From: Suit <suit-bounces@ietf.org> On Behalf Of Michael = Richardson
Sent: Wednesday, June 13, 2018 11:09 AM
To: suit <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
=             &n= bsp;   creating a hash-based signature.

     o  If the 'key_ops' field is present, = it MUST include 'verify'
=             &n= bsp;   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


--
] =             &n= bsp; Never tell me the odds! =             &n= bsp;   | ipv6 mesh
networks [
]   Michael Richardson, Sandelman Software Works =        | network
architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/ =        |   ruby on rails
[

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
-=3D IPv6 IoT consulting =3D-




_______________________________________________
Suit mailing list
Suit@ietf.org
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.

= --Apple-Mail=_E7915BCC-9048-4898-8895-20C25B84A823--