From nobody Tue Jun 2 14:36:58 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3311A92BA for ; Tue, 2 Jun 2015 14:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 z-58M0kK9LMw for ; Tue, 2 Jun 2015 14:36:44 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C25821A90AD for ; Tue, 2 Jun 2015 14:36:44 -0700 (PDT) Received: from hebrews (unknown [50.38.88.51]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 26CF438E6A for ; Tue, 2 Jun 2015 14:36:44 -0700 (PDT) From: "Jim Schaad" To: Date: Tue, 2 Jun 2015 14:36:47 -0700 Message-ID: <007d01d09d7c$3b318130$b1948390$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdCdewpzQYg4yg7tSHaueHe179IkPA== Content-Language: en-us Archived-At: Subject: [Cose] Updated Editors Draft X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 21:36:46 -0000 I have pushed up an update to my COSE draft which has several changes in it. * I have moved to using maps at the top level * I have starting building the tables of keys, along with IANA considerations, that are using integers rather than strings * I have updated the examples to match Please look at the tables that I have started creating along with the IANA considerations and provide input. https://cose-wg.github.io/cose-spec/ jim From nobody Wed Jun 3 17:43:24 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2331A8A3A; Wed, 3 Jun 2015 10:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 0u1ty-H1lqos; Wed, 3 Jun 2015 10:36:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2301A9073; Wed, 3 Jun 2015 10:36:58 -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.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150603173658.17642.80056.idtracker@ietfa.amsl.com> Date: Wed, 03 Jun 2015 10:36:58 -0700 Archived-At: X-Mailman-Approved-At: Wed, 03 Jun 2015 17:43:23 -0700 Cc: cose WG Subject: [Cose] WG Action: Formed CBOR Object Signing and Encryption (cose) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 17:37:01 -0000 A new IETF working group has been formed in the Security Area. For additional information please contact the Area Directors or the WG Chairs. CBOR Object Signing and Encryption (cose) ------------------------------------------------ Current Status: Proposed WG Chairs: Justin Richer Kepeng Li Assigned Area Director: Kathleen Moriarty Mailing list Address: cose@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cose Archive: http://www.ietf.org/mail-archive/web/cose/ Charter: Concise Binary Object Representation (CBOR, RFC 7049) is a concise binary format for the serialization of data structured to an extended version of the JSON data model. COSE seeks to create CBOR-based object signing and encryption formats. One motivation for COSE was to reuse functionality from the JOSE working group using the CBOR data representation as it is more amenable to constrained nodes and constrained node networks (RFC 7228). The JOSE working group recently completed producing representations for cryptographic keys, message authentication (MACs), encryption, and digital signatures, using JSON representation. The resulting formats will not be cryptographically convertible from or to JOSE formats. This lack of a need for bit-for-bit compatibility will enable some simplification in the adaptation process. Criteria that should be considered in the decision making process, changing from JSON to CBOR encoding include: o Maintain the current JOSE paradigms and formatting where feasible. o Minimize message size, code size, and computational complexity to suit constrained environments, where this is expected to be used. o Improve security o Provide new functionality for additional use cases that were not required for JOSE. Key management and binding of keys to identities are out of scope for the working group. The COSE WG will not innovate in terms of cryptography. The specification of algorithms in COSE is limited to those in RFCs or active IETF WG documents. The working group will coordinate its progress with the ACE, DICE and CORE working groups to ensure that we are fulfilling the needs of these constituencies to the extent relevant to their work. Other groups may be added to this list as the set of use cases is expanded. The WG will have two deliverables: 1. A standards-track specification covering the same cryptographic formats from JOSE, with optimizations for constrained device processing, expressed in CBOR; 2. Registration for algorithms (such as AES-CCM-8) that are appropriate for constrained environments. The Working Group will use a wiki to track desired use cases for its work, but does not intend to publish this as an RFC. Milestones: Jun 2015 - Submit COSE specification as a WG item Jun 2015 - Submit COSE constrained-appropriate algorithms as a WG item Jan 2016 - Submit COSE specification to the IESG, for publication as a Proposed Standard Jan 2016 - Submit COSE constrained-appropriate algorithms to the IESG, for publication as a Proposed Standard From nobody Thu Jun 4 09:35:04 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAAF1A9040 for ; Thu, 4 Jun 2015 09:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 2rebGUtE3Jwd for ; Thu, 4 Jun 2015 09:35:01 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42E2E1B346C for ; Thu, 4 Jun 2015 09:34:38 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id F1747817F5 for ; Thu, 4 Jun 2015 19:34:35 +0300 (EEST) Date: Thu, 4 Jun 2015 19:34:35 +0300 From: Ilari Liusvaara To: cose@ietf.org Message-ID: <20150604163435.GA19933@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Subject: [Cose] Comments on draft-schaad-cose-latest (2nd June 2015) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 16:35:04 -0000 I read the spec, and here are some comments (hope I am not too far in the weeds): Section 1.1: "Switch from using a map to using an array at the message level. While this change means that it is no longer possible to add new named parameters to the top level message, it also means that there is not a need to define how older implementations are defined to behave when new fields are present. Most of the reasons that a new field would need to be defined are adequately addressed by defining a new parameter instead." Wasn't top-level message converted back to a map? Section 1.2: "The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119]." There's also "NOT RECOMMENDED" (synonym of "SHOULD NOT")? :-) Section 1.3: "There currently is no standard CBOR grammar available for use by specifications. In this document, we use the grammar defined in the CBOR data definition language (CDDL) [I-D.greevenbosch-appsawg-cbor-cddl]." If anything like milestones are to be met, relying on this for final document not likely to be a good idea. But it is fine for discussion. Some options for later: - Defining what is needed. - Lots of english prose. :-) Section 2: "Implementations SHOULD be prepared to find an integer in the location which does not correspond to the values 0 to 2. If this is found then the client MUST stop attempting to parse the structure and fail. Clients need to recognize that the set of values could be extended at a later date, but should not provide a security service based on guesses of what is there." Does this refer to values of key msg_type? If so, aren't the values 1-3, not 0-2? Section 3: "Both buckets are implemented as CBOR maps. The maps can be keyed by signed integers, unsigned integers and strings. The signed and unsigned integers are used for compactness of encoding." Nit: The term used by CBOR itself seems to "negative integer". Section 3.1: "TODO: Do we need to repeat definitions for all or just for some and refer to the JOSE documents?" At least noting the rules for determining type of element each thing should have, similarly as those are defined in section 7 for keys. Section 4: "At least one of protected and unprotected MUST be present." Why is this requirement there (there may be good reasons, seems to come from JOSE)? "For body_protected and sign_protected, if the fields are not present in their corresponding maps, an bstr of length zero should be used." Should? The encoding of this is interop-critical. Also, why not use NULL for absent field here? Section 5: "One of the byproducts of using the same technique for encrypting and encoding both the content and the keys using the various key management techniques, is a requirement that all of the key management techniques use an Authenticated Encryption (AE) algorithm. (For the purpose of this document we use a slightly loose definition of AE algorithms.) When encrypting the plain text, it is normal to use an Authenticated Encryption with Additional Data (AEAD) algorithm. For key management, either AE or AEAD algorithms can be used. See Appendix A for more details about the different types of algorithms." I can't parse this. What this seems to be saying that if performing is: - If encrypting plaintext, encryption has to be AEAD - If encrypting keys, the encryption can either be AE or AEAD? "protected contains the information about the plain text or encryption process that is to be integrity protected. The field is encoded in CBOR as a ‘bstr’ if present and the value ‘nil’ if there is no data." Is that 'nil' leftover from using arrays? Should it be that the member is absent if empty? Also nit: The CBOR value seems to be named "null". "iv contains the initialization vector (IV), or it’s equivalent, if one is needed by the encryption algorithm. If there is no IV, then the value ‘nil’ is used." Should be absent if IV is not needed? "aad contains additional authenticated data (aad) supplied by the application. This field contains information about the plain text data that is authenticated, but not encrypted. If the application does not provide this data, the value ‘nil’ is used." Should be absent if no aad? "cipherText contains the encrypted plain text. If the cipherText is to be transported independently of the control information about the encryption process (i.e. detached content) then the value ‘nil’ is encoded here." Should be absent if no ciphertext? "A ‘nil’ value if there are no recipients." Should be absent if no recipients? Section 5.1.1: "The ‘protected’, ‘iv’, ‘aad’, ‘ciphertext’ and ‘recipients’ fields MUST be nil." Should be absent instead? Section 5.1.2: "The ‘protected’, ‘aad’, and ‘recipients’ fields MUST be nil." Should be absent instead? Section 5.1.3: "The ‘protected’, ‘aad’, and ‘iv’ fields all use the ‘nil’ value." Sould be absent instead? Section 5.1.4: "The ‘protected’, ‘aad’, and ‘iv’ fields all use the ‘nil’ value." Should be absent instead? Also, no note of ciphertext field. Should be absent? It seems like presence or absence of ciphertext tells apart DKA (5.1.4) and KAwKW (5.1.5). Section 5.1.5: "The ‘protected’, ‘aad’, and ‘iv’ fields all use the ‘nil’ value." Should be absent instead? "At a minimum, the ‘unprotected’ field SHOULD contain the ‘alg’ parameter, a parameter identifying the recipient asymmetric key, and a parameter with the sender’s asymmetric public key." Parameter with sender’s asymmetric public key? Is that epk? Or something else? Or epk or something else depending on situation? Section 5.2: "1. If there is protected data, CBOR encode the map to a byte string and place in the protected field of the Enc_structure and the COSE_Encrypt structure." Shouldn't this be copy from message, since the field is already byte string there? Also, should this be null if no protected field? "2. Copy the ‘aad’ field from the COSE_Encrypt structure to the Enc_Structure." Should this be null if no aad field? Section 5.3: "1. Verify that the ‘protected’ field is empty. 2. Verify that the ‘aad’ field is empty." Empty means absent? Section 6: "At least one of protected and unprotected MUST be present." Why is this requirement (might be good reasons, seems to come from JOSE)? "1. Create a MAC_structure and copy the protected and payload elements from the COSE_mac structure." The protected is written as null if absent? Section 7: "The same fields defined in [RFC7517] are used here with the following changes in rules:" The formatting of block below this looks screwed. Section 9.2: This section looks empty (no text, no subsections)? Section 9.3: "NOTE: Need to review the range assignments. It does not necessarily make sense as specification required uses 1 byte positive integers and 2 byte strings. ## COSE Header Algorithm Key Table" There should be section break here? Section C: The examples could use some indentation to make easier to read? Section C.6: There are some null values in the dump (key 6). Are those supposed to be signatures? Section E: "jwk" and "kid" might need integers? Section G: Some of these could use integers? Section H: - Since kty is mandatory, it should have integer? - use and key_ops could have integers as values? - important key parameters could have integer values? - what are 'r' and 't' for RSA? And is 'dp' missing for RSA? -Ilari From nobody Thu Jun 4 17:32:36 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2834C1ACDD1 for ; Thu, 4 Jun 2015 17:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 o-j9oH-COOQV for ; Thu, 4 Jun 2015 17:32:31 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 249011ACDD0 for ; Thu, 4 Jun 2015 17:32:30 -0700 (PDT) Received: from hebrews (unknown [50.109.244.255]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 2B80B2CA3D; Thu, 4 Jun 2015 17:32:28 -0700 (PDT) From: "Jim Schaad" To: "'Ilari Liusvaara'" , References: <20150604163435.GA19933@LK-Perkele-VII> In-Reply-To: <20150604163435.GA19933@LK-Perkele-VII> Date: Thu, 4 Jun 2015 17:32:31 -0700 Message-ID: <003d01d09f27$1e1e0850$5a5a18f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQGQD/YfkP5v8dCXigsYGpwmf5tpTp4dt/PA Archived-At: Subject: Re: [Cose] Comments on draft-schaad-cose-latest (2nd June 2015) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 00:32:34 -0000 > -----Original Message----- > From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Ilari Liusvaara > Sent: Thursday, June 04, 2015 9:35 AM > To: cose@ietf.org > Subject: [Cose] Comments on draft-schaad-cose-latest (2nd June 2015) >=20 > I read the spec, and here are some comments (hope I am not too far in = the > weeds): >=20 >=20 > Section 1.1: >=20 > "Switch from using a map to using an array at the message level. > While this change means that it is no longer possible to add new named > parameters to the top level message, it also means that there is not a = need to > define how older implementations are defined to behave when new fields = are > present. Most of the reasons that a new field would need to be defined = are > adequately addressed by defining a new parameter instead." >=20 > Wasn't top-level message converted back to a map? Yes it was, I just missed this place. >=20 >=20 > Section 1.2: >=20 > "The key words =E2=80=9CMUST=E2=80=9D, =E2=80=9CMUST NOT=E2=80=9D, = =E2=80=9CREQUIRED=E2=80=9D, =E2=80=9CSHALL=E2=80=9D, =E2=80=9CSHALL = NOT=E2=80=9D, > =E2=80=9CSHOULD=E2=80=9D, =E2=80=9CSHOULD NOT=E2=80=9D, = =E2=80=9CRECOMMENDED=E2=80=9D, =E2=80=9CMAY=E2=80=9D, and = =E2=80=9COPTIONAL=E2=80=9D in > this document are to be interpreted as described in [RFC2119]." >=20 > There's also "NOT RECOMMENDED" (synonym of "SHOULD NOT")? :-) I have never made sure the list was exhaustive. I have just copied this = text forward. I can add it without problems. >=20 > Section 1.3: >=20 > "There currently is no standard CBOR grammar available for use by > specifications. In this document, we use the grammar defined in the = CBOR data > definition language (CDDL) [I-D.greevenbosch-appsawg-cbor-cddl]." >=20 > If anything like milestones are to be met, relying on this for final = document not > likely to be a good idea. But it is fine for discussion. >=20 > Some options for later: > - Defining what is needed. > - Lots of english prose. :-) Yes, this is likely to become informational at some point in the future. = =20 >=20 >=20 > Section 2: >=20 > "Implementations SHOULD be prepared to find an integer in the location = which > does not correspond to the values 0 to 2. If this is found then the = client MUST > stop attempting to parse the structure and fail. > Clients need to recognize that the set of values could be extended at = a later > date, but should not provide a security service based on guesses of = what is > there." >=20 > Does this refer to values of key msg_type? If so, aren't the values = 1-3, not 0-2? Good catch - updated. >=20 > Section 3: >=20 > "Both buckets are implemented as CBOR maps. The maps can be keyed by > signed integers, unsigned integers and strings. The signed and = unsigned integers > are used for compactness of encoding." >=20 > Nit: The term used by CBOR itself seems to "negative integer". Make sense as +9 is a "signed" number. >=20 > Section 3.1: >=20 > "TODO: Do we need to repeat definitions for all or just for some and = refer to the > JOSE documents?" >=20 > At least noting the rules for determining type of element each thing = should have, > similarly as those are defined in section 7 for keys. Yes - I could just reference the table in the appendix (or move that = table forward) and that would take care of it. However there has been = some push to not rely on the JOSE documents for this type of detail. >=20 > Section 4: >=20 > "At least one of protected and unprotected MUST be present." >=20 > Why is this requirement there (there may be good reasons, seems to = come from > JOSE)? This goes back to the missing text/changed text in section 3. The = algorithm identification header field is going to be required. It this = needs to have someplace to be placed and that is one of these two = fields. >=20 > "For body_protected and sign_protected, if the fields are not present = in their > corresponding maps, an bstr of length zero should be used." >=20 > Should? The encoding of this is interop-critical. Also, why not use = NULL for > absent field here? This is a lower case should and does have the same 2119 language meaning = (see the text in 1.1 about natural language). However 'is' will work = just as well. I could just as easily use NULL, but there is no size or conception = difference. The change from NULL to an empty bstr came about from the = idea at one point during using arrays that it might be easier to do the = parsing if the empty binary string was used instead. It might also make = checking of types easier. This change got copied down into the = structure to be signed as it made the code easier (just copy the item). = As I said, I am not wedded to either way. >=20 > Section 5: >=20 > "One of the byproducts of using the same technique for encrypting and = encoding > both the content and the keys using the various key management = techniques, is > a requirement that all of the key management techniques use an = Authenticated > Encryption (AE) algorithm. (For the purpose of this document we use a = slightly > loose definition of AE > algorithms.) When encrypting the plain text, it is normal to use an = Authenticated > Encryption with Additional Data (AEAD) algorithm. For key management, = either > AE or AEAD algorithms can be used. See Appendix A for more details = about the > different types of algorithms." >=20 > I can't parse this. >=20 > What this seems to be saying that if performing is: > - If encrypting plaintext, encryption has to be AEAD > - If encrypting keys, the encryption can either be AE or AEAD? >=20 > "protected contains the information about the plain text or encryption = process > that is to be integrity protected. The field is encoded in CBOR as a = =E2=80=98bstr=E2=80=99 if > present and the value =E2=80=98nil=E2=80=99 if there is no data." >=20 > Is that 'nil' leftover from using arrays? Should it be that the member = is absent if > empty? Yes it is. I did not make a hard pass over the document looking for all = of the changes that needed to be made for killing arrays. >=20 > Also nit: The CBOR value seems to be named "null". >=20 > "iv contains the initialization vector (IV), or it=E2=80=99s = equivalent, if one is needed by > the encryption algorithm. If there is no IV, then the value = =E2=80=98nil=E2=80=99 is used." >=20 > Should be absent if IV is not needed? Again - missed this in the array kill pass. However, I am thinking that = IV may migrate to be a header parameter instead. >=20 > "aad contains additional authenticated data (aad) supplied by the = application. > This field contains information about the plain text data that is = authenticated, > but not encrypted. If the application does not provide this data, the = value =E2=80=98nil=E2=80=99 is > used." >=20 > Should be absent if no aad? Again - missed in array kill pass >=20 > "cipherText contains the encrypted plain text. If the cipherText is to = be > transported independently of the control information about the = encryption > process (i.e. detached content) then the value =E2=80=98nil=E2=80=99 > is encoded here." >=20 > Should be absent if no ciphertext? >=20 > "A =E2=80=98nil=E2=80=99 value if there are no recipients." >=20 > Should be absent if no recipients? >=20 > Section 5.1.1: >=20 > "The =E2=80=98protected=E2=80=99, =E2=80=98iv=E2=80=99, = =E2=80=98aad=E2=80=99, =E2=80=98ciphertext=E2=80=99 and = =E2=80=98recipients=E2=80=99 fields MUST be nil." >=20 > Should be absent instead? >=20 > Section 5.1.2: >=20 > "The =E2=80=98protected=E2=80=99, =E2=80=98aad=E2=80=99, and = =E2=80=98recipients=E2=80=99 fields MUST be nil." >=20 > Should be absent instead? >=20 > Section 5.1.3: >=20 > "The =E2=80=98protected=E2=80=99, =E2=80=98aad=E2=80=99, and = =E2=80=98iv=E2=80=99 fields all use the =E2=80=98nil=E2=80=99 value." >=20 > Sould be absent instead? >=20 > Section 5.1.4: >=20 > "The =E2=80=98protected=E2=80=99, =E2=80=98aad=E2=80=99, and = =E2=80=98iv=E2=80=99 fields all use the =E2=80=98nil=E2=80=99 value." >=20 > Should be absent instead? >=20 > Also, no note of ciphertext field. Should be absent? It seems like = presence or > absence of ciphertext tells apart DKA (5.1.4) and KAwKW (5.1.5). Currently the difference is based on different algorithm identifiers. = ECDH-ES vs. ECDH-ES+A128KW >=20 > Section 5.1.5: >=20 > "The =E2=80=98protected=E2=80=99, =E2=80=98aad=E2=80=99, and = =E2=80=98iv=E2=80=99 fields all use the =E2=80=98nil=E2=80=99 value." >=20 > Should be absent instead? >=20 > "At a minimum, the =E2=80=98unprotected=E2=80=99 field SHOULD contain = the =E2=80=98alg=E2=80=99 > parameter, a parameter identifying the recipient asymmetric key, and a > parameter with the sender=E2=80=99s asymmetric public key." >=20 > Parameter with sender=E2=80=99s asymmetric public key? Is that epk? Or = something else? > Or epk or something else depending on situation? That is going to depend on if we only support ephemeral-static or also = support static-static. In the latter case it may be any method of = identifying a key such as a 'kid'. >=20 > Section 5.2: >=20 > "1. If there is protected data, CBOR encode the map to a byte string = and place in > the protected field of the Enc_structure and the COSE_Encrypt = structure." >=20 > Shouldn't this be copy from message, since the field is already byte = string there? It is there for received messages, but no necessary created yet for = sending. But yes that would work as text as well. At some point in = time I will need to do a pass for textual consistency of how I write = this type of step. >=20 > Also, should this be null if no protected field? >=20 > "2. Copy the =E2=80=98aad=E2=80=99 field from the COSE_Encrypt = structure to the Enc_Structure." >=20 > Should this be null if no aad field? >=20 > Section 5.3: >=20 > "1. Verify that the =E2=80=98protected=E2=80=99 field is empty. > 2. Verify that the =E2=80=98aad=E2=80=99 field is empty." >=20 > Empty means absent? Yes >=20 > Section 6: >=20 > "At least one of protected and unprotected MUST be present." >=20 > Why is this requirement (might be good reasons, seems to come from = JOSE)? >=20 > "1. Create a MAC_structure and copy the protected and payload elements = from > the COSE_mac structure." >=20 > The protected is written as null if absent? >=20 > Section 7: >=20 > "The same fields defined in [RFC7517] are used here with the following = changes > in rules:" >=20 > The formatting of block below this looks screwed. One day I will learn correct markdown for RFCs. I am more used to doing = xml and have not figured everything out yet. >=20 > Section 9.2: >=20 > This section looks empty (no text, no subsections)? Yes - I have not filled this section in yet. >=20 > Section 9.3: >=20 > "NOTE: Need to review the range assignments. It does not necessarily = make > sense as specification required uses 1 byte positive integers and > 2 byte strings. ## COSE Header Algorithm Key Table" >=20 > There should be section break here? Yes -mark down error. >=20 > Section C: >=20 > The examples could use some indentation to make easier to read? >=20 > Section C.6: >=20 > There are some null values in the dump (key 6). Are those supposed to = be > signatures? My examples generation program was broken. I think this will be fixed = in the next version >=20 > Section E: >=20 > "jwk" and "kid" might need integers? 'kid' now has an integer. Do we believe that jwk is something that = makes lots of sense to keep? How used do we believe that it will be? = i.e. should it be a one byte or a two byte integer value. >=20 > Section G: >=20 > Some of these could use integers? Need to get some ideas of what algorithms should have one byte integer = encoding and which should be two byte integer encoding. Which are = important algorithms? >=20 > Section H: >=20 > - Since kty is mandatory, it should have integer? > - use and key_ops could have integers as values? > - important key parameters could have integer values? > - what are 'r' and 't' for RSA? And is 'dp' missing for RSA? I have just started a pass working on the key structure. =20 There was a typo with an extra 1 being put into the table for dp, it is = there but shifted over by one column. This has been fixed. Jim >=20 >=20 >=20 > -Ilari >=20 > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Fri Jun 5 17:38:13 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2C41AC3DC for ; Fri, 5 Jun 2015 17:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 ECUMM3LhgEgC for ; Fri, 5 Jun 2015 17:38:10 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CD871A9134 for ; Fri, 5 Jun 2015 17:38:10 -0700 (PDT) Received: from hebrews (unknown [104.240.61.209]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 0E72A38F30 for ; Fri, 5 Jun 2015 17:38:08 -0700 (PDT) From: "Jim Schaad" To: References: <20150606002142.32321.49197.idtracker@ietfa.amsl.com> In-Reply-To: <20150606002142.32321.49197.idtracker@ietfa.amsl.com> Date: Fri, 5 Jun 2015 17:37:57 -0700 Message-ID: <004b01d09ff1$134973e0$39dc5ba0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHs3SFPLVzw5hg1zG+0aW4rgK6ix51mJzyg Content-Language: en-us Archived-At: Subject: [Cose] FW: New Version Notification for draft-schaad-cose-02.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 00:38:12 -0000 Since we now have an official working group. I will propose this as a = candidate draft to address the specification milestone. I am willing to add the algorithms piece to this document if that is the = desire of the group, or it can be done as an independent document (my = initial preference). Jim =20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, June 05, 2015 5:22 PM > To: Jim Schaad; Jim Schaad > Subject: New Version Notification for draft-schaad-cose-02.txt >=20 >=20 > A new version of I-D, draft-schaad-cose-02.txt has been successfully = submitted > by Jim Schaad and posted to the IETF repository. >=20 > Name: draft-schaad-cose > Revision: 02 > Title: CBOR Encoded Message Syntax > Document date: 2015-06-05 > Group: Individual Submission > Pages: 35 > URL: = https://www.ietf.org/internet-drafts/draft-schaad-cose-02.txt > Status: https://datatracker.ietf.org/doc/draft-schaad-cose/ > Htmlized: https://tools.ietf.org/html/draft-schaad-cose-02 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-schaad-cose-02 >=20 > Abstract: > Concise Binary Object Representation (CBOR) is data format designed > for small code size and small message size. There is a need for = the > ability to have the basic security services defined for this data > format. This document specifies how to do signatures, message > authentication codes and encryption using this data format. The = work > in this document is derived in part from the JSON web security > documents using the same parameters and algorithm identifiers as = they > do. >=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 Fri Jun 5 18:48:46 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B381ACD28 for ; Fri, 5 Jun 2015 18:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 q8aOVGEOljes for ; Fri, 5 Jun 2015 18:48:43 -0700 (PDT) Received: from out4133-146.mail.aliyun.com (out4133-146.mail.aliyun.com [42.120.133.146]) by ietfa.amsl.com (Postfix) with ESMTP id 913011A8905 for ; Fri, 5 Jun 2015 18:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1433555322; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=CFMzjmaDG1JzqU9QrbicSmyPl7u1dllyVFEJYPs3p/g=; b=N0ggTHkX0ohcETXG9L0i1ucEUuusN03IOgFSxYxUz9ZX/ueLCcV1MjjFQflmfbBm1rSqVXGBPhwwmsPOSia7cOop8Rpu/3pNsAtIOAXXFAJT/y+0T2dCzKpvEHKyigb3oM+BDW3CtoysVUdh1hQhG1YnY60sduBNSFqj5zOq+Dw= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R561e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41f05043; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=2; RT=2; SR=0; Received: from 10.22.40.252(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.207) by smtp.aliyun-inc.com(127.0.0.1); Sat, 06 Jun 2015 09:48:38 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Sat, 06 Jun 2015 09:48:34 +0800 From: "Kepeng Li" To: Jim Schaad , Message-ID: Thread-Topic: [Cose] FW: New Version Notification for draft-schaad-cose-02.txt References: <20150606002142.32321.49197.idtracker@ietfa.amsl.com> <004b01d09ff1$134973e0$39dc5ba0$@augustcellars.com> In-Reply-To: <004b01d09ff1$134973e0$39dc5ba0$@augustcellars.com> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Cose] FW: New Version Notification for draft-schaad-cose-02.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 01:48:45 -0000 Hi Jim, Thanks for the draft. >I am willing to add the algorithms piece to this document if that is the >desire of the group, or it can be done as an independent document (my >initial preference).edx According to our milestones, the algorithm piece is a separate item. Jun 2015 - Submit COSE specification as a WG item Jun 2015 - Submit COSE constrained-appropriate algorithms as a WG item Kind Regards Kepeng =D4=DA 6/6/15 8:37 am=A3=AC "Jim Schaad" =D0=B4=C8=EB: >Since we now have an official working group. I will propose this as a >candidate draft to address the specification milestone. > >I am willing to add the algorithms piece to this document if that is the >desire of the group, or it can be done as an independent document (my >initial preference). > >Jim >=20 > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Friday, June 05, 2015 5:22 PM >> To: Jim Schaad; Jim Schaad >> Subject: New Version Notification for draft-schaad-cose-02.txt >>=20 >>=20 >> A new version of I-D, draft-schaad-cose-02.txt has been successfully >>submitted >> by Jim Schaad and posted to the IETF repository. >>=20 >> Name: draft-schaad-cose >> Revision: 02 >> Title: CBOR Encoded Message Syntax >> Document date: 2015-06-05 >> Group: Individual Submission >> Pages: 35 >> URL: =20 >>https://www.ietf.org/internet-drafts/draft-schaad-cose-02.txt >> Status: https://datatracker.ietf.org/doc/draft-schaad-cose/ >> Htmlized: https://tools.ietf.org/html/draft-schaad-cose-02 >> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-schaad-cose-02 >>=20 >> Abstract: >> Concise Binary Object Representation (CBOR) is data format designed >> for small code size and small message size. There is a need for the >> ability to have the basic security services defined for this data >> format. This document specifies how to do signatures, message >> authentication codes and encryption using this data format. The work >> in this document is derived in part from the JSON web security >> documents using the same parameters and algorithm identifiers as they >> do. >>=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 > >_______________________________________________ >Cose mailing list >Cose@ietf.org >https://www.ietf.org/mailman/listinfo/cose From nobody Fri Jun 5 19:31:33 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2311A90C0 for ; Fri, 5 Jun 2015 19:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 Ew8uG0va2uuX for ; Fri, 5 Jun 2015 19:31:29 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D53871A8F4E for ; Fri, 5 Jun 2015 19:31:29 -0700 (PDT) Received: from hebrews (unknown [104.240.61.209]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 8564C2C9C5; Fri, 5 Jun 2015 19:31:26 -0700 (PDT) From: "Jim Schaad" To: "'Kepeng Li'" , References: <20150606002142.32321.49197.idtracker@ietfa.amsl.com> <004b01d09ff1$134973e0$39dc5ba0$@augustcellars.com> In-Reply-To: Date: Fri, 5 Jun 2015 19:31:00 -0700 Message-ID: <006401d0a000$e8366ef0$b8a34cd0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHs3SFPLVzw5hg1zG+0aW4rgK6ixwM2MA3XAk4irUGdOiSiUA== Content-Language: en-us Archived-At: Subject: Re: [Cose] FW: New Version Notification for draft-schaad-cose-02.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 02:31:31 -0000 > -----Original Message----- > From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Kepeng Li > Sent: Friday, June 05, 2015 6:49 PM > To: Jim Schaad; cose@ietf.org > Subject: Re: [Cose] FW: New Version Notification for draft-schaad-cose-02. txt > > Hi Jim, > > Thanks for the draft. > > >I am willing to add the algorithms piece to this document if that is > >the desire of the group, or it can be done as an independent document > >(my initial preference).edx > > > According to our milestones, the algorithm piece is a separate item. That just says that we need a document to cover that milestone. It can be a single document or a combined document as the working group feels best. Jim > > Jun 2015 - Submit COSE specification as a WG item > Jun 2015 - Submit COSE constrained-appropriate algorithms as a WG item > > > Kind Regards > Kepeng > > $B:_(B 6/6/15 8:37 am$B!$(B "Jim Schaad" $B > >Since we now have an official working group. I will propose this as a > >candidate draft to address the specification milestone. > > > >I am willing to add the algorithms piece to this document if that is > >the desire of the group, or it can be done as an independent document > >(my initial preference). > > > >Jim > > > > > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Friday, June 05, 2015 5:22 PM > >> To: Jim Schaad; Jim Schaad > >> Subject: New Version Notification for draft-schaad-cose-02.txt > >> > >> > >> A new version of I-D, draft-schaad-cose-02.txt has been successfully > >>submitted by Jim Schaad and posted to the IETF repository. > >> > >> Name: draft-schaad-cose > >> Revision: 02 > >> Title: CBOR Encoded Message Syntax > >> Document date: 2015-06-05 > >> Group: Individual Submission > >> Pages: 35 > >> URL: > >>https://www.ietf.org/internet-drafts/draft-schaad-cose-02.txt > >> Status: https://datatracker.ietf.org/doc/draft-schaad-cose/ > >> Htmlized: https://tools.ietf.org/html/draft-schaad-cose-02 > >> Diff: https://www.ietf.org/rfcdiff?url2=draft-schaad-cose-02 > >> > >> Abstract: > >> Concise Binary Object Representation (CBOR) is data format designed > >> for small code size and small message size. There is a need for the > >> ability to have the basic security services defined for this data > >> format. This document specifies how to do signatures, message > >> authentication codes and encryption using this data format. The work > >> in this document is derived in part from the JSON web security > >> documents using the same parameters and algorithm identifiers as they > >> do. > >> > >> > >> > >> > >> Please note that it may take a couple of minutes from the time of > >>submission until the htmlized version and diff are available at > >>tools.ietf.org. > >> > >> The IETF Secretariat > > > >_______________________________________________ > >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 Fri Jun 5 20:04:52 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B8F1ACD36 for ; Fri, 5 Jun 2015 20:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Q6LJvcWDSqLZ for ; Fri, 5 Jun 2015 20:04:49 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0144.outbound.protection.outlook.com [207.46.100.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64E991ACD2F for ; Fri, 5 Jun 2015 20:04:49 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.184.10; Sat, 6 Jun 2015 03:04:48 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0184.014; Sat, 6 Jun 2015 03:04:48 +0000 From: Mike Jones To: Jim Schaad , 'Kepeng Li' , "cose@ietf.org" Thread-Topic: [Cose] FW: New Version Notification for draft-schaad-cose-02.txt Thread-Index: AQHs3SFPLVzw5hg1zG+0aW4rgK6ix51mJzyggAAUTQCAAAvbAIAAB/+g Date: Sat, 6 Jun 2015 03:04:47 +0000 Message-ID: References: <20150606002142.32321.49197.idtracker@ietfa.amsl.com> <004b01d09ff1$134973e0$39dc5ba0$@augustcellars.com> <006401d0a000$e8366ef0$b8a34cd0$@augustcellars.com> In-Reply-To: <006401d0a000$e8366ef0$b8a34cd0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none; x-originating-ip: [50.47.90.173] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 3:E1FnX+FiyxlubPM6HS4rMuwSgXCUOheH7D09jmPyc6WQ1x5c6Nlcv3HZv0DEcs6YNVtetm99FBiYMZNPhGW/lUQvEovKKXBbnNBxpBnNXvhx4FjVRitdFjR3gE+rFP8et1asKaYPN3ckLyMcOy2jdQ==; 10:5TPdBhcnc1TYOydsLVebh239L25tnrjIxPiEsIleXSHYfAbrO2e3wnbvhySh2hcKaHNqsd5xCO1epHMu8UwSGeikLG2bcOOw2JscHETSEYA=; 6:e6vicIJwv50z8ydKRQhlXR9Z9Mqe4LSsQdqYITd6knpHQ2615QLj0uT+2zBqrOMl x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(520003)(5005006)(3002001); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 05991796DF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(13464003)(377424004)(51914003)(377454003)(71364002)(86612001)(19580405001)(5001770100001)(2656002)(87936001)(5001960100002)(2501003)(189998001)(107886002)(76576001)(5002640100001)(122556002)(50986999)(54356999)(66066001)(76176999)(62966003)(2900100001)(2950100001)(74316001)(77156002)(106116001)(40100003)(93886004)(33656002)(46102003)(92566002)(77096005)(230783001)(99286002)(19580395003)(102836002)(86362001)(15975445007); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2015 03:04:47.6338 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Subject: Re: [Cose] FW: New Version Notification for draft-schaad-cose-02.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 03:04:51 -0000 For what it's worth, I'd advocate having a separate algorithm document for = the same reasons that JOSE did. For one, it enables that document to be re= vised in the future without having to then revise the underlying signature/= MAC/encryption/key representations. Also, based on my experience as a JOSE editor, I think the result was clean= er because we separated the algorithm descriptions from the descriptions of= how to perform cryptographic operations. It was good discipline to have t= o describe the steps to create and use the data structures without falling = back on particulars of specific algorithms. Also, the single-purpose nature of an algorithms doc can make it easier to = read and use a reference. You're not having to sort out what are data desc= riptions and what are algorithm descriptions. It's just algorithms. Cheers, -- Mike P.S. I agree with Jim's procedural point that the charter allows the worki= ng group to produce deliverables either in combined or separated documents. -----Original Message----- From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Friday, June 05, 2015 7:31 PM To: 'Kepeng Li'; cose@ietf.org Subject: Re: [Cose] FW: New Version Notification for draft-schaad-cose-02.t= xt > -----Original Message----- > From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Kepeng Li > Sent: Friday, June 05, 2015 6:49 PM > To: Jim Schaad; cose@ietf.org > Subject: Re: [Cose] FW: New Version Notification for draft-schaad-cose-02= . txt > > Hi Jim, > > Thanks for the draft. > > >I am willing to add the algorithms piece to this document if that is=20 > >the desire of the group, or it can be done as an independent document=20 > >(my initial preference).edx > > > According to our milestones, the algorithm piece is a separate item. That just says that we need a document to cover that milestone. It can be = a single document or a combined document as the working group feels best. Jim > > Jun 2015 - Submit COSE specification as a WG item > Jun 2015 - Submit COSE constrained-appropriate algorithms as a WG=20 > item > > > Kind Regards > Kepeng > > =1B$B:_=1B(B 6/6/15 8:37 am=1B$B!$=1B(B "Jim Schaad" =1B$B > >Since we now have an official working group. I will propose this as=20 > >a candidate draft to address the specification milestone. > > > >I am willing to add the algorithms piece to this document if that is=20 > >the desire of the group, or it can be done as an independent document=20 > >(my initial preference). > > > >Jim > > > > > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Friday, June 05, 2015 5:22 PM > >> To: Jim Schaad; Jim Schaad > >> Subject: New Version Notification for draft-schaad-cose-02.txt > >> > >> > >> A new version of I-D, draft-schaad-cose-02.txt has been=20 > >>successfully submitted by Jim Schaad and posted to the IETF repository= . > >> > >> Name: draft-schaad-cose > >> Revision: 02 > >> Title: CBOR Encoded Message Syntax > >> Document date: 2015-06-05 > >> Group: Individual Submission > >> Pages: 35 > >> URL: > >>https://www.ietf.org/internet-drafts/draft-schaad-cose-02.txt > >> Status: https://datatracker.ietf.org/doc/draft-schaad-cose/ > >> Htmlized: https://tools.ietf.org/html/draft-schaad-cose-02 > >> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-schaad-cose-= 02 > >> > >> Abstract: > >> Concise Binary Object Representation (CBOR) is data format designed > >> for small code size and small message size. There is a need for th= e > >> ability to have the basic security services defined for this data > >> format. This document specifies how to do signatures, message > >> authentication codes and encryption using this data format. The work > >> in this document is derived in part from the JSON web security > >> documents using the same parameters and algorithm identifiers as they > >> do. > >> > >> > >> > >> > >> Please note that it may take a couple of minutes from the time of=20 > >>submission until the htmlized version and diff are available at=20 > >>tools.ietf.org. > >> > >> The IETF Secretariat > > > >_______________________________________________ > >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 _______________________________________________ Cose mailing list Cose@ietf.org https://www.ietf.org/mailman/listinfo/cose From nobody Sat Jun 6 00:39:41 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A57611B29C5 for ; Sat, 6 Jun 2015 00:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 E6hgZo5F5R64 for ; Sat, 6 Jun 2015 00:39:35 -0700 (PDT) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 562D61B29C4 for ; Sat, 6 Jun 2015 00:39:34 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 4FFA13FD4; Sat, 6 Jun 2015 10:39:32 +0300 (EEST) Date: Sat, 6 Jun 2015 10:39:31 +0300 From: Ilari Liusvaara To: Jim Schaad Message-ID: <20150606073931.GA5970@LK-Perkele-VII> References: <20150606002142.32321.49197.idtracker@ietfa.amsl.com> <004b01d09ff1$134973e0$39dc5ba0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <004b01d09ff1$134973e0$39dc5ba0$@augustcellars.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] FW: New Version Notification for draft-schaad-cose-02.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 07:39:38 -0000 On Fri, Jun 05, 2015 at 05:37:57PM -0700, Jim Schaad wrote: > > Subject: New Version Notification for draft-schaad-cose-02.txt > > > > URL: https://www.ietf.org/internet-drafts/draft-schaad-cose-02.txt > > Status: https://datatracker.ietf.org/doc/draft-schaad-cose/ > > Htmlized: https://tools.ietf.org/html/draft-schaad-cose-02 > > Diff: https://www.ietf.org/rfcdiff?url2=draft-schaad-cose-02 Did a quick review (some of the stuff is new, some is still standing from previous review (I did go through the reply briefly): 1) Section 5: " recipients contains the recipient information. The field can have one of two data types: o An array of COSE_encrypt elements, one for each recipient. " Err... Expected list of 2 items, found 1. 2) Section 5.1.2: "The 'protected', 'iv', 'aad', 'ciphertext' and 'recipients' fields MUST be absent." Apeendix B contains some text about applying RSA-KEM. It says there are three layers. Wouldn't the middle layer be key wrapping, and thus seemingly violate that MUST not have recipients? 3) Sections 5.1.3, 5.1.4 and 5.1.5: "The 'protected', 'aad', and 'iv' fields MUST be absent." Recipients is allowed? What semantics does that have? Decrypts to private key of appropriate type, to be used for decryption? 4) Section 5.1.4: "The 'protected', 'aad', and 'iv' fields MUST be absent." Can ciphertext field be present, depending on the algorithm? Epk has to be present, wouldn't that contain the key agreement values? 5) Section 5.1.5: "At a minimum, the 'unprotected' field SHOULD contain the 'alg' parameter, a parameter identifying the recipient asymmetric key, and a parameter with the sender's asymmetric public key." I realize this is written to allow ECDH static-static. However, as comment of adding ECDH static-static, if one does that, one either has to either: - Include a nonce field, to be mixed in at KDF stage. - Be careful what key wrapping algorithms one uses. The reason for that is that many encryption algorithms have nonces that are: - Too short to randomly generate without unacceptably high risk of collision (and used too long to reliably count). - Catastrophically break the algorithm if repeated. e.g. AES-KW is ok, since it lacks nonce entierely. e.g. AES-GCM is not, because its 12 byte nonce is too short for random generation. 6) Section 5.2: "If there is protected data, CBOR encode the map to a byte string and place in the protected field of the Enc_structure and the COSE_Encrypt structure." And what if there isn't, what is written into Enc_structure? - Nonexistent? - 0xF6 (null)? - 0x60 (empty string)? - 0x61 0xA0 (empty map)? 7) Section 5.2: "Copy the 'aad' field from the COSE_Encrypt structure to the Enc_Structure." And what if 'aad' is absent, what is copied? - Nonexistent (creates problems if protected also can be nonexistent)? - 0xF6 (null)? - 0x60 (empty string, but to me it seems nonexistent != empty string)? 8) Section 6: "Create a MAC_structure and copy the protected and payload elements from the COSE_mac structure." What if protected element is missing (the choices seem to be the same as in 6)? 9) Section C: It might be possible to format those examples in way that is easier to read (TODO: Try various formattings). 10) Section C.1: Maybe add TODO note about ECDH-SS. Does not seem to be defined anywhere (I searched this draft, JWA, JWK, JWE and JWS). [TODO: ECDH-SS and spk parameter are to be defined] Or something like that. 11) Section D: It occurs to me that if using "decode to pointer table", the technique is more efficient the smaller the largest understood key is (or the less understood keys there are). OTOH, dunno to what extent overlaps in the table complicate implementations. Encryption, Signatures and MACs seem quite separate. The idea of "decode to pointer table" is to first do scan pass where pointers to values of various fields are written into table, and then operate on those pointers, decoding appropriate values (this is since values can appear in any order in maps). 12) (general, algorithms draft stuff): How would ECDH using CFRG curves (that should be stable now) be done? The public keys have only one 32/56 byte octet string (and the private keys too). While ECDH part should be stable, that is part of larger document, where at least signature parts are under work, so I don't know about the schedule of that draft. -Ilari From nobody Sat Jun 6 16:50:11 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832B21A0029; Sat, 6 Jun 2015 16:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 dbciL5Gv-G0U; Sat, 6 Jun 2015 16:50:07 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0143.outbound.protection.outlook.com [207.46.100.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C65BE1A001C; Sat, 6 Jun 2015 16:50:07 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.184.10; Sat, 6 Jun 2015 23:50:06 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0184.014; Sat, 6 Jun 2015 23:50:06 +0000 From: Mike Jones To: Jim Schaad , "jose@ietf.org" , "cose@ietf.org" Thread-Topic: [Cose] Use of supplied authenticated information with AEAD algorithms Thread-Index: AdCgs4SjUrfkds2zS0eiti0pLyx2hA== Date: Sat, 6 Jun 2015 23:50:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none; x-originating-ip: [66.194.79.10] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 3:hYw4zKjRtUOxdseURvFRY23EI95ra7F5cYEjkxPkvVqtimRe9sv9olUjFOBP36ujab2Rnpn6YDRy9JmnNNCwN4wJiWrBs5RtpHJPwiob0sQP61P3Iz+zmKpM6Z7+Iqw/1LCUnDS+jyLuRbG8M3v/Qg==; 10:nDnnAdrUL1ZrJPldhN/FaHSbLNGz+BDG5jF6bEMp+MaXI2XPrKUmu6KvTPZjhMq77aor3mMEcpNXp2ydRfzDPhxpERAW2TlhGhJC4tC0QHc=; 6:Bh1iP6eqtwSV72LmVxUTSfwjA+sHNAf7CcitsVhzMXDamLsb6WoUM3owwdOciOp8 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(520003)(5005006)(3002001); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 05991796DF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(52604005)(377454003)(2900100001)(19625215002)(62966003)(74316001)(77156002)(50986999)(19609705001)(122556002)(66066001)(54356999)(86362001)(19580395003)(19300405004)(102836002)(15975445007)(92566002)(2201001)(99286002)(40100003)(33656002)(77096005)(46102003)(2656002)(87936001)(19617315012)(86612001)(19580405001)(5001770100001)(76576001)(107886002)(5002640100001)(16236675004)(5001920100001)(5001960100002)(189998001)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB44219EF2DB00A613AFFB028F5B10BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2015 23:50:05.3257 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Subject: Re: [Cose] Use of supplied authenticated information with AEAD algorithms X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 23:50:10 -0000 --_000_BY2PR03MB44219EF2DB00A613AFFB028F5B10BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd overlooked this note earlier, so am just replying now. Jim, the case o= f detached additional authenticated data is an interesting one. Thanks for= bringing this up. As an initial reaction, is there a reason this couldn't be handled in the s= ame manner as detached payloads, as is done in JWS Appendix F http://tools.= ietf.org/html/rfc7515#appendix-F, by omitting the AAD value in the transmit= ted form but including it in the integrity computation? -- Mike From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Wednesday, April 08, 2015 4:19 PM To: jose@ietf.org; cose@ietf.org Subject: [Cose] Use of supplied authenticated information with AEAD algorit= hms In the process of going through the use cases that have arisen for dealing = with the COSE world in ACE. I have come to a realization that we have perh= aps messed up the paradigm for additional data when dealing with AEAD algor= ithms. I don't think this is an issue for the world which JOSE came out of= , but it may be an issue going in the future and is definitely an issue for= the world of CoAP. In JOSE we make the assumption that all of the additional authenticated dat= a is transmitted as part of the JOSE message. This makes sense because we = did not have a large number of cases where it would not be. However, if on= e looks at the CoAP/ACE world this is not always true. In their case they = are going to want to potentially have both authenticated data carried as pa= rt of the message, but also have authenticated data which is carried in the= envelope. Case of sending a JWT, this would be the equivalent of needing to send the = name of the originator in the headers and still wanting to have it validate= d as part of the token. (As opposed to just sending it in the body of the = JWT.) I don't know of any cases currently where this is a problem for JOSE. I do= know that it is a potential problem for COSE. Can any body think of a use case for JOSE where this paradigm needs to be f= ixed? Jim --_000_BY2PR03MB44219EF2DB00A613AFFB028F5B10BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’d overlooked t= his note earlier, so am just replying now.  Jim, the case of detached = additional authenticated data is an interesting one.  Thanks for bring= ing this up.

 

As an initial reaction= , is there a reason this couldn’t be handled in the same manner as de= tached payloads, as is done in JWS Appendix F http://tools.ietf= .org/html/rfc7515#appendix-F, by omitting the AAD value in the transmit= ted form but including it in the integrity computation?

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      -- Mike

 

From: Cose [ma= ilto:cose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Wednesday, April 08, 2015 4:19 PM
To: jose@ietf.org; cose@ietf.org
Subject: [Cose] Use of supplied authenticated information with AEAD = algorithms

 

In the process of going through the use cases that h= ave arisen for dealing with the COSE world in ACE.  I have come to a r= ealization that we have perhaps messed up the paradigm for additional data = when dealing with AEAD algorithms.  I don’t think this is an issue for the world which JOSE came out of, but it may be= an issue going in the future and is definitely an issue for the world of C= oAP.

 

In JOSE we make the assumption that all of the addit= ional authenticated data is transmitted as part of the JOSE message.  = This makes sense because we did not have a large number of cases where it w= ould not be.  However, if one looks at the CoAP/ACE world this is not always true.  In their case they are g= oing to want to potentially have both authenticated data carried as part of= the message, but also have authenticated data which is carried in the enve= lope. 

 

Case of sending a JWT, this would be the equivalent = of needing to send the name of the originator in the headers and still want= ing to have it validated as part of the token.  (As opposed to just se= nding it in the body of the JWT.)

 

I don’t know of any cases currently where this= is a problem for JOSE.  I do know that it is a potential problem for = COSE.

 

Can any body think of a use case for JOSE where this= paradigm needs to be fixed?

 

Jim

 

--_000_BY2PR03MB44219EF2DB00A613AFFB028F5B10BY2PR03MB442namprd_-- From nobody Sat Jun 6 17:33:35 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5571A1B4A for ; Sat, 6 Jun 2015 17:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 dY11Icb83OMS for ; Sat, 6 Jun 2015 17:33:31 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0774.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:774]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 095901A1B49 for ; Sat, 6 Jun 2015 17:33:30 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.184.10; Sun, 7 Jun 2015 00:33:09 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0184.014; Sun, 7 Jun 2015 00:33:09 +0000 From: Mike Jones To: Derek Atkins Thread-Topic: [Cose] Issue: Reuse the Enrypt structure for recipients Thread-Index: AQHQjN+10lJyO1ENSaipAaz9l4o5Tp2gVqpg Date: Sun, 7 Jun 2015 00:33:08 +0000 Message-ID: References: <001c01d08399$642ed490$2c8c7db0$@augustcellars.com> <008401d08c33$504feb60$f0efc220$@augustcellars.com> <008601d08c3c$6049a570$20dcf050$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ihtfp.com; dkim=none (message not signed) header.d=none; x-originating-ip: [66.194.79.10] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 3:aCC71U/9l1QcIWaS4LsN/86NRnxlpToJKhGMUjXgFwhm2zxrrhbdGNIH2oW+PpkMroA3Tm4EdMR/IfqXbenCxRgxEMSjlOS45pLL2MVb6orQctFdmBS3e/mpgv+N0lFPCSwvanJkZk5rwnO031Hp+Q==; 10:mYAW9ShdC77Nw92v64SbasRdaOr92JW4HRV+g9WSmNs43f431D1+zYViVdJADpa/2y30tEXZlI1TlVq+E8lZoJ/EqTB68AEpYjW0xe4PBL4=; 6:aPtifTcE6xuhL/ZpMRDuBBfL81Hy+C3N5gKopU7bUhIv3FdA+Q0cPzpLY4/GuR2B x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(520003)(5005006)(3002001); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 0600F93FE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(13464003)(54356999)(76176999)(46102003)(50986999)(66066001)(5001920100001)(92566002)(189998001)(5001960100002)(110136002)(106116001)(99286002)(76576001)(15974865002)(86612001)(19580405001)(19580395003)(5002640100001)(93886004)(74316001)(122556002)(561944003)(33656002)(2656002)(87936001)(40100003)(62966003)(77156002)(86362001)(77096005)(2900100001)(15975445007)(2950100001)(102836002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2015 00:33:08.2583 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Cc: Jim Schaad , "cose@ietf.org" Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 00:33:34 -0000 Replying to Derek's question " I guess my question to you (not being as int= imately familiar with JWKs) is whether the algorithm of the wrapped (encryp= ted) key is exposed somewhere outside the wrapping?"... Yes, in JOSE, the key wrap algorithm is always explicitly declared in the J= WE "alg" header parameter http://tools.ietf.org/html/rfc7516#section-4.1.1.= Repeating the algorithm in the equivalent of a JWK "alg" member http://to= ols.ietf.org/html/rfc7517#section-4.4 would only add redundant information,= both increasing the message size, and possibly worse, creating new error c= ases that would have to be checked for. For instance, a new error that thi= s approach would introduce that is impossible for JWE encrypted_key values = is for the two algorithm declarations not to match. It's simpler and less = error prone when the data structure can't represent such inconsistent state= s in the first place. Cheers, -- Mike -----Original Message----- From: Derek Atkins [mailto:derek@ihtfp.com]=20 Sent: Tuesday, May 12, 2015 11:16 AM To: Mike Jones Cc: Jim Schaad; 'Derek Atkins'; cose@ietf.org Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients Mike Jones writes: > What was presented to the JOSE working group in Denver by Richard Barnes = was the option of representing encrypted keys as encrypted JWK structures, = rather than just encrypted bare keys. The choice is between encrypting: > {"kty":"oct", > "alg":"A128KW", > "k":"GawgguFyGrWKav7AX4VKUg"} > or simply the bytes that "k" represents in base64url encoded form. Encry= pting just the bytes is smaller, and contains no redundant information that= will simply be discarded. Is it necesarily redundant? What says that the key being encrypted (wrapped) is of the exact same algorithm/size/mode as the method being used= to encrypt/wrap it? E.g., I can certainly posit a situation where I am encrypting an AES-128-CC= M key with an AES-256-GCM key (Or even more, I could see encrypting a 3DES = key with AES). In this case the extra information is definitely not redund= ant, and is certainly not derivable just from 'k'. I guess my question to you (not being as intimately familiar with JWKs) is = whether the algorithm of the wrapped (encrypted) key is exposed somewhere o= utside the wrapping? > That's why the JOSE working group rejected using encrypted JWKs as the en= crypted_key representation. If the "encrypt structure" you're referring to= is different than this, it would probably be good to explain what it is, h= ow you're proposing to reuse it, and why reusing it doesn't add extraneous = unused information, as Richard's proposal in Denver did. ... > -- Mike -derek > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com] > Sent: Monday, May 11, 2015 11:47 PM > To: Mike Jones; 'Derek Atkins' > Cc: cose@ietf.org > Subject: RE: [Cose] Issue: Reuse the Enrypt structure for recipients > > I don't understand what you are arguing for or against. > > Are you saying don't do the reuse of the structure? > Are you saying don't do the extra tagging of encrypted key vs encrypted c= ontent? > Are you saying something completely different? > > jim > >> -----Original Message----- >> From: Mike Jones [mailto:Michael.Jones@microsoft.com] >> Sent: Monday, May 11, 2015 3:25 PM >> To: Jim Schaad; 'Derek Atkins' >> Cc: cose@ietf.org >> Subject: RE: [Cose] Issue: Reuse the Enrypt structure for recipients >>=20 >> From my point of view, the JOSE WG didn't reject encrypting a JWK to=20 >> represent the encrypted key because it was a change. The working=20 >> group rejected it because there was no need to carry any data that=20 >> would remain unused about the encrypted key, when just the the=20 >> encrypted key value > itself >> would do. Particularly in a space-constrained environment, carrying=20 >> extra metadata about a key that will only be discarded seems wasteful=20 >> in the extreme. >>=20 >> I would advocate having the encrypted_key value remain only an=20 >> encrypted form of the CEK value, adding nothing extra. >>=20 >> - Mike >>=20 >> -----Original Message----- >> From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad >> Sent: Monday, May 11, 2015 10:42 PM >> To: 'Derek Atkins' >> Cc: cose@ietf.org >> Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients >>=20 >> At the present time, that information can easily be inferred by context. > In the >> event that we want to talk about use the "recipient" structure as a=20 >> top > level >> object then I think this question would need to be revisited. >>=20 >> Jim >>=20 >>=20 >> > -----Original Message----- >> > From: Derek Atkins [mailto:derek@ihtfp.com] >> > Sent: Monday, May 11, 2015 8:23 AM >> > To: Jim Schaad >> > Cc: cose@ietf.org >> > Subject: Re: [Cose] Issue: Reuse the Enrypt structure for=20 >> > recipients >> > >> > I believe that yes, the map should be reused, however if we do that=20 >> > I wonder whether you need to add a tag that says whether it's an=20 >> > encrypted key or encrypted 'data'? >> > >> > -derek >> > >> > "Jim Schaad" writes: >> > >> > > Question: Reuse Encrypt body map for recipients >> > > >> > > Discussion: >> > > >> > > The concept of using the same structure for both recipients and=20 >> > > the base encryption map was introduced to the JOSE working group=20 >> > > at the Denver meeting. The JOSE working group rejected the idea=20 >> > > as being too much of a change to make in the current working code. >> > > The concept is that the same data structure, with the same=20 >> > > elements is used to encode both the content encryption and each=20 >> > > of the recipient >> structures. >> > > While in JOSE, many of the same elements are not present in the=20 >> > > recipient structure (i.e. iv and aad), some of these elements=20 >> > > later appeared as part of algorithm descriptions (iv is a header=20 >> > > parameter >> > defined for AES-GCM key wrapping). >> > > >> > > Using the same structure for encrypting content as well as=20 >> > > encrypting keys allows for some neat tricks to be played at a=20 >> > > later date if needed. One example is that you could separate the=20 >> > > key wrapping algorithm, and the ECDH-KDF algorithm pair into=20 >> > > separate layers. This allows one to move towards a Chinese Menu=20 >> > > method of selecting and using algorithms rather than the current=20 >> > > algorithm suite >> method. >> > > While I would not recommend that this happen in the current=20 >> > > specification, it might be nice to keep it open as an option to=20 >> > > be used >> in the >> > future as new algorithms are added. >> > > >> > > Another advantage of doing this folding is in code size. In my=20 >> > > implementation, I have created the recipient class as inheriting=20 >> > > from the encryption body class. The recipient class contains=20 >> > > only code that deals with the cryptography of key management. =20 >> > > All of the >> > encoding/decoding is >> > > handled by the base encryption class. If the structures are kept >> separate >> > > as they are today then that code would need to be added to the=20 >> > > recipient class. While my code does not currently deal with idea=20 >> > > of having multiple layers of key management. I believe that this=20 >> > > would be a minimal addition to the current code base. >> > > >> > > >> > > _______________________________________________ >> > > Cose mailing list >> > > Cose@ietf.org >> > > https://www.ietf.org/mailman/listinfo/cose >> > > >> > > >> > >> > -- >> > Derek Atkins 617-623-3745 >> > derek@ihtfp.com www.ihtfp.com >> > Computer and Internet Security Consultant >>=20 >> _______________________________________________ >> Cose mailing list >> Cose@ietf.org >> https://www.ietf.org/mailman/listinfo/cose > > > --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Sat Jun 6 18:09:30 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFCE1A1BB5; Sat, 6 Jun 2015 18:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 5iu8fiRG7FQW; Sat, 6 Jun 2015 18:09:25 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D87621A1BB1; Sat, 6 Jun 2015 18:09:25 -0700 (PDT) Received: from hebrews (unknown [104.240.61.209]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id B590E38EFE; Sat, 6 Jun 2015 18:09:24 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , , References: In-Reply-To: Date: Sat, 6 Jun 2015 18:09:08 -0700 Message-ID: <009801d0a0be$9bb2c880$d3185980$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0099_01D0A083.EF548CC0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQICb9aFkiTXAgeTegYz4it7vRUZe508nUBA Content-Language: en-us Archived-At: Subject: Re: [Cose] Use of supplied authenticated information with AEAD algorithms X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 01:09:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0099_01D0A083.EF548CC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit You would have a potential flexibility issue of not having both types, other than that it would not be an issue. From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Saturday, June 06, 2015 4:50 PM To: Jim Schaad; jose@ietf.org; cose@ietf.org Subject: RE: [Cose] Use of supplied authenticated information with AEAD algorithms I'd overlooked this note earlier, so am just replying now. Jim, the case of detached additional authenticated data is an interesting one. Thanks for bringing this up. As an initial reaction, is there a reason this couldn't be handled in the same manner as detached payloads, as is done in JWS Appendix F http://tools.ietf.org/html/rfc7515#appendix-F, by omitting the AAD value in the transmitted form but including it in the integrity computation? -- Mike From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Wednesday, April 08, 2015 4:19 PM To: jose@ietf.org ; cose@ietf.org Subject: [Cose] Use of supplied authenticated information with AEAD algorithms In the process of going through the use cases that have arisen for dealing with the COSE world in ACE. I have come to a realization that we have perhaps messed up the paradigm for additional data when dealing with AEAD algorithms. I don't think this is an issue for the world which JOSE came out of, but it may be an issue going in the future and is definitely an issue for the world of CoAP. In JOSE we make the assumption that all of the additional authenticated data is transmitted as part of the JOSE message. This makes sense because we did not have a large number of cases where it would not be. However, if one looks at the CoAP/ACE world this is not always true. In their case they are going to want to potentially have both authenticated data carried as part of the message, but also have authenticated data which is carried in the envelope. Case of sending a JWT, this would be the equivalent of needing to send the name of the originator in the headers and still wanting to have it validated as part of the token. (As opposed to just sending it in the body of the JWT.) I don't know of any cases currently where this is a problem for JOSE. I do know that it is a potential problem for COSE. Can any body think of a use case for JOSE where this paradigm needs to be fixed? Jim ------=_NextPart_000_0099_01D0A083.EF548CC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You would have a potential flexibility issue of = not having both types, other than that it would not be an = issue.

 

From: Mike = Jones [mailto:Michael.Jones@microsoft.com]
Sent: Saturday, = June 06, 2015 4:50 PM
To: Jim Schaad; jose@ietf.org; = cose@ietf.org
Subject: RE: [Cose] Use of supplied = authenticated information with AEAD = algorithms

 

I’d overlooked this note earlier, so am = just replying now.  Jim, the case of detached additional = authenticated data is an interesting one.  Thanks for bringing this = up.

 

As an initial reaction, = is there a reason this couldn’t be handled in the same manner as = detached payloads, as is done in JWS Appendix F http://tools.ietf.= org/html/rfc7515#appendix-F, by omitting the AAD value in the = transmitted form but including it in the integrity = computation?

 

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;   -- Mike

 

From: Cose = [mailto:cose-bounces@ietf.org] = On Behalf Of Jim Schaad
Sent: Wednesday, April 08, 2015 = 4:19 PM
To: jose@ietf.org; cose@ietf.org
Subject: = [Cose] Use of supplied authenticated information with AEAD = algorithms

 

In the = process of going through the use cases that have arisen for dealing with = the COSE world in ACE.  I have come to a realization that we have = perhaps messed up the paradigm for additional data when dealing with = AEAD algorithms.  I don’t think this is an issue for the = world which JOSE came out of, but it may be an issue going in the future = and is definitely an issue for the world of CoAP.

 

In JOSE we = make the assumption that all of the additional authenticated data is = transmitted as part of the JOSE message.  This makes sense because = we did not have a large number of cases where it would not be.  = However, if one looks at the CoAP/ACE world this is not always = true.  In their case they are going to want to potentially have = both authenticated data carried as part of the message, but also have = authenticated data which is carried in the envelope.  =

 

Case of sending a JWT, this would be the equivalent of = needing to send the name of the originator in the headers and still = wanting to have it validated as part of the token.  (As opposed to = just sending it in the body of the JWT.)

 

I = don’t know of any cases currently where this is a problem for = JOSE.  I do know that it is a potential problem for = COSE.

 

Can any body think of a use case for JOSE where this = paradigm needs to be fixed?

 

Jim

 

------=_NextPart_000_0099_01D0A083.EF548CC0-- From nobody Sun Jun 7 10:59:40 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E982C1ACCE8 for ; Sun, 7 Jun 2015 10:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 TNrhPWqGdnbx for ; Sun, 7 Jun 2015 10:59:38 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 768D11ACCE2 for ; Sun, 7 Jun 2015 10:59:37 -0700 (PDT) X-AuditID: 1209190c-f79936d000000dc6-37-55748687dcd7 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 41.CA.03526.78684755; Sun, 7 Jun 2015 13:59:36 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t57HxZJM010011 for ; Sun, 7 Jun 2015 13:59:35 -0400 Received: from [172.20.0.173] (rrcs-74-62-50-2.west.biz.rr.com [74.62.50.2]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t57HxWvV003752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 7 Jun 2015 13:59:34 -0400 From: Justin Richer X-Pgp-Agent: GPGMail 2.5b6 Content-Type: multipart/signed; boundary="Apple-Mail=_892C2A09-0960-4ABC-9F79-0244AAAB7DE6"; protocol="application/pgp-signature"; micalg=pgp-sha256 Date: Sun, 7 Jun 2015 10:59:34 -0700 Message-Id: To: "cose@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsUixCmqrdvRVhJqcJzfYtrWqawOjB5Llvxk CmCM4rJJSc3JLEst0rdL4Mr4vOEda8EhgYp3C74wNTDO4Oti5OSQEDCRWHRnHROELSZx4d56 ti5GLg4hgcVMEuv7prJCOEcYJb6vm84I4dxhkti26SwbSAubgKrE/JW3oNqlJJpeHwMrYhaY wijx7PBsRpCEsICoRNuCL+wgNouAisScBzNYuhg5OHgFrCQOv9cCCYsIKEtMOtbMCmLzCuhJ PHr6mB2kREJAVuLrVrkJjHyzkE2dhaQMxGYW0JZYtvA1M4StKbG/ezkLhC0vsf3tHKi4pcTi mTeg4rYSt/oWMEHYdhKPpi1iXcDIsYpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXUC83s0QvNaV0 EyM4uCV5djC+Oah0iFGAg1GJh/fFzOJQIdbEsuLK3EOMkhxMSqK813NKQoX4kvJTKjMSizPi i0pzUosPMaoA7Xq0YfUFRimWvPy8VCURXhVuoDrelMTKqtSifJgyaQ4WJXHeTT/4QoQE0hNL UrNTUwtSi2CyMhwcShK8mq1AjYJFqempFWmZOSUIaSYOzkOMEhw8QMOjW0CGFxck5hZnpkPk TzEqSonzyoI0C4AkMkrz4HphSekVozjQW8K8RiBVPMCEBtf9CmgwE9Dg71+LQQaXJCKkpBoY mV9zyz02fxzp94inbfnEeft81Aw0jQzn2rmFLZs5uXgWk0TQxy3cJVHc/8q7398KkIrhTbq3 eFnvrecLXwWwlaSZ+rRcTGhVaq9J91gc9emEWnDi+uLEvCtyW4QSJ69RqLr4fV57mMe3awed u00Zvwur+f3m2LW36rP5z87KTns7j5kGntuUWIozEg21mIuKEwGGln/xJQMAAA== Archived-At: Subject: [Cose] Introduction X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 17:59:40 -0000 --Apple-Mail=_892C2A09-0960-4ABC-9F79-0244AAAB7DE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi everybody, As many of you have seen, I=E2=80=99m one of your chairs in the = newly-formed COSE working group. I=E2=80=99ve been an active member of = several groups here in the IETF, most notably the OAuth and JOSE groups = for a number of years, as well as participating in other standards = groups in other SDO=E2=80=99s. I=E2=80=99ve edited several RFC-track = documents and contributed to several published specifications. = Additionally, I=E2=80=99m also a software engineer with submission = credits on many open source projects, most relevant to here being the = Nimbus JOSE JWT library for Java. I=E2=80=99m here not to drive any particular implementation or agenda, = but as chair I=E2=80=99m here to facilitate the group, to help it work = efficiently and work well. That said, I do believe there=E2=80=99s a lot = that we can lean on from past efforts (especially JOSE, from which this = group has sprung), and if at all possible I would like this new effort = to avoid taking the 4.5 years that JOSE did from inception to RFC. I will be at the Prague meeting in person, and I look forward to working = with you all. =E2=80=94 Justin --Apple-Mail=_892C2A09-0960-4ABC-9F79-0244AAAB7DE6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVdIaHAAoJEDPAngkbd+w94ukH/2YSjZkCU7jlcIsg0WhFqAV3 cNDxVljisSR4CL4gVRymqC1HCP6d2hkqQdYnqhd2rzwjqyk/IG+tPOgdE727cVln +aZn1UgEvznWEVYCH5Qev7eM+9rgeps6lOA0afWAdyjq4/mL+h76lm4WALES/Xhd gpmRnMQER7fhRDzKxkVQSI+C0o3MqDg+t9DlytEHEq/cO1OR7BZJujB0zFSGHudk ++W5xBzDvfLzQ3ERJ5hvpZPMTbeiT3pgXcZ09gCQ3i+kTxX74url8fkuUlWraLsp pVgUYLzYYy1S58bbP62E+M5V8WsPOpEfvJK1aFoXrB03h2v/sMCJwghKBTRF5n4= =pwS/ -----END PGP SIGNATURE----- --Apple-Mail=_892C2A09-0960-4ABC-9F79-0244AAAB7DE6-- From nobody Sun Jun 7 18:37:00 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836D81A8952 for ; Sun, 7 Jun 2015 18:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.151 X-Spam-Level: *** X-Spam-Status: No, score=3.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 gF4GH2DdBHSv for ; Sun, 7 Jun 2015 18:36:57 -0700 (PDT) Received: from out4133-50.mail.aliyun.com (out4133-50.mail.aliyun.com [42.120.133.50]) by ietfa.amsl.com (Postfix) with ESMTP id CE4551B2A21 for ; Sun, 7 Jun 2015 18:36:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1433727415; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=vlOfj8ufV4ePHxFjzE/oPByHWikvP5QbPxGJxXTRUEA=; b=OHgDGMV/4eGx8cB/5t+J/LoyFYo1eMTtLohmlhjnd7IGDwYKGlXlDy0Ih8ydtPDWdNFZaROuGV+VKp0IfbqsHSbhIfRprcnQk8mEMuBTme0fE+b1jT06yOvsMxnzs+n9OYaiVuG5INQizrGDkAJL+l9Hwf7QNihr0EM3lxEGr/4= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R451e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g08151; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=2; RT=2; SR=0; Received: from 10.1.147.12(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.158) by smtp.aliyun-inc.com(127.0.0.1); Mon, 08 Jun 2015 09:36:51 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Mon, 08 Jun 2015 09:36:45 +0800 From: "Kepeng Li" To: Justin Richer , "cose@ietf.org" Message-ID: Thread-Topic: [Cose] Introduction References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Cose] Introduction X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 01:36:59 -0000 Hi Justin, Welcome on board! I am the other co-chair for COSE working group, and I am also co-chairing ACE working group.=20 I have been an active member of CoRE for several years, and my past experience in IETF is mainly about Internet Of Things and security. One of the COSE goals is to coordinate its progress with the ACE, DICE and CORE working groups to ensure that we are fulfilling the needs of these constituencies. I hope I can help these coordinations, and help the COSE work to make progress efficiently. I will also attend Prague F2F meeting, and I look forward to working with you and our group participants. BTW, I have requested one hour session for COSE in Prague, and let=A1=AFs have the first WG meeting there. Thanks, Kind Regards Kepeng =D4=DA 8/6/15 1:59 am=A3=AC "Justin Richer" =D0=B4=C8=EB: >Hi everybody, > >As many of you have seen, I=A1=AFm one of your chairs in the newly-formed COSE >working group. I=A1=AFve been an active member of several groups here in the >IETF, most notably the OAuth and JOSE groups for a number of years, as >well as participating in other standards groups in other SDO=A1=AFs. I=A1=AFve >edited several RFC-track documents and contributed to several published >specifications. Additionally, I=A1=AFm also a software engineer with >submission credits on many open source projects, most relevant to here >being the Nimbus JOSE JWT library for Java. > >I=A1=AFm here not to drive any particular implementation or agenda, but as >chair I=A1=AFm here to facilitate the group, to help it work efficiently and >work well. That said, I do believe there=A1=AFs a lot that we can lean on from >past efforts (especially JOSE, from which this group has sprung), and if >at all possible I would like this new effort to avoid taking the 4.5 >years that JOSE did from inception to RFC. > >I will be at the Prague meeting in person, and I look forward to working >with you all. > > =A1=AA Justin >_______________________________________________ >Cose mailing list >Cose@ietf.org >https://www.ietf.org/mailman/listinfo/cose From nobody Mon Jun 8 08:38:46 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACC81B2F59 for ; Mon, 8 Jun 2015 08:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham 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 ZaYkoxojRVSP for ; Mon, 8 Jun 2015 08:38:36 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5A1F1B2F79 for ; Mon, 8 Jun 2015 08:37:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id AA587E2036; Mon, 8 Jun 2015 11:37:35 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 32388-06; Mon, 8 Jun 2015 11:37:31 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id AC382E2035; Mon, 8 Jun 2015 11:37:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1433777851; bh=GUeOiCu+5Vt+ODOxkMC8tdfb0OAmERDVqEyfF/nAgHY=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=AP1GtV+igpwVC5PPZzEsEIG91heG05EuA4v4NBfvuZtEbO7rwkSM6lCHov7KbqXvX Gb0/tJgkpAgkGY7ydCaviIdSXxu0BXC5t1RPNGu8WMsNuq+6/zzrh5ZuSBzux3aMio b6ZlqziOcY/+URTxzw4B+8BEpMwmDg6QZy0slxZs= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t58FbVvV007804; Mon, 8 Jun 2015 11:37:31 -0400 From: Derek Atkins To: Mike Jones References: <001c01d08399$642ed490$2c8c7db0$@augustcellars.com> <008401d08c33$504feb60$f0efc220$@augustcellars.com> <008601d08c3c$6049a570$20dcf050$@augustcellars.com> Date: Mon, 08 Jun 2015 11:37:31 -0400 In-Reply-To: (Mike Jones's message of "Sun, 7 Jun 2015 00:33:08 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Jim Schaad , "cose@ietf.org" Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 15:38:44 -0000 I guess I'm still confused... What would the structure look like for encrypting an AES-128 key with AES-256 encryption? I would expect it to look something like: JWE: { alg: aes256, data: } where is the following data, encrypted and base64 encoded: : { alg: aes128, key: } If the key used for the encryption of the JWE is not the same algorithm as the key being encrypted then you NEED to be explicit. Again, maybe I'm being confused by something because I'm not intimately familiar with the data structures. But I'll point out that this is why Kerberos has both a KeyType and EncType, because the key being encrypted could be for a different algorithm than the weapping of said key. -derek Mike Jones writes: > Replying to Derek's question " I guess my question to you (not being > as intimately familiar with JWKs) is whether the algorithm of the > wrapped (encrypted) key is exposed somewhere outside the wrapping?"... > > Yes, in JOSE, the key wrap algorithm is always explicitly declared in > the JWE "alg" header parameter > http://tools.ietf.org/html/rfc7516#section-4.1.1. Repeating the > algorithm in the equivalent of a JWK "alg" member > http://tools.ietf.org/html/rfc7517#section-4.4 would only add > redundant information, both increasing the message size, and possibly > worse, creating new error cases that would have to be checked for. > For instance, a new error that this approach would introduce that is > impossible for JWE encrypted_key values is for the two algorithm > declarations not to match. It's simpler and less error prone when the > data structure can't represent such inconsistent states in the first > place. > > Cheers, > -- Mike > > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: Tuesday, May 12, 2015 11:16 AM > To: Mike Jones > Cc: Jim Schaad; 'Derek Atkins'; cose@ietf.org > Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients > > Mike Jones writes: > >> What was presented to the JOSE working group in Denver by Richard Barnes was the option of representing encrypted keys as encrypted JWK structures, rather than just encrypted bare keys. The choice is between encrypting: >> {"kty":"oct", >> "alg":"A128KW", >> "k":"GawgguFyGrWKav7AX4VKUg"} >> or simply the bytes that "k" represents in base64url encoded form. Encrypting just the bytes is smaller, and contains no redundant information that will simply be discarded. > > Is it necesarily redundant? What says that the key being encrypted > (wrapped) is of the exact same algorithm/size/mode as the method being used to encrypt/wrap it? > > E.g., I can certainly posit a situation where I am encrypting an AES-128-CCM key with an AES-256-GCM key (Or even more, I could see encrypting a 3DES key with AES). In this case the extra information is definitely not redundant, and is certainly not derivable just from 'k'. > > I guess my question to you (not being as intimately familiar with JWKs) is whether the algorithm of the wrapped (encrypted) key is exposed somewhere outside the wrapping? > >> That's why the JOSE working group rejected using encrypted JWKs as >> the encrypted_key representation. If the "encrypt structure" you're >> referring to is different than this, it would probably be good to >> explain what it is, how you're proposing to reuse it, and why >> reusing it doesn't add extraneous unused information, as Richard's >> proposal in Denver did. > > ... > >> -- Mike > > -derek > >> -----Original Message----- >> From: Jim Schaad [mailto:ietf@augustcellars.com] >> Sent: Monday, May 11, 2015 11:47 PM >> To: Mike Jones; 'Derek Atkins' >> Cc: cose@ietf.org >> Subject: RE: [Cose] Issue: Reuse the Enrypt structure for recipients >> >> I don't understand what you are arguing for or against. >> >> Are you saying don't do the reuse of the structure? >> Are you saying don't do the extra tagging of encrypted key vs >> encrypted content? >> Are you saying something completely different? >> >> jim >> >>> -----Original Message----- >>> From: Mike Jones [mailto:Michael.Jones@microsoft.com] >>> Sent: Monday, May 11, 2015 3:25 PM >>> To: Jim Schaad; 'Derek Atkins' >>> Cc: cose@ietf.org >>> Subject: RE: [Cose] Issue: Reuse the Enrypt structure for recipients >>> >>> From my point of view, the JOSE WG didn't reject encrypting a JWK to >>> represent the encrypted key because it was a change. The working >>> group rejected it because there was no need to carry any data that >>> would remain unused about the encrypted key, when just the the >>> encrypted key value >> itself >>> would do. Particularly in a space-constrained environment, carrying >>> extra metadata about a key that will only be discarded seems wasteful >>> in the extreme. >>> >>> I would advocate having the encrypted_key value remain only an >>> encrypted form of the CEK value, adding nothing extra. >>> >>> - Mike >>> >>> -----Original Message----- >>> From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad >>> Sent: Monday, May 11, 2015 10:42 PM >>> To: 'Derek Atkins' >>> Cc: cose@ietf.org >>> Subject: Re: [Cose] Issue: Reuse the Enrypt structure for recipients >>> >>> At the present time, that information can easily be inferred by context. >> In the >>> event that we want to talk about use the "recipient" structure as a >>> top >> level >>> object then I think this question would need to be revisited. >>> >>> Jim >>> >>> >>> > -----Original Message----- >>> > From: Derek Atkins [mailto:derek@ihtfp.com] >>> > Sent: Monday, May 11, 2015 8:23 AM >>> > To: Jim Schaad >>> > Cc: cose@ietf.org >>> > Subject: Re: [Cose] Issue: Reuse the Enrypt structure for >>> > recipients >>> > >>> > I believe that yes, the map should be reused, however if we do that >>> > I wonder whether you need to add a tag that says whether it's an >>> > encrypted key or encrypted 'data'? >>> > >>> > -derek >>> > >>> > "Jim Schaad" writes: >>> > >>> > > Question: Reuse Encrypt body map for recipients >>> > > >>> > > Discussion: >>> > > >>> > > The concept of using the same structure for both recipients and >>> > > the base encryption map was introduced to the JOSE working group >>> > > at the Denver meeting. The JOSE working group rejected the idea >>> > > as being too much of a change to make in the current working code. >>> > > The concept is that the same data structure, with the same >>> > > elements is used to encode both the content encryption and each >>> > > of the recipient >>> structures. >>> > > While in JOSE, many of the same elements are not present in the >>> > > recipient structure (i.e. iv and aad), some of these elements >>> > > later appeared as part of algorithm descriptions (iv is a header >>> > > parameter >>> > defined for AES-GCM key wrapping). >>> > > >>> > > Using the same structure for encrypting content as well as >>> > > encrypting keys allows for some neat tricks to be played at a >>> > > later date if needed. One example is that you could separate the >>> > > key wrapping algorithm, and the ECDH-KDF algorithm pair into >>> > > separate layers. This allows one to move towards a Chinese Menu >>> > > method of selecting and using algorithms rather than the current >>> > > algorithm suite >>> method. >>> > > While I would not recommend that this happen in the current >>> > > specification, it might be nice to keep it open as an option to >>> > > be used >>> in the >>> > future as new algorithms are added. >>> > > >>> > > Another advantage of doing this folding is in code size. In my >>> > > implementation, I have created the recipient class as inheriting >>> > > from the encryption body class. The recipient class contains >>> > > only code that deals with the cryptography of key management. >>> > > All of the >>> > encoding/decoding is >>> > > handled by the base encryption class. If the structures are kept >>> separate >>> > > as they are today then that code would need to be added to the >>> > > recipient class. While my code does not currently deal with idea >>> > > of having multiple layers of key management. I believe that this >>> > > would be a minimal addition to the current code base. >>> > > >>> > > >>> > > _______________________________________________ >>> > > Cose mailing list >>> > > Cose@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/cose >>> > > >>> > > >>> > >>> > -- >>> > Derek Atkins 617-623-3745 >>> > derek@ihtfp.com www.ihtfp.com >>> > Computer and Internet Security Consultant >>> >>> _______________________________________________ >>> Cose mailing list >>> Cose@ietf.org >>> https://www.ietf.org/mailman/listinfo/cose >> >> >> -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Jun 10 18:02:46 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2B31A0235 for ; Wed, 10 Jun 2015 18:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 Be4SQJ3-IIAu for ; Wed, 10 Jun 2015 18:02:43 -0700 (PDT) Received: from out4133-98.mail.aliyun.com (out4133-98.mail.aliyun.com [42.120.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id B98FC1A038D for ; Wed, 10 Jun 2015 18:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1433984561; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=fWJLPcoGPRNoLmaKyXZeHnR9iz7FYLeQhKo4rPwYleM=; b=cyYGOa7OrBARqJF7rLDjG8+oMFTyx2EaHSqCVwDGCBWjLPVbDLaakqy7m9ZPTYVB4G3rFp5s/Y4YYrKCxypvYfZT82aOHMGT5J+ctFz3t270xjjpiSzG4NmZov/uxDD86N/TL8wh/5Rlpa6Ekzc+05PEljI9tOL9qkol1XF/cuo= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R171e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41f05021; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=3; RT=3; SR=0; Received: from 10.1.147.12(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.162) by smtp.aliyun-inc.com(127.0.0.1); Thu, 11 Jun 2015 09:02:37 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Thu, 11 Jun 2015 09:02:34 +0800 From: "Kepeng Li" To: Mike Jones , Jim Schaad , "cose@ietf.org" Message-ID: Thread-Topic: Algorithm draft Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Subject: [Cose] Algorithm draft X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 01:02:45 -0000 Currently, we have received feedback from Mike to have a separate algorithm draft.=20 Any other feedback? Also, we need to find somebody to write the algorithm draft, if we decide to have a separate one. Any volunteers? Thanks, Kind Regards Kepeng =D4=DA 6/6/15 11:04 am=A3=AC "Mike Jones" =D0=B4=C8=EB: >For what it's worth, I'd advocate having a separate algorithm document >for the same reasons that JOSE did. For one, it enables that document to >be revised in the future without having to then revise the underlying >signature/MAC/encryption/key representations. > >Also, based on my experience as a JOSE editor, I think the result was >cleaner because we separated the algorithm descriptions from the >descriptions of how to perform cryptographic operations. It was good >discipline to have to describe the steps to create and use the data >structures without falling back on particulars of specific algorithms. > >Also, the single-purpose nature of an algorithms doc can make it easier >to read and use a reference. You're not having to sort out what are data >descriptions and what are algorithm descriptions. It's just algorithms. > > Cheers, > -- Mike > >P.S. I agree with Jim's procedural point that the charter allows the >working group to produce deliverables either in combined or separated >documents. > >-----Original Message----- >From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad >Sent: Friday, June 05, 2015 7:31 PM >To: 'Kepeng Li'; cose@ietf.org >Subject: Re: [Cose] FW: New Version Notification for >draft-schaad-cose-02.txt > > >> -----Original Message----- >> From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Kepeng Li >> Sent: Friday, June 05, 2015 6:49 PM >> To: Jim Schaad; cose@ietf.org >> Subject: Re: [Cose] FW: New Version Notification for >>draft-schaad-cose-02. >txt >> >> Hi Jim, >> >> Thanks for the draft. >> >> >I am willing to add the algorithms piece to this document if that is >> >the desire of the group, or it can be done as an independent document >> >(my initial preference).edx >> >> >> According to our milestones, the algorithm piece is a separate item. > >That just says that we need a document to cover that milestone. It can >be a single document or a combined document as the working group feels >best. > >Jim > >> >> Jun 2015 - Submit COSE specification as a WG item >> Jun 2015 - Submit COSE constrained-appropriate algorithms as a WG >> item >> >> >> Kind Regards >> Kepeng >> >> =D4=DA 6/6/15 8:37 am=A3=AC "Jim Schaad" =D0=B4=C8=EB: >> >> >Since we now have an official working group. I will propose this as >> >a candidate draft to address the specification milestone. >> > >> >I am willing to add the algorithms piece to this document if that is >> >the desire of the group, or it can be done as an independent document >> >(my initial preference). >> > >> >Jim >> > >> > >> >> -----Original Message----- >> >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> >> Sent: Friday, June 05, 2015 5:22 PM >> >> To: Jim Schaad; Jim Schaad >> >> Subject: New Version Notification for draft-schaad-cose-02.txt >> >> >> >> >> >> A new version of I-D, draft-schaad-cose-02.txt has been >> >>successfully submitted by Jim Schaad and posted to the IETF >>repository. >> >> >> >> Name: draft-schaad-cose >> >> Revision: 02 >> >> Title: CBOR Encoded Message Syntax >> >> Document date: 2015-06-05 >> >> Group: Individual Submission >> >> Pages: 35 >> >> URL: >> >>https://www.ietf.org/internet-drafts/draft-schaad-cose-02.txt >> >> Status: https://datatracker.ietf.org/doc/draft-schaad-cose/ >> >> Htmlized: https://tools.ietf.org/html/draft-schaad-cose-02 >> >> Diff: =20 >>https://www.ietf.org/rfcdiff?url2=3Ddraft-schaad-cose-02 >> >> >> >> Abstract: >> >> Concise Binary Object Representation (CBOR) is data format >>designed >> >> for small code size and small message size. There is a need for >>the >> >> ability to have the basic security services defined for this data >> >> format. This document specifies how to do signatures, message >> >> authentication codes and encryption using this data format. The >work >> >> in this document is derived in part from the JSON web security >> >> documents using the same parameters and algorithm identifiers as >they >> >> do. >> >> >> >> >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> >>submission until the htmlized version and diff are available at >> >>tools.ietf.org. >> >> >> >> The IETF Secretariat >> > >> >_______________________________________________ >> >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 > >_______________________________________________ >Cose mailing list >Cose@ietf.org >https://www.ietf.org/mailman/listinfo/cose From nobody Wed Jun 10 22:18:09 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32FEA1A90B3 for ; Wed, 10 Jun 2015 22:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 647McZtgwR7H for ; Wed, 10 Jun 2015 22:18:06 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2883A1A90AE for ; Wed, 10 Jun 2015 22:18:06 -0700 (PDT) Received: from hebrews (unknown [50.109.226.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 5714D2C9E7; Wed, 10 Jun 2015 22:17:54 -0700 (PDT) From: "Jim Schaad" To: "'Kepeng Li'" , References: In-Reply-To: Date: Wed, 10 Jun 2015 22:17:50 -0700 Message-ID: <004701d0a406$01b088d0$05119a70$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 thread-index: AQFYUUpjDoi1hjauk2Dx1fFZPoh2XJ6XaPIw Content-Language: en-us Archived-At: Subject: Re: [Cose] Algorithm draft X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 05:18:08 -0000 > -----Original Message----- > From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Kepeng Li > Sent: Wednesday, June 10, 2015 6:03 PM > To: Mike Jones; Jim Schaad; cose@ietf.org > Subject: [Cose] Algorithm draft > > Currently, we have received feedback from Mike to have a separate algorithm > draft. > > Any other feedback? > > Also, we need to find somebody to write the algorithm draft, if we decide to > have a separate one. > > Any volunteers? While I am willing to do this, I would prefer if it were somebody else if the document is separate. I object going to WG meetings where you only have one person who is doing the presentations. On the other hand, please remember the aggressive schedule that we are trying to keep for this group. Jim > > Thanks, > > Kind Regards > Kepeng > > $B:_(B 6/6/15 11:04 am$B!$(B "Mike Jones" $B > >For what it's worth, I'd advocate having a separate algorithm document > >for the same reasons that JOSE did. For one, it enables that document > >to be revised in the future without having to then revise the > >underlying signature/MAC/encryption/key representations. > > > >Also, based on my experience as a JOSE editor, I think the result was > >cleaner because we separated the algorithm descriptions from the > >descriptions of how to perform cryptographic operations. It was good > >discipline to have to describe the steps to create and use the data > >structures without falling back on particulars of specific algorithms. > > > >Also, the single-purpose nature of an algorithms doc can make it easier > >to read and use a reference. You're not having to sort out what are > >data descriptions and what are algorithm descriptions. It's just algorithms. > > > > Cheers, > > -- Mike > > > >P.S. I agree with Jim's procedural point that the charter allows the > >working group to produce deliverables either in combined or separated > >documents. > > > >-----Original Message----- > >From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad > >Sent: Friday, June 05, 2015 7:31 PM > >To: 'Kepeng Li'; cose@ietf.org > >Subject: Re: [Cose] FW: New Version Notification for > >draft-schaad-cose-02.txt > > > > > >> -----Original Message----- > >> From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Kepeng Li > >> Sent: Friday, June 05, 2015 6:49 PM > >> To: Jim Schaad; cose@ietf.org > >> Subject: Re: [Cose] FW: New Version Notification for > >>draft-schaad-cose-02. > >txt > >> > >> Hi Jim, > >> > >> Thanks for the draft. > >> > >> >I am willing to add the algorithms piece to this document if that is > >> >the desire of the group, or it can be done as an independent > >> >document (my initial preference).edx > >> > >> > >> According to our milestones, the algorithm piece is a separate item. > > > >That just says that we need a document to cover that milestone. It can > >be a single document or a combined document as the working group feels > >best. > > > >Jim > > > >> > >> Jun 2015 - Submit COSE specification as a WG item > >> Jun 2015 - Submit COSE constrained-appropriate algorithms as a WG > >> item > >> > >> > >> Kind Regards > >> Kepeng > >> > >> $B:_(B 6/6/15 8:37 am$B!$(B "Jim Schaad" $B >> > >> >Since we now have an official working group. I will propose this as > >> >a candidate draft to address the specification milestone. > >> > > >> >I am willing to add the algorithms piece to this document if that is > >> >the desire of the group, or it can be done as an independent > >> >document (my initial preference). > >> > > >> >Jim > >> > > >> > > >> >> -----Original Message----- > >> >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> >> Sent: Friday, June 05, 2015 5:22 PM > >> >> To: Jim Schaad; Jim Schaad > >> >> Subject: New Version Notification for draft-schaad-cose-02.txt > >> >> > >> >> > >> >> A new version of I-D, draft-schaad-cose-02.txt has been > >> >>successfully submitted by Jim Schaad and posted to the IETF > >>repository. > >> >> > >> >> Name: draft-schaad-cose > >> >> Revision: 02 > >> >> Title: CBOR Encoded Message Syntax > >> >> Document date: 2015-06-05 > >> >> Group: Individual Submission > >> >> Pages: 35 > >> >> URL: > >> >>https://www.ietf.org/internet-drafts/draft-schaad-cose-02.txt > >> >> Status: https://datatracker.ietf.org/doc/draft-schaad-cose/ > >> >> Htmlized: https://tools.ietf.org/html/draft-schaad-cose-02 > >> >> Diff: > >>https://www.ietf.org/rfcdiff?url2=draft-schaad-cose-02 > >> >> > >> >> Abstract: > >> >> Concise Binary Object Representation (CBOR) is data format > >>designed > >> >> for small code size and small message size. There is a need > >> >> for > >>the > >> >> ability to have the basic security services defined for this data > >> >> format. This document specifies how to do signatures, message > >> >> authentication codes and encryption using this data format. > >> >> The > >work > >> >> in this document is derived in part from the JSON web security > >> >> documents using the same parameters and algorithm identifiers > >> >> as > >they > >> >> do. > >> >> > >> >> > >> >> > >> >> > >> >> Please note that it may take a couple of minutes from the time of > >> >>submission until the htmlized version and diff are available at > >> >>tools.ietf.org. > >> >> > >> >> The IETF Secretariat > >> > > >> >_______________________________________________ > >> >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 > > > >_______________________________________________ > >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 Thu Jun 11 10:10:39 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410201A03C7 for ; Thu, 11 Jun 2015 10:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 APzg2DkfnVvY for ; Thu, 11 Jun 2015 10:10:36 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0773.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::773]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D8B01A0145 for ; Thu, 11 Jun 2015 10:10:35 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.195.6; Thu, 11 Jun 2015 17:10:18 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0195.005; Thu, 11 Jun 2015 17:10:18 +0000 From: Mike Jones To: Jim Schaad , 'Kepeng Li' , "cose@ietf.org" Thread-Topic: [Cose] Algorithm draft Thread-Index: AQHQo+JULTFPLWJliECVCdPyo+Ygop2mxCcAgADGdTA= Date: Thu, 11 Jun 2015 17:10:18 +0000 Message-ID: References: <004701d0a406$01b088d0$05119a70$@augustcellars.com> In-Reply-To: <004701d0a406$01b088d0$05119a70$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e8:ee31::2] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:RCOVD0qMhqhK/80buRwrEEVP3/r3YNWl7kIRJKW7Xe8x81EhvQGXjQH7yZbIIkryiWcL3mpWbTCVFeRhIlWlT9mQDVsH56EzslB/XqsgkvGJWBbckU6UlOpwU0T9sxrM3+6ToX95L3IZZZFZSSUzbw==; 24:HH8+nDI3uw1+/r9EwG0z67SBFeaaKKUC0tJjPoWCpnGmIo/fy/37P6t08hnIA+BmNjtcFOsFuxO3tz5NE6ae2s6Z7acz+ui7eAfWlaeDBPY=; 20:PYfIccpSC+JUym4kP0NMeO1GuvNdbQ+p9NKRMsBPIVJXHmp5/agbn+flDSJfbT5Ep0DoQmxnHRk70aVowckHSg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 0604AFA86B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(51414003)(51914003)(377454003)(13464003)(377424004)(51704005)(71364002)(164054003)(19580405001)(76176999)(2900100001)(15975445007)(19580395003)(77096005)(102836002)(40100003)(2656002)(54356999)(50986999)(2950100001)(86362001)(74316001)(189998001)(5001770100001)(2501003)(5002640100001)(106116001)(77156002)(62966003)(92566002)(87936001)(107886002)(5001960100002)(5001920100001)(5003600100002)(33656002)(76576001)(46102003)(122556002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2015 17:10:18.8095 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Subject: Re: [Cose] Algorithm draft X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 17:10:38 -0000 I'd be glad to do this. I look forward to helping us get these specs out q= uickly in ways that meet the use cases people have. Cheers, -- Mike -----Original Message----- From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Wednesday, June 10, 2015 10:18 PM To: 'Kepeng Li'; cose@ietf.org Subject: Re: [Cose] Algorithm draft > -----Original Message----- > From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Kepeng Li > Sent: Wednesday, June 10, 2015 6:03 PM > To: Mike Jones; Jim Schaad; cose@ietf.org > Subject: [Cose] Algorithm draft > > Currently, we have received feedback from Mike to have a separate algorithm > draft. > > Any other feedback? > > Also, we need to find somebody to write the algorithm draft, if we=20 > decide to > have a separate one. > > Any volunteers? While I am willing to do this, I would prefer if it were somebody else if t= he document is separate. I object going to WG meetings where you only have= one person who is doing the presentations. On the other hand, please reme= mber the aggressive schedule that we are trying to keep for this group. Jim > > Thanks, > > Kind Regards > Kepeng > > =1B$B:_=1B(B 6/6/15 11:04 am=1B$B!$=1B(B "Mike Jones" =1B$B > >For what it's worth, I'd advocate having a separate algorithm=20 > >document for the same reasons that JOSE did. For one, it enables=20 > >that document to be revised in the future without having to then=20 > >revise the underlying signature/MAC/encryption/key representations. > > > >Also, based on my experience as a JOSE editor, I think the result was=20 > >cleaner because we separated the algorithm descriptions from the=20 > >descriptions of how to perform cryptographic operations. It was good=20 > >discipline to have to describe the steps to create and use the data=20 > >structures without falling back on particulars of specific algorithms. > > > >Also, the single-purpose nature of an algorithms doc can make it=20 > >easier to read and use a reference. You're not having to sort out=20 > >what are data descriptions and what are algorithm descriptions. It's=20 > >just algorithms. > > > > Cheers, > > -- Mike > > > >P.S. I agree with Jim's procedural point that the charter allows the=20 > >working group to produce deliverables either in combined or separated=20 > >documents. > > > >-----Original Message----- > >From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad > >Sent: Friday, June 05, 2015 7:31 PM > >To: 'Kepeng Li'; cose@ietf.org > >Subject: Re: [Cose] FW: New Version Notification for=20 > >draft-schaad-cose-02.txt > > > > > >> -----Original Message----- > >> From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Kepeng Li > >> Sent: Friday, June 05, 2015 6:49 PM > >> To: Jim Schaad; cose@ietf.org > >> Subject: Re: [Cose] FW: New Version Notification for=20 > >>draft-schaad-cose-02. > >txt > >> > >> Hi Jim, > >> > >> Thanks for the draft. > >> > >> >I am willing to add the algorithms piece to this document if that=20 > >> >is the desire of the group, or it can be done as an independent=20 > >> >document (my initial preference).edx > >> > >> > >> According to our milestones, the algorithm piece is a separate item. > > > >That just says that we need a document to cover that milestone. It=20 > >can be a single document or a combined document as the working group=20 > >feels best. > > > >Jim > > > >> > >> Jun 2015 - Submit COSE specification as a WG item > >> Jun 2015 - Submit COSE constrained-appropriate algorithms as a WG=20 > >> item > >> > >> > >> Kind Regards > >> Kepeng > >> > >> =1B$B:_=1B(B 6/6/15 8:37 am=1B$B!$=1B(B "Jim Schaad" =1B$B >> > >> >Since we now have an official working group. I will propose this=20 > >> >as a candidate draft to address the specification milestone. > >> > > >> >I am willing to add the algorithms piece to this document if that=20 > >> >is the desire of the group, or it can be done as an independent=20 > >> >document (my initial preference). > >> > > >> >Jim > >> > > >> > > >> >> -----Original Message----- > >> >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> >> Sent: Friday, June 05, 2015 5:22 PM > >> >> To: Jim Schaad; Jim Schaad > >> >> Subject: New Version Notification for draft-schaad-cose-02.txt > >> >> > >> >> > >> >> A new version of I-D, draft-schaad-cose-02.txt has been=20 > >> >>successfully submitted by Jim Schaad and posted to the IETF > >>repository. > >> >> > >> >> Name: draft-schaad-cose > >> >> Revision: 02 > >> >> Title: CBOR Encoded Message Syntax > >> >> Document date: 2015-06-05 > >> >> Group: Individual Submission > >> >> Pages: 35 > >> >> URL: > >> >>https://www.ietf.org/internet-drafts/draft-schaad-cose-02.txt > >> >> Status: https://datatracker.ietf.org/doc/draft-schaad-cose/ > >> >> Htmlized: https://tools.ietf.org/html/draft-schaad-cose-02 > >> >> Diff: > >>https://www.ietf.org/rfcdiff?url2=3Ddraft-schaad-cose-02 > >> >> > >> >> Abstract: > >> >> Concise Binary Object Representation (CBOR) is data format > >>designed > >> >> for small code size and small message size. There is a need=20 > >> >> for > >>the > >> >> ability to have the basic security services defined for this dat= a > >> >> format. This document specifies how to do signatures, message > >> >> authentication codes and encryption using this data format. > >> >> The > >work > >> >> in this document is derived in part from the JSON web security > >> >> documents using the same parameters and algorithm identifiers=20 > >> >> as > >they > >> >> do. > >> >> > >> >> > >> >> > >> >> > >> >> Please note that it may take a couple of minutes from the time=20 > >> >>of submission until the htmlized version and diff are available=20 > >> >>at tools.ietf.org. > >> >> > >> >> The IETF Secretariat > >> > > >> >_______________________________________________ > >> >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 > > > >_______________________________________________ > >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 _______________________________________________ Cose mailing list Cose@ietf.org https://www.ietf.org/mailman/listinfo/cose From nobody Thu Jun 11 10:33:20 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E963F1A8887 for ; Thu, 11 Jun 2015 10:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Kw2LqpxUXjDN for ; Thu, 11 Jun 2015 10:33:17 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 251051A886B for ; Thu, 11 Jun 2015 10:33:15 -0700 (PDT) X-AuditID: 12074425-f79076d000000db5-0d-5579c65a6c17 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 84.2A.03509.A56C9755; Thu, 11 Jun 2015 13:33:14 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t5BHXDHk003882 for ; Thu, 11 Jun 2015 13:33:14 -0400 Received: from [192.168.2.154] ([12.217.69.145]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t5BHXBIH026298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 11 Jun 2015 13:33:13 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_298D9FB9-3AD9-4063-8712-DFBBD45ED6A0" Message-Id: <3032DD54-1B5B-4CD7-A72C-2CA8517B5E5F@mit.edu> Date: Thu, 11 Jun 2015 10:33:10 -0700 To: cose@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsUixCmqrBt1rDLUYGOjiMW0rVNZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8ezXNsaCi1IVE7ccZW5gPCnWxcjJISFgIrFoZTszhC0mceHe erYuRi4OIYHFTBKP3kxghHCOMkr8+HWaCaRKSOAgk8SUVUkgNpuAqsT8lbfA4swCCRJ/X/0D s4UFFCRer5nFCmLzClhJ/L17FCzOAlT/694b9i5GDg4RAUGJu53mECV6Eo+ePgYLSwjISnzd KjeBkXcWkqGzkFRBxLUlli18zQxha0rs717OgimuIdH5bSLrAka2VYyyKblVurmJmTnFqcm6 xcmJeXmpRboWermZJXqpKaWbGEEBye6iuoNxwiGlQ4wCHIxKPLwVJypChVgTy4orcw8xSnIw KYnyNh6sDBXiS8pPqcxILM6ILyrNSS0+xCjBwawkwtu5FSjHm5JYWZValA+TkuZgURLn3fSD L0RIID2xJDU7NbUgtQgmK8PBoSTBy3gUqFGwKDU9tSItM6cEIc3EwQkynAdouC5IDW9xQWJu cWY6RP4Uo6KUOC8/SEIAJJFRmgfXC0sYrxjFgV4R5v14BKiKB5hs4LpfAQ1mAhq8kLkcZHBJ IkJKqoGR6Z0Lh8Q/bmGfQw/Wm0ya3HHzbOuZtZIii3++FUtn6No265x6gmHZ/oZFL9xr1y6d mztnAaPX65Ru543qex+Xz9v44/uXjWuc1+0r37s161iy3asTfJtvO0dLBpvdK/2ld+LWPPe7 oXtzff7NmHao1G7TRt1oVTZuz+qz37i+7gnQKs6eox4QqsRSnJFoqMVcVJwIABQhTPzzAgAA Archived-At: Subject: [Cose] Call for Draft Adoption X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 17:33:19 -0000 --Apple-Mail=_298D9FB9-3AD9-4063-8712-DFBBD45ED6A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We=E2=80=99re starting a two week review period to determine a potential = starting draft for the COSE work. So far, there has been one potential = draft submitted: https://tools.ietf.org/html/draft-schaad-cose-02 = During this two week period, please review the above draft and comment = to the list whether you think it is a reasonable starting point for the = COSE work, or not. If not, please submit an alternative draft and = present it to the list. At the end of the two week period, the chairs will do a consensus call. = If there=E2=80=99s rough consensus to adopt this (or another) draft, = we=E2=80=99ll turn it into a working group document and get it started = before Prague. Things to keep in mind during this review: - This draft will be the starting point, not the ending point.=20 - There will be many opportunities to edit and alter the document = before it=E2=80=99s final. - If you have major contentions with the document, please bring them = up, particularly if you have a way to fix them. - Please be willing to submit text as well as ideas. =E2=80=94 Justin= --Apple-Mail=_298D9FB9-3AD9-4063-8712-DFBBD45ED6A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We=E2=80=99re starting a two week review period to determine = a potential starting draft for the COSE work. So far, there has been one = potential draft submitted:

https://tools.ietf.org/html/draft-schaad-cose-02

During this two week = period, please review the above draft and comment to the list whether = you think it is a reasonable starting point for the COSE work, or not. = If not, please submit an alternative draft and present it to the = list.

At the = end of the two week period, the chairs will do a consensus call. If = there=E2=80=99s rough consensus to adopt this (or another) draft, = we=E2=80=99ll turn it into a working group document and get it started = before Prague.

Things to keep in mind during this review:

 - This draft will = be the starting point, not the ending point. 
 - There will be many opportunities to edit and alter = the document before it=E2=80=99s final.
 - If = you have major contentions with the document, please bring them up, = particularly if you have a way to fix them.
 - = Please be willing to submit text as well as ideas.

 =E2=80=94 = Justin
= --Apple-Mail=_298D9FB9-3AD9-4063-8712-DFBBD45ED6A0-- From nobody Thu Jun 11 14:29:19 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5AE1AD244 for ; Thu, 11 Jun 2015 14:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 VB8pLmeP7-Nw for ; Thu, 11 Jun 2015 14:29:14 -0700 (PDT) Received: from mail-ig0-f179.google.com (na3sys009aog108.obsmtp.com [74.125.149.199]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11E1A1A8851 for ; Thu, 11 Jun 2015 14:29:14 -0700 (PDT) Received: from mail-ig0-f179.google.com ([209.85.213.179]) (using TLSv1) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKVXn9qUJqDfErjrIPx+2/vFBp6LT224XU@postini.com; Thu, 11 Jun 2015 14:29:14 PDT Received: by igblz2 with SMTP id lz2so12994027igb.1 for ; Thu, 11 Jun 2015 14:29:13 -0700 (PDT) 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-type; bh=7Mhp82QylF8F0mquOaiIoLCO8QFI/KVZ9Yyj90eLEvY=; b=dvIZ2jq/So8378NWd2PJIIrenuJgaA4E51+/jk8hJWI1U9HOScQEWqp6y6FRLcKwCR yy/6tf4KawQ27g8IdShUelJ29RijbFBdq0neRkUM9ji0dqoxamUSMzoY27OLaP3qYEBZ nizuOQrx2F7R5cpKHGRXdOQnHiEFpgXYBo89ixv2MD8gcAFXhKfdXKRmA2EzTkPv/FUV 4/EFJen94aQv/GPgRibKlu4oDDEDGs9Uut9nW1LqzMdYp030zGiyhwkg+tQERFboH/U0 VF2oGTLihsqh237dXa2nP4KjSgkCnkwnGJoNax5S004FqQM3LATcZAeLxqQFINi0AU1t UluQ== X-Gm-Message-State: ALoCoQkbaK7oiNJ4kiBeqg4WFjQiGa4aI1ptbY7IJhag6Yss+zkoTwd0Jk/5n15g8yciC5Qc7O7UIWn1fq/1VWK5oYkC9PpYQwSsJ1LeAdDQIZtY48EnmJEIWisOO5RMXMTtkm6VXyS3 X-Received: by 10.50.78.170 with SMTP id c10mr486357igx.0.1434058153177; Thu, 11 Jun 2015 14:29:13 -0700 (PDT) X-Received: by 10.50.78.170 with SMTP id c10mr486347igx.0.1434058153031; Thu, 11 Jun 2015 14:29:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.64.209 with HTTP; Thu, 11 Jun 2015 14:28:42 -0700 (PDT) In-Reply-To: References: <004701d0a406$01b088d0$05119a70$@augustcellars.com> From: Brian Campbell Date: Thu, 11 Jun 2015 14:28:42 -0700 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=089e0122e688cc9704051844aed8 Archived-At: Cc: Jim Schaad , Kepeng Li , "cose@ietf.org" Subject: Re: [Cose] Algorithm draft X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 21:29:17 -0000 --089e0122e688cc9704051844aed8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99d be willing to help Mike with a separate algorithms draft. On Thu, Jun 11, 2015 at 10:10 AM, Mike Jones wrote: > I'd be glad to do this. I look forward to helping us get these specs out > quickly in ways that meet the use cases people have. > > Cheers, > -- Mike > > -----Original Message----- > From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Wednesday, June 10, 2015 10:18 PM > To: 'Kepeng Li'; cose@ietf.org > Subject: Re: [Cose] Algorithm draft > > > > > -----Original Message----- > > From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Kepeng Li > > Sent: Wednesday, June 10, 2015 6:03 PM > > To: Mike Jones; Jim Schaad; cose@ietf.org > > Subject: [Cose] Algorithm draft > > > > Currently, we have received feedback from Mike to have a separate > algorithm > > draft. > > > > Any other feedback? > > > > Also, we need to find somebody to write the algorithm draft, if we > > decide > to > > have a separate one. > > > > Any volunteers? > > While I am willing to do this, I would prefer if it were somebody else if > the document is separate. I object going to WG meetings where you only > have one person who is doing the presentations. On the other hand, pleas= e > remember the aggressive schedule that we are trying to keep for this grou= p. > > Jim > > > > > Thanks, > > > > Kind Regards > > Kepeng > > > > =E5=9C=A8 6/6/15 11:04 am=EF=BC=8C "Mike Jones" =E5=86=99=E5=85=A5: > > > > >For what it's worth, I'd advocate having a separate algorithm > > >document for the same reasons that JOSE did. For one, it enables > > >that document to be revised in the future without having to then > > >revise the underlying signature/MAC/encryption/key representations. > > > > > >Also, based on my experience as a JOSE editor, I think the result was > > >cleaner because we separated the algorithm descriptions from the > > >descriptions of how to perform cryptographic operations. It was good > > >discipline to have to describe the steps to create and use the data > > >structures without falling back on particulars of specific algorithms. > > > > > >Also, the single-purpose nature of an algorithms doc can make it > > >easier to read and use a reference. You're not having to sort out > > >what are data descriptions and what are algorithm descriptions. It's > > >just > algorithms. > > > > > > Cheers, > > > -- Mike > > > > > >P.S. I agree with Jim's procedural point that the charter allows the > > >working group to produce deliverables either in combined or separated > > >documents. > > > > > >-----Original Message----- > > >From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad > > >Sent: Friday, June 05, 2015 7:31 PM > > >To: 'Kepeng Li'; cose@ietf.org > > >Subject: Re: [Cose] FW: New Version Notification for > > >draft-schaad-cose-02.txt > > > > > > > > >> -----Original Message----- > > >> From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Kepeng Li > > >> Sent: Friday, June 05, 2015 6:49 PM > > >> To: Jim Schaad; cose@ietf.org > > >> Subject: Re: [Cose] FW: New Version Notification for > > >>draft-schaad-cose-02. > > >txt > > >> > > >> Hi Jim, > > >> > > >> Thanks for the draft. > > >> > > >> >I am willing to add the algorithms piece to this document if that > > >> >is the desire of the group, or it can be done as an independent > > >> >document (my initial preference).edx > > >> > > >> > > >> According to our milestones, the algorithm piece is a separate item. > > > > > >That just says that we need a document to cover that milestone. It > > >can be a single document or a combined document as the working group > > >feels best. > > > > > >Jim > > > > > >> > > >> Jun 2015 - Submit COSE specification as a WG item > > >> Jun 2015 - Submit COSE constrained-appropriate algorithms as a WG > > >> item > > >> > > >> > > >> Kind Regards > > >> Kepeng > > >> > > >> =E5=9C=A8 6/6/15 8:37 am=EF=BC=8C "Jim Schaad" =E5=86=99=E5=85=A5: > > >> > > >> >Since we now have an official working group. I will propose this > > >> >as a candidate draft to address the specification milestone. > > >> > > > >> >I am willing to add the algorithms piece to this document if that > > >> >is the desire of the group, or it can be done as an independent > > >> >document (my initial preference). > > >> > > > >> >Jim > > >> > > > >> > > > >> >> -----Original Message----- > > >> >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > >> >> Sent: Friday, June 05, 2015 5:22 PM > > >> >> To: Jim Schaad; Jim Schaad > > >> >> Subject: New Version Notification for draft-schaad-cose-02.txt > > >> >> > > >> >> > > >> >> A new version of I-D, draft-schaad-cose-02.txt has been > > >> >>successfully submitted by Jim Schaad and posted to the IETF > > >>repository. > > >> >> > > >> >> Name: draft-schaad-cose > > >> >> Revision: 02 > > >> >> Title: CBOR Encoded Message Syntax > > >> >> Document date: 2015-06-05 > > >> >> Group: Individual Submission > > >> >> Pages: 35 > > >> >> URL: > > >> >>https://www.ietf.org/internet-drafts/draft-schaad-cose-02.txt > > >> >> Status: > https://datatracker.ietf.org/doc/draft-schaad-cose/ > > >> >> Htmlized: https://tools.ietf.org/html/draft-schaad-cose-02 > > >> >> Diff: > > >>https://www.ietf.org/rfcdiff?url2=3Ddraft-schaad-cose-02 > > >> >> > > >> >> Abstract: > > >> >> Concise Binary Object Representation (CBOR) is data format > > >>designed > > >> >> for small code size and small message size. There is a need > > >> >> for > > >>the > > >> >> ability to have the basic security services defined for this > data > > >> >> format. This document specifies how to do signatures, message > > >> >> authentication codes and encryption using this data format. > > >> >> The > > >work > > >> >> in this document is derived in part from the JSON web security > > >> >> documents using the same parameters and algorithm identifiers > > >> >> as > > >they > > >> >> do. > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> Please note that it may take a couple of minutes from the time > > >> >>of submission until the htmlized version and diff are available > > >> >>at tools.ietf.org. > > >> >> > > >> >> The IETF Secretariat > > >> > > > >> >_______________________________________________ > > >> >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 > > > > > >_______________________________________________ > > >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 > > _______________________________________________ > 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 > --089e0122e688cc9704051844aed8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I=E2=80=99d be willing to help Mike with a separate algori= thms draft.

= On Thu, Jun 11, 2015 at 10:10 AM, Mike Jones <Michael.Jones@mic= rosoft.com> wrote:
I'd = be glad to do this.=C2=A0 I look forward to helping us get these specs out = quickly in ways that meet the use cases people have.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike

-----Original Message-----
From: Cose [mailto:cose-bounces@ie= tf.org] On Behalf Of Jim Schaad
Sent: Wednesday, June 10, 2015 10:18 PM To: 'Kepeng Li'; cose@ietf.org=
Subject: Re: [Cose] Algorith= m draft



> -----Original Message-----
> From: Cose [mailto:cose-bounc= es@ietf.org] On Behalf Of Kepeng Li
> Sent: Wednesday, June 10, 2015 6:03 PM
> To: Mike Jones; Jim Schaad; cose@ietf= .org
> Subject: [Cose] Algorithm draft
>
> Currently, we have received feedback from Mike to have a separate
algorithm
> draft.
>
> Any other feedback?
>
> Also, we need to find somebody to write the algorithm draft, if we
> decide
to
> have a separate one.
>
> Any volunteers?

While I am willing to do this, I would prefer if it were somebody else if t= he document is separate.=C2=A0 I object going to WG meetings where you only= have one person who is doing the presentations.=C2=A0 On the other hand, p= lease remember the aggressive schedule that we are trying to keep for this = group.

Jim

>
> Thanks,
>
> Kind Regards
> Kepeng
>
> =E5=9C=A8 6/6/15 11:04 am=EF=BC=8C "Mike Jones" <Michael.Jones@microsoft.com>= =E5=86=99=E5=85=A5:
>
> >For what it's worth, I'd advocate having a separate algori= thm
> >document for the same reasons that JOSE did.=C2=A0 For one, it ena= bles
> >that document to be revised in the future without having to then > >revise the underlying signature/MAC/encryption/key representations= .
> >
> >Also, based on my experience as a JOSE editor, I think the result = was
> >cleaner because we separated the algorithm descriptions from the > >descriptions of how to perform cryptographic operations.=C2=A0 It = was good
> >discipline to have to describe the steps to create and use the dat= a
> >structures without falling back on particulars of specific algorit= hms.
> >
> >Also, the single-purpose nature of an algorithms doc can make it > >easier to read and use a reference.=C2=A0 You're not having to= sort out
> >what are data descriptions and what are algorithm descriptions.=C2= =A0 It's
> >just
algorithms.
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cheers,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
> >
> >P.S.=C2=A0 I agree with Jim's procedural point that the charte= r allows the
> >working group to produce deliverables either in combined or separa= ted
> >documents.
> >
> >-----Original Message-----
> >From: Cose [mailto:cose-b= ounces@ietf.org] On Behalf Of Jim Schaad
> >Sent: Friday, June 05, 2015 7:31 PM
> >To: 'Kepeng Li'; cose@iet= f.org
> >Subject: Re: [Cose] FW: New Version Notification for
> >draft-schaad-cose-02.txt
> >
> >
> >> -----Original Message-----
> >> From: Cose [mailto:c= ose-bounces@ietf.org] On Behalf Of Kepeng Li
> >> Sent: Friday, June 05, 2015 6:49 PM
> >> To: Jim Schaad; cose@ietf.or= g
> >> Subject: Re: [Cose] FW: New Version Notification for
> >>draft-schaad-cose-02.
> >txt
> >>
> >> Hi Jim,
> >>
> >> Thanks for the draft.
> >>
> >> >I am willing to add the algorithms piece to this document= if that
> >> >is the desire of the group, or it can be done as an indep= endent
> >> >document (my initial preference).edx
> >>
> >>
> >> According to our milestones, the algorithm piece is a separat= e item.
> >
> >That just says that we need a document to cover that milestone.=C2= =A0 It
> >can be a single document or a combined document as the working gro= up
> >feels best.
> >
> >Jim
> >
> >>
> >> Jun 2015 - Submit COSE specification as a WG item
> >>=C2=A0 =C2=A0Jun 2015 - Submit COSE constrained-appropriate al= gorithms as a WG
> >> item
> >>
> >>
> >> Kind Regards
> >> Kepeng
> >>
> >> =E5=9C=A8 6/6/15 8:37 am=EF=BC=8C "Jim Schaad" <= ietf@augustcellars.com> = =E5=86=99=E5=85=A5:
> >>
> >> >Since we now have an official working group.=C2=A0 I will= propose this
> >> >as a candidate draft to address the specification milesto= ne.
> >> >
> >> >I am willing to add the algorithms piece to this document= if that
> >> >is the desire of the group, or it can be done as an indep= endent
> >> >document (my initial preference).
> >> >
> >> >Jim
> >> >
> >> >
> >> >> -----Original Message-----
> >> >> From: in= ternet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> >> >> Sent: Friday, June 05, 2015 5:22 PM
> >> >> To: Jim Schaad; Jim Schaad
> >> >> Subject: New Version Notification for draft-schaad-c= ose-02.txt
> >> >>
> >> >>
> >> >> A new version of I-D, draft-schaad-cose-02.txt has b= een
> >> >>successfully submitted=C2=A0 by Jim Schaad and posted= to the IETF
> >>repository.
> >> >>
> >> >> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-= schaad-cose
> >> >> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
> >> >> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CBOR Encode= d Message Syntax
> >> >> Document date:=C2=A0 2015-06-05
> >> >> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual = Submission
> >> >> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 35
> >> >> URL:
> >> >>https://www.ietf.org/internet-drafts= /draft-schaad-cose-02.txt
> >> >> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http= s://datatracker.ietf.org/doc/draft-schaad-cose/
> >> >> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tool= s.ietf.org/html/draft-schaad-cose-02
> >> >> Diff:
> >>https://www.ietf.org/rfcdiff?url2=3Ddraft-schaad-c= ose-02
> >> >>
> >> >> Abstract:
> >> >>=C2=A0 =C2=A0 Concise Binary Object Representation (C= BOR) is data format
> >>designed
> >> >>=C2=A0 =C2=A0 for small code size and small message s= ize.=C2=A0 There is a need
> >> >> for
> >>the
> >> >>=C2=A0 =C2=A0 ability to have the basic security serv= ices defined for this data
> >> >>=C2=A0 =C2=A0 format.=C2=A0 This document specifies h= ow to do signatures, message
> >> >>=C2=A0 =C2=A0 authentication codes and encryption usi= ng this data format.
> >> >> The
> >work
> >> >>=C2=A0 =C2=A0 in this document is derived in part fro= m the JSON web security
> >> >>=C2=A0 =C2=A0 documents using the same parameters and= algorithm identifiers
> >> >> as
> >they
> >> >>=C2=A0 =C2=A0 do.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> Please note that it may take a couple of minutes fro= m the time
> >> >>of submission=C2=A0 until the htmlized version and di= ff are available
> >> >>at tools.ietf.org.
> >> >>
> >> >> The IETF Secretariat
> >> >
> >> >_______________________________________________
> >> >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
> >
> >_______________________________________________
> >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

_______________________________________________
Cose mailing list
Cose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cose

_______________________________________________
Cose mailing list
Cose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cose

--089e0122e688cc9704051844aed8-- From nobody Thu Jun 11 14:30:57 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD391A9112 for ; Thu, 11 Jun 2015 14:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 KJFxjOGAPcs0 for ; Thu, 11 Jun 2015 14:30:52 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0752.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::752]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D4461A8821 for ; Thu, 11 Jun 2015 14:30:52 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.195.6; Thu, 11 Jun 2015 21:30:33 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0195.005; Thu, 11 Jun 2015 21:30:33 +0000 From: Mike Jones To: Brian Campbell Thread-Topic: [Cose] Algorithm draft Thread-Index: AQHQo+JULTFPLWJliECVCdPyo+Ygop2mxCcAgADGdTCAAEjMAIAAAGGQ Date: Thu, 11 Jun 2015 21:30:33 +0000 Message-ID: References: <004701d0a406$01b088d0$05119a70$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: pingidentity.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e8:ee31::2] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:t/bKonBpbNvRhw/akdgAvk0zxHcfsKif9L3xPdbjYQI6ZcOOzRs29lG7fAFAaqOahLHxwJYbdW5iv9KmojlejyhrCxxEV/23Uwyy0RERWmSU6iea1Mn0UBpNwBEwyWQtOna+tZ5HzgalTbLRMxN+xQ==; 24:Hlqj46qzif0eVChkjF/4aYY0XlzYBCdNuHHnSZhgEqMaPwMCmWXo2m/CRpCogRfBuNwhF/5/bixPUVvpMRwO2iP2/cq85/TGIL2OTJclI00=; 20:uQ/79V7AOst1vwkLW+UCqmBWpPxzySIVObfZz+a87weLZTwQGLZfHdt7j2xFLfLVJ8KPYzOOpuZvSedIAMX7qg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 0604AFA86B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(479174004)(51414003)(24454002)(377454003)(13464003)(377424004)(51704005)(71364002)(164054003)(54356999)(86612001)(102836002)(16236675004)(76176999)(15975445007)(19580395003)(19580405001)(77096005)(2950100001)(2656002)(99286002)(40100003)(50986999)(86362001)(2900100001)(74316001)(189998001)(62966003)(106116001)(77156002)(5002640100001)(92566002)(87936001)(5001960100002)(5001920100001)(14971765001)(19625215002)(16601075003)(5003600100002)(19609705001)(19617315012)(76576001)(19300405004)(33656002)(46102003)(93886004)(122556002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4425DAD7A9BAFE9989ACAC3F5BC0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2015 21:30:33.0650 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Cc: Jim Schaad , Kepeng Li , "cose@ietf.org" Subject: Re: [Cose] Algorithm draft X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 21:30:56 -0000 --_000_BY2PR03MB4425DAD7A9BAFE9989ACAC3F5BC0BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmWQgYmUgaG9ub3JlZCB0byBoYXZlIEJyaWFuIGFzIGNvLWVkaXRvciBvZiB0aGUgZHJhZnQu DQoNCkZyb206IEJyaWFuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5j b21dDQpTZW50OiBUaHVyc2RheSwgSnVuZSAxMSwgMjAxNSAyOjI5IFBNDQpUbzogTWlrZSBKb25l cw0KQ2M6IEppbSBTY2hhYWQ7IEtlcGVuZyBMaTsgY29zZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtDb3NlXSBBbGdvcml0aG0gZHJhZnQNCg0KSeKAmWQgYmUgd2lsbGluZyB0byBoZWxwIE1pa2Ug d2l0aCBhIHNlcGFyYXRlIGFsZ29yaXRobXMgZHJhZnQuDQoNCk9uIFRodSwgSnVuIDExLCAyMDE1 IGF0IDEwOjEwIEFNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFp bHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KSSdkIGJlIGdsYWQgdG8g ZG8gdGhpcy4gIEkgbG9vayBmb3J3YXJkIHRvIGhlbHBpbmcgdXMgZ2V0IHRoZXNlIHNwZWNzIG91 dCBxdWlja2x5IGluIHdheXMgdGhhdCBtZWV0IHRoZSB1c2UgY2FzZXMgcGVvcGxlIGhhdmUuDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2hlZXJzLA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBDb3NlIFttYWlsdG86Y29zZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpjb3NlLWJvdW5j ZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgSmltIFNjaGFhZA0KU2VudDogV2VkbmVzZGF5LCBK dW5lIDEwLCAyMDE1IDEwOjE4IFBNDQpUbzogJ0tlcGVuZyBMaSc7IGNvc2VAaWV0Zi5vcmc8bWFp bHRvOmNvc2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0Nvc2VdIEFsZ29yaXRobSBkcmFmdA0K DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBDb3NlIFttYWlsdG86 Y29zZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpjb3NlLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBC ZWhhbGYgT2YgS2VwZW5nIExpDQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAxMCwgMjAxNSA2OjAz IFBNDQo+IFRvOiBNaWtlIEpvbmVzOyBKaW0gU2NoYWFkOyBjb3NlQGlldGYub3JnPG1haWx0bzpj b3NlQGlldGYub3JnPg0KPiBTdWJqZWN0OiBbQ29zZV0gQWxnb3JpdGhtIGRyYWZ0DQo+DQo+IEN1 cnJlbnRseSwgd2UgaGF2ZSByZWNlaXZlZCBmZWVkYmFjayBmcm9tIE1pa2UgdG8gaGF2ZSBhIHNl cGFyYXRlDQphbGdvcml0aG0NCj4gZHJhZnQuDQo+DQo+IEFueSBvdGhlciBmZWVkYmFjaz8NCj4N Cj4gQWxzbywgd2UgbmVlZCB0byBmaW5kIHNvbWVib2R5IHRvIHdyaXRlIHRoZSBhbGdvcml0aG0g ZHJhZnQsIGlmIHdlDQo+IGRlY2lkZQ0KdG8NCj4gaGF2ZSBhIHNlcGFyYXRlIG9uZS4NCj4NCj4g QW55IHZvbHVudGVlcnM/DQoNCldoaWxlIEkgYW0gd2lsbGluZyB0byBkbyB0aGlzLCBJIHdvdWxk IHByZWZlciBpZiBpdCB3ZXJlIHNvbWVib2R5IGVsc2UgaWYgdGhlIGRvY3VtZW50IGlzIHNlcGFy YXRlLiAgSSBvYmplY3QgZ29pbmcgdG8gV0cgbWVldGluZ3Mgd2hlcmUgeW91IG9ubHkgaGF2ZSBv bmUgcGVyc29uIHdobyBpcyBkb2luZyB0aGUgcHJlc2VudGF0aW9ucy4gIE9uIHRoZSBvdGhlciBo YW5kLCBwbGVhc2UgcmVtZW1iZXIgdGhlIGFnZ3Jlc3NpdmUgc2NoZWR1bGUgdGhhdCB3ZSBhcmUg dHJ5aW5nIHRvIGtlZXAgZm9yIHRoaXMgZ3JvdXAuDQoNCkppbQ0KDQo+DQo+IFRoYW5rcywNCj4N Cj4gS2luZCBSZWdhcmRzDQo+IEtlcGVuZw0KPg0KPiDlnKggNi82LzE1IDExOjA0IGFt77yMICJN aWtlIEpvbmVzIiA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb20+PiDlhpnlhaU6DQo+DQo+ID5Gb3Igd2hhdCBpdCdzIHdvcnRoLCBJ J2QgYWR2b2NhdGUgaGF2aW5nIGEgc2VwYXJhdGUgYWxnb3JpdGhtDQo+ID5kb2N1bWVudCBmb3Ig dGhlIHNhbWUgcmVhc29ucyB0aGF0IEpPU0UgZGlkLiAgRm9yIG9uZSwgaXQgZW5hYmxlcw0KPiA+ dGhhdCBkb2N1bWVudCB0byBiZSByZXZpc2VkIGluIHRoZSBmdXR1cmUgd2l0aG91dCBoYXZpbmcg dG8gdGhlbg0KPiA+cmV2aXNlIHRoZSB1bmRlcmx5aW5nIHNpZ25hdHVyZS9NQUMvZW5jcnlwdGlv bi9rZXkgcmVwcmVzZW50YXRpb25zLg0KPiA+DQo+ID5BbHNvLCBiYXNlZCBvbiBteSBleHBlcmll bmNlIGFzIGEgSk9TRSBlZGl0b3IsIEkgdGhpbmsgdGhlIHJlc3VsdCB3YXMNCj4gPmNsZWFuZXIg YmVjYXVzZSB3ZSBzZXBhcmF0ZWQgdGhlIGFsZ29yaXRobSBkZXNjcmlwdGlvbnMgZnJvbSB0aGUN Cj4gPmRlc2NyaXB0aW9ucyBvZiBob3cgdG8gcGVyZm9ybSBjcnlwdG9ncmFwaGljIG9wZXJhdGlv bnMuICBJdCB3YXMgZ29vZA0KPiA+ZGlzY2lwbGluZSB0byBoYXZlIHRvIGRlc2NyaWJlIHRoZSBz dGVwcyB0byBjcmVhdGUgYW5kIHVzZSB0aGUgZGF0YQ0KPiA+c3RydWN0dXJlcyB3aXRob3V0IGZh bGxpbmcgYmFjayBvbiBwYXJ0aWN1bGFycyBvZiBzcGVjaWZpYyBhbGdvcml0aG1zLg0KPiA+DQo+ ID5BbHNvLCB0aGUgc2luZ2xlLXB1cnBvc2UgbmF0dXJlIG9mIGFuIGFsZ29yaXRobXMgZG9jIGNh biBtYWtlIGl0DQo+ID5lYXNpZXIgdG8gcmVhZCBhbmQgdXNlIGEgcmVmZXJlbmNlLiAgWW91J3Jl IG5vdCBoYXZpbmcgdG8gc29ydCBvdXQNCj4gPndoYXQgYXJlIGRhdGEgZGVzY3JpcHRpb25zIGFu ZCB3aGF0IGFyZSBhbGdvcml0aG0gZGVzY3JpcHRpb25zLiAgSXQncw0KPiA+anVzdA0KYWxnb3Jp dGhtcy4NCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaGVlcnMsDQo+ID4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCj4gPg0KPiA+UC5TLiAgSSBhZ3Jl ZSB3aXRoIEppbSdzIHByb2NlZHVyYWwgcG9pbnQgdGhhdCB0aGUgY2hhcnRlciBhbGxvd3MgdGhl DQo+ID53b3JraW5nIGdyb3VwIHRvIHByb2R1Y2UgZGVsaXZlcmFibGVzIGVpdGhlciBpbiBjb21i aW5lZCBvciBzZXBhcmF0ZWQNCj4gPmRvY3VtZW50cy4NCj4gPg0KPiA+LS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPkZyb206IENvc2UgW21haWx0bzpjb3NlLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOmNvc2UtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBKaW0gU2NoYWFkDQo+ ID5TZW50OiBGcmlkYXksIEp1bmUgMDUsIDIwMTUgNzozMSBQTQ0KPiA+VG86ICdLZXBlbmcgTGkn OyBjb3NlQGlldGYub3JnPG1haWx0bzpjb3NlQGlldGYub3JnPg0KPiA+U3ViamVjdDogUmU6IFtD b3NlXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiA+ZHJhZnQtc2NoYWFkLWNv c2UtMDIudHh0DQo+ID4NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ PiBGcm9tOiBDb3NlIFttYWlsdG86Y29zZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpjb3NlLWJv dW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgS2VwZW5nIExpDQo+ID4+IFNlbnQ6IEZyaWRh eSwgSnVuZSAwNSwgMjAxNSA2OjQ5IFBNDQo+ID4+IFRvOiBKaW0gU2NoYWFkOyBjb3NlQGlldGYu b3JnPG1haWx0bzpjb3NlQGlldGYub3JnPg0KPiA+PiBTdWJqZWN0OiBSZTogW0Nvc2VdIEZXOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4+ZHJhZnQtc2NoYWFkLWNvc2UtMDIuDQo+ ID50eHQNCj4gPj4NCj4gPj4gSGkgSmltLA0KPiA+Pg0KPiA+PiBUaGFua3MgZm9yIHRoZSBkcmFm dC4NCj4gPj4NCj4gPj4gPkkgYW0gd2lsbGluZyB0byBhZGQgdGhlIGFsZ29yaXRobXMgcGllY2Ug dG8gdGhpcyBkb2N1bWVudCBpZiB0aGF0DQo+ID4+ID5pcyB0aGUgZGVzaXJlIG9mIHRoZSBncm91 cCwgb3IgaXQgY2FuIGJlIGRvbmUgYXMgYW4gaW5kZXBlbmRlbnQNCj4gPj4gPmRvY3VtZW50ICht eSBpbml0aWFsIHByZWZlcmVuY2UpLmVkeA0KPiA+Pg0KPiA+Pg0KPiA+PiBBY2NvcmRpbmcgdG8g b3VyIG1pbGVzdG9uZXMsIHRoZSBhbGdvcml0aG0gcGllY2UgaXMgYSBzZXBhcmF0ZSBpdGVtLg0K PiA+DQo+ID5UaGF0IGp1c3Qgc2F5cyB0aGF0IHdlIG5lZWQgYSBkb2N1bWVudCB0byBjb3ZlciB0 aGF0IG1pbGVzdG9uZS4gIEl0DQo+ID5jYW4gYmUgYSBzaW5nbGUgZG9jdW1lbnQgb3IgYSBjb21i aW5lZCBkb2N1bWVudCBhcyB0aGUgd29ya2luZyBncm91cA0KPiA+ZmVlbHMgYmVzdC4NCj4gPg0K PiA+SmltDQo+ID4NCj4gPj4NCj4gPj4gSnVuIDIwMTUgLSBTdWJtaXQgQ09TRSBzcGVjaWZpY2F0 aW9uIGFzIGEgV0cgaXRlbQ0KPiA+PiAgIEp1biAyMDE1IC0gU3VibWl0IENPU0UgY29uc3RyYWlu ZWQtYXBwcm9wcmlhdGUgYWxnb3JpdGhtcyBhcyBhIFdHDQo+ID4+IGl0ZW0NCj4gPj4NCj4gPj4N Cj4gPj4gS2luZCBSZWdhcmRzDQo+ID4+IEtlcGVuZw0KPiA+Pg0KPiA+PiDlnKggNi82LzE1IDg6 MzcgYW3vvIwgIkppbSBTY2hhYWQiIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPG1haWx0bzppZXRm QGF1Z3VzdGNlbGxhcnMuY29tPj4g5YaZ5YWlOg0KPiA+Pg0KPiA+PiA+U2luY2Ugd2Ugbm93IGhh dmUgYW4gb2ZmaWNpYWwgd29ya2luZyBncm91cC4gIEkgd2lsbCBwcm9wb3NlIHRoaXMNCj4gPj4g PmFzIGEgY2FuZGlkYXRlIGRyYWZ0IHRvIGFkZHJlc3MgdGhlIHNwZWNpZmljYXRpb24gbWlsZXN0 b25lLg0KPiA+PiA+DQo+ID4+ID5JIGFtIHdpbGxpbmcgdG8gYWRkIHRoZSBhbGdvcml0aG1zIHBp ZWNlIHRvIHRoaXMgZG9jdW1lbnQgaWYgdGhhdA0KPiA+PiA+aXMgdGhlIGRlc2lyZSBvZiB0aGUg Z3JvdXAsIG9yIGl0IGNhbiBiZSBkb25lIGFzIGFuIGluZGVwZW5kZW50DQo+ID4+ID5kb2N1bWVu dCAobXkgaW5pdGlhbCBwcmVmZXJlbmNlKS4NCj4gPj4gPg0KPiA+PiA+SmltDQo+ID4+ID4NCj4g Pj4gPg0KPiA+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiA+PiBGcm9tOiBp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4g W21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZz5dDQo+ID4+ID4+IFNlbnQ6IEZyaWRheSwgSnVuZSAwNSwgMjAxNSA1OjIyIFBNDQo+ ID4+ID4+IFRvOiBKaW0gU2NoYWFkOyBKaW0gU2NoYWFkDQo+ID4+ID4+IFN1YmplY3Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc2NoYWFkLWNvc2UtMDIudHh0DQo+ID4+ID4+ DQo+ID4+ID4+DQo+ID4+ID4+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zY2hhYWQtY29z ZS0wMi50eHQgaGFzIGJlZW4NCj4gPj4gPj5zdWNjZXNzZnVsbHkgc3VibWl0dGVkICBieSBKaW0g U2NoYWFkIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYNCj4gPj5yZXBvc2l0b3J5Lg0KPiA+PiA+Pg0K PiA+PiA+PiBOYW1lOiAgICAgICAgICAgZHJhZnQtc2NoYWFkLWNvc2UNCj4gPj4gPj4gUmV2aXNp b246ICAgICAgIDAyDQo+ID4+ID4+IFRpdGxlOiAgICAgICAgICBDQk9SIEVuY29kZWQgTWVzc2Fn ZSBTeW50YXgNCj4gPj4gPj4gRG9jdW1lbnQgZGF0ZTogIDIwMTUtMDYtMDUNCj4gPj4gPj4gR3Jv dXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiA+PiA+PiBQYWdlczogICAgICAg ICAgMzUNCj4gPj4gPj4gVVJMOg0KPiA+PiA+Pmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1zY2hhYWQtY29zZS0wMi50eHQNCj4gPj4gPj4gU3RhdHVzOiAgICAgICAg IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNjaGFhZC1jb3NlLw0KPiA+ PiA+PiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNj aGFhZC1jb3NlLTAyDQo+ID4+ID4+IERpZmY6DQo+ID4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LXNjaGFhZC1jb3NlLTAyDQo+ID4+ID4+DQo+ID4+ID4+IEFic3RyYWN0 Og0KPiA+PiA+PiAgICBDb25jaXNlIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb24gKENCT1Ip IGlzIGRhdGEgZm9ybWF0DQo+ID4+ZGVzaWduZWQNCj4gPj4gPj4gICAgZm9yIHNtYWxsIGNvZGUg c2l6ZSBhbmQgc21hbGwgbWVzc2FnZSBzaXplLiAgVGhlcmUgaXMgYSBuZWVkDQo+ID4+ID4+IGZv cg0KPiA+PnRoZQ0KPiA+PiA+PiAgICBhYmlsaXR5IHRvIGhhdmUgdGhlIGJhc2ljIHNlY3VyaXR5 IHNlcnZpY2VzIGRlZmluZWQgZm9yIHRoaXMgZGF0YQ0KPiA+PiA+PiAgICBmb3JtYXQuICBUaGlz IGRvY3VtZW50IHNwZWNpZmllcyBob3cgdG8gZG8gc2lnbmF0dXJlcywgbWVzc2FnZQ0KPiA+PiA+ PiAgICBhdXRoZW50aWNhdGlvbiBjb2RlcyBhbmQgZW5jcnlwdGlvbiB1c2luZyB0aGlzIGRhdGEg Zm9ybWF0Lg0KPiA+PiA+PiBUaGUNCj4gPndvcmsNCj4gPj4gPj4gICAgaW4gdGhpcyBkb2N1bWVu dCBpcyBkZXJpdmVkIGluIHBhcnQgZnJvbSB0aGUgSlNPTiB3ZWIgc2VjdXJpdHkNCj4gPj4gPj4g ICAgZG9jdW1lbnRzIHVzaW5nIHRoZSBzYW1lIHBhcmFtZXRlcnMgYW5kIGFsZ29yaXRobSBpZGVu dGlmaWVycw0KPiA+PiA+PiBhcw0KPiA+dGhleQ0KPiA+PiA+PiAgICBkby4NCj4gPj4gPj4NCj4g Pj4gPj4NCj4gPj4gPj4NCj4gPj4gPj4NCj4gPj4gPj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUNCj4gPj4gPj5vZiBzdWJtaXNz aW9uICB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlDQo+ ID4+ID4+YXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCj4gPj4gPj4N Cj4gPj4gPj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gPj4gPg0KPiA+PiA+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gPkNvc2UgbWFpbGluZyBs aXN0DQo+ID4+ID5Db3NlQGlldGYub3JnPG1haWx0bzpDb3NlQGlldGYub3JnPg0KPiA+PiA+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlDQo+ID4+DQo+ID4+DQo+ID4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IENv c2UgbWFpbGluZyBsaXN0DQo+ID4+IENvc2VAaWV0Zi5vcmc8bWFpbHRvOkNvc2VAaWV0Zi5vcmc+ DQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29zZQ0KPiA+DQo+ ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Q29z ZSBtYWlsaW5nIGxpc3QNCj4gPkNvc2VAaWV0Zi5vcmc8bWFpbHRvOkNvc2VAaWV0Zi5vcmc+DQo+ ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2UNCj4NCj4NCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQ29zZSBtYWls aW5nIGxpc3QNCj4gQ29zZUBpZXRmLm9yZzxtYWlsdG86Q29zZUBpZXRmLm9yZz4NCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDb3NlIG1haWxpbmcgbGlzdA0KQ29zZUBp ZXRmLm9yZzxtYWlsdG86Q29zZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vY29zZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KQ29zZSBtYWlsaW5nIGxpc3QNCkNvc2VAaWV0Zi5vcmc8bWFpbHRvOkNvc2VA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2UNCg0K --_000_BY2PR03MB4425DAD7A9BAFE9989ACAC3F5BC0BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4 IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUs IGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi5pbQ0KCXttc28tc3R5bGUtbmFtZTppbTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmWQgYmUgaG9ub3JlZCB0byBoYXZl IEJyaWFuIGFzIGNvLWVkaXRvciBvZiB0aGUgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBCcmlhbiBDYW1wYmVsbCBbbWFpbHRvOmJjYW1wYmVsbEBwaW5n aWRlbnRpdHkuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdW5lIDExLCAyMDE1 IDI6MjkgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM8YnI+DQo8Yj5DYzo8L2I+IEppbSBT Y2hhYWQ7IEtlcGVuZyBMaTsgY29zZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W0Nvc2VdIEFsZ29yaXRobSBkcmFmdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPknigJlkIGJlIHdpbGxpbmcgdG8gaGVscCBNaWtlIHdpdGggYSBzZXBhcmF0ZSBhbGdvcml0 aG1zIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gVGh1LCBKdW4gMTEsIDIwMTUgYXQgMTA6MTAgQU0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9 Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkknZCBiZSBnbGFkIHRvIGRvIHRoaXMuJm5ic3A7IEkgbG9vayBm b3J3YXJkIHRvIGhlbHBpbmcgdXMgZ2V0IHRoZXNlIHNwZWNzIG91dCBxdWlja2x5IGluIHdheXMg dGhhdCBtZWV0IHRoZSB1c2UgY2FzZXMgcGVvcGxlIGhhdmUuPGJyPg0KPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENoZWVycyw8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg LS0gTWlrZTxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+LS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImltIj5Gcm9tOiBDb3NlIFttYWlsdG86PGEg aHJlZj0ibWFpbHRvOmNvc2UtYm91bmNlc0BpZXRmLm9yZyI+Y29zZS1ib3VuY2VzQGlldGYub3Jn PC9hPl0gT24gQmVoYWxmIE9mIEppbSBTY2hhYWQ8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9Imlt Ij5TZW50OiBXZWRuZXNkYXksIEp1bmUgMTAsIDIwMTUgMTA6MTggUE08L3NwYW4+PGJyPg0KPHNw YW4gY2xhc3M9ImltIj5UbzogJ0tlcGVuZyBMaSc7IDxhIGhyZWY9Im1haWx0bzpjb3NlQGlldGYu b3JnIj5jb3NlQGlldGYub3JnPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3ViamVjdDogUmU6IFtDb3NlXSBBbGdvcml0aG0gZHJh ZnQ8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PGJyPg0KJmd0OyBGcm9tOiBDb3NlIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmNvc2UtYm91bmNl c0BpZXRmLm9yZyI+Y29zZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIEtlcGVu ZyBMaTxicj4NCiZndDsgU2VudDogV2VkbmVzZGF5LCBKdW5lIDEwLCAyMDE1IDY6MDMgUE08YnI+ DQomZ3Q7IFRvOiBNaWtlIEpvbmVzOyBKaW0gU2NoYWFkOyA8YSBocmVmPSJtYWlsdG86Y29zZUBp ZXRmLm9yZyI+Y29zZUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IFN1YmplY3Q6IFtDb3NlXSBBbGdv cml0aG0gZHJhZnQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyBDdXJyZW50bHksIHdlIGhhdmUgcmVjZWl2 ZWQgZmVlZGJhY2sgZnJvbSBNaWtlIHRvIGhhdmUgYSBzZXBhcmF0ZTxicj4NCmFsZ29yaXRobTxi cj4NCiZndDsgZHJhZnQuPGJyPg0KJmd0Ozxicj4NCiZndDsgQW55IG90aGVyIGZlZWRiYWNrPzxi cj4NCiZndDs8YnI+DQomZ3Q7IEFsc28sIHdlIG5lZWQgdG8gZmluZCBzb21lYm9keSB0byB3cml0 ZSB0aGUgYWxnb3JpdGhtIGRyYWZ0LCBpZiB3ZTxicj4NCiZndDsgZGVjaWRlPGJyPg0KdG88YnI+ DQomZ3Q7IGhhdmUgYSBzZXBhcmF0ZSBvbmUuPGJyPg0KJmd0Ozxicj4NCiZndDsgQW55IHZvbHVu dGVlcnM/PGJyPg0KPGJyPg0KV2hpbGUgSSBhbSB3aWxsaW5nIHRvIGRvIHRoaXMsIEkgd291bGQg cHJlZmVyIGlmIGl0IHdlcmUgc29tZWJvZHkgZWxzZSBpZiB0aGUgZG9jdW1lbnQgaXMgc2VwYXJh dGUuJm5ic3A7IEkgb2JqZWN0IGdvaW5nIHRvIFdHIG1lZXRpbmdzIHdoZXJlIHlvdSBvbmx5IGhh dmUgb25lIHBlcnNvbiB3aG8gaXMgZG9pbmcgdGhlIHByZXNlbnRhdGlvbnMuJm5ic3A7IE9uIHRo ZSBvdGhlciBoYW5kLCBwbGVhc2UgcmVtZW1iZXIgdGhlIGFnZ3Jlc3NpdmUgc2NoZWR1bGUgdGhh dA0KIHdlIGFyZSB0cnlpbmcgdG8ga2VlcCBmb3IgdGhpcyBncm91cC48YnI+DQo8YnI+DQpKaW08 YnI+DQo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGFua3MsPGJyPg0KJmd0Ozxicj4NCiZndDsgS2lu ZCBSZWdhcmRzPGJyPg0KJmd0OyBLZXBlbmc8YnI+DQomZ3Q7PGJyPg0KJmd0OyA8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7lnKg8L3NwYW4+IDYvNi8xNSAx MTowNCBhbTxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPu+8 jDwvc3Bhbj4gJnF1b3Q7TWlrZSBKb25lcyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hh ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZn dDsNCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuWGmeWF pTwvc3Bhbj46PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0O0ZvciB3aGF0IGl0J3Mgd29ydGgsIEkn ZCBhZHZvY2F0ZSBoYXZpbmcgYSBzZXBhcmF0ZSBhbGdvcml0aG08YnI+DQomZ3Q7ICZndDtkb2N1 bWVudCBmb3IgdGhlIHNhbWUgcmVhc29ucyB0aGF0IEpPU0UgZGlkLiZuYnNwOyBGb3Igb25lLCBp dCBlbmFibGVzPGJyPg0KJmd0OyAmZ3Q7dGhhdCBkb2N1bWVudCB0byBiZSByZXZpc2VkIGluIHRo ZSBmdXR1cmUgd2l0aG91dCBoYXZpbmcgdG8gdGhlbjxicj4NCiZndDsgJmd0O3JldmlzZSB0aGUg dW5kZXJseWluZyBzaWduYXR1cmUvTUFDL2VuY3J5cHRpb24va2V5IHJlcHJlc2VudGF0aW9ucy48 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDtBbHNvLCBiYXNlZCBvbiBteSBleHBlcmllbmNl IGFzIGEgSk9TRSBlZGl0b3IsIEkgdGhpbmsgdGhlIHJlc3VsdCB3YXM8YnI+DQomZ3Q7ICZndDtj bGVhbmVyIGJlY2F1c2Ugd2Ugc2VwYXJhdGVkIHRoZSBhbGdvcml0aG0gZGVzY3JpcHRpb25zIGZy b20gdGhlPGJyPg0KJmd0OyAmZ3Q7ZGVzY3JpcHRpb25zIG9mIGhvdyB0byBwZXJmb3JtIGNyeXB0 b2dyYXBoaWMgb3BlcmF0aW9ucy4mbmJzcDsgSXQgd2FzIGdvb2Q8YnI+DQomZ3Q7ICZndDtkaXNj aXBsaW5lIHRvIGhhdmUgdG8gZGVzY3JpYmUgdGhlIHN0ZXBzIHRvIGNyZWF0ZSBhbmQgdXNlIHRo ZSBkYXRhPGJyPg0KJmd0OyAmZ3Q7c3RydWN0dXJlcyB3aXRob3V0IGZhbGxpbmcgYmFjayBvbiBw YXJ0aWN1bGFycyBvZiBzcGVjaWZpYyBhbGdvcml0aG1zLjxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0O0Fsc28sIHRoZSBzaW5nbGUtcHVycG9zZSBuYXR1cmUgb2YgYW4gYWxnb3JpdGhtcyBk b2MgY2FuIG1ha2UgaXQ8YnI+DQomZ3Q7ICZndDtlYXNpZXIgdG8gcmVhZCBhbmQgdXNlIGEgcmVm ZXJlbmNlLiZuYnNwOyBZb3UncmUgbm90IGhhdmluZyB0byBzb3J0IG91dDxicj4NCiZndDsgJmd0 O3doYXQgYXJlIGRhdGEgZGVzY3JpcHRpb25zIGFuZCB3aGF0IGFyZSBhbGdvcml0aG0gZGVzY3Jp cHRpb25zLiZuYnNwOyBJdCdzPGJyPg0KJmd0OyAmZ3Q7anVzdDxicj4NCmFsZ29yaXRobXMuPGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtDaGVlcnMsPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstLSBNaWtlPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7UC5TLiZuYnNwOyBJIGFncmVlIHdpdGggSmltJ3MgcHJvY2VkdXJhbCBwb2ludCB0 aGF0IHRoZSBjaGFydGVyIGFsbG93cyB0aGU8YnI+DQomZ3Q7ICZndDt3b3JraW5nIGdyb3VwIHRv IHByb2R1Y2UgZGVsaXZlcmFibGVzIGVpdGhlciBpbiBjb21iaW5lZCBvciBzZXBhcmF0ZWQ8YnI+ DQomZ3Q7ICZndDtkb2N1bWVudHMuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7LS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDtGcm9tOiBDb3NlIFttYWlsdG86PGEg aHJlZj0ibWFpbHRvOmNvc2UtYm91bmNlc0BpZXRmLm9yZyI+Y29zZS1ib3VuY2VzQGlldGYub3Jn PC9hPl0gT24gQmVoYWxmIE9mIEppbSBTY2hhYWQ8YnI+DQomZ3Q7ICZndDtTZW50OiBGcmlkYXks IEp1bmUgMDUsIDIwMTUgNzozMSBQTTxicj4NCiZndDsgJmd0O1RvOiAnS2VwZW5nIExpJzsgPGEg aHJlZj0ibWFpbHRvOmNvc2VAaWV0Zi5vcmciPmNvc2VAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAm Z3Q7U3ViamVjdDogUmU6IFtDb3NlXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcjxi cj4NCiZndDsgJmd0O2RyYWZ0LXNjaGFhZC1jb3NlLTAyLnR4dDxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnI+DQomZ3Q7ICZndDsmZ3Q7IEZyb206IENvc2UgW21haWx0bzo8YSBocmVmPSJtYWlsdG86Y29z ZS1ib3VuY2VzQGlldGYub3JnIj5jb3NlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYg T2YgS2VwZW5nIExpPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBTZW50OiBGcmlkYXksIEp1bmUgMDUsIDIw MTUgNjo0OSBQTTxicj4NCiZndDsgJmd0OyZndDsgVG86IEppbSBTY2hhYWQ7IDxhIGhyZWY9Im1h aWx0bzpjb3NlQGlldGYub3JnIj5jb3NlQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyZndDsg U3ViamVjdDogUmU6IFtDb3NlXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcjxicj4N CiZndDsgJmd0OyZndDtkcmFmdC1zY2hhYWQtY29zZS0wMi48YnI+DQomZ3Q7ICZndDt0eHQ8YnI+ DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBIaSBKaW0sPGJyPg0KJmd0OyAmZ3Q7 Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgVGhhbmtzIGZvciB0aGUgZHJhZnQuPGJyPg0KJmd0OyAm Z3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0O0kgYW0gd2lsbGluZyB0byBhZGQgdGhlIGFs Z29yaXRobXMgcGllY2UgdG8gdGhpcyBkb2N1bWVudCBpZiB0aGF0PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyAmZ3Q7aXMgdGhlIGRlc2lyZSBvZiB0aGUgZ3JvdXAsIG9yIGl0IGNhbiBiZSBkb25lIGFzIGFu IGluZGVwZW5kZW50PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ZG9jdW1lbnQgKG15IGluaXRpYWwg cHJlZmVyZW5jZSkuZWR4PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDs8YnI+ DQomZ3Q7ICZndDsmZ3Q7IEFjY29yZGluZyB0byBvdXIgbWlsZXN0b25lcywgdGhlIGFsZ29yaXRo bSBwaWVjZSBpcyBhIHNlcGFyYXRlIGl0ZW0uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 VGhhdCBqdXN0IHNheXMgdGhhdCB3ZSBuZWVkIGEgZG9jdW1lbnQgdG8gY292ZXIgdGhhdCBtaWxl c3RvbmUuJm5ic3A7IEl0PGJyPg0KJmd0OyAmZ3Q7Y2FuIGJlIGEgc2luZ2xlIGRvY3VtZW50IG9y IGEgY29tYmluZWQgZG9jdW1lbnQgYXMgdGhlIHdvcmtpbmcgZ3JvdXA8YnI+DQomZ3Q7ICZndDtm ZWVscyBiZXN0Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O0ppbTxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IEp1biAyMDE1IC0gU3VibWl0 IENPU0Ugc3BlY2lmaWNhdGlvbiBhcyBhIFdHIGl0ZW08YnI+DQomZ3Q7ICZndDsmZ3Q7Jm5ic3A7 ICZuYnNwO0p1biAyMDE1IC0gU3VibWl0IENPU0UgY29uc3RyYWluZWQtYXBwcm9wcmlhdGUgYWxn b3JpdGhtcyBhcyBhIFdHPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBpdGVtPGJyPg0KJmd0OyAmZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IEtpbmQgUmVnYXJkczxicj4N CiZndDsgJmd0OyZndDsgS2VwZW5nPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZn dDsgPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5ZyoPC9z cGFuPiA2LzYvMTUgODozNyBhbTxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3Ro aWMmcXVvdDsiPu+8jDwvc3Bhbj4gJnF1b3Q7SmltIFNjaGFhZCZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20iPmlldGZAYXVndXN0Y2VsbGFycy5jb208L2E+ Jmd0Ow0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5YaZ 5YWlPC9zcGFuPjo8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7U2lu Y2Ugd2Ugbm93IGhhdmUgYW4gb2ZmaWNpYWwgd29ya2luZyBncm91cC4mbmJzcDsgSSB3aWxsIHBy b3Bvc2UgdGhpczxicj4NCiZndDsgJmd0OyZndDsgJmd0O2FzIGEgY2FuZGlkYXRlIGRyYWZ0IHRv IGFkZHJlc3MgdGhlIHNwZWNpZmljYXRpb24gbWlsZXN0b25lLjxicj4NCiZndDsgJmd0OyZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0O0kgYW0gd2lsbGluZyB0byBhZGQgdGhlIGFsZ29y aXRobXMgcGllY2UgdG8gdGhpcyBkb2N1bWVudCBpZiB0aGF0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAm Z3Q7aXMgdGhlIGRlc2lyZSBvZiB0aGUgZ3JvdXAsIG9yIGl0IGNhbiBiZSBkb25lIGFzIGFuIGlu ZGVwZW5kZW50PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ZG9jdW1lbnQgKG15IGluaXRpYWwgcHJl ZmVyZW5jZSkuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7 SmltPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZn dDsgJmd0OyZndDsgJmd0OyZndDsgRnJvbTogPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9 Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZzwvYT5dPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBTZW50OiBGcmlkYXksIEp1bmUgMDUs IDIwMTUgNToyMiBQTTxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsgVG86IEppbSBTY2hhYWQ7 IEppbSBTY2hhYWQ8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IFN1YmplY3Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc2NoYWFkLWNvc2UtMDIudHh0PGJyPg0KJmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsmZ3Q7ICZndDsmZ3Q7IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zY2hhYWQtY29zZS0w Mi50eHQgaGFzIGJlZW48YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7c3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCZuYnNwOyBieSBKaW0gU2NoYWFkIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEY8YnI+DQom Z3Q7ICZndDsmZ3Q7cmVwb3NpdG9yeS48YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBOYW1lOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ZHJhZnQtc2NoYWFkLWNvc2U8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 IFJldmlzaW9uOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzAyPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBUaXRsZTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENCT1Ig RW5jb2RlZCBNZXNzYWdlIFN5bnRheDxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsgRG9jdW1l bnQgZGF0ZTombmJzcDsgMjAxNS0wNi0wNTxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsgR3Jv dXA6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Np b248YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IFBhZ2VzOiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgMzU8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IFVSTDo8YnI+DQom Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LXNjaGFhZC1jb3NlLTAyLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zY2hhYWQtY29zZS0wMi50eHQ8 L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBTdGF0dXM6Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LXNjaGFhZC1jb3NlLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LXNjaGFhZC1jb3NlLzwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7IEh0bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY2hhYWQtY29zZS0wMiIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY2hhYWQtY29zZS0wMjwvYT48 YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7IERpZmY6PGJyPg0KJmd0OyAmZ3Q7Jmd0OzxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1zY2hhYWQtY29zZS0w MiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1zY2hhYWQtY29zZS0wMjwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7 Jm5ic3A7ICZuYnNwOyBDb25jaXNlIEJpbmFyeSBPYmplY3QgUmVwcmVzZW50YXRpb24gKENCT1Ip IGlzIGRhdGEgZm9ybWF0PGJyPg0KJmd0OyAmZ3Q7Jmd0O2Rlc2lnbmVkPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgZm9yIHNtYWxsIGNvZGUgc2l6ZSBhbmQgc21hbGwg bWVzc2FnZSBzaXplLiZuYnNwOyBUaGVyZSBpcyBhIG5lZWQ8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZn dDsmZ3Q7IGZvcjxicj4NCiZndDsgJmd0OyZndDt0aGU8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyBhYmlsaXR5IHRvIGhhdmUgdGhlIGJhc2ljIHNlY3VyaXR5IHNlcnZp Y2VzIGRlZmluZWQgZm9yIHRoaXMgZGF0YTxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsmbmJz cDsgJm5ic3A7IGZvcm1hdC4mbmJzcDsgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgaG93IHRvIGRv IHNpZ25hdHVyZXMsIG1lc3NhZ2U8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZu YnNwOyBhdXRoZW50aWNhdGlvbiBjb2RlcyBhbmQgZW5jcnlwdGlvbiB1c2luZyB0aGlzIGRhdGEg Zm9ybWF0Ljxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsgVGhlPGJyPg0KJmd0OyAmZ3Q7d29y azxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IGluIHRoaXMgZG9jdW1l bnQgaXMgZGVyaXZlZCBpbiBwYXJ0IGZyb20gdGhlIEpTT04gd2ViIHNlY3VyaXR5PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgZG9jdW1lbnRzIHVzaW5nIHRoZSBzYW1l IHBhcmFtZXRlcnMgYW5kIGFsZ29yaXRobSBpZGVudGlmaWVyczxicj4NCiZndDsgJmd0OyZndDsg Jmd0OyZndDsgYXM8YnI+DQomZ3Q7ICZndDt0aGV5PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0 OyZuYnNwOyAmbmJzcDsgZG8uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsg Jmd0OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0OyZndDsgUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWU8YnI+DQom Z3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7b2Ygc3VibWlzc2lvbiZuYnNwOyB1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7 Jmd0O2F0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRv b2xzLmlldGYub3JnPC9hPi48YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAm Z3Q7Jmd0OyAmZ3Q7Jmd0OyBUaGUgSUVURiBTZWNyZXRhcmlhdDxicj4NCiZndDsgJmd0OyZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJmd0O19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7Q29zZSBtYWlsaW5nIGxp c3Q8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDs8YSBocmVmPSJtYWlsdG86Q29zZUBpZXRmLm9yZyI+ Q29zZUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDs8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2UiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2U8L2E+PGJyPg0KJmd0OyAmZ3Q7 Jmd0Ozxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBDb3Nl IG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOkNvc2VAaWV0 Zi5vcmciPkNvc2VAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2UiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2U8L2E+PGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQomZ3Q7ICZndDtDb3NlIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0Ozxh IGhyZWY9Im1haWx0bzpDb3NlQGlldGYub3JnIj5Db3NlQGlldGYub3JnPC9hPjxicj4NCiZndDsg Jmd0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29zZSIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29z ZTwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IENvc2UgbWFpbGluZyBsaXN0PGJy Pg0KJmd0OyA8YSBocmVmPSJtYWlsdG86Q29zZUBpZXRmLm9yZyI+Q29zZUBpZXRmLm9yZzwvYT48 YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y29zZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY29zZTwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCkNvc2UgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv OkNvc2VAaWV0Zi5vcmciPkNvc2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlPC9hPjxicj4NCjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KQ29zZSBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Q29zZUBpZXRmLm9yZyI+Q29zZUBpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2Nvc2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2Nvc2U8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_BY2PR03MB4425DAD7A9BAFE9989ACAC3F5BC0BY2PR03MB442namprd_-- From nobody Thu Jun 11 19:21:22 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105B51B3618 for ; Thu, 11 Jun 2015 19:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.452 X-Spam-Level: X-Spam-Status: No, score=0.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 WExg84OxfAes for ; Thu, 11 Jun 2015 19:21:20 -0700 (PDT) Received: from out4133-50.mail.aliyun.com (out4133-50.mail.aliyun.com [42.120.133.50]) by ietfa.amsl.com (Postfix) with ESMTP id 71A0A1B3616 for ; Thu, 11 Jun 2015 19:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1434075678; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=1c4r1OCQd7q4eM78NDTa7PhyfAR1c3aewyZ5mg67de0=; b=kYwNms8l22qv3cL7DzD6iPETrSJiyVrPPQnpBWB3KrAMUYzDKROqmH3IJWpcT1A+fvzsmfS2Y3okgdSpQlza42zse9FQMmxDk/9OMYa53I7895MeFMl+xC+iuxmwfLPc5wAebHmeBkyHr/5BOPuY1SrVQUp4D0k57WH+JK+3hss= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R691e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r46d02010; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=2; RT=2; SR=0; Received: from 10.1.157.169(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.74.163) by smtp.aliyun-inc.com(127.0.0.1); Fri, 12 Jun 2015 10:21:16 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Fri, 12 Jun 2015 10:21:07 +0800 From: "Kepeng Li" To: Justin Richer , Message-ID: Thread-Topic: [Cose] Call for Draft Adoption References: <3032DD54-1B5B-4CD7-A72C-2CA8517B5E5F@mit.edu> In-Reply-To: <3032DD54-1B5B-4CD7-A72C-2CA8517B5E5F@mit.edu> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3516949276_9365697" Archived-At: Subject: Re: [Cose] Call for Draft Adoption X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 02:21:22 -0000 > ʼʹ MIME ʽʼĶʶ ˸ʽˣ޷ʶʼķֲ򲿷ݡ --B_3516949276_9365697 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable >https://tools.ietf.org/html/draft-schaad-cose-02 In case that people can=A1=AFt find it on the WG page, here it is: https://tools.ietf.org/html/draft-schaad-cose-msg-00 The contents are the same. Only document names are different. Thanks, Kind Regards Kepeng=20 =B7=A2=BC=FE=C8=CB: Justin Richer =C8=D5=C6=DA: Friday, 12 June, 2015 1:33 am =D6=C1: =D6=F7=CC=E2: [Cose] Call for Draft Adoption We=A1=AFre starting a two week review period to determine a potential starting draft for the COSE work. So far, there has been one potential draft submitted: https://tools.ietf.org/html/draft-schaad-cose-02 During this two week period, please review the above draft and comment to the list whether you think it is a reasonable starting point for the COSE work, or not. If not, please submit an alternative draft and present it to the list. At the end of the two week period, the chairs will do a consensus call. If there=A1=AFs rough consensus to adopt this (or another) draft, we=A1=AFll turn it i= nto a working group document and get it started before Prague. Things to keep in mind during this review: - This draft will be the starting point, not the ending point. - There will be many opportunities to edit and alter the document before it=A1=AFs final. - If you have major contentions with the document, please bring them up, particularly if you have a way to fix them. - Please be willing to submit text as well as ideas. =A1=AA Justin _______________________________________________ Cose mailing list Cose@ietf.org https://www.ietf.org/mailman/listinfo/cose --B_3516949276_9365697 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable

In case that people can’t fi= nd it on the WG page, here it is:

The contents are the same.  Only d= ocument names are different.

Thanks,

=
Kind Regards
Kepeng 

=B7=A2=BC=FE=C8=CB: Justin Richer <jricher@MIT.EDU>
=C8=D5=C6=DA: Friday, 12 June, 2015 1:33 am
=D6=C1: <cose@ietf.org>
=D6=F7=CC=E2: [Cose] Call for Draft Adoption
<= div>
We’re starting a two week r= eview period to determine a potential starting draft for the COSE work. So f= ar, there has been one potential draft submitted:
=
https://tools.ietf.org/html/draft-schaad-cose-02

During this two week p= eriod, please review the above draft and comment to the list whether you thi= nk it is a reasonable starting point for the COSE work, or not. If not, plea= se submit an alternative draft and present it to the list.

At the end of the two week period, the ch= airs will do a consensus call. If there’s rough consensus to adopt thi= s (or another) draft, we’ll turn it into a working group document and = get it started before Prague.


 - This draft will be the starting point, not = the ending point. 
 - There will be many opport= unities to edit and alter the document before it’s final.
&nb= sp;- Please be willing to submit text as well as ideas.
<= br class=3D"">
 — Justin
______= _________________________________________ Cose mailing list Cose@ietf.org https://www.ietf.org/m= ailman/listinfo/cose --B_3516949276_9365697-- From nobody Fri Jun 12 09:40:40 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E240A1ABD3C for ; Fri, 12 Jun 2015 09:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 0WdBqR_WOF7O for ; Fri, 12 Jun 2015 09:40:36 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA26E1A92DD for ; Fri, 12 Jun 2015 09:40:36 -0700 (PDT) Received: from hebrews (unknown [50.109.240.20]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id F13262C9F7 for ; Fri, 12 Jun 2015 09:40:35 -0700 (PDT) From: "Jim Schaad" To: Date: Fri, 12 Jun 2015 09:40:42 -0700 Message-ID: <000f01d0a52e$8673a970$935afc50$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdClK45u0z0NNIHKRwK7W3rpe7Ahcw== Content-Language: en-us Archived-At: Subject: [Cose] Thoughts about the use of AAD in COSE X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 16:40:39 -0000 I have been thinking about the use of AAD in some different applications and how the field was created during the JOSE WG process. There are two different ways that AAD is expected to be supplied by applications. It is either going to be data that is carried as part of the message structure, or it is going to be data that the application has external from our message structure. This would include both implied data (i.e. information from a conversation that is carried forward but is implied in the message) and information that is part of the containing message but not part of the COSE message. In the creation of JOSE, it was determined that applications might have additional data they wanted to have verified and carried as part of the message. The obvious way to do this is to create an item that is placed in the protected header field. The problem with this for JOSE is that the data might be binary rather than textual. This means that the data would need to be base64 encoded in order to put it into the protected header. The protected header is then base64 encoded when the message is created to be sent. This means that the AAD data supplied by the application is double base64 encoded. To prevent this, an independent field 'aad' was created to carry the potential binary data instead. Since COSE has the ability to carry binary data directly without doing the double base64 encoding (actually without any base64 encoding), there is no reason to keep the separate AAD data field for data that is carried in the message. Instead it can just be placed in the protected header section of the message. There is still a need to deal with the question of AAD that is not carried in the message. But that is a different issue. One question that is open for discussion is "Should we define a generic program supplied AAD protected header field, or should we say that this is an application's responsibility?" The reason not defining a generic field is that it makes more sense to keep the pieces of the AAD data separated rather than having an extra encoding level. Jim From nobody Fri Jun 12 10:13:45 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83641A8934 for ; Fri, 12 Jun 2015 10:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 hQQ8YWMcNZbO for ; Fri, 12 Jun 2015 10:13:43 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0126.outbound.protection.outlook.com [65.55.169.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B173C1A8728 for ; Fri, 12 Jun 2015 10:13:42 -0700 (PDT) Received: from BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) by BY2PR03MB572.namprd03.prod.outlook.com (10.141.143.152) with Microsoft SMTP Server (TLS) id 15.1.184.17; Fri, 12 Jun 2015 17:13:41 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.195.6; Fri, 12 Jun 2015 17:13:40 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0195.005; Fri, 12 Jun 2015 17:13:40 +0000 From: Mike Jones To: Jim Schaad , "cose@ietf.org" Thread-Topic: [Cose] Thoughts about the use of AAD in COSE Thread-Index: AdClK45u0z0NNIHKRwK7W3rpe7AhcwABtjEg Date: Fri, 12 Jun 2015 17:13:40 +0000 Message-ID: References: <000f01d0a52e$8673a970$935afc50$@augustcellars.com> In-Reply-To: <000f01d0a52e$8673a970$935afc50$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none; x-originating-ip: [50.47.90.173] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:W5NYBnM9AVX0XhxhhzTrFiBcA3QpxOq0ufgTPtTwjm7QVn2t6beS3Un39+KhcFY66KaNMqpeYLXRQyOs6seCsn8SryN2XZsVtOPiD6t4cyIuTS/dUyPZhCb9r02RGFVOmI7WzFjl3gMotINlBv25tg==; 24:P0lH/PQFuLgFRfwBsdcNn3kxGAbhU6CuWBpKJuuxLWd5GB6kh3iMnOFqlSYWEcplJ8thaL/LCqrYcgZ9p8yJu/cjXUMjo/oDDIIMXBQ2U38=; 20:W6YqEyD2fhM+6PNTCWYl4GjLtvVQ2kVDThpyhBrVN8q0TVz7X8zDyp3Zw1NH6MaUsFOFqJ83fIKt+teMHJLyIw== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB572; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 060503E79B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(76576001)(19580395003)(19580405001)(5003600100002)(2501003)(92566002)(107886002)(2950100001)(102836002)(99286002)(5001770100001)(5001960100002)(189998001)(77096005)(74316001)(33656002)(15975445007)(2900100001)(5002640100001)(54356999)(50986999)(87936001)(76176999)(77156002)(62966003)(86362001)(40100003)(122556002)(2656002)(46102003)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2015 17:13:40.5874 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 X-Microsoft-Exchange-Diagnostics: 1; BY2PR03MB572; 2:H0gotvI8dmfxeE+jV21B2deoIWpSUn3jNJFxEaQjhxV1T2gVdtBCStqlMQ8KaMSn; 2:S+K7RQvUmIYCb52zIRwjv4lz7x9QUiucthrvcrikdlORA4dpXgmOLqyRa94Np5x//+M6TnrgD2NClt6EiHK3PXZYWvXUrzOxnIWNTFIpkyVm8cxsQYCIoPJkJu/AwvT+bmiBKY3ciW1e9uxU99IZUg==; 9:/lMARcMm2+zWHQR9Ryl/YtZrL07zXnkFIb43ZheZrMXoQG5RJLwUEeR79qHvlwIG7I6FLqT98d9NUvFad9JWhX/zlYSUlS7hwR4yRe4Qg3NIEXHjiK7PIeyk1meBZFnz+erfaLBxSFel/E8tSRV22A== X-OriginatorOrg: microsoft.com Archived-At: Subject: Re: [Cose] Thoughts about the use of AAD in COSE X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 17:13:45 -0000 I agree that there's no need to carry forward the JOSE top-level "aad" memb= er, for the reasons you cite. I also agree that there's no requirement to define a specific AAD header fi= eld, since any fields placed in the protected header will be integrity-prot= ected, and there may be multiple such fields used by the application. On t= he other hand, we could reserve a header parameter value for the applicatio= n to use in the common case that it needs only one application AAD value - = with the definition clearly saying that the contents are application-define= d. -- Mike -----Original Message----- From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Friday, June 12, 2015 9:41 AM To: cose@ietf.org Subject: [Cose] Thoughts about the use of AAD in COSE I have been thinking about the use of AAD in some different applications an= d how the field was created during the JOSE WG process. There are two different ways that AAD is expected to be supplied by applica= tions. It is either going to be data that is carried as part of the messag= e structure, or it is going to be data that the application has external fr= om our message structure. This would include both implied data (i.e. infor= mation from a conversation that is carried forward but is implied in the me= ssage) and information that is part of the containing message but not part= of the COSE message. =20 In the creation of JOSE, it was determined that applications might have add= itional data they wanted to have verified and carried as part of the messag= e. The obvious way to do this is to create an item that is placed in the p= rotected header field. The problem with this for JOSE is that the data mig= ht be binary rather than textual. This means that the data would need to b= e base64 encoded in order to put it into the protected header. The protect= ed header is then base64 encoded when the message is created to be sent. T= his means that the AAD data supplied by the application is double base64 encoded. To prevent this, an independent field 'aad' was created to= carry the potential binary data instead. Since COSE has the ability to carry binary data directly without doing the = double base64 encoding (actually without any base64 encoding), there is no = reason to keep the separate AAD data field for data that is carried in the = message. Instead it can just be placed in the protected header section of = the message. There is still a need to deal with the question of AAD that i= s not carried in the message. But that is a different issue. One question that is open for discussion is "Should we define a generic pro= gram supplied AAD protected header field, or should we say that this is an = application's responsibility?" The reason not defining a generic field is that it makes more sense to keep= the pieces of the AAD data separated rather than having an extra encoding = level.=20 Jim _______________________________________________ Cose mailing list Cose@ietf.org https://www.ietf.org/mailman/listinfo/cose From nobody Sat Jun 13 00:34:08 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5AD91A6F17 for ; Sat, 13 Jun 2015 00:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.15 X-Spam-Level: X-Spam-Status: No, score=-0.15 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35] autolearn=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 Zq9RWLsBhyQp for ; Sat, 13 Jun 2015 00:34:05 -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 795261A1E0E for ; Sat, 13 Jun 2015 00:33:06 -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 t5D7X24t010278 for ; Sat, 13 Jun 2015 09:33:02 +0200 (CEST) Received: from alma.local (p5DCCC91B.dip0.t-ipconnect.de [93.204.201.27]) (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 3m7rHf21B0z9B19; Sat, 13 Jun 2015 09:33:02 +0200 (CEST) Message-ID: <557BDCA9.1090308@tzi.org> Date: Sat, 13 Jun 2015 09:32:57 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: cose@ietf.org X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Cose] Editorial: New term "label" X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 07:34:06 -0000 Justin Richer wrote: > We’re starting a two week review period to determine a potential > starting draft for the COSE work. > At the end of the two week period, the chairs will do a consensus call. So you want to play this safe RFC 2418 wise. OK. But let's not get stuck with a month of dead time. (Also, let's get the WG draft in before the I-D cutoff.) I'm assuming we will actively work on Jim's draft during this time (for most of us under the assumption that this will be the WG draft after the various timeouts have passed). In the next couple of weeks, I will post a number of change proposals, some editorial, some at the level of encoding, and maybe some with deeper impact. Today's proposal is editorial, motivated by our overloading of the term "key". "Key" is used both as a cryptographic key (which is then further specialized as COSE_Key), and as the thing indexing a map ("map key"). The latter are not only strings, but integers in COSE. There often is a need for "string or integer used in an identifying role", not just for map keys, but also for algorithm identifiers etc. So I propose we introduce the term "label" for these. This allows us to talk about labels and values in a map. For these, and also for the places where a label is used in the value position (e.g., under the label kty) we don't constantly need to say "integer or string". Introducing a CDDL production for label also simplifies the CDDL a lot. I'll propose detailed text later today; just throwing out the idea now. Grüße, Carsten From nobody Sat Jun 13 07:38:02 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751171A9048 for ; Sat, 13 Jun 2015 07:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 PK0bjVMMr4fl for ; Sat, 13 Jun 2015 07:37:58 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB6121A9047 for ; Sat, 13 Jun 2015 07:37:57 -0700 (PDT) Received: from hebrews (unknown [50.109.240.20]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id E48ED2CA15; Sat, 13 Jun 2015 07:37:56 -0700 (PDT) From: "Jim Schaad" To: "'Carsten Bormann'" , References: <557BDCA9.1090308@tzi.org> In-Reply-To: <557BDCA9.1090308@tzi.org> Date: Sat, 13 Jun 2015 07:38:04 -0700 Message-ID: <002b01d0a5e6$8ed94850$ac8bd8f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQH8U6MrgwBGyu21t+BNKuZ0X0SMTJ1TJAsg Content-Language: en-us Archived-At: Subject: Re: [Cose] Editorial: New term "label" X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 14:37:59 -0000 > -----Original Message----- > From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Carsten Bormann > Sent: Saturday, June 13, 2015 12:33 AM > To: cose@ietf.org > Subject: [Cose] Editorial: New term "label" >=20 > Justin Richer wrote: > > We=E2=80=99re starting a two week review period to determine a = potential > > starting draft for the COSE work. > > At the end of the two week period, the chairs will do a consensus = call. >=20 > So you want to play this safe RFC 2418 wise. OK. > But let's not get stuck with a month of dead time. > (Also, let's get the WG draft in before the I-D cutoff.) >=20 > I'm assuming we will actively work on Jim's draft during this time = (for most > of us under the assumption that this will be the WG draft after the = various > timeouts have passed). >=20 > In the next couple of weeks, I will post a number of change proposals, = some > editorial, some at the level of encoding, and maybe some with deeper > impact. >=20 > Today's proposal is editorial, motivated by our overloading of the = term > "key". > "Key" is used both as a cryptographic key (which is then further = specialized > as COSE_Key), and as the thing indexing a map ("map key"). > The latter are not only strings, but integers in COSE. There often is = a need > for "string or integer used in an identifying role", not just for map = keys, but > also for algorithm identifiers etc. >=20 > So I propose we introduce the term "label" for these. This allows us = to talk > about labels and values in a map. For these, and also for the places = where a > label is used in the value position (e.g., under the label kty) we = don't > constantly need to say "integer or string". > Introducing a CDDL production for label also simplifies the CDDL a = lot. The idea of separating the uses of the word key and using different = terms makes complete sense to me. I agree that this would make things = much easier. I am leery about the idea of using the same term in a = generic manner for both map keys and map values as a general rule. It = makes sense for something like the 'crit' protected header where the = value is intended to be a set of map keys, but for something like 'kty' = where you are just using the type I don't know that I agree. It might make more sense for us to define two different things: * label - replaces the term 'cbor map key' * iors - a locally defined cbor type of integer or string I am not wedded to either of those terms if anybody comes up with = something better. Jim >=20 > I'll propose detailed text later today; just throwing out the idea = now. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Sat Jun 13 09:17:53 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF57E1AC417 for ; Sat, 13 Jun 2015 09:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 u0hUjKLxI0gF for ; Sat, 13 Jun 2015 09:17:51 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0107.outbound.protection.outlook.com [207.46.100.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDD251AC411 for ; Sat, 13 Jun 2015 09:17:50 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.195.6; Sat, 13 Jun 2015 16:17:49 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0195.005; Sat, 13 Jun 2015 16:17:49 +0000 From: Mike Jones To: Jim Schaad , 'Carsten Bormann' , "cose@ietf.org" Thread-Topic: [Cose] Editorial: New term "label" Thread-Index: AQHQpatZ9WeHKwZD4EyojavvdG42XJ2qgcUAgAAb3co= Date: Sat, 13 Jun 2015 16:17:47 +0000 Message-ID: References: <557BDCA9.1090308@tzi.org>, <002b01d0a5e6$8ed94850$ac8bd8f0$@augustcellars.com> In-Reply-To: <002b01d0a5e6$8ed94850$ac8bd8f0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none; x-originating-ip: [50.47.90.173] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:IJXzm79cW+VIfr/7gsS2Ut2+SHY+ui3vFKIrhZXN/t6jneHxJ/qvPczjQ8A/1piW6J/Ccbcg/u1xyucwclhuSCimYiftztZGKGY/+4py2McuT4fq8WFlovyxVT9flqtzt8IUhClBjrwgQEVMcjZbOA==; 24:aYi+flp42TqEDJNTEw/8SDqXH0ga/JSLJrKisE5J+bGUK7lYNsUwmI2dmyCgEZ08ROGjx6sLb39GDTlVxmMKncekAA6qmOOdxvI7/ZHqNv0=; 20:Dh7LmAQfWxFYcgFpjNYtPkcnkwYyDt4X6VAKUVI0ddPybJmVNmuGKqMpbuYVNtQERGhV/RKTNOu8DIpp+79JWw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 0606BBEB39 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(13464003)(377454003)(51704005)(561944003)(19625215002)(33656002)(66066001)(19580395003)(19580405001)(74316001)(40100003)(19617315012)(77156002)(62966003)(122556002)(5002640100001)(5001770100001)(2501003)(5003600100002)(92566002)(189998001)(107886002)(5001960100002)(2900100001)(2950100001)(15975445007)(16236675004)(76176999)(54356999)(50986999)(87936001)(2656002)(86612001)(77096005)(102836002)(86362001)(99286002)(106116001)(46102003)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442B3AE460B395856AB66C6F5BA0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2015 16:17:48.0118 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Subject: Re: [Cose] Editorial: New term "label" X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 16:17:53 -0000 --_000_BY2PR03MB442B3AE460B395856AB66C6F5BA0BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2Z0ZW4sIG9uZSB0YWxrcyBvZiBOYW1lOlZhbHVlIHBhaXJzLiBUaGF0J3MgaW50dWl0aXZlLCBh bmQgbWF0Y2hlcyB0aGUgdGVybWlub2xvZ3kgdXNlZCBmb3IgSk9TRSAmIEpXVC4gIEkgdW5kZXJz dGFuZCB0aGF0IGl0IG1pZ2h0IGJlIGEgYml0IG9kZCB3aGVuIG51bWJlcnMgYXJlIHVzZWQgYXMg dGhlIE5hbWUuDQoNCkkgd291bGQgYmUgb2sgd2l0aCB1c2luZyB0aGUgdGVybSBMYWJlbCBhbmQg TGFiZWw6VmFsdWUgcGFpcnMgaWYgd2UgZXhwbGljaXRseSBwcm92aWRlIGEgZGVmaW5pdGlvbiBm b3Igb3VyIHVzZSBvZiB0aGUgdGVybSBpbiB0aGUgVGVybWlub2xvZ3kgc2VjdGlvbi4gIChJbmRl ZWQsIHRoYXQncyB3aGF0IEkgdGhvdWdodCBDYXJzdGVuIHdhcyBwcm9wb3NpbmcuKQ0KDQotLSBN aWtlDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogSmltIFNjaGFhZDxt YWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4NClNlbnQ6IOKAjjYv4oCOMTMv4oCOMjAxNSA3 OjM4IEFNDQpUbzogJ0NhcnN0ZW4gQm9ybWFubic8bWFpbHRvOmNhYm9AdHppLm9yZz47IGNvc2VA aWV0Zi5vcmc8bWFpbHRvOmNvc2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0Nvc2VdIEVkaXRv cmlhbDogTmV3IHRlcm0gImxhYmVsIg0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBDb3NlIFttYWlsdG86Y29zZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgQ2Fyc3RlbiBCb3JtYW5uDQo+IFNlbnQ6IFNhdHVyZGF5LCBKdW5lIDEzLCAyMDE1IDEyOjMz IEFNDQo+IFRvOiBjb3NlQGlldGYub3JnDQo+IFN1YmplY3Q6IFtDb3NlXSBFZGl0b3JpYWw6IE5l dyB0ZXJtICJsYWJlbCINCj4NCj4gSnVzdGluIFJpY2hlciB3cm90ZToNCj4gPiBXZeKAmXJlIHN0 YXJ0aW5nIGEgdHdvIHdlZWsgcmV2aWV3IHBlcmlvZCB0byBkZXRlcm1pbmUgYSBwb3RlbnRpYWwN Cj4gPiBzdGFydGluZyBkcmFmdCBmb3IgdGhlIENPU0Ugd29yay4NCj4gPiBBdCB0aGUgZW5kIG9m IHRoZSB0d28gd2VlayBwZXJpb2QsIHRoZSBjaGFpcnMgd2lsbCBkbyBhIGNvbnNlbnN1cyBjYWxs Lg0KPg0KPiBTbyB5b3Ugd2FudCB0byBwbGF5IHRoaXMgc2FmZSBSRkMgMjQxOCB3aXNlLiAgT0su DQo+IEJ1dCBsZXQncyBub3QgZ2V0IHN0dWNrIHdpdGggYSBtb250aCBvZiBkZWFkIHRpbWUuDQo+ IChBbHNvLCBsZXQncyBnZXQgdGhlIFdHIGRyYWZ0IGluIGJlZm9yZSB0aGUgSS1EIGN1dG9mZi4p DQo+DQo+IEknbSBhc3N1bWluZyB3ZSB3aWxsIGFjdGl2ZWx5IHdvcmsgb24gSmltJ3MgZHJhZnQg ZHVyaW5nIHRoaXMgdGltZSAoZm9yIG1vc3QNCj4gb2YgdXMgdW5kZXIgdGhlIGFzc3VtcHRpb24g dGhhdCB0aGlzIHdpbGwgYmUgdGhlIFdHIGRyYWZ0IGFmdGVyIHRoZSB2YXJpb3VzDQo+IHRpbWVv dXRzIGhhdmUgcGFzc2VkKS4NCj4NCj4gSW4gdGhlIG5leHQgY291cGxlIG9mIHdlZWtzLCBJIHdp bGwgcG9zdCBhIG51bWJlciBvZiBjaGFuZ2UgcHJvcG9zYWxzLCBzb21lDQo+IGVkaXRvcmlhbCwg c29tZSBhdCB0aGUgbGV2ZWwgb2YgZW5jb2RpbmcsIGFuZCBtYXliZSBzb21lIHdpdGggZGVlcGVy DQo+IGltcGFjdC4NCj4NCj4gVG9kYXkncyBwcm9wb3NhbCBpcyBlZGl0b3JpYWwsIG1vdGl2YXRl ZCBieSBvdXIgb3ZlcmxvYWRpbmcgb2YgdGhlIHRlcm0NCj4gImtleSIuDQo+ICJLZXkiIGlzIHVz ZWQgYm90aCBhcyBhIGNyeXB0b2dyYXBoaWMga2V5ICh3aGljaCBpcyB0aGVuIGZ1cnRoZXIgc3Bl Y2lhbGl6ZWQNCj4gYXMgQ09TRV9LZXkpLCBhbmQgYXMgdGhlIHRoaW5nIGluZGV4aW5nIGEgbWFw ICgibWFwIGtleSIpLg0KPiBUaGUgbGF0dGVyIGFyZSBub3Qgb25seSBzdHJpbmdzLCBidXQgaW50 ZWdlcnMgaW4gQ09TRS4gIFRoZXJlIG9mdGVuIGlzIGEgbmVlZA0KPiBmb3IgInN0cmluZyBvciBp bnRlZ2VyIHVzZWQgaW4gYW4gaWRlbnRpZnlpbmcgcm9sZSIsIG5vdCBqdXN0IGZvciBtYXAga2V5 cywgYnV0DQo+IGFsc28gZm9yIGFsZ29yaXRobSBpZGVudGlmaWVycyBldGMuDQo+DQo+IFNvIEkg cHJvcG9zZSB3ZSBpbnRyb2R1Y2UgdGhlIHRlcm0gImxhYmVsIiBmb3IgdGhlc2UuICBUaGlzIGFs bG93cyB1cyB0byB0YWxrDQo+IGFib3V0IGxhYmVscyBhbmQgdmFsdWVzIGluIGEgbWFwLiAgRm9y IHRoZXNlLCBhbmQgYWxzbyBmb3IgdGhlIHBsYWNlcyB3aGVyZSBhDQo+IGxhYmVsIGlzIHVzZWQg aW4gdGhlIHZhbHVlIHBvc2l0aW9uIChlLmcuLCB1bmRlciB0aGUgbGFiZWwga3R5KSB3ZSBkb24n dA0KPiBjb25zdGFudGx5IG5lZWQgdG8gc2F5ICJpbnRlZ2VyIG9yIHN0cmluZyIuDQo+IEludHJv ZHVjaW5nIGEgQ0RETCBwcm9kdWN0aW9uIGZvciBsYWJlbCBhbHNvIHNpbXBsaWZpZXMgdGhlIENE REwgYSBsb3QuDQoNClRoZSBpZGVhIG9mIHNlcGFyYXRpbmcgdGhlIHVzZXMgb2YgdGhlIHdvcmQg a2V5IGFuZCB1c2luZyBkaWZmZXJlbnQgdGVybXMgbWFrZXMgY29tcGxldGUgc2Vuc2UgdG8gbWUu ICBJIGFncmVlIHRoYXQgdGhpcyB3b3VsZCBtYWtlIHRoaW5ncyBtdWNoIGVhc2llci4gSSBhbSBs ZWVyeSBhYm91dCB0aGUgaWRlYSBvZiB1c2luZyB0aGUgc2FtZSB0ZXJtIGluIGEgZ2VuZXJpYyBt YW5uZXIgZm9yIGJvdGggbWFwIGtleXMgYW5kIG1hcCB2YWx1ZXMgYXMgYSBnZW5lcmFsIHJ1bGUu ICBJdCBtYWtlcyBzZW5zZSBmb3Igc29tZXRoaW5nIGxpa2UgdGhlICdjcml0JyBwcm90ZWN0ZWQg aGVhZGVyIHdoZXJlIHRoZSB2YWx1ZSBpcyBpbnRlbmRlZCB0byBiZSBhIHNldCBvZiBtYXAga2V5 cywgYnV0IGZvciBzb21ldGhpbmcgbGlrZSAna3R5JyB3aGVyZSB5b3UgYXJlIGp1c3QgdXNpbmcg dGhlIHR5cGUgSSBkb24ndCBrbm93IHRoYXQgSSBhZ3JlZS4NCg0KSXQgbWlnaHQgbWFrZSBtb3Jl IHNlbnNlIGZvciB1cyB0byBkZWZpbmUgdHdvIGRpZmZlcmVudCB0aGluZ3M6DQoNCiogIGxhYmVs IC0gcmVwbGFjZXMgdGhlIHRlcm0gJ2Nib3IgbWFwIGtleScNCiogIGlvcnMgLSBhIGxvY2FsbHkg ZGVmaW5lZCBjYm9yIHR5cGUgb2YgaW50ZWdlciBvciBzdHJpbmcNCg0KSSBhbSBub3Qgd2VkZGVk IHRvIGVpdGhlciBvZiB0aG9zZSB0ZXJtcyBpZiBhbnlib2R5IGNvbWVzIHVwIHdpdGggc29tZXRo aW5nIGJldHRlci4NCg0KSmltDQoNCj4NCj4gSSdsbCBwcm9wb3NlIGRldGFpbGVkIHRleHQgbGF0 ZXIgdG9kYXk7IGp1c3QgdGhyb3dpbmcgb3V0IHRoZSBpZGVhIG5vdy4NCj4NCj4gR3LDvMOfZSwg Q2Fyc3Rlbg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBDb3NlIG1haWxpbmcgbGlzdA0KPiBDb3NlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29zZQ0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KQ29zZSBtYWlsaW5nIGxpc3QNCkNvc2VAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29zZQ0K --_000_BY2PR03MB442B3AE460B395856AB66C6F5BA0BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg LS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+T2Z0ZW4sIG9uZSB0YWxrcyBvZiBOYW1l OlZhbHVlIHBhaXJzLiBUaGF0J3MgaW50dWl0aXZlLCBhbmQgbWF0Y2hlcyB0aGUgdGVybWlub2xv Z3kgdXNlZCBmb3IgSk9TRSAmYW1wOyBKV1QuJm5ic3A7IEkgdW5kZXJzdGFuZCB0aGF0IGl0IG1p Z2h0IGJlIGEgYml0IG9kZCB3aGVuIG51bWJlcnMgYXJlIHVzZWQgYXMgdGhlIE5hbWUuPGJyPg0K PGJyPg0KSSB3b3VsZCBiZSBvayB3aXRoIHVzaW5nIHRoZSB0ZXJtIExhYmVsIGFuZCBMYWJlbDpW YWx1ZSBwYWlycyBpZiB3ZSBleHBsaWNpdGx5IHByb3ZpZGUgYSBkZWZpbml0aW9uIGZvciBvdXIg dXNlIG9mIHRoZSB0ZXJtIGluIHRoZSBUZXJtaW5vbG9neSBzZWN0aW9uLiZuYnNwOyAoSW5kZWVk LCB0aGF0J3Mgd2hhdCBJIHRob3VnaHQgQ2Fyc3RlbiB3YXMgcHJvcG9zaW5nLik8YnI+DQo8YnI+ DQotLSBNaWtlPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGhyPg0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7 IGZvbnQtd2VpZ2h0OmJvbGQiPkZyb206DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPjxhIGhyZWY9Im1haWx0bzppZXRm QGF1Z3VzdGNlbGxhcnMuY29tIj5KaW0gU2NoYWFkPC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13 ZWlnaHQ6Ym9sZCI+U2VudDoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJy aSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+4oCONi/igI4xMy/igI4yMDE1IDc6MzggQU08 L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsg Zm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPlRvOg0KPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0Ij48YSBocmVm PSJtYWlsdG86Y2Fib0B0emkub3JnIj4nQ2Fyc3RlbiBCb3JtYW5uJzwvYT47DQo8YSBocmVmPSJt YWlsdG86Y29zZUBpZXRmLm9yZyI+Y29zZUBpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZv bnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPlJlOiBbQ29zZV0gRWRpdG9yaWFs OiBOZXcgdGVybSAmcXVvdDtsYWJlbCZxdW90Ozwvc3Bhbj48YnI+DQo8YnI+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+DQo8ZGl2 IGNsYXNzPSJQbGFpblRleHQiPjxicj4NCjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08YnI+DQomZ3Q7IEZyb206IENvc2UgWzxhIGhyZWY9Im1haWx0bzpjb3NlLWJvdW5jZXNA aWV0Zi5vcmciPm1haWx0bzpjb3NlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2Yg Q2Fyc3RlbiBCb3JtYW5uPGJyPg0KJmd0OyBTZW50OiBTYXR1cmRheSwgSnVuZSAxMywgMjAxNSAx MjozMyBBTTxicj4NCiZndDsgVG86IGNvc2VAaWV0Zi5vcmc8YnI+DQomZ3Q7IFN1YmplY3Q6IFtD b3NlXSBFZGl0b3JpYWw6IE5ldyB0ZXJtICZxdW90O2xhYmVsJnF1b3Q7PGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IEp1c3RpbiBSaWNoZXIgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IFdl4oCZcmUgc3RhcnRp bmcgYSB0d28gd2VlayByZXZpZXcgcGVyaW9kIHRvIGRldGVybWluZSBhIHBvdGVudGlhbDxicj4N CiZndDsgJmd0OyBzdGFydGluZyBkcmFmdCBmb3IgdGhlIENPU0Ugd29yay48YnI+DQomZ3Q7ICZn dDsgQXQgdGhlIGVuZCBvZiB0aGUgdHdvIHdlZWsgcGVyaW9kLCB0aGUgY2hhaXJzIHdpbGwgZG8g YSBjb25zZW5zdXMgY2FsbC48YnI+DQomZ3Q7IDxicj4NCiZndDsgU28geW91IHdhbnQgdG8gcGxh eSB0aGlzIHNhZmUgUkZDIDI0MTggd2lzZS4mbmJzcDsgT0suPGJyPg0KJmd0OyBCdXQgbGV0J3Mg bm90IGdldCBzdHVjayB3aXRoIGEgbW9udGggb2YgZGVhZCB0aW1lLjxicj4NCiZndDsgKEFsc28s IGxldCdzIGdldCB0aGUgV0cgZHJhZnQgaW4gYmVmb3JlIHRoZSBJLUQgY3V0b2ZmLik8YnI+DQom Z3Q7IDxicj4NCiZndDsgSSdtIGFzc3VtaW5nIHdlIHdpbGwgYWN0aXZlbHkgd29yayBvbiBKaW0n cyBkcmFmdCBkdXJpbmcgdGhpcyB0aW1lIChmb3IgbW9zdDxicj4NCiZndDsgb2YgdXMgdW5kZXIg dGhlIGFzc3VtcHRpb24gdGhhdCB0aGlzIHdpbGwgYmUgdGhlIFdHIGRyYWZ0IGFmdGVyIHRoZSB2 YXJpb3VzPGJyPg0KJmd0OyB0aW1lb3V0cyBoYXZlIHBhc3NlZCkuPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IEluIHRoZSBuZXh0IGNvdXBsZSBvZiB3ZWVrcywgSSB3aWxsIHBvc3QgYSBudW1iZXIgb2Yg Y2hhbmdlIHByb3Bvc2Fscywgc29tZTxicj4NCiZndDsgZWRpdG9yaWFsLCBzb21lIGF0IHRoZSBs ZXZlbCBvZiBlbmNvZGluZywgYW5kIG1heWJlIHNvbWUgd2l0aCBkZWVwZXI8YnI+DQomZ3Q7IGlt cGFjdC48YnI+DQomZ3Q7IDxicj4NCiZndDsgVG9kYXkncyBwcm9wb3NhbCBpcyBlZGl0b3JpYWws IG1vdGl2YXRlZCBieSBvdXIgb3ZlcmxvYWRpbmcgb2YgdGhlIHRlcm08YnI+DQomZ3Q7ICZxdW90 O2tleSZxdW90Oy48YnI+DQomZ3Q7ICZxdW90O0tleSZxdW90OyBpcyB1c2VkIGJvdGggYXMgYSBj cnlwdG9ncmFwaGljIGtleSAod2hpY2ggaXMgdGhlbiBmdXJ0aGVyIHNwZWNpYWxpemVkPGJyPg0K Jmd0OyBhcyBDT1NFX0tleSksIGFuZCBhcyB0aGUgdGhpbmcgaW5kZXhpbmcgYSBtYXAgKCZxdW90 O21hcCBrZXkmcXVvdDspLjxicj4NCiZndDsgVGhlIGxhdHRlciBhcmUgbm90IG9ubHkgc3RyaW5n cywgYnV0IGludGVnZXJzIGluIENPU0UuJm5ic3A7IFRoZXJlIG9mdGVuIGlzIGEgbmVlZDxicj4N CiZndDsgZm9yICZxdW90O3N0cmluZyBvciBpbnRlZ2VyIHVzZWQgaW4gYW4gaWRlbnRpZnlpbmcg cm9sZSZxdW90Oywgbm90IGp1c3QgZm9yIG1hcCBrZXlzLCBidXQ8YnI+DQomZ3Q7IGFsc28gZm9y IGFsZ29yaXRobSBpZGVudGlmaWVycyBldGMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFNvIEkgcHJv cG9zZSB3ZSBpbnRyb2R1Y2UgdGhlIHRlcm0gJnF1b3Q7bGFiZWwmcXVvdDsgZm9yIHRoZXNlLiZu YnNwOyBUaGlzIGFsbG93cyB1cyB0byB0YWxrPGJyPg0KJmd0OyBhYm91dCBsYWJlbHMgYW5kIHZh bHVlcyBpbiBhIG1hcC4mbmJzcDsgRm9yIHRoZXNlLCBhbmQgYWxzbyBmb3IgdGhlIHBsYWNlcyB3 aGVyZSBhPGJyPg0KJmd0OyBsYWJlbCBpcyB1c2VkIGluIHRoZSB2YWx1ZSBwb3NpdGlvbiAoZS5n LiwgdW5kZXIgdGhlIGxhYmVsIGt0eSkgd2UgZG9uJ3Q8YnI+DQomZ3Q7IGNvbnN0YW50bHkgbmVl ZCB0byBzYXkgJnF1b3Q7aW50ZWdlciBvciBzdHJpbmcmcXVvdDsuPGJyPg0KJmd0OyBJbnRyb2R1 Y2luZyBhIENEREwgcHJvZHVjdGlvbiBmb3IgbGFiZWwgYWxzbyBzaW1wbGlmaWVzIHRoZSBDRERM IGEgbG90Ljxicj4NCjxicj4NClRoZSBpZGVhIG9mIHNlcGFyYXRpbmcgdGhlIHVzZXMgb2YgdGhl IHdvcmQga2V5IGFuZCB1c2luZyBkaWZmZXJlbnQgdGVybXMgbWFrZXMgY29tcGxldGUgc2Vuc2Ug dG8gbWUuJm5ic3A7IEkgYWdyZWUgdGhhdCB0aGlzIHdvdWxkIG1ha2UgdGhpbmdzIG11Y2ggZWFz aWVyLiBJIGFtIGxlZXJ5IGFib3V0IHRoZSBpZGVhIG9mIHVzaW5nIHRoZSBzYW1lIHRlcm0gaW4g YSBnZW5lcmljIG1hbm5lciBmb3IgYm90aCBtYXAga2V5cyBhbmQgbWFwIHZhbHVlcyBhcw0KIGEg Z2VuZXJhbCBydWxlLiZuYnNwOyBJdCBtYWtlcyBzZW5zZSBmb3Igc29tZXRoaW5nIGxpa2UgdGhl ICdjcml0JyBwcm90ZWN0ZWQgaGVhZGVyIHdoZXJlIHRoZSB2YWx1ZSBpcyBpbnRlbmRlZCB0byBi ZSBhIHNldCBvZiBtYXAga2V5cywgYnV0IGZvciBzb21ldGhpbmcgbGlrZSAna3R5JyB3aGVyZSB5 b3UgYXJlIGp1c3QgdXNpbmcgdGhlIHR5cGUgSSBkb24ndCBrbm93IHRoYXQgSSBhZ3JlZS48YnI+ DQo8YnI+DQpJdCBtaWdodCBtYWtlIG1vcmUgc2Vuc2UgZm9yIHVzIHRvIGRlZmluZSB0d28gZGlm ZmVyZW50IHRoaW5nczo8YnI+DQo8YnI+DQoqJm5ic3A7IGxhYmVsIC0gcmVwbGFjZXMgdGhlIHRl cm0gJ2Nib3IgbWFwIGtleSc8YnI+DQoqJm5ic3A7IGlvcnMgLSBhIGxvY2FsbHkgZGVmaW5lZCBj Ym9yIHR5cGUgb2YgaW50ZWdlciBvciBzdHJpbmc8YnI+DQo8YnI+DQpJIGFtIG5vdCB3ZWRkZWQg dG8gZWl0aGVyIG9mIHRob3NlIHRlcm1zIGlmIGFueWJvZHkgY29tZXMgdXAgd2l0aCBzb21ldGhp bmcgYmV0dGVyLjxicj4NCjxicj4NCkppbTxicj4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBJJ2xs IHByb3Bvc2UgZGV0YWlsZWQgdGV4dCBsYXRlciB0b2RheTsganVzdCB0aHJvd2luZyBvdXQgdGhl IGlkZWEgbm93Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBHcsO8w59lLCBDYXJzdGVuPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJmd0OyBDb3NlIG1haWxpbmcgbGlzdDxicj4NCiZndDsgQ29zZUBpZXRmLm9yZzxi cj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9j b3NlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2U8L2E+PGJyPg0K PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpDb3NlIG1haWxpbmcgbGlzdDxicj4NCkNvc2VAaWV0Zi5vcmc8YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2UiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vY29zZTwvYT48YnI+DQo8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BY2PR03MB442B3AE460B395856AB66C6F5BA0BY2PR03MB442namprd_-- From nobody Sat Jun 13 09:46:55 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62F61ACCFD for ; Sat, 13 Jun 2015 09:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_55=0.6] autolearn=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 5NPaa57zR9LK for ; Sat, 13 Jun 2015 09:46:51 -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 5DA101ACCFA for ; Sat, 13 Jun 2015 09:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t5DGkh8p014240; Sat, 13 Jun 2015 18:46:43 +0200 (CEST) Received: from alma.local (p5DCCC91B.dip0.t-ipconnect.de [93.204.201.27]) (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 3m84ZW2wpTz99B1; Sat, 13 Jun 2015 18:46:43 +0200 (CEST) Message-ID: <557C5E6D.9020308@tzi.org> Date: Sat, 13 Jun 2015 18:46:37 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: Mike Jones References: <557BDCA9.1090308@tzi.org>, <002b01d0a5e6$8ed94850$ac8bd8f0$@augustcellars.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Jim Schaad , "cose@ietf.org" Subject: Re: [Cose] Editorial: New term "label" X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 16:46:54 -0000 Mike Jones wrote: > I would be ok with using the term Label and Label:Value pairs if we > explicitly provide a definition for our use of the term in the > Terminology section. (Indeed, that's what I thought Carsten was proposing.) Right. Below is the pertinent section 1 text in my current draft PR (which is not yet quite finished). Grüße, Carsten ## CBOR related terminology {#label} In JSON, maps are called objects and only have one kind of map key: a string. In COSE, we use both strings and integers (both unsigned and negative integers) as map keys, as well as data items to identify specific choices. The (negative and unsigned) integers are used for compactness of encoding and easy comparison. Since the word "key" is mainly used in its other meaning as a cryptographic key, we use the term "label" for this usage of either an integer or a string to identify map keys and choice data items. ~~~~ CDDL label = int / tstr ~~~~ From nobody Sat Jun 13 12:32:29 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E51D1ACDF1 for ; Sat, 13 Jun 2015 12:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 8hF9W6yYr4fx for ; Sat, 13 Jun 2015 12:32:26 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0720.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::720]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4CC41ACDED for ; Sat, 13 Jun 2015 12:32:25 -0700 (PDT) Received: from BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) by BY2PR03MB222.namprd03.prod.outlook.com (10.242.36.146) with Microsoft SMTP Server (TLS) id 15.1.190.9; Sat, 13 Jun 2015 19:32:21 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.195.6; Sat, 13 Jun 2015 19:32:21 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0195.005; Sat, 13 Jun 2015 19:32:20 +0000 From: Mike Jones To: Carsten Bormann Thread-Topic: [Cose] Editorial: New term "label" Thread-Index: AQHQpatZ9WeHKwZD4EyojavvdG42XJ2qgcUAgAAb3cqAAAgOgIAALk1d Date: Sat, 13 Jun 2015 19:32:20 +0000 Message-ID: References: <557BDCA9.1090308@tzi.org>, <002b01d0a5e6$8ed94850$ac8bd8f0$@augustcellars.com> , <557C5E6D.9020308@tzi.org> In-Reply-To: <557C5E6D.9020308@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tzi.org; dkim=none (message not signed) header.d=none; x-originating-ip: [50.47.90.173] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:EKdbXh4Bb2JfEgucDfLIc9h6R8Qg0MD+Fe+nmE3gG+zMiP74meCkMLhP30MctC1KWIsKI1Ts3WeQ+YccUi2GRlwHOnxo87yWaJTLVk/ILx6H15wjMBUp3B6NpAY0kmmkd84v9f5mj4A4sHy8WHLARw==; 24:RDs+PQJAnJMQIqXux7c0y65YjEpd5taY0EtpJYhQcObcRPADFX856tQTJprTyUHD4Bc9odDK0tgxHWIBiXPpEC01gMTtNi9UpJBsBxpD/b0=; 20:6a09iEo75PW238h00hJoVmgwrRN0uGlDVNemYhqBIErLGc5A8qjirYgvc50MJPszEmVhQT9Qfj3VmINq4QJicg== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB222; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0606BBEB39 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(122556002)(76176999)(54356999)(99286002)(5003600100002)(2950100001)(2900100001)(19580405001)(106116001)(19580395003)(15975445007)(40100003)(102836002)(77096005)(50986999)(66066001)(19625215002)(77156002)(62966003)(16236675004)(5001920100001)(5001960100002)(110136002)(189998001)(33656002)(87936001)(2656002)(93886004)(86612001)(86362001)(76576001)(5002640100001)(74316001)(92566002)(19617315012)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4421A35A4AB84A97F992749F5BA0BY2PR03MB442namprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2015 19:32:20.5754 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 X-Microsoft-Exchange-Diagnostics: 1; BY2PR03MB222; 2:3gze2Gvsh1cSdKPIUZ37fYvs3LTfFpXq0UIuuIl9b9HjN8FR5rc+d6fr5WApbfcX; 2:Kbbf0EXU1+Ci9/QzcFoErCvaYj7ndbzJuwohNjnkwSqXrqXx0QDtTkS7NDOPHLsYoS2Sjv+XdjExmMgEJr6qnhKpRb+zZarRaATmCW7z0opWhgreXrzC+1Q0sXD0hnjZK4hbeUXfP/IC/fRz5H8NaQ==; 9:2Snjtai8t3IikMDHnG6cuxDRv9e+gP+Gu5O0e1SJDuk2GUfoNWAMe0QBwqn/Lrde/cmmk9WQ/+UE1rekfieRy+JbOUOkytgzcRVk6VXTnDgf1KAFrwQVmc4JojR+Qrva57soRIO8PMYD67E0otyRAg== X-OriginatorOrg: microsoft.com Archived-At: Cc: Jim Schaad , "cose@ietf.org" Subject: Re: [Cose] Editorial: New term "label" X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 19:32:28 -0000 --_000_BY2PR03MB4421A35A4AB84A97F992749F5BA0BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBDYXJzdGVuIEJvcm1h bm48bWFpbHRvOmNhYm9AdHppLm9yZz4NClNlbnQ6IOKAjjYv4oCOMTMv4oCOMjAxNSA5OjQ2IEFN DQpUbzogTWlrZSBKb25lczxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0KQ2M6 IEppbSBTY2hhYWQ8bWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20+OyBjb3NlQGlldGYub3Jn PG1haWx0bzpjb3NlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtDb3NlXSBFZGl0b3JpYWw6IE5l dyB0ZXJtICJsYWJlbCINCg0KTWlrZSBKb25lcyB3cm90ZToNCj4gSSB3b3VsZCBiZSBvayB3aXRo IHVzaW5nIHRoZSB0ZXJtIExhYmVsIGFuZCBMYWJlbDpWYWx1ZSBwYWlycyBpZiB3ZQ0KPiBleHBs aWNpdGx5IHByb3ZpZGUgYSBkZWZpbml0aW9uIGZvciBvdXIgdXNlIG9mIHRoZSB0ZXJtIGluIHRo ZQ0KPiBUZXJtaW5vbG9neSBzZWN0aW9uLiAgKEluZGVlZCwgdGhhdCdzIHdoYXQgSSB0aG91Z2h0 IENhcnN0ZW4gd2FzIHByb3Bvc2luZy4pDQoNClJpZ2h0LiAgQmVsb3cgaXMgdGhlIHBlcnRpbmVu dCBzZWN0aW9uIDEgdGV4dCBpbiBteSBjdXJyZW50IGRyYWZ0IFBSDQood2hpY2ggaXMgbm90IHll dCBxdWl0ZSBmaW5pc2hlZCkuDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0KDQojIyBDQk9SIHJlbGF0 ZWQgdGVybWlub2xvZ3kgeyNsYWJlbH0NCg0KSW4gSlNPTiwgbWFwcyBhcmUgY2FsbGVkIG9iamVj dHMgYW5kIG9ubHkgaGF2ZSBvbmUga2luZCBvZiBtYXAga2V5OiBhDQpzdHJpbmcuDQpJbiBDT1NF LCB3ZSB1c2UgYm90aCBzdHJpbmdzIGFuZCBpbnRlZ2VycyAoYm90aCB1bnNpZ25lZCBhbmQgbmVn YXRpdmUNCmludGVnZXJzKSBhcyBtYXAga2V5cywgYXMgd2VsbCBhcyBkYXRhIGl0ZW1zIHRvIGlk ZW50aWZ5IHNwZWNpZmljDQpjaG9pY2VzLg0KVGhlIChuZWdhdGl2ZSBhbmQgdW5zaWduZWQpIGlu dGVnZXJzIGFyZSB1c2VkIGZvciBjb21wYWN0bmVzcyBvZg0KZW5jb2RpbmcgYW5kIGVhc3kgY29t cGFyaXNvbi4NClNpbmNlIHRoZSB3b3JkICJrZXkiIGlzIG1haW5seSB1c2VkIGluIGl0cyBvdGhl ciBtZWFuaW5nIGFzIGENCmNyeXB0b2dyYXBoaWMga2V5LCB3ZSB1c2UgdGhlIHRlcm0gImxhYmVs IiBmb3IgdGhpcyB1c2FnZSBvZiBlaXRoZXIgYW4NCmludGVnZXIgb3IgYSBzdHJpbmcgdG8gaWRl bnRpZnkgbWFwIGtleXMgYW5kIGNob2ljZSBkYXRhIGl0ZW1zLg0KDQp+fn5+IENEREwNCg0KbGFi ZWwgPSBpbnQgLyB0c3RyDQoNCn5+fn4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkNvc2UgbWFpbGluZyBsaXN0DQpDb3NlQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2UNCg== --_000_BY2PR03MB4421A35A4AB84A97F992749F5BA0BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg LS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+JiM0MzsxPGJyPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXYgZGlyPSJsdHIiPg0KPGhyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPkZyb206DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1z aXplOjExcHQiPjxhIGhyZWY9Im1haWx0bzpjYWJvQHR6aS5vcmciPkNhcnN0ZW4gQm9ybWFubjwv YT48L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJp ZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6DQo8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPuKA jjYv4oCOMTMv4oCOMjAxNSA5OjQ2IEFNPC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0OyBmb250LXdlaWdodDpib2xk Ij5UbzoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlm OyBmb250LXNpemU6MTFwdCI+PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbSI+TWlrZSBKb25lczwvYT48L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPkNj Og0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZv bnQtc2l6ZToxMXB0Ij48YSBocmVmPSJtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbSI+Smlt IFNjaGFhZDwvYT47DQo8YSBocmVmPSJtYWlsdG86Y29zZUBpZXRmLm9yZyI+Y29zZUBpZXRmLm9y ZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1z ZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6DQo8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjEx cHQiPlJlOiBbQ29zZV0gRWRpdG9yaWFsOiBOZXcgdGVybSAmcXVvdDtsYWJlbCZxdW90Ozwvc3Bh bj48YnI+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMHB0OyI+DQo8ZGl2IGNsYXNzPSJQbGFpblRleHQiPk1pa2UgSm9uZXMgd3Jv dGU6PGJyPg0KJmd0OyBJIHdvdWxkIGJlIG9rIHdpdGggdXNpbmcgdGhlIHRlcm0gTGFiZWwgYW5k IExhYmVsOlZhbHVlIHBhaXJzIGlmIHdlPGJyPg0KJmd0OyBleHBsaWNpdGx5IHByb3ZpZGUgYSBk ZWZpbml0aW9uIGZvciBvdXIgdXNlIG9mIHRoZSB0ZXJtIGluIHRoZTxicj4NCiZndDsgVGVybWlu b2xvZ3kgc2VjdGlvbi4mbmJzcDsgKEluZGVlZCwgdGhhdCdzIHdoYXQgSSB0aG91Z2h0IENhcnN0 ZW4gd2FzIHByb3Bvc2luZy4pPGJyPg0KPGJyPg0KUmlnaHQuJm5ic3A7IEJlbG93IGlzIHRoZSBw ZXJ0aW5lbnQgc2VjdGlvbiAxIHRleHQgaW4gbXkgY3VycmVudCBkcmFmdCBQUjxicj4NCih3aGlj aCBpcyBub3QgeWV0IHF1aXRlIGZpbmlzaGVkKS48YnI+DQo8YnI+DQpHcsO8w59lLCBDYXJzdGVu PGJyPg0KPGJyPg0KPGJyPg0KIyMgQ0JPUiByZWxhdGVkIHRlcm1pbm9sb2d5IHsjbGFiZWx9PGJy Pg0KPGJyPg0KSW4gSlNPTiwgbWFwcyBhcmUgY2FsbGVkIG9iamVjdHMgYW5kIG9ubHkgaGF2ZSBv bmUga2luZCBvZiBtYXAga2V5OiBhPGJyPg0Kc3RyaW5nLjxicj4NCkluIENPU0UsIHdlIHVzZSBi b3RoIHN0cmluZ3MgYW5kIGludGVnZXJzIChib3RoIHVuc2lnbmVkIGFuZCBuZWdhdGl2ZTxicj4N CmludGVnZXJzKSBhcyBtYXAga2V5cywgYXMgd2VsbCBhcyBkYXRhIGl0ZW1zIHRvIGlkZW50aWZ5 IHNwZWNpZmljPGJyPg0KY2hvaWNlcy48YnI+DQpUaGUgKG5lZ2F0aXZlIGFuZCB1bnNpZ25lZCkg aW50ZWdlcnMgYXJlIHVzZWQgZm9yIGNvbXBhY3RuZXNzIG9mPGJyPg0KZW5jb2RpbmcgYW5kIGVh c3kgY29tcGFyaXNvbi48YnI+DQpTaW5jZSB0aGUgd29yZCAmcXVvdDtrZXkmcXVvdDsgaXMgbWFp bmx5IHVzZWQgaW4gaXRzIG90aGVyIG1lYW5pbmcgYXMgYTxicj4NCmNyeXB0b2dyYXBoaWMga2V5 LCB3ZSB1c2UgdGhlIHRlcm0gJnF1b3Q7bGFiZWwmcXVvdDsgZm9yIHRoaXMgdXNhZ2Ugb2YgZWl0 aGVyIGFuPGJyPg0KaW50ZWdlciBvciBhIHN0cmluZyB0byBpZGVudGlmeSBtYXAga2V5cyBhbmQg Y2hvaWNlIGRhdGEgaXRlbXMuPGJyPg0KPGJyPg0Kfn5+fiBDRERMPGJyPg0KPGJyPg0KbGFiZWwg PSBpbnQgLyB0c3RyPGJyPg0KPGJyPg0Kfn5+fjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KQ29zZSBtYWlsaW5nIGxpc3Q8YnI+ DQpDb3NlQGlldGYub3JnPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9jb3NlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nv c2U8L2E+PGJyPg0KPC9kaXY+DQo8L3NwYW4+PC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BY2PR03MB4421A35A4AB84A97F992749F5BA0BY2PR03MB442namprd_-- From nobody Thu Jun 18 12:15:12 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481A11B33F7 for ; Thu, 18 Jun 2015 12:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.4 X-Spam-Level: * X-Spam-Status: No, score=1.4 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 6QOeOA2VAbgW for ; Thu, 18 Jun 2015 12:15:10 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C10F1B33F5 for ; Thu, 18 Jun 2015 12:15:10 -0700 (PDT) Received: from hebrews (unknown [50.109.240.20]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 70E5738F4E; Thu, 18 Jun 2015 12:15:09 -0700 (PDT) From: "Jim Schaad" To: "'Carsten Bormann'" References: <557BDCA9.1090308@tzi.org>, <002b01d0a5e6$8ed94850$ac8bd8f0$@augustcellars.com> <557C5E6D.9020308@tzi.org> In-Reply-To: <557C5E6D.9020308@tzi.org> Date: Thu, 18 Jun 2015 12:15:18 -0700 Message-ID: <026b01d0a9fb$1e3639a0$5aa2ace0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQH8U6MrgwBGyu21t+BNKuZ0X0SMTAHd/k3cAfwJDG0CCfM9np0sLYrA Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] Editorial: New term "label" X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 19:15:11 -0000 Carsten, Looking at your pull request, I find that you basically did do the one = thing that I referred to in my original message about potentially having = a new confusion develop. Looking at your definition for COSE_KEY Label =3D> int / tstr COSE_Key =3D { kty =3D> label, ? key_ops =3D> [+label ], ? alg =3D> label, ? kid =3D> bstr, * keys =3D> values } You are suggesting using label as the value portion of kty, key_ops and = alg. However the value that is placed in these fields is never used as = a map key in any location. We are therefore having the term lable (or = at least the type) used both where it is referring to something that = would be a key as well as something that is just a value. I do believe that the use of label is completely correct for something = type 'crit' as what it refers to is labels. Thus crit =3D> [+label]=20 Is a totally reasonable CDDL for that item. I would prefer to keep these the term for key and the type of int/tstr = separate. Jim > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Saturday, June 13, 2015 9:47 AM > To: Mike Jones > Cc: Jim Schaad; cose@ietf.org > Subject: Re: [Cose] Editorial: New term "label" >=20 > Mike Jones wrote: > > I would be ok with using the term Label and Label:Value pairs if we > > explicitly provide a definition for our use of the term in the > > Terminology section. (Indeed, that's what I thought Carsten was > > proposing.) >=20 > Right. Below is the pertinent section 1 text in my current draft PR = (which is > not yet quite finished). >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > ## CBOR related terminology {#label} >=20 > In JSON, maps are called objects and only have one kind of map key: a > string. > In COSE, we use both strings and integers (both unsigned and negative > integers) as map keys, as well as data items to identify specific = choices. > The (negative and unsigned) integers are used for compactness of = encoding > and easy comparison. > Since the word "key" is mainly used in its other meaning as a = cryptographic > key, we use the term "label" for this usage of either an integer or a = string to > identify map keys and choice data items. >=20 > ~~~~ CDDL >=20 > label =3D int / tstr >=20 > ~~~~ From nobody Thu Jun 18 12:39:35 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9561B3414 for ; Thu, 18 Jun 2015 12:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.3 X-Spam-Level: * X-Spam-Status: No, score=1.3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_55=0.6] autolearn=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 QJ0In53n8R1c for ; Thu, 18 Jun 2015 12:39:33 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D18981B341D for ; Thu, 18 Jun 2015 12:39:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 5AEF4E2035; Thu, 18 Jun 2015 15:39:16 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 16266-05; Thu, 18 Jun 2015 15:39:13 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id D0E09E2036; Thu, 18 Jun 2015 15:39:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1434656352; bh=Vn249a6B+pyrlSCx1v9Wat/fsNWu3084JItpqRKYR/0=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=P36dNHCR8dbtSMbhbTqEX060XMtu+hFMl065SDl08vVGuOSUE6kJf/rn+3/+L0xeH CpNBvAbVxRSrvAcd2KnmIkiDbQd/k7mjxm+9dQ5t0YQTK07cAAs3+ivmgzqZ8Achvk DwEhFfcxmAdFF83vTvhSI19Nt9JxxRjNlIcO2W2c= Received: from 192.168.248.204 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 18 Jun 2015 15:39:12 -0400 Message-ID: <543905cf2e4cadbe8429f4d948b62f98.squirrel@mail2.ihtfp.org> In-Reply-To: <026b01d0a9fb$1e3639a0$5aa2ace0$@augustcellars.com> References: <557BDCA9.1090308@tzi.org>, <002b01d0a5e6$8ed94850$ac8bd8f0$@augustcellars.com> <557C5E6D.9020308@tzi.org> <026b01d0a9fb$1e3639a0$5aa2ace0$@augustcellars.com> Date: Thu, 18 Jun 2015 15:39:12 -0400 From: "Derek Atkins" To: "Jim Schaad" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: 'Carsten Bormann' , cose@ietf.org Subject: Re: [Cose] Editorial: New term "label" X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 19:39:34 -0000 Jim, Do you think you'd prefer something that looks more like: label => int / tstr value => int / tstr COSE_Key = { kty => value, ? key_ops => [+value ], ? alg => value, ? kid => bstr, * keys => values } (I'm not sure if "value" is the appropriate name to use, and I'm not sure if "keys" should be changed to "label" in the last line) -derek On Thu, June 18, 2015 3:15 pm, Jim Schaad wrote: > Carsten, > > Looking at your pull request, I find that you basically did do the one > thing that I referred to in my original message about potentially having a > new confusion develop. > > Looking at your definition for COSE_KEY > > Label => int / tstr > > COSE_Key = { > kty => label, > ? key_ops => [+label ], > ? alg => label, > ? kid => bstr, > * keys => values > } > > You are suggesting using label as the value portion of kty, key_ops and > alg. However the value that is placed in these fields is never used as a > map key in any location. We are therefore having the term lable (or at > least the type) used both where it is referring to something that would be > a key as well as something that is just a value. > > I do believe that the use of label is completely correct for something > type 'crit' as what it refers to is labels. Thus > crit => [+label] > Is a totally reasonable CDDL for that item. > > I would prefer to keep these the term for key and the type of int/tstr > separate. > > Jim > > >> -----Original Message----- >> From: Carsten Bormann [mailto:cabo@tzi.org] >> Sent: Saturday, June 13, 2015 9:47 AM >> To: Mike Jones >> Cc: Jim Schaad; cose@ietf.org >> Subject: Re: [Cose] Editorial: New term "label" >> >> Mike Jones wrote: >> > I would be ok with using the term Label and Label:Value pairs if we >> > explicitly provide a definition for our use of the term in the >> > Terminology section. (Indeed, that's what I thought Carsten was >> > proposing.) >> >> Right. Below is the pertinent section 1 text in my current draft PR >> (which is >> not yet quite finished). >> >> Grüße, Carsten >> >> >> ## CBOR related terminology {#label} >> >> In JSON, maps are called objects and only have one kind of map key: a >> string. >> In COSE, we use both strings and integers (both unsigned and negative >> integers) as map keys, as well as data items to identify specific >> choices. >> The (negative and unsigned) integers are used for compactness of >> encoding >> and easy comparison. >> Since the word "key" is mainly used in its other meaning as a >> cryptographic >> key, we use the term "label" for this usage of either an integer or a >> string to >> identify map keys and choice data items. >> >> ~~~~ CDDL >> >> label = int / tstr >> >> ~~~~ > > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Jun 18 12:53:43 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8FB1B3442 for ; Thu, 18 Jun 2015 12:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.597 X-Spam-Level: X-Spam-Status: No, score=0.597 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 3FUJpwTDMXdD for ; Thu, 18 Jun 2015 12:53:40 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0122.outbound.protection.outlook.com [65.55.169.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB8DB1A90AB for ; Thu, 18 Jun 2015 12:53:39 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.195.6; Thu, 18 Jun 2015 19:53:37 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0195.005; Thu, 18 Jun 2015 19:53:37 +0000 From: Mike Jones To: Derek Atkins , Jim Schaad Thread-Topic: [Cose] Editorial: New term "label" Thread-Index: AQHQpatZ9WeHKwZD4EyojavvdG42XJ2qgcUAgAAb3cqAAAgOgIAIBTMAgAAGrQCAAAOrEA== Date: Thu, 18 Jun 2015 19:53:36 +0000 Message-ID: References: <557BDCA9.1090308@tzi.org>, <002b01d0a5e6$8ed94850$ac8bd8f0$@augustcellars.com> <557C5E6D.9020308@tzi.org> <026b01d0a9fb$1e3639a0$5aa2ace0$@augustcellars.com> <543905cf2e4cadbe8429f4d948b62f98.squirrel@mail2.ihtfp.org> In-Reply-To: <543905cf2e4cadbe8429f4d948b62f98.squirrel@mail2.ihtfp.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ihtfp.com; dkim=none (message not signed) header.d=none; x-originating-ip: [50.47.90.173] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:fevUnO+DJmnVEWHerpSavNAclBlSONAnXq5UNklqQWyjNLDmyx7oj0oAB30vs8XNJregbYNhRfANKU+GgDtL4701Dj8DLg8F/V+SbD4aLyVZYGK86xJXAFqd6V6CuARc91MpXyOBDWS7P2gEbWDIYQ==; 24:sY+JsX8MbckTHbv6zchNIw8H8rg4XhX4cHB72FTuW5PnWB+WzeqmlqhCHIvUocYpk0p8uZz/PGVahDEw0kMcwAY0xNM3CgwvcPnS+wuYisE=; 20:8sshdnYTpwIZrVH79W1VaaI9SMknWRFv8lCLe9fbIvwzSJtmivPJyUa/2CPMFgVJ4wpDX0+63FmhXCeNkbSwmw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 0611A21987 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(377454003)(51704005)(15974865002)(33656002)(66066001)(5002640100001)(5003600100002)(74316001)(19580395003)(77156002)(62966003)(5001770100001)(40100003)(92566002)(5001960100002)(189998001)(122556002)(19580405001)(2950100001)(2900100001)(54356999)(50986999)(76176999)(2656002)(87936001)(86612001)(102836002)(15975445007)(77096005)(86362001)(106116001)(46102003)(93886004)(76576001)(99286002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2015 19:53:36.9561 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Cc: 'Carsten Bormann' , "cose@ietf.org" Subject: Re: [Cose] Editorial: New term "label" X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 19:53:41 -0000 VmFsdWUgY2FuIGJlIGFueSBDQk9SIHR5cGUsIGluY2x1ZGluZyBhcnJheXMsIHN0cnVjdHVyZXMs IEJvb2xlYW5zLCBhbmQgbnVsbCwgbm90IGp1c3QgaW50IG9yIHRzdHIuDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDb3NlIFttYWlsdG86Y29zZS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgRGVyZWsgQXRraW5zDQpTZW50OiBUaHVyc2RheSwgSnVuZSAxOCwgMjAx NSAxMjozOSBQTQ0KVG86IEppbSBTY2hhYWQNCkNjOiAnQ2Fyc3RlbiBCb3JtYW5uJzsgY29zZUBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtDb3NlXSBFZGl0b3JpYWw6IE5ldyB0ZXJtICJsYWJlbCIN Cg0KSmltLA0KDQpEbyB5b3UgdGhpbmsgeW91J2QgcHJlZmVyIHNvbWV0aGluZyB0aGF0IGxvb2tz IG1vcmUgbGlrZToNCg0KbGFiZWwgPT4gaW50IC8gdHN0cg0KdmFsdWUgPT4gaW50IC8gdHN0cg0K DQpDT1NFX0tleSA9IHsNCiAgICBrdHkgPT4gdmFsdWUsDQogICAgPyBrZXlfb3BzID0+IFsrdmFs dWUgXSwNCiAgICA/IGFsZyA9PiB2YWx1ZSwNCiAgICA/IGtpZCA9PiBic3RyLA0KICAgICoga2V5 cyA9PiB2YWx1ZXMNCiB9DQoNCg0KKEknbSBub3Qgc3VyZSBpZiAidmFsdWUiIGlzIHRoZSBhcHBy b3ByaWF0ZSBuYW1lIHRvIHVzZSwgYW5kIEknbSBub3Qgc3VyZSBpZiAia2V5cyIgc2hvdWxkIGJl IGNoYW5nZWQgdG8gImxhYmVsIiBpbiB0aGUgbGFzdCBsaW5lKQ0KDQotZGVyZWsNCg0KT24gVGh1 LCBKdW5lIDE4LCAyMDE1IDM6MTUgcG0sIEppbSBTY2hhYWQgd3JvdGU6DQo+IENhcnN0ZW4sDQo+ DQo+IExvb2tpbmcgYXQgeW91ciBwdWxsIHJlcXVlc3QsIEkgZmluZCB0aGF0IHlvdSBiYXNpY2Fs bHkgZGlkIGRvIHRoZSBvbmUgDQo+IHRoaW5nIHRoYXQgSSByZWZlcnJlZCB0byBpbiBteSBvcmln aW5hbCBtZXNzYWdlIGFib3V0IHBvdGVudGlhbGx5IA0KPiBoYXZpbmcgYSBuZXcgY29uZnVzaW9u IGRldmVsb3AuDQo+DQo+IExvb2tpbmcgYXQgeW91ciBkZWZpbml0aW9uIGZvciBDT1NFX0tFWQ0K Pg0KPiBMYWJlbCA9PiBpbnQgLyB0c3RyDQo+DQo+IENPU0VfS2V5ID0gew0KPiAgICAga3R5ID0+ IGxhYmVsLA0KPiAgICAgPyBrZXlfb3BzID0+IFsrbGFiZWwgXSwNCj4gICAgID8gYWxnID0+IGxh YmVsLA0KPiAgICAgID8ga2lkID0+IGJzdHIsDQo+ICAgICAgKiBrZXlzID0+IHZhbHVlcw0KPiAg fQ0KPg0KPiBZb3UgYXJlIHN1Z2dlc3RpbmcgdXNpbmcgbGFiZWwgYXMgdGhlIHZhbHVlIHBvcnRp b24gb2Yga3R5LCBrZXlfb3BzIGFuZA0KPiBhbGcuICAgSG93ZXZlciB0aGUgdmFsdWUgdGhhdCBp cyBwbGFjZWQgaW4gdGhlc2UgZmllbGRzIGlzIG5ldmVyIHVzZWQgYXMgYQ0KPiBtYXAga2V5IGlu IGFueSBsb2NhdGlvbi4gIFdlIGFyZSB0aGVyZWZvcmUgaGF2aW5nIHRoZSB0ZXJtIGxhYmxlIChv ciANCj4gYXQgbGVhc3QgdGhlIHR5cGUpIHVzZWQgYm90aCB3aGVyZSBpdCBpcyByZWZlcnJpbmcg dG8gc29tZXRoaW5nIHRoYXQgDQo+IHdvdWxkIGJlIGEga2V5IGFzIHdlbGwgYXMgc29tZXRoaW5n IHRoYXQgaXMganVzdCBhIHZhbHVlLg0KPg0KPiBJIGRvIGJlbGlldmUgdGhhdCB0aGUgdXNlIG9m IGxhYmVsIGlzIGNvbXBsZXRlbHkgY29ycmVjdCBmb3Igc29tZXRoaW5nIA0KPiB0eXBlICdjcml0 JyBhcyB3aGF0IGl0IHJlZmVycyB0byBpcyBsYWJlbHMuICBUaHVzDQo+ICAgICBjcml0ID0+IFsr bGFiZWxdDQo+IElzIGEgdG90YWxseSByZWFzb25hYmxlIENEREwgZm9yIHRoYXQgaXRlbS4NCj4N Cj4gSSB3b3VsZCBwcmVmZXIgdG8ga2VlcCB0aGVzZSB0aGUgdGVybSBmb3Iga2V5IGFuZCB0aGUg dHlwZSBvZiBpbnQvdHN0ciANCj4gc2VwYXJhdGUuDQo+DQo+IEppbQ0KPg0KPg0KPj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IENhcnN0ZW4gQm9ybWFubiBbbWFpbHRvOmNh Ym9AdHppLm9yZ10NCj4+IFNlbnQ6IFNhdHVyZGF5LCBKdW5lIDEzLCAyMDE1IDk6NDcgQU0NCj4+ IFRvOiBNaWtlIEpvbmVzDQo+PiBDYzogSmltIFNjaGFhZDsgY29zZUBpZXRmLm9yZw0KPj4gU3Vi amVjdDogUmU6IFtDb3NlXSBFZGl0b3JpYWw6IE5ldyB0ZXJtICJsYWJlbCINCj4+DQo+PiBNaWtl IEpvbmVzIHdyb3RlOg0KPj4gPiBJIHdvdWxkIGJlIG9rIHdpdGggdXNpbmcgdGhlIHRlcm0gTGFi ZWwgYW5kIExhYmVsOlZhbHVlIHBhaXJzIGlmIHdlIA0KPj4gPiBleHBsaWNpdGx5IHByb3ZpZGUg YSBkZWZpbml0aW9uIGZvciBvdXIgdXNlIG9mIHRoZSB0ZXJtIGluIHRoZSANCj4+ID4gVGVybWlu b2xvZ3kgc2VjdGlvbi4gIChJbmRlZWQsIHRoYXQncyB3aGF0IEkgdGhvdWdodCBDYXJzdGVuIHdh cw0KPj4gPiBwcm9wb3NpbmcuKQ0KPj4NCj4+IFJpZ2h0LiAgQmVsb3cgaXMgdGhlIHBlcnRpbmVu dCBzZWN0aW9uIDEgdGV4dCBpbiBteSBjdXJyZW50IGRyYWZ0IFBSIA0KPj4gKHdoaWNoIGlzIG5v dCB5ZXQgcXVpdGUgZmluaXNoZWQpLg0KPj4NCj4+IEdyw7zDn2UsIENhcnN0ZW4NCj4+DQo+Pg0K Pj4gIyMgQ0JPUiByZWxhdGVkIHRlcm1pbm9sb2d5IHsjbGFiZWx9DQo+Pg0KPj4gSW4gSlNPTiwg bWFwcyBhcmUgY2FsbGVkIG9iamVjdHMgYW5kIG9ubHkgaGF2ZSBvbmUga2luZCBvZiBtYXAga2V5 OiBhIA0KPj4gc3RyaW5nLg0KPj4gSW4gQ09TRSwgd2UgdXNlIGJvdGggc3RyaW5ncyBhbmQgaW50 ZWdlcnMgKGJvdGggdW5zaWduZWQgYW5kIG5lZ2F0aXZlDQo+PiBpbnRlZ2VycykgYXMgbWFwIGtl eXMsIGFzIHdlbGwgYXMgZGF0YSBpdGVtcyB0byBpZGVudGlmeSBzcGVjaWZpYyANCj4+IGNob2lj ZXMuDQo+PiBUaGUgKG5lZ2F0aXZlIGFuZCB1bnNpZ25lZCkgaW50ZWdlcnMgYXJlIHVzZWQgZm9y IGNvbXBhY3RuZXNzIG9mIA0KPj4gZW5jb2RpbmcgYW5kIGVhc3kgY29tcGFyaXNvbi4NCj4+IFNp bmNlIHRoZSB3b3JkICJrZXkiIGlzIG1haW5seSB1c2VkIGluIGl0cyBvdGhlciBtZWFuaW5nIGFz IGEgDQo+PiBjcnlwdG9ncmFwaGljIGtleSwgd2UgdXNlIHRoZSB0ZXJtICJsYWJlbCIgZm9yIHRo aXMgdXNhZ2Ugb2YgZWl0aGVyIA0KPj4gYW4gaW50ZWdlciBvciBhIHN0cmluZyB0byBpZGVudGlm eSBtYXAga2V5cyBhbmQgY2hvaWNlIGRhdGEgaXRlbXMuDQo+Pg0KPj4gfn5+fiBDRERMDQo+Pg0K Pj4gbGFiZWwgPSBpbnQgLyB0c3RyDQo+Pg0KPj4gfn5+fg0KPg0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBDb3NlIG1haWxpbmcgbGlzdA0KPiBD b3NlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29z ZQ0KPg0KDQoNCi0tIA0KICAgICAgIERlcmVrIEF0a2lucyAgICAgICAgICAgICAgICAgNjE3LTYy My0zNzQ1DQogICAgICAgZGVyZWtAaWh0ZnAuY29tICAgICAgICAgICAgIHd3dy5paHRmcC5jb20N CiAgICAgICBDb21wdXRlciBhbmQgSW50ZXJuZXQgU2VjdXJpdHkgQ29uc3VsdGFudA0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ29zZSBtYWlsaW5n IGxpc3QNCkNvc2VAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY29zZQ0K From nobody Thu Jun 18 13:02:26 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896231B2D5E for ; Thu, 18 Jun 2015 13:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.121 X-Spam-Level: ** X-Spam-Status: No, score=2.121 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_55=0.6, T_DKIM_INVALID=0.01] autolearn=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 64HRj87nrvCp for ; Thu, 18 Jun 2015 13:02:24 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84431A0084 for ; Thu, 18 Jun 2015 13:02:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 5AD6AE2035; Thu, 18 Jun 2015 16:02:22 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 16266-09; Thu, 18 Jun 2015 16:02:19 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 72368E2036; Thu, 18 Jun 2015 16:02:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1434657739; bh=TR7XwydoI9VrhxIeBVdZ38MOMxqKFTlJKKWp0L+u0Vs=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=rVq1bh1dU14FsZ5eHne7OMYb5itLQXGx3SrtBfGBiHP58TL1PUCk9ttyULHGEFJF3 6y2nwYLOhc8kVVmwRD4TF89o+JKbh4VDMKwWNlzzxLsR4zuzt57LDNqieDhjxL3/G7 VFNe4D/siHPS2A6Eg4OlKZp9mL6heLGKBKLvTTrw= Received: from 192.168.248.204 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 18 Jun 2015 16:02:19 -0400 Message-ID: <3301a7f05d5bec8ce19217e063f494d2.squirrel@mail2.ihtfp.org> In-Reply-To: References: <557BDCA9.1090308@tzi.org>, <002b01d0a5e6$8ed94850$ac8bd8f0$@augustcellars.com> <557C5E6D.9020308@tzi.org> <026b01d0a9fb$1e3639a0$5aa2ace0$@augustcellars.com> <543905cf2e4cadbe8429f4d948b62f98.squirrel@mail2.ihtfp.org> Date: Thu, 18 Jun 2015 16:02:19 -0400 From: "Derek Atkins" To: "Mike Jones" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Jim Schaad , 'Carsten Bormann' , "cose@ietf.org" Subject: Re: [Cose] Editorial: New term "label" X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 20:02:25 -0000 Would you rather I called it "int_or_string_value"? The kty label can only have an int or tstr value, but we don't want to label it "label". -derek On Thu, June 18, 2015 3:53 pm, Mike Jones wrote: > Value can be any CBOR type, including arrays, structures, Booleans, and > null, not just int or tstr. > > -----Original Message----- > From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Derek Atkins > Sent: Thursday, June 18, 2015 12:39 PM > To: Jim Schaad > Cc: 'Carsten Bormann'; cose@ietf.org > Subject: Re: [Cose] Editorial: New term "label" > > Jim, > > Do you think you'd prefer something that looks more like: > > label => int / tstr > value => int / tstr > > COSE_Key = { > kty => value, > ? key_ops => [+value ], > ? alg => value, > ? kid => bstr, > * keys => values > } > > > (I'm not sure if "value" is the appropriate name to use, and I'm not sure > if "keys" should be changed to "label" in the last line) > > -derek > > On Thu, June 18, 2015 3:15 pm, Jim Schaad wrote: >> Carsten, >> >> Looking at your pull request, I find that you basically did do the one >> thing that I referred to in my original message about potentially >> having a new confusion develop. >> >> Looking at your definition for COSE_KEY >> >> Label => int / tstr >> >> COSE_Key = { >> kty => label, >> ? key_ops => [+label ], >> ? alg => label, >> ? kid => bstr, >> * keys => values >> } >> >> You are suggesting using label as the value portion of kty, key_ops and >> alg. However the value that is placed in these fields is never used as >> a >> map key in any location. We are therefore having the term lable (or >> at least the type) used both where it is referring to something that >> would be a key as well as something that is just a value. >> >> I do believe that the use of label is completely correct for something >> type 'crit' as what it refers to is labels. Thus >> crit => [+label] >> Is a totally reasonable CDDL for that item. >> >> I would prefer to keep these the term for key and the type of int/tstr >> separate. >> >> Jim >> >> >>> -----Original Message----- >>> From: Carsten Bormann [mailto:cabo@tzi.org] >>> Sent: Saturday, June 13, 2015 9:47 AM >>> To: Mike Jones >>> Cc: Jim Schaad; cose@ietf.org >>> Subject: Re: [Cose] Editorial: New term "label" >>> >>> Mike Jones wrote: >>> > I would be ok with using the term Label and Label:Value pairs if we >>> > explicitly provide a definition for our use of the term in the >>> > Terminology section. (Indeed, that's what I thought Carsten was >>> > proposing.) >>> >>> Right. Below is the pertinent section 1 text in my current draft PR >>> (which is not yet quite finished). >>> >>> Grüße, Carsten >>> >>> >>> ## CBOR related terminology {#label} >>> >>> In JSON, maps are called objects and only have one kind of map key: a >>> string. >>> In COSE, we use both strings and integers (both unsigned and negative >>> integers) as map keys, as well as data items to identify specific >>> choices. >>> The (negative and unsigned) integers are used for compactness of >>> encoding and easy comparison. >>> Since the word "key" is mainly used in its other meaning as a >>> cryptographic key, we use the term "label" for this usage of either >>> an integer or a string to identify map keys and choice data items. >>> >>> ~~~~ CDDL >>> >>> label = int / tstr >>> >>> ~~~~ >> >> _______________________________________________ >> Cose mailing list >> Cose@ietf.org >> https://www.ietf.org/mailman/listinfo/cose >> > > > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Jun 18 13:16:19 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB991B34D2 for ; Thu, 18 Jun 2015 13:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 IMkNk8nq1khI for ; Thu, 18 Jun 2015 13:16:16 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0133.outbound.protection.outlook.com [207.46.100.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FFF61B34D0 for ; Thu, 18 Jun 2015 13:16:16 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.195.6; Thu, 18 Jun 2015 20:16:13 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0195.005; Thu, 18 Jun 2015 20:16:13 +0000 From: Mike Jones To: Derek Atkins Thread-Topic: [Cose] Editorial: New term "label" Thread-Index: AQHQpatZ9WeHKwZD4EyojavvdG42XJ2qgcUAgAAb3cqAAAgOgIAIBTMAgAAGrQCAAAOrEIAAAsqAgAAD4y8= Date: Thu, 18 Jun 2015 20:16:13 +0000 Message-ID: References: <557BDCA9.1090308@tzi.org>, <002b01d0a5e6$8ed94850$ac8bd8f0$@augustcellars.com> <557C5E6D.9020308@tzi.org> <026b01d0a9fb$1e3639a0$5aa2ace0$@augustcellars.com> <543905cf2e4cadbe8429f4d948b62f98.squirrel@mail2.ihtfp.org> , <3301a7f05d5bec8ce19217e063f494d2.squirrel@mail2.ihtfp.org> In-Reply-To: <3301a7f05d5bec8ce19217e063f494d2.squirrel@mail2.ihtfp.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ihtfp.com; dkim=none (message not signed) header.d=none; x-originating-ip: [166.176.184.210] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:KIOv8BypDxuleAc2H2FzYQjrjqQzo91ED6yd8ofUNUjey4uSacWKhVk3EggzsR7N8S+GxPGycP4P9Cq4iP7YiECYeTjatkosyXzaK7WNmcWM0HurnJJv4mcPscmTVYBusMY/VQ2xoRf0jA+NIRl7bA==; 24:kislbq3z6AcR3VDa7rf7IVYZNbSqojJZ3Ze25E20rDbe2XUOFqSRVk1/a6rGQGy6legMzKua4BzYSCgT+0lEkyhDqJCOEaWRp58JHUICMrI=; 20:x9H6Y2TXWWEITZPIjyvoqaxn3tfMBe9/zhxZItebUSI2nsMwJMjiAfzCNcg4PE8deJB33SzjAj0FZIpPKh1/2w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 0611A21987 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51704005)(377454003)(24454002)(13464003)(5002640100001)(19625215002)(77156002)(106116001)(62966003)(93886004)(76576001)(19617315012)(66066001)(33656002)(189998001)(92566002)(561944003)(99286002)(110136002)(5001960100002)(16601075003)(86362001)(77096005)(54356999)(102836002)(15975445007)(19580395003)(46102003)(2950100001)(40100003)(122556002)(5003600100002)(74316001)(87936001)(86612001)(19580405001)(2656002)(16236675004)(76176999)(50986999)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442DFEF3520868C090BBAB2F5A50BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2015 20:16:13.4887 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Cc: Jim Schaad , 'Carsten Bormann' , "cose@ietf.org" Subject: Re: [Cose] Editorial: New term "label" X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 20:16:18 -0000 --_000_BY2PR03MB442DFEF3520868C090BBAB2F5A50BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBJJ20gbWlzc2luZyBzb21ldGhpbmcgaGVyZS4gSSB0aG91Z2h0IHRoYXQgd2hhdCB3 ZSB3ZXJlIGRpc2N1c3NpbmcgaW4gdGhpcyB0aHJlYWQgd2FzIGEgcHJvcG9zYWwgdG8gdXNlIHRo ZSB0ZXJtICJsYWJlbCIgZm9yIENCT1Igb2JqZWN0IGtleXMgaW4gb3VyIHNwZWNzLCBzbyB0aGF0 IG9iamVjdHMgd291bGQgYmUgZGVzY3JpYmVkIGFzIGNvbnRhaW5pbmcgbGFiZWw6dmFsdWUgcGFp cnMuDQoNClRoaXMgaXMgdHJ1ZSBvZiBhbGwgbGFiZWxzIC0gbm90IGp1c3Qga3R5IGxhYmVscy4g IFNvIEkgZG9uJ3Qga25vdyB3aHkgeW91IHdvdWxkbid0IHdhbnQgdG8gY2FsbCBhIHNwZWNpZmlj IGxhYmVsIGEgbGFiZWwsIGFzc3VtaW5nIHdlIGFkb3B0IHRoYXQgdGVybWlub2xvZ3kuDQoNCi0t IE1pa2UNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBEZXJlayBBdGtp bnM8bWFpbHRvOmRlcmVrQGlodGZwLmNvbT4NClNlbnQ6IOKAjjYv4oCOMTgv4oCOMjAxNSAxOjAy IFBNDQpUbzogTWlrZSBKb25lczxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPg0K Q2M6IEppbSBTY2hhYWQ8bWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20+OyAnQ2Fyc3RlbiBC b3JtYW5uJzxtYWlsdG86Y2Fib0B0emkub3JnPjsgY29zZUBpZXRmLm9yZzxtYWlsdG86Y29zZUBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQ29zZV0gRWRpdG9yaWFsOiBOZXcgdGVybSAibGFiZWwi DQoNCldvdWxkIHlvdSByYXRoZXIgSSBjYWxsZWQgaXQgImludF9vcl9zdHJpbmdfdmFsdWUiPw0K DQpUaGUga3R5IGxhYmVsIGNhbiBvbmx5IGhhdmUgYW4gaW50IG9yIHRzdHIgdmFsdWUsIGJ1dCB3 ZSBkb24ndCB3YW50IHRvDQpsYWJlbCBpdCAibGFiZWwiLg0KDQotZGVyZWsNCg0KT24gVGh1LCBK dW5lIDE4LCAyMDE1IDM6NTMgcG0sIE1pa2UgSm9uZXMgd3JvdGU6DQo+IFZhbHVlIGNhbiBiZSBh bnkgQ0JPUiB0eXBlLCBpbmNsdWRpbmcgYXJyYXlzLCBzdHJ1Y3R1cmVzLCBCb29sZWFucywgYW5k DQo+IG51bGwsIG5vdCBqdXN0IGludCBvciB0c3RyLg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBDb3NlIFttYWlsdG86Y29zZS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgRGVyZWsgQXRraW5zDQo+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDE4LCAyMDE1IDEy OjM5IFBNDQo+IFRvOiBKaW0gU2NoYWFkDQo+IENjOiAnQ2Fyc3RlbiBCb3JtYW5uJzsgY29zZUBp ZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0Nvc2VdIEVkaXRvcmlhbDogTmV3IHRlcm0gImxhYmVs Ig0KPg0KPiBKaW0sDQo+DQo+IERvIHlvdSB0aGluayB5b3UnZCBwcmVmZXIgc29tZXRoaW5nIHRo YXQgbG9va3MgbW9yZSBsaWtlOg0KPg0KPiBsYWJlbCA9PiBpbnQgLyB0c3RyDQo+IHZhbHVlID0+ IGludCAvIHRzdHINCj4NCj4gQ09TRV9LZXkgPSB7DQo+ICAgICBrdHkgPT4gdmFsdWUsDQo+ICAg ICA/IGtleV9vcHMgPT4gWyt2YWx1ZSBdLA0KPiAgICAgPyBhbGcgPT4gdmFsdWUsDQo+ICAgICA/ IGtpZCA9PiBic3RyLA0KPiAgICAgKiBrZXlzID0+IHZhbHVlcw0KPiAgfQ0KPg0KPg0KPiAoSSdt IG5vdCBzdXJlIGlmICJ2YWx1ZSIgaXMgdGhlIGFwcHJvcHJpYXRlIG5hbWUgdG8gdXNlLCBhbmQg SSdtIG5vdCBzdXJlDQo+IGlmICJrZXlzIiBzaG91bGQgYmUgY2hhbmdlZCB0byAibGFiZWwiIGlu IHRoZSBsYXN0IGxpbmUpDQo+DQo+IC1kZXJlaw0KPg0KPiBPbiBUaHUsIEp1bmUgMTgsIDIwMTUg MzoxNSBwbSwgSmltIFNjaGFhZCB3cm90ZToNCj4+IENhcnN0ZW4sDQo+Pg0KPj4gTG9va2luZyBh dCB5b3VyIHB1bGwgcmVxdWVzdCwgSSBmaW5kIHRoYXQgeW91IGJhc2ljYWxseSBkaWQgZG8gdGhl IG9uZQ0KPj4gdGhpbmcgdGhhdCBJIHJlZmVycmVkIHRvIGluIG15IG9yaWdpbmFsIG1lc3NhZ2Ug YWJvdXQgcG90ZW50aWFsbHkNCj4+IGhhdmluZyBhIG5ldyBjb25mdXNpb24gZGV2ZWxvcC4NCj4+ DQo+PiBMb29raW5nIGF0IHlvdXIgZGVmaW5pdGlvbiBmb3IgQ09TRV9LRVkNCj4+DQo+PiBMYWJl bCA9PiBpbnQgLyB0c3RyDQo+Pg0KPj4gQ09TRV9LZXkgPSB7DQo+PiAgICAga3R5ID0+IGxhYmVs LA0KPj4gICAgID8ga2V5X29wcyA9PiBbK2xhYmVsIF0sDQo+PiAgICAgPyBhbGcgPT4gbGFiZWws DQo+PiAgICAgID8ga2lkID0+IGJzdHIsDQo+PiAgICAgICoga2V5cyA9PiB2YWx1ZXMNCj4+ICB9 DQo+Pg0KPj4gWW91IGFyZSBzdWdnZXN0aW5nIHVzaW5nIGxhYmVsIGFzIHRoZSB2YWx1ZSBwb3J0 aW9uIG9mIGt0eSwga2V5X29wcyBhbmQNCj4+IGFsZy4gICBIb3dldmVyIHRoZSB2YWx1ZSB0aGF0 IGlzIHBsYWNlZCBpbiB0aGVzZSBmaWVsZHMgaXMgbmV2ZXIgdXNlZCBhcw0KPj4gYQ0KPj4gbWFw IGtleSBpbiBhbnkgbG9jYXRpb24uICBXZSBhcmUgdGhlcmVmb3JlIGhhdmluZyB0aGUgdGVybSBs YWJsZSAob3INCj4+IGF0IGxlYXN0IHRoZSB0eXBlKSB1c2VkIGJvdGggd2hlcmUgaXQgaXMgcmVm ZXJyaW5nIHRvIHNvbWV0aGluZyB0aGF0DQo+PiB3b3VsZCBiZSBhIGtleSBhcyB3ZWxsIGFzIHNv bWV0aGluZyB0aGF0IGlzIGp1c3QgYSB2YWx1ZS4NCj4+DQo+PiBJIGRvIGJlbGlldmUgdGhhdCB0 aGUgdXNlIG9mIGxhYmVsIGlzIGNvbXBsZXRlbHkgY29ycmVjdCBmb3Igc29tZXRoaW5nDQo+PiB0 eXBlICdjcml0JyBhcyB3aGF0IGl0IHJlZmVycyB0byBpcyBsYWJlbHMuICBUaHVzDQo+PiAgICAg Y3JpdCA9PiBbK2xhYmVsXQ0KPj4gSXMgYSB0b3RhbGx5IHJlYXNvbmFibGUgQ0RETCBmb3IgdGhh dCBpdGVtLg0KPj4NCj4+IEkgd291bGQgcHJlZmVyIHRvIGtlZXAgdGhlc2UgdGhlIHRlcm0gZm9y IGtleSBhbmQgdGhlIHR5cGUgb2YgaW50L3RzdHINCj4+IHNlcGFyYXRlLg0KPj4NCj4+IEppbQ0K Pj4NCj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBDYXJzdGVu IEJvcm1hbm4gW21haWx0bzpjYWJvQHR6aS5vcmddDQo+Pj4gU2VudDogU2F0dXJkYXksIEp1bmUg MTMsIDIwMTUgOTo0NyBBTQ0KPj4+IFRvOiBNaWtlIEpvbmVzDQo+Pj4gQ2M6IEppbSBTY2hhYWQ7 IGNvc2VAaWV0Zi5vcmcNCj4+PiBTdWJqZWN0OiBSZTogW0Nvc2VdIEVkaXRvcmlhbDogTmV3IHRl cm0gImxhYmVsIg0KPj4+DQo+Pj4gTWlrZSBKb25lcyB3cm90ZToNCj4+PiA+IEkgd291bGQgYmUg b2sgd2l0aCB1c2luZyB0aGUgdGVybSBMYWJlbCBhbmQgTGFiZWw6VmFsdWUgcGFpcnMgaWYgd2UN Cj4+PiA+IGV4cGxpY2l0bHkgcHJvdmlkZSBhIGRlZmluaXRpb24gZm9yIG91ciB1c2Ugb2YgdGhl IHRlcm0gaW4gdGhlDQo+Pj4gPiBUZXJtaW5vbG9neSBzZWN0aW9uLiAgKEluZGVlZCwgdGhhdCdz IHdoYXQgSSB0aG91Z2h0IENhcnN0ZW4gd2FzDQo+Pj4gPiBwcm9wb3NpbmcuKQ0KPj4+DQo+Pj4g UmlnaHQuICBCZWxvdyBpcyB0aGUgcGVydGluZW50IHNlY3Rpb24gMSB0ZXh0IGluIG15IGN1cnJl bnQgZHJhZnQgUFINCj4+PiAod2hpY2ggaXMgbm90IHlldCBxdWl0ZSBmaW5pc2hlZCkuDQo+Pj4N Cj4+PiBHcsO8w59lLCBDYXJzdGVuDQo+Pj4NCj4+Pg0KPj4+ICMjIENCT1IgcmVsYXRlZCB0ZXJt aW5vbG9neSB7I2xhYmVsfQ0KPj4+DQo+Pj4gSW4gSlNPTiwgbWFwcyBhcmUgY2FsbGVkIG9iamVj dHMgYW5kIG9ubHkgaGF2ZSBvbmUga2luZCBvZiBtYXAga2V5OiBhDQo+Pj4gc3RyaW5nLg0KPj4+ IEluIENPU0UsIHdlIHVzZSBib3RoIHN0cmluZ3MgYW5kIGludGVnZXJzIChib3RoIHVuc2lnbmVk IGFuZCBuZWdhdGl2ZQ0KPj4+IGludGVnZXJzKSBhcyBtYXAga2V5cywgYXMgd2VsbCBhcyBkYXRh IGl0ZW1zIHRvIGlkZW50aWZ5IHNwZWNpZmljDQo+Pj4gY2hvaWNlcy4NCj4+PiBUaGUgKG5lZ2F0 aXZlIGFuZCB1bnNpZ25lZCkgaW50ZWdlcnMgYXJlIHVzZWQgZm9yIGNvbXBhY3RuZXNzIG9mDQo+ Pj4gZW5jb2RpbmcgYW5kIGVhc3kgY29tcGFyaXNvbi4NCj4+PiBTaW5jZSB0aGUgd29yZCAia2V5 IiBpcyBtYWlubHkgdXNlZCBpbiBpdHMgb3RoZXIgbWVhbmluZyBhcyBhDQo+Pj4gY3J5cHRvZ3Jh cGhpYyBrZXksIHdlIHVzZSB0aGUgdGVybSAibGFiZWwiIGZvciB0aGlzIHVzYWdlIG9mIGVpdGhl cg0KPj4+IGFuIGludGVnZXIgb3IgYSBzdHJpbmcgdG8gaWRlbnRpZnkgbWFwIGtleXMgYW5kIGNo b2ljZSBkYXRhIGl0ZW1zLg0KPj4+DQo+Pj4gfn5+fiBDRERMDQo+Pj4NCj4+PiBsYWJlbCA9IGlu dCAvIHRzdHINCj4+Pg0KPj4+IH5+fn4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4gQ29zZSBtYWlsaW5nIGxpc3QNCj4+IENvc2VAaWV0 Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29zZQ0KPj4N Cj4NCj4NCj4gLS0NCj4gICAgICAgIERlcmVrIEF0a2lucyAgICAgICAgICAgICAgICAgNjE3LTYy My0zNzQ1DQo+ICAgICAgICBkZXJla0BpaHRmcC5jb20gICAgICAgICAgICAgd3d3LmlodGZwLmNv bTxodHRwOi8vd3d3LmlodGZwLmNvbT4NCj4gICAgICAgIENvbXB1dGVyIGFuZCBJbnRlcm5ldCBT ZWN1cml0eSBDb25zdWx0YW50DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IENvc2UgbWFpbGluZyBsaXN0DQo+IENvc2VAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlDQo+DQoNCg0KLS0NCiAg ICAgICBEZXJlayBBdGtpbnMgICAgICAgICAgICAgICAgIDYxNy02MjMtMzc0NQ0KICAgICAgIGRl cmVrQGlodGZwLmNvbSAgICAgICAgICAgICB3d3cuaWh0ZnAuY29tPGh0dHA6Ly93d3cuaWh0ZnAu Y29tPg0KICAgICAgIENvbXB1dGVyIGFuZCBJbnRlcm5ldCBTZWN1cml0eSBDb25zdWx0YW50DQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDb3NlIG1h aWxpbmcgbGlzdA0KQ29zZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jb3NlDQo= --_000_BY2PR03MB442DFEF3520868C090BBAB2F5A50BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg LS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+SSB0aGluayBJJ20gbWlzc2luZyBzb21l dGhpbmcgaGVyZS4gSSB0aG91Z2h0IHRoYXQgd2hhdCB3ZSB3ZXJlIGRpc2N1c3NpbmcgaW4gdGhp cyB0aHJlYWQgd2FzIGEgcHJvcG9zYWwgdG8gdXNlIHRoZSB0ZXJtICZxdW90O2xhYmVsJnF1b3Q7 IGZvciBDQk9SIG9iamVjdCBrZXlzIGluIG91ciBzcGVjcywgc28gdGhhdCBvYmplY3RzIHdvdWxk IGJlIGRlc2NyaWJlZA0KIGFzIGNvbnRhaW5pbmcgbGFiZWw6dmFsdWUgcGFpcnMuPGJyPg0KPGJy Pg0KVGhpcyBpcyB0cnVlIG9mIGFsbCBsYWJlbHMgLSBub3QganVzdCBrdHkgbGFiZWxzLiZuYnNw OyBTbyBJIGRvbid0IGtub3cgd2h5IHlvdSB3b3VsZG4ndCB3YW50IHRvIGNhbGwgYSBzcGVjaWZp YyBsYWJlbCBhIGxhYmVsLCBhc3N1bWluZyB3ZSBhZG9wdCB0aGF0IHRlcm1pbm9sb2d5Ljxicj4N Cjxicj4NCi0tIE1pa2U8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8aHI+DQo8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsg Zm9udC13ZWlnaHQ6Ym9sZCI+RnJvbToNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+PGEgaHJlZj0ibWFpbHRvOmRlcmVr QGlodGZwLmNvbSI+RGVyZWsgQXRraW5zPC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6 Ym9sZCI+U2VudDoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5z LXNlcmlmOyBmb250LXNpemU6MTFwdCI+4oCONi/igI4xOC/igI4yMDE1IDE6MDIgUE08L3NwYW4+ PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1z aXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPlRvOg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0Ij48YSBocmVmPSJtYWls dG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj5NaWtlIEpvbmVzPC9hPjwvc3Bhbj48YnI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6 MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPjxhIGhyZWY9Im1haWx0bzpp ZXRmQGF1Z3VzdGNlbGxhcnMuY29tIj5KaW0gU2NoYWFkPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpj YWJvQHR6aS5vcmciPidDYXJzdGVuIEJvcm1hbm4nPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmNvc2VA aWV0Zi5vcmciPg0KY29zZUBpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0 OmJvbGQiPlN1YmplY3Q6DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmks c2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPlJlOiBbQ29zZV0gRWRpdG9yaWFsOiBOZXcgdGVy bSAmcXVvdDtsYWJlbCZxdW90Ozwvc3Bhbj48YnI+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGZv bnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+DQo8ZGl2IGNsYXNzPSJQ bGFpblRleHQiPldvdWxkIHlvdSByYXRoZXIgSSBjYWxsZWQgaXQgJnF1b3Q7aW50X29yX3N0cmlu Z192YWx1ZSZxdW90Oz88YnI+DQo8YnI+DQpUaGUga3R5IGxhYmVsIGNhbiBvbmx5IGhhdmUgYW4g aW50IG9yIHRzdHIgdmFsdWUsIGJ1dCB3ZSBkb24ndCB3YW50IHRvPGJyPg0KbGFiZWwgaXQgJnF1 b3Q7bGFiZWwmcXVvdDsuPGJyPg0KPGJyPg0KLWRlcmVrPGJyPg0KPGJyPg0KT24gVGh1LCBKdW5l IDE4LCAyMDE1IDM6NTMgcG0sIE1pa2UgSm9uZXMgd3JvdGU6PGJyPg0KJmd0OyBWYWx1ZSBjYW4g YmUgYW55IENCT1IgdHlwZSwgaW5jbHVkaW5nIGFycmF5cywgc3RydWN0dXJlcywgQm9vbGVhbnMs IGFuZDxicj4NCiZndDsgbnVsbCwgbm90IGp1c3QgaW50IG9yIHRzdHIuPGJyPg0KJmd0Ozxicj4N CiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IENvc2UgWzxh IGhyZWY9Im1haWx0bzpjb3NlLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpjb3NlLWJvdW5jZXNA aWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgRGVyZWsgQXRraW5zPGJyPg0KJmd0OyBTZW50OiBU aHVyc2RheSwgSnVuZSAxOCwgMjAxNSAxMjozOSBQTTxicj4NCiZndDsgVG86IEppbSBTY2hhYWQ8 YnI+DQomZ3Q7IENjOiAnQ2Fyc3RlbiBCb3JtYW5uJzsgY29zZUBpZXRmLm9yZzxicj4NCiZndDsg U3ViamVjdDogUmU6IFtDb3NlXSBFZGl0b3JpYWw6IE5ldyB0ZXJtICZxdW90O2xhYmVsJnF1b3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDsgSmltLDxicj4NCiZndDs8YnI+DQomZ3Q7IERvIHlvdSB0aGlu ayB5b3UnZCBwcmVmZXIgc29tZXRoaW5nIHRoYXQgbG9va3MgbW9yZSBsaWtlOjxicj4NCiZndDs8 YnI+DQomZ3Q7IGxhYmVsID0mZ3Q7IGludCAvIHRzdHI8YnI+DQomZ3Q7IHZhbHVlID0mZ3Q7IGlu dCAvIHRzdHI8YnI+DQomZ3Q7PGJyPg0KJmd0OyBDT1NFX0tleSA9IHs8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGt0eSA9Jmd0OyB2YWx1ZSw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ID8ga2V5X29wcyA9Jmd0OyBbJiM0Mzt2YWx1ZSBdLDxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgPyBhbGcgPSZndDsgdmFsdWUsPGJyPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA/IGtpZCA9Jmd0OyBic3RyLDxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgKiBrZXlzID0mZ3Q7IHZhbHVlczxicj4NCiZndDsmbmJzcDsgfTxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAoSSdtIG5vdCBzdXJlIGlmICZxdW90O3ZhbHVlJnF1b3Q7 IGlzIHRoZSBhcHByb3ByaWF0ZSBuYW1lIHRvIHVzZSwgYW5kIEknbSBub3Qgc3VyZTxicj4NCiZn dDsgaWYgJnF1b3Q7a2V5cyZxdW90OyBzaG91bGQgYmUgY2hhbmdlZCB0byAmcXVvdDtsYWJlbCZx dW90OyBpbiB0aGUgbGFzdCBsaW5lKTxicj4NCiZndDs8YnI+DQomZ3Q7IC1kZXJlazxicj4NCiZn dDs8YnI+DQomZ3Q7IE9uIFRodSwgSnVuZSAxOCwgMjAxNSAzOjE1IHBtLCBKaW0gU2NoYWFkIHdy b3RlOjxicj4NCiZndDsmZ3Q7IENhcnN0ZW4sPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBM b29raW5nIGF0IHlvdXIgcHVsbCByZXF1ZXN0LCBJIGZpbmQgdGhhdCB5b3UgYmFzaWNhbGx5IGRp ZCBkbyB0aGUgb25lPGJyPg0KJmd0OyZndDsgdGhpbmcgdGhhdCBJIHJlZmVycmVkIHRvIGluIG15 IG9yaWdpbmFsIG1lc3NhZ2UgYWJvdXQgcG90ZW50aWFsbHk8YnI+DQomZ3Q7Jmd0OyBoYXZpbmcg YSBuZXcgY29uZnVzaW9uIGRldmVsb3AuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBMb29r aW5nIGF0IHlvdXIgZGVmaW5pdGlvbiBmb3IgQ09TRV9LRVk8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7IExhYmVsID0mZ3Q7IGludCAvIHRzdHI8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 IENPU0VfS2V5ID0gezxicj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGt0eSA9 Jmd0OyBsYWJlbCw8YnI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA/IGtleV9v cHMgPSZndDsgWyYjNDM7bGFiZWwgXSw8YnI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA/IGFsZyA9Jmd0OyBsYWJlbCw8YnI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA/IGtpZCA9Jmd0OyBic3RyLDxicj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICoga2V5cyA9Jmd0OyB2YWx1ZXM8YnI+DQomZ3Q7Jmd0OyZuYnNwOyB9 PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBZb3UgYXJlIHN1Z2dlc3RpbmcgdXNpbmcgbGFi ZWwgYXMgdGhlIHZhbHVlIHBvcnRpb24gb2Yga3R5LCBrZXlfb3BzIGFuZDxicj4NCiZndDsmZ3Q7 IGFsZy4mbmJzcDsmbmJzcDsgSG93ZXZlciB0aGUgdmFsdWUgdGhhdCBpcyBwbGFjZWQgaW4gdGhl c2UgZmllbGRzIGlzIG5ldmVyIHVzZWQgYXM8YnI+DQomZ3Q7Jmd0OyBhPGJyPg0KJmd0OyZndDsg bWFwIGtleSBpbiBhbnkgbG9jYXRpb24uJm5ic3A7IFdlIGFyZSB0aGVyZWZvcmUgaGF2aW5nIHRo ZSB0ZXJtIGxhYmxlIChvcjxicj4NCiZndDsmZ3Q7IGF0IGxlYXN0IHRoZSB0eXBlKSB1c2VkIGJv dGggd2hlcmUgaXQgaXMgcmVmZXJyaW5nIHRvIHNvbWV0aGluZyB0aGF0PGJyPg0KJmd0OyZndDsg d291bGQgYmUgYSBrZXkgYXMgd2VsbCBhcyBzb21ldGhpbmcgdGhhdCBpcyBqdXN0IGEgdmFsdWUu PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJIGRvIGJlbGlldmUgdGhhdCB0aGUgdXNlIG9m IGxhYmVsIGlzIGNvbXBsZXRlbHkgY29ycmVjdCBmb3Igc29tZXRoaW5nPGJyPg0KJmd0OyZndDsg dHlwZSAnY3JpdCcgYXMgd2hhdCBpdCByZWZlcnMgdG8gaXMgbGFiZWxzLiZuYnNwOyBUaHVzPGJy Pg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY3JpdCA9Jmd0OyBbJiM0MztsYWJl bF08YnI+DQomZ3Q7Jmd0OyBJcyBhIHRvdGFsbHkgcmVhc29uYWJsZSBDRERMIGZvciB0aGF0IGl0 ZW0uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJIHdvdWxkIHByZWZlciB0byBrZWVwIHRo ZXNlIHRoZSB0ZXJtIGZvciBrZXkgYW5kIHRoZSB0eXBlIG9mIGludC90c3RyPGJyPg0KJmd0OyZn dDsgc2VwYXJhdGUuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBKaW08YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tPGJyPg0KJmd0OyZndDsmZ3Q7IEZyb206IENhcnN0ZW4gQm9ybWFubiBbPGEgaHJlZj0ibWFp bHRvOmNhYm9AdHppLm9yZyI+bWFpbHRvOmNhYm9AdHppLm9yZzwvYT5dPGJyPg0KJmd0OyZndDsm Z3Q7IFNlbnQ6IFNhdHVyZGF5LCBKdW5lIDEzLCAyMDE1IDk6NDcgQU08YnI+DQomZ3Q7Jmd0OyZn dDsgVG86IE1pa2UgSm9uZXM8YnI+DQomZ3Q7Jmd0OyZndDsgQ2M6IEppbSBTY2hhYWQ7IGNvc2VA aWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0OyZndDsgU3ViamVjdDogUmU6IFtDb3NlXSBFZGl0b3JpYWw6 IE5ldyB0ZXJtICZxdW90O2xhYmVsJnF1b3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7IE1pa2UgSm9uZXMgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsgSSB3b3VsZCBi ZSBvayB3aXRoIHVzaW5nIHRoZSB0ZXJtIExhYmVsIGFuZCBMYWJlbDpWYWx1ZSBwYWlycyBpZiB3 ZTxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7IGV4cGxpY2l0bHkgcHJvdmlkZSBhIGRlZmluaXRpb24g Zm9yIG91ciB1c2Ugb2YgdGhlIHRlcm0gaW4gdGhlPGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsgVGVy bWlub2xvZ3kgc2VjdGlvbi4mbmJzcDsgKEluZGVlZCwgdGhhdCdzIHdoYXQgSSB0aG91Z2h0IENh cnN0ZW4gd2FzPGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsgcHJvcG9zaW5nLik8YnI+DQomZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgUmlnaHQuJm5ic3A7IEJlbG93IGlzIHRoZSBwZXJ0aW5l bnQgc2VjdGlvbiAxIHRleHQgaW4gbXkgY3VycmVudCBkcmFmdCBQUjxicj4NCiZndDsmZ3Q7Jmd0 OyAod2hpY2ggaXMgbm90IHlldCBxdWl0ZSBmaW5pc2hlZCkuPGJyPg0KJmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7IEdyw7zDn2UsIENhcnN0ZW48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgIyMgQ0JPUiByZWxhdGVkIHRlcm1pbm9sb2d5 IHsjbGFiZWx9PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEluIEpTT04sIG1h cHMgYXJlIGNhbGxlZCBvYmplY3RzIGFuZCBvbmx5IGhhdmUgb25lIGtpbmQgb2YgbWFwIGtleTog YTxicj4NCiZndDsmZ3Q7Jmd0OyBzdHJpbmcuPGJyPg0KJmd0OyZndDsmZ3Q7IEluIENPU0UsIHdl IHVzZSBib3RoIHN0cmluZ3MgYW5kIGludGVnZXJzIChib3RoIHVuc2lnbmVkIGFuZCBuZWdhdGl2 ZTxicj4NCiZndDsmZ3Q7Jmd0OyBpbnRlZ2VycykgYXMgbWFwIGtleXMsIGFzIHdlbGwgYXMgZGF0 YSBpdGVtcyB0byBpZGVudGlmeSBzcGVjaWZpYzxicj4NCiZndDsmZ3Q7Jmd0OyBjaG9pY2VzLjxi cj4NCiZndDsmZ3Q7Jmd0OyBUaGUgKG5lZ2F0aXZlIGFuZCB1bnNpZ25lZCkgaW50ZWdlcnMgYXJl IHVzZWQgZm9yIGNvbXBhY3RuZXNzIG9mPGJyPg0KJmd0OyZndDsmZ3Q7IGVuY29kaW5nIGFuZCBl YXN5IGNvbXBhcmlzb24uPGJyPg0KJmd0OyZndDsmZ3Q7IFNpbmNlIHRoZSB3b3JkICZxdW90O2tl eSZxdW90OyBpcyBtYWlubHkgdXNlZCBpbiBpdHMgb3RoZXIgbWVhbmluZyBhcyBhPGJyPg0KJmd0 OyZndDsmZ3Q7IGNyeXB0b2dyYXBoaWMga2V5LCB3ZSB1c2UgdGhlIHRlcm0gJnF1b3Q7bGFiZWwm cXVvdDsgZm9yIHRoaXMgdXNhZ2Ugb2YgZWl0aGVyPGJyPg0KJmd0OyZndDsmZ3Q7IGFuIGludGVn ZXIgb3IgYSBzdHJpbmcgdG8gaWRlbnRpZnkgbWFwIGtleXMgYW5kIGNob2ljZSBkYXRhIGl0ZW1z Ljxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyB+fn5+IENEREw8YnI+DQomZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgbGFiZWwgPSBpbnQgLyB0c3RyPGJyPg0KJmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IH5+fn48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0 OyZndDsgQ29zZSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyBDb3NlQGlldGYub3JnPGJyPg0K Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9j b3NlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2U8L2E+PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgLS08YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERlcmVrIEF0a2lucyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA2MTctNjIzLTM3NDU8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlcmVrQGlodGZwLmNvbSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vd3d3LmlodGZwLmNvbSI+d3d3LmlodGZwLmNv bTwvYT48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IENvbXB1dGVyIGFuZCBJbnRlcm5ldCBTZWN1cml0eSBDb25zdWx0YW50PGJyPg0KJmd0Ozxicj4N CiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7IENvc2UgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBDb3NlQGlldGYub3JnPGJyPg0KJmd0 OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2UiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29zZTwvYT48YnI+DQomZ3Q7PGJy Pg0KPGJyPg0KPGJyPg0KLS0gPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IERlcmVrIEF0a2lucyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA2 MTctNjIzLTM3NDU8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVy ZWtAaWh0ZnAuY29tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWh0ZnAuY29t Ij53d3cuaWh0ZnAuY29tPC9hPjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBDb21wdXRlciBhbmQgSW50ZXJuZXQgU2VjdXJpdHkgQ29uc3VsdGFudDxicj4NCjxicj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KQ29z ZSBtYWlsaW5nIGxpc3Q8YnI+DQpDb3NlQGlldGYub3JnPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2Nvc2U8L2E+PGJyPg0KPC9kaXY+DQo8L3NwYW4+PC9mb250Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_BY2PR03MB442DFEF3520868C090BBAB2F5A50BY2PR03MB442namprd_-- From nobody Thu Jun 18 13:16:50 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D11C1B2BC0 for ; Thu, 18 Jun 2015 13:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 4n0u71uJqDfk for ; Thu, 18 Jun 2015 13:16:47 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D7541A1A24 for ; Thu, 18 Jun 2015 13:16:47 -0700 (PDT) Received: from hebrews (unknown [50.109.240.20]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 386BF2CA57; Thu, 18 Jun 2015 13:16:46 -0700 (PDT) From: "Jim Schaad" To: "'Derek Atkins'" References: <557BDCA9.1090308@tzi.org>, <002b01d0a5e6$8ed94850$ac8bd8f0$@augustcellars.com> <557C5E6D.9020308@tzi.org> <026b01d0a9fb$1e3639a0$5aa2ace0$@augustcellars.com> <543905cf2e4cadbe8429f4d948b62f98.squirrel@mail2.ihtfp.org> In-Reply-To: <543905cf2e4cadbe8429f4d948b62f98.squirrel@mail2.ihtfp.org> Date: Thu, 18 Jun 2015 13:16:55 -0700 Message-ID: <027601d0aa03$b9b783e0$2d268ba0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQH8U6MrgwBGyu21t+BNKuZ0X0SMTAHd/k3cAfwJDG0CCfM9ngKfeZSwAnDlb2mdA7uroA== Archived-At: Cc: 'Carsten Bormann' , cose@ietf.org Subject: Re: [Cose] Editorial: New term "label" X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 20:16:49 -0000 Yes that is more what I would like to see, although the problem is that = value is a bit too restrictive. I would want to distinguish between = cases where the value is going to be either an int/tstr or it can be any = cbor type object. Value vs values is probably not a good distinguisher. torn =3D> int/tstring label=3D> torn (torn is a really bad name for this. I wish I could come up with = something good. Tint does not work nor does tori. Perhaps if I stop = trying to encode the type and use something like simple_value.) I would agree that the last line needs to be changed as well. That got = missed in the pull request. Jim > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: Thursday, June 18, 2015 12:39 PM > To: Jim Schaad > Cc: 'Carsten Bormann'; cose@ietf.org > Subject: Re: [Cose] Editorial: New term "label" >=20 > Jim, >=20 > Do you think you'd prefer something that looks more like: >=20 > label =3D> int / tstr > value =3D> int / tstr >=20 > COSE_Key =3D { > kty =3D> value, > ? key_ops =3D> [+value ], > ? alg =3D> value, > ? kid =3D> bstr, > * keys =3D> values > } >=20 >=20 > (I'm not sure if "value" is the appropriate name to use, and I'm not = sure if > "keys" should be changed to "label" in the last line) >=20 > -derek >=20 > On Thu, June 18, 2015 3:15 pm, Jim Schaad wrote: > > Carsten, > > > > Looking at your pull request, I find that you basically did do the = one > > thing that I referred to in my original message about potentially > > having a new confusion develop. > > > > Looking at your definition for COSE_KEY > > > > Label =3D> int / tstr > > > > COSE_Key =3D { > > kty =3D> label, > > ? key_ops =3D> [+label ], > > ? alg =3D> label, > > ? kid =3D> bstr, > > * keys =3D> values > > } > > > > You are suggesting using label as the value portion of kty, key_ops = and > > alg. However the value that is placed in these fields is never = used as a > > map key in any location. We are therefore having the term lable (or > > at least the type) used both where it is referring to something that > > would be a key as well as something that is just a value. > > > > I do believe that the use of label is completely correct for = something > > type 'crit' as what it refers to is labels. Thus > > crit =3D> [+label] > > Is a totally reasonable CDDL for that item. > > > > I would prefer to keep these the term for key and the type of = int/tstr > > separate. > > > > Jim > > > > > >> -----Original Message----- > >> From: Carsten Bormann [mailto:cabo@tzi.org] > >> Sent: Saturday, June 13, 2015 9:47 AM > >> To: Mike Jones > >> Cc: Jim Schaad; cose@ietf.org > >> Subject: Re: [Cose] Editorial: New term "label" > >> > >> Mike Jones wrote: > >> > I would be ok with using the term Label and Label:Value pairs if = we > >> > explicitly provide a definition for our use of the term in the > >> > Terminology section. (Indeed, that's what I thought Carsten was > >> > proposing.) > >> > >> Right. Below is the pertinent section 1 text in my current draft = PR > >> (which is not yet quite finished). > >> > >> Gr=C3=BC=C3=9Fe, Carsten > >> > >> > >> ## CBOR related terminology {#label} > >> > >> In JSON, maps are called objects and only have one kind of map key: = a > >> string. > >> In COSE, we use both strings and integers (both unsigned and = negative > >> integers) as map keys, as well as data items to identify specific > >> choices. > >> The (negative and unsigned) integers are used for compactness of > >> encoding and easy comparison. > >> Since the word "key" is mainly used in its other meaning as a > >> cryptographic key, we use the term "label" for this usage of either > >> an integer or a string to identify map keys and choice data items. > >> > >> ~~~~ CDDL > >> > >> label =3D int / tstr > >> > >> ~~~~ > > > > _______________________________________________ > > Cose mailing list > > Cose@ietf.org > > https://www.ietf.org/mailman/listinfo/cose > > >=20 >=20 > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant From nobody Thu Jun 18 13:27:17 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B5A1B2D5D for ; Thu, 18 Jun 2015 13:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 CfA2f78oL1Xi for ; Thu, 18 Jun 2015 13:27:14 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FE0A1B2D2F for ; Thu, 18 Jun 2015 13:27:14 -0700 (PDT) Received: from hebrews (unknown [50.109.240.20]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id C2E872CA55; Thu, 18 Jun 2015 13:27:12 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , "'Derek Atkins'" References: <557BDCA9.1090308@tzi.org>, <002b01d0a5e6$8ed94850$ac8bd8f0$@augustcellars.com> <557C5E6D.9020308@tzi.org> <026b01d0a9fb$1e3639a0$5aa2ace0$@augustcellars.com> <543905cf2e4cadbe8429f4d948b62f98.squirrel@mail2.ihtfp.org> , <3301a7f05d5bec8ce19217e063f494d2.squirrel@mail2.ihtfp.org> In-Reply-To: Date: Thu, 18 Jun 2015 13:27:22 -0700 Message-ID: <000001d0aa05$2f3d4f90$8db7eeb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D0A9CA.82E1ABE0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQH8U6MrgwBGyu21t+BNKuZ0X0SMTAHd/k3cAfwJDG0CCfM9ngKfeZSwAnDlb2kBygIHYwKKDxgGAYd1Dmmc1OMf4A== Content-Language: en-us Archived-At: Cc: 'Carsten Bormann' , cose@ietf.org Subject: Re: [Cose] Editorial: New term "label" X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 20:27:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D0A9CA.82E1ABE0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable If you look at the CDDL rule =20 Cose_key: { kty=3D>label } =20 you end up with=20 kty is the key in a map. We want to refer to this as the label of the = field in the map. So =E2=80=98kty=E2=80=99 is a label. The type of = the label in the map is restricted to being an integer (negative or = non-negative) or a string. label is the value associated with the key =E2=80=98kty=E2=80=99 in the = map. We also want to restrict the types allowed to being either an = integer or a string. =20 If we use the term =E2=80=98label=E2=80=99 to represent both the map key = and the type of the map value, there is a potential for getting confused = here. I want to make these distinguishable by allowing for one term for = the map key and one term for the type object. =20 Jim =20 =20 From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 Sent: Thursday, June 18, 2015 1:16 PM To: Derek Atkins Cc: Jim Schaad; 'Carsten Bormann'; cose@ietf.org Subject: RE: [Cose] Editorial: New term "label" =20 I think I'm missing something here. I thought that what we were = discussing in this thread was a proposal to use the term "label" for = CBOR object keys in our specs, so that objects would be described as = containing label:value pairs. This is true of all labels - not just kty labels. So I don't know why = you wouldn't want to call a specific label a label, assuming we adopt = that terminology. -- Mike _____ =20 From: Derek Atkins =20 Sent: =E2=80=8E6/=E2=80=8E18/=E2=80=8E2015 1:02 PM To: Mike Jones =20 Cc: Jim Schaad ; 'Carsten Bormann' = ; cose@ietf.org =20 Subject: Re: [Cose] Editorial: New term "label" Would you rather I called it "int_or_string_value"? The kty label can only have an int or tstr value, but we don't want to label it "label". -derek On Thu, June 18, 2015 3:53 pm, Mike Jones wrote: > Value can be any CBOR type, including arrays, structures, Booleans, = and > null, not just int or tstr. > > -----Original Message----- > From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Derek Atkins > Sent: Thursday, June 18, 2015 12:39 PM > To: Jim Schaad > Cc: 'Carsten Bormann'; cose@ietf.org =20 > Subject: Re: [Cose] Editorial: New term "label" > > Jim, > > Do you think you'd prefer something that looks more like: > > label =3D> int / tstr > value =3D> int / tstr > > COSE_Key =3D { > kty =3D> value, > ? key_ops =3D> [+value ], > ? alg =3D> value, > ? kid =3D> bstr, > * keys =3D> values > } > > > (I'm not sure if "value" is the appropriate name to use, and I'm not = sure > if "keys" should be changed to "label" in the last line) > > -derek > > On Thu, June 18, 2015 3:15 pm, Jim Schaad wrote: >> Carsten, >> >> Looking at your pull request, I find that you basically did do the = one >> thing that I referred to in my original message about potentially >> having a new confusion develop. >> >> Looking at your definition for COSE_KEY >> >> Label =3D> int / tstr >> >> COSE_Key =3D { >> kty =3D> label, >> ? key_ops =3D> [+label ], >> ? alg =3D> label, >> ? kid =3D> bstr, >> * keys =3D> values >> } >> >> You are suggesting using label as the value portion of kty, key_ops = and >> alg. However the value that is placed in these fields is never used = as >> a >> map key in any location. We are therefore having the term lable (or >> at least the type) used both where it is referring to something that >> would be a key as well as something that is just a value. >> >> I do believe that the use of label is completely correct for = something >> type 'crit' as what it refers to is labels. Thus >> crit =3D> [+label] >> Is a totally reasonable CDDL for that item. >> >> I would prefer to keep these the term for key and the type of = int/tstr >> separate. >> >> Jim >> >> >>> -----Original Message----- >>> From: Carsten Bormann [mailto:cabo@tzi.org] >>> Sent: Saturday, June 13, 2015 9:47 AM >>> To: Mike Jones >>> Cc: Jim Schaad; cose@ietf.org =20 >>> Subject: Re: [Cose] Editorial: New term "label" >>> >>> Mike Jones wrote: >>> > I would be ok with using the term Label and Label:Value pairs if = we >>> > explicitly provide a definition for our use of the term in the >>> > Terminology section. (Indeed, that's what I thought Carsten was >>> > proposing.) >>> >>> Right. Below is the pertinent section 1 text in my current draft PR >>> (which is not yet quite finished). >>> >>> Gr=C3=BC=C3=9Fe, Carsten >>> >>> >>> ## CBOR related terminology {#label} >>> >>> In JSON, maps are called objects and only have one kind of map key: = a >>> string. >>> In COSE, we use both strings and integers (both unsigned and = negative >>> integers) as map keys, as well as data items to identify specific >>> choices. >>> The (negative and unsigned) integers are used for compactness of >>> encoding and easy comparison. >>> Since the word "key" is mainly used in its other meaning as a >>> cryptographic key, we use the term "label" for this usage of either >>> an integer or a string to identify map keys and choice data items. >>> >>> ~~~~ CDDL >>> >>> label =3D int / tstr >>> >>> ~~~~ >> >> _______________________________________________ >> Cose mailing list >> Cose@ietf.org =20 >> https://www.ietf.org/mailman/listinfo/cose >> > > > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com = www.ihtfp.com =20 > Computer and Internet Security Consultant > > _______________________________________________ > Cose mailing list > Cose@ietf.org =20 > https://www.ietf.org/mailman/listinfo/cose > --=20 Derek Atkins 617-623-3745 derek@ihtfp.com = www.ihtfp.com =20 Computer and Internet Security Consultant _______________________________________________ Cose mailing list Cose@ietf.org =20 https://www.ietf.org/mailman/listinfo/cose ------=_NextPart_000_0001_01D0A9CA.82E1ABE0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

If you look at the CDDL rule

 

Cose_key: {

kty=3D>label

}

 

you end up with

kty is the key in a map.=C2=A0 We want to refer to this as the label of = the field in the map.=C2=A0 So =E2=80=98kty=E2=80=99 is a = label.=C2=A0=C2=A0 The type of the label in the map is restricted to = being an integer (negative or non-negative) or a = string.

label is the value associated with the key =E2=80=98kty=E2=80=99 in the = map. We also want to restrict the types allowed to being either an = integer or a string.

 

If we use the term =E2=80=98label=E2=80=99 to represent both the map = key and the type of the map value, there is a potential for getting = confused here.=C2=A0 I want to make these distinguishable by allowing = for one term for the map key and one term for the type = object.

 

Jim

 

 

From:<= /b> = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: = Thursday, June 18, 2015 1:16 PM
To: Derek Atkins
Cc: = Jim Schaad; 'Carsten Bormann'; cose@ietf.org
Subject: RE: = [Cose] Editorial: New term = "label"

 

I think I'm = missing something here. I thought that what we were discussing in this = thread was a proposal to use the term "label" for CBOR object = keys in our specs, so that objects would be described as containing = label:value pairs.

This is true of all labels - not just kty = labels.  So I don't know why you wouldn't want to call a specific = label a label, assuming we adopt that terminology.

-- = Mike

From: = Derek Atkins
Sent: = =E2=80=8E6/=E2= =80=8E18/=E2=80=8E2015 1:02 PM
To: = Mike = Jones
Cc: = Jim Schaad; 'Carsten Bormann'; cose@ietf.org
Subject: = Re: [Cose] = Editorial: New term = "label"

Would you rather I = called it "int_or_string_value"?

The kty label can only = have an int or tstr value, but we don't want to
label it = "label".

-derek

On Thu, June 18, 2015 3:53 pm, = Mike Jones wrote:
> Value can be any CBOR type, including arrays, = structures, Booleans, and
> null, not just int or = tstr.
>
> -----Original Message-----
> From: Cose [mailto:cose-bounces@ietf.org] = On Behalf Of Derek Atkins
> Sent: Thursday, June 18, 2015 12:39 = PM
> To: Jim Schaad
> Cc: 'Carsten Bormann'; cose@ietf.org
> Subject: Re: = [Cose] Editorial: New term "label"
>
> = Jim,
>
> Do you think you'd prefer something that looks more = like:
>
> label =3D> int / tstr
> value =3D> int = / tstr
>
> COSE_Key =3D {
>     = kty =3D> value,
>     ? key_ops =3D> = [+value ],
>     ? alg =3D> = value,
>     ? kid =3D> = bstr,
>     * keys =3D> = values
>  }
>
>
> (I'm not sure if = "value" is the appropriate name to use, and I'm not = sure
> if "keys" should be changed to "label" = in the last line)
>
> -derek
>
> On Thu, June = 18, 2015 3:15 pm, Jim Schaad wrote:
>> = Carsten,
>>
>> Looking at your pull request, I find = that you basically did do the one
>> thing that I referred to = in my original message about potentially
>> having a new = confusion develop.
>>
>> Looking at your definition = for COSE_KEY
>>
>> Label =3D> int / = tstr
>>
>> COSE_Key =3D = {
>>     kty =3D> = label,
>>     ? key_ops =3D> [+label = ],
>>     ? alg =3D> = label,
>>      ? kid =3D> = bstr,
>>      * keys =3D> = values
>>  }
>>
>> You are suggesting = using label as the value portion of kty, key_ops and
>> = alg.   However the value that is placed in these fields is = never used as
>> a
>> map key in any location.  = We are therefore having the term lable (or
>> at least the = type) used both where it is referring to something that
>> = would be a key as well as something that is just a = value.
>>
>> I do believe that the use of label is = completely correct for something
>> type 'crit' as what it = refers to is labels.  Thus
>>     crit = =3D> [+label]
>> Is a totally reasonable CDDL for that = item.
>>
>> I would prefer to keep these the term for = key and the type of int/tstr
>> = separate.
>>
>> = Jim
>>
>>
>>> -----Original = Message-----
>>> From: Carsten Bormann [mailto:cabo@tzi.org]
>>> = Sent: Saturday, June 13, 2015 9:47 AM
>>> To: Mike = Jones
>>> Cc: Jim Schaad; cose@ietf.org
>>> Subject: = Re: [Cose] Editorial: New term = "label"
>>>
>>> Mike Jones = wrote:
>>> > I would be ok with using the term Label and = Label:Value pairs if we
>>> > explicitly provide a = definition for our use of the term in the
>>> > = Terminology section.  (Indeed, that's what I thought Carsten = was
>>> > proposing.)
>>>
>>> = Right.  Below is the pertinent section 1 text in my current draft = PR
>>> (which is not yet quite = finished).
>>>
>>> Gr=C3=BC=C3=9Fe, = Carsten
>>>
>>>
>>> ## CBOR related = terminology {#label}
>>>
>>> In JSON, maps are = called objects and only have one kind of map key: a
>>> = string.
>>> In COSE, we use both strings and integers (both = unsigned and negative
>>> integers) as map keys, as well as = data items to identify specific
>>> choices.
>>> = The (negative and unsigned) integers are used for compactness = of
>>> encoding and easy comparison.
>>> Since = the word "key" is mainly used in its other meaning as = a
>>> cryptographic key, we use the term "label" = for this usage of either
>>> an integer or a string to = identify map keys and choice data items.
>>>
>>> = ~~~~ CDDL
>>>
>>> label =3D int / = tstr
>>>
>>> ~~~~
>>
>> = _______________________________________________
>> Cose mailing = list
>> Cose@ietf.org
>> https://www.ietf.org/= mailman/listinfo/cose
>>
>
>
> = --
>        Derek = Atkins           &= nbsp;     = 617-623-3745
>        derek@ihtfp.com   &nbs= p;         www.ihtfp.com
>   =      Computer and Internet Security = Consultant
>
> = _______________________________________________
> Cose mailing = list
> Cose@ietf.org
> = https://www.ietf.org/= mailman/listinfo/cose
>


-- =
       Derek = Atkins           &= nbsp;     = 617-623-3745
       derek@ihtfp.com   &nbs= p;         www.ihtfp.com
   &nbs= p;   Computer and Internet Security = Consultant

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

<= /html> ------=_NextPart_000_0001_01D0A9CA.82E1ABE0-- From nobody Thu Jun 18 13:36:08 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0AAE1B3501 for ; Thu, 18 Jun 2015 13:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 D0mX9R9xV3fL for ; Thu, 18 Jun 2015 13:36:04 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0112.outbound.protection.outlook.com [207.46.100.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021DE1B3500 for ; Thu, 18 Jun 2015 13:36:03 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.195.6; Thu, 18 Jun 2015 20:36:01 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0195.005; Thu, 18 Jun 2015 20:36:01 +0000 From: Mike Jones To: Jim Schaad , 'Derek Atkins' Thread-Topic: [Cose] Editorial: New term "label" Thread-Index: AQHQpatZ9WeHKwZD4EyojavvdG42XJ2qgcUAgAAb3cqAAAgOgIAIBTMAgAAGrQCAAAOrEIAAAsqAgAAD4y+AAAMdAIAAAmuH Date: Thu, 18 Jun 2015 20:36:01 +0000 Message-ID: References: <557BDCA9.1090308@tzi.org>, <002b01d0a5e6$8ed94850$ac8bd8f0$@augustcellars.com> <557C5E6D.9020308@tzi.org> <026b01d0a9fb$1e3639a0$5aa2ace0$@augustcellars.com> <543905cf2e4cadbe8429f4d948b62f98.squirrel@mail2.ihtfp.org> , <3301a7f05d5bec8ce19217e063f494d2.squirrel@mail2.ihtfp.org> , <000001d0aa05$2f3d4f90$8db7eeb0$@augustcellars.com> In-Reply-To: <000001d0aa05$2f3d4f90$8db7eeb0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [209.206.162.148] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:RUS8Zd4dSlbilbshSomvap8E7pJ9bHbMzMHEFKY+ulAl5np0ZSvh4DVymGC2+G/jAgSMO9i7n9PvCP9FJlm3dI0zVk7iyp3X2TkCUHL8SdU5aAeXJmirMyIPXbK4hVAhpRLezGZXlQOuTYzKqJEA2A==; 24:3rbeQbOspjmL+kVQpI5fWUYYb/3LEyqWAEVPxZKfW8jbvsMBH8SeKxmDpTTr4Pr+94dG56uPLwkBu9z0YH2NSrbKD9Rqzt0E4TgSrUhbArA=; 20:1YjqfeDuGu0Oxojb8sIkq9QK/0TQjrEg3Pdrt6AOMYAim9LUyWXM9W6BmYpDoKck3ONzDUCuBy6+vh6GjbcIXw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 0611A21987 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(377454003)(51704005)(199003)(189002)(24454002)(13464003)(106116001)(86362001)(77096005)(46102003)(54356999)(16236675004)(2950100001)(2900100001)(86612001)(102836002)(15975445007)(76176999)(50986999)(87936001)(2656002)(99286002)(93886004)(16601075003)(76576001)(19580395003)(74316001)(19617315012)(19625215002)(33656002)(15974865002)(561944003)(66066001)(5002640100001)(5003600100002)(5001960100002)(40100003)(5001920100001)(122556002)(19580405001)(189998001)(92566002)(62966003)(77156002)(5001770100001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442E014DDCB084A395CD014F5A50BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2015 20:36:01.4320 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Cc: 'Carsten Bormann' , "cose@ietf.org" Subject: Re: [Cose] Editorial: New term "label" X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 20:36:06 -0000 --_000_BY2PR03MB442E014DDCB084A395CD014F5A50BY2PR03MB442namprd_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Ok. Then introduce a string-or-int production and define label as that. May= be that's what you were thinking already. :-) ________________________________ From: Jim Schaad Sent: =FD6/=FD18/=FD2015 1:27 PM To: Mike Jones; 'Derek Atkins' Cc: 'Carsten Bormann'; cose@ietf.org Subject: RE: [Cose] Editorial: New term "label" If you look at the CDDL rule Cose_key: { kty=3D>label } you end up with kty is the key in a map. We want to refer to this as the label of the fiel= d in the map. So =91kty=92 is a label. The type of the label in the map = is restricted to being an integer (negative or non-negative) or a string. label is the value associated with the key =91kty=92 in the map. We also wa= nt to restrict the types allowed to being either an integer or a string. If we use the term =91label=92 to represent both the map key and the type o= f the map value, there is a potential for getting confused here. I want to= make these distinguishable by allowing for one term for the map key and on= e term for the type object. Jim From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Thursday, June 18, 2015 1:16 PM To: Derek Atkins Cc: Jim Schaad; 'Carsten Bormann'; cose@ietf.org Subject: RE: [Cose] Editorial: New term "label" I think I'm missing something here. I thought that what we were discussing = in this thread was a proposal to use the term "label" for CBOR object keys = in our specs, so that objects would be described as containing label:value = pairs. This is true of all labels - not just kty labels. So I don't know why you = wouldn't want to call a specific label a label, assuming we adopt that term= inology. -- Mike ________________________________ From: Derek Atkins Sent: =FD6/=FD18/=FD2015 1:02 PM To: Mike Jones Cc: Jim Schaad; 'Carsten Bormann'; cose@ietf.org Subject: Re: [Cose] Editorial: New term "label" Would you rather I called it "int_or_string_value"? The kty label can only have an int or tstr value, but we don't want to label it "label". -derek On Thu, June 18, 2015 3:53 pm, Mike Jones wrote: > Value can be any CBOR type, including arrays, structures, Booleans, and > null, not just int or tstr. > > -----Original Message----- > From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Derek Atkins > Sent: Thursday, June 18, 2015 12:39 PM > To: Jim Schaad > Cc: 'Carsten Bormann'; cose@ietf.org > Subject: Re: [Cose] Editorial: New term "label" > > Jim, > > Do you think you'd prefer something that looks more like: > > label =3D> int / tstr > value =3D> int / tstr > > COSE_Key =3D { > kty =3D> value, > ? key_ops =3D> [+value ], > ? alg =3D> value, > ? kid =3D> bstr, > * keys =3D> values > } > > > (I'm not sure if "value" is the appropriate name to use, and I'm not sure > if "keys" should be changed to "label" in the last line) > > -derek > > On Thu, June 18, 2015 3:15 pm, Jim Schaad wrote: >> Carsten, >> >> Looking at your pull request, I find that you basically did do the one >> thing that I referred to in my original message about potentially >> having a new confusion develop. >> >> Looking at your definition for COSE_KEY >> >> Label =3D> int / tstr >> >> COSE_Key =3D { >> kty =3D> label, >> ? key_ops =3D> [+label ], >> ? alg =3D> label, >> ? kid =3D> bstr, >> * keys =3D> values >> } >> >> You are suggesting using label as the value portion of kty, key_ops and >> alg. However the value that is placed in these fields is never used as >> a >> map key in any location. We are therefore having the term lable (or >> at least the type) used both where it is referring to something that >> would be a key as well as something that is just a value. >> >> I do believe that the use of label is completely correct for something >> type 'crit' as what it refers to is labels. Thus >> crit =3D> [+label] >> Is a totally reasonable CDDL for that item. >> >> I would prefer to keep these the term for key and the type of int/tstr >> separate. >> >> Jim >> >> >>> -----Original Message----- >>> From: Carsten Bormann [mailto:cabo@tzi.org] >>> Sent: Saturday, June 13, 2015 9:47 AM >>> To: Mike Jones >>> Cc: Jim Schaad; cose@ietf.org >>> Subject: Re: [Cose] Editorial: New term "label" >>> >>> Mike Jones wrote: >>> > I would be ok with using the term Label and Label:Value pairs if we >>> > explicitly provide a definition for our use of the term in the >>> > Terminology section. (Indeed, that's what I thought Carsten was >>> > proposing.) >>> >>> Right. Below is the pertinent section 1 text in my current draft PR >>> (which is not yet quite finished). >>> >>> Gr=FC?e, Carsten >>> >>> >>> ## CBOR related terminology {#label} >>> >>> In JSON, maps are called objects and only have one kind of map key: a >>> string. >>> In COSE, we use both strings and integers (both unsigned and negative >>> integers) as map keys, as well as data items to identify specific >>> choices. >>> The (negative and unsigned) integers are used for compactness of >>> encoding and easy comparison. >>> Since the word "key" is mainly used in its other meaning as a >>> cryptographic key, we use the term "label" for this usage of either >>> an integer or a string to identify map keys and choice data items. >>> >>> ~~~~ CDDL >>> >>> label =3D int / tstr >>> >>> ~~~~ >> >> _______________________________________________ >> Cose mailing list >> Cose@ietf.org >> https://www.ietf.org/mailman/listinfo/cose >> > > > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com<= http://www.ihtfp.com> > Computer and Internet Security Consultant > > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant _______________________________________________ Cose mailing list Cose@ietf.org https://www.ietf.org/mailman/listinfo/cose --_000_BY2PR03MB442E014DDCB084A395CD014F5A50BY2PR03MB442namprd_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Ok. Then intr= oduce a string-or-int production and define label as that. Maybe that's wha= t you were thinking already. :-)
From: Jim Schaad
Sent: =FD6/= =FD18/=FD2015 1:27 PM
To: Mike Jones; 'Derek Atkins'
Cc: 'Carsten Bormann'; cose@ietf.org
Subject: RE: [= Cose] Editorial: New term "label"

If you look at the CDDL rule=

 

Cose_key: {

kty=3D>label

}

 

you end up with

kty is the key in a map.  We w= ant to refer to this as the label of the field in the map.  So =91kty= =92 is a label.   The type of the label in the map is restricted to being an integer (negative or non-negative) or a string.

label is the value associated with = the key =91kty=92 in the map. We also want to restrict the types allowed to= being either an integer or a string.

 

If we use the term =91label=92 to r= epresent both the map key and the type of the map value, there is a potenti= al for getting confused here.  I want to make these distinguishable by allowing for one term for the map key and one term for = the type object.

 

Jim

 

 

From: Mike Jones [mailto:Michael.J= ones@microsoft.com]
Sent: Thursday, June 18, 2015 1:16 PM
To: Derek Atkins
Cc: Jim Schaad; 'Carsten Bormann'; cose@ietf.org
Subject: RE: [Cose] Editorial: New term "label"

 

I think I'm missing something here. I thought that= what we were discussing in this thread was a proposal to use the term &quo= t;label" for CBOR object keys in our specs, so that objects would be described as containing label:value pairs.

This is true of all labels - not just kty labels.  So I don't know why= you wouldn't want to call a specific label a label, assuming we adopt that= terminology.

-- Mike

From: Derek Atkins
Sent: =FD6/=FD18/=FD2015 1:02 PM
To: Mike J= ones
Cc: Jim Schaad<= /a>; 'Carsten Bormann'; cose@ietf.org
Subject: Re: [Cose] Editorial: New term "label"

Would you rather I = called it "int_or_string_value"?

The kty label can only have an int or tstr value, but we don't want to
label it "label".

-derek

On Thu, June 18, 2015 3:53 pm, Mike Jones wrote:
> Value can be any CBOR type, including arrays, structures, Booleans, an= d
> null, not just int or tstr.
>
> -----Original Message-----
> From: Cose [mailto:cose-bounc= es@ietf.org] On Behalf Of Derek Atkins
> Sent: Thursday, June 18, 2015 12:39 PM
> To: Jim Schaad
> Cc: 'Carsten Bormann'; cose@ietf.org<= /a>
> Subject: Re: [Cose] Editorial: New term "label"
>
> Jim,
>
> Do you think you'd prefer something that looks more like:
>
> label =3D> int / tstr
> value =3D> int / tstr
>
> COSE_Key =3D {
>     kty =3D> value,
>     ? key_ops =3D> [+value ],
>     ? alg =3D> value,
>     ? kid =3D> bstr,
>     * keys =3D> values
>  }
>
>
> (I'm not sure if "value" is the appropriate name to use, and= I'm not sure
> if "keys" should be changed to "label" in the last= line)
>
> -derek
>
> On Thu, June 18, 2015 3:15 pm, Jim Schaad wrote:
>> Carsten,
>>
>> Looking at your pull request, I find that you basically did do the= one
>> thing that I referred to in my original message about potentially<= br> >> having a new confusion develop.
>>
>> Looking at your definition for COSE_KEY
>>
>> Label =3D> int / tstr
>>
>> COSE_Key =3D {
>>     kty =3D> label,
>>     ? key_ops =3D> [+label ],
>>     ? alg =3D> label,
>>      ? kid =3D> bstr,
>>      * keys =3D> values
>>  }
>>
>> You are suggesting using label as the value portion of kty, key_op= s and
>> alg.   However the value that is placed in these fields = is never used as
>> a
>> map key in any location.  We are therefore having the term la= ble (or
>> at least the type) used both where it is referring to something th= at
>> would be a key as well as something that is just a value.
>>
>> I do believe that the use of label is completely correct for somet= hing
>> type 'crit' as what it refers to is labels.  Thus
>>     crit =3D> [+label]
>> Is a totally reasonable CDDL for that item.
>>
>> I would prefer to keep these the term for key and the type of int/= tstr
>> separate.
>>
>> Jim
>>
>>
>>> -----Original Message-----
>>> From: Carsten Bormann [mailto:= cabo@tzi.org]
>>> Sent: Saturday, June 13, 2015 9:47 AM
>>> To: Mike Jones
>>> Cc: Jim Schaad; cose@ietf.org=
>>> Subject: Re: [Cose] Editorial: New term "label"
>>>
>>> Mike Jones wrote:
>>> > I would be ok with using the term Label and Label:Value p= airs if we
>>> > explicitly provide a definition for our use of the term i= n the
>>> > Terminology section.  (Indeed, that's what I thought= Carsten was
>>> > proposing.)
>>>
>>> Right.  Below is the pertinent section 1 text in my curre= nt draft PR
>>> (which is not yet quite finished).
>>>
>>> Gr=FCße, Carsten
>>>
>>>
>>> ## CBOR related terminology {#label}
>>>
>>> In JSON, maps are called objects and only have one kind of map= key: a
>>> string.
>>> In COSE, we use both strings and integers (both unsigned and n= egative
>>> integers) as map keys, as well as data items to identify speci= fic
>>> choices.
>>> The (negative and unsigned) integers are used for compactness = of
>>> encoding and easy comparison.
>>> Since the word "key" is mainly used in its other mea= ning as a
>>> cryptographic key, we use the term "label" for this = usage of either
>>> an integer or a string to identify map keys and choice data it= ems.
>>>
>>> ~~~~ CDDL
>>>
>>> label =3D int / tstr
>>>
>>> ~~~~
>>
>> _______________________________________________
>> Cose mailing list
>> Cose@ietf.org
>> https://www= .ietf.org/mailman/listinfo/cose
>>
>
>
> --
>        Derek Atkins  &nbs= p;            &= nbsp; 617-623-3745
>        derek@ihtfp.com        &= nbsp;    www.ihtfp.com
>        Computer and Internet Securi= ty Consultant
>
> _______________________________________________
> Cose mailing list
> Cose@ietf.org
> https://www.iet= f.org/mailman/listinfo/cose
>


--
       Derek Atkins    &n= bsp;            617-= 623-3745
       der= ek@ihtfp.com          = ;   www.ihtfp.com
       Computer and Internet Security Consult= ant

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

--_000_BY2PR03MB442E014DDCB084A395CD014F5A50BY2PR03MB442namprd_-- From nobody Thu Jun 18 14:38:52 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255AE1B3595 for ; Thu, 18 Jun 2015 14:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=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 PSeSvOWNQzyO for ; Thu, 18 Jun 2015 14:38:49 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 438FD1B3594 for ; Thu, 18 Jun 2015 14:38:49 -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 t5ILcfLC015299; Thu, 18 Jun 2015 23:38:41 +0200 (CEST) Received: from alma.local (p5DC7EA60.dip0.t-ipconnect.de [93.199.234.96]) (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 3mCGq514vQz9B0V; Thu, 18 Jun 2015 23:38:41 +0200 (CEST) Message-ID: <55833A5F.3060908@tzi.org> Date: Thu, 18 Jun 2015 23:38:39 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: Mike Jones References: <557BDCA9.1090308@tzi.org>, <002b01d0a5e6$8ed94850$ac8bd8f0$@augustcellars.com> <557C5E6D.9020308@tzi.org> <026b01d0a9fb$1e3639a0$5aa2ace0$@augustcellars.com> <543905cf2e4cadbe8429f4d948b62f98.squirrel@mail2.ihtfp.org> , <3301a7f05d5bec8ce19217e063f494d2.squirrel@mail2.ihtfp.org> , <000001d0aa05$2f3d4f90$8db7eeb0$@augustcellars.com> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Jim Schaad , 'Derek Atkins' , "cose@ietf.org" Subject: Re: [Cose] Editorial: New term "label" X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 21:38:51 -0000 Mike Jones wrote: > Ok. Then introduce a string-or-int production and define label as that. > Maybe that's what you were thinking already. :-) Indeed. My text proposal is at https://github.com/cabo/cose-spec/blob/editorial/draft-schaad-cose.md#cbor-related-terminology-label (and below). (Unfortunately, github's flavor of markdown is somewhat limited; this should still be mostly readable except for the tables.) Grüße, Carsten From nobody Thu Jun 18 14:42:53 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148A21A1B23 for ; Thu, 18 Jun 2015 14:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=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 1IVW3FCnmuUD for ; Thu, 18 Jun 2015 14:42:51 -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 15EA21A1B2D for ; Thu, 18 Jun 2015 14:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t5ILgjRF025369; Thu, 18 Jun 2015 23:42:45 +0200 (CEST) Received: from alma.local (p5DC7EA60.dip0.t-ipconnect.de [93.199.234.96]) (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 3mCGvn1GNkz9B0X; Thu, 18 Jun 2015 23:42:44 +0200 (CEST) Message-ID: <55833B53.2020407@tzi.org> Date: Thu, 18 Jun 2015 23:42:43 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: Mike Jones References: <557BDCA9.1090308@tzi.org>, <002b01d0a5e6$8ed94850$ac8bd8f0$@augustcellars.com> <557C5E6D.9020308@tzi.org> <026b01d0a9fb$1e3639a0$5aa2ace0$@augustcellars.com> <543905cf2e4cadbe8429f4d948b62f98.squirrel@mail2.ihtfp.org> , <3301a7f05d5bec8ce19217e063f494d2.squirrel@mail2.ihtfp.org> , <000001d0aa05$2f3d4f90$8db7eeb0$@augustcellars.com> <55833A5F.3060908@tzi.org> In-Reply-To: <55833A5F.3060908@tzi.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Jim Schaad , 'Derek Atkins' , "cose@ietf.org" Subject: Re: [Cose] Editorial: New term "label" X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 21:42:52 -0000 Oh, and we can always use another term for a label that is not in a map key position. "designator" is the most bureaucratic term I could find (not yet used in the below text proposal). Grüße, Carsten Carsten Bormann wrote: > Mike Jones wrote: >> Ok. Then introduce a string-or-int production and define label as that. >> Maybe that's what you were thinking already. :-) > > Indeed. > > My text proposal is at > > https://github.com/cabo/cose-spec/blob/editorial/draft-schaad-cose.md#cbor-related-terminology-label > > (and below). (Unfortunately, github's flavor of markdown is somewhat > limited; this should still be mostly readable except for the tables.) > > Grüße, Carsten > > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > From nobody Fri Jun 19 12:21:16 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55E11AD0BA for ; Fri, 19 Jun 2015 12:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 aY_hMq6-wNqY for ; Fri, 19 Jun 2015 12:21:13 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D3CE1AD0B4 for ; Fri, 19 Jun 2015 12:21:13 -0700 (PDT) Received: from hebrews (unknown [50.109.240.20]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 7262F2C9F5 for ; Fri, 19 Jun 2015 12:21:12 -0700 (PDT) From: "Jim Schaad" To: References: <20150619181004.23248.63878.idtracker@ietfa.amsl.com> In-Reply-To: <20150619181004.23248.63878.idtracker@ietfa.amsl.com> Date: Fri, 19 Jun 2015 12:21:19 -0700 Message-ID: <008b01d0aac5$212cae80$63860b80$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIKwry+2aGpGyS3Pc1hYbGwi42iQp1AAG0Q Content-Language: en-us Archived-At: Subject: [Cose] FW: New Version Notification for draft-schaad-cose-msg-01.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 19:21:15 -0000 I have posted an updated version of the document. This includes: Merging in the label/key separation change - except for where it was = using label for values Add Media type registrations for 4 new media types Add an example to the "Three levels of Recipient Information" appendix Start making changes so that the CDDL spec can become informational = rather than normative Fill in some of the COSE Headers section with protected/unprotected = items Make IV a protected/unprotected item rather than a message item. Remove aad as a message item. Various editorial and real changes. Jim > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, June 19, 2015 11:10 AM > To: Jim Schaad; Jim Schaad > Subject: New Version Notification for draft-schaad-cose-msg-01.txt >=20 >=20 > A new version of I-D, draft-schaad-cose-msg-01.txt has been = successfully > submitted by Jim Schaad and posted to the IETF repository. >=20 > Name: draft-schaad-cose-msg > Revision: 01 > Title: CBOR Encoded Message Syntax > Document date: 2015-06-19 > Group: Individual Submission > Pages: 48 > URL: = https://www.ietf.org/internet-drafts/draft-schaad-cose-msg- > 01.txt > Status: = https://datatracker.ietf.org/doc/draft-schaad-cose-msg/ > Htmlized: https://tools.ietf.org/html/draft-schaad-cose-msg-01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-schaad-cose-msg-01 >=20 > Abstract: > Concise Binary Object Representation (CBOR) is data format designed > for small code size and small message size. There is a need for = the > ability to have the basic security services defined for this data > format. This document specifies how to do signatures, message > authentication codes and encryption using this data format. >=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 Fri Jun 19 12:33:18 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BCA1ACCE7 for ; Fri, 19 Jun 2015 12:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_ORG=0.611] autolearn=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 Q-Sc8NcsEZWW for ; Fri, 19 Jun 2015 12:33:15 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 721421AD367 for ; Fri, 19 Jun 2015 12:33:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id B99CBE2035; Fri, 19 Jun 2015 15:33:12 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 24466-06; Fri, 19 Jun 2015 15:33:10 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id D355FE2036; Fri, 19 Jun 2015 15:33:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1434742389; bh=dAsxGCOSc3IYlZmjEixPNi6pydmKOC0zXNDu1kcjUsI=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=Df9rfhLrzPYN2CMPtxG9fx0ZTq+6RRCIG49IvcLSeqD9MdqmVgBwIxThnNhu+NXHC 0Qe2KXetaxhl5mvfzyPzJZs8gnttkqaeb6qUyJAJbAG8rlyB97X47myVTwHujdtA37 1tBBB6tUypea8nvQMaMqP++lQNkUhQHQzMZ4tEnw= Received: from 192.168.248.204 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Fri, 19 Jun 2015 15:33:09 -0400 Message-ID: <265e1f399e6a0f9fbf7c7eb772b3240a.squirrel@mail2.ihtfp.org> In-Reply-To: <008b01d0aac5$212cae80$63860b80$@augustcellars.com> References: <20150619181004.23248.63878.idtracker@ietfa.amsl.com> <008b01d0aac5$212cae80$63860b80$@augustcellars.com> Date: Fri, 19 Jun 2015 15:33:09 -0400 From: "Derek Atkins" To: "Jim Schaad" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] FW: New Version Notification for draft-schaad-cose-msg-01.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 19:33:17 -0000 Hi, One thing I failed to find in the document (granted, I haven't read this update yet) is: exactly how does one encode e.g. an ECDSA signature for inclusion into the COSE_Sign object? One of my developers is trying to implement this and the issue arose: how do you encode r and s in a COSE Signature? I had to reverse engineer the example, but I *think* it's just the byte-strings of r and s concatenated together (and not e.g. the ASN1 output). but I couldn't find anywhere in the COSE spec where this is actually specified? Did I miss a reference? -derek On Fri, June 19, 2015 3:21 pm, Jim Schaad wrote: > I have posted an updated version of the document. This includes: > > Merging in the label/key separation change - except for where it was using > label for values > Add Media type registrations for 4 new media types > Add an example to the "Three levels of Recipient Information" appendix > Start making changes so that the CDDL spec can become informational rather > than normative > Fill in some of the COSE Headers section with protected/unprotected items > Make IV a protected/unprotected item rather than a message item. > Remove aad as a message item. > Various editorial and real changes. > > Jim > > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Friday, June 19, 2015 11:10 AM >> To: Jim Schaad; Jim Schaad >> Subject: New Version Notification for draft-schaad-cose-msg-01.txt >> >> >> A new version of I-D, draft-schaad-cose-msg-01.txt has been successfully >> submitted by Jim Schaad and posted to the IETF repository. >> >> Name: draft-schaad-cose-msg >> Revision: 01 >> Title: CBOR Encoded Message Syntax >> Document date: 2015-06-19 >> Group: Individual Submission >> Pages: 48 >> URL: >> https://www.ietf.org/internet-drafts/draft-schaad-cose-msg- >> 01.txt >> Status: https://datatracker.ietf.org/doc/draft-schaad-cose-msg/ >> Htmlized: https://tools.ietf.org/html/draft-schaad-cose-msg-01 >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-schaad-cose-msg-01 >> >> Abstract: >> Concise Binary Object Representation (CBOR) is data format designed >> for small code size and small message size. There is a need for the >> ability to have the basic security services defined for this data >> format. This document specifies how to do signatures, message >> authentication codes and encryption using this data format. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> The IETF Secretariat > > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Jun 19 12:57:02 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6064F1AD49D for ; Fri, 19 Jun 2015 12:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 NNcxFQ78C8a2 for ; Fri, 19 Jun 2015 12:56:58 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9361E1AD47E for ; Fri, 19 Jun 2015 12:56:58 -0700 (PDT) Received: from hebrews (unknown [50.109.240.20]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id CF8492CA08; Fri, 19 Jun 2015 12:56:57 -0700 (PDT) From: "Jim Schaad" To: "'Derek Atkins'" References: <20150619181004.23248.63878.idtracker@ietfa.amsl.com> <008b01d0aac5$212cae80$63860b80$@augustcellars.com> <265e1f399e6a0f9fbf7c7eb772b3240a.squirrel@mail2.ihtfp.org> In-Reply-To: <265e1f399e6a0f9fbf7c7eb772b3240a.squirrel@mail2.ihtfp.org> Date: Fri, 19 Jun 2015 12:57:07 -0700 Message-ID: <000001d0aaca$1ffb4120$5ff1c360$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIKwry+2aGpGyS3Pc1hYbGwi42iQgMudcYmAmckIxGdE2G0wA== Content-Language: en-us Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] FW: New Version Notification for draft-schaad-cose-msg-01.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 19:57:00 -0000 Technically speaking that is not in this draft but in the algorithms = draft. However, yes I have encoded this as r || s where both r and s are the = length of the hash. (i.e. don't remove leading zeros) Jim > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: Friday, June 19, 2015 12:33 PM > To: Jim Schaad > Cc: cose@ietf.org > Subject: Re: [Cose] FW: New Version Notification for = draft-schaad-cose-msg- > 01.txt >=20 > Hi, >=20 > One thing I failed to find in the document (granted, I haven't read = this > update yet) is: exactly how does one encode e.g. an ECDSA signature = for > inclusion into the COSE_Sign object? One of my developers is trying = to > implement this and the issue arose: how do you encode r and s in a = COSE > Signature? >=20 > I had to reverse engineer the example, but I *think* it's just the = byte-strings > of r and s concatenated together (and not e.g. the ASN1 output). but = I > couldn't find anywhere in the COSE spec where this is actually = specified? >=20 > Did I miss a reference? >=20 > -derek >=20 > On Fri, June 19, 2015 3:21 pm, Jim Schaad wrote: > > I have posted an updated version of the document. This includes: > > > > Merging in the label/key separation change - except for where it was > > using label for values Add Media type registrations for 4 new media > > types Add an example to the "Three levels of Recipient Information" > > appendix Start making changes so that the CDDL spec can become > > informational rather than normative Fill in some of the COSE Headers > > section with protected/unprotected items Make IV a > > protected/unprotected item rather than a message item. > > Remove aad as a message item. > > Various editorial and real changes. > > > > Jim > > > > > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Friday, June 19, 2015 11:10 AM > >> To: Jim Schaad; Jim Schaad > >> Subject: New Version Notification for draft-schaad-cose-msg-01.txt > >> > >> > >> A new version of I-D, draft-schaad-cose-msg-01.txt has been > >> successfully submitted by Jim Schaad and posted to the IETF = repository. > >> > >> Name: draft-schaad-cose-msg > >> Revision: 01 > >> Title: CBOR Encoded Message Syntax > >> Document date: 2015-06-19 > >> Group: Individual Submission > >> Pages: 48 > >> URL: > >> https://www.ietf.org/internet-drafts/draft-schaad-cose-msg- > >> 01.txt > >> Status: = https://datatracker.ietf.org/doc/draft-schaad-cose-msg/ > >> Htmlized: = https://tools.ietf.org/html/draft-schaad-cose-msg-01 > >> Diff: > >> https://www.ietf.org/rfcdiff?url2=3Ddraft-schaad-cose-msg-01 > >> > >> Abstract: > >> Concise Binary Object Representation (CBOR) is data format = designed > >> for small code size and small message size. There is a need for = the > >> ability to have the basic security services defined for this = data > >> format. This document specifies how to do signatures, message > >> authentication codes and encryption using this data format. > >> > >> > >> > >> > >> Please note that it may take a couple of minutes from the time of > >> submission until the htmlized version and diff are available at > >> tools.ietf.org. > >> > >> The IETF Secretariat > > > > _______________________________________________ > > Cose mailing list > > Cose@ietf.org > > https://www.ietf.org/mailman/listinfo/cose > > >=20 >=20 > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant From nobody Fri Jun 19 13:28:09 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5461B2A17 for ; Fri, 19 Jun 2015 13:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 IjCH9PAkz5Me for ; Fri, 19 Jun 2015 13:28:06 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42211B2A16 for ; Fri, 19 Jun 2015 13:28:05 -0700 (PDT) Received: from hebrews (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 3EE6A38F70; Fri, 19 Jun 2015 13:28:05 -0700 (PDT) From: "Jim Schaad" To: "'Derek Atkins'" References: <20150619181004.23248.63878.idtracker@ietfa.amsl.com> <008b01d0aac5$212cae80$63860b80$@augustcellars.com> <265e1f399e6a0f9fbf7c7eb772b3240a.squirrel@mail2.ihtfp.org> In-Reply-To: <265e1f399e6a0f9fbf7c7eb772b3240a.squirrel@mail2.ihtfp.org> Date: Fri, 19 Jun 2015 13:28:15 -0700 Message-ID: <000101d0aace$79010800$6b031800$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIKwry+2aGpGyS3Pc1hYbGwi42iQgMudcYmAmckIxGdE2psEA== Content-Language: en-us Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] FW: New Version Notification for draft-schaad-cose-msg-01.txt X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 20:28:08 -0000 I should have mentioned, If I was writing the algorithm draft I would = mostly be stealing the basics from the JOSE algorithm draft and cleaning = things up. I don't like the KDF functions, but much of the rest is = going to be similar. Jim > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: Friday, June 19, 2015 12:33 PM > To: Jim Schaad > Cc: cose@ietf.org > Subject: Re: [Cose] FW: New Version Notification for = draft-schaad-cose-msg- > 01.txt >=20 > Hi, >=20 > One thing I failed to find in the document (granted, I haven't read = this > update yet) is: exactly how does one encode e.g. an ECDSA signature = for > inclusion into the COSE_Sign object? One of my developers is trying = to > implement this and the issue arose: how do you encode r and s in a = COSE > Signature? >=20 > I had to reverse engineer the example, but I *think* it's just the = byte-strings > of r and s concatenated together (and not e.g. the ASN1 output). but = I > couldn't find anywhere in the COSE spec where this is actually = specified? >=20 > Did I miss a reference? >=20 > -derek >=20 > On Fri, June 19, 2015 3:21 pm, Jim Schaad wrote: > > I have posted an updated version of the document. This includes: > > > > Merging in the label/key separation change - except for where it was > > using label for values Add Media type registrations for 4 new media > > types Add an example to the "Three levels of Recipient Information" > > appendix Start making changes so that the CDDL spec can become > > informational rather than normative Fill in some of the COSE Headers > > section with protected/unprotected items Make IV a > > protected/unprotected item rather than a message item. > > Remove aad as a message item. > > Various editorial and real changes. > > > > Jim > > > > > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Friday, June 19, 2015 11:10 AM > >> To: Jim Schaad; Jim Schaad > >> Subject: New Version Notification for draft-schaad-cose-msg-01.txt > >> > >> > >> A new version of I-D, draft-schaad-cose-msg-01.txt has been > >> successfully submitted by Jim Schaad and posted to the IETF = repository. > >> > >> Name: draft-schaad-cose-msg > >> Revision: 01 > >> Title: CBOR Encoded Message Syntax > >> Document date: 2015-06-19 > >> Group: Individual Submission > >> Pages: 48 > >> URL: > >> https://www.ietf.org/internet-drafts/draft-schaad-cose-msg- > >> 01.txt > >> Status: = https://datatracker.ietf.org/doc/draft-schaad-cose-msg/ > >> Htmlized: = https://tools.ietf.org/html/draft-schaad-cose-msg-01 > >> Diff: > >> https://www.ietf.org/rfcdiff?url2=3Ddraft-schaad-cose-msg-01 > >> > >> Abstract: > >> Concise Binary Object Representation (CBOR) is data format = designed > >> for small code size and small message size. There is a need for = the > >> ability to have the basic security services defined for this = data > >> format. This document specifies how to do signatures, message > >> authentication codes and encryption using this data format. > >> > >> > >> > >> > >> Please note that it may take a couple of minutes from the time of > >> submission until the htmlized version and diff are available at > >> tools.ietf.org. > >> > >> The IETF Secretariat > > > > _______________________________________________ > > Cose mailing list > > Cose@ietf.org > > https://www.ietf.org/mailman/listinfo/cose > > >=20 >=20 > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant From nobody Fri Jun 19 17:12:56 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEBFD1A9045; Fri, 19 Jun 2015 17:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=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 wjdzfq8U-Pec; Fri, 19 Jun 2015 17:12:49 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BAA61A9076; Fri, 19 Jun 2015 17:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t5K0Cjhh001196; Sat, 20 Jun 2015 02:12:45 +0200 (CEST) Received: from alma.local (p5DC7EA60.dip0.t-ipconnect.de [93.199.234.96]) (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 3mCyBP02qJz99ST; Sat, 20 Jun 2015 02:12:44 +0200 (CEST) Message-ID: <5584AFFA.7030507@tzi.org> Date: Sat, 20 Jun 2015 02:12:42 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: dtls-iot@ietf.org, core@ietf.org, ace@ietf.org, cose@ietf.org, t2trg@irtf.org X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Cose] Constrained Node/Network Cluster @ IETF93, early draft version X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 00:12:52 -0000 A first draft version of the IETF93 agenda is out. ** THIS IS GOING TO CHANGE ** for conflict resolution, so please don't make travel arrangements based on it. Here is my usual eclectic condensed agenda built from that. (Bye, bye, appsawg. lwig over roll is interesting; at least we do have a roll meeting at all.) Note that the t2trg meeting on Monday is a "summary" meeting for those who haven't been able to join during the weekend (conflicts with Hackathon, ICNRG, etc.) All times are CEST (UTC+0200) (the browser timezone function appears to have vanished from https://datatracker.ietf.org/meeting/agenda-utc, but maybe we can reinstate that for those who want to listen from remote). Sorry for the duplicate posting, the IETF mail system does not allow sending to all 9 mailing lists at the same time. Grüße, Carsten SATURDAY, July 18, 2015 1000-1800 Session I (TBD) IRTF*** t2trg Proposed Thing-to-thing Research Group 0900-2100 IETF Hackathon - Chez Louis SUNDAY, July 19, 2015 0900-1600 Session II (TBD) IRTF*** t2trg Proposed Thing-to-thing Research Group 1000-1800 IETF Hackathon - Chez Louis 1600-1700 Newcomers' Meet and Greet (open to Newcomers and WG chairs only) - Garden Terrace 1700-1900 Welcome Reception - Grand Hilton Ballroom MONDAY, July 20, 2015 0900-1130 Morning Session I Grand Hilton BR ART appsawg Applications Area Working Group WG Karlin I/II OPS anima Autonomic Networking Integrated Model and Approach WG Berlin/Brussels SEC *** cose CBOR Object Signing and Encryption WG Congress H II TSV rmcat RTP Media Congestion Avoidance Techniques WG 1300-1500 Afternoon Session I Congress H III INT 6man IPv6 Maintenance WG Grand Hilton BR RTG detnet Deterministic Networking BOF 1520-1720 Afternoon Session II Berlin/Brussels IRTF*** t2trg Proposed Thing-to-Thing Research Group Congress H III TSV tcpinc TCP Increased Security WG 1740-1840 Afternoon Session III Congress H II INT *** 6lo IPv6 over Networks of Resource-constrained Nodes WG Karlin I/II SEC httpauth Hypertext Transfer Protocol Authentication WG 1850-1950 Afternoon Session IV Congress H I INT intarea Internet Area Working Group WG TUESDAY, July 21, 2015 1300-1500 Afternoon Session I Karlin I/II ART httpbis Hypertext Transfer Protocol WG Congress H II INT *** 6lo IPv6 over Networks of Resource-constrained Nodes WG Grand Hilton BR OPS v6ops IPv6 Operations WG 1520-1720 Afternoon Session II Karlin I/II ART *** core Constrained RESTful Environments WG Congress H II RTG rtgarea Routing Area Open Meeting Congress H III SEC tls Transport Layer Security WG 1740-1840 Afternoon Session III Congress H III ART uta Using TLS in Applications WG Berlin/Brussels INT *** lwig Light-Weight Implementation Guidance WG Congress H I RTG *** roll Routing Over Low power and Lossy networks WG WEDNESDAY, July 22, 2015 0900-1130 Morning Session I Athens/Barcel. INT dnssd Extensions for Scalable DNS Service Discovery WG Karlin I/II SEC *** ace Authentication and Authorization for Constrained Environments WG Grand Hilton BR SEC tls Transport Layer Security WG 1300-1530 Afternoon Session I Grand Hilton BR INT homenet Home Networking WG Berlin/Brussels RTG bier Bit Indexed Explicit Replication WG 1740-1940 Afternoon Session III Athens/Barcel. SEC oauth Web Authorization Protocol WG Congress H III TSV tsvwg Transport Area Working Group WG THURSDAY, July 23, 2015 1300-1500 Afternoon Session I Congress H II SEC saag Security Area Open Meeting Karlin I/II TSV taps Transport Services WG 1520-1720 Afternoon Session II Athens/Barcel. INT *** 6tisch IPv6 over the TSCH mode of IEEE 802.15.4e WG Congress H III SEC acme Automated Certificate Management Environment WG Grand Hilton BR TSV tsvwg Transport Area Working Group WG 1740-1910 Afternoon Session III Athens/Barcel. ART webpush Web-Based Push Notifications WG Karlin I/II OPS anima Autonomic Networking Integrated Model and Approach WG Grand Hilton BR TSV tsvarea Transport Area Open Meeting FRIDAY, July 24, 2015 0900-1130 Morning Session I Grand Hilton BR OPS v6ops IPv6 Operations WG Karlin I/II SEC openpgp Open Specification for Pretty Good Privacy WG 1150-1320 Afternoon Session I Karlin I/II ART *** core Constrained RESTful Environments WG Congress H I SEC tokbind Token Binding WG From nobody Fri Jun 19 18:39:18 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB391B2C5B for ; Fri, 19 Jun 2015 18:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 o3OirGF2r8ZT for ; Fri, 19 Jun 2015 18:39:16 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01BFC1B2C4D for ; Fri, 19 Jun 2015 18:39:14 -0700 (PDT) X-AuditID: 1209190d-f796f6d000005314-07-5584c441492e Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 75.F8.21268.144C4855; Fri, 19 Jun 2015 21:39:13 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t5K1dCCO012758 for ; Fri, 19 Jun 2015 21:39:13 -0400 Received: from [192.168.128.56] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t5K1dB6q008337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 19 Jun 2015 21:39:12 -0400 Message-ID: <5584C435.3020106@mit.edu> Date: Fri, 19 Jun 2015 21:39:01 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: cose@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGIsWRmVeSWpSXmKPExsUixG6nout4pCXUYOVaDYtpW6eyOjB6LFny kymAMYrLJiU1J7MstUjfLoErY//ddraCfawV+6YcY29g3MjSxcjJISFgIvFhQjM7hC0mceHe erYuRi4OIYHFTBITfjxhhXCOMkpM3zqdBcJ5zyRxdPIFNpAWXgE1idPnINpZBFQlVm/bwApi swHZ09e0MIHYogJRElMfr2OBqBeUODnzCZDNwSECZN/tNAcJCwuoSHw6eh+shFnATGLe5ofM ELa8xPa3c5gnMPLNQtI9C0nZLCRlCxiZVzHKpuRW6eYmZuYUpybrFicn5uWlFuka6eVmluil ppRuYgQFGack7w7GdweVDjEKcDAq8fAuWNwSKsSaWFZcmXuIUZKDSUmU9/QhoBBfUn5KZUZi cUZ8UWlOavEhRgkOZiUR3rmzgXK8KYmVValF+TApaQ4WJXHeTT/4QoQE0hNLUrNTUwtSi2Cy MhwcShK8j0CGChalpqdWpGXmlCCkmTg4QYbzAA0/CFLDW1yQmFucmQ6RP8Woy7Hgx+21TEIs efl5qVLivEqHgYoEQIoySvPg5sCSwytGcaC3hHldQap4gIkFbtIroCVMQEsmlDeBLClJREhJ NTBqnKyztzrJ3/g/IaEig+NV896NZid0/zOIyodv2bjw+rPp6xNr5l7t/PLu4/2ulYdbVLeL GV8qcbZavfDAkuPLP6alnuScaJ3MYcC5Pvr/rnKueQvs4v6c/x4XaLdzztZfP4X1jqoel09Z UjG9dMK57XFz3H71mcveOFb00YIr/u/6tw9/uG36qsRSnJFoqMVcVJwIAAO1uELpAgAA Archived-At: Subject: [Cose] IETF93 Preliminary Schedule X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 01:39:17 -0000 The preliminary schedule for IETF93 has been posted, and at the moment we're on for the first slot: Monday morning at 9-11:30. I think that so far we're avoiding our main conflicts, and we've got a big 2.5h slot to get this group off the ground properly. We'll be looking for input on the agenda soon, so if you want to pontificate on something hopefully-COSE-related, let the chairs know: cose-chairs@tools.ietf.org (Side note, "cose-chairs" is probably the best email address in all of IETF.) And finally, a reminder that we're looking to gather consensus and/or alternatives to draft-schaad-cose-msg as a WG input document by this coming Wednesday, June 24. -- Justin From nobody Fri Jun 19 20:47:37 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06A91B2CE4 for ; Fri, 19 Jun 2015 20:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 NIqG-0r8ZJlG for ; Fri, 19 Jun 2015 20:47:35 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C2FF1ACE72 for ; Fri, 19 Jun 2015 20:47:34 -0700 (PDT) Received: from hebrews (unknown [50.109.240.20]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id B9E9838F62; Fri, 19 Jun 2015 20:47:32 -0700 (PDT) From: "Jim Schaad" To: "'Justin Richer'" , References: <5584C435.3020106@mit.edu> In-Reply-To: <5584C435.3020106@mit.edu> Date: Fri, 19 Jun 2015 20:47:33 -0700 Message-ID: <002801d0ab0b$de3bdf00$9ab39d00$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJswfYikRPO7lPSbby02Dzhrvq0jJx8k6jQ Content-Language: en-us Archived-At: Subject: Re: [Cose] IETF93 Preliminary Schedule X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 03:47:36 -0000 Look at the schedule again. We only get half of that time. The other half goes to IPSECME. Jim > -----Original Message----- > From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Justin Richer > Sent: Friday, June 19, 2015 6:39 PM > To: cose@ietf.org > Subject: [Cose] IETF93 Preliminary Schedule > > The preliminary schedule for IETF93 has been posted, and at the moment > we're on for the first slot: Monday morning at 9-11:30. I think that so far > we're avoiding our main conflicts, and we've got a big 2.5h slot to get this > group off the ground properly. > > We'll be looking for input on the agenda soon, so if you want to pontificate > on something hopefully-COSE-related, let the chairs know: > cose-chairs@tools.ietf.org > > (Side note, "cose-chairs" is probably the best email address in all of > IETF.) > > And finally, a reminder that we're looking to gather consensus and/or > alternatives to draft-schaad-cose-msg as a WG input document by this > coming Wednesday, June 24. > > -- Justin > > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Sat Jun 20 05:25:17 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400101A1BEC for ; Sat, 20 Jun 2015 05:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 igcKM7va_rya for ; Sat, 20 Jun 2015 05:25:13 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3B31A1BF4 for ; Sat, 20 Jun 2015 05:25:12 -0700 (PDT) X-AuditID: 1209190d-f796f6d000005314-85-55855ba6ae92 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 5E.B4.21268.7AB55855; Sat, 20 Jun 2015 08:25:11 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t5KCPAOo009119; Sat, 20 Jun 2015 08:25:10 -0400 Received: from [192.168.128.56] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t5KCP839030666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 20 Jun 2015 08:25:09 -0400 Message-ID: <55855B9A.7030304@mit.edu> Date: Sat, 20 Jun 2015 08:24:58 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Jim Schaad , cose@ietf.org References: <5584C435.3020106@mit.edu> <002801d0ab0b$de3bdf00$9ab39d00$@augustcellars.com> In-Reply-To: <002801d0ab0b$de3bdf00$9ab39d00$@augustcellars.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixG6nrrs8ujXUoG0Th8W0rVNZLVZP/87m wOSxcc50No8lS34yBTBFcdmkpOZklqUW6dslcGX8f/advWAFd0Xr/v+MDYytnF2MnBwSAiYS X+6vZoewxSQu3FvPBmILCSxmkljTy9PFyAVkb2SU2HX5ECuEc5tJorPhFyNIFa+AmsT3fV/B bBYBVYl3+6azgNhsQPb0NS1MILaoQJTE1MfrWCDqBSVOznwCZosImEmsOdsEtk1YQF9i9qQX zBCboyS2HFwCNpNTwEHiWNsdsHpmAVuJO3N3M0PY8hLb385hnsAoMAvJ2FlIymYhKVvAyLyK UTYlt0o3NzEzpzg1Wbc4OTEvL7VI10gvN7NELzWldBMjKFA5JXl3ML47qHSIUYCDUYmHd8Hi llAh1sSy4srcQ4ySHExKorz/7gGF+JLyUyozEosz4otKc1KLDzFKcDArifD6abSGCvGmJFZW pRblw6SkOViUxHk3/eALERJITyxJzU5NLUgtgsnKcHAoSfB6RQE1ChalpqdWpGXmlCCkmTg4 QYbzAA1PAKnhLS5IzC3OTIfIn2JUlBLnFQZJCIAkMkrz4HphieQVozjQK8K8RSBVPMAkBNf9 CmgwE9DgCeVNIINLEhFSUg2M2leYjpdHzL5lPOPK5PivKgfnuzgwbT29MPEI//0nITHlX4qW 8xW6MS0pcl3f8yz+Sop5+sSOJQYnCgN7omd+cImatPD2lMV2Psdr10x+6L1ySpujOGOWNXMP w2OzxyqGltcfyazOzY3V3JV/qfXdgtRrSrkelyqN5/vlGWzutapyvi2yuVhNiaU4I9FQi7mo OBEA69YOOP8CAAA= Archived-At: Subject: Re: [Cose] IETF93 Preliminary Schedule X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 12:25:15 -0000 Good catch, Jim, I hadn't noticed that the room was shared between the two. And of course, everyone keep in mind that this schedule is subject to change. -- Justin On 6/19/2015 11:47 PM, Jim Schaad wrote: > Look at the schedule again. We only get half of that time. The other half > goes to IPSECME. > > Jim > > >> -----Original Message----- >> From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Justin Richer >> Sent: Friday, June 19, 2015 6:39 PM >> To: cose@ietf.org >> Subject: [Cose] IETF93 Preliminary Schedule >> >> The preliminary schedule for IETF93 has been posted, and at the moment >> we're on for the first slot: Monday morning at 9-11:30. I think that so > far >> we're avoiding our main conflicts, and we've got a big 2.5h slot to get > this >> group off the ground properly. >> >> We'll be looking for input on the agenda soon, so if you want to > pontificate >> on something hopefully-COSE-related, let the chairs know: >> cose-chairs@tools.ietf.org >> >> (Side note, "cose-chairs" is probably the best email address in all of >> IETF.) >> >> And finally, a reminder that we're looking to gather consensus and/or >> alternatives to draft-schaad-cose-msg as a WG input document by this >> coming Wednesday, June 24. >> >> -- Justin >> >> _______________________________________________ >> Cose mailing list >> Cose@ietf.org >> https://www.ietf.org/mailman/listinfo/cose From nobody Sat Jun 20 08:05:57 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1B31A038B for ; Sat, 20 Jun 2015 08:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 et5_WkwnfAUX for ; Sat, 20 Jun 2015 08:05:53 -0700 (PDT) Received: from out4133-146.mail.aliyun.com (out4133-146.mail.aliyun.com [42.120.133.146]) by ietfa.amsl.com (Postfix) with ESMTP id 824761A0334 for ; Sat, 20 Jun 2015 08:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1434812751; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=PuEpvgm4UWCo658cE4qhpdC71VKoppD/3sH0rnwdjFg=; b=pDJBLc8PaRumFFGXPM0IjQmmji2TbZgwe3wL4BBxg3JbWkq/j7AcTHb+BVe6OKh0oUFZzR4CV2FVZYZ7bcd2mcege3EfOL8Q1BSW0d7kOkda7SgIKGHf7Dk6tYXr7Py4spOv19xp4EOaVS2OSBqqifsJSiHKrGBsTlyGnLdy2pQ= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R101e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g03025; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=3; RT=3; SR=0; Received: from 10.22.45.45(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.207) by smtp.aliyun-inc.com(127.0.0.1); Sat, 20 Jun 2015 23:05:46 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Sat, 20 Jun 2015 23:05:38 +0800 From: "Kepeng Li" To: Mike Jones , Jim Schaad , "cose@ietf.org" Message-ID: Thread-Topic: [Cose] Algorithm draft References: <004701d0a406$01b088d0$05119a70$@augustcellars.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Cose] Algorithm draft X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 15:05:55 -0000 Hi Mike and Jim, Thanks for volunteering. It will be good if we can have the -00 version before our submission deadline, that is, 6th July, 2015. Kind Regards Kepeng =D4=DA 12/6/15 1:10 am=A3=AC "Mike Jones" =D0=B4=C8=EB: >I'd be glad to do this. I look forward to helping us get these specs out >quickly in ways that meet the use cases people have. > > Cheers, > -- Mike > >-----Original Message----- >From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad >Sent: Wednesday, June 10, 2015 10:18 PM >To: 'Kepeng Li'; cose@ietf.org >Subject: Re: [Cose] Algorithm draft > > > >> -----Original Message----- >> From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Kepeng Li >> Sent: Wednesday, June 10, 2015 6:03 PM >> To: Mike Jones; Jim Schaad; cose@ietf.org >> Subject: [Cose] Algorithm draft >> >> Currently, we have received feedback from Mike to have a separate >algorithm >> draft. >> >> Any other feedback? >> >> Also, we need to find somebody to write the algorithm draft, if we >> decide >to >> have a separate one. >> >> Any volunteers? > >While I am willing to do this, I would prefer if it were somebody else if >the document is separate. I object going to WG meetings where you only >have one person who is doing the presentations. On the other hand, >please remember the aggressive schedule that we are trying to keep for >this group. > >Jim > >> >> Thanks, >> >> Kind Regards >> Kepeng >> >> =D4=DA 6/6/15 11:04 am=A3=AC "Mike Jones" =D0=B4=C8=EB: >> >> >For what it's worth, I'd advocate having a separate algorithm >> >document for the same reasons that JOSE did. For one, it enables >> >that document to be revised in the future without having to then >> >revise the underlying signature/MAC/encryption/key representations. >> > >> >Also, based on my experience as a JOSE editor, I think the result was >> >cleaner because we separated the algorithm descriptions from the >> >descriptions of how to perform cryptographic operations. It was good >> >discipline to have to describe the steps to create and use the data >> >structures without falling back on particulars of specific algorithms. >> > >> >Also, the single-purpose nature of an algorithms doc can make it >> >easier to read and use a reference. You're not having to sort out >> >what are data descriptions and what are algorithm descriptions. It's >> >just >algorithms. >> > >> > Cheers, >> > -- Mike >> > >> >P.S. I agree with Jim's procedural point that the charter allows the >> >working group to produce deliverables either in combined or separated >> >documents. >> > >> >-----Original Message----- >> >From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad >> >Sent: Friday, June 05, 2015 7:31 PM >> >To: 'Kepeng Li'; cose@ietf.org >> >Subject: Re: [Cose] FW: New Version Notification for >> >draft-schaad-cose-02.txt >> > >> > >> >> -----Original Message----- >> >> From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Kepeng Li >> >> Sent: Friday, June 05, 2015 6:49 PM >> >> To: Jim Schaad; cose@ietf.org >> >> Subject: Re: [Cose] FW: New Version Notification for >> >>draft-schaad-cose-02. >> >txt >> >> >> >> Hi Jim, >> >> >> >> Thanks for the draft. >> >> >> >> >I am willing to add the algorithms piece to this document if that >> >> >is the desire of the group, or it can be done as an independent >> >> >document (my initial preference).edx >> >> >> >> >> >> According to our milestones, the algorithm piece is a separate item. >> > >> >That just says that we need a document to cover that milestone. It >> >can be a single document or a combined document as the working group >> >feels best. >> > >> >Jim >> > >> >> >> >> Jun 2015 - Submit COSE specification as a WG item >> >> Jun 2015 - Submit COSE constrained-appropriate algorithms as a WG >> >> item >> >> >> >> >> >> Kind Regards >> >> Kepeng >> >> >> >> =D4=DA 6/6/15 8:37 am=A3=AC "Jim Schaad" =D0=B4=C8=EB: >> >> >> >> >Since we now have an official working group. I will propose this >> >> >as a candidate draft to address the specification milestone. >> >> > >> >> >I am willing to add the algorithms piece to this document if that >> >> >is the desire of the group, or it can be done as an independent >> >> >document (my initial preference). >> >> > >> >> >Jim >> >> > >> >> > >> >> >> -----Original Message----- >> >> >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> >> >> Sent: Friday, June 05, 2015 5:22 PM >> >> >> To: Jim Schaad; Jim Schaad >> >> >> Subject: New Version Notification for draft-schaad-cose-02.txt >> >> >> >> >> >> >> >> >> A new version of I-D, draft-schaad-cose-02.txt has been >> >> >>successfully submitted by Jim Schaad and posted to the IETF >> >>repository. >> >> >> >> >> >> Name: draft-schaad-cose >> >> >> Revision: 02 >> >> >> Title: CBOR Encoded Message Syntax >> >> >> Document date: 2015-06-05 >> >> >> Group: Individual Submission >> >> >> Pages: 35 >> >> >> URL: >> >> >>https://www.ietf.org/internet-drafts/draft-schaad-cose-02.txt >> >> >> Status: =20 >>https://datatracker.ietf.org/doc/draft-schaad-cose/ >> >> >> Htmlized: https://tools.ietf.org/html/draft-schaad-cose-02 >> >> >> Diff: >> >>https://www.ietf.org/rfcdiff?url2=3Ddraft-schaad-cose-02 >> >> >> >> >> >> Abstract: >> >> >> Concise Binary Object Representation (CBOR) is data format >> >>designed >> >> >> for small code size and small message size. There is a need >> >> >> for >> >>the >> >> >> ability to have the basic security services defined for this >>data >> >> >> format. This document specifies how to do signatures, message >> >> >> authentication codes and encryption using this data format. >> >> >> The >> >work >> >> >> in this document is derived in part from the JSON web security >> >> >> documents using the same parameters and algorithm identifiers >> >> >> as >> >they >> >> >> do. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Please note that it may take a couple of minutes from the time >> >> >>of submission until the htmlized version and diff are available >> >> >>at tools.ietf.org. >> >> >> >> >> >> The IETF Secretariat >> >> > >> >> >_______________________________________________ >> >> >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 >> > >> >_______________________________________________ >> >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 > >_______________________________________________ >Cose mailing list >Cose@ietf.org >https://www.ietf.org/mailman/listinfo/cose From nobody Sat Jun 20 09:31:30 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9801A88DE for ; Sat, 20 Jun 2015 09:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 DyG79YR5IwiP for ; Sat, 20 Jun 2015 09:31:27 -0700 (PDT) Received: from out4133-34.mail.aliyun.com (out4133-34.mail.aliyun.com [42.120.133.34]) by ietfa.amsl.com (Postfix) with ESMTP id 024C51A88D6 for ; Sat, 20 Jun 2015 09:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1434817885; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=4rHsa/RMeR2On8fu4PS12cXk/JoZ66Ej0jpjgLqItjk=; b=CdR0Kod0MhTbvRloy/L//XlHrFQWLqxpcd0/bH2AcUNX4c2E4rf1u3r9iruWhQ3AjSXhpmIdqk/PJ7FF70iMGFcipHRatM+osZPNDZThtAFD1UtThTxKjW6OVFL+Tx6PR9O7V7Usb4xuCxfmLzkqeTWiLsN+7PY11Fw9d6AIe8w= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R191e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r41g08151; MF=kepeng.lkp@alibaba-inc.com; PH=DS; RN=4; RT=4; SR=0; Received: from 10.22.45.45(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.207) by smtp.aliyun-inc.com(127.0.0.1); Sun, 21 Jun 2015 00:31:19 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Sun, 21 Jun 2015 00:31:12 +0800 From: "Kepeng Li" To: "Kepeng Li" , "Mike Jones" , "Jim Schaad" , "cose@ietf.org" Message-ID: Thread-Topic: [Cose] Algorithm draft References: <004701d0a406$01b088d0$05119a70$@augustcellars.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Cose] Algorithm draft X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 16:31:29 -0000 Sorry, I missed Brian Campbell. Brian mentioned his willingness to help with the separate algorithms draft. Kind Regards Kepeng =D4=DA 20/6/15 11:05 pm=A3=AC "Kepeng Li" =D0=B4=C8=EB: >Hi Mike and Jim, > >Thanks for volunteering. > >It will be good if we can have the -00 version before our submission >deadline, that is, 6th July, 2015. > >Kind Regards >Kepeng > >=D4=DA 12/6/15 1:10 am=A3=AC "Mike Jones" =D0=B4=C8=EB: > >>I'd be glad to do this. I look forward to helping us get these specs out >>quickly in ways that meet the use cases people have. >> >> Cheers, >> -- Mike >> >>-----Original Message----- >>From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad >>Sent: Wednesday, June 10, 2015 10:18 PM >>To: 'Kepeng Li'; cose@ietf.org >>Subject: Re: [Cose] Algorithm draft >> >> >> >>> -----Original Message----- >>> From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Kepeng Li >>> Sent: Wednesday, June 10, 2015 6:03 PM >>> To: Mike Jones; Jim Schaad; cose@ietf.org >>> Subject: [Cose] Algorithm draft >>> >>> Currently, we have received feedback from Mike to have a separate >>algorithm >>> draft. >>> >>> Any other feedback? >>> >>> Also, we need to find somebody to write the algorithm draft, if we >>> decide >>to >>> have a separate one. >>> >>> Any volunteers? >> >>While I am willing to do this, I would prefer if it were somebody else if >>the document is separate. I object going to WG meetings where you only >>have one person who is doing the presentations. On the other hand, >>please remember the aggressive schedule that we are trying to keep for >>this group. >> >>Jim >> >>> >>> Thanks, >>> >>> Kind Regards >>> Kepeng >>> >>> =D4=DA 6/6/15 11:04 am=A3=AC "Mike Jones" =D0=B4=C8=EB: >>> >>> >For what it's worth, I'd advocate having a separate algorithm >>> >document for the same reasons that JOSE did. For one, it enables >>> >that document to be revised in the future without having to then >>> >revise the underlying signature/MAC/encryption/key representations. >>> > >>> >Also, based on my experience as a JOSE editor, I think the result was >>> >cleaner because we separated the algorithm descriptions from the >>> >descriptions of how to perform cryptographic operations. It was good >>> >discipline to have to describe the steps to create and use the data >>> >structures without falling back on particulars of specific algorithms. >>> > >>> >Also, the single-purpose nature of an algorithms doc can make it >>> >easier to read and use a reference. You're not having to sort out >>> >what are data descriptions and what are algorithm descriptions. It's >>> >just >>algorithms. >>> > >>> > Cheers, >>> > -- Mike >>> > >>> >P.S. I agree with Jim's procedural point that the charter allows the >>> >working group to produce deliverables either in combined or separated >>> >documents. >>> > >>> >-----Original Message----- >>> >From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad >>> >Sent: Friday, June 05, 2015 7:31 PM >>> >To: 'Kepeng Li'; cose@ietf.org >>> >Subject: Re: [Cose] FW: New Version Notification for >>> >draft-schaad-cose-02.txt >>> > >>> > >>> >> -----Original Message----- >>> >> From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Kepeng Li >>> >> Sent: Friday, June 05, 2015 6:49 PM >>> >> To: Jim Schaad; cose@ietf.org >>> >> Subject: Re: [Cose] FW: New Version Notification for >>> >>draft-schaad-cose-02. >>> >txt >>> >> >>> >> Hi Jim, >>> >> >>> >> Thanks for the draft. >>> >> >>> >> >I am willing to add the algorithms piece to this document if that >>> >> >is the desire of the group, or it can be done as an independent >>> >> >document (my initial preference).edx >>> >> >>> >> >>> >> According to our milestones, the algorithm piece is a separate item. >>> > >>> >That just says that we need a document to cover that milestone. It >>> >can be a single document or a combined document as the working group >>> >feels best. >>> > >>> >Jim >>> > >>> >> >>> >> Jun 2015 - Submit COSE specification as a WG item >>> >> Jun 2015 - Submit COSE constrained-appropriate algorithms as a WG >>> >> item >>> >> >>> >> >>> >> Kind Regards >>> >> Kepeng >>> >> >>> >> =D4=DA 6/6/15 8:37 am=A3=AC "Jim Schaad" =D0=B4=C8=EB: >>> >> >>> >> >Since we now have an official working group. I will propose this >>> >> >as a candidate draft to address the specification milestone. >>> >> > >>> >> >I am willing to add the algorithms piece to this document if that >>> >> >is the desire of the group, or it can be done as an independent >>> >> >document (my initial preference). >>> >> > >>> >> >Jim >>> >> > >>> >> > >>> >> >> -----Original Message----- >>> >> >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> >> >> Sent: Friday, June 05, 2015 5:22 PM >>> >> >> To: Jim Schaad; Jim Schaad >>> >> >> Subject: New Version Notification for draft-schaad-cose-02.txt >>> >> >> >>> >> >> >>> >> >> A new version of I-D, draft-schaad-cose-02.txt has been >>> >> >>successfully submitted by Jim Schaad and posted to the IETF >>> >>repository. >>> >> >> >>> >> >> Name: draft-schaad-cose >>> >> >> Revision: 02 >>> >> >> Title: CBOR Encoded Message Syntax >>> >> >> Document date: 2015-06-05 >>> >> >> Group: Individual Submission >>> >> >> Pages: 35 >>> >> >> URL: >>> >> >>https://www.ietf.org/internet-drafts/draft-schaad-cose-02.txt >>> >> >> Status: =20 >>>https://datatracker.ietf.org/doc/draft-schaad-cose/ >>> >> >> Htmlized: https://tools.ietf.org/html/draft-schaad-cose-02 >>> >> >> Diff: >>> >>https://www.ietf.org/rfcdiff?url2=3Ddraft-schaad-cose-02 >>> >> >> >>> >> >> Abstract: >>> >> >> Concise Binary Object Representation (CBOR) is data format >>> >>designed >>> >> >> for small code size and small message size. There is a need >>> >> >> for >>> >>the >>> >> >> ability to have the basic security services defined for this >>>data >>> >> >> format. This document specifies how to do signatures, message >>> >> >> authentication codes and encryption using this data format. >>> >> >> The >>> >work >>> >> >> in this document is derived in part from the JSON web security >>> >> >> documents using the same parameters and algorithm identifiers >>> >> >> as >>> >they >>> >> >> do. >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> Please note that it may take a couple of minutes from the time >>> >> >>of submission until the htmlized version and diff are available >>> >> >>at tools.ietf.org. >>> >> >> >>> >> >> The IETF Secretariat >>> >> > >>> >> >_______________________________________________ >>> >> >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 >>> > >>> >_______________________________________________ >>> >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 >> >>_______________________________________________ >>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 Jun 20 13:53:02 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733F61AC39C for ; Sat, 20 Jun 2015 13:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 JBSK0JcXxWfS for ; Sat, 20 Jun 2015 13:52:58 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0136.outbound.protection.outlook.com [65.55.169.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CEBF1AC399 for ; Sat, 20 Jun 2015 13:52:58 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.195.6; Sat, 20 Jun 2015 20:52:56 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0195.005; Sat, 20 Jun 2015 20:52:56 +0000 From: Mike Jones To: Kepeng Li , Jim Schaad , "cose@ietf.org" Thread-Topic: [Cose] Algorithm draft Thread-Index: AQHQo+JULTFPLWJliECVCdPyo+Ygop2mxCcAgADGdTCADgLBAIAAF+gAgABI/OA= Date: Sat, 20 Jun 2015 20:52:56 +0000 Message-ID: References: <004701d0a406$01b088d0$05119a70$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: alibaba-inc.com; dkim=none (message not signed) header.d=none; x-originating-ip: [50.47.90.173] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:MAt9w/JagH46R9wZfMXr1AST+ntulHa1wfJPwYXoq/pjmsLoDxveJlDroSORoy48nY7Z9ptYyo4RihnaX3A0bRB0JfiPGN4VeJ0DKOg5ly+O3JHDMVQCDWJPBhJWlLv6XHDhwdw6Gd1zkZ0ptIHa0A==; 24:IRRDOeXFwrHKk5ct570OdSdBqRohv1NBpz8KQJXAYkwPoUjsZilJWIJykv6pPqT1xwVPhAp5hUXALIH8XdRANO1+YEfN5hNvCqJAW7PibKk=; 20:clIF9PPy9G7gPXklD6F3C9Y/AbeTQbaz1VMw96Q7mJUE80JXKOl+cZImnhM1b+zItEAPWkhiEYEXiFE8QNYbRw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 0613912E23 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51414003)(51914003)(479174004)(13464003)(377424004)(71364002)(52604005)(377454003)(51704005)(164054003)(66066001)(107886002)(5001960100002)(5003600100002)(5002640100001)(40100003)(189998001)(74316001)(33656002)(5001770100001)(77156002)(62966003)(92566002)(122556002)(2900100001)(2501003)(19580405001)(54356999)(50986999)(76176999)(87936001)(2656002)(102836002)(15975445007)(86612001)(86362001)(77096005)(106116001)(46102003)(76576001)(19580395003)(2950100001)(99286002)(93886004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2015 20:52:56.3699 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Subject: Re: [Cose] Algorithm draft X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 20:53:01 -0000 Hi Kepeng, Brian and I have synced and we'll get an algorithms draft out during this c= oming week. -- Mike -----Original Message----- From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Kepeng Li Sent: Saturday, June 20, 2015 9:31 AM To: Kepeng Li; Mike Jones; Jim Schaad; cose@ietf.org Subject: Re: [Cose] Algorithm draft Sorry, I missed Brian Campbell. Brian mentioned his willingness to help with the separate algorithms draft. Kind Regards Kepeng =1B$B:_=1B(B 20/6/15 11:05 pm=1B$B!$=1B(B "Kepeng Li" =1B$BHi Mike and Jim, > >Thanks for volunteering. > >It will be good if we can have the -00 version before our submission=20 >deadline, that is, 6th July, 2015. > >Kind Regards >Kepeng > >=1B$B:_=1B(B 12/6/15 1:10 am=1B$B!$=1B(B "Mike Jones" =1B$B >>I'd be glad to do this. I look forward to helping us get these specs=20 >>out quickly in ways that meet the use cases people have. >> >> Cheers, >> -- Mike >> >>-----Original Message----- >>From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad >>Sent: Wednesday, June 10, 2015 10:18 PM >>To: 'Kepeng Li'; cose@ietf.org >>Subject: Re: [Cose] Algorithm draft >> >> >> >>> -----Original Message----- >>> From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Kepeng Li >>> Sent: Wednesday, June 10, 2015 6:03 PM >>> To: Mike Jones; Jim Schaad; cose@ietf.org >>> Subject: [Cose] Algorithm draft >>> >>> Currently, we have received feedback from Mike to have a separate >>algorithm >>> draft. >>> >>> Any other feedback? >>> >>> Also, we need to find somebody to write the algorithm draft, if we=20 >>> decide >>to >>> have a separate one. >>> >>> Any volunteers? >> >>While I am willing to do this, I would prefer if it were somebody else=20 >>if the document is separate. I object going to WG meetings where you=20 >>only have one person who is doing the presentations. On the other=20 >>hand, please remember the aggressive schedule that we are trying to=20 >>keep for this group. >> >>Jim >> >>> >>> Thanks, >>> >>> Kind Regards >>> Kepeng >>> >>> =1B$B:_=1B(B 6/6/15 11:04 am=1B$B!$=1B(B "Mike Jones" =1B$B>> >>> >For what it's worth, I'd advocate having a separate algorithm=20 >>> >document for the same reasons that JOSE did. For one, it enables=20 >>> >that document to be revised in the future without having to then=20 >>> >revise the underlying signature/MAC/encryption/key representations. >>> > >>> >Also, based on my experience as a JOSE editor, I think the result=20 >>> >was cleaner because we separated the algorithm descriptions from=20 >>> >the descriptions of how to perform cryptographic operations. It=20 >>> >was good discipline to have to describe the steps to create and use=20 >>> >the data structures without falling back on particulars of specific al= gorithms. >>> > >>> >Also, the single-purpose nature of an algorithms doc can make it=20 >>> >easier to read and use a reference. You're not having to sort out=20 >>> >what are data descriptions and what are algorithm descriptions. =20 >>> >It's just >>algorithms. >>> > >>> > Cheers, >>> > -- Mike >>> > >>> >P.S. I agree with Jim's procedural point that the charter allows=20 >>> >the working group to produce deliverables either in combined or=20 >>> >separated documents. >>> > >>> >-----Original Message----- >>> >From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad >>> >Sent: Friday, June 05, 2015 7:31 PM >>> >To: 'Kepeng Li'; cose@ietf.org >>> >Subject: Re: [Cose] FW: New Version Notification for=20 >>> >draft-schaad-cose-02.txt >>> > >>> > >>> >> -----Original Message----- >>> >> From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Kepeng Li >>> >> Sent: Friday, June 05, 2015 6:49 PM >>> >> To: Jim Schaad; cose@ietf.org >>> >> Subject: Re: [Cose] FW: New Version Notification for=20 >>> >>draft-schaad-cose-02. >>> >txt >>> >> >>> >> Hi Jim, >>> >> >>> >> Thanks for the draft. >>> >> >>> >> >I am willing to add the algorithms piece to this document if=20 >>> >> >that is the desire of the group, or it can be done as an=20 >>> >> >independent document (my initial preference).edx >>> >> >>> >> >>> >> According to our milestones, the algorithm piece is a separate item. >>> > >>> >That just says that we need a document to cover that milestone. It=20 >>> >can be a single document or a combined document as the working=20 >>> >group feels best. >>> > >>> >Jim >>> > >>> >> >>> >> Jun 2015 - Submit COSE specification as a WG item >>> >> Jun 2015 - Submit COSE constrained-appropriate algorithms as a=20 >>> >> WG item >>> >> >>> >> >>> >> Kind Regards >>> >> Kepeng >>> >> >>> >> =1B$B:_=1B(B 6/6/15 8:37 am=1B$B!$=1B(B "Jim Schaad" =1B$B>> >> >>> >> >Since we now have an official working group. I will propose=20 >>> >> >this as a candidate draft to address the specification milestone. >>> >> > >>> >> >I am willing to add the algorithms piece to this document if=20 >>> >> >that is the desire of the group, or it can be done as an=20 >>> >> >independent document (my initial preference). >>> >> > >>> >> >Jim >>> >> > >>> >> > >>> >> >> -----Original Message----- >>> >> >> From: internet-drafts@ietf.org=20 >>> >> >> [mailto:internet-drafts@ietf.org] >>> >> >> Sent: Friday, June 05, 2015 5:22 PM >>> >> >> To: Jim Schaad; Jim Schaad >>> >> >> Subject: New Version Notification for draft-schaad-cose-02.txt >>> >> >> >>> >> >> >>> >> >> A new version of I-D, draft-schaad-cose-02.txt has been=20 >>> >> >>successfully submitted by Jim Schaad and posted to the IETF >>> >>repository. >>> >> >> >>> >> >> Name: draft-schaad-cose >>> >> >> Revision: 02 >>> >> >> Title: CBOR Encoded Message Syntax >>> >> >> Document date: 2015-06-05 >>> >> >> Group: Individual Submission >>> >> >> Pages: 35 >>> >> >> URL: >>> >> >>https://www.ietf.org/internet-drafts/draft-schaad-cose-02.txt >>> >> >> Status: =20 >>>https://datatracker.ietf.org/doc/draft-schaad-cose/ >>> >> >> Htmlized: https://tools.ietf.org/html/draft-schaad-cose-02 >>> >> >> Diff: >>> >>https://www.ietf.org/rfcdiff?url2=3Ddraft-schaad-cose-02 >>> >> >> >>> >> >> Abstract: >>> >> >> Concise Binary Object Representation (CBOR) is data format >>> >>designed >>> >> >> for small code size and small message size. There is a=20 >>> >> >> need for >>> >>the >>> >> >> ability to have the basic security services defined for=20 >>> >> >> this >>>data >>> >> >> format. This document specifies how to do signatures, message >>> >> >> authentication codes and encryption using this data format. >>> >> >> The >>> >work >>> >> >> in this document is derived in part from the JSON web security >>> >> >> documents using the same parameters and algorithm=20 >>> >> >> identifiers as >>> >they >>> >> >> do. >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> Please note that it may take a couple of minutes from the time=20 >>> >> >>of submission until the htmlized version and diff are=20 >>> >> >>available at tools.ietf.org. >>> >> >> >>> >> >> The IETF Secretariat >>> >> > >>> >> >_______________________________________________ >>> >> >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 >>> > >>> >_______________________________________________ >>> >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 >> >>_______________________________________________ >>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 _______________________________________________ Cose mailing list Cose@ietf.org https://www.ietf.org/mailman/listinfo/cose From nobody Sat Jun 20 14:17:28 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27ED51A1B14 for ; Sat, 20 Jun 2015 14:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 D1ecEB-A7bXJ for ; Sat, 20 Jun 2015 14:17:23 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D7991A1B07 for ; Sat, 20 Jun 2015 14:17:23 -0700 (PDT) X-AuditID: 1209190f-f79716d000002ea2-b7-5585d862ee21 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id C0.D0.11938.268D5855; Sat, 20 Jun 2015 17:17:22 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t5KLHLa7019288; Sat, 20 Jun 2015 17:17:21 -0400 Received: from [192.168.128.56] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t5KLHIHb010992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 20 Jun 2015 17:17:20 -0400 Message-ID: <5585D854.3050206@mit.edu> Date: Sat, 20 Jun 2015 17:17:08 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mike Jones , Kepeng Li , Jim Schaad , "cose@ietf.org" References: <004701d0a406$01b088d0$05119a70$@augustcellars.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUixCmqrJt0ozXUYMdMXotpW6eyWqye/p3N 4vL8Iou90z6xOLB4THz7kcVj45zpbB5Llvxk8mjd8Zc9gCWKyyYlNSezLLVI3y6BK2PZ5jNM BR+dK67tSmtg/GLexcjJISFgIrHn5ykmCFtM4sK99WwgtpDAYiaJd6fzuxi5gOyNjBIbN3xh hXBuM0ms7fsMVsUroCYx7/ZDFhCbRUBVon3TerBJbED29DUtYLaoQJTE1MfrWCDqBSVOznzC AjJIRGANo8SpjVuApnJwCAsoSxxsU4NYcI9JYvaqpYwgDZwC0RK7myeD2cwCZhJdW7ugbHmJ 5q2zmScwCsxCMncWkrJZSMoWMDKvYpRNya3SzU3MzClOTdYtTk7My0st0jXRy80s0UtNKd3E CA5nSf4djN8OKh1iFOBgVOLh/bG0JVSINbGsuDL3EKMkB5OSKO+/e0AhvqT8lMqMxOKM+KLS nNTiQ4wSHMxKIrwXZ7aGCvGmJFZWpRblw6SkOViUxHk3/eALERJITyxJzU5NLUgtgsnKcHAo SfD2XQdqFCxKTU+tSMvMKUFIM3FwggznARq+H6SGt7ggMbc4Mx0if4pRUUqcdxZIQgAkkVGa B9cLSzevGMWBXhHm/QRSxQNMVXDdr4AGMwENnlDeBDK4JBEhJdXAGHT9Lv++sCYOO9PHq58v +HHgZ9g2G7veO1e2/mR8zfnww7WwhU8nH9daInL79+vsff07da7NvV5THiy/n918ajfbNDOe Zdx/v2iuLn3BZjjpwCUdb/0DD7Qb3nkJfolNmrug/RrP2uJcYdOy42YPZ02767m5uuJl+V9v necRN3USrgom7TFsO6bEUpyRaKjFXFScCABTLlgbEgMAAA== Archived-At: Subject: Re: [Cose] Algorithm draft X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 21:17:26 -0000 OK, we'll take that into consideration as a starting draft as well, based on discussion in the previous thread. I'd like to give the group time to review it specifically, so we'll start a one-week timer once it's published to the group, sound good? -- Justin On 6/20/2015 4:52 PM, Mike Jones wrote: > Hi Kepeng, > > Brian and I have synced and we'll get an algorithms draft out during this coming week. > > -- Mike > > -----Original Message----- > From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Kepeng Li > Sent: Saturday, June 20, 2015 9:31 AM > To: Kepeng Li; Mike Jones; Jim Schaad; cose@ietf.org > Subject: Re: [Cose] Algorithm draft > > Sorry, I missed Brian Campbell. > > Brian mentioned his willingness to help with the separate algorithms draft. > > > Kind Regards > Kepeng > > 在 20/6/15 11:05 pm， "Kepeng Li" 写入: > >> Hi Mike and Jim, >> >> Thanks for volunteering. >> >> It will be good if we can have the -00 version before our submission >> deadline, that is, 6th July, 2015. >> >> Kind Regards >> Kepeng >> >> 在 12/6/15 1:10 am， "Mike Jones" 写入: >> >>> I'd be glad to do this. I look forward to helping us get these specs >>> out quickly in ways that meet the use cases people have. >>> >>> Cheers, >>> -- Mike >>> >>> -----Original Message----- >>> From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad >>> Sent: Wednesday, June 10, 2015 10:18 PM >>> To: 'Kepeng Li'; cose@ietf.org >>> Subject: Re: [Cose] Algorithm draft >>> >>> >>> >>>> -----Original Message----- >>>> From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Kepeng Li >>>> Sent: Wednesday, June 10, 2015 6:03 PM >>>> To: Mike Jones; Jim Schaad; cose@ietf.org >>>> Subject: [Cose] Algorithm draft >>>> >>>> Currently, we have received feedback from Mike to have a separate >>> algorithm >>>> draft. >>>> >>>> Any other feedback? >>>> >>>> Also, we need to find somebody to write the algorithm draft, if we >>>> decide >>> to >>>> have a separate one. >>>> >>>> Any volunteers? >>> While I am willing to do this, I would prefer if it were somebody else >>> if the document is separate. I object going to WG meetings where you >>> only have one person who is doing the presentations. On the other >>> hand, please remember the aggressive schedule that we are trying to >>> keep for this group. >>> >>> Jim >>> >>>> Thanks, >>>> >>>> Kind Regards >>>> Kepeng >>>> >>>> 在 6/6/15 11:04 am， "Mike Jones" 写入: >>>> >>>>> For what it's worth, I'd advocate having a separate algorithm >>>>> document for the same reasons that JOSE did. For one, it enables >>>>> that document to be revised in the future without having to then >>>>> revise the underlying signature/MAC/encryption/key representations. >>>>> >>>>> Also, based on my experience as a JOSE editor, I think the result >>>>> was cleaner because we separated the algorithm descriptions from >>>>> the descriptions of how to perform cryptographic operations. It >>>>> was good discipline to have to describe the steps to create and use >>>>> the data structures without falling back on particulars of specific algorithms. >>>>> >>>>> Also, the single-purpose nature of an algorithms doc can make it >>>>> easier to read and use a reference. You're not having to sort out >>>>> what are data descriptions and what are algorithm descriptions. >>>>> It's just >>> algorithms. >>>>> Cheers, >>>>> -- Mike >>>>> >>>>> P.S. I agree with Jim's procedural point that the charter allows >>>>> the working group to produce deliverables either in combined or >>>>> separated documents. >>>>> >>>>> -----Original Message----- >>>>> From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad >>>>> Sent: Friday, June 05, 2015 7:31 PM >>>>> To: 'Kepeng Li'; cose@ietf.org >>>>> Subject: Re: [Cose] FW: New Version Notification for >>>>> draft-schaad-cose-02.txt >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Kepeng Li >>>>>> Sent: Friday, June 05, 2015 6:49 PM >>>>>> To: Jim Schaad; cose@ietf.org >>>>>> Subject: Re: [Cose] FW: New Version Notification for >>>>>> draft-schaad-cose-02. >>>>> txt >>>>>> Hi Jim, >>>>>> >>>>>> Thanks for the draft. >>>>>> >>>>>>> I am willing to add the algorithms piece to this document if >>>>>>> that is the desire of the group, or it can be done as an >>>>>>> independent document (my initial preference).edx >>>>>> >>>>>> According to our milestones, the algorithm piece is a separate item. >>>>> That just says that we need a document to cover that milestone. It >>>>> can be a single document or a combined document as the working >>>>> group feels best. >>>>> >>>>> Jim >>>>> >>>>>> Jun 2015 - Submit COSE specification as a WG item >>>>>> Jun 2015 - Submit COSE constrained-appropriate algorithms as a >>>>>> WG item >>>>>> >>>>>> >>>>>> Kind Regards >>>>>> Kepeng >>>>>> >>>>>> 在 6/6/15 8:37 am， "Jim Schaad" 写入: >>>>>> >>>>>>> Since we now have an official working group. I will propose >>>>>>> this as a candidate draft to address the specification milestone. >>>>>>> >>>>>>> I am willing to add the algorithms piece to this document if >>>>>>> that is the desire of the group, or it can be done as an >>>>>>> independent document (my initial preference). >>>>>>> >>>>>>> Jim >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: internet-drafts@ietf.org >>>>>>>> [mailto:internet-drafts@ietf.org] >>>>>>>> Sent: Friday, June 05, 2015 5:22 PM >>>>>>>> To: Jim Schaad; Jim Schaad >>>>>>>> Subject: New Version Notification for draft-schaad-cose-02.txt >>>>>>>> >>>>>>>> >>>>>>>> A new version of I-D, draft-schaad-cose-02.txt has been >>>>>>>> successfully submitted by Jim Schaad and posted to the IETF >>>>>> repository. >>>>>>>> Name: draft-schaad-cose >>>>>>>> Revision: 02 >>>>>>>> Title: CBOR Encoded Message Syntax >>>>>>>> Document date: 2015-06-05 >>>>>>>> Group: Individual Submission >>>>>>>> Pages: 35 >>>>>>>> URL: >>>>>>>> https://www.ietf.org/internet-drafts/draft-schaad-cose-02.txt >>>>>>>> Status: >>>> https://datatracker.ietf.org/doc/draft-schaad-cose/ >>>>>>>> Htmlized: https://tools.ietf.org/html/draft-schaad-cose-02 >>>>>>>> Diff: >>>>>> https://www.ietf.org/rfcdiff?url2=draft-schaad-cose-02 >>>>>>>> Abstract: >>>>>>>> Concise Binary Object Representation (CBOR) is data format >>>>>> designed >>>>>>>> for small code size and small message size. There is a >>>>>>>> need for >>>>>> the >>>>>>>> ability to have the basic security services defined for >>>>>>>> this >>>> data >>>>>>>> format. This document specifies how to do signatures, message >>>>>>>> authentication codes and encryption using this data format. >>>>>>>> The >>>>> work >>>>>>>> in this document is derived in part from the JSON web security >>>>>>>> documents using the same parameters and algorithm >>>>>>>> identifiers as >>>>> they >>>>>>>> do. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Please note that it may take a couple of minutes from the time >>>>>>>> of submission until the htmlized version and diff are >>>>>>>> available at tools.ietf.org. >>>>>>>> >>>>>>>> The IETF Secretariat >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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 Jun 20 19:45:48 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFF11A90F8 for ; Sat, 20 Jun 2015 19:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 aa1oySuqRre5 for ; Sat, 20 Jun 2015 19:45:43 -0700 (PDT) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (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 21A1E1A90F7 for ; Sat, 20 Jun 2015 19:45:42 -0700 (PDT) Received: by igboe5 with SMTP id oe5so41234907igb.1 for ; Sat, 20 Jun 2015 19:45:42 -0700 (PDT) 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-type; bh=2uhY4ZRT6FBMU3Fw+U7QlVGHQ6C0SrS03cUAWHN5ckU=; b=Bfz5RACNIyPV6kIg9yI/scd44ebsUim6XxjSw/mYhjRR0SnTSfxLhXG9VuhgQdqErJ Os8y5Wq3MAACMRDnqH3e0/L5Gd5SxVJSjjMrKtdbs7Ht6UQV42nQkmXE4rr4KzhC42kY hatEfm+HqXC2ZnZ54bzzRsqJIMDhlzgFwqUQtITj59Jeq2JfGMDO/ruV7ekPiAyb6hSA FQgJbdRxEWF551omIXRylyzECa4JkgCtKSMUw9gxKW4aO3CkDM+vK+xpoOIYNjmbJgBS wkrkDiSHdBAkQhbrM0XsQINOfs6daEUZ7tey0K5O2y4JnjYkHYuzyxIJXgdvj0eBvguy GWdQ== X-Gm-Message-State: ALoCoQlfntyZRvJg3nAyCTGWcSqG3zWtzWszJsDKZacmFOzMOBrMWRBjBHWcpIqSNZ3fOADwaoTc X-Received: by 10.107.35.203 with SMTP id j194mr31441059ioj.45.1434854742270; Sat, 20 Jun 2015 19:45:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.64.209 with HTTP; Sat, 20 Jun 2015 19:45:12 -0700 (PDT) In-Reply-To: <5585D854.3050206@mit.edu> References: <004701d0a406$01b088d0$05119a70$@augustcellars.com> <5585D854.3050206@mit.edu> From: Brian Campbell Date: Sat, 20 Jun 2015 20:45:12 -0600 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=001a1140444037d9680518fe2796 Archived-At: Cc: Mike Jones , Kepeng Li , Jim Schaad , "cose@ietf.org" Subject: Re: [Cose] Algorithm draft X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2015 02:45:46 -0000 --001a1140444037d9680518fe2796 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sounds okay to me. On Sat, Jun 20, 2015 at 3:17 PM, Justin Richer wrote: > OK, we'll take that into consideration as a starting draft as well, based > on discussion in the previous thread. I'd like to give the group time to > review it specifically, so we'll start a one-week timer once it's publish= ed > to the group, sound good? > > -- Justin > > > On 6/20/2015 4:52 PM, Mike Jones wrote: > >> Hi Kepeng, >> >> Brian and I have synced and we'll get an algorithms draft out during thi= s >> coming week. >> >> -- Mike >> >> -----Original Message----- >> From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Kepeng Li >> Sent: Saturday, June 20, 2015 9:31 AM >> To: Kepeng Li; Mike Jones; Jim Schaad; cose@ietf.org >> Subject: Re: [Cose] Algorithm draft >> >> Sorry, I missed Brian Campbell. >> >> Brian mentioned his willingness to help with the separate algorithms >> draft. >> >> >> Kind Regards >> Kepeng >> >> =E5=9C=A8 20/6/15 11:05 pm=EF=BC=8C "Kepeng Li" =E5=86=99=E5=85=A5: >> >> Hi Mike and Jim, >>> >>> Thanks for volunteering. >>> >>> It will be good if we can have the -00 version before our submission >>> deadline, that is, 6th July, 2015. >>> >>> Kind Regards >>> Kepeng >>> >>> =E5=9C=A8 12/6/15 1:10 am=EF=BC=8C "Mike Jones" =E5=86=99=E5=85=A5: >>> >>> I'd be glad to do this. I look forward to helping us get these specs >>>> out quickly in ways that meet the use cases people have. >>>> >>>> Cheers, >>>> -- Mike >>>> >>>> -----Original Message----- >>>> From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad >>>> Sent: Wednesday, June 10, 2015 10:18 PM >>>> To: 'Kepeng Li'; cose@ietf.org >>>> Subject: Re: [Cose] Algorithm draft >>>> >>>> >>>> >>>> -----Original Message----- >>>>> From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Kepeng Li >>>>> Sent: Wednesday, June 10, 2015 6:03 PM >>>>> To: Mike Jones; Jim Schaad; cose@ietf.org >>>>> Subject: [Cose] Algorithm draft >>>>> >>>>> Currently, we have received feedback from Mike to have a separate >>>>> >>>> algorithm >>>> >>>>> draft. >>>>> >>>>> Any other feedback? >>>>> >>>>> Also, we need to find somebody to write the algorithm draft, if we >>>>> decide >>>>> >>>> to >>>> >>>>> have a separate one. >>>>> >>>>> Any volunteers? >>>>> >>>> While I am willing to do this, I would prefer if it were somebody else >>>> if the document is separate. I object going to WG meetings where you >>>> only have one person who is doing the presentations. On the other >>>> hand, please remember the aggressive schedule that we are trying to >>>> keep for this group. >>>> >>>> Jim >>>> >>>> Thanks, >>>>> >>>>> Kind Regards >>>>> Kepeng >>>>> >>>>> =E5=9C=A8 6/6/15 11:04 am=EF=BC=8C "Mike Jones" =E5=86=99=E5=85=A5: >>>>> >>>>> For what it's worth, I'd advocate having a separate algorithm >>>>>> document for the same reasons that JOSE did. For one, it enables >>>>>> that document to be revised in the future without having to then >>>>>> revise the underlying signature/MAC/encryption/key representations. >>>>>> >>>>>> Also, based on my experience as a JOSE editor, I think the result >>>>>> was cleaner because we separated the algorithm descriptions from >>>>>> the descriptions of how to perform cryptographic operations. It >>>>>> was good discipline to have to describe the steps to create and use >>>>>> the data structures without falling back on particulars of specific >>>>>> algorithms. >>>>>> >>>>>> Also, the single-purpose nature of an algorithms doc can make it >>>>>> easier to read and use a reference. You're not having to sort out >>>>>> what are data descriptions and what are algorithm descriptions. >>>>>> It's just >>>>>> >>>>> algorithms. >>>> >>>>> Cheers, >>>>>> -- Mike >>>>>> >>>>>> P.S. I agree with Jim's procedural point that the charter allows >>>>>> the working group to produce deliverables either in combined or >>>>>> separated documents. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad >>>>>> Sent: Friday, June 05, 2015 7:31 PM >>>>>> To: 'Kepeng Li'; cose@ietf.org >>>>>> Subject: Re: [Cose] FW: New Version Notification for >>>>>> draft-schaad-cose-02.txt >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>>> From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Kepeng Li >>>>>>> Sent: Friday, June 05, 2015 6:49 PM >>>>>>> To: Jim Schaad; cose@ietf.org >>>>>>> Subject: Re: [Cose] FW: New Version Notification for >>>>>>> draft-schaad-cose-02. >>>>>>> >>>>>> txt >>>>>> >>>>>>> Hi Jim, >>>>>>> >>>>>>> Thanks for the draft. >>>>>>> >>>>>>> I am willing to add the algorithms piece to this document if >>>>>>>> that is the desire of the group, or it can be done as an >>>>>>>> independent document (my initial preference).edx >>>>>>>> >>>>>>> >>>>>>> According to our milestones, the algorithm piece is a separate item= . >>>>>>> >>>>>> That just says that we need a document to cover that milestone. It >>>>>> can be a single document or a combined document as the working >>>>>> group feels best. >>>>>> >>>>>> Jim >>>>>> >>>>>> Jun 2015 - Submit COSE specification as a WG item >>>>>>> Jun 2015 - Submit COSE constrained-appropriate algorithms as a >>>>>>> WG item >>>>>>> >>>>>>> >>>>>>> Kind Regards >>>>>>> Kepeng >>>>>>> >>>>>>> =E5=9C=A8 6/6/15 8:37 am=EF=BC=8C "Jim Schaad" =E5=86=99=E5=85=A5: >>>>>>> >>>>>>> Since we now have an official working group. I will propose >>>>>>>> this as a candidate draft to address the specification milestone. >>>>>>>> >>>>>>>> I am willing to add the algorithms piece to this document if >>>>>>>> that is the desire of the group, or it can be done as an >>>>>>>> independent document (my initial preference). >>>>>>>> >>>>>>>> Jim >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>>> From: internet-drafts@ietf.org >>>>>>>>> [mailto:internet-drafts@ietf.org] >>>>>>>>> Sent: Friday, June 05, 2015 5:22 PM >>>>>>>>> To: Jim Schaad; Jim Schaad >>>>>>>>> Subject: New Version Notification for draft-schaad-cose-02.txt >>>>>>>>> >>>>>>>>> >>>>>>>>> A new version of I-D, draft-schaad-cose-02.txt has been >>>>>>>>> successfully submitted by Jim Schaad and posted to the IETF >>>>>>>>> >>>>>>>> repository. >>>>>>> >>>>>>>> Name: draft-schaad-cose >>>>>>>>> Revision: 02 >>>>>>>>> Title: CBOR Encoded Message Syntax >>>>>>>>> Document date: 2015-06-05 >>>>>>>>> Group: Individual Submission >>>>>>>>> Pages: 35 >>>>>>>>> URL: >>>>>>>>> https://www.ietf.org/internet-drafts/draft-schaad-cose-02.txt >>>>>>>>> Status: >>>>>>>>> >>>>>>>> https://datatracker.ietf.org/doc/draft-schaad-cose/ >>>>> >>>>>> Htmlized: https://tools.ietf.org/html/draft-schaad-cose-02 >>>>>>>>> Diff: >>>>>>>>> >>>>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-schaad-cose-02 >>>>>>> >>>>>>>> Abstract: >>>>>>>>> Concise Binary Object Representation (CBOR) is data format >>>>>>>>> >>>>>>>> designed >>>>>>> >>>>>>>> for small code size and small message size. There is a >>>>>>>>> need for >>>>>>>>> >>>>>>>> the >>>>>>> >>>>>>>> ability to have the basic security services defined for >>>>>>>>> this >>>>>>>>> >>>>>>>> data >>>>> >>>>>> format. This document specifies how to do signatures, message >>>>>>>>> authentication codes and encryption using this data format. >>>>>>>>> The >>>>>>>>> >>>>>>>> work >>>>>> >>>>>>> in this document is derived in part from the JSON web security >>>>>>>>> documents using the same parameters and algorithm >>>>>>>>> identifiers as >>>>>>>>> >>>>>>>> they >>>>>> >>>>>>> do. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Please note that it may take a couple of minutes from the time >>>>>>>>> of submission until the htmlized version and diff are >>>>>>>>> available at tools.ietf.org. >>>>>>>>> >>>>>>>>> The IETF Secretariat >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> _______________________________________________ >>>> 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 >>> >> >> _______________________________________________ >> 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 >> > > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose > --001a1140444037d9680518fe2796 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sounds okay to me.
On Sat, Jun 20, 2015 at 3:17 PM, Justin Richer= <jricher@mit.edu> wrote:
OK= , we'll take that into consideration as a starting draft as well, based= on discussion in the previous thread. I'd like to give the group time = to review it specifically, so we'll start a one-week timer once it'= s published to the group, sound good?

=C2=A0-- Justin


On 6/20/2015 4:52 PM, Mike Jones wrote:
Hi Kepeng,

Brian and I have synced and we'll get an algorithms draft out during th= is coming week.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike

-----Original Message-----
From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Kepeng Li
Sent: Saturday, June 20, 2015 9:31 AM
To: Kepeng Li; Mike Jones; Jim Schaad; cose@ietf.org
Subject: Re: [Cose] Algorithm draft

Sorry, I missed Brian Campbell.

Brian mentioned his willingness to help with the separate algorithms draft.=


Kind Regards
Kepeng

=E5=9C=A8 20/6/15 11:05 pm=EF=BC=8C "Kepeng Li" <kepeng.lkp@alibaba-inc.c= om> =E5=86=99=E5=85=A5:

Hi Mike and Jim,

Thanks for volunteering.

It will be good if we can have the -00 version before our submission
deadline, that is, 6th July, 2015.

Kind Regards
Kepeng

=E5=9C=A8 12/6/15 1:10 am=EF=BC=8C "Mike Jones" <Michael.Jones@microsoft= .com> =E5=86=99=E5=85=A5:

I'd be glad to do this.=C2=A0 I look forward to helping us get these sp= ecs
out quickly in ways that meet the use cases people have.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike

-----Original Message-----
From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Wednesday, June 10, 2015 10:18 PM
To: 'Kepeng Li'; cose@ietf.org
Subject: Re: [Cose] Algorithm draft



-----Original Message-----
From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Kepeng Li
Sent: Wednesday, June 10, 2015 6:03 PM
To: Mike Jones; Jim Schaad; cose@ietf.org
Subject: [Cose] Algorithm draft

Currently, we have received feedback from Mike to have a separate
algorithm
draft.

Any other feedback?

Also, we need to find somebody to write the algorithm draft, if we
decide
to
have a separate one.

Any volunteers?
While I am willing to do this, I would prefer if it were somebody else
if the document is separate.=C2=A0 I object going to WG meetings where you<= br> only have one person who is doing the presentations.=C2=A0 On the other
hand, please remember the aggressive schedule that we are trying to
keep for this group.

Jim

Thanks,

Kind Regards
Kepeng

=E5=9C=A8 6/6/15 11:04 am=EF=BC=8C "Mike Jones" <Michael.Jones@microsoft= .com> =E5=86=99=E5=85=A5:

For what it's worth, I'd advocate having a separate algorithm
document for the same reasons that JOSE did.=C2=A0 For one, it enables
that document to be revised in the future without having to then
revise the underlying signature/MAC/encryption/key representations.

Also, based on my experience as a JOSE editor, I think the result
was cleaner because we separated the algorithm descriptions from
the descriptions of how to perform cryptographic operations.=C2=A0 It
was good discipline to have to describe the steps to create and use
the data structures without falling back on particulars of specific algorit= hms.

Also, the single-purpose nature of an algorithms doc can make it
easier to read and use a reference.=C2=A0 You're not having to sort out=
what are data descriptions and what are algorithm descriptions.
It's just
algorithms.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike

P.S.=C2=A0 I agree with Jim's procedural point that the charter allows<= br> the working group to produce deliverables either in combined or
separated documents.

-----Original Message-----
From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Friday, June 05, 2015 7:31 PM
To: 'Kepeng Li'; cose@ietf.org
Subject: Re: [Cose] FW: New Version Notification for
draft-schaad-cose-02.txt


-----Original Message-----
From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Kepeng Li
Sent: Friday, June 05, 2015 6:49 PM
To: Jim Schaad; cose@iet= f.org
Subject: Re: [Cose] FW: New Version Notification for
draft-schaad-cose-02.
txt
Hi Jim,

Thanks for the draft.

I am willing to add the algorithms piece to this document if
that is the desire of the group, or it can be done as an
independent document (my initial preference).edx

According to our milestones, the algorithm piece is a separate item.
That just says that we need a document to cover that milestone.=C2=A0 It can be a single document or a combined document as the working
group feels best.

Jim

Jun 2015 - Submit COSE specification as a WG item
=C2=A0 =C2=A0Jun 2015 - Submit COSE constrained-appropriate algorithms as a=
WG item


Kind Regards
Kepeng

=E5=9C=A8 6/6/15 8:37 am=EF=BC=8C "Jim Schaad" <ietf@augustcellars.com>= ; =E5=86=99=E5=85=A5:

Since we now have an official working group.=C2=A0 I will propose
this as a candidate draft to address the specification milestone.

I am willing to add the algorithms piece to this document if
that is the desire of the group, or it can be done as an
independent document (my initial preference).

Jim


-----Original Message-----
From: interne= t-drafts@ietf.org
[mailto:inter= net-drafts@ietf.org]
Sent: Friday, June 05, 2015 5:22 PM
To: Jim Schaad; Jim Schaad
Subject: New Version Notification for draft-schaad-cose-02.txt


A new version of I-D, draft-schaad-cose-02.txt has been
successfully submitted=C2=A0 by Jim Schaad and posted to the IETF
repository.
Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-schaad-cose
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CBOR Encoded Message Syntax
Document date:=C2=A0 2015-06-05
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 35
URL:
https://www.ietf.org/internet-drafts/dr= aft-schaad-cose-02.txt
Status:
https://datatracker.ietf.org/doc/draft-schaad-cos= e/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ie= tf.org/html/draft-schaad-cose-02
Diff:
https://www.ietf.org/rfcdiff?url2=3Ddraft-sc= haad-cose-02
Abstract:
=C2=A0 =C2=A0 Concise Binary Object Representation (CBOR) is data format
designed
=C2=A0 =C2=A0 for small code size and small message size.=C2=A0 There is a<= br> need for
the
=C2=A0 =C2=A0 ability to have the basic security services defined for
this
data
=C2=A0 =C2=A0 format.=C2=A0 This document specifies how to do signatures, m= essage
=C2=A0 =C2=A0 authentication codes and encryption using this data format. The
work
=C2=A0 =C2=A0 in this document is derived in part from the JSON web securit= y
=C2=A0 =C2=A0 documents using the same parameters and algorithm
identifiers as
they
=C2=A0 =C2=A0 do.




Please note that it may take a couple of minutes from the time
of submission=C2=A0 until the htmlized version and diff are
available at tools.ietf.org.

The IETF Secretariat
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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

_______________________________________________
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

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

--001a1140444037d9680518fe2796-- From nobody Fri Jun 26 19:18:56 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D0A1B2BF7 for ; Fri, 26 Jun 2015 19:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 0CR2SLJMMdOM for ; Fri, 26 Jun 2015 19:18:53 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9D21B2C0C for ; Fri, 26 Jun 2015 19:18:51 -0700 (PDT) X-AuditID: 12074422-f79d26d0000026d6-fd-558e080a070a Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id A4.DE.09942.A080E855; Fri, 26 Jun 2015 22:18:50 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t5R2Iob5023512 for ; Fri, 26 Jun 2015 22:18:50 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t5R2Il1B006480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 26 Jun 2015 22:18:49 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_46501408-B967-42A6-9168-65A6C69810D6" Message-Id: <1B462EEC-67AF-4F19-B8F5-82BA36C59C8D@mit.edu> Date: Fri, 26 Jun 2015 22:18:47 -0400 To: cose@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsUixG6nrsvF0Rdq8PGzocW0rVNZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsXpJJ0vBPv6KsyuWsjYwHuXtYuTkkBAwkbjyoJUZwhaTuHBv PVsXIxeHkMBiJonL6/8xQzhHGSU2v+1mgXC+Mkk07nwA1sImoCoxf+UtJhCbWSBB4vfMK4wg trCAvsSGqz+A4hwcvAJWEqvOlYGEWYDKf228wQ4SFhEQlLjbaQ4S5hXQk3j09DFYWEJAVuLr VrkJjLyzkMychaQKIq4tsWzha2YIW1Nif/dyFkxxDYnObxNZFzCyrWKUTcmt0s1NzMwpTk3W LU5OzMtLLdI11cvNLNFLTSndxAgOSBelHYw/DyodYhTgYFTi4c281BsqxJpYVlyZe4hRkoNJ SZRX5xpQiC8pP6UyI7E4I76oNCe1+BCjBAezkghv1WOgHG9KYmVValE+TEqag0VJnHfTD74Q IYH0xJLU7NTUgtQimKwMB4eSBG8eW1+okGBRanpqRVpmTglCmomDE2Q4D9Bwe5Aa3uKCxNzi zHSI/ClGRSlx3nkgCQGQREZpHlwvLGG8YhQHekWY9zRIFQ8w2cB1vwIazAQ0+G18F8jgkkSE lFQD4yyj28/v3zr48OJ8xwlxf//wivGpi3I7cQc/iVoyy2VJU5RGoYW99nzzhj79vkR7H+vF 7vaGLlOcGay4CzZZvW5SvnyQ6dInOylGg3O8vlxyW/g+fP8tZjW7+d2MnZucrC+GzSzvV2MQ 2vFynS3f/+eHL6R63Du5cdJDzQOqbw/u/FL5ZPW+aCWW4oxEQy3mouJEANjJ5pnzAgAA Archived-At: Subject: [Cose] Consensus Call on Input Draft Adoption X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 02:18:55 -0000 --Apple-Mail=_46501408-B967-42A6-9168-65A6C69810D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The chairs would like to make a consensus call on accepting the = following document as the input draft for a new working group item: https://tools.ietf.org/html/draft-schaad-cose-msg-01 = This document, if accepted, will become the basis of the COSE message = syntax specification. Please reply to this thread whether or not you would like to accept this = document as input to the working group.=20 Thank you, =E2=80=94 Justin (& Kepeng)= --Apple-Mail=_46501408-B967-42A6-9168-65A6C69810D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The chairs would like to make a consensus call on accepting = the following document as the input draft for a new working group = item:


https://tools.ietf.org/html/draft-schaad-cose-msg-01
<= div class=3D"">

This document, if accepted, will become = the basis of the COSE message syntax specification.

Please reply to this = thread whether or not you would like to accept this document as input to = the working group. 

Thank you,
 =E2=80=94 Justin (& = Kepeng)
= --Apple-Mail=_46501408-B967-42A6-9168-65A6C69810D6-- From nobody Fri Jun 26 19:31:31 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1089C1B2C86 for ; Fri, 26 Jun 2015 19:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 o2t-lXT1ZpRr for ; Fri, 26 Jun 2015 19:31:28 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFAD31B2B42 for ; Fri, 26 Jun 2015 19:31:27 -0700 (PDT) X-AuditID: 1209190d-f796f6d000005314-cb-558e0afee7df Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 76.E9.21268.EFA0E855; Fri, 26 Jun 2015 22:31:26 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t5R2VP42024343 for ; Fri, 26 Jun 2015 22:31:26 -0400 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t5R2VOF5009030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 26 Jun 2015 22:31:25 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_0031BF98-93A6-4E83-9C6E-BF7755117BBF" Message-Id: <13DE5790-1C07-46A8-A900-EC059D03B55A@mit.edu> Date: Fri, 26 Jun 2015 22:31:24 -0400 To: cose@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPIsWRmVeSWpSXmKPExsUixG6nrvuPqy/UoPe1iMW0rVNZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcf7wesaCw2oVd/7INTD2KHQxcnJICJhITDjaxQJhi0lcuLee rYuRi0NIYDGTxMpDLcwgCSGBo4wSpzoCIBJfmSTWT5zDBpJgE1CVmL/yFhOIzSyQIPGz9wlY XFhAX+LnsRtgU3kFrCT6t00Hs1mA6te1vGHsYuTgEBEQlLjbaQ5Roifx6OljdpCwhICsxNet chMYeWchGToLSRVEXFti2cLXzBC2psT+7uUsmOIaEp3fJrIuYGRbxSibklulm5uYmVOcmqxb nJyYl5dapGukl5tZopeaUrqJERSOnJK8OxjfHVQ6xCjAwajEw5txqTdUiDWxrLgy9xCjJAeT kiivzjWgEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHeqsdAOd6UxMqq1KJ8mJQ0B4uSOO+mH3wh QgLpiSWp2ampBalFMFkZDg4lCd6nnH2hQoJFqempFWmZOSUIaSYOTpDhPEDDj4LU8BYXJOYW Z6ZD5E8xKkqJ874ESQiAJDJK8+B6YeniFaM40CvCvLNBqniAqQau+xXQYCagwW/ju0AGlyQi pKQaGFvT96yazRD2eH4ZS7xfaJ7Uy51WZumyR9/PerxWe67Lvb8bPY3Sv5f8VvAqLY0O0mhi 4P2XOGnP5ZDQWuv9fNyf2/je8XxYWWCbp13qK9EWM2Pbfvbyq+dOJX50uXLo3d5zZkV1bI7P VLVrbWw+6pY9df1+TvGEXVHZ5x+7Su86tOyzmtYYqsRSnJFoqMVcVJwIADWhERHyAgAA Archived-At: Subject: [Cose] Document Structur, Editors, and Prague X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 02:31:30 -0000 --Apple-Mail=_0031BF98-93A6-4E83-9C6E-BF7755117BBF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Separating this on a new thread so as not to confuse the consensus call = on the document as it currently stands. In parallel to the review and call for acceptance of = https://tools.ietf.org/html/draft-schaad-cose-msg-01 = as input, the = chairs have spoken to several potential editors and have asked both Jim = Shaad and Brian Campbell to act in that capacity.=20 Additionally, we have asked Jim to prepare a version of the above = document with the algorithm definitions included as an exercise in = document structure. Jim has said he will make this version available = prior to the Prague meeting, in the hopes that the WG can determine = whether or not a single-document or multiple-document format will be = used going forward. The thought here is that it=E2=80=99s easier to = abstract things into two documents than it is to combine them into one, = and this structure will give us a good starting point for discussion. = Keep an eye out for this document, which will be in the form of an I-D = from Jim. Finally, our meeting has been officially scheduled. We=E2=80=99re the = first session on Monday morning, and we=E2=80=99re sharing the room with = IPSECME for the 9:00-11:30 slot. They=E2=80=99ll be taking the first = hour, and we=E2=80=99ll be taking the balance of the slot. On paper that = gives us 90 minutes starting at 10:00; in practice we might get a little = bit more than that as the IPSECME chairs have indicated that their work = might not take a full hour and we can start early. As such, please try = to get to the room before the official 10am time slot, as we=E2=80=99ll = be starting as soon as we can whether you=E2=80=99re there or not. :) Additionally, the chairs would like to now officially solicit proposals = for presentations during the inaugural COSE face to face. Thank you everyone. Please remember to chime in on the other thread, and = we=E2=80=99ll see you in Prague! =E2=80=94 Justin (& Kepeng)= --Apple-Mail=_0031BF98-93A6-4E83-9C6E-BF7755117BBF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Separating this on a = new thread so as not to confuse the consensus call on the document as it = currently stands.

In = parallel to the review and call for acceptance of https://tools.ietf.org/html/draft-schaad-cose-msg-01 a= s input, the chairs have spoken to several potential editors and have = asked both Jim Shaad and Brian Campbell to act in that = capacity. 

Additionally, we have asked Jim to prepare a version of the = above document with the algorithm definitions included as an exercise in = document structure. Jim has said he will make this version available = prior to the Prague meeting, in the hopes that the WG can determine = whether or not a single-document or multiple-document format will be = used going forward. The thought here is that it=E2=80=99s easier to = abstract things into two documents than it is to combine them into one, = and this structure will give us a good starting point for discussion. = Keep an eye out for this document, which will be in the form of an I-D = from Jim.

Finally, our meeting has been officially scheduled. We=E2=80=99= re the first session on Monday morning, and we=E2=80=99re sharing the = room with IPSECME for the 9:00-11:30 slot. They=E2=80=99ll be taking the = first hour, and we=E2=80=99ll be taking the balance of the slot. On = paper that gives us 90 minutes starting at 10:00; in practice we might = get a little bit more than that as the IPSECME chairs have indicated = that their work might not take a full hour and we can start early. As = such, please try to get to the room before the official 10am time slot, = as we=E2=80=99ll be starting as soon as we can whether you=E2=80=99re = there or not. :)

Additionally, the chairs would like to now officially solicit = proposals for presentations during the inaugural COSE face to = face.

Thank = you everyone. Please remember to chime in on the other thread, and = we=E2=80=99ll see you in Prague!
 =E2=80=94 = Justin (& Kepeng)
= --Apple-Mail=_0031BF98-93A6-4E83-9C6E-BF7755117BBF-- From nobody Sat Jun 27 02:07:00 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF1B1B32C1 for ; Sat, 27 Jun 2015 02:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ovYVOhD1Vvyh for ; Sat, 27 Jun 2015 02:06:47 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0772.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:772]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE7BD1B32BF for ; Sat, 27 Jun 2015 02:06:46 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.201.16; Sat, 27 Jun 2015 09:06:40 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0201.000; Sat, 27 Jun 2015 09:06:40 +0000 From: Mike Jones To: "cose@ietf.org" Thread-Topic: Review of draft-schaad-cose-msg-01 Thread-Index: AdCwuG36k7Yq5VJ4SCGK90wxv/T+IA== Date: Sat, 27 Jun 2015 09:06:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [50.47.90.173] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:rZtND5Y88zKO551CMABCnzY1h+fMLwqkTHATcrQGdNCnxCBRqxUWDtW4u0YqknePdcUzWteCZiafuYOQdzmgpugyceEHSLjG/l0Us1guSwxIy9htFg12AItXrSAAZ3Ykfx2M9sX3cuzaOorWwnwQ7g==; 24:kdvitF7o5Ch8ihsx3rpWSRU25h9Bj/6KERrRd7V/oRypKct1z8f3/7oV9un1fvlKzPHcB45mHrOesSaaj0x0JXzx2iloyIc83OEUlGfvDjQ=; 20:x7kHoFu5XG3kLiXtR29NY0FQvkh+fb5WaInN11oPW10aC/gjumoEMPRLNupZhNHFdQ3VHeYZ00fGoE5MQrpdqg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0620CADDF3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(60444003)(2900100001)(19580395003)(5002640100001)(19580405001)(5001960100002)(450100001)(40100003)(19617315012)(62966003)(77156002)(19300405004)(66066001)(107886002)(102836002)(189998001)(33656002)(229853001)(15975445007)(110136002)(77096005)(5003600100002)(2351001)(2501003)(122556002)(16236675004)(50986999)(54356999)(86612001)(86362001)(575784001)(87936001)(2656002)(92566002)(19625215002)(230783001)(74316001)(99286002)(46102003)(76576001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442E3A163870ADE7AAABCF5F5AC0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2015 09:06:40.4891 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Subject: [Cose] Review of draft-schaad-cose-msg-01 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 09:06:58 -0000 --_000_BY2PR03MB442E3A163870ADE7AAABCF5F5AC0BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In response to the call for adoption, I'm submitting the following review f= eedback on draft-schaad-cose-msg-01. Most of the major comments are motivated by the goal of "ke= eping simple things simple". Particularly in constrained environments, it'= s likely to be normal for implementations to use only the parts of COSE the= y their application needs. I believe that we should therefore optimize the= representations we define for the common cases, while making it possible t= o also gracefully accommodate less common, if possibly more general cases a= s well. Also, given my role as a designer and editor of the JOSE specs, I'll say ex= plicitly that it's not my goal to try to have all the decisions in COSE exa= ctly mirror those in JOSE. Some things can clearly be simplified for COSE,= and I'm all for that. I plan to consider each issue on its individual mer= its. That said, here's my review... MAJOR ISSUES 1. Representations should be optimized for the single recipient case. In JOSE, going into IESG review, "signatures" or "recipients" arrays were r= equired for the JSON Serializations, with only general multi-signature/mult= i-recipient representations being defined for JWS and JWE. Based on feedba= ck from numerous developers who were using JOSE for use cases that only eve= r used a single signature or recipient, Richard Barnes asked that the Flatt= ened serializations be added to optimize for the common single signature/re= cipient cases. Based on this developer feedback, we did this. Unless we do the same for COSE, I'm sure we'll receive the same feedback th= at requiring the "recipients" array in use cases where it will always conta= in one element is unnecessarily complicated. We should do this now. While the argument against this could be made that "it's even more complica= ted to support both the flattened and general serializations than just the = general one", I believe that in practice, this is a mostly specious argumen= t. Applications will choose or build an implementation that fits their use= case - either one that supports single or multiple recipients. Applicatio= n profiles will choose one or the other representation and will generally n= ot call for both. The way to achieve this is to define a flattened representation as JOSE did= , in which header parameters about both the payload and the recipient are c= arried in the top level "unprotected" and "protected" elements. 2. HMACs should be optimized for the no-key-management case. Particularly for constrained devices, it is unlikely that applications will= want to pay the performance penalty of generating and encrypting a key man= agement key to perform a MAC operation. Heck, they may not have credible r= andom number generation in the first place! And they are likewise unlikely= to want to pay the message size penalty of carrying the encrypted key. I'm fine with the optional ability to have key management for MACs, but the= default should be that no key management information is present in the rep= resentation. The only algorithm represented by default should be the MAC a= lgorithm - not even "dir" (direct). I suspect that this can be cleanly don= e by omitting the key management layer entirely when it's not used, rather = than explicitly using "dir" (direct). 3. Wrapped keys should be able to be represented as simply the wrapped key= value - not as an encrypted data structure with unnecessary information. Key management keys are by definition ephemeral and so no metadata needs to= be carried about them. Yes, the algorithm used to wrap the key needs to b= e represented, but this is already represented separately from the wrapped = key. A simple way to achieve this is to define an encrypted_key field to represe= nt the wrapped key, when appropriate for the algorithm. Among other benefi= ts, this will enable the use of the standard RFC 3394 AES Key Wrap algorith= ms, in the same way that JOSE uses "A128KW", etc. Note that if the working group chooses to, the ability to represent encrypt= ed keys as data structures can also be retained in parallel to this simpler= approach. Applications can then choose which method works best for them. 4. Simpler and more comprehensible examples are needed. I would include examples for the simplest and likely most common use cases: * HMAC without key management * Single signature * Encryption using AES Key Wrap for key management and AES GCM for c= ontent encryption Also, to be comprehensible to most readers, the examples need to include bo= th symbolic and numeric identifiers for all fields. Also, decoded represen= tations for encoded values need to be shown. For instance, the Direct MAC example in C.1 should be changed from beginnin= g like this: { 1: 3, 2: h'a10104', 4: h'546869732069732074686520636f6e74656e742e', 10: h'2ba937ca03d76c3dbad30cfcbaeef586f9c0f9ba616ad67e9205d3857 6ad9930', to beginning like this: { 1 (msg_type): 3 (MACed message), 2 (protected): h'a10104' (alg:HS256), 4 (payload): h'546869732069732074686520636f6e74656e742e', 10 (tag): h'2ba937ca03d76c3dbad30cfcbaeef586f9c0f9ba616ad67e9205d3857 6ad9930', MINOR ISSUES These issues are organized by section number, providing comments on the spe= c text in the order of appearance. 27 issues are described, labeled a, b, = c, ... aa. The section numbers and names in which they appear are included= in the write-up. 2. The COSE_MSG structure a. Change: Implementations MUST be prepared to find an integer under this label which does not correspond to the values 1 to 3. If this is found then the client MUST stop attempting to parse the structure and fail. to: Implementations MUST be prepared to find an integer under this label which does not correspond to the values 1 to 3. If this is found then the client MUST stop attempting to parse the structure and fail, unless it understands and implements the extension label value. b. This syntax needs more explanation: COSE_Tagged_MSG =3D #6.999(COSE_MSG) ; Replace 999 with TBD1 I assume that this is a use of http://tools.ietf.org/html/rfc7049#section-2= .4 (Optional Tagging of Items), but you should explicitly say that. c. Change: | ciphertext | 4 | TODO: Should we re-use the same as payload | | | | or not? | to: | ciphertext | 7 | For COSE_encrypt | It's cleaner not to reuse the same label value for different semantic meani= ngs. If we do that, we might come to regret it as the spec evolves. Besid= es, it's not like using another short integer value here will cause us to r= un out of them in this context. d. Change: These two buckets are available for use in all of the structures in this document except for keys. While these buckets can be present, they may not all be usable in all instances. to: These two buckets are defined for use in all of the structures in this document except for keys. While these buckets are defined, they may not be usable or used in all instances. The new text makes it clearer that "protected" and "unprotected" can't be i= ncluded where their values can't be used. 3.1. COSE Headers e. Change: The field is used to indicate which protected header keys an application which is processing a message is required to understand. to: The field is used to indicate which protected header keys defined by extensions to this specification that an application that is processing a message is required to understand. The language should make it clear that "crit" is only for defining behavior= of critical extensions - not for making header parameters defined by this = spec critical. f. In Table 2, change: | jku | * | tstr | | URL to COSE key object | | | | | | | | jwk | * | COSE_Key | | contains a COSE key not | | | | | | a JWK key | | | | | | | to: | jku | * | tstr | | URL to JWK [RFC 7517] | | | | | | | | cku | * | tstr | | URL to COSE key object | | | | | | | | ck | * | COSE_Key | | contains a COSE key | | | | | | | It still makes sense to be able to represent URLs to JWK and COSE Key objec= ts. But we shouldn't call the COSE Key passed by value "jwk", since that's= misleading. g. Open Issue 1. Which of the following items do we want to have stand= ardized in this document: jku, jwk, x5c, x5t, x5t#S256, x5u, zip? I would keep all of them, other than changing "jku" and "jwk" to "jku", "ck= u", and "ck" per (f) above. h. Open Issue 2. I am currently torn on the question "Should epk and iv/n= once be algorithm specific or generic headers?" I would define common labels for them since they are commonly used across m= ultiple algorithms. 4. Signing Structure i. The description of "protected" says "The field MUST NOT hold attributes= about the payload being signed". Assuming that a flattened syntax is adde= d, this would then become something like "The field MUST NOT hold attribute= s about the payload being signed unless the flattened serialization is bein= g used". Other related statements throughout the document would likewise n= eed to be similarly updated. j. The end of the signing section says: In addition to performing the signature verification, one must also perform the appropriate checks to ensure that the key is correctly paired with the signing identity and that the appropriate authorization is done. There needs to be a reference to a place where the process of verifying the= key's association with the signing identity is described. Particular meth= ods are clearly beyond the scope of this specification but saying this litt= le about the process will likely just leave many people confused. 5. Encryption Object k. The introduction to this section says: In this section we describe the structure and methods to be used when doing an encryption in COSE. In COSE, we use the same techniques and structures for encrypting both the plain text and the keys used to protect the text. This is different from the approach used by both [RFC5652] and [RFC7516] where different structures are used for the plain text and for the different key management techniques. I'll note that if issue 3 is resolved (Wrapped keys should be able to be re= presented as simply the wrapped key value), this paragraph will have to be = revised accordingly. l. A generic "iv" (initialization vector) field should also be defined in = the list of parameters for the encryption object. Yes, not all algorithms = will use it, but many will. m. A "tag" (authentication tag) field should be defined in the list of par= ameters for the encryption object. Yes, not all the algorithms will use it= , but many will. 5.1.1. Direct Encryption n. The spec says: o At a minimum, the 'unprotected' field MUST contain the 'alg' parameter and SHOULD contain a parameter identifying the shared secret. SHOULD is too strong here because in some protocols, the shared secret will= already be known by methods other than an included "kid" or other key sele= ction value. A "SHOULD ... unless ..." construct like was used in similar = JOSE descriptions is probably the right thing to use here. 6. MAC Objects o. The "How to compute a MAC" instructions say: 5. Encrypt and encode the MAC key for each recipient of the message. This is not correct when direct key management or no key management is used= . Please revise to accurately include these cases as well. 7. Key Structure p. The spec says: The "key_ops" element is preferred over the "use" element as the information provided that way is more finely detailed about the operations allowed. It is strongly suggested that this element be present for all keys. Like in (n), the application may know the key usage from application contex= t, rendering the inclusion of "key_ops" unnecessary. Language something li= ke "It is strongly suggested that this element be present for all keys unle= ss this information is already know to the application through other means"= should be used to capture this. The working group should also discuss whether it wants to carry forward "us= e" for JWK compatibility, even if it is deprecated. I personally would be = in favor of doing so. q. I would define short numeric values that correspond to the defines "key= _ops" string values. I'd do the same for the "use" values. 8. CBOR Encoder Restrictions r. The spec says: o All parsers used SHOULD fail on both parsing and generation if the same label is used twice as a key for the same map. I would strongly prefer that the "SHOULD" be changed to "MUST". CBOR doesn= 't have the same legacy of lax parsers that we inherited from JavaScript/EC= MAscript for JSON. Let's not open the door to them! 9.5 COSE Algorithm Registry s. I would add an additional "JOSE algorithm name" field to this registry,= whose value is the corresponding "Algorithm Name" entry in the IANA JSON W= eb Signature and Encryption Algorithms registry at http://www.iana.org/assi= gnments/jose/jose.xhtml#web-signature-encryption-algorithms, if such an ent= ry exists. This will tie the two registries together so that definitions o= f algorithms already defined by JOSE need not be repeated for COSE. In many cases then, the COSE algorithms draft (or section) can just cite th= e definition in RFC 7518 and register the corresponding short numeric label= for COSE use. 9.8.1 COSE Security Message t. Besides registering the MIME type "application/cose", I would also regi= ster one for a base64url encoded COSE message - an idea first described to = me by Joe Hildebrand. It could be called "application/cose+base64url" or s= omething of that ilk. 9.8.2 COSE Key Media Type u. "application/jwk+json" should be changed to something like "application= /cose-key" and "application/jwk-set+json" should be changed to something li= ke "application/cose-key-set". 11.2. Informative References v. The date on the AES-GCM reference (SP 800-38D) should be November 2007 = - not June 2015. Appendix A. AEAD and AE Algorithms w. The spec says: This authentication value may be: o A separately generated tag computed by both the encrypter and decrypter and then compared by the decryptor. This tag value may be either placed at the end of the cipher text (the decision we made) or kept separately (the decision made by the JOSE working group). This is the approach followed by AES-GCM [AES-GCM] and AES-CCM [RFC3610]. The last sentence is not true, as written. The AES-GCM spec describes "the= ciphertext and tag outputs" - not a single combined output. Common implem= entations correspond to this, such as the implementation of GCM in .NET. The CCM description in RFC 3610 Section 2.4 describes the output using the = text "The final result c consists of the encrypted message followed by the = encrypted authentication value U", which admits either implementation. Lik= ewise, at least the .NET CCM implementation produces separate ciphertext an= d authentication tag values. Whether the tag should be separate or automatically appended to the ciphert= ext isn't a hill I'm going to die on (although the working group should dis= cuss this and make an explicit decision in this regard), but the text descr= ibing the decision should at least be changed to be accurate. Appendix C. Examples x. The uses of strings and corresponding labels such as those that follow = are confusing - especially since key ID values are binary in COSE. A fragm= ent of such an example that confused me was: 3: { 5: "bilbo.baggins@hobbiton.example" }, There are similar strings in some of the other examples that I also couldn'= t wrap my head around. Appendix D. COSE Header Algorithm Label Table y. I would change the term "Header Algorithm" to "Header Parameter". (I s= uspect this was a cut-and-paste error.) z. In Appendix D and Appendix E, I would call out that the names in the "n= ame" columns correspond to names defined in RFC 7518. Appendix F. COSE General Values aa. This seems confused, as it mixes "kty" values (EC=3D1, RSA=3D2, oct=3D= 3) with curve values (P256=3D4, P521=3D5). I would keep these separate. A= lso, wherever the curve names are defined, I would also include P384, as JO= SE did. NITS I will be submitting spelling and grammar corrections as a GitHub pull requ= est against the spec repository rather than detail them here. I'll post th= e pull request link once it's been created. CONCLUSIONS I'd like to thank Jim for doing the work to produce a well-thought-out init= ial draft. I believe it provides a solid starting point for the COSE work. I'd be willing to produce specific proposed edits for any/all of the above = issues and comments, should the editors find that useful. Best wishes, -- Mike --_000_BY2PR03MB442E3A163870ADE7AAABCF5F5AC0BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In response to the call for adoption, I’m subm= itting the following review feedback on draft-schaa= d-cose-msg-01.  Most of the major comments are motivated by the go= al of “keeping simple things simple”.  Particularly in con= strained environments, it’s likely to be normal for implementations to use only the parts of COSE they their application needs.  I believ= e that we should therefore optimize the representations we define for the c= ommon cases, while making it possible to also gracefully accommodate less c= ommon, if possibly more general cases as well.

 

Also, given my role as a designer and editor of the = JOSE specs, I’ll say explicitly that it’s not my goal to try to= have all the decisions in COSE exactly mirror those in JOSE.  Some th= ings can clearly be simplified for COSE, and I’m all for that.  I plan to consider each issue on its individual merits.&nb= sp; That said, here’s my review…

 

MAJOR ISSUES

 

1.  Representations should be optimized for = the single recipient case.

 

In JOSE, going into IESG review, “signatures&#= 8221; or “recipients” arrays were required for the JSON Seriali= zations, with only general multi-signature/multi-recipient representations = being defined for JWS and JWE.  Based on feedback from numerous developers who were using JOSE for use cases that only ever used a single = signature or recipient, Richard Barnes asked that the Flattened serializati= ons be added to optimize for the common single signature/recipient cases.&n= bsp; Based on this developer feedback, we did this.

 

Unless we do the same for COSE, I’m sure we= 217;ll receive the same feedback that requiring the “recipients”= ; array in use cases where it will always contain one element is unnecessar= ily complicated.  We should do this now.

 

While the argument against this could be made that &= #8220;it’s even more complicated to support both the flattened and ge= neral serializations than just the general one”, I believe that in pr= actice, this is a mostly specious argument.  Applications will choose or build an implementation that fits their use case – ei= ther one that supports single or multiple recipients.  Application pro= files will choose one or the other representation and will generally not ca= ll for both.

 

The way to achieve this is to define a flattened rep= resentation as JOSE did, in which header parameters about both the payload = and the recipient are carried in the top level “unprotected” an= d “protected” elements.

 

2.  HMACs should be optimized for the no-key= -management case.

 

Particularly for constrained devices, it is unlikely= that applications will want to pay the performance penalty of generating a= nd encrypting a key management key to perform a MAC operation.  Heck, = they may not have credible random number generation in the first place!  And they are likewise unlikely to wan= t to pay the message size penalty of carrying the encrypted key.=

 

I’m fine with the optional ability to have key= management for MACs, but the default should be that no key management info= rmation is present in the representation.  The only algorithm represen= ted by default should be the MAC algorithm – not even “dir” (direct).  I suspect that this can be clea= nly done by omitting the key management layer entirely when it’s not = used, rather than explicitly using “dir” (direct).

 

3.  Wrapped keys should be able to be repres= ented as simply the wrapped key value – not as an encrypted data stru= cture with unnecessary information.

 

Key management keys are by definition ephemeral and = so no metadata needs to be carried about them.  Yes, the algorithm use= d to wrap the key needs to be represented, but this is already represented = separately from the wrapped key.

 

A simple way to achieve this is to define an encrypt= ed_key field to represent the wrapped key, when appropriate for the algorit= hm.  Among other benefits, this will enable the use of the standard RF= C 3394 AES Key Wrap algorithms, in the same way that JOSE uses “A128KW”, etc.

 

Note that if the working group chooses to, the abili= ty to represent encrypted keys as data structures can also be retained in p= arallel to this simpler approach.  Applications can then choose which = method works best for them.

 

4.  Simpler and more comprehensible examples= are needed.

 

I would include examples for the simplest and likely= most common use cases:

·        HMAC without key management

·        Single signature

·        Encryption using AES Key Wrap for key manage= ment and AES GCM for content encryption

 

Also, to be comprehensible to most readers, the exam= ples need to include both symbolic and numeric identifiers for all fields.&= nbsp; Also, decoded representations for encoded values need to be shown.

 

For instance, the Direct MAC example in C.1 should b= e changed from beginning like this:

 

   {

     1: 3,

     2: h'a10104',

     4: h'5468697320697320746865= 20636f6e74656e742e',

     10: h'2ba937ca03d76c3dbad30= cfcbaeef586f9c0f9ba616ad67e9205d3857

   6ad9930',

 

to beginning like this:

 

   {

     1 (msg_type): 3 (MACed mess= age),

     2 (protected): h'a10104' (a= lg:HS256),

     4 (payload): h'546869732069= 732074686520636f6e74656e742e',

     10 (tag): h'2ba937ca03d76c3= dbad30cfcbaeef586f9c0f9ba616ad67e9205d3857

   6ad9930',

 

MINOR ISSUES

 

These issues are organized by section number, provid= ing comments on the spec text in the order of appearance.  27 issues a= re described, labeled a, b, c, … aa.  The section numbers and na= mes in which they appear are included in the write-up.

 

2.  The COSE_MSG structure

 

a.  Change:

=    Implementations MUST be prepared to find an integer under this= label

=    which does not correspond to the values 1 to 3.  If this = is found

=    then the client MUST stop attempting to parse the structure an= d fail.

to:

=    Implementations MUST be prepared to find an integer under this= label

=    which does not correspond to the values 1 to 3.  If this = is found

=    then the client MUST stop attempting to parse the structure an= d fail,

=    unless it understands and implements the extension label value= .

 

b.  This syntax needs more explanation:

   COSE_Tagged_MSG =3D #6.999(COSE_MSG)&nb= sp;  ; Replace 999 with TBD1

 

I assume that this is a use of http://tools.ietf.org/html/rfc7049#section-2.4 (Optional Tagging of Ite= ms), but you should explicitly say that.

 

c.  Change:

=    | ciphertext  | 4      | TODO: S= hould we re-use the same as payload |

=    |          &= nbsp;  |        | or not? &nbs= p;            &= nbsp;           &nbs= p;         |

to:

=    | ciphertext  | 7      | For COS= E_encrypt           =             &nb= sp;   |

 

It’s cleaner not to reuse the same label value= for different semantic meanings.  If we do that, we might come to reg= ret it as the spec evolves.  Besides, it’s not like using anothe= r short integer value here will cause us to run out of them in this context.

 

d.  Change:

=   These two buckets

=    are available for use in all of the structures in this documen= t

=    except for keys.  While these buckets can be present, the= y may not

=    all be usable in all instances.

to:

=   These two buckets

=    are defined for use in all of the structures in this document<= o:p>

=    except for keys.  While these buckets are defined, they m= ay not

=    be usable or used in all instances.

=  

The new text makes it clearer that “protected&= #8221; and “unprotected” can’t be included where their va= lues can’t be used.

 

3.1.  COSE Headers

 

e.  Change:

=   The field is used to indicate which protected header keys=

=       an application which is processing a message= is required to

=       understand.

to:

=   The field is used to indicate which protected header keys=

=       defined by extensions to this specification = that

=       an application that is processing a message = is required to

=       understand.

 

The language should make it clear that “crit&#= 8221; is only for defining behavior of critical extensions – not for = making header parameters defined by this spec critical.

 

f.  In Table 2, change:

=    | jku      | *    = ; | tstr     |       = ;    | URL to COSE key object  |

=    |          | = ;      |       =    |           = |            &n= bsp;            |

=    | jwk      | *    = ; | COSE_Key |           = | contains a COSE key not |

=    |          | = ;      |       =    |           = | a JWK key          &nbs= p;    |

=    |          | = ;      |       =    |           = |            &n= bsp;            |

to:

=    | jku      | *    = ; | tstr     |       = ;    | URL to JWK [RFC 7517]   |=

=    |          | = ;      |       =    |           = |            &n= bsp;            |

=   | cku      | *    = | tstr     |       =     | URL to COSE key object  |

=    |          | = ;      |       =    |           = |            &n= bsp;            |

=    | ck       | *   =   | COSE_Key |         &n= bsp; | contains a COSE key     |

=    |          | = ;      |       =    |           = |            &n= bsp;            |

 

It still makes sense to be able to represent URLs to= JWK and COSE Key objects.  But we shouldn’t call the COSE Key p= assed by value “jwk”, since that’s misleading.=

 

g.     Open Issue 1.  Which= of the following items do we want to have standardized in

       this document: = jku, jwk, x5c, x5t, x5t#S256, x5u, zip?

 

I would keep all of them, other than changing “= ;jku” and “jwk” to “jku”, “cku”, = and “ck” per (f) above.

 

h.  Open Issue 2.  I am currently torn on = the question "Should epk and iv/nonce be

       algorithm speci= fic or generic headers?"

 

I would define common labels for them since they are= commonly used across multiple algorithms.

 

4.  Signing Structure

 

i.  The description of “protected” = says “The field MUST NOT hold attributes about the payload being sign= ed”.  Assuming that a flattened syntax is added, this would then= become something like “The field MUST NOT hold attributes about the payload being signed unless the flattened serialization is being used̶= 1;.  Other related statements throughout the document would likewise n= eed to be similarly updated.

 

j.  The end of the signing section says:

=    In addition to performing the signature verification, one must= also

=    perform the appropriate checks to ensure that the key is corre= ctly

=    paired with the signing identity and that the appropriate=

=    authorization is done.

 

There needs to be a reference to a place where the p= rocess of verifying the key’s association with the signing identity i= s described.  Particular methods are clearly beyond the scope of this = specification but saying this little about the process will likely just leave many people confused.

 

5.  Encryption Object

 

k.  The introduction to this section says:=

=    In this section we describe the structure and methods to be us= ed when

=    doing an encryption in COSE.  In COSE, we use the same te= chniques and

=    structures for encrypting both the plain text and the keys use= d to

=   protect the text.  This is different from the approach use= d by both

=    [RFC5652] and [RFC7516] where different structures are used fo= r the

=    plain text and for the different key management techniques.

 

I’ll note that if issue 3 is resolved (Wrap= ped keys should be able to be represented as simply the wrapped key value), this paragraph will have to be revised accordingly.

 

l.  A generic “iv” (initialization = vector) field should also be defined in the list of parameters for the encr= yption object.  Yes, not all algorithms will use it, but many will.

 

m.  A “tag” (authentication tag) fi= eld should be defined in the list of parameters for the encryption object.&= nbsp; Yes, not all the algorithms will use it, but many will.

 

5.1.1.  Direct Encryption

 

n.  The spec says:

=    o  At a minimum, the 'unprotected' field MUST contain the= 'alg'

=       parameter and SHOULD contain a parameter ide= ntifying the shared

=       secret.

 

SHOULD is too strong here because in some protocols,= the shared secret will already be known by methods other than an included = “kid” or other key selection value.  A “SHOULD ̷= 0; unless …” construct like was used in similar JOSE descriptio= ns is probably the right thing to use here.

 

6.  MAC Objects

 

o.  The “How to compute a MAC” inst= ructions say:

=    5.  Encrypt and encode the MAC key for each recipient of = the message.

 

This is not correct when direct key management or no= key management is used.  Please revise to accurately include these ca= ses as well.

 

7.  Key Structure

 

p.  The spec says:

=    The "key_ops" element is preferred over the "us= e" element as the

=    information provided that way is more finely detailed about th= e

=    operations allowed.  It is strongly suggested that this e= lement be

=    present for all keys.

 

Like in (n), the application may know the key usage = from application context, rendering the inclusion of “key_ops” = unnecessary.  Language something like “It is strongly suggested = that this element be present for all keys unless this information is already know to the application through other means” should be us= ed to capture this.

 

The working group should also discuss whether it wan= ts to carry forward “use” for JWK compatibility, even if it is = deprecated.  I personally would be in favor of doing so.

 

q.  I would define short numeric values that co= rrespond to the defines “key_ops” string values.  I’= d do the same for the “use” values.

 

8.  CBOR Encoder Restrictions

 

r.  The spec says:

=    o  All parsers used SHOULD fail on both parsing and gener= ation if the

=       same label is used twice as a key for the sa= me map.

 

I would strongly prefer that the “SHOULD”= ; be changed to “MUST”.  CBOR doesn’t have the same = legacy of lax parsers that we inherited from JavaScript/ECMAscript for JSON= .  Let’s not open the door to them!

 

9.5  COSE Algorithm Registry

 

s.  I would add an additional “JOSE algor= ithm name” field to this registry, whose value is the corresponding &= #8220;Algorithm Name” entry in the IANA JSON Web Signature and Encryp= tion Algorithms registry at http://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-al= gorithms, if such an entry exists.  This will tie the two registri= es together so that definitions of algorithms already defined by JOSE need = not be repeated for COSE.

 

In many cases then, the COSE algorithms draft (or se= ction) can just cite the definition in RFC 7518 and register the correspond= ing short numeric label for COSE use.

 

9.8.1  COSE Security Message

 

t.  Besides registering the MIME type “ap= plication/cose”, I would also register one for a base64url encoded CO= SE message – an idea first described to me by Joe Hildebrand.  I= t could be called “application/cose+base64url” or something= of that ilk.

 

9.8.2  COSE Key Media Type

 

u.  “application/jwk+json” shou= ld be changed to something like “application/cose-key” and R= 20;application/jwk-set+json” should be changed to something like = “application/cose-key-set”.

 

11.2.  Informative References

 

v.  The date on the AES-GCM reference (SP 800-3= 8D) should be November 2007 – not June 2015.

 

Appendix A.  AEAD and AE Algorithms<= /p>

 

w.  The spec says:

=   This authentication value may be:

=    o  A separately generated tag computed by both the encryp= ter and

=       decrypter and then compared by the decryptor= .  This tag value may

=       be either placed at the end of the cipher te= xt (the decision we

=       made) or kept separately (the decision made = by the JOSE working

=       group).  This is the approach followed = by AES-GCM [AES-GCM] and

=       AES-CCM [RFC3610].

 

The last sentence is not true, as written.  The= AES-GCM spec describes “the ciphert= ext and tag outputs” – not a single combined output.&nbs= p; Common implementations correspond to this, such as the implementation of GCM in .NET.

 

The CCM description in RFC 3610 Section 2.4 describe= s the output using the text “The final result c consists of the encry= pted message followed by the encrypted authentication value U”, which= admits either implementation.  Likewise, at least the .NET CCM implementation produces separate ciphertext and authenticatio= n tag values.

 

Whether the tag should be separate or automatically = appended to the ciphertext isn’t a hill I’m going to die on (al= though the working group should discuss this and make an explicit decision = in this regard), but the text describing the decision should at least be changed to be accurate.

 

Appendix C.  Examples

 

x.  The uses of strings and corresponding label= s such as those that follow are confusing – especially since key ID v= alues are binary in COSE.  A fragment of such an example that confused= me was:

=          3: {

=            5: "bilbo= .baggins@hobbiton.example"

=          },

 

There are similar strings in some of the other examp= les that I also couldn’t wrap my head around.

 

Appendix D.  COSE Header Algorithm Label Table<= o:p>

 

y.  I would change the term “Header Algor= ithm” to “Header Parameter”.  (I suspect this was a = cut-and-paste error.)

 

z.  In Appendix D and Appendix E, I would call = out that the names in the “name” columns correspond to names de= fined in RFC 7518.

 

Appendix F.  COSE General Values

 

aa.  This seems confused, as it mixes “kt= y” values (EC=3D1, RSA=3D2, oct=3D3) with curve values (P256=3D4, P52= 1=3D5).  I would keep these separate.  Also, wherever the curve n= ames are defined, I would also include P384, as JOSE did.

 

NITS

 

I will be submitting spelling and grammar correction= s as a GitHub pull request against the spec repository rather than detail t= hem here.  I’ll post the pull request link once it’s been = created.

 

CONCLUSIONS

 

I’d like to thank Jim for doing the work to pr= oduce a well-thought-out initial draft.  I believe it provides a solid= starting point for the COSE work.

 

I’d be willing to produce specific proposed ed= its for any/all of the above issues and comments, should the editors find t= hat useful.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; Best wishes,

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

 

--_000_BY2PR03MB442E3A163870ADE7AAABCF5F5AC0BY2PR03MB442namprd_-- From nobody Sat Jun 27 02:09:59 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78191B32CE for ; Sat, 27 Jun 2015 02:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 mE4zO6Os5TcJ for ; Sat, 27 Jun 2015 02:09:57 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0709.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:709]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875731B32CD for ; Sat, 27 Jun 2015 02:09:56 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.201.16; Sat, 27 Jun 2015 09:09:13 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0201.000; Sat, 27 Jun 2015 09:09:01 +0000 From: Mike Jones To: Justin Richer , "cose@ietf.org" Thread-Topic: [Cose] Consensus Call on Input Draft Adoption Thread-Index: AQHQsH+jI1Lh4E4r+Eewkm+/ikiPyZ3AEDhQ Date: Sat, 27 Jun 2015 09:09:01 +0000 Message-ID: References: <1B462EEC-67AF-4F19-B8F5-82BA36C59C8D@mit.edu> In-Reply-To: <1B462EEC-67AF-4F19-B8F5-82BA36C59C8D@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: MIT.EDU; dkim=none (message not signed) header.d=none; x-originating-ip: [50.47.90.173] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:C3j5UrRlRNU0mdd3AHKT1SEONbx6tohWzla+EcQS1Xd4BO13w+BQW4sZDtV/r/jyMxVcXEzWj9I2utWt8MzkgphuWMRDQyH+CNJ5x/2xFJ2cgJpVwrRIpoOry7RCL1RPS1NX1bNvcR/bPniuBZlYQQ==; 24:uXDxrUl7m83SKsGf0NicltJHa01TSOd2P5AtRQEedEaszTMkThh3QkAxDIeSO8E6JOcrOlRutdKq1QssEr5la+sRX8eRz+Rxz1978SJlmm8=; 20:gFVVs0TWkqOiBDaTfCKIkvV77H8AmD/rLo0h3d0CptH9wuC+w8MhxETntAMKtfEzdnnxuJWufT1bxmG51EtvyQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 0620CADDF3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(377454003)(86612001)(122556002)(77156002)(19609705001)(19580395003)(46102003)(87936001)(2656002)(19580405001)(74316001)(33656002)(16236675004)(86362001)(92566002)(5003600100002)(19625215002)(19617315012)(2171001)(99286002)(106116001)(54356999)(76176999)(50986999)(107886002)(19300405004)(40100003)(102836002)(2501003)(5001770100001)(5002640100001)(110136002)(76576001)(64706001)(189998001)(66066001)(5001960100002)(77096005)(15975445007)(2900100001)(62966003)(2950100001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442A62DC4F14ACD77C38C18F5AC0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2015 09:09:01.1178 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Subject: Re: [Cose] Consensus Call on Input Draft Adoption X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 09:09:58 -0000 --_000_BY2PR03MB442A62DC4F14ACD77C38C18F5AC0BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TGV0IG1lIGJlIHRoZSBmaXJzdCB0byBzYXkgdGhhdCBJIGFwcHJvdmUgb2YgYWRvcHRpbmcgdGhp cyBkb2N1bWVudCBhcyBhIHdvcmtpbmcgZ3JvdXAgZHJhZnQuICBJ4oCZZCBsaWtlIHRvIHRoYW5r IEppbSBmb3IgZG9pbmcgdGhlIHdvcmsgdG8gcHJvZHVjZSBhIHdlbGwtdGhvdWdodC1vdXQgaW5p dGlhbCBkcmFmdC4gIEkgYmVsaWV2ZSBpdCBwcm92aWRlcyBhIHNvbGlkIHN0YXJ0aW5nIHBvaW50 IGZvciB0aGUgQ09TRSB3b3JrLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBCZXN0IHdpc2hlcywNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJv bTogQ29zZSBbbWFpbHRvOmNvc2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEp1c3Rp biBSaWNoZXINClNlbnQ6IEZyaWRheSwgSnVuZSAyNiwgMjAxNSA3OjE5IFBNDQpUbzogY29zZUBp ZXRmLm9yZw0KU3ViamVjdDogW0Nvc2VdIENvbnNlbnN1cyBDYWxsIG9uIElucHV0IERyYWZ0IEFk b3B0aW9uDQoNClRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBtYWtlIGEgY29uc2Vuc3VzIGNhbGwg b24gYWNjZXB0aW5nIHRoZSBmb2xsb3dpbmcgZG9jdW1lbnQgYXMgdGhlIGlucHV0IGRyYWZ0IGZv ciBhIG5ldyB3b3JraW5nIGdyb3VwIGl0ZW06DQoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXNjaGFhZC1jb3NlLW1zZy0wMQ0KDQoNClRoaXMgZG9jdW1lbnQsIGlmIGFjY2Vw dGVkLCB3aWxsIGJlY29tZSB0aGUgYmFzaXMgb2YgdGhlIENPU0UgbWVzc2FnZSBzeW50YXggc3Bl Y2lmaWNhdGlvbi4NCg0KUGxlYXNlIHJlcGx5IHRvIHRoaXMgdGhyZWFkIHdoZXRoZXIgb3Igbm90 IHlvdSB3b3VsZCBsaWtlIHRvIGFjY2VwdCB0aGlzIGRvY3VtZW50IGFzIGlucHV0IHRvIHRoZSB3 b3JraW5nIGdyb3VwLg0KDQpUaGFuayB5b3UsDQog4oCUIEp1c3RpbiAoJiBLZXBlbmcpDQo= --_000_BY2PR03MB442A62DC4F14ACD77C38C18F5AC0BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkxldCBtZSBiZSB0aGUgZmlyc3QgdG8gc2F5IHRoYXQgSSBhcHByb3Zl IG9mIGFkb3B0aW5nIHRoaXMgZG9jdW1lbnQgYXMgYSB3b3JraW5nIGdyb3VwIGRyYWZ0LiZuYnNw OyBJ4oCZZCBsaWtlIHRvIHRoYW5rIEppbSBmb3IgZG9pbmcgdGhlIHdvcmsgdG8gcHJvZHVjZSBh IHdlbGwtdGhvdWdodC1vdXQNCiBpbml0aWFsIGRyYWZ0LiZuYnNwOyBJIGJlbGlldmUgaXQgcHJv dmlkZXMgYSBzb2xpZCBzdGFydGluZyBwb2ludCBmb3IgdGhlIENPU0Ugd29yay48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBCZXN0IHdpc2hlcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBDb3NlIFttYWlsdG86Y29z ZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4gUmljaGVyPGJy Pg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSnVuZSAyNiwgMjAxNSA3OjE5IFBNPGJyPg0KPGI+VG86 PC9iPiBjb3NlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtDb3NlXSBDb25zZW5zdXMg Q2FsbCBvbiBJbnB1dCBEcmFmdCBBZG9wdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBtYWtlIGEgY29uc2Vu c3VzIGNhbGwgb24gYWNjZXB0aW5nIHRoZSBmb2xsb3dpbmcgZG9jdW1lbnQgYXMgdGhlIGlucHV0 IGRyYWZ0IGZvciBhIG5ldyB3b3JraW5nIGdyb3VwIGl0ZW06PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1zY2hhYWQtY29zZS1tc2ctMDEiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1zY2hhYWQtY29zZS1tc2ctMDE8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBkb2N1bWVudCwgaWYgYWNjZXB0 ZWQsIHdpbGwgYmVjb21lIHRoZSBiYXNpcyBvZiB0aGUgQ09TRSBtZXNzYWdlIHN5bnRheCBzcGVj aWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5QbGVhc2UgcmVwbHkgdG8gdGhpcyB0aHJlYWQgd2hldGhlciBvciBub3QgeW91IHdv dWxkIGxpa2UgdG8gYWNjZXB0IHRoaXMgZG9jdW1lbnQgYXMgaW5wdXQgdG8gdGhlIHdvcmtpbmcg Z3JvdXAuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoYW5rIHlvdSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwO+KAlCBKdXN0aW4gKCZhbXA7IEtlcGVuZyk8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BY2PR03MB442A62DC4F14ACD77C38C18F5AC0BY2PR03MB442namprd_-- From nobody Sat Jun 27 03:53:36 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7929C1AC3CB; Sat, 27 Jun 2015 03:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=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 634rlL_i3j3K; Sat, 27 Jun 2015 03:53:30 -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 C45AA1AC428; Sat, 27 Jun 2015 03:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t5RArISQ024756; Sat, 27 Jun 2015 12:53:18 +0200 (CEST) Received: from alma.local (p5DC7EA60.dip0.t-ipconnect.de [93.199.234.96]) (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 3mJX4G3DZbz9905; Sat, 27 Jun 2015 12:53:18 +0200 (CEST) Message-ID: <558E809C.5020409@tzi.org> Date: Sat, 27 Jun 2015 12:53:16 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: dtls-iot@ietf.org, core@ietf.org, ace@ietf.org, cose@ietf.org, t2trg@irtf.org X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Cose] Constrained Node/Network Cluster @ IETF93, "final" version X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 10:53:31 -0000 Below is the "final" version of the eclectic IoT agenda (I have filled in the T2TRG Sat/Sun meeting, which is waiting for its room assignment). Again, there is still some potential for changes. Apart from a dozen room changes, the main difference from the early version is that the second 6lo and 6tisch meetings were swapped. Grüße, Carsten Carsten Bormann wrote: > A first draft version of the IETF93 agenda is out. > ** THIS IS GOING TO CHANGE ** for conflict resolution, > so please don't make travel arrangements based on it. > > Here is my usual eclectic condensed agenda built from that. > (Bye, bye, appsawg. lwig over roll is interesting; at least we do > have a roll meeting at all.) > Note that the t2trg meeting on Monday is a "summary" meeting for those > who haven't been able to join during the weekend (conflicts with > Hackathon, ICNRG, etc.) > > All times are CEST (UTC+0200) (the browser timezone function appears > to have vanished from https://datatracker.ietf.org/meeting/agenda-utc, > but maybe we can reinstate that for those who want to listen from > remote). > > Sorry for the duplicate posting, the IETF mail system does not allow > sending to all 9 mailing lists at the same time. SATURDAY, July 18, 2015 1000-1800 Session I (TBD) IRTF*** t2trg Proposed Thing-to-thing Research Group 0900-2100 IETF Hackathon - Chez Louis SUNDAY, July 19, 2015 0900-1600 Session II (TBD) IRTF*** t2trg Proposed Thing-to-thing Research Group 0900-1800 IETF Hackathon - Chez Louis 1600-1700 Newcomers' Meet and Greet (open to Newcomers and WG chairs only) - Garden Terrace 1700-1900 Welcome Reception - Grand Hilton Ballroom MONDAY, July 20, 2015 0900-1130 Morning Session I Grand Hilton BR ART appsawg ART Area General Applications Working Group WG Karlin I/II OPS anima Autonomic Networking Integrated Model and Approach WG Berlin/Brussels SEC *** cose CBOR Object Signing and Encryption WG - 10:00 - 11:30 Congress H II TSV rmcat RTP Media Congestion Avoidance Techniques WG 1300-1500 Afternoon Session I Congress H III INT 6man IPv6 Maintenance WG Grand Hilton BR RTG detnet Deterministic Networking BOF 1520-1720 Afternoon Session II Berlin/Brussels IRTF*** t2trg Proposed Thing-to-Thing Research Group Congress H III TSV tcpinc TCP Increased Security WG 1740-1840 Afternoon Session III Congress H II INT *** 6lo IPv6 over Networks of Resource-constrained Nodes WG Congress H I OPS opsarea Operations & Management Area Open Meeting Karlin I/II SEC httpauth Hypertext Transfer Protocol Authentication WG 1850-1950 Afternoon Session IV Congress H III INT intarea Internet Area Working Group WG TUESDAY, July 21, 2015 1300-1500 Afternoon Session I Congress H I ART httpbis Hypertext Transfer Protocol WG Athens/Barcel. INT *** 6tisch IPv6 over the TSCH mode of IEEE 802.15.4e WG Congress H II OPS v6ops IPv6 Operations WG - Joint Session with SUNSET4 1520-1720 Afternoon Session II Karlin I/II ART *** core Constrained RESTful Environments WG Congress H II RTG rtgarea Routing Area Open Meeting Congress H III SEC tls Transport Layer Security WG 1740-1840 Afternoon Session III Congress H III ART uta Using TLS in Applications WG Berlin/Brussels INT *** lwig Light-Weight Implementation Guidance WG Congress H I RTG *** roll Routing Over Low power and Lossy networks WG WEDNESDAY, July 22, 2015 0900-1130 Morning Session I Athens/Barcel. INT dnssd Extensions for Scalable DNS Service Discovery WG Karlin I/II SEC *** ace Authentication and Authorization for Constrained Environments WG Grand Hilton BR SEC tls Transport Layer Security WG 1300-1530 Afternoon Session I Grand Hilton BR INT homenet Home Networking WG Berlin/Brussels RTG bier Bit Indexed Explicit Replication WG 1740-1940 Afternoon Session III Athens/Barcel. SEC oauth Web Authorization Protocol WG Congress H III TSV tsvwg Transport Area Working Group WG THURSDAY, July 23, 2015 1300-1500 Afternoon Session I Congress H II SEC saag Security Area Open Meeting Karlin I/II TSV taps Transport Services WG 1520-1720 Afternoon Session II Congress H I INT *** 6lo IPv6 over Networks of Resource-constrained Nodes WG Congress H III SEC acme Automated Certificate Management Environment WG Karlin I/II TSV tsvwg Transport Area Working Group WG 1740-1910 Afternoon Session III Karlin I/II ART webpush Web-Based Push Notifications WG Congress H I OPS anima Autonomic Networking Integrated Model and Approach WG Grand Hilton BR TSV tsvarea Transport Area Open Meeting FRIDAY, July 24, 2015 0900-1130 Morning Session I Grand Hilton BR OPS v6ops IPv6 Operations WG - Joint Session with SUNSET4 Congress H I SEC openpgp Open Specification for Pretty Good Privacy WG 1150-1320 Afternoon Session I Karlin I/II ART *** core Constrained RESTful Environments WG Congress H I SEC tokbind Token Binding WG From nobody Sat Jun 27 04:06:15 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9DF1AC417 for ; Sat, 27 Jun 2015 04:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=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 ZA9EWomtQ_fZ for ; Sat, 27 Jun 2015 04:06:14 -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 F01BA1AC3CB for ; Sat, 27 Jun 2015 04:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t5RB6BWa025042 for ; Sat, 27 Jun 2015 13:06:11 +0200 (CEST) Received: from alma.local (p5DC7EA60.dip0.t-ipconnect.de [93.199.234.96]) (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 3mJXM749ycz992g; Sat, 27 Jun 2015 13:06:11 +0200 (CEST) Message-ID: <558E83A1.6070804@tzi.org> Date: Sat, 27 Jun 2015 13:06:09 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: "cose@ietf.org" References: <1B462EEC-67AF-4F19-B8F5-82BA36C59C8D@mit.edu> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Cose] Consensus Call on Input Draft Adoption X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 11:06:15 -0000 Mike Jones wrote: > Let me be the first to say that I approve of adopting this document as a > working group draft. I’d like to thank Jim for doing the work to > produce a well-thought-out initial draft. I believe it provides a solid > starting point for the COSE work. +1. I hope the chairs can declare consensus on this well before the looming I-D deadline (2015-07-06), so we can go into the Prague meeting with a draft-ietf-cose-.... Grüße, Carsten From nobody Sat Jun 27 07:45:45 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A69F1ACE70 for ; Sat, 27 Jun 2015 07:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.452 X-Spam-Level: X-Spam-Status: No, score=0.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 1puGjIsj9dQR for ; Sat, 27 Jun 2015 07:45:41 -0700 (PDT) Received: from out4133-34.mail.aliyun.com (out4133-34.mail.aliyun.com [42.120.133.34]) by ietfa.amsl.com (Postfix) with ESMTP id AA1921ACF07 for ; Sat, 27 Jun 2015 07:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1435416337; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=P6ZPjgYTJ6TO3VzznQFJzzVDf3ysJkamMIjUuX7fpjA=; b=hecamNz1FYdZvIf04MmCFAwmZbhh8uFwikCIuhgVH2HyhO5rW2YIlaGuoxPqQ8pa4fZDpTZ4L0xzsK8JwVEqiYEkWJiEBLqFhqru651Mzp5agz7p28nEChPNY+ONm6Np+sQPvBiJkYezLthaAqRgK6uMc7uZYCJ3PhPRPQ5XJoQ= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R251e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=c01a14441; MF=kepeng.lkp@alibaba-inc.com; NM=0; PH=DS; RN=2; RT=2; SR=0; Received: from 10.22.56.54(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Sat, 27 Jun 2015 22:45:34 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Sat, 27 Jun 2015 22:45:26 +0800 From: "Kepeng Li" To: Justin Richer , Message-ID: Thread-Topic: [Cose] Consensus Call on Input Draft Adoption References: <1B462EEC-67AF-4F19-B8F5-82BA36C59C8D@mit.edu> In-Reply-To: <1B462EEC-67AF-4F19-B8F5-82BA36C59C8D@mit.edu> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3518289934_9381456" Archived-At: Subject: Re: [Cose] Consensus Call on Input Draft Adoption X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 14:45:43 -0000 > ʼʹ MIME ʽʼĶʶ ˸ʽˣ޷ʶʼķֲ򲿷ݡ --B_3518289934_9381456 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Just to add that the deadline to provide your feedback is the end of 4th Jul, 2015. Thanks, Kind Regards Kepeng (&Justin) =B7=A2=BC=FE=C8=CB: Justin Richer =C8=D5=C6=DA: Saturday, 27 June, 2015 10:18 am =D6=C1: =D6=F7=CC=E2: [Cose] Consensus Call on Input Draft Adoption The chairs would like to make a consensus call on accepting the following document as the input draft for a new working group item: https://tools.ietf.org/html/draft-schaad-cose-msg-01 This document, if accepted, will become the basis of the COSE message synta= x specification. Please reply to this thread whether or not you would like to accept this document as input to the working group. Thank you, =A1=AA Justin (& Kepeng) _______________________________________________ Cose mailing list Cose@ietf.org https://www.ietf.org/mailman/listinfo/cose --B_3518289934_9381456 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
Just to add that the deadline to= provide your feedback is the end of 4th Jul, 2015.

Thanks,

Kind Regards
Kepeng (&Justin= )

=B7=A2=BC=FE=C8=CB: Justin Ric= her <jricher@MIT.EDU>
=C8=D5=C6=DA: Saturday, 27 June, 2015 10:18 am
=D6=C1: <c= ose@ietf.org>
=D6=F7=CC=E2: [Cose] = Consensus Call on Input Draft Adoption

The chairs would like to make a consensus call on accepting = the following document as the input draft for a new working group item:


<= a href=3D"https://tools.ietf.org/html/draft-schaad-cose-msg-01" class=3D"">https= ://tools.ietf.org/html/draft-schaad-cose-msg-01


This document, = if accepted, will become the basis of the COSE message syntax specification.=

Please reply to this th= read whether or not you would like to accept this document as input to the w= orking group. 

Than= k you,
 — Justin (& Kepeng)
_______________________________________________ Cose mailing list Cose@ietf.org https://www.ietf.org/m= ailman/listinfo/cose --B_3518289934_9381456-- From nobody Sat Jun 27 08:25:15 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C281B2BB2 for ; Sat, 27 Jun 2015 08:25:13 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 lA-P4HxcneBU for ; Sat, 27 Jun 2015 08:25:01 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72ED81B2BBA for ; Sat, 27 Jun 2015 08:25:00 -0700 (PDT) Received: from hebrews (unknown [50.109.240.20]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id A54D12C9F3; Sat, 27 Jun 2015 08:24:57 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , References: In-Reply-To: Date: Sat, 27 Jun 2015 08:25:09 -0700 Message-ID: <000201d0b0ed$755707c0$60051740$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01D0B0B2.C90464C0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQE1NDqbRmt1XQuFZCU3Rn0/gnMmS573Zg+Q Content-Language: en-us Archived-At: Subject: Re: [Cose] Review of draft-schaad-cose-msg-01 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 15:25:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0003_01D0B0B2.C90464C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Saturday, June 27, 2015 2:07 AM To: cose@ietf.org Subject: [Cose] Review of draft-schaad-cose-msg-01 In response to the call for adoption, I'm submitting the following review feedback on draft-schaad-cose-msg-01 . Most of the major comments are motivated by the goal of "keeping simple things simple". Particularly in constrained environments, it's likely to be normal for implementations to use only the parts of COSE they their application needs. I believe that we should therefore optimize the representations we define for the common cases, while making it possible to also gracefully accommodate less common, if possibly more general cases as well. Also, given my role as a designer and editor of the JOSE specs, I'll say explicitly that it's not my goal to try to have all the decisions in COSE exactly mirror those in JOSE. Some things can clearly be simplified for COSE, and I'm all for that. I plan to consider each issue on its individual merits. That said, here's my review. MAJOR ISSUES 1. Representations should be optimized for the single recipient case. In JOSE, going into IESG review, "signatures" or "recipients" arrays were required for the JSON Serializations, with only general multi-signature/multi-recipient representations being defined for JWS and JWE. Based on feedback from numerous developers who were using JOSE for use cases that only ever used a single signature or recipient, Richard Barnes asked that the Flattened serializations be added to optimize for the common single signature/recipient cases. Based on this developer feedback, we did this. Unless we do the same for COSE, I'm sure we'll receive the same feedback that requiring the "recipients" array in use cases where it will always contain one element is unnecessarily complicated. We should do this now. While the argument against this could be made that "it's even more complicated to support both the flattened and general serializations than just the general one", I believe that in practice, this is a mostly specious argument. Applications will choose or build an implementation that fits their use case - either one that supports single or multiple recipients. Application profiles will choose one or the other representation and will generally not call for both. The way to achieve this is to define a flattened representation as JOSE did, in which header parameters about both the payload and the recipient are carried in the top level "unprotected" and "protected" elements. [JLS] This was discussed on the mailing list. There are a number of trade-offs that were discussed. Please review that discussion and see if you have something new to add. Please remember that we are looking at both the message size and the code size as criteria when making decisions. 2. HMACs should be optimized for the no-key-management case. Particularly for constrained devices, it is unlikely that applications will want to pay the performance penalty of generating and encrypting a key management key to perform a MAC operation. Heck, they may not have credible random number generation in the first place! And they are likewise unlikely to want to pay the message size penalty of carrying the encrypted key. I'm fine with the optional ability to have key management for MACs, but the default should be that no key management information is present in the representation. The only algorithm represented by default should be the MAC algorithm - not even "dir" (direct). I suspect that this can be cleanly done by omitting the key management layer entirely when it's not used, rather than explicitly using "dir" (direct). [JLS] See above. 3. Wrapped keys should be able to be represented as simply the wrapped key value - not as an encrypted data structure with unnecessary information. Key management keys are by definition ephemeral and so no metadata needs to be carried about them. Yes, the algorithm used to wrap the key needs to be represented, but this is already represented separately from the wrapped key. A simple way to achieve this is to define an encrypted_key field to represent the wrapped key, when appropriate for the algorithm. Among other benefits, this will enable the use of the standard RFC 3394 AES Key Wrap algorithms, in the same way that JOSE uses "A128KW", etc. Note that if the working group chooses to, the ability to represent encrypted keys as data structures can also be retained in parallel to this simpler approach. Applications can then choose which method works best for them. [JLS] I don't understand this comment. This is not what the document says. 4. Simpler and more comprehensible examples are needed. I would include examples for the simplest and likely most common use cases: * HMAC without key management * Single signature * Encryption using AES Key Wrap for key management and AES GCM for content encryption Also, to be comprehensible to most readers, the examples need to include both symbolic and numeric identifiers for all fields. Also, decoded representations for encoded values need to be shown. For instance, the Direct MAC example in C.1 should be changed from beginning like this: { 1: 3, 2: h'a10104', 4: h'546869732069732074686520636f6e74656e742e', 10: h'2ba937ca03d76c3dbad30cfcbaeef586f9c0f9ba616ad67e9205d3857 6ad9930', to beginning like this: { 1 (msg_type): 3 (MACed message), 2 (protected): h'a10104' (alg:HS256), 4 (payload): h'546869732069732074686520636f6e74656e742e', 10 (tag): h'2ba937ca03d76c3dbad30cfcbaeef586f9c0f9ba616ad67e9205d3857 6ad9930', [JLS] More examples are on the way in the future. MINOR ISSUES These issues are organized by section number, providing comments on the spec text in the order of appearance. 27 issues are described, labeled a, b, c, . aa. The section numbers and names in which they appear are included in the write-up. 2. The COSE_MSG structure a. Change: Implementations MUST be prepared to find an integer under this label which does not correspond to the values 1 to 3. If this is found then the client MUST stop attempting to parse the structure and fail. to: Implementations MUST be prepared to find an integer under this label which does not correspond to the values 1 to 3. If this is found then the client MUST stop attempting to parse the structure and fail, unless it understands and implements the extension label value. [JLS] I do not believe that this is required. If you implement a new item, then you don't have a pure implementation of this document and the clause is implicit. b. This syntax needs more explanation: COSE_Tagged_MSG = #6.999(COSE_MSG) ; Replace 999 with TBD1 I assume that this is a use of http://tools.ietf.org/html/rfc7049#section-2.4 (Optional Tagging of Items), but you should explicitly say that. [JLS] This falls in to the question of normative reference on CDDL. If it is a normative reference, this is not necessary as you are expected to understand CDDL. If CDDL is informational, then it would be required. c. Change: | ciphertext | 4 | TODO: Should we re-use the same as payload | | | | or not? | to: | ciphertext | 7 | For COSE_encrypt | It's cleaner not to reuse the same label value for different semantic meanings. If we do that, we might come to regret it as the spec evolves. Besides, it's not like using another short integer value here will cause us to run out of them in this context. [JLS] The TODO is a marker for future discussion - There are both advantages and disadvantages to re-using the same label. On one hand, it is easy for programs to always look in the same location for the content independent of what type of content it is. This may make things easier for items which have detached content depending on how the API handles this. On the other hand, an API might want to have them separate. I don't know what the answer for this is yet. d. Change: These two buckets are available for use in all of the structures in this document except for keys. While these buckets can be present, they may not all be usable in all instances. to: These two buckets are defined for use in all of the structures in this document except for keys. While these buckets are defined, they may not be usable or used in all instances. The new text makes it clearer that "protected" and "unprotected" can't be included where their values can't be used. [JLS] That text does not make it any clearer to me. 3.1. COSE Headers e. Change: The field is used to indicate which protected header keys an application which is processing a message is required to understand. to: The field is used to indicate which protected header keys defined by extensions to this specification that an application that is processing a message is required to understand. The language should make it clear that "crit" is only for defining behavior of critical extensions - not for making header parameters defined by this spec critical. [JLS] This does not make things clearer tome. f. In Table 2, change: | jku | * | tstr | | URL to COSE key object | | | | | | | | jwk | * | COSE_Key | | contains a COSE key not | | | | | | a JWK key | | | | | | | to: | jku | * | tstr | | URL to JWK [RFC 7517] | | | | | | | | cku | * | tstr | | URL to COSE key object | | | | | | | | ck | * | COSE_Key | | contains a COSE key | | | | | | | It still makes sense to be able to represent URLs to JWK and COSE Key objects. But we shouldn't call the COSE Key passed by value "jwk", since that's misleading. [JLS] Thus the open issue marker. g. Open Issue 1. Which of the following items do we want to have standardized in this document: jku, jwk, x5c, x5t, x5t#S256, x5u, zip? I would keep all of them, other than changing "jku" and "jwk" to "jku", "cku", and "ck" per (f) above. [JLS] This will be a discussion issue. h. Open Issue 2. I am currently torn on the question "Should epk and iv/nonce be algorithm specific or generic headers?" I would define common labels for them since they are commonly used across multiple algorithms. 4. Signing Structure i. The description of "protected" says "The field MUST NOT hold attributes about the payload being signed". Assuming that a flattened syntax is added, this would then become something like "The field MUST NOT hold attributes about the payload being signed unless the flattened serialization is being used". Other related statements throughout the document would likewise need to be similarly updated. [JLS] But it is not current added - so this is not currently an actionable statement. j. The end of the signing section says: In addition to performing the signature verification, one must also perform the appropriate checks to ensure that the key is correctly paired with the signing identity and that the appropriate authorization is done. There needs to be a reference to a place where the process of verifying the key's association with the signing identity is described. Particular methods are clearly beyond the scope of this specification but saying this little about the process will likely just leave many people confused. [JLS] What do you think this should reference? 5. Encryption Object k. The introduction to this section says: In this section we describe the structure and methods to be used when doing an encryption in COSE. In COSE, we use the same techniques and structures for encrypting both the plain text and the keys used to protect the text. This is different from the approach used by both [RFC5652] and [RFC7516] where different structures are used for the plain text and for the different key management techniques. I'll note that if issue 3 is resolved (Wrapped keys should be able to be represented as simply the wrapped key value), this paragraph will have to be revised accordingly. [JLS] But currently not an actionable statement. l. A generic "iv" (initialization vector) field should also be defined in the list of parameters for the encryption object. Yes, not all algorithms will use it, but many will. m. A "tag" (authentication tag) field should be defined in the list of parameters for the encryption object. Yes, not all the algorithms will use it, but many will. [JLS] Maybe true for 'iv', however 'tag' is part of the ciphertext. 5.1.1. Direct Encryption n. The spec says: o At a minimum, the 'unprotected' field MUST contain the 'alg' parameter and SHOULD contain a parameter identifying the shared secret. SHOULD is too strong here because in some protocols, the shared secret will already be known by methods other than an included "kid" or other key selection value. A "SHOULD . unless ." construct like was used in similar JOSE descriptions is probably the right thing to use here. [JLS] The .unless. clause is confusing as hell so I do not plan to include it. The definition of SHOULD means that put it there unless you have a good reason not to do so. 6. MAC Objects o. The "How to compute a MAC" instructions say: 5. Encrypt and encode the MAC key for each recipient of the message. This is not correct when direct key management or no key management is used. Please revise to accurately include these cases as well. [JLS} This is correct for the current document. 7. Key Structure p. The spec says: The "key_ops" element is preferred over the "use" element as the information provided that way is more finely detailed about the operations allowed. It is strongly suggested that this element be present for all keys. Like in (n), the application may know the key usage from application context, rendering the inclusion of "key_ops" unnecessary. Language something like "It is strongly suggested that this element be present for all keys unless this information is already know to the application through other means" should be used to capture this. The working group should also discuss whether it wants to carry forward "use" for JWK compatibility, even if it is deprecated. I personally would be in favor of doing so. [JLS] If you think this, then please open it as a discussion issue. I don't see any good use for it that is not better served by 'key_ops'. This is doubly true given that the W3C Crypto group q. I would define short numeric values that correspond to the defines "key_ops" string values. I'd do the same for the "use" values. [JLS] Yes this will be happening going forward. 8. CBOR Encoder Restrictions r. The spec says: o All parsers used SHOULD fail on both parsing and generation if the same label is used twice as a key for the same map. I would strongly prefer that the "SHOULD" be changed to "MUST". CBOR doesn't have the same legacy of lax parsers that we inherited from JavaScript/ECMAscript for JSON. Let's not open the door to them! 9.5 COSE Algorithm Registry s. I would add an additional "JOSE algorithm name" field to this registry, whose value is the corresponding "Algorithm Name" entry in the IANA JSON Web Signature and Encryption Algorithms registry at http://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-alg orithms, if such an entry exists. This will tie the two registries together so that definitions of algorithms already defined by JOSE need not be repeated for COSE. In many cases then, the COSE algorithms draft (or section) can just cite the definition in RFC 7518 and register the corresponding short numeric label for COSE use. [JLS] Do we have a reason to believe that COSE implementers are going to have a larger overlap with JOSE implementers? 9.8.1 COSE Security Message t. Besides registering the MIME type "application/cose", I would also register one for a base64url encoded COSE message - an idea first described to me by Joe Hildebrand. It could be called "application/cose+base64url" or something of that ilk. [JLS] I would expect the media-type reviewers to object to that because this is a transport encoding not a content encoding. Do you have a reason to believe otherwise? 9.8.2 COSE Key Media Type u. "application/jwk+json" should be changed to something like "application/cose-key" and "application/jwk-set+json" should be changed to something like "application/cose-key-set". 11.2. Informative References v. The date on the AES-GCM reference (SP 800-38D) should be November 2007 - not June 2015. Appendix A. AEAD and AE Algorithms w. The spec says: This authentication value may be: o A separately generated tag computed by both the encrypter and decrypter and then compared by the decryptor. This tag value may be either placed at the end of the cipher text (the decision we made) or kept separately (the decision made by the JOSE working group). This is the approach followed by AES-GCM [AES-GCM] and AES-CCM [RFC3610]. The last sentence is not true, as written. The AES-GCM spec describes "the ciphertext and tag outputs" - not a single combined output. Common implementations correspond to this, such as the implementation of GCM in .NET. The CCM description in RFC 3610 Section 2.4 describes the output using the text "The final result c consists of the encrypted message followed by the encrypted authentication value U", which admits either implementation. Likewise, at least the .NET CCM implementation produces separate ciphertext and authentication tag values. Whether the tag should be separate or automatically appended to the ciphertext isn't a hill I'm going to die on (although the working group should discuss this and make an explicit decision in this regard), but the text describing the decision should at least be changed to be accurate. [JLS] Wrong reference -will correct. Appendix C. Examples x. The uses of strings and corresponding labels such as those that follow are confusing - especially since key ID values are binary in COSE. A fragment of such an example that confused me was: 3: { 5: " bilbo.baggins@hobbiton.example" }, There are similar strings in some of the other examples that I also couldn't wrap my head around. [JLS] My code does not match the spec here. Originally they were strings. Appendix D. COSE Header Algorithm Label Table y. I would change the term "Header Algorithm" to "Header Parameter". (I suspect this was a cut-and-paste error.) [JLS] I have not settled on a consistent set of terms for this yet. I need to do so and then make a pass to correct them all. I don't think that some of the terms I am currently using are sufficiently distinct to make it easy to figure things out. z. In Appendix D and Appendix E, I would call out that the names in the "name" columns correspond to names defined in RFC 7518. [JLS] These tables are disappearing as part of the add the algorithms to the document exercise. Appendix F. COSE General Values aa. This seems confused, as it mixes "kty" values (EC=1, RSA=2, oct=3) with curve values (P256=4, P521=5). I would keep these separate. Also, wherever the curve names are defined, I would also include P384, as JOSE did. [JLS] That may happen in the future. I just needed a table to put things in for now. NITS I will be submitting spelling and grammar corrections as a GitHub pull request against the spec repository rather than detail them here. I'll post the pull request link once it's been created. CONCLUSIONS I'd like to thank Jim for doing the work to produce a well-thought-out initial draft. I believe it provides a solid starting point for the COSE work. I'd be willing to produce specific proposed edits for any/all of the above issues and comments, should the editors find that useful. Best wishes, -- Mike ------=_NextPart_000_0003_01D0B0B2.C90464C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: Cose = [mailto:cose-bounces@ietf.org] On Behalf Of Mike = Jones
Sent: Saturday, June 27, 2015 2:07 AM
To: = cose@ietf.org
Subject: [Cose] Review of = draft-schaad-cose-msg-01

 

In response = to the call for adoption, I’m submitting the following review = feedback on draft-schaad= -cose-msg-01.  Most of the major comments are motivated by the = goal of “keeping simple things simple”.  Particularly = in constrained environments, it’s likely to be normal for = implementations to use only the parts of COSE they their application = needs.  I believe that we should therefore optimize the = representations we define for the common cases, while making it possible = to also gracefully accommodate less common, if possibly more general = cases as well.

 

Also, given = my role as a designer and editor of the JOSE specs, I’ll say = explicitly that it’s not my goal to try to have all the decisions = in COSE exactly mirror those in JOSE.  Some things can clearly be = simplified for COSE, and I’m all for that.  I plan to = consider each issue on its individual merits.  That said, = here’s my review…

 

MAJOR = ISSUES

 

1.  Representations should be optimized for = the single recipient case.

 

In JOSE, = going into IESG review, “signatures” or = “recipients” arrays were required for the JSON = Serializations, with only general multi-signature/multi-recipient = representations being defined for JWS and JWE.  Based on feedback = from numerous developers who were using JOSE for use cases that only = ever used a single signature or recipient, Richard Barnes asked that the = Flattened serializations be added to optimize for the common single = signature/recipient cases.  Based on this developer feedback, we = did this.

 

Unless we do the same for COSE, I’m sure = we’ll receive the same feedback that requiring the = “recipients” array in use cases where it will always contain = one element is unnecessarily complicated.  We should do this = now.

 

While the argument against this could be made that = “it’s even more complicated to support both the flattened = and general serializations than just the general one”, I believe = that in practice, this is a mostly specious argument.  Applications = will choose or build an implementation that fits their use case – = either one that supports single or multiple recipients.  = Application profiles will choose one or the other representation and = will generally not call for both.

 

The way to = achieve this is to define a flattened representation as JOSE did, in = which header parameters about both the payload and the recipient are = carried in the top level “unprotected” and = “protected” elements.

 

[JLS] This was discussed on = the mailing list.  There are a number of trade-offs that were = discussed.  Please review that discussion and see if you have = something new to add.  Please remember that we are looking at both = the message size and the code size as criteria when making = decisions.

 

2.  = HMACs should be optimized for the no-key-management = case.

 

Particularly for constrained devices, it is unlikely = that applications will want to pay the performance penalty of generating = and encrypting a key management key to perform a MAC operation.  = Heck, they may not have credible random number generation in the first = place!  And they are likewise unlikely to want to pay the message = size penalty of carrying the encrypted key.

 

I’m = fine with the optional ability to have key management for MACs, but the = default should be that no key management information is present in the = representation.  The only algorithm represented by default should = be the MAC algorithm – not even “dir” (direct).  = I suspect that this can be cleanly done by omitting the key management = layer entirely when it’s not used, rather than explicitly using = “dir” (direct).

 

[JLS] See = above.

 

3.  Wrapped keys should be able to be = represented as simply the wrapped key value – not as an encrypted = data structure with unnecessary information.

 

Key = management keys are by definition ephemeral and so no metadata needs to = be carried about them.  Yes, the algorithm used to wrap the key = needs to be represented, but this is already represented separately from = the wrapped key.

 

A simple way = to achieve this is to define an encrypted_key field to represent the = wrapped key, when appropriate for the algorithm.  Among other = benefits, this will enable the use of the standard RFC 3394 AES Key Wrap = algorithms, in the same way that JOSE uses “A128KW”, = etc.

 

Note that if the working group chooses to, the ability = to represent encrypted keys as data structures can also be retained in = parallel to this simpler approach.  Applications can then choose = which method works best for them.

 

[JLS] I don’t = understand this comment.  This is not what the document = says.

 

4.  Simpler and more comprehensible examples = are needed.

 

I would = include examples for the simplest and likely most common use = cases:

·        = HMAC without key = management

·        = Single signature

·        = Encryption using AES Key Wrap for key = management and AES GCM for content encryption

 

Also, to be = comprehensible to most readers, the examples need to include both = symbolic and numeric identifiers for all fields.  Also, decoded = representations for encoded values need to be shown.

 

For = instance, the Direct MAC example in C.1 should be changed from beginning = like this:

 

   {

     1: 3,

     2: = h'a10104',

     = 4: h'546869732069732074686520636f6e74656e742e',

     10: = h'2ba937ca03d76c3dbad30cfcbaeef586f9c0f9ba616ad67e9205d3857

   6ad9930',

 

to beginning = like this:

 

   {

     1 (msg_type): 3 (MACed = message),

     2 = (protected): h'a10104' (alg:HS256),

     4 (payload): = h'546869732069732074686520636f6e74656e742e',

     10 (tag): = h'2ba937ca03d76c3dbad30cfcbaeef586f9c0f9ba616ad67e9205d3857

   6ad9930',

 

[JLS] More examples are on = the way in the future.

 

MINOR = ISSUES

 

These issues are organized by section number, = providing comments on the spec text in the order of appearance.  27 = issues are described, labeled a, b, c, … aa.  The section = numbers and names in which they appear are included in the = write-up.

 

2.  The COSE_MSG structure

 

a.  = Change:

   Implementations MUST be = prepared to find an integer under this label

   = which does not correspond to the values 1 to 3.  If this is = found

   then the client MUST = stop attempting to parse the structure and fail.

to:

   Implementations MUST be = prepared to find an integer under this label

   = which does not correspond to the values 1 to 3.  If this is = found

   then the client MUST = stop attempting to parse the structure and fail,

   = unless it understands and implements the extension label = value.

 

[JLS] I do not believe that this is required.  If = you implement a new item, then you don’t have a pure = implementation of this document and the clause is = implicit.

 

b.  = This syntax needs more explanation:

   COSE_Tagged_MSG =3D = #6.999(COSE_MSG)   ; Replace 999 with TBD1

 

I assume = that this is a use of http://tools.ietf= .org/html/rfc7049#section-2.4 (Optional Tagging of Items), but you = should explicitly say that.

 

[JLS]  This falls in to the question of = normative reference on CDDL.  If it is a normative reference, this = is not necessary as you are expected to understand CDDL.  If CDDL = is informational, then it would be required.

 

c.  Change:

   = | ciphertext  | 4      | TODO: Should we = re-use the same as payload |

   = |            = |        | or = not?           &nb= sp;           &nbs= p;            = |

to:

   = | ciphertext  | 7      | For = COSE_encrypt          &= nbsp;           &n= bsp;    |

 

It’s = cleaner not to reuse the same label value for different semantic = meanings.  If we do that, we might come to regret it as the spec = evolves.  Besides, it’s not like using another short integer = value here will cause us to run out of them in this = context.

 

[JLS]  The TODO is a = marker for future discussion – There are both advantages and = disadvantages to re-using the same label.  On one hand, it is easy = for programs to always look in the same location for the content = independent of what type of content it is.  This may make things = easier for items which have detached content depending on how the API = handles this.  On the other hand, an API might want to have them = separate.   I don’t know what the answer for this is = yet.

 

d.  Change:

  These = two buckets

   are available for use = in all of the structures in this document

   = except for keys.  While these buckets can be present, they may = not

   all be usable in all = instances.

to:

  These two = buckets

   are defined for use in = all of the structures in this document

   = except for keys.  While these buckets are defined, they may = not

   be usable or used in = all instances.

 

The new text makes it clearer that = “protected” and “unprotected” can’t be = included where their values can’t be used.

[JLS] That text does not = make it any clearer to me.

 

3.1.  = COSE Headers

 

e.  Change:

  The = field is used to indicate which protected header = keys

      an = application which is processing a message is required = to

      = understand.

to:

  The field is used to indicate = which protected header keys

      defined by extensions to this = specification that

      an = application that is processing a message is required = to

      = understand.

 

The language = should make it clear that “crit” is only for defining = behavior of critical extensions – not for making header parameters = defined by this spec critical.

[JLS] This does not make things clearer = tome.

 

f.  In Table 2, change:

   = | jku      | *     | = tstr     = |           | URL to = COSE key object  |

   = |          = |       = |          = |           = |            =           =    |

   | = jwk      | *     | COSE_Key = |           | contains = a COSE key not |

   = |          = |       = |          = |           | a JWK = key           &nbs= p;   |

   = |          = |       = |          = |           = |            =              = |

to:

   = | jku      | *     | = tstr     = |           | URL to = JWK [RFC 7517]   |

   = |          = |       = |          = |           = |            =           =    |

  | = cku      | *     | = tstr     = |           | URL to = COSE key object  |

   = |          = |       = |          = |           = |            =           =    |

   | ck    =    | *     | COSE_Key = |           | contains = a COSE key     |

   = |          = |       = |          = |           = |            =              = |

 

It still makes sense to be able to represent URLs to = JWK and COSE Key objects.  But we shouldn’t call the COSE Key = passed by value “jwk”, since that’s = misleading.

[JLS] Thus the open issue = marker.

 

g.     Open Issue 1.  Which = of the following items do we want to have standardized = in

       this document: = jku, jwk, x5c, x5t, x5t#S256, x5u, zip?

 

I would keep = all of them, other than changing “jku” and “jwk” = to “jku”, “cku”, and “ck” per (f) = above.

[JLS] This will be a discussion = issue.

 

h.  Open Issue 2.  I am currently torn on = the question "Should epk and iv/nonce be

       algorithm = specific or generic headers?"

 

I would = define common labels for them since they are commonly used across = multiple algorithms.

 

4.  = Signing Structure

 

i.           = ;      The description = of “protected” says “The field MUST NOT hold = attributes about the payload being signed”.  Assuming that a = flattened syntax is added, this would then become something like = “The field MUST NOT hold attributes about the payload being signed = unless the flattened serialization is being used”.  Other = related statements throughout the document would likewise need to be = similarly updated.

[JLS] But it is not current added – so this is = not currently an actionable statement.

 

j.  The = end of the signing section says:

   = In addition to performing the signature verification, one must = also

   perform the appropriate = checks to ensure that the key is correctly

   = paired with the signing identity and that the = appropriate

   authorization is = done.

 

There needs to be a reference to a place where the = process of verifying the key’s association with the signing = identity is described.  Particular methods are clearly beyond the = scope of this specification but saying this little about the process = will likely just leave many people confused.

[JLS] What do you think this = should reference?

 

5.  = Encryption Object

 

k.  The = introduction to this section says:

   = In this section we describe the structure and methods to be used = when

   doing an encryption in = COSE.  In COSE, we use the same techniques = and

   structures for = encrypting both the plain text and the keys used = to

  protect the text.  = This is different from the approach used by both

   = [RFC5652] and [RFC7516] where different structures are used for = the

   plain text and for the = different key management techniques.

 

I’ll = note that if issue 3 is resolved (Wrapped keys should be able to be = represented as simply the wrapped key value), this paragraph will = have to be revised accordingly.

[JLS] But currently not an actionable = statement.

 

l.  A = generic “iv” (initialization vector) field should also be = defined in the list of parameters for the encryption object.  Yes, = not all algorithms will use it, but many will.

 

m.  A = “tag” (authentication tag) field should be defined in the = list of parameters for the encryption object.  Yes, not all the = algorithms will use it, but many will.

[JLS] Maybe true for = ‘iv’, however ‘tag’ is part of the = ciphertext.

 

5.1.1.  = Direct Encryption

 

n.  The = spec says:

   o  At a minimum, = the 'unprotected' field MUST contain the 'alg'

      parameter and SHOULD contain a = parameter identifying the shared

      secret.

 

SHOULD is = too strong here because in some protocols, the shared secret will = already be known by methods other than an included “kid” or = other key selection value.  A “SHOULD … unless = …” construct like was used in similar JOSE descriptions is = probably the right thing to use here.

[JLS] The = …unless… clause is confusing as hell so I do not plan to = include it.  The definition of SHOULD means that put it there = unless you have a good reason not to do so.

 

6.  MAC = Objects

 

o.  The “How to compute a MAC” = instructions say:

   5.  Encrypt and = encode the MAC key for each recipient of the = message.

 

This is not = correct when direct key management or no key management is used.  = Please revise to accurately include these cases as = well.

[JLS} = This is correct for the current document.

 

7.  Key = Structure

 

p.  The spec says:

   = The "key_ops" element is preferred over the "use" = element as the

   information provided = that way is more finely detailed about the

   = operations allowed.  It is strongly suggested that this element = be

   present for all = keys.

 

Like in (n), the application may know the key usage = from application context, rendering the inclusion of = “key_ops” unnecessary.  Language something like = “It is strongly suggested that this element be present for all = keys unless this information is already know to the application through = other means” should be used to capture this.

 

The working = group should also discuss whether it wants to carry forward = “use” for JWK compatibility, even if it is deprecated.  = I personally would be in favor of doing so.

[JLS] If you think this, = then please open it as a discussion issue.  I don’t see any = good use for it that is not better served by = ‘key_ops’.  This is doubly true given that the W3C = Crypto group

 

q.  I = would define short numeric values that correspond to the defines = “key_ops” string values.  I’d do the same for the = “use” values.

[JLS] Yes this will be happening going = forward.

 

8.  = CBOR Encoder Restrictions

 

r.  The = spec says:

   o  All parsers = used SHOULD fail on both parsing and generation if = the

      same = label is used twice as a key for the same map.

 

I would = strongly prefer that the “SHOULD” be changed to = “MUST”.  CBOR doesn’t have the same legacy of lax = parsers that we inherited from JavaScript/ECMAscript for JSON.  = Let’s not open the door to them!

 

9.5  = COSE Algorithm Registry

 

s.  I = would add an additional “JOSE algorithm name” field to this = registry, whose value is the corresponding “Algorithm Name” = entry in the IANA JSON Web Signature and Encryption Algorithms registry = at http://www.iana.org/assignments/jose/jose.xhtml#web-s= ignature-encryption-algorithms, if such an entry exists.  This = will tie the two registries together so that definitions of algorithms = already defined by JOSE need not be repeated for COSE.

 

In many = cases then, the COSE algorithms draft (or section) can just cite the = definition in RFC 7518 and register the corresponding short numeric = label for COSE use.

[JLS] Do we have a reason to believe that COSE = implementers are going to have a larger overlap with JOSE = implementers?

 

9.8.1  = COSE Security Message

 

t.  = Besides registering the MIME type “application/cose”, I = would also register one for a base64url encoded COSE message – an = idea first described to me by Joe Hildebrand.  It could be called = “application/cose+base64url” or something of that = ilk.

[JLS]  I would expect the media-type reviewers = to object to that because this is a transport encoding not a content = encoding.  Do you have a reason to believe = otherwise?

 

9.8.2  = COSE Key Media Type

 

u.  = “application/jwk+json” should be changed to something like = “application/cose-key” and = “application/jwk-set+json” should be changed to something = like “application/cose-key-set”.

 

11.2.  = Informative References

 

v.  The = date on the AES-GCM reference (SP 800-38D) should be November 2007 = – not June 2015.

 

Appendix = A.  AEAD and AE Algorithms

 

w.  The = spec says:

  This authentication value may = be:

   o  A separately = generated tag computed by both the encrypter and

      decrypter and then compared by the = decryptor.  This tag value may

      be either placed at the end of the = cipher text (the decision we

      made) or kept separately (the = decision made by the JOSE working

      group).  This is the approach = followed by AES-GCM [AES-GCM] and

      AES-CCM = [RFC3610].

 

The last = sentence is not true, as written.  The AES-GCM spec describes = “the ciphertext and tag = outputs” – not a single combined output.  Common = implementations correspond to this, such as the implementation of GCM in = .NET.

 

The CCM description in RFC 3610 Section 2.4 describes = the output using the text “The final result c consists of the = encrypted message followed by the encrypted authentication value = U”, which admits either implementation.  Likewise, at least = the .NET CCM implementation produces separate ciphertext and = authentication tag values.

 

Whether the = tag should be separate or automatically appended to the ciphertext = isn’t a hill I’m going to die on (although the working group = should discuss this and make an explicit decision in this regard), but = the text describing the decision should at least be changed to be = accurate.

 

[JLS] Wrong reference = –will correct.

 

Appendix = C.  Examples

 

x.  The = uses of strings and corresponding labels such as those that follow are = confusing – especially since key ID values are binary in = COSE.  A fragment of such an example that confused me = was:

         3: = {

           5: = "bilbo.baggins@hobbiton.example"

         = },

 

There are similar strings in some of the other = examples that I also couldn’t wrap my head = around.

[JLS] My code does not match the spec here.  = Originally they were strings.

 

Appendix = D.  COSE Header Algorithm Label Table

 

y.  I = would change the term “Header Algorithm” to “Header = Parameter”.  (I suspect this was a cut-and-paste = error.)

[JLS] I have not settled on a consistent set of = terms for this yet.  I need to do so and then make a pass to = correct them all.  I don’t think that some of the terms I am = currently using are sufficiently distinct to make it easy to figure = things out.

 

z.  In = Appendix D and Appendix E, I would call out that the names in the = “name” columns correspond to names defined in RFC = 7518.

[JLS] = These tables are disappearing as part of the add the algorithms to the = document exercise.

 

Appendix = F.  COSE General Values

 

aa.  = This seems confused, as it mixes “kty” values (EC=3D1, = RSA=3D2, oct=3D3) with curve values (P256=3D4, P521=3D5).  I would = keep these separate.  Also, wherever the curve names are defined, I = would also include P384, as JOSE did.

[JLS] That may happen in the = future.  I just needed a table to put things in for = now.

 

NITS

 

I will be = submitting spelling and grammar corrections as a GitHub pull request = against the spec repository rather than detail them here. =  I’ll post the pull request link once it’s been = created.

 

CONCLUSIONS

 

I’d = like to thank Jim for doing the work to produce a well-thought-out = initial draft.  I believe it provides a solid starting point for = the COSE work.

 

I’d be = willing to produce specific proposed edits for any/all of the above = issues and comments, should the editors find that useful. =

 

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;  Best wishes,

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;  -- Mike

 

------=_NextPart_000_0003_01D0B0B2.C90464C0-- From nobody Sat Jun 27 08:42:52 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56691B2DD2 for ; Sat, 27 Jun 2015 08:42:49 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 v3WcbEcYKX7b for ; Sat, 27 Jun 2015 08:42:48 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 758511B2DD3 for ; Sat, 27 Jun 2015 08:42:48 -0700 (PDT) Received: from hebrews (unknown [50.109.240.20]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id BA2FD2C9F3; Sat, 27 Jun 2015 08:42:47 -0700 (PDT) From: "Jim Schaad" To: "'Justin Richer'" , References: <1B462EEC-67AF-4F19-B8F5-82BA36C59C8D@mit.edu> In-Reply-To: <1B462EEC-67AF-4F19-B8F5-82BA36C59C8D@mit.edu> Date: Sat, 27 Jun 2015 08:43:00 -0700 Message-ID: <000701d0b0ef$f3267300$d9735900$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01D0B0B5.46C996D0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJY2oSeSME8IW5u9lRslrpXo0MKwpywKlSQ Content-Language: en-us Archived-At: Subject: Re: [Cose] Consensus Call on Input Draft Adoption X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 15:42:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0008_01D0B0B5.46C996D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I would like to remind people that why the call is on the document that = is in the IETF repository, a more up to date version can be found at = https://cose-wg.github.io/cose-spec/. This version has edits and = changes that are not currently in the IETF version of the document. =20 Jim =20 =20 From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Justin Richer Sent: Friday, June 26, 2015 7:19 PM To: cose@ietf.org Subject: [Cose] Consensus Call on Input Draft Adoption =20 The chairs would like to make a consensus call on accepting the = following document as the input draft for a new working group item: =20 =20 https://tools.ietf.org/html/draft-schaad-cose-msg-01 =20 =20 This document, if accepted, will become the basis of the COSE message = syntax specification. =20 Please reply to this thread whether or not you would like to accept this = document as input to the working group.=20 =20 Thank you, =E2=80=94 Justin (& Kepeng) ------=_NextPart_000_0008_01D0B0B5.46C996D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I would like to remind people that why the call is on the document that = is in the IETF repository, a more up to date version can be found at https://cose-wg.github.io/c= ose-spec/.=C2=A0 This version has edits and changes that are not = currently in the IETF version of the document.

 

Jim

 

 

From:<= /b> = Cose [mailto:cose-bounces@ietf.org] On Behalf Of Justin = Richer
Sent: Friday, June 26, 2015 7:19 PM
To: = cose@ietf.org
Subject: [Cose] Consensus Call on Input Draft = Adoption

 

The chairs = would like to make a consensus call on accepting the following document = as the input draft for a new working group item:

 

 

 

 

This document, if accepted, will become the basis of = the COSE message syntax specification.

 

Please reply to this thread whether or not you would = like to accept this document as input to the working = group. 

 

Thank you,

 =E2=80=94 Justin (& = Kepeng)

------=_NextPart_000_0008_01D0B0B5.46C996D0-- From nobody Sat Jun 27 11:09:44 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E863E1A1EEE for ; Sat, 27 Jun 2015 11:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=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 kqCePMLC0vYi for ; Sat, 27 Jun 2015 11:09:43 -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 D16DC1A1E0F for ; Sat, 27 Jun 2015 11:09:42 -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 t5RI9bQu014487; Sat, 27 Jun 2015 20:09:37 +0200 (CEST) Received: from alma.local (eduroam-pool7-1946.wlan.uni-bremen.de [134.102.119.154]) (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 3mJjlj0M4rz98nB; Sat, 27 Jun 2015 20:09:36 +0200 (CEST) Message-ID: <558EE6DF.4080305@tzi.org> Date: Sat, 27 Jun 2015 20:09:35 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: Jim Schaad References: <1B462EEC-67AF-4F19-B8F5-82BA36C59C8D@mit.edu> <000701d0b0ef$f3267300$d9735900$@augustcellars.com> In-Reply-To: <000701d0b0ef$f3267300$d9735900$@augustcellars.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] Consensus Call on Input Draft Adoption X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 18:09:44 -0000 Jim Schaad wrote: > I would like to remind people that why [while] > the call is on the document that > is in the IETF repository, a more up to date version can be found at > https://cose-wg.github.io/cose-spec/. This version has edits and > changes that are not currently in the IETF version of the document. Right. We should use the time we wait for the adoption call to expire, to do some technical work as well. I'll certainly send out some technical comments in the next couple of days, and I hope we can use those to further advance the work and fast-forward the draft once adopted. Grüße, Carsten From nobody Sat Jun 27 12:29:11 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 173271A88B2 for ; Sat, 27 Jun 2015 12:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 0rq8kici5czx for ; Sat, 27 Jun 2015 12:29:09 -0700 (PDT) Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com [209.85.220.174]) (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 316B61A88B0 for ; Sat, 27 Jun 2015 12:29:08 -0700 (PDT) Received: by qkhu186 with SMTP id u186so73067913qkh.0 for ; Sat, 27 Jun 2015 12:29:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=HThhnDuRbaRD9Zq0g70aCEtoQDzN5mHYr3gB7AvIZEY=; b=URl5ggiXvH//QjG2p3PTr4C3XuwoNVC92Wa79ZtfxMK8E6tmbFVIz86TvJHJeu/ncG 57ziT2NJDxOJ5aVb438drT0wBiU+RC2dn9KHtKUJD16QllBS0U32HTEpd0EY16XCeKWu aliigQ3ISqhBsgP3pfBAubXTncin7P9Kj+OfPpTaMMDuTRTmr+YXUO/8LiCnmojzjYlC 2jBeUhl/xxBTSXkw/Me1D7buyKgOz6IOkR0pj2FNotVqZdZUplL/G1IvmvYfvy0cM4Sa V3zJ42hb41K688d0QHEJJkSU5c2L/H2aHP8GsS6xSIcAhK188sjpYTGYH9JA0t9tl7Dc wGEg== X-Gm-Message-State: ALoCoQmm18JTS2nC0C5x0IeN3tDbH8qSU8jwZPnoW1SNlwmpj2kSpcSuXeClBsmjK8DM1/segjb1 X-Received: by 10.140.238.15 with SMTP id j15mr10887319qhc.4.1435433348224; Sat, 27 Jun 2015 12:29:08 -0700 (PDT) Received: from [192.168.1.216] (186-79-107-199.baf.movistar.cl. [186.79.107.199]) by mx.google.com with ESMTPSA id c73sm8994876qka.24.2015.06.27.12.29.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 27 Jun 2015 12:29:07 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: John Bradley In-Reply-To: <558E83A1.6070804@tzi.org> Date: Sat, 27 Jun 2015 16:29:00 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <506C16CD-239D-43AA-9CAB-BBFDE9148CB2@ve7jtb.com> References: <1B462EEC-67AF-4F19-B8F5-82BA36C59C8D@mit.edu> <558E83A1.6070804@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "cose@ietf.org" Subject: Re: [Cose] Consensus Call on Input Draft Adoption X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 19:29:11 -0000 +1 > On Jun 27, 2015, at 8:06 AM, Carsten Bormann wrote: >=20 > Mike Jones wrote: >> Let me be the first to say that I approve of adopting this document = as a >> working group draft. I=E2=80=99d like to thank Jim for doing the = work to >> produce a well-thought-out initial draft. I believe it provides a = solid >> starting point for the COSE work. >=20 > +1. >=20 > I hope the chairs can declare consensus on this well before the = looming > I-D deadline (2015-07-06), so we can go into the Prague meeting with a > draft-ietf-cose-.... >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Sat Jun 27 16:20:35 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFDB1ACAD5 for ; Sat, 27 Jun 2015 16:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 xEc1Ypk2GndC for ; Sat, 27 Jun 2015 16:20:33 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 0F13E1AC3FB for ; Sat, 27 Jun 2015 16:20:32 -0700 (PDT) Received: by oiax193 with SMTP id x193so97026291oia.2 for ; Sat, 27 Jun 2015 16:20:32 -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-type; bh=LUKXE3gqx8s54JfTFx02Fh9/7EkypqFvXb/LacJBHiU=; b=fjGpHA+RHI6VXFR5fkKVU4GEieNCJYHqik7tRkf4WH3PpvcA3LDvA2qiG7kpGTzUjV XaE+L/JKNnvcdssoqEnSoyzEQJ/2wCgjoJQHxavuyG1qzfjipFpKvHEmh2nFAKrrhsCQ aYNrZ23aOhDiDBpaxWWecF/kwpj8k42algn99RA9CmzA8CkdPnOcvt+uO0HFOdabBSsT LLsOJa9PAOoAVQci9zGzZ7476QrXUbEYNjzLkgE1MXgdj0ZftOEjXzKLFk0FBB8ULEg8 sAVruQtjvurb+lUuhDQGZ7NAzIHZ6q4W5q9eVfFgQJbCIwkk78lH7q006D4vTwWnwSag 4wJw== X-Received: by 10.60.60.230 with SMTP id k6mr7678617oer.21.1435447232222; Sat, 27 Jun 2015 16:20:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.116.99 with HTTP; Sat, 27 Jun 2015 16:20:12 -0700 (PDT) In-Reply-To: <506C16CD-239D-43AA-9CAB-BBFDE9148CB2@ve7jtb.com> References: <1B462EEC-67AF-4F19-B8F5-82BA36C59C8D@mit.edu> <558E83A1.6070804@tzi.org> <506C16CD-239D-43AA-9CAB-BBFDE9148CB2@ve7jtb.com> From: Dick Hardt Date: Sat, 27 Jun 2015 16:20:12 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=089e01538c585edbde0519881ac3 Archived-At: Cc: Carsten Bormann , "cose@ietf.org" Subject: Re: [Cose] Consensus Call on Input Draft Adoption X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 23:20:34 -0000 --089e01538c585edbde0519881ac3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 On Sat, Jun 27, 2015 at 12:29 PM, John Bradley wrote: > +1 > > On Jun 27, 2015, at 8:06 AM, Carsten Bormann wrote: > > > > Mike Jones wrote: > >> Let me be the first to say that I approve of adopting this document as= a > >> working group draft. I=E2=80=99d like to thank Jim for doing the work= to > >> produce a well-thought-out initial draft. I believe it provides a sol= id > >> starting point for the COSE work. > > > > +1. > > > > I hope the chairs can declare consensus on this well before the looming > > I-D deadline (2015-07-06), so we can go into the Prague meeting with a > > draft-ietf-cose-.... > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > _______________________________________________ > > 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 > --089e01538c585edbde0519881ac3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

On Sat, Jun 27, 2015 at 12:29 PM, John Bradley &l= t;ve7jtb@ve7jtb.com<= /a>> wrote:
+1
> On Jun 27, 2015, at 8:06 AM, C= arsten Bormann <cabo@tzi.org> wro= te:
>
> Mike Jones wrote:
>> Let me be the first to say that I approve of adopting this documen= t as a
>> working group draft.=C2=A0 I=E2=80=99d like to thank Jim for doing= the work to
>> produce a well-thought-out initial draft.=C2=A0 I believe it provi= des a solid
>> starting point for the COSE work.
>
> +1.
>
> I hope the chairs can declare consensus on this well before the loomin= g
> I-D deadline (2015-07-06), so we can go into the Prague meeting with a=
> draft-ietf-cose-....
>
> Gr=C3=BC=C3=9Fe, Carsten
>
> _______________________________________________
> 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

--089e01538c585edbde0519881ac3-- From nobody Sun Jun 28 22:45:12 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1D21A0155 for ; Sun, 28 Jun 2015 22:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 5zOhUdEy5Qf3 for ; Sun, 28 Jun 2015 22:45:09 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0133.outbound.protection.outlook.com [65.55.169.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 029221A011D for ; Sun, 28 Jun 2015 22:45:08 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.201.16; Mon, 29 Jun 2015 05:45:06 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0201.000; Mon, 29 Jun 2015 05:44:54 +0000 From: Mike Jones To: "cose@ietf.org" Thread-Topic: Nits discovered during my review of draft-schaad-cose-msg-01 Thread-Index: AdCyLrUrIC9wv46ATN+A2Ppo8C/tXA== Date: Mon, 29 Jun 2015 05:44:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [50.47.90.173] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:g3klDZGem58IuUNRutrzQIsmAyYioXgz3NfwrTPnDDXdi2/eRg9i9SpBIj5SUXbiGS2fShn5fFV2nh/Zkaup67e/nZR9uqrA6WP3gO03OdsbrLdja/Y50kQWniHwC3jMIt8F3vFwYt1gqtKDDi/1Bw==; 24:EDQYXc7Kaaoqtrm7sSXTwyzLfDFaAziuhbHtBWcfD4PuQhCQ56tasI7uAuKmj/wZDvBB8RM1IDUuydA7/8F9Fqe6gaaog0X8EIq9ni/D7mQ=; 20:txWvft12Vyh0SO8PVjZCNyKB5vACkJ/fPw7V6nMMOSsfvLbdHbPah7ET7VV1vZZ/oq63mw5UW63tUzy92m4Spw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0622A98CD5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(2351001)(229853001)(2656002)(16236675004)(87936001)(122556002)(86362001)(54356999)(50986999)(5002640100001)(19617315012)(46102003)(450100001)(40100003)(76576001)(92566002)(2501003)(33656002)(19625215002)(19609705001)(230783001)(77096005)(86612001)(189998001)(102836002)(74316001)(107886002)(99286002)(2900100001)(5001960100002)(77156002)(110136002)(62966003)(15975445007)(5003600100002)(66066001)(19580395003)(19300405004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442521126799F001A439939F5AA0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2015 05:44:54.0521 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Subject: [Cose] Nits discovered during my review of draft-schaad-cose-msg-01 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 05:45:10 -0000 --_000_BY2PR03MB442521126799F001A439939F5AA0BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've submitted these as a GitHub pull request. Thanks to Justin for help w= ith the GitHub mechanics. The pull request is https://github.com/cose-wg/cose-spec/pull/50. This branch includes grammar and spelling corrections. Most of the grammar= corrections are changing instances of "which" to "that", where appropriate= . I also changed uses of the term "byte" to "octet". -- Mike --_000_BY2PR03MB442521126799F001A439939F5AA0BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve submitted these as a GitHub pull request.=   Thanks to Justin for help with the GitHub mechanics.

 

The pull request is https://github.com/cose-wg/cose-spec/pull/50.

 

This branch includes grammar and spelling correction= s.  Most of the grammar corrections are changing instances of "wh= ich" to "that", where appropriate.  I also changed uses= of the term "byte" to "octet".

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

 

--_000_BY2PR03MB442521126799F001A439939F5AA0BY2PR03MB442namprd_-- From nobody Sun Jun 28 23:13:27 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8F61A1A55 for ; Sun, 28 Jun 2015 23:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35] autolearn=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 c4jSBVhEnAz5 for ; Sun, 28 Jun 2015 23:13:25 -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 092551A1A4A for ; Sun, 28 Jun 2015 23:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t5T6DJJH007456; Mon, 29 Jun 2015 08:13:19 +0200 (CEST) Received: from alma.local (p5DC7EA60.dip0.t-ipconnect.de [93.199.234.96]) (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 3mKdmH1HJXz9B9G; Mon, 29 Jun 2015 08:13:19 +0200 (CEST) Message-ID: <5590E1FD.8040209@tzi.org> Date: Mon, 29 Jun 2015 08:13:17 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: Mike Jones References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "cose@ietf.org" Subject: Re: [Cose] Nits discovered during my review of draft-schaad-cose-msg-01 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 06:13:26 -0000 Mike Jones wrote: > I also changed uses of the term "byte" to "octet". It would be nice if we could avoid doing that. IEC 80000-13 should be mandatory reading by now. (For the pedantic, we can always add the usual text: In this specification, the term "byte" is used in its now customary sense as a synonym for "octet".) Grüße, Carsten From nobody Sun Jun 28 23:36:49 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188901A1A52 for ; Sun, 28 Jun 2015 23:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 3WvcgMF_51kD for ; Sun, 28 Jun 2015 23:36:45 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0122.outbound.protection.outlook.com [207.46.100.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92C9C1A1B21 for ; Sun, 28 Jun 2015 23:36:45 -0700 (PDT) Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.207.12; Mon, 29 Jun 2015 06:36:44 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0201.000; Mon, 29 Jun 2015 06:36:44 +0000 From: Mike Jones To: Carsten Bormann Thread-Topic: [Cose] Nits discovered during my review of draft-schaad-cose-msg-01 Thread-Index: AdCyLrUrIC9wv46ATN+A2Ppo8C/tXAAA/smAAADRi3k= Date: Mon, 29 Jun 2015 06:36:43 +0000 Message-ID: References: , <5590E1FD.8040209@tzi.org> In-Reply-To: <5590E1FD.8040209@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tzi.org; dkim=none (message not signed) header.d=none; x-originating-ip: [50.47.90.173] x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:nW7dPkfWGqAEmmbQtyzVESanzaZwZUsH7tGvfo7wjP9mbn+cquwyJ2EEMpJEtvRTD204cu00H97vEIG6FFoRLH0IhCMASEVsmXF2T/u3zjLw0RN0sEKHnS9td+3ZkT78vJJNmcsmqvrXyZ4tVaCvbQ==; 24:B/BnYYVqoC9ggLbqdKmmVdtp9GHJ5dOIp7omyXktBVp3ORSjLycMROdwtpD79MMIoBDxGCcNXz0jKNCFi3W9UjML2FpGoTmhRCrQypZ7Cn4=; 20:Wmyc/W6gJhkpvSRf+XZpyWXVSHA+fnv3DD9LSDqPYuNXlOinuMUV4yvQc1/d3x2amfxn4RGO/ZJHVll5jsVpWw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 0622A98CD5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(5001960100002)(5003600100002)(92566002)(40100003)(102836002)(77156002)(2900100001)(62966003)(122556002)(19580405001)(74316001)(19580395003)(19617315012)(2950100001)(66066001)(5002640100001)(86612001)(19625215002)(189998001)(77096005)(33656002)(99286002)(5001920100001)(15975445007)(110136002)(46102003)(16236675004)(87936001)(230783001)(2656002)(54356999)(76176999)(50986999)(86362001)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442BB9D89DA460E7F5FBA63F5AA0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2015 06:36:43.4786 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Cc: "cose@ietf.org" Subject: Re: [Cose] Nits discovered during my review of draft-schaad-cose-msg-01 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 06:36:47 -0000 --_000_BY2PR03MB442BB9D89DA460E7F5FBA63F5AA0BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSdtIG9rIHdpdGggeW91ciBhcHByb2FjaCB0byB0aGlzIGFzIHdlbGwsIENhcnN0ZW4uICBKaW0s IGRvIHlvdSB3YW50IHRvIGFwcGx5IHRoZSBwdWxsIHJlcXVlc3QgYW5kIHRoZW4gZWRpdCB0aGUg cmVzdWx0IHRvIGFwcGx5IHlvdXIgZGVzaXJlZCB0cmVhdG1lbnQgb2YgYnl0ZS9vY3RldCBvdXIg d291bGQgeW91IHByZWZlciB0aGF0IEkgdXBkYXRlIHRoZSBicmFuY2ggaW4gYSBzcGVjaWZpYyB3 YXkgZmlyc3Q/DQoNCi0tIE1pa2UNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpG cm9tOiBDYXJzdGVuIEJvcm1hbm48bWFpbHRvOmNhYm9AdHppLm9yZz4NClNlbnQ6IOKAjjYv4oCO Mjgv4oCOMjAxNSAxMToxMyBQTQ0KVG86IE1pa2UgSm9uZXM8bWFpbHRvOk1pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbT4NCkNjOiBjb3NlQGlldGYub3JnPG1haWx0bzpjb3NlQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtDb3NlXSBOaXRzIGRpc2NvdmVyZWQgZHVyaW5nIG15IHJldmlldyBvZiBk cmFmdC1zY2hhYWQtY29zZS1tc2ctMDENCg0KTWlrZSBKb25lcyB3cm90ZToNCj4gSSBhbHNvIGNo YW5nZWQgdXNlcyBvZiB0aGUgdGVybSAiYnl0ZSIgdG8gIm9jdGV0Ii4NCg0KSXQgd291bGQgYmUg bmljZSBpZiB3ZSBjb3VsZCBhdm9pZCBkb2luZyB0aGF0Lg0KSUVDIDgwMDAwLTEzIHNob3VsZCBi ZSBtYW5kYXRvcnkgcmVhZGluZyBieSBub3cuDQoNCihGb3IgdGhlIHBlZGFudGljLCB3ZSBjYW4g YWx3YXlzIGFkZCB0aGUgdXN1YWwgdGV4dDoNCiAgIEluIHRoaXMgc3BlY2lmaWNhdGlvbiwgdGhl IHRlcm0gImJ5dGUiIGlzIHVzZWQgaW4gaXRzIG5vdyBjdXN0b21hcnkNCiAgIHNlbnNlIGFzIGEg c3lub255bSBmb3IgIm9jdGV0Ii4pDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNvc2UgbWFpbGluZyBsaXN0DQpD b3NlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2UN Cg== --_000_BY2PR03MB442BB9D89DA460E7F5FBA63F5AA0BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg LS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+SSdtIG9rIHdpdGggeW91ciBhcHByb2Fj aCB0byB0aGlzIGFzIHdlbGwsIENhcnN0ZW4uJm5ic3A7IEppbSwgZG8geW91IHdhbnQgdG8gYXBw bHkgdGhlIHB1bGwgcmVxdWVzdCBhbmQgdGhlbiBlZGl0IHRoZSByZXN1bHQgdG8gYXBwbHkgeW91 ciBkZXNpcmVkIHRyZWF0bWVudCBvZiBieXRlL29jdGV0IG91ciB3b3VsZCB5b3UgcHJlZmVyIHRo YXQgSSB1cGRhdGUNCiB0aGUgYnJhbmNoIGluIGEgc3BlY2lmaWMgd2F5IGZpcnN0Pzxicj4NCjxi cj4NCi0tIE1pa2U8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8aHI+DQo8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFw dDsgZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbToNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+PGEgaHJlZj0ibWFpbHRvOmNh Ym9AdHppLm9yZyI+Q2Fyc3RlbiBCb3JtYW5uPC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWln aHQ6Ym9sZCI+U2VudDoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxz YW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+4oCONi/igI4yOC/igI4yMDE1IDExOjEzIFBNPC9z cGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZv bnQtc2l6ZToxMXB0OyBmb250LXdlaWdodDpib2xkIj5UbzoNCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+PGEgaHJlZj0i bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWlrZSBKb25lczwvYT48L3NwYW4+ PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1z aXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPkNjOg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0Ij48YSBocmVmPSJtYWls dG86Y29zZUBpZXRmLm9yZyI+Y29zZUBpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQt d2VpZ2h0OmJvbGQiPlN1YmplY3Q6DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPlJlOiBbQ29zZV0gTml0cyBkaXNjb3Zl cmVkIGR1cmluZyBteSByZXZpZXcgb2YgZHJhZnQtc2NoYWFkLWNvc2UtbXNnLTAxPC9zcGFuPjxi cj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwcHQ7Ij4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+TWlrZSBKb25lcyB3cm90ZTo8 YnI+DQomZ3Q7IEkgYWxzbyBjaGFuZ2VkIHVzZXMgb2YgdGhlIHRlcm0gJnF1b3Q7Ynl0ZSZxdW90 OyB0byAmcXVvdDtvY3RldCZxdW90Oy48YnI+DQo8YnI+DQpJdCB3b3VsZCBiZSBuaWNlIGlmIHdl IGNvdWxkIGF2b2lkIGRvaW5nIHRoYXQuPGJyPg0KSUVDIDgwMDAwLTEzIHNob3VsZCBiZSBtYW5k YXRvcnkgcmVhZGluZyBieSBub3cuPGJyPg0KPGJyPg0KKEZvciB0aGUgcGVkYW50aWMsIHdlIGNh biBhbHdheXMgYWRkIHRoZSB1c3VhbCB0ZXh0Ojxicj4NCiZuYnNwOyZuYnNwOyBJbiB0aGlzIHNw ZWNpZmljYXRpb24sIHRoZSB0ZXJtICZxdW90O2J5dGUmcXVvdDsgaXMgdXNlZCBpbiBpdHMgbm93 IGN1c3RvbWFyeTxicj4NCiZuYnNwOyZuYnNwOyBzZW5zZSBhcyBhIHN5bm9ueW0gZm9yICZxdW90 O29jdGV0JnF1b3Q7Lik8YnI+DQo8YnI+DQpHcsO8w59lLCBDYXJzdGVuPGJyPg0KPGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpDb3NlIG1h aWxpbmcgbGlzdDxicj4NCkNvc2VAaWV0Zi5vcmc8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2UiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vY29zZTwvYT48YnI+DQo8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_BY2PR03MB442BB9D89DA460E7F5FBA63F5AA0BY2PR03MB442namprd_-- From nobody Mon Jun 29 00:48:55 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDBC01A8029 for ; Mon, 29 Jun 2015 00:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.859 X-Spam-Level: X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 hNzv_r1HyBcE for ; Mon, 29 Jun 2015 00:48:52 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01D451A8547 for ; Mon, 29 Jun 2015 00:48:51 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail11.telekom.de with ESMTP; 29 Jun 2015 09:48:47 +0200 X-IronPort-AV: E=Sophos;i="5.13,697,1427752800"; d="scan'208,217";a="697690359" Received: from he111527.emea1.cds.t-internal.com ([10.125.90.86]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 29 Jun 2015 09:48:48 +0200 Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.97]) by HE111527.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a56::7cd:5a56]) with mapi; Mon, 29 Jun 2015 09:48:46 +0200 From: To: , Date: Mon, 29 Jun 2015 09:48:45 +0200 Thread-Topic: [Cose] Consensus Call on Input Draft Adoption Thread-Index: AdCxL+Hmgcu/WzbORtG9B72W6V987ABEB9Qw Message-ID: References: <1B462EEC-67AF-4F19-B8F5-82BA36C59C8D@mit.edu> <558E83A1.6070804@tzi.org> <506C16CD-239D-43AA-9CAB-BBFDE9148CB2@ve7jtb.com> In-Reply-To: Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF4028D0764D201HE111541eme_" MIME-Version: 1.0 Archived-At: Cc: cabo@tzi.org, cose@ietf.org Subject: Re: [Cose] Consensus Call on Input Draft Adoption X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 07:48:55 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF4028D0764D201HE111541eme_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KRnJvbTogQ29zZSBbbWFpbHRvOmNvc2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIERpY2sgSGFyZHQNClNlbnQ6IFNvbm50YWcsIDI4LiBKdW5pIDIwMTUgMDE6MjANClRvOiBK b2huIEJyYWRsZXkNCkNjOiBDYXJzdGVuIEJvcm1hbm47IGNvc2VAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbQ29zZV0gQ29uc2Vuc3VzIENhbGwgb24gSW5wdXQgRHJhZnQgQWRvcHRpb24NCg0KKzEN Cg0KT24gU2F0LCBKdW4gMjcsIDIwMTUgYXQgMTI6MjkgUE0sIEpvaG4gQnJhZGxleSA8dmU3anRi QHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4gd3JvdGU6DQorMQ0KPiBPbiBK dW4gMjcsIDIwMTUsIGF0IDg6MDYgQU0sIENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPG1h aWx0bzpjYWJvQHR6aS5vcmc+PiB3cm90ZToNCj4NCj4gTWlrZSBKb25lcyB3cm90ZToNCj4+IExl dCBtZSBiZSB0aGUgZmlyc3QgdG8gc2F5IHRoYXQgSSBhcHByb3ZlIG9mIGFkb3B0aW5nIHRoaXMg ZG9jdW1lbnQgYXMgYQ0KPj4gd29ya2luZyBncm91cCBkcmFmdC4gIEnigJlkIGxpa2UgdG8gdGhh bmsgSmltIGZvciBkb2luZyB0aGUgd29yayB0bw0KPj4gcHJvZHVjZSBhIHdlbGwtdGhvdWdodC1v dXQgaW5pdGlhbCBkcmFmdC4gIEkgYmVsaWV2ZSBpdCBwcm92aWRlcyBhIHNvbGlkDQo+PiBzdGFy dGluZyBwb2ludCBmb3IgdGhlIENPU0Ugd29yay4NCj4NCj4gKzEuDQo+DQo+IEkgaG9wZSB0aGUg Y2hhaXJzIGNhbiBkZWNsYXJlIGNvbnNlbnN1cyBvbiB0aGlzIHdlbGwgYmVmb3JlIHRoZSBsb29t aW5nDQo+IEktRCBkZWFkbGluZSAoMjAxNS0wNy0wNiksIHNvIHdlIGNhbiBnbyBpbnRvIHRoZSBQ cmFndWUgbWVldGluZyB3aXRoIGENCj4gZHJhZnQtaWV0Zi1jb3NlLS4uLi4NCj4NCj4gR3LDvMOf ZSwgQ2Fyc3Rlbg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBDb3NlIG1haWxpbmcgbGlzdA0KPiBDb3NlQGlldGYub3JnPG1haWx0bzpDb3Nl QGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2UN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNvc2Ug bWFpbGluZyBsaXN0DQpDb3NlQGlldGYub3JnPG1haWx0bzpDb3NlQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlDQoNCg== --_000_CE8995AB5D178F44A2154F5C9A97CAF4028D0764D201HE111541eme_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQg Mi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xh c3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1hdXRvc3BhY2U6 bm9uZSc+PHNwYW4gbGFuZz1ERSBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4rMTwvc3Bhbj48c3BhbiBsYW5nPURF IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1ERSBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gQ29zZSBbbWFpbHRvOmNvc2UtYm91bmNlc0BpZXRmLm9y Z10gPGI+T24gQmVoYWxmIE9mIDwvYj5EaWNrIEhhcmR0PGJyPjxiPlNlbnQ6PC9iPiBTb25udGFn LCAyOC4gSnVuaSAyMDE1IDAxOjIwPGJyPjxiPlRvOjwvYj4gSm9obiBCcmFkbGV5PGJyPjxiPkNj OjwvYj4gQ2Fyc3RlbiBCb3JtYW5uOyBjb3NlQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBS ZTogW0Nvc2VdIENvbnNlbnN1cyBDYWxsIG9uIElucHV0IERyYWZ0IEFkb3B0aW9uPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD4rMTxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9u IFNhdCwgSnVuIDI3LCAyMDE1IGF0IDEyOjI5IFBNLCBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9 Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZlN2p0YkB2ZTdqdGIu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPisxPG86 cD48L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mZ3Q7IE9uIEp1biAyNywg MjAxNSwgYXQgODowNiBBTSwgQ2Fyc3RlbiBCb3JtYW5uICZsdDs8YSBocmVmPSJtYWlsdG86Y2Fi b0B0emkub3JnIj5jYWJvQHR6aS5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+Jmd0Ozxicj4mZ3Q7IE1p a2UgSm9uZXMgd3JvdGU6PGJyPiZndDsmZ3Q7IExldCBtZSBiZSB0aGUgZmlyc3QgdG8gc2F5IHRo YXQgSSBhcHByb3ZlIG9mIGFkb3B0aW5nIHRoaXMgZG9jdW1lbnQgYXMgYTxicj4mZ3Q7Jmd0OyB3 b3JraW5nIGdyb3VwIGRyYWZ0LiZuYnNwOyBJ4oCZZCBsaWtlIHRvIHRoYW5rIEppbSBmb3IgZG9p bmcgdGhlIHdvcmsgdG88YnI+Jmd0OyZndDsgcHJvZHVjZSBhIHdlbGwtdGhvdWdodC1vdXQgaW5p dGlhbCBkcmFmdC4mbmJzcDsgSSBiZWxpZXZlIGl0IHByb3ZpZGVzIGEgc29saWQ8YnI+Jmd0OyZn dDsgc3RhcnRpbmcgcG9pbnQgZm9yIHRoZSBDT1NFIHdvcmsuPGJyPiZndDs8YnI+Jmd0OyArMS48 YnI+Jmd0Ozxicj4mZ3Q7IEkgaG9wZSB0aGUgY2hhaXJzIGNhbiBkZWNsYXJlIGNvbnNlbnN1cyBv biB0aGlzIHdlbGwgYmVmb3JlIHRoZSBsb29taW5nPGJyPiZndDsgSS1EIGRlYWRsaW5lICgyMDE1 LTA3LTA2KSwgc28gd2UgY2FuIGdvIGludG8gdGhlIFByYWd1ZSBtZWV0aW5nIHdpdGggYTxicj4m Z3Q7IGRyYWZ0LWlldGYtY29zZS0uLi4uPGJyPiZndDs8YnI+Jmd0OyBHcsO8w59lLCBDYXJzdGVu PGJyPiZndDs8YnI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4mZ3Q7IENvc2UgbWFpbGluZyBsaXN0PGJyPiZndDsgPGEgaHJlZj0ibWFpbHRv OkNvc2VAaWV0Zi5vcmciPkNvc2VAaWV0Zi5vcmc8L2E+PGJyPiZndDsgPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlPC9hPjxicj48YnI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Q29zZSBtYWlsaW5n IGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOkNvc2VAaWV0Zi5vcmciPkNvc2VAaWV0Zi5vcmc8L2E+ PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29zZSIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29z ZTwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_CE8995AB5D178F44A2154F5C9A97CAF4028D0764D201HE111541eme_-- From nobody Mon Jun 29 03:38:12 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF691A8A90 for ; Mon, 29 Jun 2015 03:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 gDmQ0IQgQqGQ for ; Mon, 29 Jun 2015 03:38:09 -0700 (PDT) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (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 D87AB1A8A8D for ; Mon, 29 Jun 2015 03:38:08 -0700 (PDT) Received: by lagc2 with SMTP id c2so4424909lag.3 for ; Mon, 29 Jun 2015 03:38:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=McJA2ImNplX2MdT4xeNph4rHbcesgj46BQEyIXtADek=; b=HuMnJeccq14dDuFXlu6P40v3U1lTrFluAByUIusqL/UXKtcAhug906UQP5HOJN6TQo 7cw2E8kW/Lp9lS9IVjbTs4FDVzXXcKHDmMj6fQ6DXXFAfyYCP50iZgw/bdzCbU4EQceM prbT74Sbqi+GFlC4CnnjvMsKROYjlg9iz7DmS4e67Uh+aIY2Zzxp5z4DuIVOriDo6lC2 EC9fzYbNWvjEC9WrJcgz1OFCV+/2lia3PIBAjkMsnDh2cKWReM9lCRpevc4Qup8cgA0U bPlyGKnMpJ9fMd9aXWjN4ZGTh0pCdaWwwALQGEFDgcVhLD1NKV4/iM3wqWXe2/DAVD47 dfqg== X-Gm-Message-State: ALoCoQk4UqZ6WlWC9gsHG/AbRPm8OuXI3lkabG0hQ0iUH+Nq8jjmwqdomMe4YZ1G9x0GebOganQd X-Received: by 10.112.213.108 with SMTP id nr12mr13546111lbc.42.1435574287143; Mon, 29 Jun 2015 03:38:07 -0700 (PDT) Received: from [192.168.0.102] (89-253-76-185.customers.ownit.se. [89.253.76.185]) by mx.google.com with ESMTPSA id z9sm6382118laj.2.2015.06.29.03.38.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jun 2015 03:38:06 -0700 (PDT) Message-ID: <5591200C.5030409@sics.se> Date: Mon, 29 Jun 2015 12:38:04 +0200 From: Ludwig Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: cose@ietf.org References: <1B462EEC-67AF-4F19-B8F5-82BA36C59C8D@mit.edu> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090901080601060004000209" Archived-At: Subject: Re: [Cose] Consensus Call on Input Draft Adoption X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 10:38:11 -0000 This is a cryptographically signed message in MIME format. --------------ms090901080601060004000209 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-06-27 11:09, Mike Jones wrote: > Let me be the first to say that I approve of adopting this document as = a > working group draft. I=92d like to thank Jim for doing the work to > produce a well-thought-out initial draft. I believe it provides a soli= d > starting point for the COSE work. > > Best wishe= s, > > -- Mike > +1 /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2 Scheelev=E4gen 17 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --------------ms090901080601060004000209 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVDCC BhgwggUAoAMCAQICAwyGmDANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE1MDEwODA4MzkwNloXDTE2MDEwOTIyNDEzMFowODEXMBUGA1UE AwwObHVkd2lnQHNpY3Muc2UxHTAbBgkqhkiG9w0BCQEWDmx1ZHdpZ0BzaWNzLnNlMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxUHisC6rgXFsBHHBGo8ulz/cLX3gX5Ufhcwo rp+7djzMMuKPM1KOHq0bjWhmFe8ly8CzWdk2NS600t7IEBQWJiHLsdc12UqmNswQUpD7oqkR 1nRGT6leAHYTWapkR+nczZ2NxD+H7u4ZWVIZg0DFiTqtY8ghYHHYYy8BBoc/jHG78X4+JJAg s5XOa0gVl7W38vDvVpo14xhWEBGjzPk9WxWirqAF66PF+JEu2JD9LzFbpEq829SRXJMFB9wp oQNlH0UQ01/2sWCIBxPpHuEjxEF/V3Z/F2VsNTy4zvYrd+/MYO3w30F+bWQNZsMHEkTW1pEh iz7rQPWTBXoO8Fv0wQIDAQABo4IC1DCCAtAwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTqvKspqEm0E4R1sgsABYKk 6xDJqDAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAZBgNVHREEEjAQgQ5sdWR3 aWdAc2ljcy5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsG AQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBj ZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0 aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5 aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQEFBQADggEBAGXwFsbSfv4mMWqIk64CoxuR6ozo7J37igca7d9tpKIzVIp6xp7Zt+a+J9X3 1r4zgMRFnZJWQ5hy82W/fVDeG9i3NGMM6p7DNUrGjTbVHd11BQtbUOG9MSlyWKQbmt3Q1ElC f4SRLAQot5SPryLR2FTxQuFkMOrcDzVxNxnMgatOM2fAO8KS0H+wX+I7gC3pEnbg/eMqNgU+ Ktbc2y9naDNmLNLN65s8TT9xZyoQEn9S1oU8Xnh596OMu49Eccws8Ny+vAGESIHG4bqhMSjj rmDilL1Wj9nQahmBnID5oZD5g9s9KyqxiZIGNnowYYOpCrSeITZ1b7wg50dC8ySojnYwggY0 MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEw MjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0d Lep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiU fsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8Eg5Dp IpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebfeZuC YKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/ MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0j BBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzAB hhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nm c2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9 eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukD FUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyi kfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8Cnykh ExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b 970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCD z+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqA SfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO7cNb BIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GCUBth HSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0NbeY+ UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAwyGmDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA2MjkxMDM4MDRaMCMGCSqGSIb3DQEJBDEW BBTyAf1ehELiJaSDAoO4IMT0ZJmeITBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDIaYMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMMhpgwDQYJKoZIhvcNAQEBBQAE ggEAn8XicqGOR1D/APtV3a/5B8hPMJcAes/HGePlm47WMLaD1Pq34kdYUwUECQfDu6rDFPeE ed31M4gHj/wCZmx3LQjWBiC0h33r4UTnkJ88XVQv7a94pdrdTWxZnc3gq7cjSho/H7XuRDJE yMV2xJETLlJZK7HEpE3cgeLZZ0KEB/lwdBjtKwPKWuEHcnhSZTtgZ4p1vmkJtdIRgdLQJMcf gPW8iJNv3MP57w7SvY9RQZCkzqoUMHeBlrR++rwGjvTvUtMQDb/W69cRoCHkXdXLHBdG4Jrk r+Efiqfnt/qyOPyY3Ey4ZAZDmibyAZEJRNqlpaDT5xJIAdlTc7H/W1eb0gAAAAAAAA== --------------ms090901080601060004000209-- From nobody Tue Jun 30 09:14:21 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD32E1ACD5C for ; Tue, 30 Jun 2015 09:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 ErIgoAoPgwsd for ; Tue, 30 Jun 2015 09:14:18 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 F01CD1ACD5B for ; Tue, 30 Jun 2015 09:14:17 -0700 (PDT) Received: by oiax193 with SMTP id x193so11146488oia.2 for ; Tue, 30 Jun 2015 09:14: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-type; bh=pfgX93Idb9gVINQEhMAYIfoPuQocFzFCHUbSSpFFdaA=; b=Dd3OE+z/WSeaX4xD7pWU8L8/m7zRWLzgaKqE4MsT8s1ZkD3Tbwr4STfrMJ0BGjJuMf 7Yte5RR1JL5ELmTueZo0z8ZkwmkPMw7XvdghvjjE4oLIgH7baQp33o6dM1HL8vziB7z/ XYGVedcfme+XRCz53dM1GMQ5zCEDasM5fP+rdXPkzEINhzYfdvF/e7QZttHJKuqiKkiz +Tk8dvQLyBAoWEaT13Cz0UfPcIsffKdWMYGsjjuXNk59y2LSgb28RJQ4NiRBNl11V8TD Z1jE2EiGkklzirNDxf0Urp5gwuemYP24C6jimbNtGJj/GTnfhiMmrCxhCOwMewowq3+z cubQ== X-Received: by 10.182.63.106 with SMTP id f10mr17883461obs.87.1435680857324; Tue, 30 Jun 2015 09:14:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.116.99 with HTTP; Tue, 30 Jun 2015 09:13:57 -0700 (PDT) In-Reply-To: <000201d0b0ed$755707c0$60051740$@augustcellars.com> References: <000201d0b0ed$755707c0$60051740$@augustcellars.com> From: Dick Hardt Date: Tue, 30 Jun 2015 09:13:57 -0700 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=e89a8fb203488300ba0519be7f7c Archived-At: Cc: Mike Jones , cose@ietf.org Subject: Re: [Cose] Review of draft-schaad-cose-msg-01 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 16:14:21 -0000 --e89a8fb203488300ba0519be7f7c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Jun 27, 2015 at 8:25 AM, Jim Schaad wrote: > > > > > *From:* Cose [mailto:cose-bounces@ietf.org] *On Behalf Of *Mike Jones > *Sent:* Saturday, June 27, 2015 2:07 AM > *To:* cose@ietf.org > *Subject:* [Cose] Review of draft-schaad-cose-msg-01 > > > > In response to the call for adoption, I=E2=80=99m submitting the followin= g review > feedback on draft-schaad-cose-msg-01 > . Most of the major > comments are motivated by the goal of =E2=80=9Ckeeping simple things simp= le=E2=80=9D. > Particularly in constrained environments, it=E2=80=99s likely to be norma= l for > implementations to use only the parts of COSE they their application > needs. I believe that we should therefore optimize the representations w= e > define for the common cases, while making it possible to also gracefully > accommodate less common, if possibly more general cases as well. > > > > Also, given my role as a designer and editor of the JOSE specs, I=E2=80= =99ll say > explicitly that it=E2=80=99s not my goal to try to have all the decisions= in COSE > exactly mirror those in JOSE. Some things can clearly be simplified for > COSE, and I=E2=80=99m all for that. I plan to consider each issue on its > individual merits. That said, here=E2=80=99s my review=E2=80=A6 > > > > *MAJOR ISSUES* > > > > *1. Representations should be optimized for the single recipient case.* > > > > In JOSE, going into IESG review, =E2=80=9Csignatures=E2=80=9D or =E2=80= =9Crecipients=E2=80=9D arrays were > required for the JSON Serializations, with only general > multi-signature/multi-recipient representations being defined for JWS and > JWE. Based on feedback from numerous developers who were using JOSE for > use cases that only ever used a single signature or recipient, Richard > Barnes asked that the Flattened serializations be added to optimize for t= he > common single signature/recipient cases. Based on this developer feedbac= k, > we did this. > > > > Unless we do the same for COSE, I=E2=80=99m sure we=E2=80=99ll receive th= e same feedback > that requiring the =E2=80=9Crecipients=E2=80=9D array in use cases where = it will always > contain one element is unnecessarily complicated. We should do this now. > > > > While the argument against this could be made that =E2=80=9Cit=E2=80=99s = even more > complicated to support both the flattened and general serializations than > just the general one=E2=80=9D, I believe that in practice, this is a most= ly > specious argument. Applications will choose or build an implementation > that fits their use case =E2=80=93 either one that supports single or mul= tiple > recipients. Application profiles will choose one or the other > representation and will generally not call for both. > > > > The way to achieve this is to define a flattened representation as JOSE > did, in which header parameters about both the payload and the recipient > are carried in the top level =E2=80=9Cunprotected=E2=80=9D and =E2=80=9Cp= rotected=E2=80=9D elements. > > > > [JLS] This was discussed on the mailing list. There are a number of > trade-offs that were discussed. Please review that discussion and see if > you have something new to add. Please remember that we are looking at bo= th > the message size and the code size as criteria when making decisions. > > > I searched the mailing list for this WG and could not find this discussion. JLS: would you please provide a pointer to the discussion on this WG list so I can understand the tradeoffs? Thanks! --e89a8fb203488300ba0519be7f7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Jun 27, 2015 at 8:25 AM, Jim Schaad <ietf@augustcellars.c= om> wrote:

=C2=A0

=C2=A0

From: Cose [mailto:cose-bounces@ietf.org] On Beha= lf Of Mike Jones
Sent: Saturday, June 27, 2015 2:07 AM
= To: cose@ietf.org
Subject: [Cose] Review of draft-schaad-cose-msg-01

=C2=A0

In response to the call for adoption, I=E2=80= =99m submitting the following review feedback on draft-schaad-cose-m= sg-01.=C2=A0 Most of the major comments are motivated by the goal of = =E2=80=9Ckeeping simple things simple=E2=80=9D.=C2=A0 Particularly in const= rained environments, it=E2=80=99s likely to be normal for implementations t= o use only the parts of COSE they their application needs.=C2=A0 I believe = that we should therefore optimize the representations we define for the com= mon cases, while making it possible to also gracefully accommodate less com= mon, if possibly more general cases as well.

=C2=A0

Also, given my rol= e as a designer and editor of the JOSE specs, I=E2=80=99ll say explicitly t= hat it=E2=80=99s not my goal to try to have all the decisions in COSE exact= ly mirror those in JOSE.=C2=A0 Some things can clearly be simplified for CO= SE, and I=E2=80=99m all for that.=C2=A0 I plan to consider each issue on it= s individual merits.=C2=A0 That said, here=E2=80=99s my review=E2=80=A6<= /u>

=C2=A0

MAJOR ISSUES

=C2=A0

1.=C2=A0 Representations should= be optimized for the single recipient case.

=C2=A0

In JOSE, goin= g into IESG review, =E2=80=9Csignatures=E2=80=9D or =E2=80=9Crecipients=E2= =80=9D arrays were required for the JSON Serializations, with only general = multi-signature/multi-recipient representations being defined for JWS and J= WE.=C2=A0 Based on feedback from numerous developers who were using JOSE fo= r use cases that only ever used a single signature or recipient, Richard Ba= rnes asked that the Flattened serializations be added to optimize for the c= ommon single signature/recipient cases.=C2=A0 Based on this developer feedb= ack, we did this.

=C2=A0<= /u>

Unless we do the same for COSE, I=E2=80=99m s= ure we=E2=80=99ll receive the same feedback that requiring the =E2=80=9Crec= ipients=E2=80=9D array in use cases where it will always contain one elemen= t is unnecessarily complicated.=C2=A0 We should do this now.<= /p>

=C2=A0

Wh= ile the argument against this could be made that =E2=80=9Cit=E2=80=99s even= more complicated to support both the flattened and general serializations = than just the general one=E2=80=9D, I believe that in practice, this is a m= ostly specious argument.=C2=A0 Applications will choose or build an impleme= ntation that fits their use case =E2=80=93 either one that supports single = or multiple recipients.=C2=A0 Application profiles will choose one or the o= ther representation and will generally not call for both.

=

=C2=A0

The w= ay to achieve this is to define a flattened representation as JOSE did, in = which header parameters about both the payload and the recipient are carrie= d in the top level =E2=80=9Cunprotected=E2=80=9D and =E2=80=9Cprotected=E2= =80=9D elements.

=C2=A0

[JLS] This was discussed on the mailing list.=C2=A0= There are a number of trade-offs that were discussed.=C2=A0 Please review = that discussion and see if you have something new to add.=C2=A0 Please reme= mber that we are looking at both the message size and the code size as crit= eria when making decisions.

=C2=A0


I searched the mailing list for this WG and could not find= this discussion. JLS: would you please provide a pointer to the discussion= on this WG list so I can understand the tradeoffs? Thanks!

<= /div>

--e89a8fb203488300ba0519be7f7c-- From nobody Tue Jun 30 09:22:32 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8DD1ACE75 for ; Tue, 30 Jun 2015 09:22:30 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 3KVLskkUKjOS for ; Tue, 30 Jun 2015 09:22:23 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CC371ACDD6 for ; Tue, 30 Jun 2015 09:22:23 -0700 (PDT) Received: from hebrews (unknown [50.109.240.20]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id E553E2CA1E; Tue, 30 Jun 2015 09:22:21 -0700 (PDT) From: "Jim Schaad" To: "'Dick Hardt'" References: <000201d0b0ed$755707c0$60051740$@augustcellars.com> In-Reply-To: Date: Tue, 30 Jun 2015 09:22:36 -0700 Message-ID: <004c01d0b350$fa75e3d0$ef61ab70$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01D0B316.4E1A4020" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQE1NDqbRmt1XQuFZCU3Rn0/gnMmSwIfoXgdAZXjzIOe3o038A== Content-Language: en-us Archived-At: Cc: 'Mike Jones' , cose@ietf.org Subject: Re: [Cose] Review of draft-schaad-cose-msg-01 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 16:22:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004D_01D0B316.4E1A4020 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 Sent: Tuesday, June 30, 2015 9:14 AM To: Jim Schaad Cc: Mike Jones; cose@ietf.org Subject: Re: [Cose] Review of draft-schaad-cose-msg-01 =20 =20 =20 On Sat, Jun 27, 2015 at 8:25 AM, Jim Schaad > wrote: =20 =20 From: Cose [mailto:cose-bounces@ietf.org = ] On Behalf Of Mike Jones Sent: Saturday, June 27, 2015 2:07 AM To: cose@ietf.org =20 Subject: [Cose] Review of draft-schaad-cose-msg-01 =20 In response to the call for adoption, I=E2=80=99m submitting the = following review feedback on draft-schaad-cose-msg-01 = . Most of the = major comments are motivated by the goal of =E2=80=9Ckeeping simple = things simple=E2=80=9D. Particularly in constrained environments, = it=E2=80=99s likely to be normal for implementations to use only the = parts of COSE they their application needs. I believe that we should = therefore optimize the representations we define for the common cases, = while making it possible to also gracefully accommodate less common, if = possibly more general cases as well. =20 Also, given my role as a designer and editor of the JOSE specs, = I=E2=80=99ll say explicitly that it=E2=80=99s not my goal to try to have = all the decisions in COSE exactly mirror those in JOSE. Some things can = clearly be simplified for COSE, and I=E2=80=99m all for that. I plan to = consider each issue on its individual merits. That said, here=E2=80=99s = my review=E2=80=A6 =20 MAJOR ISSUES =20 1. Representations should be optimized for the single recipient case. =20 In JOSE, going into IESG review, =E2=80=9Csignatures=E2=80=9D or = =E2=80=9Crecipients=E2=80=9D arrays were required for the JSON = Serializations, with only general multi-signature/multi-recipient = representations being defined for JWS and JWE. Based on feedback from = numerous developers who were using JOSE for use cases that only ever = used a single signature or recipient, Richard Barnes asked that the = Flattened serializations be added to optimize for the common single = signature/recipient cases. Based on this developer feedback, we did = this. =20 Unless we do the same for COSE, I=E2=80=99m sure we=E2=80=99ll receive = the same feedback that requiring the =E2=80=9Crecipients=E2=80=9D array = in use cases where it will always contain one element is unnecessarily = complicated. We should do this now. =20 While the argument against this could be made that =E2=80=9Cit=E2=80=99s = even more complicated to support both the flattened and general = serializations than just the general one=E2=80=9D, I believe that in = practice, this is a mostly specious argument. Applications will choose = or build an implementation that fits their use case =E2=80=93 either one = that supports single or multiple recipients. Application profiles will = choose one or the other representation and will generally not call for = both. =20 The way to achieve this is to define a flattened representation as JOSE = did, in which header parameters about both the payload and the recipient = are carried in the top level =E2=80=9Cunprotected=E2=80=9D and = =E2=80=9Cprotected=E2=80=9D elements. =20 [JLS] This was discussed on the mailing list. There are a number of = trade-offs that were discussed. Please review that discussion and see = if you have something new to add. Please remember that we are looking = at both the message size and the code size as criteria when making = decisions. =20 =20 I searched the mailing list for this WG and could not find this = discussion. JLS: would you please provide a pointer to the discussion on = this WG list so I can understand the tradeoffs? Thanks! =20 [JLS] Look for the subject =E2=80=9C[Cose] Issue: Encoding for a single = recipient or structure=E2=80=9D ------=_NextPart_000_004D_01D0B316.4E1A4020 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

 

From:<= /b> = Dick Hardt [mailto:dick.hardt@gmail.com]
Sent: Tuesday, June = 30, 2015 9:14 AM
To: Jim Schaad
Cc: Mike Jones; = cose@ietf.org
Subject: Re: [Cose] Review of = draft-schaad-cose-msg-01

 

 

 

On Sat, = Jun 27, 2015 at 8:25 AM, Jim Schaad <ietf@augustcellars.com> = wrote:

 

 

From:= Cose [mailto:cose-bounces@ietf.org] On Behalf Of Mike = Jones
Sent: Saturday, June 27, 2015 2:07 AM
To: cose@ietf.org
Subject: [Cose] Review of = draft-schaad-cose-msg-01

 <= /o:p>

In response = to the call for adoption, I=E2=80=99m submitting the following review = feedback on draft-schaad-cose-msg-01.  Most of the major = comments are motivated by the goal of =E2=80=9Ckeeping simple things = simple=E2=80=9D.  Particularly in constrained environments, = it=E2=80=99s likely to be normal for implementations to use only the = parts of COSE they their application needs.  I believe that we = should therefore optimize the representations we define for the common = cases, while making it possible to also gracefully accommodate less = common, if possibly more general cases as well.

 <= /o:p>

Also, given = my role as a designer and editor of the JOSE specs, I=E2=80=99ll say = explicitly that it=E2=80=99s not my goal to try to have all the = decisions in COSE exactly mirror those in JOSE.  Some things can = clearly be simplified for COSE, and I=E2=80=99m all for that.  I = plan to consider each issue on its individual merits.  That said, = here=E2=80=99s my review=E2=80=A6

 <= /o:p>

MAJOR = ISSUES

 <= /o:p>

1.  = Representations should be optimized for the single recipient = case.

 <= /o:p>

In JOSE, = going into IESG review, =E2=80=9Csignatures=E2=80=9D or = =E2=80=9Crecipients=E2=80=9D arrays were required for the JSON = Serializations, with only general multi-signature/multi-recipient = representations being defined for JWS and JWE.  Based on feedback = from numerous developers who were using JOSE for use cases that only = ever used a single signature or recipient, Richard Barnes asked that the = Flattened serializations be added to optimize for the common single = signature/recipient cases.  Based on this developer feedback, we = did this.

 <= /o:p>

Unless we = do the same for COSE, I=E2=80=99m sure we=E2=80=99ll receive the same = feedback that requiring the =E2=80=9Crecipients=E2=80=9D array in use = cases where it will always contain one element is unnecessarily = complicated.  We should do this now.

 <= /o:p>

While the = argument against this could be made that =E2=80=9Cit=E2=80=99s even more = complicated to support both the flattened and general serializations = than just the general one=E2=80=9D, I believe that in practice, this is = a mostly specious argument.  Applications will choose or build an = implementation that fits their use case =E2=80=93 either one that = supports single or multiple recipients.  Application profiles will = choose one or the other representation and will generally not call for = both.

 <= /o:p>

The way to = achieve this is to define a flattened representation as JOSE did, in = which header parameters about both the payload and the recipient are = carried in the top level =E2=80=9Cunprotected=E2=80=9D and = =E2=80=9Cprotected=E2=80=9D elements.

 

[JLS] This was discussed on the mailing list.  = There are a number of trade-offs that were discussed.  Please = review that discussion and see if you have something new to add.  = Please remember that we are looking at both the message size and the = code size as criteria when making decisions.

 <= /o:p>

 

I = searched the mailing list for this WG and could not find this = discussion. JLS: would you please provide a pointer to the discussion on = this WG list so I can understand the tradeoffs? = Thanks!

 

[JLS]=C2=A0 Look for the = subject =E2=80=9C[Cose] Issue: Encoding for a single recipient or = structure=E2=80=9D

------=_NextPart_000_004D_01D0B316.4E1A4020-- From nobody Tue Jun 30 10:10:00 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AEE1B3217 for ; Tue, 30 Jun 2015 10:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 DuZwQhLERrc1 for ; Tue, 30 Jun 2015 10:09:56 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::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 1E8EE1B320D for ; Tue, 30 Jun 2015 10:09:56 -0700 (PDT) Received: by oiax193 with SMTP id x193so12418056oia.2 for ; Tue, 30 Jun 2015 10:09:55 -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-type; bh=s8dusKWD6gJZUpnRHxyDCgf/dHQ48NIM1uNnFWkOrnM=; b=fIZWs93Mrm8a7lbXAJNy5a6eOnz8rSl8GZQkDJAvz/P44dvOBTt5ePFoD6WzBwkZUG 5stqw+ysJGjGIGVFq0v9sr4y15fP2JAFz08s4gmGTdt220hspESNSRAY9nZbbsHxbdE9 uX2LsbCVbjHoncKp359XIy17nBmJh1F8sK5akU85vopuAplIvz3wTSxcwbMOdoQXcV48 tzF064mfy0CGnTSz5ulv4uPiSTAB/yJhFeZlbPTuXKJLePYT6iAO44Bf/c4bbMjN6Mau NErvGWLEvJMavWV60pV9FeuXQKyy101S+dtUSKLa/7bOx3rmMlrZbfOn4oxoUElu/EHl auBw== X-Received: by 10.182.63.106 with SMTP id f10mr18141641obs.87.1435684195523; Tue, 30 Jun 2015 10:09:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.116.99 with HTTP; Tue, 30 Jun 2015 10:09:36 -0700 (PDT) In-Reply-To: <004c01d0b350$fa75e3d0$ef61ab70$@augustcellars.com> References: <000201d0b0ed$755707c0$60051740$@augustcellars.com> <004c01d0b350$fa75e3d0$ef61ab70$@augustcellars.com> From: Dick Hardt Date: Tue, 30 Jun 2015 10:09:36 -0700 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=e89a8fb203487be43c0519bf46fa Archived-At: Cc: Mike Jones , cose@ietf.org Subject: Re: [Cose] Review of draft-schaad-cose-msg-01 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 17:09:58 -0000 --e89a8fb203487be43c0519bf46fa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Jim. I concur with always using an array. On Tue, Jun 30, 2015 at 9:22 AM, Jim Schaad wrote: > > > > > *From:* Dick Hardt [mailto:dick.hardt@gmail.com] > *Sent:* Tuesday, June 30, 2015 9:14 AM > *To:* Jim Schaad > *Cc:* Mike Jones; cose@ietf.org > *Subject:* Re: [Cose] Review of draft-schaad-cose-msg-01 > > > > > > > > On Sat, Jun 27, 2015 at 8:25 AM, Jim Schaad > wrote: > > > > > > *From:* Cose [mailto:cose-bounces@ietf.org] *On Behalf Of *Mike Jones > *Sent:* Saturday, June 27, 2015 2:07 AM > *To:* cose@ietf.org > *Subject:* [Cose] Review of draft-schaad-cose-msg-01 > > > > In response to the call for adoption, I=E2=80=99m submitting the followin= g review > feedback on draft-schaad-cose-msg-01 > . Most of the major > comments are motivated by the goal of =E2=80=9Ckeeping simple things simp= le=E2=80=9D. > Particularly in constrained environments, it=E2=80=99s likely to be norma= l for > implementations to use only the parts of COSE they their application > needs. I believe that we should therefore optimize the representations w= e > define for the common cases, while making it possible to also gracefully > accommodate less common, if possibly more general cases as well. > > > > Also, given my role as a designer and editor of the JOSE specs, I=E2=80= =99ll say > explicitly that it=E2=80=99s not my goal to try to have all the decisions= in COSE > exactly mirror those in JOSE. Some things can clearly be simplified for > COSE, and I=E2=80=99m all for that. I plan to consider each issue on its > individual merits. That said, here=E2=80=99s my review=E2=80=A6 > > > > *MAJOR ISSUES* > > > > *1. Representations should be optimized for the single recipient case.* > > > > In JOSE, going into IESG review, =E2=80=9Csignatures=E2=80=9D or =E2=80= =9Crecipients=E2=80=9D arrays were > required for the JSON Serializations, with only general > multi-signature/multi-recipient representations being defined for JWS and > JWE. Based on feedback from numerous developers who were using JOSE for > use cases that only ever used a single signature or recipient, Richard > Barnes asked that the Flattened serializations be added to optimize for t= he > common single signature/recipient cases. Based on this developer feedbac= k, > we did this. > > > > Unless we do the same for COSE, I=E2=80=99m sure we=E2=80=99ll receive th= e same feedback > that requiring the =E2=80=9Crecipients=E2=80=9D array in use cases where = it will always > contain one element is unnecessarily complicated. We should do this now. > > > > While the argument against this could be made that =E2=80=9Cit=E2=80=99s = even more > complicated to support both the flattened and general serializations than > just the general one=E2=80=9D, I believe that in practice, this is a most= ly > specious argument. Applications will choose or build an implementation > that fits their use case =E2=80=93 either one that supports single or mul= tiple > recipients. Application profiles will choose one or the other > representation and will generally not call for both. > > > > The way to achieve this is to define a flattened representation as JOSE > did, in which header parameters about both the payload and the recipient > are carried in the top level =E2=80=9Cunprotected=E2=80=9D and =E2=80=9Cp= rotected=E2=80=9D elements. > > > > [JLS] This was discussed on the mailing list. There are a number of > trade-offs that were discussed. Please review that discussion and see if > you have something new to add. Please remember that we are looking at bo= th > the message size and the code size as criteria when making decisions. > > > > > > I searched the mailing list for this WG and could not find this > discussion. JLS: would you please provide a pointer to the discussion on > this WG list so I can understand the tradeoffs? Thanks! > > > > [JLS] Look for the subject =E2=80=9C[Cose] Issue: Encoding for a single = recipient > or structure=E2=80=9D > --e89a8fb203487be43c0519bf46fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Jim. I concur with always using an array.

On Tue, Jun 30, 2015 = at 9:22 AM, Jim Schaad <ietf@augustcellars.com> wrote:<= br>

=C2=A0=

=C2=A0

From: Dick= Hardt [mailto:di= ck.hardt@gmail.com]
Sent: Tuesday, June 30, 2015 9:14 AM
= To: Jim Schaad
Cc: Mike Jones; cose@ietf.org
Subject: Re: [Cose] Rev= iew of draft-schaad-cose-msg-01

=C2=A0

= =C2=A0

=C2=A0

<= div>

On Sat, Jun 27, 2015 at 8:25 A= M, Jim Schaad <ietf@augustcellars.com> wrote:

=C2=A0

=C2=A0

From: Cose [mailto:cose-bounces@ietf.org] O= n Behalf Of Mike Jones
Sent: Saturday, June 27, 2015 2:07 AM<= br>To: cose@ietf.= org
Subject: [Cose] Review of draft-schaad-cose-msg-01=

=C2=A0

In response to the call for adoption, I=E2=80=99m submitt= ing the following review feedback on draft-schaad-cose-msg-01.= =C2=A0 Most of the major comments are motivated by the goal of =E2=80=9Ckee= ping simple things simple=E2=80=9D.=C2=A0 Particularly in constrained envir= onments, it=E2=80=99s likely to be normal for implementations to use only t= he parts of COSE they their application needs.=C2=A0 I believe that we shou= ld therefore optimize the representations we define for the common cases, w= hile making it possible to also gracefully accommodate less common, if poss= ibly more general cases as well.

= =C2=A0

Also, given my role as a des= igner and editor of the JOSE specs, I=E2=80=99ll say explicitly that it=E2= =80=99s not my goal to try to have all the decisions in COSE exactly mirror= those in JOSE.=C2=A0 Some things can clearly be simplified for COSE, and I= =E2=80=99m all for that.=C2=A0 I plan to consider each issue on its individ= ual merits.=C2=A0 That said, here=E2=80=99s my review=E2=80=A6

=C2=A0

= MAJOR ISSUES

=C2=A0

1.=C2=A0 Representations should be optim= ized for the single recipient case.

=C2=A0

In JOSE, going into IES= G review, =E2=80=9Csignatures=E2=80=9D or =E2=80=9Crecipients=E2=80=9D arra= ys were required for the JSON Serializations, with only general multi-signa= ture/multi-recipient representations being defined for JWS and JWE.=C2=A0 B= ased on feedback from numerous developers who were using JOSE for use cases= that only ever used a single signature or recipient, Richard Barnes asked = that the Flattened serializations be added to optimize for the common singl= e signature/recipient cases.=C2=A0 Based on this developer feedback, we did= this.

=C2=A0

Unless we do the same for COSE, I=E2=80=99m sure we=E2= =80=99ll receive the same feedback that requiring the =E2=80=9Crecipients= =E2=80=9D array in use cases where it will always contain one element is un= necessarily complicated.=C2=A0 We should do this now.

=C2=A0

While the= argument against this could be made that =E2=80=9Cit=E2=80=99s even more c= omplicated to support both the flattened and general serializations than ju= st the general one=E2=80=9D, I believe that in practice, this is a mostly s= pecious argument.=C2=A0 Applications will choose or build an implementation= that fits their use case =E2=80=93 either one that supports single or mult= iple recipients.=C2=A0 Application profiles will choose one or the other re= presentation and will generally not call for both.

=C2=A0

The way to a= chieve this is to define a flattened representation as JOSE did, in which h= eader parameters about both the payload and the recipient are carried in th= e top level =E2=80=9Cunprotected=E2=80=9D and =E2=80=9Cprotected=E2=80=9D e= lements.

=C2=A0

[JLS] This was discussed on the mailing list.=C2=A0 There are a nu= mber of trade-offs that were discussed.=C2=A0 Please review that discussion= and see if you have something new to add.=C2=A0 Please remember that we ar= e looking at both the message size and the code size as criteria when makin= g decisions.

=C2=A0

= =C2=A0

I searched the mailing l= ist for this WG and could not find this discussion. JLS: would you please p= rovide a pointer to the discussion on this WG list so I can understand the = tradeoffs? Thanks!

=C2=A0

[JLS]=C2=A0 Look for the subject =E2=80=9C[Cose] Issue: Enc= oding for a single recipient or structure=E2=80=9D

=

--e89a8fb203487be43c0519bf46fa-- From nobody Tue Jun 30 14:54:35 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAE01B32E6 for ; Tue, 30 Jun 2015 14:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 jLHc6Yfj1_46 for ; Tue, 30 Jun 2015 14:54:21 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0731.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 805461B32E8 for ; Tue, 30 Jun 2015 14:54:20 -0700 (PDT) Received: from BL2PR03MB433.namprd03.prod.outlook.com (10.141.92.19) by BL2PR03MB435.namprd03.prod.outlook.com (10.141.92.24) with Microsoft SMTP Server (TLS) id 15.1.207.12; Tue, 30 Jun 2015 21:54:01 +0000 Received: from BL2PR03MB433.namprd03.prod.outlook.com ([10.141.92.19]) by BL2PR03MB433.namprd03.prod.outlook.com ([10.141.92.19]) with mapi id 15.01.0207.004; Tue, 30 Jun 2015 21:54:01 +0000 From: Mike Jones To: Jim Schaad , "cose@ietf.org" Thread-Topic: [Cose] Review of draft-schaad-cose-msg-01 Thread-Index: AdCwuG36k7Yq5VJ4SCGK90wxv/T+IAANQXOAAKRsWeA= Date: Tue, 30 Jun 2015 21:54:01 +0000 Message-ID: References: <000201d0b0ed$755707c0$60051740$@augustcellars.com> In-Reply-To: <000201d0b0ed$755707c0$60051740$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e0:ee43::6] x-microsoft-exchange-diagnostics: 1; BL2PR03MB435; 5:jv3U7E2aERSB3FPAcrEBB/vI128wiuDKaFGDm3tMmunzWY0XRQNTKB+PRvGTg66tsiI6dp8zWe6aREm1MUhv/SnaL777IRbSmeOA6pHyfAP/sgFW7cz2KhAYmFgJ0cN34AjQ1H6OJA7agV1sWtuEFw==; 24:T4B+W2kYcNHlUK9IEbr5mNv1vdZYN/hgy0ogC88l3IIhz2HzUUiYxoDffs5tFAeC9VQY5pOXLzyRMTH4d8248UmucbxQa4fxkMYCwV5oEnQ=; 20:6x7MjCU6sA/PNZ8L4H0r+B0qa+xoeqDwWoY9S7wi6gmql4MmygiIGOO4BmGNEyU1Pzr1FlFLpUqTL/i+ZxJZjg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB435; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BL2PR03MB435; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB435; x-forefront-prvs: 06237E4555 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(76104003)(60444003)(377454003)(46034005)(74316001)(54356999)(5001960100002)(19617315012)(107886002)(5003600100002)(102836002)(33656002)(87936001)(19580395003)(575784001)(77156002)(62966003)(19625215002)(77096005)(19580405001)(86362001)(46102003)(2656002)(2950100001)(40100003)(76176999)(50986999)(15975445007)(122556002)(189998001)(92566002)(19609705001)(230783001)(16236675004)(2900100001)(5001770100001)(5002640100001)(2501003)(99286002)(76576001)(86612001)(19300405004)(3826002)(579004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB435; H:BL2PR03MB433.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; Content-Type: multipart/alternative; boundary="_000_BL2PR03MB433057E1E27B134F9775A89F5A90BL2PR03MB433namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2015 21:54:01.3216 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB435 Archived-At: Subject: Re: [Cose] Review of draft-schaad-cose-msg-01 X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 21:54:34 -0000 --_000_BL2PR03MB433057E1E27B134F9775A89F5A90BL2PR03MB433namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim, is the discussion you're referring to for my issue 2 the thread "Key m= anagement in the World of COSE" or is there an additional thread you're ref= erring to? From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Saturday, June 27, 2015 8:25 AM To: Mike Jones; cose@ietf.org Subject: RE: [Cose] Review of draft-schaad-cose-msg-01 From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Saturday, June 27, 2015 2:07 AM To: cose@ietf.org Subject: [Cose] Review of draft-schaad-cose-msg-01 In response to the call for adoption, I'm submitting the following review f= eedback on draft-schaad-cose-msg-01. Most of the major comments are motivated by the goal of "ke= eping simple things simple". Particularly in constrained environments, it'= s likely to be normal for implementations to use only the parts of COSE the= y their application needs. I believe that we should therefore optimize the= representations we define for the common cases, while making it possible t= o also gracefully accommodate less common, if possibly more general cases a= s well. Also, given my role as a designer and editor of the JOSE specs, I'll say ex= plicitly that it's not my goal to try to have all the decisions in COSE exa= ctly mirror those in JOSE. Some things can clearly be simplified for COSE,= and I'm all for that. I plan to consider each issue on its individual mer= its. That said, here's my review... MAJOR ISSUES 1. Representations should be optimized for the single recipient case. In JOSE, going into IESG review, "signatures" or "recipients" arrays were r= equired for the JSON Serializations, with only general multi-signature/mult= i-recipient representations being defined for JWS and JWE. Based on feedba= ck from numerous developers who were using JOSE for use cases that only eve= r used a single signature or recipient, Richard Barnes asked that the Flatt= ened serializations be added to optimize for the common single signature/re= cipient cases. Based on this developer feedback, we did this. Unless we do the same for COSE, I'm sure we'll receive the same feedback th= at requiring the "recipients" array in use cases where it will always conta= in one element is unnecessarily complicated. We should do this now. While the argument against this could be made that "it's even more complica= ted to support both the flattened and general serializations than just the = general one", I believe that in practice, this is a mostly specious argumen= t. Applications will choose or build an implementation that fits their use= case - either one that supports single or multiple recipients. Applicatio= n profiles will choose one or the other representation and will generally n= ot call for both. The way to achieve this is to define a flattened representation as JOSE did= , in which header parameters about both the payload and the recipient are c= arried in the top level "unprotected" and "protected" elements. [JLS] This was discussed on the mailing list. There are a number of trade-= offs that were discussed. Please review that discussion and see if you hav= e something new to add. Please remember that we are looking at both the me= ssage size and the code size as criteria when making decisions. 2. HMACs should be optimized for the no-key-management case. Particularly for constrained devices, it is unlikely that applications will= want to pay the performance penalty of generating and encrypting a key man= agement key to perform a MAC operation. Heck, they may not have credible r= andom number generation in the first place! And they are likewise unlikely= to want to pay the message size penalty of carrying the encrypted key. I'm fine with the optional ability to have key management for MACs, but the= default should be that no key management information is present in the rep= resentation. The only algorithm represented by default should be the MAC a= lgorithm - not even "dir" (direct). I suspect that this can be cleanly don= e by omitting the key management layer entirely when it's not used, rather = than explicitly using "dir" (direct). [JLS] See above. 3. Wrapped keys should be able to be represented as simply the wrapped key= value - not as an encrypted data structure with unnecessary information. Key management keys are by definition ephemeral and so no metadata needs to= be carried about them. Yes, the algorithm used to wrap the key needs to b= e represented, but this is already represented separately from the wrapped = key. A simple way to achieve this is to define an encrypted_key field to represe= nt the wrapped key, when appropriate for the algorithm. Among other benefi= ts, this will enable the use of the standard RFC 3394 AES Key Wrap algorith= ms, in the same way that JOSE uses "A128KW", etc. Note that if the working group chooses to, the ability to represent encrypt= ed keys as data structures can also be retained in parallel to this simpler= approach. Applications can then choose which method works best for them. [JLS] I don't understand this comment. This is not what the document says. 4. Simpler and more comprehensible examples are needed. I would include examples for the simplest and likely most common use cases: * HMAC without key management * Single signature * Encryption using AES Key Wrap for key management and AES GCM for c= ontent encryption Also, to be comprehensible to most readers, the examples need to include bo= th symbolic and numeric identifiers for all fields. Also, decoded represen= tations for encoded values need to be shown. For instance, the Direct MAC example in C.1 should be changed from beginnin= g like this: { 1: 3, 2: h'a10104', 4: h'546869732069732074686520636f6e74656e742e', 10: h'2ba937ca03d76c3dbad30cfcbaeef586f9c0f9ba616ad67e9205d3857 6ad9930', to beginning like this: { 1 (msg_type): 3 (MACed message), 2 (protected): h'a10104' (alg:HS256), 4 (payload): h'546869732069732074686520636f6e74656e742e', 10 (tag): h'2ba937ca03d76c3dbad30cfcbaeef586f9c0f9ba616ad67e9205d3857 6ad9930', [JLS] More examples are on the way in the future. MINOR ISSUES These issues are organized by section number, providing comments on the spe= c text in the order of appearance. 27 issues are described, labeled a, b, = c, ... aa. The section numbers and names in which they appear are included= in the write-up. 2. The COSE_MSG structure a. Change: Implementations MUST be prepared to find an integer under this label which does not correspond to the values 1 to 3. If this is found then the client MUST stop attempting to parse the structure and fail. to: Implementations MUST be prepared to find an integer under this label which does not correspond to the values 1 to 3. If this is found then the client MUST stop attempting to parse the structure and fail, unless it understands and implements the extension label value. [JLS] I do not believe that this is required. If you implement a new item,= then you don't have a pure implementation of this document and the clause = is implicit. b. This syntax needs more explanation: COSE_Tagged_MSG =3D #6.999(COSE_MSG) ; Replace 999 with TBD1 I assume that this is a use of http://tools.ietf.org/html/rfc7049#section-2= .4 (Optional Tagging of Items), but you should explicitly say that. [JLS] This falls in to the question of normative reference on CDDL. If it= is a normative reference, this is not necessary as you are expected to und= erstand CDDL. If CDDL is informational, then it would be required. c. Change: | ciphertext | 4 | TODO: Should we re-use the same as payload | | | | or not? | to: | ciphertext | 7 | For COSE_encrypt | It's cleaner not to reuse the same label value for different semantic meani= ngs. If we do that, we might come to regret it as the spec evolves. Besid= es, it's not like using another short integer value here will cause us to r= un out of them in this context. [JLS] The TODO is a marker for future discussion - There are both advantag= es and disadvantages to re-using the same label. On one hand, it is easy f= or programs to always look in the same location for the content independent= of what type of content it is. This may make things easier for items whic= h have detached content depending on how the API handles this. On the othe= r hand, an API might want to have them separate. I don't know what the an= swer for this is yet. d. Change: These two buckets are available for use in all of the structures in this document except for keys. While these buckets can be present, they may not all be usable in all instances. to: These two buckets are defined for use in all of the structures in this document except for keys. While these buckets are defined, they may not be usable or used in all instances. The new text makes it clearer that "protected" and "unprotected" can't be i= ncluded where their values can't be used. [JLS] That text does not make it any clearer to me. 3.1. COSE Headers e. Change: The field is used to indicate which protected header keys an application which is processing a message is required to understand. to: The field is used to indicate which protected header keys defined by extensions to this specification that an application that is processing a message is required to understand. The language should make it clear that "crit" is only for defining behavior= of critical extensions - not for making header parameters defined by this = spec critical. [JLS] This does not make things clearer tome. f. In Table 2, change: | jku | * | tstr | | URL to COSE key object | | | | | | | | jwk | * | COSE_Key | | contains a COSE key not | | | | | | a JWK key | | | | | | | to: | jku | * | tstr | | URL to JWK [RFC 7517] | | | | | | | | cku | * | tstr | | URL to COSE key object | | | | | | | | ck | * | COSE_Key | | contains a COSE key | | | | | | | It still makes sense to be able to represent URLs to JWK and COSE Key objec= ts. But we shouldn't call the COSE Key passed by value "jwk", since that's= misleading. [JLS] Thus the open issue marker. g. Open Issue 1. Which of the following items do we want to have stand= ardized in this document: jku, jwk, x5c, x5t, x5t#S256, x5u, zip? I would keep all of them, other than changing "jku" and "jwk" to "jku", "ck= u", and "ck" per (f) above. [JLS] This will be a discussion issue. h. Open Issue 2. I am currently torn on the question "Should epk and iv/n= once be algorithm specific or generic headers?" I would define common labels for them since they are commonly used across m= ultiple algorithms. 4. Signing Structure i. The description of "protected" says "The field MUST NOT = hold attributes about the payload being signed". Assuming that a flattened= syntax is added, this would then become something like "The field MUST NOT= hold attributes about the payload being signed unless the flattened serial= ization is being used". Other related statements throughout the document w= ould likewise need to be similarly updated. [JLS] But it is not current added - so this is not currently an actionable = statement. j. The end of the signing section says: In addition to performing the signature verification, one must also perform the appropriate checks to ensure that the key is correctly paired with the signing identity and that the appropriate authorization is done. There needs to be a reference to a place where the process of verifying the= key's association with the signing identity is described. Particular meth= ods are clearly beyond the scope of this specification but saying this litt= le about the process will likely just leave many people confused. [JLS] What do you think this should reference? 5. Encryption Object k. The introduction to this section says: In this section we describe the structure and methods to be used when doing an encryption in COSE. In COSE, we use the same techniques and structures for encrypting both the plain text and the keys used to protect the text. This is different from the approach used by both [RFC5652] and [RFC7516] where different structures are used for the plain text and for the different key management techniques. I'll note that if issue 3 is resolved (Wrapped keys should be able to be re= presented as simply the wrapped key value), this paragraph will have to be = revised accordingly. [JLS] But currently not an actionable statement. l. A generic "iv" (initialization vector) field should also be defined in = the list of parameters for the encryption object. Yes, not all algorithms = will use it, but many will. m. A "tag" (authentication tag) field should be defined in the list of par= ameters for the encryption object. Yes, not all the algorithms will use it= , but many will. [JLS] Maybe true for 'iv', however 'tag' is part of the ciphertext. 5.1.1. Direct Encryption n. The spec says: o At a minimum, the 'unprotected' field MUST contain the 'alg' parameter and SHOULD contain a parameter identifying the shared secret. SHOULD is too strong here because in some protocols, the shared secret will= already be known by methods other than an included "kid" or other key sele= ction value. A "SHOULD ... unless ..." construct like was used in similar = JOSE descriptions is probably the right thing to use here. [JLS] The ...unless... clause is confusing as hell so I do not plan to incl= ude it. The definition of SHOULD means that put it there unless you have a= good reason not to do so. 6. MAC Objects o. The "How to compute a MAC" instructions say: 5. Encrypt and encode the MAC key for each recipient of the message. This is not correct when direct key management or no key management is used= . Please revise to accurately include these cases as well. [JLS} This is correct for the current document. 7. Key Structure p. The spec says: The "key_ops" element is preferred over the "use" element as the information provided that way is more finely detailed about the operations allowed. It is strongly suggested that this element be present for all keys. Like in (n), the application may know the key usage from application contex= t, rendering the inclusion of "key_ops" unnecessary. Language something li= ke "It is strongly suggested that this element be present for all keys unle= ss this information is already know to the application through other means"= should be used to capture this. The working group should also discuss whether it wants to carry forward "us= e" for JWK compatibility, even if it is deprecated. I personally would be = in favor of doing so. [JLS] If you think this, then please open it as a discussion issue. I don'= t see any good use for it that is not better served by 'key_ops'. This is = doubly true given that the W3C Crypto group q. I would define short numeric values that correspond to the defines "key= _ops" string values. I'd do the same for the "use" values. [JLS] Yes this will be happening going forward. 8. CBOR Encoder Restrictions r. The spec says: o All parsers used SHOULD fail on both parsing and generation if the same label is used twice as a key for the same map. I would strongly prefer that the "SHOULD" be changed to "MUST". CBOR doesn= 't have the same legacy of lax parsers that we inherited from JavaScript/EC= MAscript for JSON. Let's not open the door to them! 9.5 COSE Algorithm Registry s. I would add an additional "JOSE algorithm name" field to this registry,= whose value is the corresponding "Algorithm Name" entry in the IANA JSON W= eb Signature and Encryption Algorithms registry at http://www.iana.org/assi= gnments/jose/jose.xhtml#web-signature-encryption-algorithms, if such an ent= ry exists. This will tie the two registries together so that definitions o= f algorithms already defined by JOSE need not be repeated for COSE. In many cases then, the COSE algorithms draft (or section) can just cite th= e definition in RFC 7518 and register the corresponding short numeric label= for COSE use. [JLS] Do we have a reason to believe that COSE implementers are going to ha= ve a larger overlap with JOSE implementers? 9.8.1 COSE Security Message t. Besides registering the MIME type "application/cose", I would also regi= ster one for a base64url encoded COSE message - an idea first described to = me by Joe Hildebrand. It could be called "application/cose+base64url" or s= omething of that ilk. [JLS] I would expect the media-type reviewers to object to that because th= is is a transport encoding not a content encoding. Do you have a reason to= believe otherwise? 9.8.2 COSE Key Media Type u. "application/jwk+json" should be changed to something like "application= /cose-key" and "application/jwk-set+json" should be changed to something li= ke "application/cose-key-set". 11.2. Informative References v. The date on the AES-GCM reference (SP 800-38D) should be November 2007 = - not June 2015. Appendix A. AEAD and AE Algorithms w. The spec says: This authentication value may be: o A separately generated tag computed by both the encrypter and decrypter and then compared by the decryptor. This tag value may be either placed at the end of the cipher text (the decision we made) or kept separately (the decision made by the JOSE working group). This is the approach followed by AES-GCM [AES-GCM] and AES-CCM [RFC3610]. The last sentence is not true, as written. The AES-GCM spec describes "the= ciphertext and tag outputs" - not a single combined output. Common implem= entations correspond to this, such as the implementation of GCM in .NET. The CCM description in RFC 3610 Section 2.4 describes the output using the = text "The final result c consists of the encrypted message followed by the = encrypted authentication value U", which admits either implementation. Lik= ewise, at least the .NET CCM implementation produces separate ciphertext an= d authentication tag values. Whether the tag should be separate or automatically appended to the ciphert= ext isn't a hill I'm going to die on (although the working group should dis= cuss this and make an explicit decision in this regard), but the text descr= ibing the decision should at least be changed to be accurate. [JLS] Wrong reference -will correct. Appendix C. Examples x. The uses of strings and corresponding labels such as those that follow = are confusing - especially since key ID values are binary in COSE. A fragm= ent of such an example that confused me was: 3: { 5: "bilbo.baggins@hobbiton.example" }, There are similar strings in some of the other examples that I also couldn'= t wrap my head around. [JLS] My code does not match the spec here. Originally they were strings. Appendix D. COSE Header Algorithm Label Table y. I would change the term "Header Algorithm" to "Header Parameter". (I s= uspect this was a cut-and-paste error.) [JLS] I have not settled on a consistent set of terms for this yet. I need= to do so and then make a pass to correct them all. I don't think that som= e of the terms I am currently using are sufficiently distinct to make it ea= sy to figure things out. z. In Appendix D and Appendix E, I would call out that the names in the "n= ame" columns correspond to names defined in RFC 7518. [JLS] These tables are disappearing as part of the add the algorithms to th= e document exercise. Appendix F. COSE General Values aa. This seems confused, as it mixes "kty" values (EC=3D1, RSA=3D2, oct=3D= 3) with curve values (P256=3D4, P521=3D5). I would keep these separate. A= lso, wherever the curve names are defined, I would also include P384, as JO= SE did. [JLS] That may happen in the future. I just needed a table to put things i= n for now. NITS I will be submitting spelling and grammar corrections as a GitHub pull requ= est against the spec repository rather than detail them here. I'll post th= e pull request link once it's been created. CONCLUSIONS I'd like to thank Jim for doing the work to produce a well-thought-out init= ial draft. I believe it provides a solid starting point for the COSE work. I'd be willing to produce specific proposed edits for any/all of the above = issues and comments, should the editors find that useful. Best wishes, -- Mike --_000_BL2PR03MB433057E1E27B134F9775A89F5A90BL2PR03MB433namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jim, is the discussion= you’re referring to for my issue 2 the thread “Key management = in the World of COSE” or is there an additional thread you’re r= eferring to?

 

From: Jim Scha= ad [mailto:ietf@augustcellars.com]
Sent: Saturday, June 27, 2015 8:25 AM
To: Mike Jones; cose@ietf.org
Subject: RE: [Cose] Review of draft-schaad-cose-msg-01

 

 

 

From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Saturday, June 27, 2015 2:07 AM
To: cose@ietf.org
Subject: [Cose] Review of draft-schaad-cose-msg-01

 

In response to the call for adoption, I’m subm= itting the following review feedback on draft-schaa= d-cose-msg-01.  Most of the major comments are motivated by the go= al of “keeping simple things simple”.  Particularly in con= strained environments, it’s likely to be normal for implementations to use only the parts of COSE they their application needs.  I believ= e that we should therefore optimize the representations we define for the c= ommon cases, while making it possible to also gracefully accommodate less c= ommon, if possibly more general cases as well.

 

Also, given my role as a designer and editor of the = JOSE specs, I’ll say explicitly that it’s not my goal to try to= have all the decisions in COSE exactly mirror those in JOSE.  Some th= ings can clearly be simplified for COSE, and I’m all for that.  I plan to consider each issue on its individual merits.&nb= sp; That said, here’s my review…

 

MAJOR ISSUES

 

1.  Representations should be optimized for = the single recipient case.

 

In JOSE, going into IESG review, “signatures&#= 8221; or “recipients” arrays were required for the JSON Seriali= zations, with only general multi-signature/multi-recipient representations = being defined for JWS and JWE.  Based on feedback from numerous developers who were using JOSE for use cases that only ever used a single = signature or recipient, Richard Barnes asked that the Flattened serializati= ons be added to optimize for the common single signature/recipient cases.&n= bsp; Based on this developer feedback, we did this.

 

Unless we do the same for COSE, I’m sure we= 217;ll receive the same feedback that requiring the “recipients”= ; array in use cases where it will always contain one element is unnecessar= ily complicated.  We should do this now.

 

While the argument against this could be made that &= #8220;it’s even more complicated to support both the flattened and ge= neral serializations than just the general one”, I believe that in pr= actice, this is a mostly specious argument.  Applications will choose or build an implementation that fits their use case – ei= ther one that supports single or multiple recipients.  Application pro= files will choose one or the other representation and will generally not ca= ll for both.

 

The way to achieve this is to define a flattened rep= resentation as JOSE did, in which header parameters about both the payload = and the recipient are carried in the top level “unprotected” an= d “protected” elements.

 

[JLS] This was discussed o= n the mailing list.  There are a number of trade-offs that were discus= sed.  Please review that discussion and see if you have something new = to add.  Please remember that we are looking at both the message size and the code size as criteria when making decisions.=

 

2.  HMACs should be optimized for the no-key= -management case.

 

Particularly for constrained devices, it is unlikely= that applications will want to pay the performance penalty of generating a= nd encrypting a key management key to perform a MAC operation.  Heck, = they may not have credible random number generation in the first place!  And they are likewise unlikely to wan= t to pay the message size penalty of carrying the encrypted key.=

 

I’m fine with the optional ability to have key= management for MACs, but the default should be that no key management info= rmation is present in the representation.  The only algorithm represen= ted by default should be the MAC algorithm – not even “dir” (direct).  I suspect that this can be clea= nly done by omitting the key management layer entirely when it’s not = used, rather than explicitly using “dir” (direct).

 

[JLS] See above.

 

3.  Wrapped keys should be able to be repres= ented as simply the wrapped key value – not as an encrypted data stru= cture with unnecessary information.

 

Key management keys are by definition ephemeral and = so no metadata needs to be carried about them.  Yes, the algorithm use= d to wrap the key needs to be represented, but this is already represented = separately from the wrapped key.

 

A simple way to achieve this is to define an encrypt= ed_key field to represent the wrapped key, when appropriate for the algorit= hm.  Among other benefits, this will enable the use of the standard RF= C 3394 AES Key Wrap algorithms, in the same way that JOSE uses “A128KW”, etc.

 

Note that if the working group chooses to, the abili= ty to represent encrypted keys as data structures can also be retained in p= arallel to this simpler approach.  Applications can then choose which = method works best for them.

 

[JLS] I don’t unders= tand this comment.  This is not what the document says.

 

4.  Simpler and more comprehensible examples= are needed.

 

I would include examples for the simplest and likely= most common use cases:

·    &n= bsp;   HMAC without key management

·    &n= bsp;   Single signature

·    &n= bsp;   Encryption using AES Key Wrap for key management and AES GCM for con= tent encryption

 

Also, to be comprehensible to most readers, the exam= ples need to include both symbolic and numeric identifiers for all fields.&= nbsp; Also, decoded representations for encoded values need to be shown.

 

For instance, the Direct MAC example in C.1 should b= e changed from beginning like this:

 

   {

     1: 3,

     2: h'a10104',

     4: h'5468697320697320746865= 20636f6e74656e742e',

     10: h'2ba937ca03d76c3dbad30= cfcbaeef586f9c0f9ba616ad67e9205d3857

   6ad9930',

 

to beginning like this:

 

   {

     1 (msg_type): 3 (MACed mess= age),

     2 (protected): h'a10104' (a= lg:HS256),

     4 (payload): h'546869732069= 732074686520636f6e74656e742e',

     10 (tag): h'2ba937ca03d76c3= dbad30cfcbaeef586f9c0f9ba616ad67e9205d3857

   6ad9930',

 

[JLS] More examples are on= the way in the future.

 

MINOR ISSUES

 

These issues are organized by section number, provid= ing comments on the spec text in the order of appearance.  27 issues a= re described, labeled a, b, c, … aa.  The section numbers and na= mes in which they appear are included in the write-up.

 

2.  The COSE_MSG structure

 

a.  Change:

=    Implementations MUST be prepared to find an integer under this= label

=    which does not correspond to the values 1 to 3.  If this = is found

=    then the client MUST stop attempting to parse the structure an= d fail.

to:

=    Implementations MUST be prepared to find an integer under this= label

=    which does not correspond to the values 1 to 3.  If this = is found

=    then the client MUST stop attempting to parse the structure an= d fail,

=    unless it understands and implements the extension label value= .

=  

[JLS] I do not believe that this is required.  If you implem= ent a new item, then you don’t have a pure implementation of this doc= ument and the clause is implicit.

 

b.  This syntax needs more explanation:

   COSE_Tagged_MSG =3D #6.999(COSE_MSG)&nb= sp;  ; Replace 999 with TBD1

 

I assume that this is a use of http://tools.ietf.org/html/rfc7049#section-2.4 (Optional Tagging of Ite= ms), but you should explicitly say that.

 

[JLS]  This falls in = to the question of normative reference on CDDL.  If it is a normative = reference, this is not necessary as you are expected to understand CDDL.&nb= sp; If CDDL is informational, then it would be required.<= /p>

 

c.  Change:

=    | ciphertext  | 4      | TODO: S= hould we re-use the same as payload |

=    |          &= nbsp;  |        | or not? &nbs= p;            &= nbsp;           &nbs= p;         |

to:

=    | ciphertext  | 7      | For COS= E_encrypt           =             &nb= sp;   |

 

It’s cleaner not to reuse the same label value= for different semantic meanings.  If we do that, we might come to reg= ret it as the spec evolves.  Besides, it’s not like using anothe= r short integer value here will cause us to run out of them in this context.

 

[JLS]  The TODO is a = marker for future discussion – There are both advantages and disadvan= tages to re-using the same label.  On one hand, it is easy for program= s to always look in the same location for the content independent of what type of content it is.  This may make things easi= er for items which have detached content depending on how the API handles t= his.  On the other hand, an API might want to have them separate. = ;  I don’t know what the answer for this is yet.

 

d.  Change:

=   These two buckets

=    are available for use in all of the structures in this documen= t

=    except for keys.  While these buckets can be present, the= y may not

=    all be usable in all instances.

to:

=   These two buckets

=    are defined for use in all of the structures in this document<= o:p>

=    except for keys.  While these buckets are defined, they m= ay not

=    be usable or used in all instances.

=  

The new text makes it clearer that “protected&= #8221; and “unprotected” can’t be included where their va= lues can’t be used.

[JLS] That text does not m= ake it any clearer to me.

 

3.1.  COSE Headers

 

e.  Change:

=   The field is used to indicate which protected header keys=

=       an application which is processing a message= is required to

=       understand.

to:

=   The field is used to indicate which protected header keys=

=       defined by extensions to this specification = that

=       an application that is processing a message = is required to

=       understand.

 

The language should make it clear that “crit&#= 8221; is only for defining behavior of critical extensions – not for = making header parameters defined by this spec critical.

[JLS] This does not make t= hings clearer tome.

 

f.  In Table 2, change:

=    | jku      | *    = ; | tstr     |       = ;    | URL to COSE key object  |

=    |          | = ;      |       =    |           = |            &n= bsp;            |

=    | jwk      | *    = ; | COSE_Key |           = | contains a COSE key not |

=    |          | = ;      |       =    |           = | a JWK key          &nbs= p;    |

=    |          | = ;      |       =    |           = |            &n= bsp;            |

to:

=    | jku      | *    = ; | tstr     |       = ;    | URL to JWK [RFC 7517]   |=

=    |          | = ;      |       =    |           = |            &n= bsp;            |

=   | cku      | *    = | tstr     |       =     | URL to COSE key object  |

=    |          | = ;      |       =    |           = |            &n= bsp;            |

=    | ck       | *   =   | COSE_Key |         &n= bsp; | contains a COSE key     |

=    |          | = ;      |       =    |           = |            &n= bsp;            |

 

It still makes sense to be able to represent URLs to= JWK and COSE Key objects.  But we shouldn’t call the COSE Key p= assed by value “jwk”, since that’s misleading.=

[JLS] Thus the open issue = marker.

 

g.     Open Issue 1.  Which= of the following items do we want to have standardized in

       this document: = jku, jwk, x5c, x5t, x5t#S256, x5u, zip?

 

I would keep all of them, other than changing “= ;jku” and “jwk” to “jku”, “cku”, = and “ck” per (f) above.

[JLS] This will be a discu= ssion issue.

 

h.  Open Issue 2.  I am currently torn on = the question "Should epk and iv/nonce be

       algorithm speci= fic or generic headers?"

 

I would define common labels for them since they are= commonly used across multiple algorithms.

 

4.  Signing Structure

 

i.         &nb= sp;       The description of “protected” says “The field MUS= T NOT hold attributes about the payload being signed”.  Assuming= that a flattened syntax is added, this would then become something like &#= 8220;The field MUST NOT hold attributes about the payload being signed unless the flattened serialization is being used”.  Other relat= ed statements throughout the document would likewise need to be similarly u= pdated.

[JLS] But it is not curren= t added – so this is not currently an actionable statement.

 

j.  The end of the signing section says:

=    In addition to performing the signature verification, one must= also

=    perform the appropriate checks to ensure that the key is corre= ctly

=    paired with the signing identity and that the appropriate=

=    authorization is done.

 

There needs to be a reference to a place where the p= rocess of verifying the key’s association with the signing identity i= s described.  Particular methods are clearly beyond the scope of this = specification but saying this little about the process will likely just leave many people confused.

[JLS] What do you think th= is should reference?

 

5.  Encryption Object

 

k.  The introduction to this section says:=

=    In this section we describe the structure and methods to be us= ed when

=    doing an encryption in COSE.  In COSE, we use the same te= chniques and

=    structures for encrypting both the plain text and the keys use= d to

=   protect the text.  This is different from the approach use= d by both

=    [RFC5652] and [RFC7516] where different structures are used fo= r the

=    plain text and for the different key management techniques.

 

I’ll note that if issue 3 is resolved (Wrap= ped keys should be able to be represented as simply the wrapped key value), this paragraph will have to be revised accordingly.

[JLS] But currently not an= actionable statement.

 

l.  A generic “iv” (initialization = vector) field should also be defined in the list of parameters for the encr= yption object.  Yes, not all algorithms will use it, but many will.

 

m.  A “tag” (authentication tag) fi= eld should be defined in the list of parameters for the encryption object.&= nbsp; Yes, not all the algorithms will use it, but many will.

[JLS] Maybe true for ̵= 6;iv’, however ‘tag’ is part of the ciphertext.

 

5.1.1.  Direct Encryption

 

n.  The spec says:

=    o  At a minimum, the 'unprotected' field MUST contain the= 'alg'

=       parameter and SHOULD contain a parameter ide= ntifying the shared

=       secret.

 

SHOULD is too strong here because in some protocols,= the shared secret will already be known by methods other than an included = “kid” or other key selection value.  A “SHOULD ̷= 0; unless …” construct like was used in similar JOSE descriptio= ns is probably the right thing to use here.

[JLS] The …unless= 230; clause is confusing as hell so I do not plan to include it.  The = definition of SHOULD means that put it there unless you have a good reason = not to do so.

 

6.  MAC Objects

 

o.  The “How to compute a MAC” inst= ructions say:

=    5.  Encrypt and encode the MAC key for each recipient of = the message.

 

This is not correct when direct key management or no= key management is used.  Please revise to accurately include these ca= ses as well.

[JLS} This is correct for = the current document.

 

7.  Key Structure

 

p.  The spec says:

=    The "key_ops" element is preferred over the "us= e" element as the

=    information provided that way is more finely detailed about th= e

=    operations allowed.  It is strongly suggested that this e= lement be

=    present for all keys.

 

Like in (n), the application may know the key usage = from application context, rendering the inclusion of “key_ops” = unnecessary.  Language something like “It is strongly suggested = that this element be present for all keys unless this information is already know to the application through other means” should be us= ed to capture this.

 

The working group should also discuss whether it wan= ts to carry forward “use” for JWK compatibility, even if it is = deprecated.  I personally would be in favor of doing so.

[JLS] If you think this, t= hen please open it as a discussion issue.  I don’t see any good = use for it that is not better served by ‘key_ops’.  This i= s doubly true given that the W3C Crypto group

 

q.  I would define short numeric values that co= rrespond to the defines “key_ops” string values.  I’= d do the same for the “use” values.

[JLS] Yes this will be hap= pening going forward.

 

8.  CBOR Encoder Restrictions

 

r.  The spec says:

=    o  All parsers used SHOULD fail on both parsing and gener= ation if the

=       same label is used twice as a key for the sa= me map.

 

I would strongly prefer that the “SHOULD”= ; be changed to “MUST”.  CBOR doesn’t have the same = legacy of lax parsers that we inherited from JavaScript/ECMAscript for JSON= .  Let’s not open the door to them!

 

9.5  COSE Algorithm Registry

 

s.  I would add an additional “JOSE algor= ithm name” field to this registry, whose value is the corresponding &= #8220;Algorithm Name” entry in the IANA JSON Web Signature and Encryp= tion Algorithms registry at http://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-al= gorithms, if such an entry exists.  This will tie the two registri= es together so that definitions of algorithms already defined by JOSE need = not be repeated for COSE.

 

In many cases then, the COSE algorithms draft (or se= ction) can just cite the definition in RFC 7518 and register the correspond= ing short numeric label for COSE use.

[JLS] Do we have a reason = to believe that COSE implementers are going to have a larger overlap with J= OSE implementers?

 

9.8.1  COSE Security Message

 

t.  Besides registering the MIME type “ap= plication/cose”, I would also register one for a base64url encoded CO= SE message – an idea first described to me by Joe Hildebrand.  I= t could be called “application/cose+base64url” or something= of that ilk.

[JLS]  I would expect= the media-type reviewers to object to that because this is a transport enc= oding not a content encoding.  Do you have a reason to believe otherwi= se?

 

9.8.2  COSE Key Media Type

 

u.  “application/jwk+json” shou= ld be changed to something like “application/cose-key” and R= 20;application/jwk-set+json” should be changed to something like = “application/cose-key-set”.

 

11.2.  Informative References

 

v.  The date on the AES-GCM reference (SP 800-3= 8D) should be November 2007 – not June 2015.

 

Appendix A.  AEAD and AE Algorithms<= /p>

 

w.  The spec says:

=   This authentication value may be:

=    o  A separately generated tag computed by both the encryp= ter and

=       decrypter and then compared by the decryptor= .  This tag value may

=       be either placed at the end of the cipher te= xt (the decision we

=       made) or kept separately (the decision made = by the JOSE working

=       group).  This is the approach followed = by AES-GCM [AES-GCM] and

=       AES-CCM [RFC3610].

 

The last sentence is not true, as written.  The= AES-GCM spec describes “the ciphert= ext and tag outputs” – not a single combined output.&nbs= p; Common implementations correspond to this, such as the implementation of GCM in .NET.

 

The CCM description in RFC 3610 Section 2.4 describe= s the output using the text “The final result c consists of the encry= pted message followed by the encrypted authentication value U”, which= admits either implementation.  Likewise, at least the .NET CCM implementation produces separate ciphertext and authenticatio= n tag values.

 

Whether the tag should be separate or automatically = appended to the ciphertext isn’t a hill I’m going to die on (al= though the working group should discuss this and make an explicit decision = in this regard), but the text describing the decision should at least be changed to be accurate.

 

[JLS] Wrong reference R= 11;will correct.

 

Appendix C.  Examples

 

x.  The uses of strings and corresponding label= s such as those that follow are confusing – especially since key ID v= alues are binary in COSE.  A fragment of such an example that confused= me was:

=          3: {

=            5: "bilbo.baggins@hobbiton.example"

=          },

 

There are similar strings in some of the other examp= les that I also couldn’t wrap my head around.

[JLS] My code does not mat= ch the spec here.  Originally they were strings.

 

Appendix D.  COSE Header Algorithm Label Table<= o:p>

 

y.  I would change the term “Header Algor= ithm” to “Header Parameter”.  (I suspect this was a = cut-and-paste error.)

[JLS] I have not settled o= n a consistent set of terms for this yet.  I need to do so and then ma= ke a pass to correct them all.  I don’t think that some of the t= erms I am currently using are sufficiently distinct to make it easy to figure things out.

 

z.  In Appendix D and Appendix E, I would call = out that the names in the “name” columns correspond to names de= fined in RFC 7518.

[JLS] These tables are dis= appearing as part of the add the algorithms to the document exercise.<= /o:p>

 

Appendix F.  COSE General Values

 

aa.  This seems confused, as it mixes “kt= y” values (EC=3D1, RSA=3D2, oct=3D3) with curve values (P256=3D4, P52= 1=3D5).  I would keep these separate.  Also, wherever the curve n= ames are defined, I would also include P384, as JOSE did.

[JLS] That may happen in t= he future.  I just needed a table to put things in for now.=

 

NITS

 

I will be submitting spelling and grammar correction= s as a GitHub pull request against the spec repository rather than detail t= hem here.  I’ll post the pull request link once it’s been = created.

 

CONCLUSIONS

 

I’d like to thank Jim for doing the work to pr= oduce a well-thought-out initial draft.  I believe it provides a solid= starting point for the COSE work.

 

I’d be willing to produce specific proposed ed= its for any/all of the above issues and comments, should the editors find t= hat useful.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; Best wishes,

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

 

--_000_BL2PR03MB433057E1E27B134F9775A89F5A90BL2PR03MB433namprd_-- From nobody Tue Jun 30 15:44:40 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271131B2A32 for ; Tue, 30 Jun 2015 15:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 3KA7pCiSS5Lc for ; Tue, 30 Jun 2015 15:44:37 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0146.outbound.protection.outlook.com [65.55.169.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A67151B332A for ; Tue, 30 Jun 2015 15:44:36 -0700 (PDT) Received: from BL2PR03MB434.namprd03.prod.outlook.com (10.141.92.22) by BL2PR03MB322.namprd03.prod.outlook.com (10.141.68.17) with Microsoft SMTP Server (TLS) id 15.1.201.11; Tue, 30 Jun 2015 22:44:35 +0000 Received: from BL2PR03MB433.namprd03.prod.outlook.com (10.141.92.19) by BL2PR03MB434.namprd03.prod.outlook.com (10.141.92.22) with Microsoft SMTP Server (TLS) id 15.1.207.12; Tue, 30 Jun 2015 22:44:33 +0000 Received: from BL2PR03MB433.namprd03.prod.outlook.com ([10.141.92.19]) by BL2PR03MB433.namprd03.prod.outlook.com ([10.141.92.19]) with mapi id 15.01.0207.004; Tue, 30 Jun 2015 22:44:33 +0000 From: Mike Jones To: Jim Schaad , "cose@ietf.org" Thread-Topic: [Cose] Issue: Encoding for a single recipient or structure Thread-Index: AdCDmTM3cpCIVDijSSWQU/yxCPpImgv5+bgA Date: Tue, 30 Jun 2015 22:44:33 +0000 Message-ID: References: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> In-Reply-To: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e0:ee43::6] x-microsoft-exchange-diagnostics: 1; BL2PR03MB434; 5:UUGydpJFRK7StuFkEpMJrVHTw3KF87Lu4ktkejm/Kq6mKqzf7rdx79qcNlpKedpxvktKkaYViV0eeMgQ0KWdo8z9gI5YZioVQ7lDEbCyReHcV/5FBkmNacb3o3ZNqt1y+oR1AfC11+SduhzR+oKyrw==; 24:YmO7zdLbXvuEmC31UH1cd65YKdliYp7i6w0L14Wx+5qcVLKPcYPTFfW1G8kNn+IJWtkAbpoRLN6dgFjR7E4uKVBoFoS+Zc9lv8Mi0vZ+OTc=; 20:yZPRySPGsNqi+mPB8jtIBS08cehxj1dR6IP3KLgUX9aFsgwSUlp7r2957WJM7WtYQKNgO47E1Wy4RjPkCvA99A== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB434; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB322; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BL2PR03MB434; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB434; x-forefront-prvs: 06237E4555 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(33656002)(19580405001)(19580395003)(87936001)(99286002)(46102003)(2656002)(92566002)(86362001)(76176999)(54356999)(74316001)(50986999)(189998001)(5001960100002)(107886002)(2501003)(122556002)(5001770100001)(15975445007)(62966003)(77156002)(76576001)(5001920100001)(102836002)(5002640100001)(77096005)(5003600100002)(2950100001)(2900100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB434; H:BL2PR03MB433.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2015 22:44:33.2197 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB434 X-Microsoft-Exchange-Diagnostics: 1; BL2PR03MB322; 2:NWX1cVbyPL4nuJISxD/crWhVc4o3Oek48FtzZeTiM7ZIt1DRtgWpleBgeP3M6nIn; 3:Beg10qhQUmADEA6ycQHhweLiL7VooTllFiWZxi3xguqg878ZlkFaH/rqaAXiOIdO25hS2dv4PvZL+ePjwVfbBbWmwfGj31QlGwWfcE43STmrrPnwZxmp3xNg2zcyy/xHo/NrRM6ZXCXRp/YUpOiNHw==; 25:QlF5gZYmA6HI0o357MvsuGnSzstILB1v5qqww70dwKrPfxjGSN3+aG1zpXn7hVKrevgs9WgXjBvHG1bi/yckuh5lv0fYRIgwZFMKaq/bbtiT9qSgwhUwNArKzhHEUCTFeRjIz0jmTnUQonjWc79fkfXdYzQ6Upj0rId2Wk+eZmGLW5VqvSyXF9VFrJJwXfTj5Pmasirg5AmanwPBQSs30W4Ye6ZCVTTEiTNHTGjI46xKkvQyxk6F8Xlq94tNDaxO9eExHus5Vn3hn8exP89oqg==; 23:0MhqH9jKHRXvW0k50Sv6LtKisyKjp0+/xGL0I0Wp8j/ndaVv0rCj/AuW9sMrxIiPjrPARjjmemzV2kDwN22rxrEmwi787TVDHfIKfkEckZy6XxrYusyXBj6FvvkZ/2/gc101yXkMjGzqySFrOLPliBBKbqyVh5GTQwrL2bNkTYew+y8ID/dfybCMI3iV4hqLcwe4og+OFXhFrYL6lka2bBUwAolp9s7d+I8mULb2lKZPeV8o/+OxSXI7/TmhvH9W X-OriginatorOrg: microsoft.com Archived-At: Subject: Re: [Cose] Issue: Encoding for a single recipient or structure X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 22:44:39 -0000 Hi Jim, Per your suggestion in response to my issue 1, I'm reviewing this thread. = (I'm also including the original message below so WG members who joined the= list when the WG was formed will see it.) First, let me ask a question to see if I correctly understand the problem w= ith your option (1) below. JWE used "alg" for the key management algorithm= and "enc" for the content encryption algorithm. Likewise, JWE used "encry= pted_key" for the encrypted key value and "ciphertext" for the encrypted pl= aintext. Since there were no name collisions, all could live in the top-le= vel JSON object. Whereas, your current COSE draft uses the equivalent of "= alg" for both algorithms and the equivalent of "ciphertext" for both encryp= ted values, hence the label collisions you are citing below, correct? If my understanding is right, then unless a JWE-like approach were adopted = in which different labels are used for the different purposes, then yes, I = agree that (1) wouldn't work. Was this change to a single set of labels th= e intended topic of the thread "[Cose] Issue: Reuse the Enrypt structure f= or recipients"? I'm asking because a lot of the thread ended up being abou= t a different topic - whether the encrypted_key value would contain just an= encrypted bare key or the equivalent of an encrypted JWK structure. You asked if I had anything new to add to the discussion. I'll add this... Just like for JOSE, I expect that many applications will implement only the= COSE features that they need. For instance, JWT [RFC 7519] implementation= s only need to implement the JOSE Compact Serializations - not the JSON Ser= ializations. I expect there to be many COSE applications that will similar= ly only implement support for a single recipient. This would save on code = size and be simpler. I believe that applications that only use a single recipient will be the mo= st common, hence the goal stated in my review to optimize for this case. A= ssuming we take your option (1) off the table and limit discussion to only = your options (2) and (3) below, then the choice seems to be between these e= ffective grammars for the single recipient case: (2) recipients: {recipient_data} (3) recipients: [{recpient_data}] If you're only ever building code for the single recipient case, then (2) i= s simpler. But I agree that if you're using code that supports multiple re= cipients, then (3) is simpler, if somewhat less elegant. What do others think about this tradeoff? -- Mike -----Original Message----- From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Thursday, April 30, 2015 3:59 PM To: cose@ietf.org Subject: [Cose] Issue: Encoding for a single recipient or structure Question: Flattened encoding - a) Roll into parent map b) Just be a map c) Single element in array Discussion: A late addition to the JOSE specification was the ability to fold a single = recipient map into the base encryption or signature map. This is doable be= cause the keys for all of the maps in question are unique. This would not = be true if the issue on reusing the encryption body for the recipient struc= ture is accepted. This issue is being discussed in a separate mail thread = (but is current). If arrays were to be used at the top level, one just app= ends the elements to the end of the base structure (see examples in the cu= rrent document). There are three different options that can be selected at this point: 1) The recipient/signature map is folded into the encryption/signing messa= ge top level. If we accept the change for using the same structure for bot= h the encryption body and the recipients, this is not a viable option due t= o collisions of keys in the map. 2) The recipient/signature element in the base map is permitted to be eith= er an array of recipient/signature elements or a single recipient/signature= map. This option was rejected by the JOSE group as being too complicated = for programmers to deal with. The cost of this option is 2 bytes over opti= on one. (One byte for the recipients key, one byte for the map marker.)=20 CDDL grammar would be: recipients: [+[recipient_data]] / {recipient_data} 3) We do not support any special form of dealing with a single recipient. The cost of this option is 3 bytes over option one. (One byte for the reci= pients key, one byte for the array marker, one byte for the map marker.) CDDL grammar would be: recipients: [+[recpient_data]] _______________________________________________ Cose mailing list Cose@ietf.org https://www.ietf.org/mailman/listinfo/cose From nobody Tue Jun 30 15:58:48 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F321ACC8F for ; Tue, 30 Jun 2015 15:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 j5z_Ksa1rCzg for ; Tue, 30 Jun 2015 15:58:43 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE7CD1AC431 for ; Tue, 30 Jun 2015 15:58:42 -0700 (PDT) Received: from hebrews (unknown [50.109.240.20]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 9281038F16 for ; Tue, 30 Jun 2015 15:58:41 -0700 (PDT) From: "Jim Schaad" To: Date: Tue, 30 Jun 2015 15:58:54 -0700 Message-ID: <002f01d0b388$57a1cc90$06e565b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdCzawyxSrx7crBqRU6O1oap4YBQYw== Content-Language: en-us Archived-At: Subject: [Cose] AES based MAC algorithm X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 22:58:47 -0000 In doing the work on getting algorithms into the document I ended up with a "Which one" question. AES-MAC has historically been the block cipher MAC algorithm used by most people. In part because it has been around the longest. It does the traditional AES-CBC mode of encryption and then takes the last block of the output as the MAC value. AES-CMAC (also known as AES-OMAC1) is a variant of the same algorithm which uses one extra encryption operation and an XOR operation at the end of the process to provide higher security than is available with AES-MAC. Details of this algorithm can be found in RFC 4493. Do people have a preference as to which of these two algorithms is specified? My personal preference leans towards using the newer algorithm as there is not a significant performance penalty and it appears to have better security properties. Jim From nobody Tue Jun 30 16:21:07 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8157C1B3359 for ; Tue, 30 Jun 2015 16:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 arqr-b-veZRO for ; Tue, 30 Jun 2015 16:21:01 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0724.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:724]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0627C1B2E56 for ; Tue, 30 Jun 2015 16:21:00 -0700 (PDT) Received: from BL2PR03MB434.namprd03.prod.outlook.com (10.141.92.22) by BL2PR03MB274.namprd03.prod.outlook.com (10.255.231.19) with Microsoft SMTP Server (TLS) id 15.1.213.10; Tue, 30 Jun 2015 23:20:41 +0000 Received: from BL2PR03MB433.namprd03.prod.outlook.com (10.141.92.19) by BL2PR03MB434.namprd03.prod.outlook.com (10.141.92.22) with Microsoft SMTP Server (TLS) id 15.1.207.12; Tue, 30 Jun 2015 23:20:40 +0000 Received: from BL2PR03MB433.namprd03.prod.outlook.com ([10.141.92.19]) by BL2PR03MB433.namprd03.prod.outlook.com ([10.141.92.19]) with mapi id 15.01.0207.004; Tue, 30 Jun 2015 23:20:39 +0000 From: Mike Jones To: Jim Schaad , "cose@ietf.org" Thread-Topic: [Cose] AES based MAC algorithm Thread-Index: AdCzawyxSrx7crBqRU6O1oap4YBQYwAHv6EQ Date: Tue, 30 Jun 2015 23:20:39 +0000 Message-ID: References: <002f01d0b388$57a1cc90$06e565b0$@augustcellars.com> In-Reply-To: <002f01d0b388$57a1cc90$06e565b0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e0:ee43::6] x-microsoft-exchange-diagnostics: 1; BL2PR03MB434; 5:+uFcOypp2NeYfsCpW1bC5p3+W0BENidS55m5JieZNliejVLlZIqZcsDHJyu4fl+SNMwy5OBxDaBUM7TYkKq8qIiHEuzqM5Uu3tSKvIU4Qi111ffj5WG0zfaVpIyZWv0TbBBchSx9l6N+6veYxDlNyA==; 24:PakqG4j44wogxWUQeNHezfAF1zVjwnvj3zdBOOQoyXDeTq/s6FSILqoezSkMoY1u3VgeqWTQBIBPtntX3aD5JkOSFkZuJpZUKxnAV1dS8Ng=; 20:0b6Il5cYfh7jWQj15xY0HIOfNHqmTWQxsC69NDQgH32RrD6XMLXMEV2+y1ostgEx7P52ZvDdEVrtjIWYwdVLvA== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB434; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB274; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BL2PR03MB434; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB434; x-forefront-prvs: 06237E4555 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(52314003)(13464003)(33656002)(19580405001)(19580395003)(86612001)(87936001)(99286002)(46102003)(2656002)(92566002)(99936001)(86362001)(76176999)(54356999)(74316001)(50986999)(189998001)(5001960100002)(107886002)(2501003)(5001770100001)(15975445007)(40100003)(5890100001)(62966003)(77156002)(76576001)(5001920100001)(102836002)(5002640100001)(5003600100002)(77096005)(2900100001)(2950100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB434; H:BL2PR03MB433.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/mixed; boundary="_002_BL2PR03MB433794DEE4787CD5A4B26A6F5A90BL2PR03MB433namprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2015 23:20:39.3013 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB434 X-Microsoft-Exchange-Diagnostics: 1; BL2PR03MB274; 2:3zmhaHaWYLTrYY34ZRONBiL3pShrMmIPsFGE0M9ELOT2/3i5+pVW0ZGqHNV9BuMs; 3:0GxbuuKkcgE0DlWqY1DcFR/c6phqZ3au2g4IB5GAb9v2r/tR3NSn/+v7sBE4ILJ/Zc1FvztTF0JdshQikjD3sDKFAVNc8m6BLg5CI6ZT0+h4roDwdlgReK3k0n9LdnGeH3aQPQiNf+WzytOGtDfZuQ==; 25:dXNdrVm2akU96UbZZ2hP00kgfLnUzoZ9xiuDT3/BKE90JLIqwrNlsdPZrh2t+lxXxP8z3fqWboveECEVcRrDidEj/YfBPBuDEhMeXFjvcIMg+zqDyGQ9F/L1/5l0CR+vveI3UlWiRX81vgZRCMW1JLHK3D5sV1w2ftRR7zbgc/WkirXn8XHoabzIB+QGnXQ5fGF4upNCPVVK5UzPYRV8LHEBLkAsMGi64wkT7cAKr57TN2XKieHxTv1Do8R5ich2ADY53nQDTZ00ot1q7XchDg==; 23:D/aOsxSQghRxlF3vS9tE6qixZ0tm22WmNv7IBBcul/zh0hYVzn5FR9U9RNUZHVFuvRj1Gtox/P8p7GU9aJA0wdGwuLdKAPVDoXnfBMSTep7z3Wf3uIwya9q8Myqt8udm1NXCL1Ek775F54AYl4j6zPrnM0WSdjkQz2/jsPGNjYOmjGfdRNlJAYaMbB3hkzcV79eaDS9pp+oW2hahj8z/ee/vsaPTHWIsYUVviw1n7fTstWP+YscOdmeHF7Laog8Y X-OriginatorOrg: microsoft.com Archived-At: Subject: Re: [Cose] AES based MAC algorithm X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 23:21:03 -0000 --_002_BL2PR03MB433794DEE4787CD5A4B26A6F5A90BL2PR03MB433namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Do you have data on how commonly available implementations of these algorit= hms are to help inform the choice? As you know, in JOSE we drove the set o= f algorithm choices off of a survey of which algorithms were implemented on= which common development platforms. (See the attached spreadsheet.) I realize that in this case, the right sets of development platforms to sur= vey may be different than the largely Web-targeted development platforms th= at JOSE surveyed. For COSE, the right tools are more likely to be embedded= systems development platforms. Anyway, if we can make this choice based on data, that would be good. If t= he data shows that people will have to largely build AES-MAC or AES-CMAC fr= om scratch because their platforms don't support either of them, then I agr= ee with your preference for AES-CMAC. -- Mike -----Original Message----- From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Tuesday, June 30, 2015 3:59 PM To: cose@ietf.org Subject: [Cose] AES based MAC algorithm In doing the work on getting algorithms into the document I ended up with a= "Which one" question. AES-MAC has historically been the block cipher MAC algorithm used by most p= eople. In part because it has been around the longest. It does the tradit= ional AES-CBC mode of encryption and then takes the last block of the outpu= t as the MAC value. AES-CMAC (also known as AES-OMAC1) is a variant of the same algorithm which= uses one extra encryption operation and an XOR operation at the end of the= process to provide higher security than is available with AES-MAC. Detail= s of this algorithm can be found in RFC 4493. Do people have a preference as to which of these two algorithms is specifie= d? My personal preference leans towards using the newer algorithm as there= is not a significant performance penalty and it appears to have better sec= urity properties. Jim _______________________________________________ Cose mailing list Cose@ietf.org https://www.ietf.org/mailman/listinfo/cose --_002_BL2PR03MB433794DEE4787CD5A4B26A6F5A90BL2PR03MB433namprd_ Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="Support for JWA Crypto Algorithms.xlsx" Content-Description: Support for JWA Crypto Algorithms.xlsx Content-Disposition: attachment; filename="Support for JWA Crypto Algorithms.xlsx"; size=18750; creation-date="Mon, 23 Jul 2012 22:38:19 GMT"; modification-date="Sat, 28 Jul 2012 02:24:02 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDF3RNAiwEAAJQGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM VclqwzAQvRf6D0bXEittoZQSp4cuxzaQ9AMUa2KL2JLQTNPk7ztWFtqQBZNAe7GwpXnLDHruPc7r KplBQONsJq7TrkjA5k4bW2TiY/TauRcJkrJaVc5CJhaA4rF/edEbLTxgwtUWM1ES+QcpMS+hVpg6 D5Z3Ji7Uivg1FNKrfKoKkDfd7p3MnSWw1KEGQ/R7zzBRnxUlL3P+vFQyNlYkT8tzDVUmlPeVyRWx UDmzeouk4yYTk4N2+WfN0Cn6AEpjCUB1lfpgmDEMgYiNoZA7OQNU2I505SrlyigMS+Pxiq3vYWh2 9rta1b3zOILRkAxUoDdVs3c5r+SXC9Oxc9P0MEjb1sQWpbUydq37AH88jDIu12cW0viLwC113PwT Hbd/pIP4zoGMz9NHEmGODABpUQGe2e0S9BhzqQLoIfFtLs4u4Cf2ER2kxtwBGZfTe/47qiLoIX6O uEFwHjlFA7SfwjqymuqOZyAIZGATWrsu/4aRI7g94VYwQ5PxGvQObhn/Kf1vAAAA//8DAFBLAwQU AAYACAAAACEAtVUwI/UAAABMAgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySz07DMAzG70i8Q+T7 6m5ICKGlu0xIuyFUHsAk7h+1jaMkQPf2hAOCSmPb0fbnzz9b3u7maVQfHGIvTsO6KEGxM2J712p4 rZ9WD6BiImdpFMcajhxhV93ebF94pJSbYtf7qLKLixq6lPwjYjQdTxQL8exypZEwUcphaNGTGahl 3JTlPYa/HlAtPNXBaggHeweqPvo8+bK3NE1veC/mfWKXToxAnhM7y3blQ2YLqc/bqJpCy0mDFfOc 0xHJ+yJjA54m2lxP9P+2OHEiS4nQSODzPN+Kc0Dr64Eun2ip+L3OPOKnhOFNZPhhwcUPVF8AAAD/ /wMAUEsDBBQABgAIAAAAIQDeCf0oAgEAANQDAAAaAAgBeGwvX3JlbHMvd29ya2Jvb2sueG1sLnJl bHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8k89qwzAMxu+DvYPRfXGSbmWU Or2MQa9b9wAmUeLQxDaW9idvP5NDukDJLqEXgyT8fT/Qp/3hp+/EFwZqnVWQJSkItKWrWtso+Di9 PjyDINa20p2zqGBAgkNxf7d/w05z/ESm9SSiiiUFhtnvpKTSYK8pcR5tnNQu9JpjGRrpdXnWDco8 Tbcy/NWAYqYpjpWCcKw2IE6Dj87/a7u6bkt8ceVnj5avWMhvF85kEDmK6tAgK5haJMfJJonEIK/D 5DeGyZdgshvDZEsw2zVhyOiA1TuHmEK6rGrWXoJ5WhWGhy6GfgoMjfWS/eOa9hxPCS/uYynHd9qH nN1i8QsAAP//AwBQSwMEFAAGAAgAAAAhALq0cdpiAQAAcQIAAA8AAAB4bC93b3JrYm9vay54bWyM Uk1PwzAMvSPxH6LcWdruQ9u0dhICxC4IibGdQ+Ou0dKkSlK6/XvcTC1DcOBkO3559nvJan2qFPkE 66TRKY1HESWgcyOkPqT0fft0N6fEea4FV0ZDSs/g6Dq7vVm1xh4/jDkSJNAupaX39ZIxl5dQcTcy NWjsFMZW3GNpD8zVFrhwJYCvFEuiaMYqLjW9MCztfzhMUcgcHkzeVKD9hcSC4h7Xd6WsHc1WhVSw uygivK5feIV7nxQlijv/KKQHkdIplqaFHwe2qe8bqbC7GEdjyrJB5KslAgreKL9FeT07+pVMkmTW ITsrdhJa932pK8lpL7UwbUonc7T23FdxglUbWnspfIlU8XSR9GfPIA+lT+ksxlvIzq7og4E4JkSi g7q3ztQYX6qLGxSAuV1KTOxGxB3DLzTOGtCYD+jkT/T4Co35gA4usUCEK+Vc5WhVF8ISk+ksCdNZ /1uyLwAAAP//AwBQSwMEFAAGAAgAAAAhAPtipW2UBgAApxsAABMAAAB4bC90aGVtZS90aGVtZTEu eG1s7FlPb9s2FL8P2HcgdG9tJ7YbB3WK2LGbrU0bxG6HHmmZllhTokDSSX0b2uOAAcO6YZcBu+0w bCvQArt0nyZbh60D+hX2SEqyGMtL0gYb1tWHRCJ/fP/f4yN19dqDiKFDIiTlcdurXa56iMQ+H9M4 aHt3hv1LGx6SCsdjzHhM2t6cSO/a1vvvXcWbKiQRQbA+lpu47YVKJZuVivRhGMvLPCExzE24iLCC VxFUxgIfAd2IVdaq1WYlwjT2UIwjIHt7MqE+QUNN0tvKiPcYvMZK6gGfiYEmTZwVBjue1jRCzmWX CXSIWdsDPmN+NCQPlIcYlgom2l7V/LzK1tUK3kwXMbVibWFd3/zSdemC8XTN8BTBKGda69dbV3Zy +gbA1DKu1+t1e7WcngFg3wdNrSxFmvX+Rq2T0SyA7OMy7W61Ua27+AL99SWZW51Op9FKZbFEDcg+ 1pfwG9VmfXvNwRuQxTeW8PXOdrfbdPAGZPHNJXz/SqtZd/EGFDIaT5fQ2qH9fko9h0w42y2FbwB8 o5rCFyiIhjy6NIsJj9WqWIvwfS76ANBAhhWNkZonZIJ9iOIujkaCYs0AbxJcmLFDvlwa0ryQ9AVN VNv7MMGQEQt6r55//+r5U/Tq+ZPjh8+OH/50/OjR8cMfLS1n4S6Og+LCl99+9ufXH6M/nn7z8vEX 5XhZxP/6wye//Px5ORAyaCHRiy+f/PbsyYuvPv39u8cl8G2BR0X4kEZEolvkCB3wCHQzhnElJyNx vhXDEFNnBQ6Bdgnpngod4K05ZmW4DnGNd1dA8SgDXp/dd2QdhGKmaAnnG2HkAPc4Zx0uSg1wQ/Mq WHg4i4Ny5mJWxB1gfFjGu4tjx7W9WQJVMwtKx/bdkDhi7jMcKxyQmCik5/iUkBLt7lHq2HWP+oJL PlHoHkUdTEtNMqQjJ5AWi3ZpBH6Zl+kMrnZss3cXdTgr03qHHLpISAjMSoQfEuaY8TqeKRyVkRzi iBUNfhOrsEzIwVz4RVxPKvB0QBhHvTGRsmzNbQH6Fpx+A0O9KnX7HptHLlIoOi2jeRNzXkTu8Gk3 xFFShh3QOCxiP5BTCFGM9rkqg+9xN0P0O/gBxyvdfZcSx92nF4I7NHBEWgSInpmJEl9eJ9yJ38Gc TTAxVQZKulOpIxr/XdlmFOq25fCubLe9bdjEypJn90SxXoX7D5boHTyL9wlkxfIW9a5Cv6vQ3ltf oVfl8sXX5UUphiqtGxLba5vOO1rZeE8oYwM1Z+SmNL23hA1o3IdBvc4cOkl+EEtCeNSZDAwcXCCw WYMEVx9RFQ5CnEDfXvM0kUCmpAOJEi7hvGiGS2lrPPT+yp42G/ocYiuHxGqPj+3wuh7Ojhs5GSNV YM60GaN1TeCszNavpERBt9dhVtNCnZlbzYhmiqLDLVdZm9icy8HkuWowmFsTOhsE/RBYuQnHfs0a zjuYkbG2u/VR5hbjhYt0kQzxmKQ+0nov+6hmnJTFypIiWg8bDPrseIrVCtxamuwbcDuLk4rs6ivY Zd57Ey9lEbzwElA7mY4sLiYni9FR22s11hoe8nHS9iZwVIbHKAGvS91MYhbAfZOvhA37U5PZZPnC m61MMTcJanD7Ye2+pLBTBxIh1Q6WoQ0NM5WGAIs1Jyv/WgPMelEKlFSjs0mxvgHB8K9JAXZ0XUsm E+KrorMLI9p29jUtpXymiBiE4yM0YjNxgMH9OlRBnzGVcONhKoJ+ges5bW0z5RbnNOmKl2IGZ8cx S0KclludolkmW7gpSLkM5q0gHuhWKrtR7vyqmJS/IFWKYfw/U0XvJ3AFsT7WHvDhdlhgpDOl7XGh Qg5VKAmp3xfQOJjaAdECV7wwDUEFd9TmvyCH+r/NOUvDpDWcJNUBDZCgsB+pUBCyD2XJRN8pxGrp 3mVJspSQiaiCuDKxYo/IIWFDXQObem/3UAihbqpJWgYM7mT8ue9pBo0C3eQU882pZPnea3Pgn+58 bDKDUm4dNg1NZv9cxLw9WOyqdr1Znu29RUX0xKLNqmdZAcwKW0ErTfvXFOGcW62tWEsarzUy4cCL yxrDYN4QJXCRhPQf2P+o8Jn94KE31CE/gNqK4PuFJgZhA1F9yTYeSBdIOziCxskO2mDSpKxp09ZJ Wy3brC+40835njC2luws/j6nsfPmzGXn5OJFGju1sGNrO7bS1ODZkykKQ5PsIGMcY76UFT9m8dF9 cPQOfDaYMSVNMMGnKoGhhx6YPIDktxzN0q2/AAAA//8DAFBLAwQUAAYACAAAACEAQb/4YNkAAADK AQAAIwAAAHhsL3dvcmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzrJHBTsMwDEDvSPxD5DtJ uwNCaOkuCGlXGB/gpW4b0TpRbBD7e4J2odMkLpws2/Lzk73dfS2z+aQiMbGH1jZgiEPqI48e3g7P dw9gRJF7nBOThxMJ7Lrbm+0Lzah1SKaYxVQKi4dJNT86J2GiBcWmTFw7QyoLak3L6DKGdxzJbZrm 3pXfDOhWTLPvPZR9vwFzOOW6+W92GoYY6CmFj4VYr6xwiseZKhDLSOrB2nNFzqG1VRbcdY/2Pz1y iaxUXkm1HlpWRhc9d5G39hj5R9KtPtB9AwAA//8DAFBLAwQUAAYACAAAACEA++hdR2ABAAB1AgAA GAAAAHhsL3dvcmtzaGVldHMvc2hlZXQyLnhtbIySwWrDMAyG74O9g/G9cbp16xqSlEEp62Ewxra7 4yiJaWwF213bt5+SkDLopTcJSZ9//XK6PpmW/YLzGm3G51HMGViFpbZ1xr+/trMXznyQtpQtWsj4 GTxf5/d36RHd3jcAgRHB+ow3IXSJEF41YKSPsANLlQqdkYFSVwvfOZDlMGRa8RDHz8JIbflISNwt DKwqrWCD6mDAhhHioJWB9PtGd36iGXULzki3P3QzhaYjRKFbHc4DlDOjkl1t0cmipb1P84VUE3tI rvBGK4ceqxARToxCr3deiZUgUp6WmjbobWcOqoy/zrnI08GcHw1H/y9mvdcF4r4v7MqMx32ruOrd Dl5/OFZCJQ9t+MTjG+i6CXTYRbQg9f0SSXnegFfkHoGix8urGxkkYTtZw7t0tbaetVANTUvO3MiJ I4oDdv3o8omzAkNAM2UNnRfojD2WVYhhSnq5lw+T/wEAAP//AwBQSwMEFAAGAAgAAAAhAPvoXUdg AQAAdQIAABgAAAB4bC93b3Jrc2hlZXRzL3NoZWV0My54bWyMksFqwzAMhu+DvYPxvXG6desakpRB KethMMa2u+MoiWlsBdtd27efkpAy6KU3CUmff/1yuj6Zlv2C8xptxudRzBlYhaW2dca/v7azF858 kLaULVrI+Bk8X+f3d+kR3d43AIERwfqMNyF0iRBeNWCkj7ADS5UKnZGBUlcL3zmQ5TBkWvEQx8/C SG35SEjcLQysKq1gg+pgwIYR4qCVgfT7Rnd+ohl1C85Itz90M4WmI0ShWx3OA5Qzo5JdbdHJoqW9 T/OFVBN7SK7wRiuHHqsQEU6MQq93XomVIFKelpo26G1nDqqMv865yNPBnB8NR/8vZr3XBeK+L+zK jMd9q7jq3Q5efzhWQiUPbfjE4xvougl02EW0IPX9Ekl53oBX5B6BosfLqxsZJGE7WcO7dLW2nrVQ DU1LztzIiSOKA3b96PKJswJDQDNlDZ0X6Iw9llWIYUp6uZcPk/8BAAD//wMAUEsDBBQABgAIAAAA IQBwba3KEQ4AAP9VAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1srJxbc+o4Esfft2q/A8X7 AOZO6uRMDRgOd8xld585xEmogTgLnNt8+m1Zsix1O2pNLS/gyD+1Wq3+S7JN/On3n+dT6Xt8uR6T t8dyUKmVS/HbIXk6vr08lv+1G/3WLZeut/3b0/6UvMWP5V/xtfz753/+49OP5PLn9TWObyWw8HZ9 LL/ebu8P1er18Bqf99dK8h6/wZnn5HLe3+DPy0v1+n6J909ppfOpWq/V2tXz/vhWlhYeLj42kufn 4yEOk8O3c/x2k0Yu8Wl/A/+vr8f3a2btfPAxd95f/vz2/tshOb+Dia/H0/H2KzVaLp0PD5OXt+Sy /3qCfv8MmvtDZjv9g5g/Hw+X5Jo83ypgriodpX3uVXtVsPT509MReiDCXrrEz4/lP4KHXaNbrn7+ lAbo38f4x9U4Lt32X7fxKT7c4icYp3LpryQ5bw974VsPBk3/uRQBP8lCMUZfk+RPYWwC1WrQ7DU1 IprdH27H7/EgPgH9R70B4/xf6QkcgxtV7Yd5nPk0Ssc1upSe4uf9t9Ntk/wYx8eX1xs416w0IVIi YA9Pv8L4eoCRgsYrqdlDcgIb8Fk6H0XGQaD3P9PvH8en2+tjuVvpdDqNZqPTKpcO36635PwfeSIQ XumKdVURvnXFVqvZ7jL1oJ9pg/Ct6gVBpR5w1aBHaTX4VtWa9UqzGTRr7brbUTib1oRv7ahXD9uq Inyrir1KUOulgbnefomRD+CcI0YdZQG+lYW2tuCoBpJPPYbvrJqzmQDyL60gDnQf+ZgGevDhQNfL uuhwMMgGXxyoih3ds6/x9TY6ikR0e51lQpCnAvTY1WyWBEGeBR2/JAiyLBAHyuNepd3m00cMsQxu ngfdSrfb7rA5G2TjLw5Uo20/dQVZDogDPTQ++gp6mb9wkNUUa4hPwtazTBIHqjL47hiTepZD4iCr 4RVYMeOlgRUHqiZMXbqP7jSqynksnSPD/W3/+dMl+VGCJQzcuL7vxYIYPIheiBmx0ahooepZ8oMp EqY4YeYPYQcmw3IJ6l9h3v7+udH9VP0Oc/FBIX2JQJg10mzZyIAircBGQorUbGJIiSYyMqJID1n5 UoCgDo0pgtqZUKLRtr2dFiAoKrMCpGNbmUtETGg6uA0bWRQgTdSjZUFLyMyKIl3UpYgiHRTdNUUa TdvfDUWaqKEtReq2kR0luj2NVEEDWggwNVtCEIrIpCx3D2lBumNoCX0U7hgyOQhrj2X41MOButen BBr2gSRg7tY2UP/DAgJl4FAi4K42glJnRIkeMvKFIihxxiwxYYkpS8xYYk4J1N0FSyxZYsUSEUus WWLDEluW2LkIK/1hUblj+gtrsI4YWYfTnxI4/SUB+w+dubly0zUnpEQb6X8oEVf6U4KkP0VQUo0p gQQyYYkpS8xYYk4J5OmCJZYssWKJiCXWLLFhiS1L7FyElf4wy94x/YU19+xPCZz+koBPnf4BWkRD irTRaj2UiCv/KUHynyIou8csMWGJKUvMWGJOCZz/LLFkiRVLRCyxZokNS2xZYucirPyHafaO+S+s 2dN/gLYU/QIEzd0DicBnrgCU3iFF2mihGUrEpQBKEAVQBCuAJSYsMWWJGUvMJQEXoTpodbRrXFAj SCRL3siKNRKxxJolNiyxZYmdi7A0ADlyRw0Ia/YaQDRQgGANSARkrIczQAkeUqSN1pKhROBTW0Ej PqIE0QBFsAZYYsISU5aYscRcEk4NUCMoIkveyIo1ErHEmiU2LLFliZ2LsDQAQbujBoQ1Zh0oQLAG JAIy1tkboAQPKdJGs95QIhAIbQWN+IgSRAMUwRpgiQlLTFlixhJzScCn7i5ZB6gRFJElb2TFGolY Ys0SG5bYssTORVgagJuYd9SAsMasAwUI1oBErHUAJXhIkRZKzqFEXBqgRA+58kUi4ka7Tq0eSpyx ZCDiGsHZN5EI3J/QSAdd308lYrqLOjRjiTnvyYJHljyyoq6goES8kTVrZCMJ8dRCxy2ooc31VkJm bIMaGsYdY8hSBLR2R0UIa8yqUIAg/wcSsVYFlB0hRVooxYYSMVMMjdqIEkQREnErQjJORUgEblno kSWKoM6gPs9YYs57suCRJY+sqCsothFvZM0a2UiCUYSEzNhSRTCGLEWIJy13lERqjlklihgsCsVY 6wRK+bCAaaM7S0PFuHRRgBBhKMatDAU5paEYc0broklvWuAQFgePzD28WXgwSw9mVeAOVoiHmTVv ZqMQRiSKMqNMVcKZsmUinr+Zj5dh4v8/nqqJX2CgpaOOUrdfwAREJtKOuXjUUTqFyo7JtNDtp6Fi nDKRTZkIuaooMIMyd8wjEx6Z8siMR+YFCErbBY8sFeKS/Yo3E/HIWiHy51zixwobvtKWR3ZOxJYB SOqeMhDm7NWCyoAyVAaSMVeLOpJKKH6yBG2ZTAsxQ8WYOY4SYlSAUBlQl/EkPy6wg6Qy4ZEpj8x4 ZK4QVwYvCsyg0Cw9zKx4MxGPrBVST3+YKIUgQ+4YuS1vd6eQDwJhK0E8kbvjgiAf8Jn7OqoEylAl SMac7Otosg/F7+5ACRaD7sUOFWNGIkDjPVKMGXO6caI+d9FCNy5oi1xkK0Z86YuKJnJo6gPNfKC5 gszuY5cWHszSg1kpxuwZvlyKPOystR3xa10pChp8sg3a6mp5YAm0K4CMYbSFATPsPYUhzHFLBGWo MCQDnzp/6vjmq/h5KRJGC92cGirGlRkjxVjCQAL7UsCg+X/MIxOF5BPhlK8045G5Qly9XHgwSw9m VeAOEnbEI2uF5JHY6JJ8xPEqvPVgdor5IBZ27sOces/cF+bsG0x0UaAMzX3JwGee+yjEofh9NM59 xAwV80Ek0jlnpBh37su2TIbkPotMVEv5bnha0DayO+ORuUJcvVx4MEsPZlXgDgp6xCNrheSR2OiS fMTxmrL1YHaK+SAWdu7DcN4z94U5bt4vYNCAD8TP+MGONe+TG0mSMfXRQWvDUNkRC6EWEd6AjBQE 5jRDLw5kYyaDfB4rM/lcNvFpfeoDzXyguQ+08IGWCvoggdIpY+VjKPKB1grKA7fxqbbNIDMB8Nju MuiDBLC1AP29pxaEOW4dKGBQXg3Ev6OgOb6BNuNhAdMheyBph9GChMw8p1qgDPJ5rPzJ57aJKnG2 PvWBZj7Q3Ada+EBLBUGf9eyALypWPoYiH2itoDxwG59q2wxya8GdALYWxPO5O14o00eCdE9UwKC8 Gohb+WhdaJA7p5IxQ9FC+/ihsmOlOVpfRkUMuij/ohi4jaGTw7jCSifKsWJcCTTxYKYF/qDwzHhk 7tHSwoNZejArxbiiE3nYWWs7+TWyHGNz/NAObKsqOZCdu21bD+Lp3B31QB8IUj0UMGjAB+KJCl4b 0O3RsIBpkX2StGMGq0f0UMAQPVCfqR4k49YDz0xVv0yfUXhmPDJXiMubhQez9GBWijH3Ijg6kYed tbaT64GODdEDi+zcbVt6EP+reUc9pOaY6wbFmNFroBwdKMac+5t4r6QY89qiixJnqBhXVowUY+Zf D60zXxSTb23HpGTi0dbUg5l5MHMPZuHBLD2YlQcTeTBrxeQx3HjU2nowOzdj57t4jnq/+b/u8SS5 gKH5Tp8kN5EmQmXH1ATNd2nHne+Sced71q9sZhrrXmQlE1Xiamvqwcw8mLkHs/Bglh7MyoOJPJi1 YoxLAI9aWw9m52bsfBdP5u6Y7/JBn7kTJPudumTc87tkzFxukfldMu75XTKuHBwpf9z5Lu3kc9NY 1cpLJqrE1dbUg5l5MHMPZuHBLD2YlQcTeTBrxeQR23jU2nowOzdj57t4iGTmu/vf6wUN2xXzfQdN tO/u1xUkX8QjHu0NaFFIi6aqSPy+Q19VdnLrtt8gBctvcEvc85LvADFeHODuj7ACFU3N9ND9o754 cY+Esql8QItCWjTNivJAzPIio4to8zQHKGtpYRwv88rZ6ZVxOjKO18bxRh7b0YNIWdFzR0nQMOqg eT0uXXQF1K8rKJ++B7QopEULVWSPem7d9hsmE8tvMS5Q9jdHXViB/pgzU1BD02lfnBZU+rKt9I7G gBaFWVHPGDJZETqUDdNSUVYfu+hCZZVDWb0IirLjtXG8ydC2Pr01Tu/ksR05cePAX+fyNoMQpB7x Zj4maTT6EJk0QHm2DmhRSItWqsiKRgfdzdpkkNnFdCjsbomLO/9uyUtBq1tdpL5+XUFmt0hRSKlI FVnd6qEbDpsMMruV5o7VrQa+ynTqM6UhU0GB+WjhbuVQllEDWhRaRbZLYofrHemG3A+LXyhpl7r5 VC4TKIdyl3S9rCik1CYrMoIIRVDD9ljsUUyPxWQBZX9rshg1hJV0bck82lpFdpOwidNNgnjcwyZg NGxtNCn0GxrKmh/QotAqsj0Si3EWBNYjAcsg6VFro1sE/YaGco9IUWhRtkfmys16pNZeM4/a6EKv 39BQ7hEpCi3K9shcDVmP5DpnZXaHjJqGco9IUdgwi2yPxBLiPWpqvTFj1CGjpqHcI1IUNswi2yNz /WBjBLBOoG4+BUqL8o2R8m1o5/jykr5b8lo6JN/E+x878BIzXareeVlvPoj9InhOzrThTDoNkDNd OJMuGORMD86kcy4+02g8CCkVtNOowZla0Zl6B6yly3RVm4M3V77vX+LF/vJyfLuWTvEzdKxWgeBe 5Lsv0+Nb8p6WQqp+TW7wAsvsr1d4/WkM22bxKszSc5Lcsj/AMWF3G9++vZeSyxFemJm+0fSx/J5c bpf98QYtPByfHsuXyVM6IcLrQE9xtL/cdHwDiK8uzen0KqSqT0APqvrVrZ//BwAA//8DAFBLAwQU AAYACAAAACEA1ohQeh4IAAD2WwAADQAAAHhsL3N0eWxlcy54bWzsXO1v2jgY/37S/Q9RvncBBm2p gGnQ5jSp601rJ91XAwZ8TWIuMSvsdP/7PbbjxLyEZLyFdt6kLQl++fl5tx/brQ9z37O+4zAiNGjb 1XcV28LBgA5JMG7b357ci2vbihgKhsijAW7bCxzZHzq//9aK2MLDjxOMmQVNBFHbnjA2vXGcaDDB Pore0SkO4JcRDX3E4DUcO9E0xGgY8Uq+59QqlUvHRySwZQs3/qBIIz4Kn2fTiwH1p4iRPvEIW4i2 bMsf3HwaBzREfQ+gzqt1NFBti5e15n0yCGlER+wdNOfQ0YgM8DrKptN0oKVOa0QDFlkDOgsY0ApI JVq9eQ7oS+Dy3+BrXKzTin5Y35EHX6q202kNqEdDiwFpAJn4EiAfyxI95JF+SHixEfKJt5Cfa/yD oGZczicwNv7R4UAknE6rz0tt6Csc99u2G//htYp1uNT2lnYr4s9p2v0YEuRZ3wICgomtz4+81zVK FQd+Wa1UigPP58AWKjV7QKbLQ3ZGMth9DNHaNLBj9JM1pliEgYKn5Nhl41DiIUQyAlklnpfYjWtu IeBDpwX2i+EwcOHFip+fFlOwDwGYWi4zjiyXU3ocokW11iheIaIeGXIU456wSgmZuUrzZvrxDyQY 4jketu3LumhdA1wUXEZft03+9zR99S7v3N7dgQfgur2rIzQKzfYOjvSu28xuVMgYyGifhkMIAzTv pr51Wh4eMRCLkIwn/H9Gp1xIKGPgNDutIUFjGiAPHh3ZynJNiB8gVGjbPh6SmQ9yJ33hmtQ5vJud e4HeBb7CvYnSOw+GTSBuUUNZ1RNtIArO1vIplELFgf6K/IXKS04dh1EKQC5z0zHuIjtbyaeRG9re UTqXeohls1vjf4U+an2oIefUSAdcsEIeW9dB/SxjcxBrY5R0LB24Uuozg1OQLiVLQGyMwbYPsOc9 ciP81ygx8A2wXvORFcx812efwMfDdIZPK9QjBCXxo7Tp8gUYkVWpDvXjSvCoV7LQdOotHmZ+H4eu mA6K3sTXrnA76ftHj4wDH/MJFgASRb6ElOEBExNUEZ5kIWikCOCxDARXKYJLHQG8bKEBnzqmw92H As20f4ByTAo4ukxJCdOE631lJ+my5qNcMeNiulk2k9qS1hodxXw7S2pqaYPvdZrBi4IjG5Rsqsas dAEEn8nL35QYq/elzjstpKSaL7UwMuDrAgMQciyn8/NRtlpp8GDoKUtz4B0PEHSsGHCO9NLgnQe9 suxiwkAlM8djWZZhTCCAkC1ZYwXpcGIMLSqpgc5SMYaXo2oZBFW29RKi6ROeg5EVlsDZpm9ZQIGN rwMoDOC8gILzU6xf0kh42Qx0S5ABdfLa2lJ7i3uWSEAhhB4cTu6ztD8ZvFK1crxLCRTZj4X71c7i RmIIgRv/zCDc/BLiEZmfwr9nhWwJJMB8ZNucRRVwG1ItypXRLHhnokKaRK7G/MtGZVnDD2diStDh rIAikRgVUCyP2T1RzJwFL5GYcuFpEgOPaSyUwNs6y80yGCAGUt6ObzCyIECuuGwIAO3QEMRUFya3 2jrK0ipKMhO2eIa1bXfRUIHgoe6MeIwEfF5bu+JLiavF/6A0KQ+GVi8vEoer5R/wjIXIU10At/Uq 15u6eOCLLkkNLnMpKCFra32AC1QdgCPSikPWG8aQzv6BKsN5uqpUq8PEHz5AckmkqPsylS0qEe05 YiF5jtPaEgGFXFMQ6Z8gYMfBUKtEZ8wjgV4kmqAhfdGKzOSzSqDx2bYwtPJzH0WYt8CHkOQ24+6z 0/NPxMeR9YBfrK/UR4GozPc4xEBUXyr/DDYuL7WXpt5WMgfriTeZ1tuUeEPJmsKEhuQHkJuvKoxx gIV0rC00WAwI+pUy2DTBt3qAFKTTInjhSOJlqL9nESOjxT2K2D1QS5SNJiEJnp+oS+RSFd/IAXtE /uRJI14AKCoNmaXSQd+moqJ6vYU9EvyDzCZtXEFdIYaeDypUPme9dbX5vPX21fJqtV1RFoacUp4r hSQAPAgFEP8YJq1S8QyZZExV9i4EY6oKmR4tdVaovNGC2Gm8EYeNZoyq1UXjrOMNH0vp5pL9QCGt VJ5dd+yFKqZxgAkDWCGKGQO4uwHUNhSvbaLauMlX38L6c9OV1e17K1qs5isxjHRXn2OM4BkawSIz FhMM7xEMmzDgzAPhQr7paGHAa9StLR7moAtjxtP8amtjRhuyT4AYbTDacP75EuMbTN5EHO3ZutKz S97E+AbjG8ShMpNFfKW5dOMbjG84jm/IyambbQ7Lh7b33eZQ7pKJYTacuRaHWgvx4U0zW63LJWen zJamlQsa9mX/m0oQmDSZ2IDHU3ZmY9+26xpWJ6iFLK0yRqfeK2DCGxPe8JOMZsuuvFXmp5aejGaH v87+7HKZ/WpWME2YZIxpIVU5rzApPm0SnwniLFw+WZJ7IdWGnSq5ddZ3LeZW2TAly62jKL3pRMmr sSunPVf1thPm2omiTXIv5UUp8SHECxYCzjT9vO6u5BW3/ARaqZtfxX24Quj32/wKBsPetrAFZ0RP NaW3yrKuwEsp0/CwYgS5KsChU8bveBZ3miVncWFGNMQjNPPYU/Jj206fP4v7J+FIblzqC/lOmWii bafP9/ySy6o4eQvnJe8jWHyF/61ZSNr2v3fdq+btnVu7uK50ry/q73Hjotno3l406r3u7a3brNQq vf/g4Cy/EPsGLofe48JpcTE2XAtVrd9EHlxLHcaDjcE/pt/atvYi4XNlcAC2/FcMwhH7kcWF3Z3/ AQAA//8DAFBLAwQUAAYACAAAACEAgy/oZb8EAAB4DgAAFAAAAHhsL3NoYXJlZFN0cmluZ3MueG1s vFfdkto2FL7vTN/hjK82nQFjNrvdZsA7xAsh+wMMTnbTq46wBahrS44kQ+jT9Fn6ZD3CkDiSl+aq N8z48/nT4XyfjnvXX/IMNlQqJnjfC9odDyhPRMr4qu99/DBqXXmgNOEpyQSnfW9HlXcd/vxTTykN 6MtV31trXbzxfZWsaU5UWxSU45ulkDnR+ChXviokJalaU6rzzO92Opd+Thj3IBEl133v9TmmKTn7 XNKoQoLOuRf2FAt7OryhKpGs0Fhiz9dhzzdw9YpNYxviIqXtP5UNz8YzG7p9iv3bp6ENk2zlM65t eBx3Ly5t8Pehnd805Y0qSILNwlMrKjfUC9EObN9xfH712gUvgq4NYqE2hEXa0LypwHlTknnckGTY 5D6Z/mKnGTZFHDZFbOjtPB4Ef1zYIRFtTQdD5w8aRjfjltPhcJhlZhoSiEpsLtyw5ZLR1phmWU44 DAscQypJBrEmaGUnGwTdq7snG51MbWSAf7drh+RwDDFg9DZyYPRvgtH6XfTQZN0Az3Z67U79vFzs 7ABvkTfJLiJKZ9R+d0s2BG6jgY0PeCoFS234oyIrJ8ZzurTtoqaJaU+GH2xDM/0tiMuiEFLDomSZ BmSYgIwtJJE7v8iINnphO06m6DcRGlTlS1P0+0+vs0VG+PMrdP3In7nYOqoxI5LkMCG5c8opalcc 39t14AEcHqCgxDS5ZwvbOGoiSNREkKqOR5LZIZAQ2LImSuzftGZ3URy0HhuoZPxwjmDrAw4aLJiG Z+oMS80Kp/SU1R3dwZMkxQ8ErJueiIqkjgcm3KxlrJI9h/GCgXg82CNrotZ2Q2pOKJqWk0GM0z9/ n3C76AaWG2rg3s12Gj8MIlNfvR43dN3qWMCpSC9lwz/UTmaHqZkcM7n11IxeSoUTe7zq4aLt3DJf B/qrUad93u7Y1cx2kdwVSN7D1gDdtnMtHm1e9GUKCCRVHBQBQPJDs9bVdQ2a3Iy4OXmO3Gz0aFgF DkoIpaIK6intyIY5qOo/QIeD1QkmGBmHoP1b+xy2TK9B4nPLbE9KOYqwl/Bf7WpQl65tbDK1oRdX kmtnJ7lG0RxwtaWy6tySSdzzWG42GbMionhrkPRzyRCAXEiKT4oSmTiUNZqJ0Q6qj8ptXIVeY2gu eOubouO2aaLsY6ZwFgmeEA13N6NX7tFMxIl9H2BMUAVNGK4BKa6UfMlWpcS7H+s9QyKfiDiN4RME nfYlnMV4U8A9FQWRqZP5oVsNvV3REW+es8bL+1gNCusNlWxT1TnC27squPHgsbMAPjGeiq0Cjv4b 5x77NIN45jD8keEqbx9hD6J1YL/ADM7ATeLYHNV0vMZeZA3+vTsY4VQsxZfvA8mwJ2f4w3xc2v+C DcnwOyPw8CkRGdJerhZ9bzTCb4Kg0zGwHAmuK7uImA2BGXRJcpbtKrhrgP3nBq2AnHEhDejvU+lw TjNK1KEtpoJDEf9XAc2U+0YHXGOSrEyrfUavsaWyqhjEEpRY6i1BaplbETcjKquO4iFqnz5mar/v tA7NONtYhPQqMmr9Kzp8HMzf7/ey9xwzljJBQu8putSUQ4qjIhk+Y4lIoQNbkVx5wTLEROl8IFUB 7fQVWpMkH78cw38BAAD//wMAUEsDBBQABgAIAAAAIQBgQQnkUQEAAGYCAAARAAgBZG9jUHJvcHMv Y29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEklFLwzAUhd8F/0PJ e5s201lC28EmexAHghPFt5jcbWVNGpJot39v2m61Q8HH3HPy5ZxLstlBVsEXGFvWKkdJFKMAFK9F qbY5elkvwxQF1jElWFUryNERLJoV11cZ15TXBp5MrcG4EmzgScpSrnO0c05TjC3fgWQ28g7lxU1t JHP+aLZYM75nW8AkjqdYgmOCOYZbYKgHIjohBR+Q+tNUHUBwDBVIUM7iJErwj9eBkfbPC50ycsrS HbXvdIo7Zgvei4P7YMvB2DRN1Ey6GD5/gt9Wj89d1bBU7a44oCITnHIDzNWmWLAKPoI524PJ8Gje 7rBi1q38ujcliPmxWJV7CB78pm2Gf6se2nXoySACn4r2Hc7K62Rxv16igsQJCeNpSNJ1klIypbfp e/v4xf02ZT+Qpwj/Eu9aYkwouaExGRHPgKLLffkzim8AAAD//wMAUEsDBBQABgAIAAAAIQDcWXjt 3AsAALQbAAAnAAAAeGwvcHJpbnRlclNldHRpbmdzL3ByaW50ZXJTZXR0aW5nczEuYmlu7Fd5NNTr G3+tpWsva0mKso+d6DbJdCUma5Yxdt80GPsuxrWEEJUllFHWLINCssSPe8kIRdMokSVZsmXf4ved ln/6655z//id8zs+73ne53ne932e830/Z545z4sFWGAAjMBFIAO0gD5sGQB5eM0LQMAR+MMiAxSB HFAAqrDlCH4FHSNgfg/6BI13AD0doANT+9z3OsKaA5jDPj08M8CeHpzNBx4QnPffg+5HCkZY08Py 0/81s4GRjumI3K+r/97n/5aC8wRtAECT72gCyQw/7V/1zw0UHyfA6jKAK1q0r/8OGm+/Qn5UkYEJ XtyB92jyM/7Xc7v+/zcDv/4ymuDrGqNNLtBuzQnKgfm3mnIHAeAIMAPucH25wHUMATe42mg1fAQo AxVYlGHLABjDUXqQnSPOzemcoxMEgIGdE2SMC4LgVR8fyOubbwQ54dzdAED5erhCAT/URXcTX7y9 KwSMIG93V18f2gkVObkAWBw9cLSv+WdA8QEgf9HInHYvVtj+p9jA867vhetgnoUTDqEDe45oHjjE SotGG2v9QdO9LLQZAOnvCjDQfa+rk3IA/lejxdCBcaUfmz8UAnHJzcEd7+EFeXtDjjIoOx87BAJ4 WnBuB7KMK2np/m3J5nrIjCur//F+DQK6gqHznafsU93RodaKuenHA/vyqntF8eiRd7z8hoICbaXH NKpH+xLQayyEKN6HD4owTGlEU+fJD1USuMwPx7kNUDrnJDQr78cUchee5+Tae/8IKsz9sl9IMOGG 6ru6TEpvZvDmYP9c54tM1cfWqk9cJ11lZWzOZH9KzezPsFR/dz1kTZ44cV7kiW+lgMiWSuGQD1OR 5HzoyOFWDJ5dVvNS6RbmUwtZ2OqG5IOrfE/8pXZkF/3DEPluEblr7X2lqhrIyKmDZGIdMyXiOiQv kXoyd3VwOJhDasdAoOhruO7sRdwii1soau2sMCXpCx6PENdeFhrLTL2/QVqgcyOY5L/tkknEefP4 nxQTv5opfaA1qGF1L2LM95z5GCrmGeT3oeHa0ox5rLPwWuD1hUq/4sd1v5cZuykaChmEXl8XliTE mi0a35vKulQ4+GalM36DNUC8Yy2hWsjp+Zza2gfJHYnZTe0xwoutRqiK7b2XTmZHzaY9cX6mZA4i Ezmyi+YnHQQrZ3hNPXISC8Qt6KrbVUvDVYjSs/ENNX5CnklOT63WGU4FFS/oe27iyQiH7dtkZGcI sw8pZAUbsWbVxCFQkS5vg63YTz+iz/moopeP+lW2bq4GQZoWqfN8fXn2TR2PriFbf0KwI3n4aLnl 0vYe/tET05uJGPvAF0UcOjOK7JbLXMWhunsIZYyUOR9DoZUH0i5XKghIUiN6059Vj2sgVMqP7N28 8oQ36cuBv4fV8Z9Kup7J41YmUrqt7ebt0wxUl1+Js/UyMk2MFmrjwjCvVFAOQ5svMfqGyUEKqR1J 9D6fw2Lvi9jq1d1gt+vgU0oTvNdaSfGxOHZcXC9T/GyrStWqWL3vtRSiYyhKndSSSzHRTTDSbrqk RbEME4mv5Y2au5ZXddPtzCazLb7gM1NdeJFees4frZSXggqzvdpZkTuKoblbsoNBSHnU1Wp9BWtK cPD6IDGh5mWX1A7vE751iprkVo+pv0zRGNnd9nT2VtAn6sbo5mcdl/dx22v1CAkCTrkoLWUHsRid vHqp+ckGRWqdasFPx5Q1jpw/et+GsLPcP1soGbozjWQXHvBxORF0RuK2/VC9+xrXwSHmrFkR54gL bR4VPQycpsdQxhw3KDZxLmJ/JaMlc7v3kpDSovtEh2vjgq7IsRXVluQczdCyyfYsjKoo9RiaiiwJ QllrlKK5yvVetBaYP47ykJ3Jmcc+oJvwzGOgogP8hJd71DhnsuugHFN7BhOH4L/EzG4ru8ZN6B4t XuW8YqLuIeYsG+40nkrKb7BfdKpIS9Pw8NWMI17zZdPC9J8zdZ1R6bpWYtnnuwRtxFUJt7Bj0SzB iNUlng3pmf/c9+eqJuQwmGmIVh2spvz2NAHDXew9oZIBxYakPDtPiBogSh3fOB8e8jdeQ3ihNvq0 9pyWNR8nz+BQE9SRJ4IojMnK647bscdqcHtcGuexlJcuYfdDRuVIMWJLeUmXzff3m5grPVxr7mNj K/QfIVc3IsKj5PND12Jt6UkxUboVciR1FqRXhMtp6WnliZtQtSSdWcNY1VT+aphMHXYIc8amIHDe KiEuhuQ7VBvl1iogkJ2KC3mj3yFDjzBMg67+NmktGU20dS3uHXk09mava/X7qcduTgcnXRyb9WNk 9y/xV82/FkWpJZzscVAdODF8okM6w9Ra5Vl5C7Vo+lHsXKi6TrQ00jPkOrFPkqtL/GKuUIzwZsmi eLzULeiD4dmCSdazc6ph+OcLxd2Ayns3kRJwmPhBVUTW8eohq3jzm+aM/pmHuOxvt41DEg2a1KZn fiNXsbeZ04Ku+TyfEv3dyBGd1RZdPMF3tMyqvMyXHSvMFC4SKxb0kMCr4DLPbyHQoINPooZOfGlJ DZEnsT0/1ZPzEK2W/siXPrkX8fA3pxWmoSKvIWeeuaTDZq+H25uPys95rnuIjSdW5G7dXLiF5M3/ mFgRCZvJyC6ddmEH3KI22XNbTVWMEJ/XKSzRtj76IHnrpic+Mo+D/pXcxscThHp1MYIj1rV//y0J I+uFNm5s+3jSlPxbLcZhLvHocQMc+WQyC1///rHpQ5gUL/a8tpQABcPU7vufPcQa98S0B4exVIiT e4PD7LHtgZgX1xvFywIxhheyeB8vKJFdslSQYvpxFoGCY8r6lkm3CuRlNZC9akTDj+r6lnduFUiQ NkSxTzt7yR5ibVGTXxm1rye31JSfEpPVSyz2fTfixcXn9lfKXWprSX3qQgbVr+BjlbPNK9FNsq91 MOGCdUdND1T5xd/+bbfL6pD9h+XDK6MZF56z1GTdrnfADm6yjwauZ7NgdUsDHpD/LLYgaYxxJAdq XosUPykcJKJjTWd+x1nR33GeyrL4cTmEWkEkYgie1O41jahigzWGiMss8wLYRMaNhltH2XpywyDV Zp2mviWfrfG5Ragef3zYOqi8cmDiLdP91WyImf/0gzhIaUDxiF3LWHuiJ0Gfny+dUkMfX5ckJ3uq bolrdDtVjuRnOprF4fzKUyuJHBMZf7dnuetIeoSmjAy3oxuxCmPD6oy7jbSsyPLrdn7foSkTe/mt 2LvpTLuq6HCMQkKH6ECLpkx6K9Tz6WZ2qt6ogkX3K5qeUozX4H19C4dVaqkZpR1QduRfvWCgq6FE jQhRVdJtIO511jn9CaFdxlxVGYcm8dQ7hCfPnFCUYce9vT749Y023crUZT1tLYxKjg1H0sURtckW 9blmaQfFeEvunp4/fRN03Ve0RgNm790pUB01TrtW2fd5NCi6/uJkpqdZuohM5lgVvUuJkP7BWybu +TddzmLudgukHCnXT7rhUF2h9KhoH26Ss1E9ViFAIPICRUSmi+ry9Wh/epugpudOP5cVa70S57ug 6RlvYVRHg9isVSN1Cd3bsB6M5rgza1VNXcqeDLUMQnOkzyZyl03a9TZYLmasZM4m2pdNWuYH+39W RqfPWmVSl3Int9fmM0Jta5GC9fnH8jc9Ol3UnWs5vtbnO+RvyvW4qLvVcug05JvprQ6XUn2afYQl g9En0Kt2T6hL+ZOnTZYz2DNmW6zLJll6Q65MKQupDERTshrxLOdrOklDq8L9fhuv2xmMx0NEbZoU rarUu1TN8yrDbbYb6vqk74grba8jD4ce2ygJGLJpFJT8fM/szBeRFWQ3auz2Mksxu+29Yy9rM80u oRAHrjxMUX2tvEDNm+d50ebN00lpntOdeSpYZiu7bf9VubivkMS4v3eHjn4HBgBK41r6aGV6wA33 sQHAAZ5dgew3GwLwsxPggT1wBqywTQMbOAB3eO57p/b9aO5gResyD4BD8ItWCY6Ug0UFtuXht6ws 3BHLwUMR8MJD/tue2o+ZtqsGv3j54Mwep0NpTfMudhnYZWCXgV0GdhnYZWCXgV0GdhnYZWCXgf8J A/8FAAD//wMAUEsDBBQABgAIAAAAIQCiocrBnAEAAFwDAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCi BAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJyTQWsbMRCF74X8h0X3WGs7lGK0CsVp yKGlBjvJWdXOekW0ktBMFru/vtpdHMttcultNO/x+DQjidtDZ4seIhrvKjaflawAp31t3L5ij7v7 6y+sQFKuVtY7qNgRkN3Kq09iE32ASAawSBEOK9YShRXnqFvoFM6S7JLS+NgpSse4575pjIY7r187 cMQXZfmZw4HA1VBfh7dANiWuevrf0NrrgQ+fdseQgKX4GoI1WlG6pfxhdPToGyq+HTRYwXNRJLot 6Ndo6ChLwfOj2GplYZ2CZaMsguDnhngANQxto0xEKXpa9aDJxwLN7zS2BSt+KYQBp2K9ikY5SliD bTqMtQ1IUT77+IItAKHgyTA1xzL35rW5kcvRkIpL4xAwgSThEnFnyAL+bDYq0jvEy5x4ZJh4J5zt wDfP+d5IR2nxsTSR5rcaB5X4/iJa+y4od8z2tfYx+DhuUfCTLL4b94KPYefvFMFpM5dNsW1VhDot 86SfG+IhLSXaIWTdKreH+uT5Vxje0dP0WeT8ZlYuy/REsp7g528h/wAAAP//AwBQSwMEFAAGAAgA AAAhADYCE9FAAgAAHwYAABQAAAB4bC90YWJsZXMvdGFibGUxLnhtbHRU23LaMBB970z/QaP3YuQ0 5DJABkhpkyHAxKTtq7AFVkeWPJKA+O+zvhZR9VGrc/bsro52+PCeCXRk2nAlR5j0+hgxGauEy/0I v23mX24xMpbKhAol2QgXzOCH8edPQ0u3giFgSzPCqbX5fRCYOGUZNT2VMwk3O6UzauGo94HJNaOJ SRmzmQjCfn8QZJRLjHgCshhJmkH2TZkUTgk3uaDF0glqthvhCbnfhCFGVlkqzKs6Rak6QeVQdwoC TEPo8X33BFnDK0hELW2PkLeDTJUGbHtT5iuV3Wgfj4f0YNWcC8s0OpcPxnX/MyUOmTQoVgdpQbGk VJnqC7e5N0P3zCmJ3GE3U0WAaupprKmmGSqH4LJufSxo9pz1kwqXdOMjfW1Jj8zEmucWXODSBj7a dUvrLb9tXPy1Dw9zaYr7xWWiTgZOlh8v2oJiyueaMSEiWwiww3elEl++QZtuFaHfrv6VD3/T4vkq cuGhD37Xwp/pkaLn2cTlEB+HdKOcghfiYkaNFRcN9n1E+F/1u01kohVPHC2vP0j3XdY/1g7cawzS TQvgEYsXfOuQvMYgf01Y2PTCFF5PkG7IL+FMF7lVjorXF6Rrfl14OP8aYkq9fiCd+V8P28LR9fqB dAZewaaKooVD8XoCvmrzTlIlrPfHOJRyZbnW/V+l3U9YRq4VK3MEZ8vDNKuk+gtPcqca/WpHVsEX lvBDBtoGduCca2PrtVNtwzK2ABNehMqNaeGnM9jaDbNGdNGzQsYfAAAA//8DAFBLAQItABQABgAI AAAAIQDF3RNAiwEAAJQGAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsB Ai0AFAAGAAgAAAAhALVVMCP1AAAATAIAAAsAAAAAAAAAAAAAAAAAxAMAAF9yZWxzLy5yZWxzUEsB Ai0AFAAGAAgAAAAhAN4J/SgCAQAA1AMAABoAAAAAAAAAAAAAAAAA6gYAAHhsL19yZWxzL3dvcmti b29rLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhALq0cdpiAQAAcQIAAA8AAAAAAAAAAAAAAAAALAkA AHhsL3dvcmtib29rLnhtbFBLAQItABQABgAIAAAAIQD7YqVtlAYAAKcbAAATAAAAAAAAAAAAAAAA ALsKAAB4bC90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAEG/+GDZAAAAygEAACMAAAAA AAAAAAAAAAAAgBEAAHhsL3dvcmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzUEsBAi0AFAAG AAgAAAAhAPvoXUdgAQAAdQIAABgAAAAAAAAAAAAAAAAAmhIAAHhsL3dvcmtzaGVldHMvc2hlZXQy LnhtbFBLAQItABQABgAIAAAAIQD76F1HYAEAAHUCAAAYAAAAAAAAAAAAAAAAADAUAAB4bC93b3Jr c2hlZXRzL3NoZWV0My54bWxQSwECLQAUAAYACAAAACEAcG2tyhEOAAD/VQAAGAAAAAAAAAAAAAAA AADGFQAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1sUEsBAi0AFAAGAAgAAAAhANaIUHoeCAAA9lsA AA0AAAAAAAAAAAAAAAAADSQAAHhsL3N0eWxlcy54bWxQSwECLQAUAAYACAAAACEAgy/oZb8EAAB4 DgAAFAAAAAAAAAAAAAAAAABWLAAAeGwvc2hhcmVkU3RyaW5ncy54bWxQSwECLQAUAAYACAAAACEA YEEJ5FEBAABmAgAAEQAAAAAAAAAAAAAAAABHMQAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYA CAAAACEA3Fl47dwLAAC0GwAAJwAAAAAAAAAAAAAAAADPMwAAeGwvcHJpbnRlclNldHRpbmdzL3By aW50ZXJTZXR0aW5nczEuYmluUEsBAi0AFAAGAAgAAAAhAKKhysGcAQAAXAMAABAAAAAAAAAAAAAA AAAA8D8AAGRvY1Byb3BzL2FwcC54bWxQSwECLQAUAAYACAAAACEANgIT0UACAAAfBgAAFAAAAAAA AAAAAAAAAADCQgAAeGwvdGFibGVzL3RhYmxlMS54bWxQSwUGAAAAAA8ADwD0AwAANEUAAAAA --_002_BL2PR03MB433794DEE4787CD5A4B26A6F5A90BL2PR03MB433namprd_-- From nobody Tue Jun 30 17:14:55 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6611B2CC0 for ; Tue, 30 Jun 2015 17:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 3lqzjgA-ar7b for ; Tue, 30 Jun 2015 17:14:51 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64EEE1B2CBF for ; Tue, 30 Jun 2015 17:14:51 -0700 (PDT) Received: from hebrews (unknown [50.109.240.20]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 57C8B38F08; Tue, 30 Jun 2015 17:14:50 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , References: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> In-Reply-To: Date: Tue, 30 Jun 2015 17:15:04 -0700 Message-ID: <009501d0b392$fb7cc680$f2765380$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJBW2regVOc1KgJrCGEY9SFfcIRjgIjyzTpnNNQiKA= Content-Language: en-us Archived-At: Subject: Re: [Cose] Issue: Encoding for a single recipient or structure X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 00:14:53 -0000 > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Tuesday, June 30, 2015 3:45 PM > To: Jim Schaad; cose@ietf.org > Subject: RE: [Cose] Issue: Encoding for a single recipient or structure > > Hi Jim, > > Per your suggestion in response to my issue 1, I'm reviewing this thread. > (I'm also including the original message below so WG members who joined > the list when the WG was formed will see it.) > > First, let me ask a question to see if I correctly understand the problem with > your option (1) below. JWE used "alg" for the key management algorithm > and "enc" for the content encryption algorithm. Likewise, JWE used > "encrypted_key" for the encrypted key value and "ciphertext" for the > encrypted plaintext. Since there were no name collisions, all could live in > the top-level JSON object. Whereas, your current COSE draft uses the > equivalent of "alg" for both algorithms and the equivalent of "ciphertext" > for both encrypted values, hence the label collisions you are citing below, > correct? > > If my understanding is right, then unless a JWE-like approach were adopted > in which different labels are used for the different purposes, then yes, I > agree that (1) wouldn't work. Was this change to a single set of labels the > intended topic of the thread "[Cose] Issue: Reuse the Enrypt structure for > recipients"? I'm asking because a lot of the thread ended up being about a > different topic - whether the encrypted_key value would contain just an > encrypted bare key or the equivalent of an encrypted JWK structure. > > You asked if I had anything new to add to the discussion. I'll add this... > > Just like for JOSE, I expect that many applications will implement only the > COSE features that they need. For instance, JWT [RFC 7519] > implementations only need to implement the JOSE Compact Serializations - > not the JSON Serializations. I expect there to be many COSE applications > that will similarly only implement support for a single recipient. This would > save on code size and be simpler. > > I believe that applications that only use a single recipient will be the most > common, hence the goal stated in my review to optimize for this case. > Assuming we take your option (1) off the table and limit discussion to only > your options (2) and (3) below, then the choice seems to be between these > effective grammars for the single recipient case: > (2) recipients: {recipient_data} > (3) recipients: [{recpient_data}] > > If you're only ever building code for the single recipient case, then (2) is > simpler. But I agree that if you're using code that supports multiple > recipients, then (3) is simpler, if somewhat less elegant. I am going to make the same challenge to you that I made to Derik at one point. Can you provide code to show that option 2 is significantly larger than option 3? Jim > > What do others think about this tradeoff? > > -- Mike > > -----Original Message----- > From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Thursday, April 30, 2015 3:59 PM > To: cose@ietf.org > Subject: [Cose] Issue: Encoding for a single recipient or structure > > Question: Flattened encoding - > a) Roll into parent map > b) Just be a map > c) Single element in array > > Discussion: > > A late addition to the JOSE specification was the ability to fold a single > recipient map into the base encryption or signature map. This is doable > because the keys for all of the maps in question are unique. This would not > be true if the issue on reusing the encryption body for the recipient > structure is accepted. This issue is being discussed in a separate mail thread > (but is current). If arrays were to be used at the top level, one just appends > the elements to the end of the base structure (see examples in the current > document). > > There are three different options that can be selected at this point: > > 1) The recipient/signature map is folded into the encryption/signing > message top level. If we accept the change for using the same structure for > both the encryption body and the recipients, this is not a viable option due > to collisions of keys in the map. > > 2) The recipient/signature element in the base map is permitted to be > either an array of recipient/signature elements or a single > recipient/signature map. This option was rejected by the JOSE group as > being too complicated for programmers to deal with. The cost of this > option is 2 bytes over option one. (One byte for the recipients key, one > byte for the map marker.) > > CDDL grammar would be: recipients: [+[recipient_data]] / {recipient_data} > > 3) We do not support any special form of dealing with a single recipient. > The cost of this option is 3 bytes over option one. (One byte for the > recipients key, one byte for the array marker, one byte for the map marker.) > > CDDL grammar would be: recipients: [+[recpient_data]] > > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Tue Jun 30 17:45:57 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5B01A0242 for ; Tue, 30 Jun 2015 17:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 739KrYN91zbg for ; Tue, 30 Jun 2015 17:45:54 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0148.outbound.protection.outlook.com [207.46.100.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7B6B1A0060 for ; Tue, 30 Jun 2015 17:45:53 -0700 (PDT) Received: from BL2PR03MB434.namprd03.prod.outlook.com (10.141.92.22) by BL2PR03MB162.namprd03.prod.outlook.com (10.255.230.145) with Microsoft SMTP Server (TLS) id 15.1.201.16; Wed, 1 Jul 2015 00:45:53 +0000 Received: from BL2PR03MB433.namprd03.prod.outlook.com (10.141.92.19) by BL2PR03MB434.namprd03.prod.outlook.com (10.141.92.22) with Microsoft SMTP Server (TLS) id 15.1.207.12; Wed, 1 Jul 2015 00:45:52 +0000 Received: from BL2PR03MB433.namprd03.prod.outlook.com ([10.141.92.19]) by BL2PR03MB433.namprd03.prod.outlook.com ([10.141.92.19]) with mapi id 15.01.0207.004; Wed, 1 Jul 2015 00:45:53 +0000 From: Mike Jones To: Jim Schaad , "cose@ietf.org" Thread-Topic: [Cose] Issue: Encoding for a single recipient or structure Thread-Index: AdCDmTM3cpCIVDijSSWQU/yxCPpImgv5+bgAAAR4DgAAACbLYA== Date: Wed, 1 Jul 2015 00:45:53 +0000 Message-ID: References: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> <009501d0b392$fb7cc680$f2765380$@augustcellars.com> In-Reply-To: <009501d0b392$fb7cc680$f2765380$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e0:ee43::6] x-microsoft-exchange-diagnostics: 1; BL2PR03MB434; 5:aUooRIrQpNIBZKvxIgnNqj5U2yeqQdm2IS/3YVPpMh0JTc9LEpTJdVOYNyC7eEY9pW2tODUtDsT0YfIlpqqeIig49ID7gc5g8T+glMyVPfdEusrKcBEoijuy6AXIXlAax+D6qzZ2snL5nHxDcLRwtQ==; 24:EYwitQxzAykY3TaEhQDYvNMHpOKuf/QS4wlCASHB5LQE4pdOASahoFqoiR5bKczeYJu0DNsSLZBI2gPRzyhftacAwZ9+b6RpDp/kpz64bTk=; 20:JpKMY9lv+WvzsIODTLmG8rx4hPy2/wwgcAfdBvJ++gf+u6YWQ7uMxyoSkYyKonL5GS41gNpb+8X8vZuft+7j2A== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB434; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB162; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BL2PR03MB434; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB434; x-forefront-prvs: 0624A2429E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51704005)(13464003)(2656002)(86362001)(87936001)(92566002)(107886002)(5001960100002)(99286002)(5001770100001)(2501003)(19580405001)(19580395003)(77156002)(62966003)(2900100001)(2950100001)(74316001)(15975445007)(102836002)(77096005)(50986999)(40100003)(54356999)(76176999)(86612001)(5003600100002)(76576001)(46102003)(33656002)(5002640100001)(189998001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB434; H:BL2PR03MB433.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2015 00:45:53.1932 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB434 X-Microsoft-Exchange-Diagnostics: 1; BL2PR03MB162; 2:9yZcJxrLCY/PnjGdoG+cSa2ew2ZculRrg33uPZhGb5Httw0y5O011jLIZh4+GbR2; 3:31XQi4Q3wsP5nRSyK9fQDRTsQeUTAwlI9WVULNA2VEIt5AbUAPQti6LSW4nJaBJj8TJUd4kRThErtIrBtxFom1BA+4cIN0vItcD+vbQGIo5kkvqpWR7hAFWa0+FbzX86qb90ckNJsYKk4URHDqtZ6w==; 25:DMT/UaPecmfSxy36k3PQ1/soOLlRUVp8grADAB5Jh2q2MLk8UMsLEACcYACoYEQQdcqsazeAAZdBPOJfnDXGEAxzzrPSB9dlYBRgSCWdmWX/SjRGE3WUn9cpEH9ub1Ua9mH+WfckiNde1TTHFIxG7Fmdanv8L7VCyKoarF+Ge5TmHT2kgFX1PUZWjaoVNqcD7nrVRBrdY8zQW5nZ2jwJHHFZeodY0HwDIUTqlqgiAOCQGxwp6iEuEu/Uvwei2acSG57z1oQukUB31rFLCDZxcg==; 23:K7Hx1EVEDzHSO21zbDLD2OgzS/hcgs8K2fbxEdffGDJXuwG1IUDSI1P21qSgyGBJLfl/RVscvYd6mv1kwbzaq79KarOUvzUOOc1Vw0r7S8xIl8KpsiAbmW5LBgnk8DFnR+Od/9+lYOFf7bdhr341tuJT+2m596+GDPAz2VjJ0l9EXmYuKHSZ/gMRTZla+OaG+qt6eurMn0LFk7YdV5Gmocluv7vIVGHlQC4IfQXPF6uW9DXz18BHIoUsiUGWtc5Q X-OriginatorOrg: microsoft.com Archived-At: Subject: Re: [Cose] Issue: Encoding for a single recipient or structure X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 00:45:56 -0000 Reply inline below... > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com] > Sent: Tuesday, June 30, 2015 5:15 PM > To: Mike Jones; cose@ietf.org > Subject: RE: [Cose] Issue: Encoding for a single recipient or structure >=20 >=20 >=20 > > -----Original Message----- > > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > > Sent: Tuesday, June 30, 2015 3:45 PM > > To: Jim Schaad; cose@ietf.org > > Subject: RE: [Cose] Issue: Encoding for a single recipient or > > structure > > > > Hi Jim, > > > > Per your suggestion in response to my issue 1, I'm reviewing this threa= d. > > (I'm also including the original message below so WG members who > > joined the list when the WG was formed will see it.) > > > > First, let me ask a question to see if I correctly understand the > > problem > with > > your option (1) below. JWE used "alg" for the key management > > algorithm and "enc" for the content encryption algorithm. Likewise, > > JWE used "encrypted_key" for the encrypted key value and "ciphertext" > > for the encrypted plaintext. Since there were no name collisions, all > > could live > in > > the top-level JSON object. Whereas, your current COSE draft uses the > > equivalent of "alg" for both algorithms and the equivalent of "cipherte= xt" > > for both encrypted values, hence the label collisions you are citing > below, > > correct? > > > > If my understanding is right, then unless a JWE-like approach were > > adopted in which different labels are used for the different purposes, > > then yes, I agree that (1) wouldn't work. Was this change to a single > > set of labels > the > > intended topic of the thread "[Cose] Issue: Reuse the Enrypt > > structure > for > > recipients"? I'm asking because a lot of the thread ended up being > > about > a > > different topic - whether the encrypted_key value would contain just > > an encrypted bare key or the equivalent of an encrypted JWK structure. > > > > You asked if I had anything new to add to the discussion. I'll add > this... > > > > Just like for JOSE, I expect that many applications will implement > > only > the > > COSE features that they need. For instance, JWT [RFC 7519] > > implementations only need to implement the JOSE Compact Serializations > > - not the JSON Serializations. I expect there to be many COSE > > applications that will similarly only implement support for a single > > recipient. This > would > > save on code size and be simpler. > > > > I believe that applications that only use a single recipient will be > > the > most > > common, hence the goal stated in my review to optimize for this case. > > Assuming we take your option (1) off the table and limit discussion to > only > > your options (2) and (3) below, then the choice seems to be between > > these effective grammars for the single recipient case: > > (2) recipients: {recipient_data} > > (3) recipients: [{recpient_data}] > > > > If you're only ever building code for the single recipient case, then > > (2) > is > > simpler. But I agree that if you're using code that supports multiple > > recipients, then (3) is simpler, if somewhat less elegant. >=20 > I am going to make the same challenge to you that I made to Derik at one > point. >=20 > Can you provide code to show that option 2 is significantly larger than o= ption > 3? I'm not saying that there's a significant code size difference. Maybe you = can tell us how much code would be removed from your implementation if you = #ifdef'ed out the loops associated with producing and consuming the recipie= nts arrays and just replaced it with code using a singleton array value (op= tion 3) or simply a recipient_data map value (option 2). I admit up front = that there will be almost no code size difference between 2 or 3 if the imp= lementation has been compiled to only support a single recipient. My main point in raising this issue now is we're likely to hear the same th= ing about COSE that Richard Barnes heard from developers who were really us= ing the JSON Serializations before we added the flattened data representati= on - that having to emit and parse a singleton array is ugly, awkward, etc. This isn't a show-stopper to me, but now that there's a working group, I wa= nted to raise the issue for the working group to explicitly consider up fro= nt, rather than wait until people are using early implementations and we he= ar back from developers "why couldn't this have been simpler in the simple = case"? Cheers, -- Mike > Jim >=20 > > > > What do others think about this tradeoff? > > > > -- Mike > > > > -----Original Message----- > > From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad > > Sent: Thursday, April 30, 2015 3:59 PM > > To: cose@ietf.org > > Subject: [Cose] Issue: Encoding for a single recipient or structure > > > > Question: Flattened encoding - > > a) Roll into parent map > > b) Just be a map > > c) Single element in array > > > > Discussion: > > > > A late addition to the JOSE specification was the ability to fold a > > single recipient map into the base encryption or signature map. This > > is doable because the keys for all of the maps in question are unique. > > This would > not > > be true if the issue on reusing the encryption body for the recipient > > structure is accepted. This issue is being discussed in a separate > > mail > thread > > (but is current). If arrays were to be used at the top level, one > > just > appends > > the elements to the end of the base structure (see examples in the > current > > document). > > > > There are three different options that can be selected at this point: > > > > 1) The recipient/signature map is folded into the encryption/signing > > message top level. If we accept the change for using the same > > structure > for > > both the encryption body and the recipients, this is not a viable > > option > due > > to collisions of keys in the map. > > > > 2) The recipient/signature element in the base map is permitted to be > > either an array of recipient/signature elements or a single > > recipient/signature map. This option was rejected by the JOSE group > > as being too complicated for programmers to deal with. The cost of > > this option is 2 bytes over option one. (One byte for the recipients > > key, one byte for the map marker.) > > > > CDDL grammar would be: recipients: [+[recipient_data]] / > > {recipient_data} > > > > 3) We do not support any special form of dealing with a single recipie= nt. > > The cost of this option is 3 bytes over option one. (One byte for the > > recipients key, one byte for the array marker, one byte for the map > marker.) > > > > CDDL grammar would be: recipients: [+[recpient_data]] > > > > _______________________________________________ > > Cose mailing list > > Cose@ietf.org > > https://www.ietf.org/mailman/listinfo/cose From nobody Tue Jun 30 18:01:04 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373C81A010D for ; Tue, 30 Jun 2015 18:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 aph46ipO0TCU for ; Tue, 30 Jun 2015 18:00:58 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 712DB1A0070 for ; Tue, 30 Jun 2015 18:00:58 -0700 (PDT) Received: by oigx81 with SMTP id x81so20880742oig.1 for ; Tue, 30 Jun 2015 18:00:58 -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-type; bh=F/GJJxGSpb4O+9fim3zQC5XIRKDAmdMqNAAiqv5xzHo=; b=isH0qekZ+es9uk5ijpJb1miDwViRivwA7uis3bEKMju1fFEsfuSo1BauwsgjRyTM7m xm72tRMBiB6B1u1JTUU9YynaK5BkQCgEONTL/pyyaQIkLi/9N49TeXc7VrdtvGK8zUKc dfbbI7xmXN44VGuO6qkhHHQtMLk3QsdHLWS5vX3pbU1Cl7n4ddOnvcU1BJiwsOBd8LWs usKVD0L/NsQucHxgZJTWhg3cVo3vmrCEsxUNgTZQg5OmB68Hm+RGX1vd73Rbbq3LBTJI RvRquuURurTY3vbTl/0x0ILSTvMgzaPRk06jUwQEWW3kMqfpz6H3GSsyGVTZS1Cg2XDs h1LA== X-Received: by 10.182.33.67 with SMTP id p3mr9858462obi.69.1435712458394; Tue, 30 Jun 2015 18:00:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.116.99 with HTTP; Tue, 30 Jun 2015 18:00:39 -0700 (PDT) In-Reply-To: References: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> <009501d0b392$fb7cc680$f2765380$@augustcellars.com> From: Dick Hardt Date: Tue, 30 Jun 2015 18:00:39 -0700 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a11c1e8d015151f0519c5db40 Archived-At: Cc: Jim Schaad , "cose@ietf.org" Subject: Re: [Cose] Issue: Encoding for a single recipient or structure X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 01:01:02 -0000 --001a11c1e8d015151f0519c5db40 Content-Type: text/plain; charset=UTF-8 If I'm writing a library and I have to support multiple recipients to be compliant, then given a choice between dealing with both a singleton and an array(a) vs just an array (c), then I'll pick just an array (c). ... or am I missing some aspect of how this is simpler Mike? On Tue, Jun 30, 2015 at 5:45 PM, Mike Jones wrote: > Reply inline below... > > > -----Original Message----- > > From: Jim Schaad [mailto:ietf@augustcellars.com] > > Sent: Tuesday, June 30, 2015 5:15 PM > > To: Mike Jones; cose@ietf.org > > Subject: RE: [Cose] Issue: Encoding for a single recipient or structure > > > > > > > > > -----Original Message----- > > > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > > > Sent: Tuesday, June 30, 2015 3:45 PM > > > To: Jim Schaad; cose@ietf.org > > > Subject: RE: [Cose] Issue: Encoding for a single recipient or > > > structure > > > > > > Hi Jim, > > > > > > Per your suggestion in response to my issue 1, I'm reviewing this > thread. > > > (I'm also including the original message below so WG members who > > > joined the list when the WG was formed will see it.) > > > > > > First, let me ask a question to see if I correctly understand the > > > problem > > with > > > your option (1) below. JWE used "alg" for the key management > > > algorithm and "enc" for the content encryption algorithm. Likewise, > > > JWE used "encrypted_key" for the encrypted key value and "ciphertext" > > > for the encrypted plaintext. Since there were no name collisions, all > > > could live > > in > > > the top-level JSON object. Whereas, your current COSE draft uses the > > > equivalent of "alg" for both algorithms and the equivalent of > "ciphertext" > > > for both encrypted values, hence the label collisions you are citing > > below, > > > correct? > > > > > > If my understanding is right, then unless a JWE-like approach were > > > adopted in which different labels are used for the different purposes, > > > then yes, I agree that (1) wouldn't work. Was this change to a single > > > set of labels > > the > > > intended topic of the thread "[Cose] Issue: Reuse the Enrypt > > > structure > > for > > > recipients"? I'm asking because a lot of the thread ended up being > > > about > > a > > > different topic - whether the encrypted_key value would contain just > > > an encrypted bare key or the equivalent of an encrypted JWK structure. > > > > > > You asked if I had anything new to add to the discussion. I'll add > > this... > > > > > > Just like for JOSE, I expect that many applications will implement > > > only > > the > > > COSE features that they need. For instance, JWT [RFC 7519] > > > implementations only need to implement the JOSE Compact Serializations > > > - not the JSON Serializations. I expect there to be many COSE > > > applications that will similarly only implement support for a single > > > recipient. This > > would > > > save on code size and be simpler. > > > > > > I believe that applications that only use a single recipient will be > > > the > > most > > > common, hence the goal stated in my review to optimize for this case. > > > Assuming we take your option (1) off the table and limit discussion to > > only > > > your options (2) and (3) below, then the choice seems to be between > > > these effective grammars for the single recipient case: > > > (2) recipients: {recipient_data} > > > (3) recipients: [{recpient_data}] > > > > > > If you're only ever building code for the single recipient case, then > > > (2) > > is > > > simpler. But I agree that if you're using code that supports multiple > > > recipients, then (3) is simpler, if somewhat less elegant. > > > > I am going to make the same challenge to you that I made to Derik at one > > point. > > > > Can you provide code to show that option 2 is significantly larger than > option > > 3? > > I'm not saying that there's a significant code size difference. Maybe you > can tell us how much code would be removed from your implementation if you > #ifdef'ed out the loops associated with producing and consuming the > recipients arrays and just replaced it with code using a singleton array > value (option 3) or simply a recipient_data map value (option 2). I admit > up front that there will be almost no code size difference between 2 or 3 > if the implementation has been compiled to only support a single recipient. > > My main point in raising this issue now is we're likely to hear the same > thing about COSE that Richard Barnes heard from developers who were really > using the JSON Serializations before we added the flattened data > representation - that having to emit and parse a singleton array is ugly, > awkward, etc. > > This isn't a show-stopper to me, but now that there's a working group, I > wanted to raise the issue for the working group to explicitly consider up > front, rather than wait until people are using early implementations and we > hear back from developers "why couldn't this have been simpler in the > simple case"? > > Cheers, > -- Mike > > > Jim > > > > > > > > What do others think about this tradeoff? > > > > > > -- Mike > > > > > > -----Original Message----- > > > From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad > > > Sent: Thursday, April 30, 2015 3:59 PM > > > To: cose@ietf.org > > > Subject: [Cose] Issue: Encoding for a single recipient or structure > > > > > > Question: Flattened encoding - > > > a) Roll into parent map > > > b) Just be a map > > > c) Single element in array > > > > > > Discussion: > > > > > > A late addition to the JOSE specification was the ability to fold a > > > single recipient map into the base encryption or signature map. This > > > is doable because the keys for all of the maps in question are unique. > > > This would > > not > > > be true if the issue on reusing the encryption body for the recipient > > > structure is accepted. This issue is being discussed in a separate > > > mail > > thread > > > (but is current). If arrays were to be used at the top level, one > > > just > > appends > > > the elements to the end of the base structure (see examples in the > > current > > > document). > > > > > > There are three different options that can be selected at this point: > > > > > > 1) The recipient/signature map is folded into the encryption/signing > > > message top level. If we accept the change for using the same > > > structure > > for > > > both the encryption body and the recipients, this is not a viable > > > option > > due > > > to collisions of keys in the map. > > > > > > 2) The recipient/signature element in the base map is permitted to be > > > either an array of recipient/signature elements or a single > > > recipient/signature map. This option was rejected by the JOSE group > > > as being too complicated for programmers to deal with. The cost of > > > this option is 2 bytes over option one. (One byte for the recipients > > > key, one byte for the map marker.) > > > > > > CDDL grammar would be: recipients: [+[recipient_data]] / > > > {recipient_data} > > > > > > 3) We do not support any special form of dealing with a single > recipient. > > > The cost of this option is 3 bytes over option one. (One byte for the > > > recipients key, one byte for the array marker, one byte for the map > > marker.) > > > > > > CDDL grammar would be: recipients: [+[recpient_data]] > > > > > > _______________________________________________ > > > 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 > --001a11c1e8d015151f0519c5db40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If I'm writing a library and I have to support multipl= e recipients to be compliant, then given a choice between dealing with both= a singleton and an array(a) vs just an array (c), then I'll pick just = an array (c). ... or am I missing some aspect of how this is simpler Mike?= =C2=A0

On Tu= e, Jun 30, 2015 at 5:45 PM, Mike Jones <Michael.Jones@microsoft.= com> wrote:
Reply inline be= low...

> -----Original Message-----
> From: Jim Schaad [mailto:iet= f@augustcellars.com]
> Sent: Tuesday, June 30, 2015 5:15 PM
> To: Mike Jones; cose@ietf.org
> Subject: RE: [Cose] Issue: Encoding for a single recipient or structur= e
>
>
>
> > -----Original Message-----
> > From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> > Sent: Tuesday, June 30, 2015 3:45 PM
> > To: Jim Schaad; cose@ietf.org
> > Subject: RE: [Cose] Issue: Encoding for a single recipient or
> > structure
> >
> > Hi Jim,
> >
> > Per your suggestion in response to my issue 1, I'm reviewing = this thread.
> > (I'm also including the original message below so WG members = who
> > joined the list when the WG was formed will see it.)
> >
> > First, let me ask a question to see if I correctly understand the=
> > problem
> with
> > your option (1) below.=C2=A0 JWE used "alg" for the key= management
> > algorithm and "enc" for the content encryption algorith= m.=C2=A0 Likewise,
> > JWE used "encrypted_key" for the encrypted key value an= d "ciphertext"
> > for the encrypted plaintext.=C2=A0 Since there were no name colli= sions, all
> > could live
> in
> > the top-level JSON object.=C2=A0 Whereas, your current COSE draft= uses the
> > equivalent of "alg" for both algorithms and the equival= ent of "ciphertext"
> > for both encrypted values, hence the label collisions you are cit= ing
> below,
> > correct?
> >
> > If my understanding is right, then unless a JWE-like approach wer= e
> > adopted in which different labels are used for the different purp= oses,
> > then yes, I agree that (1) wouldn't work.=C2=A0 Was this chan= ge to a single
> > set of labels
> the
> > intended topic of the thread "[Cose] Issue:=C2=A0 Reuse the = Enrypt
> > structure
> for
> > recipients"?=C2=A0 I'm asking because a lot of the threa= d ended up being
> > about
> a
> > different topic - whether the encrypted_key value would contain j= ust
> > an encrypted bare key or the equivalent of an encrypted JWK struc= ture.
> >
> > You asked if I had anything new to add to the discussion.=C2=A0 I= 'll add
> this...
> >
> > Just like for JOSE, I expect that many applications will implemen= t
> > only
> the
> > COSE features that they need.=C2=A0 For instance, JWT [RFC 7519]<= br> > > implementations only need to implement the JOSE Compact Serializa= tions
> > - not the JSON Serializations.=C2=A0 I expect there to be many CO= SE
> > applications that will similarly only implement support for a sin= gle
> > recipient.=C2=A0 This
> would
> > save on code size and be simpler.
> >
> > I believe that applications that only use a single recipient will= be
> > the
> most
> > common, hence the goal stated in my review to optimize for this c= ase.
> > Assuming we take your option (1) off the table and limit discussi= on to
> only
> > your options (2) and (3) below, then the choice seems to be betwe= en
> > these effective grammars for the single recipient case:
> >=C2=A0 =C2=A0 =C2=A0(2) recipients: {recipient_data}
> >=C2=A0 =C2=A0 =C2=A0(3) recipients: [{recpient_data}]
> >
> > If you're only ever building code for the single recipient ca= se, then
> > (2)
> is
> > simpler.=C2=A0 But I agree that if you're using code that sup= ports multiple
> > recipients, then (3) is simpler, if somewhat less elegant.
>
> I am going to make the same challenge to you that I made to Derik at o= ne
> point.
>
> Can you provide code to show that option 2 is significantly larger tha= n option
> 3?

I'm not saying that there's a significant code size dif= ference.=C2=A0 Maybe you can tell us how much code would be removed from yo= ur implementation if you #ifdef'ed out the loops associated with produc= ing and consuming the recipients arrays and just replaced it with code usin= g a singleton array value (option 3) or simply a recipient_data map value (= option 2).=C2=A0 I admit up front that there will be almost no code size di= fference between 2 or 3 if the implementation has been compiled to only sup= port a single recipient.

My main point in raising this issue now is we're likely to hear the sam= e thing about COSE that Richard Barnes heard from developers who were reall= y using the JSON Serializations before we added the flattened data represen= tation - that having to emit and parse a singleton array is ugly, awkward, = etc.

This isn't a show-stopper to me, but now that there's a working gro= up, I wanted to raise the issue for the working group to explicitly conside= r up front, rather than wait until people are using early implementations a= nd we hear back from developers "why couldn't this have been simpl= er in the simple case"?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike

> Jim
>
> >
> > What do others think about this tradeoff?
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
> >
> > -----Original Message-----
> > From: Cose [mailto:cose-= bounces@ietf.org] On Behalf Of Jim Schaad
> > Sent: Thursday, April 30, 2015 3:59 PM
> > To: cose@ietf.org
> > Subject: [Cose] Issue: Encoding for a single recipient or structu= re
> >
> > Question: Flattened encoding -
> > a)=C2=A0 Roll into parent map
> > b)=C2=A0 Just be a map
> > c)=C2=A0 Single element in array
> >
> > Discussion:
> >
> > A late addition to the JOSE specification was the ability to fold= a
> > single recipient map into the base encryption or signature map.= =C2=A0 This
> > is doable because the keys for all of the maps in question are un= ique.
> > This would
> not
> > be true if the issue on reusing the encryption body for the recip= ient
> > structure is accepted.=C2=A0 This issue is being discussed in a s= eparate
> > mail
> thread
> > (but is current).=C2=A0 If arrays were to be used at the top leve= l, one
> > just
> appends
> > the elements to the end of the base structure=C2=A0 (see examples= in the
> current
> > document).
> >
> > There are three different options that can be selected at this po= int:
> >
> > 1)=C2=A0 The recipient/signature map is folded into the encryptio= n/signing
> > message top level.=C2=A0 If we accept the change for using the sa= me
> > structure
> for
> > both the encryption body and the recipients, this is not a viable=
> > option
> due
> > to collisions of keys in the map.
> >
> > 2)=C2=A0 The recipient/signature element in the base map is permi= tted to be
> > either an array of recipient/signature elements or a single
> > recipient/signature map.=C2=A0 This option was rejected by the JO= SE group
> > as being too complicated for programmers to deal with.=C2=A0 The = cost of
> > this option is 2 bytes over option one.=C2=A0 (One byte for the r= ecipients
> > key, one byte for the map marker.)
> >
> > CDDL grammar would be:=C2=A0 recipients: [+[recipient_data]] / > > {recipient_data}
> >
> > 3)=C2=A0 We do not support any special form of dealing with a sin= gle recipient.
> > The cost of this option is 3 bytes over option one.=C2=A0 (One by= te for the
> > recipients key, one byte for the array marker, one byte for the m= ap
> marker.)
> >
> > CDDL grammar would be:=C2=A0 recipients: [+[recpient_data]]
> >
> > _______________________________________________
> > 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

--001a11c1e8d015151f0519c5db40-- From nobody Tue Jun 30 18:12:01 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3C71A0171 for ; Tue, 30 Jun 2015 18:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 B-pT4O7fFcX8 for ; Tue, 30 Jun 2015 18:11:55 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0136.outbound.protection.outlook.com [65.55.169.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 175701A016B for ; Tue, 30 Jun 2015 18:11:54 -0700 (PDT) Received: from BL2PR03MB433.namprd03.prod.outlook.com (10.141.92.19) by BL2PR03MB433.namprd03.prod.outlook.com (10.141.92.19) with Microsoft SMTP Server (TLS) id 15.1.207.12; Wed, 1 Jul 2015 01:11:51 +0000 Received: from BL2PR03MB433.namprd03.prod.outlook.com ([10.141.92.19]) by BL2PR03MB433.namprd03.prod.outlook.com ([10.141.92.19]) with mapi id 15.01.0207.004; Wed, 1 Jul 2015 01:11:51 +0000 From: Mike Jones To: Dick Hardt Thread-Topic: [Cose] Issue: Encoding for a single recipient or structure Thread-Index: AdCDmTM3cpCIVDijSSWQU/yxCPpImgv5+bgAAAR4DgAAACbLYAABcMGAAAAkBNA= Date: Wed, 1 Jul 2015 01:11:51 +0000 Message-ID: References: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> <009501d0b392$fb7cc680$f2765380$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e0:ee43::6] x-microsoft-exchange-diagnostics: 1; BL2PR03MB433; 5:tP8myB1dMEmkKYOU582sMm0CNrT/wlsD6fohypl0EMY0FNXfKxdwU4zi4r+gb+xWysv/okZNmiWtisYhq0upP4LrOaFbW7lD1YkID8kzau7yc9SXCMXpEmDXDXqt8s+C3X2q+YKrzaTQy2oHI0iREg==; 24:mbr+fdFszo8PGT1yS/Pmj2Pb3NUj5Bn7RNe/CRGPkBZzVgHD7JPWGU7LHS6+mZgnsL4EkllY7Gczhe/YzRfS2RKn1F/vGLvSlXW+yBHtQ2A=; 20:HEAm7yQSL/owFOacXfrry8Lsa2XE9Nyt9vlgKUs+Swz+guhToPg7qGV0CM1k6ex08C/mXH23Xmtcj55sAx8UDQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB433; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BL2PR03MB433; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB433; x-forefront-prvs: 0624A2429E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(13464003)(51704005)(377454003)(62966003)(5002640100001)(2656002)(93886004)(87936001)(15975445007)(74316001)(19609705001)(19580405001)(33656002)(76176999)(54356999)(102836002)(19625215002)(16236675004)(86612001)(86362001)(189998001)(99286002)(50986999)(77156002)(19580395003)(77096005)(110136002)(46102003)(19300405004)(5001960100002)(40100003)(2950100001)(2900100001)(76576001)(5003600100002)(92566002)(5001920100001)(19617315012)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB433; H:BL2PR03MB433.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BL2PR03MB433110A60A3FE944DDB0865F5A80BL2PR03MB433namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2015 01:11:51.5111 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB433 Archived-At: Cc: Jim Schaad , "cose@ietf.org" Subject: Re: [Cose] Issue: Encoding for a single recipient or structure X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 01:11:59 -0000 --_000_BL2PR03MB433110A60A3FE944DDB0865F5A80BL2PR03MB433namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgdW5kZXJseWluZyBhc3N1bXB0aW9uIGlzIHRoYXQganVzdCBsaWtlIHdlIGRpZCBpbiBKT1NF LCB5b3UgKmRvbuKAmXQqIGhhdmUgdG8gc3VwcG9ydCBtdWx0aXBsZSByZWNpcGllbnRzIHRvIGJl IGNvbXBsaWFudC4gIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTUjc2VjdGlvbi03 IHNheXM6DQoNCiAgIEpXU3MgdXNlIG9uZSBvZiB0d28gc2VyaWFsaXphdGlvbnM6IHRoZSBKV1Mg Q29tcGFjdCBTZXJpYWxpemF0aW9uIG9yDQogICB0aGUgSldTIEpTT04gU2VyaWFsaXphdGlvbi4g IEFwcGxpY2F0aW9ucyB1c2luZyB0aGlzIHNwZWNpZmljYXRpb24NCiAgIG5lZWQgdG8gc3BlY2lm eSB3aGF0IHNlcmlhbGl6YXRpb24gYW5kIHNlcmlhbGl6YXRpb24gZmVhdHVyZXMgYXJlDQogICB1 c2VkIGZvciB0aGF0IGFwcGxpY2F0aW9uLiAgRm9yIGluc3RhbmNlLCBhcHBsaWNhdGlvbnMgbWln aHQgc3BlY2lmeQ0KICAgdGhhdCBvbmx5IHRoZSBKV1MgSlNPTiBTZXJpYWxpemF0aW9uIGlzIHVz ZWQsIHRoYXQgb25seSBKV1MgSlNPTg0KICAgU2VyaWFsaXphdGlvbiBzdXBwb3J0IGZvciBhIHNp bmdsZSBzaWduYXR1cmUgb3IgTUFDIHZhbHVlIGlzIHVzZWQsIG9yDQogICB0aGF0IHN1cHBvcnQg Zm9yIG11bHRpcGxlIHNpZ25hdHVyZXMgYW5kL29yIE1BQyB2YWx1ZXMgaXMgdXNlZC4gIEpXUw0K ICAgaW1wbGVtZW50YXRpb25zIG9ubHkgbmVlZCB0byBpbXBsZW1lbnQgdGhlIGZlYXR1cmVzIG5l ZWRlZCBmb3IgdGhlDQogICBhcHBsaWNhdGlvbnMgdGhleSBhcmUgZGVzaWduZWQgdG8gc3VwcG9y dC4NCg0KSW5kZWVkLCBJIGJlbGlldmUgdGhhdCB3ZSBzaG91bGQgYWRkIGVxdWl2YWxlbnQgdGV4 dCB0byBDT1NFLCBiZWNhdXNlIGl04oCZcyBldmVuIG1vcmUgbGlrZWx5IGluIGNvbnN0cmFpbmVk IGVudmlyb25tZW50cyB0aGFuIFdlYiBlbnZpcm9ubWVudHMgdGhhdCBhcHBsaWNhdGlvbnMgd2ls bCBzcGVjaWZ5IHRoYXQgdGhleSBhcmUgb25seSB1c2luZyBzdWJzZXRzIG9mIHRoZSBDT1NFLWRl ZmluZWQgZmVhdHVyZXMgYW5kIHRoYXQgZ2VuZXJhbC1wdXJwb3NlIGxpYnJhcmllcyB3aWxsIGJl IGNvbXBpbGVkIGZvciBzcGVjaWZpYyBhcHBsaWNhdGlvbnMgd2l0aCAjaWZkZWYgc2V0dGluZ3Mg dG8gcmVtb3ZlIHVudXNlZCBjb2RlIHBhdGhzLiAgSSBwbGFuIHRvIHByb3Bvc2UgZXhhY3QgdGV4 dCBhbG9uZyB0aGVzZSBsaW5lcyBmb3IgaW5jbHVzaW9uLg0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQoN CkZyb206IERpY2sgSGFyZHQgW21haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbV0NClNlbnQ6IFR1 ZXNkYXksIEp1bmUgMzAsIDIwMTUgNjowMSBQTQ0KVG86IE1pa2UgSm9uZXMNCkNjOiBKaW0gU2No YWFkOyBjb3NlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0Nvc2VdIElzc3VlOiBFbmNvZGluZyBm b3IgYSBzaW5nbGUgcmVjaXBpZW50IG9yIHN0cnVjdHVyZQ0KDQpJZiBJJ20gd3JpdGluZyBhIGxp YnJhcnkgYW5kIEkgaGF2ZSB0byBzdXBwb3J0IG11bHRpcGxlIHJlY2lwaWVudHMgdG8gYmUgY29t cGxpYW50LCB0aGVuIGdpdmVuIGEgY2hvaWNlIGJldHdlZW4gZGVhbGluZyB3aXRoIGJvdGggYSBz aW5nbGV0b24gYW5kIGFuIGFycmF5KGEpIHZzIGp1c3QgYW4gYXJyYXkgKGMpLCB0aGVuIEknbGwg cGljayBqdXN0IGFuIGFycmF5IChjKS4gLi4uIG9yIGFtIEkgbWlzc2luZyBzb21lIGFzcGVjdCBv ZiBob3cgdGhpcyBpcyBzaW1wbGVyIE1pa2U/DQoNCk9uIFR1ZSwgSnVuIDMwLCAyMDE1IGF0IDU6 NDUgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpSZXBseSBpbmxpbmUgYmVsb3cuLi4N Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKaW0gU2NoYWFkIFttYWls dG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbTxtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT5d DQo+IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMzAsIDIwMTUgNToxNSBQTQ0KPiBUbzogTWlrZSBKb25l czsgY29zZUBpZXRmLm9yZzxtYWlsdG86Y29zZUBpZXRmLm9yZz4NCj4gU3ViamVjdDogUkU6IFtD b3NlXSBJc3N1ZTogRW5jb2RpbmcgZm9yIGEgc2luZ2xlIHJlY2lwaWVudCBvciBzdHJ1Y3R1cmUN Cj4NCj4NCj4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IE1pa2Ug Sm9uZXMgW21haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbT5dDQo+ID4gU2VudDogVHVlc2RheSwgSnVuZSAzMCwgMjAxNSAz OjQ1IFBNDQo+ID4gVG86IEppbSBTY2hhYWQ7IGNvc2VAaWV0Zi5vcmc8bWFpbHRvOmNvc2VAaWV0 Zi5vcmc+DQo+ID4gU3ViamVjdDogUkU6IFtDb3NlXSBJc3N1ZTogRW5jb2RpbmcgZm9yIGEgc2lu Z2xlIHJlY2lwaWVudCBvcg0KPiA+IHN0cnVjdHVyZQ0KPiA+DQo+ID4gSGkgSmltLA0KPiA+DQo+ ID4gUGVyIHlvdXIgc3VnZ2VzdGlvbiBpbiByZXNwb25zZSB0byBteSBpc3N1ZSAxLCBJJ20gcmV2 aWV3aW5nIHRoaXMgdGhyZWFkLg0KPiA+IChJJ20gYWxzbyBpbmNsdWRpbmcgdGhlIG9yaWdpbmFs IG1lc3NhZ2UgYmVsb3cgc28gV0cgbWVtYmVycyB3aG8NCj4gPiBqb2luZWQgdGhlIGxpc3Qgd2hl biB0aGUgV0cgd2FzIGZvcm1lZCB3aWxsIHNlZSBpdC4pDQo+ID4NCj4gPiBGaXJzdCwgbGV0IG1l IGFzayBhIHF1ZXN0aW9uIHRvIHNlZSBpZiBJIGNvcnJlY3RseSB1bmRlcnN0YW5kIHRoZQ0KPiA+ IHByb2JsZW0NCj4gd2l0aA0KPiA+IHlvdXIgb3B0aW9uICgxKSBiZWxvdy4gIEpXRSB1c2VkICJh bGciIGZvciB0aGUga2V5IG1hbmFnZW1lbnQNCj4gPiBhbGdvcml0aG0gYW5kICJlbmMiIGZvciB0 aGUgY29udGVudCBlbmNyeXB0aW9uIGFsZ29yaXRobS4gIExpa2V3aXNlLA0KPiA+IEpXRSB1c2Vk ICJlbmNyeXB0ZWRfa2V5IiBmb3IgdGhlIGVuY3J5cHRlZCBrZXkgdmFsdWUgYW5kICJjaXBoZXJ0 ZXh0Ig0KPiA+IGZvciB0aGUgZW5jcnlwdGVkIHBsYWludGV4dC4gIFNpbmNlIHRoZXJlIHdlcmUg bm8gbmFtZSBjb2xsaXNpb25zLCBhbGwNCj4gPiBjb3VsZCBsaXZlDQo+IGluDQo+ID4gdGhlIHRv cC1sZXZlbCBKU09OIG9iamVjdC4gIFdoZXJlYXMsIHlvdXIgY3VycmVudCBDT1NFIGRyYWZ0IHVz ZXMgdGhlDQo+ID4gZXF1aXZhbGVudCBvZiAiYWxnIiBmb3IgYm90aCBhbGdvcml0aG1zIGFuZCB0 aGUgZXF1aXZhbGVudCBvZiAiY2lwaGVydGV4dCINCj4gPiBmb3IgYm90aCBlbmNyeXB0ZWQgdmFs dWVzLCBoZW5jZSB0aGUgbGFiZWwgY29sbGlzaW9ucyB5b3UgYXJlIGNpdGluZw0KPiBiZWxvdywN Cj4gPiBjb3JyZWN0Pw0KPiA+DQo+ID4gSWYgbXkgdW5kZXJzdGFuZGluZyBpcyByaWdodCwgdGhl biB1bmxlc3MgYSBKV0UtbGlrZSBhcHByb2FjaCB3ZXJlDQo+ID4gYWRvcHRlZCBpbiB3aGljaCBk aWZmZXJlbnQgbGFiZWxzIGFyZSB1c2VkIGZvciB0aGUgZGlmZmVyZW50IHB1cnBvc2VzLA0KPiA+ IHRoZW4geWVzLCBJIGFncmVlIHRoYXQgKDEpIHdvdWxkbid0IHdvcmsuICBXYXMgdGhpcyBjaGFu Z2UgdG8gYSBzaW5nbGUNCj4gPiBzZXQgb2YgbGFiZWxzDQo+IHRoZQ0KPiA+IGludGVuZGVkIHRv cGljIG9mIHRoZSB0aHJlYWQgIltDb3NlXSBJc3N1ZTogIFJldXNlIHRoZSBFbnJ5cHQNCj4gPiBz dHJ1Y3R1cmUNCj4gZm9yDQo+ID4gcmVjaXBpZW50cyI/ICBJJ20gYXNraW5nIGJlY2F1c2UgYSBs b3Qgb2YgdGhlIHRocmVhZCBlbmRlZCB1cCBiZWluZw0KPiA+IGFib3V0DQo+IGENCj4gPiBkaWZm ZXJlbnQgdG9waWMgLSB3aGV0aGVyIHRoZSBlbmNyeXB0ZWRfa2V5IHZhbHVlIHdvdWxkIGNvbnRh aW4ganVzdA0KPiA+IGFuIGVuY3J5cHRlZCBiYXJlIGtleSBvciB0aGUgZXF1aXZhbGVudCBvZiBh biBlbmNyeXB0ZWQgSldLIHN0cnVjdHVyZS4NCj4gPg0KPiA+IFlvdSBhc2tlZCBpZiBJIGhhZCBh bnl0aGluZyBuZXcgdG8gYWRkIHRvIHRoZSBkaXNjdXNzaW9uLiAgSSdsbCBhZGQNCj4gdGhpcy4u Lg0KPiA+DQo+ID4gSnVzdCBsaWtlIGZvciBKT1NFLCBJIGV4cGVjdCB0aGF0IG1hbnkgYXBwbGlj YXRpb25zIHdpbGwgaW1wbGVtZW50DQo+ID4gb25seQ0KPiB0aGUNCj4gPiBDT1NFIGZlYXR1cmVz IHRoYXQgdGhleSBuZWVkLiAgRm9yIGluc3RhbmNlLCBKV1QgW1JGQyA3NTE5XQ0KPiA+IGltcGxl bWVudGF0aW9ucyBvbmx5IG5lZWQgdG8gaW1wbGVtZW50IHRoZSBKT1NFIENvbXBhY3QgU2VyaWFs aXphdGlvbnMNCj4gPiAtIG5vdCB0aGUgSlNPTiBTZXJpYWxpemF0aW9ucy4gIEkgZXhwZWN0IHRo ZXJlIHRvIGJlIG1hbnkgQ09TRQ0KPiA+IGFwcGxpY2F0aW9ucyB0aGF0IHdpbGwgc2ltaWxhcmx5 IG9ubHkgaW1wbGVtZW50IHN1cHBvcnQgZm9yIGEgc2luZ2xlDQo+ID4gcmVjaXBpZW50LiAgVGhp cw0KPiB3b3VsZA0KPiA+IHNhdmUgb24gY29kZSBzaXplIGFuZCBiZSBzaW1wbGVyLg0KPiA+DQo+ ID4gSSBiZWxpZXZlIHRoYXQgYXBwbGljYXRpb25zIHRoYXQgb25seSB1c2UgYSBzaW5nbGUgcmVj aXBpZW50IHdpbGwgYmUNCj4gPiB0aGUNCj4gbW9zdA0KPiA+IGNvbW1vbiwgaGVuY2UgdGhlIGdv YWwgc3RhdGVkIGluIG15IHJldmlldyB0byBvcHRpbWl6ZSBmb3IgdGhpcyBjYXNlLg0KPiA+IEFz c3VtaW5nIHdlIHRha2UgeW91ciBvcHRpb24gKDEpIG9mZiB0aGUgdGFibGUgYW5kIGxpbWl0IGRp c2N1c3Npb24gdG8NCj4gb25seQ0KPiA+IHlvdXIgb3B0aW9ucyAoMikgYW5kICgzKSBiZWxvdywg dGhlbiB0aGUgY2hvaWNlIHNlZW1zIHRvIGJlIGJldHdlZW4NCj4gPiB0aGVzZSBlZmZlY3RpdmUg Z3JhbW1hcnMgZm9yIHRoZSBzaW5nbGUgcmVjaXBpZW50IGNhc2U6DQo+ID4gICAgICgyKSByZWNp cGllbnRzOiB7cmVjaXBpZW50X2RhdGF9DQo+ID4gICAgICgzKSByZWNpcGllbnRzOiBbe3JlY3Bp ZW50X2RhdGF9XQ0KPiA+DQo+ID4gSWYgeW91J3JlIG9ubHkgZXZlciBidWlsZGluZyBjb2RlIGZv ciB0aGUgc2luZ2xlIHJlY2lwaWVudCBjYXNlLCB0aGVuDQo+ID4gKDIpDQo+IGlzDQo+ID4gc2lt cGxlci4gIEJ1dCBJIGFncmVlIHRoYXQgaWYgeW91J3JlIHVzaW5nIGNvZGUgdGhhdCBzdXBwb3J0 cyBtdWx0aXBsZQ0KPiA+IHJlY2lwaWVudHMsIHRoZW4gKDMpIGlzIHNpbXBsZXIsIGlmIHNvbWV3 aGF0IGxlc3MgZWxlZ2FudC4NCj4NCj4gSSBhbSBnb2luZyB0byBtYWtlIHRoZSBzYW1lIGNoYWxs ZW5nZSB0byB5b3UgdGhhdCBJIG1hZGUgdG8gRGVyaWsgYXQgb25lDQo+IHBvaW50Lg0KPg0KPiBD YW4geW91IHByb3ZpZGUgY29kZSB0byBzaG93IHRoYXQgb3B0aW9uIDIgaXMgc2lnbmlmaWNhbnRs eSBsYXJnZXIgdGhhbiBvcHRpb24NCj4gMz8NCkknbSBub3Qgc2F5aW5nIHRoYXQgdGhlcmUncyBh IHNpZ25pZmljYW50IGNvZGUgc2l6ZSBkaWZmZXJlbmNlLiAgTWF5YmUgeW91IGNhbiB0ZWxsIHVz IGhvdyBtdWNoIGNvZGUgd291bGQgYmUgcmVtb3ZlZCBmcm9tIHlvdXIgaW1wbGVtZW50YXRpb24g aWYgeW91ICNpZmRlZidlZCBvdXQgdGhlIGxvb3BzIGFzc29jaWF0ZWQgd2l0aCBwcm9kdWNpbmcg YW5kIGNvbnN1bWluZyB0aGUgcmVjaXBpZW50cyBhcnJheXMgYW5kIGp1c3QgcmVwbGFjZWQgaXQg d2l0aCBjb2RlIHVzaW5nIGEgc2luZ2xldG9uIGFycmF5IHZhbHVlIChvcHRpb24gMykgb3Igc2lt cGx5IGEgcmVjaXBpZW50X2RhdGEgbWFwIHZhbHVlIChvcHRpb24gMikuICBJIGFkbWl0IHVwIGZy b250IHRoYXQgdGhlcmUgd2lsbCBiZSBhbG1vc3Qgbm8gY29kZSBzaXplIGRpZmZlcmVuY2UgYmV0 d2VlbiAyIG9yIDMgaWYgdGhlIGltcGxlbWVudGF0aW9uIGhhcyBiZWVuIGNvbXBpbGVkIHRvIG9u bHkgc3VwcG9ydCBhIHNpbmdsZSByZWNpcGllbnQuDQoNCk15IG1haW4gcG9pbnQgaW4gcmFpc2lu ZyB0aGlzIGlzc3VlIG5vdyBpcyB3ZSdyZSBsaWtlbHkgdG8gaGVhciB0aGUgc2FtZSB0aGluZyBh Ym91dCBDT1NFIHRoYXQgUmljaGFyZCBCYXJuZXMgaGVhcmQgZnJvbSBkZXZlbG9wZXJzIHdobyB3 ZXJlIHJlYWxseSB1c2luZyB0aGUgSlNPTiBTZXJpYWxpemF0aW9ucyBiZWZvcmUgd2UgYWRkZWQg dGhlIGZsYXR0ZW5lZCBkYXRhIHJlcHJlc2VudGF0aW9uIC0gdGhhdCBoYXZpbmcgdG8gZW1pdCBh bmQgcGFyc2UgYSBzaW5nbGV0b24gYXJyYXkgaXMgdWdseSwgYXdrd2FyZCwgZXRjLg0KDQpUaGlz IGlzbid0IGEgc2hvdy1zdG9wcGVyIHRvIG1lLCBidXQgbm93IHRoYXQgdGhlcmUncyBhIHdvcmtp bmcgZ3JvdXAsIEkgd2FudGVkIHRvIHJhaXNlIHRoZSBpc3N1ZSBmb3IgdGhlIHdvcmtpbmcgZ3Jv dXAgdG8gZXhwbGljaXRseSBjb25zaWRlciB1cCBmcm9udCwgcmF0aGVyIHRoYW4gd2FpdCB1bnRp bCBwZW9wbGUgYXJlIHVzaW5nIGVhcmx5IGltcGxlbWVudGF0aW9ucyBhbmQgd2UgaGVhciBiYWNr IGZyb20gZGV2ZWxvcGVycyAid2h5IGNvdWxkbid0IHRoaXMgaGF2ZSBiZWVuIHNpbXBsZXIgaW4g dGhlIHNpbXBsZSBjYXNlIj8NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaGVl cnMsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KPiBKaW0NCj4N Cj4gPg0KPiA+IFdoYXQgZG8gb3RoZXJzIHRoaW5rIGFib3V0IHRoaXMgdHJhZGVvZmY/DQo+ID4N Cj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KPiA+DQo+ID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBDb3NlIFttYWlsdG86Y29zZS1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpjb3NlLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgSmlt IFNjaGFhZA0KPiA+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAzMCwgMjAxNSAzOjU5IFBNDQo+ID4g VG86IGNvc2VAaWV0Zi5vcmc8bWFpbHRvOmNvc2VAaWV0Zi5vcmc+DQo+ID4gU3ViamVjdDogW0Nv c2VdIElzc3VlOiBFbmNvZGluZyBmb3IgYSBzaW5nbGUgcmVjaXBpZW50IG9yIHN0cnVjdHVyZQ0K PiA+DQo+ID4gUXVlc3Rpb246IEZsYXR0ZW5lZCBlbmNvZGluZyAtDQo+ID4gYSkgIFJvbGwgaW50 byBwYXJlbnQgbWFwDQo+ID4gYikgIEp1c3QgYmUgYSBtYXANCj4gPiBjKSAgU2luZ2xlIGVsZW1l bnQgaW4gYXJyYXkNCj4gPg0KPiA+IERpc2N1c3Npb246DQo+ID4NCj4gPiBBIGxhdGUgYWRkaXRp b24gdG8gdGhlIEpPU0Ugc3BlY2lmaWNhdGlvbiB3YXMgdGhlIGFiaWxpdHkgdG8gZm9sZCBhDQo+ ID4gc2luZ2xlIHJlY2lwaWVudCBtYXAgaW50byB0aGUgYmFzZSBlbmNyeXB0aW9uIG9yIHNpZ25h dHVyZSBtYXAuICBUaGlzDQo+ID4gaXMgZG9hYmxlIGJlY2F1c2UgdGhlIGtleXMgZm9yIGFsbCBv ZiB0aGUgbWFwcyBpbiBxdWVzdGlvbiBhcmUgdW5pcXVlLg0KPiA+IFRoaXMgd291bGQNCj4gbm90 DQo+ID4gYmUgdHJ1ZSBpZiB0aGUgaXNzdWUgb24gcmV1c2luZyB0aGUgZW5jcnlwdGlvbiBib2R5 IGZvciB0aGUgcmVjaXBpZW50DQo+ID4gc3RydWN0dXJlIGlzIGFjY2VwdGVkLiAgVGhpcyBpc3N1 ZSBpcyBiZWluZyBkaXNjdXNzZWQgaW4gYSBzZXBhcmF0ZQ0KPiA+IG1haWwNCj4gdGhyZWFkDQo+ ID4gKGJ1dCBpcyBjdXJyZW50KS4gIElmIGFycmF5cyB3ZXJlIHRvIGJlIHVzZWQgYXQgdGhlIHRv cCBsZXZlbCwgb25lDQo+ID4ganVzdA0KPiBhcHBlbmRzDQo+ID4gdGhlIGVsZW1lbnRzIHRvIHRo ZSBlbmQgb2YgdGhlIGJhc2Ugc3RydWN0dXJlICAoc2VlIGV4YW1wbGVzIGluIHRoZQ0KPiBjdXJy ZW50DQo+ID4gZG9jdW1lbnQpLg0KPiA+DQo+ID4gVGhlcmUgYXJlIHRocmVlIGRpZmZlcmVudCBv cHRpb25zIHRoYXQgY2FuIGJlIHNlbGVjdGVkIGF0IHRoaXMgcG9pbnQ6DQo+ID4NCj4gPiAxKSAg VGhlIHJlY2lwaWVudC9zaWduYXR1cmUgbWFwIGlzIGZvbGRlZCBpbnRvIHRoZSBlbmNyeXB0aW9u L3NpZ25pbmcNCj4gPiBtZXNzYWdlIHRvcCBsZXZlbC4gIElmIHdlIGFjY2VwdCB0aGUgY2hhbmdl IGZvciB1c2luZyB0aGUgc2FtZQ0KPiA+IHN0cnVjdHVyZQ0KPiBmb3INCj4gPiBib3RoIHRoZSBl bmNyeXB0aW9uIGJvZHkgYW5kIHRoZSByZWNpcGllbnRzLCB0aGlzIGlzIG5vdCBhIHZpYWJsZQ0K PiA+IG9wdGlvbg0KPiBkdWUNCj4gPiB0byBjb2xsaXNpb25zIG9mIGtleXMgaW4gdGhlIG1hcC4N Cj4gPg0KPiA+IDIpICBUaGUgcmVjaXBpZW50L3NpZ25hdHVyZSBlbGVtZW50IGluIHRoZSBiYXNl IG1hcCBpcyBwZXJtaXR0ZWQgdG8gYmUNCj4gPiBlaXRoZXIgYW4gYXJyYXkgb2YgcmVjaXBpZW50 L3NpZ25hdHVyZSBlbGVtZW50cyBvciBhIHNpbmdsZQ0KPiA+IHJlY2lwaWVudC9zaWduYXR1cmUg bWFwLiAgVGhpcyBvcHRpb24gd2FzIHJlamVjdGVkIGJ5IHRoZSBKT1NFIGdyb3VwDQo+ID4gYXMg YmVpbmcgdG9vIGNvbXBsaWNhdGVkIGZvciBwcm9ncmFtbWVycyB0byBkZWFsIHdpdGguICBUaGUg Y29zdCBvZg0KPiA+IHRoaXMgb3B0aW9uIGlzIDIgYnl0ZXMgb3ZlciBvcHRpb24gb25lLiAgKE9u ZSBieXRlIGZvciB0aGUgcmVjaXBpZW50cw0KPiA+IGtleSwgb25lIGJ5dGUgZm9yIHRoZSBtYXAg bWFya2VyLikNCj4gPg0KPiA+IENEREwgZ3JhbW1hciB3b3VsZCBiZTogIHJlY2lwaWVudHM6IFsr W3JlY2lwaWVudF9kYXRhXV0gLw0KPiA+IHtyZWNpcGllbnRfZGF0YX0NCj4gPg0KPiA+IDMpICBX ZSBkbyBub3Qgc3VwcG9ydCBhbnkgc3BlY2lhbCBmb3JtIG9mIGRlYWxpbmcgd2l0aCBhIHNpbmds ZSByZWNpcGllbnQuDQo+ID4gVGhlIGNvc3Qgb2YgdGhpcyBvcHRpb24gaXMgMyBieXRlcyBvdmVy IG9wdGlvbiBvbmUuICAoT25lIGJ5dGUgZm9yIHRoZQ0KPiA+IHJlY2lwaWVudHMga2V5LCBvbmUg Ynl0ZSBmb3IgdGhlIGFycmF5IG1hcmtlciwgb25lIGJ5dGUgZm9yIHRoZSBtYXANCj4gbWFya2Vy LikNCj4gPg0KPiA+IENEREwgZ3JhbW1hciB3b3VsZCBiZTogIHJlY2lwaWVudHM6IFsrW3JlY3Bp ZW50X2RhdGFdXQ0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiBDb3NlIG1haWxpbmcgbGlzdA0KPiA+IENvc2VAaWV0Zi5vcmc8bWFp bHRvOkNvc2VAaWV0Zi5vcmc+DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jb3NlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpDb3NlIG1haWxpbmcgbGlzdA0KQ29zZUBpZXRmLm9yZzxtYWlsdG86Q29zZUBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29zZQ0KDQo= --_000_BL2PR03MB433110A60A3FE944DDB0865F5A80BL2PR03MB433namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TXkgdW5kZXJseWluZyBhc3N1bXB0aW9uIGlzIHRo YXQganVzdCBsaWtlIHdlIGRpZCBpbiBKT1NFLCB5b3UgKjxiPmRvbuKAmXQ8L2I+KiBoYXZlIHRv IHN1cHBvcnQgbXVsdGlwbGUgcmVjaXBpZW50cyB0byBiZSBjb21wbGlhbnQuJm5ic3A7DQo8YSBo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTE1I3NlY3Rpb24tNyI+aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxNSNzZWN0aW9uLTc8L2E+IHNheXM6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxh bmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyBKV1NzIHVzZSBvbmUgb2YgdHdvIHNlcmlhbGl6YXRpb25zOiB0aGUgSldTIENvbXBh Y3QgU2VyaWFsaXphdGlvbiBvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB0 aGUgSldTIEpTT04gU2VyaWFsaXphdGlvbi4mbmJzcDsgQXBwbGljYXRpb25zIHVzaW5nIHRoaXMg c3BlY2lmaWNhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBuZWVkIHRv IHNwZWNpZnkgd2hhdCBzZXJpYWxpemF0aW9uIGFuZCBzZXJpYWxpemF0aW9uIGZlYXR1cmVzIGFy ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB1c2VkIGZvciB0aGF0IGFwcGxp Y2F0aW9uLiZuYnNwOyBGb3IgaW5zdGFuY2UsIGFwcGxpY2F0aW9ucyBtaWdodCBzcGVjaWZ5PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJl YWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHRoYXQgb25seSB0aGUgSldTIEpTT04g U2VyaWFsaXphdGlvbiBpcyB1c2VkLCB0aGF0DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxs b3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPm9ubHkgSldTIEpTT048bzpwPjwvbzpwPjwvc3Bhbj48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3Jl OmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OztiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+Jm5ic3A7 Jm5ic3A7IFNlcmlhbGl6YXRpb24gc3VwcG9ydCBmb3IgYSBzaW5nbGUgc2lnbmF0dXJlIG9yIE1B QyB2YWx1ZSBpcyB1c2VkPC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiwNCiBvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFu IGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyB0aGF0IHN1cHBvcnQgZm9yIG11bHRpcGxlIHNpZ25hdHVyZXMgYW5kL29yIE1B QyB2YWx1ZXMgaXMgdXNlZC4mbmJzcDsNCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdztt c28taGlnaGxpZ2h0OnllbGxvdyI+SldTPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFu IGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7YmFj a2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPiZuYnNwOyZuYnNwOyBpbXBsZW1l bnRhdGlvbnMgb25seSBuZWVkIHRvIGltcGxlbWVudCB0aGUgZmVhdHVyZXMgbmVlZGVkIGZvciB0 aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFn ZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2JhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6 eWVsbG93Ij4mbmJzcDsmbmJzcDsgYXBwbGljYXRpb25zIHRoZXkgYXJlIGRlc2lnbmVkIHRvIHN1 cHBvcnQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW5kZWVkLCBJIGJlbGlldmUgdGhhdCB3ZSBzaG91 bGQgYWRkIGVxdWl2YWxlbnQgdGV4dCB0byBDT1NFLCBiZWNhdXNlIGl04oCZcyBldmVuIG1vcmUg bGlrZWx5IGluIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cyB0aGFuIFdlYiBlbnZpcm9ubWVudHMg dGhhdCBhcHBsaWNhdGlvbnMNCiB3aWxsIHNwZWNpZnkgdGhhdCB0aGV5IGFyZSBvbmx5IHVzaW5n IHN1YnNldHMgb2YgdGhlIENPU0UtZGVmaW5lZCBmZWF0dXJlcyBhbmQgdGhhdCBnZW5lcmFsLXB1 cnBvc2UgbGlicmFyaWVzIHdpbGwgYmUgY29tcGlsZWQgZm9yIHNwZWNpZmljIGFwcGxpY2F0aW9u cyB3aXRoICNpZmRlZiBzZXR0aW5ncyB0byByZW1vdmUgdW51c2VkIGNvZGUgcGF0aHMuJm5ic3A7 IEkgcGxhbiB0byBwcm9wb3NlIGV4YWN0IHRleHQgYWxvbmcgdGhlc2UgbGluZXMgZm9yIGluY2x1 c2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBN aWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gRGljayBIYXJkdCBbbWFpbHRvOmRpY2suaGFyZHRA Z21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bmUgMzAsIDIwMTUgNjow MSBQTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lczxicj4NCjxiPkNjOjwvYj4gSmltIFNjaGFh ZDsgY29zZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0Nvc2VdIElzc3VlOiBF bmNvZGluZyBmb3IgYSBzaW5nbGUgcmVjaXBpZW50IG9yIHN0cnVjdHVyZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIEknbSB3cml0aW5nIGEgbGlicmFyeSBhbmQgSSBo YXZlIHRvIHN1cHBvcnQgbXVsdGlwbGUgcmVjaXBpZW50cyB0byBiZSBjb21wbGlhbnQsIHRoZW4g Z2l2ZW4gYSBjaG9pY2UgYmV0d2VlbiBkZWFsaW5nIHdpdGggYm90aCBhIHNpbmdsZXRvbiBhbmQg YW4gYXJyYXkoYSkgdnMganVzdCBhbiBhcnJheSAoYyksIHRoZW4gSSdsbCBwaWNrIGp1c3QgYW4g YXJyYXkgKGMpLiAuLi4gb3IgYW0gSSBtaXNzaW5nIHNvbWUNCiBhc3BlY3Qgb2YgaG93IHRoaXMg aXMgc2ltcGxlciBNaWtlPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gVHVlLCBKdW4gMzAsIDIwMTUgYXQgNTo0NSBQTSwgTWlrZSBKb25lcyAm bHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJf YmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVwbHkgaW5saW5lIGJlbG93Li4uPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4NCiZndDsgRnJvbTogSmltIFNjaGFhZCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzppZXRmQGF1 Z3VzdGNlbGxhcnMuY29tIj5pZXRmQGF1Z3VzdGNlbGxhcnMuY29tPC9hPl08YnI+DQomZ3Q7IFNl bnQ6IFR1ZXNkYXksIEp1bmUgMzAsIDIwMTUgNToxNSBQTTxicj4NCiZndDsgVG86IE1pa2UgSm9u ZXM7IDxhIGhyZWY9Im1haWx0bzpjb3NlQGlldGYub3JnIj5jb3NlQGlldGYub3JnPC9hPjxicj4N CiZndDsgU3ViamVjdDogUkU6IFtDb3NlXSBJc3N1ZTogRW5jb2RpbmcgZm9yIGEgc2luZ2xlIHJl Y2lwaWVudCBvciBzdHJ1Y3R1cmU8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQom Z3Q7ICZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsgRnJvbTog TWlrZSBKb25lcyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT5dPGJyPg0KJmd0OyAmZ3Q7IFNl bnQ6IFR1ZXNkYXksIEp1bmUgMzAsIDIwMTUgMzo0NSBQTTxicj4NCiZndDsgJmd0OyBUbzogSmlt IFNjaGFhZDsgPGEgaHJlZj0ibWFpbHRvOmNvc2VAaWV0Zi5vcmciPmNvc2VAaWV0Zi5vcmc8L2E+ PGJyPg0KJmd0OyAmZ3Q7IFN1YmplY3Q6IFJFOiBbQ29zZV0gSXNzdWU6IEVuY29kaW5nIGZvciBh IHNpbmdsZSByZWNpcGllbnQgb3I8YnI+DQomZ3Q7ICZndDsgc3RydWN0dXJlPGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7IEhpIEppbSw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg UGVyIHlvdXIgc3VnZ2VzdGlvbiBpbiByZXNwb25zZSB0byBteSBpc3N1ZSAxLCBJJ20gcmV2aWV3 aW5nIHRoaXMgdGhyZWFkLjxicj4NCiZndDsgJmd0OyAoSSdtIGFsc28gaW5jbHVkaW5nIHRoZSBv cmlnaW5hbCBtZXNzYWdlIGJlbG93IHNvIFdHIG1lbWJlcnMgd2hvPGJyPg0KJmd0OyAmZ3Q7IGpv aW5lZCB0aGUgbGlzdCB3aGVuIHRoZSBXRyB3YXMgZm9ybWVkIHdpbGwgc2VlIGl0Lik8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgRmlyc3QsIGxldCBtZSBhc2sgYSBxdWVzdGlvbiB0byBz ZWUgaWYgSSBjb3JyZWN0bHkgdW5kZXJzdGFuZCB0aGU8YnI+DQomZ3Q7ICZndDsgcHJvYmxlbTxi cj4NCiZndDsgd2l0aDxicj4NCiZndDsgJmd0OyB5b3VyIG9wdGlvbiAoMSkgYmVsb3cuJm5ic3A7 IEpXRSB1c2VkICZxdW90O2FsZyZxdW90OyBmb3IgdGhlIGtleSBtYW5hZ2VtZW50PGJyPg0KJmd0 OyAmZ3Q7IGFsZ29yaXRobSBhbmQgJnF1b3Q7ZW5jJnF1b3Q7IGZvciB0aGUgY29udGVudCBlbmNy eXB0aW9uIGFsZ29yaXRobS4mbmJzcDsgTGlrZXdpc2UsPGJyPg0KJmd0OyAmZ3Q7IEpXRSB1c2Vk ICZxdW90O2VuY3J5cHRlZF9rZXkmcXVvdDsgZm9yIHRoZSBlbmNyeXB0ZWQga2V5IHZhbHVlIGFu ZCAmcXVvdDtjaXBoZXJ0ZXh0JnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7IGZvciB0aGUgZW5jcnlwdGVk IHBsYWludGV4dC4mbmJzcDsgU2luY2UgdGhlcmUgd2VyZSBubyBuYW1lIGNvbGxpc2lvbnMsIGFs bDxicj4NCiZndDsgJmd0OyBjb3VsZCBsaXZlPGJyPg0KJmd0OyBpbjxicj4NCiZndDsgJmd0OyB0 aGUgdG9wLWxldmVsIEpTT04gb2JqZWN0LiZuYnNwOyBXaGVyZWFzLCB5b3VyIGN1cnJlbnQgQ09T RSBkcmFmdCB1c2VzIHRoZTxicj4NCiZndDsgJmd0OyBlcXVpdmFsZW50IG9mICZxdW90O2FsZyZx dW90OyBmb3IgYm90aCBhbGdvcml0aG1zIGFuZCB0aGUgZXF1aXZhbGVudCBvZiAmcXVvdDtjaXBo ZXJ0ZXh0JnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7IGZvciBib3RoIGVuY3J5cHRlZCB2YWx1ZXMsIGhl bmNlIHRoZSBsYWJlbCBjb2xsaXNpb25zIHlvdSBhcmUgY2l0aW5nPGJyPg0KJmd0OyBiZWxvdyw8 YnI+DQomZ3Q7ICZndDsgY29ycmVjdD88YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSWYg bXkgdW5kZXJzdGFuZGluZyBpcyByaWdodCwgdGhlbiB1bmxlc3MgYSBKV0UtbGlrZSBhcHByb2Fj aCB3ZXJlPGJyPg0KJmd0OyAmZ3Q7IGFkb3B0ZWQgaW4gd2hpY2ggZGlmZmVyZW50IGxhYmVscyBh cmUgdXNlZCBmb3IgdGhlIGRpZmZlcmVudCBwdXJwb3Nlcyw8YnI+DQomZ3Q7ICZndDsgdGhlbiB5 ZXMsIEkgYWdyZWUgdGhhdCAoMSkgd291bGRuJ3Qgd29yay4mbmJzcDsgV2FzIHRoaXMgY2hhbmdl IHRvIGEgc2luZ2xlPGJyPg0KJmd0OyAmZ3Q7IHNldCBvZiBsYWJlbHM8YnI+DQomZ3Q7IHRoZTxi cj4NCiZndDsgJmd0OyBpbnRlbmRlZCB0b3BpYyBvZiB0aGUgdGhyZWFkICZxdW90O1tDb3NlXSBJ c3N1ZTombmJzcDsgUmV1c2UgdGhlIEVucnlwdDxicj4NCiZndDsgJmd0OyBzdHJ1Y3R1cmU8YnI+ DQomZ3Q7IGZvcjxicj4NCiZndDsgJmd0OyByZWNpcGllbnRzJnF1b3Q7PyZuYnNwOyBJJ20gYXNr aW5nIGJlY2F1c2UgYSBsb3Qgb2YgdGhlIHRocmVhZCBlbmRlZCB1cCBiZWluZzxicj4NCiZndDsg Jmd0OyBhYm91dDxicj4NCiZndDsgYTxicj4NCiZndDsgJmd0OyBkaWZmZXJlbnQgdG9waWMgLSB3 aGV0aGVyIHRoZSBlbmNyeXB0ZWRfa2V5IHZhbHVlIHdvdWxkIGNvbnRhaW4ganVzdDxicj4NCiZn dDsgJmd0OyBhbiBlbmNyeXB0ZWQgYmFyZSBrZXkgb3IgdGhlIGVxdWl2YWxlbnQgb2YgYW4gZW5j cnlwdGVkIEpXSyBzdHJ1Y3R1cmUuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFlvdSBh c2tlZCBpZiBJIGhhZCBhbnl0aGluZyBuZXcgdG8gYWRkIHRvIHRoZSBkaXNjdXNzaW9uLiZuYnNw OyBJJ2xsIGFkZDxicj4NCiZndDsgdGhpcy4uLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyBKdXN0IGxpa2UgZm9yIEpPU0UsIEkgZXhwZWN0IHRoYXQgbWFueSBhcHBsaWNhdGlvbnMgd2ls bCBpbXBsZW1lbnQ8YnI+DQomZ3Q7ICZndDsgb25seTxicj4NCiZndDsgdGhlPGJyPg0KJmd0OyAm Z3Q7IENPU0UgZmVhdHVyZXMgdGhhdCB0aGV5IG5lZWQuJm5ic3A7IEZvciBpbnN0YW5jZSwgSldU IFtSRkMgNzUxOV08YnI+DQomZ3Q7ICZndDsgaW1wbGVtZW50YXRpb25zIG9ubHkgbmVlZCB0byBp bXBsZW1lbnQgdGhlIEpPU0UgQ29tcGFjdCBTZXJpYWxpemF0aW9uczxicj4NCiZndDsgJmd0OyAt IG5vdCB0aGUgSlNPTiBTZXJpYWxpemF0aW9ucy4mbmJzcDsgSSBleHBlY3QgdGhlcmUgdG8gYmUg bWFueSBDT1NFPGJyPg0KJmd0OyAmZ3Q7IGFwcGxpY2F0aW9ucyB0aGF0IHdpbGwgc2ltaWxhcmx5 IG9ubHkgaW1wbGVtZW50IHN1cHBvcnQgZm9yIGEgc2luZ2xlPGJyPg0KJmd0OyAmZ3Q7IHJlY2lw aWVudC4mbmJzcDsgVGhpczxicj4NCiZndDsgd291bGQ8YnI+DQomZ3Q7ICZndDsgc2F2ZSBvbiBj b2RlIHNpemUgYW5kIGJlIHNpbXBsZXIuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEkg YmVsaWV2ZSB0aGF0IGFwcGxpY2F0aW9ucyB0aGF0IG9ubHkgdXNlIGEgc2luZ2xlIHJlY2lwaWVu dCB3aWxsIGJlPGJyPg0KJmd0OyAmZ3Q7IHRoZTxicj4NCiZndDsgbW9zdDxicj4NCiZndDsgJmd0 OyBjb21tb24sIGhlbmNlIHRoZSBnb2FsIHN0YXRlZCBpbiBteSByZXZpZXcgdG8gb3B0aW1pemUg Zm9yIHRoaXMgY2FzZS48YnI+DQomZ3Q7ICZndDsgQXNzdW1pbmcgd2UgdGFrZSB5b3VyIG9wdGlv biAoMSkgb2ZmIHRoZSB0YWJsZSBhbmQgbGltaXQgZGlzY3Vzc2lvbiB0bzxicj4NCiZndDsgb25s eTxicj4NCiZndDsgJmd0OyB5b3VyIG9wdGlvbnMgKDIpIGFuZCAoMykgYmVsb3csIHRoZW4gdGhl IGNob2ljZSBzZWVtcyB0byBiZSBiZXR3ZWVuPGJyPg0KJmd0OyAmZ3Q7IHRoZXNlIGVmZmVjdGl2 ZSBncmFtbWFycyBmb3IgdGhlIHNpbmdsZSByZWNpcGllbnQgY2FzZTo8YnI+DQomZ3Q7ICZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOygyKSByZWNpcGllbnRzOiB7cmVjaXBpZW50X2RhdGF9PGJyPg0K Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsoMykgcmVjaXBpZW50czogW3tyZWNwaWVudF9k YXRhfV08YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSWYgeW91J3JlIG9ubHkgZXZlciBi dWlsZGluZyBjb2RlIGZvciB0aGUgc2luZ2xlIHJlY2lwaWVudCBjYXNlLCB0aGVuPGJyPg0KJmd0 OyAmZ3Q7ICgyKTxicj4NCiZndDsgaXM8YnI+DQomZ3Q7ICZndDsgc2ltcGxlci4mbmJzcDsgQnV0 IEkgYWdyZWUgdGhhdCBpZiB5b3UncmUgdXNpbmcgY29kZSB0aGF0IHN1cHBvcnRzIG11bHRpcGxl PGJyPg0KJmd0OyAmZ3Q7IHJlY2lwaWVudHMsIHRoZW4gKDMpIGlzIHNpbXBsZXIsIGlmIHNvbWV3 aGF0IGxlc3MgZWxlZ2FudC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGFtIGdvaW5nIHRvIG1ha2Ug dGhlIHNhbWUgY2hhbGxlbmdlIHRvIHlvdSB0aGF0IEkgbWFkZSB0byBEZXJpayBhdCBvbmU8YnI+ DQomZ3Q7IHBvaW50Ljxicj4NCiZndDs8YnI+DQomZ3Q7IENhbiB5b3UgcHJvdmlkZSBjb2RlIHRv IHNob3cgdGhhdCBvcHRpb24gMiBpcyBzaWduaWZpY2FudGx5IGxhcmdlciB0aGFuIG9wdGlvbjxi cj4NCiZndDsgMz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JJ20gbm90IHNheWluZyB0aGF0IHRoZXJlJ3MgYSBzaWduaWZpY2FudCBjb2RlIHNp emUgZGlmZmVyZW5jZS4mbmJzcDsgTWF5YmUgeW91IGNhbiB0ZWxsIHVzIGhvdyBtdWNoIGNvZGUg d291bGQgYmUgcmVtb3ZlZCBmcm9tIHlvdXIgaW1wbGVtZW50YXRpb24gaWYgeW91ICNpZmRlZidl ZCBvdXQgdGhlIGxvb3BzIGFzc29jaWF0ZWQgd2l0aCBwcm9kdWNpbmcgYW5kIGNvbnN1bWluZyB0 aGUgcmVjaXBpZW50cyBhcnJheXMNCiBhbmQganVzdCByZXBsYWNlZCBpdCB3aXRoIGNvZGUgdXNp bmcgYSBzaW5nbGV0b24gYXJyYXkgdmFsdWUgKG9wdGlvbiAzKSBvciBzaW1wbHkgYSByZWNpcGll bnRfZGF0YSBtYXAgdmFsdWUgKG9wdGlvbiAyKS4mbmJzcDsgSSBhZG1pdCB1cCBmcm9udCB0aGF0 IHRoZXJlIHdpbGwgYmUgYWxtb3N0IG5vIGNvZGUgc2l6ZSBkaWZmZXJlbmNlIGJldHdlZW4gMiBv ciAzIGlmIHRoZSBpbXBsZW1lbnRhdGlvbiBoYXMgYmVlbiBjb21waWxlZCB0byBvbmx5IHN1cHBv cnQNCiBhIHNpbmdsZSByZWNpcGllbnQuPGJyPg0KPGJyPg0KTXkgbWFpbiBwb2ludCBpbiByYWlz aW5nIHRoaXMgaXNzdWUgbm93IGlzIHdlJ3JlIGxpa2VseSB0byBoZWFyIHRoZSBzYW1lIHRoaW5n IGFib3V0IENPU0UgdGhhdCBSaWNoYXJkIEJhcm5lcyBoZWFyZCBmcm9tIGRldmVsb3BlcnMgd2hv IHdlcmUgcmVhbGx5IHVzaW5nIHRoZSBKU09OIFNlcmlhbGl6YXRpb25zIGJlZm9yZSB3ZSBhZGRl ZCB0aGUgZmxhdHRlbmVkIGRhdGEgcmVwcmVzZW50YXRpb24gLSB0aGF0IGhhdmluZyB0byBlbWl0 IGFuZCBwYXJzZQ0KIGEgc2luZ2xldG9uIGFycmF5IGlzIHVnbHksIGF3a3dhcmQsIGV0Yy48YnI+ DQo8YnI+DQpUaGlzIGlzbid0IGEgc2hvdy1zdG9wcGVyIHRvIG1lLCBidXQgbm93IHRoYXQgdGhl cmUncyBhIHdvcmtpbmcgZ3JvdXAsIEkgd2FudGVkIHRvIHJhaXNlIHRoZSBpc3N1ZSBmb3IgdGhl IHdvcmtpbmcgZ3JvdXAgdG8gZXhwbGljaXRseSBjb25zaWRlciB1cCBmcm9udCwgcmF0aGVyIHRo YW4gd2FpdCB1bnRpbCBwZW9wbGUgYXJlIHVzaW5nIGVhcmx5IGltcGxlbWVudGF0aW9ucyBhbmQg d2UgaGVhciBiYWNrIGZyb20gZGV2ZWxvcGVycyAmcXVvdDt3aHkgY291bGRuJ3QNCiB0aGlzIGhh dmUgYmVlbiBzaW1wbGVyIGluIHRoZSBzaW1wbGUgY2FzZSZxdW90Oz88YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQ2hlZXJz LDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAtLSBNaWtlPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCiZndDsgSmltPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyBXaGF0IGRvIG90aGVycyB0aGluayBhYm91dCB0aGlzIHRyYWRlb2ZmPzxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7LS0gTWlrZTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyBGcm9tOiBDb3NlIFttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOmNvc2UtYm91bmNlc0BpZXRmLm9yZyI+Y29zZS1ib3VuY2VzQGlldGYub3JnPC9h Pl0gT24gQmVoYWxmIE9mIEppbSBTY2hhYWQ8YnI+DQomZ3Q7ICZndDsgU2VudDogVGh1cnNkYXks IEFwcmlsIDMwLCAyMDE1IDM6NTkgUE08YnI+DQomZ3Q7ICZndDsgVG86IDxhIGhyZWY9Im1haWx0 bzpjb3NlQGlldGYub3JnIj5jb3NlQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyBTdWJqZWN0 OiBbQ29zZV0gSXNzdWU6IEVuY29kaW5nIGZvciBhIHNpbmdsZSByZWNpcGllbnQgb3Igc3RydWN0 dXJlPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFF1ZXN0aW9uOiBGbGF0dGVuZWQgZW5j b2RpbmcgLTxicj4NCiZndDsgJmd0OyBhKSZuYnNwOyBSb2xsIGludG8gcGFyZW50IG1hcDxicj4N CiZndDsgJmd0OyBiKSZuYnNwOyBKdXN0IGJlIGEgbWFwPGJyPg0KJmd0OyAmZ3Q7IGMpJm5ic3A7 IFNpbmdsZSBlbGVtZW50IGluIGFycmF5PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IERp c2N1c3Npb246PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEEgbGF0ZSBhZGRpdGlvbiB0 byB0aGUgSk9TRSBzcGVjaWZpY2F0aW9uIHdhcyB0aGUgYWJpbGl0eSB0byBmb2xkIGE8YnI+DQom Z3Q7ICZndDsgc2luZ2xlIHJlY2lwaWVudCBtYXAgaW50byB0aGUgYmFzZSBlbmNyeXB0aW9uIG9y IHNpZ25hdHVyZSBtYXAuJm5ic3A7IFRoaXM8YnI+DQomZ3Q7ICZndDsgaXMgZG9hYmxlIGJlY2F1 c2UgdGhlIGtleXMgZm9yIGFsbCBvZiB0aGUgbWFwcyBpbiBxdWVzdGlvbiBhcmUgdW5pcXVlLjxi cj4NCiZndDsgJmd0OyBUaGlzIHdvdWxkPGJyPg0KJmd0OyBub3Q8YnI+DQomZ3Q7ICZndDsgYmUg dHJ1ZSBpZiB0aGUgaXNzdWUgb24gcmV1c2luZyB0aGUgZW5jcnlwdGlvbiBib2R5IGZvciB0aGUg cmVjaXBpZW50PGJyPg0KJmd0OyAmZ3Q7IHN0cnVjdHVyZSBpcyBhY2NlcHRlZC4mbmJzcDsgVGhp cyBpc3N1ZSBpcyBiZWluZyBkaXNjdXNzZWQgaW4gYSBzZXBhcmF0ZTxicj4NCiZndDsgJmd0OyBt YWlsPGJyPg0KJmd0OyB0aHJlYWQ8YnI+DQomZ3Q7ICZndDsgKGJ1dCBpcyBjdXJyZW50KS4mbmJz cDsgSWYgYXJyYXlzIHdlcmUgdG8gYmUgdXNlZCBhdCB0aGUgdG9wIGxldmVsLCBvbmU8YnI+DQom Z3Q7ICZndDsganVzdDxicj4NCiZndDsgYXBwZW5kczxicj4NCiZndDsgJmd0OyB0aGUgZWxlbWVu dHMgdG8gdGhlIGVuZCBvZiB0aGUgYmFzZSBzdHJ1Y3R1cmUmbmJzcDsgKHNlZSBleGFtcGxlcyBp biB0aGU8YnI+DQomZ3Q7IGN1cnJlbnQ8YnI+DQomZ3Q7ICZndDsgZG9jdW1lbnQpLjxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGVyZSBhcmUgdGhyZWUgZGlmZmVyZW50IG9wdGlvbnMg dGhhdCBjYW4gYmUgc2VsZWN0ZWQgYXQgdGhpcyBwb2ludDo8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgMSkmbmJzcDsgVGhlIHJlY2lwaWVudC9zaWduYXR1cmUgbWFwIGlzIGZvbGRlZCBp bnRvIHRoZSBlbmNyeXB0aW9uL3NpZ25pbmc8YnI+DQomZ3Q7ICZndDsgbWVzc2FnZSB0b3AgbGV2 ZWwuJm5ic3A7IElmIHdlIGFjY2VwdCB0aGUgY2hhbmdlIGZvciB1c2luZyB0aGUgc2FtZTxicj4N CiZndDsgJmd0OyBzdHJ1Y3R1cmU8YnI+DQomZ3Q7IGZvcjxicj4NCiZndDsgJmd0OyBib3RoIHRo ZSBlbmNyeXB0aW9uIGJvZHkgYW5kIHRoZSByZWNpcGllbnRzLCB0aGlzIGlzIG5vdCBhIHZpYWJs ZTxicj4NCiZndDsgJmd0OyBvcHRpb248YnI+DQomZ3Q7IGR1ZTxicj4NCiZndDsgJmd0OyB0byBj b2xsaXNpb25zIG9mIGtleXMgaW4gdGhlIG1hcC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgMikmbmJzcDsgVGhlIHJlY2lwaWVudC9zaWduYXR1cmUgZWxlbWVudCBpbiB0aGUgYmFzZSBt YXAgaXMgcGVybWl0dGVkIHRvIGJlPGJyPg0KJmd0OyAmZ3Q7IGVpdGhlciBhbiBhcnJheSBvZiBy ZWNpcGllbnQvc2lnbmF0dXJlIGVsZW1lbnRzIG9yIGEgc2luZ2xlPGJyPg0KJmd0OyAmZ3Q7IHJl Y2lwaWVudC9zaWduYXR1cmUgbWFwLiZuYnNwOyBUaGlzIG9wdGlvbiB3YXMgcmVqZWN0ZWQgYnkg dGhlIEpPU0UgZ3JvdXA8YnI+DQomZ3Q7ICZndDsgYXMgYmVpbmcgdG9vIGNvbXBsaWNhdGVkIGZv ciBwcm9ncmFtbWVycyB0byBkZWFsIHdpdGguJm5ic3A7IFRoZSBjb3N0IG9mPGJyPg0KJmd0OyAm Z3Q7IHRoaXMgb3B0aW9uIGlzIDIgYnl0ZXMgb3ZlciBvcHRpb24gb25lLiZuYnNwOyAoT25lIGJ5 dGUgZm9yIHRoZSByZWNpcGllbnRzPGJyPg0KJmd0OyAmZ3Q7IGtleSwgb25lIGJ5dGUgZm9yIHRo ZSBtYXAgbWFya2VyLik8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQ0RETCBncmFtbWFy IHdvdWxkIGJlOiZuYnNwOyByZWNpcGllbnRzOiBbJiM0MztbcmVjaXBpZW50X2RhdGFdXSAvPGJy Pg0KJmd0OyAmZ3Q7IHtyZWNpcGllbnRfZGF0YX08YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgMykmbmJzcDsgV2UgZG8gbm90IHN1cHBvcnQgYW55IHNwZWNpYWwgZm9ybSBvZiBkZWFsaW5n IHdpdGggYSBzaW5nbGUgcmVjaXBpZW50Ljxicj4NCiZndDsgJmd0OyBUaGUgY29zdCBvZiB0aGlz IG9wdGlvbiBpcyAzIGJ5dGVzIG92ZXIgb3B0aW9uIG9uZS4mbmJzcDsgKE9uZSBieXRlIGZvciB0 aGU8YnI+DQomZ3Q7ICZndDsgcmVjaXBpZW50cyBrZXksIG9uZSBieXRlIGZvciB0aGUgYXJyYXkg bWFya2VyLCBvbmUgYnl0ZSBmb3IgdGhlIG1hcDxicj4NCiZndDsgbWFya2VyLik8YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsgQ0RETCBncmFtbWFyIHdvdWxkIGJlOiZuYnNwOyByZWNpcGll bnRzOiBbJiM0MztbcmVjcGllbnRfZGF0YV1dPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0 OyAmZ3Q7IENvc2UgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpD b3NlQGlldGYub3JnIj5Db3NlQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2UiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nvc2U8L2E+PGJyPg0KPGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpD b3NlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpDb3NlQGlldGYub3JnIj5Db3Nl QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY29zZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vY29zZTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BL2PR03MB433110A60A3FE944DDB0865F5A80BL2PR03MB433namprd_-- From nobody Tue Jun 30 18:17:18 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3F01A0193 for ; Tue, 30 Jun 2015 18:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 EGkNeHpRafJN for ; Tue, 30 Jun 2015 18:17:13 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5619A1A0173 for ; Tue, 30 Jun 2015 18:17:13 -0700 (PDT) Received: by oift81 with SMTP id t81so21097955oif.3 for ; Tue, 30 Jun 2015 18:17:13 -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-type; bh=AVSEub5UZK0BWt9uNsdRTaNyQ4y+tO+CNCMb6o80M+4=; b=l6JCrfHzcZjjGnfGEp0eZ1LRUrIv8z9MnxJXaUx1yrTMq6cdzs1cyLRfXxB0+4ex1d YDZdkbaOhOCraAoePfPJeV1aXEfoKdgeGq79gSvlJYT9cC9oXp31iV1dj19WnY/xnUos kCXWtWx2/0ZAXlO+SZK9ngP/BRGxEPwiueiIWelLCfRRi+RgiLhCmERlBkmO8cGdv1Mr +/ynH/NrO8a3yWK7nCimGKyO8q57xp0XUGWjF8rvaGsZyFv/gb12tjgmaKIhFfN2IpJB Ypkjt8w94eYNOfVA+x0wxUwpd9/J/cf+sDPIhlAh5L46gq8WiZLVgkjFs5AlGOcUpUSV IK/Q== X-Received: by 10.60.60.70 with SMTP id f6mr21920902oer.8.1435713433135; Tue, 30 Jun 2015 18:17:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.116.99 with HTTP; Tue, 30 Jun 2015 18:16:53 -0700 (PDT) In-Reply-To: References: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> <009501d0b392$fb7cc680$f2765380$@augustcellars.com> From: Dick Hardt Date: Tue, 30 Jun 2015 18:16:53 -0700 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=089e015374ac2e796b0519c615f8 Archived-At: Cc: Jim Schaad , "cose@ietf.org" Subject: Re: [Cose] Issue: Encoding for a single recipient or structure X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 01:17:17 -0000 --089e015374ac2e796b0519c615f8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the refresher MIke. I expect that if I want to deploy COSE, I would be adding support to the JOSE libraries I already have that I would deploy on the server, so a consistent data model would be very beneficial and increase the odds that it is correct and hence secure. If there is agreement that multiple recipients is optional, then I would strongly prefer option (a). I'm sure this was covered in JOSE, but I don't know of any scenarios where I would need multiple recipients -- particularly in a constrained environment. Is there a multiple recipient use case documented somewhere? On Tue, Jun 30, 2015 at 6:11 PM, Mike Jones wrote: > My underlying assumption is that just like we did in JOSE, you **don=E2= =80=99t** > have to support multiple recipients to be compliant. > http://tools.ietf.org/html/rfc7515#section-7 says: > > > > JWSs use one of two serializations: the JWS Compact Serialization or > > the JWS JSON Serialization. Applications using this specification > > need to specify what serialization and serialization features are > > used for that application. For instance, applications might specify > > that only the JWS JSON Serialization is used, that only JWS JSON > > Serialization support for a single signature or MAC value is used, or > > that support for multiple signatures and/or MAC values is used. JWS > > implementations only need to implement the features needed for the > > applications they are designed to support. > > > > Indeed, I believe that we should add equivalent text to COSE, because it= =E2=80=99s > even more likely in constrained environments than Web environments that > applications will specify that they are only using subsets of the > COSE-defined features and that general-purpose libraries will be compiled > for specific applications with #ifdef settings to remove unused code > paths. I plan to propose exact text along these lines for inclusion. > > > > -- Mike > > > > > > *From:* Dick Hardt [mailto:dick.hardt@gmail.com] > *Sent:* Tuesday, June 30, 2015 6:01 PM > *To:* Mike Jones > *Cc:* Jim Schaad; cose@ietf.org > *Subject:* Re: [Cose] Issue: Encoding for a single recipient or structure > > > > If I'm writing a library and I have to support multiple recipients to be > compliant, then given a choice between dealing with both a singleton and = an > array(a) vs just an array (c), then I'll pick just an array (c). ... or a= m > I missing some aspect of how this is simpler Mike? > > > > On Tue, Jun 30, 2015 at 5:45 PM, Mike Jones > wrote: > > Reply inline below... > > > > -----Original Message----- > > From: Jim Schaad [mailto:ietf@augustcellars.com] > > Sent: Tuesday, June 30, 2015 5:15 PM > > To: Mike Jones; cose@ietf.org > > Subject: RE: [Cose] Issue: Encoding for a single recipient or structure > > > > > > > > > -----Original Message----- > > > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > > > Sent: Tuesday, June 30, 2015 3:45 PM > > > To: Jim Schaad; cose@ietf.org > > > Subject: RE: [Cose] Issue: Encoding for a single recipient or > > > structure > > > > > > Hi Jim, > > > > > > Per your suggestion in response to my issue 1, I'm reviewing this > thread. > > > (I'm also including the original message below so WG members who > > > joined the list when the WG was formed will see it.) > > > > > > First, let me ask a question to see if I correctly understand the > > > problem > > with > > > your option (1) below. JWE used "alg" for the key management > > > algorithm and "enc" for the content encryption algorithm. Likewise, > > > JWE used "encrypted_key" for the encrypted key value and "ciphertext" > > > for the encrypted plaintext. Since there were no name collisions, al= l > > > could live > > in > > > the top-level JSON object. Whereas, your current COSE draft uses the > > > equivalent of "alg" for both algorithms and the equivalent of > "ciphertext" > > > for both encrypted values, hence the label collisions you are citing > > below, > > > correct? > > > > > > If my understanding is right, then unless a JWE-like approach were > > > adopted in which different labels are used for the different purposes= , > > > then yes, I agree that (1) wouldn't work. Was this change to a singl= e > > > set of labels > > the > > > intended topic of the thread "[Cose] Issue: Reuse the Enrypt > > > structure > > for > > > recipients"? I'm asking because a lot of the thread ended up being > > > about > > a > > > different topic - whether the encrypted_key value would contain just > > > an encrypted bare key or the equivalent of an encrypted JWK structure= . > > > > > > You asked if I had anything new to add to the discussion. I'll add > > this... > > > > > > Just like for JOSE, I expect that many applications will implement > > > only > > the > > > COSE features that they need. For instance, JWT [RFC 7519] > > > implementations only need to implement the JOSE Compact Serialization= s > > > - not the JSON Serializations. I expect there to be many COSE > > > applications that will similarly only implement support for a single > > > recipient. This > > would > > > save on code size and be simpler. > > > > > > I believe that applications that only use a single recipient will be > > > the > > most > > > common, hence the goal stated in my review to optimize for this case. > > > Assuming we take your option (1) off the table and limit discussion t= o > > only > > > your options (2) and (3) below, then the choice seems to be between > > > these effective grammars for the single recipient case: > > > (2) recipients: {recipient_data} > > > (3) recipients: [{recpient_data}] > > > > > > If you're only ever building code for the single recipient case, then > > > (2) > > is > > > simpler. But I agree that if you're using code that supports multipl= e > > > recipients, then (3) is simpler, if somewhat less elegant. > > > > I am going to make the same challenge to you that I made to Derik at on= e > > point. > > > > Can you provide code to show that option 2 is significantly larger than > option > > 3? > > I'm not saying that there's a significant code size difference. Maybe yo= u > can tell us how much code would be removed from your implementation if yo= u > #ifdef'ed out the loops associated with producing and consuming the > recipients arrays and just replaced it with code using a singleton array > value (option 3) or simply a recipient_data map value (option 2). I admi= t > up front that there will be almost no code size difference between 2 or 3 > if the implementation has been compiled to only support a single recipien= t. > > My main point in raising this issue now is we're likely to hear the same > thing about COSE that Richard Barnes heard from developers who were reall= y > using the JSON Serializations before we added the flattened data > representation - that having to emit and parse a singleton array is ugly, > awkward, etc. > > This isn't a show-stopper to me, but now that there's a working group, I > wanted to raise the issue for the working group to explicitly consider up > front, rather than wait until people are using early implementations and = we > hear back from developers "why couldn't this have been simpler in the > simple case"? > > Cheers, > -- Mike > > > > Jim > > > > > > > > What do others think about this tradeoff? > > > > > > -- Mike > > > > > > -----Original Message----- > > > From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad > > > Sent: Thursday, April 30, 2015 3:59 PM > > > To: cose@ietf.org > > > Subject: [Cose] Issue: Encoding for a single recipient or structure > > > > > > Question: Flattened encoding - > > > a) Roll into parent map > > > b) Just be a map > > > c) Single element in array > > > > > > Discussion: > > > > > > A late addition to the JOSE specification was the ability to fold a > > > single recipient map into the base encryption or signature map. This > > > is doable because the keys for all of the maps in question are unique= . > > > This would > > not > > > be true if the issue on reusing the encryption body for the recipient > > > structure is accepted. This issue is being discussed in a separate > > > mail > > thread > > > (but is current). If arrays were to be used at the top level, one > > > just > > appends > > > the elements to the end of the base structure (see examples in the > > current > > > document). > > > > > > There are three different options that can be selected at this point: > > > > > > 1) The recipient/signature map is folded into the encryption/signing > > > message top level. If we accept the change for using the same > > > structure > > for > > > both the encryption body and the recipients, this is not a viable > > > option > > due > > > to collisions of keys in the map. > > > > > > 2) The recipient/signature element in the base map is permitted to b= e > > > either an array of recipient/signature elements or a single > > > recipient/signature map. This option was rejected by the JOSE group > > > as being too complicated for programmers to deal with. The cost of > > > this option is 2 bytes over option one. (One byte for the recipients > > > key, one byte for the map marker.) > > > > > > CDDL grammar would be: recipients: [+[recipient_data]] / > > > {recipient_data} > > > > > > 3) We do not support any special form of dealing with a single > recipient. > > > The cost of this option is 3 bytes over option one. (One byte for th= e > > > recipients key, one byte for the array marker, one byte for the map > > marker.) > > > > > > CDDL grammar would be: recipients: [+[recpient_data]] > > > > > > _______________________________________________ > > > 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 > > > --089e015374ac2e796b0519c615f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the refresher MIke.=C2=A0

I = expect that if I want to deploy COSE, I would be adding support to the JOSE= libraries I already have that I would deploy on the server, so a consisten= t data model would be very beneficial and increase the odds that it is corr= ect and hence secure.

If there is agreement that m= ultiple recipients is optional, then I would strongly prefer option (a).

I'm sure this was covered in JOSE, but I don'= ;t know of any scenarios where I would need multiple recipients -- particul= arly in a constrained environment. Is there a multiple recipient use case d= ocumented somewhere?
=C2=A0


On Tue, Jun 30, 2015 at 6:1= 1 PM, Mike Jones <Michael.Jones@microsoft.com> wro= te:

My underlying assumption = is that just like we did in JOSE, you *don=E2=80=99t* have to suppor= t multiple recipients to be compliant.=C2=A0 = http://tools.ietf.org/html/rfc7515#section-7 says:=

=C2=A0

=C2=A0=C2=A0 JWSs use one of two serializations: the JWS Compac= t Serialization or

=C2=A0=C2=A0 the JWS JSON Serialization.=C2=A0 Applications usi= ng this specification

=C2=A0=C2=A0 need to specify what serialization and serializati= on features are

=C2=A0=C2=A0 used for that application.=C2=A0 For instance, app= lications might specify

=C2=A0=C2=A0 that only the JWS JSON Serialization is used, that only JWS JSON=

=C2=A0=C2=A0 Serialization support for a sing= le signature or MAC value is used, or

=C2=A0=C2=A0 that support for multiple signatures and/or MAC va= lues is used.=C2=A0 JWS

=C2=A0=C2=A0 implementations only need to imp= lement the features needed for the

=C2=A0=C2=A0 applications they are designed t= o support.

=C2=A0

Indeed, I believe that we= should add equivalent text to COSE, because it=E2=80=99s even more likely = in constrained environments than Web environments that applications will specify that they are only using subsets of the COSE-defined features= and that general-purpose libraries will be compiled for specific applicati= ons with #ifdef settings to remove unused code paths.=C2=A0 I plan to propo= se exact text along these lines for inclusion.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

=C2=A0

From: Dick Har= dt [mailto:dick.h= ardt@gmail.com]
Sent: Tuesday, June 30, 2015 6:01 PM
To: Mike Jones
Cc: Jim Schaad; c= ose@ietf.org
Subject: Re: [Cose] Issue: Encoding for a single recipient or struct= ure

=C2=A0

If I'm writing a library and I have to support m= ultiple recipients to be compliant, then given a choice between dealing wit= h both a singleton and an array(a) vs just an array (c), then I'll pick= just an array (c). ... or am I missing some aspect of how this is simpler Mike?=C2=A0

=C2=A0

On Tue, Jun 30, 2015 at 5:45 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

Reply inline below...


> -----Original Message-----
> From: Jim Schaad [mailto:ietf@augustcellars.com]
> Sent: Tuesday, June 30, 2015 5:15 PM
> To: Mike Jones; cos= e@ietf.org
> Subject: RE: [Cose] Issue: Encoding for a single recipient or structur= e
>
>
>
> > -----Original Message-----
> > From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> > Sent: Tuesday, June 30, 2015 3:45 PM
> > To: Jim Schaad; cose@ietf.org
> > Subject: RE: [Cose] Issue: Encoding for a single recipient or
> > structure
> >
> > Hi Jim,
> >
> > Per your suggestion in response to my issue 1, I'm reviewing = this thread.
> > (I'm also including the original message below so WG members = who
> > joined the list when the WG was formed will see it.)
> >
> > First, let me ask a question to see if I correctly understand the=
> > problem
> with
> > your option (1) below.=C2=A0 JWE used "alg" for the key= management
> > algorithm and "enc" for the content encryption algorith= m.=C2=A0 Likewise,
> > JWE used "encrypted_key" for the encrypted key value an= d "ciphertext"
> > for the encrypted plaintext.=C2=A0 Since there were no name colli= sions, all
> > could live
> in
> > the top-level JSON object.=C2=A0 Whereas, your current COSE draft= uses the
> > equivalent of "alg" for both algorithms and the equival= ent of "ciphertext"
> > for both encrypted values, hence the label collisions you are cit= ing
> below,
> > correct?
> >
> > If my understanding is right, then unless a JWE-like approach wer= e
> > adopted in which different labels are used for the different purp= oses,
> > then yes, I agree that (1) wouldn't work.=C2=A0 Was this chan= ge to a single
> > set of labels
> the
> > intended topic of the thread "[Cose] Issue:=C2=A0 Reuse the = Enrypt
> > structure
> for
> > recipients"?=C2=A0 I'm asking because a lot of the threa= d ended up being
> > about
> a
> > different topic - whether the encrypted_key value would contain j= ust
> > an encrypted bare key or the equivalent of an encrypted JWK struc= ture.
> >
> > You asked if I had anything new to add to the discussion.=C2=A0 I= 'll add
> this...
> >
> > Just like for JOSE, I expect that many applications will implemen= t
> > only
> the
> > COSE features that they need.=C2=A0 For instance, JWT [RFC 7519]<= br> > > implementations only need to implement the JOSE Compact Serializa= tions
> > - not the JSON Serializations.=C2=A0 I expect there to be many CO= SE
> > applications that will similarly only implement support for a sin= gle
> > recipient.=C2=A0 This
> would
> > save on code size and be simpler.
> >
> > I believe that applications that only use a single recipient will= be
> > the
> most
> > common, hence the goal stated in my review to optimize for this c= ase.
> > Assuming we take your option (1) off the table and limit discussi= on to
> only
> > your options (2) and (3) below, then the choice seems to be betwe= en
> > these effective grammars for the single recipient case:
> >=C2=A0 =C2=A0 =C2=A0(2) recipients: {recipient_data}
> >=C2=A0 =C2=A0 =C2=A0(3) recipients: [{recpient_data}]
> >
> > If you're only ever building code for the single recipient ca= se, then
> > (2)
> is
> > simpler.=C2=A0 But I agree that if you're using code that sup= ports multiple
> > recipients, then (3) is simpler, if somewhat less elegant.
>
> I am going to make the same challenge to you that I made to Derik at o= ne
> point.
>
> Can you provide code to show that option 2 is significantly larger tha= n option
> 3?

I'm not saying that there's a significant co= de size difference.=C2=A0 Maybe you can tell us how much code would be remo= ved from your implementation if you #ifdef'ed out the loops associated = with producing and consuming the recipients arrays and just replaced it with code using a singleton array value (option 3) or= simply a recipient_data map value (option 2).=C2=A0 I admit up front that = there will be almost no code size difference between 2 or 3 if the implemen= tation has been compiled to only support a single recipient.

My main point in raising this issue now is we're likely to hear the sam= e thing about COSE that Richard Barnes heard from developers who were reall= y using the JSON Serializations before we added the flattened data represen= tation - that having to emit and parse a singleton array is ugly, awkward, etc.

This isn't a show-stopper to me, but now that there's a working gro= up, I wanted to raise the issue for the working group to explicitly conside= r up front, rather than wait until people are using early implementations a= nd we hear back from developers "why couldn't this have been simpler in the simple case"?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike


> Jim
>
> >
> > What do others think about this tradeoff?
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
> >
> > -----Original Message-----
> > From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad
> > Sent: Thursday, April 30, 2015 3:59 PM
> > To: cose@ietf.= org
> > Subject: [Cose] Issue: Encoding for a single recipient or structu= re
> >
> > Question: Flattened encoding -
> > a)=C2=A0 Roll into parent map
> > b)=C2=A0 Just be a map
> > c)=C2=A0 Single element in array
> >
> > Discussion:
> >
> > A late addition to the JOSE specification was the ability to fold= a
> > single recipient map into the base encryption or signature map.= =C2=A0 This
> > is doable because the keys for all of the maps in question are un= ique.
> > This would
> not
> > be true if the issue on reusing the encryption body for the recip= ient
> > structure is accepted.=C2=A0 This issue is being discussed in a s= eparate
> > mail
> thread
> > (but is current).=C2=A0 If arrays were to be used at the top leve= l, one
> > just
> appends
> > the elements to the end of the base structure=C2=A0 (see examples= in the
> current
> > document).
> >
> > There are three different options that can be selected at this po= int:
> >
> > 1)=C2=A0 The recipient/signature map is folded into the encryptio= n/signing
> > message top level.=C2=A0 If we accept the change for using the sa= me
> > structure
> for
> > both the encryption body and the recipients, this is not a viable=
> > option
> due
> > to collisions of keys in the map.
> >
> > 2)=C2=A0 The recipient/signature element in the base map is permi= tted to be
> > either an array of recipient/signature elements or a single
> > recipient/signature map.=C2=A0 This option was rejected by the JO= SE group
> > as being too complicated for programmers to deal with.=C2=A0 The = cost of
> > this option is 2 bytes over option one.=C2=A0 (One byte for the r= ecipients
> > key, one byte for the map marker.)
> >
> > CDDL grammar would be:=C2=A0 recipients: [+[recipient_data]] / > > {recipient_data}
> >
> > 3)=C2=A0 We do not support any special form of dealing with a sin= gle recipient.
> > The cost of this option is 3 bytes over option one.=C2=A0 (One by= te for the
> > recipients key, one byte for the array marker, one byte for the m= ap
> marker.)
> >
> > CDDL grammar would be:=C2=A0 recipients: [+[recpient_data]]
> >
> > _______________________________________________
> > Cose mailing list
> > Cose@ietf.org<= /a>
> > https://www.ietf.org/mailman/listinfo/cose

_______________________________________________
Cose mailing list
Cose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cose

=C2=A0


--089e015374ac2e796b0519c615f8-- From nobody Tue Jun 30 21:31:24 2015 Return-Path: X-Original-To: cose@ietfa.amsl.com Delivered-To: cose@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D18B1A8788 for ; Tue, 30 Jun 2015 21:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 j9D-b70bWIfO for ; Tue, 30 Jun 2015 21:31:18 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1E8A1A700E for ; Tue, 30 Jun 2015 21:31:17 -0700 (PDT) Received: from hebrews (unknown [50.109.240.20]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id E977638EF2; Tue, 30 Jun 2015 21:31:15 -0700 (PDT) From: "Jim Schaad" To: "'Dick Hardt'" References: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> <009501d0b392$fb7cc680$f2765380$@augustcellars.com> In-Reply-To: Date: Tue, 30 Jun 2015 21:31:30 -0700 Message-ID: <00d001d0b3b6$ce20f2f0$6a62d8d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D1_01D0B37C.21C96DF0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJBW2regVOc1KgJrCGEY9SFfcIRjgIjyzTpArNKyUYA0EcPdQJL5N93AtWHUysCrbMn05x5AFXA Content-Language: en-us Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] Issue: Encoding for a single recipient or structure X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 04:31:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D1_01D0B37C.21C96DF0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Part of the question is going to be where do you expect COSE to be used = in the future. =20 If one believes that it is only for use in constrained environments, = then it is unlikely that there is a need for multiple recipients. Based = on the use cases that have been provided at the current time, it is also = likely that there is no need to have anything more than a shared secret = method of key management.=20 =20 If one believes that it will be used in environments other than just = constrained environments =E2=80=93 say in SACM or MILE then there are = probably several use cases for multiple recipients and multiple key = management methods. An example would be a central authority providing = an encrypted token to a client that is good for multiple servers, each = server having its own private key for decryption.=20 =20 Another thing might be a version of multi-cast of messages. Currently = this is designed to use a previously sent pre-shared secret. But it is = possible that this might become a multiple recipient type system = instead. =20 One also always has the case of an entity wanting to archive the = messages it is sending =E2=80=93 and adding itself as a recipient. =20 I think it is quite likely that there will be application profiles of = COSE, just as there are application protocols of CMS. This is where one = can say that a feature does not need to be implemented. But it still = makes the code much simpler for all involved if there is only one way = that is used to do something. This was not the approach used for = portions of JOSE such as encoding a single recipient message. I can = think of at least three different ways to encode this type of message. =20 =20 =20 From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 Sent: Tuesday, June 30, 2015 6:17 PM To: Mike Jones Cc: Jim Schaad; cose@ietf.org Subject: Re: [Cose] Issue: Encoding for a single recipient or structure =20 Thanks for the refresher MIke.=20 =20 I expect that if I want to deploy COSE, I would be adding support to the = JOSE libraries I already have that I would deploy on the server, so a = consistent data model would be very beneficial and increase the odds = that it is correct and hence secure. =20 If there is agreement that multiple recipients is optional, then I would = strongly prefer option (a). =20 I'm sure this was covered in JOSE, but I don't know of any scenarios = where I would need multiple recipients -- particularly in a constrained = environment. Is there a multiple recipient use case documented = somewhere? =20 =20 =20 On Tue, Jun 30, 2015 at 6:11 PM, Mike Jones > wrote: My underlying assumption is that just like we did in JOSE, you = *don=E2=80=99t* have to support multiple recipients to be compliant. = http://tools.ietf.org/html/rfc7515#section-7 says: =20 JWSs use one of two serializations: the JWS Compact Serialization or the JWS JSON Serialization. Applications using this specification need to specify what serialization and serialization features are used for that application. For instance, applications might specify that only the JWS JSON Serialization is used, that only JWS JSON Serialization support for a single signature or MAC value is used, or that support for multiple signatures and/or MAC values is used. JWS implementations only need to implement the features needed for the applications they are designed to support. =20 Indeed, I believe that we should add equivalent text to COSE, because = it=E2=80=99s even more likely in constrained environments than Web = environments that applications will specify that they are only using = subsets of the COSE-defined features and that general-purpose libraries = will be compiled for specific applications with #ifdef settings to = remove unused code paths. I plan to propose exact text along these = lines for inclusion. =20 -- Mike =20 =20 From: Dick Hardt [mailto:dick.hardt@gmail.com = ]=20 Sent: Tuesday, June 30, 2015 6:01 PM To: Mike Jones Cc: Jim Schaad; cose@ietf.org =20 Subject: Re: [Cose] Issue: Encoding for a single recipient or structure =20 If I'm writing a library and I have to support multiple recipients to be = compliant, then given a choice between dealing with both a singleton and = an array(a) vs just an array (c), then I'll pick just an array (c). ... = or am I missing some aspect of how this is simpler Mike?=20 =20 On Tue, Jun 30, 2015 at 5:45 PM, Mike Jones > wrote: Reply inline below... > -----Original Message----- > From: Jim Schaad [mailto:ietf@augustcellars.com = ] > Sent: Tuesday, June 30, 2015 5:15 PM > To: Mike Jones; cose@ietf.org =20 > Subject: RE: [Cose] Issue: Encoding for a single recipient or = structure > > > > > -----Original Message----- > > From: Mike Jones [mailto:Michael.Jones@microsoft.com = ] > > Sent: Tuesday, June 30, 2015 3:45 PM > > To: Jim Schaad; cose@ietf.org =20 > > Subject: RE: [Cose] Issue: Encoding for a single recipient or > > structure > > > > Hi Jim, > > > > Per your suggestion in response to my issue 1, I'm reviewing this = thread. > > (I'm also including the original message below so WG members who > > joined the list when the WG was formed will see it.) > > > > First, let me ask a question to see if I correctly understand the > > problem > with > > your option (1) below. JWE used "alg" for the key management > > algorithm and "enc" for the content encryption algorithm. Likewise, > > JWE used "encrypted_key" for the encrypted key value and = "ciphertext" > > for the encrypted plaintext. Since there were no name collisions, = all > > could live > in > > the top-level JSON object. Whereas, your current COSE draft uses = the > > equivalent of "alg" for both algorithms and the equivalent of = "ciphertext" > > for both encrypted values, hence the label collisions you are citing > below, > > correct? > > > > If my understanding is right, then unless a JWE-like approach were > > adopted in which different labels are used for the different = purposes, > > then yes, I agree that (1) wouldn't work. Was this change to a = single > > set of labels > the > > intended topic of the thread "[Cose] Issue: Reuse the Enrypt > > structure > for > > recipients"? I'm asking because a lot of the thread ended up being > > about > a > > different topic - whether the encrypted_key value would contain just > > an encrypted bare key or the equivalent of an encrypted JWK = structure. > > > > You asked if I had anything new to add to the discussion. I'll add > this... > > > > Just like for JOSE, I expect that many applications will implement > > only > the > > COSE features that they need. For instance, JWT [RFC 7519] > > implementations only need to implement the JOSE Compact = Serializations > > - not the JSON Serializations. I expect there to be many COSE > > applications that will similarly only implement support for a single > > recipient. This > would > > save on code size and be simpler. > > > > I believe that applications that only use a single recipient will be > > the > most > > common, hence the goal stated in my review to optimize for this = case. > > Assuming we take your option (1) off the table and limit discussion = to > only > > your options (2) and (3) below, then the choice seems to be between > > these effective grammars for the single recipient case: > > (2) recipients: {recipient_data} > > (3) recipients: [{recpient_data}] > > > > If you're only ever building code for the single recipient case, = then > > (2) > is > > simpler. But I agree that if you're using code that supports = multiple > > recipients, then (3) is simpler, if somewhat less elegant. > > I am going to make the same challenge to you that I made to Derik at = one > point. > > Can you provide code to show that option 2 is significantly larger = than option > 3? I'm not saying that there's a significant code size difference. Maybe = you can tell us how much code would be removed from your implementation = if you #ifdef'ed out the loops associated with producing and consuming = the recipients arrays and just replaced it with code using a singleton = array value (option 3) or simply a recipient_data map value (option 2). = I admit up front that there will be almost no code size difference = between 2 or 3 if the implementation has been compiled to only support a = single recipient. My main point in raising this issue now is we're likely to hear the same = thing about COSE that Richard Barnes heard from developers who were = really using the JSON Serializations before we added the flattened data = representation - that having to emit and parse a singleton array is = ugly, awkward, etc. This isn't a show-stopper to me, but now that there's a working group, I = wanted to raise the issue for the working group to explicitly consider = up front, rather than wait until people are using early implementations = and we hear back from developers "why couldn't this have been simpler in = the simple case"? Cheers, -- Mike > Jim > > > > > What do others think about this tradeoff? > > > > -- Mike > > > > -----Original Message----- > > From: Cose [mailto:cose-bounces@ietf.org = ] On Behalf Of Jim Schaad > > Sent: Thursday, April 30, 2015 3:59 PM > > To: cose@ietf.org =20 > > Subject: [Cose] Issue: Encoding for a single recipient or structure > > > > Question: Flattened encoding - > > a) Roll into parent map > > b) Just be a map > > c) Single element in array > > > > Discussion: > > > > A late addition to the JOSE specification was the ability to fold a > > single recipient map into the base encryption or signature map. = This > > is doable because the keys for all of the maps in question are = unique. > > This would > not > > be true if the issue on reusing the encryption body for the = recipient > > structure is accepted. This issue is being discussed in a separate > > mail > thread > > (but is current). If arrays were to be used at the top level, one > > just > appends > > the elements to the end of the base structure (see examples in the > current > > document). > > > > There are three different options that can be selected at this = point: > > > > 1) The recipient/signature map is folded into the = encryption/signing > > message top level. If we accept the change for using the same > > structure > for > > both the encryption body and the recipients, this is not a viable > > option > due > > to collisions of keys in the map. > > > > 2) The recipient/signature element in the base map is permitted to = be > > either an array of recipient/signature elements or a single > > recipient/signature map. This option was rejected by the JOSE group > > as being too complicated for programmers to deal with. The cost of > > this option is 2 bytes over option one. (One byte for the = recipients > > key, one byte for the map marker.) > > > > CDDL grammar would be: recipients: [+[recipient_data]] / > > {recipient_data} > > > > 3) We do not support any special form of dealing with a single = recipient. > > The cost of this option is 3 bytes over option one. (One byte for = the > > recipients key, one byte for the array marker, one byte for the map > marker.) > > > > CDDL grammar would be: recipients: [+[recpient_data]] > > > > _______________________________________________ > > Cose mailing list > > Cose@ietf.org =20 > > https://www.ietf.org/mailman/listinfo/cose _______________________________________________ Cose mailing list Cose@ietf.org =20 https://www.ietf.org/mailman/listinfo/cose =20 =20 ------=_NextPart_000_00D1_01D0B37C.21C96DF0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Part of the question is going to be where do you expect COSE to be used = in the future.

 

If one believes that it is only for use in constrained environments, = then it is unlikely that there is a need for multiple recipients.=C2=A0 = Based on the use cases that have been provided at the current time, it = is also likely that there is no need to have anything more than a shared = secret method of key management.

 

If one believes that it will be used in environments other than just = constrained environments =E2=80=93 say in SACM or MILE then there are = probably several use cases for multiple recipients and multiple key = management methods.=C2=A0 An example would be a central authority = providing an encrypted token to a client that is good for multiple = servers, each server having its own private key for decryption. =

 

Another thing might be a version of multi-cast of messages.=C2=A0 = Currently this is designed to use a previously sent pre-shared = secret.=C2=A0 But it is possible that this might become a multiple = recipient type system instead.

 

One also always has the case of an entity wanting to archive the = messages it is sending =E2=80=93 and adding itself as a = recipient.

 

I think it is quite likely that there will be application profiles of = COSE, just as there are application protocols of CMS.=C2=A0 This is = where one can say that a feature does not need to be implemented.=C2=A0 = But it still makes the code much simpler for all involved if there is = only one way that is used to do something.=C2=A0 This was not the = approach used for portions of JOSE such as encoding a single recipient = message.=C2=A0 I can think of at least three different ways to encode = this type of message.

 

 

 

From:<= /b> = Dick Hardt [mailto:dick.hardt@gmail.com]
Sent: Tuesday, June = 30, 2015 6:17 PM
To: Mike Jones
Cc: Jim Schaad; = cose@ietf.org
Subject: Re: [Cose] Issue: Encoding for a single = recipient or structure

 

Thanks = for the refresher MIke. 

 

I = expect that if I want to deploy COSE, I would be adding support to the = JOSE libraries I already have that I would deploy on the server, so a = consistent data model would be very beneficial and increase the odds = that it is correct and hence secure.

 

If there is agreement that multiple recipients is = optional, then I would strongly prefer option = (a).

 

I'm sure this was covered in JOSE, but I don't know of = any scenarios where I would need multiple recipients -- particularly in = a constrained environment. Is there a multiple recipient use case = documented somewhere?

 

 

 

On Tue, = Jun 30, 2015 at 6:11 PM, Mike Jones <Michael.Jones@microsoft.com> = wrote:

My underlying assumption is that just like we did in JOSE, you = *don=E2=80=99t* have to support multiple recipients to be = compliant.  http://tools.ietf.org/html/rfc7515#section-7 = says:

 

   JWSs use one = of two serializations: the JWS Compact Serialization = or

   the JWS JSON = Serialization.  Applications using this = specification

   need to = specify what serialization and serialization features = are

   used for that = application.  For instance, applications might = specify

   that only the = JWS JSON Serialization is used, that only JWS JSON

   Serialization support for a single = signature or MAC value is used, or

   that support = for multiple signatures and/or MAC values is used.  JWS

   implementations only need to = implement the features needed for the

   applications they are designed to = support.

 

Indeed, I believe that we should add equivalent text to COSE, because = it=E2=80=99s even more likely in constrained environments than Web = environments that applications will specify that they are only using = subsets of the COSE-defined features and that general-purpose libraries = will be compiled for specific applications with #ifdef settings to = remove unused code paths.  I plan to propose exact text along these = lines for inclusion.

 

            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   -- Mike

 

 

From: Dick = Hardt [mailto:dick.hardt@gmail.com]
Sent: Tuesday, = June 30, 2015 6:01 PM
To: Mike Jones
Cc: Jim Schaad; = cose@ietf.org
Subject: Re: [Cose] Issue: = Encoding for a single recipient or = structure

 <= /o:p>

If I'm = writing a library and I have to support multiple recipients to be = compliant, then given a choice between dealing with both a singleton and = an array(a) vs just an array (c), then I'll pick just an array (c). ... = or am I missing some aspect of how this is simpler = Mike? 

 <= /o:p>

On Tue, Jun = 30, 2015 at 5:45 PM, Mike Jones <Michael.Jones@microsoft.com> = wrote:

Reply = inline below...


> = -----Original Message-----
> From: Jim Schaad [mailto:ietf@augustcellars.com]
> Sent: Tuesday, = June 30, 2015 5:15 PM
> To: Mike Jones; cose@ietf.org
> Subject: RE: [Cose] Issue: = Encoding for a single recipient or = structure
>
>
>
> > -----Original = Message-----
> > From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> > Sent: = Tuesday, June 30, 2015 3:45 PM
> > To: Jim Schaad; cose@ietf.org
> > Subject: RE: [Cose] = Issue: Encoding for a single recipient or
> > structure
> = >
> > Hi Jim,
> >
> > Per your suggestion = in response to my issue 1, I'm reviewing this thread.
> > (I'm = also including the original message below so WG members who
> > = joined the list when the WG was formed will see it.)
> = >
> > First, let me ask a question to see if I correctly = understand the
> > problem
> with
> > your = option (1) below.  JWE used "alg" for the key = management
> > algorithm and "enc" for the content = encryption algorithm.  Likewise,
> > JWE used = "encrypted_key" for the encrypted key value and = "ciphertext"
> > for the encrypted plaintext.  = Since there were no name collisions, all
> > could live
> = in
> > the top-level JSON object.  Whereas, your current = COSE draft uses the
> > equivalent of "alg" for both = algorithms and the equivalent of "ciphertext"
> > for = both encrypted values, hence the label collisions you are citing
> = below,
> > correct?
> >
> > If my = understanding is right, then unless a JWE-like approach were
> = > adopted in which different labels are used for the different = purposes,
> > then yes, I agree that (1) wouldn't work.  = Was this change to a single
> > set of labels
> = the
> > intended topic of the thread "[Cose] Issue:  = Reuse the Enrypt
> > structure
> for
> > = recipients"?  I'm asking because a lot of the thread ended up = being
> > about
> a
> > different topic - = whether the encrypted_key value would contain just
> > an = encrypted bare key or the equivalent of an encrypted JWK = structure.
> >
> > You asked if I had anything new to = add to the discussion.  I'll add
> this...
> = >
> > Just like for JOSE, I expect that many applications = will implement
> > only
> the
> > COSE features = that they need.  For instance, JWT [RFC 7519]
> > = implementations only need to implement the JOSE Compact = Serializations
> > - not the JSON Serializations.  I = expect there to be many COSE
> > applications that will = similarly only implement support for a single
> > = recipient.  This
> would
> > save on code size and = be simpler.
> >
> > I believe that applications that = only use a single recipient will be
> > the
> = most
> > common, hence the goal stated in my review to optimize = for this case.
> > Assuming we take your option (1) off the = table and limit discussion to
> only
> > your options (2) = and (3) below, then the choice seems to be between
> > these = effective grammars for the single recipient case:
> >  =    (2) recipients: {recipient_data}
> >    =  (3) recipients: [{recpient_data}]
> >
> > If = you're only ever building code for the single recipient case, = then
> > (2)
> is
> > simpler.  But I agree = that if you're using code that supports multiple
> > = recipients, then (3) is simpler, if somewhat less = elegant.
>
> I am going to make the same challenge to you = that I made to Derik at one
> point.
>
> Can you = provide code to show that option 2 is significantly larger than = option
> 3?

I'm not = saying that there's a significant code size difference.  Maybe you = can tell us how much code would be removed from your implementation if = you #ifdef'ed out the loops associated with producing and consuming the = recipients arrays and just replaced it with code using a singleton array = value (option 3) or simply a recipient_data map value (option 2).  = I admit up front that there will be almost no code size difference = between 2 or 3 if the implementation has been compiled to only support a = single recipient.

My main point in raising this issue now is = we're likely to hear the same thing about COSE that Richard Barnes heard = from developers who were really using the JSON Serializations before we = added the flattened data representation - that having to emit and parse = a singleton array is ugly, awkward, etc.

This isn't a = show-stopper to me, but now that there's a working group, I wanted to = raise the issue for the working group to explicitly consider up front, = rather than wait until people are using early implementations and we = hear back from developers "why couldn't this have been simpler in = the simple case"?

            =                     = Cheers,
                =                 -- = Mike


> = Jim
>
> >
> > What do others think about this = tradeoff?
> >
> >          =                    -- = Mike
> >
> > -----Original Message-----
> > = From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim = Schaad
> > Sent: Thursday, April 30, 2015 3:59 PM
> > = To: cose@ietf.org
> > Subject: [Cose] Issue: = Encoding for a single recipient or structure
> >
> > = Question: Flattened encoding -
> > a)  Roll into parent = map
> > b)  Just be a map
> > c)  Single = element in array
> >
> > Discussion:
> = >
> > A late addition to the JOSE specification was the = ability to fold a
> > single recipient map into the base = encryption or signature map.  This
> > is doable because = the keys for all of the maps in question are unique.
> > This = would
> not
> > be true if the issue on reusing the = encryption body for the recipient
> > structure is = accepted.  This issue is being discussed in a separate
> > = mail
> thread
> > (but is current).  If arrays were = to be used at the top level, one
> > just
> = appends
> > the elements to the end of the base structure  = (see examples in the
> current
> > document).
> = >
> > There are three different options that can be selected = at this point:
> >
> > 1)  The = recipient/signature map is folded into the encryption/signing
> = > message top level.  If we accept the change for using the = same
> > structure
> for
> > both the encryption = body and the recipients, this is not a viable
> > = option
> due
> > to collisions of keys in the = map.
> >
> > 2)  The recipient/signature element = in the base map is permitted to be
> > either an array of = recipient/signature elements or a single
> > = recipient/signature map.  This option was rejected by the JOSE = group
> > as being too complicated for programmers to deal = with.  The cost of
> > this option is 2 bytes over option = one.  (One byte for the recipients
> > key, one byte for = the map marker.)
> >
> > CDDL grammar would be:  = recipients: [+[recipient_data]] /
> > {recipient_data}
> = >
> > 3)  We do not support any special form of dealing = with a single recipient.
> > The cost of this option is 3 bytes = over option one.  (One byte for the
> > recipients key, = one byte for the array marker, one byte for the map
> = marker.)
> >
> > CDDL grammar would be:  = recipients: [+[recpient_data]]
> >
> > = _______________________________________________
> > 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

 <= /o:p>

 

------=_NextPart_000_00D1_01D0B37C.21C96DF0--