From nobody Fri Sep 2 19:58:31 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 906F412D08C for ; Fri, 2 Sep 2016 19:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 dB9POYK0iD4O for ; Fri, 2 Sep 2016 19:58:27 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (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 5FF6212B016 for ; Fri, 2 Sep 2016 19:58:27 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id q42so134690200uaq.1 for ; Fri, 02 Sep 2016 19:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=QACEUWa/6MPxoyyBxQAK6C++xkBbK+xQiQNAynNDuHQ=; b=JAMo5bCwB1OySuEZv+PnXoAVgwueGyQ6ISUMEsiUaynRAF9IGQOjOIzy3et3EdTPCd zUoMbONgUkdlf+a05Cxg9IerPmXbBHO/Y4FIXtqQsVCZIAChOPe3Qbax1UmRvjYzmPEq ijFik24u893syN3CUVINDI6gbb/J0X4qQN+HO3Owys7cZe/bwDXzl5MSKF8KuCL99L7e Ou88PA/46ZpKcPkDd/CIwshK59xsi3e+JlgbPBNPW6Aphx1Q90aN7tvNpcozpILx1S79 YRai/N/Eo2if3A1RliriPN8RyJ4/DGfV5oi8litEFBDNPZ5txg2Fm6KAvP4EkRuopR8Y cbEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=QACEUWa/6MPxoyyBxQAK6C++xkBbK+xQiQNAynNDuHQ=; b=VVpGwQYFUpPiSbP+Q8a2II23dZT7amX19V6hbNn3IQPOfWcTD7mM6q3fX5hNJVkv/L OfLT9m9/nhewZAQ7+0nw+VLKpCoM9iZcRGjEj8ecnqXOfV04+WYWGZObVnaoaO7qap+5 VCZAM2Ld4+PXsiukISFMOBrRFL3/cAlvz+jcMpbaoPGeAsl6LRSK8i3VFePfVCUAs+Mt StKhttSlPeP2N6x+BvwDtTKzqt0EeFIE1FBqEJdwxp+gQU4VpQ2RaKpS5Fh4KhOEg9mc ET4izaAWim2iEvNvnRpwiMJJSnlnBd9aAl5txY2AsBPeUO5J9wXsjU9vfbljs+vqICAD eS5A== X-Gm-Message-State: AE9vXwPljpcY6cqQhXRn8Lqvmo669I92+PSlYoMeSJkc6n/14Ym/6HJ4lbsS5Ykh7WQAuVS7CqKCw1m+lwl+QQ== X-Received: by 10.176.81.196 with SMTP id h4mr15827758uaa.95.1472871506321; Fri, 02 Sep 2016 19:58:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.40.226 with HTTP; Fri, 2 Sep 2016 19:58:25 -0700 (PDT) From: Kathleen Moriarty Date: Fri, 2 Sep 2016 22:58:25 -0400 Message-ID: To: "cose@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [COSE] AD review of draft-ietf-cose-msg 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, 03 Sep 2016 02:58:29 -0000 Hello, Thank you all for your work on draft-ietf-cose-msg. I mainly have nits to fix in my comments, which is bound to happen with such a long draft. Sorry for the time it took to turn this review around. I haven't looked at the shepherd report yet, but it will need to include any remaining downrefs - assuming some of the idnits for this can be cleaned up. The idnits need to be checked as well as there are some formatting problems that can easily be corrected. Nits: Abstract Change from: 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. To: Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. Introduction: Change from: There has been an increased focus on the small, constrained devices that make up the Internet of Things (IoT). To: There has been an increased focus on small, constrained devices that make up the Internet of Things (IoT). Change from: A need exists to provide message security services for IoT and using CBOR as the message encoding format makes sense. To: A need exists to provide message security services for IoT, using CBOR as the message encoding format makes sense. Section 1.1 Change from: o Define a single top message structure so that encrypted, signed and MACed messages can easily identified and still have a consistent view. To: o Define a single top message structure so that encrypted, signed and MACed messages can easily be identified and still have a consistent view. For the following, I am not sure I am parsing this correctly, can it be rephrased: o Signed messages separate the concept of protected and unprotected parameters that are for the content and the signature. Section 3: In the 'protected' bucket definition: change from: Senders SHOULD encode an zero length map as a zero length string rather than as a zero length map (encoded as h'a0'). To: Senders SHOULD encode a zero length map as a zero length string rather than as a zero length map (encoded as h'a0'). s/an/a/ Change from: After encoding the map the value is wrapped in the binary object. To: After encoding the map, the value is wrapped in the binary object. Section 4: Second sentence: Can this be reworded from: COSE_Sign allows for one or more signers to be applied to a single content. To: COSE_Sign allows for one or more signers to be applied to a single piece of content. It doesn't read well to me, but if that is a well understood way to phrase this, let me know. Section 4.1: Can the second "about" be changed to "for" or "describing"? It took me a few times reading this to get it. current: There are provisions for parameters about the content and parameters about the signature to be carried along with the signature itself. Section 4.1 middle of second paragraph: Change from: Support of different communities of recipients is the primary reason that signers choose to include more than one signature. To: Support for different communities of recipients is the primary reason that signers choose to include more than one signature. Section 5.4, second bullet #3 Is this intended to be "Direct and Direct"? Direct and Direct Key Agreement: The key is determined by the key and algorithm in the recipient structure. =E2=80=A6 Section 6.4: Change from: How to verify a MAC are: To: The steps of how to verify a MAC are: You don't save a line of text, so it would be better to include what is needed for it to be easily understood. Section 9, first paragraph: Remove the parens and s/One/A MAC/ Change from: (One cannot, for example, be used to prove the identity of the sender to a third party.) To: A MAC cannot, for example, be used to prove the identity of the sender to a third party. *Many of the places where parenthesis are used, it would be better to remove them and leave the sentence as part of the paragraph. Section 9.1.1: second sentence should be more clear that the "method is an attack method. How about change from: The current best method appears to be a brute force attack on the key. To: The current best attack method appears to be brute force on the key. Section 9.2.1, first bullet, second sentence: Remove the last comma. change from: If this is not the case, an attacker will be able to generate a message with a valid tag given two message, tag pairs. To: If this is not the case, an attacker will be able to generate a message with a valid tag given two message tag pairs. Same section, the second bullet doesn't read well. The current text: o If the same key is used for both encryption and authentication operations, using CBC modes an attacker can produce messages with a valid authentication code. How about: o When using CBC mode, if the same key is used for both encryption and authentication operations, an attacker can produce messages with a valid authentication code. Section 10.2, 4th paragraph, second to last sentence: Change from (s/user/use/): Less constrained devices will want to be able to user larger messages and are more willing to generate new keys for every operation. This favors larger values of L and M. To: Less constrained devices will want to be able to use larger messages and are more willing to generate new keys for every operation. This favors larger values of L and M. Same section, third to last bullet, add "is": Change from: o If the 'alg' field present, it MUST match the AES-CCM algorithm being used. To: o If the 'alg' field is present, it MUST match the AES-CCM algorithm being used. Section 12.1.2.1 Is PFS spelled out in the draft before this use? Just checking=E2=80=A6 I= t might not be as it appears as "perfect forward secrecy (no abbreviation) and RFC4949 in section 12.4 Section 15, second paragraph: It reads oddly to me=E2=80=A6 Applications are therefore intended to profile the usage of this document. This section provides a set of guidelines and topics that applications need to consider when using this document. What do you mean by 'profile the usage'? Should this be worded differently= ? Section 16.2 I think it's a little confusing to state the registry values require expert review, then buried in the 'label' description say it can be specification required. Wouldn't it be more clear to state that a dependency exists and a specification is required in the intro paragraph for this section? This applies to the other sections that also require a specification as it don't seem that all registries do. Section 16.7 There is a spurious > character It is requested that IANA create a new registry "COSE Key Type Registry"> The Section 16.11, third bullet: Can you rephrase the following sentence, it could read better: Some of the ranges are restricted in range, items that are not expected to be common or are not expected to be used in constrained environments should be assigned to values which will encode to longer byte strings. Section 17. I don't see theft that says this section should be removed upon publication. Is it supposed to be retained in the document? Just checking as I thought the boiler plate for this has them being removed. Section 18: This bullet is difficult to read, is it missing an "or"?: o Use of 'direct' as a recipient algorithm combined with a second recipient algorithm, either directly in a separate message, exposes the direct key to the second recipient. How about: o Use of 'direct' as a recipient algorithm combined with a second recipient algorithm, either directly or in a separate message, exposes the direct key to the second recipient. Thank you! It's nice to see this get wrapped up in a timely manner. --=20 Best regards, Kathleen From nobody Sat Sep 3 14:59:55 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 1E48C12B076 for ; Sat, 3 Sep 2016 14:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-1.508, 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 VojOraeXpi5H for ; Sat, 3 Sep 2016 14:59:51 -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 2A41A12B010 for ; Sat, 3 Sep 2016 14:59:50 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 3 Sep 2016 15:12:16 -0700 From: Jim Schaad To: 'Kathleen Moriarty' , References: In-Reply-To: Date: Sat, 3 Sep 2016 14:59:06 -0700 Message-ID: <0a1801d2062e$6604d260$320e7720$@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: AQDp94lwGHQJUgjVV1PYuK1ecb6CG6I4SOkg Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Subject: Re: [COSE] AD review of draft-ietf-cose-msg 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, 03 Sep 2016 21:59:54 -0000 > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Kathleen = Moriarty > Sent: Friday, September 02, 2016 7:58 PM > To: cose@ietf.org > Subject: [COSE] AD review of draft-ietf-cose-msg >=20 > Hello, >=20 > Thank you all for your work on draft-ietf-cose-msg. I mainly have = nits to fix in > my comments, which is bound to happen with such a long draft. Sorry = for the > time it took to turn this review around. >=20 > I haven't looked at the shepherd report yet, but it will need to = include any > remaining downrefs - assuming some of the idnits for this can be = cleaned up. > The idnits need to be checked as well as there are some formatting = problems > that can easily be corrected. The formatting issues are going to need to be fixed either by the RFC = Editor or by a new fix to xml2rfc. It has to do with the fact that I do = a hanging text list for a sentence rather than for a key word followed = by punctuation. >=20 >=20 > Nits: >=20 > Abstract >=20 > Change from: > 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. > To: > Concise Binary Object Representation (CBOR) is a data format = designed > for small code size and small message size. There is a need for = the > ability to have basic security services defined for this data > format. Done >=20 > Introduction: > Change from: > There has been an increased focus on the small, constrained devices > that make up the Internet of Things (IoT). > To: > There has been an increased focus on small, constrained devices > that make up the Internet of Things (IoT). Done > Change from: > A need exists to provide message security > services for IoT and using CBOR as the message encoding format = makes > sense. > To: > A need exists to provide message security > services for IoT, using CBOR as the message encoding format makes > sense. Done >=20 > Section 1.1 > Change from: > o Define a single top message structure so that encrypted, signed > and MACed messages can easily identified and still have a > consistent view. > To: > o Define a single top message structure so that encrypted, signed > and MACed messages can easily be identified and still have a > consistent view. Done >=20 > For the following, I am not sure I am parsing this correctly, can it = be rephrased: > o Signed messages separate the concept of protected and = unprotected > parameters that are for the content and the signature. >=20 Does this work? o Signed messages distinguish between the protected and unprotected = parameters that relate to the content from those that relate to the = signature. > Section 3: > In the 'protected' bucket definition: > change from: > Senders SHOULD encode an zero length map as a zero > length string rather than as a zero length map (encoded as = h'a0'). > To: > Senders SHOULD encode a zero length map as a zero > length string rather than as a zero length map (encoded as = h'a0'). > s/an/a/ Done >=20 > Change from: > After encoding the map the value is > wrapped in the binary object. > To: > After encoding the map, the value is > wrapped in the binary object. > Done =20 > Section 4: Second sentence: >=20 > Can this be reworded from: > COSE_Sign allows > for one or more signers to be applied to a single content. > To: COSE_Sign allows > for one or more signers to be applied to a single piece of content. >=20 > It doesn't read well to me, but if that is a well understood way to = phrase this, let > me know. How does this work? COSE_Sign allows for one or more signatures to be applied to the = same content. >=20 > Section 4.1: Can the second "about" be changed to "for" or = "describing"? It took > me a few times reading this to get it. > current: > There are provisions for parameters > about the content and parameters about the signature to be carried > along with the signature itself. Does this work? Parameters related to the content and parameters related to the = signature are carried along with the signature itself. >=20 > Section 4.1 middle of second paragraph: > Change from: > Support of different communities of > recipients is the primary reason that signers choose to include = more > than one signature. > To: > Support for different communities of > recipients is the primary reason that signers choose to include = more > than one signature. Done >=20 > Section 5.4, second bullet #3 > Is this intended to be "Direct and Direct"? > Direct and Direct Key Agreement: The key is determined by = the > key and algorithm in the recipient structure. =E2=80=A6 >=20 If I use the section titles it becomes: Direct Encryption and Direct Key Agreement: ... I think this might be better - what do you think? > Section 6.4: > Change from: > How to verify a MAC are: > To: > The steps of how to verify a MAC are: >=20 > You don't save a line of text, so it would be better to include what = is needed for > it to be easily understood. Done >=20 > Section 9, first paragraph: > Remove the parens and s/One/A MAC/ > Change from: > (One cannot, for example, be used to prove the identity > of the sender to a third party.) > To: A MAC cannot, for example, be used to prove the identity > of the sender to a third party. Done >=20 > *Many of the places where parenthesis are used, it would be better to = remove > them and leave the sentence as part of the paragraph. I have included a note to the RFC editor to look at this as an issue. I = think that they should stay as that is the way that I thought it should = be at the time. >=20 > Section 9.1.1: second sentence should be more clear that the "method = is an > attack method. How about change from: > The current best method appears to be a > brute force attack on the key. > To: > The current best attack method appears to be > brute force on the key. Changed to=20 The current best attack appears to be brute force on the key. >=20 > Section 9.2.1, first bullet, second sentence: > Remove the last comma. > change from: > If this is not the case, an attacker will be able to > generate a message with a valid tag given two message, tag = pairs. > To: > If this is not the case, an attacker will be able to > generate a message with a valid tag given two message tag pairs. Changed to=20 given to message and tag pairs >=20 > Same section, the second bullet doesn't read well. The current text: > o If the same key is used for both encryption and authentication > operations, using CBC modes an attacker can produce messages = with > a valid authentication code. > How about: > o When using CBC mode, if the same key is used for both encryption = and > authentication > operations, an attacker can produce messages with > a valid authentication code. Done >=20 > Section 10.2, 4th paragraph, second to last sentence: > Change from (s/user/use/): > Less constrained devices will want to be able to user > larger messages and are more willing to generate new keys for every > operation. This favors larger values of L and M. > To: > Less constrained devices will want to be able to use > larger messages and are more willing to generate new keys for every > operation. This favors larger values of L and M. Done >=20 > Same section, third to last bullet, add "is": > Change from: > o If the 'alg' field present, it MUST match the AES-CCM algorithm > being used. > To: > o If the 'alg' field is present, it MUST match the AES-CCM = algorithm > being used. Done, along with the rest of the cut and pastes from here. >=20 > Section 12.1.2.1 >=20 > Is PFS spelled out in the draft before this use? Just = checking=E2=80=A6 It might not be as > it appears as "perfect forward secrecy (no > abbreviation) and RFC4949 in section 12.4 Does not appear to be - It is now expanded >=20 > Section 15, second paragraph: >=20 > It reads oddly to me=E2=80=A6 > Applications are therefore intended to profile the usage of this > document. This section provides a set of guidelines and topics = that > applications need to consider when using this document. >=20 > What do you mean by 'profile the usage'? Should this be worded = differently? Does this make more sense? It is intended that a profile of this document be created that = defines the interopability requirements for that specific application. This section provides a set of guidelines and topics that need = to be considered when profiling this document. >=20 > Section 16.2 >=20 > I think it's a little confusing to state the registry values require = expert review, > then buried in the 'label' description say it can be specification = required. > Wouldn't it be more clear to state that a dependency exists and a = specification is > required in the intro paragraph for this section? This applies to the = other > sections that also require a specification as it don't seem that all = registries do. >=20 > Section 16.7 >=20 > There is a spurious > character > It is requested that IANA create a new registry "COSE Key Type > Registry"> The Typo should have been a period. Done >=20 > Section 16.11, third bullet: Can you rephrase the following sentence, = it could > read better: > Some > of the ranges are restricted in range, items that are not = expected > to be common or are not expected to be used in constrained > environments should be assigned to values which will encode to > longer byte strings. Does this work any better? The length of the encoded value should be weighed against = how many code points of that length are left, the capabilities of = devices for expected use, and the number of code points left that encode = to that size. >=20 > Section 17. >=20 > I don't see theft that says this section should be removed upon > publication. Is it supposed to be retained in the document? Just > checking as I thought the boiler plate for this has them being = removed. Currently it is just as a comment in the XML to the RFC Editor rather = than as explicit text in the document. I think this meets the spirit of = the request in RFC 7942. >=20 > Section 18: This bullet is difficult to read, is it missing an "or"?: > o Use of 'direct' as a recipient algorithm combined with a second > recipient algorithm, either directly in a separate message, > exposes the direct key to the second recipient. > How about: > o Use of 'direct' as a recipient algorithm combined with a second > recipient algorithm, either directly or in a separate message, > exposes the direct key to the second recipient. I have just removed the secondary clause entirely. I don't think it = helps anything anymore. >=20 >=20 >=20 > Thank you! It's nice to see this get wrapped up in a timely manner. Jim > -- >=20 > Best regards, > Kathleen >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Sat Sep 3 15:59:00 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 740F412B118 for ; Sat, 3 Sep 2016 15:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-1.508, 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 Ofoz9870SBMG for ; Sat, 3 Sep 2016 15:58:57 -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 8316712B006 for ; Sat, 3 Sep 2016 15:58:56 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 3 Sep 2016 16:11:56 -0700 From: Jim Schaad To: 'Kathleen Moriarty' , References: In-Reply-To: Date: Sat, 3 Sep 2016 15:58:47 -0700 Message-ID: <0a2101d20636$bc946c50$35bd44f0$@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: AQDp94lwGHQJUgjVV1PYuK1ecb6CG6I4cA6w Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Subject: Re: [COSE] AD review of draft-ietf-cose-msg 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, 03 Sep 2016 22:58:58 -0000 > Section 16.2 >=20 > I think it's a little confusing to state the registry values require = expert review, > then buried in the 'label' description say it can be specification = required. > Wouldn't it be more clear to state that a dependency exists and a = specification is > required in the intro paragraph for this section? This applies to the = other > sections that also require a specification as it don't seem that all = registries do. >=20 I separated this issue because I think it is potentially going to need = more discussion than any of the other issues. >From the IANA point of view, I want to keep these registry rules simple. = That is, I want IANA to treat the registries as if everything is expert = review. Given that I want to break down the label ranges. Would it makes sense = to move this language from here to section 16.11 so that it is clear = that this will be for the expert reviewers to look at rather than for = IANA to look at? Jim From nobody Sun Sep 4 19:21:20 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 8E54212B11D for ; Sun, 4 Sep 2016 19:21:19 -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, FREEMAIL_FROM=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 p7pjMfA2-tS3 for ; Sun, 4 Sep 2016 19:21:17 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (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 6E7C712B14D for ; Sun, 4 Sep 2016 19:21:17 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id f76so67045284vke.0 for ; Sun, 04 Sep 2016 19:21:17 -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:content-transfer-encoding; bh=tIX8pqpkkMCoP/wxgTHxHVq8lm0eHUn7gy/MKKQeRAk=; b=DXA4V7DMGQ10fHhLPMixNUNZu3I0ccsSx60iAznN9z+GEza3/yd8KrWSv2N/hCzCFn SL2YXvmjpvycGu6ApCvwRPE+NLFmXnuzXXiaHMumYvxBEIeOTvxv+722+aJUXXpHr2sy r93btDwtLAmHzkG0HCIbeFszvxeKc3Ebgs78YbCcI2C0+lePlgtMcBVJZY5bFo/9J8GX 1BlZsiv0+W/svevcqrEwsK9rKB6kgA/Af/rtJ6gh0WP9SC29fUdg5WARH3cPL84dR1UP XYdbbVemHN2i+Gf/R17i0TOqVxEq9WMykJMArUAcyc3UeT9yU6BgQFREW5CANd/Kl91F vEkg== 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:content-transfer-encoding; bh=tIX8pqpkkMCoP/wxgTHxHVq8lm0eHUn7gy/MKKQeRAk=; b=Ax6KLagfztx1Bl4GztQxLPjENkVfWpovs8tWF7UvwfMMzuhxtqAsfjnyX716DM3uD7 Nw4hRG8SUezycOwjrxXKTPW4YC1ykmt1qGplRXWil7mdcVXNng6R+42rDJLu5K4eH1jv 2TZPev8omRXx1YUhAe/mFykj5aTknLeqhJ9XeeLPmq+HoXpTEKHEU2qkYR8nzGKDIQ4c f6S0c9o/McaN4dyFBE7qk6VTWQSRH+9CnbRbmS5UwEOQFxrq/clMuW2+S8WInjuDouQk dPLO+SgwRKXMsZ9DcoVR9IyRv5gXfJlzEfwyOctW8riXFDoeBy9m1A6cs6tA54lx9tZr 34Tg== X-Gm-Message-State: AE9vXwP2/AK1n5szYyWFvG2EmET7n5nmpOk435ljrvmsO+gPAEogxexFmmqGy8p04i9vWgXy4lxkDcD6drk+pg== X-Received: by 10.31.73.130 with SMTP id w124mr12053303vka.156.1473042076475; Sun, 04 Sep 2016 19:21:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.40.226 with HTTP; Sun, 4 Sep 2016 19:21:15 -0700 (PDT) In-Reply-To: <0a1801d2062e$6604d260$320e7720$@augustcellars.com> References: <0a1801d2062e$6604d260$320e7720$@augustcellars.com> From: Kathleen Moriarty Date: Sun, 4 Sep 2016 22:21:15 -0400 Message-ID: To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] AD review of draft-ietf-cose-msg 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, 05 Sep 2016 02:21:19 -0000 Hi Jim, Thanks for the very quick response! Inline. On Sat, Sep 3, 2016 at 5:59 PM, Jim Schaad wrote: > > >> -----Original Message----- >> From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Kathleen Moriarty >> Sent: Friday, September 02, 2016 7:58 PM >> To: cose@ietf.org >> Subject: [COSE] AD review of draft-ietf-cose-msg >> >> Hello, >> >> Thank you all for your work on draft-ietf-cose-msg. I mainly have nits = to fix in >> my comments, which is bound to happen with such a long draft. Sorry for= the >> time it took to turn this review around. >> >> I haven't looked at the shepherd report yet, but it will need to include= any >> remaining downrefs - assuming some of the idnits for this can be cleaned= up. >> The idnits need to be checked as well as there are some formatting probl= ems >> that can easily be corrected. > > The formatting issues are going to need to be fixed either by the RFC Edi= tor or by a new fix to xml2rfc. It has to do with the fact that I do a han= ging text list for a sentence rather than for a key word followed by punctu= ation. > >> >> >> Nits: >> >> Abstract >> >> Change from: >> 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. >> To: >> Concise Binary Object Representation (CBOR) is a data format designed >> for small code size and small message size. There is a need for the >> ability to have basic security services defined for this data >> format. > > Done > >> >> Introduction: >> Change from: >> There has been an increased focus on the small, constrained devices >> that make up the Internet of Things (IoT). >> To: >> There has been an increased focus on small, constrained devices >> that make up the Internet of Things (IoT). > > Done > >> Change from: >> A need exists to provide message security >> services for IoT and using CBOR as the message encoding format makes >> sense. >> To: >> A need exists to provide message security >> services for IoT, using CBOR as the message encoding format makes >> sense. > > Done > >> >> Section 1.1 >> Change from: >> o Define a single top message structure so that encrypted, signed >> and MACed messages can easily identified and still have a >> consistent view. >> To: >> o Define a single top message structure so that encrypted, signed >> and MACed messages can easily be identified and still have a >> consistent view. > > Done > >> >> For the following, I am not sure I am parsing this correctly, can it be = rephrased: >> o Signed messages separate the concept of protected and unprotected >> parameters that are for the content and the signature. >> > > Does this work? > o Signed messages distinguish between the protected and unprotected pa= rameters that relate to the content from those that relate to the signature= . Yes, that reads better to me, thank you! > >> Section 3: >> In the 'protected' bucket definition: >> change from: >> Senders SHOULD encode an zero length map as a zero >> length string rather than as a zero length map (encoded as h'a0'). >> To: >> Senders SHOULD encode a zero length map as a zero >> length string rather than as a zero length map (encoded as h'a0'). >> s/an/a/ > > Done > >> >> Change from: >> After encoding the map the value is >> wrapped in the binary object. >> To: >> After encoding the map, the value is >> wrapped in the binary object. >> > > Done > > >> Section 4: Second sentence: >> >> Can this be reworded from: >> COSE_Sign allows >> for one or more signers to be applied to a single content. >> To: COSE_Sign allows >> for one or more signers to be applied to a single piece of content. >> >> It doesn't read well to me, but if that is a well understood way to phra= se this, let >> me know. > > How does this work? > COSE_Sign allows for one or more signatures to be applied to the same= content. Ah, that's better, thank you! > >> >> Section 4.1: Can the second "about" be changed to "for" or "describing"?= It took >> me a few times reading this to get it. >> current: >> There are provisions for parameters >> about the content and parameters about the signature to be carried >> along with the signature itself. > > Does this work? > Parameters related to the content and parameters related to the s= ignature are carried along with the signature itself. Thank you, that helps me. > >> >> Section 4.1 middle of second paragraph: >> Change from: >> Support of different communities of >> recipients is the primary reason that signers choose to include more >> than one signature. >> To: >> Support for different communities of >> recipients is the primary reason that signers choose to include more >> than one signature. > > Done > >> >> Section 5.4, second bullet #3 >> Is this intended to be "Direct and Direct"? >> Direct and Direct Key Agreement: The key is determined by the >> key and algorithm in the recipient structure. =E2=80=A6 >> > > If I use the section titles it becomes: > Direct Encryption and Direct Key Agreement: ... > I think this might be better - what do you think? Yes, please do expand that, thank you! That makes sense now. :-) > >> Section 6.4: >> Change from: >> How to verify a MAC are: >> To: >> The steps of how to verify a MAC are: >> >> You don't save a line of text, so it would be better to include what is = needed for >> it to be easily understood. > > Done > >> >> Section 9, first paragraph: >> Remove the parens and s/One/A MAC/ >> Change from: >> (One cannot, for example, be used to prove the identity >> of the sender to a third party.) >> To: A MAC cannot, for example, be used to prove the identity >> of the sender to a third party. > > Done > >> >> *Many of the places where parenthesis are used, it would be better to re= move >> them and leave the sentence as part of the paragraph. > > I have included a note to the RFC editor to look at this as an issue. I = think that they should stay as that is the way that I thought it should be = at the time. OK, fair enough. That's a good way to figure out the best solution. Thanks= . > >> >> Section 9.1.1: second sentence should be more clear that the "method is = an >> attack method. How about change from: >> The current best method appears to be a >> brute force attack on the key. >> To: >> The current best attack method appears to be >> brute force on the key. > > Changed to > The current best attack appears to be brute force on the key. Better, thanks! > >> >> Section 9.2.1, first bullet, second sentence: >> Remove the last comma. >> change from: >> If this is not the case, an attacker will be able to >> generate a message with a valid tag given two message, tag pairs. >> To: >> If this is not the case, an attacker will be able to >> generate a message with a valid tag given two message tag pairs. > > Changed to > given to message and tag pairs Ah, ok, thanks. At least there was something to fix there ;-) > >> >> Same section, the second bullet doesn't read well. The current text: >> o If the same key is used for both encryption and authentication >> operations, using CBC modes an attacker can produce messages with >> a valid authentication code. >> How about: >> o When using CBC mode, if the same key is used for both encryption a= nd >> authentication >> operations, an attacker can produce messages with >> a valid authentication code. > > Done > >> >> Section 10.2, 4th paragraph, second to last sentence: >> Change from (s/user/use/): >> Less constrained devices will want to be able to user >> larger messages and are more willing to generate new keys for every >> operation. This favors larger values of L and M. >> To: >> Less constrained devices will want to be able to use >> larger messages and are more willing to generate new keys for every >> operation. This favors larger values of L and M. > > Done > >> >> Same section, third to last bullet, add "is": >> Change from: >> o If the 'alg' field present, it MUST match the AES-CCM algorithm >> being used. >> To: >> o If the 'alg' field is present, it MUST match the AES-CCM algorithm >> being used. > > Done, along with the rest of the cut and pastes from here. Cool, thanks. > >> >> Section 12.1.2.1 >> >> Is PFS spelled out in the draft before this use? Just checking=E2=80=A6= It might not be as >> it appears as "perfect forward secrecy (no >> abbreviation) and RFC4949 in section 12.4 > > Does not appear to be - It is now expanded Great, thanks! Easy to miss this in a big document when text gets moved ar= ound. > >> >> Section 15, second paragraph: >> >> It reads oddly to me=E2=80=A6 >> Applications are therefore intended to profile the usage of this >> document. This section provides a set of guidelines and topics that >> applications need to consider when using this document. >> >> What do you mean by 'profile the usage'? Should this be worded differen= tly? > > Does this make more sense? > > It is intended that a profile of this document be created that de= fines the interopability requirements for that specific application. > This section provides a set of guidelines and topics that need to= be considered when profiling this document. > Much better, thank you!! > >> >> Section 16.2 >> >> I think it's a little confusing to state the registry values require exp= ert review, >> then buried in the 'label' description say it can be specification requi= red. >> Wouldn't it be more clear to state that a dependency exists and a specif= ication is >> required in the intro paragraph for this section? This applies to the o= ther >> sections that also require a specification as it don't seem that all reg= istries do. >> >> Section 16.7 >> >> There is a spurious > character >> It is requested that IANA create a new registry "COSE Key Type >> Registry"> The > > Typo should have been a period. > Done Thanks! > >> >> Section 16.11, third bullet: Can you rephrase the following sentence, i= t could >> read better: >> Some >> of the ranges are restricted in range, items that are not expected >> to be common or are not expected to be used in constrained >> environments should be assigned to values which will encode to >> longer byte strings. > > Does this work any better? > > The length of the encoded value should be weighed against h= ow many code points of that length are left, the capabilities of devices fo= r expected use, and the number of code points left that encode to that size= . Yes, thank you! > >> >> Section 17. >> >> I don't see theft that says this section should be removed upon >> publication. Is it supposed to be retained in the document? Just >> checking as I thought the boiler plate for this has them being removed. > > Currently it is just as a comment in the XML to the RFC Editor rather tha= n as explicit text in the document. I think this meets the spirit of the r= equest in RFC 7942. Ah, ok, so it is meant to be removed. This may come up in the IESG reviews. If it does either one of us can respond quickly. Good to know the intent. I'd be fine with whatever the WG wanted, but need to know what that is, which is why I asked. It helps to have this knowledge ahead of time. > >> >> Section 18: This bullet is difficult to read, is it missing an "or"?: >> o Use of 'direct' as a recipient algorithm combined with a second >> recipient algorithm, either directly in a separate message, >> exposes the direct key to the second recipient. >> How about: >> o Use of 'direct' as a recipient algorithm combined with a second >> recipient algorithm, either directly or in a separate message, >> exposes the direct key to the second recipient. > > I have just removed the secondary clause entirely. I don't think it help= s anything anymore. OK, thanks. Thank you! I see you have a separate response for the IANA question. I'll try to get back to you tomorrow or Tuesday on that as it is getting late. Have a nice weekend and thanks again for all your work on this. Kathleen > >> >> >> >> Thank you! It's nice to see this get wrapped up in a timely manner. > > Jim > >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose > --=20 Best regards, Kathleen From nobody Tue Sep 6 11:00:47 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 F374812B29C for ; Tue, 6 Sep 2016 11:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 60rJGooUq6_7 for ; Tue, 6 Sep 2016 11:00:44 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (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 4079C12B312 for ; Tue, 6 Sep 2016 11:00:42 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id 49so72436421uat.3 for ; Tue, 06 Sep 2016 11:00:42 -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=6manh2PubDYUgg7vwexZElxtbTWOuK428iPvp1SVqjg=; b=phSu/RyTmiA3Octbb1iy1om6AQ/fZmbYUUQxJRzy+Q9hAKepWA68Wu3YpvCNHQL8aZ b0Uijd9oWme65KVYaRFrfXRE49kpcFYk4sWOFVQha5WgFQEBaoKyjBtaOwBBAXBCsH60 CMg5wHOY8BLOG6N2Y35Od7yeGGzU1hck2q8BMXdgDNxlTKoHsDXCjA9kfHIvEDFoguZu P4ezYt+YGs89ubUoYWWaLNDPLLiaXiXG7QKx0Yv/CyzSA5z+rtt1UVDa5RzQWM8ghQBp 6uj+OazK4AJGRvYX41XmsXIbBh3bbGcGLL2qCaHRKSMl6bKBM2nt6h9CHTHXPVHWLuna n8yQ== 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=6manh2PubDYUgg7vwexZElxtbTWOuK428iPvp1SVqjg=; b=P1v0WOepF/r1wdrlFzd2XHAoLqmbt7bw7dbQHDd2MGRRWEg1zVB3x4sGpqXsfIc4K+ KNJ6lZl7jn42lmdW6dFYxv3x0rz70jTomSb7emJZP1u5vLuu4fR9FwwXYGNjI8zwMdUy HRH4/bQzif7FDMSBjLS/fbrKD/1DUWspTM0oACNUTXIjStUBPyQFWL9CZofwFoXJmF0N Q8nByrMKovuGR0oTZlecM2SLmzr2ZHwXD8LEISeGZVhWg31sUvOuUOhErrrsmNfzizeK be7q5wDOM88Of78duUA3ZlBKjfk+1T5TuNC9a5jwPsHUxAoQlxcf5RONJP735HM4vTu4 yg+Q== X-Gm-Message-State: AE9vXwPAPQ4SzBxgq1wkYqup+eCIvrRsI54wqQh2gNkON444G3c5E5NqnW7xqHLy0jxlgMTSSn5HESlIRcFO7Q== X-Received: by 10.176.81.196 with SMTP id h4mr25465735uaa.95.1473184841130; Tue, 06 Sep 2016 11:00:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.40.226 with HTTP; Tue, 6 Sep 2016 11:00:40 -0700 (PDT) In-Reply-To: <0a2101d20636$bc946c50$35bd44f0$@augustcellars.com> References: <0a2101d20636$bc946c50$35bd44f0$@augustcellars.com> From: Kathleen Moriarty Date: Tue, 6 Sep 2016 14:00:40 -0400 Message-ID: To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] AD review of draft-ietf-cose-msg 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, 06 Sep 2016 18:00:46 -0000 On Sat, Sep 3, 2016 at 6:58 PM, Jim Schaad wrote: >> Section 16.2 >> >> I think it's a little confusing to state the registry values require expert review, >> then buried in the 'label' description say it can be specification required. >> Wouldn't it be more clear to state that a dependency exists and a specification is >> required in the intro paragraph for this section? This applies to the other >> sections that also require a specification as it don't seem that all registries do. >> > > I separated this issue because I think it is potentially going to need more discussion than any of the other issues. Good, thanks. > > From the IANA point of view, I want to keep these registry rules simple. That is, I want IANA to treat the registries as if everything is expert review. > > Given that I want to break down the label ranges. Would it makes sense to move this language from here to section 16.11 so that it is clear that this will be for the expert reviewers to look at rather than for IANA to look at? Well, this just applies to section 16.2, right? If so, then I think the intro to just the subsection that requires a specification should also include that information. If it's buried within the subsection, I think it gets lost for the draft review process. It might work out fine when it's used to add to the registry, but it should be as clear as possible. If it were just in 16.11, I think that would be confusing since it doesn't apply to all the registries established by this draft. ANother sentence or two in the introduction should be all this requires to make it more clear. WHat do you think? Thanks, Kathleen > > Jim > > -- Best regards, Kathleen From nobody Tue Sep 6 11:40:18 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 4F6F212B27A for ; Tue, 6 Sep 2016 11:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, 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 vs0KxkHMHTSn for ; Tue, 6 Sep 2016 11:40:05 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D6A212B302 for ; Tue, 6 Sep 2016 11:40:05 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 6 Sep 2016 11:53:22 -0700 From: Jim Schaad To: 'Kathleen Moriarty' References: <0a2101d20636$bc946c50$35bd44f0$@augustcellars.com> In-Reply-To: Date: Tue, 6 Sep 2016 11:39:56 -0700 Message-ID: <0ce101d2086e$125c9d90$3715d8b0$@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: AQDp94lwGHQJUgjVV1PYuK1ecb6CGwIQcMrOAdKRxnuiHdQX8A== Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] AD review of draft-ietf-cose-msg 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, 06 Sep 2016 18:40:16 -0000 > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Kathleen Moriarty > Sent: Tuesday, September 06, 2016 11:01 AM > To: Jim Schaad > Cc: cose@ietf.org > Subject: Re: [COSE] AD review of draft-ietf-cose-msg > > On Sat, Sep 3, 2016 at 6:58 PM, Jim Schaad wrote: > >> Section 16.2 > >> > >> I think it's a little confusing to state the registry values require > >> expert review, then buried in the 'label' description say it can be specification > required. > >> Wouldn't it be more clear to state that a dependency exists and a > >> specification is required in the intro paragraph for this section? > >> This applies to the other sections that also require a specification as it don't > seem that all registries do. > >> > > > > I separated this issue because I think it is potentially going to need more > discussion than any of the other issues. > > Good, thanks. > > > > > From the IANA point of view, I want to keep these registry rules simple. That > is, I want IANA to treat the registries as if everything is expert review. > > > > Given that I want to break down the label ranges. Would it makes sense to > move this language from here to section 16.11 so that it is clear that this will be > for the expert reviewers to look at rather than for IANA to look at? > > Well, this just applies to section 16.2, right? If so, then I think the intro to just > the subsection that requires a specification should also include that information. > If it's buried within the subsection, I think it gets lost for the draft review > process. It might work out fine when it's used to add to the registry, but it > should be as clear as possible. If it were just in 16.11, I think that would be > confusing since it doesn't apply to all the registries established by this draft. > ANother sentence or two in the introduction should be all this requires to make > it more clear. WHat do you think? No, this issue applies to section 16.2 (Header parameters), 16.4 (Algorithms), 16.5 (Key Common Parameters) and 16.8 (Elliptic Curve Parameters). Since it is for more than just one section I think it could merit its own bullet point in 16.11 and that would be reasonable. Some additional text would also work as well, but it is not a one place fix. Jim > > > Thanks, > Kathleen > > > > > Jim > > > > > > > > -- > > Best regards, > Kathleen > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Tue Sep 6 12:22: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 34DF212B30F for ; Tue, 6 Sep 2016 12:22:23 -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, FREEMAIL_FROM=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 PVi2EHX0j0AV for ; Tue, 6 Sep 2016 12:22:21 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60C5E12B284 for ; Tue, 6 Sep 2016 12:22:21 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id j189so99874055vkc.2 for ; Tue, 06 Sep 2016 12:22:21 -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=dAHuaR8ERIbECux512gJ9lfQFxPTmL2pzYDxOmCaogo=; b=Q6Ge4IM4p5Msj0JzUuEA5OhLQoR1zyUcuQpNhYp8hsOAXeT5YGzy1Bs4PzbfpYPvht N9TqouaJ1PBFuzLIN4kZPcURcnXMaJsR6HGXXj5fR9aZbh+yFsIGeqm2//CmRQgFB1jh Jw8G/uyzTTr0kvHpxUEZidhY1kI4orhoY5G1stwR94GGCNDRIP3jwEHzTTCasBKiVvrv NS/KWxnzb360wdOlOMp/lP0uHMIHSwfAmBGJmJ2fzx0uZhnvC+d0xCP95+KW3QrZH0KC mbImPJKP2nvyjtQ2gRzdh/uBbpIzPn9L33jO5qhll/hvbIbm3laje84/TcEawRMmX8O+ XhuQ== 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=dAHuaR8ERIbECux512gJ9lfQFxPTmL2pzYDxOmCaogo=; b=Za8w31AvR8I8TMqaYJOoDzZ5OVAJE20VLUtGRJ3EfoikiguxocjEWZ4JIiVnElp6q5 Sb8X+xpcnWLmsKMJH4JzAErp1AYUR2SYr+AlxrW80RGZ5nGdJl+DwKucvH5Tfur72j5X dNQgvED4qkMScdIpMyQdXYDUllT3T0eW9/HPaXiwY0ALuYHSupZr4UarDzWgeTlwxfNC dzpDNLqms5ePPNqvHN9OmdvLcBkprVvd0ozjh3NDR4Ok796WEmfUHXQ/XFGdj6WK38JZ VGeGrVnYAa5p4V2o5bpc26FDrGVK3fB3B0baceFCH6vhmCPKv9vONWOf+L25eT/6tZen a+PQ== X-Gm-Message-State: AE9vXwPAe8gFzX27N4roga1U0/8ZD2B0J0HjEBuOVW73xPvx7bzX7FarikAaW+k1/mXyo/RpveKtBgLpssYxAg== X-Received: by 10.31.73.130 with SMTP id w124mr17769358vka.156.1473189740441; Tue, 06 Sep 2016 12:22:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.40.226 with HTTP; Tue, 6 Sep 2016 12:22:19 -0700 (PDT) In-Reply-To: <0ce101d2086e$125c9d90$3715d8b0$@augustcellars.com> References: <0a2101d20636$bc946c50$35bd44f0$@augustcellars.com> <0ce101d2086e$125c9d90$3715d8b0$@augustcellars.com> From: Kathleen Moriarty Date: Tue, 6 Sep 2016 15:22:19 -0400 Message-ID: To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] AD review of draft-ietf-cose-msg 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, 06 Sep 2016 19:22:23 -0000 On Tue, Sep 6, 2016 at 2:39 PM, Jim Schaad wrote: > > >> -----Original Message----- >> From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Kathleen Moriarty >> Sent: Tuesday, September 06, 2016 11:01 AM >> To: Jim Schaad >> Cc: cose@ietf.org >> Subject: Re: [COSE] AD review of draft-ietf-cose-msg >> >> On Sat, Sep 3, 2016 at 6:58 PM, Jim Schaad wrote: >> >> Section 16.2 >> >> >> >> I think it's a little confusing to state the registry values require >> >> expert review, then buried in the 'label' description say it can be > specification >> required. >> >> Wouldn't it be more clear to state that a dependency exists and a >> >> specification is required in the intro paragraph for this section? >> >> This applies to the other sections that also require a specification as > it don't >> seem that all registries do. >> >> >> > >> > I separated this issue because I think it is potentially going to need > more >> discussion than any of the other issues. >> >> Good, thanks. >> >> > >> > From the IANA point of view, I want to keep these registry rules simple. > That >> is, I want IANA to treat the registries as if everything is expert review. >> > >> > Given that I want to break down the label ranges. Would it makes sense > to >> move this language from here to section 16.11 so that it is clear that > this will be >> for the expert reviewers to look at rather than for IANA to look at? >> >> Well, this just applies to section 16.2, right? If so, then I think the > intro to just >> the subsection that requires a specification should also include that > information. >> If it's buried within the subsection, I think it gets lost for the draft > review >> process. It might work out fine when it's used to add to the registry, > but it >> should be as clear as possible. If it were just in 16.11, I think that > would be >> confusing since it doesn't apply to all the registries established by this > draft. >> ANother sentence or two in the introduction should be all this requires to > make >> it more clear. WHat do you think? > > No, this issue applies to section 16.2 (Header parameters), 16.4 > (Algorithms), 16.5 (Key Common Parameters) and 16.8 (Elliptic Curve > Parameters). Oh, that's right... Since it is for more than just one section I think it could > merit its own bullet point in 16.11 and that would be reasonable. > > Some additional text would also work as well, but it is not a one place fix. I think it will be more clear in each section since you can do it with just a sentence in the intro. It should help avoid problems later since each section adds to a registry or creates one. Thanks, Kathleen > > Jim > >> >> >> Thanks, >> Kathleen >> >> > >> > Jim >> > >> > >> >> >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose > -- Best regards, Kathleen From nobody Tue Sep 6 15:10:13 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 2470E12B095 for ; Tue, 6 Sep 2016 15:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, 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 Nhv9qyRJ0M_b for ; Tue, 6 Sep 2016 15:10:09 -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 4928712B0D7 for ; Tue, 6 Sep 2016 15:10:09 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 6 Sep 2016 15:23:27 -0700 From: Jim Schaad To: 'Kathleen Moriarty' References: <0a2101d20636$bc946c50$35bd44f0$@augustcellars.com> <0ce101d2086e$125c9d90$3715d8b0$@augustcellars.com> In-Reply-To: Date: Tue, 6 Sep 2016 15:10:00 -0700 Message-ID: <0d2501d2088b$6af36ca0$40da45e0$@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: AQDp94lwGHQJUgjVV1PYuK1ecb6CGwIQcMrOAdKRxnsCxFEWuwHINRiZofmqfDA= Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] AD review of draft-ietf-cose-msg 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, 06 Sep 2016 22:10:12 -0000 So something along the lines of this? The registry is to be created as Expert Review Required. There are additional restrictions for sub-ranges of values. Expert review guidelines are provided in Section 16.11. Jim > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Kathleen Moriarty > Sent: Tuesday, September 06, 2016 12:22 PM > To: Jim Schaad > Cc: cose@ietf.org > Subject: Re: [COSE] AD review of draft-ietf-cose-msg > > On Tue, Sep 6, 2016 at 2:39 PM, Jim Schaad wrote: > > > > > >> -----Original Message----- > >> From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Kathleen > >> Moriarty > >> Sent: Tuesday, September 06, 2016 11:01 AM > >> To: Jim Schaad > >> Cc: cose@ietf.org > >> Subject: Re: [COSE] AD review of draft-ietf-cose-msg > >> > >> On Sat, Sep 3, 2016 at 6:58 PM, Jim Schaad wrote: > >> >> Section 16.2 > >> >> > >> >> I think it's a little confusing to state the registry values > >> >> require expert review, then buried in the 'label' description say > >> >> it can be > > specification > >> required. > >> >> Wouldn't it be more clear to state that a dependency exists and a > >> >> specification is required in the intro paragraph for this section? > >> >> This applies to the other sections that also require a > >> >> specification as > > it don't > >> seem that all registries do. > >> >> > >> > > >> > I separated this issue because I think it is potentially going to > >> > need > > more > >> discussion than any of the other issues. > >> > >> Good, thanks. > >> > >> > > >> > From the IANA point of view, I want to keep these registry rules simple. > > That > >> is, I want IANA to treat the registries as if everything is expert review. > >> > > >> > Given that I want to break down the label ranges. Would it makes > >> > sense > > to > >> move this language from here to section 16.11 so that it is clear > >> that > > this will be > >> for the expert reviewers to look at rather than for IANA to look at? > >> > >> Well, this just applies to section 16.2, right? If so, then I think > >> the > > intro to just > >> the subsection that requires a specification should also include that > > information. > >> If it's buried within the subsection, I think it gets lost for the > >> draft > > review > >> process. It might work out fine when it's used to add to the > >> registry, > > but it > >> should be as clear as possible. If it were just in 16.11, I think > >> that > > would be > >> confusing since it doesn't apply to all the registries established by > >> this > > draft. > >> ANother sentence or two in the introduction should be all this > >> requires to > > make > >> it more clear. WHat do you think? > > > > No, this issue applies to section 16.2 (Header parameters), 16.4 > > (Algorithms), 16.5 (Key Common Parameters) and 16.8 (Elliptic Curve > > Parameters). > > Oh, that's right... > > Since it is for more than just one section I think it could > > merit its own bullet point in 16.11 and that would be reasonable. > > > > Some additional text would also work as well, but it is not a one place fix. > > I think it will be more clear in each section since you can do it with just a > sentence in the intro. It should help avoid problems later since each section > adds to a registry or creates one. > > Thanks, > Kathleen > > > > > > Jim > > > >> > >> > >> Thanks, > >> Kathleen > >> > >> > > >> > Jim > >> > > >> > > >> > >> > >> > >> -- > >> > >> Best regards, > >> Kathleen > >> > >> _______________________________________________ > >> COSE mailing list > >> COSE@ietf.org > >> https://www.ietf.org/mailman/listinfo/cose > > > > > > -- > > Best regards, > Kathleen > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Fri Sep 9 19:12:05 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 3635312B2D1 for ; Fri, 9 Sep 2016 19:12:03 -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, FREEMAIL_FROM=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 XcD_ZfDqp7Df for ; Fri, 9 Sep 2016 19:12:01 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 7C9D412B2CF for ; Fri, 9 Sep 2016 19:12:01 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id h8so7889482qka.1 for ; Fri, 09 Sep 2016 19:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=N4qUjRv6BxhAKpq/hSorZndHHwGBlBXssk+FDgX2EsQ=; b=LdbhqVg4WfnQAhoIyuRAoHcvTzMg7GWeIO0gdNyO2wTSgyp0hYyvD2Th7307a8p0t8 dklztSuXAux8x6sTbkH4fLtYG+pn8KpczB+GWVa6TlW4AAkIkjxuV0m7zkpOl+aAXita tKu7Bje+qxatK2FbuQAt44rTQ9xiVuvOo9fLNNre1Q697c3NREoF/0oHPfjSp95eo8oU SQ+cuoHtiASuovJPHVwKVtt43mTu5qy3azkTrdf6ujBJHMyAJeXFIbp3oDnYF4vXi0f4 ebesRJ3sDx8J6PTX66eeVG97uRv1t0e/0FqxH+HDCEHT3E9ytH9WZT51na1aQEyQM+Ox fiVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=N4qUjRv6BxhAKpq/hSorZndHHwGBlBXssk+FDgX2EsQ=; b=FR7e25s/FVuBci4mQIc82DxBfaZedkvEam8geujtqmFZc7rSP8ZDG+wkGq9R/Qr2Rm jH7LSdK+9Xy1Rf3h38nZqECRntqZlPgXOgHd2Dco9lqmtBGPa+/B+MIE1TXap06NoZfF PMBoRGtRStF+phb7Vuuu1bbthQ2t/LUlhjRUC/nDXtKZl3y2NynA666KO4IVCjhuV1ZL G+YjPpkAgi37mXrm43J/ryfbbEc3LSA4EUPrDKDVX8y8OPMPVItWBLhfouu7qlZs6ae6 RJkfvun+ESk+ITDvmk5mmyxnGDr9Ynt1XhZVogAUOJgdgwn5pVinyOdM21GMQfQ7Hjc2 Gq7g== X-Gm-Message-State: AE9vXwP+ZBd+XtZPXaY8XjaeMFiSQupmyz/IszD+AjAHhSJQAEmLlMuLaunvwjRtE+kVvQ== X-Received: by 10.55.46.195 with SMTP id u186mr8009120qkh.189.1473473520634; Fri, 09 Sep 2016 19:12:00 -0700 (PDT) Received: from [192.168.1.3] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id g22sm3806046qta.1.2016.09.09.19.11.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 09 Sep 2016 19:12:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (13G36) In-Reply-To: <0d2501d2088b$6af36ca0$40da45e0$@augustcellars.com> Date: Fri, 9 Sep 2016 22:11:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5D8F9919-B95D-4CAD-929D-CB513EEFBCDC@gmail.com> References: <0a2101d20636$bc946c50$35bd44f0$@augustcellars.com> <0ce101d2086e$125c9d90$3715d8b0$@augustcellars.com> <0d2501d2088b$6af36ca0$40da45e0$@augustcellars.com> To: Jim Schaad Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] AD review of draft-ietf-cose-msg 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, 10 Sep 2016 02:12:03 -0000 Sorry I didn't see this message, not sure why. Hmmm, how about for the sections that have the need for a specification, you= add in something like: Please excuse typos, sent from handheld device=20 > On Sep 6, 2016, at 6:10 PM, Jim Schaad wrote: >=20 > So something along the lines of this? >=20 > The registry is to be created as Expert Review Required. There are > additional requirements for sub-ranges of values, > where a specification may also be necessary. Expert review guidelines > are provided in Section 16.11. Thanks, Kathleen=20 >=20 > Jim >=20 >=20 >=20 >> -----Original Message----- >> From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Kathleen Moriarty >> Sent: Tuesday, September 06, 2016 12:22 PM >> To: Jim Schaad >> Cc: cose@ietf.org >> Subject: Re: [COSE] AD review of draft-ietf-cose-msg >>=20 >>> On Tue, Sep 6, 2016 at 2:39 PM, Jim Schaad wrot= e: >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Kathleen >>>> Moriarty >>>> Sent: Tuesday, September 06, 2016 11:01 AM >>>> To: Jim Schaad >>>> Cc: cose@ietf.org >>>> Subject: Re: [COSE] AD review of draft-ietf-cose-msg >>>>=20 >>>> On Sat, Sep 3, 2016 at 6:58 PM, Jim Schaad > wrote: >>>>>> Section 16.2 >>>>>>=20 >>>>>> I think it's a little confusing to state the registry values >>>>>> require expert review, then buried in the 'label' description say >>>>>> it can be >>> specification >>>> required. >>>>>> Wouldn't it be more clear to state that a dependency exists and a >>>>>> specification is required in the intro paragraph for this section? >>>>>> This applies to the other sections that also require a >>>>>> specification as >>> it don't >>>> seem that all registries do. >>>>>=20 >>>>> I separated this issue because I think it is potentially going to >>>>> need >>> more >>>> discussion than any of the other issues. >>>>=20 >>>> Good, thanks. >>>>=20 >>>>>=20 >>>>> =46rom the IANA point of view, I want to keep these registry rules > simple. >>> That >>>> is, I want IANA to treat the registries as if everything is expert > review. >>>>>=20 >>>>> Given that I want to break down the label ranges. Would it makes >>>>> sense >>> to >>>> move this language from here to section 16.11 so that it is clear >>>> that >>> this will be >>>> for the expert reviewers to look at rather than for IANA to look at? >>>>=20 >>>> Well, this just applies to section 16.2, right? If so, then I think >>>> the >>> intro to just >>>> the subsection that requires a specification should also include that >>> information. >>>> If it's buried within the subsection, I think it gets lost for the >>>> draft >>> review >>>> process. It might work out fine when it's used to add to the >>>> registry, >>> but it >>>> should be as clear as possible. If it were just in 16.11, I think >>>> that >>> would be >>>> confusing since it doesn't apply to all the registries established by >>>> this >>> draft. >>>> ANother sentence or two in the introduction should be all this >>>> requires to >>> make >>>> it more clear. WHat do you think? >>>=20 >>> No, this issue applies to section 16.2 (Header parameters), 16.4 >>> (Algorithms), 16.5 (Key Common Parameters) and 16.8 (Elliptic Curve >>> Parameters). >>=20 >> Oh, that's right... >>=20 >> Since it is for more than just one section I think it could >>> merit its own bullet point in 16.11 and that would be reasonable. >>>=20 >>> Some additional text would also work as well, but it is not a one place > fix. >>=20 >> I think it will be more clear in each section since you can do it with > just a >> sentence in the intro. It should help avoid problems later since each > section >> adds to a registry or creates one. >>=20 >> Thanks, >> Kathleen >>=20 >>=20 >>>=20 >>> Jim >>>=20 >>>>=20 >>>>=20 >>>> Thanks, >>>> Kathleen >>>>=20 >>>>>=20 >>>>> Jim >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>>=20 >>>> Best regards, >>>> Kathleen >>>>=20 >>>> _______________________________________________ >>>> COSE mailing list >>>> COSE@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cose >>=20 >>=20 >>=20 >> -- >>=20 >> Best regards, >> Kathleen >>=20 >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose >=20 From nobody Sat Sep 10 14:30:44 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 53879128B38 for ; Sat, 10 Sep 2016 14:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, 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 4kiHXJhwv9Fp for ; Sat, 10 Sep 2016 14:30:41 -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 00BF312B164 for ; Sat, 10 Sep 2016 14:30:40 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 10 Sep 2016 14:43:37 -0700 From: Jim Schaad To: References: <0a2101d20636$bc946c50$35bd44f0$@augustcellars.com> <0ce101d2086e$125c9d90$3715d8b0$@augustcellars.com> <0d2501d2088b$6af36ca0$40da45e0$@augustcellars.com> <5D8F9919-B95D-4CAD-929D-CB513EEFBCDC@gmail.com> In-Reply-To: <5D8F9919-B95D-4CAD-929D-CB513EEFBCDC@gmail.com> Date: Sat, 10 Sep 2016 14:30:09 -0700 Message-ID: <002301d20baa$8355cd70$8a016850$@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: AQDp94lwGHQJUgjVV1PYuK1ecb6CGwIQcMrOAdKRxnsCxFEWuwHINRiZAOcIpbYBR0JjpaHudlGw Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] AD review of draft-ietf-cose-msg 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, 10 Sep 2016 21:30:43 -0000 OK, I am going to suggest that the paragraph should read as follows: It is requested that IANA create a new registry entitled "COSE Header Parameters". The registry should be created as Expert Review Required. Guidelines for the experts is provided in Section 16.11. It should be noted that in additional to the expert review, some portions of the registry require a specification, potentially on standards track, be supplied as well. Jim > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of > kathleen.moriarty.ietf@gmail.com > Sent: Friday, September 09, 2016 7:12 PM > To: Jim Schaad > Cc: cose@ietf.org > Subject: Re: [COSE] AD review of draft-ietf-cose-msg > > Sorry I didn't see this message, not sure why. > > Hmmm, how about for the sections that have the need for a specification, you > add in something like: > > Please excuse typos, sent from handheld device > > > On Sep 6, 2016, at 6:10 PM, Jim Schaad wrote: > > > > So something along the lines of this? > > > > The registry is to be created as Expert Review Required. There are > > additional requirements for sub-ranges of values, > > > where a specification may also be necessary. Expert review guidelines > > are provided in Section 16.11. > > Thanks, > Kathleen > > > > Jim > > > > > > > >> -----Original Message----- > >> From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Kathleen > >> Moriarty > >> Sent: Tuesday, September 06, 2016 12:22 PM > >> To: Jim Schaad > >> Cc: cose@ietf.org > >> Subject: Re: [COSE] AD review of draft-ietf-cose-msg > >> > >>> On Tue, Sep 6, 2016 at 2:39 PM, Jim Schaad > wrote: > >>> > >>> > >>>> -----Original Message----- > >>>> From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Kathleen > >>>> Moriarty > >>>> Sent: Tuesday, September 06, 2016 11:01 AM > >>>> To: Jim Schaad > >>>> Cc: cose@ietf.org > >>>> Subject: Re: [COSE] AD review of draft-ietf-cose-msg > >>>> > >>>> On Sat, Sep 3, 2016 at 6:58 PM, Jim Schaad > > wrote: > >>>>>> Section 16.2 > >>>>>> > >>>>>> I think it's a little confusing to state the registry values > >>>>>> require expert review, then buried in the 'label' description say > >>>>>> it can be > >>> specification > >>>> required. > >>>>>> Wouldn't it be more clear to state that a dependency exists and a > >>>>>> specification is required in the intro paragraph for this section? > >>>>>> This applies to the other sections that also require a > >>>>>> specification as > >>> it don't > >>>> seem that all registries do. > >>>>> > >>>>> I separated this issue because I think it is potentially going to > >>>>> need > >>> more > >>>> discussion than any of the other issues. > >>>> > >>>> Good, thanks. > >>>> > >>>>> > >>>>> From the IANA point of view, I want to keep these registry rules > > simple. > >>> That > >>>> is, I want IANA to treat the registries as if everything is expert > > review. > >>>>> > >>>>> Given that I want to break down the label ranges. Would it makes > >>>>> sense > >>> to > >>>> move this language from here to section 16.11 so that it is clear > >>>> that > >>> this will be > >>>> for the expert reviewers to look at rather than for IANA to look at? > >>>> > >>>> Well, this just applies to section 16.2, right? If so, then I > >>>> think the > >>> intro to just > >>>> the subsection that requires a specification should also include > >>>> that > >>> information. > >>>> If it's buried within the subsection, I think it gets lost for the > >>>> draft > >>> review > >>>> process. It might work out fine when it's used to add to the > >>>> registry, > >>> but it > >>>> should be as clear as possible. If it were just in 16.11, I think > >>>> that > >>> would be > >>>> confusing since it doesn't apply to all the registries established > >>>> by this > >>> draft. > >>>> ANother sentence or two in the introduction should be all this > >>>> requires to > >>> make > >>>> it more clear. WHat do you think? > >>> > >>> No, this issue applies to section 16.2 (Header parameters), 16.4 > >>> (Algorithms), 16.5 (Key Common Parameters) and 16.8 (Elliptic Curve > >>> Parameters). > >> > >> Oh, that's right... > >> > >> Since it is for more than just one section I think it could > >>> merit its own bullet point in 16.11 and that would be reasonable. > >>> > >>> Some additional text would also work as well, but it is not a one > >>> place > > fix. > >> > >> I think it will be more clear in each section since you can do it > >> with > > just a > >> sentence in the intro. It should help avoid problems later since > >> each > > section > >> adds to a registry or creates one. > >> > >> Thanks, > >> Kathleen > >> > >> > >>> > >>> Jim > >>> > >>>> > >>>> > >>>> Thanks, > >>>> Kathleen > >>>> > >>>>> > >>>>> Jim > >>>> > >>>> > >>>> > >>>> -- > >>>> > >>>> Best regards, > >>>> Kathleen > >>>> > >>>> _______________________________________________ > >>>> COSE mailing list > >>>> COSE@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/cose > >> > >> > >> > >> -- > >> > >> Best regards, > >> Kathleen > >> > >> _______________________________________________ > >> COSE mailing list > >> COSE@ietf.org > >> https://www.ietf.org/mailman/listinfo/cose > > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Sat Sep 10 16:27:12 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 DC17912B19F for ; Sat, 10 Sep 2016 16:27:10 -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, FREEMAIL_FROM=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 BUqArVtMbi-U for ; Sat, 10 Sep 2016 16:27:09 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC88012B156 for ; Sat, 10 Sep 2016 16:27:08 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id t7so8843251qkh.2 for ; Sat, 10 Sep 2016 16:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=h4xhDkq4DUvO1QRJjyovYGNfAsf9AOAZTjGf2csOylQ=; b=rcB/icXCAeBiAWsrJ4TVr+QJ2o5w/nyKDCaeGUeXeOBy2eEk/BG4MgEY/Vx6cQplRu f3z8HaH9LduL24+3+9/dFMgn2I6tfweZoZVBHPkiDoezNPYwznTojVwJovpw+xMf2o4N q1sMlBE+aOf3OHpFSKq0G0KV00L4PvISjQ4NAPy8K83CP57LcI6EAYBXyq4Epbhtn489 njn1xMsr1cF6MD3ixo5wkDX5vc39b6JPVcCZbU0ZvIdqmtslGUH6/240Qk3I86wVSn3C ub4jedtv61lbFTTrenOztioIiU7l7UL5NgCKPfCoSFuuUq5e8lIbOoU7WwwE1OtlzSew liPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=h4xhDkq4DUvO1QRJjyovYGNfAsf9AOAZTjGf2csOylQ=; b=ivkl4AliwmKjwVq+ZwhkIdcmbi1H6j3aH8mNP95he10pzASYXCMCH+FLdEjuEVa8/A QjQvK4gse2ZB3J4UCMQF/vU489spme+ZIjBBy2fi7H0jprgw5MfU7solO06xMhBfc4ly BZl7/0WpG3BnNMqZq8RoudgDeMWEe03EV1vzElUozSd5TaF142V4UUz1kMPDXSqsXfkW S/7tf+FS2G0cWYmwBywhzFsEwykRKKGFEB22fx+o+BKoy9RijkeZDznJovRLBzza2U44 tdIjNLQoEh/mJuRBvQOnIis4oMA0Q0sYktrZMq8wBbst/VdIGMz93b4VCUikGAtkSw5u h/pg== X-Gm-Message-State: AE9vXwOv++N1CzmDto4Jr6Yy96T4WnUFZg2x0vtO6Cew4ei7YV6Psh33lkuxTK8dX9BWJg== X-Received: by 10.55.163.196 with SMTP id m187mr688969qke.40.1473550027941; Sat, 10 Sep 2016 16:27:07 -0700 (PDT) Received: from [192.168.1.3] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id q78sm4883032qki.15.2016.09.10.16.27.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 10 Sep 2016 16:27:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (13G36) In-Reply-To: <002301d20baa$8355cd70$8a016850$@augustcellars.com> Date: Sat, 10 Sep 2016 19:27:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0a2101d20636$bc946c50$35bd44f0$@augustcellars.com> <0ce101d2086e$125c9d90$3715d8b0$@augustcellars.com> <0d2501d2088b$6af36ca0$40da45e0$@augustcellars.com> <5D8F9919-B95D-4CAD-929D-CB513EEFBCDC@gmail.com> <002301d20baa$8355cd70$8a016850$@augustcellars.com> To: Jim Schaad Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] AD review of draft-ietf-cose-msg 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, 10 Sep 2016 23:27:11 -0000 Please excuse typos, sent from handheld device=20 > On Sep 10, 2016, at 5:30 PM, Jim Schaad wrote: >=20 > OK, >=20 > I am going to suggest that the paragraph should read as follows: >=20 > It is requested that IANA create a new registry entitled "COSE Header > Parameters". The registry should be created as Expert Review Required. > Guidelines for the experts is provided in Section 16.11. It should be not= ed > that in additional to the expert review, some portions of the registry > require a specification, potentially on standards track, be supplied as > well. >=20 Thanks, that wording is helpful as that wasn't entirely clear to me. Let me= know when it's ready. I still need to dig into the downrefs, but that won'= t take long. Thanks, Kathleen=20 >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of >> kathleen.moriarty.ietf@gmail.com >> Sent: Friday, September 09, 2016 7:12 PM >> To: Jim Schaad >> Cc: cose@ietf.org >> Subject: Re: [COSE] AD review of draft-ietf-cose-msg >>=20 >> Sorry I didn't see this message, not sure why. >>=20 >> Hmmm, how about for the sections that have the need for a specification, > you >> add in something like: >>=20 >> Please excuse typos, sent from handheld device >>=20 >>> On Sep 6, 2016, at 6:10 PM, Jim Schaad wrote: >>>=20 >>> So something along the lines of this? >>>=20 >>> The registry is to be created as Expert Review Required. There are >>> additional requirements for sub-ranges of values, >>=20 >>> where a specification may also be necessary. Expert review guidelines >>> are provided in Section 16.11. >>=20 >> Thanks, >> Kathleen >>>=20 >>> Jim >>>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Kathleen >>>> Moriarty >>>> Sent: Tuesday, September 06, 2016 12:22 PM >>>> To: Jim Schaad >>>> Cc: cose@ietf.org >>>> Subject: Re: [COSE] AD review of draft-ietf-cose-msg >>>>=20 >>>>> On Tue, Sep 6, 2016 at 2:39 PM, Jim Schaad >> wrote: >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Kathleen >>>>>> Moriarty >>>>>> Sent: Tuesday, September 06, 2016 11:01 AM >>>>>> To: Jim Schaad >>>>>> Cc: cose@ietf.org >>>>>> Subject: Re: [COSE] AD review of draft-ietf-cose-msg >>>>>>=20 >>>>>> On Sat, Sep 3, 2016 at 6:58 PM, Jim Schaad >>> wrote: >>>>>>>> Section 16.2 >>>>>>>>=20 >>>>>>>> I think it's a little confusing to state the registry values >>>>>>>> require expert review, then buried in the 'label' description say >>>>>>>> it can be >>>>> specification >>>>>> required. >>>>>>>> Wouldn't it be more clear to state that a dependency exists and a >>>>>>>> specification is required in the intro paragraph for this section? >>>>>>>> This applies to the other sections that also require a >>>>>>>> specification as >>>>> it don't >>>>>> seem that all registries do. >>>>>>>=20 >>>>>>> I separated this issue because I think it is potentially going to >>>>>>> need >>>>> more >>>>>> discussion than any of the other issues. >>>>>>=20 >>>>>> Good, thanks. >>>>>>=20 >>>>>>>=20 >>>>>>> =46rom the IANA point of view, I want to keep these registry rules >>> simple. >>>>> That >>>>>> is, I want IANA to treat the registries as if everything is expert >>> review. >>>>>>>=20 >>>>>>> Given that I want to break down the label ranges. Would it makes >>>>>>> sense >>>>> to >>>>>> move this language from here to section 16.11 so that it is clear >>>>>> that >>>>> this will be >>>>>> for the expert reviewers to look at rather than for IANA to look at? >>>>>>=20 >>>>>> Well, this just applies to section 16.2, right? If so, then I >>>>>> think the >>>>> intro to just >>>>>> the subsection that requires a specification should also include >>>>>> that >>>>> information. >>>>>> If it's buried within the subsection, I think it gets lost for the >>>>>> draft >>>>> review >>>>>> process. It might work out fine when it's used to add to the >>>>>> registry, >>>>> but it >>>>>> should be as clear as possible. If it were just in 16.11, I think >>>>>> that >>>>> would be >>>>>> confusing since it doesn't apply to all the registries established >>>>>> by this >>>>> draft. >>>>>> ANother sentence or two in the introduction should be all this >>>>>> requires to >>>>> make >>>>>> it more clear. WHat do you think? >>>>>=20 >>>>> No, this issue applies to section 16.2 (Header parameters), 16.4 >>>>> (Algorithms), 16.5 (Key Common Parameters) and 16.8 (Elliptic Curve >>>>> Parameters). >>>>=20 >>>> Oh, that's right... >>>>=20 >>>> Since it is for more than just one section I think it could >>>>> merit its own bullet point in 16.11 and that would be reasonable. >>>>>=20 >>>>> Some additional text would also work as well, but it is not a one >>>>> place >>> fix. >>>>=20 >>>> I think it will be more clear in each section since you can do it >>>> with >>> just a >>>> sentence in the intro. It should help avoid problems later since >>>> each >>> section >>>> adds to a registry or creates one. >>>>=20 >>>> Thanks, >>>> Kathleen >>>>=20 >>>>=20 >>>>>=20 >>>>> Jim >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Thanks, >>>>>> Kathleen >>>>>>=20 >>>>>>>=20 >>>>>>> Jim >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>>=20 >>>>>> Best regards, >>>>>> Kathleen >>>>>>=20 >>>>>> _______________________________________________ >>>>>> COSE mailing list >>>>>> COSE@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cose >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>>=20 >>>> Best regards, >>>> Kathleen >>>>=20 >>>> _______________________________________________ >>>> COSE mailing list >>>> COSE@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cose >>=20 >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose >=20 From nobody Sat Sep 10 22:14:16 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 D766512B0A7; Sat, 10 Sep 2016 22:14:14 -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.32.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147357085487.32499.17703966837275325616.idtracker@ietfa.amsl.com> Date: Sat, 10 Sep 2016 22:14:14 -0700 Archived-At: Cc: cose@ietf.org Subject: [COSE] I-D Action: draft-ietf-cose-msg-18.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, 11 Sep 2016 05:14:15 -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-18.txt Pages : 118 Date : 2016-09-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 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-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-18 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 Sat Sep 10 22:16:34 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 A115112B0DA for ; Sat, 10 Sep 2016 22:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, 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 QN424UxDEp6C for ; Sat, 10 Sep 2016 22:16:31 -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 9D1C812B098 for ; Sat, 10 Sep 2016 22:16:30 -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.1210.3; Sat, 10 Sep 2016 22:29:49 -0700 From: Jim Schaad To: References: <147357085487.32499.17703966837275325616.idtracker@ietfa.amsl.com> In-Reply-To: <147357085487.32499.17703966837275325616.idtracker@ietfa.amsl.com> Date: Sat, 10 Sep 2016 22:16:22 -0700 Message-ID: <005401d20beb$a487d0b0$ed977210$@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: AQFTIxruA1QRZQwkIKps4HnZ+RyrVaFxkPLg Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: kathleen.moriarty.ietf@gmail.com Subject: [COSE] FW: I-D Action: draft-ietf-cose-msg-18.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, 11 Sep 2016 05:16:32 -0000 I believe that this draft addresses all of the AD comments. > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Saturday, September 10, 2016 10:14 PM > To: i-d-announce@ietf.org > Cc: cose@ietf.org > Subject: [COSE] I-D Action: draft-ietf-cose-msg-18.txt > > > 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-18.txt > Pages : 118 > Date : 2016-09-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 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-18 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-18 > > > 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/ > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Wed Sep 14 12:24:43 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 BA60112B028 for ; Wed, 14 Sep 2016 12:24:41 -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, FREEMAIL_FROM=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 1K6f0rUKnJMT for ; Wed, 14 Sep 2016 12:24:39 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 772AD127077 for ; Wed, 14 Sep 2016 12:24:39 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id t67so34330548ywg.3 for ; Wed, 14 Sep 2016 12:24:39 -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=jO+7yrG0pSXVOWi9qMWmQQOj4F8mNYBbeQSt6dUjiss=; b=0AWfKvxCvhv0pazP36LKwuckJ1XYdtp4cPUu7mtFtZ4ENvd1wrbhvOTqcF6H8un1XG mOHBui/9u7DX903FgAsUXAKig76ZgQCFAOw33f9skT/YWJM6iuUrzzyIS03D/lBAWIwt /q3dleyqdg0CGDcVhuDJWcfVAt1Z5pAZxQJDpVCQwmpWgq+uaqOuUpF470hp5X0oyjFT O1+3z2oo8WNraVRxfywlyWYYwEFqhapwRpB36V82ZE+R32x5JotgVE21ck54W9jtbNfL uZQQm+4XdA3Jt9I/wtfMvzVza6vbfyLnPxn5+wCKrOmYflwXb2szVMFA84RKvT3ygJo6 z3xA== 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=jO+7yrG0pSXVOWi9qMWmQQOj4F8mNYBbeQSt6dUjiss=; b=N8a2A9gnWbkwQ+lFS8prOYGbzbMEb8T8v233gbIA22f/DBeXRg4xDdbC9gFAMdlRo7 vfNpfBeFOOdkd7N8ailnNIlxAXrSuuh9zl1+2BmDEMhDKJ3YrHNvyiaOSR4Jmr0Vz/M1 Xb/MEOJ/nt74qXZBA75zMDYIqZ5BE+uRic1ssUZay32YTxcb4IPEEYj/WEsMCeUJ7gvW Ffsr00jjNv+7FPTJ4RzUgjFUD1RX6vTcamGeJxFBlVH/SJaFZQqDLCy2Y4ylFeeXuO1Q yIQNeWAuoPJz4ymfWmp0815WqL5s5USBpeeC4FPZYFy2O9OXgdVBZu/uT9XtzGGnvHn0 W1Jw== X-Gm-Message-State: AE9vXwNo3NXj7ejjhg9BW9wRqbBwtYU16PevnEFblG2315653PdC341XiKBAD/5sOTgGfc6TIFSo5HMLnfVDKg== X-Received: by 10.13.254.135 with SMTP id o129mr5102150ywf.117.1473881078720; Wed, 14 Sep 2016 12:24:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.8 with HTTP; Wed, 14 Sep 2016 12:24:38 -0700 (PDT) In-Reply-To: References: <0a2101d20636$bc946c50$35bd44f0$@augustcellars.com> <0ce101d2086e$125c9d90$3715d8b0$@augustcellars.com> <0d2501d2088b$6af36ca0$40da45e0$@augustcellars.com> <5D8F9919-B95D-4CAD-929D-CB513EEFBCDC@gmail.com> <002301d20baa$8355cd70$8a016850$@augustcellars.com> From: Kathleen Moriarty Date: Wed, 14 Sep 2016 15:24:38 -0400 Message-ID: To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "cose@ietf.org" Subject: Re: [COSE] AD review of draft-ietf-cose-msg 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, 14 Sep 2016 19:24:42 -0000 Hello, top-posting. I just went through all of the downrefs and the only 2 that are not in the downref registry are RFC3610 and RFC7539. Both have been referenced normatively before, RFC3610 by RFC4309, RFC5084, RFC5412, and RFC5669 and RFC7539 by RFC7905. I'll make a note of this when I start the last call and am adding them to the registry as I believe they are community accepted normative references. Thank you, Kathleen On Sat, Sep 10, 2016 at 7:27 PM, wrote: > > > Please excuse typos, sent from handheld device > >> On Sep 10, 2016, at 5:30 PM, Jim Schaad wrote: >> >> OK, >> >> I am going to suggest that the paragraph should read as follows: >> >> It is requested that IANA create a new registry entitled "COSE Header >> Parameters". The registry should be created as Expert Review Required. >> Guidelines for the experts is provided in Section 16.11. It should be noted >> that in additional to the expert review, some portions of the registry >> require a specification, potentially on standards track, be supplied as >> well. >> > > Thanks, that wording is helpful as that wasn't entirely clear to me. Let me know when it's ready. I still need to dig into the downrefs, but that won't take long. > > Thanks, > Kathleen >> >> Jim >> >> >>> -----Original Message----- >>> From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of >>> kathleen.moriarty.ietf@gmail.com >>> Sent: Friday, September 09, 2016 7:12 PM >>> To: Jim Schaad >>> Cc: cose@ietf.org >>> Subject: Re: [COSE] AD review of draft-ietf-cose-msg >>> >>> Sorry I didn't see this message, not sure why. >>> >>> Hmmm, how about for the sections that have the need for a specification, >> you >>> add in something like: >>> >>> Please excuse typos, sent from handheld device >>> >>>> On Sep 6, 2016, at 6:10 PM, Jim Schaad wrote: >>>> >>>> So something along the lines of this? >>>> >>>> The registry is to be created as Expert Review Required. There are >>>> additional requirements for sub-ranges of values, >>> >>>> where a specification may also be necessary. Expert review guidelines >>>> are provided in Section 16.11. >>> >>> Thanks, >>> Kathleen >>>> >>>> Jim >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Kathleen >>>>> Moriarty >>>>> Sent: Tuesday, September 06, 2016 12:22 PM >>>>> To: Jim Schaad >>>>> Cc: cose@ietf.org >>>>> Subject: Re: [COSE] AD review of draft-ietf-cose-msg >>>>> >>>>>> On Tue, Sep 6, 2016 at 2:39 PM, Jim Schaad >>> wrote: >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Kathleen >>>>>>> Moriarty >>>>>>> Sent: Tuesday, September 06, 2016 11:01 AM >>>>>>> To: Jim Schaad >>>>>>> Cc: cose@ietf.org >>>>>>> Subject: Re: [COSE] AD review of draft-ietf-cose-msg >>>>>>> >>>>>>> On Sat, Sep 3, 2016 at 6:58 PM, Jim Schaad >>>> wrote: >>>>>>>>> Section 16.2 >>>>>>>>> >>>>>>>>> I think it's a little confusing to state the registry values >>>>>>>>> require expert review, then buried in the 'label' description say >>>>>>>>> it can be >>>>>> specification >>>>>>> required. >>>>>>>>> Wouldn't it be more clear to state that a dependency exists and a >>>>>>>>> specification is required in the intro paragraph for this section? >>>>>>>>> This applies to the other sections that also require a >>>>>>>>> specification as >>>>>> it don't >>>>>>> seem that all registries do. >>>>>>>> >>>>>>>> I separated this issue because I think it is potentially going to >>>>>>>> need >>>>>> more >>>>>>> discussion than any of the other issues. >>>>>>> >>>>>>> Good, thanks. >>>>>>> >>>>>>>> >>>>>>>> From the IANA point of view, I want to keep these registry rules >>>> simple. >>>>>> That >>>>>>> is, I want IANA to treat the registries as if everything is expert >>>> review. >>>>>>>> >>>>>>>> Given that I want to break down the label ranges. Would it makes >>>>>>>> sense >>>>>> to >>>>>>> move this language from here to section 16.11 so that it is clear >>>>>>> that >>>>>> this will be >>>>>>> for the expert reviewers to look at rather than for IANA to look at? >>>>>>> >>>>>>> Well, this just applies to section 16.2, right? If so, then I >>>>>>> think the >>>>>> intro to just >>>>>>> the subsection that requires a specification should also include >>>>>>> that >>>>>> information. >>>>>>> If it's buried within the subsection, I think it gets lost for the >>>>>>> draft >>>>>> review >>>>>>> process. It might work out fine when it's used to add to the >>>>>>> registry, >>>>>> but it >>>>>>> should be as clear as possible. If it were just in 16.11, I think >>>>>>> that >>>>>> would be >>>>>>> confusing since it doesn't apply to all the registries established >>>>>>> by this >>>>>> draft. >>>>>>> ANother sentence or two in the introduction should be all this >>>>>>> requires to >>>>>> make >>>>>>> it more clear. WHat do you think? >>>>>> >>>>>> No, this issue applies to section 16.2 (Header parameters), 16.4 >>>>>> (Algorithms), 16.5 (Key Common Parameters) and 16.8 (Elliptic Curve >>>>>> Parameters). >>>>> >>>>> Oh, that's right... >>>>> >>>>> Since it is for more than just one section I think it could >>>>>> merit its own bullet point in 16.11 and that would be reasonable. >>>>>> >>>>>> Some additional text would also work as well, but it is not a one >>>>>> place >>>> fix. >>>>> >>>>> I think it will be more clear in each section since you can do it >>>>> with >>>> just a >>>>> sentence in the intro. It should help avoid problems later since >>>>> each >>>> section >>>>> adds to a registry or creates one. >>>>> >>>>> Thanks, >>>>> Kathleen >>>>> >>>>> >>>>>> >>>>>> Jim >>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Kathleen >>>>>>> >>>>>>>> >>>>>>>> Jim >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Best regards, >>>>>>> Kathleen >>>>>>> >>>>>>> _______________________________________________ >>>>>>> COSE mailing list >>>>>>> COSE@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/cose >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Best regards, >>>>> Kathleen >>>>> >>>>> _______________________________________________ >>>>> COSE mailing list >>>>> COSE@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/cose >>> >>> _______________________________________________ >>> COSE mailing list >>> COSE@ietf.org >>> https://www.ietf.org/mailman/listinfo/cose >> -- Best regards, Kathleen From nobody Wed Sep 14 15:24:50 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 7C16A127A90; Wed, 14 Sep 2016 15:24:49 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <147389188950.29919.7016783910261901311.idtracker@ietfa.amsl.com> Date: Wed, 14 Sep 2016 15:24:49 -0700 Archived-At: Cc: cose-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, goran.selander@ericsson.com, cose@ietf.org, draft-ietf-cose-msg@ietf.org Subject: [COSE] Last Call: (CBOR Object Signing and Encryption (COSE)) to Proposed Standard X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 22:24:49 -0000 The IESG has received a request from the CBOR Object Signing and Encryption WG (cose) to consider the following document: - 'CBOR Object Signing and Encryption (COSE)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-09-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc7539: ChaCha20 and Poly1305 for IETF Protocols (Informational - Independent Submission Editor stream) rfc3394: Advanced Encryption Standard (AES) Key Wrap Algorithm (Informational - IETF stream) rfc3610: Counter with CBC-MAC (CCM) (Informational - Independent Submission Editor stream) rfc5869: HMAC-based Extract-and-Expand Key Derivation Function (HKDF) (Informational - IETF stream) rfc6090: Fundamental Elliptic Curve Cryptography Algorithms (Informational - IETF stream) rfc2104: HMAC: Keyed-Hashing for Message Authentication (Informational - IETF stream) Note that some of these references may already be listed in the acceptable Downref Registry. From nobody Wed Sep 14 22:12:20 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 D491012B17B for ; Wed, 14 Sep 2016 22:12:19 -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 ImzBPwJ0KJ5w for ; Wed, 14 Sep 2016 22:12:17 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 91BDB12B16E for ; Wed, 14 Sep 2016 22:12:16 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id i130so80241113wmf.0 for ; Wed, 14 Sep 2016 22:12:16 -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=4URuAqawscVMHoeEinlXaC7OaWI0mHYmJ+AoWwOPhSo=; b=JppBd0UoJBcC4bGcR6xoZQpMhMpivYZSiV69RS+oNj1xH4Bo6nMDF1mKJ+x+b4EG7k 2pFMY6lJjDOzSmsBHpRWpJ2o2Z1nnHPUmq72GURYdjl9jXGxia0qyrFRUT7ZVSta/ky3 /3E2TZYZmIrP/deTnjKbJL4ArYOCJ8BYVHB4vFooIqK7PEcQusgZUvWlBxza28rrujTY U9LQM9X+PMWq2uaV+zu34HIAZGamBC0SibawPH7nEc4enJ5JBVhl0f1i9Fv0XfG+spLu V4g2WkJK+GmNj5XiB231/GnJTwalPhFLsh7/9kG4mjGm2H/9fjt2ED+hipE99TggYjDs 88UQ== 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=4URuAqawscVMHoeEinlXaC7OaWI0mHYmJ+AoWwOPhSo=; b=B2uckhDV+QKidWgFVTO/FHa/unnfgkF8BjGT8/YEYlvT3+SDOP3Oc9DSTbIwPZV+r6 sFwNFBDXAPuaWHZJwFi5NcfKrPTJYkXolp8V0RsbaZq1Y56z55vtoR+GyrIOLqssaro2 UkT3ti9XRN6DOzDsi/j4lLC4Ox3YP69b7oDszHrrOMjZUkKdtnDbGwF2l9tEh30ZQGlz JKT3rKrGo6Lv416kpsCe/WhRfcouk/t/qmAI+oGvupbRXzCOx+7sXvkzmyYF48WCqq32 MirznSweZIKFR+DjAVQHqGQeeRf2A/K6Ep51wymAZdrTZAnd0iAilyFdfaeCUlsh/QDC OcJw== X-Gm-Message-State: AE9vXwPgOulQBnbbzGomjcFLazei26E76wenYCf/79xy7vongi38MghPX+joc0tmZL/P/An2XLRzk6KFakJosA== X-Received: by 10.28.206.197 with SMTP id e188mr1055736wmg.65.1473916335476; Wed, 14 Sep 2016 22:12:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.94.103 with HTTP; Wed, 14 Sep 2016 22:12:14 -0700 (PDT) In-Reply-To: References: <00c501d1eb68$23eee540$6bccafc0$@augustcellars.com> From: Samuel Erdtman Date: Thu, 15 Sep 2016 07:12:14 +0200 Message-ID: To: =?UTF-8?Q?G=C3=B6ran_Selander?= Content-Type: multipart/alternative; boundary=94eb2c1941129ae9a0053c84e35d Archived-At: Cc: Jim Schaad , 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: Thu, 15 Sep 2016 05:12:20 -0000 --94eb2c1941129ae9a0053c84e35d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry for now replying earlier, When reading the comments I think that we have come to a good place. Thanks for an awesome job Jim! //Samuel On Sun, Aug 7, 2016 at 9:41 AM, G=C3=B6ran Selander wrote: > Just a quick comment: > > On 2016-07-31 22:14, "COSE on behalf of Jim Schaad" on behalf of ietf@augustcellars.com> wrote: > > > > >=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 authent= icated 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. > > > In draft-ietf-cose-msg-14, both texts on kid and IV had the formulation > "they can be placed in the unprotected headers bucket=E2=80=9D. I asked i= n my > review if this could instead be replaced with a recommendation, to reduce > the number of options, for the benefit of the user of this specification. > But I think Samuel has a point that making all headers protected could > sometimes be an alternative which also simplifies for the user. I propose > we change the normative statement to MAY or revert to the original > formulation, both for kid and IV. > > G=C3=B6ran > > (going back to vacation) > > --94eb2c1941129ae9a0053c84e35d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry for now replying earlier, When reading the comm= ents I think that we have come to a good place.

Thanks fo= r an awesome job Jim!

//Samuel

On Sun, Aug 7, 2016 at 9:41= AM, G=C3=B6ran Selander <goran.selander@ericsson.com> wrote:
Just a quick comment:

On 2016-07-31 22:14, "COSE on behalf of Jim Schaad" <cose-bounces@ietf.org
on behalf of iet= f@augustcellars.com> wrote:

>
>=E2=80=9CAs the IV is authenticated by the
>=C2=A0 =C2=A0 =C2=A0 encryption process, it SHOULD be placed in the unp= rotected 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 phrasing under Partial IV to be =E2=80=9CAs the IV is authen= ticated 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.


In draft-ietf-cose-msg-14, both texts on kid and IV had the formulat= ion
"they can be placed in the unprotected headers bucket=E2=80=9D. I aske= d in my
review if this could instead be replaced with a recommendation, to reduce the number of options, for the benefit of the user of this specification. But I think Samuel has a point that making all headers protected could
sometimes be an alternative which also simplifies for the user. I propose we change the normative statement to MAY or revert to the original
formulation, both for kid and IV.

G=C3=B6ran

(going back to vacation)


--94eb2c1941129ae9a0053c84e35d-- From nobody Thu Sep 22 11:39:17 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 DF03112B334; Thu, 22 Sep 2016 11:39:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147456955487.22422.7694430867546942228.idtracker@ietfa.amsl.com> Date: Thu, 22 Sep 2016 11:39:14 -0700 Archived-At: Cc: Kathleen.Moriarty.ietf@gmail.com, cose-chairs@ietf.org, ietf@justin.richer.org, cose@ietf.org Subject: [COSE] cose - Not having a session at IETF 97 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, 22 Sep 2016 18:39:15 -0000 Justin Richer, a chair of the cose working group, indicated that the cose working group does not plan to hold a session at IETF 97. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Mon Sep 26 17:53:11 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 0D93412B047 for ; Mon, 26 Sep 2016 17:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 nxYFo_1RIPS9 for ; Mon, 26 Sep 2016 17:53:06 -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 B203712B3A4 for ; Mon, 26 Sep 2016 17:53:05 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 26 Sep 2016 18:05:58 -0700 From: Jim Schaad To: References: <33a10112-ee91-75df-a390-1c7c2a23a729@bbn.com> In-Reply-To: <33a10112-ee91-75df-a390-1c7c2a23a729@bbn.com> Date: Mon, 26 Sep 2016 17:52:30 -0700 Message-ID: <021401d21859$6eadb700$4c092500$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0215_01D2181E.C2543630" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQLn+ErX890UkhHKZArMVoO8r82N055gwCow X-Originating-IP: [192.168.1.152] Archived-At: Cc: 'Kathleen Moriarty' Subject: [COSE] FW: secdir review of cose-msg-18 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, 27 Sep 2016 00:53:10 -0000 ------=_NextPart_000_0215_01D2181E.C2543630 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable For your pleasure, here is the SEC DIR review that I got for the COSE = document. I have responded to these comments, resisting some changes = and making changes in other cases. =20 You can look at the current set of changes that I intend to publish = tomorrow evening so that the IESG telechat can continue. The biggest = change is the title of sections 5.1.1 and 12 have been updated to what I = consider to be better ones as suggested by Stephen in a later message, = but in response to a comment below. =20 While comments before I publish the new the new version tomorrow, the = fact that I have published should not be considered as a reason to = object if you feel these are bad changes. =20 Jim =20 =20 From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Wednesday, September 21, 2016 7:27 AM To: secdir ; Jim Schaad ; = Justin Richer ; Kepeng Li ; = Kathleen Moriarty Subject: secdir review of cose-msg-18 =20 SECDIR review of draft-ietf-cose-msg-18 =20 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written with the intent of improving security = requirements and considerations in IETF drafts. Comments not addressed = in last call may be included in AD reviews during the IESG review. = Document editors and WG chairs should treat these comments just like any = other last call comments. =20 This document defines formats for signing and/or encryption of data = encoded using CBOR (RFC7049). The signing/encryption approach adopted = here is based on the standards developed in JOSE (RFCs 7515-18), since = CBOR is based on JSON.=20 =20 This is a large document: about 90 pages plus almost 30 pages of = appendices (providing useful examples). Close to half of the = (non-appendix portion) document is devoted to specifications for a set = of algorithms for encryption, signatures, message authentication, and = key distribution. Only when the reader reaches page 73 is it made clear = that the algorithm descriptions are not MTI; they define a set from = which application developers must (?) choose when creating a profile for = COSE use in a specific application context. Given the long-standing IETF = policy to trying to facilitate algorithm agility, =20 I think it preferable to extract these descriptions and publish them as = separate RFCs, a practice often employed in documenting many other = security protocols (including JOSE, from which this work is based).=20 =20 =20 The document begins with a brief explanation of how COSE differs from = JOSE, an excellent preface to the document. The cited design differences = all seem very appropriate for CBOR, e.g., using binary encoding instead = of base64url, shedding some of the odd constraints adopted in JOSE = because of pre-existing work in the area, and updating the list of = algorithms. =20 Since there is no standard grammar for CBOR, the author adopted the = primitive types defined in an I-D (draft-ietf- = greevenbosch-appsawg-cbor-cddl) to allow for a concise specification of = COSE formats. I recommend that this document be held for publication = until that I-D is approved. I also note that the cited I-D is = Informational, but this document is Standards Track. the cited I-D is = listed as informative, but the syntax it defines is used extensively = throughout this document, thus I believe it really is normative. =20 =20 Section 2 defines the basic COSE data structure. The description seems = clear and logical, but the list of message types is a bit puzzling = (absent information that is provided later, in Sections 4 and 5). For = example, there is a Single Signer data Object, and a Signed Data Object. = If the latter accommodates multiple signers, why not make that part of = the name? The same nomenclature confusion arises for encrypted objects = directed to a single recipient vs. multiple recipients. =20 Section 3 Describes the header parameters. It provides generally good, = detailed descriptions of the common header elements and explains why = certain conventions are adopted. It clearly describes requirements = imposed on senders and recipients.=20 =20 =20 Section 4 describes the objects used to convey one or more signatures = for objects. The description here is a bit confusing when it discusses = one vs. multiple signatures. The format that allows carriage of multiple = signatures does not necessarily imply that there are multiple signers, = e.g., the multiple signatures may be present to accommodate different = algorithm capabilities for different recipients. The introduction to 4.2 = says:=20 =E2=80=9CThe COSE_Sign1 signature structure is used when only one = signer is going to be placed on a message.=E2=80=9D Perhaps it would be clearer to say that this structure is used when only = one signature is to be placed in a message. =20 Overall this section is well written and provides useful details about = how to compute signatures and counter signatures. =20 =20 Section 5 describes the COSE encryption objects. I disagree with one = choice of terminology adopted here: =E2=80=9Crecipient algorithm = classes=E2=80=9D which is described in 5.1.1. This is really a = discussion of classes of key distribution/management algorithms, = focusing on how each recipient of an encrypted message acquires the CEK = used to decrypt the message. I=E2=80=99d prefer a less obscure name for = this sub-section. Otherwise this section is well written and provide = lots of useful details about how to encrypt and decrypt messages for two = classes of encryption algorithms. =20 =20 Section 6 describes the MAC objects. Here too there are two types of = structures, depending on whether a recipient implicitly knows what key = to use to verify the MAC, or whether an ID for one or more MAC keys must = be communicated. The text here closely parallels that of Section 5 and = is very good. =20 =20 Section 7 describes the COSE key structure. It is designed to = accommodate the data needed by a wide range of key distribution = mechanisms and encryption techniques. =20 =20 Section 8 defines two classes of signature algorithms that can be used = with COSE, specifies an algorithm of each type, and provides security = guidance for each algorithm. I think it would be preferable to remove = the detailed algorithm descriptions (Sections 8.1 and 8.2) and = associated security considerations (which are well written) from this = document. The comments below apply to sections 9, 10, 11 and 12.=20 =20 I have several concerns about including the algorithm (vs. algorithm = class) descriptions here. For many security protocols (and = security-focused data formats), we usually (though not always) specify = mandatory and optional to implement algorithms in separate documents, to = facilitate algorithm agility. I think we should follow that model for = COSE. Also, the text here does not mandate support for these algorithms; = it merely provides details for a set of algorithms that a sender and/or = receive may choose to implement. One has to read the final sentence of = the opening paragraph of Section 15 to learn that this is the intent, = i.e., that selection of specific algorithms is deferred to the each = application that makes use of COSE. Given that later statement, it = appears that the algorithms specified in Sections 8-12 ate intended to = define the set from which application developer MUST choose, but that = too is not clearly stated. I think this makes it even more appropriate = to remove the detailed algorithm discussions from this document. =20 =20 Section 12 describes the =E2=80=9Crecipient algorithm classes=E2=80=9D = aka key distribution/management methods. Most of this section is = analogous to the preceding sections (9-11) where specific algorithms are = described for use with COSE, and thus my comments about undue bundling = of algorithms with a protocol specs apply here too. I do not object to = describing key transport, key wrapping and key agreement methods in = general, but the detailed specs in 12.2.1, 12.4.1 and 12.5.1 seem = inappropriate here, for the reasons noted above. =20 =20 Section 13 describes parameters for key objects used by COSE. The specs = here are sufficiently generic that they do not suffer from the problems = I noted for Sections 8-12. =20 =20 Section 15 provides guidance for application developers making use of = COSE. This is where a reader finally discovers that the algorithms = described in Sections 8-12 are not MTI, and that each application is = expected to specify which algorithms are MTI in that context, to = facilitate interoperability. =20 Section 16 (IANA Considerations) describes the registries that need to = be created for COSE, and extensions to the CoAP registry to support = COSE. It seem to be well written and comprehensive. =20 Section 18 (Security Considerations) is a good adjunct to the already = well-written security considerations discussions provided for the = algorithms in Sections 8-12. =20 =20 Typos and suggested rewording. =20 Section 2:=20 =20 The COSE object structure is designed so that there can be a large = amount of common code when parsing and processing the different security messages. -> The COSE object structure is designed so that there can be a large = amount of common code when parsing and processing the different types of = security messages. =20 COSE messages are also built using the concept of using layers to = =E2=80=A6=20 -> COSE messages are built using the concept of layers to =E2=80=A6 =20 Section 3: =20 The integer and string values for labels has been divided =E2=80=A6 -> The integer and string values for labels have been divided =E2=80=A6 =20 Applications SHOULD perform the same checks that the same label = =E2=80=A6 -> Applications SHOULD verify that the same label =E2=80=A6 =20 Applications should have a statement if the label can be omitted. -> Applications SHOULD (?) have a statement if the label can be omitted. =20 Integers are from the "CoAP Content-Formats" IANA registry table. (no = reference) =20 As the IV is authenticated by the encryption process, it can be placed = in the unprotected header bucket. (in general, an encryption process = will not =E2=80=9Cauthenticate=E2=80=9D an IV, but use of a modified IV = will yield mangled plaintext, which can be detected by an integrity = check or a signature. the same comment applies to the similar statement = in the =E2=80=9Cpartial IV=E2=80=9D description.) =20 =20 Section 4: =20 Edwards Digital Signature Algorithm (EdDSA) signature algorithm and with = the Elliptic Curve Digital Signature Algorithm (ECDSA) signature = algorithm. -> Edwards Digital Signature Algorithm (EdDSA) (cite) and with the = Elliptic Curve Digital Signature Algorithm (ECDSA) (cite). =20 One of the features supplied in the COSE document is the = ability=E2=80=A6 -> One of the features offered by the COSE format is the ability = =E2=80=A6 =20 This algorithm takes in the body information =E2=80=A6 -> The signing and verification processes take in the body information = =E2=80=A6 =20 Counter signatures provide a method of having a different signature = occur on some piece of content. -> Counter signatures provide a method of associating different = signatures generated by different signers with some piece of content. =20 =20 Section 5 =20 Other: The key is randomly generated. -> Other: The key is randomly or pseudo-randomly generated. =20 =20 Section 6 =20 (This knowledge of sender assumes that there are only two parties = involved and you did not send the message yourself.) -> (This knowledge of sender assumes that there are only two parties = involved and you did not send the message to yourself.) =20 =20 Section 15: =20 It is intended that a profile of this document be created that defines the interopability -> It is intended that a profile of this document be created that defines the interoperability ------=_NextPart_000_0215_01D2181E.C2543630 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Fo= r your pleasure, here is the SEC DIR review that I got for the COSE = document.=C2=A0 I have responded to these comments, resisting some = changes and making changes in other cases.

 

Yo= u can look at the current set of changes that I intend to publish = tomorrow evening so that the IESG telechat can continue.=C2=A0 The = biggest change is the title of sections 5.1.1 and 12 have been updated = to what I consider to be better ones as suggested by Stephen in a later = message, but in response to a comment below.

 

Wh= ile comments before I publish the new the new version tomorrow, the fact = that I have published should not be considered as a reason to object if = you feel these are bad changes.

 

Ji= m

 

 

Fr= om: = Stephen Kent [mailto:kent@bbn.com]
Sent: Wednesday, September = 21, 2016 7:27 AM
To: secdir <secdir@ietf.org>; Jim = Schaad <ietf@augustcellars.com>; Justin Richer = <jricher@mit.edu>; Kepeng Li <kepeng.lkp@alibaba-inc.com>; = Kathleen Moriarty = <Kathleen.Moriarty.ietf@gmail.com>
Subject: secdir = review of cose-msg-18

 

SECDIR review of = draft-ietf-cose-msg-18

 

I have reviewed = this document as part of the security directorate's ongoing effort to = review all IETF documents being processed by the IESG.=C2=A0 These = comments were written with the intent of improving security requirements = and considerations in IETF drafts.=C2=A0 Comments not addressed in last = call may be included in AD reviews during the IESG review.=C2=A0 = Document editors and WG chairs should treat these comments just like any = other last call comments.

 

This document = defines formats for signing and/or encryption of data encoded using CBOR = (RFC7049). The signing/encryption approach adopted here is based on the = standards developed in JOSE (RFCs 7515-18), since CBOR is based on JSON. =

 

This is a large = document: about 90 pages plus almost 30 pages of appendices (providing = useful examples).=C2=A0 Close to half of the (non-appendix portion) = document is devoted to specifications for a set of algorithms for = encryption, signatures, message authentication, and key distribution. = Only when the reader reaches page 73 is it made clear that the algorithm = descriptions are not MTI; they define a set from which application = developers must (?) choose when creating a profile for COSE use in a = specific application context. Given the long-standing IETF policy to = trying to facilitate algorithm agility, =C2=A0

I think it = preferable to extract these descriptions and publish them as separate = RFCs, a practice often employed in documenting many other security = protocols (including JOSE, from which this work is based). =

 

 

The document = begins with a brief explanation of how COSE differs from JOSE, an = excellent preface to the document. The cited design differences all seem = very appropriate for CBOR, e.g., using binary encoding instead of = base64url, shedding some of the odd constraints adopted in JOSE because = of pre-existing work in the area, and updating the list of = algorithms.

 

Since there is no = standard grammar for CBOR, the author adopted the primitive types = defined in an I-D (draft-ietf- greevenbosch-appsawg-cbor-cddl) to allow = for a concise specification of COSE formats. I recommend that this = document be held for publication until that I-D is approved. I also note = that the cited I-D is Informational, but this document is Standards = Track. the cited I-D is listed as informative, but the syntax it defines = is used extensively throughout this document, thus I believe it really = is normative.

 

 

Section 2 defines = the basic COSE data structure. The description seems clear and logical, = but the list of message types is a bit puzzling (absent information that = is provided later, in Sections 4 and 5). For example, there is a Single = Signer data Object, and a Signed Data Object. If the latter accommodates = multiple signers, why not make that part of the name? The same = nomenclature confusion arises for encrypted objects directed to a single = recipient vs. multiple recipients.

=

 

Section 3 = Describes the header parameters. It provides generally good, detailed = descriptions of the common header elements and explains why certain = conventions are adopted. It clearly describes requirements imposed on = senders and recipients.

 

 

Section 4 = describes the objects used to convey one or more signatures for objects. = The description here is a bit confusing when it discusses one vs. = multiple signatures. The format that allows carriage of multiple = signatures does not necessarily imply that there are multiple signers, = e.g., the multiple signatures may be present to accommodate different = algorithm capabilities for different recipients. The introduction to 4.2 = says:

=C2=A0=C2=A0=C2=A0 =E2=80=9CThe COSE_Sign1 = signature structure is used when only one signer is going to be placed = on a message.=E2=80=9D

Perhaps it would be clearer to say that = this structure is used when only one signature is to be placed in = a message.

 

Overall this = section is well written and provides useful details about how to compute = signatures and counter signatures.

 

 

Section 5 = describes the COSE encryption objects. I disagree with one choice of = terminology adopted here: =E2=80=9Crecipient algorithm classes=E2=80=9D = which is described in 5.1.1. This is really a discussion of classes of = key distribution/management algorithms, focusing on how each recipient = of an encrypted message acquires the CEK used to decrypt the message. = I=E2=80=99d prefer a less obscure name for this sub-section. Otherwise = this section is well written and provide lots of useful details about = how to encrypt and decrypt messages for two classes of encryption = algorithms.

 

 

Section 6 = describes the MAC objects. Here too there are two types of structures, = depending on whether a recipient implicitly knows what key to use to = verify the MAC, or whether an ID for one or more MAC keys must be = communicated. The text here closely parallels that of Section 5 and is = very good.

 

 

Section 7 = describes the COSE key structure. It is designed to accommodate the data = needed by a wide range of key distribution mechanisms and encryption = techniques.

 

 

Section 8 defines = two classes of signature algorithms that can be used with COSE, = specifies an algorithm of each type, and provides security guidance for = each algorithm. I think it would be preferable to remove the detailed = algorithm descriptions (Sections 8.1 and 8.2) and associated security = considerations (which are well written) from this document. The comments = below apply to sections 9, 10, 11 and 12.

 

I have several = concerns about including the algorithm (vs. algorithm class) = descriptions here. For many security protocols (and security-focused = data formats), we usually (though not always) specify mandatory and = optional to implement algorithms in separate documents, to facilitate = algorithm agility. I think we should follow that model for COSE. Also, = the text here does not mandate support for these algorithms; it merely = provides details for a set of algorithms that a sender and/or receive = may choose to implement. One has to read the final sentence of the = opening paragraph of Section 15 to learn that this is the intent, i.e., = that selection of specific algorithms is deferred to the each = application that makes use of COSE. Given that later statement, it = appears that the algorithms specified in Sections 8-12 ate intended to = define the set from which application developer MUST choose, but that = too is not clearly stated. I think this makes it even more appropriate = to remove the detailed algorithm discussions from this document. = =C2=A0

 

Section 12 = describes the =E2=80=9Crecipient algorithm classes=E2=80=9D aka key = distribution/management methods. Most of this section is analogous to = the preceding sections (9-11) where specific algorithms are described = for use with COSE, and thus my comments about undue bundling of = algorithms with a protocol specs apply here too. I do not object to = describing key transport, key wrapping and key agreement methods in = general, but the detailed specs in 12.2.1, 12.4.1 and 12.5.1 seem = inappropriate here, for the reasons noted above.

 

 

Section 13 = describes parameters for key objects used by COSE. The specs here are = sufficiently generic that they do not suffer from the problems I noted = for Sections 8-12.

 

 

Section 15 = provides guidance for application developers making use of COSE. This is = where a reader finally discovers that=C2=A0 the algorithms described in = Sections 8-12 are not MTI, and that each application is expected to = specify which algorithms are MTI in that context, to facilitate = interoperability.

 

Section 16 (IANA = Considerations) describes the registries that need to be created for = COSE, and extensions to the CoAP registry to support COSE. It seem to be = well written and comprehensive.

 

Section 18 = (Security Considerations) is a good adjunct to the already well-written = security considerations discussions provided for the algorithms in = Sections 8-12.

 

 

Typos and = suggested rewording.

 

Section 2: =

 

The COSE object = structure is designed so that there can be a large amount of common code = when parsing and processing the different

security = messages.

-> The COSE object structure is = designed so that there can be a large amount of common code when parsing = and processing the different types of security = messages.

 

COSE messages are = also built using the concept of using layers to =E2=80=A6 =

-> COSE messages are built using the = concept of layers to =E2=80=A6

 

Section = 3:

 

The integer and = string values for labels has been divided = =E2=80=A6

-> The integer and string values for = labels have been divided = =E2=80=A6

 

Applications = SHOULD perform the same checks that the same label = =E2=80=A6

-> Applications SHOULD verify that the same label = =E2=80=A6

 

Applications = should have a statement if the label can be = omitted.

-> Applications SHOULD (?) have a statement if the label can be = omitted.

 

Integers are from = the "CoAP Content-Formats" IANA registry table. (no reference)

 

As the IV is = authenticated by the encryption process, it can be placed in the = unprotected header bucket. (in general, an encryption = process will not =E2=80=9Cauthenticate=E2=80=9D an IV, but use of a = modified IV will yield mangled plaintext, which can be detected by an = integrity check or a signature. the same comment applies to the similar = statement in the =E2=80=9Cpartial IV=E2=80=9D = description.)

 

 

Section = 4:

 

Edwards Digital = Signature Algorithm (EdDSA) signature algorithm and with the Elliptic = Curve Digital Signature Algorithm (ECDSA) signature = algorithm.

-> Edwards Digital Signature Algorithm = (EdDSA) (cite) and with the Elliptic Curve Digital = Signature Algorithm (ECDSA) (cite).

 

One of the = features supplied in the COSE document is the = ability=E2=80=A6

-> One of the features offered by the COSE = format is the ability = =E2=80=A6

 

This algorithm = takes in the body information =E2=80=A6

-> The signing and verification = processes take in the body = information =E2=80=A6

 

Counter signatures = provide a method of having a different signature occur on some piece of = content.

-> Counter signatures provide a method = of associating = different signatures generated by different signers with some piece of = content.

 

 

Section = 5

 

Other:=C2=A0 The = key is randomly generated.

-> Other:=C2=A0 = The key is randomly or pseudo-randomly generated.

 

 

Section = 6

 

(This knowledge of = sender assumes that there are only two parties involved and you did not = send the message yourself.)

-> (This = knowledge of sender assumes that there are only two parties involved and = you did not send the message to yourself.)

 

 

Section = 15:

 

It is intended = that a profile of this document be created that

defines the = interopability

-> It is intended that a profile of this = document be created that

=C2=A0=C2=A0 defines the interoperability

------=_NextPart_000_0215_01D2181E.C2543630-- From nobody Tue Sep 27 12:02:48 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 4F52812B4A3; Tue, 27 Sep 2016 12:02:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147500296731.4432.6406493584230647663.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2016 12:02:47 -0700 Archived-At: Cc: cose-chairs@ietf.org, goran.selander@ericsson.com, cose@ietf.org, draft-ietf-cose-msg@ietf.org Subject: [COSE] Spencer Dawkins' No Objection on draft-ietf-cose-msg-18: (with COMMENT) 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: Tue, 27 Sep 2016 19:02:47 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-cose-msg-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm going to be a No Objection for this doc no matter what, so it's safe to answer my question :-) This is for use with CoAP, right? Would you rely on CoAP for fragmentation, if that's required? From nobody Tue Sep 27 13:36:23 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 746D612B26E; Tue, 27 Sep 2016 13:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.217 X-Spam-Level: X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, 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 REEGWWBJKsXw; Tue, 27 Sep 2016 13:36:14 -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 562E112B39E; Tue, 27 Sep 2016 13:36:11 -0700 (PDT) Received: from hebrews (173.8.216.38) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 27 Sep 2016 13:49:24 -0700 From: Jim Schaad To: 'Spencer Dawkins' , 'The IESG' References: <147500296731.4432.6406493584230647663.idtracker@ietfa.amsl.com> In-Reply-To: <147500296731.4432.6406493584230647663.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2016 13:35:57 -0700 Message-ID: <02f601d218fe$c27987b0$476c9710$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQEAm8SCcXuKGaeRHPKmHZdDMnWWLqIwxcag X-Originating-IP: [173.8.216.38] Archived-At: Cc: cose-chairs@ietf.org, cose@ietf.org, draft-ietf-cose-msg@ietf.org, goran.selander@ericsson.com Subject: Re: [COSE] Spencer Dawkins' No Objection on draft-ietf-cose-msg-18: (with COMMENT) 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, 27 Sep 2016 20:36:16 -0000 Yes this is targeted at CoAP. CoAP should provide the needed fragmentation and we are currently have discussions in the CORE group about the best way to provide this both on a per message basis and a per fragment basis. Jim > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Spencer Dawkins > Sent: Tuesday, September 27, 2016 12:03 PM > To: The IESG > Cc: cose-chairs@ietf.org; goran.selander@ericsson.com; cose@ietf.org; draft- > ietf-cose-msg@ietf.org > Subject: [COSE] Spencer Dawkins' No Objection on draft-ietf-cose-msg-18: (with > COMMENT) > > Spencer Dawkins has entered the following ballot position for > draft-ietf-cose-msg-18: No Objection > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this introductory > paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm going to be a No Objection for this doc no matter what, so it's safe to > answer my question :-) > > This is for use with CoAP, right? Would you rely on CoAP for fragmentation, if > that's required? > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Tue Sep 27 14:25:11 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 7FBAF12B011; Tue, 27 Sep 2016 14:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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 RcTiBm81Oqu8; Tue, 27 Sep 2016 14:25:07 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 0174A12B334; Tue, 27 Sep 2016 14:25:07 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id i129so16139993ywe.2; Tue, 27 Sep 2016 14:25:06 -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=kR+lh4H2YBo9EjhiopFZd3wu1K8wX4rLQD62Md+NjFs=; b=Ix5mQWc/eosnxVBEnghbKUqzuoSuDbkZo3hpbMa7tu+DgXoz0uEWVtAdjAZ7EaGs4N CFpWZLxvsCHogREzUZwu5FOvWOJBjzppwO13DhDumw/ccs03p278g+LuJEIVzfijyiCz N2gf/Fm4QaQ3XnQHlqnecmyl1h4Ne8p0bmMYFzQJWBMARN5lKFlXn3eptO1IFkktkFSi Za+kfjElXxxOov/0LY/UeITymKtWrrRwZDprHUO/EVzsl6QarXJBG6d0+umzK9Ao3fg6 u71PhvXka02WcuyWWcQdU1ktc1IiVwfFFZCHy/fZzHraS7RT+RFehX4eyJ6X7l69D9Xi 5epg== 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=kR+lh4H2YBo9EjhiopFZd3wu1K8wX4rLQD62Md+NjFs=; b=N5v8QrEGlqV7i7JtYva+jNoNR8N0WJd0PRTQbDSvC4NW22jjNqh7P2zdlo7GwqLs+V wFnQLk85RNdYUL2OvMJWsDSUG9lWUNsSGWy7WMhDFkh7vHQ9pwgDW5O4ybBtLutv9TEb B/rLxfltj3w0Buoxh4jt6STzIgNfP0gmJjzEfaJMDMjr+LFno5fmn2ReqA3WydF9FLdU 5bzwWwI1rcb8wRbqS/ENIn0jLUwqoXwwXfaTcWjZml0F2GT3h1cUP1c3u0Xi6NKAqbad eCLRRPUE7fILjNvnKkVCNUm3pXBom7fY0OpkmocYJscI/KMYS1+GcUDOYJ1/NcGfQR5p 3T7Q== X-Gm-Message-State: AE9vXwOiEx+Da54We+8TmZA6r3GfhPn0lwnzylGGLSEyIrk/z+K3RkZ2U0yLHASMPDHWpBjJ4EBGxOoVkadUYQ== X-Received: by 10.129.161.86 with SMTP id y83mr22316055ywg.61.1475011506243; Tue, 27 Sep 2016 14:25:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.24.86 with HTTP; Tue, 27 Sep 2016 14:25:05 -0700 (PDT) In-Reply-To: <02f601d218fe$c27987b0$476c9710$@augustcellars.com> References: <147500296731.4432.6406493584230647663.idtracker@ietfa.amsl.com> <02f601d218fe$c27987b0$476c9710$@augustcellars.com> From: Spencer Dawkins at IETF Date: Tue, 27 Sep 2016 16:25:05 -0500 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=001a114f8d26de8e5f053d83e0e9 Archived-At: Cc: draft-ietf-cose-msg@ietf.org, cose-chairs@ietf.org, cose@ietf.org, The IESG , goran.selander@ericsson.com Subject: Re: [COSE] Spencer Dawkins' No Objection on draft-ietf-cose-msg-18: (with COMMENT) 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, 27 Sep 2016 21:25:09 -0000 --001a114f8d26de8e5f053d83e0e9 Content-Type: text/plain; charset=UTF-8 On Tue, Sep 27, 2016 at 3:35 PM, Jim Schaad wrote: > Yes this is targeted at CoAP. CoAP should provide the needed fragmentation > and we are currently have discussions in the CORE group about the best way > to provide this both on a per message basis and a per fragment basis. Thank you, Jim. Spencer > Jim > > > > -----Original Message----- > > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Spencer Dawkins > > Sent: Tuesday, September 27, 2016 12:03 PM > > To: The IESG > > Cc: cose-chairs@ietf.org; goran.selander@ericsson.com; cose@ietf.org; > draft- > > ietf-cose-msg@ietf.org > > Subject: [COSE] Spencer Dawkins' No Objection on draft-ietf-cose-msg-18: > (with > > COMMENT) > > > > Spencer Dawkins has entered the following ballot position for > > draft-ietf-cose-msg-18: No Objection > > > > When responding, please keep the subject line intact and reply to all > email > > addresses included in the To and CC lines. (Feel free to cut this > introductory > > paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I'm going to be a No Objection for this doc no matter what, so it's safe > to > > answer my question :-) > > > > This is for use with CoAP, right? Would you rely on CoAP for > fragmentation, if > > that's required? > > > > > > _______________________________________________ > > COSE mailing list > > COSE@ietf.org > > https://www.ietf.org/mailman/listinfo/cose > > --001a114f8d26de8e5f053d83e0e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Sep 27, 2016 at 3:35 PM, Jim Schaad <ietf@augustcellars.com= > wrote:
Yes this is target= ed at CoAP.=C2=A0 CoAP should provide the needed fragmentation
and we are currently have discussions in the CORE group about the best way<= br> to provide this both on a per message basis and a per fragment basis.

Thank you, Jim.

Spencer=
=C2=A0
Jim


> -----Original Message-----
> From: COSE [mailto:cose-bounc= es@ietf.org] On Behalf Of Spencer Dawkins
> Sent: Tuesday, September 27, 2016 12:03 PM
> To: The IESG <iesg@ietf.org>= ;
> Cc: cose-chairs@ietf.org; = goran.selander@ericsson.com<= /a>; cose@ietf.org;
draft-
> ietf-cose-msg@ietf.org > Subject: [COSE] Spencer Dawkins' No Objection on draft-ietf-cose-m= sg-18:
(with
> COMMENT)
>
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-cose-msg-18: No Objection
>
> When responding, please keep the subject line intact and reply to all<= br> email
> addresses included in the To and CC lines. (Feel free to cut this
introductory
> paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/dra= ft-ietf-cose-msg/
>
>
>
> ------------------------------------------------------------= ----------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> I'm going to be a No Objection for this doc no matter what, so it&= #39;s safe
to
> answer my question :-)
>
> This is for use with CoAP, right? Would you rely on CoAP for
fragmentation, if
> that's required?
>
>
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose

--001a114f8d26de8e5f053d83e0e9-- From nobody Tue Sep 27 20:39: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 7C9A512B3C0; Tue, 27 Sep 2016 20:39:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147503397650.11759.7571084980083889443.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2016 20:39:36 -0700 Archived-At: Cc: cose-chairs@ietf.org, goran.selander@ericsson.com, cose@ietf.org, draft-ietf-cose-msg@ietf.org Subject: [COSE] Ben Campbell's No Objection on draft-ietf-cose-msg-18: (with COMMENT) 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: Wed, 28 Sep 2016 03:39:36 -0000 Ben Campbell has entered the following ballot position for draft-ietf-cose-msg-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A few minor comments: Substantive: -1.3, definition of "int": Is that really _unsigned_ or negative? Or is it a signed integer than can be negative or non-negative? (contrasting with uint?) (Or is int merely a parent of nint and uint?) -3: What is the scope of uniqueness for map labels? I expected it to be the map, but the text immediately aftewards suggests the scope may be the whole message. Whatever the answer, it would help to be explicit. - Informative References: [I-D.irtf-cfrg-eddsa]: Other algorithm references are normative. Why not this one? Editorial: "Contributing to this Memo" section: Is this intended to stay in the final RFC? If not, it might be worth a note to the RFC editor. -1, first paragraph, last sentence: Comma splice. -1, 2nd paragraph: MAC usually expands to Message Authentication _Code_. -2, 6th paragraph, last sentence: s/method/methods (assuming the following list is a list of methods, and not steps in a method. -3, definition of protected: -4.1, "COSE_Sign_Tagged = #6.991(COSE_Sign) ; Replace 991 with TBD1": Is the comment intended as a note to the RFC editor? If so, it might be helpful to label it as such. -4.3, first bullet: "If multiple items are included, care needs to be taken that data cannot bleed between the items." Is this talking about data framing, or something else? From nobody Tue Sep 27 23:49:56 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 9D26712B069; Tue, 27 Sep 2016 23:49:55 -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.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147504539564.11819.8959916471419931617.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2016 23:49:55 -0700 Archived-At: Cc: cose@ietf.org Subject: [COSE] I-D Action: draft-ietf-cose-msg-19.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: Wed, 28 Sep 2016 06:49:55 -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-19.txt Pages : 118 Date : 2016-09-27 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 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-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-19 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 Tue Sep 27 23:53: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 C007112B2C0 for ; Tue, 27 Sep 2016 23:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.217 X-Spam-Level: X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, 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 zQrTxz_vEsYj for ; Tue, 27 Sep 2016 23:53:06 -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 A345512B069 for ; Tue, 27 Sep 2016 23:53:05 -0700 (PDT) Received: from hebrews (64.134.138.2) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 28 Sep 2016 00:06:19 -0700 From: Jim Schaad To: References: <147504539581.11819.2210757977132864354.idtracker@ietfa.amsl.com> In-Reply-To: <147504539581.11819.2210757977132864354.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2016 23:52:52 -0700 Message-ID: <036b01d21954$f0abbda0$d20338e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQCkqus5CUeIlLNVBG1wBNke4KoceKLpU8TQ X-Originating-IP: [64.134.138.2] Archived-At: Subject: [COSE] FW: New Version Notification for draft-ietf-cose-msg-19.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: Wed, 28 Sep 2016 06:53:08 -0000 This revision deals with the comments in the secdir review. Additional comments have come in since then, hopefully an update and = responses will be tomorrow. Jim > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, September 27, 2016 11:50 PM > To: Jim Schaad > Subject: New Version Notification for draft-ietf-cose-msg-19.txt >=20 >=20 > A new version of I-D, draft-ietf-cose-msg-19.txt has been successfully = submitted > by Jim Schaad and posted to the IETF repository. >=20 > Name: draft-ietf-cose-msg > Revision: 19 > Title: CBOR Object Signing and Encryption (COSE) > Document date: 2016-09-27 > Group: cose > Pages: 118 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-cose-msg-19.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ > Htmlized: https://tools.ietf.org/html/draft-ietf-cose-msg-19 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cose-msg-19 >=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 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 Wed Sep 28 05:39:05 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 3E16812B113; Wed, 28 Sep 2016 05:39:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147506634324.16628.6590617577304586745.idtracker@ietfa.amsl.com> Date: Wed, 28 Sep 2016 05:39:03 -0700 Archived-At: Cc: cose-chairs@ietf.org, goran.selander@ericsson.com, cose@ietf.org, draft-ietf-cose-msg@ietf.org Subject: [COSE] Stephen Farrell's Discuss on draft-ietf-cose-msg-19: (with DISCUSS and COMMENT) 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: Wed, 28 Sep 2016 12:39:03 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-cose-msg-19: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I think this is a fine design and well documented, (though long) and I'm sure we'll clear up the points below quickly enough. Some of them may need some discussion but others are mostly checking. (1) general: I think the inclusion of CDDL is an error here and we'd be better off having someone (if interested) generate the CDDL schema stuff later on when/if CDDL is standardised/stabilised. Including it now creates the potential for breakage unnecessarily IMO. However, the WG did explicitly discuss iirc, so this is just a personal comment that I'm also in the rough on inclusion of CDDL in this spec. (As an example, for someone not familiar with CDDL, the inclusion of fragments interspersed in the text is distracting and potentially puzzling when one gets to the end of section 3.) However, I do think there are places where the CDDL is effectively normative despite what is said in the introduction, the ones I've spotted are below. (Happy to chat about 'em as I may be mistaken.) I also wondered if one could really implement this if all the CDDL was removed from the text, which is what I think would be required if CDDL were really to be informative. Anyway the places I think some more text may be needed are: (1.1) table 2: As-is the value type column seems to me to make CDDL normative. I don't see the natural language version that you said would be normative. (1.2) 4.4, 2nd list point 1: the use of Sig_structure makes the CDDL normative. (Same with the use in 4.5 and Enc_structure in 5.3.) (1.3) 7.1, the key_ops value is only specified in CDDL, in Table 3. (It is well-defined below the table in text though, so this one's borderline.) (1.4) 11.2: it's not clear to me that a reader knows how to handle decoding of the two optional fields at the end (other and SuppPrivInfo) without looking at the CDDL. Can you explain? (That might be just my ignorance of CBOR, but wanted to check.) (2) 3.1, alg: so you're disallowing a setup where the kid alone identifies the key and algorithm to the recipient? That is used in some IETF protocols (OSPF iirc) so rhat's a pity, and will in those (maybe less common) cases consume a few bytes that could otherwise be saved. I think, but am not sure, that the WG already discussed this, but if not, maybe worth a thought? (Or even a 2nd thought:-) And appendix A.1 is really puzzling - as it provides instructions for how to not follow a MUST in the body of the document. (3) 7.1: key_op 8, "derive bits" - I don't think this usage is clear enough, can you say what's meant here? (4) Why not make deterministic ECDSA a MUST? 8.1.1 says: "Applications that specify ECDSA should evaluate the ability to get good random number generation and require deterministic signatures where poor random number generation exists." I don't think that is sufficiently clear, nor realistic, and I don't recall this being discussed on the list (sorry if I'm forgetting) and bad random values are a killer flaw here that has happened in the wild. (5) Table 6, is this 25519 or 448? Where does it say? Sorry if I'm being dumb here, but I don't see where you say which curve is specified, the definition of 'crv' says defined for this alg which I assume means listed in Table 6. (6) section 10: why MUST the kty values be present always? That seems unnecessary in some contexts and I don't get a security reason why it's needed e.g. if there's an alg id somewhere - can you explain? I can see folks omitting this leading to interop problems for not useful reasons. (Same comment applies in other cases where kty is a MUST, e.g. 12.1.2, 12.2.1.) (7) section 11: given that we know people will use human memorable secrets, why have you not defined codepoints for PBES2 (or the more commonly supported?) PBDKF2? I'm fine if there's a reason, or even if it was discussed by the WG, but just wanted to check as I'd worry that folks will use the ones defined here with human memorable secrets no matter what the spec says so giving 'em something more tailored might be better. (OTOH, one could argue that making this apparent might be worse too I guess.) (8) 12.4: Why is no ephemeral-ephemeral (E-E) variant supported? Some protocols will allow for that and it seems wrong to disallow it when it could relatively easily be supported. For some applications where content is dealt with in store-and-forward mode, there may be situations (e.g. provisioning, "introduction") where E-E could be used. As-is, applications wanting that will have to hack the recipient DH-public into a home-grown structure (or use one of the COSE_Key labels from Table 19) and then treat that as ES-DH. That seems likely to lead to non-interop or security errors being made. I'd be fine if you even said how to re-use the structures currently defined for E-E btw and didn't introduce new structures. (9) 16.4: I'm not sure expert review is right here. What if the expert is asked to add SM2/SM4 while there is still no widely available non-Chinese text to describe those? I think the expert ought enforce a "specification required" rule at least and maybe more. (And ought never allow an algorithm with no specification publicly available.) (10) 16.4 (and elsewhere maybe) I think this registry is missing a column - as is being done in the TLS WG, I think there should be a column saying if the IETF is happy enough with an algorithm and that getting a "Y" in that ought require standards action. (Or some similar scheme.) I don't think the standards-track range of codepoints is enough here, e.g. at some time we will want to deprecate things, and at other times we may want to define things for the future on the standards-track but not (yet) recommend their use. The last bullet in 16.11 does help here, but I'd argue that we need to do more to protect the expert (and implementers) from the trickle of vanity/national algorithms/curves that are always being proposed. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 1.4: the 2nd last paragraph is unclear to me. Probably just needs re-phrasing. - 1.5: I'd add a reference to RFC5116. - 3.1, crit: The statement that security libraries or application code can handle this is odd - isn't that an API requirement? (I'm not objecting, but it's odd.) - 3.1, "content type" is the space there intended? If so, maybe add quotes or a comma or something to disambiguate the name and descriptive text? Same for other multi-word names here. - 3.1, "all the keys may need to be checked" - really? Or do you mean all the keys associated with this kid? - 3.1, IV/Partial IV - I think it's an error to define this here. What if some algorithm can't use that kind of (0|partial)^IV but needs something else instead? Shouldn't all mechanism for handling IVs be defined by the algorithm/mode? (This isn't a discuss because I can't think of a good counter example and there'd be other ways around the problem too probably.) - 4.1: signingTime is often needed with signatures. Isn't that common enough to want to define a way to do it, as an option? - 4.1: If I sign with a private key corresponding to a 2047 or 2049 bit RSA public key modulus, then is it clear what to put where in the signature bstr? (Yes, that'd be dumb, but I wonder is what to do well enough defined, as I don't think you can rule it out in all cases.) Since you don't include RSA here I guess it's ok to skip this, but maybe you need to say that such issues need to be handled in the definition of signature algs. - 4.3: "cannot bleed" isn't clear enough maybe, give an example perhaps where the decoder can fail to disambiguate a boundary? 4.4, last para: I disagree that one must (even lowercase must) check the signing identity. That's application behaviour and should be stated here in such concrete terms. At least s/must also/may also want to/ (Note - the above were comments on -18, but also seem to work based on -19. Subsequent comments are on -19.) - 7.1: "starting at the same base IV" - are you missing "and incrementing" or something? Otherwise I think this seems unclear. - 8.2.1: is the phrasing of the 1st para right? would it be better to say that the value of a key for EdDSA MUST NOT be used for ECDH and vice-versa. (Or maybe points instead of keys?) - 8.2.1: you need a reference for batch signing. (Or could it be omitted?) - section 9: I think it'd be good to be clearer about the strength of truncated MAC values. (And I can't recall the right thing to say off the top of my head:-) - 11: RFC2898 is about to be obsoleted by [1]. I suspect it'd be better to refer to the draft as that should be published soon. (Same for RFC3447 btw.) [1] https://datatracker.ietf.org/doc/draft-moriarty-pkcs5-v2dot1/ - 12.4: Why "OKP"? And saying there's no "simple way" to do point validation seems fairly opaque, a reference there or explanatory text would be good. (Ah, it's in section 13, maybe shuffle the text or include a pointer.) Octet key pair doesn't seem like that good a name to me btw. - 12.5: The 1st para seems wrong. (Or at least is unclear to me.) "Encrypted with and " seems ambiguous anyway, does it mean double encryption or two parallel ciphertexts? (I assume the former.) What's the algebraic thing you're trying to explain? It'd be good to provide that for such relatively complex operations I think. Is this what you mean? KW(KDF(DH-shared),CEK) - Table 22: The EC2 or OKP value is fixed per curve and the cryptographic function being performed so seems unnecessary. Do you really need it so? Why? (I'm not buying that some future form of ECC might mean this is needed btw - and codepoints aren't expensive here, right? So other forms of ECC can burn codepoints when that's needed and in the meantime we'd save bytes and complexity.) - Section 15: Do we have any examples of such a profile? I think it'd be great if we did and could add an informative reference here (even if that's to an early I-D). - section 19: I don't get how ECDSA is normative and the cfrg curves are not. Same for RFC6979. Maybe these all could do with checking? (No big deal IMO but maybe worth it.) - Appendices A.1 (as already noted) and A.2 are a puzzle. Why say in the body of the document to do and then an appendix that says how to do ? - Appendix C and the implementation status section: Many thanks - great to see that! (I didn't check 'em though:-) - Thanks also for speedily handling the extensive secdir review. [2] https://www.ietf.org/mail-archive/web/secdir/current/msg06801.html From nobody Wed Sep 28 06:21:05 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 5DB8612B138 for ; Wed, 28 Sep 2016 06:21:04 -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, FREEMAIL_FROM=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 w7iBQrVMRphW for ; Wed, 28 Sep 2016 06:21:00 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d: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 3B1DA12B0D6 for ; Wed, 28 Sep 2016 06:21:00 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id j129so38317849qkd.1 for ; Wed, 28 Sep 2016 06:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=87NRS1EalGbL4q34geG6KVZJFyMazdT8NRImbVUY/A4=; b=puftS+ry08e5ir/u6hNWOEPTKrUdKS3E7uDk9ji61A3XSJDHB/3oPvW7xH0KE0zk1F FdLLL6LLsKR9waB6qPQcOyjkiXS9vS95tqo1FJVJ/ZZQ6Amb9rlDvpnjPyl6W6uUGAXo Sr7pntT34OBEb3rvmDCHRzAvSyGznWdptnkkYm8FuuN4/61umcAKbhY8a17JhlnyY5ZE fS7KzdHCm8lTkdsbxAwxpYp1mhJHyDsGvGrB3EGutf9cLvh8PFsZ2BCokJFblyTnXZcm uzOVs6RlPGydX8oLtvew4qMdo98Z2XldslOztRLzrJJMlFpmTi76iJK+Ifod3IP8tjlB OFVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=87NRS1EalGbL4q34geG6KVZJFyMazdT8NRImbVUY/A4=; b=ITeJKdZaXX0kZBlJruTf3DtcKgXr7NMJrX4vThJ80lcMXzKsGrmW7akdRdB7aEOvfz QcTabYr0YlcCNkb3VMzRt/Pli7CZPXmxi0C06/bcwb1aq0+6bY6kPcUJ7FFCGf6dcK6R JrZ953tg+LkgBOHNlY3uEBIG5SocKx/Ufn1lzkxcEvtLIbwv920ujFc70KR7rQqFlCBO G77XyH/kPgQFEBtQFmXCvhzFZQ9JqsR9eGYRzi6hawDFCW+tGPZlDqMZjxZChIe0+x3H N2NR9lfo2ZrTF1mwQcccFcouQDIBK/JQKB52PcMi6w1oVf3+l68qFNxbMSf7kAB82pCE yBvw== X-Gm-Message-State: AA6/9RkA76bplMnZKbUVVRC8i4clBDmC1eaJYhkkE86aF9+FLng/o9XhUhcU+khOgavDGQ== X-Received: by 10.55.106.2 with SMTP id f2mr31944024qkc.124.1475068859416; Wed, 28 Sep 2016 06:20:59 -0700 (PDT) Received: from [192.168.1.8] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id r2sm3823124qtd.46.2016.09.28.06.20.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 28 Sep 2016 06:20:58 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (13G36) In-Reply-To: <036b01d21954$f0abbda0$d20338e0$@augustcellars.com> Date: Wed, 28 Sep 2016 09:20:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147504539581.11819.2210757977132864354.idtracker@ietfa.amsl.com> <036b01d21954$f0abbda0$d20338e0$@augustcellars.com> To: Jim Schaad Archived-At: Cc: cose@ietf.org Subject: Re: [COSE] FW: New Version Notification for draft-ietf-cose-msg-19.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: Wed, 28 Sep 2016 13:21:04 -0000 Thank you, Jim for staying on top of the responses. =20 Kathleen=20 Please excuse typos, sent from handheld device=20 > On Sep 28, 2016, at 2:52 AM, Jim Schaad wrote: >=20 > This revision deals with the comments in the secdir review. >=20 > Additional comments have come in since then, hopefully an update and respo= nses will be tomorrow. >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Tuesday, September 27, 2016 11:50 PM >> To: Jim Schaad >> Subject: New Version Notification for draft-ietf-cose-msg-19.txt >>=20 >>=20 >> A new version of I-D, draft-ietf-cose-msg-19.txt has been successfully su= bmitted >> by Jim Schaad and posted to the IETF repository. >>=20 >> Name: draft-ietf-cose-msg >> Revision: 19 >> Title: CBOR Object Signing and Encryption (COSE) >> Document date: 2016-09-27 >> Group: cose >> Pages: 118 >> URL: https://www.ietf.org/internet-drafts/draft-ietf-cose-msg-= 19.txt >> Status: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ >> Htmlized: https://tools.ietf.org/html/draft-ietf-cose-msg-19 >> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cose-msg-1= 9 >>=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 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 submiss= ion >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >=20 >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Wed Sep 28 15:20:46 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 24BEC12B00D; Wed, 28 Sep 2016 15:20:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147510124114.16603.14442590762723238530.idtracker@ietfa.amsl.com> Date: Wed, 28 Sep 2016 15:20:41 -0700 Archived-At: Cc: cose-chairs@ietf.org, goran.selander@ericsson.com, cose@ietf.org, draft-ietf-cose-msg@ietf.org Subject: [COSE] Alexey Melnikov's No Objection on draft-ietf-cose-msg-19: (with COMMENT) 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: Wed, 28 Sep 2016 22:20:41 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-cose-msg-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Stephen, I've seen several documents recently that "reference CDDL informatively" and I don't believe that. So the whole situation with CDDL makes me rather unhappy. Comments on the document: This is a well written document, despite its length. Thank you for that. Some specific comments: I am pretty sure that the CDDL reference is normative. On page 13: media type syntax reference is outdated, you should reference RFC 6838, Section 4.2 has relevant ABNF. In Media type registrations: Applications that use this media type: To be identified This answer is not useful, please specify types of applications that will be using these media types. Something along the lines of what you specified in the Introduction. From nobody Wed Sep 28 22:39:45 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 1E7D512B05B; Wed, 28 Sep 2016 22:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.217 X-Spam-Level: X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, 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 4eZPr9PXqbRz; Wed, 28 Sep 2016 22:39:41 -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 5293A12B057; Wed, 28 Sep 2016 22:39:41 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 28 Sep 2016 22:52:59 -0700 From: Jim Schaad To: 'Ben Campbell' , 'The IESG' References: <147503397650.11759.7571084980083889443.idtracker@ietfa.amsl.com> In-Reply-To: <147503397650.11759.7571084980083889443.idtracker@ietfa.amsl.com> Date: Wed, 28 Sep 2016 22:39:31 -0700 Message-ID: <049501d21a13$dcaa3a10$95feae30$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQI72LF3s8HkLwgD0/KHp+5vvh02RJ+8YPHA X-Originating-IP: [192.168.1.152] Archived-At: Cc: cose-chairs@ietf.org, cose@ietf.org, draft-ietf-cose-msg@ietf.org, goran.selander@ericsson.com Subject: Re: [COSE] Ben Campbell's No Objection on draft-ietf-cose-msg-18: (with COMMENT) 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, 29 Sep 2016 05:39:44 -0000 Changes are in https://github.com/cose-wg/cose-spec/pull/181 > -----Original Message----- > From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Ben Campbell > Sent: Tuesday, September 27, 2016 8:40 PM > To: The IESG > Cc: cose-chairs@ietf.org; goran.selander@ericsson.com; cose@ietf.org; draft- > ietf-cose-msg@ietf.org > Subject: [COSE] Ben Campbell's No Objection on draft-ietf-cose-msg-18: (with > COMMENT) > > Ben Campbell has entered the following ballot position for > draft-ietf-cose-msg-18: No Objection > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this introductory > paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > A few minor comments: > > Substantive: > > -1.3, definition of "int": Is that really _unsigned_ or negative? Or is it a signed > integer than can be negative or non-negative? (contrasting with uint?) (Or is int > merely a parent of nint and uint?) Using the terminology of CDDL, this is really unsigned or negative. Specifically, it would be the union of uint (unsigned - 0 and above) and nint (negative integer strictly less than 0). Both of these types have different major types so they are coded differently. > > -3: What is the scope of uniqueness for map labels? I expected it to be the map, > but the text immediately aftewards suggests the scope may be the whole > message. Whatever the answer, it would help to be explicit. I kind of thought that it was sufficiently explicit. Does it work better for you if the first sentence reads: If a label is used in one of the maps, it MUST appear only once in that map and it MUST NOT appear in the other map. Then leave the rest of the text in the paragraph alone. > > - Informative References: [I-D.irtf-cfrg-eddsa]: Other algorithm references are > normative. Why not this one? I plead the 5th. It would be because I pasted it in the wrong place and missed the fact. I have been acting as if this was a normative reference. Kathleen, is there a problem if I just move this reference? > > Editorial: > > "Contributing to this Memo" section: Is this intended to stay in the final RFC? If > not, it might be worth a note to the RFC editor. The not already exists in the XML. > > -1, first paragraph, last sentence: Comma splice. Changed in response to the Gen-Art review already. > > -1, 2nd paragraph: MAC usually expands to Message Authentication _Code_. Yeah, Changed in response to the Gen-Art review already > > -2, 6th paragraph, last sentence: s/method/methods (assuming the following > list is a list of methods, and not steps in a method. Should be plural - changed > > -3, definition of protected: Did you lose some text at this point? > > -4.1, "COSE_Sign_Tagged = #6.991(COSE_Sign) ; Replace 991 with TBD1": Is the > comment intended as a note to the RFC editor? If so, it might be helpful to label > it as such. Added as a note to the XML > > -4.3, first bullet: "If multiple items are included, care needs to be taken that data > cannot bleed between the items." > Is this talking about data framing, or something else? That is probably not the term that I would use for this, but it is similar. The requirement is to make sure that data from one item is separated from another item so that when the hash string is constructed the same hash string cannot be constructed for two different pairs of items. Jim > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Thu Sep 29 04:55:39 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 17CDB12B0A8; Thu, 29 Sep 2016 04:55:39 -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, FREEMAIL_FROM=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 nwGhdwerQije; Thu, 29 Sep 2016 04:55:34 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 6B75812B427; Thu, 29 Sep 2016 04:55:34 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id 30so10201586qth.2; Thu, 29 Sep 2016 04:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VNp2+QMQsdcg8Hrzam/pLRIffyG/l/EiUR3DwDT12Rg=; b=zLr292HFcw4RLghcqDcoftc8puCu1pkNdsLonee6IX7AnLNZTfdM/K8o5jfRfSTEOp BVjQhasto2st8Y7o+rYozp1EkSS7e8LrDWs0OZ5UUEANCUXxwaamyaDIp7Oa8ZX2TrMb WvAmPqYt6BN4xajmrfNt5HvyGMdDFGoFD909n7zh+smn7+Z+EY/O+aUIvZ5YS2uDyLxK R4zPndDUk5rEpHY4ULHi0s94eTYF6TrUitoEKiVLehHZQh/jcDhaXf9kFnGoNLTFXkaF 1TfaQX4PsCRcJSic1EpQ6EfiCysIydEBiY/Dk6Tuu9NSG5VO2ONQZf/YznsLihRyHLUx LtFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VNp2+QMQsdcg8Hrzam/pLRIffyG/l/EiUR3DwDT12Rg=; b=K3462iwOYffajF+LwZDr/BbTOUpr9OseuJDHqYzTLe/bSkRaCfRjOTerF4UBLgtr6z EzPUJMceGBG5mfHYt6SevNm7QtE4r2bGTmkOdIp2iJk3vMWfYT1o5OJ/KZNnLBb9fCQY MuoRhhnvQ1v/S8YxSCgoVqY2PS89wIxe2PbEozk3gtGeF05noi179jHBZPq76giUenF0 PUuMeO9KjXh4YjsZvg9joYPmR3TfGK27xDtnh7FB8gYylsthboBbzaEaL179vx5uHnl8 ZJKgT7FN1mBRBPmZMmzwNM2F3yXjYkdDM6qI/xHS3FSFtqhJLa/WJB39M7hr5HKgB7yV HwvQ== X-Gm-Message-State: AA6/9RlxcJCliTiGd2g8WRXzqAfRzOSsYbe6a267W0b5zsKBWd6e9reeVbw0PvnSMFSerw== X-Received: by 10.200.36.66 with SMTP id d2mr1087864qtd.34.1475150133628; Thu, 29 Sep 2016 04:55:33 -0700 (PDT) Received: from [192.168.1.8] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id a192sm6393311qkc.26.2016.09.29.04.55.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 29 Sep 2016 04:55:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (13G36) In-Reply-To: <147510124114.16603.14442590762723238530.idtracker@ietfa.amsl.com> Date: Thu, 29 Sep 2016 07:55:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147510124114.16603.14442590762723238530.idtracker@ietfa.amsl.com> To: Alexey Melnikov Archived-At: Cc: draft-ietf-cose-msg@ietf.org, cose-chairs@ietf.org, cose@ietf.org, The IESG , goran.selander@ericsson.com Subject: Re: [COSE] Alexey Melnikov's No Objection on draft-ietf-cose-msg-19: (with COMMENT) 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, 29 Sep 2016 11:55:39 -0000 We've gotten enough questions on this that I'm thinking the best course of a= ction is to make a change and put it back through last call. The change cou= ld be to make the reference normative and wait on the publication of CDDL (i= n the editors queue) or to fully specify the format in this draft. I'll wait until a little before 10 in hopes we get some more discussion. Thank you, Kathleen=20 Please excuse typos, sent from handheld device=20 > On Sep 28, 2016, at 6:20 PM, Alexey Melnikov wrot= e: >=20 > Alexey Melnikov has entered the following ballot position for > draft-ietf-cose-msg-19: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Stephen, I've seen several documents recently that "reference CDDL > informatively" and I don't believe that. So the whole situation with CDDL > makes me rather unhappy. >=20 > Comments on the document: >=20 > This is a well written document, despite its length. Thank you for that. >=20 > Some specific comments: >=20 > I am pretty sure that the CDDL reference is normative. >=20 > On page 13: media type syntax reference is outdated, you should reference > RFC 6838, Section 4.2 has relevant ABNF. >=20 > In Media type registrations: >=20 > Applications that use this media type: To be identified >=20 > This answer is not useful, please specify types of applications that will > be using these media types. Something along the lines of what you > specified in the Introduction. >=20 >=20 From nobody Thu Sep 29 06:50: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 7729812B12B; Thu, 29 Sep 2016 06:50:24 -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, FREEMAIL_FROM=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 LoupsfLv5XOg; Thu, 29 Sep 2016 06:50:22 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::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 8D0DF12B115; Thu, 29 Sep 2016 06:50:21 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id v205so75086915vke.1; Thu, 29 Sep 2016 06:50:21 -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:content-transfer-encoding; bh=L8vgVZMIjDWJY5bQA65o9diIkcG3Ws2ODApvy95YdDA=; b=o4Yde1/gJlhJuubxFMd2YUTwgqVWJES5tqFYnLPiZA0LxrLbKJz1OVS1rR/4yKii06 p95sBIA6hWxqBd/jCy+jIIJtfHyuTff3mcH14cn6Y2FAiZi7NghrvJT6/tW+efFH1IbP 7iBtPcA5SVl07yHRapkRjKjSxaXAasncHFbMi0q7be7yj5jHUFe78cSADHS3ZdMdwRZX 05qqzgiX3EZKo6fC614eiMLG92zS8UmAUUyKZHwZApKxLH6r2S7SC0bMjR5XsRr4DuRg Z3m4bYegKJjA4LDSaw8QoFEpgctA1Z7QAQkLJx0nkf3BmnGagZoEuH6gunwil3VlUO04 8g/g== 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:content-transfer-encoding; bh=L8vgVZMIjDWJY5bQA65o9diIkcG3Ws2ODApvy95YdDA=; b=HUJ8D/jD0Hc5GoOnG/xQxCOwmg/V0V7mQmEIr09a5nz/wIXbVJSznU2GmH6eky4GJZ y7H9WFPICNJ6/vb6UpXm/KncoirCQUCX5PlTScFKPC/7nml/WH/5YV3KMUHSR47Gcqi+ +OgxGR+w+YnAUXDuDcpqytNp5cSS1V4mMKZ8rmD/Y4M5c7G0s88dv8kuvubquNiJlyYc OPXIFXmvbbA8l019qKo3BIGB0eOSshWo4n55LlI/kQPxuDlqPhL3LK9MvHPWWaWScfU3 9TbXzZM/P0gQWx1lXUbHANhj/8iCsQgdgZX/5dRY4DR53ba/iNZ7dLqWEX7DqN/1iAv7 UozA== X-Gm-Message-State: AA6/9RkQhHAdpIL+oj+ZQlYYT2xMAaH4oK54ZdEyzPav3tXKS6tQ7WgiQ0pMCJB99BnFoSWgO8nwkLjx5lV3Rg== X-Received: by 10.31.12.84 with SMTP id 81mr1037136vkm.152.1475157020692; Thu, 29 Sep 2016 06:50:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.8 with HTTP; Thu, 29 Sep 2016 06:50:20 -0700 (PDT) In-Reply-To: References: <147510124114.16603.14442590762723238530.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Thu, 29 Sep 2016 09:50:20 -0400 Message-ID: To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-cose-msg@ietf.org, cose-chairs@ietf.org, "cose@ietf.org" , The IESG , =?UTF-8?Q?G=C3=B6ran_Selander?= Subject: Re: [COSE] Alexey Melnikov's No Objection on draft-ietf-cose-msg-19: (with COMMENT) 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, 29 Sep 2016 13:50:24 -0000 I'll leave it on this weeks call since this is the only outstanding issue. We can sort through what to do with it so we don't have to have it on a telecjat again. Thanks, Kathleen On Thu, Sep 29, 2016 at 7:55 AM, wrote: > We've gotten enough questions on this that I'm thinking the best course o= f action is to make a change and put it back through last call. The change= could be to make the reference normative and wait on the publication of CD= DL (in the editors queue) or to fully specify the format in this draft. > > I'll wait until a little before 10 in hopes we get some more discussion. > > Thank you, > Kathleen > > Please excuse typos, sent from handheld device > >> On Sep 28, 2016, at 6:20 PM, Alexey Melnikov wr= ote: >> >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-cose-msg-19: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Stephen, I've seen several documents recently that "reference CDDL >> informatively" and I don't believe that. So the whole situation with CDD= L >> makes me rather unhappy. >> >> Comments on the document: >> >> This is a well written document, despite its length. Thank you for that. >> >> Some specific comments: >> >> I am pretty sure that the CDDL reference is normative. >> >> On page 13: media type syntax reference is outdated, you should referenc= e >> RFC 6838, Section 4.2 has relevant ABNF. >> >> In Media type registrations: >> >> Applications that use this media type: To be identified >> >> This answer is not useful, please specify types of applications that wil= l >> be using these media types. Something along the lines of what you >> specified in the Introduction. >> >> --=20 Best regards, Kathleen From nobody Thu Sep 29 17:07:23 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 7BDF012B0AB; Thu, 29 Sep 2016 17:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sRTiSHBohsm; Thu, 29 Sep 2016 17:07:13 -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 0B62812B13D; Thu, 29 Sep 2016 17:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id u8U06wvq015128; Fri, 30 Sep 2016 02:06:58 +0200 (CEST) Received: from nar-4.local (unknown [IPv6:2001:13c7:7003:4000:5520:99bf:7034:5716]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3slWvh3Y6Pz3DKt; Fri, 30 Sep 2016 02:06:56 +0200 (CEST) Message-ID: <57EDAC9F.9090303@tzi.org> Date: Thu, 29 Sep 2016 18:06:55 -0600 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Jim Schaad References: <147503397650.11759.7571084980083889443.idtracker@ietfa.amsl.com> <049501d21a13$dcaa3a10$95feae30$@augustcellars.com> In-Reply-To: <049501d21a13$dcaa3a10$95feae30$@augustcellars.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: 'Ben Campbell' , cose-chairs@ietf.org, 'The IESG' , draft-ietf-cose-msg@ietf.org, goran.selander@ericsson.com, cose@ietf.org Subject: Re: [COSE] Ben Campbell's No Objection on draft-ietf-cose-msg-18: (with COMMENT) 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: Fri, 30 Sep 2016 00:07:15 -0000 Jim Schaad wrote: > Using the terminology of CDDL, this is really unsigned or negative. (This is actually CBOR terminology that CDDL just inherits. These terms would be in use even without using CDDL.) > Specifically, it would be the union of uint (unsigned - 0 and above) and > nint (negative integer strictly less than 0). Both of these types have > different major types so they are coded differently. Exactly. Grüße, Carsten (CBOR background: unsigned numbers are much more frequent in constrained environments than signed ones, so they are major type 0. Signed numbers are coded similar to the way they are in protobuf, except that we got rid of the shifting to put the sign bit somewhere and instead just added major type 1 to indicate a negative. So we have unsigned (0..) and negative (..-1) as separate major types.)