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 A24D6130DE2 for ; Thu, 21 Jun 2018 08:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com 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 lVsbYBEUvUxq for ; Thu, 21 Jun 2018 08:11:22 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40041.outbound.protection.outlook.com [40.107.4.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F6F412F1A6 for ; Thu, 21 Jun 2018 08:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mbhrAq4BY1wb4aXJhxneLWYaL+h2CnFH92CmWQhTRf0=; b=R5kik/iueIRRyq4u9eZObwwAw3MvMrCWB4MMCUcdBRKl3MNyItYynGEYl0T2oduiN5DzG9bTTeiaX9DCKXLubP8ydVl+ubGe8J3TogtoY9wGmL+joTVGydwA9D0DOr/aiPQb8GzrM9lZWTwUAxYWQsYF0yKd6/iiPYE6wFXw9AY= Received: from AM4PR0802MB2260.eurprd08.prod.outlook.com (10.172.217.150) by AM4PR0802MB2289.eurprd08.prod.outlook.com (10.172.218.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.884.20; Thu, 21 Jun 2018 15:11:18 +0000 Received: from AM4PR0802MB2260.eurprd08.prod.outlook.com ([fe80::15ab:db2e:593b:b5e0]) by AM4PR0802MB2260.eurprd08.prod.outlook.com ([fe80::15ab:db2e:593b:b5e0%4]) with mapi id 15.20.0863.016; Thu, 21 Jun 2018 15:11:18 +0000 From: Brendan Moran To: Russ Housley CC: suit Thread-Topic: [Suit] draft-housley-suit-cose-hash-sig Thread-Index: AQHUA0IcLpl64e0Ltk+rjSClOrFaQaRei+EAgAxRz4A= Date: Thu, 21 Jun 2018 15:11:18 +0000 Message-ID: <0CDB8D05-0214-4749-9907-5A1B0B4A2191@arm.com> References: <31676.1528913351@localhost> <04f401d40349$33a58b10$9af0a130$@augustcellars.com> In-Reply-To: <04f401d40349$33a58b10$9af0a130$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.8.2) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brendan.Moran@arm.com; x-originating-ip: [217.140.96.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0802MB2289; 7:1NbDkRX+lZGSVMjmVWJ/wxijDBQ34/i0OPu1yBciYN4cmaDzkZ89jXQPMb4wcjuqqLhW/IN8uHIXVpt9ekHgEU4HP1ioRTQwVW9Nc7asOCLP8SLPoTd2NCAUaidHwUf826BJiI208Y2AARR984PhzOHei4GEfP2YBwNky1R6rT1V0BCWnkGmZvennkpDCL6xocNfm92YrKvz409NaPQLNQRtE+Wt0qIQyeKfm5mN+hLySakPikiRo8s2ZMn6E4pq x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 22394dd2-625c-4455-fede-08d5d7893d7c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:AM4PR0802MB2289; x-ms-traffictypediagnostic: AM4PR0802MB2289: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:AM4PR0802MB2289; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0802MB2289; x-forefront-prvs: 07106EF9B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(396003)(39860400002)(346002)(366004)(376002)(189003)(199004)(40434004)(13464003)(3846002)(6116002)(81166006)(5250100002)(6916009)(7736002)(82746002)(5890100001)(8676002)(2900100001)(5660300001)(81156014)(2906002)(72206003)(68736007)(14454004)(4326008)(966005)(53936002)(25786009)(3660700001)(50226002)(478600001)(3280700002)(6246003)(8936002)(606006)(106356001)(33656002)(57306001)(105586002)(316002)(66066001)(186003)(59450400001)(6512007)(54896002)(6306002)(236005)(86362001)(486006)(99286004)(6506007)(53546011)(97736004)(6436002)(476003)(36756003)(2616005)(229853002)(102836004)(446003)(76176011)(6486002)(11346002)(83716003)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0802MB2289; H:AM4PR0802MB2260.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: RxZtLHOAhwEKSJWXgjNiFn9fcv2cPEfwTVyy62fBUT/pFgZl8a0RtxMyDEfvbHVD1zFnCQ9n/d0txuNJWyIvS7rWoWb1H69Ergi3lh4KcD0HkIQhGzYhy4lFZHy30L9OHihFfAIgBkaIrn8KO4Gl6KY/dYvK+nODCvxW+KS0HoWy+fu5mJrZ02atDB9znoslVgSAkaOjGDldGTbrR7zqRyjfF8MBrYOZ7GqqcB/y2XPx4/SdKq8ln6C9aXxYnWrrUC5UdVcRUK68DyvMS8F91Tm/a+QITcLWHMDt+BYu6j/sG8ZSP6517563JQtsyLhuFk8i2Q1DkaRFxgWEDxgwWg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_0CDB8D050214474999075A1B0B4A2191armcom_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 22394dd2-625c-4455-fede-08d5d7893d7c X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2018 15:11:18.4265 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0802MB2289 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:11:26 -0000 --_000_0CDB8D050214474999075A1B0B4A2191armcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 d= raft. Could you please explain what the difference is between these two dra= fts and why the mcgrew draft was a better choice than XMSS? Thanks, Brendan On 13 Jun 2018, at 20:03, Jim Schaad > wrote: -----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 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 th= e 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 http://www.sandelman.ca/ = | ruby on rails [ -- Michael Richardson >, S= andelman 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 confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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. --_000_0CDB8D050214474999075A1B0B4A2191armcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
I see that there are two current drafts for hash-based sign= atures:
https://tools.ietf.org/html/draft-mcgrew-hash-sigs-11=
https://tools.ietf.org/html/draft-irt= f-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 betwe= en 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-bou= nces@ietf.org> On Behalf Of Michael Richardson
Sent: Wednesday, June 13, 2018 11:09 AM
To: suit <suit@ietf.org&= gt;
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
            &nb= sp;   creating a hash-based signature.

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

Clearly this is not something that travels over the network.  Is this<= br class=3D"">
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 sign= ature
  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<= br class=3D"">   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 prod= uce.
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


--
]             &= nbsp; Never tell me the odds!       &nbs= p;         | ipv6 mesh
networks [
]   Michael Richardson, Sandelman Software Works   &nbs= p;    | network
architect  [
]     mc= r@sandelman.ca  ht= tp://www.sandelman.ca/        | &nbs= p; ruby on rails
[

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




_______________________________________________
Suit mailing list
Suit@ietf.org=
ht= tps://www.ietf.org/mailman/listinfo/suit

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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. --_000_0CDB8D050214474999075A1B0B4A2191armcom_--