From nobody Mon Aug 1 01:21:48 2016 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 A817712D0B1 for ; Mon, 1 Aug 2016 01:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.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 tLMyZnMZqL1s for ; Mon, 1 Aug 2016 01:21:44 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 0C0DF12D1CA for ; Mon, 1 Aug 2016 01:21:43 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id i5so232186366wmg.0 for ; Mon, 01 Aug 2016 01:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EAPGQdROokCMfnz3KGskgl1LN0ujL5ffHM7JjvKktBY=; b=nAPG8mKyvzF8YzF0uD3U9iLMm9F0HxHLPJ6a2ZRlCRLDlQZw8IIs3nipD8Bafu8Bjd g6RCiXwxX4gjKgdx38kEXH1gSV9Ggj3qOfD9Pu8Zdz6QVCHjgTtXqmA9FP7mev3TlM+e XU/D6UKyQhIAc3LwEqD4924JJnmuP7gkkFg9WcojmFf4WR0hGgzqSKu/Mt1q30+5EkKC HPOopPOFpQ3q+dwoPulkHzf6MqQf8rVTG4YBOYaMpOCw1iPUUF53rvFp4sjWRJPIlhaw DREb+In0swbNNF6JMMUzTFr5NPI1R0MUrMpgReoiUBCDgxjh3VKZR1g+0anFwcgyXZrU itVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EAPGQdROokCMfnz3KGskgl1LN0ujL5ffHM7JjvKktBY=; b=HVrlASzZEDq9fTcwpRuzqk/wOogv12gy1NTnfeIm3J7CwW2rwbFFj11zhb9NT5fPVG MNy9xdyTQrlH34/oXlIJwNe9VSBYJamVDXpn454OBhRfwjwM2S3VHAtNchB65BkyTnkE MnZvEuSEAgg5in00qBS9Q9j4nQyALUgffXtMQVJgVDub73sa5SRVQEktWOKK0hXFu8wn 7ZQmC1rHTagL0dL+ye/51CkeYSt0mV4nvKassxitXnwCkGgtFyGyaxGJqxd5nYmhi5gq kzGQVX5G+6v/bYDdYNMJo7vjbb5QukaEOfAWKmCRH/ubRJZQQpyz1RSpE0tUWlYawaOd Tq8g== X-Gm-Message-State: AEkooutlVuplYxdlwIwNJ838VVZVzbILKK9BYpSOKQD7/h5w4+sBjET2DqRaiw/72tH16Y79Q0ila1WihZuCAw== X-Received: by 10.28.207.197 with SMTP id f188mr52952969wmg.69.1470039702127; Mon, 01 Aug 2016 01:21:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.169.231 with HTTP; Mon, 1 Aug 2016 01:21:41 -0700 (PDT) In-Reply-To: References: From: Samuel Erdtman Date: Mon, 1 Aug 2016 10:21:41 +0200 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=94eb2c0d42fe405f4b0538fe4a11 Archived-At: Cc: cose Subject: Re: [COSE] Adoption of RSA and alternative algorithms X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 08:21:47 -0000 --94eb2c0d42fe405f4b0538fe4a11 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable see inline On Fri, Jul 29, 2016 at 4:04 PM, Justin Richer wrote: > Hi all, hope that everyone is recovering from Berlin. As discussed in the > meeting last week, the working group is considering additional work on RS= A > and other algorithms in the COSE messages framework. These would be > published in a document separate from the core draft that is now on its > journey to RFC-land. > > The chairs would like to gauge the sentiment of the working group on a > number of items related to this proposed work. Please respond with your > answers to the list. > > > 1) Do you think it=E2=80=99s necessary or worthwhile to define RSA and ot= her > additional algorithms in the COSE messages framework? > > A) Yes, we should do an RSA/other-algs document > B) No, we shouldn=E2=80=99t do an RSA/other-algs document > C) Yes, but not right now > D) I need more information (please ask what you want to know) > E) I don=E2=80=99t give a flying rat whether this gets done or not > > A) I think RSA is interesting now and for a while, to make it easier to integrate with legacy systems. They would need to change stuff but they might have an RSA implementation they could reuse. > > > 2) If the work is adopted, where should it be done? > > A) Here in COSE (we=E2=80=99ll keep the group open for this item) > B) In other working group (please specify where; note that ACE is a > possible option) > C) I need more information (ask what you want to know) > D) I don=E2=80=99t give a flying rat where this happens > D) Don=C2=B4t care > > 3) If the work is adopted, which draft is a good starting point? > > A) Jim=E2=80=99s draft: https://tools.ietf.org/html/draft-schaad-cose-alg= -01 > B) Mike=E2=80=99s draft: https://tools.ietf.org/html/draft-jones-cose-rsa= -00 > C) Some other draft (please tell us which one it is or offer to write it > yourself) > D) I need more information (ask what you want to know) > E) I don=E2=80=99t give a flying rat which document we start with > > > E) Don=C2=B4t care, they look the same to me. > > > We=E2=80=99re going to keep this thread open for two weeks at the AD=E2= =80=99s request, > and the chairs will try to make a consensus call at the end of that time > period. > > Thank you, > > =E2=80=94 Justin & Kepeng, your COSE chairs > > > * \. - - . > ' _ , -`. > ' _,' _,' > ' ,-' _/ > ' ,-' \ _/ > ' ,' \ _' > ' ' _\' > ' , _,-' \ _________ > \,_,--' \ \\_______\ > \ \\+=3D+=3D+=3D+\ > \ \\=3D+=3D+=3D+=3D\ > \ \\+=3D+=3D+=3D+\ > \ \\=3D+=3D+=3D+=3D\________ > \ \\+=3D+=3D+=3D+____----)) > \ \`---------.)))\\ > \ ||+=3D+=3D+=3D+=3D+=3D\\ /\\ > \ ||___________\\/ \\ > \ ||------------\\ > ejm \|| \\ > * > > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > --94eb2c0d42fe405f4b0538fe4a11 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
see inline

On Fri, Jul 29, 2016 at 4:04 PM, Justin Richer <jricher@mit.ed= u> wrote:
Hi all, hope that everyone is recovering from Berlin. As= discussed in the meeting last week, the working group is considering addit= ional work on RSA and other algorithms in the COSE messages framework. Thes= e would be published in a document separate from the core draft that is now= on its journey to RFC-land.

The chairs would like to ga= uge the sentiment of the working group on a number of items related to this= proposed work. Please respond with your answers to the list.

1) Do you think it=E2=80=99s necessary or worthw= hile to define RSA and other additional algorithms in the COSE messages fra= mework?

A) Yes, we should do an RSA/other-algs doc= ument
B) No, we shouldn=E2=80=99t do an RSA/other-algs document
C) Yes, but not right now
D) I need more information (pl= ease ask what you want to know)
E) I don=E2=80=99t give a flying = rat whether this gets done or not


A) I think RSA is interesting now and for a while, to mak= e it easier to integrate with legacy systems. They would need to change stu= ff but they might have an RSA implementation they could reuse.
=C2=A0


2) If the work is adopt= ed, where should it be done?

A) Here in COSE (we= =E2=80=99ll keep the group open for this item)
B) In other workin= g group (please specify where; note that ACE is a possible option)
C) I need more information (ask what you want to know)
D) I don= =E2=80=99t give a flying rat where this happens=C2=A0

D) Don=C2=B4t care
=C2=A0

___________________________= ____________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose


--94eb2c0d42fe405f4b0538fe4a11-- From nobody Tue Aug 2 15:22:40 2016 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 0B6B512D9DA for ; Tue, 2 Aug 2016 15:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.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 VpghMRIJILEJ for ; Tue, 2 Aug 2016 15:22:33 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 E722112D9D1 for ; Tue, 2 Aug 2016 15:22:31 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id o80so310194127wme.1 for ; Tue, 02 Aug 2016 15:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2uB03vX0PUzliz8CqtWtAbyNo0HzQb70MYW4x9wSo0c=; b=rEDpOwV/EUHwh9AnAl9ckAo47HwBSwelyet9Ie+R3f2pXWrjM1V3t25/qc8jnK+n1e JOJ6jazYeNmhBSXxC3yA9yLkyoq3O+fMz+fnubX3E5SVAnM9WIaLV+HcEXTvdCAAmWfx WlLi2QH6m79odLV4ejAeZ9lL9WIFRcqqBLbbR93eZMxNxhzThAyaaQsMODw2h5lXW0Wa R0ORJzGcD/avBANFW3PN1FJ+xU6mHfzgDdXAYRKdKOd0TEQnNxlo9zIghfDIWbrkl6q9 6t1DOYcjLIco3Kvd9mG3QY80rC03FP/t31OI0X4T9Fpqswhm18jbqbIFcwFzmugoGUDB +aMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2uB03vX0PUzliz8CqtWtAbyNo0HzQb70MYW4x9wSo0c=; b=aohXErMc6hyu8y7KQNy01JP/c7uy+seHjP3XmmQpTXZ8U/uvHAvDuWy0W1uIuNGip2 3RQVHw5WHqQ4AgDSfetBtJIHliB6F5WJP92EW0PFPaAF7HI7EdFnvfjWzpeBSQtawKtX lQY/hKGJsqRLfjlr/9MA+p1ATXFgflLTYlRGFq8rO695fV5xTFjOJvchO5zk9BrWiFmQ lRRf+OJrV4ABkqObsEQaeXQN8Ge7T8dgyJk94yc1DQzgEAzWT5LhsPDpvWCEuISmxkiq NI1pzoKywjer88FFc5kraF80S2og4isM0Y7CNsrNDJ1fVEL45gpT0fkaqhszV+fxnwVB qwHw== X-Gm-Message-State: AEkoouvbeAd2z1zzZsOozKDf0Zy7Rq0wiMJ89kQymimqFhfBhJhvj/W6TV9qUvEVBczTX3zfwmREyNLKnTpWbg== X-Received: by 10.194.103.3 with SMTP id fs3mr59433450wjb.115.1470176550125; Tue, 02 Aug 2016 15:22:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.169.231 with HTTP; Tue, 2 Aug 2016 15:22:29 -0700 (PDT) In-Reply-To: <00c501d1eb68$23eee540$6bccafc0$@augustcellars.com> References: <00c501d1eb68$23eee540$6bccafc0$@augustcellars.com> From: Samuel Erdtman Date: Wed, 3 Aug 2016 00:22:29 +0200 Message-ID: To: Jim Schaad , =?UTF-8?Q?G=C3=B6ran_Selander?= Content-Type: multipart/alternative; boundary=089e010d8a1c074d7d05391e2796 Archived-At: Cc: cose Subject: Re: [COSE] draft-ietf-cose-msg-15 review X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 22:22:38 -0000 --089e010d8a1c074d7d05391e2796 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the quick reply Jim, I have fond another thing I want to ask about and then I have added comments inline. I added you G=C3=B6ran in direct message because I had a question on a formulation that you had requested, search for your name in the response form Jim and you=C2=B4ll find the question. I might just be lacking in CBOR skills but to see it seems like an inconsistency 3. Header Parameters =E2=80=9CSenders SHOULD encode an empty protected map as a zero length binary object (i.e., the byte string h'a0'). This encoding is used because it is both shorter and the version used in the serialization structures for cryptographic computation.=E2=80= =9D Here it says that I should use the =E2=80=9Czero length binary object=E2=80= =9D since it is the form used in =E2=80=9Cthe serialization structures for cryptographic computation.=E2=80=9D, but in section =E2=80=9C4.4. Signing and Verification Process=E2=80=9D and =E2=80=9C6.3. How to compute and verify a MAC=E2=80=9D it says when creati= ng the MAC_structure or Sig_structure: =E2=80=9CThe protected attributes from the COSE_MAC structure. If there ar= e no protected attributes, a zero length bstr is used.=E2=80=9D and =E2=80=9CThe protected attributes from the body structure encoded in a bstr= type. If there are no protected attributes, a bstr of length zero is used.=E2=80= =9D //Samuel On Sun, Jul 31, 2016 at 10:14 PM, Jim Schaad wrote= : > First, thanks for the review comments. It is never too late until the RF= C > is actually published and even then a new version can be published to > address future issues. > > Individual comments inline > > Jim > > > From: Samuel Erdtman [mailto:samuel@erdtman.se] > Sent: Sunday, July 31, 2016 12:42 AM > To: cose ; Jim Schaad > Subject: draft-ietf-cose-msg-15 review > > Hi > > I after reading the specification a second time and started on a > JavaScript implementation things are starting to make sense and I like it= . > Maybe a bit long (feels like a mountain to climb) before starting to work > with it. However well done Jim and all others that has contributed. I lik= e > the combination of prose and CDDL, it is great to have the same thing > described in two ways. > > If it=C2=B4s not to late I would like to contribute with a set of comment= s. > > =3D=3D General comments > * Is it possible to link to tables it would be great not having to search > form them e.g. in section 3.1. where Common COSE Headers Parameters > referencing Table 2. > > [JLS] I am going to assume you are looking at the HTMLized version of th= e > document on the IETF web site. The links that are inserted are a function > of the tool that converts the document from text to HTML rather than a > function of the source document (which does have the links in the XML). = If > you look at the HTML version on the github site, then you can get the lin= ks > but will not have table numbers until a new version of xml2rfc is release= d > (assuming it has my bug fixes in it). Sorry, cannot help on this issue. > > * Encryption section, 5, was harder to read then Signing, section 4, and > Mac, section 6. It felt a more mixed up, but I don=E2=80=99t have any con= cert > suggestions that would make it much better. > > [JLS] I have a feeling that this is because of the recursive nature of ho= w > encryption is done. Mac does not suffer from that because all of the > recipient processing is covered in encryption. Without a specific > suggestion it is hard to figure out what to do. It will be interesting t= o > see if others have suggestions. > I=C2=B4ll reread and think about it. > * Is this specification registering a whole new set of algorithms? and > registries? for CWT we only add mappings but keep the attributes, this is > also much of the work done in the ACE framework, but when I read here it > looks like you have new registries for everything. would it not be better > to just have mappings here. > > [JLS] First, registries are cheap so the mere fact that we are creating a > large number of new registries is not, in and of itself, a problem. > I understand that the cost of creating is low. I was thinking in lines of not having to duplicate maintenance work and synergies of getting registry updates from two directions since the content is so similar. > > * Without going into a deeper analysis it looks like section 7 to 9, and > to some extent 10 and 11 are doing the same thing as JWA (RFC7518). Would > it be possible to not duplicate things from RFC7518. I think this reflect= s > in the new IANA registries setup too. I think it would be good if we coul= d > try to reuse more of the work gone into JOSE e.g. maybe only defining > mappings for the algorithm identifiers to CBOR labels/keys.. > > [JLS] I did consider re-using the JWA registries for the registries that = I > created, in the end I did not for a couple of reasons. The primary reaso= n > is that the there are some algorithms defined in the COSE document which > are not the same as are defined in JWA. The method of going from a ECDH > key agreement operation to a symmetric key is completely different both i= n > terms of the context structure and KDF algorithm used to do the > derivation. This would mean that one would start getting multiple > algorithms that appear to be the same but aren't in many details. There > are a couple of registries such as the Curve Table which are going to hav= e > the same contents, but it just seemed easier to continue making new > registries rather than try and figure out which should be duplicated and > which should be separate. Going in from the IANA web page, it is going t= o > be easier to just find all of the COSE registries by name if the start wi= th > the same string. > I can see your point, I might personally had selected another path, but I= =C2=B4m fine with your choice if no one else thinks it is a problem.. > > =3D=3D Section specific comments and questions > > =3D=3D=3D 16.4. COSE Algorithms Registry > > =E2=80=9CThe initial contents of the registry can be found in Table 10, > Table 9, Table 11, Table 5, Table 7, Table 8, Table 15, Table 16, > Table 17, and Table 18. The specification column for all rows in > that table should be this document.=E2=80=9D > * It would be great with links to the different sections (see general > comment about table links). > > [JLS] See comment above. > > > =3D=3D=3D 1.1. Design changes from JOSE > =E2=80=9CMACed messages have the ability to use the same set of recipient > algorithms as enveloped messages for obtaining the MAC > authentication key.=E2=80=9D > * Why is this called out for MACed messages, is this not true for signed > too? > > [JLS] No this is not true for signed messages. For MACed messages, one > needs to convey the secret symmetric key from the sender to the recipient > in the same way that one does this for encrypted messages. For signed > messages one needs to identify a public key, there is no need to keep tha= t > field secret. > My bad > > =3D=3D=3D 1.3. CBOR Grammar > =E2=80=9CWe therefore describe the CBOR structures in prose.=E2=80=9D > * I would prefer not to use =E2=80=98we=E2=80=99 and write something like= =E2=80=9CThe CBOR > structures are therefore describe in prose.=E2=80=9D > > [JLS] that is reasonable. > > =E2=80=9CThe collected CDDL can be extracted from the XML version of this > document via the following XPath expression below. (Depending on the > XPath evaluator one is using, it may be necessary to deal with > > as an entity.)=E2=80=9D > * Is the XML available for ready RFCs? I have only found it for drafts, i= f > not this comment might not be very helpful. > > [JLS] This depends on where one gets the RFC and how far into the future > one looks. It is true that currently only the text is available for an R= FC > on the RFC Editor web site, however if one goes through the data tracker > the XML is available. In the, hopefully not too distant future, the RFC > Editor web site is going to start having XML for RFCs as that is becoming > the official version of an RFC with HTML and other versions as just > instantiations of the XML. > Okay, if that is the case then it makes sense to keep it. > > > =3D=3D=3D 1.4. CBOR Related Terminology > =E2=80=9CIn COSE, we use strings, negative integers and unsigned > integers as map keys.=E2=80=9D > * Feels like mix of terms with unsigned and negative integers I think it > should be signed and unsigned or positive and negative integers. > > [JLS] Yeah, I had the same problem with this as well. These are the term= s > used by CBOR so blame them. I think the issue is that normally unsigned > integers includes zero, but positive integers do not include zero. I don= 't > know why they did not use signed and unsigned. > Okay > > =E2=80=9CThe integers are used for compactness of > encoding and easy comparison.=E2=80=9D > * A motivation for strings would be good too since the existence of the > option requires implementors to handle both (not crash if a string comes)= . > If I remember correctly the reason was was of development/debugging. > > [JLS] While that would be one motivation, it is not really the motivation > that I had. I was looking for a cheap way to increase the number of two > byte labels. The requirement not to crash is no different if the label i= s > a string or a floating point value. This requirement is in the next > paragraph. The code to ignore string labels until we have defined one i= s > not really a big issue. I have added some justification text on the gith= ub > version. > Thanks > > =3D=3D=3D 3. Header Parameters > =E2=80=9CTwo buckets are provided for each layer:=E2=80=9D > * This is the first time I see the term layer used, maybe an explanation > in the terms section > > =E2=80=9C(With the exception of the COSE_Sign structure, the > only data that needs to cross layers is the cryptographic key.)=E2=80= =9D > * Is the parentheses really required, I would just drop them. > [JLS] Fine. > > =E2=80=9CLabels in each of the maps MUST be unique. When processing mess= ages, > if a label appears multiple times, the message MUST be rejected as > malformed. Applications SHOULD perform the same checks that the same > label does not occur in both the protected and unprotected headers. > If the message is not rejected as malformed, attributes MUST be > obtained from the protected bucket before they are obtained from the > unprotected bucket.=E2=80=9D > * Does this mean that I can have algorithm in both protected and > unprotected bucket but that the protected one takes presence? Could we no= t > just forbid duplication over both buckets? > [JLS] Yes that is what the text means. The reason that this is a should > rather than must is that for some people might find the checks that all o= f > the headers are unique to be burdensome on small devices. Providing the > alternate method of getting the same result, that is the the protected > headers win, means that we will have a consistent set of implementations. > Removal of fields from the protected headers will cause failures to occur > while adding things by middle boxes to the unprotected headers will not > cause a cryptographic failure. > Okay > > =3D=3D=3D 3.1. Common COSE Headers Parameters > * Why is some of the headers shortened (alg, crit) but not all (content > type)? I would prefer if we could map as close to JOSE as possible and I > would also like to avoid spaces in the names because then I can very easi= ly > do JSON input to my implementation and have it do the transformation of > labels from strings to integers. When reading more I see that this applie= s > to more sections. > > [JLS] I have kept the same names where it seemed reasonable, but used new > names where it seemed more appropriate. For 'content type', what is > defined here does not have an exact match in the JWS world. It ends up > combining some of both the 'typ' and 'ctyp' fields of JOSE. If you have = a > JWT, then I have been told you put that into the 'typ' field of JWS, but = it > goes into the 'content type' field of COSE. The other two which have > spaces in them do not have a counterpart in JOSE. However, given that th= e > string names are just for discussion purposes I am not sure that using > really short names is generally a good way to go. > Would it not make sense then to have no shortened names. If I understand things correctly all labels have descriptions in the specification, there is no labels where we just refer to the JOSE description. I don=C2=B4t really need the shortening, what i need/want is names I can us= e directly in variable/constant names. In the implementation I=C2=B4m working= on I try to keep the user from knowing about the integer labels, letting the library do the translation to and from names and then it would be more convenient if the names where possible to user directly as variables/constants i.e. no spaces in the names. > > =E2=80=9CThis parameter MUST be present in the > COSE_Signature, COSE_Sign1, COSE_Encrypt, COSE_Encrypt0, COSE_Mac, > and COSE_Mac0 structures=E2=80=9D > * Should it not be COSE_Sign and not COSE_Signature? > > [JLS] No COSE_Signature is correct. There is no algorithm field for a > COSE_Sign as the signature algorithm needs to be different for each signe= r > when multiple signers are on a message. > Okay > > =E2=80=9C(The algorithm range is -1 to -65536; the higher > end is for more optional algorithm specific items.)=E2=80=9D > * How does this relate to =E2=80=9CInteger labels in the range -1 to -255= can be > omitted=E2=80=9D? > * With the =E2=80=9Chigher end=E2=80=9D are you referring to -1? it seem = strange to have > the more optional parameters in that end to me > [JLS] The intention is to say greater in absolute magnitude. If you have > a better term then please share it. Smaller and lower seem to have the > same problem as higher does. > That is a challenge, when I read it again I see two other problems what does "more optional" meed and where is the breaking point between more and less optional items (similar to 1024 for TCP and UDP ports). Maybe it would be okay to remove the content of the parentheses. > > =E2=80=9CAs the IV is authenticated by the > encryption process, it SHOULD be placed in the unprotected header > bucket.=E2=80=9D > * Is there a good reason for this SHOULD? why is it better to put it in > the unprotected header? if I could I would put all my headers in the > protected and not have to bother with the unprotected part. I would prefe= r > the phrasing under Partial IV to be =E2=80=9CAs the IV is authenticated b= y the > encryption process, this value can be placed in the unprotected header > bucket=E2=80=9D > [JLS] The strengthening of this statement was made at the request of G=C3= =B6ran > so he should probably respond. > > =E2=80=9CCOSE_Sign, COSE_Sign1, COSE_Signature, COSE_Encrypt, > COSE_recipient, COSE_Encrypt0, COSE_Mac and COSE_Mac0=E2=80=9D > * In table 2 it says that the counter signature is one or many > COSE_Signature, so it does not seem to match this statement? > * When is a counter signature an encryption? > > [JLS] You missed the preceding sentence "The counter signature can occur > as an unprotected attribute in any of the following structures" > It should have a "parameter" between "signature" and "can". > Now I get it, thanks > > =3D=3D=3D 4.4. Signing and Verification Process > =E2=80=9CThe protected attributes from the body structure encoded in a > bstr type. If there are no protected attributes, a bstr of > length zero is used.=E2=80=9D > * Or a empty map CBOR encoded, right? > > [JLS] No, this is a case where the fact that there are two equivalent > encodings means we must choose one of them and only use it. The same byt= e > stream must always be obtained regardless of which of those two encodings > are used. > Of course. > > =3D=3D=3D 5.1. Enveloped COSE Structure > * This might have been up before, but has it been considered to swap plac= e > of ciphertext and recipients so that not the full message has to be > received before the CEK can be retrieved and maybe the ciphertext can be > decrypted as the message is received. > [JLS] No that was never discussed. Given that we are focused on small > messages I don't think that it would be a big win given that it would mak= e > the processing of the encryption structures more complicated. If that is > something that is desired, I would recommend that such an application use= s > a detached content and send the COSE structure followed by the ciphertext > stream. > Seems reasonable I thought about the added code complexity but not about the detached solution. > > * I cannot se any language on the key format in the recipients structure > is is always a COSE key? should the content type header be used to descri= be > the key format? or is it implicitly known by the application context? > > [JLS] There is no format for a key, it is a binary value. You are the > second person who seem to think it should be structured content. Please > let me know what in the text made you think this as it is clearly not > sufficiently explicit. > Not sure, I think I noted it when implementing (or thinking about) and had to understand how to take the decrypted CEK and input it to the underlying crypto engine. When implementing both sides i would know the format i.e. application context but if I would like to be more flexible and support to handle different key formats (e.g. in a server) then I would need to know the format of the key, right? > > =3D=3D=3D 5.3. Encryption Algorithm for AEAD algorithms > =3D=3D=3D 5.4. Encryption algorithm for AE algorithms > * Capital =E2=80=98A=E2=80=99 on algorithm or a small =E2=80=98a=E2=80=99= in section 5.3 headline > > [JLS] should be upper case > > * Heading =E2=80=9C5.4. Encryption algorithm for AE algorithms=E2=80=9D = and =E2=80=9C5.3. > Encryption Algorithm for AEAD algorithms=E2=80=9D is confusing compared t= o the > equivalent sections in mac and signing. I would like theses sections to > call out that it is how to encrypt and decrypt. > > [JLS] That makes sense > > =3D=3D=3D 7. Key Objects > * The CDDL example looks different, in my opinion worse, compared to the > other earlier examples. > > [JLS] This was done in response to an earlier review where it was noted > that the strings in the CDDL and the strings in the text did not match. > Since the numbers are not the same, even though the strings are it was > deemed better to remove the strings from the CDDL than to rewrite all of > the text which would have had other problems. > Okay, so if I understand it correctly there kty, kid etc. has other numeric label values in other context so to have the string in the CDDL might confuse since it is translated to other numeric values. Not sure I agree with earlier reviewer but okay. Why is it not possible to use the same numeric lable for kty, kid, etc in all places? > > * Are there any examples, I found no reference here. > > [JLS] Added reference > > > =3D=3D=3D 7.1. COSE Key Common Parameters > =E2=80=9CIf this parameter is present in the key structure, > the application MUST verify that this algorithm matches the > algorithm for which the key is being used.=E2=80=9D > * This is not reflected in Signing, Encryption and Mac section, maybe it > would be good to add something there too, if the relation to COSE_Key > should be close. > > [JLS] No I don't think it should be in those places as well. There is no > requirement that you need to be using COSE_Key objects to move keys > around. While it is easy for somethings, in other cases there are going = to > be completely different methods of moving keys. Since the place one draw= s > keys from may not always be a COSE_Key object, I don't think that putting > this text in everywhere is the best use of space. > Okay > > > =3D=3D=3D 16. IANA Considerations > Why is the major type included in the registry? Is it not enough with the > specification reference and having the definition there. In my opinion th= e > main goal of the registration is to avoid label collisions and and not to > provide more then basic information. > > [JLS] Your opinion is noted. I would prefer to have the type information > due to the fact that not all specifications are going to be public. Havi= ng > the type information will still allow for middle boxes to check that the > type is correct even if the content of the field is not understood. > > =3D=3D=3D 17.2. COSE Testing Library > I would prefer test vectors in the specification compared to this github > link. > > [JLS] You were complaining earlier about the length of the document > already. If you want a printed RFC which contains the broken out example= s > then argue for that on the list, but I prefer having it outside of the > document as it makes things easier to correct if they are wrong. Also if > you look at the github link you will see that there are lot of examples > which are not in this document as it can be much more complete. > Okay, and you have created a great number of examples on the github pages, which is awesome, I have not yet understood exactly how I would use them but I guess I will by spending some time on it. > > Jim > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > --089e010d8a1c074d7d05391e2796 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the quick reply Jim, I have fond another t= hing I want to ask about and then I have added comments inline.

I added you G=C3=B6ran in direct message because I had a question on= a formulation that you had requested, search for your name in the response= form Jim and you=C2=B4ll find the question.


I might = just be lacking in CBOR skills but to see it seems like an inconsistency
3.=C2=A0 Header Parameters
=E2=80=9CSenders SHOULD encode an empty = protected map as a
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 zero length binary obj= ect (i.e., the byte string h'a0').=C2=A0 This
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 encoding is used because it is both shorter and the version us= ed
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in the serialization structures for cr= yptographic computation.=E2=80=9D
Here it says that I should use the =E2= =80=9Czero length binary object=E2=80=9D since it is the form used in =E2= =80=9Cthe serialization structures for cryptographic computation.=E2=80=9D,= but in section
=E2=80=9C4.4.=C2=A0 Signing and Verification Process=E2= =80=9D and
=E2=80=9C6.3.=C2=A0 How to compute and verify a MAC=E2=80=9D= it says when creating the MAC_structure or Sig_structure:
=E2=80=9CThe = protected attributes from the COSE_MAC structure.=C2=A0 If there are no pro= tected attributes, a zero length bstr is used.=E2=80=9D
and
=E2=80= =9CThe protected attributes from the body structure encoded in a bstr type.= =C2=A0 If there are no protected attributes, a bstr of length zero is used.= =E2=80=9D

//Samuel

On Sun, Jul 31, 2016 at 10:14 PM, Jim Schaad <ietf@= augustcellars.com> wrote:
F= irst, thanks for the review comments.=C2=A0 It is never too late until the = RFC is actually published and even then a new version can be published to a= ddress future issues.

Individual comments inline

Jim


From: Samuel Erdtman [mailto:samuel@er= dtman.se]
Sent: Sunday, July 31, 2016 12:42 AM
To: cose <cose@ietf.org>; Jim Sc= haad <ietf@augustcellars.com>
Subject: draft-ietf-cose-msg-15 review

Hi

I after reading the specification a second time and started on a JavaScript= implementation things are starting to make sense and I like it. Maybe a bi= t long (feels like a mountain to climb) before starting to work with it. Ho= wever well done Jim and all others that has contributed. I like the combina= tion of prose and CDDL, it is great to have the same thing described in two= ways.

If it=C2=B4s not to late I would like to contribute with a set of comments.=

=3D=3D General comments
* Is it possible to link to tables it would be great not having to search f= orm them e.g. in section 3.1. where Common COSE Headers Parameters referenc= ing Table 2.

[JLS]=C2=A0 I am going to assume you are looking at the HTMLized ver= sion of the document on the IETF web site. The links that are inserted are = a function of the tool that converts the document from text to HTML rather = than a function of the source document (which does have the links in the XM= L).=C2=A0 If you look at the HTML version on the github site, then you can = get the links but will not have table numbers until a new version of xml2rf= c is released (assuming it has my bug fixes in it).=C2=A0 Sorry, cannot hel= p on this issue.

* Encryption section, 5, was harder to read then Signing, section 4, and Ma= c, section 6. It felt a more mixed up, but I don=E2=80=99t have any concert= suggestions that would make it much better.

[JLS] I have a feeling that this is because of the recursive nature = of how encryption is done.=C2=A0 Mac does not suffer from that because all = of the recipient processing is covered in encryption.=C2=A0 Without a speci= fic suggestion it is hard to figure out what to do.=C2=A0 It will be intere= sting to see if others have suggestions.

* Is this specification registering a whole new set of algorithms? and regi= stries? for CWT we only add mappings but keep the attributes, this is also = much of the work done in the ACE framework, but when I read here it looks l= ike you have new registries for everything. would it not be better to just = have mappings here.

[JLS] First, registries are cheap so the mere fact that we are creat= ing a large number of new registries is not, in and of itself, a problem.


* Without going into a deeper analysis it looks like section 7 to 9, and to= some extent 10 and 11 are doing the same thing as JWA (RFC7518). Would it = be possible to not duplicate things from RFC7518. I think this reflects in = the new IANA registries setup too. I think it would be good if we could try= to reuse more of the work gone into JOSE e.g. maybe only defining mappings= for the algorithm identifiers to CBOR labels/keys..

[JLS] I did consider re-using the JWA registries for the registries = that I created, in the end I did not for a couple of reasons.=C2=A0 The pri= mary reason is that the there are some algorithms defined in the COSE docum= ent which are not the same as are defined in JWA.=C2=A0 =C2=A0The method of= going from a ECDH key agreement operation to a symmetric key is completely= different both in terms of the context structure and KDF algorithm used to= do the derivation.=C2=A0 This would mean that one would start getting mult= iple algorithms that appear to be the same but aren't in many details.= =C2=A0 There are a couple of registries such as the Curve Table which are g= oing to have the same contents, but it just seemed easier to continue makin= g new registries rather than try and figure out which should be duplicated = and which should be separate.=C2=A0 Going in from the IANA web page, it is = going to be easier to just find all of the COSE registries by name if the s= tart with the same string.


=3D=3D Section specific comments and questions

=3D=3D=3D 16.4.=C2=A0 COSE Algorithms Registry

=E2=80=9CThe initial contents of the registry can be found in Table 10,
=C2=A0 =C2=A0Table 9, Table 11, Table 5, Table 7, Table 8, Table 15, Table = 16,
=C2=A0 =C2=A0Table 17, and Table 18.=C2=A0 The specification column for all= rows in
=C2=A0 =C2=A0that table should be this document.=E2=80=9D
* It would be great with links to the different sections (see general comme= nt about table links).

[JLS] See comment above.


=3D=3D=3D 1.1.=C2=A0 Design changes from JOSE
=E2=80=9CMACed messages have the ability to use the same set of recipient =C2=A0 =C2=A0 =C2=A0 algorithms as enveloped messages for obtaining the MAC=
=C2=A0 =C2=A0 =C2=A0 authentication key.=E2=80=9D
* Why is this called out for MACed messages, is this not true for signed to= o?

[JLS] No this is not true for signed messages.=C2=A0 For MACed messa= ges, one needs to convey the secret symmetric key from the sender to the re= cipient in the same way that one does this for encrypted messages.=C2=A0 Fo= r signed messages one needs to identify a public key, there is no need to k= eep that field secret.

=
=C2=A0

=3D=3D=3D 1.3.=C2=A0 CBOR Grammar
=E2=80=9CWe therefore describe the CBOR structures in prose.=E2=80=9D
* I would prefer not to use =E2=80=98we=E2=80=99 and write something like = =E2=80=9CThe CBOR structures are therefore describe in prose.=E2=80=9D

[JLS] that is reasonable.

=E2=80=9CThe collected CDDL can be extracted from the XML version of this =C2=A0 =C2=A0document via the following XPath expression below.=C2=A0 (Depe= nding on the
=C2=A0 =C2=A0XPath evaluator one is using, it may be necessary to deal with= &gt;
=C2=A0 =C2=A0as an entity.)=E2=80=9D
* Is the XML available for ready RFCs? I have only found it for drafts, if = not this comment might not be very helpful.

[JLS] This depends on where one gets the RFC and how far into the fu= ture one looks.=C2=A0 It is true that currently only the text is available = for an RFC on the RFC Editor web site, however if one goes through the data= tracker the XML is available. In the, hopefully not too distant future, th= e RFC Editor web site is going to start having XML for RFCs as that is beco= ming the official version of an RFC with HTML and other versions as just in= stantiations of the XML.

Okay, if that = is the case then it makes sense to keep it.
=C2=A0


=3D=3D=3D 1.4.=C2=A0 CBOR Related Terminology
=E2=80=9CIn COSE, we use strings, negative integers and unsigned
=C2=A0 =C2=A0integers as map keys.=E2=80=9D
* Feels like mix of terms with unsigned and negative integers I think it sh= ould be signed and unsigned or positive and negative integers.

[JLS] Yeah, I had the same problem with this as well.=C2=A0 These ar= e the terms used by CBOR so blame them.=C2=A0 I think the issue is that nor= mally unsigned integers includes zero, but positive integers do not include= zero.=C2=A0 I don't know why they did not use signed and unsigned.
=

Okay
=C2=A0

=E2=80=9CThe integers are used for compactness of
=C2=A0 =C2=A0encoding and easy comparison.=E2=80=9D
* A motivation for strings would be good too since the existence of the opt= ion requires implementors to handle both (not crash if a string comes). If = I remember correctly the reason was was of development/debugging.

[JLS] While that would be one motivation, it is not really the motiv= ation that I had.=C2=A0 I was looking for a cheap way to increase the numbe= r of two byte labels.=C2=A0 The requirement not to crash is no different if= the label is a string or a floating point value.=C2=A0 This requirement is= in the next paragraph.=C2=A0 =C2=A0The code to ignore string labels until = we have defined one is not really a big issue.=C2=A0 I have added some just= ification text on the github version.=C2=A0

=
Thanks
=C2=A0

=3D=3D=3D 3.=C2=A0 Header Parameters
=E2=80=9CTwo buckets are provided for each layer:=E2=80=9D
* This is the first time I see the term layer used, maybe an explanation in= the terms section

=E2=80=9C(With the exception of the COSE_Sign structure, the
=C2=A0 =C2=A0only data that needs to cross layers is the cryptographic key.= )=E2=80=9D
* Is the parentheses really required, I would just drop them.
[JLS] Fine.

=E2=80=9CLabels in each of the maps MUST be unique.=C2=A0 When processing m= essages,
=C2=A0 =C2=A0if a label appears multiple times, the message MUST be rejecte= d as
=C2=A0 =C2=A0malformed.=C2=A0 Applications SHOULD perform the same checks t= hat the same
=C2=A0 =C2=A0label does not occur in both the protected and unprotected hea= ders.
=C2=A0 =C2=A0If the message is not rejected as malformed, attributes MUST b= e
=C2=A0 =C2=A0obtained from the protected bucket before they are obtained fr= om the
=C2=A0 =C2=A0unprotected bucket.=E2=80=9D
* Does this mean that I can have algorithm in both protected and unprotecte= d bucket but that the protected one takes presence? Could we not just forbi= d duplication over both buckets?
[JLS] Yes that is what the text means.=C2=A0 The reason that this is= a should rather than must is that for some people might find the checks th= at all of the headers are unique to be burdensome on small devices.=C2=A0 P= roviding the alternate method of getting the same result, that is the the p= rotected headers win, means that we will have a consistent set of implement= ations.=C2=A0 Removal of fields from the protected headers will cause failu= res to occur while adding things by middle boxes to the unprotected headers= will not cause a cryptographic failure.

Okay
=C2=A0

=3D=3D=3D 3.1.=C2=A0 Common COSE Headers Parameters
* Why is some of the headers shortened (alg, crit) but not all (content typ= e)? I would prefer if we could map as close to JOSE as possible and I would= also like to avoid spaces in the names because then I can very easily do J= SON input to my implementation and have it do the transformation of labels = from strings to integers. When reading more I see that this applies to more= sections.

[JLS] I have kept the same names where it seemed reasonable, but use= d new names where it seemed more appropriate.=C2=A0 For 'content type&#= 39;, what is defined here does not have an exact match in the JWS world.=C2= =A0 It ends up combining some of both the 'typ' and 'ctyp' = fields of JOSE.=C2=A0 If you have a JWT, then I have been told you put that= into the 'typ' field of JWS, but it goes into the 'content typ= e' field of COSE.=C2=A0 =C2=A0 The other two which have spaces in them = do not have a counterpart in JOSE.=C2=A0 However, given that the string nam= es are just for discussion purposes I am not sure that using really short n= ames is generally a good way to go.


=E2=80=9CThis parameter MUST be present in the
=C2=A0 =C2=A0 =C2=A0 COSE_Signature, COSE_Sign1, COSE_Encrypt, COSE_Encrypt= 0, COSE_Mac,
=C2=A0 =C2=A0 =C2=A0 and COSE_Mac0 structures=E2=80=9D
* Should it not be COSE_Sign and not COSE_Signature?

[JLS] No COSE_Signature is correct.=C2=A0 There is no algorithm fiel= d for a COSE_Sign as the signature algorithm needs to be different for each= signer when multiple signers are on a message.

Okay
=C2=A0

=E2=80=9C(The algorithm range is -1 to -65536; the higher
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0end is for more optional algorithm specif= ic items.)=E2=80=9D
* How does this relate to =E2=80=9CInteger labels in the range -1 to -255 c= an be omitted=E2=80=9D?
* With the =E2=80=9Chigher end=E2=80=9D are you referring to -1? it seem st= range to have the more optional parameters in that end to me
[JLS] The intention is to say greater in absolute magnitude.=C2=A0 I= f you have a better term then please share it.=C2=A0 Smaller and lower seem= to have the same problem as higher does.

That is a challenge, when I read it again I see two other problems what = does "more optional" meed and where is the breaking point between= more and less optional items (similar to 1024 for TCP and UDP ports). Mayb= e it would be okay to remove the content of the parentheses.

=E2=80=9CAs the IV is authenticated by the
=C2=A0 =C2=A0 =C2=A0 encryption process, it SHOULD be placed in the unprote= cted header
=C2=A0 =C2=A0 =C2=A0 bucket.=E2=80=9D
* Is there a good reason for this SHOULD? why is it better to put it in the= unprotected header? if I could I would put all my headers in the protected= and not have to bother with the unprotected part. I would prefer the phras= ing under Partial IV to be =E2=80=9CAs the IV is authenticated by the encry= ption process, this value can be placed in the unprotected header bucket=E2= =80=9D
[JLS] The strengthening of this statement was made at the request of= G=C3=B6ran so he should probably respond.

=E2=80=9CCOSE_Sign, COSE_Sign1, COSE_Signature, COSE_Encrypt,
=C2=A0 =C2=A0 =C2=A0 COSE_recipient, COSE_Encrypt0, COSE_Mac and COSE_Mac0= =E2=80=9D
* In table 2 it says that the counter signature is one or many COSE_Signatu= re, so it does not seem to match this statement?
* When is a counter signature an encryption?

[JLS] You missed the preceding sentence "The counter signature = can occur as an unprotected attribute in any of the following structures&qu= ot;
It should have a "parameter" between "signature" and &q= uot;can".

Now I get it, thanks
=
=C2=A0

=3D=3D=3D 4.4.=C2=A0 Signing and Verification Process
=E2=80=9CThe protected attributes from the body structure encoded in a
=C2=A0 =C2=A0 =C2=A0 =C2=A0bstr type.=C2=A0 If there are no protected attri= butes, a bstr of
=C2=A0 =C2=A0 =C2=A0 =C2=A0length zero is used.=E2=80=9D
* Or a empty map CBOR encoded, right?

[JLS] No, this is a case where the fact that there are two equivalen= t encodings means we must choose one of them and only use it.=C2=A0 The sam= e byte stream must always be obtained regardless of which of those two enco= dings are used.

Of course.
=C2=A0

=3D=3D=3D 5.1.=C2=A0 Enveloped COSE Structure
* This might have been up before, but has it been considered to swap place = of ciphertext and recipients so that not the full message has to be receive= d before the CEK can be retrieved and maybe the ciphertext can be decrypted= as the message is received.
[JLS] No that was never discussed.=C2=A0 Given that we are focused o= n small messages I don't think that it would be a big win given that it= would make the processing of the encryption structures more complicated.= =C2=A0 If that is something that is desired, I would recommend that such an= application uses a detached content and send the COSE structure followed b= y the ciphertext stream.


* I cannot se any language on the key format in the recipients structure is= is always a COSE key? should the content type header be used to describe t= he key format? or is it implicitly known by the application context?

[JLS] There is no format for a key, it is a binary value.=C2=A0 You = are the second person who seem to think it should be structured content.=C2= =A0 Please let me know what in the text made you think this as it is clearl= y not sufficiently explicit.


=3D=3D=3D 5.3.=C2=A0 Encryption Algorithm for AEAD algorithms
=3D=3D=3D 5.4.=C2=A0 Encryption algorithm for AE algorithms
* Capital =E2=80=98A=E2=80=99 on algorithm or a small =E2=80=98a=E2=80=99 i= n section 5.3 headline

[JLS] should be upper case

* Heading =E2=80=9C5.4.=C2=A0 Encryption algorithm for AE algorithms=E2=80= =9D and =E2=80=9C5.3.=C2=A0 Encryption Algorithm for AEAD algorithms=E2=80= =9D is confusing compared to the equivalent sections in mac and signing. I = would like theses sections to call out that it is how to encrypt and decryp= t.

[JLS] That makes sense

=3D=3D=3D 7.=C2=A0 Key Objects
* The CDDL example looks different, in my opinion worse, compared to the ot= her earlier examples.

[JLS] This was done in response to an earlier review where it was no= ted that the strings in the CDDL and the strings in the text did not match.= =C2=A0 Since the numbers are not the same, even though the strings are it w= as deemed better to remove the strings from the CDDL than to rewrite all of= the text which would have had other problems.

Okay, so if I understand it correctly there kty, kid etc. has other= numeric label values in other context so to have the string in the CDDL mi= ght confuse since it is translated to other numeric values. Not sure I agre= e with earlier reviewer but okay.
Why is it not possible to u= se the same numeric lable for kty, kid, etc in all places?
= =C2=A0

* Are there any examples, I found no reference here.

[JLS] Added reference


=3D=3D=3D 7.1.=C2=A0 COSE Key Common Parameters
=E2=80=9CIf this parameter is present in the key structure,
=C2=A0 =C2=A0 =C2=A0 the application MUST verify that this algorithm matche= s the
=C2=A0 =C2=A0 =C2=A0 algorithm for which the key is being used.=E2=80=9D * This is not reflected in Signing, Encryption and Mac section, maybe it wo= uld be good to add something there too, if the relation to COSE_Key should = be close.

[JLS] No I don't think it should be in those places as well.=C2= =A0 There is no requirement that you need to be using COSE_Key objects to m= ove keys around.=C2=A0 While it is easy for somethings, in other cases ther= e are going to be completely different methods of moving keys.=C2=A0 Since = the place one draws keys from may not always be a COSE_Key object, I don= 9;t think that putting this text in everywhere is the best use of space.

Okay
=C2=A0


=3D=3D=3D 16.=C2=A0 IANA Considerations
Why is the major type included in the registry? Is it not enough with the s= pecification reference and having the definition there. In my opinion the m= ain goal of the registration is to avoid label collisions and and not to pr= ovide more then basic information.

[JLS] Your opinion is noted.=C2=A0 I would prefer to have the type i= nformation due to the fact that not all specifications are going to be publ= ic.=C2=A0 Having the type information will still allow for middle boxes to = check that the type is correct even if the content of the field is not unde= rstood.

=3D=3D=3D 17.2.=C2=A0 COSE Testing Library
I would prefer test vectors in the specification compared to this github li= nk.

[JLS] You were complaining earlier about the length of the document = already.=C2=A0 If you want a printed RFC which contains the broken out exam= ples then argue for that on the list, but I prefer having it outside of the= document as it makes things easier to correct if they are wrong.=C2=A0 Als= o if you look at the github link you will see that there are lot of example= s which are not in this document as it can be much more complete.

Okay, and you have created a great number of exa= mples on the github pages, which is awesome, I have not yet understood exac= tly how I would use them but I guess I will by spending some time on it.
=C2=A0

Jim


_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

--089e010d8a1c074d7d05391e2796-- From nobody Tue Aug 2 22:59:08 2016 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 5FFD312D0CD for ; Tue, 2 Aug 2016 22:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 AYsU_6Fhxxod for ; Tue, 2 Aug 2016 22:59:05 -0700 (PDT) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 849A3120727 for ; Tue, 2 Aug 2016 22:59:05 -0700 (PDT) Received: from mfilter21-d.gandi.net (mfilter21-d.gandi.net [217.70.178.149]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 195F941C08F; Wed, 3 Aug 2016 07:59:04 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter21-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter21-d.gandi.net (mfilter21-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Q1WVp1utg56K; Wed, 3 Aug 2016 07:59:02 +0200 (CEST) X-Originating-IP: 93.199.227.76 Received: from nar-3.local (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 9DEEC41C08A; Wed, 3 Aug 2016 07:59:01 +0200 (CEST) Message-ID: <57A18824.2060603@tzi.org> Date: Wed, 03 Aug 2016 07:59:00 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Samuel Erdtman References: <00c501d1eb68$23eee540$6bccafc0$@augustcellars.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Jim Schaad , =?UTF-8?B?R8O2cmFuIFNlbGFuZGVy?= , cose Subject: Re: [COSE] draft-ietf-cose-msg-15 review X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 05:59:07 -0000 Samuel Erdtman wrote: > Senders SHOULD encode an empty protected map as a > zero length binary object (i.e., the byte string h'a0'). Oh. Good catch. It seems to me that the "i.e." refers to the "empty protected map" that you would find normally encoded as h'a0' (the encoding of which in turn is 0x41a0). This is then shortened to an empty byte string h'' (the encoding of which in turn is 0x40). The "i.e." could be read as referring to the latter (this is actually more a more likely reading), so it probably should be moved to the first half of the sentence. Grüße, Carsten From nobody Sat Aug 6 10:29:26 2016 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 7857C12D52C for ; Sat, 6 Aug 2016 10:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.247, 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 kvQ91mM8-4bM for ; Sat, 6 Aug 2016 10:29:21 -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 3809112D520 for ; Sat, 6 Aug 2016 10:29:20 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 6 Aug 2016 10:41:11 -0700 From: Jim Schaad To: 'Samuel Erdtman' , =?utf-8?Q?'G=C3=B6ran_Selander'?= References: <00c501d1eb68$23eee540$6bccafc0$@augustcellars.com> In-Reply-To: Date: Sat, 6 Aug 2016 10:29:12 -0700 Message-ID: <012c01d1f008$0e29a570$2a7cf050$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_012D_01D1EFCD.61D1F960" X-Mailer: Microsoft Outlook 16.0 thread-index: AQGkZvOQCuSjA72aUhH7wvP5+M98TQJetcK6AeQwCragdRLP8A== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: 'cose' Subject: Re: [COSE] draft-ietf-cose-msg-15 review X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2016 17:29:24 -0000 ------=_NextPart_000_012D_01D1EFCD.61D1F960 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Lots of comments inline. I have removed some of the things that seem to = be closed. =20 Jim =20 =20 From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Samuel Erdtman Sent: Tuesday, August 02, 2016 3:22 PM To: Jim Schaad ; G=C3=B6ran Selander = Cc: cose Subject: Re: [COSE] draft-ietf-cose-msg-15 review =20 Thanks for the quick reply Jim, I have fond another thing I want to ask = about and then I have added comments inline. I added you G=C3=B6ran in direct message because I had a question on a = formulation that you had requested, search for your name in the response = form Jim and you=C2=B4ll find the question. I might just be lacking in CBOR skills but to see it seems like an = inconsistency 3. Header Parameters =E2=80=9CSenders SHOULD encode an empty protected map as a zero length binary object (i.e., the byte string h'a0'). This encoding is used because it is both shorter and the version used in the serialization structures for cryptographic = computation.=E2=80=9D Does it help if this is re-written as: Senders SHOULD encode an empty protected map as a zero length binary = (encoding h=E2=80=9940=E2=80=99) rather than as a zero length map = wrapped in a binary (encoding h=E2=80=9941a0=E2=80=99). The zero length = binary encoding is preferred because it is both shorter and is the = encoding used in the serialization structures for cryptographic = computation. This fixes my CBOR encoding error as well as presenting both of the = encodings so it is clear what is being discussed. Here it says that I should use the =E2=80=9Czero length binary = object=E2=80=9D since it is the form used in =E2=80=9Cthe serialization = structures for cryptographic computation.=E2=80=9D, but in section=20 =E2=80=9C4.4. Signing and Verification Process=E2=80=9D and=20 =E2=80=9C6.3. How to compute and verify a MAC=E2=80=9D it says when = creating the MAC_structure or Sig_structure: =E2=80=9CThe protected attributes from the COSE_MAC structure. If there = are no protected attributes, a zero length bstr is used.=E2=80=9D=20 and=20 =E2=80=9CThe protected attributes from the body structure encoded in a = bstr type. If there are no protected attributes, a bstr of length zero = is used.=E2=80=9D //Samuel =20 On Sun, Jul 31, 2016 at 10:14 PM, Jim Schaad > wrote: First, thanks for the review comments. It is never too late until the = RFC is actually published and even then a new version can be published = to address future issues. Individual comments inline Jim From: Samuel Erdtman [mailto:samuel@erdtman.se = ] Sent: Sunday, July 31, 2016 12:42 AM To: cose >; Jim Schaad = > Subject: draft-ietf-cose-msg-15 review Hi I after reading the specification a second time and started on a = JavaScript implementation things are starting to make sense and I like = it. Maybe a bit long (feels like a mountain to climb) before starting to = work with it. However well done Jim and all others that has contributed. = I like the combination of prose and CDDL, it is great to have the same = thing described in two ways. If it=C2=B4s not to late I would like to contribute with a set of = comments. =3D=3D General comments * Encryption section, 5, was harder to read then Signing, section 4, and = Mac, section 6. It felt a more mixed up, but I don=E2=80=99t have any = concert suggestions that would make it much better. [JLS] I have a feeling that this is because of the recursive nature of = how encryption is done. Mac does not suffer from that because all of = the recipient processing is covered in encryption. Without a specific = suggestion it is hard to figure out what to do. It will be interesting = to see if others have suggestions. I=C2=B4ll reread and think about it.=20 =20 =3D=3D=3D 3.1. Common COSE Headers Parameters * Why is some of the headers shortened (alg, crit) but not all (content = type)? I would prefer if we could map as close to JOSE as possible and I = would also like to avoid spaces in the names because then I can very = easily do JSON input to my implementation and have it do the = transformation of labels from strings to integers. When reading more I = see that this applies to more sections. [JLS] I have kept the same names where it seemed reasonable, but used = new names where it seemed more appropriate. For 'content type', what is = defined here does not have an exact match in the JWS world. It ends up = combining some of both the 'typ' and 'ctyp' fields of JOSE. If you have = a JWT, then I have been told you put that into the 'typ' field of JWS, = but it goes into the 'content type' field of COSE. The other two = which have spaces in them do not have a counterpart in JOSE. However, = given that the string names are just for discussion purposes I am not = sure that using really short names is generally a good way to go. =20 Would it not make sense then to have no shortened names. If I understand = things correctly all labels have descriptions in the specification, = there is no labels where we just refer to the JOSE description. I don=C2=B4t really need the shortening, what i need/want is names I can = use directly in variable/constant names. In the implementation I=C2=B4m = working on I try to keep the user from knowing about the integer labels, = letting the library do the translation to and from names and then it = would be more convenient if the names where possible to user directly as = variables/constants i.e. no spaces in the names. =20 [JLS] I kept the short names for compatibility with JOSE so that people = would transition faster. However, if people thing we should I have no = problems with moving to longer names in all cases. =20 =20 =E2=80=9C(The algorithm range is -1 to -65536; the higher end is for more optional algorithm specific items.)=E2=80=9D * How does this relate to =E2=80=9CInteger labels in the range -1 to = -255 can be omitted=E2=80=9D? * With the =E2=80=9Chigher end=E2=80=9D are you referring to -1? it seem = strange to have the more optional parameters in that end to me [JLS] The intention is to say greater in absolute magnitude. If you = have a better term then please share it. Smaller and lower seem to have = the same problem as higher does. =20 That is a challenge, when I read it again I see two other problems what = does "more optional" meed and where is the breaking point between more = and less optional items (similar to 1024 for TCP and UDP ports). Maybe = it would be okay to remove the content of the parentheses. =20 [JLS] OK =E2=80=93 I am going to re-write this because it is just too = hard to keep as it is. =20 New text will be: =20 Integer label sin the range -1 to -128 can be omitted as they are = algorithm dependent. If an application can correctly process an = algorithm, it can be assumed that it will correctly process all of the = common parameters associated with that algorithm. Integer labels in the = range of -129 to -65536 SHOULD be included as these would be less common = parameters that might not be generally supported. =20 One of the ways that this might be implemented would be to add two new = parameters in the future to do something similar to = draft-selander-ace-cose-ecdhe, but without the worry about doing PFS. = We would define the following algorithm dependent items: =20 ECDH-SS-Assign-Key-With-kid ECDH-SS-Set-Key-Lifetime =20 When these items are used, the resultant key from the key agreement step = would be named with a kid and potentially given a lifetime (either in = messages or time) and then used in a sequence of future messages until = such a time as it expires. The static-static ECDH would provide the = needed information to do authorization which can then be placed on the = short time key. =20 If a client wants to use this feature, it could then put the new = attributes in the =E2=80=98crit=E2=80=99 field and know that the server = would reject the message if it does not support them. Alternatively, it = could just try and use them and hope for the best in terms of trying to = figure out if they are supported. A returned message might indicate = that the assign kid attribute is supported, but it would not indicate if = the key lifetime attribute is also supported. =20 =20 =20 =E2=80=9CAs the IV is authenticated by the encryption process, it SHOULD be placed in the unprotected header bucket.=E2=80=9D * Is there a good reason for this SHOULD? why is it better to put it in = the unprotected header? if I could I would put all my headers in the = protected and not have to bother with the unprotected part. I would = prefer the phrasing under Partial IV to be =E2=80=9CAs the IV is = authenticated by the encryption process, this value can be placed in the = unprotected header bucket=E2=80=9D [JLS] The strengthening of this statement was made at the request of = G=C3=B6ran so he should probably respond. =20 =3D=3D=3D 5.1. Enveloped COSE Structure * This might have been up before, but has it been considered to swap = place of ciphertext and recipients so that not the full message has to = be received before the CEK can be retrieved and maybe the ciphertext can = be decrypted as the message is received. [JLS] No that was never discussed. Given that we are focused on small = messages I don't think that it would be a big win given that it would = make the processing of the encryption structures more complicated. If = that is something that is desired, I would recommend that such an = application uses a detached content and send the COSE structure followed = by the ciphertext stream. =20 Seems reasonable I thought about the added code complexity but not about = the detached solution. =20 * I cannot se any language on the key format in the recipients structure = is is always a COSE key? should the content type header be used to = describe the key format? or is it implicitly known by the application = context? [JLS] There is no format for a key, it is a binary value. You are the = second person who seem to think it should be structured content. Please = let me know what in the text made you think this as it is clearly not = sufficiently explicit. =20 Not sure, I think I noted it when implementing (or thinking about) and = had to understand how to take the decrypted CEK and input it to the = underlying crypto engine. When implementing both sides i would know the = format i.e. application context but if I would like to be more flexible = and support to handle different key formats (e.g. in a server) then I = would need to know the format of the key, right? =20 [JLS] You are overthinking the problem. We only transport binary = secrets within the encrypted content portion of a recipient structure. = We do not transport EC or RSA keys here. I think that I am going to = look at modifying the description of ciphertext in the recipient = structure. =20 =3D=3D=3D 7. Key Objects * The CDDL example looks different, in my opinion worse, compared to the = other earlier examples. [JLS] This was done in response to an earlier review where it was noted = that the strings in the CDDL and the strings in the text did not match. = Since the numbers are not the same, even though the strings are it was = deemed better to remove the strings from the CDDL than to rewrite all of = the text which would have had other problems. =20 Okay, so if I understand it correctly there kty, kid etc. has other = numeric label values in other context so to have the string in the CDDL = might confuse since it is translated to other numeric values. Not sure I = agree with earlier reviewer but okay. Why is it not possible to use the same numeric lable for kty, kid, etc = in all places? [JLS] It would be possible to do that for the items assigned in this = document. However, these are kept in different registries and could = easily diverge in the future. Having a difference today can be thought = of as a way of making sure people are prepared for problems in the = future. If people really want to harmonize them I would not object. =20 =3D=3D=3D 17.2. COSE Testing Library I would prefer test vectors in the specification compared to this github = link. [JLS] You were complaining earlier about the length of the document = already. If you want a printed RFC which contains the broken out = examples then argue for that on the list, but I prefer having it outside = of the document as it makes things easier to correct if they are wrong. = Also if you look at the github link you will see that there are lot of = examples which are not in this document as it can be much more complete. =20 Okay, and you have created a great number of examples on the github = pages, which is awesome, I have not yet understood exactly how I would = use them but I guess I will by spending some time on it. =20 [JLS] If there is anything that I can do to make things clearer, please = be sure and let me know. One of the things that should be on my list is = to provide a better description of the JSON structure for the examples. = I am not sure if it is really self-explanatory or not. Also, please let = me know if you think the organization can be improved or if there are = missing examples. =20 Jim =20 =20 Jim _______________________________________________ COSE mailing list COSE@ietf.org =20 https://www.ietf.org/mailman/listinfo/cose =20 ------=_NextPart_000_012D_01D1EFCD.61D1F960 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Lots of = comments inline.=C2=A0 I have removed some of the things that seem to be = closed.

 

Jim

 

 

From:<= /b> = COSE [mailto:cose-bounces@ietf.org] On Behalf Of Samuel = Erdtman
Sent: Tuesday, August 02, 2016 3:22 PM
To: = Jim Schaad <ietf@augustcellars.com>; G=C3=B6ran Selander = <goran.selander@ericsson.com>
Cc: cose = <cose@ietf.org>
Subject: Re: [COSE] = draft-ietf-cose-msg-15 review

 

Thanks for the quick reply Jim, I have fond another = thing I want to ask about and then I have added comments = inline.


I added you = G=C3=B6ran in direct message because I had a question on a formulation = that you had requested, search for your name in the response form Jim = and you=C2=B4ll find the question.



I might just be = lacking in CBOR skills but to see it seems like an = inconsistency

3.  Header Parameters
=E2=80=9CSenders = SHOULD encode an empty protected map as = a
      zero length binary object (i.e., the = byte string h'a0').  This
      = encoding is used because it is both shorter and the version = used
      in the serialization structures = for cryptographic computation.=E2=80=9D

Does it help if this is re-written as:

Senders SHOULD encode an empty protected map as a zero length binary = (encoding h=E2=80=9940=E2=80=99) rather than as a zero length map = wrapped in a binary (encoding h=E2=80=9941a0=E2=80=99).=C2=A0 The zero = length binary encoding is preferred because it is both shorter and is = the encoding used in the serialization structures for cryptographic = computation.

This fixes my CBOR encoding error as well as presenting both of the = encodings so it is clear what is being = discussed.


Here it says that I should use the = =E2=80=9Czero length binary object=E2=80=9D since it is the form used in = =E2=80=9Cthe serialization structures for cryptographic = computation.=E2=80=9D, but in section
=E2=80=9C4.4.  Signing = and Verification Process=E2=80=9D and
=E2=80=9C6.3.  How to = compute and verify a MAC=E2=80=9D it says when creating the = MAC_structure or Sig_structure:
=E2=80=9CThe protected attributes = from the COSE_MAC structure.  If there are no protected attributes, = a zero length bstr is used.=E2=80=9D
and
=E2=80=9CThe protected = attributes from the body structure encoded in a bstr type.  If = there are no protected attributes, a bstr of length zero is = used.=E2=80=9D

//Samuel

 

On Sun, = Jul 31, 2016 at 10:14 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

First, = thanks for the review comments.  It is never too late until the RFC = is actually published and even then a new version can be published to = address future issues.

Individual comments = inline

Jim


From: Samuel Erdtman [mailto:samuel@erdtman.se]
Sent: = Sunday, July 31, 2016 12:42 AM
To: cose <cose@ietf.org>; Jim Schaad <ietf@augustcellars.com>
= Subject: draft-ietf-cose-msg-15 review

Hi

I after reading = the specification a second time and started on a JavaScript = implementation things are starting to make sense and I like it. Maybe a = bit long (feels like a mountain to climb) before starting to work with = it. However well done Jim and all others that has contributed. I like = the combination of prose and CDDL, it is great to have the same thing = described in two ways.

If it=C2=B4s not to late I would like to = contribute with a set of comments.

=3D=3D General = comments

* Encryption section, 5, was harder to read then = Signing, section 4, and Mac, section 6. It felt a more mixed up, but I = don=E2=80=99t have any concert suggestions that would make it much = better.

[JLS] I have a feeling that this is because of the = recursive nature of how encryption is done.  Mac does not suffer = from that because all of the recipient processing is covered in = encryption.  Without a specific suggestion it is hard to figure out = what to do.  It will be interesting to see if others have = suggestions.


I=C2=B4ll reread and think about it. =


 


=3D=3D=3D 3.1.  Common COSE Headers = Parameters
* Why is some of the headers shortened (alg, crit) but not = all (content type)? I would prefer if we could map as close to JOSE as = possible and I would also like to avoid spaces in the names because then = I can very easily do JSON input to my implementation and have it do the = transformation of labels from strings to integers. When reading more I = see that this applies to more sections.

[JLS] I have kept the = same names where it seemed reasonable, but used new names where it = seemed more appropriate.  For 'content type', what is defined here = does not have an exact match in the JWS world.  It ends up = combining some of both the 'typ' and 'ctyp' fields of JOSE.  If you = have a JWT, then I have been told you put that into the 'typ' field of = JWS, but it goes into the 'content type' field of COSE.    The = other two which have spaces in them do not have a counterpart in = JOSE.  However, given that the string names are just for discussion = purposes I am not sure that using really short names is generally a good = way to go.

 

Would it not make sense then to have no shortened = names. If I understand things correctly all labels have descriptions in = the specification, there is no labels where we just refer to the JOSE = description.

I don=C2=B4t = really need the shortening, what i need/want is names I can use directly = in variable/constant names. In the implementation I=C2=B4m working on I = try to keep the user from knowing about the integer labels, letting the = library do the translation to and from names and then it would be more = convenient if the names where possible to user directly as = variables/constants i.e. no spaces in the names.

 

[JLS] I kept the short names for compatibility with JOSE so that people = would transition faster.=C2=A0 However, if people thing we should I have = no problems with moving to longer names in all = cases.

 



 


=E2=80=9C(The algorithm range is -1 to -65536; the = higher
         end is for more optional = algorithm specific items.)=E2=80=9D
* How does this relate to = =E2=80=9CInteger labels in the range -1 to -255 can be = omitted=E2=80=9D?
* With the =E2=80=9Chigher end=E2=80=9D are you = referring to -1? it seem strange to have the more optional parameters in = that end to me
[JLS] The intention is to say greater in absolute = magnitude.  If you have a better term then please share it.  = Smaller and lower seem to have the same problem as higher = does.

 

That is a challenge, when I read it again I see two = other problems what does "more optional" meed and where is the = breaking point between more and less optional items (similar to 1024 for = TCP and UDP ports). Maybe it would be okay to remove the content of the = parentheses.

 

[JLS]=C2=A0 OK =E2=80=93 I am going to re-write this because it is just = too hard to keep as it is.

 

New text will be:

 

Integer label sin the range -1 to -128 can be omitted as they are = algorithm dependent.=C2=A0 If an application can correctly process an = algorithm, it can be assumed that it will correctly process all of the = common parameters associated with that algorithm.=C2=A0 Integer labels = in the range of -129 to -65536 SHOULD be included as these would be less = common parameters that might not be generally = supported.

 

<back to message>

One of the ways that this might be implemented would be to add two new = parameters in the future to do something similar to = draft-selander-ace-cose-ecdhe, but without the worry about doing = PFS.=C2=A0 We would define the following algorithm dependent = items:

 

ECDH-SS-Assign-Key-With-kid

ECDH-SS-Set-Key-Lifetime

 

When these items are used, the resultant key from the key agreement = step would be named with a kid and potentially given a lifetime (either = in messages or time) and then used in a sequence of future messages = until such a time as it expires.=C2=A0 The static-static ECDH would = provide the needed information to do authorization which can then be = placed on the short time key.

 

If a client wants to use this feature, it could then put the new = attributes in the =E2=80=98crit=E2=80=99 field and know that the server = would reject the message if it does not support them.=C2=A0 = Alternatively, it could just try and use them and hope for the best in = terms of trying to figure out if they are supported.=C2=A0 A returned = message might indicate that the assign kid attribute is supported, but = it would not indicate if the key lifetime attribute is also = supported.

 

 

 


=E2=80=9CAs the IV is authenticated by = the
      encryption process, it SHOULD be placed in = the unprotected header
      bucket.=E2=80=9D
* Is = there a good reason for this SHOULD? why is it better to put it in the = unprotected header? if I could I would put all my headers in the = protected and not have to bother with the unprotected part. I would = prefer the phrasing under Partial IV to be =E2=80=9CAs the IV is = authenticated by the encryption process, this value can be placed in the = unprotected header bucket=E2=80=9D
[JLS] The strengthening of this = statement was made at the request of G=C3=B6ran so he should probably = respond.

 




=3D=3D=3D 5.1.  Enveloped COSE Structure
* = This might have been up before, but has it been considered to swap place = of ciphertext and recipients so that not the full message has to be = received before the CEK can be retrieved and maybe the ciphertext can be = decrypted as the message is received.
[JLS] No that was never = discussed.  Given that we are focused on small messages I don't = think that it would be a big win given that it would make the processing = of the encryption structures more complicated.  If that is = something that is desired, I would recommend that such an application = uses a detached content and send the COSE structure followed by the = ciphertext stream.

 

Seems reasonable I thought about the added code = complexity but not about the detached = solution.

 


* I = cannot se any language on the key format in the recipients structure is = is always a COSE key? should the content type header be used to describe = the key format? or is it implicitly known by the application = context?

[JLS] There is no format for a key, it is a binary = value.  You are the second person who seem to think it should be = structured content.  Please let me know what in the text made you = think this as it is clearly not sufficiently = explicit.

 

Not sure, I think I noted it when implementing (or = thinking about) and had to understand how to take the decrypted CEK and = input it to the underlying crypto engine. When implementing both sides i = would know the format i.e. application context but if I would like to be = more flexible and support to handle different key formats (e.g. in a = server) then I would need to know the format of the key, = right?

 

[JLS] You are overthinking the problem.=C2=A0 We only transport binary = secrets within the encrypted content portion of a recipient = structure.=C2=A0 We do not transport EC or RSA keys here.=C2=A0=C2=A0 I = think that I am going to look at modifying the description of ciphertext = in the recipient structure.

 


=3D=3D=3D 7.  Key Objects
* The CDDL = example looks different, in my opinion worse, compared to the other = earlier examples.

[JLS] This was done in response to an earlier = review where it was noted that the strings in the CDDL and the strings = in the text did not match.  Since the numbers are not the same, = even though the strings are it was deemed better to remove the strings = from the CDDL than to rewrite all of the text which would have had other = problems.

 

Okay, so if I understand it correctly there kty, kid = etc. has other numeric label values in other context so to have the = string in the CDDL might confuse since it is translated to other numeric = values. Not sure I agree with earlier reviewer but = okay.

Why is it not = possible to use the same numeric lable for kty, kid, etc in all = places?

[JLS] It would be possible to do that for the items assigned in this = document.=C2=A0 However, these are kept in different registries and = could easily diverge in the future.=C2=A0 Having a difference today can = be thought of as a way of making sure people are prepared for problems = in the future.=C2=A0 If people really want to harmonize them I would not = object.

 





=3D=3D=3D 17.2.  COSE Testing = Library
I would prefer test vectors in the specification compared to = this github link.

[JLS] You were complaining earlier about the = length of the document already.  If you want a printed RFC which = contains the broken out examples then argue for that on the list, but I = prefer having it outside of the document as it makes things easier to = correct if they are wrong.  Also if you look at the github link you = will see that there are lot of examples which are not in this document = as it can be much more complete.

 

Okay, and you have created a great number of examples = on the github pages, which is awesome, I have not yet understood exactly = how I would use them but I guess I will by spending some time on = it.

 

[JLS] If there is anything that I can do to make things clearer, please = be sure and let me know. One of the things that should be on my list is = to provide a better description of the JSON structure for the = examples.=C2=A0 I am not sure if it is really self-explanatory or = not.=C2=A0 Also, please let me know if you think the organization can be = improved or if there are missing examples.

 

Jim

 

 


Jim


____________________________________= ___________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

 

------=_NextPart_000_012D_01D1EFCD.61D1F960-- From nobody Sat Aug 6 10:58:35 2016 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 4901412D552 for ; Sat, 6 Aug 2016 10:58:33 -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, HTML_MESSAGE=0.001, 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 lmk7PhlR4Fka for ; Sat, 6 Aug 2016 10:58:31 -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 175FF12D520 for ; Sat, 6 Aug 2016 10:58:30 -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 u76Hw1xS017976; Sat, 6 Aug 2016 19:58:01 +0200 (CEST) Received: from nar-4.local.mail (p5DC7E34C.dip0.t-ipconnect.de [93.199.227.76]) (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 3s6BGx2gWtzDDNJ; Sat, 6 Aug 2016 19:58:01 +0200 (CEST) Date: Sat, 6 Aug 2016 19:58:00 +0200 From: Carsten Bormann To: Jim Schaad , "=?utf-8?Q?'G=C3=B6ran_Selander'?=" , "'Samuel Erdtman'" Message-ID: In-Reply-To: <012c01d1f008$0e29a570$2a7cf050$@augustcellars.com> References: <00c501d1eb68$23eee540$6bccafc0$@augustcellars.com> <012c01d1f008$0e29a570$2a7cf050$@augustcellars.com> X-Mailer: Airmail (382) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="57a62528_7432d096_385a" Archived-At: Cc: 'cose' Subject: Re: [COSE] draft-ietf-cose-msg-15 review X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2016 17:58:33 -0000 --57a62528_7432d096_385a Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hmm. =C2=A0COSE is defined on the data model level. =C2=A0This new text g= oes down to explain how that data model will then be serialized (encoded)= . =C2=A0We don=E2=80=99t do this in other places. =C2=A0This might confus= e. =C2=A0More so as this is about a byte string that is encoding another = data model (that of a header map). =C2=A0But we are not talking about tha= t encoding, but about the encoding of the byte string data item carrying = an either empty byte string or an encoded map. I think we are better off staying at the data model level; we might want = to add something about =E2=80=9Cwhich is then in turn encoded as=E2=80=A6= =E2=80=9D if that is clearly separated from the encoding of the embedded = CBOR byte string. (None of this is =E2=80=9Cwrong=22; this choice is about what might confu= se new people the least, and I=E2=80=99m only guessing here.) Gr=C3=BC=C3=9Fe, Carsten On 6 August 2016 at 19:29:37, Jim Schaad (ietf=40augustcellars.com) wrote= : Does it help if this is re-written as: Senders SHOULD encode an empty protected map as a zero length binary (enc= oding h=E2=80=9940=E2=80=99) rather than as a zero length map wrapped in = a binary (encoding h=E2=80=9941a0=E2=80=99).=C2=A0 The zero length binary= encoding is preferred because it is both shorter and is the encoding use= d in the serialization structures for cryptographic computation. This fixes my CBOR encoding error as well as presenting both of the encod= ings so it is clear what is being discussed. --57a62528_7432d096_385a Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Pull request = https://github.com= /cose-wg/cose-spec/pull/173 has a few more proposed modifications to = deal with some issues you have raised.

 

This = includes =E2=80=93 a definition of layers, clarification text for = =E2=80=98crit=E2=80=99 w/ algorithm parameters and a couple of small = other issues.

 

Jim

 

------=_NextPart_000_0145_01D1EFE0.6E0996D0-- From nobody Sun Aug 7 00:42:06 2016 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 B8E7912D119 for ; Sun, 7 Aug 2016 00:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Yh1zJnktqQdU for ; Sun, 7 Aug 2016 00:42:03 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 1031F12B04F for ; Sun, 7 Aug 2016 00:42:02 -0700 (PDT) X-AuditID: c1b4fb3a-c91fe700000009bd-e6-57a6e647b53c Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id 0B.06.02493.746E6A75; Sun, 7 Aug 2016 09:42:01 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.248]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0301.000; Sun, 7 Aug 2016 09:41:59 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: Jim Schaad , 'Samuel Erdtman' , 'cose' Thread-Topic: [COSE] draft-ietf-cose-msg-15 review Thread-Index: AQHR6v8IeGPwDT6h1EmTSz21KxNK+aAy2L6AgApPmoA= Date: Sun, 7 Aug 2016 07:41:59 +0000 Message-ID: References: <00c501d1eb68$23eee540$6bccafc0$@augustcellars.com> In-Reply-To: <00c501d1eb68$23eee540$6bccafc0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: <5C8ABEFD73EB1D4DA6961950159B8A63@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7tK7ns2XhBlc6mS2mbZ3KarF6+nc2 i/9LTzE5MHtsnDOdzePFvz2MHkuW/GQKYI7isklJzcksSy3St0vgyvh3ZjlzwQW+it/9/9kb GBfwdTFyckgImEgsnfaKvYuRi0NIYD2jxLKeqUwQzmJGid6vb9hBqtgEXCQeNDxiArFFBNIl jnatYASxhQUMJX5+WsMCETeS+Dn1IZRtJbH3ygwwm0VARWJ+xx2wXl4BC4n1E/YxQixoY5Q4 fuk82AJOAQeJiR++g9mMAmIS30+tAWtgFhCXuPVkPhPEqQISS/acZ4awRSVePv7HCmKLCuhJ fP86GyquJLHo9megeg6gXk2J9bv0IcZYS/S8uMcMYStKTOl+yA5xj6DEyZlPWCYwis1Csm0W QvcsJN2zkHTPQtK9gJF1FaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZgrB3c8ttqB+PB546H GAU4GJV4eBWmLQsXYk0sK67MPcQowcGsJML7/SFQiDclsbIqtSg/vqg0J7X4EKM0B4uSOK// S8VwIYH0xJLU7NTUgtQimCwTB6dUA2PfMqup7x8nHRH/UaxwxS3pz/431dtuO/xc3LL/0pVm DcFdRtfvmzvMmyzx8srd6iUaBwIsdzIqmnCv1Dtv5nOSNVyYbfYDS03O/3tb4hdxt9xysvU+ K7jg7CqFm5bv1xfVKL/zvx407++ri4KMfWoccmtU+9VOH96jFRWyWf/NkWTjv4Fue68rsRRn JBpqMRcVJwIApva7y7ECAAA= Archived-At: Subject: Re: [COSE] draft-ietf-cose-msg-15 review X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2016 07:42:04 -0000 SnVzdCBhIHF1aWNrIGNvbW1lbnQ6DQoNCk9uIDIwMTYtMDctMzEgMjI6MTQsICJDT1NFIG9uIGJl aGFsZiBvZiBKaW0gU2NoYWFkIiA8Y29zZS1ib3VuY2VzQGlldGYub3JnDQpvbiBiZWhhbGYgb2Yg aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4gd3JvdGU6DQoNCj4NCj7igJxBcyB0aGUgSVYgaXMgYXV0 aGVudGljYXRlZCBieSB0aGUNCj4gICAgICBlbmNyeXB0aW9uIHByb2Nlc3MsIGl0IFNIT1VMRCBi ZSBwbGFjZWQgaW4gdGhlIHVucHJvdGVjdGVkIGhlYWRlcg0KPiAgICAgIGJ1Y2tldC7igJ0NCj4q IElzIHRoZXJlIGEgZ29vZCByZWFzb24gZm9yIHRoaXMgU0hPVUxEPyB3aHkgaXMgaXQgYmV0dGVy IHRvIHB1dCBpdCBpbg0KPnRoZSB1bnByb3RlY3RlZCBoZWFkZXI/IGlmIEkgY291bGQgSSB3b3Vs ZCBwdXQgYWxsIG15IGhlYWRlcnMgaW4gdGhlDQo+cHJvdGVjdGVkIGFuZCBub3QgaGF2ZSB0byBi b3RoZXIgd2l0aCB0aGUgdW5wcm90ZWN0ZWQgcGFydC4gSSB3b3VsZA0KPnByZWZlciB0aGUgcGhy YXNpbmcgdW5kZXIgUGFydGlhbCBJViB0byBiZSDigJxBcyB0aGUgSVYgaXMgYXV0aGVudGljYXRl ZCBieQ0KPnRoZSBlbmNyeXB0aW9uIHByb2Nlc3MsIHRoaXMgdmFsdWUgY2FuIGJlIHBsYWNlZCBp biB0aGUgdW5wcm90ZWN0ZWQNCj5oZWFkZXIgYnVja2V04oCdDQo+W0pMU10gVGhlIHN0cmVuZ3Ro ZW5pbmcgb2YgdGhpcyBzdGF0ZW1lbnQgd2FzIG1hZGUgYXQgdGhlIHJlcXVlc3Qgb2YNCj5Hw7Zy YW4gc28gaGUgc2hvdWxkIHByb2JhYmx5IHJlc3BvbmQuDQoNCg0KSW4gZHJhZnQtaWV0Zi1jb3Nl LW1zZy0xNCwgYm90aCB0ZXh0cyBvbiBraWQgYW5kIElWIGhhZCB0aGUgZm9ybXVsYXRpb24NCiJ0 aGV5IGNhbiBiZSBwbGFjZWQgaW4gdGhlIHVucHJvdGVjdGVkIGhlYWRlcnMgYnVja2V04oCdLiBJ IGFza2VkIGluIG15DQpyZXZpZXcgaWYgdGhpcyBjb3VsZCBpbnN0ZWFkIGJlIHJlcGxhY2VkIHdp dGggYSByZWNvbW1lbmRhdGlvbiwgdG8gcmVkdWNlDQp0aGUgbnVtYmVyIG9mIG9wdGlvbnMsIGZv ciB0aGUgYmVuZWZpdCBvZiB0aGUgdXNlciBvZiB0aGlzIHNwZWNpZmljYXRpb24uDQpCdXQgSSB0 aGluayBTYW11ZWwgaGFzIGEgcG9pbnQgdGhhdCBtYWtpbmcgYWxsIGhlYWRlcnMgcHJvdGVjdGVk IGNvdWxkDQpzb21ldGltZXMgYmUgYW4gYWx0ZXJuYXRpdmUgd2hpY2ggYWxzbyBzaW1wbGlmaWVz IGZvciB0aGUgdXNlci4gSSBwcm9wb3NlDQp3ZSBjaGFuZ2UgdGhlIG5vcm1hdGl2ZSBzdGF0ZW1l bnQgdG8gTUFZIG9yIHJldmVydCB0byB0aGUgb3JpZ2luYWwNCmZvcm11bGF0aW9uLCBib3RoIGZv ciBraWQgYW5kIElWLg0KDQpHw7ZyYW4NCg0KKGdvaW5nIGJhY2sgdG8gdmFjYXRpb24pDQoNCg== From nobody Wed Aug 10 20:49:40 2016 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 A970D12D619; Wed, 10 Aug 2016 20:49:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147088737869.13454.8712832152231697654.idtracker@ietfa.amsl.com> Date: Wed, 10 Aug 2016 20:49:38 -0700 Archived-At: Cc: cose@ietf.org Subject: [COSE] I-D Action: draft-ietf-cose-msg-16.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 03:49:38 -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 of the IETF. Title : CBOR Object Signing and Encryption (COSE) Author : Jim Schaad Filename : draft-ietf-cose-msg-16.txt Pages : 117 Date : 2016-08-10 Abstract: Concise Binary Object Representation (CBOR) is data format designed for small code size and small message size. There is a need for the ability to have the basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) specification. This specification describes how to create and process signature, message authentication codes and encryption using CBOR for serialization. This specification additionally specifies how to represent cryptographic keys using CBOR. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cose-msg-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-16 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 Thu Aug 11 09:27:59 2016 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 AD14512D81C for ; Thu, 11 Aug 2016 09:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 uF6lqeG7QBmo for ; Thu, 11 Aug 2016 09:27:53 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 AB5E012D7C2 for ; Thu, 11 Aug 2016 09:27:53 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id c15so1109574oig.0 for ; Thu, 11 Aug 2016 09:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i9jEcSorHIlcJCvGfXiutIJWADijgUYmQ7fFsOWvCqI=; b=Hjf4RaGi1kzlZYV43qLs8PxtWqjCjClNHeiKz6Wuh2vm+hkxrW/n51EjgZOrdsL0HC OjuUKYNPPGbKxgi2QumK9JN4lTcOPu+nrPqhp9ZG4QZNW0OgwJ81YBDhGDa8IJr8OW6G ORRFf9IYYsXZBH9bZr2N0Hgcy0rbU+Eg8HSsIIVlNCGsatmYO4fPYgeOalCZz9uS/oIC JHXu7EAOw3qep40RjTE/+VqRB94aunPvfK5PznteBZ/9wUvKF4mkZ0oeWvqaY3vBoYMJ WM1AW+px27KeUaRikGCH+ExRG+GeCp26ESm6UWkFqoq505YRg0kVmU5VDEvi4/cIan09 MZOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i9jEcSorHIlcJCvGfXiutIJWADijgUYmQ7fFsOWvCqI=; b=UagNXlKfhJURILd96sayp5HKjs7ug2j3nCoEiC2JjJQSXIowSHlaArSKlv7Ac2cESD DDhfAdP1kFOxO5rt7gXHITG8j6wWL9sWgM025dj7mZORMHecfBVepSAia8QrtzZSkiik ex0V05w0oBC7olN5w8FdlcUTFsarj7wMUYKU4kB0ZgHdeSoI4sY/GXvrHHwTBHOFZtpU 6niGfb5MBfUj7sSf7QIjLk/DDhW+5awAb8a4nQyG5tgi5m20h6auPNsaiSxic47U5cLZ 6jptUyksw6nVQcZ4o8Cr4rsYd2ZuBXjjYjmmhQcXAZjXeFBEq21wnRO3OkyeDVorlUBO 8ugQ== X-Gm-Message-State: AEkoousvMiHMeBkAmnOglMjt+Y1GZ55S5/eI9OK7TVKBV9vcfU5lR/Nrei2Tl/mof2rruwd1ITrfNqcY/eerRQ== X-Received: by 10.202.216.4 with SMTP id p4mr5851923oig.140.1470932872988; Thu, 11 Aug 2016 09:27:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.4.71 with HTTP; Thu, 11 Aug 2016 09:27:32 -0700 (PDT) In-Reply-To: References: From: Matias Woloski Date: Thu, 11 Aug 2016 13:27:32 -0300 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=001a113d3576620fb40539ce3f4e Archived-At: Cc: cose Subject: Re: [COSE] Adoption of RSA and alternative algorithms X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 16:27:55 -0000 --001a113d3576620fb40539ce3f4e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable inline On Fri, Jul 29, 2016 at 11:04 AM, Justin Richer wrote: > Hi all, hope that everyone is recovering from Berlin. As discussed in the > meeting last week, the working group is considering additional work on RS= A > and other algorithms in the COSE messages framework. These would be > published in a document separate from the core draft that is now on its > journey to RFC-land. > > The chairs would like to gauge the sentiment of the working group on a > number of items related to this proposed work. Please respond with your > answers to the list. > > > 1) Do you think it=E2=80=99s necessary or worthwhile to define RSA and ot= her > additional algorithms in the COSE messages framework? > > A) Yes, we should do an RSA/other-algs document > B) No, we shouldn=E2=80=99t do an RSA/other-algs document > C) Yes, but not right now > D) I need more information (please ask what you want to know) > E) I don=E2=80=99t give a flying rat whether this gets done or not > > A) RS can be implemented in pretty much any language, easily enough. > > 2) If the work is adopted, where should it be done? > > A) Here in COSE (we=E2=80=99ll keep the group open for this item) > B) In other working group (please specify where; note that ACE is a > possible option) > C) I need more information (ask what you want to know) > D) I don=E2=80=99t give a flying rat where this happens > > D) > > 3) If the work is adopted, which draft is a good starting point? > > A) Jim=E2=80=99s draft: https://tools.ietf.org/html/draft-schaad-cose-alg= -01 > B) Mike=E2=80=99s draft: https://tools.ietf.org/html/draft-jones-cose-rsa= -00 > C) Some other draft (please tell us which one it is or offer to write it > yourself) > D) I need more information (ask what you want to know) > E) I don=E2=80=99t give a flying rat which document we start with > > E) > > > We=E2=80=99re going to keep this thread open for two weeks at the AD=E2= =80=99s request, > and the chairs will try to make a consensus call at the end of that time > period. > > Thank you, > > =E2=80=94 Justin & Kepeng, your COSE chairs > > > * \. - - . > ' _ , -`. > ' _,' _,' > ' ,-' _/ > ' ,-' \ _/ > ' ,' \ _' > ' ' _\' > ' , _,-' \ _________ > \,_,--' \ \\_______\ > \ \\+=3D+=3D+=3D+\ > \ \\=3D+=3D+=3D+=3D\ > \ \\+=3D+=3D+=3D+\ > \ \\=3D+=3D+=3D+=3D\________ > \ \\+=3D+=3D+=3D+____----)) > \ \`---------.)))\\ > \ ||+=3D+=3D+=3D+=3D+=3D\\ /\\ > \ ||___________\\/ \\ > \ ||------------\\ > ejm \|| \\ > * > > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > =E1=90=A7 --001a113d3576620fb40539ce3f4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
inline

On Fri, Jul 29, 2016 at 11:04 AM, Justin Richer <jricher@mit.edu> wrote:
Hi all, hope that everyone is recovering from Berlin. As discussed in the= meeting last week, the working group is considering additional work on RSA= and other algorithms in the COSE messages framework. These would be publis= hed in a document separate from the core draft that is now on its journey t= o RFC-land.

The chairs would like to gauge the sentiment= of the working group on a number of items related to this proposed work. P= lease respond with your answers to the list.


<= /div>
1) Do you think it=E2=80=99s necessary or worthwhile to define RS= A and other additional algorithms in the COSE messages framework?

A) Yes, we should do an RSA/other-algs document
B= ) No, we shouldn=E2=80=99t do an RSA/other-algs document
C) Yes, = but not right now
D) I need more information (please ask what you= want to know)
E) I don=E2=80=99t give a flying rat whether this = gets done or not

A) RS can= be implemented in pretty much any language, easily enough.

2) If the work is adopted, where should it be done?
<= div>

=

3) If the work is adopted, which draft is a good starti= ng point?

C) Some other draft (please tell us which one it= is or offer to write it yourself)
D) I need more information (as= k what you want to know)
E) I don=E2=80=99t give a flying rat whi= ch document we start with

= E)


We=E2=80=99re going to ke= ep this thread open for two weeks at the AD=E2=80=99s request, and the chai= rs will try to make a consensus call at the end of that time period.
<= div>
Thank you,

=C2=A0=E2=80=94 Just= in & Kepeng, your COSE chairs


=
        \.  -   -  .
       '          _ , -`.
     '        _,'     _,'
    '      ,-'      _/
   '    ,-' \     _/
  '   ,'     \  _'
  '  '       _\'
  ' ,    _,-'  \     _________
  \,_,--'       \    \\_______\
                 \    \\+=3D+=3D+=3D+\
                  \    \\=3D+=3D+=3D+=3D\
                   \    \\+=3D+=3D+=3D+\
                    \    \\=3D+=3D+=3D+=3D\________
                     \    \\+=3D+=3D+=3D+____----))
                      \    \`---------.)))\\
                       \   ||+=3D+=3D+=3D+=3D+=3D\\ /\\
                        \  ||___________\\/ \\
                         \ ||------------\\
  ejm                     \||             \\


___________________________= ____________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose


= =E1=90=A7
--001a113d3576620fb40539ce3f4e-- From nobody Thu Aug 11 10:20:57 2016 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 B26EE12D08F for ; Thu, 11 Aug 2016 10:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 LK7Yb7ZBAAaF for ; Thu, 11 Aug 2016 10:20:53 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 AF8E712D5E7 for ; Thu, 11 Aug 2016 10:20:53 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id x130so2213028ite.1 for ; Thu, 11 Aug 2016 10:20:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7fi0FC3BteFaxG8m4wSNK4LQx1HCre1p+fILy3Zz074=; b=faO8F4SsLMgID+p3CEqlAPMnRSCte6ztH6aALWonyW0Wtyy5kUalH4xR14WSUvFcLy feqavLBMJ+5jNFVkFlWlVIrgZCMG2TCCGacTczw9g3G4SjaLgmWuhy4XdN4S8lxCucLJ j8MGxjoHclA28lWnt2T2yQMXr+pn4wSjWKD80= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7fi0FC3BteFaxG8m4wSNK4LQx1HCre1p+fILy3Zz074=; b=lnPvYUVUKTwHh8+bDotrzsirO7V2cZwYIjckYMNfKbPZSVlQIkfrRQBSkxeI2VGAiK NjV90gA7eCTqVP8kRZ0x+BxV5qvQNkdrrd6UOrjt9p6+2a37OPDlw1jZ5XZXPNsDtEru JOC+YqSlx1tH6TtpYtAT2s8kRH2y0zB0xRjdOhwjyl+EWshybuR5xMGCvn4YX02BEGqR XO/eN/vQ9Qqg0jyqXW2YhQ4gKhR2EoGO8gmDemhZenlBBJEdSgs3hWQV4pC/qJAsfkhF g8gVxFUgT3FxQk7c8ek0l392pa3sgdRiSZhtWsvtYUjUVxK1e5krKgIg1caiuCytx6yD RgJA== X-Gm-Message-State: AEkoousxe/p1giUw7UhjwEHxmNahfISiCd/p4RN4v6GT87n4xhzIu8JguIR8d3wkdC5S/+YgC3lkwUUxNw/4Wy3V X-Received: by 10.36.115.5 with SMTP id y5mr11438152itb.63.1470936053030; Thu, 11 Aug 2016 10:20:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.123.14 with HTTP; Thu, 11 Aug 2016 10:20:22 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Thu, 11 Aug 2016 11:20:22 -0600 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=001a1144990aedc3870539cefcda Archived-At: Cc: cose Subject: Re: [COSE] Adoption of RSA and alternative algorithms X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 17:20:56 -0000 --001a1144990aedc3870539cefcda Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 1) A. And, as I've said several times previously, I think RSASSA-PKCS1-v1_5 should be included. 2) D but A probably makes sense. 3) E On Fri, Jul 29, 2016 at 8:04 AM, Justin Richer wrote: > Hi all, hope that everyone is recovering from Berlin. As discussed in the > meeting last week, the working group is considering additional work on RS= A > and other algorithms in the COSE messages framework. These would be > published in a document separate from the core draft that is now on its > journey to RFC-land. > > The chairs would like to gauge the sentiment of the working group on a > number of items related to this proposed work. Please respond with your > answers to the list. > > > 1) Do you think it=E2=80=99s necessary or worthwhile to define RSA and ot= her > additional algorithms in the COSE messages framework? > > A) Yes, we should do an RSA/other-algs document > B) No, we shouldn=E2=80=99t do an RSA/other-algs document > C) Yes, but not right now > D) I need more information (please ask what you want to know) > E) I don=E2=80=99t give a flying rat whether this gets done or not > > > > 2) If the work is adopted, where should it be done? > > A) Here in COSE (we=E2=80=99ll keep the group open for this item) > B) In other working group (please specify where; note that ACE is a > possible option) > C) I need more information (ask what you want to know) > D) I don=E2=80=99t give a flying rat where this happens > > > > 3) If the work is adopted, which draft is a good starting point? > > A) Jim=E2=80=99s draft: https://tools.ietf.org/html/draft-schaad-cose-alg= -01 > B) Mike=E2=80=99s draft: https://tools.ietf.org/html/draft-jones-cose-rsa= -00 > C) Some other draft (please tell us which one it is or offer to write it > yourself) > D) I need more information (ask what you want to know) > E) I don=E2=80=99t give a flying rat which document we start with > > > > > We=E2=80=99re going to keep this thread open for two weeks at the AD=E2= =80=99s request, > and the chairs will try to make a consensus call at the end of that time > period. > > Thank you, > > =E2=80=94 Justin & Kepeng, your COSE chairs > > > * \. - - . > ' _ , -`. > ' _,' _,' > ' ,-' _/ > ' ,-' \ _/ > ' ,' \ _' > ' ' _\' > ' , _,-' \ _________ > \,_,--' \ \\_______\ > \ \\+=3D+=3D+=3D+\ > \ \\=3D+=3D+=3D+=3D\ > \ \\+=3D+=3D+=3D+\ > \ \\=3D+=3D+=3D+=3D\________ > \ \\+=3D+=3D+=3D+____----)) > \ \`---------.)))\\ > \ ||+=3D+=3D+=3D+=3D+=3D\\ /\\ > \ ||___________\\/ \\ > \ ||------------\\ > ejm \|| \\ > * > > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > --001a1144990aedc3870539cefcda Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
1) A. And, as I've said several times previously, I th= ink RSASSA-PKCS1-v1_5 should be included.
2)= D but A probably makes sense.
3) E

On Fri, Jul 29, 2016 at 8:04 AM, Justin Ri= cher <jricher@mit.edu> wrote:
Hi all, hope that everyone is recover= ing from Berlin. As discussed in the meeting last week, the working group i= s considering additional work on RSA and other algorithms in the COSE messa= ges framework. These would be published in a document separate from the cor= e draft that is now on its journey to RFC-land.

The chai= rs would like to gauge the sentiment of the working group on a number of it= ems related to this proposed work. Please respond with your answers to the = list.


1) Do you think it=E2=80=99s = necessary or worthwhile to define RSA and other additional algorithms in th= e COSE messages framework?

A) Yes, we should do an= RSA/other-algs document
B) No, we shouldn=E2=80=99t do an RSA/ot= her-algs document
C) Yes, but not right now
D) I need m= ore information (please ask what you want to know)
E) I don=E2=80= =99t give a flying rat whether this gets done or not



2) If the work is adopted, where should it= be done?

A) Here in COSE (we=E2=80=99ll keep the = group open for this item)
B) In other working group (please speci= fy where; note that ACE is a possible option)
C) I need more info= rmation (ask what you want to know)
D) I don=E2=80=99t give a fly= ing rat where this happens



3) If the work is adopted, which draft is a good starting point?





\. - - . ' _ , -`. ' _,' _,' ' ,-' _/ ' ,-' \ _/ ' ,' \ _' ' ' _\' ' , _,-' \ _________ \,_,--' \ \\_______\ \ \\+=3D+=3D+=3D+\ \ \\=3D+=3D+=3D+=3D\ \ \\+=3D+=3D+=3D+\ \ \\=3D+=3D+=3D+=3D\________ \ \\+=3D+=3D+=3D+____----)) \ \`---------.)))\\ \ ||+=3D+=3D+=3D+=3D+=3D\\ /\\ \ ||___________\\/ \\ \ ||------------\\ ejm \|| \\


___________________________= ____________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose


--001a1144990aedc3870539cefcda-- From nobody Thu Aug 11 15:32:04 2016 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 BB90612D82C for ; Thu, 11 Aug 2016 15:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 DNqNtc-P2pI9 for ; Thu, 11 Aug 2016 15:32:00 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0106.outbound.protection.outlook.com [104.47.42.106]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8666112D605 for ; Thu, 11 Aug 2016 15:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iraWVOlBR3i96V7J58fsVGlVhB+RRZ4a4bWJGsvduoE=; b=ccDZOboyfMkBEI2pehSZLTpEdJVIZqDHf3YJauDmeULz1053eAMxd+WZSp3bg3mhdUFhPjW4IWeTf1lgMqGuXnRY5mJPtCFd8u8T+6BNGLPny6IQKei/EuYTI/dAqK8YlHsBIPyyP3kp2MKmyBcIHaTANl1zpdelRHOXrw+Smx0= Received: from DM5PR03MB2441.namprd03.prod.outlook.com (10.168.233.11) by DM5PR03MB2444.namprd03.prod.outlook.com (10.168.233.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Thu, 11 Aug 2016 22:31:58 +0000 Received: from DM5PR03MB2441.namprd03.prod.outlook.com ([10.168.233.11]) by DM5PR03MB2441.namprd03.prod.outlook.com ([10.168.233.11]) with mapi id 15.01.0549.026; Thu, 11 Aug 2016 22:31:58 +0000 From: Anthony Nadalin To: "cose@ietf.org" Thread-Topic: [COSE] Adoption of RSA and alternative algorithms Thread-Index: AQHR6aIjR4RjK35FXkWLzfd8NdrKSKBEA1dAgABo97A= Date: Thu, 11 Aug 2016 22:31:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-originating-ip: [2001:4898:80e8:e::768] x-ms-office365-filtering-correlation-id: ddcb271c-79dd-4cab-b445-08d3c2374e92 x-microsoft-exchange-diagnostics: 1; DM5PR03MB2444; 6:NpYWeByItY+VoHo2OtweGHLr7AA6NxgEAF6QFQ1W/qTFOYGK8zwQ/iE8Y+xbO6Yt40Dh09kmMSRP/yTlXy/EaspRx23FritA3v75+EopTOd+jTifLWtzr2T9bm6fKMOBhx+AwX4KI8R3KcSWkig08ot83+DrArzEseRUMKn8pHS+p1xVD5sIBOoUCC9wdSTfzdTXr4fkauqTo40MqHrR7Otm3h4Yh6M1mNg40CXz8zcG5ZVI0rugUJuENhpY2IEV8B1APdYYzhAAWob4+49YQ1AQmJrzXG6AWbwcnk3r9bMf204YZ9+afHOk+5sho53GTB/kAnwvjULgHYLSplFlhw==; 5:tARC6EDxRqTZSYS8REdvp35mpJhQymS+1E1XnOKWG5+XQo1qozlV71aEiwZfIsWRsTJHeEaInh7NcL2PKpmTLj7YdI0V6rGYz2mjKPybzTpVxR2bwoYpExHO780IfBhiA8+jGMMN2uFugopo+xkGhg==; 24:zFWPLGBCVaX95WV3NIVYVgtooYAbs6ljwCaeH9qsLLOGoBSdFe+CZmukGa5fxEcEV0oXUK7YR2bRNL+5b8JuPloGeCBO+SAReknjNr0FfeA=; 7:rmhhEM/r7ZNNPo+sb91WTNvAqxZirZNTI5Ru+RSUV0D717a15LdityPBeLvopcQV94OCvbZKWn9QXcOeMHiayFEn/oMQFab4T+YvQw9wxdGEuxqzneucbey6ZCca9uLdGW/hSbPkL6ufgIQZ3ybETuqPyZMctMZnSeqn8Nbo7JCTCMi8t4iSXzBu96dV5gWisNQKyJgI0dDXGh51IZbfnl3na+eHSa6fx2JjTIkvkJFcF5tmvTxAVlkk4cxvhI7F x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM5PR03MB2444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:DM5PR03MB2444; BCL:0; PCL:0; RULEID:; SRVR:DM5PR03MB2444; x-forefront-prvs: 0031A0FFAF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(189002)(199003)(53754006)(19609705001)(19625215002)(87936001)(5002640100001)(54356999)(16236675004)(33656002)(5005710100001)(189998001)(76176999)(10090500001)(76576001)(7696003)(8990500004)(10290500002)(10400500002)(7906003)(50986999)(86362001)(2900100001)(110136002)(11100500001)(107886002)(450100001)(97736004)(7736002)(101416001)(86612001)(2950100001)(790700001)(8676002)(102836003)(6116002)(5640700001)(106116001)(2501003)(3660700001)(106356001)(8936002)(15975445007)(122556002)(81156014)(1730700003)(5630700001)(3280700002)(19617315012)(2351001)(77096005)(586003)(9686002)(68736007)(81166006)(99286002)(19300405004)(105586002)(19580405001)(92566002)(19580395003)(2906002)(74316002)(7846002)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR03MB2444; H:DM5PR03MB2441.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR03MB2441E74275577721C0115CE8A61E0DM5PR03MB2441namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2016 22:31:58.5327 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR03MB2444 Archived-At: Subject: Re: [COSE] Adoption of RSA and alternative algorithms X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 22:32:02 -0000 --_000_DM5PR03MB2441E74275577721C0115CE8A61E0DM5PR03MB2441namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVyZSBhcmUgbXkgY2hvaWNlcw0KDQoxLiAgICAgIEENCg0KMi4gICAgICBBDQoNCjMuICAgICAg Qg0KRnJvbTogQ09TRSBbbWFpbHRvOmNvc2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEp1c3RpbiBSaWNoZXINClNlbnQ6IEZyaWRheSwgSnVseSAyOSwgMjAxNiAxMDowNCBBTQ0KVG86 IGNvc2UgPGNvc2VAaWV0Zi5vcmc8bWFpbHRvOmNvc2VAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW0NP U0VdIEFkb3B0aW9uIG9mIFJTQSBhbmQgYWx0ZXJuYXRpdmUgYWxnb3JpdGhtcw0KDQpIaSBhbGws IGhvcGUgdGhhdCBldmVyeW9uZSBpcyByZWNvdmVyaW5nIGZyb20gQmVybGluLiBBcyBkaXNjdXNz ZWQgaW4gdGhlIG1lZXRpbmcgbGFzdCB3ZWVrLCB0aGUgd29ya2luZyBncm91cCBpcyBjb25zaWRl cmluZyBhZGRpdGlvbmFsIHdvcmsgb24gUlNBIGFuZCBvdGhlciBhbGdvcml0aG1zIGluIHRoZSBD T1NFIG1lc3NhZ2VzIGZyYW1ld29yay4gVGhlc2Ugd291bGQgYmUgcHVibGlzaGVkIGluIGEgZG9j dW1lbnQgc2VwYXJhdGUgZnJvbSB0aGUgY29yZSBkcmFmdCB0aGF0IGlzIG5vdyBvbiBpdHMgam91 cm5leSB0byBSRkMtbGFuZC4NCg0KVGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIGdhdWdlIHRoZSBz ZW50aW1lbnQgb2YgdGhlIHdvcmtpbmcgZ3JvdXAgb24gYSBudW1iZXIgb2YgaXRlbXMgcmVsYXRl ZCB0byB0aGlzIHByb3Bvc2VkIHdvcmsuIFBsZWFzZSByZXNwb25kIHdpdGggeW91ciBhbnN3ZXJz IHRvIHRoZSBsaXN0Lg0KDQoNCjEpIERvIHlvdSB0aGluayBpdOKAmXMgbmVjZXNzYXJ5IG9yIHdv cnRod2hpbGUgdG8gZGVmaW5lIFJTQSBhbmQgb3RoZXIgYWRkaXRpb25hbCBhbGdvcml0aG1zIGlu IHRoZSBDT1NFIG1lc3NhZ2VzIGZyYW1ld29yaz8NCg0KQSkgWWVzLCB3ZSBzaG91bGQgZG8gYW4g UlNBL290aGVyLWFsZ3MgZG9jdW1lbnQNCkIpIE5vLCB3ZSBzaG91bGRu4oCZdCBkbyBhbiBSU0Ev b3RoZXItYWxncyBkb2N1bWVudA0KQykgWWVzLCBidXQgbm90IHJpZ2h0IG5vdw0KRCkgSSBuZWVk IG1vcmUgaW5mb3JtYXRpb24gKHBsZWFzZSBhc2sgd2hhdCB5b3Ugd2FudCB0byBrbm93KQ0KRSkg SSBkb27igJl0IGdpdmUgYSBmbHlpbmcgcmF0IHdoZXRoZXIgdGhpcyBnZXRzIGRvbmUgb3Igbm90 DQoNCg0KDQoyKSBJZiB0aGUgd29yayBpcyBhZG9wdGVkLCB3aGVyZSBzaG91bGQgaXQgYmUgZG9u ZT8NCg0KQSkgSGVyZSBpbiBDT1NFICh3ZeKAmWxsIGtlZXAgdGhlIGdyb3VwIG9wZW4gZm9yIHRo aXMgaXRlbSkNCkIpIEluIG90aGVyIHdvcmtpbmcgZ3JvdXAgKHBsZWFzZSBzcGVjaWZ5IHdoZXJl OyBub3RlIHRoYXQgQUNFIGlzIGEgcG9zc2libGUgb3B0aW9uKQ0KQykgSSBuZWVkIG1vcmUgaW5m b3JtYXRpb24gKGFzayB3aGF0IHlvdSB3YW50IHRvIGtub3cpDQpEKSBJIGRvbuKAmXQgZ2l2ZSBh IGZseWluZyByYXQgd2hlcmUgdGhpcyBoYXBwZW5zDQoNCg0KDQozKSBJZiB0aGUgd29yayBpcyBh ZG9wdGVkLCB3aGljaCBkcmFmdCBpcyBhIGdvb2Qgc3RhcnRpbmcgcG9pbnQ/DQoNCkEpIEppbeKA mXMgZHJhZnQ6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY2hhYWQtY29zZS1h bGctMDENCkIpIE1pa2XigJlzIGRyYWZ0OiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtam9uZXMtY29zZS1yc2EtMDANCkMpIFNvbWUgb3RoZXIgZHJhZnQgKHBsZWFzZSB0ZWxsIHVz IHdoaWNoIG9uZSBpdCBpcyBvciBvZmZlciB0byB3cml0ZSBpdCB5b3Vyc2VsZikNCkQpIEkgbmVl ZCBtb3JlIGluZm9ybWF0aW9uIChhc2sgd2hhdCB5b3Ugd2FudCB0byBrbm93KQ0KRSkgSSBkb27i gJl0IGdpdmUgYSBmbHlpbmcgcmF0IHdoaWNoIGRvY3VtZW50IHdlIHN0YXJ0IHdpdGgNCg0KDQoN Cg0KV2XigJlyZSBnb2luZyB0byBrZWVwIHRoaXMgdGhyZWFkIG9wZW4gZm9yIHR3byB3ZWVrcyBh dCB0aGUgQUTigJlzIHJlcXVlc3QsIGFuZCB0aGUgY2hhaXJzIHdpbGwgdHJ5IHRvIG1ha2UgYSBj b25zZW5zdXMgY2FsbCBhdCB0aGUgZW5kIG9mIHRoYXQgdGltZSBwZXJpb2QuDQoNClRoYW5rIHlv dSwNCg0KIOKAlCBKdXN0aW4gJiBLZXBlbmcsIHlvdXIgQ09TRSBjaGFpcnMNCg0KDQoNCiAgICAg ICAgXC4gIC0gICAtICAuDQoNCiAgICAgICAnICAgICAgICAgIF8gLCAtYC4NCg0KICAgICAnICAg ICAgICBfLCcgICAgIF8sJw0KDQogICAgJyAgICAgICwtJyAgICAgIF8vDQoNCiAgICcgICAgLC0n IFwgICAgIF8vDQoNCiAgJyAgICwnICAgICBcICBfJw0KDQogICcgICcgICAgICAgX1wnDQoNCiAg JyAsICAgIF8sLScgIFwgICAgIF9fX19fX19fXw0KDQogIFwsXywtLScgICAgICAgXCAgICBcXF9f X19fX19cPHNtYjovL19fX19fX18vPg0KDQogICAgICAgICAgICAgICAgIFwgICAgXFwrPSs9Kz0r XDxzbWI6Ly8rPSs9Kz0rLz4NCg0KICAgICAgICAgICAgICAgICAgXCAgICBcXD0rPSs9Kz1cPHNt YjovLz0rPSs9Kz0vPg0KDQogICAgICAgICAgICAgICAgICAgXCAgICBcXCs9Kz0rPStcPHNtYjov Lys9Kz0rPSsvPg0KDQogICAgICAgICAgICAgICAgICAgIFwgICAgXFw9Kz0rPSs9XF9fX19fX19f DQoNCiAgICAgICAgICAgICAgICAgICAgIFwgICAgXFwrPSs9Kz0rX19fXy0tLS0pKQ0KDQogICAg ICAgICAgICAgICAgICAgICAgXCAgICBcYC0tLS0tLS0tLS4pKSlcXA0KDQogICAgICAgICAgICAg ICAgICAgICAgIFwgICB8fCs9Kz0rPSs9Kz1cXCAvXFwNCg0KICAgICAgICAgICAgICAgICAgICAg ICAgXCAgfHxfX19fX19fX19fX1xcLyBcXA0KDQogICAgICAgICAgICAgICAgICAgICAgICAgXCB8 fC0tLS0tLS0tLS0tLVxcDQoNCiAgZWptICAgICAgICAgICAgICAgICAgICAgXHx8ICAgICAgICAg ICAgIFxcDQoNCg== --_000_DM5PR03MB2441E74275577721C0115CE8A61E0DM5PR03MB2441namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJh Z3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1z dHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0K cC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUt bmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCnNwYW4uRW1haWxT dHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTI0NDc1MzEz ODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTQwNTIx OTI4NiA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcx NSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCkBsaXN0IGwwOmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21h bi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFs cGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6 LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206 MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkhlcmUgYXJlIG15IGNob2ljZXMNCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4y NWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkE8c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD48L286cD48L3NwYW4+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4y NWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj4zLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5CPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IENPU0UgWzxhIGhy ZWY9Im1haWx0bzpjb3NlLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpjb3NlLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4gUmljaGVyPGJyPg0KPGI+U2Vu dDo8L2I+IEZyaWRheSwgSnVseSAyOSwgMjAxNiAxMDowNCBBTTxicj4NCjxiPlRvOjwvYj4gY29z ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNvc2VAaWV0Zi5vcmciPmNvc2VAaWV0Zi5vcmc8L2E+Jmd0 Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbQ09TRV0gQWRvcHRpb24gb2YgUlNBIGFuZCBhbHRlcm5h dGl2ZSBhbGdvcml0aG1zPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SGkgYWxsLCBob3BlIHRoYXQgZXZlcnlvbmUgaXMgcmVjb3ZlcmluZyBmcm9tIEJlcmxp bi4gQXMgZGlzY3Vzc2VkIGluIHRoZSBtZWV0aW5nIGxhc3Qgd2VlaywgdGhlIHdvcmtpbmcgZ3Jv dXAgaXMgY29uc2lkZXJpbmcgYWRkaXRpb25hbCB3b3JrIG9uIFJTQSBhbmQgb3RoZXIgYWxnb3Jp dGhtcyBpbiB0aGUgQ09TRSBtZXNzYWdlcyBmcmFtZXdvcmsuIFRoZXNlIHdvdWxkIGJlIHB1Ymxp c2hlZCBpbiBhIGRvY3VtZW50DQogc2VwYXJhdGUgZnJvbSB0aGUgY29yZSBkcmFmdCB0aGF0IGlz IG5vdyBvbiBpdHMgam91cm5leSB0byBSRkMtbGFuZC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBnYXVnZSB0aGUg c2VudGltZW50IG9mIHRoZSB3b3JraW5nIGdyb3VwIG9uIGEgbnVtYmVyIG9mIGl0ZW1zIHJlbGF0 ZWQgdG8gdGhpcyBwcm9wb3NlZCB3b3JrLiBQbGVhc2UgcmVzcG9uZCB3aXRoIHlvdXIgYW5zd2Vy cyB0byB0aGUgbGlzdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4xKSBEbyB5b3UgdGhpbmsgaXTigJlzIG5lY2Vzc2FyeSBvciB3b3J0aHdo aWxlIHRvIGRlZmluZSBSU0EgYW5kIG90aGVyIGFkZGl0aW9uYWwgYWxnb3JpdGhtcyBpbiB0aGUg Q09TRSBtZXNzYWdlcyBmcmFtZXdvcms/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEpIFllcywgd2Ugc2hvdWxkIGRvIGFuIFJTQS9vdGhlci1h bGdzIGRvY3VtZW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5CKSBObywgd2Ugc2hvdWxkbuKAmXQgZG8gYW4gUlNBL290aGVyLWFsZ3MgZG9jdW1l bnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkMp IFllcywgYnV0IG5vdCByaWdodCBub3c8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkQpIEkgbmVlZCBtb3JlIGluZm9ybWF0aW9uIChwbGVhc2UgYXNr IHdoYXQgeW91IHdhbnQgdG8ga25vdyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkUpIEkgZG9u4oCZdCBnaXZlIGEgZmx5aW5nIHJhdCB3aGV0aGVy IHRoaXMgZ2V0cyBkb25lIG9yIG5vdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MikgSWYgdGhlIHdvcmsgaXMgYWRvcHRlZCwgd2hlcmUg c2hvdWxkIGl0IGJlIGRvbmU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkEpIEhlcmUgaW4gQ09TRSAod2XigJlsbCBrZWVwIHRoZSBncm91cCBv cGVuIGZvciB0aGlzIGl0ZW0pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5CKSBJbiBvdGhlciB3b3JraW5nIGdyb3VwIChwbGVhc2Ugc3BlY2lmeSB3 aGVyZTsgbm90ZSB0aGF0IEFDRSBpcyBhIHBvc3NpYmxlIG9wdGlvbik8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkMpIEkgbmVlZCBtb3JlIGluZm9y bWF0aW9uIChhc2sgd2hhdCB5b3Ugd2FudCB0byBrbm93KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RCkgSSBkb27igJl0IGdpdmUgYSBmbHlpbmcg cmF0IHdoZXJlIHRoaXMgaGFwcGVuczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MykgSWYgdGhlIHdvcmsgaXMgYWRvcHRlZCwgd2hpY2gg ZHJhZnQgaXMgYSBnb29kIHN0YXJ0aW5nIHBvaW50PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BKSBKaW3igJlzIGRyYWZ0OiZuYnNwOzxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY2hhYWQtY29zZS1hbGctMDEi Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY2hhYWQtY29zZS1hbGctMDE8L2E+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CKSBN aWtl4oCZcyBkcmFmdDombmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtam9uZXMtY29zZS1yc2EtMDAiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1qb25lcy1jb3NlLXJzYS0wMDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkMpIFNvbWUgb3RoZXIgZHJhZnQgKHBsZWFzZSB0ZWxsIHVzIHdo aWNoIG9uZSBpdCBpcyBvciBvZmZlciB0byB3cml0ZSBpdCB5b3Vyc2VsZik8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkQpIEkgbmVlZCBtb3JlIGlu Zm9ybWF0aW9uIChhc2sgd2hhdCB5b3Ugd2FudCB0byBrbm93KTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RSkgSSBkb27igJl0IGdpdmUgYSBmbHlp bmcgcmF0IHdoaWNoIGRvY3VtZW50IHdlIHN0YXJ0IHdpdGg8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2XigJlyZSBnb2luZyB0byBr ZWVwIHRoaXMgdGhyZWFkIG9wZW4gZm9yIHR3byB3ZWVrcyBhdCB0aGUgQUTigJlzIHJlcXVlc3Qs IGFuZCB0aGUgY2hhaXJzIHdpbGwgdHJ5IHRvIG1ha2UgYSBjb25zZW5zdXMgY2FsbCBhdCB0aGUg ZW5kIG9mIHRoYXQgdGltZSBwZXJpb2QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rIHlvdSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A74oCUIEp1c3RpbiAmYW1wOyBLZXBl bmcsIHlvdXIgQ09TRSBjaGFpcnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cHJlPjxiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBcLiZuYnNw OyAtJm5ic3A7Jm5ic3A7IC0mbmJzcDsgLjxvOnA+PC9vOnA+PC9iPjwvcHJlPg0KPHByZT48Yj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBfICwgLWAuPG86cD48L286cD48L2I+ PC9wcmU+DQo8cHJlPjxiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAnJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IF8sJyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBf LCc8bzpwPjwvbzpwPjwvYj48L3ByZT4NCjxwcmU+PGI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICcmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLC0nJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IF8vPG86cD48L286cD48L2I+PC9wcmU+DQo8cHJlPjxiPiZuYnNwOyZuYnNwOyAnJm5ic3A7 Jm5ic3A7Jm5ic3A7ICwtJyBcJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IF8vPG86cD48L286cD48 L2I+PC9wcmU+DQo8cHJlPjxiPiZuYnNwOyAnJm5ic3A7Jm5ic3A7ICwnJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFwmbmJzcDsgXyc8bzpwPjwvbzpwPjwvYj48L3ByZT4NCjxwcmU+PGI+Jm5ic3A7 ICcmbmJzcDsgJyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBfXCc8bzpwPjwv bzpwPjwvYj48L3ByZT4NCjxwcmU+PGI+Jm5ic3A7ICcgLCZuYnNwOyZuYnNwOyZuYnNwOyBfLC0n Jm5ic3A7IFwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgX19fX19fX19fPG86cD48L286cD48L2I+ PC9wcmU+DQo8cHJlPjxiPiZuYnNwOyBcLF8sLS0nJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFwmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0ic21iOi8vX19fX19fXy8iPlxc X19fX19fX1w8L2E+PG86cD48L286cD48L2I+PC9wcmU+DQo8cHJlPjxiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBcJm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9InNt YjovLyYjNDM7PSYjNDM7PSYjNDM7PSYjNDM7LyI+XFwmIzQzOz0mIzQzOz0mIzQzOz0mIzQzO1w8 L2E+PG86cD48L286cD48L2I+PC9wcmU+DQo8cHJlPjxiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBcJm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9InNtYjov Lz0mIzQzOz0mIzQzOz0mIzQzOz0vIj5cXD0mIzQzOz0mIzQzOz0mIzQzOz1cPC9hPjxvOnA+PC9v OnA+PC9iPjwvcHJlPg0KPHByZT48Yj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgXCZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJzbWI6Ly8mIzQz Oz0mIzQzOz0mIzQzOz0mIzQzOy8iPlxcJiM0Mzs9JiM0Mzs9JiM0Mzs9JiM0MztcPC9hPjxvOnA+ PC9vOnA+PC9iPjwvcHJlPg0KPHByZT48Yj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgXCZuYnNwOyZuYnNwOyZuYnNwOyBcXD0mIzQzOz0m IzQzOz0mIzQzOz1cX19fX19fX188bzpwPjwvbzpwPjwvYj48L3ByZT4NCjxwcmU+PGI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFwmbmJzcDsmbmJzcDsmbmJzcDsgXFwmIzQzOz0mIzQzOz0mIzQzOz0mIzQzO19fX18tLS0tKSk8 bzpwPjwvbzpwPjwvYj48L3ByZT4NCjxwcmU+PGI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFwmbmJzcDsmbmJzcDsm bmJzcDsgXGAtLS0tLS0tLS0uKSkpXFw8bzpwPjwvbzpwPjwvYj48L3ByZT4NCjxwcmU+PGI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFwmbmJzcDsmbmJzcDsgfHwmIzQzOz0mIzQzOz0mIzQzOz0mIzQzOz0m IzQzOz1cXCAvXFw8bzpwPjwvbzpwPjwvYj48L3ByZT4NCjxwcmU+PGI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFwmbmJzcDsgfHxfX19fX19fX19fX1xcLyBcXDxvOnA+PC9vOnA+PC9iPjwvcHJl Pg0KPHByZT48Yj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgXCB8fC0tLS0tLS0tLS0t LVxcPG86cD48L286cD48L2I+PC9wcmU+DQo8cHJlPjxiPiZuYnNwOyBlam0mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgXHx8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFxcPG86cD48L286cD48L2I+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM5PR03MB2441E74275577721C0115CE8A61E0DM5PR03MB2441namp_-- From nobody Sun Aug 14 11:00:39 2016 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 4492012D788; Sun, 14 Aug 2016 11:00:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147119763827.13911.15538797272867633297.idtracker@ietfa.amsl.com> Date: Sun, 14 Aug 2016 11:00:38 -0700 Archived-At: Cc: cose@ietf.org Subject: [COSE] I-D Action: draft-ietf-cose-msg-17.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2016 18:00:38 -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 of the IETF. Title : CBOR Object Signing and Encryption (COSE) Author : Jim Schaad Filename : draft-ietf-cose-msg-17.txt Pages : 117 Date : 2016-08-14 Abstract: Concise Binary Object Representation (CBOR) is data format designed for small code size and small message size. There is a need for the ability to have the basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) specification. This specification describes how to create and process signature, message authentication codes and encryption using CBOR for serialization. This specification additionally specifies how to represent cryptographic keys using CBOR. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cose-msg-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-17 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 Sun Aug 14 11:26:14 2016 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 E5DC712B04A for ; Sun, 14 Aug 2016 11:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, 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 6f7fsV5pcW5f for ; Sun, 14 Aug 2016 11:26:12 -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 12F9712B00A for ; Sun, 14 Aug 2016 11:26:12 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 14 Aug 2016 11:37:55 -0700 From: Jim Schaad To: 'cose' References: <147119763839.13911.2967544845228455646.idtracker@ietfa.amsl.com> In-Reply-To: <147119763839.13911.2967544845228455646.idtracker@ietfa.amsl.com> Date: Sun, 14 Aug 2016 11:25:39 -0700 Message-ID: <032601d1f659$43c59700$cb50c500$@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: AQGpXG6TVTsCrW0SR9DMVcWkCKmLZ6CZ+Ybw Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: [COSE] FW: New Version Notification for draft-ietf-cose-msg-17.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2016 18:26:14 -0000 This just fixed a pair of small issues in the review for the Shepherds = writeup > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Sunday, August 14, 2016 11:01 AM > To: Jim Schaad > Subject: New Version Notification for draft-ietf-cose-msg-17.txt >=20 >=20 > A new version of I-D, draft-ietf-cose-msg-17.txt has been successfully = submitted > by Jim Schaad and posted to the IETF repository. >=20 > Name: draft-ietf-cose-msg > Revision: 17 > Title: CBOR Object Signing and Encryption (COSE) > Document date: 2016-08-14 > Group: cose > Pages: 117 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-cose-msg-17.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ > Htmlized: https://tools.ietf.org/html/draft-ietf-cose-msg-17 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cose-msg-17 >=20 > Abstract: > Concise Binary Object Representation (CBOR) is data format designed > for small code size and small message size. There is a need for = the > ability to have the basic security services defined for this data > format. This document defines the CBOR Object Signing and = Encryption > (COSE) specification. This specification describes how to create = and > process signature, message authentication codes and encryption = using > CBOR for serialization. This specification additionally specifies > how to represent cryptographic keys using CBOR. >=20 >=20 >=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 > The IETF Secretariat From nobody Mon Aug 15 00:05:27 2016 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 5D72212D87F for ; Mon, 15 Aug 2016 00:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sics-se.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 G9rFp6jIWY7l for ; Mon, 15 Aug 2016 00:05:23 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 1129612D09B for ; Mon, 15 Aug 2016 00:05:23 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id o80so85918081wme.1 for ; Mon, 15 Aug 2016 00:05:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=0CYJgVvE013sx4CgNdwYYTz0bV0mBCDtsDQbUNVT7SE=; b=YPYoyXkIcj3zb3ZX83EuJgefTDta+I7jhDLi/7Yi/AcMTTh5/PknUw3XOfJ447JLGS D3dT8tsxC6JEX6RdrYFwAvcUfGpKwDY1N5QDSq5orLDB4m3Y7FzYUVfVfHn3Vkq9ukEG YVXPMUUb/1TX4tSl3t7HahbINyMpN6G63yaCVE35IvzLposHVKZKgIQi2QR4Wop8HNkq 0VeeJc3O5BonOUX9jJDFqXoRjNzqpUR0GRMRtF6CBRD8bYqPAk4KTeqePm7Mk7uReODu 9qdEaxADRdu30njz8DSgQ1zez9fSV59oSZR8eX6tiLMPUPUQoNXhPs+Cqd/wM8ZrbH/R 3wXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=0CYJgVvE013sx4CgNdwYYTz0bV0mBCDtsDQbUNVT7SE=; b=HjLangpKI6yl2TRZUPgW7ETxXDkP4Vcg7YECZjjnTHAO/P4nmmvJCLGpiIMm+JnF7c E6+Sl+NGl02PrrPUZXthFx8/J/9i1d5Z/Klsqqf5vMaENs36nu76sHfFZmXu2p/j5FS7 VV5ZRpm6AO0NBNpzLFGR5zpwN8Bp0fjax6wQyyiI+XZ+tHoITAqKs78v4PeJNB5gpOVd 4Ml5KY2MVx99LeLB2UrXjpczFk1VlDdpW7IPi0ldURDVrjAYuigCNQGo/c9Fk8dDLar9 C6Ak4BuaAVFpSXYwr+nnP0rZqZZO06Rdc9YW4fta2Zmdm0UrQ5QT3ihukyctEK8WmI6u J3pw== X-Gm-Message-State: AEkoouuYsqGzayelhlprk+MWbe+7p6d+QB4p1f92mJ1WEHy410nehJfBaXDOF5XFdLLMyzwQ X-Received: by 10.25.16.212 with SMTP id 81mr4746455lfq.174.1471244721152; Mon, 15 Aug 2016 00:05:21 -0700 (PDT) Received: from [192.168.0.166] ([85.235.12.155]) by smtp.gmail.com with ESMTPSA id h13sm3485509lji.33.2016.08.15.00.05.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Aug 2016 00:05:20 -0700 (PDT) To: cose@ietf.org References: From: Ludwig Seitz Message-ID: Date: Mon, 15 Aug 2016 09:05:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040809020206000302010603" Archived-At: Subject: Re: [COSE] Adoption of RSA and alternative algorithms X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 07:05:25 -0000 This is a cryptographically signed message in MIME format. --------------ms040809020206000302010603 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 2016-07-29 16:04, Justin Richer wrote: > Hi all, hope that everyone is recovering from Berlin. As discussed in > the meeting last week, the working group is considering additional > work on RSA and other algorithms in the COSE messages framework. > These would be published in a document separate from the core draft > that is now on its journey to RFC-land. > > The chairs would like to gauge the sentiment of the working group on > a number of items related to this proposed work. Please respond with > your answers to the list. > > > 1) Do you think it=92s necessary or worthwhile to define RSA and other > additional algorithms in the COSE messages framework? E) I don=92t give a flying rat whether this gets done or not (Not relevant for the usecases I am looking at) > 2) If the work is adopted, where should it be done? > > A) Here in COSE (we=92ll keep the group open for this item) If we do it, COSE seems the most fitting WG to do it. I trust this would = not delay the other work in the group? > > 3) If the work is adopted, which draft is a good starting point? > E) I don=92t give a flying rat which document we start with > Regards, Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms040809020206000302010603 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CtQwggTqMIID0qADAgECAhAU4QcxMULaotNy8Yzm2pESMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMzE0MDkzNDMyWhcNMTcwMzE0MDkzNDMyWjA4MRcwFQYDVQQDDA5sdWR3 aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNpY3Muc2UwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9kgmm82Op78D9DXYNJrQW5bUdSxElnOC/CzAK/enHn+uF B/RLo8alI6Ukd35qsAtcje0I3e/RtbkRnkEuhKneH+aDRofy7YaWQO61CjIlcdndTx8FEmXK /swcafYX5PbyzQFGgApwtWFkVXcq3R87CDB3VbkHzTHIBmfwZ4hhDeEyuJoSuWEVWQppfTji /GpVLiDx6s+Zqm3qI5EkjvhQ+jX3tJxXqUf4w1BY6/sBLfvr7TOPGPoAmi6B2UOgyDSfX3c0 +jzlYFLNb6Eqc7uGvaQi7VN39kAJXz9f+qL/wokaNjboK3/JyTG/ikxsWymzO9E0/U9apn2Y z5SVUGSDAgMBAAGjggGxMIIBrTAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFN37NX1Db3Xp23cbQI1MpYPUMw84 MB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMwYTAkBggr BgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUFBzAChi1odHRwOi8v YWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYDVR0fBDEwLzAtoCug KYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMBkGA1UdEQQSMBCB Dmx1ZHdpZ0BzaWNzLnNlMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBG BgNVHSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEAUy78MN+soYHwIz+6m9mMkzPF KfgIq7sLupWnis7K5U66U9zfKOVDReyfUvPmar7P7Tb9uNNrUlkk3lSISplqU30TMnVbtK5D I0mxdpa1hZxIAa8uWQnAh/oYJJYaMziKxpZgsUjel6/ZnD0z/QsuHo763I1boi2ghe4Knj0f qFO79ErRr9aJJBfQlFVwQ4gRoYtMz18/usC3eqGxFz8a/LCeRMWeZJagGJ/St1WW1HUBmMFd vRFweeUdCvDbzK+WjqbxhXyi7b0sH65lWIjINCBVQ0AvqOwm/aXEWcIQlAIJjr2kEC6c0VY6 V1aP16BAKooEgGGOTrmcDGeteXZRyjCCBeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEw DQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMT IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMw MTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAn BgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFy dENvbSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AL192vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGt TCRk9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdf a89VLnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx 7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4D IM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFg MA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0T AQH/BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5z dGFydHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRz L2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvv GqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wB i4StDwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspB OB/y5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvets D+bjyOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyI NBfCBJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA 0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf 1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/ tdfrBzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH 2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9 VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp /2deoprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhAU4QcxMULa otNy8Yzm2pESMA0GCWCGSAFlAwQCAQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNjA4MTUwNzA1MTlaMC8GCSqGSIb3DQEJBDEiBCDIg08XY1ka 49RKqgYpCscm90SbcdYoS8ughH0maoba0jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVu dCBDQQIQFOEHMTFC2qLTcvGM5tqREjCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD QQIQFOEHMTFC2qLTcvGM5tqREjANBgkqhkiG9w0BAQEFAASCAQBPZFS9VyWZmtSqE1PitIgz AQFdmZOzbT93Ger9jhHCy7Te+uyr9sqK8+pbIxqoYOTWOq3y9QVhUSzxZN81Cscws2QQD4EY UYFcXYZspCs+vpVuZrpVYjAZdSwyR7Nz98oDQ2ILKdF+cOqAYEew3iJxhFe5Y5s05GzJIpY/ zFzJV4VFr7GLeBNLVT4EtLMAsW8N/VqIJ/rLWQ3g9uipqh3ivv4A1gjLJPGI5BnXKHTuxr2n Xjm3rNV5wRw1KQFT1m9cWxlIWzVshG0kbtsu/+xnYYWJcIe3ntKw21S8hKAkv1Bb3U0KQMFq iQ4bEG1wH3qt4I+C3b9Th4yCXuZ7V6sYAAAAAAAA --------------ms040809020206000302010603-- From nobody Mon Aug 15 05:48:58 2016 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 B491212DD4C for ; Mon, 15 Aug 2016 05:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, 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 FbhbQpFrpuuQ for ; Mon, 15 Aug 2016 05:48:56 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 9C39B12DD4B for ; Mon, 15 Aug 2016 05:48:56 -0700 (PDT) X-AuditID: 12074423-5dbff700000029ea-8f-57b1ba375f0f Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 2D.2B.10730.73AB1B75; Mon, 15 Aug 2016 08:48:55 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u7FCmsjl019151 for ; Mon, 15 Aug 2016 08:48:54 -0400 Received: from [10.12.107.166] ([12.38.6.17]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u7FCmrxR019470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 15 Aug 2016 08:48:54 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_F89C7FA4-01BE-46F4-88B8-02B62CF8450D" Message-Id: Date: Mon, 15 Aug 2016 08:48:52 -0400 To: cose Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCIsWRmVeSWpSXmKPExsUixCmqrWu+a2O4wd3l8hbTtk5ldWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqb+qawFiyUr5q+Zw9rAuEG0i5GTQ0LARGLx80csXYxcHEIC bUwSj96sZ4VwjjJK/PrfCeXsY5J49uIFO0gLm4CqxPQ1LUwgNrNAgkTfsQ6gdg4OYQFxiSv/ U0HCvAJWEvNvz2MHCbMAle/bWgNiighISFzYUAZRoSexaf1bJogbZCWenFzEMoGRZxaSmbOQ lEHEtSWWLXzNDGFrSuzvXs6CKa4h0fltIusCRrZVjLIpuVW6uYmZOcWpybrFyYl5ealFumZ6 uZkleqkppZsYQYHH7qK8g/Fln/chRgEORiUeXoG6DeFCrIllxZW5hxglOZiURHlnTtwYLsSX lJ9SmZFYnBFfVJqTWnyIUYKDWUmEd8YWoBxvSmJlVWpRPkxKmoNFSZx3+7f2cCGB9MSS1OzU 1ILUIpisDAeHkgTvpR1AjYJFqempFWmZOSUIaSYOTpDhPEDDb4LU8BYXJOYWZ6ZD5E8xKkqJ 8zaBJARAEhmleXC9oMTAo8Ym+IpRHOgVYV7NnUBVPMCkAtf9CmgwE9BgfekNIINLEhFSUg2M PJuD59gn7HZbFz6DZ7H/lm9fjN/cV7v6xU4hM6Nsw9amFKtDYs/q7a5Mzb/FcFV0tm3m/Deu fTz1Nycv4HizWeeSqVxEyRLB5lo1NaP4PS8U3dbZ56TKyzj+Noi6UVjmtTFyq6OI5bS3r07f yjz0qEy9vDC1L2wfr+bcpQv9tVIP3GBYs0pFiaU4I9FQi7moOBEAZE0vCecCAAA= Archived-At: Subject: [COSE] RSA Algorithms X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 12:48:57 -0000 --Apple-Mail=_F89C7FA4-01BE-46F4-88B8-02B62CF8450D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi COSE group, After some discussion, the chairs and the AD have determined that there = is not broad enough support for the RSA algorithms draft at this time to = move the work forward. As such, it is our plan to close the COSE working = group at the completion of the messages draft. If the RSA algorithms = draft gathers momentum in the future, it can go forward as an = AD-sponsored extension to the core specification, or another WG can pick = it up. The chairs encourage those who support the RSA extension to = pursue one of these avenues if they=E2=80=99d like to see the document = go forward. Thank you, Justin & Kepeng, your COSE chairs __________. /_/-----/_/| __ ( ( ' ' ( (| /'--'\ (_( ' ' (_(|/. .\ / /=3D=3D=3D=3D=3D/ /| '||' /_//____/_/ | || (o|:.....|o) | || |_|:_____|_|/' _||_ ' ' /____\ --Apple-Mail=_F89C7FA4-01BE-46F4-88B8-02B62CF8450D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi COSE group,

After some discussion, the chairs and the AD have determined = that there is not broad enough support for the RSA algorithms draft at = this time to move the work forward. As such, it is our plan to close the = COSE working group at the completion of the messages draft. If the RSA = algorithms draft gathers momentum in the future, it can go forward as an = AD-sponsored extension to the core specification, or another WG can pick = it up. The chairs encourage those who support the RSA extension to = pursue one of these avenues if they=E2=80=99d like to see the document = go forward.

Thank you,
  Justin & Kepeng, = your COSE chairs

  =  __________.
  /_/-----/_/|   __
  ( ( ' ' ( (| /'--'\
  (_( ' ' (_(|/.   =  .\
  / /=3D=3D=3D=3D=3D/ /|  '||'
 /_//____/_/ |   = ||
(o|:.....|o) |   ||
|_|:_____|_|/'  _||_
 '       =  '    /____\

= --Apple-Mail=_F89C7FA4-01BE-46F4-88B8-02B62CF8450D-- From nobody Fri Aug 19 20:38:09 2016 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 7BCE912D593; Fri, 19 Aug 2016 20:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, 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 8hhM51Lu9tfa; Fri, 19 Aug 2016 20:38:07 -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 1BCB112D59D; Fri, 19 Aug 2016 20:38:07 -0700 (PDT) Received: from hebrews (50.39.87.194) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 19 Aug 2016 20:50:01 -0700 From: Jim Schaad To: Date: Fri, 19 Aug 2016 20:37:42 -0700 Message-ID: <000e01d1fa94$367b9e70$a372db50$@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: AdH6kokei5TGRZTvT2Kzds0e5Iym2g== Content-Language: en-us X-Originating-IP: [50.39.87.194] Archived-At: Cc: 'cose' Subject: [COSE] draft-birkholz-sacm-coswid-01 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 03:38:08 -0000 This represents a fast read through and not a hard review. Section 1 - bullet point 2 - I think that the reference to X.1520 is in the wrong place Section 2 - the change of the naming scheme seems to be gratuitous. You need to justify it if you are going to keep it. Section 3 - why are you wrapping a hash in a bstr rather than leaving it as an array? Section 4 - you have the protected and unprotected header restrictions backwards Jim From nobody Fri Aug 19 21:03:24 2016 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 8910512D114; Fri, 19 Aug 2016 21:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, 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 HdIWCk2W4fJx; Fri, 19 Aug 2016 21:03:21 -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 0B60012B042; Fri, 19 Aug 2016 21:03:21 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 19 Aug 2016 21:15:08 -0700 From: Jim Schaad To: Date: Fri, 19 Aug 2016 21:02:48 -0700 Message-ID: <000f01d1fa97$b8838dd0$298aa970$@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: AdH6kokei5TGRZTvT2Kzds0e5Iym2g== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: 'cose' Subject: [COSE] draft-birkholz-sacm-coswid-01 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 04:03:22 -0000 This represents a fast read through and not a hard review. Section 1 - bullet point 2 - I think that the reference to X.1520 is in the wrong place Section 2 - the change of the naming scheme seems to be gratuitous. You need to justify it if you are going to keep it. Section 3 - why are you wrapping a hash in a bstr rather than leaving it as an array? Section 4 - you have the protected and unprotected header restrictions backwards Jim From nobody Fri Aug 19 21:13:56 2016 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 0A02F12D5B5 for ; Fri, 19 Aug 2016 21:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, 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 xU_E3HtSKn5D for ; Fri, 19 Aug 2016 21:13:53 -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 39D1D12D5B2 for ; Fri, 19 Aug 2016 21:13:53 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 19 Aug 2016 21:26:07 -0700 From: Jim Schaad To: 'cose' References: <000e01d1fa94$367b9e70$a372db50$@augustcellars.com> In-Reply-To: <000e01d1fa94$367b9e70$a372db50$@augustcellars.com> Date: Fri, 19 Aug 2016 21:13:48 -0700 Message-ID: <001601d1fa99$416da4e0$c448eea0$@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: AQEtwLjjDh6HbAn+VJSXTHFk4tqcZqGZsP4A Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [COSE] draft-birkholz-sacm-coswid-01 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 04:13:55 -0000 Wrong mail list > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Friday, August 19, 2016 8:38 PM > To: draft-birkholz-sacm-coswid@ietf.org > Cc: 'cose' > Subject: [COSE] draft-birkholz-sacm-coswid-01 > > This represents a fast read through and not a hard review. > > Section 1 - bullet point 2 - I think that the reference to X.1520 is in the wrong > place > > Section 2 - the change of the naming scheme seems to be gratuitous. You need > to justify it if you are going to keep it. > > Section 3 - why are you wrapping a hash in a bstr rather than leaving it as an > array? > > Section 4 - you have the protected and unprotected header restrictions > backwards > > Jim > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Tue Aug 30 07:34:02 2016 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 F05F312D162; Tue, 30 Aug 2016 07:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.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 Qau_5yFGV452; Tue, 30 Aug 2016 07:33:52 -0700 (PDT) Received: from out4133-146.mail.aliyun.com (out4133-146.mail.aliyun.com [42.120.133.146]) by ietfa.amsl.com (Postfix) with ESMTP id 40F7F12D619; Tue, 30 Aug 2016 07:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1472567457; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=9W7941pJZm2h1JVcWYpzlYMjfFU7/ePK1GSmm3C1+f4=; b=fvpqLZNX9GJUeHirBGpja705wv2TjH8TVrseQCscP6Wnpsyqli2I+dDk8P43YgxSkdeTarGU6IqM87Srp/WMRLs3c6nySzqKda9y5gE/mJ8605vvKaZDf4NLgXiyF59FosrVfyDF26FevkM9N801PC4ZCFhBZU1hV/4pHvqxb4M= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R861e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03293; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=2; SR=0; TI=SMTPD_----5DeDlVN_1472567447; Received: from 30.39.21.91(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.207) by smtp.aliyun-inc.com(127.0.0.1); Tue, 30 Aug 2016 22:30:51 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Tue, 30 Aug 2016 22:30:43 +0800 From: "Kepeng Li" To: cose , ace Message-ID: Thread-Topic: NomCom 2016-2017: Call for Nominations References: <147250302871.19142.11825877398134368393.idtracker@ietfa.amsl.com> In-Reply-To: <147250302871.19142.11825877398134368393.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Subject: [COSE] FW: NomCom 2016-2017: Call for Nominations X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 14:33:57 -0000 FYI. =D4=DA 29/8/16 10:37 pm=A3=AC "NomCom Chair 2016" =D0=B4=C8=EB= : >Please forward on to your Working Groups - > >The 2016-17 Nominating Committee (Nomcom) is seeking nominations from >now until October 8, 2016. The open positions being considered by this >year's Nomcom can be found at the end of this email and also on this >year's Nomcom website: > >https://datatracker.ietf.org/nomcom/2016/ > >Nominations may be made by selecting the Nominate link at the top of >the Nomcom 2016 home page, or by visiting the following URL: > >https://datatracker.ietf.org/nomcom/2016/nominate/ > > {Note that nominations made using the web tool require an ietf.org > datatracker account. You can create a datatracker ietf.org account > if you don't have one already by visiting the following URL: > https://datatracker.ietf.org/accounts/create/ } > >If you are unable to use the web form, nominations may instead be made >by email to nomcom-16@ietf.org. If using email, please include the word >"Nominate" in the Subject and indicate in the email who is being >nominated, their email address (to confirm acceptance of the >nomination), and the position for which you are making the nomination. >If you are nominating someone other than yourself, please tell us if >we may tell the nominee that you were the one who made the nomination. >If you wish to nominate someone via email for more than one position, >please use separate emails to do so. > >Self-nomination is welcome! > >Willing nominees will be asked to fill out a questionnaire >specific to the position for which they are nominated. The questionnaires >will be available on September 2, 2016 and have a submission deadline of >October 13, 2016. > >NomCom 2016-17 will follow the policy for "Open Disclosure of Willing >Nominees" described in BCP 10/RFC 7437. As stated in RFC 7437: "The >list of nominees willing to be considered for positions under review >in the current Nomcom cycle is not confidential". Willing nominees for >each position will be listed in a publicly accessible way - anyone >with a datatracker account may access the lists. Additionally, the >nomination form asks if we may share your own name with the >nominee. In all other ways, the confidentiality requirements of BCP10 >remain in effect. All feedback and all Nomcom deliberations will >remain confidential and will not be disclosed. > >There is a field on the form you can mark in order to allow the Nomcom >to tell the nominee that you were the one who made the >nomination. This defaults to =A1=B0no=A1=B1 - so if you don't mark the field >we won=A1=AFt tell. > >In order to ensure time to collect sufficient community feedback about >each of the willing nominees, nominations must be received by the >NomCom on or before October 8, 2016. > >Please submit your nominations as early as possible for the sake of >your nominees. Note that nominations should not wait for management >permission, as it is easier to decline the nomination than put one in >late. > >The Nomcom appoints individuals to fill the open slots on the IAOC, >the IAB, and the IESG. The list of people and posts whose terms end >with the March 2017 IETF meeting, and thus the positions for which >this Nomcom is responsible, follows: > >IAOC > > Lou Berger > >IAB > > Ralph Droms* > Russ Housley* > Robert Sparks > Andrew Sullivan > Dave Thaler* > Suzanne Woolf > >IESG > > Jari Arkko (GEN)* > Deborah Brungard (RTG) > Ben Campbell (ART) > Spencer Dawkins (TSV) > Stephen Farrell (SEC)* > Joel Jaeggli (OPS)* > Terry Manderson (INT) > Alvaro Retana (RTG) > >*- have indicated that they do not intend to accept a >renomination. This information is always up to date on >https://datatracker.ietf.org/nomcom/2016/ > >Please be resourceful in identifying possible candidates for these >positions, as developing our talent is a very crucial requirement for >the IETF, and also, please consider accepting a nomination. You'll >find extensive information about specific positions, developed by the >IAB, IESG, and IAOC, under individual tabs at: > > https://datatracker.ietf.org/nomcom/2016/requirements/ > >In addition to nominations, the Nomcom seeks community input on the >positions themselves. We need and welcome the community's views and >input on the jobs within each organization. If you have ideas on the >positions' responsibilities (more, less, different), please let us >know. > >Please send suggestions and feedback about this to nomcom-16@ietf.org. > >Thank you for your help in identifying qualified nominees! > >Lucy Lynch >Nomcom Chair 2016-17 >nomcom-chair-2016@ietf.org >llynch@civil-tongue.net