From nobody Sat Aug 11 14:03:57 2018 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 922C4130FE5 for ; Sat, 11 Aug 2018 14:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 pvxRMNlpSxUk for ; Sat, 11 Aug 2018 14:03:54 -0700 (PDT) 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 F00CB130FCD for ; Sat, 11 Aug 2018 14:03:53 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 11 Aug 2018 14:00:06 -0700 From: Jim Schaad To: 'cose' Date: Sat, 11 Aug 2018 14:03:43 -0700 Message-ID: <000001d431b6$cb559720$6200c560$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdQxtA2DT5yVF6cfTFK7Kp+35wjH0w== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [COSE] Recharter the COSE working group. X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 21:03:57 -0000 I have approached the Security ADs about progressing the COSE from Proposed Standard to Full Standard. They have indicated that they would be open to this. In addition to this, there are a couple of other documents related to COSE which are looking for homes and this would provide an opportunity for them to be dealt with as well. The charter text that I have proposed is: ********************************* CBOR Object Signing and Encryption (COSE, RFC 8152) describes how to create and process signatures, message authentication codes, and encryption use Concise Binary Object Representation (CBOR, RFC 7049) for serialization. COSE additionally describes a representation for cryptographic keys. COSE has been picked up and is being used both by a number of groups within the IETF (i.e. ACE, CORE, ANAMA, 6TiSCH and SUIT) as well as outside of the IETF (i.e. W3C and FIDO). There are a number of implementations, both open source and private, now in existence. The specification is now sufficiently mature that it makes sense to try and advance it to STD status. The standards progression work will focus on: 1. Should the document be split in two? One document for the structures and one document for the algorithm definitions. 2. What areas in the document need clarification before the document can be progressed? 3. What implementations exist and do they cover all of the major sections of the document? There are a small number of COSE related documents that will also be addressed by the working group dealing with additional attributes and algorithms that need to be reviewed and published. The first set of three are listed in the deliverables. A re-charter will be required to expand this list. The SUIT working group has identified a need for the use of hash base signatures in the form of Leighton-Micali Signatures (LMS) (draft-mcgrew-hash-sigs). This signature form is resistant to quantum computing and is low-cost for validation. The W3C Web Authentication working group has identified a need for the ability to use algorithms which are currently part of TPMs which are widely deployed. Many of the algorithms for this work are not expected to be IETF recommended algorithms. At the time COSE was developed, there was a sense that X.509 certificates was not a feature that needed to be transferred from the JOSE key document (RFC 7517). Since that time a better sense of how certificates would be used both in the IoT sphere and with COSE outside of the IoT sphere has been developed. The need to be able to identify X.509 certificates is now a feature that needs to be provided. Key management and binding of keys to identities are out of scope for the working group. The COSE WG will not innovate in terms of cryptography. The specification of algorithms in COSE is limited to those in RFCs or active IETF WG documents. The working group will coordinate its progress with the ACE, SUIT and CORE working groups to ensure that we are fulfilling the needs of these constituencies to the extent relevant to their work. Other groups may be added to this list as the set of use cases is expanded. The WG will have four deliverables: 1. Republishing a version of RFC 8152 suitable for advancement to full standard. 2. Use of Hash-based Signature algorithms in COSE using draft-housley-suit-cose-hash-sig as a starting point. 3. Placement of X.509 certificates in COSE messages and keys using draft-schaad-cose-x509 as a starting point. 4. Define the algorithms needed for W3C Web Authentication for COSE using draft-jones-webauthn-cose-algorithms and draft-jones-webauthn-secp256k1 as a starting point. ****************************** I don't currently have a set of milestones associated with this charter in part because I have not talked to everybody about what they believe they can do. For RFC 8152, assuming that the document is split into two pieces, I would expect that we should be able to get the split documents to the IESG prior to the Prague meeting. Assuming that the IESG requires that we wait an additional six months of the new document I would expect that roughly nine months later an updated document could go to the IESG for full standard. The hash-based signature algorithm document is probably in good shape, the big question would be should it be coordinated with the similar documents in the LAMPS working group. If that is not needed then this should take less than a year to finish. The X.509 certificates draft needs to get review, but I believe that it is good shape now and probably ready to go. I don't know what the state is for the two Web Authentication drafts as I have not read the first in a while and have never read the second. Jim From nobody Sun Aug 12 14:47:52 2018 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 740FE130E4B for ; Sun, 12 Aug 2018 14:47:51 -0700 (PDT) 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] 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 iAk3pMHmt_tn for ; Sun, 12 Aug 2018 14:47:49 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 A929C130E48 for ; Sun, 12 Aug 2018 14:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w7CLlChM020128; Sun, 12 Aug 2018 23:47:13 +0200 (CEST) Received: from [192.168.217.114] (p54A6C84F.dip0.t-ipconnect.de [84.166.200.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41pXWh553PzDWPF; Sun, 12 Aug 2018 23:47:12 +0200 (CEST) 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: <000001d431b6$cb559720$6200c560$@augustcellars.com> Date: Sun, 12 Aug 2018 23:47:11 +0200 Cc: cose X-Mao-Original-Outgoing-Id: 555803230.387682-c92bce1e70deb636093af70d2765f663 Content-Transfer-Encoding: quoted-printable Message-Id: References: <000001d431b6$cb559720$6200c560$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [COSE] Recharter the COSE working group. X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2018 21:47:52 -0000 Hi Jim, Interesting initiative. On Aug 11, 2018, at 23:03, Jim Schaad wrote: >=20 > The W3C Web Authentication working group has identified a need for the > ability to use algorithms which are currently part of TPMs which are = widely > deployed. Many of the algorithms for this work are not expected to be = IETF > recommended algorithms. I also think it would be good to create a code space for hash algorithms = for use with COSE. We need this for SUIT. Also, today this weird little thing surfaced: https://tools.ietf.org/html/draft-multiformats-multihash-00 (Yet another registry for hash functions=E2=80=A6 I=E2=80=99ll keep = mute about the format proposed.) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Aug 13 11:34:38 2018 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 6E040130DFE for ; Mon, 13 Aug 2018 11:34:36 -0700 (PDT) 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_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 uTfeq8Fj-Gk8 for ; Mon, 13 Aug 2018 11:34:34 -0700 (PDT) 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 5290C130DC1 for ; Mon, 13 Aug 2018 11:34:34 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 13 Aug 2018 11:30:46 -0700 From: Jim Schaad To: 'Carsten Bormann' CC: 'cose' References: <000001d431b6$cb559720$6200c560$@augustcellars.com> In-Reply-To: Date: Mon, 13 Aug 2018 11:34:26 -0700 Message-ID: <001b01d43334$452a40e0$cf7ec2a0$@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: AQF8J5y/pC3U/85YElMlXZNkQ5wSYQHki7RapV70O8A= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Recharter the COSE working group. X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 18:34:36 -0000 > -----Original Message----- > From: Carsten Bormann > Sent: Sunday, August 12, 2018 2:47 PM > To: Jim Schaad > Cc: cose > Subject: Re: [COSE] Recharter the COSE working group. >=20 > Hi Jim, >=20 > Interesting initiative. >=20 > On Aug 11, 2018, at 23:03, Jim Schaad wrote: > > > > The W3C Web Authentication working group has identified a need for = the > > ability to use algorithms which are currently part of TPMs which are > > widely deployed. Many of the algorithms for this work are not > > expected to be IETF recommended algorithms. >=20 > I also think it would be good to create a code space for hash = algorithms for use > with COSE. Yes I think it would potentially be something to put in the charter. = There is already some work dealing with registration of hash algorithms = in the certificate document because it is hard to refer to the hash of a = certificate without being able to define which hash function to use. I do not currently believe that there is a need to define a COSE = equivalent to the CMS DigestedData structure at this point. Given the = potential flexibility desired it is probably better to have people do = this on an ad hoc basis. Jim >=20 > We need this for SUIT. >=20 > Also, today this weird little thing surfaced: > https://tools.ietf.org/html/draft-multiformats-multihash-00 > (Yet another registry for hash functions=E2=80=A6 I=E2=80=99ll keep = mute about the format > proposed.) >=20 > Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Aug 13 12:06:06 2018 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 51111130DC1 for ; Mon, 13 Aug 2018 12:06:05 -0700 (PDT) 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] 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 h81OLh287liY for ; Mon, 13 Aug 2018 12:06:04 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 3397E130F89 for ; Mon, 13 Aug 2018 12:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w7DJ5pZY016800; Mon, 13 Aug 2018 21:05:51 +0200 (CEST) Received: from [192.168.217.114] (p54A6C84F.dip0.t-ipconnect.de [84.166.200.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41q4v305ptzDWfb; Mon, 13 Aug 2018 21:05:50 +0200 (CEST) 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: <001b01d43334$452a40e0$cf7ec2a0$@augustcellars.com> Date: Mon, 13 Aug 2018 21:05:50 +0200 Cc: cose X-Mao-Original-Outgoing-Id: 555879948.2500859-40f15976d32b9efbaf4068ae1248c95f Content-Transfer-Encoding: quoted-printable Message-Id: <91B112BF-89F5-4E48-BFFF-EC7C93473C42@tzi.org> References: <000001d431b6$cb559720$6200c560$@augustcellars.com> <001b01d43334$452a40e0$cf7ec2a0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [COSE] Recharter the COSE working group. X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 19:06:05 -0000 > I do not currently believe that there is a need to define a COSE = equivalent to the CMS DigestedData structure at this point. Given the = potential flexibility desired it is probably better to have people do = this on an ad hoc basis. I agree completely. So we only need those numbers. (Maybe including the occasional truncated hash.) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Aug 13 12:45:44 2018 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 3809F130E21 for ; Mon, 13 Aug 2018 12:45:43 -0700 (PDT) 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, 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 FUUwpfVB7gx9 for ; Mon, 13 Aug 2018 12:45:40 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD16F126CC7 for ; Mon, 13 Aug 2018 12:45:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7718E300A2E for ; Mon, 13 Aug 2018 15:45:37 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fzFDiWEy1vD8 for ; Mon, 13 Aug 2018 15:45:35 -0400 (EDT) Received: from new-host-3.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id 84BE1300295; Mon, 13 Aug 2018 15:45:35 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Russ Housley In-Reply-To: <000001d431b6$cb559720$6200c560$@augustcellars.com> Date: Mon, 13 Aug 2018 15:45:36 -0400 Cc: cose Content-Transfer-Encoding: quoted-printable Message-Id: <252453AB-2C28-437E-88D3-191AD2F37A8E@vigilsec.com> References: <000001d431b6$cb559720$6200c560$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [COSE] Recharter the COSE working group. X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 19:45:43 -0000 I support this recharter activity. The SUIT WG does not want to specify = the use of hash-based signature algorithms with COSE because they have = much greater applicability than just signing software packages. I did = write a draft that could be used = as a starting point for this portion of the work. Russ > On Aug 11, 2018, at 5:03 PM, Jim Schaad = wrote: >=20 > I have approached the Security ADs about progressing the COSE from = Proposed > Standard to Full Standard. They have indicated that they would be = open to > this. In addition to this, there are a couple of other documents = related to > COSE which are looking for homes and this would provide an opportunity = for > them to be dealt with as well. >=20 > The charter text that I have proposed is: >=20 > ********************************* >=20 > CBOR Object Signing and Encryption (COSE, RFC 8152) describes how to = create > and process signatures, message authentication codes, and encryption = use > Concise Binary Object Representation (CBOR, RFC 7049) for = serialization. > COSE additionally describes a representation for cryptographic keys. >=20 > COSE has been picked up and is being used both by a number of groups = within > the IETF (i.e. ACE, CORE, ANAMA, 6TiSCH and SUIT) as well as outside = of the > IETF (i.e. W3C and FIDO). There are a number of implementations, both = open > source and private, now in existence. The specification is now > sufficiently mature that it makes sense to try and advance it to STD = status. >=20 > The standards progression work will focus on: > 1. Should the document be split in two? One document for the = structures and > one document for the algorithm definitions. > 2. What areas in the document need clarification before the document = can be > progressed? > 3. What implementations exist and do they cover all of the major = sections > of the document? >=20 > There are a small number of COSE related documents that will also be > addressed by the working group dealing with additional attributes and > algorithms that need to be reviewed and published. The first set of = three > are listed in the deliverables. A re-charter will be required to = expand > this list. >=20 > The SUIT working group has identified a need for the use of hash base > signatures in the form of Leighton-Micali Signatures (LMS) > (draft-mcgrew-hash-sigs). This signature form is resistant to quantum > computing and is low-cost for validation. >=20 > The W3C Web Authentication working group has identified a need for the > ability to use algorithms which are currently part of TPMs which are = widely > deployed. Many of the algorithms for this work are not expected to be = IETF > recommended algorithms. >=20 > At the time COSE was developed, there was a sense that X.509 = certificates > was not a feature that needed to be transferred from the JOSE key = document > (RFC 7517). Since that time a better sense of how certificates would = be > used both in the IoT sphere and with COSE outside of the IoT sphere = has been > developed. The need to be able to identify X.509 certificates is now = a > feature that needs to be provided. >=20 > Key management and binding of keys to identities are out of scope for = the > working group.=20 > The COSE WG will not innovate in terms of cryptography.=20 > The specification of algorithms in COSE is limited to those in RFCs or > active IETF WG documents. >=20 > The working group will coordinate its progress with the ACE, SUIT and = CORE > working groups to ensure that we are fulfilling the needs of these > constituencies to the extent relevant to their work.=20 > Other groups may be added to this list as the set of use cases is = expanded. >=20 > The WG will have four deliverables: >=20 > 1. Republishing a version of RFC 8152 suitable for advancement to full > standard. > 2. Use of Hash-based Signature algorithms in COSE using > draft-housley-suit-cose-hash-sig as a starting point. > 3. Placement of X.509 certificates in COSE messages and keys using > draft-schaad-cose-x509 as a starting point. > 4. Define the algorithms needed for W3C Web Authentication for COSE = using > draft-jones-webauthn-cose-algorithms and = draft-jones-webauthn-secp256k1 as a > starting point. >=20 > ****************************** >=20 > I don't currently have a set of milestones associated with this = charter in > part because I have not talked to everybody about what they believe = they can > do. >=20 > For RFC 8152, assuming that the document is split into two pieces, I = would > expect that we should be able to get the split documents to the IESG = prior > to the Prague meeting. Assuming that the IESG requires that we wait = an > additional six months of the new document I would expect that roughly = nine > months later an updated document could go to the IESG for full = standard. >=20 > The hash-based signature algorithm document is probably in good shape, = the > big question would be should it be coordinated with the similar = documents in > the LAMPS working group. If that is not needed then this should take = less > than a year to finish. >=20 > The X.509 certificates draft needs to get review, but I believe that = it is > good shape now and probably ready to go. >=20 > I don't know what the state is for the two Web Authentication drafts = as I > have not read the first in a while and have never read the second.=20 >=20 > Jim >=20 >=20 >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Mon Aug 13 13:11:53 2018 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 EFF8A130E39 for ; Mon, 13 Aug 2018 13:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 51VqvWmvUzU3 for ; Mon, 13 Aug 2018 13:11:48 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 F070C130E55 for ; Mon, 13 Aug 2018 13:11:47 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id j205-v6so29564206oib.4 for ; Mon, 13 Aug 2018 13:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=vxiQaRqGghg5wu/5ES03cB0ViQZT06RQ8J5SCEOWVlA=; b=EBuFJGngNb0PEWtCgWonx5NBhcO6477lUa/Fa6NQE8rMVgZ89J4QUIX28603s4rRz9 xKnKaNWwLpFKgIO0T6UOMxau58yyb00w+wABbsQC9yNbbVOQ4lpbRvcgaSh5E33sm/wI 93Dq1q+OoiPXxrBF4kJJ8ZwlCiNmjnqAJvHD2kb/NruB/a7INsTVp/f22spug2W5vCIE N0gcFPHrn34QJ7daGozYKIXlNu/Rr8U2RjEHRqZ6UkeIb74xWXDYnu8W4+f4abq0r7FS 0z4A91jABL99avZG31I4b0cgdoR6ASmhr8a9cjqTYF3j2PhbUIMPI+5O6NwBSGb+fjTT 07uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=vxiQaRqGghg5wu/5ES03cB0ViQZT06RQ8J5SCEOWVlA=; b=ApmWGEnrsxOZwsFLd3ZUwYAhYrm2Z7GTpsQXSuEXR8fxukoq5ai5OrQBzTlc7SSMzi PeOrlmfsXHbCTxrOvLBiI6JajzImo1XXj8mPQ8iVs7WQ2PfUfHkFPVTUbBjYAErnBcao HqM2U+iy98oDY/ohaLQQw9/y97AQNiCnhWOb6wC7s5NOSCpJcON5CjQiyExaIY1/SCGW 5yKHH0LHH7k4kKG8cTZbFz4IpYjbNYEClR3/Pvy29K2Gm2cnQ968XSX+3G/wz/gmBQyc QfPt2HpDKkTv4c0e/DcTnmlW15uKekRVU9OOI0iCFpQ2MmQTeGf8p/Do6E3EIfnEKU2/ Z3cw== X-Gm-Message-State: AOUpUlEodQZtbRsBrtfchCbJ1HfQ9Xv2wPTSDnD5e0adFRygRGSZsiGS SJRy7kIHkecD/Nt/XX0YS1aHRySO7Xg= X-Google-Smtp-Source: AA+uWPy8chJ8Pv43P6ls7kYEMLAi5gdxOwHu2QILjRvZHI/q4D2lJ6dbE+zby7ZyEMnA262HNsBl3g== X-Received: by 2002:aca:de04:: with SMTP id v4-v6mr20779051oig.328.1534191106890; Mon, 13 Aug 2018 13:11:46 -0700 (PDT) Received: from [10.6.21.160] ([128.177.113.102]) by smtp.gmail.com with ESMTPSA id q204-v6sm17962540oih.49.2018.08.13.13.11.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Aug 2018 13:11:46 -0700 (PDT) To: Russ Housley , Jim Schaad Cc: cose References: <000001d431b6$cb559720$6200c560$@augustcellars.com> <252453AB-2C28-437E-88D3-191AD2F37A8E@vigilsec.com> From: "Matthew A. Miller" Openpgp: preference=signencrypt Autocrypt: addr=linuxwolf@outer-planes.net; prefer-encrypt=mutual; keydata= xsBNBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAHNLk1hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGZAb3V0ZXItcGxhbmVzLm5ldD7CwIAE EwEKACoCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AFCQvHJDEFAlirCeQCGQEACgkQ7PRy ThCeBbt+sAgAzUQokr+f+ArieIrv2JkiQLqiBaZX29Aph9YwG3OPLWSdESEKkFOSJT0LWbsC cAKHLrVfgl2+6iPhf4OOacTdqK7wS6vruPZC1ChdO7NZTgbVa0hP/Q/QKEoaMGNdfc1/lgxY 5kwh+bvGIF1+HyadytgCBBHxdVEhYI7G3ejKqA8iVwri1VW0Wjp8iWdjpF74swIHhid5GcAu 6VJgVNJw3P+WkTkNrkd2tx5yUfNXQuGyFhxwlpiuaOpIk3p74P6e8h/riMpkJ5mIH/ryGTH7 qxpEIuep2bLQZmGwBen8kf3MO/VbiA/NMY6OHdc93EBKr0g7n2BA5uFLdy79FqAA3M7ATQRS aAKKAQgAwP67h8GJUO6XYyWOrcJGXDJnnZEDS+q+bTQXkJMFa74rVIx0yioqY8QdpBJFGaMT 4DCNYe/3pw61ZTDDKqukSCfOh/ssdd8zSGTQZSX5lR4B4+00/LKWugP6iHHHYiETbBVb5bxc aR/LE41Wx3z2HsW3TkeZB6WVk82MTclS1zCuY3p9AeCvr424BSQL7KC38y2eQc95G+nabsVD c6oQ8oZOf1D2giBb2VgbYkSppKj8BKvBtmjCauWeEq/AkZKaDAdua8Qj0vEfgcoh8aavlPJi rqj1YNSyc3AO4R5prPGgTepcUpW8ip8xIPAFoJXfuvsZSV7uVP36gwApU4+ZnwARAQABwsB8 BBgBCgAmAhsMFiEEMddYjeyQaQ1rzJjg7PRyThCeBbsFAlpvpIsFCQvLWoEACgkQ7PRyThCe BbuNHAf/cchJ7kHoIr5i+jgVRuR71AGlxlMbVolnS5tza3bi9Ie63LRdOtMUE3pDUQo25cWd cP7pzwwRBCDD2GxfIuyMCWaES0xtQdTIyNOAFFOtBtCFOrsNEk+iLAu6GBr4QzSQKW1QW4/b vcfpM2pLQn7Zd6naUioEYfTHCMmYHr7hQXaPNEQ7V/J4pLVAN8bHyVgQ9ciQN91DUs6jnueM BUW7DNvuHq0RDzA+ufYdpQAjwl4z1v+rnJ79P3HTxfFdiTTAk9MjyVQklHxS067cmLYkSOku dnCOHhDmSFwkKd9EwOBNuztpjCzmM5SgOT+U/iHH+IM/Hv6bjVCiAQ5WOihe6Q== Message-ID: <0796519c-8232-9e02-5d2c-e4dde48bc129@outer-planes.net> Date: Mon, 13 Aug 2018 14:11:44 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <252453AB-2C28-437E-88D3-191AD2F37A8E@vigilsec.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ITQUF4ZIeIRcexa1wERbKbciOAqWb436E" Archived-At: Subject: Re: [COSE] Recharter the COSE working group. X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 20:11:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ITQUF4ZIeIRcexa1wERbKbciOAqWb436E Content-Type: multipart/mixed; boundary="XQ1NdrvCQmNRChc4VFYw9oXoilYWzmAYJ"; protected-headers="v1" From: "Matthew A. Miller" To: Russ Housley , Jim Schaad Cc: cose Message-ID: <0796519c-8232-9e02-5d2c-e4dde48bc129@outer-planes.net> Subject: Re: [COSE] Recharter the COSE working group. References: <000001d431b6$cb559720$6200c560$@augustcellars.com> <252453AB-2C28-437E-88D3-191AD2F37A8E@vigilsec.com> In-Reply-To: <252453AB-2C28-437E-88D3-191AD2F37A8E@vigilsec.com> --XQ1NdrvCQmNRChc4VFYw9oXoilYWzmAYJ Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable I also support this effort. The COSE WG already closed, but that shouldn't stop the proposed COSEbis WG from using this mailing list (and/or hopefully just not adopting the -bis suffix). I am curious what rationales there are for splitting the document. Not opposed, mind you; just curious. - m&m Matthew A. Miller < http://goo.gl/LM55L > On 18/08/13 13:45, Russ Housley wrote: > I support this recharter activity. The SUIT WG does not want to specif= y the use of hash-based signature algorithms with COSE because they have = much greater applicability than just signing software packages. I did wr= ite a draft that could be used as a= starting point for this portion of the work. >=20 > Russ >=20 >=20 >> On Aug 11, 2018, at 5:03 PM, Jim Schaad wrote= : >> >> I have approached the Security ADs about progressing the COSE from Pro= posed >> Standard to Full Standard. They have indicated that they would be ope= n to >> this. In addition to this, there are a couple of other documents rela= ted to >> COSE which are looking for homes and this would provide an opportunity= for >> them to be dealt with as well. >> >> The charter text that I have proposed is: >> >> ********************************* >> >> CBOR Object Signing and Encryption (COSE, RFC 8152) describes how to c= reate >> and process signatures, message authentication codes, and encryption u= se >> Concise Binary Object Representation (CBOR, RFC 7049) for serializatio= n. >> COSE additionally describes a representation for cryptographic keys. >> >> COSE has been picked up and is being used both by a number of groups w= ithin >> the IETF (i.e. ACE, CORE, ANAMA, 6TiSCH and SUIT) as well as outside o= f the >> IETF (i.e. W3C and FIDO). There are a number of implementations, both= open >> source and private, now in existence. The specification is now >> sufficiently mature that it makes sense to try and advance it to STD s= tatus. >> >> The standards progression work will focus on: >> 1. Should the document be split in two? One document for the structur= es and >> one document for the algorithm definitions. >> 2. What areas in the document need clarification before the document = can be >> progressed? >> 3. What implementations exist and do they cover all of the major sect= ions >> of the document? >> >> There are a small number of COSE related documents that will also be >> addressed by the working group dealing with additional attributes and >> algorithms that need to be reviewed and published. The first set of t= hree >> are listed in the deliverables. A re-charter will be required to expa= nd >> this list. >> >> The SUIT working group has identified a need for the use of hash base >> signatures in the form of Leighton-Micali Signatures (LMS) >> (draft-mcgrew-hash-sigs). This signature form is resistant to quantum= >> computing and is low-cost for validation. >> >> The W3C Web Authentication working group has identified a need for the= >> ability to use algorithms which are currently part of TPMs which are w= idely >> deployed. Many of the algorithms for this work are not expected to be= IETF >> recommended algorithms. >> >> At the time COSE was developed, there was a sense that X.509 certifica= tes >> was not a feature that needed to be transferred from the JOSE key docu= ment >> (RFC 7517). Since that time a better sense of how certificates would = be >> used both in the IoT sphere and with COSE outside of the IoT sphere ha= s been >> developed. The need to be able to identify X.509 certificates is now = a >> feature that needs to be provided. >> >> Key management and binding of keys to identities are out of scope for = the >> working group.=20 >> The COSE WG will not innovate in terms of cryptography.=20 >> The specification of algorithms in COSE is limited to those in RFCs or= >> active IETF WG documents. >> >> The working group will coordinate its progress with the ACE, SUIT and = CORE >> working groups to ensure that we are fulfilling the needs of these >> constituencies to the extent relevant to their work.=20 >> Other groups may be added to this list as the set of use cases is expa= nded. >> >> The WG will have four deliverables: >> >> 1. Republishing a version of RFC 8152 suitable for advancement to full= >> standard. >> 2. Use of Hash-based Signature algorithms in COSE using >> draft-housley-suit-cose-hash-sig as a starting point. >> 3. Placement of X.509 certificates in COSE messages and keys using >> draft-schaad-cose-x509 as a starting point. >> 4. Define the algorithms needed for W3C Web Authentication for COSE us= ing >> draft-jones-webauthn-cose-algorithms and draft-jones-webauthn-secp256k= 1 as a >> starting point. >> >> ****************************** >> >> I don't currently have a set of milestones associated with this charte= r in >> part because I have not talked to everybody about what they believe th= ey can >> do. >> >> For RFC 8152, assuming that the document is split into two pieces, I w= ould >> expect that we should be able to get the split documents to the IESG p= rior >> to the Prague meeting. Assuming that the IESG requires that we wait a= n >> additional six months of the new document I would expect that roughly = nine >> months later an updated document could go to the IESG for full standar= d. >> >> The hash-based signature algorithm document is probably in good shape,= the >> big question would be should it be coordinated with the similar docume= nts in >> the LAMPS working group. If that is not needed then this should take = less >> than a year to finish. >> >> The X.509 certificates draft needs to get review, but I believe that i= t is >> good shape now and probably ready to go. >> >> I don't know what the state is for the two Web Authentication drafts a= s I >> have not read the first in a while and have never read the second.=20 >> >> Jim >> >> >> >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose >=20 --XQ1NdrvCQmNRChc4VFYw9oXoilYWzmAYJ-- --ITQUF4ZIeIRcexa1wERbKbciOAqWb436E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEMddYjeyQaQ1rzJjg7PRyThCeBbsFAltx5gEACgkQ7PRyThCe BbsmYQf6AnkT5Xu6WvWV/YMQyDW+jqKbqOI4G6dmXx9smSeX2A9cZTYqvFYr+gxq /Xk/+9HXShyysiozK6Iu1DRbeX9O0Sj87Jz9goPQ+8r3MJ3x2ls0EpuACNdiqgxy w0EEVGvigaEyZohR3ZD+o/CMbu4WTnw9eSiULYOD5TU7da4sQobJrkijAHwWOfsg Sny0+guC+MBFzwgk11sUHc/GLxwBUN90guaEuUx7XRBeijOkzBaSFNmV2d2EhYOc 3XAC2jSzoEXFDHziKi61wDFIZ3cp6eQU2/BGpY1Erm+SrepnMDnSmx8eHrFRyEBm gu8075Lz1/otThWMhE/mrJjx6KNhjw== =Ie5L -----END PGP SIGNATURE----- --ITQUF4ZIeIRcexa1wERbKbciOAqWb436E-- From nobody Mon Aug 13 13:53:09 2018 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 B6C40131096 for ; Mon, 13 Aug 2018 13:53:08 -0700 (PDT) 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_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 2H-q9C4iGGTc for ; Mon, 13 Aug 2018 13:53:05 -0700 (PDT) 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 29EBC131095 for ; Mon, 13 Aug 2018 13:53:05 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 13 Aug 2018 13:49:14 -0700 From: Jim Schaad To: "'Matthew A. Miller'" CC: 'cose' References: <000001d431b6$cb559720$6200c560$@augustcellars.com> <252453AB-2C28-437E-88D3-191AD2F37A8E@vigilsec.com> <0796519c-8232-9e02-5d2c-e4dde48bc129@outer-planes.net> In-Reply-To: <0796519c-8232-9e02-5d2c-e4dde48bc129@outer-planes.net> Date: Mon, 13 Aug 2018 13:52:53 -0700 Message-ID: <003201d43347$9d1aa250$d74fe6f0$@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: AQF8J5y/pC3U/85YElMlXZNkQ5wSYQCxgFREATYUNialXwHEMA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] Recharter the COSE working group. X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 20:53:09 -0000 There are two basic reasons for splitting the document. First, a shorter document is normally just easier to deal with and by = and large one is only dealing with one of the documents at any given = time. (We did get complaints from the IESG at the time about the = document length.) Second, the structure document would not have any algorithm details or = recommendations in it. The issue with having algorithms in a full = standard is what happens when that algorithm suddenly because broken. = Do you now need to de-list the standard because it is saying to do = things that are no longer recommended? Having the algorithms separate = from the structure make this problem moot. Protocols that reference the = standard and make algorithm requirements would need to deal with this = but no the core structure document. One unimportant reason is that not having the algorithms means that it = is going to be easier (I think) to validate that we have implementations = of all of the interesting parts of the structure document. Jim > -----Original Message----- > From: Matthew A. Miller > Sent: Monday, August 13, 2018 1:12 PM > To: Russ Housley ; Jim Schaad > > Cc: cose > Subject: Re: [COSE] Recharter the COSE working group. >=20 > I also support this effort. The COSE WG already closed, but that = shouldn't stop > the proposed COSEbis WG from using this mailing list (and/or hopefully = just not > adopting the -bis suffix). >=20 > I am curious what rationales there are for splitting the document. = Not > opposed, mind you; just curious. >=20 >=20 > - m&m >=20 > Matthew A. Miller > < http://goo.gl/LM55L > >=20 > On 18/08/13 13:45, Russ Housley wrote: > > I support this recharter activity. The SUIT WG does not want to = specify the > use of hash-based signature algorithms with COSE because they have = much > greater applicability than just signing software packages. I did = write a draft > that could be used as a starting = point for > this portion of the work. > > > > Russ > > > > > >> On Aug 11, 2018, at 5:03 PM, Jim Schaad = wrote: > >> > >> I have approached the Security ADs about progressing the COSE from > >> Proposed Standard to Full Standard. They have indicated that they > >> would be open to this. In addition to this, there are a couple of > >> other documents related to COSE which are looking for homes and = this > >> would provide an opportunity for them to be dealt with as well. > >> > >> The charter text that I have proposed is: > >> > >> ********************************* > >> > >> CBOR Object Signing and Encryption (COSE, RFC 8152) describes how = to > >> create and process signatures, message authentication codes, and > >> encryption use Concise Binary Object Representation (CBOR, RFC = 7049) for > serialization. > >> COSE additionally describes a representation for cryptographic = keys. > >> > >> COSE has been picked up and is being used both by a number of = groups > >> within the IETF (i.e. ACE, CORE, ANAMA, 6TiSCH and SUIT) as well as > >> outside of the IETF (i.e. W3C and FIDO). There are a number of > >> implementations, both open source and private, now in existence. > >> The specification is now sufficiently mature that it makes sense to = try and > advance it to STD status. > >> > >> The standards progression work will focus on: > >> 1. Should the document be split in two? One document for the > >> structures and one document for the algorithm definitions. > >> 2. What areas in the document need clarification before the = document > >> can be progressed? > >> 3. What implementations exist and do they cover all of the major > >> sections of the document? > >> > >> There are a small number of COSE related documents that will also = be > >> addressed by the working group dealing with additional attributes = and > >> algorithms that need to be reviewed and published. The first set = of > >> three are listed in the deliverables. A re-charter will be = required > >> to expand this list. > >> > >> The SUIT working group has identified a need for the use of hash = base > >> signatures in the form of Leighton-Micali Signatures (LMS) > >> (draft-mcgrew-hash-sigs). This signature form is resistant to > >> quantum computing and is low-cost for validation. > >> > >> The W3C Web Authentication working group has identified a need for > >> the ability to use algorithms which are currently part of TPMs = which > >> are widely deployed. Many of the algorithms for this work are not > >> expected to be IETF recommended algorithms. > >> > >> At the time COSE was developed, there was a sense that X.509 > >> certificates was not a feature that needed to be transferred from = the > >> JOSE key document (RFC 7517). Since that time a better sense of = how > >> certificates would be used both in the IoT sphere and with COSE > >> outside of the IoT sphere has been developed. The need to be able = to > >> identify X.509 certificates is now a feature that needs to be = provided. > >> > >> Key management and binding of keys to identities are out of scope = for > >> the working group. > >> The COSE WG will not innovate in terms of cryptography. > >> The specification of algorithms in COSE is limited to those in RFCs > >> or active IETF WG documents. > >> > >> The working group will coordinate its progress with the ACE, SUIT = and > >> CORE working groups to ensure that we are fulfilling the needs of > >> these constituencies to the extent relevant to their work. > >> Other groups may be added to this list as the set of use cases is = expanded. > >> > >> The WG will have four deliverables: > >> > >> 1. Republishing a version of RFC 8152 suitable for advancement to > >> full standard. > >> 2. Use of Hash-based Signature algorithms in COSE using > >> draft-housley-suit-cose-hash-sig as a starting point. > >> 3. Placement of X.509 certificates in COSE messages and keys using > >> draft-schaad-cose-x509 as a starting point. > >> 4. Define the algorithms needed for W3C Web Authentication for COSE > >> using draft-jones-webauthn-cose-algorithms and > >> draft-jones-webauthn-secp256k1 as a starting point. > >> > >> ****************************** > >> > >> I don't currently have a set of milestones associated with this > >> charter in part because I have not talked to everybody about what > >> they believe they can do. > >> > >> For RFC 8152, assuming that the document is split into two pieces, = I > >> would expect that we should be able to get the split documents to = the > >> IESG prior to the Prague meeting. Assuming that the IESG requires > >> that we wait an additional six months of the new document I would > >> expect that roughly nine months later an updated document could go = to the > IESG for full standard. > >> > >> The hash-based signature algorithm document is probably in good > >> shape, the big question would be should it be coordinated with the > >> similar documents in the LAMPS working group. If that is not = needed > >> then this should take less than a year to finish. > >> > >> The X.509 certificates draft needs to get review, but I believe = that > >> it is good shape now and probably ready to go. > >> > >> I don't know what the state is for the two Web Authentication = drafts > >> as I have not read the first in a while and have never read the = second. > >> > >> Jim > >> > >> > >> > >> _______________________________________________ > >> COSE mailing list > >> COSE@ietf.org > >> https://www.ietf.org/mailman/listinfo/cose > > > > _______________________________________________ > > COSE mailing list > > COSE@ietf.org > > https://www.ietf.org/mailman/listinfo/cose > > From nobody Tue Aug 14 08:20:50 2018 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 B323C130DD1 for ; Tue, 14 Aug 2018 08:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 wufu6J2xCDf6 for ; Tue, 14 Aug 2018 08:20:39 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 12EC4130DC9 for ; Tue, 14 Aug 2018 08:20:38 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id j205-v6so34295571oib.4 for ; Tue, 14 Aug 2018 08:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=e32eXnwRZP4/5fU4rGIOv5Sd/0ovcSt4tXE1nP5lCmo=; b=KEanR6PLAEIMdifaaUMufSWCRTySKfxnyoydSsl5+w+5q7kpR5nfRvr6FO5C1w5o8n 9+OOhJb3tVBSOgoCk6a5NEg4YF5Zqq0IbyDVzzEF/rC3x2LMlHDxX5NOl3SS5+3GrF30 zaEM96+rFEBPPbdEmPOZz7bP8B+AIrHn+wMDJ2fefv75v25yaVgby96Kr8f6HwSrPseA ytFaxiUJiEGjE/fl2aJHSq7gsave9oriqtrsfqMWa3uYNFCg5V1jEgZPTA646jGvlXxt 0O16i15SSZHZDNuQTjUfW6daBJhmglFxhQDQrP9wIHwbTd/j5ETDrgZPf5wWXAkxoDT5 0QRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=e32eXnwRZP4/5fU4rGIOv5Sd/0ovcSt4tXE1nP5lCmo=; b=O5YTmNO4BGXoGWBQhU5gCk12I9ALuiuScbjSzto7LdNlGXUGjFVLS93nIIrVYccX0L ex2cFJHlFwhrdyLCItUEiKqFXXtBpGFUnX1rV8FfNQ6qpJTAfFIPTnnlOXQUkyE+zD+J cTSsSs2WPNgC9Sc+zDqosNCw0uzQDsraXwt8fA/G+QJKfNDT1IuLxuMepgIWsrIH1Ciu MgDfuK3YETmHHJUhm2Ck0Al2UNE6PEnQ88YsNqfO5rgQw2LpYs/bohu3TX7UDi9GQlYc bH/pCAhXqM0gS/0I+Qmy3ZJqWo5wGfLI/Gxrqijivm7Uet+bYdNCibun39Q3wtxbgMgK 7+Kw== X-Gm-Message-State: AOUpUlGoj+VGPaEY+xonpIdIHpRWd081Ng2ICH1bXpm02giRQqi4EUZF hdOxzc2g6p26CtkS10y7xOdTFT4yQRw= X-Google-Smtp-Source: AA+uWPxRRIoEwiNs2KbixnpHZwzY1hAT1U0XW8nR+u2yjmTsyn+bk1MLOXklu7Skbt+h7pt8odvfkg== X-Received: by 2002:aca:5e42:: with SMTP id s63-v6mr21655504oib.134.1534260037851; Tue, 14 Aug 2018 08:20:37 -0700 (PDT) Received: from [10.6.21.160] ([128.177.113.102]) by smtp.gmail.com with ESMTPSA id b125-v6sm16573685oia.38.2018.08.14.08.20.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Aug 2018 08:20:37 -0700 (PDT) To: Jim Schaad Cc: 'cose' References: <000001d431b6$cb559720$6200c560$@augustcellars.com> <252453AB-2C28-437E-88D3-191AD2F37A8E@vigilsec.com> <0796519c-8232-9e02-5d2c-e4dde48bc129@outer-planes.net> <003201d43347$9d1aa250$d74fe6f0$@augustcellars.com> From: "Matthew A. Miller" Openpgp: preference=signencrypt Autocrypt: addr=linuxwolf@outer-planes.net; prefer-encrypt=mutual; keydata= xsBNBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAHNLk1hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGZAb3V0ZXItcGxhbmVzLm5ldD7CwIAE EwEKACoCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AFCQvHJDEFAlirCeQCGQEACgkQ7PRy ThCeBbt+sAgAzUQokr+f+ArieIrv2JkiQLqiBaZX29Aph9YwG3OPLWSdESEKkFOSJT0LWbsC cAKHLrVfgl2+6iPhf4OOacTdqK7wS6vruPZC1ChdO7NZTgbVa0hP/Q/QKEoaMGNdfc1/lgxY 5kwh+bvGIF1+HyadytgCBBHxdVEhYI7G3ejKqA8iVwri1VW0Wjp8iWdjpF74swIHhid5GcAu 6VJgVNJw3P+WkTkNrkd2tx5yUfNXQuGyFhxwlpiuaOpIk3p74P6e8h/riMpkJ5mIH/ryGTH7 qxpEIuep2bLQZmGwBen8kf3MO/VbiA/NMY6OHdc93EBKr0g7n2BA5uFLdy79FqAA3M7ATQRS aAKKAQgAwP67h8GJUO6XYyWOrcJGXDJnnZEDS+q+bTQXkJMFa74rVIx0yioqY8QdpBJFGaMT 4DCNYe/3pw61ZTDDKqukSCfOh/ssdd8zSGTQZSX5lR4B4+00/LKWugP6iHHHYiETbBVb5bxc aR/LE41Wx3z2HsW3TkeZB6WVk82MTclS1zCuY3p9AeCvr424BSQL7KC38y2eQc95G+nabsVD c6oQ8oZOf1D2giBb2VgbYkSppKj8BKvBtmjCauWeEq/AkZKaDAdua8Qj0vEfgcoh8aavlPJi rqj1YNSyc3AO4R5prPGgTepcUpW8ip8xIPAFoJXfuvsZSV7uVP36gwApU4+ZnwARAQABwsB8 BBgBCgAmAhsMFiEEMddYjeyQaQ1rzJjg7PRyThCeBbsFAlpvpIsFCQvLWoEACgkQ7PRyThCe BbuNHAf/cchJ7kHoIr5i+jgVRuR71AGlxlMbVolnS5tza3bi9Ie63LRdOtMUE3pDUQo25cWd cP7pzwwRBCDD2GxfIuyMCWaES0xtQdTIyNOAFFOtBtCFOrsNEk+iLAu6GBr4QzSQKW1QW4/b vcfpM2pLQn7Zd6naUioEYfTHCMmYHr7hQXaPNEQ7V/J4pLVAN8bHyVgQ9ciQN91DUs6jnueM BUW7DNvuHq0RDzA+ufYdpQAjwl4z1v+rnJ79P3HTxfFdiTTAk9MjyVQklHxS067cmLYkSOku dnCOHhDmSFwkKd9EwOBNuztpjCzmM5SgOT+U/iHH+IM/Hv6bjVCiAQ5WOihe6Q== Message-ID: <4719053b-b6a6-7d80-6782-e2e3c5e21229@outer-planes.net> Date: Tue, 14 Aug 2018 09:20:36 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <003201d43347$9d1aa250$d74fe6f0$@augustcellars.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kkAfLrwsulP9QGaBpBojtbCTNUG4mUcEm" Archived-At: Subject: Re: [COSE] Recharter the COSE working group. X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 15:20:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kkAfLrwsulP9QGaBpBojtbCTNUG4mUcEm Content-Type: multipart/mixed; boundary="jw7Udpidub5dvTUfCnFuq7cW7o8HtAfco"; protected-headers="v1" From: "Matthew A. Miller" To: Jim Schaad Cc: 'cose' Message-ID: <4719053b-b6a6-7d80-6782-e2e3c5e21229@outer-planes.net> Subject: Re: [COSE] Recharter the COSE working group. References: <000001d431b6$cb559720$6200c560$@augustcellars.com> <252453AB-2C28-437E-88D3-191AD2F37A8E@vigilsec.com> <0796519c-8232-9e02-5d2c-e4dde48bc129@outer-planes.net> <003201d43347$9d1aa250$d74fe6f0$@augustcellars.com> In-Reply-To: <003201d43347$9d1aa250$d74fe6f0$@augustcellars.com> --jw7Udpidub5dvTUfCnFuq7cW7o8HtAfco Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Thanks Jim, For whatever it's worth, these are roughly what I thought were worthwhile reasons to split before I asked. I wonder if it's really worth waiting for the WG to be formed before deciding to split, or if consensus to do so can be reached during chartering. It seems to me fairly uncontroversial and it can just be made so now. I'm confident the directorate reviewers would thank you in addition to the ADs. - m&m Matthew A. Miller < http://goo.gl/LM55L > On 18/08/13 14:52, Jim Schaad wrote: > There are two basic reasons for splitting the document. >=20 > First, a shorter document is normally just easier to deal with and by a= nd large one is only dealing with one of the documents at any given time.= (We did get complaints from the IESG at the time about the document len= gth.) >=20 > Second, the structure document would not have any algorithm details or = recommendations in it. The issue with having algorithms in a full standa= rd is what happens when that algorithm suddenly because broken. Do you n= ow need to de-list the standard because it is saying to do things that ar= e no longer recommended? Having the algorithms separate from the structu= re make this problem moot. Protocols that reference the standard and mak= e algorithm requirements would need to deal with this but no the core str= ucture document. >=20 > One unimportant reason is that not having the algorithms means that it = is going to be easier (I think) to validate that we have implementations = of all of the interesting parts of the structure document. >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: Matthew A. Miller >> Sent: Monday, August 13, 2018 1:12 PM >> To: Russ Housley ; Jim Schaad >> >> Cc: cose >> Subject: Re: [COSE] Recharter the COSE working group. >> >> I also support this effort. The COSE WG already closed, but that shou= ldn't stop >> the proposed COSEbis WG from using this mailing list (and/or hopefully= just not >> adopting the -bis suffix). >> >> I am curious what rationales there are for splitting the document. No= t >> opposed, mind you; just curious. >> >> >> - m&m >> >> Matthew A. Miller >> < http://goo.gl/LM55L > >> >> On 18/08/13 13:45, Russ Housley wrote: >>> I support this recharter activity. The SUIT WG does not want to spec= ify the >> use of hash-based signature algorithms with COSE because they have muc= h >> greater applicability than just signing software packages. I did writ= e a draft >> that could be used as a starting= point for >> this portion of the work. >>> >>> Russ >>> >>> >>>> On Aug 11, 2018, at 5:03 PM, Jim Schaad wro= te: >>>> >>>> I have approached the Security ADs about progressing the COSE from >>>> Proposed Standard to Full Standard. They have indicated that they >>>> would be open to this. In addition to this, there are a couple of >>>> other documents related to COSE which are looking for homes and this= >>>> would provide an opportunity for them to be dealt with as well. >>>> >>>> The charter text that I have proposed is: >>>> >>>> ********************************* >>>> >>>> CBOR Object Signing and Encryption (COSE, RFC 8152) describes how to= >>>> create and process signatures, message authentication codes, and >>>> encryption use Concise Binary Object Representation (CBOR, RFC 7049)= for >> serialization. >>>> COSE additionally describes a representation for cryptographic keys.= >>>> >>>> COSE has been picked up and is being used both by a number of groups= >>>> within the IETF (i.e. ACE, CORE, ANAMA, 6TiSCH and SUIT) as well as >>>> outside of the IETF (i.e. W3C and FIDO). There are a number of >>>> implementations, both open source and private, now in existence. >>>> The specification is now sufficiently mature that it makes sense to = try and >> advance it to STD status. >>>> >>>> The standards progression work will focus on: >>>> 1. Should the document be split in two? One document for the >>>> structures and one document for the algorithm definitions. >>>> 2. What areas in the document need clarification before the documen= t >>>> can be progressed? >>>> 3. What implementations exist and do they cover all of the major >>>> sections of the document? >>>> >>>> There are a small number of COSE related documents that will also be= >>>> addressed by the working group dealing with additional attributes an= d >>>> algorithms that need to be reviewed and published. The first set of= >>>> three are listed in the deliverables. A re-charter will be required= >>>> to expand this list. >>>> >>>> The SUIT working group has identified a need for the use of hash bas= e >>>> signatures in the form of Leighton-Micali Signatures (LMS) >>>> (draft-mcgrew-hash-sigs). This signature form is resistant to >>>> quantum computing and is low-cost for validation. >>>> >>>> The W3C Web Authentication working group has identified a need for >>>> the ability to use algorithms which are currently part of TPMs which= >>>> are widely deployed. Many of the algorithms for this work are not >>>> expected to be IETF recommended algorithms. >>>> >>>> At the time COSE was developed, there was a sense that X.509 >>>> certificates was not a feature that needed to be transferred from th= e >>>> JOSE key document (RFC 7517). Since that time a better sense of how= >>>> certificates would be used both in the IoT sphere and with COSE >>>> outside of the IoT sphere has been developed. The need to be able t= o >>>> identify X.509 certificates is now a feature that needs to be provid= ed. >>>> >>>> Key management and binding of keys to identities are out of scope fo= r >>>> the working group. >>>> The COSE WG will not innovate in terms of cryptography. >>>> The specification of algorithms in COSE is limited to those in RFCs >>>> or active IETF WG documents. >>>> >>>> The working group will coordinate its progress with the ACE, SUIT an= d >>>> CORE working groups to ensure that we are fulfilling the needs of >>>> these constituencies to the extent relevant to their work. >>>> Other groups may be added to this list as the set of use cases is ex= panded. >>>> >>>> The WG will have four deliverables: >>>> >>>> 1. Republishing a version of RFC 8152 suitable for advancement to >>>> full standard. >>>> 2. Use of Hash-based Signature algorithms in COSE using >>>> draft-housley-suit-cose-hash-sig as a starting point. >>>> 3. Placement of X.509 certificates in COSE messages and keys using >>>> draft-schaad-cose-x509 as a starting point. >>>> 4. Define the algorithms needed for W3C Web Authentication for COSE >>>> using draft-jones-webauthn-cose-algorithms and >>>> draft-jones-webauthn-secp256k1 as a starting point. >>>> >>>> ****************************** >>>> >>>> I don't currently have a set of milestones associated with this >>>> charter in part because I have not talked to everybody about what >>>> they believe they can do. >>>> >>>> For RFC 8152, assuming that the document is split into two pieces, I= >>>> would expect that we should be able to get the split documents to th= e >>>> IESG prior to the Prague meeting. Assuming that the IESG requires >>>> that we wait an additional six months of the new document I would >>>> expect that roughly nine months later an updated document could go t= o the >> IESG for full standard. >>>> >>>> The hash-based signature algorithm document is probably in good >>>> shape, the big question would be should it be coordinated with the >>>> similar documents in the LAMPS working group. If that is not needed= >>>> then this should take less than a year to finish. >>>> >>>> The X.509 certificates draft needs to get review, but I believe that= >>>> it is good shape now and probably ready to go. >>>> >>>> I don't know what the state is for the two Web Authentication drafts= >>>> as I have not read the first in a while and have never read the seco= nd. >>>> >>>> Jim >>>> >>>> >>>> >>>> _______________________________________________ >>>> COSE mailing list >>>> COSE@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cose >>> >>> _______________________________________________ >>> COSE mailing list >>> COSE@ietf.org >>> https://www.ietf.org/mailman/listinfo/cose >>> >=20 >=20 --jw7Udpidub5dvTUfCnFuq7cW7o8HtAfco-- --kkAfLrwsulP9QGaBpBojtbCTNUG4mUcEm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEMddYjeyQaQ1rzJjg7PRyThCeBbsFAlty80QACgkQ7PRyThCe BbvBPAgAg4/DUcwvX7AdC1eXIjtZtJ5cI9Q9hzX6oIaAluf8wPZIrcvmQsg4PaL7 MMO4ovItwiYf2dWEA59LZVKwlXjsO+HdHSeWTU0HK88T/G21q8Jb+HpPSlZc4JmK 4Neqi2kOrkMu+4J/fdd0BD28ifVcPqSR/B05gOUk6Ktm9hV0BE0T9BhshHZ21YrK JbggGJUCy61Z6X4AyAtmnkTX1sCdeXJgt8bgef/mi7L2w7Ft+atkvcuK9xWyOHUe mVolkz9RA9t1pLA+CMpaw/cLZbc/BZnSJMiamkKy+lqd/V1gnwNuaY67dlJF/9dV ZwDAapr47OxfHldsY5zOB1CqEaMPxw== =MCKV -----END PGP SIGNATURE----- --kkAfLrwsulP9QGaBpBojtbCTNUG4mUcEm-- From nobody Wed Aug 22 07:14:01 2018 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 0B5DE130DDD; Wed, 22 Aug 2018 07:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.29 X-Spam-Level: X-Spam-Status: No, score=-4.29 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_MED=-2.3, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=infineon.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 P2z1jF1NXLqI; Wed, 22 Aug 2018 07:13:58 -0700 (PDT) Received: from smtp2.infineon.com (smtp2.infineon.com [IPv6:2a00:18f0:1e00:4::4]) (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 A8176130DDC; Wed, 22 Aug 2018 07:13:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=infineon.com; i=@infineon.com; q=dns/txt; s=IFXMAIL; t=1534947238; x=1566483238; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=2noDcVZoz9Ap4grEPxIFqtmSkfsc56MBcF8F8BYkYIY=; b=apZYzMytVepnmT2Hn3ObziVHw9AkJh+CdumgTE5eu26H4Z6VJRc4mlOE KzEHp+ocQEUe3N+SquWNN5/TbtpeGy+jRxvorulhgVVXExllpmrWAhixh KN7Q4kr3GSkqSL+kUAh3sz8jKs/jqwBm16sTxmAYM7ZPKYWnE2Tg4ubv7 M=; X-SBRS: None X-IronPort-AV: E=McAfee;i="5900,7806,8992"; a="77339520" X-IronPort-AV: E=Sophos;i="5.53,274,1531778400"; d="scan'208";a="77339520" Received: from unknown (HELO mucxv001.muc.infineon.com) ([172.23.11.16]) by smtp2.infineon.com with ESMTP/TLS/AES256-GCM-SHA384; 22 Aug 2018 16:13:54 +0200 Received: from MUCSE707.infineon.com (MUCSE707.infineon.com [172.23.7.81]) by mucxv001.muc.infineon.com (Postfix) with ESMTPS; Wed, 22 Aug 2018 16:13:54 +0200 (CEST) Received: from MUCSE701.infineon.com (172.23.7.90) by MUCSE707.infineon.com (172.23.7.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1466.3; Wed, 22 Aug 2018 16:13:53 +0200 Received: from MUCSE702.infineon.com (172.23.7.91) by MUCSE701.infineon.com (172.23.7.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1466.3; Wed, 22 Aug 2018 16:13:54 +0200 Received: from MUCSE702.infineon.com ([fe80::88ef:90c6:2960:fe26]) by MUCSE702.infineon.com ([fe80::88ef:90c6:2960:fe26%17]) with mapi id 15.01.1466.008; Wed, 22 Aug 2018 16:13:54 +0200 From: To: CC: , Thread-Topic: AES/FIPS Approved Algorithm Usage Thread-Index: AdQ6D7+D4cJKQB3WQqa3VdmEG//D4Q== Date: Wed, 22 Aug 2018 14:13:54 +0000 Message-ID: <6433f2b697f74428886660d1e62ba6a7@infineon.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.23.8.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [COSE] AES/FIPS Approved Algorithm Usage X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2018 14:14:00 -0000 All, In the context of SUIT we did some analysis how to 'map' SUIT Manifest and = Payload into some COSE Crypto Containers with the focus on usage of Algorit= hms, with the following properties: (1) Usage of FIPS Approved Algorithms AND (2) Usage of Cipher (AES) Based Algorithms=20 Below are some observations, potential suggestions based on our current und= erstanding we would like to share, in case others have interest in usage of= AES Based/FIPS Approved Algorithms in COSE. A. Cipher Based MAC [COSE-9.2] Currently AES-CBC-MAC is specified in COSE. Algorithm Identifier for AES-CMAC as specified in [800-38B]/[RFC4493] would= allow the FIPS approved AES-CMAC Algorithm for usage in COSE MAC Crypto Co= ntainers. B. Key Derivation Functions [COSE-11] For KDF Usage of Secrets that are _uniformly random_: _PRF_ Algorithm Identifier(s) based on CMAC, as specified in [800-38B]/[RFC= 4493] and approved in [800-108] would allow for an FIPS Approved Cipher bas= ed PRF. _KDF_ Algorithm Identifier(s) (specifying Modes of Iteration) that refer to= [800-108] FIPS Approved KDF Algorithm=A0=20 would present a preferred option to allow the Cipher based FIPS Approved KD= Fs in COSE, since [800-108] seems to be the relevant FIPS Approved KDF Spec= for the use case of secrets that are _uniformly random_. C. Content Key Distribution 'Direct Key with KDF' [COSE-12.1.2]=20 Algorithm Identifiers for Direct Key with KDF using the KDFs from Point=A0 = B. above would allow Cipher based FIPS Approved 'Direct Key with KDF' in Co= ntent Key Distribution/ Recipient Algorithms in COSE. D. AES Key Wrap [COSE-12.2.1] COSE Key Wrap is referring to [RFC3394], which is satisfying NIST Key Wrap = Requirements. My understanding is that COSE usage of [RFC3394] supports AES Key Wrap (KW)= Mode of [800-38F],=20 but does not support AES Key Wrap with Padding (KWP) Mode of [800-38F].=20 Algorithm Identifier for KWP would provide and additional Approved Key Wrap= Mode within COSE. Thanks, Markus [COSE-9.2] https://tools.ietf.org/html/rfc8152#section-9.2 [COSE-ref] https://tools.ietf.org/html/rfc8152#ref-MAC [COSE-11] https://tools.ietf.org/html/rfc8152#section-11 [COSE-12.1.2] https://tools.ietf.org/html/rfc8152#section-12.1.2 [COSE-12.2.1] https://tools.ietf.org/html/rfc8152#section-12.2.1 [RFC4493] https://tools.ietf.org/html/rfc4493 [800-38B] https://csrc.nist.gov/publications/detail/sp/800-38b/final [800-108] https://csrc.nist.gov/publications/detail/sp/800-108/final [800-38F] https://csrc.nist.gov/publications/detail/sp/800-38f/final From nobody Wed Aug 22 12:33:36 2018 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 C0A791292AD; Wed, 22 Aug 2018 12:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 JTpGQ52wNVrw; Wed, 22 Aug 2018 12:33:25 -0700 (PDT) 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 1148A12426A; Wed, 22 Aug 2018 12:33:25 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 22 Aug 2018 12:29:32 -0700 From: Jim Schaad To: , CC: , References: <6433f2b697f74428886660d1e62ba6a7@infineon.com> In-Reply-To: <6433f2b697f74428886660d1e62ba6a7@infineon.com> Date: Wed, 22 Aug 2018 12:33:16 -0700 Message-ID: <006c01d43a4e$fb12f250$f138d6f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQNy9adOjxZVgmRU/HVQHs/vKM+a96GOrhZQ Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [COSE] AES/FIPS Approved Algorithm Usage X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2018 19:33:28 -0000 > -----Original Message----- > From: COSE On Behalf Of > Markus.Gueller@infineon.com > Sent: Wednesday, August 22, 2018 7:14 AM > To: cose@ietf.org > Cc: Ralph.Hamm@infineon.com; suit@ietf.org > Subject: [COSE] AES/FIPS Approved Algorithm Usage >=20 > All, >=20 > In the context of SUIT we did some analysis how to 'map' SUIT Manifest = and > Payload into some COSE Crypto Containers with the focus on usage of > Algorithms, with the following properties: >=20 > (1) Usage of FIPS Approved Algorithms AND > (2) Usage of Cipher (AES) Based Algorithms >=20 > Below are some observations, potential suggestions based on our = current > understanding we would like to share, in case others have interest in usage of > AES Based/FIPS Approved Algorithms in COSE. >=20 >=20 > A. Cipher Based MAC [COSE-9.2] >=20 > Currently AES-CBC-MAC is specified in COSE. > Algorithm Identifier for AES-CMAC as specified in [800-38B]/[RFC4493] would > allow the FIPS approved AES-CMAC Algorithm for usage in COSE MAC = Crypto > Containers. >=20 >=20 > B. Key Derivation Functions [COSE-11] >=20 > For KDF Usage of Secrets that are _uniformly random_: >=20 > _PRF_ Algorithm Identifier(s) based on CMAC, as specified in [800- > 38B]/[RFC4493] and approved in [800-108] would allow for an FIPS = Approved > Cipher based PRF. >=20 > _KDF_ Algorithm Identifier(s) (specifying Modes of Iteration) that = refer to [800- > 108] FIPS Approved KDF Algorithm would present a preferred option to = allow > the Cipher based FIPS Approved KDFs in COSE, since [800-108] seems to = be the > relevant FIPS Approved KDF Spec for the use case of secrets that are _uniformly > random_. >=20 >=20 > C. Content Key Distribution 'Direct Key with KDF' [COSE-12.1.2] >=20 > Algorithm Identifiers for Direct Key with KDF using the KDFs from = Point=A0 B. > above would allow Cipher based FIPS Approved 'Direct Key with KDF' in Content > Key Distribution/ Recipient Algorithms in COSE. >=20 >=20 > D. AES Key Wrap [COSE-12.2.1] >=20 > COSE Key Wrap is referring to [RFC3394], which is satisfying NIST Key = Wrap > Requirements. > My understanding is that COSE usage of [RFC3394] supports AES Key Wrap > (KW) Mode of [800-38F], but does not support AES Key Wrap with Padding > (KWP) Mode of [800-38F]. > Algorithm Identifier for KWP would provide and additional Approved Key Wrap > Mode within COSE. I am trying to figure out what you believe that is going to be added by this. Unless you see a need to have authenticated attributes at the key wrap level there is no additional benefit from using the KWP mode rather than the KW mode. As these have the same construction and are built on = the same primitive they have the same set of variabilities. Jim >=20 >=20 >=20 > Thanks, > Markus >=20 >=20 > [COSE-9.2] https://tools.ietf.org/html/rfc8152#section-9.2 > [COSE-ref] https://tools.ietf.org/html/rfc8152#ref-MAC > [COSE-11] https://tools.ietf.org/html/rfc8152#section-11 > [COSE-12.1.2] https://tools.ietf.org/html/rfc8152#section-12.1.2 > [COSE-12.2.1] https://tools.ietf.org/html/rfc8152#section-12.2.1 >=20 >=20 > [RFC4493] https://tools.ietf.org/html/rfc4493 > [800-38B] https://csrc.nist.gov/publications/detail/sp/800-38b/final >=20 > [800-108] https://csrc.nist.gov/publications/detail/sp/800-108/final >=20 > [800-38F] https://csrc.nist.gov/publications/detail/sp/800-38f/final >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Wed Aug 22 18:46:27 2018 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 18905130E53 for ; Wed, 22 Aug 2018 18:46:26 -0700 (PDT) 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_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 MTiALjUXLYDS for ; Wed, 22 Aug 2018 18:46:23 -0700 (PDT) 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 64F60130E52 for ; Wed, 22 Aug 2018 18:46:23 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 22 Aug 2018 18:42:31 -0700 From: Jim Schaad To: References: <153498664638.21061.8690156111346607732.idtracker@ietfa.amsl.com> In-Reply-To: <153498664638.21061.8690156111346607732.idtracker@ietfa.amsl.com> Date: Wed, 22 Aug 2018 18:46:15 -0700 Message-ID: <008801d43a83$15cb2a70$41617f50$@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: AQJm/4bq+Igf4SAsr1stcNVUsNZGaqOnBxNA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [COSE] FW: New Version Notification for draft-schaad-cose-rfc8152bis-algs-00.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2018 01:46:26 -0000 -----Original Message----- From: internet-drafts@ietf.org =20 Sent: Wednesday, August 22, 2018 6:11 PM To: Jim Schaad Subject: New Version Notification for = draft-schaad-cose-rfc8152bis-algs-00.txt A new version of I-D, draft-schaad-cose-rfc8152bis-algs-00.txt has been successfully submitted by Jim Schaad and posted to the IETF = repository. Name: draft-schaad-cose-rfc8152bis-algs Revision: 00 Title: CBOR Algoritms for Object Signing and Encryption (COSE) Document date: 2018-08-22 Group: Individual Submission Pages: 64 URL: = https://www.ietf.org/internet-drafts/draft-schaad-cose-rfc8152bis-algs-00= .txt Status: = https://datatracker.ietf.org/doc/draft-schaad-cose-rfc8152bis-algs/ Htmlized: = https://tools.ietf.org/html/draft-schaad-cose-rfc8152bis-algs-00 Htmlized: = https://datatracker.ietf.org/doc/html/draft-schaad-cose-rfc8152bis-algs Abstract: Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. COSE additionally describes how to represent cryptographic keys using CBOR. In this specification the conventions for the use of a number of cryptographic algorithms with COSE. The details of the structure of COSE are defined in [I-D.schaad-cose-rfc8152bis-struct]. This document along with [I-D.schaad-cose-rfc8152bis-struct] obsoletes RFC8152. = =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. The IETF Secretariat From nobody Wed Aug 22 18:48:22 2018 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 4F2E6130E53 for ; Wed, 22 Aug 2018 18:48:20 -0700 (PDT) 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_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 9aseoMqJeQ8O for ; Wed, 22 Aug 2018 18:48:17 -0700 (PDT) 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 2785C130E52 for ; Wed, 22 Aug 2018 18:48:17 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 22 Aug 2018 18:44:25 -0700 From: Jim Schaad To: References: <153498665967.21041.12044055351793921297.idtracker@ietfa.amsl.com> In-Reply-To: <153498665967.21041.12044055351793921297.idtracker@ietfa.amsl.com> Date: Wed, 22 Aug 2018 18:48:09 -0700 Message-ID: <008901d43a83$59b57ce0$0d2076a0$@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: AQG7DYqrsxq/tMiC7JwUw8cBYT+OGaT+6xfA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [COSE] FW: New Version Notification for draft-schaad-cose-rfc8152bis-struct-00.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2018 01:48:20 -0000 I have published two different drafts that between them cover all of RFC = 8152. There actually is overlap between them because I have not figured = out things like: * Should the examples be the structure or the algs draft. Arguments = exist for both points of view. * How should the IANA registrations be split up between the two drafts = for the algorithm specific registries? Creation in struct or in algs? Jim -----Original Message----- From: internet-drafts@ietf.org =20 Sent: Wednesday, August 22, 2018 6:11 PM To: Jim Schaad Subject: New Version Notification for = draft-schaad-cose-rfc8152bis-struct-00.txt A new version of I-D, draft-schaad-cose-rfc8152bis-struct-00.txt has been successfully submitted by Jim Schaad and posted to the IETF = repository. Name: draft-schaad-cose-rfc8152bis-struct Revision: 00 Title: CBOR Object Signing and Encryption (COSE) - Structures and = Process Document date: 2018-08-22 Group: Individual Submission Pages: 85 URL: = https://www.ietf.org/internet-drafts/draft-schaad-cose-rfc8152bis-struct-= 00.txt Status: = https://datatracker.ietf.org/doc/draft-schaad-cose-rfc8152bis-struct/ Htmlized: = https://tools.ietf.org/html/draft-schaad-cose-rfc8152bis-struct-00 Htmlized: = https://datatracker.ietf.org/doc/html/draft-schaad-cose-rfc8152bis-struct= Abstract: Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document along with [I-D.schaad-cose-rfc8152bis-algs] obsoletes RFC8152. = =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. The IETF Secretariat From nobody Wed Aug 22 22:43:06 2018 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 1D9BB12F1A6 for ; Wed, 22 Aug 2018 22:43:04 -0700 (PDT) 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, 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 f89bpnBIXOiv for ; Wed, 22 Aug 2018 22:43:02 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 2849712F18C for ; Wed, 22 Aug 2018 22:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w7N5gNLc003688; Thu, 23 Aug 2018 07:42:23 +0200 (CEST) Received: from [192.168.217.102] (p54A6C24D.dip0.t-ipconnect.de [84.166.194.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41wtbM3LRvzDWvR; Thu, 23 Aug 2018 07:42:23 +0200 (CEST) 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: <008901d43a83$59b57ce0$0d2076a0$@augustcellars.com> Date: Thu, 23 Aug 2018 07:42:22 +0200 Cc: cose@ietf.org X-Mao-Original-Outgoing-Id: 556695740.384751-67ba3dd796fefbd33afd68e456ad84be Content-Transfer-Encoding: quoted-printable Message-Id: References: <153498665967.21041.12044055351793921297.idtracker@ietfa.amsl.com> <008901d43a83$59b57ce0$0d2076a0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [COSE] FW: New Version Notification for draft-schaad-cose-rfc8152bis-struct-00.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2018 05:43:04 -0000 On Aug 23, 2018, at 03:48, Jim Schaad wrote: >=20 > * How should the IANA registrations be split up between the two drafts = for the algorithm specific registries? Creation in struct or in algs? That=E2=80=99s a weird thing about respinning a document that makes IANA = registrations: The registrations are already made, so you don=E2=80=99t need to respin = the document! Of course, there is specification that goes alongside those = registrations, and you may want to respin that text, but apart from = that, there fundamentally is no need for re-making those registrations. = You also may want to take the opportunity to simply document what is in = the registry in a more structured way than is possible by the simple = registration process. (You also may want to respin the policy definitions around the = registries.) Gr=C3=BC=C3=9Fe, Carsten