From nobody Mon Dec 2 22:21:39 2019 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E8F120106 for ; Mon, 2 Dec 2019 22:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 HAtGG1taxMXA for ; Mon, 2 Dec 2019 22:21:36 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96A4B1200F1 for ; Mon, 2 Dec 2019 22:21:35 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 2 Dec 2019 22:21:29 -0800 From: Jim Schaad To: 'John Mattsson' , References: In-Reply-To: Date: Mon, 2 Dec 2019 22:21:26 -0800 Message-ID: <01bd01d5a9a1$e6481490$b2d83db0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIK7AZ7ZhCgpAnv67kbs957zahDPac9Fxrw Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Comments on draft-ietf-cose-rfc8152bis-struct-07 and draft-ietf-cose-rfc8152bis-algs-06 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 06:21:37 -0000 -----Original Message----- From: COSE On Behalf Of John Mattsson Sent: Thursday, November 21, 2019 2:27 PM To: cose@ietf.org Subject: [COSE] Comments on draft-ietf-cose-rfc8152bis-struct-07 and = draft-ietf-cose-rfc8152bis-algs-06 Comments on draft-ietf-cose-rfc8152bis-struct-07 and = draft-ietf-cose-rfc8152bis-algs-06 General: - Minor note: The abstracts of the documents have minor differences and = the subsections in the introductions have differ orders. - As RFC 8610 is published now, shouldn=E2=80=99t the documents be = updated to match the final CDDL grammar? [JLS] As far as I know, the grammar does match what is in RFC 8610. = What I wanted to avoid was a normative dependency on that document. draft-ietf-cose-rfc8152bis-struct-07: - "There has been an increased focus on small, constrained devices" I think the document should mention constrained radio technologies as = well [JLS] I don't see the point to that. This is a small throw away line to = help provide motivation. Adding a duplicate of the same case does not = seem to provide any benefits.=20 - "strings" are used in in various places. Should be changed to "byte = string" or "text string" as CBOR has two types of strings. I have added = a line to the document terminology section. [JLS] I just went through the document again and made sure that I was = consistent. I am always using either "byte string" or "string". The = latter is used for text strings. I am not sure that=20 - "3. The content of the message. The content is either the plaintext = or the ciphertext as appropriate." This seems to only describe encryption. For signatures and MACs it = would be payload, signature/tag. [JLS] I would be willing to change plaintext to a different term, but = payload is way to overloaded to be placed there. While plaintext is = used in the context of encryption, it is still meaningful here as being = something that is not the ciphertext and thus is the original text. As = such it is not inappropriate for signed and mac-ed contexts. - "structure", "message", "object", "map", "array", "object structure", = "message structure", "data object", "structure object", "map object", = "array object", "data structure", "data item", "CBOR structures", "COSE = structure", "COSE map", "CBOR map", "CBOR object", "COSE object" There is a large amount of terms used in the documents. I feel that = they could be defined a bit more. Also, are all of them really needed? [JLS] I cleaned some of these out. - OLD "The set of protected header parameters wrapped in a bstr." NEW "The set of protected header parameters as a map wrapped in a = bstr." [JLS] I went with a slightly different wording. - The draft has quite a lot of text on different types of signatures = like signatures with message recovery. Would be good to have some = sentences on signatures with and without state. The text on signatures = is also missing that they provide data authentication, integrity = protection, and provides non-repudiation. [JLS] I don't see that information on stateful signatures is going to be = relevant here. A stateful signature algorithm does not change how any = of the encoding/decoding of COSE is done. The only reason why I put in = the text about message recovery signatures is that this affects how the = code is written when one of these shows up and knowing in advance that = it may be a problem is useful. [JLS] Added some text on Data Origination and Data integrity. As = previously discussed, non-repudiation is a made up term with no meaning. - "They provide either no or very limited data origination." This sentence occurs in several places. The term "data origination" = seems to not be used very much and also have different meanings. E.g. the book "Information Security: Dictionary of Concepts, = Standards and Terms" defines it as "data origination. In computing, the translation of information = from its original form into machine readable form or directly into = electrical signals." Could we replace "data origination" with "non-repudiation"? [JLS] from RFC 4949 $ data origin authentication service (I) A security service that verifies the identity of a system entity that is claimed to be the original source of received data. (See: authentication, authentication service.) Jim - "digesst" - "stucture" draft-ietf-cose-rfc8152bis-algs-06 - "the the" Cheers, John _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose From nobody Tue Dec 3 00:30:39 2019 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF02120180 for ; Tue, 3 Dec 2019 00:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 mLn-ITzGJ6b2 for ; Tue, 3 Dec 2019 00:30:36 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8D1A120131 for ; Tue, 3 Dec 2019 00:30:35 -0800 (PST) Received: from [192.168.217.116] (p548DC893.dip0.t-ipconnect.de [84.141.200.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47RwCs6gVzz160x; Tue, 3 Dec 2019 09:30:33 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <01bd01d5a9a1$e6481490$b2d83db0$@augustcellars.com> Date: Tue, 3 Dec 2019 09:30:37 +0100 Cc: John Mattsson , cose@ietf.org X-Mao-Original-Outgoing-Id: 597054634.572926-428fe4bf86b86b2fc4d92726ebe5757e Content-Transfer-Encoding: quoted-printable Message-Id: References: <01bd01d5a9a1$e6481490$b2d83db0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [COSE] Comments on draft-ietf-cose-rfc8152bis-struct-07 and draft-ietf-cose-rfc8152bis-algs-06 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 08:30:38 -0000 On Dec 3, 2019, at 07:21, Jim Schaad wrote: >=20 > [JLS] I just went through the document again and made sure that I was = consistent. I am always using either "byte string" or "string". The = latter is used for text strings. I am not sure that=20 (I=E2=80=99m not sure what you wanted to say what you aren=E2=80=99t = sure of=E2=80=A6 The sentence didn=E2=80=99t finish.) I=E2=80=99m also in favor of being specific and saying =E2=80=9Cbyte = string=E2=80=9D or =E2=80=9Ctext string=E2=80=9D. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Dec 3 09:34:09 2019 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0170120873; Tue, 3 Dec 2019 09:34:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-cose-hash-sig@ietf.org, Ivaylo Petrov , cose-chairs@ietf.org, ivaylo@ackl.io, cose@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <157539444264.24883.4326110864105178269.idtracker@ietfa.amsl.com> Date: Tue, 03 Dec 2019 09:34:02 -0800 Archived-At: Subject: [COSE] Alissa Cooper's No Objection on draft-ietf-cose-hash-sig-07: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 17:34:03 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-cose-hash-sig-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-sig/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please respond to the Gen-ART review. I agree with the Gen-ART reviewer that the reference to the SUIT working group in Section 1.1 should be removed. From nobody Tue Dec 3 09:41:07 2019 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F44120077; Tue, 3 Dec 2019 09:41:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-cose-hash-sig@ietf.org, Ivaylo Petrov , cose-chairs@ietf.org, ivaylo@ackl.io, cose@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <157539486101.24700.12161503456212968239.idtracker@ietfa.amsl.com> Date: Tue, 03 Dec 2019 09:41:01 -0800 Archived-At: Subject: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-hash-sig-07: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2019 17:41:01 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-cose-hash-sig-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-sig/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I do see the previous discussion in https://mailarchive.ietf.org/arch/msg/cose/E6ApKPKlESQQSZwySJAVF1l27OE but I am still unclear on where exactly we can represent the octet string that is the HMS-LMS public key. Do we not need to define a COSE Key Type Parameter (i.e., label) that maps to the public key value? For reference, the examples in Appendix C.7.1 of RFC 8152 include key/value pairs with the negative map labels from https://www.iana.org/assignments/cose/cose.xhtml#key-type-parameters corresponding to the key type in question. Hopefully I'm just confused and missing where this is already done, but marking as a Discuss point in case I'm not. (The linked cose-wg/Examples seem to be using a JSON structure to describe the input to the example generation, with the "public" and "private" members of the "key" that do not seem to correspond to anything that I can find at https://www.iana.org/assignments/jose/jose.xhtml#web-key-parameters, and which would in any case not directly apply to the *COSE* usage.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Related to the above Discuss, should we have an explicit statement that we do not define a way to convey an HSS/LMS private key in a COSE_Key object? (I think it is correct to not define such a thing, since conveying a stateful private key is something of a non-sequitur.) It's not entirely clear to me how much of RFC 8554 we need to duplicate in order to give the reader an understanding of the signature structure we're using. A few times while reading Sections 2.x I had to double-check that I was reading the right document :) Section 1.1 If large-scale quantum computers are ever built, these computers will be able to break many of the public-key cryptosystems currently in use. A post-quantum cryptosystem [PQC] is a system that is secure against quantum computers that have more than a trivial number of quantum bits (qubits). It is open to conjecture when it will be (nit: they're also secure against quantum computers that do have a trivial number of bits. Yes, I know this is also true about classical signature algorithms with sufficiently large keys, but the text here is perhaps not making quite the point we want to make.) Since the HSS/LMS signature algorithm does not depend on the difficulty of discrete logarithm or factoring, the HSS/LMS signature algorithm is considered to be post-quantum secure. The use of HSS/ LMS hash-based signatures to protect software update distribution, perhaps using the format that is being specified by the IETF SUIT Working Group, will allow the deployment of software that implements new cryptosystems. In light of the genart reviewer's comments, we could recast this as "there is desire have HSS/LMS-based signatures available to protect software update distribution, including from the IETF SUIT Working Group" to place the focus on the desire, which is more easily fixed in time, rather than the WG output, which will change with time. Section 2.2 Each tree in the hash-based signature algorithm specified in [HASHSIG] uses the Leighton-Micali Signature (LMS) system. LMS systems have two parameters. The first parameter is the height of the tree, h, which is the number of levels in the tree minus one. I strongly suggest making it more clear that there are two (types of) trees involved -- the HSS tree of Section 2.1, and a tree within a given LMS signature (what's being discussed here). Just using an unadorned "the tree" is a recipe for confusion. The [HASHSIG] specification defines the value I as the private key identifier, and the same I value is used for all computations with the same LMS tree. In addition, the [HASHSIG] specification defines I think RFC 8554 uses I as the identifier for the key pair, not just the private key, and it seems that in the COSE context we are more likely to be referring to a public key than a private key. Section 2.3 n - The number of bytes output by the hash function. This specification supports only SHA-256 [SHS], with n=32. H - A preimage-resistant hash function that accepts byte strings of any length, and returns an n-byte string. This specification supports only SHA-256 [SHS]. Is supporting other n values basically just a matter of allocating from a registry? If so, we might want to tweak the wording a bit to leave the possibility for such a generalization. The LM-OTS signature value can be summarized as the identifier of the LM-OTS variant, the random value, and a sequence of hash values (y[0] through y[p-1]) that correspond to the elements of the public key as described in Section 4.5 of [HASHSIG]: nit: I'd consider a different wording than "correspond to"; the correspondence is a bit hard to describe clearly, but "hash values that include as input" (or similar) is IMO fairly clear. Section 3 o The 'kty' field MUST be present, and it MUST be 'HSS-LMS'. (Re. "MUST be present", I note that RFC 8152 already has """The element "kty" is a required element in a COSE_Key map.""" o If the 'alg' field is present, and it MUST be 'HSS-LMS'. nit: no "and". Section 5 To ensure that none of tree nodes are used to generate more than one signature, the signer maintains state across different invocations of the signing algorithm. Section 12.2 of [HASHSIG] offers some practical implementation approaches around this statefulness. In There is no Section 12.2 in RFC 8554; is perhaps Section 9.2 the intended one? From nobody Tue Dec 3 19:20:51 2019 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB3312009C; Tue, 3 Dec 2019 19:20:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-cose-hash-sig@ietf.org, Ivaylo Petrov , cose-chairs@ietf.org, ivaylo@ackl.io, cose@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <157542964857.4747.788853927600346605.idtracker@ietfa.amsl.com> Date: Tue, 03 Dec 2019 19:20:48 -0800 Archived-At: Subject: [COSE] Adam Roach's No Objection on draft-ietf-cose-hash-sig-07: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 03:20:48 -0000 Adam Roach has entered the following ballot position for draft-ietf-cose-hash-sig-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-sig/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the work that went into creating this document. I have no comments on its contents (the crypto is somewhat outside my area of expertise), although I have a few observations regarding the examples. --------------------------------------------------------------------------- Appendix A: > This appendix provides a non-normative example of a COSE full message > signature and an example of a COSE_Sign1 message. This section > follows the formatting used in [RFC8152]. I would suggest that RFC 8610 might be a better reference here, as it is the document that actually defines the extended CBOR diagnostic format. In particular my recommendation is: "This section is formatted according to the extended CBOR diagnostic format defined by [RFC8610]." --------------------------------------------------------------------------- §A.1: > 98( > [ > / protected / h'a10300' / { > \ content type \ 3:0 > } / , > / unprotected / {}, > / payload / 'This is the content.', > / signatures / [ > [ > / protected / h'a101382d' / { > \ alg \ 1:-46 \ HSS-LMS \ > } / , > / unprotected / { > / kid / 4:'ItsBig' > }, > / signature / ... > ] > ] > ] > ) I think there are two things here that need to be addressed. First, section 3 of this document specifies: > o The 'kty' field MUST be present, and it MUST be 'HSS-LMS'. I can't find a 'kty' field in this example. Also, this example uses '-46' as the identifier for HSS-LMS, while section 6.1 specifies the value as "TBD." This example needs a clear note added for the RFC editor that the "-46" needs to be replaced by the IANA-assigned value. A similar annotation will be required for the 'kty' field, regarding the value assigned for section 6.2. --------------------------------------------------------------------------- §A.2: Same comments as A.1, above. From nobody Tue Dec 3 20:25:38 2019 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4056412009C; Tue, 3 Dec 2019 20:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 lHts3GuJYZw2; Tue, 3 Dec 2019 20:25:34 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2DBE1200BA; Tue, 3 Dec 2019 20:25:33 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 3 Dec 2019 20:25:24 -0800 From: Jim Schaad To: 'Adam Roach' , 'The IESG' CC: , , , References: <157542964857.4747.788853927600346605.idtracker@ietfa.amsl.com> In-Reply-To: <157542964857.4747.788853927600346605.idtracker@ietfa.amsl.com> Date: Tue, 3 Dec 2019 20:25:22 -0800 Message-ID: <023901d5aa5a$da356a90$8ea03fb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLJl4L4+IlKlTlFLcKP3dTjjyF3v6XBhf/w Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Adam Roach's No Objection on draft-ietf-cose-hash-sig-07: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 04:25:36 -0000 -----Original Message----- From: COSE On Behalf Of Adam Roach via = Datatracker Sent: Tuesday, December 3, 2019 7:21 PM To: The IESG Cc: cose-chairs@ietf.org; ivaylo@ackl.io; cose@ietf.org; = draft-ietf-cose-hash-sig@ietf.org Subject: [COSE] Adam Roach's No Objection on = draft-ietf-cose-hash-sig-07: (with COMMENT) Adam Roach has entered the following ballot position for draft-ietf-cose-hash-sig-07: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-sig/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the work that went into creating this document. I have no = comments on its contents (the crypto is somewhat outside my area of = expertise), although I have a few observations regarding the examples. -------------------------------------------------------------------------= -- Appendix A: > This appendix provides a non-normative example of a COSE full message = =20 > signature and an example of a COSE_Sign1 message. This section =20 > follows the formatting used in [RFC8152]. I would suggest that RFC 8610 might be a better reference here, as it is = the document that actually defines the extended CBOR diagnostic format. In particular my recommendation is: "This section is formatted according to the extended CBOR diagnostic format defined by [RFC8610]." -------------------------------------------------------------------------= -- =C2=A7A.1: > 98( > [ > / protected / h'a10300' / { > \ content type \ 3:0 > } / , > / unprotected / {}, > / payload / 'This is the content.', > / signatures / [ > [ > / protected / h'a101382d' / { > \ alg \ 1:-46 \ HSS-LMS \ > } / , > / unprotected / { > / kid / 4:'ItsBig' > }, > / signature / ... > ] > ] > ] > ) I think there are two things here that need to be addressed. First, section 3 of this document specifies: > o The 'kty' field MUST be present, and it MUST be 'HSS-LMS'. I can't find a 'kty' field in this example. [JLS] The 'kty' field occurs in a COSE_Key and not in a COSE signed = message. This is expected. Also, this example uses '-46' as the identifier for HSS-LMS, while = section 6.1 specifies the value as "TBD." This example needs a clear = note added for the RFC editor that the "-46" needs to be replaced by the = IANA-assigned value. A similar annotation will be required for the 'kty' = field, regarding the value assigned for section 6.2. [JLS] The powers that be (me) have declared that -46 is going to be the = IANA-assigned value. Telling IANA to replace the "-46" with anything = else would require that the example be re-generated or the signature = would not verify. -------------------------------------------------------------------------= -- =C2=A7A.2: Same comments as A.1, above. _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose From nobody Wed Dec 4 08:17:56 2019 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19C412002E; Wed, 4 Dec 2019 08:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.773 X-Spam-Level: X-Spam-Status: No, score=-2.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.073, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=oIXd63DK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Hu3QdrgJ 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 SLQfNy-AVSlF; Wed, 4 Dec 2019 08:17:41 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E27AA120019; Wed, 4 Dec 2019 08:17:37 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 48BC022281; Wed, 4 Dec 2019 11:17:37 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 04 Dec 2019 11:17:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=8 w9K+FBmXQNQ23ajIlmOXlB5YVxzfFzeUFCdE7xKh6Q=; b=oIXd63DKJAiuQapji zxy/4hgdbfjoaAt/8e0GAdrmmK0KUTMKHeXzo6C+rkEs2vAAcK3OkQ/A5qHmMWTl +I3l1RDmdac/+mZSFmgZvVgAUrogILRgZlsK+uuGyWmLMqyasfFp1bnyUlX2Pdzg hmJWoA9zaQr2Uz3c3NZ2m4BjsDu2MrmJ1oliE/Xnaca8ySz7k6WuVxiEVJ6hOeqK wK3Hj3l6gVkb/2Q64ZiQhkAy6Naf7SCLp809ZCsGeMdpwzCBCr5eHKPWNMQUC5Z8 Gp6QytTTfWbajOt8CMP/4MuEDZCh7+ZHrTeHDd+ubgOzGbsYDYt5+46u3cDIhHeM qyQtQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=8w9K+FBmXQNQ23ajIlmOXlB5YVxzfFzeUFCdE7xKh 6Q=; b=Hu3QdrgJU+ieCq78mj/Y9v/PvnW8nzQ0Zg9V/KPRblM+THjyCIi7KFIEa 2B1PnK7DN46Ouzgo3FoXPlrcJmAIyY6gy5Mi00p+Fxuu1J+SiG0BWGT7Orud34qq gKh6AcfKZnOo+WvqzPbL2jGVkc12pzgmFcTvtA6HIUY0PJfIQTQpJiGUtWwQWc2N N0kYN8IlYv7GY2l4XpwR/03wbglkohEV2XcUHOMbvU3Cdt0xxbW3CKOx69E6eyKw 1MarxHPmJHKXwsiYwKlPwmMv52ZVB2xlyM5g88Du4V5EVXytkksY+9OAZUMgpCX5 IrFh4q41E65HEZQRVJezXkkuWp3Ew== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudejledgkeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedutdekrdehuddruddtuddrleeknecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsth gvrhfuihiivgeptd X-ME-Proxy: Received: from alcoop-m-c46z.fios-router.home (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (Postfix) with ESMTPA id 998CD80060; Wed, 4 Dec 2019 11:17:36 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <157230544744.16080.11317427545621451267@ietfa.amsl.com> Date: Wed, 4 Dec 2019 11:17:35 -0500 Cc: gen-art@ietf.org, last-call@ietf.org, draft-ietf-cose-hash-sig.all@ietf.org, cose@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <21E4C0CC-2C25-40FE-836B-98A06EE975DB@cooperw.in> References: <157230544744.16080.11317427545621451267@ietfa.amsl.com> To: Elwyn Davies X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [COSE] [Gen-art] Genart last call review of draft-ietf-cose-hash-sig-05 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 16:17:43 -0000 Elwyn, thanks for your review. I entered a No Objection ballot and = requested a response to your review. Alissa > On Oct 28, 2019, at 7:30 PM, Elwyn Davies via Datatracker = wrote: >=20 > Reviewer: Elwyn Davies > Review result: Almost Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-cose-hash-sig-05 > Reviewer: Elwyn Davies > Review Date: 2019-10-28 > IETF LC End Date: 2019-10-29 > IESG Telechat date: Not scheduled for a telechat > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > <" dir=3D"auto">https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;. >=20 > Document: draft-ietf-cose-hash-sig-05 > Reviewer: Elwyn Davies > Review Date: 2019/10/28 > IETF LC End Date: 2019/10/29 > IESG Telechat date: (if known) N/A >=20 > Summary: > Almost ready, There is one minor issue (barely above editorial) and a = number > of nits. I haven't checked the details of the HSS/LMS summary derived = from RFC > 8554 and I am taking the contents of the Appendix on trust! >=20 > Major issues: > None >=20 > Minor issues: > s1.1, last para: I found the note which provides particular = motivation for > this proposal rather obscure on first reading. After thinking about = it, I now > understand why this is here, but another sentence or so reinforcing = the idea > that getting the software distribution system post-quantum secure at = the > earlest opportunity is key to avoiding melt down should quantum = computing > develop more quickly than we might expect. Also referring to the = SUIT WG is > not future proof. >=20 > Nits/editorial comments: > s1, HASHSIG reference anchor: I would be inclined to stick with the = 'standard' > anchor for RFC 8554 i.e. [RFC8554]. >=20 > s1, para 2: Expand DSA, ECDSA and EdDSA on first use ( RSA is claimed = to be > well-known). Arguably references for the various mechanisms might be = desirable. >=20 > s2, last para: s/The the/The/ >=20 > s2 and subsections: The terminology and symbology used (e.g, || for > concatenation) are (I believe) those defined in RFC 8554. This should = be > mentioned. >=20 > s2.2, para 1: 'This specification supports only SHA-256': I think = this is a > cut-and-paste from RFC 8554. Suggest: s/This specification = supports/[RFC8554] > initially only supports/ and add at the end 'This specification would > automatically support any such additional hash functions.' >=20 > s4/s4.1: Rather than leaving an empty s4 and having a single = subsection > (generally frowned upon), the phraseology used at the start of s17 of = RFC 8152 > would be an improvement. >=20 > s4: The security considerations of RFCs 8152 and 8554 are also = relevant to > implementations of this specification. >=20 > s6: References to the relevant IANA registries for 'COSE Algrithms' = and 'COSE > Key Types' should be added. >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Dec 4 11:18:22 2019 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DEF12095A for ; Wed, 4 Dec 2019 11:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 dmwFgIPnZ1zE for ; Wed, 4 Dec 2019 11:18:20 -0800 (PST) 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 8C90A120961 for ; Wed, 4 Dec 2019 11:18:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CAAF5300B35 for ; Wed, 4 Dec 2019 14:09:56 -0500 (EST) 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 yiKdy9LQrJIU for ; Wed, 4 Dec 2019 14:09:53 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 5D8B0300464; Wed, 4 Dec 2019 14:09:53 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <023901d5aa5a$da356a90$8ea03fb0$@augustcellars.com> Date: Wed, 4 Dec 2019 14:09:53 -0500 Cc: IESG , cose-chairs@ietf.org, Ivaylo Petrov , cose , draft-ietf-cose-hash-sig@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4119C2E9-EFA8-4823-B6FF-F896CF97E8BE@vigilsec.com> References: <157542964857.4747.788853927600346605.idtracker@ietfa.amsl.com> <023901d5aa5a$da356a90$8ea03fb0$@augustcellars.com> To: Adam Roach X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [COSE] Adam Roach's No Objection on draft-ietf-cose-hash-sig-07: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 19:18:21 -0000 Adam: > Adam Roach has entered the following ballot position for > draft-ietf-cose-hash-sig-07: No Objection >=20 > When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cose-hash-sig/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for the work that went into creating this document. I have no = comments on its contents (the crypto is somewhat outside my area of = expertise), although I have a few observations regarding the examples. >=20 > = --------------------------------------------------------------------------= - >=20 > Appendix A: >=20 >> This appendix provides a non-normative example of a COSE full message = =20 >> signature and an example of a COSE_Sign1 message. This section =20 >> follows the formatting used in [RFC8152]. >=20 > I would suggest that RFC 8610 might be a better reference here, as it = is the document that actually defines the extended CBOR diagnostic = format. > In particular my recommendation is: >=20 > "This section is formatted according to the extended CBOR diagnostic > format defined by [RFC8610]." Sure. That works for me. >=20 > = --------------------------------------------------------------------------= - >=20 > =C2=A7A.1: >=20 >> 98( >> [ >> / protected / h'a10300' / { >> \ content type \ 3:0 >> } / , >> / unprotected / {}, >> / payload / 'This is the content.', >> / signatures / [ >> [ >> / protected / h'a101382d' / { >> \ alg \ 1:-46 \ HSS-LMS \ >> } / , >> / unprotected / { >> / kid / 4:'ItsBig' >> }, >> / signature / ... >> ] >> ] >> ] >> ) >=20 > I think there are two things here that need to be addressed. >=20 > First, section 3 of this document specifies: >=20 >> o The 'kty' field MUST be present, and it MUST be 'HSS-LMS'. >=20 > I can't find a 'kty' field in this example. >=20 > [JLS] The 'kty' field occurs in a COSE_Key and not in a COSE signed = message. This is expected. Is there a phrase other than "When using a COSE key for this algorithm" = that would be more helpful in Section 3? > Also, this example uses '-46' as the identifier for HSS-LMS, while = section 6.1 specifies the value as "TBD." This example needs a clear = note added for the RFC editor that the "-46" needs to be replaced by the = IANA-assigned value. A similar annotation will be required for the 'kty' = field, regarding the value assigned for section 6.2. >=20 > [JLS] The powers that be (me) have declared that -46 is going to be = the IANA-assigned value. Telling IANA to replace the "-46" with = anything else would require that the example be re-generated or the = signature would not verify. I suggest the addition of: {{{ RFC Editor: This example assumes that -46 will be assigned for the HSS-LMS algorithm. If another value is assigned, then the example needs to be regenerated. }}} >=20 > = --------------------------------------------------------------------------= - >=20 > =C2=A7A.2: >=20 > Same comments as A.1, above. And, I suggest the same note to the RFC Editor. Russ From nobody Wed Dec 4 12:08:22 2019 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BEA120947 for ; Wed, 4 Dec 2019 12:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 YBD2zgWUewt4 for ; Wed, 4 Dec 2019 12:08:21 -0800 (PST) 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 DCEF21200A3 for ; Wed, 4 Dec 2019 12:08:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0BBAA300B29 for ; Wed, 4 Dec 2019 15:01:45 -0500 (EST) 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 4DMd1D874Dec for ; Wed, 4 Dec 2019 15:01:42 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 54403300460; Wed, 4 Dec 2019 15:01:42 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <157230544744.16080.11317427545621451267@ietfa.amsl.com> Date: Wed, 4 Dec 2019 15:01:42 -0500 Cc: IETF Gen-ART , last-call@ietf.org, draft-ietf-cose-hash-sig.all@ietf.org, cose@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <351AF9D0-8D01-40F0-A861-AF6ED825C439@vigilsec.com> References: <157230544744.16080.11317427545621451267@ietfa.amsl.com> To: Elwyn Davies X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [COSE] Genart last call review of draft-ietf-cose-hash-sig-05 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 20:08:22 -0000 Elwyn: Thanks for the review. I missed the review when you posted it, but I = saw Alissa's recent reply to it. > Reviewer: Elwyn Davies > Review result: Almost Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-cose-hash-sig-05 > Reviewer: Elwyn Davies > Review Date: 2019-10-28 > IETF LC End Date: 2019-10-29 > IESG Telechat date: Not scheduled for a telechat > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > <" dir=3D"auto">https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;. >=20 > Document: draft-ietf-cose-hash-sig-05 > Reviewer: Elwyn Davies > Review Date: 2019/10/28 > IETF LC End Date: 2019/10/29 > IESG Telechat date: (if known) N/A >=20 > Summary: > Almost ready, There is one minor issue (barely above editorial) and a = number > of nits. I haven't checked the details of the HSS/LMS summary derived = from RFC > 8554 and I am taking the contents of the Appendix on trust! >=20 > Major issues: > None >=20 > Minor issues: > s1.1, last para: I found the note which provides particular = motivation for > this proposal rather obscure on first reading. After thinking about = it, I now > understand why this is here, but another sentence or so reinforcing = the idea > that getting the software distribution system post-quantum secure at = the > earlest opportunity is key to avoiding melt down should quantum = computing > develop more quickly than we might expect. Also referring to the = SUIT WG is > not future proof. I hope this resolved your concern: Since the HSS/LMS signature algorithm does not depend on the difficulty of discrete logarithm or factoring, the HSS/LMS signature algorithm is considered to be post-quantum secure. The use of HSS/ LMS hash-based signatures to protect software update distribution will allow the deployment of future software that implements new cryptosystems. By deploying HSS/LMS today, authentication and integrity protection of the future software can be provided, even if advances break current digital signature mechanisms. > Nits/editorial comments: > s1, HASHSIG reference anchor: I would be inclined to stick with the = 'standard' > anchor for RFC 8554 i.e. [RFC8554]. I guess this is taste. I find [HASHSIG] easier to read in many of the = places where RFC 8554 is referenced. > s1, para 2: Expand DSA, ECDSA and EdDSA on first use ( RSA is claimed = to be > well-known). Arguably references for the various mechanisms might be = desirable. All of these are well known digital signature algorithms. They only = appear as part of the motivation section; however, I will add = references. > s2, last para: s/The the/The/ Good catch. Thanks for the careful read. Corrected. > s2 and subsections: The terminology and symbology used (e.g, || for > concatenation) are (I believe) those defined in RFC 8554. This should = be > mentioned. At the first use, I added: where, the notation comes from [HASHSIG]. > s2.2, para 1: 'This specification supports only SHA-256': I think = this is a > cut-and-paste from RFC 8554. Suggest: s/This specification = supports/[RFC8554] > initially only supports/ and add at the end 'This specification would > automatically support any such additional hash functions.' I suggest: The [HASHSIG] specification supports only SHA-256, with m=3D32. An IANA registry is defined so that other hash = functions could be used in the future. > s4/s4.1: Rather than leaving an empty s4 and having a single = subsection > (generally frowned upon), the phraseology used at the start of s17 of = RFC 8152 > would be an improvement. Agreed. That is an improvement. > s4: The security considerations of RFCs 8152 and 8554 are also = relevant to > implementations of this specification. Agreed. I added a paragraph. > s6: References to the relevant IANA registries for 'COSE Algrithms' = and 'COSE > Key Types' should be added. Agreed. I added a reference to the IANA Registry page. Russ From nobody Wed Dec 4 13:06:41 2019 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE15412004C for ; Wed, 4 Dec 2019 13:06:39 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 2Ljb0VaRIB7f for ; Wed, 4 Dec 2019 13:06:38 -0800 (PST) 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 17C3C1200A3 for ; Wed, 4 Dec 2019 13:06:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 90403300B04 for ; Wed, 4 Dec 2019 16:06:36 -0500 (EST) 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 rJ-J_L-pqbZZ for ; Wed, 4 Dec 2019 16:06:33 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 871153005C5; Wed, 4 Dec 2019 16:06:33 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley X-Priority: 1 In-Reply-To: <619FB9BA-BDEB-4E31-BC04-DF265F27E51D@vigilsec.com> Date: Wed, 4 Dec 2019 16:06:34 -0500 Cc: Jim Schaad , IESG , cose Content-Transfer-Encoding: quoted-printable Message-Id: <559B8753-15F1-4C18-A604-686FD0A96215@vigilsec.com> References: <157539486101.24700.12161503456212968239.idtracker@ietfa.amsl.com> <619FB9BA-BDEB-4E31-BC04-DF265F27E51D@vigilsec.com> To: Ben Kaduk X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-hash-sig-07: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 21:06:40 -0000 Ben: I am trying to work with Jim Schaad on your DISCUSS comment. He has = done an implementation, so I'd like to get his insight. Turning to your comments ... >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Related to the above Discuss, should we have an explicit statement = that we do > not define a way to convey an HSS/LMS private key in a COSE_Key = object? > (I think it is correct to not define such a thing, since conveying a > stateful private key is something of a non-sequitur.) I agree that we do not want to define such a structure. I'm not sure = where to say anything about it. > It's not entirely clear to me how much of RFC 8554 we need to = duplicate > in order to give the reader an understanding of the signature = structure > we're using. A few times while reading Sections 2.x I had to > double-check that I was reading the right document :) I tried to achieve a balance. I wanted to have enough to understand = HSS, LMS, and LM-OTS. > Section 1.1 >=20 > If large-scale quantum computers are ever built, these computers will > be able to break many of the public-key cryptosystems currently in > use. A post-quantum cryptosystem [PQC] is a system that is secure > against quantum computers that have more than a trivial number of > quantum bits (qubits). It is open to conjecture when it will be >=20 > (nit: they're also secure against quantum computers that do have a > trivial number of bits. Yes, I know this is also true about classical > signature algorithms with sufficiently large keys, but the text here = is > perhaps not making quite the point we want to make.) I suggest: If large-scale quantum computers are ever built, these computers will have more than a trivial number of quantum bits (qubits) and they will be able to break many of the public-key cryptosystems currently in use. A post-quantum cryptosystem [PQC] is a system that is secure against against such large-scale quantum computers. It is open to conjecture when it will be feasible to build such computers; however, RSA [RFC8017], DSA [DSS], ECDSA [DSS], and EdDSA [RFC8032] are all vulnerable if large-scale quantum computers come to pass. > Since the HSS/LMS signature algorithm does not depend on the > difficulty of discrete logarithm or factoring, the HSS/LMS signature > algorithm is considered to be post-quantum secure. The use of HSS/ > LMS hash-based signatures to protect software update distribution, > perhaps using the format that is being specified by the IETF SUIT > Working Group, will allow the deployment of software that implements > new cryptosystems. >=20 > In light of the genart reviewer's comments, we could recast this as > "there is desire have HSS/LMS-based signatures available to protect > software update distribution, including from the IETF SUIT Working > Group" to place the focus on the desire, which is more easily fixed in > time, rather than the WG output, which will change with time. I suggest: Since the HSS/LMS signature algorithm does not depend on the difficulty of discrete logarithm or factoring, the HSS/LMS signature algorithm is considered to be post-quantum secure. The use of HSS/ LMS hash-based signatures to protect software update distribution will allow the deployment of future software that implements new cryptosystems. By deploying HSS/LMS today, authentication and integrity protection of the future software can be provided, even if advances break current digital signature mechanisms. > Section 2.2 >=20 > Each tree in the hash-based signature algorithm specified in > [HASHSIG] uses the Leighton-Micali Signature (LMS) system. LMS > systems have two parameters. The first parameter is the height of > the tree, h, which is the number of levels in the tree minus one. >=20 > I strongly suggest making it more clear that there are two (types of) > trees involved -- the HSS tree of Section 2.1, and a tree within a = given > LMS signature (what's being discussed here). Just using an unadorned > "the tree" is a recipe for confusion. Perhaps an introduction sentence is enough: Subordinate LMS trees are placed in the the HSS structure discussed in Section 2.1. Each tree in the hash-based signature algorithm specified in [HASHSIG] uses the Leighton-Micali Signature (LMS) system.=20 > The [HASHSIG] specification defines the value I as the private key > identifier, and the same I value is used for all computations with > the same LMS tree. In addition, the [HASHSIG] specification defines >=20 > I think RFC 8554 uses I as the identifier for the key pair, not just = the > private key, and it seems that in the COSE context we are more likely = to > be referring to a public key than a private key. Section 4.3 of RFC 8554 says that x, I, and q are taken from the private = key, so I think this text is accurate. To address your point, I suggest: The [HASHSIG] specification defines the value I as the private key identifier, and the same I value is used for all computations with the same LMS tree. The value I is also available in the public key. In addition, the [HASHSIG] specification defines the value T[i] as the m-byte string associated with the ith node in the LMS tree, where and the nodes are indexed from 1 to 2^(h+1)-1. Thus, T[1] is the m-byte string associated with the root of the LMS tree. > Section 2.3 >=20 > n - The number of bytes output by the hash function. This > specification supports only SHA-256 [SHS], with n=3D32. >=20 > H - A preimage-resistant hash function that accepts byte strings > of any length, and returns an n-byte string. This > specification supports only SHA-256 [SHS]. >=20 > Is supporting other n values basically just a matter of allocating = from > a registry? If so, we might want to tweak the wording a bit to leave > the possibility for such a generalization. Good point. I suggest: n - The number of bytes output by the hash function. For SHA-256 [SHS], n=3D32. H - A preimage-resistant hash function that accepts byte strings of any length, and returns an n-byte string. > The LM-OTS signature value can be summarized as the identifier of the > LM-OTS variant, the random value, and a sequence of hash values (y[0] > through y[p-1]) that correspond to the elements of the public key as > described in Section 4.5 of [HASHSIG]: >=20 > nit: I'd consider a different wording than "correspond to"; the > correspondence is a bit hard to describe clearly, but "hash values = that > include as input" (or similar) is IMO fairly clear. I suggest: The LM-OTS signature value can be summarized as the identifier of the LM-OTS variant, the random value, and a sequence of hash values (y[0] through y[p-1]) as described in Section 4.5 of [HASHSIG]: u32str(otstype) || C || y[0] || ... || y[p-1] > Section 3 >=20 > o The 'kty' field MUST be present, and it MUST be 'HSS-LMS'. >=20 > (Re. "MUST be present", I note that RFC 8152 already has """The = element > "kty" is a required element in a COSE_Key map.""" Yes, but the check is still needed. I suggest: o The 'kty' field MUST be 'HSS-LMS'. >=20 > o If the 'alg' field is present, and it MUST be 'HSS-LMS'. >=20 > nit: no "and". Fixed. > Section 5 >=20 > To ensure that none of tree nodes are used to generate more than one > signature, the signer maintains state across different invocations of > the signing algorithm. Section 12.2 of [HASHSIG] offers some > practical implementation approaches around this statefulness. In >=20 > There is no Section 12.2 in RFC 8554; is perhaps Section 9.2 the > intended one? Yes. Good Catch. Russ From nobody Wed Dec 4 13:28:17 2019 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1094E1200A3; Wed, 4 Dec 2019 13:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.399, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 3XmTBTjD8pZ4; Wed, 4 Dec 2019 13:28:15 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EF9F120033; Wed, 4 Dec 2019 13:28:15 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id xB4LS9lr023443 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 4 Dec 2019 15:28:11 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1575494892; bh=MM9nELHEMO2mieAAVBOILHzMUBcIdoQH30qrkYCptZs=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=B2ypqnW8vFeV3GlCtcpKt3y9BJkx+/Vx+YpAIMQPyxGfGU8g1tCAs7tzWciJTNkRe DrtRh7j99ns80CADV3wXvKk8cgGEOtNgo1dRtqwuTRB74AozJCJQaQRH/HCYAwqNf9 wRi++3vk0ynEiDOABG4MGoWyH8MgDcNfv+odeJ5Q= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Russ Housley Cc: IESG , cose-chairs@ietf.org, Ivaylo Petrov , cose , draft-ietf-cose-hash-sig@ietf.org References: <157542964857.4747.788853927600346605.idtracker@ietfa.amsl.com> <023901d5aa5a$da356a90$8ea03fb0$@augustcellars.com> <4119C2E9-EFA8-4823-B6FF-F896CF97E8BE@vigilsec.com> From: Adam Roach Message-ID: <6f2c8b6c-e637-6a8a-2848-fef926855ca7@nostrum.com> Date: Wed, 4 Dec 2019 15:28:04 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <4119C2E9-EFA8-4823-B6FF-F896CF97E8BE@vigilsec.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [COSE] Adam Roach's No Objection on draft-ietf-cose-hash-sig-07: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 21:28:16 -0000 On 12/4/19 1:09 PM, Russ Housley wrote: > >>> o The 'kty' field MUST be present, and it MUST be 'HSS-LMS'. >> I can't find a 'kty' field in this example. >> >> [JLS] The 'kty' field occurs in a COSE_Key and not in a COSE signed message. This is expected. > Is there a phrase other than "When using a COSE key for this algorithm" that would be more helpful in Section 3? Sorry, this was mostly me reading too quickly. You're probably fine with no change, although modifying the phrasing along the lines of "...the following checks are made on the key:" might be slightly clearer. > >> Also, this example uses '-46' as the identifier for HSS-LMS, while section 6.1 specifies the value as "TBD." This example needs a clear note added for the RFC editor that the "-46" needs to be replaced by the IANA-assigned value. A similar annotation will be required for the 'kty' field, regarding the value assigned for section 6.2. >> >> [JLS] The powers that be (me) have declared that -46 is going to be the IANA-assigned value. Telling IANA to replace the "-46" with anything else would require that the example be re-generated or the signature would not verify. > I suggest the addition of: > > {{{ RFC Editor: This example assumes that -46 will be assigned for > the HSS-LMS algorithm. If another value is assigned, then the > example needs to be regenerated. }}} This sounds good to me. I've seen other i-ds do something like the following, which seems helpful (in addition to the note above):       Value:  TBD (Value between -256 and 255 to be assigned by IANA, with -46 preferred) /a From nobody Wed Dec 4 14:50:45 2019 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA8112004E for ; Wed, 4 Dec 2019 14:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 KARQz47EgUj5 for ; Wed, 4 Dec 2019 14:50:37 -0800 (PST) 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 E1449120046 for ; Wed, 4 Dec 2019 14:50:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4DAD2300ADB for ; Wed, 4 Dec 2019 17:50:35 -0500 (EST) 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 dT_4fn6ZjT-a for ; Wed, 4 Dec 2019 17:50:33 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 3092C3004B0; Wed, 4 Dec 2019 17:50:33 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <157539486101.24700.12161503456212968239.idtracker@ietfa.amsl.com> Date: Wed, 4 Dec 2019 17:50:33 -0500 Cc: IESG , cose-chairs@ietf.org, cose Content-Transfer-Encoding: 7bit Message-Id: <53448421-CFA3-49D1-88CE-92D759E8D825@vigilsec.com> References: <157539486101.24700.12161503456212968239.idtracker@ietfa.amsl.com> To: Ben Kaduk X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-hash-sig-07: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 22:50:39 -0000 Ben: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I do see the previous discussion in > https://mailarchive.ietf.org/arch/msg/cose/E6ApKPKlESQQSZwySJAVF1l27OE > but I am still unclear on where exactly we can represent the octet > string that is the HMS-LMS public key. Do we not need to define a COSE > Key Type Parameter (i.e., label) that maps to the public key value? For > reference, the examples in Appendix C.7.1 of RFC 8152 include key/value > pairs with the negative map labels from > https://www.iana.org/assignments/cose/cose.xhtml#key-type-parameters > corresponding to the key type in question. > Hopefully I'm just confused and missing where this is already done, but > marking as a Discuss point in case I'm not. (The linked > cose-wg/Examples seem to be using a JSON structure to describe the input > to the example generation, with the "public" and "private" members of > the "key" that do not seem to correspond to anything that I can find at > https://www.iana.org/assignments/jose/jose.xhtml#web-key-parameters, and > which would in any case not directly apply to the *COSE* usage.) I suggest: 6.3. COSE Key Type Parameters Registry Entry The new entry in the "COSE Key Type Parameters" registry [IANA] has the following columns: Key Type: TBD (Value to be assigned above by IANA) Name: pub Label: TBD (Value to be assigned by IANA) CBOR Type: bstr Description: Public key for HSS/LMS hash-based digital signature Reference: This document (Number to be assigned by RFC Editor) Russ From nobody Wed Dec 4 14:52:39 2019 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81020120033; Wed, 4 Dec 2019 14:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 yFT5Wttf_-u2; Wed, 4 Dec 2019 14:52:35 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AD3B12002F; Wed, 4 Dec 2019 14:52:35 -0800 (PST) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xB4MqUXx016101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 4 Dec 2019 17:52:33 -0500 Date: Wed, 4 Dec 2019 14:52:29 -0800 From: Benjamin Kaduk To: Russ Housley Cc: IESG , cose-chairs@ietf.org, cose Message-ID: <20191204225229.GU32847@mit.edu> References: <157539486101.24700.12161503456212968239.idtracker@ietfa.amsl.com> <53448421-CFA3-49D1-88CE-92D759E8D825@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53448421-CFA3-49D1-88CE-92D759E8D825@vigilsec.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-hash-sig-07: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 22:52:37 -0000 On Wed, Dec 04, 2019 at 05:50:33PM -0500, Russ Housley wrote: > Ben: > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I do see the previous discussion in > > https://mailarchive.ietf.org/arch/msg/cose/E6ApKPKlESQQSZwySJAVF1l27OE > > but I am still unclear on where exactly we can represent the octet > > string that is the HMS-LMS public key. Do we not need to define a COSE > > Key Type Parameter (i.e., label) that maps to the public key value? For > > reference, the examples in Appendix C.7.1 of RFC 8152 include key/value > > pairs with the negative map labels from > > https://www.iana.org/assignments/cose/cose.xhtml#key-type-parameters > > corresponding to the key type in question. > > Hopefully I'm just confused and missing where this is already done, but > > marking as a Discuss point in case I'm not. (The linked > > cose-wg/Examples seem to be using a JSON structure to describe the input > > to the example generation, with the "public" and "private" members of > > the "key" that do not seem to correspond to anything that I can find at > > https://www.iana.org/assignments/jose/jose.xhtml#web-key-parameters, and > > which would in any case not directly apply to the *COSE* usage.) > > I suggest: > > 6.3. COSE Key Type Parameters Registry Entry > > The new entry in the "COSE Key Type Parameters" registry [IANA] has > the following columns: > > Key Type: TBD (Value to be assigned above by IANA) > > Name: pub > > Label: TBD (Value to be assigned by IANA) > > CBOR Type: bstr > > Description: Public key for HSS/LMS hash-based digital signature > > Reference: This document (Number to be assigned by RFC Editor) That's basically what I had in mind; thanks! (We could perhaps number the different TBDs but this case is not too complicated...) -Ben From nobody Wed Dec 4 15:45:26 2019 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C416812002F; Wed, 4 Dec 2019 15:45:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cose@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cose@ietf.org Message-ID: <157550312272.11194.12272670589255910709@ietfa.amsl.com> Date: Wed, 04 Dec 2019 15:45:22 -0800 Archived-At: Subject: [COSE] I-D Action: draft-ietf-cose-hash-sig-08.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 23:45:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CBOR Object Signing and Encryption WG of the IETF. Title : Use of the HSS/LMS Hash-based Signature Algorithm with CBOR Object Signing and Encryption (COSE) Author : Russ Housley Filename : draft-ietf-cose-hash-sig-08.txt Pages : 17 Date : 2019-12-04 Abstract: This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the CBOR Object Signing and Encryption (COSE) syntax. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-sig/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cose-hash-sig-08 https://datatracker.ietf.org/doc/html/draft-ietf-cose-hash-sig-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-hash-sig-08 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 4 23:32:50 2019 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C8B1200F4; Wed, 4 Dec 2019 23:32:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-cose-hash-sig@ietf.org, Ivaylo Petrov , cose-chairs@ietf.org, ivaylo@ackl.io, cose@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <157553116442.11236.17631232365457660.idtracker@ietfa.amsl.com> Date: Wed, 04 Dec 2019 23:32:44 -0800 Archived-At: Subject: [COSE] Benjamin Kaduk's Yes on draft-ietf-cose-hash-sig-08: (with COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 07:32:44 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-cose-hash-sig-08: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-sig/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my Discuss and comment points! From nobody Thu Dec 5 07:13:13 2019 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEAF120019 for ; Thu, 5 Dec 2019 07:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PDS_TONAME_EQ_TOLOCAL_SHORT=1.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.20150623.gappssmtp.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 ukJpkQ6T_IBj for ; Thu, 5 Dec 2019 07:13:11 -0800 (PST) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EC09120013 for ; Thu, 5 Dec 2019 07:13:11 -0800 (PST) Received: by mail-ot1-x333.google.com with SMTP id o9so2896112ote.2 for ; Thu, 05 Dec 2019 07:13:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=to:from:subject:openpgp:autocrypt:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=WRCSmwNEBh7aHIohHMh0DXBFJfVSu5DdvUcSBkktUE4=; b=fBijcBw8Drq7NKr2AuvtWRtJ/ZtPTmT+3Iv50iPm6j8fCiuangWt6I7bUXQ3pQGE/b jXKvW7ut3dYvLBELSuSmAiPu4eWvo+bRTO6Ol4Eo3dTdgbMvs7im9JiB1C6vTCAXY5kc X1ImZdUBo8SvCsao08GYUXc8sriBneqbcdEHNtvCdqe2aMOOasFcNbA/n7nPuTMDqwmI NSiWyfOi+E4i5SbBcl+d8px1KOlTsoeDyyPlpX2848MtYvEvx9Q+Moyk9rHNZ/ShnLDM 2f2VqZnU+BYi4uSLXGMWXcdEU1781G8CMyQ+ZGrjn4NY+PLC1LdwXSjpENVQoBdtY4xj 0L2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:openpgp:autocrypt:message-id :date:user-agent:mime-version:content-language :content-transfer-encoding; bh=WRCSmwNEBh7aHIohHMh0DXBFJfVSu5DdvUcSBkktUE4=; b=oajBv8QUAwMHPWNh2CDjL83MxCEqRbuyl+pOjZGhh7Tgz+wkqd9VyQnwFpmUJ0xp23 AVU88g+pOGN+g6lmWSmtowDsYJeUxHaPXbbBPfMBeT++w8vNldVOTrPGooxNiVQeg4Rx muJD+tgPQAMtXBgKR52qvbNr6sNA7i42zEkQ/vvRxQdVScQhHWjmde82MNhH1Nh7QQeR RKvzzaVTkS0kuJLmoIwNYEYB+8i/tROVRDOtTB4CHCll14OTJDoCpzy5bKd5A+F0bnFj 5bfB5bKycn2vpkHnIDlIdJRE5xLYg0cCHjlFloGTCgvyQL+ePxQeyF2aTdK56V5H1xpn OQ8g== X-Gm-Message-State: APjAAAWfaaGqGyL9hbwU3A/BX6/8PzoVksjsvZH/Y2dd4nEXg2eLslyW s1UaYpkfJTezkOn9Tr3BmjalKROkE2tMqw== X-Google-Smtp-Source: APXvYqy1uIwG0pbxxQ2XQeYCk2WDZPsnE5pfDeXioWoZbH9PkxSgUvewiSJjobpX69Mrj/qCghl0/Q== X-Received: by 2002:a9d:5885:: with SMTP id x5mr6620425otg.132.1575558790285; Thu, 05 Dec 2019 07:13:10 -0800 (PST) Received: from mmiller-44677.local ([207.126.127.114]) by smtp.gmail.com with ESMTPSA id n16sm3425961otk.25.2019.12.05.07.13.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Dec 2019 07:13:09 -0800 (PST) To: cose From: "Matthew A. Miller" Openpgp: preference=signencrypt Autocrypt: addr=linuxwolf+ietf@outer-planes.net; prefer-encrypt=mutual; keydata= mQENBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAG0M01hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGYraWV0ZkBvdXRlci1wbGFuZXMubmV0 PokBPQQTAQoAJwUCWKsJ1AIbAwUJC8ckMQULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRDs 9HJOEJ4Fu1iBCADAcW06d/7GTlBjTlYuMGgjzDBoWeQ9/zxgMnSrgNb6yO7wHzE65CeFs6OI 6LQ4A34CNM3hhcWDIzlqrV25fVyy7qCh6bCNMs1pOT63+Od4kcjHtUnGGTONT5fXSGY7mCtl XJFjb3TwyLUZXQCifhCIaUdF/4SVoGk96W9ssbDKN+5xq7B7gyVkwB0WM67zxt/kC6TPcXXL 5m7jsNRpRmFQqOlIF+HrQAcSr1lKRWgetb1VHfXCgcmDaTKn1QC7s0Ml+27dc0SoIkBI8cnv inJ4oFYWrvnTlOvv+v8AFXZnPrxZ/JYvnVD/y5PX7v08Z8RFXm1AmVxIWjXPI6TySkGvuQEN BFJoAooBCADA/ruHwYlQ7pdjJY6twkZcMmedkQNL6r5tNBeQkwVrvitUjHTKKipjxB2kEkUZ oxPgMI1h7/enDrVlMMMqq6RIJ86H+yx13zNIZNBlJfmVHgHj7TT8spa6A/qIccdiIRNsFVvl vFxpH8sTjVbHfPYexbdOR5kHpZWTzYxNyVLXMK5jen0B4K+vjbgFJAvsoLfzLZ5Bz3kb6dpu xUNzqhDyhk5/UPaCIFvZWBtiRKmkqPwEq8G2aMJq5Z4Sr8CRkpoMB25rxCPS8R+ByiHxpq+U 8mKuqPVg1LJzcA7hHmms8aBN6lxSlbyKnzEg8AWgld+6+xlJXu5U/fqDAClTj5mfABEBAAGJ ATwEGAEKACYCGwwWIQQx11iN7JBpDWvMmODs9HJOEJ4FuwUCWm+kiwUJC8tagQAKCRDs9HJO EJ4Fu40cB/9xyEnuQegivmL6OBVG5HvUAaXGUxtWiWdLm3NrduL0h7rctF060xQTekNRCjbl xZ1w/unPDBEEIMPYbF8i7IwJZoRLTG1B1MjI04AUU60G0IU6uw0ST6IsC7oYGvhDNJApbVBb j9u9x+kzaktCftl3qdpSKgRh9McIyZgevuFBdo80RDtX8niktUA3xsfJWBD1yJA33UNSzqOe 54wFRbsM2+4erREPMD659h2lACPCXjPW/6ucnv0/cdPF8V2JNMCT0yPJVCSUfFLTrtyYtiRI 6S52cI4eEOZIXCQp30TA4E27O2mMLOYzlKA5P5T+Icf4gz8e/puNUKIBDlY6KF7p Message-ID: <9a011fff-36da-47cd-e604-1d029e0b2392@outer-planes.net> Date: Thu, 5 Dec 2019 08:13:09 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [COSE] Minutes from IETF 106 Session X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 15:13:12 -0000 Hello WG, The draft minutes from our session at IETF 106 are in Datatracker: < https://datatracker.ietf.org/meeting/106/materials/minutes-106-cose-00.txt > Please send any corrections to the chairs or this list. Thank you, - Ivaylo and Matthew COSE WG Chairs From nobody Thu Dec 5 14:18:23 2019 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E731201A3; Thu, 5 Dec 2019 14:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 kR1fxcZmyZWx; Thu, 5 Dec 2019 14:18:15 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08F03120168; Thu, 5 Dec 2019 14:18:14 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xB5MI6eW029406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 5 Dec 2019 17:18:09 -0500 Date: Thu, 5 Dec 2019 14:18:06 -0800 From: Benjamin Kaduk To: Russ Housley Cc: Jim Schaad , IESG , cose Message-ID: <20191205221806.GH13890@kduck.mit.edu> References: <157539486101.24700.12161503456212968239.idtracker@ietfa.amsl.com> <619FB9BA-BDEB-4E31-BC04-DF265F27E51D@vigilsec.com> <559B8753-15F1-4C18-A604-686FD0A96215@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <559B8753-15F1-4C18-A604-686FD0A96215@vigilsec.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-hash-sig-07: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 22:18:17 -0000 Hi Russ, On Wed, Dec 04, 2019 at 04:06:34PM -0500, Russ Housley wrote: > Ben: > > I am trying to work with Jim Schaad on your DISCUSS comment. He has done an implementation, so I'd like to get his insight. As it happens, I had had the same thought, so I expect he had the answer at hand for you :) > Turning to your comments ... > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Related to the above Discuss, should we have an explicit statement that we do > > not define a way to convey an HSS/LMS private key in a COSE_Key object? > > (I think it is correct to not define such a thing, since conveying a > > stateful private key is something of a non-sequitur.) > > I agree that we do not want to define such a structure. I'm not sure where to say anything about it. The best place I can see is in Section 5 (Operational Considerations), as something like "Because of the need to maintain state across invocations of the signing algorithm, a COSE Key Type Parameter for encoding the private key (and its state) is deliberately not defined; serializing the state for conveyance presents too great a risk of state reuse to justify any potential benefit from doing so." > > It's not entirely clear to me how much of RFC 8554 we need to duplicate > > in order to give the reader an understanding of the signature structure > > we're using. A few times while reading Sections 2.x I had to > > double-check that I was reading the right document :) > > I tried to achieve a balance. I wanted to have enough to understand HSS, LMS, and LM-OTS. Understood, and I'm deferring to you on judging the balance. > > Section 1.1 > > > > If large-scale quantum computers are ever built, these computers will > > be able to break many of the public-key cryptosystems currently in > > use. A post-quantum cryptosystem [PQC] is a system that is secure > > against quantum computers that have more than a trivial number of > > quantum bits (qubits). It is open to conjecture when it will be > > > > (nit: they're also secure against quantum computers that do have a > > trivial number of bits. Yes, I know this is also true about classical > > signature algorithms with sufficiently large keys, but the text here is > > perhaps not making quite the point we want to make.) > > I suggest: > > If large-scale quantum computers are ever built, these computers will > have more than a trivial number of quantum bits (qubits) and they > will be able to break many of the public-key cryptosystems currently > in use. A post-quantum cryptosystem [PQC] is a system that is secure > against against such large-scale quantum computers. It is open to > conjecture when it will be feasible to build such computers; however, > RSA [RFC8017], DSA [DSS], ECDSA [DSS], and EdDSA [RFC8032] are all > vulnerable if large-scale quantum computers come to pass. A nice solution; thanks! > > Since the HSS/LMS signature algorithm does not depend on the > > difficulty of discrete logarithm or factoring, the HSS/LMS signature > > algorithm is considered to be post-quantum secure. The use of HSS/ > > LMS hash-based signatures to protect software update distribution, > > perhaps using the format that is being specified by the IETF SUIT > > Working Group, will allow the deployment of software that implements > > new cryptosystems. > > > > In light of the genart reviewer's comments, we could recast this as > > "there is desire have HSS/LMS-based signatures available to protect > > software update distribution, including from the IETF SUIT Working > > Group" to place the focus on the desire, which is more easily fixed in > > time, rather than the WG output, which will change with time. > > I suggest: > > Since the HSS/LMS signature algorithm does not depend on the > difficulty of discrete logarithm or factoring, the HSS/LMS signature > algorithm is considered to be post-quantum secure. The use of HSS/ > LMS hash-based signatures to protect software update distribution > will allow the deployment of future software that implements new > cryptosystems. By deploying HSS/LMS today, authentication and > integrity protection of the future software can be provided, even if > advances break current digital signature mechanisms. > > > Section 2.2 > > > > Each tree in the hash-based signature algorithm specified in > > [HASHSIG] uses the Leighton-Micali Signature (LMS) system. LMS > > systems have two parameters. The first parameter is the height of > > the tree, h, which is the number of levels in the tree minus one. > > > > I strongly suggest making it more clear that there are two (types of) > > trees involved -- the HSS tree of Section 2.1, and a tree within a given > > LMS signature (what's being discussed here). Just using an unadorned > > "the tree" is a recipe for confusion. > > Perhaps an introduction sentence is enough: > > Subordinate LMS trees are placed in the the HSS structure discussed > in Section 2.1. Each tree in the hash-based signature algorithm > specified in [HASHSIG] uses the Leighton-Micali Signature (LMS) > system. It seems to be, yes. > > The [HASHSIG] specification defines the value I as the private key > > identifier, and the same I value is used for all computations with > > the same LMS tree. In addition, the [HASHSIG] specification defines > > > > I think RFC 8554 uses I as the identifier for the key pair, not just the > > private key, and it seems that in the COSE context we are more likely to > > be referring to a public key than a private key. > > Section 4.3 of RFC 8554 says that x, I, and q are taken from the private key, so I think this text is accurate. > > To address your point, I suggest: > > The [HASHSIG] specification defines the value I as the private key > identifier, and the same I value is used for all computations with > the same LMS tree. The value I is also available in the public key. > In addition, the [HASHSIG] specification defines the value T[i] as > the m-byte string associated with the ith node in the LMS tree, where > and the nodes are indexed from 1 to 2^(h+1)-1. Thus, T[1] is the > m-byte string associated with the root of the LMS tree. > > > > Section 2.3 > > > > n - The number of bytes output by the hash function. This > > specification supports only SHA-256 [SHS], with n=32. > > > > H - A preimage-resistant hash function that accepts byte strings > > of any length, and returns an n-byte string. This > > specification supports only SHA-256 [SHS]. > > > > Is supporting other n values basically just a matter of allocating from > > a registry? If so, we might want to tweak the wording a bit to leave > > the possibility for such a generalization. > > Good point. I suggest: > > n - The number of bytes output by the hash function. For > SHA-256 [SHS], n=32. > > H - A preimage-resistant hash function that accepts byte strings > of any length, and returns an n-byte string. > > > The LM-OTS signature value can be summarized as the identifier of the > > LM-OTS variant, the random value, and a sequence of hash values (y[0] > > through y[p-1]) that correspond to the elements of the public key as > > described in Section 4.5 of [HASHSIG]: > > > > nit: I'd consider a different wording than "correspond to"; the > > correspondence is a bit hard to describe clearly, but "hash values that > > include as input" (or similar) is IMO fairly clear. > > I suggest: > > The LM-OTS signature value can be summarized as the identifier of the > LM-OTS variant, the random value, and a sequence of hash values (y[0] > through y[p-1]) as described in Section 4.5 of [HASHSIG]: > > u32str(otstype) || C || y[0] || ... || y[p-1] > > > Section 3 > > > > o The 'kty' field MUST be present, and it MUST be 'HSS-LMS'. > > > > (Re. "MUST be present", I note that RFC 8152 already has """The element > > "kty" is a required element in a COSE_Key map.""" > > Yes, but the check is still needed. I suggest: > > o The 'kty' field MUST be 'HSS-LMS'. > > > > > o If the 'alg' field is present, and it MUST be 'HSS-LMS'. > > > > nit: no "and". > > Fixed. > > > Section 5 > > > > To ensure that none of tree nodes are used to generate more than one > > signature, the signer maintains state across different invocations of > > the signing algorithm. Section 12.2 of [HASHSIG] offers some > > practical implementation approaches around this statefulness. In > > > > There is no Section 12.2 in RFC 8554; is perhaps Section 9.2 the > > intended one? > > Yes. Good Catch. Thanks for all the updates! -Ben From nobody Fri Dec 6 09:27:04 2019 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09CB120110 for ; Fri, 6 Dec 2019 09:27:02 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 i6JAp6Dyt5mB for ; Fri, 6 Dec 2019 09:27:01 -0800 (PST) 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 5C3501200FE for ; Fri, 6 Dec 2019 09:27:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 84FB8300B06 for ; Fri, 6 Dec 2019 12:26:59 -0500 (EST) 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 IU5vuCpqVzRX for ; Fri, 6 Dec 2019 12:26:57 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id BBFCC300AA0; Fri, 6 Dec 2019 12:26:57 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <20191205221806.GH13890@kduck.mit.edu> Date: Fri, 6 Dec 2019 12:26:58 -0500 Cc: IESG , Jim Schaad , cose Content-Transfer-Encoding: quoted-printable Message-Id: <4A8E2FA1-C98D-45C3-B0F1-FF2B9FF056A0@vigilsec.com> References: <157539486101.24700.12161503456212968239.idtracker@ietfa.amsl.com> <619FB9BA-BDEB-4E31-BC04-DF265F27E51D@vigilsec.com> <559B8753-15F1-4C18-A604-686FD0A96215@vigilsec.com> <20191205221806.GH13890@kduck.mit.edu> To: Ben Kaduk X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-hash-sig-07: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2019 17:27:03 -0000 Ben: Trimming to the one unresolved comment... >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> Related to the above Discuss, should we have an explicit statement = that we do >>> not define a way to convey an HSS/LMS private key in a COSE_Key = object? >>> (I think it is correct to not define such a thing, since conveying a >>> stateful private key is something of a non-sequitur.) >>=20 >> I agree that we do not want to define such a structure. I'm not sure = where to say anything about it. >=20 > The best place I can see is in Section 5 (Operational Considerations), = as > something like "Because of the need to maintain state across = invocations of > the signing algorithm, a COSE Key Type Parameter for encoding the = private > key (and its state) is deliberately not defined; serializing the state = for > conveyance presents too great a risk of state reuse to justify any > potential benefit from doing so." I suggest: A COSE Key Type Parameter for encoding the HSS/LMS private key and the state about which tree nodes have been used is deliberately not defined. It was not defined to avoid creating the ability to save the private key and state, generate one or more signatures, and then restore the private key and state. Such a restoration operation provides disastrous opportunities for tree node reuse. Russ From nobody Tue Dec 10 18:06:47 2019 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BF6120086; Tue, 10 Dec 2019 18:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 V0tfkggIfUGT; Tue, 10 Dec 2019 18:06:40 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CFF1120059; Tue, 10 Dec 2019 18:06:40 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBB26XGW030420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Dec 2019 21:06:35 -0500 Date: Tue, 10 Dec 2019 18:06:32 -0800 From: Benjamin Kaduk To: Russ Housley Cc: IESG , Jim Schaad , cose Message-ID: <20191211020632.GY13890@kduck.mit.edu> References: <157539486101.24700.12161503456212968239.idtracker@ietfa.amsl.com> <619FB9BA-BDEB-4E31-BC04-DF265F27E51D@vigilsec.com> <559B8753-15F1-4C18-A604-686FD0A96215@vigilsec.com> <20191205221806.GH13890@kduck.mit.edu> <4A8E2FA1-C98D-45C3-B0F1-FF2B9FF056A0@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A8E2FA1-C98D-45C3-B0F1-FF2B9FF056A0@vigilsec.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-hash-sig-07: (with DISCUSS and COMMENT) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 02:06:42 -0000 Hi Russ, On Fri, Dec 06, 2019 at 12:26:58PM -0500, Russ Housley wrote: > Ben: > > Trimming to the one unresolved comment... > > >>> ---------------------------------------------------------------------- > >>> COMMENT: > >>> ---------------------------------------------------------------------- > >>> > >>> Related to the above Discuss, should we have an explicit statement that we do > >>> not define a way to convey an HSS/LMS private key in a COSE_Key object? > >>> (I think it is correct to not define such a thing, since conveying a > >>> stateful private key is something of a non-sequitur.) > >> > >> I agree that we do not want to define such a structure. I'm not sure where to say anything about it. > > > > The best place I can see is in Section 5 (Operational Considerations), as > > something like "Because of the need to maintain state across invocations of > > the signing algorithm, a COSE Key Type Parameter for encoding the private > > key (and its state) is deliberately not defined; serializing the state for > > conveyance presents too great a risk of state reuse to justify any > > potential benefit from doing so." > > I suggest: > > A COSE Key Type Parameter for encoding the HSS/LMS private key and > the state about which tree nodes have been used is deliberately not > defined. It was not defined to avoid creating the ability to save > the private key and state, generate one or more signatures, and then > restore the private key and state. Such a restoration operation > provides disastrous opportunities for tree node reuse. That works for me; thanks! -Ben From nobody Wed Dec 11 07:58:03 2019 Return-Path: X-Original-To: cose@ietf.org Delivered-To: cose@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8C31200D6; Wed, 11 Dec 2019 07:57:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cose@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cose@ietf.org Message-ID: <157607987677.11412.13863658082589708483@ietfa.amsl.com> Date: Wed, 11 Dec 2019 07:57:56 -0800 Archived-At: Subject: [COSE] I-D Action: draft-ietf-cose-hash-sig-09.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 15:57:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CBOR Object Signing and Encryption WG of the IETF. Title : Use of the HSS/LMS Hash-based Signature Algorithm with CBOR Object Signing and Encryption (COSE) Author : Russ Housley Filename : draft-ietf-cose-hash-sig-09.txt Pages : 17 Date : 2019-12-11 Abstract: This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the CBOR Object Signing and Encryption (COSE) syntax. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-hash-sig/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cose-hash-sig-09 https://datatracker.ietf.org/doc/html/draft-ietf-cose-hash-sig-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-hash-sig-09 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 11 07:59:06 2019 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408D912086E for ; Wed, 11 Dec 2019 07:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 8cZj1iCrM7EL for ; Wed, 11 Dec 2019 07:59:02 -0800 (PST) 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 84BBC1200D6 for ; Wed, 11 Dec 2019 07:59:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0C642300B05 for ; Wed, 11 Dec 2019 10:59:01 -0500 (EST) 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 Cv-Y6LyZaujD for ; Wed, 11 Dec 2019 10:58:59 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 850D1300474 for ; Wed, 11 Dec 2019 10:58:59 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 11 Dec 2019 10:59:00 -0500 References: <157607987677.11412.13863658082589708483@ietfa.amsl.com> To: cose In-Reply-To: <157607987677.11412.13863658082589708483@ietfa.amsl.com> Message-Id: <36DF8345-51FF-4E9B-9DAC-2D276EE61A6B@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [COSE] I-D Action: draft-ietf-cose-hash-sig-09.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 15:59:04 -0000 This update resolves the last of the comments from IESG Evaluation. Russ > On Dec 11, 2019, at 10:57 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the CBOR Object Signing and Encryption WG = of the IETF. >=20 > Title : Use of the HSS/LMS Hash-based Signature = Algorithm with CBOR Object Signing and Encryption (COSE) > Author : Russ Housley > Filename : draft-ietf-cose-hash-sig-09.txt > Pages : 17 > Date : 2019-12-11 >=20 > Abstract: > This document specifies the conventions for using the Hierarchical > Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based > signature algorithm with the CBOR Object Signing and Encryption > (COSE) syntax. The HSS/LMS algorithm is one form of hash-based > digital signature; it is described in RFC 8554. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cose-hash-sig/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-cose-hash-sig-09 > https://datatracker.ietf.org/doc/html/draft-ietf-cose-hash-sig-09 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cose-hash-sig-09 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Wed Dec 11 22:27:54 2019 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26901200FF for ; Wed, 11 Dec 2019 22:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=myidemia.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 gro_xoz5ZmAg for ; Wed, 11 Dec 2019 22:27:50 -0800 (PST) Received: from mx07-0018b601.pphosted.com (mx07-0018b601.pphosted.com [185.132.180.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F6DD1200FD for ; Wed, 11 Dec 2019 22:27:49 -0800 (PST) Received: from pps.filterd (m0136514.ppops.net [127.0.0.1]) by mx08-0018b601.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xBC6DJp5020144; Thu, 12 Dec 2019 06:27:46 GMT Received: from eur03-am5-obe.outbound.protection.outlook.com (mail-am5eur03lp2053.outbound.protection.outlook.com [104.47.8.53]) by mx08-0018b601.pphosted.com with ESMTP id 2wr45bdvfk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 Dec 2019 06:27:45 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b+kCgnc4vpD+BkBnRJZCeDR1Bwfe55M/+CrNoxX0f/lHcoZe5KMutwG2aITYwX826OlpwT/O8/ZycPEAAtiScOhdR00P1pXSXTvoh63AH53bTP3m2VE9eidsg2dvH6nTjxsOEIVTs/R0I6ygWVVxEhdaJg+kNLEubt1HMUtFkQeOw++mr+gIXxbxsfQaTj0GJjyEDPBq/YAZ0cBNUB6EpB25rRVy2IontLjFzm6HgE7GmCdSW6Not1I6fGwSA9sYm8az5q07vEq7UKqD7wZDY6Fj/W8NnDFliCQsoP3BUxzKW4MY3tAK2ruoMn+l60+cFW6nAMnig0CU5S69S5Iq0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l19+7GPNI60WGZUx8B/pZEgUW9hpbN6JpM4kXN3FKsI=; b=C5Jd1P8K6oR18CAbfba/ntb+baFocMZM+PQ2VioT7A3fUfcgrMQZZVNlM+19LCngTGgOP041rLT2L6CoSyP30iDX6+LcuiuQJ9ECcoM2TCaCRAampjvqzZiTeJJHcLhReP9k+nCio7s79jB4TTbAYCxaqYroRs/UsvYEfSpNnuJ9I07BGkpBxEuSnQ2bfczOg561BG/2iMWFNpG3szQy3HM8hhTD6nQG+Jaq2F36TqY++Z+RPREtlrE4v4cu1tX8R+NLfVx18qyDjLYTwmB8gzabzWpeKRy+OWkFoy4fuqga42GGF/GwiGpB8dQew4HezXlMQDoh+0TK7kfhKrdubg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=idemia.com; dmarc=pass action=none header.from=idemia.com; dkim=pass header.d=idemia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=myidemia.onmicrosoft.com; s=selector1-myidemia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l19+7GPNI60WGZUx8B/pZEgUW9hpbN6JpM4kXN3FKsI=; b=BiWi52eU+FD1CoN2xdYHH5PinzuqneVm/co3ffKtHoxoNYmaHdmO6pnkidp1Uj5DFRA00gbwUsjkYxMaK+xBbciXRNiqwrn3SKoF+25EMLN7dePI6GXhhzkGR9eRvphlaDFD2n7PgQcnYUcdZv3wsNfryGqdcX12JEGW0uz0cIs= Received: from AM7P189MB0805.EURP189.PROD.OUTLOOK.COM (52.135.59.7) by AM7P189MB0680.EURP189.PROD.OUTLOOK.COM (52.135.57.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.17; Thu, 12 Dec 2019 06:27:45 +0000 Received: from AM7P189MB0805.EURP189.PROD.OUTLOOK.COM ([fe80::2086:16d6:b0cb:2e25]) by AM7P189MB0805.EURP189.PROD.OUTLOOK.COM ([fe80::2086:16d6:b0cb:2e25%6]) with mapi id 15.20.2538.017; Thu, 12 Dec 2019 06:27:45 +0000 From: DESPERRIER Jean-Marc To: Ivaylo Petrov , cose Thread-Topic: =?utf-8?B?W0NPU0VdIPCflJQgV0dMQyBvZiBkcmFmdC1pZXRmLWNvc2UteDUwOQ==?= Thread-Index: AQHVoPfOuu91wIKsFEWC3NiALvVurae2KGAg Date: Thu, 12 Dec 2019 06:27:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_431684b1-a5da-4051-9fb4-5631703e02d5_Enabled=True; MSIP_Label_431684b1-a5da-4051-9fb4-5631703e02d5_SiteId=7694d41c-5504-43d9-9e40-cb254ad755ec; MSIP_Label_431684b1-a5da-4051-9fb4-5631703e02d5_Owner=g578695@mph.morpho.com; MSIP_Label_431684b1-a5da-4051-9fb4-5631703e02d5_SetDate=2019-12-12T06:27:21.7994391Z; MSIP_Label_431684b1-a5da-4051-9fb4-5631703e02d5_Name=Public; MSIP_Label_431684b1-a5da-4051-9fb4-5631703e02d5_Application=Microsoft Azure Information Protection; MSIP_Label_431684b1-a5da-4051-9fb4-5631703e02d5_ActionId=755bbbf1-a3aa-4831-b6b1-eb4f0c4db1cd; MSIP_Label_431684b1-a5da-4051-9fb4-5631703e02d5_Extended_MSFT_Method=Manual x-originating-ip: [165.225.110.111] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 21d4fb67-7a00-4b8d-54e8-08d77ecc6652 x-ms-traffictypediagnostic: AM7P189MB0680: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0249EFCB0B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(376002)(346002)(136003)(39860400002)(396003)(199004)(189003)(33656002)(316002)(110136005)(8936002)(9686003)(55016002)(52536014)(71200400001)(478600001)(966005)(2906002)(5660300002)(86362001)(81166006)(81156014)(186003)(26005)(6506007)(66446008)(55236004)(64756008)(76116006)(66946007)(66476007)(66556008)(7696005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM7P189MB0680; H:AM7P189MB0805.EURP189.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: idemia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1Y0y83qEtGraVjB9QhDjyxWkzdWIwPzMPqi1nVQodzyAjcrmguEH6Eta3Gjb8dEOVKsST91u9MaWHEgCN/GcJ7/cNVTBxyTCQYz1F9Vewyc6pzWhqMT3csRuE6goJkGaiDyjgubWqxniW127wuVQW4uVX4bmCW/U4igM9gTqPWOfNRPVIA5CO+DICDcbia7IbGIwizFlcDpoVUWAXC4Eu7uPjmnH9DyK4XRWyslE1zmcRFI5f4cNY97TR+FSXP1D+y70fdN2VBeOrtU5GkFoJFq1CAWAbBMZ6simb1n2GqkeQjGDRND5B6xzCS8k4EBFTioWLu7pEQKvi50lWPVHm8HRVi5dLnXYAYiTSeFee9yDHi8PwWDltqG1uvJqqg9y2AQhoDJORA8/RulmkUglre4GWPV6RCzdnL2aMsJ8s+TV+Jq2VLd/ZG/d13z8PyAIJBHfW7zMKnTcPRh513BrNstFND7clRnyLcHzaJgmwjs= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM7P189MB0805CC90F65CA5DACAA1A320BF550AM7P189MB0805EURP_" MIME-Version: 1.0 X-OriginatorOrg: idemia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 21d4fb67-7a00-4b8d-54e8-08d77ecc6652 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2019 06:27:45.0000 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 7694d41c-5504-43d9-9e40-cb254ad755ec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qHmP2atYfac5Tt5U1/uHCfBhv/1e5PsSV8+DV7hMNtQEgbEYDuqrNSajtqPxBVwMJ5IFAbU6euoF2Q5Gth/VUg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7P189MB0680 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9468 signatures=668685 X-Proofpoint-Spam-Details: rule=outbound_idemia_notspam policy=outbound_idemia score=0 priorityscore=1501 impostorscore=0 adultscore=0 spamscore=0 mlxlogscore=999 suspectscore=0 malwarescore=0 lowpriorityscore=0 bulkscore=0 mlxscore=0 clxscore=1015 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912120040 Archived-At: Subject: Re: [COSE] =?utf-8?q?=F0=9F=94=94_WGLC_of_draft-ietf-cose-x509?= X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2019 06:27:52 -0000 --_000_AM7P189MB0805CC90F65CA5DACAA1A320BF550AM7P189MB0805EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClJlYWR5IGV4Y2VwdCBmb3IgdGhpcyBvbmUgc21hbGwgcmVtYXJrIDoNCg0KICAgKiAg Q09TRV9TaWduYXR1cmUgYW5kIENPU0VfU2lnbjAgb2JqZWN0cywgaW4gdGhlc2Ugb2JqZWN0cyB0 aGV5DQogICAgICBpZGVudGlmeSB0aGUgY2VydGlmaWNhdGUgdG8gYmUgdXNlZCBmb3IgdmFsaWRh dGlvbiB0aGUgc2lnbmF0dXJlLg0KU2hvdWxkIHJlYWQgaW5zdGVhZCBlaXRoZXIgOg0KICAgICAg ICAgICAgICB2YWxpZGF0aW9uIG9mIHRoZSBzaWduYXR1cmUuDQpPcg0KdmFsaWRhdGluZyB0aGUg c2lnbmF0dXJlLg0KSSBob3BlIG1vcmUgcGVvcGxlIGNhbiByZXZpZXcgYW5kIGNoZWNrIHRoZXkg YWdyZWUgd2l0aCB0aGUgdGV4dCBkdXJpbmcgdGhlIHJlbWFpbmluZyB3ZWVrIHVudGlsIHRoZSAy MC4NCg0KQmVzdCByZWdhcmRzLA0KSmVhbi1NYXJjDQoNCg0KRGUgOiBDT1NFIDxjb3NlLWJvdW5j ZXNAaWV0Zi5vcmc+IERlIGxhIHBhcnQgZGUgSXZheWxvIFBldHJvdg0KRW52b3nDqSA6IHZlbmRy ZWRpIDIyIG5vdmVtYnJlIDIwMTkgMDY6NDMNCsOAIDogY29zZSA8Y29zZUBpZXRmLm9yZz4NCk9i amV0IDogW0NPU0VdIPCflJQgV0dMQyBvZiBkcmFmdC1pZXRmLWNvc2UteDUwOQ0KDQpEZWFyIGFs bCwNCg0KVGhpcyBtZXNzYWdlIHN0YXJ0cyB0aGUgV29ya2luZyBHcm91cCBMYXN0IENhbGwgb2Yg dGhlIGRyYWZ0LWlldGYtY29zZS14NTA5IFsxXS4NCg0KVGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBj YWxsIHdpbGwgcnVuIGZvciAqKmZvdXIgd2Vla3MqKiwgZW5kaW5nIG9uDQpEZWNlbWJlciAyMCwg MjAxOS4gVGhlIGV4dGVuZGVkIGxhc3QgY2FsbCBpcyBkdWUgdG8gdHJhdmVsbGluZyBhbmQgcG9z c2libGUgaG9saWRheXMgb2Ygc29tZSBvZiB0aGUgcGFydGljaXBhbnRzLg0KDQpQbGVhc2UgcmV2 aWV3IGFuZCBzZW5kIGFueSBjb21tZW50cyBvciBmZWVkYmFjayB0byB0aGUgd29ya2luZyBncm91 cC4gRXZlbiBpZiB5b3VyIGZlZWRiYWNrIGlzICJ0aGlzIGlzIHJlYWR5IiwgcGxlYXNlIGxldCB1 cyBrbm93Lg0KDQpUaGFuayB5b3UsDQoNCi0gTWF0dGhldyBhbmQgSXZheWxvDQpDT1NFIENoYWly cw0KDQpbMV06IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY29z ZS14NTA5LzxodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWNvc2UteDUwOS9fXzshIUZadGJKVm5YZncha3p0aHFIZjZC Tld6Tl84WlZJejYwbDQxSWIwSkphR0tKeXVHVUFuNFBSanRPNXdkT0dvaWYwcWZnMUFNTXl1RHZX TkxUaW9MJD4NCg== --_000_AM7P189MB0805CC90F65CA5DACAA1A320BF550AM7P189MB0805EURP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJZdSBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNCAwIDAgMCAw IDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFl1IEdv dGhpYyI7DQoJcGFub3NlLTE6MiAxMSA0IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJIFN5bWJvbCI7DQoJcGFub3NlLTE6MiAx MSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNt Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5SZWFkeSBleGNlcHQgZm9yIHRoaXMgb25lIHNtYWxsIHJlbWFy ayA6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyAqJm5ic3A7IENPU0Vf U2lnbmF0dXJlIGFuZCBDT1NFX1NpZ24wIG9iamVjdHMsIGluIHRoZXNlIG9iamVjdHMgdGhleTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlkZW50aWZ5IHRoZSBjZXJ0 aWZpY2F0ZSB0byBiZSB1c2VkIGZvciB2YWxpZGF0aW9uIHRoZSBzaWduYXR1cmUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TaG91bGQgcmVhZCBpbnN0ZWFkIGVpdGhlciA6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPnZhbGlkYXRpb24gb2YgdGhlIHNpZ25hdHVyZS48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPk9yDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4dC1pbmRlbnQ6MzUuNHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnZhbGlkYXRpbmcgdGhlIHNpZ25hdHVyZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgaG9wZSBtb3JlIHBlb3BsZSBjYW4gcmV2aWV3IGFu ZCBjaGVjayB0aGV5IGFncmVlIHdpdGggdGhlIHRleHQgZHVyaW5nIHRoZSByZW1haW5pbmcgd2Vl ayB1bnRpbCB0aGUgMjAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InRleHQtaW5kZW50OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+ DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CZXN0 IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5KZWFuLU1hcmMNCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5EZSZu YnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IENPU0UgJmx0O2Nvc2UtYm91bmNlc0Bp ZXRmLm9yZyZndDsNCjxiPkRlIGxhIHBhcnQgZGU8L2I+IEl2YXlsbyBQZXRyb3Y8YnI+DQo8Yj5F bnZvecOpJm5ic3A7OjwvYj4gdmVuZHJlZGkgMjIgbm92ZW1icmUgMjAxOSAwNjo0Mzxicj4NCjxi PsOAJm5ic3A7OjwvYj4gY29zZSAmbHQ7Y29zZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5PYmpldCZu YnNwOzo8L2I+IFtDT1NFXSA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgU3ltYm9sJnF1b3Q7LHNhbnMtc2VyaWYiPiYjMTI4Mjc2 Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBXR0xDIG9mIGRyYWZ0LWlldGYtY29zZS14NTA5PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw QjUzOTQiPkRlYXIgYWxsLDxicj4NCjxicj4NClRoaXMgbWVzc2FnZSBzdGFydHMgdGhlIFdvcmtp bmcgR3JvdXAgTGFzdCBDYWxsIG9mIHRoZSBkcmFmdC1pZXRmLWNvc2UteDUwOSBbMV0uPGJyPg0K PGJyPg0KVGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIHdpbGwgcnVuIGZvciAqKmZvdXIgd2Vl a3MqKiwgZW5kaW5nIG9uPGJyPg0KRGVjZW1iZXIgMjAsIDIwMTkuIFRoZSBleHRlbmRlZCBsYXN0 IGNhbGwgaXMgZHVlIHRvIHRyYXZlbGxpbmcgYW5kIHBvc3NpYmxlIGhvbGlkYXlzIG9mIHNvbWUg b2YgdGhlIHBhcnRpY2lwYW50cy48YnI+DQo8YnI+DQpQbGVhc2UgcmV2aWV3IGFuZCBzZW5kIGFu eSBjb21tZW50cyBvciBmZWVkYmFjayB0byB0aGUgd29ya2luZyBncm91cC4mbmJzcDtFdmVuIGlm IHlvdXIgZmVlZGJhY2sgaXMgJnF1b3Q7dGhpcyBpcyByZWFkeSZxdW90OywgcGxlYXNlIGxldCB1 cyBrbm93Ljxicj4NCjxicj4NClRoYW5rIHlvdSw8YnI+DQo8YnI+DQotJm5ic3A7TWF0dGhldyBh bmQmbmJzcDtJdmF5bG88L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwQjUzOTQiPkNPU0Ug Q2hhaXJzPGJyPg0KPGJyPg0KWzFdOiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMEI1Mzk0Ij48YSBocmVmPSJo dHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLWNvc2UteDUwOS9fXzshIUZadGJKVm5YZncha3p0aHFIZjZCTld6Tl84WlZJ ejYwbDQxSWIwSkphR0tKeXVHVUFuNFBSanRPNXdkT0dvaWYwcWZnMUFNTXl1RHZXTkxUaW9MJCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtY29zZS14NTA5LzwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIyIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AM7P189MB0805CC90F65CA5DACAA1A320BF550AM7P189MB0805EURP_-- From nobody Thu Dec 12 08:53:04 2019 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245271209CC for ; Thu, 12 Dec 2019 08:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 SDndjwVTVvZa for ; Thu, 12 Dec 2019 08:52:58 -0800 (PST) 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 586821209C5 for ; Thu, 12 Dec 2019 08:52:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 85465300B24 for ; Thu, 12 Dec 2019 11:52:56 -0500 (EST) 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 v1di1RwoZiXT for ; Thu, 12 Dec 2019 11:52:55 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 0B2CB300472; Thu, 12 Dec 2019 11:52:54 -0500 (EST) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_C3E85441-A476-4BC7-A34C-E47AA0E8AF0B" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <15EDAA9F-C715-4FB3-955E-ADB2647C914B@vigilsec.com> Date: Thu, 12 Dec 2019 11:52:55 -0500 To: LAMPS WG , cose X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [COSE] NIST posts a draft on stateful hash-based signatures X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2019 16:53:00 -0000 --Apple-Mail=_C3E85441-A476-4BC7-A34C-E47AA0E8AF0B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii https://csrc.nist.gov/publications/detail/sp/800-208/draft = The draft includes HSS/LMS and XMSS, both have RFCs out of the CFRG. Russ --Apple-Mail=_C3E85441-A476-4BC7-A34C-E47AA0E8AF0B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
https://csrc.nist.gov/publications/detail/sp/800-208/draft<= br class=3D"">

The draft = includes HSS/LMS and XMSS, both have RFCs out of the CFRG.

Russ

= --Apple-Mail=_C3E85441-A476-4BC7-A34C-E47AA0E8AF0B--