From nobody Wed Jul 1 00:13: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 595C61B29E9 for ; Wed, 1 Jul 2015 00:13:06 -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 KUb7wkgkmDkn for ; Wed, 1 Jul 2015 00:13:02 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93FF91B29E6 for ; Wed, 1 Jul 2015 00:13:02 -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 t617Cv1X002377; Wed, 1 Jul 2015 09:12:57 +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 3mLv091SJyz3H1Q; Wed, 1 Jul 2015 09:12:57 +0200 (CEST) Message-ID: <559392F7.30000@tzi.org> Date: Wed, 01 Jul 2015 09:12:55 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: Jim Schaad References: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> <009501d0b392$fb7cc680$f2765380$@augustcellars.com> <00d001d0b3b6$ce20f2f0$6a62d8d0$@augustcellars.com> In-Reply-To: <00d001d0b3b6$ce20f2f0$6a62d8d0$@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] 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 07:13:06 -0000 Jim Schaad wrote: > If one believes that it is only for use in constrained environments, > then it is unlikely that there is a need for multiple recipients. Actually, we do have scenarios with fan-out (both via proxy and per multicast), and those are actually a strong motivator for object security. The minimal-bytes alternative is to mix in the map entries for a single recipient with those for the headers etc. Both JSON and CBOR do not have a defined sequence of map entries, so this means the recipient has to piece the info together as it comes in. We'd also need a separate set of labels. Not my favorite. If we keep together that map, what we could still do is turn ? recipients => [+{COSE_encrypt_fields}] back (we had something like that earlier) into ? recipients => [+{COSE_encrypt_fields}] / {COSE_encrypt_fields} Saves that 0x81 byte in the single-receiver case. Grüße, Carsten From nobody Wed Jul 1 00:20: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 E943D1B2A31 for ; Wed, 1 Jul 2015 00:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 yXdcAmWtzsPC for ; Wed, 1 Jul 2015 00:20:57 -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 0B4321AC41D for ; Wed, 1 Jul 2015 00:20:56 -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 t617Ks0w020423 for ; Wed, 1 Jul 2015 09:20:54 +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 3mLv9L35GRz3H2g; Wed, 1 Jul 2015 09:20:54 +0200 (CEST) Message-ID: <559394D4.6080900@tzi.org> Date: Wed, 01 Jul 2015 09:20:52 +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] msg_type 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 07:20:58 -0000 In the current draft, top-level entities have a field called msg_type. When we moved back to maps (did that ever really get decided?), that created one implementation inconvenience: Since CBOR (as with JSON) does not define the sequence of entries in a map, the msg_type can occur anywhere in the map. Such as at the end. I'm again proposing to get rid of msg_type. In many applications, the msg_type will be known from context. (Since msg_type is not protected, there is no security value to having it either.) In the other applications, we would be better of with CBOR tags for the types: These always occur before the data structure being tagged. (If they are taken from the specification required space, the tags take exactly the two bytes a msg_type field would take.) One nice side effect would be that the top-level encrypt structure looks exactly like the structure for one recipient, which might save some code (and makes the spec look so much better ;-). Grüße, Carsten From nobody Wed Jul 1 08:35:54 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 DA74C1A906F for ; Wed, 1 Jul 2015 08:35:52 -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 3CVCo_GejATt for ; Wed, 1 Jul 2015 08:35:50 -0700 (PDT) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (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 4B02D1A9059 for ; Wed, 1 Jul 2015 08:35:50 -0700 (PDT) Received: by igcsj18 with SMTP id sj18so137744828igc.1 for ; Wed, 01 Jul 2015 08:35:49 -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=LEcib/cuGdKZId2IeaiFckPjLNvHirYbzMyjVE8ff6o=; b=jb1JDSAfx7LLiRRCUuB2bfppt/BV5G7mZMCBAUxxTPNjovU1nMJEPuUhT1Iwd1ID3V TKyStDVl+wKKEA2So56wkLajr6/9ggzsM5miEcnhB/c0sMMvpm+gajh1iOjlAxz8nUX8 Rwbzeo2tk5cBenKJ3w8RnwPi2iDEAh1een0bhSDNWo/vdzqncpK26IH/z1wRjpSIzyfL 4A9hAO4lMw7gRhJj0C0iLuJYUDQOnHF72lnVU8B0IfQg4ripZ/ln60UN5wymGvcCzqdH CGxyMDsfouDu3PURdI8O2J0PIJVAtWrOxb+//4f7SQ3QcDZqmE84CQf/F1AYH1Gh1tTa griw== X-Gm-Message-State: ALoCoQlIHYtouLf8ftcHwZSO2TLk3mnyhnpB32DJxu0CIwePAnpcSdNyk7jQSOkTql8dQLCmGS9S X-Received: by 10.43.76.195 with SMTP id zf3mr4993266icb.62.1435764949703; Wed, 01 Jul 2015 08:35:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.64.209 with HTTP; Wed, 1 Jul 2015 08:35:20 -0700 (PDT) In-Reply-To: References: <002f01d0b388$57a1cc90$06e565b0$@augustcellars.com> From: Brian Campbell Date: Wed, 1 Jul 2015 09:35:20 -0600 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a113321eecef87c0519d213e7 Archived-At: Cc: Jim Schaad , "cose@ietf.org" 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: Wed, 01 Jul 2015 15:35:53 -0000 --001a113321eecef87c0519d213e7 Content-Type: text/plain; charset=UTF-8 What's the motivation for an AES based MAC (vs. say an HMAC)? Is it the hope that a broader set of COSE could be supported by something that only has to support AES? Or something else? On Tue, Jun 30, 2015 at 5:20 PM, Mike Jones wrote: > Do you have data on how commonly available implementations of these > algorithms are to help inform the choice? As you know, in JOSE we drove > the set of 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 > survey may be different than the largely Web-targeted development platforms > that 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 > the data shows that people will have to largely build AES-MAC or AES-CMAC > from scratch because their platforms don't support either of them, then I > agree 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 > 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 > > > _______________________________________________ > 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 > > --001a113321eecef87c0519d213e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What's the motivation for an AES based MAC (vs. say an= HMAC)? Is it the hope that a broader set of COSE could be supported by som= ething that only has to support AES? Or something else?=C2=A0

On Tue, Jun 30, 2015= at 5:20 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
Do you have data on how common= ly available implementations of these algorithms are to help inform the cho= ice?=C2=A0 As you know, in JOSE we drove the set of algorithm choices off o= f a survey of which algorithms were implemented on which common development= platforms.=C2=A0 (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.=C2=A0 For COSE, the right tools are more likely to be emb= edded systems development platforms.

Anyway, if we can make this choice based on data, that would be good.=C2=A0= If the data shows that people will have to largely build AES-MAC or AES-CM= AC from scratch because their platforms don't support either of them, t= hen I agree with your preference for AES-CMAC.

=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: 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.=C2=A0 In part because it has been around the longest.=C2=A0 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.=C2=A0 D= etails of this algorithm can be found in RFC 4493.

Do people have a preference as to which of these two algorithms is specifie= d?=C2=A0 My personal preference leans towards using the newer algorithm as = there is not a significant performance penalty and it appears to have bette= r security properties.

Jim


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

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


--001a113321eecef87c0519d213e7-- From nobody Wed Jul 1 09:21: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 7E3261A913E for ; Wed, 1 Jul 2015 09:21:55 -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 4QwByQeB7lEG for ; Wed, 1 Jul 2015 09:21:54 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 574111A9136 for ; Wed, 1 Jul 2015 09:21:54 -0700 (PDT) Received: by oiyy130 with SMTP id y130so35811302oiy.0 for ; Wed, 01 Jul 2015 09:21:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=xtkkX7tUsKCPgBN2rAaJlLQIJVegAWC1bUWoyQV1PCs=; b=nBy7HKkqG3nKvpLOPd/6pN4+EAHGkep+YqZaT816e0uJVYe0q4ZzMYlKRw0an94SLu KE+v9fKDj2rlZ721mEYDTOj/KYxSKJowh6dmYUjECbFrIj+RuPj/FEGuO95PUGYm5Juk 70CNvV9+8jHuoCSwsmRuQoKIlpxdJeiOWdYCUzwNQYe4POO0y5kDTkMaa9XUfPDhz5H0 HlgvgzrZnFQ/4zfdeXqhCc4nyNWPMX2CSvW/ZuiYwNyYnPV04ZJ5r9+18iVasHgfICFz qYf0ubZqS4gMkQX/M7iqcZmF1DDaRN1kY9ocn7F+41N9ON13LcQnif5l4xftEkP1zy0h 5Ugg== X-Received: by 10.202.224.87 with SMTP id x84mr6323754oig.18.1435767713841; Wed, 01 Jul 2015 09:21:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.116.99 with HTTP; Wed, 1 Jul 2015 09:21:34 -0700 (PDT) From: Dick Hardt Date: Wed, 1 Jul 2015 09:21:34 -0700 Message-ID: To: cose@ietf.org Content-Type: multipart/alternative; boundary=001a113d388090540b0519d2b8a4 Archived-At: Subject: [Cose] COSE efficiency vs JOSE 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 16:21:55 -0000 --001a113d388090540b0519d2b8a4 Content-Type: text/plain; charset=UTF-8 Hello I looked over https://tools.ietf.org/html/draft-schaad-cose-00 but did not see any indication of how much more efficient COSE will be over JOSE. Has anyone done any tests with real token data? -- Dick Signup at http://HARDTWARE.com to be notified about my upcoming Kickstarter! --001a113d388090540b0519d2b8a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello

I looked over=C2=A0https://tools.ietf.or= g/html/draft-schaad-cose-00 but did not see any indication of how much = more efficient COSE will be over JOSE. Has anyone done any tests with real = token data?

=
-- Dick

Signup at http://HARDTWARE.com to be notified about my = upcoming Kickstarter!
--001a113d388090540b0519d2b8a4-- From nobody Wed Jul 1 09:47:10 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 BCB4D1A92DE for ; Wed, 1 Jul 2015 09:47:09 -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 QmHzRLyqSCFM for ; Wed, 1 Jul 2015 09:47:08 -0700 (PDT) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) (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 E685C1A92DD for ; Wed, 1 Jul 2015 09:47:07 -0700 (PDT) Received: by igblr2 with SMTP id lr2so38876626igb.0 for ; Wed, 01 Jul 2015 09:47: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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5L1FHmUjH3kdFAl8gXWtL+veVdsEW0jhV+GysZgWkRM=; b=dQnFvCECJ8KqZmII9mDAYjh4Dd7fb6v1wugSbXzKXsu9dC3NyCtMH29Mk48IuRev5R n+zuOyabYr9UNn1kNXvJkXVlYuzUkzJmmo0CGJSLk5ws3J6F3N8Obw0mkiq9SqckzrYS L47DX8ogt8ChZFohthzWMgEv1Vx41epmouMPkGOFHJqFps7UTxJN29X5MHdihKlRuLex ArP7y8mXDcJNZmDaeRjn/NLEMd7hhHdH//1i85Z2UoEu/YwR5iMQfXIGygpYhyCjg2fq lMJKW3vIt2gxpqfNW/mCGP4M8Ry5l5T0mJAA56NHlR38tDKlNYeerXUeUWdbP+kDRCLl KxGQ== X-Gm-Message-State: ALoCoQmwJRMjhNy2X1E2iNMk/EmtBBDyutOOeuOKVi4KoHkFwSP6UV5q4n32V3iUiNwKlkrYgIfJ X-Received: by 10.43.19.131 with SMTP id qk3mr5597225icb.15.1435769227234; Wed, 01 Jul 2015 09:47:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.64.209 with HTTP; Wed, 1 Jul 2015 09:46:37 -0700 (PDT) In-Reply-To: References: <1B462EEC-67AF-4F19-B8F5-82BA36C59C8D@mit.edu> From: Brian Campbell Date: Wed, 1 Jul 2015 10:46:37 -0600 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=bcaec517cddcc4ed120519d3126e Archived-At: Cc: Justin Richer , "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: Wed, 01 Jul 2015 16:47:09 -0000 --bcaec517cddcc4ed120519d3126e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I likewise would like to thank Jim for this work and approve of adopting this document as a working group draft and starting point. However, I do want to reiterate that said approval is of the draft as a starting point and does not necessarily imply an endorsement of every detail or decision therein. On Sat, Jun 27, 2015 at 3:09 AM, 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. > > > > Best wishes, > > -- Mike > > > > *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 > > > > 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. > > > > Thank you, > > =E2=80=94 Justin (& Kepeng) > > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > --bcaec517cddcc4ed120519d3126e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I likewise would like to thank Jim for this work and = approve of adopting this document as a working group draft and starting poi= nt.

However, I do want to reiterate that said approval is of = the draft as a starting point and does not necessarily imply an endorsement= of every detail or decision therein.
=
On Sat, Jun 27, 2015 at 3:09 AM, Mike Jones = <Michael.Jones@microsoft.com> wrote:

Let me be the first to sa= y that I approve of adopting this document 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 provides a solid starting point for the = COSE work.

=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 Best wishes,

=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

From: Cose [ma= ilto:cose-bounce= s@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=

=C2=A0

The chairs would like to make a consensus call on ac= cepting the following document as the input draft for a new working group i= tem:

=C2=A0

=C2=A0

=C2=A0

=C2=A0

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

=C2=A0

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

=C2=A0

Thank you,

=C2=A0=E2=80=94 Justin (& Kepeng)<= /p>


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


--bcaec517cddcc4ed120519d3126e-- From nobody Wed Jul 1 10:18: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 47CD31AC3DB for ; Wed, 1 Jul 2015 10:18:36 -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 kb1xNJr28yD7 for ; Wed, 1 Jul 2015 10:18:34 -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 38E6C1AC3CF for ; Wed, 1 Jul 2015 10:18:34 -0700 (PDT) Received: by oiax193 with SMTP id x193so37036108oia.2 for ; Wed, 01 Jul 2015 10:18:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VPLFMNzAA+3mLSdnoGGE/ZKZH00rgGy03My3Oevyqls=; b=i78IecDsaJR7hKPu7M4nJjuoqvvwdBSxngehCNzijyag/gkdrrwOS3Zxv4Mf1OG1Tg qY/AUa7JrbwRXJBzMtmJ/60xF+UHCyDEHwlNlpN75v0xPGubI2yZ21rPFFvbQiyNSST7 DSFopB/fgfm+WaHsxm8o+OCRoobfi5+zUgB1GJE4Svx/CyFhpgyw5y7fA9UaHq1C3JUb SeSZ6lXPwM1vhT0beUfME7RMorXNSszMbwNUImiX/S5bPgUfm15ulQUQ8cc8NfNl1AFc 4jOH+BJ+0C67pcwu1vCI8r9pvSPnN/D/z6yAO14/gV9GMsC7OVPqSY05ZlympnLqfoVn B2TQ== MIME-Version: 1.0 X-Received: by 10.202.64.195 with SMTP id n186mr24791990oia.53.1435771113733; Wed, 01 Jul 2015 10:18:33 -0700 (PDT) Received: by 10.182.96.66 with HTTP; Wed, 1 Jul 2015 10:18:33 -0700 (PDT) In-Reply-To: References: <1B462EEC-67AF-4F19-B8F5-82BA36C59C8D@mit.edu> Date: Thu, 2 Jul 2015 02:18:33 +0900 Message-ID: From: Nat Sakimura To: Brian Campbell Content-Type: multipart/alternative; boundary=001a113dd1e63686fc0519d38333 Archived-At: Cc: Mike Jones , Justin Richer , "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: Wed, 01 Jul 2015 17:18:36 -0000 --001a113dd1e63686fc0519d38333 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 2015-07-02 1:46 GMT+09:00 Brian Campbell : > I likewise would like to thank Jim for this work and approve of adopting > this document as a working group draft and starting point. > > However, I do want to reiterate that said approval is of the draft as a > starting point and does not necessarily imply an endorsement of every > detail or decision therein. > > On Sat, Jun 27, 2015 at 3:09 AM, 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 startin= g >> point for the COSE work. >> >> >> >> Best wishes, >> >> -- Mike >> >> >> >> *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 >> >> >> >> The chairs would like to make a consensus call on accepting the followin= g >> 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. >> >> >> >> Thank you, >> >> =E2=80=94 Justin (& Kepeng) >> >> _______________________________________________ >> Cose mailing list >> Cose@ietf.org >> https://www.ietf.org/mailman/listinfo/cose >> >> > > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a113dd1e63686fc0519d38333 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

2015-07-02 1:46 GMT+09:00 Brian Campbell <bcampbell@pingi= dentity.com>:
I likewise would like to thank Jim for this work and approve of ad= opting this document as a working group draft and starting point.

<= /div>However, I do want to reiterate that said approval is of the draft as = a starting point and does not necessarily imply an endorsement of every det= ail or decision therein.

On Sat, Jun 27, 2015 at 3:09 AM, M= ike Jones <Michael.Jones@microsoft.com> wrote:
=

Let me be the first to sa= y that I approve of adopting this document 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 provides a solid starting point for the = COSE work.

=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 Best wishes,

=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

From: Cose [ma= ilto:cose-bounce= s@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=

=C2=A0

The chairs would like to make a consensus call on ac= cepting the following document as the input draft for a new working group i= tem:

=C2=A0

=C2=A0

=C2=A0

=C2=A0

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

=C2=A0

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

=C2=A0

Thank you,

=C2=A0=E2=80=94 Justin (& Kepeng)<= /p>


__________________________________________= _____
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




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundatio= n
http://nat.saki= mura.org/
@_nat_en
--001a113dd1e63686fc0519d38333-- From nobody Wed Jul 1 11:00:10 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 1489D1B2E7B for ; Wed, 1 Jul 2015 11:00:09 -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 7st7lID0EGz5 for ; Wed, 1 Jul 2015 11:00:07 -0700 (PDT) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (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 7ED611AD2AF for ; Wed, 1 Jul 2015 11:00:07 -0700 (PDT) Received: by iecuq6 with SMTP id uq6so40051472iec.2 for ; Wed, 01 Jul 2015 11:00:06 -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=SR+QVM7vejfhYBgwbu0DQGZm62Zyh29a5WrFpWO2Ws4=; b=OsF4lLxzJla7oOOv98eVqIfS3M3J6yWFHn0lfeTZDrd9j1r21uBPVSd7QluQI6cxqL 43bsVzeUNKV2SiZyiDCl6y313/yH5P7dAjj8ZFC95uxSEvKpfTMKyqp7Zl10fQo99Kqo TYPmDu8ve2keJWNnUAy5kTbXjBALhmLJMBkTX0DZ5ylwbZH9kzMDFXlnz2/BHYU3hZtq FkVFTw0ld3XBV8TJ+WzlE2SgWwMsoUC3LkZ39JEyUlaGa+p9ConmTnJlPiVsG2TSBJJo LD4vuK3/US3CQiNc0uYnYRABi+8jd204sugcFz0vQoud7+idAPN+IP5CPp2bSgIE7HsP 4afw== X-Gm-Message-State: ALoCoQmrtwzzVA5+CH3mqLh3RmCWnZZBdFA9CbgO/3WYIVD/kqEeJRe34y1zYISd/wAcMf02XxxB X-Received: by 10.50.59.211 with SMTP id b19mr33829454igr.42.1435773606735; Wed, 01 Jul 2015 11:00:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.64.209 with HTTP; Wed, 1 Jul 2015 10:59:37 -0700 (PDT) In-Reply-To: <5590E1FD.8040209@tzi.org> References: <5590E1FD.8040209@tzi.org> From: Brian Campbell Date: Wed, 1 Jul 2015 11:59:37 -0600 Message-ID: To: Carsten Bormann Content-Type: multipart/alternative; boundary=047d7bd75758cf1f5c0519d417f8 Archived-At: Cc: Mike Jones , "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: Wed, 01 Jul 2015 18:00:09 -0000 --047d7bd75758cf1f5c0519d417f8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'd never heard of IEC 80000-13. Maybe I'm an outlier on that but I'm not sure it can be considered mandatory reading. Not too long ago, on a different WG mailing list, I was chided for using byte rather than octet. So I'd view the inclusion of that usual text ('In this specification, the term "byte" is used in its now customary sense as a synonym for "octet".') as liberating rather than pedantic :) On Mon, Jun 29, 2015 at 12:13 AM, Carsten Bormann wrote: > 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=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose > --047d7bd75758cf1f5c0519d417f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd never heard of IEC 80000-13. Maybe I'm an= outlier on that but I'm not sure it can be considered mandatory readin= g.

Not too long ago, on a different WG mailing list, I was ch= ided for using byte rather than octet. So I'd view the inclusion of tha= t usual text ('In this specification, the term "byte" is used= in its now customary sense as a synonym for "octet".') as li= berating rather than pedantic :)

<= br>
On Mon, Jun 29, 2015 at 12:13 AM, Carsten Bor= mann <cabo@tzi.org> wrote:
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:
=C2=A0 =C2=A0In this specification, the term "byte" is used in it= s now customary
=C2=A0 =C2=A0sense as a synonym for "octet".)

Gr=C3=BC=C3=9Fe, Carsten

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

--047d7bd75758cf1f5c0519d417f8-- From nobody Wed Jul 1 11:28:14 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 BDC3D1ACE8D for ; Wed, 1 Jul 2015 11:28:12 -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 g6wM39Pn76gv for ; Wed, 1 Jul 2015 11:28:11 -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 0BF0A1AC3CE for ; Wed, 1 Jul 2015 11:28:11 -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 975AA38F1C; Wed, 1 Jul 2015 11:28:09 -0700 (PDT) From: "Jim Schaad" To: "'Carsten Bormann'" , References: <559394D4.6080900@tzi.org> In-Reply-To: <559394D4.6080900@tzi.org> Date: Wed, 1 Jul 2015 11:28:10 -0700 Message-ID: <000901d0b42b$b853d6c0$28fb8440$@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: AQI2pZyTgxzzxV4F5RyuJAhaGyZkdJz7C13Q Content-Language: en-us Archived-At: Subject: Re: [Cose] msg_type 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 18:28:12 -0000 > -----Original Message----- > From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Carsten Bormann > Sent: Wednesday, July 01, 2015 12:21 AM > To: cose@ietf.org > Subject: [Cose] msg_type >=20 > In the current draft, top-level entities have a field called msg_type. >=20 > When we moved back to maps (did that ever really get decided?), that > created one implementation inconvenience: Since CBOR (as with JSON) > does not define the sequence of entries in a map, the msg_type can = occur > anywhere in the map. Such as at the end. The sense of the mailing list was to move to maps. I am still trying to = work out some better arguments for going back to arrays as I feel it is = a cleaner structure. I am trying to figure out how much of my current = implementation experience is based on language/library vs the difference = in the COSE structure. Jim >=20 > I'm again proposing to get rid of msg_type. >=20 > In many applications, the msg_type will be known from context. > (Since msg_type is not protected, there is no security value to having = it > either.) In the other applications, we would be better of with CBOR = tags for > the > types: These always occur before the data structure being tagged. > (If they are taken from the specification required space, the tags = take > exactly the two bytes a msg_type field would take.) >=20 > One nice side effect would be that the top-level encrypt structure = looks > exactly like the structure for one recipient, which might save some = code > (and makes the spec look so much better ;-). >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Wed Jul 1 11:32: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 64B791ACF0A for ; Wed, 1 Jul 2015 11:32:06 -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 0MNsb3wN1fkE for ; Wed, 1 Jul 2015 11:32:04 -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 611EF1ACEC8 for ; Wed, 1 Jul 2015 11:32:04 -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 6290D38EFF; Wed, 1 Jul 2015 11:31:54 -0700 (PDT) From: "Jim Schaad" To: "'Brian Campbell'" References: <002f01d0b388$57a1cc90$06e565b0$@augustcellars.com> In-Reply-To: Date: Wed, 1 Jul 2015 11:31:54 -0700 Message-ID: <000a01d0b42c$4116d340$c34479c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01D0B3F1.94B8BE90" X-Mailer: Microsoft Outlook 15.0 thread-index: AQLtvlvpg3Q4ySKwkVlgbTj6EJO43gFbAGEsAs2/BqOba5T/oA== Content-Language: en-us Archived-At: Cc: cose@ietf.org 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: Wed, 01 Jul 2015 18:32:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000B_01D0B3F1.94B8BE90 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The motivation that I have is two-fold: =20 1. I have been told that this is the more common way to do = integrity protection (i.e. AES based rather than hash based). 2. Yes there is probably going to be a desire in the future to have = a minimal set of cryptographic primitives in silicon. I do not = currently believe that one can completely get rid of hash functions if = one wants to do ECDH key agreement, but for other configurations it = would be possible to do AES only. =20 Jim =20 =20 From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 Sent: Wednesday, July 01, 2015 8:35 AM To: Mike Jones Cc: Jim Schaad; cose@ietf.org Subject: Re: [Cose] AES based MAC algorithm =20 What's the motivation for an AES based MAC (vs. say an HMAC)? Is it the = hope that a broader set of COSE could be supported by something that = only has to support AES? Or something else? =20 =20 On Tue, Jun 30, 2015 at 5:20 PM, Mike Jones > wrote: Do you have data on how commonly available implementations of these = algorithms are to help inform the choice? As you know, in JOSE we drove = the set of 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 = survey may be different than the largely Web-targeted development = platforms that 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 the data shows that people will have to largely build AES-MAC or = AES-CMAC from scratch because their platforms don't support either of = them, then I agree 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 =20 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 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 _______________________________________________ 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 ------=_NextPart_000_000B_01D0B3F1.94B8BE90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The motivation that I have is two-fold:

 

1.      = =C2=A0I have been told that this is the more common way to do integrity = protection (i.e. AES based rather than hash = based).

2.      = Yes there is probably going to be a desire in the future to have a = minimal set of cryptographic primitives in silicon.=C2=A0 I do not = currently believe that one can completely get rid of hash functions if = one wants to do ECDH key agreement, but for other configurations it = would be possible to do AES only.

 

Jim

 

 

From:<= /b> = Brian Campbell [mailto:bcampbell@pingidentity.com]
Sent: = Wednesday, July 01, 2015 8:35 AM
To: Mike Jones
Cc: = Jim Schaad; cose@ietf.org
Subject: Re: [Cose] AES based MAC = algorithm

 

What's = the motivation for an AES based MAC (vs. say an HMAC)? Is it the hope = that a broader set of COSE could be supported by something that only has = to support AES? Or something else? 

 

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

Do you = have data on how commonly available implementations of these algorithms = are to help inform the choice?  As you know, in JOSE we drove the = set of 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 survey may be different than the = largely Web-targeted development platforms that 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 the data shows that people will have to largely = build AES-MAC or AES-CMAC from scratch because their platforms don't = support either of them, then I agree 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 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


_______________________________________= ________
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

 

------=_NextPart_000_000B_01D0B3F1.94B8BE90-- From nobody Wed Jul 1 11:38:47 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 B14941AD151 for ; Wed, 1 Jul 2015 11:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 13s00Wxn7Qng for ; Wed, 1 Jul 2015 11:38:44 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (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 AF15C1B2A0E for ; Wed, 1 Jul 2015 11:38:27 -0700 (PDT) Received: by ykdv136 with SMTP id v136so47313054ykd.0 for ; Wed, 01 Jul 2015 11:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ML9czZCAM/902dHdB/vb5welS5/c6Hlqpu9M0iMBrvg=; b=I7itAdCO5oo8uVXXlwMi3CQsID8zisqmR0oWEiZQSMDjX4uDUD9BeyoMyTFCs3zCfo L+UUlNfOJI/aGokyxQlpog0cBze9gKReWiTuE9HBaM8Ra4QPH8VjsgwEY6i0vRxVuU6l eqXp50aRFUpOHK9hMiWdi6KqkxQ/g0uIIBXzjVfeQGyhH0UecAXsjDo1ZC6si3poKy2W baGJrrzGAaIY+PcRqOeUmuiokzFZWd4aQk5y8Z9+2VXkUTMrBUbYUUsNrgR2rLN0yms6 CUMXhd6jTfQp3eF9PdEfZigG46nOq8m4DmZOko67g49dT1JvrQQ9PIevqNOsdwB4lyPQ Mv8g== MIME-Version: 1.0 X-Received: by 10.13.251.199 with SMTP id l190mr34545781ywf.148.1435775907051; Wed, 01 Jul 2015 11:38:27 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Wed, 1 Jul 2015 11:38:26 -0700 (PDT) In-Reply-To: <002f01d0b388$57a1cc90$06e565b0$@augustcellars.com> References: <002f01d0b388$57a1cc90$06e565b0$@augustcellars.com> Date: Wed, 1 Jul 2015 11:38:26 -0700 Message-ID: From: Martin Thomson To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: cose WG 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: Wed, 01 Jul 2015 18:38:45 -0000 On 30 June 2015 at 15:58, Jim Schaad wrote: > Do people have a preference as to which of these two algorithms is > specified? Objection: leading the witness. I thought that neither would be a good choice. AEAD encompasses a MAC (neither of these), and the hashes that we have defined seem sufficient. This seems wholly speculative. From nobody Wed Jul 1 11:43: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 ED66F1B29B8 for ; Wed, 1 Jul 2015 11:43:57 -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 yCvGpWnNiwUP for ; Wed, 1 Jul 2015 11:43:55 -0700 (PDT) Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) (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 B31501B2850 for ; Wed, 1 Jul 2015 11:43:55 -0700 (PDT) Received: by igrv9 with SMTP id v9so41140369igr.1 for ; Wed, 01 Jul 2015 11:43:55 -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=bprEr6z8SfXQCL5elw75iqBsJ7d3v/HWdff6e/1M0z0=; b=kU/ib1x8DZYlQD1rBiR1nktM3rECf+k/kSKZ0s6eVAhav2EK7BijKezLfHs2Xm43R1 gpDjzJiLvCspfgq8PguZ+exectFl6thLhL6GLYDRGfq9cgtLWecat9f4muJDOnZOE/wr de4qM7VJxkhfXn15VU8wsE8ETWAf8WK4vxyW/fhCpAuTH1zgCXGhBviZafq0LNBiZGa6 Lamqt+S1qV8DqkPQbjCBJBKBTmuuSK0gz5lT41zrO3KCAwYOOxuaYD6ejZDjZMuHmVHw /cV8CKYuLrPjjkX8kyo0tDQsMunFtPSlljd7NeErOYKbwY4HI0mSmZ/hrr1z9rZ8JVKC D4RQ== X-Gm-Message-State: ALoCoQn9EVfbfriYN4I1XpNq/lODAaVXBN70b/lGDffDG+9QFfVpI6QeyLBV4JRr3Orrru3HtKpc X-Received: by 10.42.255.200 with SMTP id nj8mr6249162icb.18.1435776234911; Wed, 01 Jul 2015 11:43:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.64.209 with HTTP; Wed, 1 Jul 2015 11:43:25 -0700 (PDT) In-Reply-To: <000a01d0b42c$4116d340$c34479c0$@augustcellars.com> References: <002f01d0b388$57a1cc90$06e565b0$@augustcellars.com> <000a01d0b42c$4116d340$c34479c0$@augustcellars.com> From: Brian Campbell Date: Wed, 1 Jul 2015 12:43:25 -0600 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=bcaec50fe70b75f6eb0519d4b46b Archived-At: Cc: cose@ietf.org 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: Wed, 01 Jul 2015 18:43:58 -0000 --bcaec50fe70b75f6eb0519d4b46b Content-Type: text/plain; charset=UTF-8 I only represent a single data point but I've never seen anything other than hash based MACs used in the applications I encounter. So #1 isn't real convincing to me. #2 I can see. On Wed, Jul 1, 2015 at 12:31 PM, Jim Schaad wrote: > The motivation that I have is two-fold: > > > > 1. I have been told that this is the more common way to do > integrity protection (i.e. AES based rather than hash based). > > 2. Yes there is probably going to be a desire in the future to have > a minimal set of cryptographic primitives in silicon. I do not currently > believe that one can completely get rid of hash functions if one wants to > do ECDH key agreement, but for other configurations it would be possible to > do AES only. > > > > Jim > > > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Wednesday, July 01, 2015 8:35 AM > *To:* Mike Jones > *Cc:* Jim Schaad; cose@ietf.org > *Subject:* Re: [Cose] AES based MAC algorithm > > > > What's the motivation for an AES based MAC (vs. say an HMAC)? Is it the > hope that a broader set of COSE could be supported by something that only > has to support AES? Or something else? > > > > On Tue, Jun 30, 2015 at 5:20 PM, Mike Jones > wrote: > > Do you have data on how commonly available implementations of these > algorithms are to help inform the choice? As you know, in JOSE we drove > the set of 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 > survey may be different than the largely Web-targeted development platforms > that 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 > the data shows that people will have to largely build AES-MAC or AES-CMAC > from scratch because their platforms don't support either of them, then I > agree 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 > 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 > > > _______________________________________________ > 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 > > > --bcaec50fe70b75f6eb0519d4b46b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I only represent a single data point but I've nev= er seen anything other than hash based MACs used in the applications I enco= unter. So #1 isn't real convincing to me.

#2 I can see.

On Wed, Ju= l 1, 2015 at 12:31 PM, Jim Schaad <ietf@augustcellars.com> wrote:

The motivat= ion that I have is two-fold:

=C2=A0

1.=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 =C2=A0I have bee= n told that this is the more common way to do integrity protection (i.e. AE= S based rather than hash based).

2.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Yes = there is probably going to be a desire in the future to have a minimal set = of cryptographic primitives in silicon.=C2=A0 I do not currently believe th= at one can completely get rid of hash functions if one wants to do ECDH key= agreement, but for other configurations it would be possible to do AES onl= y.

=C2= =A0

Jim

=C2=A0

=C2=A0

=

From: Brian Cam= pbell [mailto:bcampbell@pingidentity.com]
Sent: Wednesday, July 01, 201= 5 8:35 AM
To: Mike Jones
Cc: Jim Schaad; cose@ietf.org
Subject: R= e: [Cose] AES based MAC algorithm

=

=C2=A0

What's the motivation for an AES based MAC (vs. say a= n HMAC)? Is it the hope that a broader set of COSE could be supported by so= mething that only has to support AES? Or something else?=C2=A0

=C2=A0

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

Do you have data on how commonly av= ailable implementations of these algorithms are to help inform the choice?= =C2=A0 As you know, in JOSE we drove the set of algorithm choices off of a = survey of which algorithms were implemented on which common development pla= tforms.=C2=A0 (See the attached spreadsheet.)

I realize that in this= case, the right sets of development platforms to survey may be different t= han the largely Web-targeted development platforms that JOSE surveyed.=C2= =A0 For COSE, the right tools are more likely to be embedded systems develo= pment platforms.

Anyway, if we can make this choice based on data, t= hat would be good.=C2=A0 If the data shows that people will have to largely= build AES-MAC or AES-CMAC from scratch because their platforms don't s= upport either of them, then I agree with your preference for AES-CMAC.
<= span style=3D"color:#888888">
=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: Tuesday, June 30, 2015 3:59 PM
To: cose@ietf.org
Subject: [Cose] A= ES based MAC algorithm

In doing the work on getting algorithms into = the document I ended up with a "Which one" question.

AES-M= AC has historically been the block cipher MAC algorithm used by most people= .=C2=A0 In part because it has been around the longest.=C2=A0 It does the t= raditional 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 var= iant 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.=C2=A0 Details of this algorithm can be found in RF= C 4493.

Do people have a preference as to which of these two algorit= hms is specified?=C2=A0 My personal preference leans towards using the newe= r algorithm as there is not a significant performance penalty and it appear= s to have better security properties.

Jim


_______________= ________________________________
Cose mailing list
Cose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/cose


_______________________________________= ________
Cose mailing list
Cose@ietf.org
https://www.ietf.org/mailman/listinfo/cose<= u>

=C2=A0=


--bcaec50fe70b75f6eb0519d4b46b-- From nobody Wed Jul 1 11:53: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 2251A1B2A0A for ; Wed, 1 Jul 2015 11:53:11 -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 L7omqupSIg4C for ; Wed, 1 Jul 2015 11:53:09 -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 AA9A91AC3F9 for ; Wed, 1 Jul 2015 11:53:08 -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 t61Ir4BK025238; Wed, 1 Jul 2015 20:53:04 +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 3mMBX005ttz3Ghb; Wed, 1 Jul 2015 20:53:03 +0200 (CEST) Message-ID: <5594370E.8040604@tzi.org> Date: Wed, 01 Jul 2015 20:53:02 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: Brian Campbell References: <002f01d0b388$57a1cc90$06e565b0$@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: Mike Jones , Jim Schaad , "cose@ietf.org" 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: Wed, 01 Jul 2015 18:53:11 -0000 Brian Campbell wrote: > What's the motivation for an AES based MAC (vs. say an HMAC)? Many constrained platforms have hardware support for AES. At the link layer, CBC-MAC is already in use as part of CCM. CCM-based ciphersuites are also the standard ones for the use of DTLS with CoAP. Grüße, Carsten From nobody Wed Jul 1 11:59: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 E6E071B2A50 for ; Wed, 1 Jul 2015 11:59:56 -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 ZZlQR5D1Y-TP for ; Wed, 1 Jul 2015 11:59:56 -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 0F1611B2A4E for ; Wed, 1 Jul 2015 11:59:55 -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 t61Ixq0Z008356; Wed, 1 Jul 2015 20:59:52 +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 3mMBgr1hf6z3GjW; Wed, 1 Jul 2015 20:59:52 +0200 (CEST) Message-ID: <559438A6.1060509@tzi.org> Date: Wed, 01 Jul 2015 20:59:50 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: Brian Campbell References: <5590E1FD.8040209@tzi.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Mike Jones , "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: Wed, 01 Jul 2015 18:59:57 -0000 Brian Campbell wrote: > I'd never heard of IEC 80000-13. Well, it only became a published as a standard in 2008. You probably left school before that date :-) You probably heard about the SI system in school. Unfortunately, metrologists don't care about things that can just be counted, so that part of SI staid barren for quite a while. No more. > liberating Very much so. Grüße, Carsten From nobody Wed Jul 1 12: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 65E841B2E98 for ; Wed, 1 Jul 2015 12:09:59 -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 JyeuAlvFvYM5 for ; Wed, 1 Jul 2015 12:09:58 -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 EA6741B2EB4 for ; Wed, 1 Jul 2015 12:09: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 t61J9k4B000222; Wed, 1 Jul 2015 21:09:46 +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 3mMBvF6Nygz3Gkr; Wed, 1 Jul 2015 21:09:45 +0200 (CEST) Message-ID: <55943AF8.2000108@tzi.org> Date: Wed, 01 Jul 2015 21:09:44 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: Dick Hardt 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] COSE efficiency vs JOSE 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 19:09:59 -0000 > I looked over https://tools.ietf.org/html/draft-schaad-cose-00 but did > not see any indication of how much more efficient COSE will be over > JOSE. Has anyone done any tests with real token data? Which kind of efficiency? -- message size? -- code size? -- RAM requirements? -- execution speed: -- on data center style hardware? -- on constrained nodes? I'm assuming you meant the first (all five are important to the IoT). Jim had some slides: https://www.ietf.org/proceedings/92/slides/slides-92-jose-0.pdf These are not numbered*), but slide 8 has some numbers: Overheads only – ignores contents JOSE Bormann Schaad 1 Signer 64 + base64 13 13 1 MAC recipient 64 + base64 13 14 1 Encrypt rcpt 94 + base64 14 14 There is some brownian motion in the exact numbers, but the gist should still be true. (The base 64 overhead is an additional 1/3 of the size of binary data such as protected headers, authenticators, keys, etc.) Grüße, Carsten *) ceterum censeo: All presentation slides MUST be numbered. From nobody Wed Jul 1 13:40: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 EE4711A00DD for ; Wed, 1 Jul 2015 13:40:56 -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 3hg6DgEpJYQR for ; Wed, 1 Jul 2015 13:40:55 -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 14A381A0049 for ; Wed, 1 Jul 2015 13:40:55 -0700 (PDT) Received: by igcsj18 with SMTP id sj18so144961647igc.1 for ; Wed, 01 Jul 2015 13:40:54 -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=libMirXbVl9HvuUwIH63OSNiG3Sr27po7DT8GqpOVQU=; b=W5yS0K8am/khpr2gseVrm8QgrJyse19nkwJk681nc49Z5q5XTlPFzSwK5PjktH5lHA NC8cgK3BBDkV9lYdIwlkTIs9cQ/Z0+hBqyk9mHgJrb+GGeRJazZjGH6k09km3ZfMHCwu QN4vMqUW4nsmebE42Ij/gkMDX+VpE2NSoqRVLV6FulNUfvfy+89gJWWIyswHVJwonQun FmoNi3krJ61ojkAiagpzJbugC0pD0etYNq8fEr4JNVSRBZj15/uu7/bW5A+Tkvii5Nu1 ESQR3bHQz9GFIv3YG+xVkMLiIdK3h2K2sKitTF6buI3rJ+qiXITpXB1FOhFJGgawvrBB tJOQ== X-Gm-Message-State: ALoCoQkIQcecgj/2ffvFBpIONCBMhXEOFKzL6YO6YIcMqdOsODPXDpY3qQxcwQ82I3Lulufssmdv X-Received: by 10.50.50.204 with SMTP id e12mr32383962igo.0.1435783254416; Wed, 01 Jul 2015 13:40:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.64.209 with HTTP; Wed, 1 Jul 2015 13:40:24 -0700 (PDT) In-Reply-To: <559392F7.30000@tzi.org> References: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> <009501d0b392$fb7cc680$f2765380$@augustcellars.com> <00d001d0b3b6$ce20f2f0$6a62d8d0$@augustcellars.com> <559392F7.30000@tzi.org> From: Brian Campbell Date: Wed, 1 Jul 2015 14:40:24 -0600 Message-ID: To: Carsten Bormann Content-Type: multipart/alternative; boundary=047d7bd76f4cdad7df0519d65681 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 20:40:57 -0000 --047d7bd76f4cdad7df0519d65681 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In my own experience with JOSE, the need for single recipient case is overwhelming majority and the simplicity the compact serialization afforded for that case are a major win. My own implementation supports only the compact serializations (and thus only a single recipient or signature) and it is used widely in my employer's products and services as well as being open source. No one has ever even asked about the JSON serializations (which support multiple signatures/recipients). I understand the allure of consistently treating something that could have more than one thing as always potentially having more than one. But there is real value in making the most common cases simple, which shouldn't be discounted. On Wed, Jul 1, 2015 at 1:12 AM, Carsten Bormann wrote: > Jim Schaad wrote: > > If one believes that it is only for use in constrained environments, > > then it is unlikely that there is a need for multiple recipients. > > Actually, we do have scenarios with fan-out (both via proxy and per > multicast), and those are actually a strong motivator for object security= . > > The minimal-bytes alternative is to mix in the map entries for a single > recipient with those for the headers etc. Both JSON and CBOR do not > have a defined sequence of map entries, so this means the recipient has > to piece the info together as it comes in. We'd also need a separate > set of labels. Not my favorite. > > If we keep together that map, what we could still do is turn > > ? recipients =3D> [+{COSE_encrypt_fields}] > > back (we had something like that earlier) into > > ? recipients =3D> [+{COSE_encrypt_fields}] / {COSE_encrypt_fields} > > Saves that 0x81 byte in the single-receiver case. > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose > --047d7bd76f4cdad7df0519d65681 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In my own experience with JOSE, the need for sin= gle recipient case is overwhelming majority and the simplicity the compact = serialization afforded for that case are a major win. My own implementation= supports only the compact serializations (and thus only a single recipient= or signature) and it is used widely in my employer's products and serv= ices as well as being open source. No one has ever even asked about the JSO= N serializations (which support multiple signatures/recipients).

I understand the allure of consistently treating something that could h= ave more than one thing as always potentially having more than one.
But there is real value in making the most common cases simple, whic= h shouldn't be discounted.



On Wed, Jul 1, 2015 = at 1:12 AM, Carsten Bormann <cabo@tzi.org> wrote:
Jim Schaad wrote:
> If one believes that it is only for use in constrained environments, > then it is unlikely that there is a need for multiple recipients.

Actually, we do have scenarios with fan-out (both via proxy and per<= br> multicast), and those are actually a strong motivator for object security.<= br>
The minimal-bytes alternative is to mix in the map entries for a single
recipient with those for the headers etc.=C2=A0 Both JSON and CBOR do not have a defined sequence of map entries, so this means the recipient has
to piece the info together as it comes in.=C2=A0 We'd also need a separ= ate
set of labels.=C2=A0 Not my favorite.

If we keep together that map, what we could still do is turn

=C2=A0 =C2=A0 =C2=A0 =C2=A0? recipients =3D> [+{COSE_encrypt_fields}]
back (we had something like that earlier) into

=C2=A0 =C2=A0 =C2=A0 =C2=A0? recipients =3D> [+{COSE_encrypt_fields}] / = {COSE_encrypt_fields}

Saves that 0x81 byte in the single-receiver case.

Gr=C3=BC=C3=9Fe, Carsten

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

--047d7bd76f4cdad7df0519d65681-- From nobody Wed Jul 1 15:06: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 7A1D51A70FD for ; Wed, 1 Jul 2015 15:06:54 -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 7G471dZqjlLA for ; Wed, 1 Jul 2015 15:06:52 -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 9ED3C1AD272 for ; Wed, 1 Jul 2015 15:06:51 -0700 (PDT) X-AuditID: 1209190d-f796f6d000005314-2a-5594647a874c 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-2.mit.edu (Symantec Messaging Gateway) with SMTP id 4E.D8.21268.A7464955; Wed, 1 Jul 2015 18:06:50 -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 t61M6n42026207; Wed, 1 Jul 2015 18:06:49 -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 t61M6krA028801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Jul 2015 18:06:47 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_DF3FF0A8-55C3-4C17-BA83-98CC239E6247" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Justin Richer In-Reply-To: Date: Wed, 1 Jul 2015 18:06:46 -0400 Message-Id: References: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> <009501d0b392$fb7cc680$f2765380$@augustcellars.com> <00d001d0b3b6$ce20f2f0$6a62d8d0$@augustcellars.com> <559392F7.30000@tzi.org> To: Brian Campbell X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIKsWRmVeSWpSXmKPExsUixCmqrVuVMiXUYOoqMYvV/28yWhyZcpfV YtrWqawWq6d/Z3Ng8dg4Zzqbx5IlP5k87h69yOIxbVFmAEsUl01Kak5mWWqRvl0CV8a3K4cY C/YGVHSedG1gbHHpYuTkkBAwkXj14hwThC0mceHeerYuRi4OIYHFTBIvDm2DcjYwSjxauJoZ wnnAJLGzv4u9i5GDg1kgQWLVtGCQbl4BPYlHTx+zg9jCAu4Sr2+ATOLkYBNQlZi+pgVsA6dA oMTVid8YQWwWARWJz90PWEBsZoF4iamfX7FBzLGSuP+vnRFi1x8WiZtPP4ElRAT0JW4/nQO2 V0JAVuLrVrkJjAKzEK6YheSKWWBTtSWWLXzNDGFrSuzvXs6CKa4h0fltIusCRrZVjLIpuVW6 uYmZOcWpybrFyYl5ealFukZ6uZkleqkppZsYwTEhybuD8d1BpUOMAhyMSjy8GRKTQ4VYE8uK K3MPMUpyMCmJ8rbETgkV4kvKT6nMSCzOiC8qzUktPsQowcGsJMJ7JQgox5uSWFmVWpQPk5Lm YFES5930gy9ESCA9sSQ1OzW1ILUIJivDwaEkwcuQDNQoWJSanlqRlplTgpBm4uAEGc4DNLwN pIa3uCAxtzgzHSJ/ilFRSpxXHyQhAJLIKM2D64WlrFeM4kCvCPN6g1TxANMdXPcroMFMQINf 2k8CGVySiJCSamDUT7OeYPfRVPSdZhVLqTpXnuv63j9fVbefFWhfne4cO5f5z8SOzMboA0rS lQqX1laxif7TDFCN3pfra3NpY8bJumDd1bm7lMrcIwrN/0RdZei/36GR4vXWwUSL495lyxud Rg78yz/L1ykzZYiu/L3Y4VSo8UQf2S3P3iqH340OO9M/64PYdSWW4oxEQy3mouJEAE+i9zo0 AwAA Archived-At: Cc: Carsten Bormann , 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 22:06:54 -0000 --Apple-Mail=_DF3FF0A8-55C3-4C17-BA83-98CC239E6247 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 self.setChair(false); // n.b.: commenting as an individual contributor I=E2=80=99ve got to agree with Brian on this point. To add my anecdote = to the pile: I=E2=80=99ve been using the JOSE compact serializations in = many production environments for years now, including contributing to = several different open source implementations all of which support only = the compact serializations. In that time I=E2=80=99ve never once had = someone ask for support to the JSON serializations, or ask for = multi-party signature or recipient support. I=E2=80=99d encourage folks = in the COSE list to do a survey of the numerous JOSE libraries out there = and see what features people are actually implementing and using. This = ought to be a good indicator for what to focus on here, if you ask me. To me, the JSON serializations in JOSE were always more of an academic = exercise than something I saw being used in the real world. And for a = simple case, they=E2=80=99re amazingly fantastic. When COSE was first = being discussed, I had thought it was a foregone conclusion that it = would focus on the compact serializations, considering that the entire = goal here is to make JOSE *more compact* (and/or simple in various = dimensions, given Carsten=E2=80=99s recent post). The compact = serializations are very simple data structures and this is part of the = reason that JOSE has actually taken off the way it has. =E2=80=94 Justin self.setChair(true); // back to lurking > On Jul 1, 2015, at 4:40 PM, Brian Campbell = wrote: >=20 > In my own experience with JOSE, the need for single recipient case is = overwhelming majority and the simplicity the compact serialization = afforded for that case are a major win. My own implementation supports = only the compact serializations (and thus only a single recipient or = signature) and it is used widely in my employer's products and services = as well as being open source. No one has ever even asked about the JSON = serializations (which support multiple signatures/recipients).=20 >=20 > I understand the allure of consistently treating something that could = have more than one thing as always potentially having more than one.=20 >=20 > But there is real value in making the most common cases simple, which = shouldn't be discounted.=20 >=20 >=20 >=20 > On Wed, Jul 1, 2015 at 1:12 AM, Carsten Bormann > wrote: > Jim Schaad wrote: > > If one believes that it is only for use in constrained environments, > > then it is unlikely that there is a need for multiple recipients. >=20 > Actually, we do have scenarios with fan-out (both via proxy and per > multicast), and those are actually a strong motivator for object = security. >=20 > The minimal-bytes alternative is to mix in the map entries for a = single > recipient with those for the headers etc. Both JSON and CBOR do not > have a defined sequence of map entries, so this means the recipient = has > to piece the info together as it comes in. We'd also need a separate > set of labels. Not my favorite. >=20 > If we keep together that map, what we could still do is turn >=20 > ? recipients =3D> [+{COSE_encrypt_fields}] >=20 > back (we had something like that earlier) into >=20 > ? recipients =3D> [+{COSE_encrypt_fields}] / = {COSE_encrypt_fields} >=20 > Saves that 0x81 byte in the single-receiver case. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose = >=20 > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose --Apple-Mail=_DF3FF0A8-55C3-4C17-BA83-98CC239E6247 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

self.setChair(false); // = n.b.: commenting as an individual contributor


I=E2=80=99ve got to agree with Brian on this point. To add my = anecdote to the pile: I=E2=80=99ve been using the JOSE compact = serializations in many production environments for years now, including = contributing to several different open source implementations all of = which support only the compact serializations. In that time I=E2=80=99ve = never once had someone ask for support to the JSON serializations, or = ask for multi-party signature or recipient support. I=E2=80=99d = encourage folks in the COSE list to do a survey of the numerous JOSE = libraries out there and see what features people are actually = implementing and using. This ought to be a good indicator for what to = focus on here, if you ask me.

To me, the JSON serializations in JOSE = were always more of an academic exercise than something I saw being used = in the real world. And for a simple case, they=E2=80=99re amazingly = fantastic. When COSE was first being discussed, I had thought it was a = foregone conclusion that it would focus on the compact serializations, = considering that the entire goal here is to make JOSE *more compact* = (and/or simple in various dimensions, given Carsten=E2=80=99s recent = post). The compact serializations are very simple data structures and = this is part of the reason that JOSE has actually taken off the way it = has.


=E2=80=94 Justin
self.setChair(true); // back to = lurking


On = Jul 1, 2015, at 4:40 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

In = my own experience with JOSE, the need for single recipient case is = overwhelming majority and the simplicity the compact serialization = afforded for that case are a major win. My own implementation supports = only the compact serializations (and thus only a single recipient or = signature) and it is used widely in my employer's products and services = as well as being open source. No one has ever even asked about the JSON = serializations (which support multiple signatures/recipients).

I understand the allure of consistently = treating something that could have more than one thing as always = potentially having more than one.

But = there is real value in making the most common cases simple, which = shouldn't be discounted.



On Wed, = Jul 1, 2015 at 1:12 AM, Carsten Bormann <cabo@tzi.org> wrote:
Jim Schaad wrote:
> If one believes that it is only for use in constrained = environments,
> then it is unlikely that there is a need for multiple = recipients.

Actually, we do have scenarios with fan-out (both via proxy and = per
multicast), and those are actually a strong motivator for object = security.

The minimal-bytes alternative is to mix in the map entries for a = single
recipient with those for the headers etc.  Both JSON and CBOR do = not
have a defined sequence of map entries, so this means the recipient = has
to piece the info together as it comes in.  We'd also need a = separate
set of labels.  Not my favorite.

If we keep together that map, what we could still do is turn

       ? recipients =3D> = [+{COSE_encrypt_fields}]

back (we had something like that earlier) into

       ? recipients =3D> [+{COSE_encrypt_fields}] = / {COSE_encrypt_fields}

Saves that 0x81 byte in the single-receiver case.

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

= --Apple-Mail=_DF3FF0A8-55C3-4C17-BA83-98CC239E6247-- From henrich@2000grad.com Wed Jul 1 08:14: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 A05861A8F3D for ; Wed, 1 Jul 2015 08:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, 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 jLfMKrytBGgE for ; Wed, 1 Jul 2015 08:14:03 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 987991A8F41 for ; Wed, 1 Jul 2015 08:14:03 -0700 (PDT) Received: from [192.168.0.15] ([109.69.103.162]) by mrelayeu.kundenserver.de (mreue002) with ESMTPSA (Nemesis) id 0M2U21-1Ys6P71g0b-00sLgj; Wed, 01 Jul 2015 17:14:00 +0200 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Henrich_P=F6hls?= X-Gpg-Fingerprint: 13A2 45ED 4FDC 2A66 F99E 1E29 E98E 021A 937A F4F2 In-Reply-To: <00d001d0b3b6$ce20f2f0$6a62d8d0$@augustcellars.com> Date: Wed, 1 Jul 2015 17:13:55 +0200 X-Mao-Original-Outgoing-Id: 457456435.7827-c8f3d716b6eb728ab7f1b62755a9c124 Content-Transfer-Encoding: quoted-printable Message-Id: <475F155D-6527-45D9-BC62-75CA0B34C706@2000grad.com> References: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> <009501d0b392$fb7cc680$f2765380$@augustcellars.com> <00d001d0b3b6$ce20f2f0$6a62d8d0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:djDeAdi3yHmemPlUCScf6EL7/YHQtBHFz1s9psvFytAk+b+LQ9R FGt9hEr2SPxPnshDeEhvFh1Wi9zjl9d1KN9J8IQqzW+MkncD5bO1V5EiXfN1bCj/sQD7W4L ndmVj3ACTyidt+WbBBa4tSTMArJEs7gD9lP8dFdWU+kJgBqBEvHHDNDv+1VVGo1051nTAoP dlOlyTjj/5OLnlFNtqz1g== X-UI-Out-Filterresults: notjunk:1;V01:K0:+BQiNooCzAU=:zKPzHQheUZrK17FE75dDfV eY2H4yi/dvzojbM5uJLK2KflV89O5TixzVXbYqqbL3aMJVM6gXwNurgTcDtKvyfIkfML7Uu7v P97ShxBOfA8BgGTwHyBloe5cyneRMV1jPfbd/yC7b61N4RjAaeW18tyhozN6jnuyjQOl4st5r OekldpMjguJKD+cSHxtApyG/3Kl7d2JVjoGV+VwRXAggtBTbs2KCwKG+JchupqAD+rINy5fZ5 xQT8ek+T9tCmS6r24lIItorT2OD78hQiqen7QYgVfsnUS0njT2RcEQDE22VdcBAnzsnQ4MKXY DcIWw6zHGXEzUXdZaQjuA8Wn7+aEX54hI+GYPdl87N+iQmKDDt67vPbq/lL9gGBC5DClJqtRY 5JMWVuiEwwqeNGoopQiKoYhjXtNyWIXL7r6CP87CYG/yje6QRHOIXtOSuYWH3E7UoKsf8ABlf K+ZOxynvx05WZxJit+4TAtUE3pCv6wT/QfzVY9swC2CBmdTohAHfHE4QHGhLbt4y+qxeEcuJN OzVKNcF0EWH//YW7l/tVEmzalrDIl7Ky3O2HPmW5j9BaIAd+bRsNB4cnJyPrIzyRoA9O3h8+O gkHeFxOjXLTKNH9lXAmRchdNClDL+Q4v7IVYM4ESIDD4gwtpyDLveXC8SwJL0ZHvxbuDdvyzb 15Ho8ZOWXM3MIL/okX+BVXvKIICBmBMMn4e+O9mgXJ/d59A== Archived-At: X-Mailman-Approved-At: Wed, 01 Jul 2015 16:01:08 -0700 Cc: cose@ietf.org, Dick Hardt 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 15:16:46 -0000 Dear Jim, On 01 Jul 2015, at 06:31, Jim Schaad wrote: > 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. Another application domain of COSE is integrity protection = (ECCsignatures, MACs), right?=20 I can think of use cases that benefit if you are capable of having a = compact and easily parseable representation of signed signed data. An example could be if you facilitate signatures to check if data = originated at some sensor and also that it passed (and got vetted for) = by another constrained device (e.g. data concentrator). Just my thoughts. As I currently work towards finding a good = representation for cryptographically signed JSON messages to be emitted = by constrained devices, within the RERUM project, I was following the = discussions here.=20 Best, Henrich From nobody Thu Jul 2 00:36: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 56EB01B3015 for ; Thu, 2 Jul 2015 00:36:49 -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 tkaQK96unNyK for ; Thu, 2 Jul 2015 00:36:48 -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 B726C1B2FFA for ; Thu, 2 Jul 2015 00:36:47 -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 t627af5r009688; Thu, 2 Jul 2015 09:36:42 +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 3mMWT53MbBz3GB9; Thu, 2 Jul 2015 09:36:41 +0200 (CEST) Message-ID: <5594EA07.3030508@tzi.org> Date: Thu, 02 Jul 2015 09:36:39 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: Justin Richer References: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> <009501d0b392$fb7cc680$f2765380$@augustcellars.com> <00d001d0b3b6$ce20f2f0$6a62d8d0$@augustcellars.com> <559392F7.30000@tzi.org> 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 , Brian Campbell , 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: Thu, 02 Jul 2015 07:36:49 -0000 I'm not sure the JOSE experience translates to COSE. In JOSE, there are two different forms, one array-based (a dot-joined sequence of base64 encodings of the array elements) and one map-based. COSE doesn't need that choice. All I can read from the JOSE experience cited here is a strong indicator that we want to go for arrays, not maps, at least for the outer structure. Now whether that is shaped*) [pr, un, ciph, [r1, r2]] or [pr, un, ciph, r1] or [pr, un, ciph, *r1] (where *r1 means tha the contents of r1 is expanded right in place) becomes less of a complexity argument: [pr, un, ciph, [r1]] really isn't that much more complex than [pr, un, ciph, r1] except for that one 0x81 byte wasted; in a pinch, we can also go for [pr, un, ciph, r1, r2] (which is another way of saying: [pr, un, ciph, *[r1, r2]] ) Making the array variable size disables JOSE's hack of using the array size for distinguishing JWE from JWS. But we don't need that; CBOR has tags. Grüße, Carsten *) I'm leaving msg_type out here, see other thread. From nobody Thu Jul 2 10:14: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 0477F1A0302 for ; Thu, 2 Jul 2015 10:14:30 -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 KI8V-5tgDBAV for ; Thu, 2 Jul 2015 10:14:28 -0700 (PDT) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (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 480F61A02BE for ; Thu, 2 Jul 2015 10:14:28 -0700 (PDT) Received: by iecvh10 with SMTP id vh10so61217150iec.3 for ; Thu, 02 Jul 2015 10:14:27 -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=xFg/lO8dsImlHHwPW9V62Upad22ZLe6i+H55LNEGiqU=; b=Xllo6GpozebvJKrciqujqsB/JbZRYo7e1qkTQSv4zlMBwzomA47FWUIrN135L1dMS8 vIqUhl4G1mRPigbho7hAxgbr6AGx310Ay0nJY8lpY6D9VHTCX7tLlvGZsoFOwTRgIgVT 6bJqds4y6Vfkd6/VSrM0SykI0YWxi94R4u10jjo2rSLIsLD/OX4DFbeRuorIBY0lMPvV o7Yp2s26JAT9f2aaxYgCIw9lKcJNh5beM090aBiLBownOF6FdZoZ5yAeNiAtARzDSZEo LrjQjDLJ9OQ2MB3nFR2eqBd041vcHwZ+kNx1cp3XjOnjTHgRu+7QnrF1M0dAXp+QNtpP lDPg== X-Gm-Message-State: ALoCoQnmmBPE/Xhj2q/8HxUxVOhfuMN3jNlVgnmyUu+JqKcs2i8WSsUUNJ28NN6NfXDxVV6AERKe X-Received: by 10.107.132.211 with SMTP id o80mr30832369ioi.52.1435857267597; Thu, 02 Jul 2015 10:14:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.64.209 with HTTP; Thu, 2 Jul 2015 10:13:58 -0700 (PDT) In-Reply-To: <5594EA07.3030508@tzi.org> References: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> <009501d0b392$fb7cc680$f2765380$@augustcellars.com> <00d001d0b3b6$ce20f2f0$6a62d8d0$@augustcellars.com> <559392F7.30000@tzi.org> <5594EA07.3030508@tzi.org> From: Brian Campbell Date: Thu, 2 Jul 2015 11:13:58 -0600 Message-ID: To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a113f77766245c40519e79263 Archived-At: Cc: Jim Schaad , Justin Richer , 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: Thu, 02 Jul 2015 17:14:30 -0000 --001a113f77766245c40519e79263 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Some things translate more directly than others :) Indeed the dot joined base64url encoded segments are very array like. And with CBOR that encoding and dot joining is unneeded. The JOSE experience I'm suggesting this WG consider is the relative simplicity afforded by compact serializations and the widespread use they have seen. Conceptualizing the compact serializations as arrays, you have this for signatures/macs: [protected_header, payload, signature] and this for encryption: [protected_header, encrypted_key, initialization_vector, ciphertext, authentication_tag] There's just a single recipient or just one signature. There's only one place for headers and they are always protected. It's a (relatively) simple and consistent processing model. The message can be processed or not. There's real value in the simplicity. On Thu, Jul 2, 2015 at 1:36 AM, Carsten Bormann wrote: > I'm not sure the JOSE experience translates to COSE. > > In JOSE, there are two different forms, one array-based (a dot-joined > sequence of base64 encodings of the array elements) and one map-based. > COSE doesn't need that choice. > > All I can read from the JOSE experience cited here is a strong indicator > that we want to go for arrays, not maps, at least for the outer structure= . > > Now whether that is shaped*) > > [pr, un, ciph, [r1, r2]] > > or > > [pr, un, ciph, r1] > > or > > [pr, un, ciph, *r1] > > (where *r1 means tha the contents of r1 is expanded right in place) > > becomes less of a complexity argument: > [pr, un, ciph, [r1]] > really isn't that much more complex than > [pr, un, ciph, r1] > except for that one 0x81 byte wasted; in a pinch, we can also go for > > [pr, un, ciph, r1, r2] > (which is another way of saying: > [pr, un, ciph, *[r1, r2]] > ) > > Making the array variable size disables JOSE's hack of using the array > size for distinguishing JWE from JWS. But we don't need that; CBOR has > tags. > > Gr=C3=BC=C3=9Fe, Carsten > > *) I'm leaving msg_type out here, see other thread. > --001a113f77766245c40519e79263 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Some things translate more directly than others = :)

Indeed the dot joined base64url encoded segments are very array l= ike. And with CBOR that encoding and dot joining is unneeded.

=
The JOSE experience I'm suggesting this WG consider is the relativ= e simplicity afforded by compact serializations and the widespread use they= have seen.
=C2=A0
Conceptualizing the compact serializations as arra= ys, you have this for signatures/macs:

=C2=A0=C2=A0= =C2=A0 [protected_header, payload, signature]

and this for enc= ryption:

=C2=A0=C2=A0=C2=A0 [protected_header, encrypted_key, i= nitialization_vector, ciphertext, authentication_tag]


There's just a single recipient or just one signature. There's onl= y one place for headers and they are always protected. It's a (relative= ly) simple and consistent processing model. The message can be processed or= not. There's real value in the simplicity.



=

O= n Thu, Jul 2, 2015 at 1:36 AM, Carsten Bormann <cabo@tzi.org> wro= te:
I'm not sure the JOSE experience = translates to COSE.

In JOSE, there are two different forms, one array-based (a dot-joined
sequence of base64 encodings of the array elements) and one map-based.
COSE doesn't need that choice.

All I can read from the JOSE experience cited here is a strong indicator that we want to go for arrays, not maps, at least for the outer structure.<= br>
Now whether that is shaped*)

[pr, un, ciph, [r1, r2]]

or

[pr, un, ciph, r1]

or

[pr, un, ciph, *r1]

(where *r1 means tha the contents of r1 is expanded right in place)

becomes less of a complexity argument:
[pr, un, ciph, [r1]]
really isn't that much more complex than
[pr, un, ciph, r1]
except for that one 0x81 byte wasted; in a pinch, we can also go for

[pr, un, ciph, r1, r2]
(which is another way of saying:
[pr, un, ciph, *[r1, r2]]
)

Making the array variable size disables JOSE's hack of using the array<= br> size for distinguishing JWE from JWS.=C2=A0 But we don't need that; CBO= R has
tags.

Gr=C3=BC=C3=9Fe, Carsten

*) I'm leaving msg_type out here, see other thread.

--001a113f77766245c40519e79263-- From nobody Thu Jul 2 10:32: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 9A2701A038A for ; Thu, 2 Jul 2015 10:32:25 -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 92wGPiyktExb for ; Thu, 2 Jul 2015 10:32:24 -0700 (PDT) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (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 D60261A0378 for ; Thu, 2 Jul 2015 10:32:23 -0700 (PDT) Received: by igcsj18 with SMTP id sj18so167943749igc.1 for ; Thu, 02 Jul 2015 10:32:23 -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:from:date:message-id:subject:to:cc :content-type; bh=ffwlzgKkj2pBGWHt90sSITrDzaKdwUa3dogiu+0hxOc=; b=TYRCn+SeYcNS+L4IxIsDs+/a/4Plt4gqhF6ZLmt+tP0LHOTRG3C2QgnrQnYIUTs5I0 rQ+3Bz0meOHR251ybwEH/3txM3ejPYWvs124doRFM7SstdILhgW+C9CU6yYHXHnDj1n1 En7lcgyG79tyxhUuZdl/FYX8n+u5gXknnkbiQ9hrAtOeAcriIfCwJ6r+5D8LSzFUJCNB qBhRJeY4lPbgrzQA7XEg+/t0rP9iCaCBeWFyjZw501tULxaWd3E6R7HWdMJl34GEoHxl dsy4R1gd1Z7GxzlikZJ+LALrBgcJcYgj4/uQiZCVU9+Nm7BdaIew834iguMVFoJtatxs Nhqw== X-Gm-Message-State: ALoCoQktvWJ/v2XrEGGyaxnZgKI7Lwry0upevwwijHIN6U8iw85pX/tUtjQFzC1TBtRcUQ6baWsC X-Received: by 10.42.255.200 with SMTP id nj8mr13484940icb.18.1435858342841; Thu, 02 Jul 2015 10:32:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.64.209 with HTTP; Thu, 2 Jul 2015 10:31:53 -0700 (PDT) From: Brian Campbell Date: Thu, 2 Jul 2015 11:31:53 -0600 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=bcaec50fe70b792b730519e7d20a Archived-At: Cc: Mike Jones , cose@ietf.org Subject: [Cose] Key management for MACs (was Re: 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: Thu, 02 Jul 2015 17:32:25 -0000 --bcaec50fe70b792b730519e7d20a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable What value does key management on the MAC authentication key really provide? I'm struggling to see it. What I do see is that it will make messages larger and add complexity. And it seems very likely to be a source of confusion that results in security problems around when integrity only is provided vs. integrity and sender authentication. The latter being what most will expect a MAC provides while the former isn't very useful but potentially very problematic. FWIW, I asked same(ish) question on the JOSE list yesterday in regard to an individual draft about key managed MAC keys in JOSE. On Sat, Jun 27, 2015 at 9: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 [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=E2=80=99m 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 =E2=80=93 not even =E2=80=9Cdir=E2=80=9D (direct). I suspect= that this can be cleanly done by omitting the key management layer entirely when it=E2=80=99= s not used, rather than explicitly using =E2=80=9Cdir=E2=80=9D (direct). [JLS] See above. --bcaec50fe70b792b730519e7d20a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What value does key management on the MAC authenticat= ion key really provide? I'm struggling to see it. What I do see is that= it will make messages larger and add complexity. And it seems very likely = to be a source of confusion that results in security problems around when i= ntegrity only is provided vs. integrity and sender authentication. The latt= er being what most will expect a MAC provides while the former isn't ve= ry useful but potentially very problematic.

FWIW, I aske= d same(ish) question on the JOSE list yesterday in regard to an individ= ual draft about key managed MAC keys in JOSE.


=



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

=C2=A0

=C2=A0

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

=C2=A0

=C2=A0

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

=C2=A0

2.=C2=A0 HMACs should be optimized for the no-key-man= agement case.

=C2=A0

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

=C2=A0

I=E2=80=99m 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=20 representation.=C2=A0 The only algorithm represented by default should be t= he MAC algorithm =E2=80=93 not even =E2=80=9Cdir=E2=80=9D (direct).=C2=A0 I s= uspect that this can be=20 cleanly done by omitting the key management layer entirely when it=E2=80=99= s not used, rather than explicitly using =E2=80=9Cdir=E2=80=9D (direct).

=C2=A0

[JLS] See above.

=C2=A0

--bcaec50fe70b792b730519e7d20a-- From nobody Thu Jul 2 10:45:38 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 04C641A0382 for ; Thu, 2 Jul 2015 10:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 aH3DDcVqDTek for ; Thu, 2 Jul 2015 10:45:35 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DA861A0302 for ; Thu, 2 Jul 2015 10:45:35 -0700 (PDT) Received: from [192.168.131.140] ([195.149.223.251]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MZgdm-1ZTtau2hB8-00LW92; Thu, 02 Jul 2015 19:45:30 +0200 Message-ID: <559576A9.9090002@gmx.net> Date: Thu, 02 Jul 2015 19:36:41 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Brian Campbell , Jim Schaad References: In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XFjsARA4WxR8H4Xi4Kiil5A2B6mHQMVQC" X-Provags-ID: V03:K0:iOc15KtLGq3z+9/KS6qoNDg9dCBUMlSLBRe+RpI4eXdu5n8/kb5 ThbokpRRkzhr+kvX8QWdeSzR3sSfTqETBWqQdq51HbfayzqoHoh/w/eHuWRGXuXHkR61sCX JByWvHojPvV3EypCgk3ZAIWCu55bvGgR8lkildqt13C4c9fL3F5uUozifU4vn3Ua1Y8VFb3 JPJFtqN0LlrW2EXu+0DZA== X-UI-Out-Filterresults: notjunk:1;V01:K0:9N57rFrv7JU=:iPkjK5AYXLEwsrXuSZ5RiH L0124NAQ+H3sP9U3fXj+3lNrjofoXoQwPns7GsgNyzkm+HcROrQCpUZySvrCi4nptX0E84yEp jtXTN1F56kUz8Ger1lE5bQxa8vRT8Xa4T4sDkMJaXYkK3ZmBdNRfowZmiFHnSggCd/MJGd25o cdTSOOXGImK8zFJD00MdMRDf+AVHQQt4DIobgvacTxzEFYR1lollzWssczxgssw1SMnPrBv3A mBOnjW7xIcf25aSOB6WtBTF7DMn6Jhr0Xr/6nGyw5CbjlA3ZH3qo0S9kKm62l8kilgNE/Zgi8 WBRKQ27lKNM1ex2SQ7c3tEqedcnO5dJixTBIw3+Cb4YYhYUn4mIH5BlwT0U9dLXf7HH0c7fXr cnMbgzBPrfRCOtoeuSjxKdxVtrOZ141sfQDSBgtwP39/R/22hiU9667QMDupV4O7/nKUBNc7q EvN090bO2jTJQpPKIhYNZhrXGF+I6ooXwOfl/q6Id7qc8TFiJ0n23MOPsprmz12S1Bb3kIXnu Oi4Oq2TqNO3Z94kcH7HvfAf0iiKOCVrDSjqxV1Xg1vbnU+Nx7oAMZeED1+n2wuQCO2D7YCCh+ iXkjxSOwktZzLAudxl5PnF2+2pgaI2x9Ng0COgTAr2CbzqpGXSxin9r6TD/0oxrSR4U5E4/J+ K5XsgwEHj7JbjPELEjBfEeC1P2OshqvNag4vTh4IAAgX6PA== Archived-At: Cc: Mike Jones , cose@ietf.org Subject: Re: [Cose] Key management for MACs (was Re: 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: Thu, 02 Jul 2015 17:45:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XFjsARA4WxR8H4Xi4Kiil5A2B6mHQMVQC Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > 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. It would be good to know what devices you have in mind in this discussion= =2E I personally don't think we should target devices that cannot even do key management for symmetric cryptography. I would even argue that we should aim for devices that support a random number generator and are also able to do public key crypto. We are not doing ourselves a flavor if we place artificial constraints on our protocols that make them pretty insecure in practice. We already have enough insecure IoT devices in the market. Here is the slide deck I presented in the LWIG group at the last IETF meeting; it explains the performance of state-of-the-art crypto on common Cortex M class MCUs. https://www.ietf.org/proceedings/92/slides/slides-92-lwig-3.pdf Ciao Hannes --XFjsARA4WxR8H4Xi4Kiil5A2B6mHQMVQC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVlXapAAoJEGhJURNOOiAtAVsH/RYtJ6dUdT81j6F4J4fqb4yy 6VUujIwFmBaf2q8du1tDLfGSyXgPnDnidN9IJNGsDW9bACh3P+8CGqcy/uBqd9Tj sgWROYJjp2B2+vq74E4YMZsvz4it5hMPraGwFXkc4NMVGx89MCh7VkU6/vwMd/hd u/IESBqk/mr1DZXW2cTYzfPTBqAhWyQc252Gr9NTZAsNS2QeF8F4JRNhfrE1RXc3 i6eZGFI/MojQ2zWtZWgnx4Y+k9EJ7ENC9hZenVVOzwiqkt36vUxwjRuF9EUlhkWl u5GFL2BHNvBd77gScnrhN1uTLzM9hbSIB9KDAjWqeH1Oe4L0nlMcNqbTT2mBSd0= =rEey -----END PGP SIGNATURE----- --XFjsARA4WxR8H4Xi4Kiil5A2B6mHQMVQC-- From nobody Thu Jul 2 10:52: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 7A86E1A1B4A for ; Thu, 2 Jul 2015 10:52:53 -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 ZdMYg1S9OJnA for ; Thu, 2 Jul 2015 10:52:51 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0703.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:703]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0563D1A1B48 for ; Thu, 2 Jul 2015 10:52:50 -0700 (PDT) Received: from BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) by BY2PR03MB255.namprd03.prod.outlook.com (10.242.37.22) with Microsoft SMTP Server (TLS) id 15.1.207.12; Thu, 2 Jul 2015 17:52:45 +0000 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.201.16; Thu, 2 Jul 2015 17:52:39 +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; Thu, 2 Jul 2015 17:52:39 +0000 From: Mike Jones To: Hannes Tschofenig , Brian Campbell , Jim Schaad Thread-Topic: [Cose] Key management for MACs (was Re: Review of draft-schaad-cose-msg-01) Thread-Index: AQHQtO7otSq2x1sR40SvzKRDC45tbp3IdCkg Date: Thu, 2 Jul 2015 17:52:39 +0000 Message-ID: References: <559576A9.9090002@gmx.net> In-Reply-To: <559576A9.9090002@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmx.net; dkim=none (message not signed) header.d=none; x-originating-ip: [50.47.90.173] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:sOFJOBkyj1nnFxQGDZ2jrhEbjIkVN/hVg174++PtowjsQtcrXcNmKk8C1H+BNLUh2ewj9wiRIgKi57UQYNnU4YdTb+QN3LOQRn40VDUxHk2AJlvBhuL/k0RuSzt7KZJ1NRgJ4iVlPa4NesC2wAdTog==; 24:Y0Cbgw1OR724Ro2W2NEoh7jPa6zRKUg2YAkQN5qqWlWZj4szqz9B8C6yb46oQo4RAlMzFXVAqWFln3cm1JGo7L/MfDbwjovgpf2t2V3uo7s=; 20:rDnrNRjBU3IYcm6B6EiLq5oi+RQTnaWSoMXJZ1/AdgWJ67JYhIjST5i3ElQIVQHbvVdP0eL+UVx18tNkQL9k7A== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB255; 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: 06259BA5A2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(74316001)(66066001)(86362001)(87936001)(189998001)(2656002)(2950100001)(19580395003)(92566002)(2900100001)(19580405001)(5001960100002)(15975445007)(102836002)(77096005)(5002640100001)(106116001)(230783001)(86612001)(46102003)(99286002)(5003600100002)(50986999)(62966003)(77156002)(5001770100001)(40100003)(122556002)(76176999)(54356999)(33656002)(76576001); 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jul 2015 17:52:39.6087 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 X-Microsoft-Exchange-Diagnostics: 1; BY2PR03MB255; 2:jm5i+aT23MabP3hRDAg0lpuGZMnPzUSbISgoYtgtcUo9brJXuaM6y801lL68Yvmy; 3:mPZOaPnU+JUP/Khj5RDhag8Z4lp2H4Eluv9gHrkgNZ8wuJ5r2dkarptDAkRB7YnHF6K0Y0J8vKQRorXpzl3fm4HLKJXYNbu5759q/+UDgyFpAH5kZD4ZBsxsDqs5qCbIjengd9/K/WShflPXhvg+Vw==; 25:bFIE05McWVIurpeRyQ/kfPrrmklAG3fCCo2CXlSAIsd7cguUFdGFMpZUj0BJ1C519A6hz0msP//D3suso7pY3lETQGX+GDYlLWKLXUjETRrI787QKc238VG/a/LhfGdofm2wKTa4LIMivRk8PY8hRvsMLAJddZqnXEuOIMLabUHhvErleJgheEZNcsLe2UheEtUWidZmgfeucI1UcHqMAVPxCegZ6OPdxCD5YEdWLgp2tyOsYcwaNysicxXJqG7HFopk4qxMJ+WuCN0vlLnoeQ==; 23:4lYj4lvCZOoAo4CrDxdm9RsVWUcJT5IMQFOttgZ0blKXM65fFv3ORqIwyjiPv1ITM66YE/yuk4a6Y4ltkRwa1686nH1lsmos0jIiUyG0aqFj9pIViQCF99sOflimYJxDu9OqIKPyyZW5gdW9vx+iHg9DwpcT77RC4rvP7yCi/luRLbcUtNapuUPmOdYhQfaCkbmNZ9WcKioSCEMHMo7ElR3Si8ReL/Lt3SD9jp1qyK2qDtb9qRl7rh//IsFQECFr X-OriginatorOrg: microsoft.com Archived-At: Cc: "cose@ietf.org" Subject: Re: [Cose] Key management for MACs (was Re: 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: Thu, 02 Jul 2015 17:52:53 -0000 If MACs without key management were insecure, I'm sure that JWS [RFC 7515] = wouldn't have survived the SecDir review or the IESG review since it has no= key management for MACs, but it did. The question is what *additional* value key management adds in the MAC case= . (I completely understand the value of key management in the encryption case= . If you're using a deterministic content encryption algorithm and you're = encrypting the same plaintext with the same key without key management, the= ciphertext values will match, allowing attackers to correlate messages. U= sing a randomly generated content encryption key means that encryptions of = the same plaintext result in different ciphertext values - preventing this = correlation. But the payload in a MAC is not a secret, so there's no equiv= alent benefit in the MAC case.) -- Mike -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Thursday, July 02, 2015 10:37 AM To: Brian Campbell; Jim Schaad Cc: Mike Jones; cose@ietf.org Subject: Re: [Cose] Key management for MACs (was Re: Review of draft-schaad= -cose-msg-01) > Particularly for constrained devices, it is unlikely that applications=20 > will want to pay the performance penalty of generating and encrypting=20 > a key management key to perform a MAC operation. Heck, they may not=20 > have credible random number generation in the first place! And they=20 > are likewise unlikely to want to pay the message size penalty of=20 > carrying the encrypted key. It would be good to know what devices you have in mind in this discussion. I personally don't think we should target devices that cannot even do key m= anagement for symmetric cryptography. I would even argue that we should aim= for devices that support a random number generator and are also able to do= public key crypto. We are not doing ourselves a flavor if we place artificial constraints on o= ur protocols that make them pretty insecure in practice. We already have en= ough insecure IoT devices in the market. Here is the slide deck I presented in the LWIG group at the last IETF meeti= ng; it explains the performance of state-of-the-art crypto on common Cortex= M class MCUs. https://www.ietf.org/proceedings/92/slides/slides-92-lwig-3.pdf Ciao Hannes From nobody Thu Jul 2 10:57: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 622051A1B5D for ; Thu, 2 Jul 2015 10:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 8KdJBLUIq6bu for ; Thu, 2 Jul 2015 10:57:18 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 969D41A1B88 for ; Thu, 2 Jul 2015 10:57:08 -0700 (PDT) Received: from [192.168.131.140] ([195.149.223.251]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LwaQZ-1YyuEm1u8t-018IIT; Thu, 02 Jul 2015 19:56:59 +0200 Message-ID: <5595794D.3000005@gmx.net> Date: Thu, 02 Jul 2015 19:47:57 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mike Jones , Brian Campbell , Jim Schaad References: <559576A9.9090002@gmx.net> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JNaShuHrOXjhHnkX0hRQGSROgCLvIkU5k" X-Provags-ID: V03:K0:+AHOCdeudVH3sNhJoeBJJ9KzT0E1LQp+mJw9d7d6bg30iv4NSyB DSqOvYx4mFW2v55UVysd6ekd4jSa+VpePO9tOcBocj4BdEkYpu/Gqk9RM8feevQ0DTCZ0v0 ulJwy2Twd2zQDZ9whCXffgtSGFwv5pgBaStBUipx080juh+z99I/0TARDrwEJ4r3Up8DeYV ZgfV2+fWKrYrOD7QN+Oow== X-UI-Out-Filterresults: notjunk:1;V01:K0:9kIqPA+TWWk=:TYmm59dj0irASIzeUrKKPk yDILqwQXbuI3iCnsfsIZur7UQQWxJJaaez0hRTZycc/O2RK05ndJqj3AORVArE4OYK6zzUY05 ECR+P9ppgjwBaaUin/AcngNWcmTu9g1a5G7ruAXSxmbKq8xbgZSaWTqtEbOm7EpCmVVbWz+/J Kv/LbkEXLmNXIMOURuoNLlGDfCENmMwyVcWSEaN8UpozdKUXTy6nhTTxvHD4GFOD6mOIMcEDh JhjhFxHFxag2lCbd6uC82Xfi2GAdw0fL4acDY7IQAsdT3z2XmJim6wfK3L+7EyW6OuTpcVGsM t/x716uwxTuRhcmya2Urk/hGzo3b0n7y+BuWjyhteAqaVv5wXxUNTv04fYj38MQkfLcvjbDy9 qd0li2d2LNI99t2ujpdNTo5mXDQZQ5KGVa+nnUTFpDKNc6RwGCHokkC22UVlU7/boUbrRzOmP 6syONr57S9hjqSvoSE6hnvgtwzD0O+sl9OVBxjLSqAAZq9ww9up7CrVkwcmuSfB3J58DNDAc/ bmVpbHtd4n65CBhFKqdfYXjIP18q/95qe/8p0xgnjixz91A6WgNf5rvFCLThE6MYSG0P/VjnK bZjLu3tVzvy+NzUlg2rRIBrGjUQL+iMfJ40Onlwiec4uWeGVzbbGp5msaMMNT6a9LijaQLevC PxByhm8ieAHdy3hCfyMhsVPk6Yph8Aj4xaf4DsPndzO3+hQ== Archived-At: Cc: "cose@ietf.org" Subject: Re: [Cose] Key management for MACs (was Re: 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: Thu, 02 Jul 2015 17:57:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JNaShuHrOXjhHnkX0hRQGSROgCLvIkU5k Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I guess the challenge with the JOSE and the COSE work is that it is a generic mechanism and you don't really know what applications are going to use them. As such it is hard to say how the key management would actually look like. Hence, it is a bit challenging to say what IoT can and cannot do. One consumer of the JOSE/JWS work was OAuth and there it is quite clear how the story looks like. In any case, whenever I read something about IoT devices I am always wondering about what devices they are talking about. Ciao Hannes On 07/02/2015 07:52 PM, Mike Jones wrote: > If MACs without key management were insecure, I'm sure that JWS [RFC 75= 15] wouldn't have survived the SecDir review or the IESG review since it = has no key management for MACs, but it did. >=20 > The question is what *additional* value key management adds in the MAC = case. >=20 > (I completely understand the value of key management in the encryption = case. If you're using a deterministic content encryption algorithm and y= ou're encrypting the same plaintext with the same key without key managem= ent, the ciphertext values will match, allowing attackers to correlate me= ssages. Using a randomly generated content encryption key means that enc= ryptions of the same plaintext result in different ciphertext values - pr= eventing this correlation. But the payload in a MAC is not a secret, so = there's no equivalent benefit in the MAC case.) >=20 > -- Mike >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 > Sent: Thursday, July 02, 2015 10:37 AM > To: Brian Campbell; Jim Schaad > Cc: Mike Jones; cose@ietf.org > Subject: Re: [Cose] Key management for MACs (was Re: Review of draft-sc= haad-cose-msg-01) >=20 >=20 >=20 >> Particularly for constrained devices, it is unlikely that applications= =20 >> will want to pay the performance penalty of generating and encrypting = >> a key management key to perform a MAC operation. Heck, they may not=20 >> have credible random number generation in the first place! And they=20 >> are likewise unlikely to want to pay the message size penalty of=20 >> carrying the encrypted key. >=20 > It would be good to know what devices you have in mind in this discussi= on. >=20 > I personally don't think we should target devices that cannot even do k= ey management for symmetric cryptography. I would even argue that we shou= ld aim for devices that support a random number generator and are also ab= le to do public key crypto. >=20 > We are not doing ourselves a flavor if we place artificial constraints = on our protocols that make them pretty insecure in practice. We already h= ave enough insecure IoT devices in the market. >=20 > Here is the slide deck I presented in the LWIG group at the last IETF m= eeting; it explains the performance of state-of-the-art crypto on common = Cortex M class MCUs. > https://www.ietf.org/proceedings/92/slides/slides-92-lwig-3.pdf >=20 > Ciao > Hannes >=20 --JNaShuHrOXjhHnkX0hRQGSROgCLvIkU5k Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVlXlNAAoJEGhJURNOOiAtc1oH/R9cbZpPa/Em+AhFPpJorfs2 PbV3hAoRGbEmwBLiloP/kWZGD5+P+kVZ/mKGXy+35CvS593FiZQNMyeOC/OWSMeU HKAoSC+tXo8opawTG923c+SbIwDliJmatf+HTpoRDqeIDfI8rpYpwY9XvS7NZc7Q pf1hw9xB/VGgeEDcL+tP7MChXAmOC6uIworCCosOe1fzwWllN56lXeOApisR3kx1 iG0/gsw2OrcVv6C4FFshYgsbpYQj7ln+Gr5cRN2n1L5TYM9OuHtC3ePqSs9Xniab VD3bBW5XeNRKekNQiOFUeI3oL5D05VDoZVop+VITfDDX1uTtl4NOfLuswaJCvIc= =7cxC -----END PGP SIGNATURE----- --JNaShuHrOXjhHnkX0hRQGSROgCLvIkU5k-- From nobody Thu Jul 2 21:16: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 3CD4C1B2B48; Thu, 2 Jul 2015 21:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 ni73F5PN08Gl; Thu, 2 Jul 2015 21:16:32 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84E801B2B40; Thu, 2 Jul 2015 21:16:31 -0700 (PDT) X-AuditID: c1b4fb2d-f79176d00000321c-18-55960c9d30af Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 29.33.12828.D9C06955; Fri, 3 Jul 2015 06:16:29 +0200 (CEST) Received: from ESESSMB303.ericsson.se ([169.254.3.19]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0210.002; Fri, 3 Jul 2015 06:16:29 +0200 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "core@ietf.org" , "cose@ietf.org" Thread-Topic: Object Secure CoAP update with COSE size estimates Thread-Index: AQHQtUcIFG/adJKjrk6N8Kdfvk5gYg== Date: Fri, 3 Jul 2015 04:16:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM+Jvje5cnmmhBg239Cz2vV3PbDFt61RW ByaPJUt+MgUwRnHZpKTmZJalFunbJXBl9MzYw14wQbjiz/6HjA2MF4S6GDk5JARMJP6+OMwO YYtJXLi3nq2LkYtDSOAoo8Tj6W9YQRJCAosYJQ58LQex2QRcJB40PGICsUWA7I19M8GahQWs Jc40rQCyOYDiDhKn9ulBlOhJrD9zCaycRUBFov3nTWYQm1fAQqJ78jewVkagvd9PrQGrYRYQ l7j1ZD4TxD0CEkv2nGeGsEUlXj7+B3aOKNDMldeb2CDiShJrD29nAVnLLKApsX6XPsQYa4lf 2z+xQNiKElO6H7JDrBWUODnzCcsERtFZSLbNQuiehaR7FpLuWUi6FzCyrmIULU4tLs5NNzLW Sy3KTC4uzs/Ty0st2cQIjJeDW37r7mBc/drxEKMAB6MSD++CN1NDhVgTy4orcw8xSnOwKInz zticFyokkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcUVHyXVfzZX31eXmlrudmTvPeoayuzdj v4+xc4iJqvem+90LpOoW7al9sMHL4vG8rrietb1nd8/lOm+65XuT6P8f5o/FvfSYp298uV2r +j5neN/6F5tvtbf7WbnULhBhjf3Pa+PtufDz548i/2auXfl0y+7Dq+/eehXA0ucQFhX7VC7B 8XiPjhJLcUaioRZzUXEiALM1s5J4AgAA Archived-At: Subject: [Cose] Object Secure CoAP update with COSE size estimates 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, 03 Jul 2015 04:16:34 -0000 DQpTb3JyeSBmb3IgY3Jvc3Nwb3N0aW5nLiBUaGUgdXBkYXRlIG9mIHRoaXMgZHJhZnQgd2FzIGFs cmVhZHkgYW5ub3VudWNlZCBvbg0KdGhlIEFDRSBsaXN0LCBidXQgaXMgYWxzbyByZWxldmFudCB0 byBDT1JFIGFuZCB0aGUgb25nb2luZyBkaXNjdXNzaW9uIGluDQpDT1NFIG9uIGVuY29kaW5nIGZv ciBzaW5nbGUgcmVjaXBpZW50cyBhbmQgbWVzc2FnZSBzaXplIGVzdGltYXRlcy4NCiANCg0KDQpo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1 cml0eS0wMg0KDQoNCk1haW4gY2hhbmdlcyBmcm9tIC0wMToNCg0KLSBTdXBwb3J0IGZvciBibG9j a3dpc2UgdHJhbnNmZXIgYW5kIGhvdyB0byBzdXBwb3J0IGFueSBDb0FQIG9wdGlvbg0KKEFwcGVu ZGl4IEEpDQotIENPU0UgcHJvZmlsZSAoQXBwZW5kaXggRCkNCi0gTWVzc2FnZSBzaXplIGNhbGN1 bGF0aW9ucyBvZiBNQUMsIEFFQUQsIHNpZ25hdHVyZSwgYW5kIHN5bW1ldHJpYw0KZW5jcnlwdGlv biArIHNpZ25hdHVyZSBmb3IgSk9TRSwgQ09TRSBhbmQgb3B0aW1pemF0aW9ucyAoQXBwZW5kaXgg RSkNCg0KDQoNCkfDtnJhbg0KDQoNCk9uIDIwMTUtMDYtMjkgMTU6NTgsICJpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmciIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQp3cm90ZToNCg0KPg0KPkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5LTAy LnR4dA0KPmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRnJhbmNlc2NhIFBhbG9t YmluaSBhbmQgcG9zdGVkIHRvIHRoZQ0KPklFVEYgcmVwb3NpdG9yeS4NCj4NCj5OYW1lOgkJZHJh ZnQtc2VsYW5kZXItYWNlLW9iamVjdC1zZWN1cml0eQ0KPlJldmlzaW9uOgkwMg0KPlRpdGxlOgkJ SnVuZSAyOSwgMjAxNQ0KPkRvY3VtZW50IGRhdGU6CTIwMTUtMDYtMjkNCj5Hcm91cDoJCUluZGl2 aWR1YWwgU3VibWlzc2lvbg0KPlBhZ2VzOgkJNDMNCj5VUkw6ICAgICAgICAgICAgDQo+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNlbGFuZGVyLWFjZS1vYmplY3Qt c2VjdXJpdHktMDINCj4udHh0DQo+U3RhdHVzOiAgICAgICAgIA0KPmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNlbGFuZGVyLWFjZS1vYmplY3Qtc2VjdXJpdHkvDQo+SHRt bGl6ZWQ6ICAgICAgIA0KPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zZWxhbmRl ci1hY2Utb2JqZWN0LXNlY3VyaXR5LTAyDQo+RGlmZjogICAgICAgICAgIA0KPmh0dHBzOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1zZWxhbmRlci1hY2Utb2JqZWN0LXNlY3VyaXR5 LTAyDQo+DQo+QWJzdHJhY3Q6DQo+ICAgVGhpcyBtZW1vIHByZXNlbnRzIE9TQ09BUCwgYSBzY2hl bWUgZm9yIHByb3RlY3Rpb24gb2YgcmVxdWVzdCBhbmQNCj4gICByZXNwb25zZSBtZXNzYWdlcyBv ZiB0aGUgQ29uc3RyYWluZWQgQXBwbGljYXRpb24gUHJvdG9jb2wgKENvQVApLA0KPiAgIHVzaW5n IGRhdGEgb2JqZWN0IHNlY3VyaXR5Lg0KPg0KPiAgICAgICAgICAgICAgICAgIA0KPiAgICAgICAg DQo+DQo+DQo+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2YNCj5zdWJtaXNzaW9uDQo+dW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4NCj5UaGUgSUVU RiBTZWNyZXRhcmlhdA0KPg0KDQo= From nobody Sun Jul 5 09:01: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 EDAC01AC400 for ; Sun, 5 Jul 2015 09:01:09 -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 wKd9HBIhKbst for ; Sun, 5 Jul 2015 09:01:08 -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 E63421AC3FB for ; Sun, 5 Jul 2015 09:01:07 -0700 (PDT) X-AuditID: 12074422-f79d26d0000026d6-f0-559954c24790 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-5.mit.edu (Symantec Messaging Gateway) with SMTP id E7.A4.09942.2C459955; Sun, 5 Jul 2015 12:01:06 -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 t65G15ET030774 for ; Sun, 5 Jul 2015 12:01:06 -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 t65G14ek025711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 5 Jul 2015 12:01:05 -0400 Message-ID: <559954BF.3020401@mit.edu> Date: Sun, 05 Jul 2015 12:01:03 -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+NgFjrJIsWRmVeSWpSXmKPExsUixCmqrXsoZGaowZrPahbTtk5ldWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRs/F4IJzPBVv/91naWD8x97FyMkhIWAiceX/ZTYIW0ziwr31 QDYXh5DAYiaJia3fWSCcI4wSWxu6GSGcd0wSm7acZQJp4RVQkzj8qQGsnUVAVeLyvzNgcTYg e/qaFjBbVCBKYurjdSwQ9YISJ2c+AbI5OESA7Lud5iBhYQF1iWd/T4KVMwuYSczb/JAZwpaX 2P52DvMERr5ZSLpnISmbhaRsASPzKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1TvdzMEr3UlNJN jKAQY3dR2sH486DSIUYBDkYlHt6G4hmhQqyJZcWVuYcYJTmYlER5c7uBQnxJ+SmVGYnFGfFF pTmpxYcYJTiYlUR4VYJnhgrxpiRWVqUW5cOkpDlYlMR5N/3gCxESSE8sSc1OTS1ILYLJynBw KEnwfgVpFCxKTU+tSMvMKUFIM3FwggznARr+G2x4cUFibnFmOkT+FKOilDhvFkhCACSRUZoH 1wtLAa8YxYFeEebdBVLFA0wfcN2vgAYzAQ0WMZ0GMrgkESEl1cAYfMZ/57a5AtOuV6cJcG7b KJuwRWjzZ9+9Ap36pb/UPhjlC+zekMc+377wMiPD93Wnngkxr7jD0Bx/febkHRoROvrT1Rmb /N987mtpuHm7e87qJTs+z7xjHObzNNDb6lPttGXc7rdaxGQKvtconDg6+9jm6Fd2SsVXEu4F 1yrn+jWlxu24NHWtEktxRqKhFnNRcSIAIj00mdwCAAA= Archived-At: Subject: [Cose] New WG Document: COSE Messages 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, 05 Jul 2015 16:01:10 -0000 Hi All, After several weeks of review and commentary, we have found consensus to adopt draft-schaad-cose-msg as the first working group draft. There was overwhelming support and no voiced dissent. A few comments were made that this is not the final desired state of the protocol for many, and this is to be expected at this stage. The new WG document is now published at: https://tools.ietf.org/html/draft-ietf-cose-msg-00 This is a direct import of Jim Schaad's previous I-D with no textual changes. We'll be talking about this draft and where it needs to go next as one of our main topics in Prague. Sincerely, your COSE chairs, -- Justin and Kepeng .-""-._ / ___/ \ _&_ _.--""|/ `\| // \\ .' ( ^/ ^ )'. / / \ \ / | _ | \ // / \ \\ | _\____/ | /_/_/_\_\_\ | .' \____/-._ | .-"-. | / `; /# \ | / / _|_.---\ | | |.-.; :--.-(_/.____/.-""\___/"-. / \ / ~~/ /\ \{"=.______.="} /--. ; /___/_~~/ ; .--\"=...__...="} / \-/ `\______|/ \-.______..-; | /`| | \ | |||| || | /_ | |_______/ | |||| || | \_/| |-------' |--'||'--._|| | | | | || |> |______| |____________|._ || _..-;| | [___] | `||() || |______ |\/|____________|jgs|| () (__) \__/ (__) () ^-- Graphic by Joan G. Stark, from: http://www.chris.com/ascii/index.php?art=objects/furniture/chairs From nobody Sun Jul 5 16:59: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 C8A911AD481 for ; Sun, 5 Jul 2015 16:59:42 -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 vi5k4tnmZ6WA for ; Sun, 5 Jul 2015 16:59:41 -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 152DC1AD37B for ; Sun, 5 Jul 2015 16:59:40 -0700 (PDT) Received: from hebrews (174-21-18-91.tukw.qwest.net [174.21.18.91]) (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 4B91E38EF1 for ; Sun, 5 Jul 2015 16:59:40 -0700 (PDT) From: "Jim Schaad" To: References: <20150705214333.29943.52631.idtracker@ietfa.amsl.com> In-Reply-To: <20150705214333.29943.52631.idtracker@ietfa.amsl.com> Date: Sun, 5 Jul 2015 16:59:56 -0700 Message-ID: <000101d0b77e$b27097b0$1751c710$@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: AQJDbaZTbeGiPi1dj2qYktyyIERFk5zoHvCw Content-Language: en-us Archived-At: Subject: [Cose] FW: New Version Notification for draft-ietf-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: Sun, 05 Jul 2015 23:59:42 -0000 This new version announcement does not seem to have gone to the COSE = mailing list. This version picks up changes I have made from the posting of the last = version until this version with the exception of adding in the strawman = that I put in for all of the algorithms. The strawman with algorithms = is posted on the github repository https://cose-wg.github.io/cose-spec/. I have also added a pointer in the readme at the github site that will = do a rfcdiff between the current draft posted on the IETF site and the = current editor's working draft. This can be used to look at the = strawman changes for algorithms. (I forgot to remove the algorithm = update from the list of changes In the posted draft.) It will need to be a working group decision if the algorithms are going = to be in a separate document or in this document. I expect that to be = discussed on the list and in Prague. I will be reviewing the open issues list over the next two weeks to see = what I think has been addressed and start raising issues on the mailing = list again. I have been spending much of the time working on the = changes to get integers used as map labels. It is time for people to = look at the resulting document and either make suggestions or approvals = on how it was done. I expect that I still have a couple of rounds of = edits to get things to match my expectations, but it should be close to = what I believe needed to be done. Jim > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Sunday, July 05, 2015 2:44 PM > To: Jim Schaad; Jim Schaad > Subject: New Version Notification for draft-ietf-cose-msg-01.txt >=20 >=20 > A new version of I-D, draft-ietf-cose-msg-01.txt has been successfully > submitted by Jim Schaad and posted to the IETF repository. >=20 > Name: draft-ietf-cose-msg > Revision: 01 > Title: CBOR Encoded Message Syntax > Document date: 2015-07-05 > Group: cose > Pages: 46 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-cose-msg-01.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ > Htmlized: https://tools.ietf.org/html/draft-ietf-cose-msg-01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-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 Sun Jul 5 17:51: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 CCE281A92AD; Sun, 5 Jul 2015 08:47:15 -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] 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 2fl5HCgWvroz; Sun, 5 Jul 2015 08:47:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C54D91A914A; Sun, 5 Jul 2015 08:47:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150705154714.17033.27978.idtracker@ietfa.amsl.com> Date: Sun, 05 Jul 2015 08:47:14 -0700 Archived-At: X-Mailman-Approved-At: Sun, 05 Jul 2015 17:51:49 -0700 Cc: cose@ietf.org Subject: [Cose] I-D Action: draft-ietf-cose-msg-00.txt 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: Sun, 05 Jul 2015 15:47:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CBOR Object Signing and Encryption Working Group of the IETF. Title : CBOR Encoded Message Syntax Author : Jim Schaad Filename : draft-ietf-cose-msg-00.txt Pages : 48 Date : 2015-07-05 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cose-msg-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 5 17:51: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 5B6B81A1A43; Sun, 5 Jul 2015 14:43:34 -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] 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 gazlDzIlcPp7; Sun, 5 Jul 2015 14:43:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 35AF81A001B; Sun, 5 Jul 2015 14:43:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150705214333.29943.18571.idtracker@ietfa.amsl.com> Date: Sun, 05 Jul 2015 14:43:33 -0700 Archived-At: X-Mailman-Approved-At: Sun, 05 Jul 2015 17:51:49 -0700 Cc: cose@ietf.org Subject: [Cose] I-D Action: draft-ietf-cose-msg-01.txt 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: Sun, 05 Jul 2015 21:43:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CBOR Object Signing and Encryption Working Group of the IETF. Title : CBOR Encoded Message Syntax Author : Jim Schaad Filename : draft-ietf-cose-msg-01.txt Pages : 46 Date : 2015-07-05 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cose-msg-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 20:22:06 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 926D61A8927 for ; Mon, 6 Jul 2015 20:22:05 -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 NylG5kYm8FrK for ; Mon, 6 Jul 2015 20:22:04 -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 B2B731A8925 for ; Mon, 6 Jul 2015 20:22:04 -0700 (PDT) Received: from hebrews (174-21-18-91.tukw.qwest.net [174.21.18.91]) (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 9A5032CA12; Mon, 6 Jul 2015 20:22:01 -0700 (PDT) From: "Jim Schaad" To: "'Martin Thomson'" References: <002f01d0b388$57a1cc90$06e565b0$@augustcellars.com> In-Reply-To: Date: Mon, 6 Jul 2015 20:22:17 -0700 Message-ID: <00b401d0b864$21aeab40$650c01c0$@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: AQLtvlvpg3Q4ySKwkVlgbTj6EJO43gKMV/Dym4DomjA= Content-Language: en-us Archived-At: Cc: 'cose WG' 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, 07 Jul 2015 03:22:05 -0000 > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Wednesday, July 01, 2015 11:38 AM > To: Jim Schaad > Cc: cose WG > Subject: Re: [Cose] AES based MAC algorithm >=20 > On 30 June 2015 at 15:58, Jim Schaad wrote: > > Do people have a preference as to which of these two algorithms is > > specified? >=20 > Objection: leading the witness. I thought that neither would be a = good > choice. AEAD encompasses a MAC (neither of these), and the hashes = that > we have defined seem sufficient. AES-CCM uses AES-MAC (not CMAC) for the purpose of computing the MAC = value portion. Jim >=20 > This seems wholly speculative. From nobody Mon Jul 6 20:51: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 35DC81A8973 for ; Mon, 6 Jul 2015 20:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=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 0zzxArAzYPrJ for ; Mon, 6 Jul 2015 20:51:52 -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 B8F2D1A8977 for ; Mon, 6 Jul 2015 20:49:47 -0700 (PDT) Received: from hebrews (174-21-18-91.tukw.qwest.net [174.21.18.91]) (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 AF7D32C9BB; Mon, 6 Jul 2015 20:49:46 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , References: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> <009501d0b392$fb7cc680$f2765380$@augustcellars.com> In-Reply-To: Date: Mon, 6 Jul 2015 20:50:02 -0700 Message-ID: <000001d0b868$022feff0$068fcfd0$@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: AQJBW2regVOc1KgJrCGEY9SFfcIRjgIjyzTpArNKyUYA0EcPdZzA1vhg 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: Tue, 07 Jul 2015 03:51:55 -0000 > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Tuesday, June 30, 2015 5:46 PM > To: Jim Schaad; cose@ietf.org > Subject: RE: [Cose] Issue: Encoding for a single recipient or structure > > 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. The difference code size is harder to specify, since I switched from using arrays to maps at the same time. However the code fragment that deals with all of the above cases (in the decode case) is // Recipients if (obj[index + 4].IsNull && (size == 5)) ; // No Recipient structures - this is just fine else if (obj[index + 4].Type == CBORType.Array) { // An array of recipients to be processed for (int i = 0; i < obj[index + 4].Count; i++) { Recipient recip = new Recipient(); recip.DecodeFromCBORObject(obj[index + 4][i], 0, obj[index + 4][i].Count); recipientList.Add(recip); } } else { // We are going to assume that this is a single recipient Recipient recip = new Recipient(); recip.DecodeFromCBORObject(obj, index + 4, size - 4); recipientList.Add(recip); } Note that this code only deals with two cases - the rolled out case and the array case. > > 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 was raised because the people Richard was working with had a different paradigm that most of us had when looking at how to process the message. Personally I found this to be a huge complication in my code base to deal with. I would note that how they dealt with multiple recipients was to copy things from the recipient to the base and treated it as a single recipient case. I think that this both made things more complicated and harder to deal with that necessary. Since all I cared about was a multiple case, I did an implantation that used multiple promises to deal with all of the possible recipients at one time. In doing so I found that I really wanted a first success promise which does not exist. > > 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 From nobody Tue Jul 7 02:35:38 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 C703B1A874F for ; Tue, 7 Jul 2015 02:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=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 ZXuf49OVONUh for ; Tue, 7 Jul 2015 02:35:35 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::6]) (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 B45021A8737 for ; Tue, 7 Jul 2015 02:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1436261732; l=3655; s=domk; d=sandeep.de; h=Content-Type:Cc:To:From:Subject:Date:References:In-Reply-To: MIME-Version; bh=DpWPk1D4RG0dg5/nmrEZqRWAKyKU4zvMX0xIeCuLXsI=; b=In3VPE7n6Vs9r2GrREB2XTZRnPOoaHYZTyJti7Rd5ckUsygLF1xR3x8kecxIHhPmcH5 x70Z+AS4rZiI61aK2ESImf//eLn/WbDyo+anM/qrdT1q2URWHt32p2d4XCByw8nYqZdfq TcEyM+bo1HMn8wW1ySbBR7mrasNVuSAWaO8= X-RZG-AUTH: :JWkQc2C7evFfytIRBe7p82UYMzBqkr+YiXEkMUacmkLgvZRJw7/TeQ== X-RZG-CLASS-ID: mo00 Received: from mail-wg0-f41.google.com ([74.125.82.41]) by smtp.strato.de (RZmta 37.8 AUTH) with ESMTPSA id R050a9r679ZUzCF (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verification FAILED - unable to get local issuer certificate)) (Client hostname not verified) for ; Tue, 7 Jul 2015 11:35:30 +0200 (CEST) Received: by wgbgr6 with SMTP id gr6so8541122wgb.3 for ; Tue, 07 Jul 2015 02:35:30 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.77.211 with SMTP id u19mr6208346wjw.19.1436261730114; Tue, 07 Jul 2015 02:35:30 -0700 (PDT) Received: by 10.27.185.6 with HTTP; Tue, 7 Jul 2015 02:35:30 -0700 (PDT) In-Reply-To: <00b401d0b864$21aeab40$650c01c0$@augustcellars.com> References: <002f01d0b388$57a1cc90$06e565b0$@augustcellars.com> <00b401d0b864$21aeab40$650c01c0$@augustcellars.com> Date: Tue, 7 Jul 2015 11:35:30 +0200 Message-ID: From: Sandeep Kumar To: Jim Schaad Content-Type: multipart/alternative; boundary=047d7bf0c5983a7302051a45be7f Archived-At: Cc: cose WG 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, 07 Jul 2015 09:35:36 -0000 --047d7bf0c5983a7302051a45be7f Content-Type: text/plain; charset=UTF-8 I support AES-CMAC as this is the preferred algorithm for MAC on systems we build. Would really like to see that gap filled in Cose, AES-CCM uses AES-MAC (aka AES-CBC-MAC) but the construction is secure only when used within AES-CCM. regards Sandeep Philips Lighting On Tue, Jul 7, 2015 at 5:22 AM, Jim Schaad wrote: > > > > -----Original Message----- > > From: Martin Thomson [mailto:martin.thomson@gmail.com] > > Sent: Wednesday, July 01, 2015 11:38 AM > > To: Jim Schaad > > Cc: cose WG > > Subject: Re: [Cose] AES based MAC algorithm > > > > On 30 June 2015 at 15:58, Jim Schaad wrote: > > > Do people have a preference as to which of these two algorithms is > > > specified? > > > > Objection: leading the witness. I thought that neither would be a good > > choice. AEAD encompasses a MAC (neither of these), and the hashes that > > we have defined seem sufficient. > > AES-CCM uses AES-MAC (not CMAC) for the purpose of computing the MAC value > portion. > > Jim > > > > > This seems wholly speculative. > > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose > --047d7bf0c5983a7302051a45be7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support AES-CMAC as this is the preferred= algorithm for MAC on systems we build. Would really like to see that gap f= illed in Cose,
AES-CCM uses AES-MAC (aka AES-CBC-MAC) but the constructi= on is secure only when used within AES-CCM.


regards
Sandeep

Philips Lighting

On Tue, Jul 7, 2015 at 5:22 AM= , Jim Schaad <ietf@augustcellars.com> wrote:


> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: Wednesday, July 01, 2015 11:38 AM
> To: Jim Schaad
> Cc: cose WG
> Subject: Re: [Cose] AES based MAC algorithm
>
> On 30 June 2015 at 15:58, Jim Schaad <ietf@augustcellars.com> wrote:<= br> > > Do people have a preference as to which of these two algorithms i= s
> > specified?
>
> Objection: leading the witness.=C2=A0 I thought that neither would be = a good
> choice.=C2=A0 AEAD encompasses a MAC (neither of these), and the hashe= s that
> we have defined seem sufficient.

AES-CCM uses AES-MAC (not CMAC) for the purpose of computing the MAC= value portion.

Jim

>
> This seems wholly speculative.

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

--047d7bf0c5983a7302051a45be7f-- From nobody Tue Jul 7 12:50: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 3F32B1A88D8 for ; Tue, 7 Jul 2015 12:50: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, 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 3QUFncdt3uQq for ; Tue, 7 Jul 2015 12:50:42 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0103.outbound.protection.outlook.com [207.46.100.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54FFC1A88B2 for ; Tue, 7 Jul 2015 12:50:42 -0700 (PDT) Received: from BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) by BY2PR03MB621.namprd03.prod.outlook.com (10.255.93.43) with Microsoft SMTP Server (TLS) id 15.1.207.19; Tue, 7 Jul 2015 19:50:40 +0000 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.213.10; Tue, 7 Jul 2015 19:50:32 +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.0213.000; Tue, 7 Jul 2015 19:50:32 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: [Cose] Review of draft-schaad-cose-msg-01 Thread-Index: AdCwuG36k7Yq5VJ4SCGK90wxv/T+IAANQXOAAKRsWeABW5wAUA== Date: Tue, 7 Jul 2015 19:50:32 +0000 Message-ID: References: <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:80e8:ed31::2] x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:61UdCr0PwJveOmoBihpdWpRiCq95Z2TkaB4ZGP9Y4BRXOyMj0gnd+gRhO0WM/VnPOPRvV+v8I9jyozIjhfPD2B2N40Pq2mumSAmufgsH0M+hbdZ7s8u8ZxPkU5C3vgPqgGI81sKO3RSVYap9Ezkftw==; 24:6MmRP0T6GFR8UdcndhZ47pwqGetcuAIUjUf4nQKBWZzFf7XP31GiZvgsWsEl+JoNjFBDbLKas3gc7nhWRXxowzX1/6xHZ7Ph0XAnzyfwmaU=; 20:RXCkbgvrkaQ79yNppqmaTW+pM7l8cm+AvJr4ROLj8VoQT9PEcKrplujJGAVcNeZBb67iHb4nYBzAt7rFovQZDA== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB621; by2pr03mb443: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); 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: 0630013541 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(76104003)(377454003)(164054003)(46034005)(189998001)(19625215002)(19580405001)(110136002)(92566002)(40100003)(230783001)(77096005)(15975445007)(62966003)(77156002)(102836002)(5001960100002)(16236675004)(33656002)(5003600100002)(86362001)(54356999)(76176999)(50986999)(86612001)(19300405004)(46102003)(74316001)(575784001)(2656002)(99286002)(19609705001)(5002640100001)(87936001)(2900100001)(19580395003)(19617315012)(3826002)(579004); 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_BY2PR03MB442C7B3D003D673A8C23D6FF5920BY2PR03MB442namprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2015 19:50:32.3127 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 X-Microsoft-Exchange-Diagnostics: 1; BY2PR03MB621; 2:+n0VWj32DbmxpWRTcd/qreg2hAWSOqII5MbtX1qCtEeUsYyDlVRK1twPhXfltPgy; 3:L+G9crvrntIDRmZz6rWopWA3Ks4e1pVE0VZvtQkzg6ULgAMf6oalJR1LWPEZfF3dRDush3Bh8GexMr9lLc69WrYTIYWX5MNG4cH4FOtSLHnJaAolyR39vE4pRRltQa+mUli2fSUhrs3hCOQNO2VbpQ==; 25:rGUQNzKz6+WZiYsxcgZPASnxPa98FT39//c5lR20RIqhEDs1J1uY9JDHYPIryEqoPuYOr8rnCDdRA73pmNIngh7/Vw/ZYbkuC4Wg5vQEhfBjLESQW9bW8DQW+4ZVjpcEpCVszEiDyNf6EmnpUn+sXWzJLu/A2sGO4hltwxOVFs/D5yJOOAy+0CSm13m9771JqpN9iveTSVOwpL/OMu06C0AeMcUL9JJOhTz73w7QuQOc3p1hm9aE/MhueyXSUg96BIM5aoFtLG0YKruUDzwuqw== X-Microsoft-Exchange-Diagnostics: 1; BY2PR03MB621; 20:u071ldjT4ARSdjCjM/180H+gV75rAB3h/9IS7ueJm0K2EpkxHQwnV01YejmkDOnl4xV5nvHWFtww3MUHcJnBerq3DM8VPCp40PjcqyYvfoM3H/Eyo7nkMve15MvJQB+HBiFN3VgjRbyJc+EXbPnPxANeixYe/rXagzGcquDVYu0I+9iBozW79sCCFGuUHxkLop8ieDFkb73psAlHv5dOR0u+IkiQxY7xsmzRrSGMBAh+1uRGVfE4X80XoGKrjnrgNppEMiId77HhH/eJ/4OXKdzWbkNj6t3C1OADfgIW0AC0tcYSqBJUd4t6vCMlaXkoO/JHODV7bDGEFcPgu5XziFV6Gdg2Eu5Xufvz4nz8/8vfN/w84ges9yBd9F710ZrV7xwu44Km3qer/PHHqQayoo9wUV62GLvv/HpiX/SXh5EqFBbNFSCmRGP9Jha20oMfxvTz131Vs2zfdvJVk16P0efh2BsMqMeoA6O5Dh+FM1HZRnJSQIAn+yW3ste8zBpn; 23:3hXGc0TyFobzcRJtfR0/pXwETaYN9NwYMt+gDZT8+qV/DtDRwTPn893U8MOM8m9vB/21YLiYhGHF/BzouEyhmNPTymyeZZHgURJ5nnQSjmosbFYl8lf0ktUKB2BgXxwIZ6eSjIaV5oLy4s/u5IDZSeL+gap9RoadYJkPLim2SqW5c/i2kkHB1pw7Y+1wR2ku2bREhB4Z63bxvTH9xSGcr8lRcxgTXm3MnSmNyS45l5Nf8I93WAHigN4EwoftTpWV X-OriginatorOrg: microsoft.com Archived-At: Cc: "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, 07 Jul 2015 19:50:56 -0000 --_000_BY2PR03MB442C7B3D003D673A8C23D6FF5920BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim, I hadn't seen an answer to this question. If the thread you're referr= ing to is "Key management in the World of COSE", my impression is that some= people talked about use cases, but there were no actual conclusions drawn. Also, could you answer Brian Campbell's question in the related thread "Key= management for MACs (was Re: [Cose] Review of draft-schaad-cose-msg-01)"? = As I said in my reply, I completely understand the value of key management= for encryption, in which there are secrets to protect, but not for MACs, w= here there are not. Thanks, -- Mike From: Mike Jones Sent: Tuesday, June 30, 2015 2:54 PM To: 'Jim Schaad'; cose@ietf.org Subject: RE: [Cose] Review of draft-schaad-cose-msg-01 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_BY2PR03MB442C7B3D003D673A8C23D6FF5920BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jim, I hadn’t se= en an answer to this question.  If the thread you’re referring t= o is “Key management in the World of = COSE”, my impression is that some people talked about use cases, but = there were no actual conclusions drawn.

 

Also, could you answer= Brian Campbell’s question in the related thread “Key managemen= t for MACs (was Re: [Cose] Review of draft-schaad-cose-msg-01)”? = ; As I said in my reply, I completely understand the value of key management for encryption, in which there are secrets to protect, b= ut not for MACs, where there are not.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          Thanks,=

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

 

From: Mike Jon= es
Sent: Tuesday, June 30, 2015 2:54 PM
To: 'Jim Schaad'; cose@ietf.org
Subject: RE: [Cose] Review of draft-schaad-cose-msg-01

 

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_BY2PR03MB442C7B3D003D673A8C23D6FF5920BY2PR03MB442namprd_-- From nobody Tue Jul 7 12:54:51 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 DEE8A1A893C for ; Tue, 7 Jul 2015 12:54:49 -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 gqBg8mBVkuC3 for ; Tue, 7 Jul 2015 12:54:42 -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 749941A892B for ; Tue, 7 Jul 2015 12:54:41 -0700 (PDT) X-AuditID: 1209190d-f796f6d000005314-4f-559c2e7f79d9 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 93.89.21268.F7E2C955; Tue, 7 Jul 2015 15:54:39 -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 t67JscvV023664; Tue, 7 Jul 2015 15:54:39 -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 t67JsYgQ030606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Jul 2015 15:54:35 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_3C133085-8019-49A9-BF84-4CE93E066EA8" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Justin Richer In-Reply-To: Date: Tue, 7 Jul 2015 15:54:34 -0400 Message-Id: <3C5E1125-371E-40E6-BD72-19C63F76DF58@mit.edu> References: <000201d0b0ed$755707c0$60051740$@augustcellars.com> To: Mike Jones X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsUixG6noluvNyfU4NwWPYtpW6eyWqye/p3N Yu+0TywOzB4b50xn81iy5CeTR+uOv+wBzFFcNimpOZllqUX6dglcGWuf3mArmLyateLATusG xq0nWLoYOTgkBEwkjv2P6mLkBDLFJC7cW8/WxcjFISSwmEliXuczVghnA6PEyrlfmSGcB0wS 609fZgFpYRZIkOidOZEJxOYV0JN49PQxO4gtLGAmsenTU0YQm01AVWL6mhawGk6BaIm922ex gtgsAioSX+dNY4eY4yFx81cb1BwricYN99lAbCGBu4wS326qgdgiAjoSjy9+Y4O4Wlbi61a5 CYwCs5BcMQvJFRBxbYllC18zQ9iaEvu7l7NgimtIdH6byLqAkW0Vo2xKbpVubmJmTnFqsm5x cmJeXmqRrpFebmaJXmpK6SZGUBRwSvLuYHx3UOkQowAHoxIP7w2J2aFCrIllxZW5hxglOZiU RHmF1eaECvEl5adUZiQWZ8QXleakFh9ilOBgVhLh/akKlONNSaysSi3Kh0lJc7AoifNu+sEX IiSQnliSmp2aWpBaBJOV4eBQkuBt0QVqFCxKTU+tSMvMKUFIM3FwggznARp+GKSGt7ggMbc4 Mx0if4pRUUqcdyNIQgAkkVGaB9cLS1KvGMWBXhHmTQap4gEmOLjuV0CDmYAGL9edBTK4JBEh JdXAKKtaZTUx7vLJ5G0P59is11typ8MiMNE3fXOPGd+K9KfpupP5z713+T3N/c2r/Yy+Sy+k eFkaVCU5HL2x/eIn++TXrh/0rPbucedKkuo3/MQecbWpatmDyE6r10GT1+cFbz+luWel6f3Z /5PfrlG7seyG4sXd644krP37fFWqBKu547lVimwh5kosxRmJhlrMRcWJAJX8WjYtAwAA Archived-At: Cc: Jim Schaad , "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, 07 Jul 2015 19:54:50 -0000 --Apple-Mail=_3C133085-8019-49A9-BF84-4CE93E066EA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Perhaps I=E2=80=99m missing something, but as chair I feel the need to = point out this line in our current charter for you all to consider: Key management and binding of keys to identities are out of scope for = the working group. =E2=80=94 Justin > On Jul 7, 2015, at 3:50 PM, Mike Jones = wrote: >=20 > Jim, I hadn=E2=80=99t seen an answer to this question. If the thread = you=E2=80=99re referring to is =E2=80=9CKey management in the World of = COSE=E2=80=9D, my impression is that some people talked about use cases, = but there were no actual conclusions drawn. > =20 > Also, could you answer Brian Campbell=E2=80=99s question in the = related thread =E2=80=9CKey management for MACs (was Re: [Cose] Review = of draft-schaad-cose-msg-01)=E2=80=9D? As I said in my reply, I = completely understand the value of key management for encryption, in = which there are secrets to protect, but not for MACs, where there are = not. > =20 > = Thanks, > -- = Mike > =20 > From: Mike Jones=20 > Sent: Tuesday, June 30, 2015 2:54 PM > To: 'Jim Schaad'; cose@ietf.org > Subject: RE: [Cose] Review of draft-schaad-cose-msg-01 > =20 > Jim, is the discussion you=E2=80=99re referring to for my issue 2 the = thread =E2=80=9CKey management in the World of COSE=E2=80=9D or is there = an additional thread you=E2=80=99re referring to? > =20 > From: Jim Schaad [mailto:ietf@augustcellars.com = ]=20 > Sent: Saturday, June 27, 2015 8:25 AM > To: Mike Jones; cose@ietf.org > Subject: RE: [Cose] Review of draft-schaad-cose-msg-01 > =20 > =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 > 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=99= ll 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 > 2. HMACs should be optimized for the no-key-management case. > =20 > 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. > =20 > I=E2=80=99m 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 =E2=80=93 not even =E2=80=9Cdir=E2=80=9D= (direct). I suspect that this can be cleanly done by omitting the key = management layer entirely when it=E2=80=99s not used, rather than = explicitly using =E2=80=9Cdir=E2=80=9D (direct). > =20 > [JLS] See above. > =20 > 3. Wrapped keys should be able to be represented as simply the = wrapped key value =E2=80=93 not as an encrypted data structure with = unnecessary information. > =20 > 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. > =20 > 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 =E2=80=9CA128KW=E2=80=9D= , etc. > =20 > 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. > =20 > [JLS] I don=E2=80=99t understand this comment. This is not what the = document says. > =20 > 4. Simpler and more comprehensible examples are needed. > =20 > I would include examples for the simplest and likely most common use = cases: > =C2=B7 HMAC without key management > =C2=B7 Single signature > =C2=B7 Encryption using AES Key Wrap for key management and AES = GCM for content encryption > =20 > 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. > =20 > For instance, the Direct MAC example in C.1 should be changed from = beginning like this: > =20 > { > 1: 3, > 2: h'a10104', > 4: h'546869732069732074686520636f6e74656e742e', > 10: h'2ba937ca03d76c3dbad30cfcbaeef586f9c0f9ba616ad67e9205d3857 > 6ad9930', > =20 > to beginning like this: > =20 > { > 1 (msg_type): 3 (MACed message), > 2 (protected): h'a10104' (alg:HS256), > 4 (payload): h'546869732069732074686520636f6e74656e742e', > 10 (tag): = h'2ba937ca03d76c3dbad30cfcbaeef586f9c0f9ba616ad67e9205d3857 > 6ad9930', > =20 > [JLS] More examples are on the way in the future. > =20 > MINOR ISSUES > =20 > 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, =E2=80=A6 aa. The section numbers and names in which = they appear are included in the write-up. > =20 > 2. The COSE_MSG structure > =20 > 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. > =20 > [JLS] I do not believe that this is required. If you implement a new = item, then you don=E2=80=99t have a pure implementation of this document = and the clause is implicit. > =20 > b. This syntax needs more explanation: > COSE_Tagged_MSG =3D #6.999(COSE_MSG) ; Replace 999 with TBD1 > =20 > 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. > =20 > [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. > =20 > c. Change: > | ciphertext | 4 | TODO: Should we re-use the same as payload = | > | | | or not? = | > to: > | ciphertext | 7 | For COSE_encrypt = | > =20 > It=E2=80=99s 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=E2=80=99s not like using another short = integer value here will cause us to run out of them in this context. > =20 > [JLS] The TODO is a marker for future discussion =E2=80=93 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=E2=80=99t know what the answer for this is yet. > =20 > 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. > =20 > The new text makes it clearer that =E2=80=9Cprotected=E2=80=9D and = =E2=80=9Cunprotected=E2=80=9D can=E2=80=99t be included where their = values can=E2=80=99t be used. > [JLS] That text does not make it any clearer to me. > =20 > 3.1. COSE Headers > =20 > 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. > =20 > The language should make it clear that =E2=80=9Ccrit=E2=80=9D is only = for defining behavior of critical extensions =E2=80=93 not for making = header parameters defined by this spec critical. > [JLS] This does not make things clearer tome. > =20 > 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 = | > | | | | | = | > =20 > It still makes sense to be able to represent URLs to JWK and COSE Key = objects. But we shouldn=E2=80=99t call the COSE Key passed by value = =E2=80=9Cjwk=E2=80=9D, since that=E2=80=99s misleading. > [JLS] Thus the open issue marker. > =20 > 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? > =20 > I would keep all of them, other than changing =E2=80=9Cjku=E2=80=9D = and =E2=80=9Cjwk=E2=80=9D to =E2=80=9Cjku=E2=80=9D, =E2=80=9Ccku=E2=80=9D,= and =E2=80=9Cck=E2=80=9D per (f) above. > [JLS] This will be a discussion issue. > =20 > h. Open Issue 2. I am currently torn on the question "Should epk and = iv/nonce be > algorithm specific or generic headers?" > =20 > I would define common labels for them since they are commonly used = across multiple algorithms. > =20 > 4. Signing Structure > =20 > i. The description of =E2=80=9Cprotected=E2=80=9D says = =E2=80=9CThe field MUST NOT hold attributes about the payload being = signed=E2=80=9D. Assuming that a flattened syntax is added, this would = then become something like =E2=80=9CThe field MUST NOT hold attributes = about the payload being signed unless the flattened serialization is = being used=E2=80=9D. Other related statements throughout the document = would likewise need to be similarly updated. > [JLS] But it is not current added =E2=80=93 so this is not currently = an actionable statement. > =20 > 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. > =20 > There needs to be a reference to a place where the process of = verifying the key=E2=80=99s 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? > =20 > 5. Encryption Object > =20 > 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. > =20 > I=E2=80=99ll 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. > =20 > l. A generic =E2=80=9Civ=E2=80=9D (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. > =20 > m. A =E2=80=9Ctag=E2=80=9D (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 =E2=80=98iv=E2=80=99, however =E2=80=98tag=E2=80=99= is part of the ciphertext. > =20 > 5.1.1. Direct Encryption > =20 > 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. > =20 > SHOULD is too strong here because in some protocols, the shared secret = will already be known by methods other than an included =E2=80=9Ckid=E2=80= =9D or other key selection value. A =E2=80=9CSHOULD =E2=80=A6 unless = =E2=80=A6=E2=80=9D construct like was used in similar JOSE descriptions = is probably the right thing to use here. > [JLS] The =E2=80=A6unless=E2=80=A6 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. > =20 > 6. MAC Objects > =20 > o. The =E2=80=9CHow to compute a MAC=E2=80=9D instructions say: > 5. Encrypt and encode the MAC key for each recipient of the = message. > =20 > 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. > =20 > 7. Key Structure > =20 > 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. > =20 > Like in (n), the application may know the key usage from application = context, rendering the inclusion of =E2=80=9Ckey_ops=E2=80=9D = unnecessary. Language something like =E2=80=9CIt is strongly suggested = that this element be present for all keys unless this information is = already know to the application through other means=E2=80=9D should be = used to capture this. > =20 > The working group should also discuss whether it wants to carry = forward =E2=80=9Cuse=E2=80=9D 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=E2=80=99t see any good use for it that is not better served by = =E2=80=98key_ops=E2=80=99. This is doubly true given that the W3C = Crypto group > =20 > q. I would define short numeric values that correspond to the defines = =E2=80=9Ckey_ops=E2=80=9D string values. I=E2=80=99d do the same for = the =E2=80=9Cuse=E2=80=9D values. > [JLS] Yes this will be happening going forward. > =20 > 8. CBOR Encoder Restrictions > =20 > 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. > =20 > I would strongly prefer that the =E2=80=9CSHOULD=E2=80=9D be changed = to =E2=80=9CMUST=E2=80=9D. CBOR doesn=E2=80=99t have the same legacy of = lax parsers that we inherited from JavaScript/ECMAscript for JSON. = Let=E2=80=99s not open the door to them! > =20 > 9.5 COSE Algorithm Registry > =20 > s. I would add an additional =E2=80=9CJOSE algorithm name=E2=80=9D = field to this registry, whose value is the corresponding =E2=80=9CAlgorith= m Name=E2=80=9D entry in the IANA JSON Web Signature and Encryption = Algorithms registry at = http://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-a= lgorithms = , 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. > =20 > 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? > =20 > 9.8.1 COSE Security Message > =20 > t. Besides registering the MIME type =E2=80=9Capplication/cose=E2=80=9D= , I would also register one for a base64url encoded COSE message =E2=80=93= an idea first described to me by Joe Hildebrand. It could be called = =E2=80=9Capplication/cose+base64url=E2=80=9D 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? > =20 > 9.8.2 COSE Key Media Type > =20 > u. =E2=80=9Capplication/jwk+json=E2=80=9D should be changed to = something like =E2=80=9Capplication/cose-key=E2=80=9D and = =E2=80=9Capplication/jwk-set+json=E2=80=9D should be changed to = something like =E2=80=9Capplication/cose-key-set=E2=80=9D. > =20 > 11.2. Informative References > =20 > v. The date on the AES-GCM reference (SP 800-38D) should be November = 2007 =E2=80=93 not June 2015. > =20 > Appendix A. AEAD and AE Algorithms > =20 > 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]. > =20 > The last sentence is not true, as written. The AES-GCM spec describes = =E2=80=9Cthe ciphertext and tag outputs=E2=80=9D =E2=80=93 not a single = combined output. Common implementations correspond to this, such as the = implementation of GCM in .NET. > =20 > The CCM description in RFC 3610 Section 2.4 describes the output using = the text =E2=80=9CThe final result c consists of the encrypted message = followed by the encrypted authentication value U=E2=80=9D, which admits = either implementation. Likewise, at least the .NET CCM implementation = produces separate ciphertext and authentication tag values. > =20 > Whether the tag should be separate or automatically appended to the = ciphertext isn=E2=80=99t a hill I=E2=80=99m 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. > =20 > [JLS] Wrong reference =E2=80=93will correct. > =20 > Appendix C. Examples > =20 > x. The uses of strings and corresponding labels such as those that = follow are confusing =E2=80=93 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 = " > }, > =20 > There are similar strings in some of the other examples that I also = couldn=E2=80=99t wrap my head around. > [JLS] My code does not match the spec here. Originally they were = strings. > =20 > Appendix D. COSE Header Algorithm Label Table > =20 > y. I would change the term =E2=80=9CHeader Algorithm=E2=80=9D to = =E2=80=9CHeader Parameter=E2=80=9D. (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=E2=80=99t = think that some of the terms I am currently using are sufficiently = distinct to make it easy to figure things out. > =20 > z. In Appendix D and Appendix E, I would call out that the names in = the =E2=80=9Cname=E2=80=9D columns correspond to names defined in RFC = 7518. > [JLS] These tables are disappearing as part of the add the algorithms = to the document exercise. > =20 > Appendix F. COSE General Values > =20 > aa. This seems confused, as it mixes =E2=80=9Ckty=E2=80=9D 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. > =20 > NITS > =20 > I will be submitting spelling and grammar corrections as a GitHub pull = request against the spec repository rather than detail them here. = I=E2=80=99ll post the pull request link once it=E2=80=99s been created. > =20 > CONCLUSIONS > =20 > 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 > I=E2=80=99d be willing to produce specific proposed edits for any/all = of the above issues and comments, should the editors find that useful. > =20 > Best = wishes, > -- Mike > =20 > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose --Apple-Mail=_3C133085-8019-49A9-BF84-4CE93E066EA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Perhaps I=E2=80=99m missing something, but as chair I feel = the need to point out this line in our current charter for you all to = consider:

Key management and binding of keys to identities are out of =
scope for the
working =
group.

 =E2=80=94 Justin


On = Jul 7, 2015, at 3:50 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Jim, I hadn=E2=80=99t seen an answer = to this question.  If the thread you=E2=80=99re referring to is =E2=80=9CKey management = in the World of COSE=E2=80=9D, my impression is that some people talked = about use cases, but there were no actual conclusions drawn.

 

Also, could = you answer Brian Campbell=E2=80=99s question in the related thread = =E2=80=9CKey management for MACs (was Re: [Cose] Review of = draft-schaad-cose-msg-01)=E2=80=9D?  As I said in my reply, I = completely understand the value of key management for encryption, in which there are secrets to = protect, but not for MACs, where there are not.

 

          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    Thanks,

          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    -- Mike

 

From: Mike Jones
Sent: Tuesday, June 30, 2015 2:54 PM
To: 'Jim Schaad'; cose@ietf.org
Subject: RE: [Cose] Review of = draft-schaad-cose-msg-01

 

Jim, is the = discussion you=E2=80=99re referring to for my issue 2 the thread =E2=80=9C= Key management in the World of COSE=E2=80=9D or is there an additional = thread you=E2=80=99re referring 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=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=99= 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=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 the common single = signature/recipient cases.  Based on this developer feedback, we did this.

 

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.

 

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.

 

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=9Cunprotecte= d=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.

 

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=E2=80=99m 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 =E2=80=93 not even =E2=80=9Cdir=E2=80=9D (direct).  I suspect that this can = be cleanly done by omitting the key management layer entirely when = it=E2=80=99s not used, rather than explicitly using =E2=80=9Cdir=E2=80=9D = (direct).

 

[JLS] See = above.

 

3.  = Wrapped keys should be able to be represented as simply the wrapped key = value =E2=80=93 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 =E2=80=9CA128KW=E2=80=9D, 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=E2=80= =99t 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:

=C2=B7        HMAC without key management

=C2=B7        Single signature

=C2=B7        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, =E2=80= =A6 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=E2=80=99t 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?           &nbs= p;            =             |

to:

   | = ciphertext  | 7      | For = COSE_encrypt          &n= bsp;           &nbs= p;    |

 

It=E2=80=99s 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=E2=80=99s 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 =E2=80=93 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=E2=80=99t 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 =E2=80=9Cprotected=E2=80=9D and =E2=80=9Cunprotected=E2=80=9D= can=E2=80=99t be included where their values can=E2=80=99t 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 =E2=80=9Ccrit=E2=80=9D is only for defining behavior = of critical extensions =E2=80=93 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  |

   = |          = |       = |          = |           = |            &= nbsp;         =    |

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

   = |          = |       = |          = |           | a JWK = key            = ;   |

   = |          = |       = |          = |           = |            &= nbsp;            = |

to:

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

   = |          = |       = |          = |           = |            &= nbsp;         =    |

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

   = |          = |       = |          = |           = |            &= nbsp;         =    |

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

   = |          = |       = |          = |           = |            &= nbsp;            = |

 

It still makes sense = to be able to represent URLs to JWK and COSE Key objects.  But we = shouldn=E2=80=99t call the COSE Key passed by value =E2=80=9Cjwk=E2=80=9D,= since that=E2=80=99s 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 = =E2=80=9Cjku=E2=80=9D and =E2=80=9Cjwk=E2=80=9D to =E2=80=9Cjku=E2=80=9D, = =E2=80=9Ccku=E2=80=9D, and =E2=80=9Cck=E2=80=9D 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.          &nb= sp;      The description of =E2=80=9Cprotected=E2=80=9D says =E2=80=9CThe = field MUST NOT hold attributes about the payload being signed=E2=80=9D.&nb= sp; Assuming that a flattened syntax is added, this would then become = something like =E2=80=9CThe field MUST NOT hold attributes about the = payload being signed unless the flattened serialization is being used=E2=80=9D.  Other = related statements throughout the document would likewise need to be = similarly updated.

[JLS] But it is not current added =E2=80=93= 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=E2=80=99s 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=E2=80=99ll 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 =E2=80=9Civ=E2=80=9D = (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 =E2=80=9Ctag=E2=80=9D (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 =E2=80=98iv=E2=80=99, = however =E2=80=98tag=E2=80=99 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 =E2=80=9Ckid=E2=80=9D or other key = selection value.  A =E2=80=9CSHOULD =E2=80=A6 unless =E2=80=A6=E2=80=9D= construct like was used in similar JOSE descriptions is probably the right thing to use here.

[JLS] The = =E2=80=A6unless=E2=80=A6 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 =E2=80=9CHo= w to compute a MAC=E2=80=9D 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 =E2=80=9Ckey_ops=E2=80= =9D unnecessary.  Language something like =E2=80=9CIt is strongly = suggested that this element be present for all keys unless this = information is already know to the application through other means=E2=80=9D should = be used to capture this.

 

The working group should also discuss whether it = wants to carry forward =E2=80=9Cuse=E2=80=9D 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=E2=80=99t see any good use for it = that is not better served by =E2=80=98key_ops=E2=80=99.  This is = doubly true given that the W3C Crypto group

 

q.  I would = define short numeric values that correspond to the defines =E2=80=9Ckey_op= s=E2=80=9D string values.  I=E2=80=99d do the same for the = =E2=80=9Cuse=E2=80=9D 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 =E2=80=9CSHOULD=E2=80= =9D be changed to =E2=80=9CMUST=E2=80=9D.  CBOR doesn=E2=80=99t = have the same legacy of lax parsers that we inherited from = JavaScript/ECMAscript for JSON.  Let=E2=80=99s not open the door to = them!

 

9.5  COSE = Algorithm Registry

 

s.  I would add = an additional =E2=80=9CJOSE algorithm name=E2=80=9D field to this = registry, whose value is the corresponding =E2=80=9CAlgorithm Name=E2=80=9D= entry in the IANA JSON Web Signature and Encryption Algorithms registry = at = http://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-a= lgorithms, 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 =E2=80=9Capplication/cose=E2=80=9D, I would = also register one for a base64url encoded COSE message =E2=80=93 an idea = first described to me by Joe Hildebrand.  It could be called = =E2=80=9Capplication/cose+base64url=E2=80=9D 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.  = =E2=80=9Capplication/jwk+json=E2=80=9D should be changed to something = like =E2=80=9Capplication/cose-key=E2=80=9D and = =E2=80=9Capplication/jwk-set+json=E2=80=9D should be changed to = something like =E2=80=9Capplication/cose-key-set=E2=80=9D.

 

11.2.  = Informative References

 

v.  The date on the AES-GCM reference (SP = 800-38D) should be November 2007 =E2=80=93 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 =E2=80=9Cthe ciphertext and tag = outputs=E2=80=9D =E2=80=93 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 =E2=80=9CThe = final result c consists of the encrypted message followed by the = encrypted authentication value U=E2=80=9D, 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=E2=80=99t a hill I=E2=80=99m 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 =E2=80=93will correct.

 

Appendix C.  Examples

 

x.  The uses of strings and corresponding = labels such as those that follow are confusing =E2=80=93 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=E2=80=99t 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 =E2=80=9CHeader = Algorithm=E2=80=9D to =E2=80=9CHeader Parameter=E2=80=9D.  (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=E2=80=99t = 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 =E2=80=9Cname=E2=80=9D 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 =E2=80=9Ckty=E2=80=9D 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=E2=80=99ll post = the pull request link once it=E2=80=99s been created.

 

CONCLUSIONS

 

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.

 

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

 

         =             &n= bsp;           &nbs= p;            =             &n= bsp; Best wishes,

         =             &n= bsp;           &nbs= p;            =             &n= bsp; -- Mike

 

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

= --Apple-Mail=_3C133085-8019-49A9-BF84-4CE93E066EA8-- From nobody Tue Jul 7 13:24: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 127971A8ABD for ; Tue, 7 Jul 2015 13:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=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 gF8nuQH7FAFc for ; Tue, 7 Jul 2015 13:24:33 -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 E30691A8ABA for ; Tue, 7 Jul 2015 13:24:32 -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 t67KORhc001367; Tue, 7 Jul 2015 22:24:27 +0200 (CEST) Received: from alma.local (p5DCCC755.dip0.t-ipconnect.de [93.204.199.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3mQwGg0965z3GgQ; Tue, 7 Jul 2015 22:24:26 +0200 (CEST) Date: Tue, 7 Jul 2015 22:24:26 +0200 From: Carsten Bormann To: Justin Richer , Mike Jones Message-ID: In-Reply-To: <3C5E1125-371E-40E6-BD72-19C63F76DF58@mit.edu> References: <000201d0b0ed$755707c0$60051740$@augustcellars.com> <3C5E1125-371E-40E6-BD72-19C63F76DF58@mit.edu> X-Mailer: Airmail (303) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="559c357a_56c22a84_f3d6" Archived-At: Cc: Jim Schaad , "=?utf-8?Q?cose=40ietf.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, 07 Jul 2015 20:24:34 -0000 --559c357a_56c22a84_f3d6 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline There is a difference between 1) =E2=80=9Ckey management=E2=80=9D (one of= the least useful words I know in the field of security) and 2) the packi= ng and unpacking of keying material into data structures for transmission= , in a way that makes use of certain cryptographic functions. =C2=A0I ind= eed hope we are doing the latter, but not the former. =C2=A0Similarly, I = hope that the concept of an =E2=80=9Cidentity=E2=80=9D does not exist at = the COSE level, and I also hope that COSE can be used to ship around keys= and other information that may be used in protocols that establish or em= ploy what could be called =E2=80=9Cidentity=E2=80=9D. If we, however, have to make sure COSE cannot be used at all for =E2=80=9C= key management=E2=80=9D or =E2=80=9Cbinding keys to identities=E2=80=9D (= whatever these things mean in an application of COSE), this is not a usef= ul activity. Gr=C3=BC=C3=9Fe, Carsten On 7 Jul 2015 at 21:55:04, Justin Richer (jricher=40mit.edu) wrote: Key management and binding of keys to identities are out of scope for the= =C2=A0 working group.=C2=A0 --559c357a_56c22a84_f3d6 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

I am more than willing to have a different term for =E2=80=9CKey = Management=E2=80=9D.=C2=A0 However, I have inherited the term from CMS = (RFC 2630) where section 12.3 talks about key management = algorithms.

 

What you re referring to below, I generally put under the term of key = life cycle

 

Jim

 

 

From:<= /b> = Brian Campbell [mailto:bcampbell@pingidentity.com]
Sent: = Tuesday, July 07, 2015 1:36 PM
To: Justin Richer
Cc: = Mike Jones; Jim Schaad; cose@ietf.org
Subject: Re: [Cose] = Review of draft-schaad-cose-msg-01

 

[wearing my cowboy hat = from Dallas:)]

I think the term "key = management" has gotten a little overloaded here. =

I believe the charter uses the term in = the broader and traditional sense that Wikipedia, for example, talks about it, like = "dealing with the generation, exchange, storage, use, and = replacement of keys" including "key servers [and] user = procedures."

Whereas the term seemed to get somewhat = co-opted in JOSE as a catch all to cover all the message level key = encryption, key encapsulation, and key agreement bits that are needed to = convey and protect a content encryption key for encryption. And that = usage has carried over into COSE.

COSE needs "key = management" in the latter sense of the word. Maybe it should be = called something else but it's a necessity for encryption. My question = the other day was about the what value there is in doing it for MAC = keys.

I suspect the = "Key management and binding of keys to identities are out of = scope" in the former sense in the charter is intended to keep COSE = scope reasonably constrained. 

 


   

 

On Tue, = Jul 7, 2015 at 1:54 PM, Justin Richer <jricher@mit.edu> = wrote:

Perhaps I=E2=80=99m missing something, but as chair I = feel the need to point out this line in our current charter for you all = to consider:

 

Key management =
and binding of keys to identities are out of scope for =
the
working =
group.

 

 =E2=80=94 Justin

 

 

On Jul 7, 2015, at 3:50 PM, Mike Jones <Michael.Jones@microsoft.com> = wrote:

 

Jim, I hadn=E2=80=99t seen an answer to this = question.  If the thread you=E2=80=99re referring to is = =E2=80=9CKey management in the World of COSE=E2=80=9D, my impression is = that some people talked about use cases, but there were no actual = conclusions drawn.

 

Also, could you answer Brian Campbell=E2=80=99s = question in the related thread =E2=80=9CKey management for MACs (was Re: = [Cose] Review of draft-schaad-cose-msg-01)=E2=80=9D?  As I said in = my reply, I completely understand the value of key management for = encryption, in which there are secrets to protect, but not for MACs, = where there are not.

 

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;       Thanks,

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

 

From: Mike = Jones
Sent: Tuesday, June 30, 2015 2:54 PM
To: 'Jim = Schaad'; cose@ietf.org
Subject: RE: [Cose] Review = of draft-schaad-cose-msg-01

 <= /o:p>

Jim, is the discussion you=E2=80=99re referring = to for my issue 2 the thread =E2=80=9CKey management in the World of = COSE=E2=80=9D or is there an additional thread you=E2=80=99re referring = 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

 <= /o:p>

 

 

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>

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

 <= /o:p>

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.

 <= /o:p>

I=E2=80=99m = 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 =E2=80=93 not even =E2=80=9Cdir=E2=80=9D = (direct).  I suspect that this can be cleanly done by omitting the = key management layer entirely when it=E2=80=99s not used, rather than = explicitly using =E2=80=9Cdir=E2=80=9D (direct).

 

[JLS] See above.

 <= /o:p>

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

 <= /o:p>

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.

 <= /o:p>

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 =E2=80=9CA128KW=E2=80=9D, = etc.

 <= /o:p>

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=E2=80=99t understand this comment.  = This is not what the document says.

 <= /o:p>

4.  = Simpler and more comprehensible examples are = needed.

 <= /o:p>

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

=C2=B7        = HMAC without key management

=C2=B7        = Single signature

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

 <= /o:p>

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.

 <= /o:p>

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

 <= /o:p>

  = {

  =    1: 3,

  =    2: h'a10104',

  =    4: = h'546869732069732074686520636f6e74656e742e',

  =    10: = h'2ba937ca03d76c3dbad30cfcbaeef586f9c0f9ba616ad67e9205d3857

  = 6ad9930',

 <= /o:p>

to = beginning like this:

 <= /o:p>

  = {

  =    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.

 <= /o:p>

MINOR = ISSUES

 <= /o:p>

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, =E2=80=A6 aa.  The section numbers and names in which they = appear are included in the write-up.

 <= /o:p>

2.  = The COSE_MSG structure

 <= /o:p>

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=E2=80=99t have a pure implementation of this document and the clause = is implicit.

 <= /o:p>

b.  = This syntax needs more explanation:

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

 <= /o:p>

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.

 <= /o:p>

[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;    |

 <= /o:p>

It=E2=80=99s= 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=E2=80=99s not like using another short = integer value here will cause us to run out of them in this = context.

 <= /o:p>

[JLS]  The TODO is a marker for future = discussion =E2=80=93 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=E2=80=99t 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 =E2=80=9Cprotected=E2=80=9D and = =E2=80=9Cunprotected=E2=80=9D can=E2=80=99t be included where their = values can=E2=80=99t be used.

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

 <= /o:p>

3.1.  = COSE Headers

 <= /o:p>

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.

 <= /o:p>

The = language should make it clear that =E2=80=9Ccrit=E2=80=9D is only for = defining behavior of critical extensions =E2=80=93 not for making header = parameters defined by this spec critical.

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

 <= /o:p>

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     |

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

 <= /o:p>

It still = makes sense to be able to represent URLs to JWK and COSE Key = objects.  But we shouldn=E2=80=99t call the COSE Key passed by = value =E2=80=9Cjwk=E2=80=9D, since that=E2=80=99s = 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?

 <= /o:p>

I would = keep all of them, other than changing =E2=80=9Cjku=E2=80=9D and = =E2=80=9Cjwk=E2=80=9D to =E2=80=9Cjku=E2=80=9D, =E2=80=9Ccku=E2=80=9D, = and =E2=80=9Cck=E2=80=9D per (f) above.

[JLS] This will be a discussion = issue.

 <= /o:p>

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

  =      algorithm specific or generic = headers?"

 <= /o:p>

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

 <= /o:p>

4.  = Signing Structure

 <= /o:p>

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

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

 <= /o:p>

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.

 <= /o:p>

There needs = to be a reference to a place where the process of verifying the = key=E2=80=99s 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?

 <= /o:p>

5.  = Encryption Object

 <= /o:p>

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.

 <= /o:p>

I=E2=80=99ll= 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.

 <= /o:p>

l.  A = generic =E2=80=9Civ=E2=80=9D (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.

 <= /o:p>

m.  A = =E2=80=9Ctag=E2=80=9D (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 =E2=80=98iv=E2=80=99, however = =E2=80=98tag=E2=80=99 is part of the ciphertext.

 <= /o:p>

5.1.1. = Direct Encryption

 <= /o:p>

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.

 <= /o:p>

SHOULD is = too strong here because in some protocols, the shared secret will = already be known by methods other than an included =E2=80=9Ckid=E2=80=9D = or other key selection value.  A =E2=80=9CSHOULD =E2=80=A6 unless = =E2=80=A6=E2=80=9D construct like was used in similar JOSE descriptions = is probably the right thing to use here.

[JLS] The =E2=80=A6unless=E2=80=A6 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.

 <= /o:p>

6.  = MAC Objects

 <= /o:p>

o.  = The =E2=80=9CHow to compute a MAC=E2=80=9D instructions = say:

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

 <= /o:p>

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.

 <= /o:p>

7.  = Key Structure

 <= /o:p>

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.

 <= /o:p>

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

 <= /o:p>

The working = group should also discuss whether it wants to carry forward = =E2=80=9Cuse=E2=80=9D 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=E2=80=99t see any good use for it that is = not better served by =E2=80=98key_ops=E2=80=99.  This is doubly = true given that the W3C Crypto group

 <= /o:p>

q.  I = would define short numeric values that correspond to the defines = =E2=80=9Ckey_ops=E2=80=9D string values.  I=E2=80=99d do the same = for the =E2=80=9Cuse=E2=80=9D values.

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

 <= /o:p>

8.  = CBOR Encoder Restrictions

 <= /o:p>

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.

 <= /o:p>

I would = strongly prefer that the =E2=80=9CSHOULD=E2=80=9D be changed to = =E2=80=9CMUST=E2=80=9D.  CBOR doesn=E2=80=99t have the same legacy = of lax parsers that we inherited from JavaScript/ECMAscript for = JSON.  Let=E2=80=99s not open the door to them!

 <= /o:p>

9.5  = COSE Algorithm Registry

 <= /o:p>

s.  I = would add an additional =E2=80=9CJOSE algorithm name=E2=80=9D field to = this registry, whose value is the corresponding =E2=80=9CAlgorithm = Name=E2=80=9D entry in the IANA JSON Web Signature and Encryption = Algorithms registry at http://www.iana.org/assignments/jose/jose.xhtml#web-sig= nature-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.

 <= /o:p>

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?

 <= /o:p>

9.8.1  = COSE Security Message

 <= /o:p>

t.  = Besides registering the MIME type =E2=80=9Capplication/cose=E2=80=9D, I = would also register one for a base64url encoded COSE message =E2=80=93 = an idea first described to me by Joe Hildebrand.  It could be = called =E2=80=9Capplication/cose+base64url=E2=80=9D 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?

 <= /o:p>

9.8.2  = COSE Key Media Type

 <= /o:p>

u.  = =E2=80=9Capplication/jwk+json=E2=80=9D should be changed to something = like =E2=80=9Capplication/cose-key=E2=80=9D and = =E2=80=9Capplication/jwk-set+json=E2=80=9D should be changed to = something like = =E2=80=9Capplication/cose-key-set=E2=80=9D.

 <= /o:p>

11.2.  = Informative References

 <= /o:p>

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

 <= /o:p>

Appendix = A.  AEAD and AE Algorithms

 <= /o:p>

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].

 <= /o:p>

The last = sentence is not true, as written.  The AES-GCM spec describes = =E2=80=9Cthe ciphertext and tag = outputs=E2=80=9D =E2=80=93 not a single combined output.  = Common implementations correspond to this, such as the implementation of = GCM in .NET.

 <= /o:p>

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

 <= /o:p>

Whether the = tag should be separate or automatically appended to the ciphertext = isn=E2=80=99t a hill I=E2=80=99m 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.

 <= /o:p>

[JLS] Wrong reference =E2=80=93will = correct.

 <= /o:p>

Appendix = C.  Examples

 <= /o:p>

x.  = The uses of strings and corresponding labels such as those that follow = are confusing =E2=80=93 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"

         = },

 <= /o:p>

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

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

 <= /o:p>

Appendix = D.  COSE Header Algorithm Label Table

 <= /o:p>

y.  I = would change the term =E2=80=9CHeader Algorithm=E2=80=9D to = =E2=80=9CHeader Parameter=E2=80=9D.  (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=E2=80=99t think that some of the terms I = am currently using are sufficiently distinct to make it easy to figure = things out.

 <= /o:p>

z.  In = Appendix D and Appendix E, I would call out that the names in the = =E2=80=9Cname=E2=80=9D columns correspond to names defined in RFC = 7518.

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

 <= /o:p>

Appendix = F.  COSE General Values

 <= /o:p>

aa.  = This seems confused, as it mixes =E2=80=9Ckty=E2=80=9D 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.

 <= /o:p>

NITS<= o:p>

 <= /o:p>

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

 <= /o:p>

CONCLUSIO= NS

 <= /o:p>

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.

 <= /o:p>

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

 <= /o:p>

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

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

 <= /o:p>

_______________________________________________
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

 

------=_NextPart_000_0082_01D0B8CB.62238030-- From nobody Tue Jul 7 15:57: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 5CC7A1B2A0C for ; Tue, 7 Jul 2015 15:57:15 -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 gZ4r4wX0SG2J for ; Tue, 7 Jul 2015 15:57:13 -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 1A5971B2A04 for ; Tue, 7 Jul 2015 15:57:13 -0700 (PDT) Received: from hebrews (174-21-18-91.tukw.qwest.net [174.21.18.91]) (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 57AF738EE8; Tue, 7 Jul 2015 15:57:12 -0700 (PDT) From: "Jim Schaad" To: "'Brian Campbell'" References: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> <009501d0b392$fb7cc680$f2765380$@augustcellars.com> <00d001d0b3b6$ce20f2f0$6a62d8d0$@augustcellars.com> <559392F7.30000@tzi.org> In-Reply-To: Date: Tue, 7 Jul 2015 15:57:29 -0700 Message-ID: <000001d0b908$4d282d60$e7788820$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D0B8CD.A0CB9F50" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJBW2regVOc1KgJrCGEY9SFfcIRjgIjyzTpArNKyUYA0EcPdQJL5N93AtWHUysCrbMn0wGRZpBdAiF4EMoBhcnxk5xYoFgw 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: Tue, 07 Jul 2015 22:57:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D0B8CD.A0CB9F50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable One needs to be careful with arguing from antecedent. Beware of black = swans. =20 I can think of a number of reasons why JOSE is not used. The fact that = everything is base64 encoded and that detached content are not = enthusiastically supported are high among these. =20 I know that MILE glanced at using JOSE since they were thinking of = moving to JSON, but the form did not match how they were currently = setup, and the base64 of all content was a problem. =20 I expect that the world of compact devices are going to want to do = something along the lines of RFC 4108 which does firmware update = packages in CMS. This is likely to want multiple signatures and lots of = binary content. Moving to JOSE is a problem on the second account and = so would be unlikely to show up on anybody=E2=80=99s radar. =20 My opinion is that if people really care about having a = =E2=80=9Cspecialized=E2=80=9D single recipient version, then by far the = best course is to go back to using arrays at the top level and do the = unrolling approach. This is the smallest message size and yet is still = a simple way to decode things. If we keep maps at the top level, I see = no benefits of trying to have a single recipient version at the savings = of a single byte in the message and additional complications. One can = keep that extra message byte and say =E2=80=93 only process the first = recipient structure even if there are more than one. =20 From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 Sent: Wednesday, July 01, 2015 1:40 PM To: Carsten Bormann Cc: Jim Schaad; cose@ietf.org Subject: Re: [Cose] Issue: Encoding for a single recipient or structure =20 In my own experience with JOSE, the need for single recipient case is = overwhelming majority and the simplicity the compact serialization = afforded for that case are a major win. My own implementation supports = only the compact serializations (and thus only a single recipient or = signature) and it is used widely in my employer's products and services = as well as being open source. No one has ever even asked about the JSON = serializations (which support multiple signatures/recipients).=20 I understand the allure of consistently treating something that could = have more than one thing as always potentially having more than one.=20 But there is real value in making the most common cases simple, which = shouldn't be discounted.=20 =20 =20 On Wed, Jul 1, 2015 at 1:12 AM, Carsten Bormann > wrote: Jim Schaad wrote: > If one believes that it is only for use in constrained environments, > then it is unlikely that there is a need for multiple recipients. Actually, we do have scenarios with fan-out (both via proxy and per multicast), and those are actually a strong motivator for object = security. The minimal-bytes alternative is to mix in the map entries for a single recipient with those for the headers etc. Both JSON and CBOR do not have a defined sequence of map entries, so this means the recipient has to piece the info together as it comes in. We'd also need a separate set of labels. Not my favorite. If we keep together that map, what we could still do is turn ? recipients =3D> [+{COSE_encrypt_fields}] back (we had something like that earlier) into ? recipients =3D> [+{COSE_encrypt_fields}] / = {COSE_encrypt_fields} Saves that 0x81 byte in the single-receiver case. Gr=C3=BC=C3=9Fe, Carsten _______________________________________________ Cose mailing list Cose@ietf.org =20 https://www.ietf.org/mailman/listinfo/cose =20 ------=_NextPart_000_0001_01D0B8CD.A0CB9F50 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

One needs to be careful with arguing from antecedent.=C2=A0 Beware of = black swans.

 

I can think of a number of reasons why JOSE is not used.=C2=A0 The fact = that everything is base64 encoded and that detached content are not = enthusiastically supported are high among these.

 

I know that MILE glanced at using JOSE since they were thinking of = moving to JSON, but the form did not match how they were currently = setup, and the base64 of all content was a = problem.

 

I expect that the world of compact devices are going to want to do = something along the lines of RFC 4108 which does firmware update = packages in CMS.=C2=A0 This is likely to want multiple signatures and = lots of binary content.=C2=A0 Moving to JOSE is a problem on the second = account and so would be unlikely to show up on anybody=E2=80=99s = radar.

 

My opinion is that if people really care about having a = =E2=80=9Cspecialized=E2=80=9D single recipient version, then by far the = best course is to go back to using arrays at the top level and do the = unrolling approach.=C2=A0 This is the smallest message size and yet is = still a simple way to decode things.=C2=A0 If we keep maps at the top = level, I see no benefits of trying to have a single recipient version at = the savings of a single =C2=A0byte in the message and additional = complications.=C2=A0 One can keep that extra message byte and say = =E2=80=93 only process the first recipient structure even if there are = more than one.

 

From:<= /b> = Brian Campbell [mailto:bcampbell@pingidentity.com]
Sent: = Wednesday, July 01, 2015 1:40 PM
To: Carsten = Bormann
Cc: Jim Schaad; cose@ietf.org
Subject: Re: = [Cose] Issue: Encoding for a single recipient or = structure

 

In my own experience = with JOSE, the need for single recipient case is overwhelming majority = and the simplicity the compact serialization afforded for that case are = a major win. My own implementation supports only the compact = serializations (and thus only a single recipient or signature) and it is = used widely in my employer's products and services as well as being open = source. No one has ever even asked about the JSON serializations (which = support multiple signatures/recipients).

I understand the allure = of consistently treating something that could have more than one thing = as always potentially having more than one.

But there is real value in making the most common = cases simple, which shouldn't be discounted.

 

 

On = Wed, Jul 1, 2015 at 1:12 AM, Carsten Bormann <cabo@tzi.org> = wrote:

Jim Schaad wrote:
> If one believes = that it is only for use in constrained environments,
> then it is = unlikely that there is a need for multiple recipients.

Actually, = we do have scenarios with fan-out (both via proxy and per
multicast), = and those are actually a strong motivator for object = security.

The minimal-bytes alternative is to mix in the map = entries for a single
recipient with those for the headers etc.  = Both JSON and CBOR do not
have a defined sequence of map entries, so = this means the recipient has
to piece the info together as it comes = in.  We'd also need a separate
set of labels.  Not my = favorite.

If we keep together that map, what we could still do is = turn

       ? recipients =3D> = [+{COSE_encrypt_fields}]

back (we had something like that = earlier) into

       ? recipients =3D> = [+{COSE_encrypt_fields}] / {COSE_encrypt_fields}

Saves that 0x81 = byte in the single-receiver case.

Gr=C3=BC=C3=9Fe, = Carsten


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

 

------=_NextPart_000_0001_01D0B8CD.A0CB9F50-- From nobody Tue Jul 7 15:57: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 337971B2A0C for ; Tue, 7 Jul 2015 15:57:35 -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 WI7kNPDn0DFG for ; Tue, 7 Jul 2015 15:57:23 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0108.outbound.protection.outlook.com [65.55.169.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 066691B2A04 for ; Tue, 7 Jul 2015 15:57:21 -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.213.10; Tue, 7 Jul 2015 22:57:17 +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.0213.000; Tue, 7 Jul 2015 22:57:17 +0000 From: Mike Jones To: Jim Schaad , 'Brian Campbell' , 'Justin Richer' Thread-Topic: [Cose] Review of draft-schaad-cose-msg-01 Thread-Index: AdCwuG36k7Yq5VJ4SCGK90wxv/T+IAANQXOAAKRsWeABW5wAUAAASnUAAAFwzoAABFs0gAAAax2A Date: Tue, 7 Jul 2015 22:57:17 +0000 Message-ID: References: <000201d0b0ed$755707c0$60051740$@augustcellars.com> <3C5E1125-371E-40E6-BD72-19C63F76DF58@mit.edu> <008101d0b906$0e744e70$2b5ceb50$@augustcellars.com> In-Reply-To: <008101d0b906$0e744e70$2b5ceb50$@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:ed31::2] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:f/PTYl/ezg1Fg+Ep0XrWPGlyElq3PxltZ1VdDVZAL4oU1zTGkWh62pr16WtUvAYaGoGDt5GRo3gPjF6UH6w2h5Hd+5/MTqpHX79WBTZ3bVk7ohnFsQ0mL/8xbL7LvdrIuqPCrtauesHUb7ClygX/hA==; 24:ABNFXKX3VYqB2PihRr+zX4GjCRE2T1DKmK6eO96vVDIQQkj0uTjCj1HyNAG7H4WI7pw9A/6bpKkQmotSqpHwZt4ca32WJdmK6qQbCnmPw24=; 20:HoQ2RIklR+bmfbhwqDHFC8RpkjhVORZgGsU3jO3lkqgfPV41X3OKAoJ/qNzIRr4DsXBW7fK276K81M8tqV6CtQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; by2pr03mb441: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); 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: 0630013541 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(46034005)(377454003)(164054003)(24454002)(76104003)(93886004)(16236675004)(19580395003)(19609705001)(19617315012)(46102003)(19300405004)(74316001)(87936001)(19580405001)(86362001)(102836002)(33656002)(230783001)(2171001)(40100003)(575784001)(2900100001)(62966003)(2950100001)(54356999)(76176999)(19625215002)(50986999)(77156002)(2656002)(86612001)(15975445007)(5001960100002)(5002640100001)(5003600100002)(77096005)(189998001)(92566002)(99286002)(3826002)(579004)(559001); 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_BY2PR03MB4427AB173398F8C37E49B9CF5920BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2015 22:57:17.1471 (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: Cc: "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, 07 Jul 2015 22:57:35 -0000 --_000_BY2PR03MB4427AB173398F8C37E49B9CF5920BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtYXNraW5nIEJyaWFu4oCZcyBxdWVzdGlvbiwgd2hhdCBkbyB5b3Ugc2VlIGFzIHRoZSBwdXJw b3NlIG9mIGtleSBtYW5hZ2VtZW50IGZvciBNQUNzLCBKaW0gKHdoZXJlIOKAnGtleSBtYW5hZ2Vt ZW504oCdIGlzIGJlaW5nIHVzZWQgaW4gdGhlIHNhbWUgd2F5IHRoYXQgQ01TIMKnMTIuMyB1c2Vk IHRoZSB0ZXJtKT8NCg0KRnJvbTogSmltIFNjaGFhZCBbbWFpbHRvOmlldGZAYXVndXN0Y2VsbGFy cy5jb21dDQpTZW50OiBUdWVzZGF5LCBKdWx5IDA3LCAyMDE1IDM6NDEgUE0NClRvOiAnQnJpYW4g Q2FtcGJlbGwnOyAnSnVzdGluIFJpY2hlcicNCkNjOiBNaWtlIEpvbmVzOyBjb3NlQGlldGYub3Jn DQpTdWJqZWN0OiBSRTogW0Nvc2VdIFJldmlldyBvZiBkcmFmdC1zY2hhYWQtY29zZS1tc2ctMDEN Cg0KSSBhbSBtb3JlIHRoYW4gd2lsbGluZyB0byBoYXZlIGEgZGlmZmVyZW50IHRlcm0gZm9yIOKA nEtleSBNYW5hZ2VtZW504oCdLiAgSG93ZXZlciwgSSBoYXZlIGluaGVyaXRlZCB0aGUgdGVybSBm cm9tIENNUyAoUkZDIDI2MzApIHdoZXJlIHNlY3Rpb24gMTIuMyB0YWxrcyBhYm91dCBrZXkgbWFu YWdlbWVudCBhbGdvcml0aG1zLg0KDQpXaGF0IHlvdSByZSByZWZlcnJpbmcgdG8gYmVsb3csIEkg Z2VuZXJhbGx5IHB1dCB1bmRlciB0aGUgdGVybSBvZiBrZXkgbGlmZSBjeWNsZQ0KDQpKaW0NCg0K DQpGcm9tOiBCcmlhbiBDYW1wYmVsbCBbbWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29t XQ0KU2VudDogVHVlc2RheSwgSnVseSAwNywgMjAxNSAxOjM2IFBNDQpUbzogSnVzdGluIFJpY2hl cg0KQ2M6IE1pa2UgSm9uZXM7IEppbSBTY2hhYWQ7IGNvc2VAaWV0Zi5vcmc8bWFpbHRvOmNvc2VA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0Nvc2VdIFJldmlldyBvZiBkcmFmdC1zY2hhYWQtY29z ZS1tc2ctMDENCg0KW3dlYXJpbmcgbXkgY293Ym95IGhhdCBmcm9tIERhbGxhczopXQ0KSSB0aGlu ayB0aGUgdGVybSAia2V5IG1hbmFnZW1lbnQiIGhhcyBnb3R0ZW4gYSBsaXR0bGUgb3ZlcmxvYWRl ZCBoZXJlLg0KSSBiZWxpZXZlIHRoZSBjaGFydGVyIHVzZXMgdGhlIHRlcm0gaW4gdGhlIGJyb2Fk ZXIgYW5kIHRyYWRpdGlvbmFsIHNlbnNlIHRoYXQgV2lraXBlZGlhPGh0dHBzOi8vZW4ud2lraXBl ZGlhLm9yZy93aWtpL0tleV9tYW5hZ2VtZW50PiwgZm9yIGV4YW1wbGUsIHRhbGtzIGFib3V0IGl0 LCBsaWtlICJkZWFsaW5nIHdpdGggdGhlIGdlbmVyYXRpb24sIGV4Y2hhbmdlLCBzdG9yYWdlLCB1 c2UsIGFuZCByZXBsYWNlbWVudCBvZiBrZXlzIiBpbmNsdWRpbmcgImtleSBzZXJ2ZXJzIFthbmRd IHVzZXIgcHJvY2VkdXJlcy4iDQpXaGVyZWFzIHRoZSB0ZXJtIHNlZW1lZCB0byBnZXQgc29tZXdo YXQgY28tb3B0ZWQgaW4gSk9TRSBhcyBhIGNhdGNoIGFsbCB0byBjb3ZlciBhbGwgdGhlIG1lc3Nh Z2UgbGV2ZWwga2V5IGVuY3J5cHRpb24sIGtleSBlbmNhcHN1bGF0aW9uLCBhbmQga2V5IGFncmVl bWVudCBiaXRzIHRoYXQgYXJlIG5lZWRlZCB0byBjb252ZXkgYW5kIHByb3RlY3QgYSBjb250ZW50 IGVuY3J5cHRpb24ga2V5IGZvciBlbmNyeXB0aW9uLiBBbmQgdGhhdCB1c2FnZSBoYXMgY2Fycmll ZCBvdmVyIGludG8gQ09TRS4NCkNPU0UgbmVlZHMgImtleSBtYW5hZ2VtZW50IiBpbiB0aGUgbGF0 dGVyIHNlbnNlIG9mIHRoZSB3b3JkLiBNYXliZSBpdCBzaG91bGQgYmUgY2FsbGVkIHNvbWV0aGlu ZyBlbHNlIGJ1dCBpdCdzIGEgbmVjZXNzaXR5IGZvciBlbmNyeXB0aW9uLiBNeSBxdWVzdGlvbiB0 aGUgb3RoZXIgZGF5IHdhcyBhYm91dCB0aGUgd2hhdCB2YWx1ZSB0aGVyZSBpcyBpbiBkb2luZyBp dCBmb3IgTUFDIGtleXMuDQpJIHN1c3BlY3QgdGhlICJLZXkgbWFuYWdlbWVudCBhbmQgYmluZGlu ZyBvZiBrZXlzIHRvIGlkZW50aXRpZXMgYXJlIG91dCBvZiBzY29wZSIgaW4gdGhlIGZvcm1lciBz ZW5zZSBpbiB0aGUgY2hhcnRlciBpcyBpbnRlbmRlZCB0byBrZWVwIENPU0Ugc2NvcGUgcmVhc29u YWJseSBjb25zdHJhaW5lZC4NCg0KDQoNCg0KT24gVHVlLCBKdWwgNywgMjAxNSBhdCAxOjU0IFBN LCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+ IHdyb3RlOg0KUGVyaGFwcyBJ4oCZbSBtaXNzaW5nIHNvbWV0aGluZywgYnV0IGFzIGNoYWlyIEkg ZmVlbCB0aGUgbmVlZCB0byBwb2ludCBvdXQgdGhpcyBsaW5lIGluIG91ciBjdXJyZW50IGNoYXJ0 ZXIgZm9yIHlvdSBhbGwgdG8gY29uc2lkZXI6DQoNCg0KS2V5IG1hbmFnZW1lbnQgYW5kIGJpbmRp bmcgb2Yga2V5cyB0byBpZGVudGl0aWVzIGFyZSBvdXQgb2Ygc2NvcGUgZm9yIHRoZQ0KDQp3b3Jr aW5nIGdyb3VwLg0KDQog4oCUIEp1c3Rpbg0KDQoNCk9uIEp1bCA3LCAyMDE1LCBhdCAzOjUwIFBN LCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KDQpKaW0sIEkgaGFkbuKAmXQgc2VlbiBhbiBh bnN3ZXIgdG8gdGhpcyBxdWVzdGlvbi4gIElmIHRoZSB0aHJlYWQgeW914oCZcmUgcmVmZXJyaW5n IHRvIGlzIOKAnEtleSBtYW5hZ2VtZW50IGluIHRoZSBXb3JsZCBvZiBDT1NF4oCdLCBteSBpbXBy ZXNzaW9uIGlzIHRoYXQgc29tZSBwZW9wbGUgdGFsa2VkIGFib3V0IHVzZSBjYXNlcywgYnV0IHRo ZXJlIHdlcmUgbm8gYWN0dWFsIGNvbmNsdXNpb25zIGRyYXduLg0KDQpBbHNvLCBjb3VsZCB5b3Ug YW5zd2VyIEJyaWFuIENhbXBiZWxs4oCZcyBxdWVzdGlvbiBpbiB0aGUgcmVsYXRlZCB0aHJlYWQg 4oCcS2V5IG1hbmFnZW1lbnQgZm9yIE1BQ3MgKHdhcyBSZTogW0Nvc2VdIFJldmlldyBvZiBkcmFm dC1zY2hhYWQtY29zZS1tc2ctMDEp4oCdPyAgQXMgSSBzYWlkIGluIG15IHJlcGx5LCBJIGNvbXBs ZXRlbHkgdW5kZXJzdGFuZCB0aGUgdmFsdWUgb2Yga2V5IG1hbmFnZW1lbnQgZm9yIGVuY3J5cHRp b24sIGluIHdoaWNoIHRoZXJlIGFyZSBzZWNyZXRzIHRvIHByb3RlY3QsIGJ1dCBub3QgZm9yIE1B Q3MsIHdoZXJlIHRoZXJlIGFyZSBub3QuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGFua3MsDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlr ZQ0KDQpGcm9tOiBNaWtlIEpvbmVzDQpTZW50OiBUdWVzZGF5LCBKdW5lIDMwLCAyMDE1IDI6NTQg UE0NClRvOiAnSmltIFNjaGFhZCc7IGNvc2VAaWV0Zi5vcmc8bWFpbHRvOmNvc2VAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSRTogW0Nvc2VdIFJldmlldyBvZiBkcmFmdC1zY2hhYWQtY29zZS1tc2ctMDEN Cg0KSmltLCBpcyB0aGUgZGlzY3Vzc2lvbiB5b3XigJlyZSByZWZlcnJpbmcgdG8gZm9yIG15IGlz c3VlIDIgdGhlIHRocmVhZCDigJxLZXkgbWFuYWdlbWVudCBpbiB0aGUgV29ybGQgb2YgQ09TReKA nSBvciBpcyB0aGVyZSBhbiBhZGRpdGlvbmFsIHRocmVhZCB5b3XigJlyZSByZWZlcnJpbmcgdG8/ DQoNCkZyb206IEppbSBTY2hhYWQgW21haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tXQ0KU2Vu dDogU2F0dXJkYXksIEp1bmUgMjcsIDIwMTUgODoyNSBBTQ0KVG86IE1pa2UgSm9uZXM7IGNvc2VA aWV0Zi5vcmc8bWFpbHRvOmNvc2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0Nvc2VdIFJldmll dyBvZiBkcmFmdC1zY2hhYWQtY29zZS1tc2ctMDENCg0KDQoNCkZyb206IENvc2UgW21haWx0bzpj b3NlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWtlIEpvbmVzDQpTZW50OiBTYXR1 cmRheSwgSnVuZSAyNywgMjAxNSAyOjA3IEFNDQpUbzogY29zZUBpZXRmLm9yZzxtYWlsdG86Y29z ZUBpZXRmLm9yZz4NClN1YmplY3Q6IFtDb3NlXSBSZXZpZXcgb2YgZHJhZnQtc2NoYWFkLWNvc2Ut bXNnLTAxDQoNCkluIHJlc3BvbnNlIHRvIHRoZSBjYWxsIGZvciBhZG9wdGlvbiwgSeKAmW0gc3Vi bWl0dGluZyB0aGUgZm9sbG93aW5nIHJldmlldyBmZWVkYmFjayBvbiBkcmFmdC1zY2hhYWQtY29z ZS1tc2ctMDE8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2NoYWFkLWNvc2UtbXNn LTAxPi4gIE1vc3Qgb2YgdGhlIG1ham9yIGNvbW1lbnRzIGFyZSBtb3RpdmF0ZWQgYnkgdGhlIGdv YWwgb2Yg4oCca2VlcGluZyBzaW1wbGUgdGhpbmdzIHNpbXBsZeKAnS4gIFBhcnRpY3VsYXJseSBp biBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMsIGl04oCZcyBsaWtlbHkgdG8gYmUgbm9ybWFsIGZv ciBpbXBsZW1lbnRhdGlvbnMgdG8gdXNlIG9ubHkgdGhlIHBhcnRzIG9mIENPU0UgdGhleSB0aGVp ciBhcHBsaWNhdGlvbiBuZWVkcy4gIEkgYmVsaWV2ZSB0aGF0IHdlIHNob3VsZCB0aGVyZWZvcmUg b3B0aW1pemUgdGhlIHJlcHJlc2VudGF0aW9ucyB3ZSBkZWZpbmUgZm9yIHRoZSBjb21tb24gY2Fz ZXMsIHdoaWxlIG1ha2luZyBpdCBwb3NzaWJsZSB0byBhbHNvIGdyYWNlZnVsbHkgYWNjb21tb2Rh dGUgbGVzcyBjb21tb24sIGlmIHBvc3NpYmx5IG1vcmUgZ2VuZXJhbCBjYXNlcyBhcyB3ZWxsLg0K DQpBbHNvLCBnaXZlbiBteSByb2xlIGFzIGEgZGVzaWduZXIgYW5kIGVkaXRvciBvZiB0aGUgSk9T RSBzcGVjcywgSeKAmWxsIHNheSBleHBsaWNpdGx5IHRoYXQgaXTigJlzIG5vdCBteSBnb2FsIHRv IHRyeSB0byBoYXZlIGFsbCB0aGUgZGVjaXNpb25zIGluIENPU0UgZXhhY3RseSBtaXJyb3IgdGhv c2UgaW4gSk9TRS4gIFNvbWUgdGhpbmdzIGNhbiBjbGVhcmx5IGJlIHNpbXBsaWZpZWQgZm9yIENP U0UsIGFuZCBJ4oCZbSBhbGwgZm9yIHRoYXQuICBJIHBsYW4gdG8gY29uc2lkZXIgZWFjaCBpc3N1 ZSBvbiBpdHMgaW5kaXZpZHVhbCBtZXJpdHMuICBUaGF0IHNhaWQsIGhlcmXigJlzIG15IHJldmll d+KApg0KDQpNQUpPUiBJU1NVRVMNCg0KMS4gIFJlcHJlc2VudGF0aW9ucyBzaG91bGQgYmUgb3B0 aW1pemVkIGZvciB0aGUgc2luZ2xlIHJlY2lwaWVudCBjYXNlLg0KDQpJbiBKT1NFLCBnb2luZyBp bnRvIElFU0cgcmV2aWV3LCDigJxzaWduYXR1cmVz4oCdIG9yIOKAnHJlY2lwaWVudHPigJ0gYXJy YXlzIHdlcmUgcmVxdWlyZWQgZm9yIHRoZSBKU09OIFNlcmlhbGl6YXRpb25zLCB3aXRoIG9ubHkg Z2VuZXJhbCBtdWx0aS1zaWduYXR1cmUvbXVsdGktcmVjaXBpZW50IHJlcHJlc2VudGF0aW9ucyBi ZWluZyBkZWZpbmVkIGZvciBKV1MgYW5kIEpXRS4gIEJhc2VkIG9uIGZlZWRiYWNrIGZyb20gbnVt ZXJvdXMgZGV2ZWxvcGVycyB3aG8gd2VyZSB1c2luZyBKT1NFIGZvciB1c2UgY2FzZXMgdGhhdCBv bmx5IGV2ZXIgdXNlZCBhIHNpbmdsZSBzaWduYXR1cmUgb3IgcmVjaXBpZW50LCBSaWNoYXJkIEJh cm5lcyBhc2tlZCB0aGF0IHRoZSBGbGF0dGVuZWQgc2VyaWFsaXphdGlvbnMgYmUgYWRkZWQgdG8g b3B0aW1pemUgZm9yIHRoZSBjb21tb24gc2luZ2xlIHNpZ25hdHVyZS9yZWNpcGllbnQgY2FzZXMu ICBCYXNlZCBvbiB0aGlzIGRldmVsb3BlciBmZWVkYmFjaywgd2UgZGlkIHRoaXMuDQoNClVubGVz cyB3ZSBkbyB0aGUgc2FtZSBmb3IgQ09TRSwgSeKAmW0gc3VyZSB3ZeKAmWxsIHJlY2VpdmUgdGhl IHNhbWUgZmVlZGJhY2sgdGhhdCByZXF1aXJpbmcgdGhlIOKAnHJlY2lwaWVudHPigJ0gYXJyYXkg aW4gdXNlIGNhc2VzIHdoZXJlIGl0IHdpbGwgYWx3YXlzIGNvbnRhaW4gb25lIGVsZW1lbnQgaXMg dW5uZWNlc3NhcmlseSBjb21wbGljYXRlZC4gIFdlIHNob3VsZCBkbyB0aGlzIG5vdy4NCg0KV2hp bGUgdGhlIGFyZ3VtZW50IGFnYWluc3QgdGhpcyBjb3VsZCBiZSBtYWRlIHRoYXQg4oCcaXTigJlz IGV2ZW4gbW9yZSBjb21wbGljYXRlZCB0byBzdXBwb3J0IGJvdGggdGhlIGZsYXR0ZW5lZCBhbmQg Z2VuZXJhbCBzZXJpYWxpemF0aW9ucyB0aGFuIGp1c3QgdGhlIGdlbmVyYWwgb25l4oCdLCBJIGJl bGlldmUgdGhhdCBpbiBwcmFjdGljZSwgdGhpcyBpcyBhIG1vc3RseSBzcGVjaW91cyBhcmd1bWVu dC4gIEFwcGxpY2F0aW9ucyB3aWxsIGNob29zZSBvciBidWlsZCBhbiBpbXBsZW1lbnRhdGlvbiB0 aGF0IGZpdHMgdGhlaXIgdXNlIGNhc2Ug4oCTIGVpdGhlciBvbmUgdGhhdCBzdXBwb3J0cyBzaW5n bGUgb3IgbXVsdGlwbGUgcmVjaXBpZW50cy4gIEFwcGxpY2F0aW9uIHByb2ZpbGVzIHdpbGwgY2hv b3NlIG9uZSBvciB0aGUgb3RoZXIgcmVwcmVzZW50YXRpb24gYW5kIHdpbGwgZ2VuZXJhbGx5IG5v dCBjYWxsIGZvciBib3RoLg0KDQpUaGUgd2F5IHRvIGFjaGlldmUgdGhpcyBpcyB0byBkZWZpbmUg YSBmbGF0dGVuZWQgcmVwcmVzZW50YXRpb24gYXMgSk9TRSBkaWQsIGluIHdoaWNoIGhlYWRlciBw YXJhbWV0ZXJzIGFib3V0IGJvdGggdGhlIHBheWxvYWQgYW5kIHRoZSByZWNpcGllbnQgYXJlIGNh cnJpZWQgaW4gdGhlIHRvcCBsZXZlbCDigJx1bnByb3RlY3RlZOKAnSBhbmQg4oCccHJvdGVjdGVk 4oCdIGVsZW1lbnRzLg0KDQpbSkxTXSBUaGlzIHdhcyBkaXNjdXNzZWQgb24gdGhlIG1haWxpbmcg bGlzdC4gIFRoZXJlIGFyZSBhIG51bWJlciBvZiB0cmFkZS1vZmZzIHRoYXQgd2VyZSBkaXNjdXNz ZWQuICBQbGVhc2UgcmV2aWV3IHRoYXQgZGlzY3Vzc2lvbiBhbmQgc2VlIGlmIHlvdSBoYXZlIHNv bWV0aGluZyBuZXcgdG8gYWRkLiAgUGxlYXNlIHJlbWVtYmVyIHRoYXQgd2UgYXJlIGxvb2tpbmcg YXQgYm90aCB0aGUgbWVzc2FnZSBzaXplIGFuZCB0aGUgY29kZSBzaXplIGFzIGNyaXRlcmlhIHdo ZW4gbWFraW5nIGRlY2lzaW9ucy4NCg0KMi4gIEhNQUNzIHNob3VsZCBiZSBvcHRpbWl6ZWQgZm9y IHRoZSBuby1rZXktbWFuYWdlbWVudCBjYXNlLg0KDQpQYXJ0aWN1bGFybHkgZm9yIGNvbnN0cmFp bmVkIGRldmljZXMsIGl0IGlzIHVubGlrZWx5IHRoYXQgYXBwbGljYXRpb25zIHdpbGwgd2FudCB0 byBwYXkgdGhlIHBlcmZvcm1hbmNlIHBlbmFsdHkgb2YgZ2VuZXJhdGluZyBhbmQgZW5jcnlwdGlu ZyBhIGtleSBtYW5hZ2VtZW50IGtleSB0byBwZXJmb3JtIGEgTUFDIG9wZXJhdGlvbi4gIEhlY2ss IHRoZXkgbWF5IG5vdCBoYXZlIGNyZWRpYmxlIHJhbmRvbSBudW1iZXIgZ2VuZXJhdGlvbiBpbiB0 aGUgZmlyc3QgcGxhY2UhICBBbmQgdGhleSBhcmUgbGlrZXdpc2UgdW5saWtlbHkgdG8gd2FudCB0 byBwYXkgdGhlIG1lc3NhZ2Ugc2l6ZSBwZW5hbHR5IG9mIGNhcnJ5aW5nIHRoZSBlbmNyeXB0ZWQg a2V5Lg0KDQpJ4oCZbSBmaW5lIHdpdGggdGhlIG9wdGlvbmFsIGFiaWxpdHkgdG8gaGF2ZSBrZXkg bWFuYWdlbWVudCBmb3IgTUFDcywgYnV0IHRoZSBkZWZhdWx0IHNob3VsZCBiZSB0aGF0IG5vIGtl eSBtYW5hZ2VtZW50IGluZm9ybWF0aW9uIGlzIHByZXNlbnQgaW4gdGhlIHJlcHJlc2VudGF0aW9u LiAgVGhlIG9ubHkgYWxnb3JpdGhtIHJlcHJlc2VudGVkIGJ5IGRlZmF1bHQgc2hvdWxkIGJlIHRo ZSBNQUMgYWxnb3JpdGhtIOKAkyBub3QgZXZlbiDigJxkaXLigJ0gKGRpcmVjdCkuICBJIHN1c3Bl Y3QgdGhhdCB0aGlzIGNhbiBiZSBjbGVhbmx5IGRvbmUgYnkgb21pdHRpbmcgdGhlIGtleSBtYW5h Z2VtZW50IGxheWVyIGVudGlyZWx5IHdoZW4gaXTigJlzIG5vdCB1c2VkLCByYXRoZXIgdGhhbiBl eHBsaWNpdGx5IHVzaW5nIOKAnGRpcuKAnSAoZGlyZWN0KS4NCg0KW0pMU10gU2VlIGFib3ZlLg0K DQozLiAgV3JhcHBlZCBrZXlzIHNob3VsZCBiZSBhYmxlIHRvIGJlIHJlcHJlc2VudGVkIGFzIHNp bXBseSB0aGUgd3JhcHBlZCBrZXkgdmFsdWUg4oCTIG5vdCBhcyBhbiBlbmNyeXB0ZWQgZGF0YSBz dHJ1Y3R1cmUgd2l0aCB1bm5lY2Vzc2FyeSBpbmZvcm1hdGlvbi4NCg0KS2V5IG1hbmFnZW1lbnQg a2V5cyBhcmUgYnkgZGVmaW5pdGlvbiBlcGhlbWVyYWwgYW5kIHNvIG5vIG1ldGFkYXRhIG5lZWRz IHRvIGJlIGNhcnJpZWQgYWJvdXQgdGhlbS4gIFllcywgdGhlIGFsZ29yaXRobSB1c2VkIHRvIHdy YXAgdGhlIGtleSBuZWVkcyB0byBiZSByZXByZXNlbnRlZCwgYnV0IHRoaXMgaXMgYWxyZWFkeSBy ZXByZXNlbnRlZCBzZXBhcmF0ZWx5IGZyb20gdGhlIHdyYXBwZWQga2V5Lg0KDQpBIHNpbXBsZSB3 YXkgdG8gYWNoaWV2ZSB0aGlzIGlzIHRvIGRlZmluZSBhbiBlbmNyeXB0ZWRfa2V5IGZpZWxkIHRv IHJlcHJlc2VudCB0aGUgd3JhcHBlZCBrZXksIHdoZW4gYXBwcm9wcmlhdGUgZm9yIHRoZSBhbGdv cml0aG0uICBBbW9uZyBvdGhlciBiZW5lZml0cywgdGhpcyB3aWxsIGVuYWJsZSB0aGUgdXNlIG9m IHRoZSBzdGFuZGFyZCBSRkMgMzM5NCBBRVMgS2V5IFdyYXAgYWxnb3JpdGhtcywgaW4gdGhlIHNh bWUgd2F5IHRoYXQgSk9TRSB1c2VzIOKAnEExMjhLV+KAnSwgZXRjLg0KDQpOb3RlIHRoYXQgaWYg dGhlIHdvcmtpbmcgZ3JvdXAgY2hvb3NlcyB0bywgdGhlIGFiaWxpdHkgdG8gcmVwcmVzZW50IGVu Y3J5cHRlZCBrZXlzIGFzIGRhdGEgc3RydWN0dXJlcyBjYW4gYWxzbyBiZSByZXRhaW5lZCBpbiBw YXJhbGxlbCB0byB0aGlzIHNpbXBsZXIgYXBwcm9hY2guICBBcHBsaWNhdGlvbnMgY2FuIHRoZW4g Y2hvb3NlIHdoaWNoIG1ldGhvZCB3b3JrcyBiZXN0IGZvciB0aGVtLg0KDQpbSkxTXSBJIGRvbuKA mXQgdW5kZXJzdGFuZCB0aGlzIGNvbW1lbnQuICBUaGlzIGlzIG5vdCB3aGF0IHRoZSBkb2N1bWVu dCBzYXlzLg0KDQo0LiAgU2ltcGxlciBhbmQgbW9yZSBjb21wcmVoZW5zaWJsZSBleGFtcGxlcyBh cmUgbmVlZGVkLg0KDQpJIHdvdWxkIGluY2x1ZGUgZXhhbXBsZXMgZm9yIHRoZSBzaW1wbGVzdCBh bmQgbGlrZWx5IG1vc3QgY29tbW9uIHVzZSBjYXNlczoNCg0K4oCiICAgICAgICBITUFDIHdpdGhv dXQga2V5IG1hbmFnZW1lbnQNCg0K4oCiICAgICAgICBTaW5nbGUgc2lnbmF0dXJlDQoNCuKAoiAg ICAgICAgRW5jcnlwdGlvbiB1c2luZyBBRVMgS2V5IFdyYXAgZm9yIGtleSBtYW5hZ2VtZW50IGFu ZCBBRVMgR0NNIGZvciBjb250ZW50IGVuY3J5cHRpb24NCg0KQWxzbywgdG8gYmUgY29tcHJlaGVu c2libGUgdG8gbW9zdCByZWFkZXJzLCB0aGUgZXhhbXBsZXMgbmVlZCB0byBpbmNsdWRlIGJvdGgg c3ltYm9saWMgYW5kIG51bWVyaWMgaWRlbnRpZmllcnMgZm9yIGFsbCBmaWVsZHMuICBBbHNvLCBk ZWNvZGVkIHJlcHJlc2VudGF0aW9ucyBmb3IgZW5jb2RlZCB2YWx1ZXMgbmVlZCB0byBiZSBzaG93 bi4NCg0KRm9yIGluc3RhbmNlLCB0aGUgRGlyZWN0IE1BQyBleGFtcGxlIGluIEMuMSBzaG91bGQg YmUgY2hhbmdlZCBmcm9tIGJlZ2lubmluZyBsaWtlIHRoaXM6DQoNCiAgIHsNCiAgICAgMTogMywN CiAgICAgMjogaCdhMTAxMDQnLA0KICAgICA0OiBoJzU0Njg2OTczMjA2OTczMjA3NDY4NjUyMDYz NmY2ZTc0NjU2ZTc0MmUnLA0KICAgICAxMDogaCcyYmE5MzdjYTAzZDc2YzNkYmFkMzBjZmNiYWVl ZjU4NmY5YzBmOWJhNjE2YWQ2N2U5MjA1ZDM4NTcNCiAgIDZhZDk5MzAnLA0KDQp0byBiZWdpbm5p bmcgbGlrZSB0aGlzOg0KDQogICB7DQogICAgIDEgKG1zZ190eXBlKTogMyAoTUFDZWQgbWVzc2Fn ZSksDQogICAgIDIgKHByb3RlY3RlZCk6IGgnYTEwMTA0JyAoYWxnOkhTMjU2KSwNCiAgICAgNCAo cGF5bG9hZCk6IGgnNTQ2ODY5NzMyMDY5NzMyMDc0Njg2NTIwNjM2ZjZlNzQ2NTZlNzQyZScsDQog ICAgIDEwICh0YWcpOiBoJzJiYTkzN2NhMDNkNzZjM2RiYWQzMGNmY2JhZWVmNTg2ZjljMGY5YmE2 MTZhZDY3ZTkyMDVkMzg1Nw0KICAgNmFkOTkzMCcsDQoNCltKTFNdIE1vcmUgZXhhbXBsZXMgYXJl IG9uIHRoZSB3YXkgaW4gdGhlIGZ1dHVyZS4NCg0KTUlOT1IgSVNTVUVTDQoNClRoZXNlIGlzc3Vl cyBhcmUgb3JnYW5pemVkIGJ5IHNlY3Rpb24gbnVtYmVyLCBwcm92aWRpbmcgY29tbWVudHMgb24g dGhlIHNwZWMgdGV4dCBpbiB0aGUgb3JkZXIgb2YgYXBwZWFyYW5jZS4gIDI3IGlzc3VlcyBhcmUg ZGVzY3JpYmVkLCBsYWJlbGVkIGEsIGIsIGMsIOKApiBhYS4gIFRoZSBzZWN0aW9uIG51bWJlcnMg YW5kIG5hbWVzIGluIHdoaWNoIHRoZXkgYXBwZWFyIGFyZSBpbmNsdWRlZCBpbiB0aGUgd3JpdGUt dXAuDQoNCjIuICBUaGUgQ09TRV9NU0cgc3RydWN0dXJlDQoNCmEuICBDaGFuZ2U6DQogICBJbXBs ZW1lbnRhdGlvbnMgTVVTVCBiZSBwcmVwYXJlZCB0byBmaW5kIGFuIGludGVnZXIgdW5kZXIgdGhp cyBsYWJlbA0KICAgd2hpY2ggZG9lcyBub3QgY29ycmVzcG9uZCB0byB0aGUgdmFsdWVzIDEgdG8g My4gIElmIHRoaXMgaXMgZm91bmQNCiAgIHRoZW4gdGhlIGNsaWVudCBNVVNUIHN0b3AgYXR0ZW1w dGluZyB0byBwYXJzZSB0aGUgc3RydWN0dXJlIGFuZCBmYWlsLg0KdG86DQogICBJbXBsZW1lbnRh dGlvbnMgTVVTVCBiZSBwcmVwYXJlZCB0byBmaW5kIGFuIGludGVnZXIgdW5kZXIgdGhpcyBsYWJl bA0KICAgd2hpY2ggZG9lcyBub3QgY29ycmVzcG9uZCB0byB0aGUgdmFsdWVzIDEgdG8gMy4gIElm IHRoaXMgaXMgZm91bmQNCiAgIHRoZW4gdGhlIGNsaWVudCBNVVNUIHN0b3AgYXR0ZW1wdGluZyB0 byBwYXJzZSB0aGUgc3RydWN0dXJlIGFuZCBmYWlsLA0KICAgdW5sZXNzIGl0IHVuZGVyc3RhbmRz IGFuZCBpbXBsZW1lbnRzIHRoZSBleHRlbnNpb24gbGFiZWwgdmFsdWUuDQoNCltKTFNdIEkgZG8g bm90IGJlbGlldmUgdGhhdCB0aGlzIGlzIHJlcXVpcmVkLiAgSWYgeW91IGltcGxlbWVudCBhIG5l dyBpdGVtLCB0aGVuIHlvdSBkb27igJl0IGhhdmUgYSBwdXJlIGltcGxlbWVudGF0aW9uIG9mIHRo aXMgZG9jdW1lbnQgYW5kIHRoZSBjbGF1c2UgaXMgaW1wbGljaXQuDQoNCmIuICBUaGlzIHN5bnRh eCBuZWVkcyBtb3JlIGV4cGxhbmF0aW9uOg0KICAgQ09TRV9UYWdnZWRfTVNHID0gIzYuOTk5KENP U0VfTVNHKSAgIDsgUmVwbGFjZSA5OTkgd2l0aCBUQkQxDQoNCkkgYXNzdW1lIHRoYXQgdGhpcyBp cyBhIHVzZSBvZiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MDQ5I3NlY3Rpb24tMi40 IChPcHRpb25hbCBUYWdnaW5nIG9mIEl0ZW1zKSwgYnV0IHlvdSBzaG91bGQgZXhwbGljaXRseSBz YXkgdGhhdC4NCg0KW0pMU10gIFRoaXMgZmFsbHMgaW4gdG8gdGhlIHF1ZXN0aW9uIG9mIG5vcm1h dGl2ZSByZWZlcmVuY2Ugb24gQ0RETC4gIElmIGl0IGlzIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSwg dGhpcyBpcyBub3QgbmVjZXNzYXJ5IGFzIHlvdSBhcmUgZXhwZWN0ZWQgdG8gdW5kZXJzdGFuZCBD RERMLiAgSWYgQ0RETCBpcyBpbmZvcm1hdGlvbmFsLCB0aGVuIGl0IHdvdWxkIGJlIHJlcXVpcmVk Lg0KDQpjLiAgQ2hhbmdlOg0KICAgfCBjaXBoZXJ0ZXh0ICB8IDQgICAgICB8IFRPRE86IFNob3Vs ZCB3ZSByZS11c2UgdGhlIHNhbWUgYXMgcGF5bG9hZCB8DQogICB8ICAgICAgICAgICAgIHwgICAg ICAgIHwgb3Igbm90PyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCnRvOg0K ICAgfCBjaXBoZXJ0ZXh0ICB8IDcgICAgICB8IEZvciBDT1NFX2VuY3J5cHQgICAgICAgICAgICAg ICAgICAgICAgICAgICB8DQoNCkl04oCZcyBjbGVhbmVyIG5vdCB0byByZXVzZSB0aGUgc2FtZSBs YWJlbCB2YWx1ZSBmb3IgZGlmZmVyZW50IHNlbWFudGljIG1lYW5pbmdzLiAgSWYgd2UgZG8gdGhh dCwgd2UgbWlnaHQgY29tZSB0byByZWdyZXQgaXQgYXMgdGhlIHNwZWMgZXZvbHZlcy4gIEJlc2lk ZXMsIGl04oCZcyBub3QgbGlrZSB1c2luZyBhbm90aGVyIHNob3J0IGludGVnZXIgdmFsdWUgaGVy ZSB3aWxsIGNhdXNlIHVzIHRvIHJ1biBvdXQgb2YgdGhlbSBpbiB0aGlzIGNvbnRleHQuDQoNCltK TFNdICBUaGUgVE9ETyBpcyBhIG1hcmtlciBmb3IgZnV0dXJlIGRpc2N1c3Npb24g4oCTIFRoZXJl IGFyZSBib3RoIGFkdmFudGFnZXMgYW5kIGRpc2FkdmFudGFnZXMgdG8gcmUtdXNpbmcgdGhlIHNh bWUgbGFiZWwuICBPbiBvbmUgaGFuZCwgaXQgaXMgZWFzeSBmb3IgcHJvZ3JhbXMgdG8gYWx3YXlz IGxvb2sgaW4gdGhlIHNhbWUgbG9jYXRpb24gZm9yIHRoZSBjb250ZW50IGluZGVwZW5kZW50IG9m IHdoYXQgdHlwZSBvZiBjb250ZW50IGl0IGlzLiAgVGhpcyBtYXkgbWFrZSB0aGluZ3MgZWFzaWVy IGZvciBpdGVtcyB3aGljaCBoYXZlIGRldGFjaGVkIGNvbnRlbnQgZGVwZW5kaW5nIG9uIGhvdyB0 aGUgQVBJIGhhbmRsZXMgdGhpcy4gIE9uIHRoZSBvdGhlciBoYW5kLCBhbiBBUEkgbWlnaHQgd2Fu dCB0byBoYXZlIHRoZW0gc2VwYXJhdGUuICAgSSBkb27igJl0IGtub3cgd2hhdCB0aGUgYW5zd2Vy IGZvciB0aGlzIGlzIHlldC4NCg0KZC4gIENoYW5nZToNCiAgVGhlc2UgdHdvIGJ1Y2tldHMNCiAg IGFyZSBhdmFpbGFibGUgZm9yIHVzZSBpbiBhbGwgb2YgdGhlIHN0cnVjdHVyZXMgaW4gdGhpcyBk b2N1bWVudA0KICAgZXhjZXB0IGZvciBrZXlzLiAgV2hpbGUgdGhlc2UgYnVja2V0cyBjYW4gYmUg cHJlc2VudCwgdGhleSBtYXkgbm90DQogICBhbGwgYmUgdXNhYmxlIGluIGFsbCBpbnN0YW5jZXMu DQp0bzoNCiAgVGhlc2UgdHdvIGJ1Y2tldHMNCiAgIGFyZSBkZWZpbmVkIGZvciB1c2UgaW4gYWxs IG9mIHRoZSBzdHJ1Y3R1cmVzIGluIHRoaXMgZG9jdW1lbnQNCiAgIGV4Y2VwdCBmb3Iga2V5cy4g IFdoaWxlIHRoZXNlIGJ1Y2tldHMgYXJlIGRlZmluZWQsIHRoZXkgbWF5IG5vdA0KICAgYmUgdXNh YmxlIG9yIHVzZWQgaW4gYWxsIGluc3RhbmNlcy4NCg0KVGhlIG5ldyB0ZXh0IG1ha2VzIGl0IGNs ZWFyZXIgdGhhdCDigJxwcm90ZWN0ZWTigJ0gYW5kIOKAnHVucHJvdGVjdGVk4oCdIGNhbuKAmXQg YmUgaW5jbHVkZWQgd2hlcmUgdGhlaXIgdmFsdWVzIGNhbuKAmXQgYmUgdXNlZC4NCltKTFNdIFRo YXQgdGV4dCBkb2VzIG5vdCBtYWtlIGl0IGFueSBjbGVhcmVyIHRvIG1lLg0KDQozLjEuICBDT1NF IEhlYWRlcnMNCg0KZS4gIENoYW5nZToNCiAgVGhlIGZpZWxkIGlzIHVzZWQgdG8gaW5kaWNhdGUg d2hpY2ggcHJvdGVjdGVkIGhlYWRlciBrZXlzDQogICAgICBhbiBhcHBsaWNhdGlvbiB3aGljaCBp cyBwcm9jZXNzaW5nIGEgbWVzc2FnZSBpcyByZXF1aXJlZCB0bw0KICAgICAgdW5kZXJzdGFuZC4N CnRvOg0KICBUaGUgZmllbGQgaXMgdXNlZCB0byBpbmRpY2F0ZSB3aGljaCBwcm90ZWN0ZWQgaGVh ZGVyIGtleXMNCiAgICAgIGRlZmluZWQgYnkgZXh0ZW5zaW9ucyB0byB0aGlzIHNwZWNpZmljYXRp b24gdGhhdA0KICAgICAgYW4gYXBwbGljYXRpb24gdGhhdCBpcyBwcm9jZXNzaW5nIGEgbWVzc2Fn ZSBpcyByZXF1aXJlZCB0bw0KICAgICAgdW5kZXJzdGFuZC4NCg0KVGhlIGxhbmd1YWdlIHNob3Vs ZCBtYWtlIGl0IGNsZWFyIHRoYXQg4oCcY3JpdOKAnSBpcyBvbmx5IGZvciBkZWZpbmluZyBiZWhh dmlvciBvZiBjcml0aWNhbCBleHRlbnNpb25zIOKAkyBub3QgZm9yIG1ha2luZyBoZWFkZXIgcGFy YW1ldGVycyBkZWZpbmVkIGJ5IHRoaXMgc3BlYyBjcml0aWNhbC4NCltKTFNdIFRoaXMgZG9lcyBu b3QgbWFrZSB0aGluZ3MgY2xlYXJlciB0b21lLg0KDQpmLiAgSW4gVGFibGUgMiwgY2hhbmdlOg0K ICAgfCBqa3UgICAgICB8ICogICAgIHwgdHN0ciAgICAgfCAgICAgICAgICAgfCBVUkwgdG8gQ09T RSBrZXkgb2JqZWN0ICB8DQogICB8ICAgICAgICAgIHwgICAgICAgfCAgICAgICAgICB8ICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgandrICAgICAgfCAqICAgICB8 IENPU0VfS2V5IHwgICAgICAgICAgIHwgY29udGFpbnMgYSBDT1NFIGtleSBub3QgfA0KICAgfCAg ICAgICAgICB8ICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICAgfCBhIEpXSyBrZXkgICAgICAg ICAgICAgICB8DQogICB8ICAgICAgICAgIHwgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCnRvOg0KICAgfCBqa3UgICAgICB8ICogICAgIHwg dHN0ciAgICAgfCAgICAgICAgICAgfCBVUkwgdG8gSldLIFtSRkMgNzUxN10gICB8DQogICB8ICAg ICAgICAgIHwgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgIHwNCiAgfCBja3UgICAgICB8ICogICAgIHwgdHN0ciAgICAgfCAgICAgICAgICAgfCBV UkwgdG8gQ09TRSBrZXkgb2JqZWN0ICB8DQogICB8ICAgICAgICAgIHwgICAgICAgfCAgICAgICAg ICB8ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgY2sgICAgICAg fCAqICAgICB8IENPU0VfS2V5IHwgICAgICAgICAgIHwgY29udGFpbnMgYSBDT1NFIGtleSAgICAg fA0KICAgfCAgICAgICAgICB8ICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICB8DQoNCkl0IHN0aWxsIG1ha2VzIHNlbnNlIHRvIGJlIGFibGUgdG8g cmVwcmVzZW50IFVSTHMgdG8gSldLIGFuZCBDT1NFIEtleSBvYmplY3RzLiAgQnV0IHdlIHNob3Vs ZG7igJl0IGNhbGwgdGhlIENPU0UgS2V5IHBhc3NlZCBieSB2YWx1ZSDigJxqd2vigJ0sIHNpbmNl IHRoYXTigJlzIG1pc2xlYWRpbmcuDQpbSkxTXSBUaHVzIHRoZSBvcGVuIGlzc3VlIG1hcmtlci4N Cg0KZy4gICAgIE9wZW4gSXNzdWUgMS4gIFdoaWNoIG9mIHRoZSBmb2xsb3dpbmcgaXRlbXMgZG8g d2Ugd2FudCB0byBoYXZlIHN0YW5kYXJkaXplZCBpbg0KICAgICAgIHRoaXMgZG9jdW1lbnQ6IGpr dSwgandrLCB4NWMsIHg1dCwgeDV0I1MyNTYsIHg1dSwgemlwPw0KDQpJIHdvdWxkIGtlZXAgYWxs IG9mIHRoZW0sIG90aGVyIHRoYW4gY2hhbmdpbmcg4oCcamt14oCdIGFuZCDigJxqd2vigJ0gdG8g 4oCcamt14oCdLCDigJxja3XigJ0sIGFuZCDigJxja+KAnSBwZXIgKGYpIGFib3ZlLg0KW0pMU10g VGhpcyB3aWxsIGJlIGEgZGlzY3Vzc2lvbiBpc3N1ZS4NCg0KaC4gIE9wZW4gSXNzdWUgMi4gIEkg YW0gY3VycmVudGx5IHRvcm4gb24gdGhlIHF1ZXN0aW9uICJTaG91bGQgZXBrIGFuZCBpdi9ub25j ZSBiZQ0KICAgICAgIGFsZ29yaXRobSBzcGVjaWZpYyBvciBnZW5lcmljIGhlYWRlcnM/Ig0KDQpJ IHdvdWxkIGRlZmluZSBjb21tb24gbGFiZWxzIGZvciB0aGVtIHNpbmNlIHRoZXkgYXJlIGNvbW1v bmx5IHVzZWQgYWNyb3NzIG11bHRpcGxlIGFsZ29yaXRobXMuDQoNCjQuICBTaWduaW5nIFN0cnVj dHVyZQ0KDQoNCmkuICAgICAgICAgICAgICAgICBUaGUgZGVzY3JpcHRpb24gb2Yg4oCccHJvdGVj dGVk4oCdIHNheXMg4oCcVGhlIGZpZWxkIE1VU1QgTk9UIGhvbGQgYXR0cmlidXRlcyBhYm91dCB0 aGUgcGF5bG9hZCBiZWluZyBzaWduZWTigJ0uICBBc3N1bWluZyB0aGF0IGEgZmxhdHRlbmVkIHN5 bnRheCBpcyBhZGRlZCwgdGhpcyB3b3VsZCB0aGVuIGJlY29tZSBzb21ldGhpbmcgbGlrZSDigJxU aGUgZmllbGQgTVVTVCBOT1QgaG9sZCBhdHRyaWJ1dGVzIGFib3V0IHRoZSBwYXlsb2FkIGJlaW5n IHNpZ25lZCB1bmxlc3MgdGhlIGZsYXR0ZW5lZCBzZXJpYWxpemF0aW9uIGlzIGJlaW5nIHVzZWTi gJ0uICBPdGhlciByZWxhdGVkIHN0YXRlbWVudHMgdGhyb3VnaG91dCB0aGUgZG9jdW1lbnQgd291 bGQgbGlrZXdpc2UgbmVlZCB0byBiZSBzaW1pbGFybHkgdXBkYXRlZC4NCltKTFNdIEJ1dCBpdCBp cyBub3QgY3VycmVudCBhZGRlZCDigJMgc28gdGhpcyBpcyBub3QgY3VycmVudGx5IGFuIGFjdGlv bmFibGUgc3RhdGVtZW50Lg0KDQpqLiAgVGhlIGVuZCBvZiB0aGUgc2lnbmluZyBzZWN0aW9uIHNh eXM6DQogICBJbiBhZGRpdGlvbiB0byBwZXJmb3JtaW5nIHRoZSBzaWduYXR1cmUgdmVyaWZpY2F0 aW9uLCBvbmUgbXVzdCBhbHNvDQogICBwZXJmb3JtIHRoZSBhcHByb3ByaWF0ZSBjaGVja3MgdG8g ZW5zdXJlIHRoYXQgdGhlIGtleSBpcyBjb3JyZWN0bHkNCiAgIHBhaXJlZCB3aXRoIHRoZSBzaWdu aW5nIGlkZW50aXR5IGFuZCB0aGF0IHRoZSBhcHByb3ByaWF0ZQ0KICAgYXV0aG9yaXphdGlvbiBp cyBkb25lLg0KDQpUaGVyZSBuZWVkcyB0byBiZSBhIHJlZmVyZW5jZSB0byBhIHBsYWNlIHdoZXJl IHRoZSBwcm9jZXNzIG9mIHZlcmlmeWluZyB0aGUga2V54oCZcyBhc3NvY2lhdGlvbiB3aXRoIHRo ZSBzaWduaW5nIGlkZW50aXR5IGlzIGRlc2NyaWJlZC4gIFBhcnRpY3VsYXIgbWV0aG9kcyBhcmUg Y2xlYXJseSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBidXQgc2F5aW5n IHRoaXMgbGl0dGxlIGFib3V0IHRoZSBwcm9jZXNzIHdpbGwgbGlrZWx5IGp1c3QgbGVhdmUgbWFu eSBwZW9wbGUgY29uZnVzZWQuDQpbSkxTXSBXaGF0IGRvIHlvdSB0aGluayB0aGlzIHNob3VsZCBy ZWZlcmVuY2U/DQoNCjUuICBFbmNyeXB0aW9uIE9iamVjdA0KDQprLiAgVGhlIGludHJvZHVjdGlv biB0byB0aGlzIHNlY3Rpb24gc2F5czoNCiAgIEluIHRoaXMgc2VjdGlvbiB3ZSBkZXNjcmliZSB0 aGUgc3RydWN0dXJlIGFuZCBtZXRob2RzIHRvIGJlIHVzZWQgd2hlbg0KICAgZG9pbmcgYW4gZW5j cnlwdGlvbiBpbiBDT1NFLiAgSW4gQ09TRSwgd2UgdXNlIHRoZSBzYW1lIHRlY2huaXF1ZXMgYW5k DQogICBzdHJ1Y3R1cmVzIGZvciBlbmNyeXB0aW5nIGJvdGggdGhlIHBsYWluIHRleHQgYW5kIHRo ZSBrZXlzIHVzZWQgdG8NCiAgcHJvdGVjdCB0aGUgdGV4dC4gIFRoaXMgaXMgZGlmZmVyZW50IGZy b20gdGhlIGFwcHJvYWNoIHVzZWQgYnkgYm90aA0KICAgW1JGQzU2NTJdIGFuZCBbUkZDNzUxNl0g d2hlcmUgZGlmZmVyZW50IHN0cnVjdHVyZXMgYXJlIHVzZWQgZm9yIHRoZQ0KICAgcGxhaW4gdGV4 dCBhbmQgZm9yIHRoZSBkaWZmZXJlbnQga2V5IG1hbmFnZW1lbnQgdGVjaG5pcXVlcy4NCg0KSeKA mWxsIG5vdGUgdGhhdCBpZiBpc3N1ZSAzIGlzIHJlc29sdmVkIChXcmFwcGVkIGtleXMgc2hvdWxk IGJlIGFibGUgdG8gYmUgcmVwcmVzZW50ZWQgYXMgc2ltcGx5IHRoZSB3cmFwcGVkIGtleSB2YWx1 ZSksIHRoaXMgcGFyYWdyYXBoIHdpbGwgaGF2ZSB0byBiZSByZXZpc2VkIGFjY29yZGluZ2x5Lg0K W0pMU10gQnV0IGN1cnJlbnRseSBub3QgYW4gYWN0aW9uYWJsZSBzdGF0ZW1lbnQuDQoNCmwuICBB IGdlbmVyaWMg4oCcaXbigJ0gKGluaXRpYWxpemF0aW9uIHZlY3RvcikgZmllbGQgc2hvdWxkIGFs c28gYmUgZGVmaW5lZCBpbiB0aGUgbGlzdCBvZiBwYXJhbWV0ZXJzIGZvciB0aGUgZW5jcnlwdGlv biBvYmplY3QuICBZZXMsIG5vdCBhbGwgYWxnb3JpdGhtcyB3aWxsIHVzZSBpdCwgYnV0IG1hbnkg d2lsbC4NCg0KbS4gIEEg4oCcdGFn4oCdIChhdXRoZW50aWNhdGlvbiB0YWcpIGZpZWxkIHNob3Vs ZCBiZSBkZWZpbmVkIGluIHRoZSBsaXN0IG9mIHBhcmFtZXRlcnMgZm9yIHRoZSBlbmNyeXB0aW9u IG9iamVjdC4gIFllcywgbm90IGFsbCB0aGUgYWxnb3JpdGhtcyB3aWxsIHVzZSBpdCwgYnV0IG1h bnkgd2lsbC4NCltKTFNdIE1heWJlIHRydWUgZm9yIOKAmGl24oCZLCBob3dldmVyIOKAmHRhZ+KA mSBpcyBwYXJ0IG9mIHRoZSBjaXBoZXJ0ZXh0Lg0KDQo1LjEuMS4gIERpcmVjdCBFbmNyeXB0aW9u DQoNCm4uICBUaGUgc3BlYyBzYXlzOg0KICAgbyAgQXQgYSBtaW5pbXVtLCB0aGUgJ3VucHJvdGVj dGVkJyBmaWVsZCBNVVNUIGNvbnRhaW4gdGhlICdhbGcnDQogICAgICBwYXJhbWV0ZXIgYW5kIFNI T1VMRCBjb250YWluIGEgcGFyYW1ldGVyIGlkZW50aWZ5aW5nIHRoZSBzaGFyZWQNCiAgICAgIHNl Y3JldC4NCg0KU0hPVUxEIGlzIHRvbyBzdHJvbmcgaGVyZSBiZWNhdXNlIGluIHNvbWUgcHJvdG9j b2xzLCB0aGUgc2hhcmVkIHNlY3JldCB3aWxsIGFscmVhZHkgYmUga25vd24gYnkgbWV0aG9kcyBv dGhlciB0aGFuIGFuIGluY2x1ZGVkIOKAnGtpZOKAnSBvciBvdGhlciBrZXkgc2VsZWN0aW9uIHZh bHVlLiAgQSDigJxTSE9VTEQg4oCmIHVubGVzcyDigKbigJ0gY29uc3RydWN0IGxpa2Ugd2FzIHVz ZWQgaW4gc2ltaWxhciBKT1NFIGRlc2NyaXB0aW9ucyBpcyBwcm9iYWJseSB0aGUgcmlnaHQgdGhp bmcgdG8gdXNlIGhlcmUuDQpbSkxTXSBUaGUg4oCmdW5sZXNz4oCmIGNsYXVzZSBpcyBjb25mdXNp bmcgYXMgaGVsbCBzbyBJIGRvIG5vdCBwbGFuIHRvIGluY2x1ZGUgaXQuICBUaGUgZGVmaW5pdGlv biBvZiBTSE9VTEQgbWVhbnMgdGhhdCBwdXQgaXQgdGhlcmUgdW5sZXNzIHlvdSBoYXZlIGEgZ29v ZCByZWFzb24gbm90IHRvIGRvIHNvLg0KDQo2LiAgTUFDIE9iamVjdHMNCg0Kby4gIFRoZSDigJxI b3cgdG8gY29tcHV0ZSBhIE1BQ+KAnSBpbnN0cnVjdGlvbnMgc2F5Og0KICAgNS4gIEVuY3J5cHQg YW5kIGVuY29kZSB0aGUgTUFDIGtleSBmb3IgZWFjaCByZWNpcGllbnQgb2YgdGhlIG1lc3NhZ2Uu DQoNClRoaXMgaXMgbm90IGNvcnJlY3Qgd2hlbiBkaXJlY3Qga2V5IG1hbmFnZW1lbnQgb3Igbm8g a2V5IG1hbmFnZW1lbnQgaXMgdXNlZC4gIFBsZWFzZSByZXZpc2UgdG8gYWNjdXJhdGVseSBpbmNs dWRlIHRoZXNlIGNhc2VzIGFzIHdlbGwuDQpbSkxTfSBUaGlzIGlzIGNvcnJlY3QgZm9yIHRoZSBj dXJyZW50IGRvY3VtZW50Lg0KDQo3LiAgS2V5IFN0cnVjdHVyZQ0KDQpwLiAgVGhlIHNwZWMgc2F5 czoNCiAgIFRoZSAia2V5X29wcyIgZWxlbWVudCBpcyBwcmVmZXJyZWQgb3ZlciB0aGUgInVzZSIg ZWxlbWVudCBhcyB0aGUNCiAgIGluZm9ybWF0aW9uIHByb3ZpZGVkIHRoYXQgd2F5IGlzIG1vcmUg ZmluZWx5IGRldGFpbGVkIGFib3V0IHRoZQ0KICAgb3BlcmF0aW9ucyBhbGxvd2VkLiAgSXQgaXMg c3Ryb25nbHkgc3VnZ2VzdGVkIHRoYXQgdGhpcyBlbGVtZW50IGJlDQogICBwcmVzZW50IGZvciBh bGwga2V5cy4NCg0KTGlrZSBpbiAobiksIHRoZSBhcHBsaWNhdGlvbiBtYXkga25vdyB0aGUga2V5 IHVzYWdlIGZyb20gYXBwbGljYXRpb24gY29udGV4dCwgcmVuZGVyaW5nIHRoZSBpbmNsdXNpb24g b2Yg4oCca2V5X29wc+KAnSB1bm5lY2Vzc2FyeS4gIExhbmd1YWdlIHNvbWV0aGluZyBsaWtlIOKA nEl0IGlzIHN0cm9uZ2x5IHN1Z2dlc3RlZCB0aGF0IHRoaXMgZWxlbWVudCBiZSBwcmVzZW50IGZv ciBhbGwga2V5cyB1bmxlc3MgdGhpcyBpbmZvcm1hdGlvbiBpcyBhbHJlYWR5IGtub3cgdG8gdGhl IGFwcGxpY2F0aW9uIHRocm91Z2ggb3RoZXIgbWVhbnPigJ0gc2hvdWxkIGJlIHVzZWQgdG8gY2Fw dHVyZSB0aGlzLg0KDQpUaGUgd29ya2luZyBncm91cCBzaG91bGQgYWxzbyBkaXNjdXNzIHdoZXRo ZXIgaXQgd2FudHMgdG8gY2FycnkgZm9yd2FyZCDigJx1c2XigJ0gZm9yIEpXSyBjb21wYXRpYmls aXR5LCBldmVuIGlmIGl0IGlzIGRlcHJlY2F0ZWQuICBJIHBlcnNvbmFsbHkgd291bGQgYmUgaW4g ZmF2b3Igb2YgZG9pbmcgc28uDQpbSkxTXSBJZiB5b3UgdGhpbmsgdGhpcywgdGhlbiBwbGVhc2Ug b3BlbiBpdCBhcyBhIGRpc2N1c3Npb24gaXNzdWUuICBJIGRvbuKAmXQgc2VlIGFueSBnb29kIHVz ZSBmb3IgaXQgdGhhdCBpcyBub3QgYmV0dGVyIHNlcnZlZCBieSDigJhrZXlfb3Bz4oCZLiAgVGhp cyBpcyBkb3VibHkgdHJ1ZSBnaXZlbiB0aGF0IHRoZSBXM0MgQ3J5cHRvIGdyb3VwDQoNCnEuICBJ IHdvdWxkIGRlZmluZSBzaG9ydCBudW1lcmljIHZhbHVlcyB0aGF0IGNvcnJlc3BvbmQgdG8gdGhl IGRlZmluZXMg4oCca2V5X29wc+KAnSBzdHJpbmcgdmFsdWVzLiAgSeKAmWQgZG8gdGhlIHNhbWUg Zm9yIHRoZSDigJx1c2XigJ0gdmFsdWVzLg0KW0pMU10gWWVzIHRoaXMgd2lsbCBiZSBoYXBwZW5p bmcgZ29pbmcgZm9yd2FyZC4NCg0KOC4gIENCT1IgRW5jb2RlciBSZXN0cmljdGlvbnMNCg0Kci4g IFRoZSBzcGVjIHNheXM6DQogICBvICBBbGwgcGFyc2VycyB1c2VkIFNIT1VMRCBmYWlsIG9uIGJv dGggcGFyc2luZyBhbmQgZ2VuZXJhdGlvbiBpZiB0aGUNCiAgICAgIHNhbWUgbGFiZWwgaXMgdXNl ZCB0d2ljZSBhcyBhIGtleSBmb3IgdGhlIHNhbWUgbWFwLg0KDQpJIHdvdWxkIHN0cm9uZ2x5IHBy ZWZlciB0aGF0IHRoZSDigJxTSE9VTETigJ0gYmUgY2hhbmdlZCB0byDigJxNVVNU4oCdLiAgQ0JP UiBkb2VzbuKAmXQgaGF2ZSB0aGUgc2FtZSBsZWdhY3kgb2YgbGF4IHBhcnNlcnMgdGhhdCB3ZSBp bmhlcml0ZWQgZnJvbSBKYXZhU2NyaXB0L0VDTUFzY3JpcHQgZm9yIEpTT04uICBMZXTigJlzIG5v dCBvcGVuIHRoZSBkb29yIHRvIHRoZW0hDQoNCjkuNSAgQ09TRSBBbGdvcml0aG0gUmVnaXN0cnkN Cg0Kcy4gIEkgd291bGQgYWRkIGFuIGFkZGl0aW9uYWwg4oCcSk9TRSBhbGdvcml0aG0gbmFtZeKA nSBmaWVsZCB0byB0aGlzIHJlZ2lzdHJ5LCB3aG9zZSB2YWx1ZSBpcyB0aGUgY29ycmVzcG9uZGlu ZyDigJxBbGdvcml0aG0gTmFtZeKAnSBlbnRyeSBpbiB0aGUgSUFOQSBKU09OIFdlYiBTaWduYXR1 cmUgYW5kIEVuY3J5cHRpb24gQWxnb3JpdGhtcyByZWdpc3RyeSBhdCBodHRwOi8vd3d3LmlhbmEu b3JnL2Fzc2lnbm1lbnRzL2pvc2Uvam9zZS54aHRtbCN3ZWItc2lnbmF0dXJlLWVuY3J5cHRpb24t YWxnb3JpdGhtcywgaWYgc3VjaCBhbiBlbnRyeSBleGlzdHMuICBUaGlzIHdpbGwgdGllIHRoZSB0 d28gcmVnaXN0cmllcyB0b2dldGhlciBzbyB0aGF0IGRlZmluaXRpb25zIG9mIGFsZ29yaXRobXMg YWxyZWFkeSBkZWZpbmVkIGJ5IEpPU0UgbmVlZCBub3QgYmUgcmVwZWF0ZWQgZm9yIENPU0UuDQoN CkluIG1hbnkgY2FzZXMgdGhlbiwgdGhlIENPU0UgYWxnb3JpdGhtcyBkcmFmdCAob3Igc2VjdGlv bikgY2FuIGp1c3QgY2l0ZSB0aGUgZGVmaW5pdGlvbiBpbiBSRkMgNzUxOCBhbmQgcmVnaXN0ZXIg dGhlIGNvcnJlc3BvbmRpbmcgc2hvcnQgbnVtZXJpYyBsYWJlbCBmb3IgQ09TRSB1c2UuDQpbSkxT XSBEbyB3ZSBoYXZlIGEgcmVhc29uIHRvIGJlbGlldmUgdGhhdCBDT1NFIGltcGxlbWVudGVycyBh cmUgZ29pbmcgdG8gaGF2ZSBhIGxhcmdlciBvdmVybGFwIHdpdGggSk9TRSBpbXBsZW1lbnRlcnM/ DQoNCjkuOC4xICBDT1NFIFNlY3VyaXR5IE1lc3NhZ2UNCg0KdC4gIEJlc2lkZXMgcmVnaXN0ZXJp bmcgdGhlIE1JTUUgdHlwZSDigJxhcHBsaWNhdGlvbi9jb3Nl4oCdLCBJIHdvdWxkIGFsc28gcmVn aXN0ZXIgb25lIGZvciBhIGJhc2U2NHVybCBlbmNvZGVkIENPU0UgbWVzc2FnZSDigJMgYW4gaWRl YSBmaXJzdCBkZXNjcmliZWQgdG8gbWUgYnkgSm9lIEhpbGRlYnJhbmQuICBJdCBjb3VsZCBiZSBj YWxsZWQg4oCcYXBwbGljYXRpb24vY29zZStiYXNlNjR1cmzigJ0gb3Igc29tZXRoaW5nIG9mIHRo YXQgaWxrLg0KW0pMU10gIEkgd291bGQgZXhwZWN0IHRoZSBtZWRpYS10eXBlIHJldmlld2VycyB0 byBvYmplY3QgdG8gdGhhdCBiZWNhdXNlIHRoaXMgaXMgYSB0cmFuc3BvcnQgZW5jb2Rpbmcgbm90 IGEgY29udGVudCBlbmNvZGluZy4gIERvIHlvdSBoYXZlIGEgcmVhc29uIHRvIGJlbGlldmUgb3Ro ZXJ3aXNlPw0KDQo5LjguMiAgQ09TRSBLZXkgTWVkaWEgVHlwZQ0KDQp1LiAg4oCcYXBwbGljYXRp b24vandrK2pzb27igJ0gc2hvdWxkIGJlIGNoYW5nZWQgdG8gc29tZXRoaW5nIGxpa2Ug4oCcYXBw bGljYXRpb24vY29zZS1rZXnigJ0gYW5kIOKAnGFwcGxpY2F0aW9uL2p3ay1zZXQranNvbuKAnSBz aG91bGQgYmUgY2hhbmdlZCB0byBzb21ldGhpbmcgbGlrZSDigJxhcHBsaWNhdGlvbi9jb3NlLWtl eS1zZXTigJ0uDQoNCjExLjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCnYuICBUaGUgZGF0 ZSBvbiB0aGUgQUVTLUdDTSByZWZlcmVuY2UgKFNQIDgwMC0zOEQpIHNob3VsZCBiZSBOb3ZlbWJl ciAyMDA3IOKAkyBub3QgSnVuZSAyMDE1Lg0KDQpBcHBlbmRpeCBBLiAgQUVBRCBhbmQgQUUgQWxn b3JpdGhtcw0KDQp3LiAgVGhlIHNwZWMgc2F5czoNCiAgVGhpcyBhdXRoZW50aWNhdGlvbiB2YWx1 ZSBtYXkgYmU6DQogICBvICBBIHNlcGFyYXRlbHkgZ2VuZXJhdGVkIHRhZyBjb21wdXRlZCBieSBi b3RoIHRoZSBlbmNyeXB0ZXIgYW5kDQogICAgICBkZWNyeXB0ZXIgYW5kIHRoZW4gY29tcGFyZWQg YnkgdGhlIGRlY3J5cHRvci4gIFRoaXMgdGFnIHZhbHVlIG1heQ0KICAgICAgYmUgZWl0aGVyIHBs YWNlZCBhdCB0aGUgZW5kIG9mIHRoZSBjaXBoZXIgdGV4dCAodGhlIGRlY2lzaW9uIHdlDQogICAg ICBtYWRlKSBvciBrZXB0IHNlcGFyYXRlbHkgKHRoZSBkZWNpc2lvbiBtYWRlIGJ5IHRoZSBKT1NF IHdvcmtpbmcNCiAgICAgIGdyb3VwKS4gIFRoaXMgaXMgdGhlIGFwcHJvYWNoIGZvbGxvd2VkIGJ5 IEFFUy1HQ00gW0FFUy1HQ01dIGFuZA0KICAgICAgQUVTLUNDTSBbUkZDMzYxMF0uDQoNClRoZSBs YXN0IHNlbnRlbmNlIGlzIG5vdCB0cnVlLCBhcyB3cml0dGVuLiAgVGhlIEFFUy1HQ00gc3BlYyBk ZXNjcmliZXMg4oCcdGhlIGNpcGhlcnRleHQgYW5kIHRhZyBvdXRwdXRz4oCdIOKAkyBub3QgYSBz aW5nbGUgY29tYmluZWQgb3V0cHV0LiAgQ29tbW9uIGltcGxlbWVudGF0aW9ucyBjb3JyZXNwb25k IHRvIHRoaXMsIHN1Y2ggYXMgdGhlIGltcGxlbWVudGF0aW9uIG9mIEdDTSBpbiAuTkVULg0KDQpU aGUgQ0NNIGRlc2NyaXB0aW9uIGluIFJGQyAzNjEwIFNlY3Rpb24gMi40IGRlc2NyaWJlcyB0aGUg b3V0cHV0IHVzaW5nIHRoZSB0ZXh0IOKAnFRoZSBmaW5hbCByZXN1bHQgYyBjb25zaXN0cyBvZiB0 aGUgZW5jcnlwdGVkIG1lc3NhZ2UgZm9sbG93ZWQgYnkgdGhlIGVuY3J5cHRlZCBhdXRoZW50aWNh dGlvbiB2YWx1ZSBV4oCdLCB3aGljaCBhZG1pdHMgZWl0aGVyIGltcGxlbWVudGF0aW9uLiAgTGlr ZXdpc2UsIGF0IGxlYXN0IHRoZSAuTkVUIENDTSBpbXBsZW1lbnRhdGlvbiBwcm9kdWNlcyBzZXBh cmF0ZSBjaXBoZXJ0ZXh0IGFuZCBhdXRoZW50aWNhdGlvbiB0YWcgdmFsdWVzLg0KDQpXaGV0aGVy IHRoZSB0YWcgc2hvdWxkIGJlIHNlcGFyYXRlIG9yIGF1dG9tYXRpY2FsbHkgYXBwZW5kZWQgdG8g dGhlIGNpcGhlcnRleHQgaXNu4oCZdCBhIGhpbGwgSeKAmW0gZ29pbmcgdG8gZGllIG9uIChhbHRo b3VnaCB0aGUgd29ya2luZyBncm91cCBzaG91bGQgZGlzY3VzcyB0aGlzIGFuZCBtYWtlIGFuIGV4 cGxpY2l0IGRlY2lzaW9uIGluIHRoaXMgcmVnYXJkKSwgYnV0IHRoZSB0ZXh0IGRlc2NyaWJpbmcg dGhlIGRlY2lzaW9uIHNob3VsZCBhdCBsZWFzdCBiZSBjaGFuZ2VkIHRvIGJlIGFjY3VyYXRlLg0K DQpbSkxTXSBXcm9uZyByZWZlcmVuY2Ug4oCTd2lsbCBjb3JyZWN0Lg0KDQpBcHBlbmRpeCBDLiAg RXhhbXBsZXMNCg0KeC4gIFRoZSB1c2VzIG9mIHN0cmluZ3MgYW5kIGNvcnJlc3BvbmRpbmcgbGFi ZWxzIHN1Y2ggYXMgdGhvc2UgdGhhdCBmb2xsb3cgYXJlIGNvbmZ1c2luZyDigJMgZXNwZWNpYWxs eSBzaW5jZSBrZXkgSUQgdmFsdWVzIGFyZSBiaW5hcnkgaW4gQ09TRS4gIEEgZnJhZ21lbnQgb2Yg c3VjaCBhbiBleGFtcGxlIHRoYXQgY29uZnVzZWQgbWUgd2FzOg0KICAgICAgICAgMzogew0KICAg ICAgICAgICA1OiAiYmlsYm8uYmFnZ2luc0Bob2JiaXRvbi5leGFtcGxlPG1haWx0bzpiaWxiby5i YWdnaW5zQGhvYmJpdG9uLmV4YW1wbGU+Ig0KICAgICAgICAgfSwNCg0KVGhlcmUgYXJlIHNpbWls YXIgc3RyaW5ncyBpbiBzb21lIG9mIHRoZSBvdGhlciBleGFtcGxlcyB0aGF0IEkgYWxzbyBjb3Vs ZG7igJl0IHdyYXAgbXkgaGVhZCBhcm91bmQuDQpbSkxTXSBNeSBjb2RlIGRvZXMgbm90IG1hdGNo IHRoZSBzcGVjIGhlcmUuICBPcmlnaW5hbGx5IHRoZXkgd2VyZSBzdHJpbmdzLg0KDQpBcHBlbmRp eCBELiAgQ09TRSBIZWFkZXIgQWxnb3JpdGhtIExhYmVsIFRhYmxlDQoNCnkuICBJIHdvdWxkIGNo YW5nZSB0aGUgdGVybSDigJxIZWFkZXIgQWxnb3JpdGht4oCdIHRvIOKAnEhlYWRlciBQYXJhbWV0 ZXLigJ0uICAoSSBzdXNwZWN0IHRoaXMgd2FzIGEgY3V0LWFuZC1wYXN0ZSBlcnJvci4pDQpbSkxT XSBJIGhhdmUgbm90IHNldHRsZWQgb24gYSBjb25zaXN0ZW50IHNldCBvZiB0ZXJtcyBmb3IgdGhp cyB5ZXQuICBJIG5lZWQgdG8gZG8gc28gYW5kIHRoZW4gbWFrZSBhIHBhc3MgdG8gY29ycmVjdCB0 aGVtIGFsbC4gIEkgZG9u4oCZdCB0aGluayB0aGF0IHNvbWUgb2YgdGhlIHRlcm1zIEkgYW0gY3Vy cmVudGx5IHVzaW5nIGFyZSBzdWZmaWNpZW50bHkgZGlzdGluY3QgdG8gbWFrZSBpdCBlYXN5IHRv IGZpZ3VyZSB0aGluZ3Mgb3V0Lg0KDQp6LiAgSW4gQXBwZW5kaXggRCBhbmQgQXBwZW5kaXggRSwg SSB3b3VsZCBjYWxsIG91dCB0aGF0IHRoZSBuYW1lcyBpbiB0aGUg4oCcbmFtZeKAnSBjb2x1bW5z IGNvcnJlc3BvbmQgdG8gbmFtZXMgZGVmaW5lZCBpbiBSRkMgNzUxOC4NCltKTFNdIFRoZXNlIHRh YmxlcyBhcmUgZGlzYXBwZWFyaW5nIGFzIHBhcnQgb2YgdGhlIGFkZCB0aGUgYWxnb3JpdGhtcyB0 byB0aGUgZG9jdW1lbnQgZXhlcmNpc2UuDQoNCkFwcGVuZGl4IEYuICBDT1NFIEdlbmVyYWwgVmFs dWVzDQoNCmFhLiAgVGhpcyBzZWVtcyBjb25mdXNlZCwgYXMgaXQgbWl4ZXMg4oCca3R54oCdIHZh bHVlcyAoRUM9MSwgUlNBPTIsIG9jdD0zKSB3aXRoIGN1cnZlIHZhbHVlcyAoUDI1Nj00LCBQNTIx PTUpLiAgSSB3b3VsZCBrZWVwIHRoZXNlIHNlcGFyYXRlLiAgQWxzbywgd2hlcmV2ZXIgdGhlIGN1 cnZlIG5hbWVzIGFyZSBkZWZpbmVkLCBJIHdvdWxkIGFsc28gaW5jbHVkZSBQMzg0LCBhcyBKT1NF IGRpZC4NCltKTFNdIFRoYXQgbWF5IGhhcHBlbiBpbiB0aGUgZnV0dXJlLiAgSSBqdXN0IG5lZWRl ZCBhIHRhYmxlIHRvIHB1dCB0aGluZ3MgaW4gZm9yIG5vdy4NCg0KTklUUw0KDQpJIHdpbGwgYmUg c3VibWl0dGluZyBzcGVsbGluZyBhbmQgZ3JhbW1hciBjb3JyZWN0aW9ucyBhcyBhIEdpdEh1YiBw dWxsIHJlcXVlc3QgYWdhaW5zdCB0aGUgc3BlYyByZXBvc2l0b3J5IHJhdGhlciB0aGFuIGRldGFp bCB0aGVtIGhlcmUuICBJ4oCZbGwgcG9zdCB0aGUgcHVsbCByZXF1ZXN0IGxpbmsgb25jZSBpdOKA mXMgYmVlbiBjcmVhdGVkLg0KDQpDT05DTFVTSU9OUw0KDQpJ4oCZZCBsaWtlIHRvIHRoYW5rIEpp bSBmb3IgZG9pbmcgdGhlIHdvcmsgdG8gcHJvZHVjZSBhIHdlbGwtdGhvdWdodC1vdXQgaW5pdGlh bCBkcmFmdC4gIEkgYmVsaWV2ZSBpdCBwcm92aWRlcyBhIHNvbGlkIHN0YXJ0aW5nIHBvaW50IGZv ciB0aGUgQ09TRSB3b3JrLg0KDQpJ4oCZZCBiZSB3aWxsaW5nIHRvIHByb2R1Y2Ugc3BlY2lmaWMg cHJvcG9zZWQgZWRpdHMgZm9yIGFueS9hbGwgb2YgdGhlIGFib3ZlIGlzc3VlcyBhbmQgY29tbWVu dHMsIHNob3VsZCB0aGUgZWRpdG9ycyBmaW5kIHRoYXQgdXNlZnVsLg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCZXN0IHdpc2hl cywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIC0tIE1pa2UNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkNvc2UgbWFpbGluZyBsaXN0DQpDb3NlQGlldGYub3JnPG1haWx0bzpDb3NlQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNvc2UgbWFp bGluZyBsaXN0DQpDb3NlQGlldGYub3JnPG1haWx0bzpDb3NlQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlDQoNCg== --_000_BY2PR03MB4427AB173398F8C37E49B9CF5920BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu TXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24g VGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJh bGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4u RW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlLWFza2luZyBCcmlh buKAmXMgcXVlc3Rpb24sIHdoYXQgZG8geW91IHNlZSBhcyB0aGUgcHVycG9zZSBvZiBrZXkgbWFu YWdlbWVudCBmb3IgTUFDcywgSmltICh3aGVyZSDigJxrZXkgbWFuYWdlbWVudOKAnSBpcyBiZWlu ZyB1c2VkIGluIHRoZSBzYW1lIHdheSB0aGF0IENNUw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7Cpzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+MTIuMyB1c2VkIHRoZSB0ZXJtKT88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiBKaW0gU2NoYWFkIFttYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbV0NCjxicj4NCjxi PlNlbnQ6PC9iPiBUdWVzZGF5LCBKdWx5IDA3LCAyMDE1IDM6NDEgUE08YnI+DQo8Yj5Ubzo8L2I+ ICdCcmlhbiBDYW1wYmVsbCc7ICdKdXN0aW4gUmljaGVyJzxicj4NCjxiPkNjOjwvYj4gTWlrZSBK b25lczsgY29zZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0Nvc2VdIFJldmll dyBvZiBkcmFmdC1zY2hhYWQtY29zZS1tc2ctMDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSBhbSBtb3JlIHRoYW4gd2lsbGluZyB0byBoYXZlIGEgZGlmZmVyZW50IHRlcm0gZm9y IOKAnEtleSBNYW5hZ2VtZW504oCdLiZuYnNwOyBIb3dldmVyLCBJIGhhdmUgaW5oZXJpdGVkIHRo ZSB0ZXJtIGZyb20gQ01TIChSRkMgMjYzMCkgd2hlcmUgc2VjdGlvbiAxMi4zIHRhbGtzIGFib3V0 DQoga2V5IG1hbmFnZW1lbnQgYWxnb3JpdGhtcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoYXQgeW91IHJlIHJlZmVy cmluZyB0byBiZWxvdywgSSBnZW5lcmFsbHkgcHV0IHVuZGVyIHRoZSB0ZXJtIG9mIGtleSBsaWZl IGN5Y2xlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5KaW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQnJpYW4gQ2Ft cGJlbGwgWzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSI+bWFpbHRv OmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVz ZGF5LCBKdWx5IDA3LCAyMDE1IDE6MzYgUE08YnI+DQo8Yj5Ubzo8L2I+IEp1c3RpbiBSaWNoZXI8 YnI+DQo8Yj5DYzo8L2I+IE1pa2UgSm9uZXM7IEppbSBTY2hhYWQ7IDxhIGhyZWY9Im1haWx0bzpj b3NlQGlldGYub3JnIj5jb3NlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W0Nvc2VdIFJldmlldyBvZiBkcmFmdC1zY2hhYWQtY29zZS1tc2ctMDE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+W3dlYXJpbmcgbXkgY293Ym95 IGhhdCBmcm9tIERhbGxhczopXTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgdGhpbmsgdGhlIHRlcm0gJnF1 b3Q7a2V5IG1hbmFnZW1lbnQmcXVvdDsgaGFzIGdvdHRlbiBhIGxpdHRsZSBvdmVybG9hZGVkIGhl cmUuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JIGJlbGlldmUgdGhlIGNoYXJ0ZXIgdXNlcyB0aGUgdGVy bSBpbiB0aGUgYnJvYWRlciBhbmQgdHJhZGl0aW9uYWwgc2Vuc2UgdGhhdA0KPGEgaHJlZj0iaHR0 cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvS2V5X21hbmFnZW1lbnQiIHRhcmdldD0iX2JsYW5r Ij5XaWtpcGVkaWE8L2E+LCBmb3IgZXhhbXBsZSwgdGFsa3MgYWJvdXQgaXQsIGxpa2UgJnF1b3Q7 ZGVhbGluZyB3aXRoIHRoZSBnZW5lcmF0aW9uLCBleGNoYW5nZSwgc3RvcmFnZSwgdXNlLCBhbmQg cmVwbGFjZW1lbnQgb2Yga2V5cyZxdW90OyBpbmNsdWRpbmcgJnF1b3Q7a2V5IHNlcnZlcnMgW2Fu ZF0gdXNlciBwcm9jZWR1cmVzLiZxdW90Ow0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+V2hlcmVhcyB0aGUg dGVybSBzZWVtZWQgdG8gZ2V0IHNvbWV3aGF0IGNvLW9wdGVkIGluIEpPU0UgYXMgYSBjYXRjaCBh bGwgdG8gY292ZXIgYWxsIHRoZSBtZXNzYWdlIGxldmVsIGtleSBlbmNyeXB0aW9uLCBrZXkgZW5j YXBzdWxhdGlvbiwgYW5kIGtleSBhZ3JlZW1lbnQgYml0cyB0aGF0IGFyZSBuZWVkZWQgdG8gY29u dmV5IGFuZCBwcm90ZWN0IGEgY29udGVudA0KIGVuY3J5cHRpb24ga2V5IGZvciBlbmNyeXB0aW9u LiBBbmQgdGhhdCB1c2FnZSBoYXMgY2FycmllZCBvdmVyIGludG8gQ09TRS4gPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPkNPU0UgbmVlZHMgJnF1b3Q7a2V5IG1hbmFnZW1lbnQmcXVvdDsgaW4gdGhl IGxhdHRlciBzZW5zZSBvZiB0aGUgd29yZC4gTWF5YmUgaXQgc2hvdWxkIGJlIGNhbGxlZCBzb21l dGhpbmcgZWxzZSBidXQgaXQncyBhIG5lY2Vzc2l0eSBmb3IgZW5jcnlwdGlvbi4gTXkgcXVlc3Rp b24gdGhlIG90aGVyIGRheSB3YXMgYWJvdXQgdGhlIHdoYXQgdmFsdWUgdGhlcmUgaXMgaW4gZG9p bmcNCiBpdCBmb3IgTUFDIGtleXMuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBzdXNwZWN0IHRoZSAmcXVvdDtLZXkgbWFuYWdlbWVudCBhbmQg YmluZGluZyBvZiBrZXlzIHRvIGlkZW50aXRpZXMgYXJlIG91dCBvZiBzY29wZSZxdW90OyBpbiB0 aGUgZm9ybWVyIHNlbnNlIGluIHRoZSBjaGFydGVyIGlzIGludGVuZGVkIHRvIGtlZXAgQ09TRSBz Y29wZSByZWFzb25hYmx5IGNvbnN0cmFpbmVkLiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCiZuYnNwOyAmbmJzcDsgPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgSnVsIDcsIDIwMTUg YXQgMTo1NCBQTSwgSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0 LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGVyaGFwcyBJ4oCZbSBtaXNzaW5nIHNv bWV0aGluZywgYnV0IGFzIGNoYWlyIEkgZmVlbCB0aGUgbmVlZCB0byBwb2ludCBvdXQgdGhpcyBs aW5lIGluIG91ciBjdXJyZW50IGNoYXJ0ZXIgZm9yIHlvdSBhbGwgdG8gY29uc2lkZXI6PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwcmU+S2V5IG1hbmFnZW1lbnQgYW5kIGJpbmRpbmcgb2Yga2V5cyB0byBpZGVudGl0aWVzIGFy ZSBvdXQgb2Ygc2NvcGUgZm9yIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8 cHJlPndvcmtpbmcgZ3JvdXAuPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A74oCU IEp1c3RpbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEp1bCA3LCAyMDE1LCBhdCAzOjUwIFBNLCBNaWtlIEpv bmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJn ZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Smlt LCBJIGhhZG7igJl0IHNlZW4gYW4gYW5zd2VyIHRvIHRoaXMgcXVlc3Rpb24uJm5ic3A7IElmIHRo ZSB0aHJlYWQgeW914oCZcmUgcmVmZXJyaW5nIHRvIGlzIOKAnEtleSBtYW5hZ2VtZW50IGluIHRo ZSBXb3JsZCBvZiBDT1NF4oCdLCBteSBpbXByZXNzaW9uIGlzIHRoYXQgc29tZQ0KIHBlb3BsZSB0 YWxrZWQgYWJvdXQgdXNlIGNhc2VzLCBidXQgdGhlcmUgd2VyZSBubyBhY3R1YWwgY29uY2x1c2lv bnMgZHJhd24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QWxzbywg Y291bGQgeW91IGFuc3dlciBCcmlhbiBDYW1wYmVsbOKAmXMgcXVlc3Rpb24gaW4gdGhlIHJlbGF0 ZWQgdGhyZWFkIOKAnEtleSBtYW5hZ2VtZW50IGZvciBNQUNzICh3YXMgUmU6IFtDb3NlXSBSZXZp ZXcgb2YgZHJhZnQtc2NoYWFkLWNvc2UtbXNnLTAxKeKAnT8mbmJzcDsNCiBBcyBJIHNhaWQgaW4g bXkgcmVwbHksIEkgY29tcGxldGVseSB1bmRlcnN0YW5kIHRoZSB2YWx1ZSBvZiBrZXkgbWFuYWdl bWVudCBmb3IgZW5jcnlwdGlvbiwgaW4gd2hpY2ggdGhlcmUgYXJlIHNlY3JldHMgdG8gcHJvdGVj dCwgYnV0IG5vdCBmb3IgTUFDcywgd2hlcmUgdGhlcmUgYXJlIG5vdC48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgVGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE1pa2UgSm9uZXMNCjxicj4NCjxiPlNlbnQ6PC9i PiBUdWVzZGF5LCBKdW5lIDMwLCAyMDE1IDI6NTQgUE08YnI+DQo8Yj5Ubzo8L2I+ICdKaW0gU2No YWFkJzsgPGEgaHJlZj0ibWFpbHRvOmNvc2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jb3Nl QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0Nvc2VdIFJldmlldyBvZiBk cmFmdC1zY2hhYWQtY29zZS1tc2ctMDE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkppbSwgaXMgdGhl IGRpc2N1c3Npb24geW914oCZcmUgcmVmZXJyaW5nIHRvIGZvciBteSBpc3N1ZSAyIHRoZSB0aHJl YWQg4oCcS2V5IG1hbmFnZW1lbnQgaW4gdGhlIFdvcmxkIG9mIENPU0XigJ0gb3IgaXMgdGhlcmUg YW4gYWRkaXRpb25hbCB0aHJlYWQgeW914oCZcmUgcmVmZXJyaW5nDQogdG8/PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEpp bSBTY2hhYWQgWzxhIGhyZWY9Im1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tIiB0YXJnZXQ9 Il9ibGFuayI+bWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb208L2E+XQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IFNhdHVyZGF5LCBKdW5lIDI3LCAyMDE1IDg6MjUgQU08YnI+DQo8Yj5Ubzo8L2I+IE1p a2UgSm9uZXM7IDxhIGhyZWY9Im1haWx0bzpjb3NlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ Y29zZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtDb3NlXSBSZXZpZXcg b2YgZHJhZnQtc2NoYWFkLWNvc2UtbXNnLTAxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IENvc2UgWzxhIGhyZWY9Im1haWx0bzpjb3NlLWJv dW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86Y29zZS1ib3VuY2VzQGlldGYu b3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TWlrZSBKb25lczxicj4NCjxiPlNlbnQ6PC9i PiBTYXR1cmRheSwgSnVuZSAyNywgMjAxNSAyOjA3IEFNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVm PSJtYWlsdG86Y29zZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNvc2VAaWV0Zi5vcmc8L2E+ PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtDb3NlXSBSZXZpZXcgb2YgZHJhZnQtc2NoYWFkLWNvc2Ut bXNnLTAxPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW4gcmVz cG9uc2UgdG8gdGhlIGNhbGwgZm9yIGFkb3B0aW9uLCBJ4oCZbSBzdWJtaXR0aW5nIHRoZSBmb2xs b3dpbmcgcmV2aWV3IGZlZWRiYWNrIG9uDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1zY2hhYWQtY29zZS1tc2ctMDEiIHRhcmdldD0iX2JsYW5rIj5kcmFmdC1zY2hh YWQtY29zZS1tc2ctMDE8L2E+LiZuYnNwOyBNb3N0IG9mIHRoZSBtYWpvciBjb21tZW50cyBhcmUg bW90aXZhdGVkIGJ5IHRoZSBnb2FsIG9mIOKAnGtlZXBpbmcgc2ltcGxlIHRoaW5ncyBzaW1wbGXi gJ0uJm5ic3A7IFBhcnRpY3VsYXJseSBpbiBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMsIGl04oCZ cyBsaWtlbHkgdG8gYmUNCiBub3JtYWwgZm9yIGltcGxlbWVudGF0aW9ucyB0byB1c2Ugb25seSB0 aGUgcGFydHMgb2YgQ09TRSB0aGV5IHRoZWlyIGFwcGxpY2F0aW9uIG5lZWRzLiZuYnNwOyBJIGJl bGlldmUgdGhhdCB3ZSBzaG91bGQgdGhlcmVmb3JlIG9wdGltaXplIHRoZSByZXByZXNlbnRhdGlv bnMgd2UgZGVmaW5lIGZvciB0aGUgY29tbW9uIGNhc2VzLCB3aGlsZSBtYWtpbmcgaXQgcG9zc2li bGUgdG8gYWxzbyBncmFjZWZ1bGx5IGFjY29tbW9kYXRlIGxlc3MgY29tbW9uLCBpZg0KIHBvc3Np Ymx5IG1vcmUgZ2VuZXJhbCBjYXNlcyBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+QWxzbywgZ2l2ZW4gbXkgcm9sZSBhcyBhIGRlc2lnbmVyIGFuZCBlZGl0b3Igb2YgdGhlIEpP U0Ugc3BlY3MsIEnigJlsbCBzYXkgZXhwbGljaXRseSB0aGF0IGl04oCZcyBub3QgbXkgZ29hbCB0 byB0cnkgdG8gaGF2ZSBhbGwgdGhlIGRlY2lzaW9ucyBpbiBDT1NFIGV4YWN0bHkgbWlycm9yIHRo b3NlIGluIEpPU0UuJm5ic3A7DQogU29tZSB0aGluZ3MgY2FuIGNsZWFybHkgYmUgc2ltcGxpZmll ZCBmb3IgQ09TRSwgYW5kIEnigJltIGFsbCBmb3IgdGhhdC4mbmJzcDsgSSBwbGFuIHRvIGNvbnNp ZGVyIGVhY2ggaXNzdWUgb24gaXRzIGluZGl2aWR1YWwgbWVyaXRzLiZuYnNwOyBUaGF0IHNhaWQs IGhlcmXigJlzIG15IHJldmlld+KApjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+TUFK T1IgSVNTVUVTPC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+MS4mbmJzcDsgUmVw cmVzZW50YXRpb25zIHNob3VsZCBiZSBvcHRpbWl6ZWQgZm9yIHRoZSBzaW5nbGUgcmVjaXBpZW50 IGNhc2UuPC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW4gSk9TRSwgZ29pbmcgaW50 byBJRVNHIHJldmlldywg4oCcc2lnbmF0dXJlc+KAnSBvciDigJxyZWNpcGllbnRz4oCdIGFycmF5 cyB3ZXJlIHJlcXVpcmVkIGZvciB0aGUgSlNPTiBTZXJpYWxpemF0aW9ucywgd2l0aCBvbmx5IGdl bmVyYWwgbXVsdGktc2lnbmF0dXJlL211bHRpLXJlY2lwaWVudCByZXByZXNlbnRhdGlvbnMNCiBi ZWluZyBkZWZpbmVkIGZvciBKV1MgYW5kIEpXRS4mbmJzcDsgQmFzZWQgb24gZmVlZGJhY2sgZnJv bSBudW1lcm91cyBkZXZlbG9wZXJzIHdobyB3ZXJlIHVzaW5nIEpPU0UgZm9yIHVzZSBjYXNlcyB0 aGF0IG9ubHkgZXZlciB1c2VkIGEgc2luZ2xlIHNpZ25hdHVyZSBvciByZWNpcGllbnQsIFJpY2hh cmQgQmFybmVzIGFza2VkIHRoYXQgdGhlIEZsYXR0ZW5lZCBzZXJpYWxpemF0aW9ucyBiZSBhZGRl ZCB0byBvcHRpbWl6ZSBmb3IgdGhlIGNvbW1vbiBzaW5nbGUNCiBzaWduYXR1cmUvcmVjaXBpZW50 IGNhc2VzLiZuYnNwOyBCYXNlZCBvbiB0aGlzIGRldmVsb3BlciBmZWVkYmFjaywgd2UgZGlkIHRo aXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Vbmxlc3Mgd2UgZG8gdGhlIHNhbWUgZm9y IENPU0UsIEnigJltIHN1cmUgd2XigJlsbCByZWNlaXZlIHRoZSBzYW1lIGZlZWRiYWNrIHRoYXQg cmVxdWlyaW5nIHRoZSDigJxyZWNpcGllbnRz4oCdIGFycmF5IGluIHVzZSBjYXNlcyB3aGVyZSBp dCB3aWxsIGFsd2F5cyBjb250YWluIG9uZSBlbGVtZW50IGlzIHVubmVjZXNzYXJpbHkNCiBjb21w bGljYXRlZC4mbmJzcDsgV2Ugc2hvdWxkIGRvIHRoaXMgbm93LjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+V2hpbGUgdGhlIGFyZ3VtZW50IGFnYWluc3QgdGhpcyBjb3VsZCBiZSBtYWRlIHRo YXQg4oCcaXTigJlzIGV2ZW4gbW9yZSBjb21wbGljYXRlZCB0byBzdXBwb3J0IGJvdGggdGhlIGZs YXR0ZW5lZCBhbmQgZ2VuZXJhbCBzZXJpYWxpemF0aW9ucyB0aGFuIGp1c3QgdGhlIGdlbmVyYWwg b25l4oCdLCBJIGJlbGlldmUgdGhhdA0KIGluIHByYWN0aWNlLCB0aGlzIGlzIGEgbW9zdGx5IHNw ZWNpb3VzIGFyZ3VtZW50LiZuYnNwOyBBcHBsaWNhdGlvbnMgd2lsbCBjaG9vc2Ugb3IgYnVpbGQg YW4gaW1wbGVtZW50YXRpb24gdGhhdCBmaXRzIHRoZWlyIHVzZSBjYXNlIOKAkyBlaXRoZXIgb25l IHRoYXQgc3VwcG9ydHMgc2luZ2xlIG9yIG11bHRpcGxlIHJlY2lwaWVudHMuJm5ic3A7IEFwcGxp Y2F0aW9uIHByb2ZpbGVzIHdpbGwgY2hvb3NlIG9uZSBvciB0aGUgb3RoZXIgcmVwcmVzZW50YXRp b24gYW5kIHdpbGwNCiBnZW5lcmFsbHkgbm90IGNhbGwgZm9yIGJvdGguPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5UaGUgd2F5IHRvIGFjaGlldmUgdGhpcyBpcyB0byBkZWZpbmUgYSBmbGF0 dGVuZWQgcmVwcmVzZW50YXRpb24gYXMgSk9TRSBkaWQsIGluIHdoaWNoIGhlYWRlciBwYXJhbWV0 ZXJzIGFib3V0IGJvdGggdGhlIHBheWxvYWQgYW5kIHRoZSByZWNpcGllbnQgYXJlIGNhcnJpZWQg aW4gdGhlIHRvcCBsZXZlbCDigJx1bnByb3RlY3RlZOKAnQ0KIGFuZCDigJxwcm90ZWN0ZWTigJ0g ZWxlbWVudHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPltKTFNdIFRoaXMgd2FzIGRp c2N1c3NlZCBvbiB0aGUgbWFpbGluZyBsaXN0LiZuYnNwOyBUaGVyZSBhcmUgYSBudW1iZXIgb2Yg dHJhZGUtb2ZmcyB0aGF0IHdlcmUgZGlzY3Vzc2VkLiZuYnNwOyBQbGVhc2UgcmV2aWV3IHRoYXQg ZGlzY3Vzc2lvbiBhbmQgc2VlIGlmIHlvdSBoYXZlIHNvbWV0aGluZw0KIG5ldyB0byBhZGQuJm5i c3A7IFBsZWFzZSByZW1lbWJlciB0aGF0IHdlIGFyZSBsb29raW5nIGF0IGJvdGggdGhlIG1lc3Nh Z2Ugc2l6ZSBhbmQgdGhlIGNvZGUgc2l6ZSBhcyBjcml0ZXJpYSB3aGVuIG1ha2luZyBkZWNpc2lv bnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+Mi4mbmJzcDsgSE1BQ3Mg c2hvdWxkIGJlIG9wdGltaXplZCBmb3IgdGhlIG5vLWtleS1tYW5hZ2VtZW50IGNhc2UuPC9iPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UGFydGljdWxhcmx5IGZvciBjb25zdHJhaW5lZCBk ZXZpY2VzLCBpdCBpcyB1bmxpa2VseSB0aGF0IGFwcGxpY2F0aW9ucyB3aWxsIHdhbnQgdG8gcGF5 IHRoZSBwZXJmb3JtYW5jZSBwZW5hbHR5IG9mIGdlbmVyYXRpbmcgYW5kIGVuY3J5cHRpbmcgYSBr ZXkgbWFuYWdlbWVudCBrZXkgdG8gcGVyZm9ybSBhIE1BQw0KIG9wZXJhdGlvbi4mbmJzcDsgSGVj aywgdGhleSBtYXkgbm90IGhhdmUgY3JlZGlibGUgcmFuZG9tIG51bWJlciBnZW5lcmF0aW9uIGlu IHRoZSBmaXJzdCBwbGFjZSEmbmJzcDsgQW5kIHRoZXkgYXJlIGxpa2V3aXNlIHVubGlrZWx5IHRv IHdhbnQgdG8gcGF5IHRoZSBtZXNzYWdlIHNpemUgcGVuYWx0eSBvZiBjYXJyeWluZyB0aGUgZW5j cnlwdGVkIGtleS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPknigJltIGZpbmUgd2l0aCB0 aGUgb3B0aW9uYWwgYWJpbGl0eSB0byBoYXZlIGtleSBtYW5hZ2VtZW50IGZvciBNQUNzLCBidXQg dGhlIGRlZmF1bHQgc2hvdWxkIGJlIHRoYXQgbm8ga2V5IG1hbmFnZW1lbnQgaW5mb3JtYXRpb24g aXMgcHJlc2VudCBpbiB0aGUgcmVwcmVzZW50YXRpb24uJm5ic3A7IFRoZSBvbmx5IGFsZ29yaXRo bQ0KIHJlcHJlc2VudGVkIGJ5IGRlZmF1bHQgc2hvdWxkIGJlIHRoZSBNQUMgYWxnb3JpdGhtIOKA kyBub3QgZXZlbiDigJxkaXLigJ0gKGRpcmVjdCkuJm5ic3A7IEkgc3VzcGVjdCB0aGF0IHRoaXMg Y2FuIGJlIGNsZWFubHkgZG9uZSBieSBvbWl0dGluZyB0aGUga2V5IG1hbmFnZW1lbnQgbGF5ZXIg ZW50aXJlbHkgd2hlbiBpdOKAmXMgbm90IHVzZWQsIHJhdGhlciB0aGFuIGV4cGxpY2l0bHkgdXNp bmcg4oCcZGly4oCdIChkaXJlY3QpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPltKTFNdIFNl ZSBhYm92ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj4zLiZuYnNwOyBX cmFwcGVkIGtleXMgc2hvdWxkIGJlIGFibGUgdG8gYmUgcmVwcmVzZW50ZWQgYXMgc2ltcGx5IHRo ZSB3cmFwcGVkIGtleSB2YWx1ZSDigJMgbm90IGFzIGFuIGVuY3J5cHRlZCBkYXRhIHN0cnVjdHVy ZSB3aXRoIHVubmVjZXNzYXJ5IGluZm9ybWF0aW9uLjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPktleSBtYW5hZ2VtZW50IGtleXMgYXJlIGJ5IGRlZmluaXRpb24gZXBoZW1lcmFsIGFu ZCBzbyBubyBtZXRhZGF0YSBuZWVkcyB0byBiZSBjYXJyaWVkIGFib3V0IHRoZW0uJm5ic3A7IFll cywgdGhlIGFsZ29yaXRobSB1c2VkIHRvIHdyYXAgdGhlIGtleSBuZWVkcyB0byBiZSByZXByZXNl bnRlZCwgYnV0IHRoaXMgaXMNCiBhbHJlYWR5IHJlcHJlc2VudGVkIHNlcGFyYXRlbHkgZnJvbSB0 aGUgd3JhcHBlZCBrZXkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BIHNpbXBsZSB3YXkg dG8gYWNoaWV2ZSB0aGlzIGlzIHRvIGRlZmluZSBhbiBlbmNyeXB0ZWRfa2V5IGZpZWxkIHRvIHJl cHJlc2VudCB0aGUgd3JhcHBlZCBrZXksIHdoZW4gYXBwcm9wcmlhdGUgZm9yIHRoZSBhbGdvcml0 aG0uJm5ic3A7IEFtb25nIG90aGVyIGJlbmVmaXRzLCB0aGlzIHdpbGwgZW5hYmxlIHRoZSB1c2UN CiBvZiB0aGUgc3RhbmRhcmQgUkZDIDMzOTQgQUVTIEtleSBXcmFwIGFsZ29yaXRobXMsIGluIHRo ZSBzYW1lIHdheSB0aGF0IEpPU0UgdXNlcyDigJxBMTI4S1figJ0sIGV0Yy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPk5vdGUgdGhhdCBpZiB0aGUgd29ya2luZyBncm91cCBjaG9vc2VzIHRv LCB0aGUgYWJpbGl0eSB0byByZXByZXNlbnQgZW5jcnlwdGVkIGtleXMgYXMgZGF0YSBzdHJ1Y3R1 cmVzIGNhbiBhbHNvIGJlIHJldGFpbmVkIGluIHBhcmFsbGVsIHRvIHRoaXMgc2ltcGxlciBhcHBy b2FjaC4mbmJzcDsgQXBwbGljYXRpb25zIGNhbg0KIHRoZW4gY2hvb3NlIHdoaWNoIG1ldGhvZCB3 b3JrcyBiZXN0IGZvciB0aGVtLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5bSkxTXSBJ IGRvbuKAmXQgdW5kZXJzdGFuZCB0aGlzIGNvbW1lbnQuJm5ic3A7IFRoaXMgaXMgbm90IHdoYXQg dGhlIGRvY3VtZW50IHNheXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ NC4mbmJzcDsgU2ltcGxlciBhbmQgbW9yZSBjb21wcmVoZW5zaWJsZSBleGFtcGxlcyBhcmUgbmVl ZGVkLjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgd291bGQgaW5jbHVkZSBleGFt cGxlcyBmb3IgdGhlIHNpbXBsZXN0IGFuZCBsaWtlbHkgbW9zdCBjb21tb24gdXNlIGNhc2VzOjxv OnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+wrc8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+SE1BQyB3aXRob3V0IGtleSBtYW5hZ2VtZW50PG86 cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5TaW5nbGUgc2lnbmF0dXJlPG86cD48L286cD48L3A+ DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj5FbmNyeXB0aW9uIHVzaW5nIEFFUyBLZXkgV3JhcCBmb3Iga2V5IG1hbmFn ZW1lbnQgYW5kIEFFUyBHQ00gZm9yIGNvbnRlbnQgZW5jcnlwdGlvbjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+QWxzbywgdG8gYmUgY29tcHJlaGVuc2libGUgdG8gbW9zdCByZWFkZXJzLCB0 aGUgZXhhbXBsZXMgbmVlZCB0byBpbmNsdWRlIGJvdGggc3ltYm9saWMgYW5kIG51bWVyaWMgaWRl bnRpZmllcnMgZm9yIGFsbCBmaWVsZHMuJm5ic3A7IEFsc28sIGRlY29kZWQgcmVwcmVzZW50YXRp b25zIGZvciBlbmNvZGVkIHZhbHVlcw0KIG5lZWQgdG8gYmUgc2hvd24uPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5Gb3IgaW5zdGFuY2UsIHRoZSBEaXJlY3QgTUFDIGV4YW1wbGUgaW4gQy4x IHNob3VsZCBiZSBjaGFuZ2VkIGZyb20gYmVnaW5uaW5nIGxpa2UgdGhpczo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyB7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxOiAzLDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMjogaCdh MTAxMDQnLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgNDogaCc1NDY4Njk3MzIwNjk3MzIwNzQ2ODY1MjA2MzZmNmU3NDY1NmU3 NDJlJyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDEwOiBoJzJiYTkzN2NhMDNkNzZjM2RiYWQzMGNmY2JhZWVmNTg2ZjljMGY5 YmE2MTZhZDY3ZTkyMDVkMzg1NzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDsmbmJzcDsgNmFkOTkzMCcsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj50byBi ZWdpbm5pbmcgbGlrZSB0aGlzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5i c3A7IHs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDEgKG1zZ190eXBlKTogMyAoTUFDZWQgbWVzc2FnZSksPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyIChw cm90ZWN0ZWQpOiBoJ2ExMDEwNCcgKGFsZzpIUzI1NiksPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA0IChwYXlsb2FkKTogaCc1 NDY4Njk3MzIwNjk3MzIwNzQ2ODY1MjA2MzZmNmU3NDY1NmU3NDJlJyw8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEwICh0YWcp OiBoJzJiYTkzN2NhMDNkNzZjM2RiYWQzMGNmY2JhZWVmNTg2ZjljMGY5YmE2MTZhZDY3ZTkyMDVk Mzg1NzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsg NmFkOTkzMCcsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPltKTFNdIE1vcmUgZXhhbXBs ZXMgYXJlIG9uIHRoZSB3YXkgaW4gdGhlIGZ1dHVyZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Yj5NSU5PUiBJU1NVRVM8L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5UaGVzZSBpc3N1ZXMgYXJlIG9yZ2FuaXplZCBieSBzZWN0aW9uIG51bWJlciwgcHJvdmlkaW5n IGNvbW1lbnRzIG9uIHRoZSBzcGVjIHRleHQgaW4gdGhlIG9yZGVyIG9mIGFwcGVhcmFuY2UuJm5i c3A7IDI3IGlzc3VlcyBhcmUgZGVzY3JpYmVkLCBsYWJlbGVkIGEsIGIsIGMsIOKApiBhYS4mbmJz cDsgVGhlIHNlY3Rpb24gbnVtYmVycw0KIGFuZCBuYW1lcyBpbiB3aGljaCB0aGV5IGFwcGVhciBh cmUgaW5jbHVkZWQgaW4gdGhlIHdyaXRlLXVwLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Mi4mbmJzcDsgVGhlIENPU0VfTVNHIHN0cnVjdHVyZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+YS4mbmJzcDsgQ2hhbmdlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyBJbXBsZW1lbnRhdGlvbnMgTVVTVCBiZSBwcmVwYXJlZCB0byBmaW5kIGFuIGludGVn ZXIgdW5kZXIgdGhpcyBsYWJlbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgd2hpY2ggZG9lcyBub3QgY29ycmVzcG9uZCB0byB0aGUgdmFsdWVzIDEg dG8gMy4mbmJzcDsgSWYgdGhpcyBpcyBmb3VuZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdGhlbiB0aGUgY2xpZW50IE1VU1Qgc3RvcCBhdHRlbXB0 aW5nIHRvIHBhcnNlIHRoZSBzdHJ1Y3R1cmUgYW5kIGZhaWwuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj50bzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsgSW1wbGVtZW50YXRpb25zIE1VU1QgYmUgcHJlcGFyZWQgdG8gZmlu ZCBhbiBpbnRlZ2VyIHVuZGVyIHRoaXMgbGFiZWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHdoaWNoIGRvZXMgbm90IGNvcnJlc3BvbmQgdG8gdGhl IHZhbHVlcyAxIHRvIDMuJm5ic3A7IElmIHRoaXMgaXMgZm91bmQ8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHRoZW4gdGhlIGNsaWVudCBNVVNUIHN0 b3AgYXR0ZW1wdGluZyB0byBwYXJzZSB0aGUgc3RydWN0dXJlIGFuZCBmYWlsLDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdW5sZXNzIGl0IHVuZGVy c3RhbmRzIGFuZCBpbXBsZW1lbnRzIHRoZSBleHRlbnNpb24gbGFiZWwgdmFsdWUuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJlZCI+W0pMU10gSSBkbyBub3QgYmVsaWV2ZSB0aGF0 IHRoaXMgaXMgcmVxdWlyZWQuJm5ic3A7IElmIHlvdSBpbXBsZW1lbnQgYSBuZXcgaXRlbSwgdGhl biB5b3UgZG9u4oCZdCBoYXZlIGEgcHVyZSBpbXBsZW1lbnRhdGlvbiBvZiB0aGlzIGRvY3VtZW50 DQogYW5kIHRoZSBjbGF1c2UgaXMgaW1wbGljaXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Yi4mbmJzcDsgVGhpcyBzeW50YXggbmVlZHMgbW9yZSBleHBsYW5hdGlvbjo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IENPU0VfVGFn Z2VkX01TRyA9ICM2Ljk5OShDT1NFX01TRykmbmJzcDsmbmJzcDsgOyBSZXBsYWNlIDk5OSB3aXRo IFRCRDE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgYXNzdW1lIHRoYXQgdGhpcyBpcyBh IHVzZSBvZg0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzA0OSNzZWN0 aW9uLTIuNCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcw NDkjc2VjdGlvbi0yLjQ8L2E+IChPcHRpb25hbCBUYWdnaW5nIG9mIEl0ZW1zKSwgYnV0IHlvdSBz aG91bGQgZXhwbGljaXRseSBzYXkgdGhhdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjpyZWQiPltKTFNdJm5ic3A7IFRoaXMgZmFsbHMgaW4gdG8gdGhlIHF1 ZXN0aW9uIG9mIG5vcm1hdGl2ZSByZWZlcmVuY2Ugb24gQ0RETC4mbmJzcDsgSWYgaXQgaXMgYSBu b3JtYXRpdmUgcmVmZXJlbmNlLCB0aGlzIGlzIG5vdCBuZWNlc3NhcnkgYXMgeW91IGFyZSBleHBl Y3RlZCB0byB1bmRlcnN0YW5kDQogQ0RETC4mbmJzcDsgSWYgQ0RETCBpcyBpbmZvcm1hdGlvbmFs LCB0aGVuIGl0IHdvdWxkIGJlIHJlcXVpcmVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5jLiZuYnNwOyBDaGFuZ2U6PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHwgY2lwaGVydGV4dCZu YnNwOyB8IDQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBUT0RPOiBTaG91bGQgd2Ug cmUtdXNlIHRoZSBzYW1lIGFzIHBheWxvYWQgfDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgb3Igbm90PyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj50bzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsgfCBjaXBoZXJ0ZXh0Jm5ic3A7IHwgNyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 IEZvciBDT1NFX2VuY3J5cHQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl04oCZcyBjbGVhbmVyIG5v dCB0byByZXVzZSB0aGUgc2FtZSBsYWJlbCB2YWx1ZSBmb3IgZGlmZmVyZW50IHNlbWFudGljIG1l YW5pbmdzLiZuYnNwOyBJZiB3ZSBkbyB0aGF0LCB3ZSBtaWdodCBjb21lIHRvIHJlZ3JldCBpdCBh cyB0aGUgc3BlYyBldm9sdmVzLiZuYnNwOyBCZXNpZGVzLCBpdOKAmXMgbm90IGxpa2UgdXNpbmcg YW5vdGhlcg0KIHNob3J0IGludGVnZXIgdmFsdWUgaGVyZSB3aWxsIGNhdXNlIHVzIHRvIHJ1biBv dXQgb2YgdGhlbSBpbiB0aGlzIGNvbnRleHQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5bSkxTXSZuYnNwOyBUaGUgVE9ETyBpcyBhIG1hcmtlciBm b3IgZnV0dXJlIGRpc2N1c3Npb24g4oCTIFRoZXJlIGFyZSBib3RoIGFkdmFudGFnZXMgYW5kIGRp c2FkdmFudGFnZXMgdG8gcmUtdXNpbmcgdGhlIHNhbWUgbGFiZWwuJm5ic3A7IE9uIG9uZSBoYW5k LCBpdCBpcyBlYXN5IGZvcg0KIHByb2dyYW1zIHRvIGFsd2F5cyBsb29rIGluIHRoZSBzYW1lIGxv Y2F0aW9uIGZvciB0aGUgY29udGVudCBpbmRlcGVuZGVudCBvZiB3aGF0IHR5cGUgb2YgY29udGVu dCBpdCBpcy4mbmJzcDsgVGhpcyBtYXkgbWFrZSB0aGluZ3MgZWFzaWVyIGZvciBpdGVtcyB3aGlj aCBoYXZlIGRldGFjaGVkIGNvbnRlbnQgZGVwZW5kaW5nIG9uIGhvdyB0aGUgQVBJIGhhbmRsZXMg dGhpcy4mbmJzcDsgT24gdGhlIG90aGVyIGhhbmQsIGFuIEFQSSBtaWdodCB3YW50IHRvIGhhdmUN CiB0aGVtIHNlcGFyYXRlLiZuYnNwOyZuYnNwOyBJIGRvbuKAmXQga25vdyB3aGF0IHRoZSBhbnN3 ZXIgZm9yIHRoaXMgaXMgeWV0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5kLiZuYnNwOyBDaGFuZ2U6PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7IFRoZXNlIHR3byBidWNrZXRzPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBhcmUgYXZhaWxhYmxlIGZv ciB1c2UgaW4gYWxsIG9mIHRoZSBzdHJ1Y3R1cmVzIGluIHRoaXMgZG9jdW1lbnQ8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGV4Y2VwdCBmb3Iga2V5 cy4mbmJzcDsgV2hpbGUgdGhlc2UgYnVja2V0cyBjYW4gYmUgcHJlc2VudCwgdGhleSBtYXkgbm90 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBhbGwg YmUgdXNhYmxlIGluIGFsbCBpbnN0YW5jZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj50bzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsgVGhlc2UgdHdvIGJ1Y2tldHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7IGFyZSBkZWZpbmVkIGZvciB1c2UgaW4gYWxsIG9mIHRoZSBzdHJ1Y3R1 cmVzIGluIHRoaXMgZG9jdW1lbnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7IGV4Y2VwdCBmb3Iga2V5cy4mbmJzcDsgV2hpbGUgdGhlc2UgYnVja2V0 cyBhcmUgZGVmaW5lZCwgdGhleSBtYXkgbm90PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBiZSB1c2FibGUgb3IgdXNlZCBpbiBhbGwgaW5zdGFuY2Vz Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBuZXcgdGV4dCBtYWtlcyBp dCBjbGVhcmVyIHRoYXQg4oCccHJvdGVjdGVk4oCdIGFuZCDigJx1bnByb3RlY3RlZOKAnSBjYW7i gJl0IGJlIGluY2x1ZGVkIHdoZXJlIHRoZWlyIHZhbHVlcyBjYW7igJl0IGJlIHVzZWQuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQi PltKTFNdIFRoYXQgdGV4dCBkb2VzIG5vdCBtYWtlIGl0IGFueSBjbGVhcmVyIHRvIG1lLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjMuMS4mbmJzcDsgQ09TRSBIZWFkZXJzPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5lLiZuYnNwOyBDaGFuZ2U6PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7IFRoZSBmaWVsZCBpcyB1c2VkIHRvIGluZGljYXRlIHdo aWNoIHByb3RlY3RlZCBoZWFkZXIga2V5czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYW4gYXBwbGljYXRpb24gd2hp Y2ggaXMgcHJvY2Vzc2luZyBhIG1lc3NhZ2UgaXMgcmVxdWlyZWQgdG88L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVu ZGVyc3RhbmQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj50 bzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgVGhlIGZpZWxkIGlzIHVz ZWQgdG8gaW5kaWNhdGUgd2hpY2ggcHJvdGVjdGVkIGhlYWRlciBrZXlzPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBk ZWZpbmVkIGJ5IGV4dGVuc2lvbnMgdG8gdGhpcyBzcGVjaWZpY2F0aW9uIHRoYXQ8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGFuIGFwcGxpY2F0aW9uIHRoYXQgaXMgcHJvY2Vzc2luZyBhIG1lc3NhZ2UgaXMgcmVxdWly ZWQgdG88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVuZGVyc3RhbmQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+VGhlIGxhbmd1YWdlIHNob3VsZCBtYWtlIGl0IGNsZWFyIHRoYXQg4oCcY3JpdOKA nSBpcyBvbmx5IGZvciBkZWZpbmluZyBiZWhhdmlvciBvZiBjcml0aWNhbCBleHRlbnNpb25zIOKA kyBub3QgZm9yIG1ha2luZyBoZWFkZXIgcGFyYW1ldGVycyBkZWZpbmVkIGJ5IHRoaXMgc3BlYyBj cml0aWNhbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImNvbG9yOnJlZCI+W0pMU10gVGhpcyBkb2VzIG5vdCBtYWtlIHRoaW5ncyBjbGVhcmVyIHRv bWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Zi4mbmJzcDsgSW4gVGFibGUg MiwgY2hhbmdlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB8 IGprdSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8ICombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCB0c3RyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBVUkwgdG8gQ09TRSBr ZXkgb2JqZWN0Jm5ic3A7IHw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDt8PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB8IGp3ayZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8ICombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBDT1NFX0tleSB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgY29udGFp bnMgYSBDT1NFIGtleSBub3QgfDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 IGEgSldLIGtleSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+dG86PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHwgamt1Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwgKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IHRzdHImbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8IFVSTCB0byBKV0sgW1JGQyA3NTE3XSAmbmJzcDsmbmJzcDt8 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7fDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDt8IGNrdSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8ICombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCB0c3RyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBVUkwg dG8gQ09TRSBrZXkgb2JqZWN0Jm5ic3A7IHw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDt8PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB8IGNrJm5ic3A7Jm5ic3A7Jm5ic3A7 ICZuYnNwOyZuYnNwOyZuYnNwO3wgKiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IENPU0VfS2V5 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCBjb250YWlucyBhIENPU0Uga2V5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXQgc3RpbGwgbWFr ZXMgc2Vuc2UgdG8gYmUgYWJsZSB0byByZXByZXNlbnQgVVJMcyB0byBKV0sgYW5kIENPU0UgS2V5 IG9iamVjdHMuJm5ic3A7IEJ1dCB3ZSBzaG91bGRu4oCZdCBjYWxsIHRoZSBDT1NFIEtleSBwYXNz ZWQgYnkgdmFsdWUg4oCcandr4oCdLCBzaW5jZSB0aGF04oCZcyBtaXNsZWFkaW5nLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5b SkxTXSBUaHVzIHRoZSBvcGVuIGlzc3VlIG1hcmtlci48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Zy4mbmJzcDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7T3BlbiBJc3N1ZSAxLiZuYnNwOyBXaGljaCBvZiB0aGUgZm9sbG93aW5nIGl0 ZW1zIGRvIHdlIHdhbnQgdG8gaGF2ZSBzdGFuZGFyZGl6ZWQgaW48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHRoaXMgZG9jdW1lbnQ6IGprdSwgandrLCB4NWMsIHg1dCwgeDV0I1MyNTYsIHg1dSwgemlwPzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB3b3VsZCBrZWVwIGFsbCBvZiB0aGVtLCBvdGhl ciB0aGFuIGNoYW5naW5nIOKAnGprdeKAnSBhbmQg4oCcandr4oCdIHRvIOKAnGprdeKAnSwg4oCc Y2t14oCdLCBhbmQg4oCcY2vigJ0gcGVyIChmKSBhYm92ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+W0pMU10gVGhpcyB3aWxs IGJlIGEgZGlzY3Vzc2lvbiBpc3N1ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5oLiZuYnNwOyBPcGVuIElzc3VlIDIuJm5ic3A7IEkgYW0gY3VycmVudGx5IHRvcm4gb24gdGhl IHF1ZXN0aW9uICZxdW90O1Nob3VsZCBlcGsgYW5kIGl2L25vbmNlIGJlPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBhbGdvcml0aG0gc3BlY2lmaWMgb3IgZ2VuZXJpYyBoZWFkZXJzPyZxdW90OzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+SSB3b3VsZCBkZWZpbmUgY29tbW9uIGxhYmVscyBmb3IgdGhl bSBzaW5jZSB0aGV5IGFyZSBjb21tb25seSB1c2VkIGFjcm9zcyBtdWx0aXBsZSBhbGdvcml0aG1z LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+NC4mbmJzcDsgU2lnbmluZyBTdHJ1Y3R1cmU8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6Ljc1aW4iPmkuPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4N ClRoZSBkZXNjcmlwdGlvbiBvZiDigJxwcm90ZWN0ZWTigJ0gc2F5cyDigJxUaGUgZmllbGQgTVVT VCBOT1QgaG9sZCBhdHRyaWJ1dGVzIGFib3V0IHRoZSBwYXlsb2FkIGJlaW5nIHNpZ25lZOKAnS4m bmJzcDsgQXNzdW1pbmcgdGhhdCBhIGZsYXR0ZW5lZCBzeW50YXggaXMgYWRkZWQsIHRoaXMgd291 bGQgdGhlbiBiZWNvbWUgc29tZXRoaW5nIGxpa2Ug4oCcVGhlIGZpZWxkIE1VU1QgTk9UIGhvbGQg YXR0cmlidXRlcyBhYm91dCB0aGUgcGF5bG9hZCBiZWluZyBzaWduZWQgdW5sZXNzDQogdGhlIGZs YXR0ZW5lZCBzZXJpYWxpemF0aW9uIGlzIGJlaW5nIHVzZWTigJ0uJm5ic3A7IE90aGVyIHJlbGF0 ZWQgc3RhdGVtZW50cyB0aHJvdWdob3V0IHRoZSBkb2N1bWVudCB3b3VsZCBsaWtld2lzZSBuZWVk IHRvIGJlIHNpbWlsYXJseSB1cGRhdGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5bSkxTXSBCdXQgaXQgaXMgbm90IGN1cnJl bnQgYWRkZWQg4oCTIHNvIHRoaXMgaXMgbm90IGN1cnJlbnRseSBhbiBhY3Rpb25hYmxlIHN0YXRl bWVudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5qLiZuYnNwOyBUaGUgZW5k IG9mIHRoZSBzaWduaW5nIHNlY3Rpb24gc2F5czo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDsgSW4gYWRkaXRpb24gdG8gcGVyZm9ybWluZyB0aGUgc2lnbmF0dXJl IHZlcmlmaWNhdGlvbiwgb25lIG11c3QgYWxzbzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgcGVyZm9ybSB0aGUgYXBwcm9wcmlhdGUgY2hlY2tzIHRv IGVuc3VyZSB0aGF0IHRoZSBrZXkgaXMgY29ycmVjdGx5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBwYWlyZWQgd2l0aCB0aGUgc2lnbmluZyBpZGVu dGl0eSBhbmQgdGhhdCB0aGUgYXBwcm9wcmlhdGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGF1dGhvcml6YXRpb24gaXMgZG9uZS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGVyZSBuZWVkcyB0byBiZSBhIHJlZmVyZW5jZSB0 byBhIHBsYWNlIHdoZXJlIHRoZSBwcm9jZXNzIG9mIHZlcmlmeWluZyB0aGUga2V54oCZcyBhc3Nv Y2lhdGlvbiB3aXRoIHRoZSBzaWduaW5nIGlkZW50aXR5IGlzIGRlc2NyaWJlZC4mbmJzcDsgUGFy dGljdWxhciBtZXRob2RzIGFyZSBjbGVhcmx5IGJleW9uZCB0aGUNCiBzY29wZSBvZiB0aGlzIHNw ZWNpZmljYXRpb24gYnV0IHNheWluZyB0aGlzIGxpdHRsZSBhYm91dCB0aGUgcHJvY2VzcyB3aWxs IGxpa2VseSBqdXN0IGxlYXZlIG1hbnkgcGVvcGxlIGNvbmZ1c2VkLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5bSkxTXSBXaGF0 IGRvIHlvdSB0aGluayB0aGlzIHNob3VsZCByZWZlcmVuY2U/PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+NS4mbmJzcDsgRW5jcnlwdGlvbiBPYmplY3Q8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPmsuJm5ic3A7IFRoZSBpbnRyb2R1Y3Rpb24gdG8gdGhpcyBzZWN0aW9uIHNh eXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEluIHRoaXMg c2VjdGlvbiB3ZSBkZXNjcmliZSB0aGUgc3RydWN0dXJlIGFuZCBtZXRob2RzIHRvIGJlIHVzZWQg d2hlbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsg ZG9pbmcgYW4gZW5jcnlwdGlvbiBpbiBDT1NFLiZuYnNwOyBJbiBDT1NFLCB3ZSB1c2UgdGhlIHNh bWUgdGVjaG5pcXVlcyBhbmQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IHN0cnVjdHVyZXMgZm9yIGVuY3J5cHRpbmcgYm90aCB0aGUgcGxhaW4gdGV4 dCBhbmQgdGhlIGtleXMgdXNlZCB0bzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDsmbmJzcDtwcm90ZWN0IHRoZSB0ZXh0LiZuYnNwOyBUaGlzIGlzIGRpZmZlcmVu dCBmcm9tIHRoZSBhcHByb2FjaCB1c2VkIGJ5IGJvdGg8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFtSRkM1NjUyXSBhbmQgW1JGQzc1MTZdIHdoZXJl IGRpZmZlcmVudCBzdHJ1Y3R1cmVzIGFyZSB1c2VkIGZvciB0aGU8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHBsYWluIHRleHQgYW5kIGZvciB0aGUg ZGlmZmVyZW50IGtleSBtYW5hZ2VtZW50IHRlY2huaXF1ZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SeKAmWxsIG5vdGUgdGhhdCBpZiBpc3N1ZSAzIGlzIHJlc29sdmVkICg8 Yj5XcmFwcGVkIGtleXMgc2hvdWxkIGJlIGFibGUgdG8gYmUgcmVwcmVzZW50ZWQgYXMgc2ltcGx5 IHRoZSB3cmFwcGVkIGtleSB2YWx1ZTwvYj4pLCB0aGlzIHBhcmFncmFwaCB3aWxsIGhhdmUgdG8g YmUgcmV2aXNlZCBhY2NvcmRpbmdseS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+W0pMU10gQnV0IGN1cnJlbnRseSBub3QgYW4g YWN0aW9uYWJsZSBzdGF0ZW1lbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ bC4mbmJzcDsgQSBnZW5lcmljIOKAnGl24oCdIChpbml0aWFsaXphdGlvbiB2ZWN0b3IpIGZpZWxk IHNob3VsZCBhbHNvIGJlIGRlZmluZWQgaW4gdGhlIGxpc3Qgb2YgcGFyYW1ldGVycyBmb3IgdGhl IGVuY3J5cHRpb24gb2JqZWN0LiZuYnNwOyBZZXMsIG5vdCBhbGwgYWxnb3JpdGhtcyB3aWxsIHVz ZSBpdCwgYnV0IG1hbnkgd2lsbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPm0uJm5ic3A7 IEEg4oCcdGFn4oCdIChhdXRoZW50aWNhdGlvbiB0YWcpIGZpZWxkIHNob3VsZCBiZSBkZWZpbmVk IGluIHRoZSBsaXN0IG9mIHBhcmFtZXRlcnMgZm9yIHRoZSBlbmNyeXB0aW9uIG9iamVjdC4mbmJz cDsgWWVzLCBub3QgYWxsIHRoZSBhbGdvcml0aG1zIHdpbGwgdXNlIGl0LCBidXQgbWFueSB3aWxs LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29s b3I6cmVkIj5bSkxTXSBNYXliZSB0cnVlIGZvciDigJhpduKAmSwgaG93ZXZlciDigJh0YWfigJkg aXMgcGFydCBvZiB0aGUgY2lwaGVydGV4dC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj41LjEuMS4mbmJzcDsgRGlyZWN0IEVuY3J5cHRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPm4uJm5ic3A7IFRoZSBzcGVjIHNheXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgQXQgYSBtaW5pbXVtLCB0aGUgJ3VucHJvdGVjdGVk JyBmaWVsZCBNVVNUIGNvbnRhaW4gdGhlICdhbGcnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwYXJhbWV0ZXIgYW5k IFNIT1VMRCBjb250YWluIGEgcGFyYW1ldGVyIGlkZW50aWZ5aW5nIHRoZSBzaGFyZWQ8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHNlY3JldC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TSE9VTEQg aXMgdG9vIHN0cm9uZyBoZXJlIGJlY2F1c2UgaW4gc29tZSBwcm90b2NvbHMsIHRoZSBzaGFyZWQg c2VjcmV0IHdpbGwgYWxyZWFkeSBiZSBrbm93biBieSBtZXRob2RzIG90aGVyIHRoYW4gYW4gaW5j bHVkZWQg4oCca2lk4oCdIG9yIG90aGVyIGtleSBzZWxlY3Rpb24gdmFsdWUuJm5ic3A7IEEg4oCc U0hPVUxEIOKApiB1bmxlc3MNCiDigKbigJ0gY29uc3RydWN0IGxpa2Ugd2FzIHVzZWQgaW4gc2lt aWxhciBKT1NFIGRlc2NyaXB0aW9ucyBpcyBwcm9iYWJseSB0aGUgcmlnaHQgdGhpbmcgdG8gdXNl IGhlcmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjpyZWQiPltKTFNdIFRoZSDigKZ1bmxlc3PigKYgY2xhdXNlIGlzIGNvbmZ1c2luZyBh cyBoZWxsIHNvIEkgZG8gbm90IHBsYW4gdG8gaW5jbHVkZSBpdC4mbmJzcDsgVGhlIGRlZmluaXRp b24gb2YgU0hPVUxEIG1lYW5zIHRoYXQgcHV0IGl0IHRoZXJlIHVubGVzcyB5b3UgaGF2ZSBhIGdv b2QgcmVhc29uDQogbm90IHRvIGRvIHNvLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjYuJm5ic3A7IE1BQyBPYmplY3RzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5vLiZu YnNwOyBUaGUg4oCcSG93IHRvIGNvbXB1dGUgYSBNQUPigJ0gaW5zdHJ1Y3Rpb25zIHNheTo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgNS4mbmJzcDsgRW5jcnlw dCBhbmQgZW5jb2RlIHRoZSBNQUMga2V5IGZvciBlYWNoIHJlY2lwaWVudCBvZiB0aGUgbWVzc2Fn ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlzIGlzIG5vdCBjb3JyZWN0 IHdoZW4gZGlyZWN0IGtleSBtYW5hZ2VtZW50IG9yIG5vIGtleSBtYW5hZ2VtZW50IGlzIHVzZWQu Jm5ic3A7IFBsZWFzZSByZXZpc2UgdG8gYWNjdXJhdGVseSBpbmNsdWRlIHRoZXNlIGNhc2VzIGFz IHdlbGwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjpyZWQiPltKTFN9IFRoaXMgaXMgY29ycmVjdCBmb3IgdGhlIGN1cnJlbnQgZG9jdW1l bnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Ny4mbmJzcDsgS2V5IFN0cnVj dHVyZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+cC4mbmJzcDsgVGhlIHNwZWMgc2F5czo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgVGhlICZxdW90O2tl eV9vcHMmcXVvdDsgZWxlbWVudCBpcyBwcmVmZXJyZWQgb3ZlciB0aGUgJnF1b3Q7dXNlJnF1b3Q7 IGVsZW1lbnQgYXMgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyBpbmZvcm1hdGlvbiBwcm92aWRlZCB0aGF0IHdheSBpcyBtb3JlIGZpbmVseSBk ZXRhaWxlZCBhYm91dCB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IG9wZXJhdGlvbnMgYWxsb3dlZC4mbmJzcDsgSXQgaXMgc3Ryb25nbHkgc3Vn Z2VzdGVkIHRoYXQgdGhpcyBlbGVtZW50IGJlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBwcmVzZW50IGZvciBhbGwga2V5cy48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5MaWtlIGluIChuKSwgdGhlIGFwcGxpY2F0aW9uIG1heSBr bm93IHRoZSBrZXkgdXNhZ2UgZnJvbSBhcHBsaWNhdGlvbiBjb250ZXh0LCByZW5kZXJpbmcgdGhl IGluY2x1c2lvbiBvZiDigJxrZXlfb3Bz4oCdIHVubmVjZXNzYXJ5LiZuYnNwOyBMYW5ndWFnZSBz b21ldGhpbmcgbGlrZSDigJxJdCBpcyBzdHJvbmdseSBzdWdnZXN0ZWQNCiB0aGF0IHRoaXMgZWxl bWVudCBiZSBwcmVzZW50IGZvciBhbGwga2V5cyB1bmxlc3MgdGhpcyBpbmZvcm1hdGlvbiBpcyBh bHJlYWR5IGtub3cgdG8gdGhlIGFwcGxpY2F0aW9uIHRocm91Z2ggb3RoZXIgbWVhbnPigJ0gc2hv dWxkIGJlIHVzZWQgdG8gY2FwdHVyZSB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ VGhlIHdvcmtpbmcgZ3JvdXAgc2hvdWxkIGFsc28gZGlzY3VzcyB3aGV0aGVyIGl0IHdhbnRzIHRv IGNhcnJ5IGZvcndhcmQg4oCcdXNl4oCdIGZvciBKV0sgY29tcGF0aWJpbGl0eSwgZXZlbiBpZiBp dCBpcyBkZXByZWNhdGVkLiZuYnNwOyBJIHBlcnNvbmFsbHkgd291bGQgYmUgaW4gZmF2b3Igb2Yg ZG9pbmcgc28uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJjb2xvcjpyZWQiPltKTFNdIElmIHlvdSB0aGluayB0aGlzLCB0aGVuIHBsZWFzZSBvcGVu IGl0IGFzIGEgZGlzY3Vzc2lvbiBpc3N1ZS4mbmJzcDsgSSBkb27igJl0IHNlZSBhbnkgZ29vZCB1 c2UgZm9yIGl0IHRoYXQgaXMgbm90IGJldHRlciBzZXJ2ZWQgYnkg4oCYa2V5X29wc+KAmS4mbmJz cDsgVGhpcyBpcyBkb3VibHkNCiB0cnVlIGdpdmVuIHRoYXQgdGhlIFczQyBDcnlwdG8gZ3JvdXA8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5xLiZuYnNwOyBJIHdvdWxkIGRlZmlu ZSBzaG9ydCBudW1lcmljIHZhbHVlcyB0aGF0IGNvcnJlc3BvbmQgdG8gdGhlIGRlZmluZXMg4oCc a2V5X29wc+KAnSBzdHJpbmcgdmFsdWVzLiZuYnNwOyBJ4oCZZCBkbyB0aGUgc2FtZSBmb3IgdGhl IOKAnHVzZeKAnSB2YWx1ZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPltKTFNdIFllcyB0aGlzIHdpbGwgYmUgaGFwcGVuaW5n IGdvaW5nIGZvcndhcmQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+OC4mbmJz cDsgQ0JPUiBFbmNvZGVyIFJlc3RyaWN0aW9uczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ ci4mbmJzcDsgVGhlIHNwZWMgc2F5czo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsgbyZuYnNwOyBBbGwgcGFyc2VycyB1c2VkIFNIT1VMRCBmYWlsIG9uIGJvdGgg cGFyc2luZyBhbmQgZ2VuZXJhdGlvbiBpZiB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNhbWUgbGFiZWwgaXMg dXNlZCB0d2ljZSBhcyBhIGtleSBmb3IgdGhlIHNhbWUgbWFwLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkkgd291bGQgc3Ryb25nbHkgcHJlZmVyIHRoYXQgdGhlIOKAnFNIT1VM ROKAnSBiZSBjaGFuZ2VkIHRvIOKAnE1VU1TigJ0uJm5ic3A7IENCT1IgZG9lc27igJl0IGhhdmUg dGhlIHNhbWUgbGVnYWN5IG9mIGxheCBwYXJzZXJzIHRoYXQgd2UgaW5oZXJpdGVkIGZyb20gSmF2 YVNjcmlwdC9FQ01Bc2NyaXB0IGZvciBKU09OLiZuYnNwOyBMZXTigJlzIG5vdA0KIG9wZW4gdGhl IGRvb3IgdG8gdGhlbSE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjkuNSZuYnNwOyBDT1NF IEFsZ29yaXRobSBSZWdpc3RyeTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+cy4mbmJzcDsg SSB3b3VsZCBhZGQgYW4gYWRkaXRpb25hbCDigJxKT1NFIGFsZ29yaXRobSBuYW1l4oCdIGZpZWxk IHRvIHRoaXMgcmVnaXN0cnksIHdob3NlIHZhbHVlIGlzIHRoZSBjb3JyZXNwb25kaW5nIOKAnEFs Z29yaXRobSBOYW1l4oCdIGVudHJ5IGluIHRoZSBJQU5BIEpTT04gV2ViIFNpZ25hdHVyZSBhbmQg RW5jcnlwdGlvbg0KIEFsZ29yaXRobXMgcmVnaXN0cnkgYXQgPGEgaHJlZj0iaHR0cDovL3d3dy5p YW5hLm9yZy9hc3NpZ25tZW50cy9qb3NlL2pvc2UueGh0bWwjd2ViLXNpZ25hdHVyZS1lbmNyeXB0 aW9uLWFsZ29yaXRobXMiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNz aWdubWVudHMvam9zZS9qb3NlLnhodG1sI3dlYi1zaWduYXR1cmUtZW5jcnlwdGlvbi1hbGdvcml0 aG1zPC9hPiwgaWYgc3VjaCBhbiBlbnRyeSBleGlzdHMuJm5ic3A7IFRoaXMgd2lsbCB0aWUgdGhl IHR3byByZWdpc3RyaWVzIHRvZ2V0aGVyIHNvIHRoYXQgZGVmaW5pdGlvbnMgb2YgYWxnb3JpdGht cyBhbHJlYWR5IGRlZmluZWQgYnkgSk9TRSBuZWVkIG5vdCBiZSByZXBlYXRlZCBmb3IgQ09TRS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkluIG1hbnkgY2FzZXMgdGhlbiwgdGhlIENPU0Ug YWxnb3JpdGhtcyBkcmFmdCAob3Igc2VjdGlvbikgY2FuIGp1c3QgY2l0ZSB0aGUgZGVmaW5pdGlv biBpbiBSRkMgNzUxOCBhbmQgcmVnaXN0ZXIgdGhlIGNvcnJlc3BvbmRpbmcgc2hvcnQgbnVtZXJp YyBsYWJlbCBmb3IgQ09TRSB1c2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPltKTFNdIERvIHdlIGhhdmUgYSByZWFzb24gdG8g YmVsaWV2ZSB0aGF0IENPU0UgaW1wbGVtZW50ZXJzIGFyZSBnb2luZyB0byBoYXZlIGEgbGFyZ2Vy IG92ZXJsYXAgd2l0aCBKT1NFIGltcGxlbWVudGVycz88L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj45LjguMSZuYnNwOyBDT1NFIFNlY3VyaXR5IE1lc3NhZ2U8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPnQuJm5ic3A7IEJlc2lkZXMgcmVnaXN0ZXJpbmcgdGhlIE1JTUUgdHlw ZSDigJxhcHBsaWNhdGlvbi9jb3Nl4oCdLCBJIHdvdWxkIGFsc28gcmVnaXN0ZXIgb25lIGZvciBh IGJhc2U2NHVybCBlbmNvZGVkIENPU0UgbWVzc2FnZSDigJMgYW4gaWRlYSBmaXJzdCBkZXNjcmli ZWQgdG8gbWUgYnkgSm9lIEhpbGRlYnJhbmQuJm5ic3A7IEl0IGNvdWxkDQogYmUgY2FsbGVkIOKA nGFwcGxpY2F0aW9uL2Nvc2UmIzQzO2Jhc2U2NHVybOKAnSBvciBzb21ldGhpbmcgb2YgdGhhdCBp bGsuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjpyZWQiPltKTFNdJm5ic3A7IEkgd291bGQgZXhwZWN0IHRoZSBtZWRpYS10eXBlIHJldmll d2VycyB0byBvYmplY3QgdG8gdGhhdCBiZWNhdXNlIHRoaXMgaXMgYSB0cmFuc3BvcnQgZW5jb2Rp bmcgbm90IGEgY29udGVudCBlbmNvZGluZy4mbmJzcDsgRG8geW91IGhhdmUgYSByZWFzb24gdG8g YmVsaWV2ZQ0KIG90aGVyd2lzZT88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj45 LjguMiZuYnNwOyBDT1NFIEtleSBNZWRpYSBUeXBlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij51LiZuYnNwOyDigJxhcHBsaWNhdGlvbi9qd2smIzQzO2pzb27igJ0gc2hvdWxkIGJlIGNoYW5n ZWQgdG8gc29tZXRoaW5nIGxpa2Ug4oCcYXBwbGljYXRpb24vY29zZS1rZXnigJ0gYW5kIOKAnGFw cGxpY2F0aW9uL2p3ay1zZXQmIzQzO2pzb27igJ0gc2hvdWxkIGJlIGNoYW5nZWQgdG8gc29tZXRo aW5nIGxpa2Ug4oCcYXBwbGljYXRpb24vY29zZS1rZXktc2V04oCdLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+MTEuMi4mbmJzcDsgSW5mb3JtYXRpdmUgUmVmZXJlbmNlczxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+di4mbmJzcDsgVGhlIGRhdGUgb24gdGhlIEFFUy1HQ00gcmVmZXJl bmNlIChTUCA4MDAtMzhEKSBzaG91bGQgYmUgTm92ZW1iZXIgMjAwNyDigJMgbm90IEp1bmUgMjAx NS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFwcGVuZGl4IEEuJm5ic3A7IEFFQUQgYW5k IEFFIEFsZ29yaXRobXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPncuJm5ic3A7IFRoZSBz cGVjIHNheXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7IFRoaXMgYXV0 aGVudGljYXRpb24gdmFsdWUgbWF5IGJlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgbyZuYnNwOyBBIHNlcGFyYXRlbHkgZ2VuZXJhdGVkIHRhZyBj b21wdXRlZCBieSBib3RoIHRoZSBlbmNyeXB0ZXIgYW5kPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZWNyeXB0ZXIg YW5kIHRoZW4gY29tcGFyZWQgYnkgdGhlIGRlY3J5cHRvci4mbmJzcDsgVGhpcyB0YWcgdmFsdWUg bWF5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBiZSBlaXRoZXIgcGxhY2VkIGF0IHRoZSBlbmQgb2YgdGhlIGNpcGhl ciB0ZXh0ICh0aGUgZGVjaXNpb24gd2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1hZGUpIG9yIGtlcHQgc2VwYXJh dGVseSAodGhlIGRlY2lzaW9uIG1hZGUgYnkgdGhlIEpPU0Ugd29ya2luZzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Z3JvdXApLiZuYnNwOyBUaGlzIGlzIHRoZSBhcHByb2FjaCBmb2xsb3dlZCBieSBBRVMtR0NNIFtB RVMtR0NNXSBhbmQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFFUy1DQ00gW1JGQzM2MTBdLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBsYXN0IHNlbnRlbmNlIGlzIG5vdCB0cnVlLCBhcyB3 cml0dGVuLiZuYnNwOyBUaGUgQUVTLUdDTSBzcGVjIGRlc2NyaWJlcyDigJw8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjVwdCI+dGhlIGNpcGhlcnRleHQgYW5kIHRhZyBvdXRwdXRzPC9zcGFuPuKA nSDigJMgbm90IGEgc2luZ2xlIGNvbWJpbmVkIG91dHB1dC4mbmJzcDsgQ29tbW9uDQogaW1wbGVt ZW50YXRpb25zIGNvcnJlc3BvbmQgdG8gdGhpcywgc3VjaCBhcyB0aGUgaW1wbGVtZW50YXRpb24g b2YgR0NNIGluIC5ORVQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgQ0NNIGRlc2Ny aXB0aW9uIGluIFJGQyAzNjEwIFNlY3Rpb24gMi40IGRlc2NyaWJlcyB0aGUgb3V0cHV0IHVzaW5n IHRoZSB0ZXh0IOKAnFRoZSBmaW5hbCByZXN1bHQgYyBjb25zaXN0cyBvZiB0aGUgZW5jcnlwdGVk IG1lc3NhZ2UgZm9sbG93ZWQgYnkgdGhlIGVuY3J5cHRlZCBhdXRoZW50aWNhdGlvbiB2YWx1ZQ0K IFXigJ0sIHdoaWNoIGFkbWl0cyBlaXRoZXIgaW1wbGVtZW50YXRpb24uJm5ic3A7IExpa2V3aXNl LCBhdCBsZWFzdCB0aGUgLk5FVCBDQ00gaW1wbGVtZW50YXRpb24gcHJvZHVjZXMgc2VwYXJhdGUg Y2lwaGVydGV4dCBhbmQgYXV0aGVudGljYXRpb24gdGFnIHZhbHVlcy48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPldoZXRoZXIgdGhlIHRhZyBzaG91bGQgYmUgc2VwYXJhdGUgb3IgYXV0b21h dGljYWxseSBhcHBlbmRlZCB0byB0aGUgY2lwaGVydGV4dCBpc27igJl0IGEgaGlsbCBJ4oCZbSBn b2luZyB0byBkaWUgb24gKGFsdGhvdWdoIHRoZSB3b3JraW5nIGdyb3VwIHNob3VsZCBkaXNjdXNz IHRoaXMgYW5kIG1ha2UgYW4gZXhwbGljaXQNCiBkZWNpc2lvbiBpbiB0aGlzIHJlZ2FyZCksIGJ1 dCB0aGUgdGV4dCBkZXNjcmliaW5nIHRoZSBkZWNpc2lvbiBzaG91bGQgYXQgbGVhc3QgYmUgY2hh bmdlZCB0byBiZSBhY2N1cmF0ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJjb2xvcjpyZWQiPltKTFNdIFdyb25nIHJlZmVyZW5jZSDigJN3aWxsIGNvcnJlY3QuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXBwZW5kaXggQy4mbmJzcDsgRXhhbXBs ZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnguJm5ic3A7IFRoZSB1c2VzIG9mIHN0cmlu Z3MgYW5kIGNvcnJlc3BvbmRpbmcgbGFiZWxzIHN1Y2ggYXMgdGhvc2UgdGhhdCBmb2xsb3cgYXJl IGNvbmZ1c2luZyDigJMgZXNwZWNpYWxseSBzaW5jZSBrZXkgSUQgdmFsdWVzIGFyZSBiaW5hcnkg aW4gQ09TRS4mbmJzcDsgQSBmcmFnbWVudCBvZiBzdWNoIGFuIGV4YW1wbGUgdGhhdA0KIGNvbmZ1 c2VkIG1lIHdhczo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMzogezwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNTogJnF1b3Q7PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzpiaWxiby5iYWdnaW5zQGhvYmJpdG9uLmV4YW1wbGUiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmJpbGJvLmJhZ2dpbnNA aG9iYml0b24uZXhhbXBsZTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IH0sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlcmUgYXJlIHNpbWlsYXIg c3RyaW5ncyBpbiBzb21lIG9mIHRoZSBvdGhlciBleGFtcGxlcyB0aGF0IEkgYWxzbyBjb3VsZG7i gJl0IHdyYXAgbXkgaGVhZCBhcm91bmQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPltKTFNdIE15IGNvZGUgZG9lcyBub3QgbWF0 Y2ggdGhlIHNwZWMgaGVyZS4mbmJzcDsgT3JpZ2luYWxseSB0aGV5IHdlcmUgc3RyaW5ncy48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BcHBlbmRpeCBELiZuYnNwOyBDT1NFIEhl YWRlciBBbGdvcml0aG0gTGFiZWwgVGFibGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnku Jm5ic3A7IEkgd291bGQgY2hhbmdlIHRoZSB0ZXJtIOKAnEhlYWRlciBBbGdvcml0aG3igJ0gdG8g 4oCcSGVhZGVyIFBhcmFtZXRlcuKAnS4mbmJzcDsgKEkgc3VzcGVjdCB0aGlzIHdhcyBhIGN1dC1h bmQtcGFzdGUgZXJyb3IuKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5bSkxTXSBJIGhhdmUgbm90IHNldHRsZWQgb24gYSBjb25z aXN0ZW50IHNldCBvZiB0ZXJtcyBmb3IgdGhpcyB5ZXQuJm5ic3A7IEkgbmVlZCB0byBkbyBzbyBh bmQgdGhlbiBtYWtlIGEgcGFzcyB0byBjb3JyZWN0IHRoZW0gYWxsLiZuYnNwOyBJIGRvbuKAmXQg dGhpbmsgdGhhdCBzb21lIG9mDQogdGhlIHRlcm1zIEkgYW0gY3VycmVudGx5IHVzaW5nIGFyZSBz dWZmaWNpZW50bHkgZGlzdGluY3QgdG8gbWFrZSBpdCBlYXN5IHRvIGZpZ3VyZSB0aGluZ3Mgb3V0 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnouJm5ic3A7IEluIEFwcGVuZGl4 IEQgYW5kIEFwcGVuZGl4IEUsIEkgd291bGQgY2FsbCBvdXQgdGhhdCB0aGUgbmFtZXMgaW4gdGhl IOKAnG5hbWXigJ0gY29sdW1ucyBjb3JyZXNwb25kIHRvIG5hbWVzIGRlZmluZWQgaW4gUkZDIDc1 MTguPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjpyZWQiPltKTFNdIFRoZXNlIHRhYmxlcyBhcmUgZGlzYXBwZWFyaW5nIGFzIHBhcnQgb2Yg dGhlIGFkZCB0aGUgYWxnb3JpdGhtcyB0byB0aGUgZG9jdW1lbnQgZXhlcmNpc2UuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXBwZW5kaXggRi4mbmJzcDsgQ09TRSBHZW5lcmFs IFZhbHVlczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+YWEuJm5ic3A7IFRoaXMgc2VlbXMg Y29uZnVzZWQsIGFzIGl0IG1peGVzIOKAnGt0eeKAnSB2YWx1ZXMgKEVDPTEsIFJTQT0yLCBvY3Q9 Mykgd2l0aCBjdXJ2ZSB2YWx1ZXMgKFAyNTY9NCwgUDUyMT01KS4mbmJzcDsgSSB3b3VsZCBrZWVw IHRoZXNlIHNlcGFyYXRlLiZuYnNwOyBBbHNvLCB3aGVyZXZlciB0aGUgY3VydmUgbmFtZXMgYXJl IGRlZmluZWQsDQogSSB3b3VsZCBhbHNvIGluY2x1ZGUgUDM4NCwgYXMgSk9TRSBkaWQuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQi PltKTFNdIFRoYXQgbWF5IGhhcHBlbiBpbiB0aGUgZnV0dXJlLiZuYnNwOyBJIGp1c3QgbmVlZGVk IGEgdGFibGUgdG8gcHV0IHRoaW5ncyBpbiBmb3Igbm93Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxiPk5JVFM8L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHdp bGwgYmUgc3VibWl0dGluZyBzcGVsbGluZyBhbmQgZ3JhbW1hciBjb3JyZWN0aW9ucyBhcyBhIEdp dEh1YiBwdWxsIHJlcXVlc3QgYWdhaW5zdCB0aGUgc3BlYyByZXBvc2l0b3J5IHJhdGhlciB0aGFu IGRldGFpbCB0aGVtIGhlcmUuJm5ic3A7IEnigJlsbCBwb3N0IHRoZSBwdWxsIHJlcXVlc3QgbGlu ayBvbmNlIGl04oCZcw0KIGJlZW4gY3JlYXRlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPkNPTkNMVVNJT05TPC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SeKAmWQgbGlr ZSB0byB0aGFuayBKaW0gZm9yIGRvaW5nIHRoZSB3b3JrIHRvIHByb2R1Y2UgYSB3ZWxsLXRob3Vn aHQtb3V0IGluaXRpYWwgZHJhZnQuJm5ic3A7IEkgYmVsaWV2ZSBpdCBwcm92aWRlcyBhIHNvbGlk IHN0YXJ0aW5nIHBvaW50IGZvciB0aGUgQ09TRSB3b3JrLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SeKAmWQgYmUgd2lsbGluZyB0byBwcm9kdWNlIHNwZWNpZmljIHByb3Bvc2VkIGVkaXRz IGZvciBhbnkvYWxsIG9mIHRoZSBhYm92ZSBpc3N1ZXMgYW5kIGNvbW1lbnRzLCBzaG91bGQgdGhl IGVkaXRvcnMgZmluZCB0aGF0IHVzZWZ1bC4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEJlc3Qgd2lzaGVzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkNvc2UgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOkNvc2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5Db3NlQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY29zZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY29zZTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KQ29zZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Q29zZUBpZXRmLm9yZyI+ Q29zZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2Nvc2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2Nvc2U8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BY2PR03MB4427AB173398F8C37E49B9CF5920BY2PR03MB442namprd_-- From nobody Tue Jul 7 16:00: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 4552B1B29F6 for ; Tue, 7 Jul 2015 16:00:36 -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 FTw3u2sMJkiZ for ; Tue, 7 Jul 2015 16:00:32 -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 47E9C1B2A29 for ; Tue, 7 Jul 2015 16:00:31 -0700 (PDT) Received: from hebrews (174-21-18-91.tukw.qwest.net [174.21.18.91]) (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 DBA6C38F0E; Tue, 7 Jul 2015 16:00:01 -0700 (PDT) From: "Jim Schaad" To: "'Brian Campbell'" , "'Carsten Bormann'" References: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> <009501d0b392$fb7cc680$f2765380$@augustcellars.com> <00d001d0b3b6$ce20f2f0$6a62d8d0$@augustcellars.com> <559392F7.30000@tzi.org> <5594EA07.3030508@tzi.org> In-Reply-To: Date: Tue, 7 Jul 2015 15:58:56 -0700 Message-ID: <001601d0b908$c33baf90$49b30eb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01D0B8CE.16DF4890" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJBW2regVOc1KgJrCGEY9SFfcIRjgIjyzTpArNKyUYA0EcPdQJL5N93AtWHUysCrbMn0wGRZpBdAiF4EMoBhcnxkwGFYDl/AaP1+x4C0TL5IZwqDFng Content-Language: en-us Archived-At: Cc: 'Justin Richer' , 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: Tue, 07 Jul 2015 23:00:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0017_01D0B8CE.16DF4890 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 Sent: Thursday, July 02, 2015 10:14 AM To: Carsten Bormann Cc: Justin Richer; Jim Schaad; cose@ietf.org Subject: Re: [Cose] Issue: Encoding for a single recipient or structure =20 Some things translate more directly than others :) Indeed the dot joined base64url encoded segments are very array like. = And with CBOR that encoding and dot joining is unneeded. The JOSE experience I'm suggesting this WG consider is the relative = simplicity afforded by compact serializations and the widespread use = they have seen. [JLS] I don=E2=80=99t know how much of this is because it is easy, or = because that was the format that was being used by = =E2=80=9Ceverybody=E2=80=9D before it even came into the working group. = Remember how many decisions boiled down to =E2=80=93 we can=E2=80=99t = change this, it would break all of the existing code. =20 Conceptualizing the compact serializations as arrays, you have this for = signatures/macs: =20 [protected_header, payload, signature] and this for encryption: [protected_header, encrypted_key, initialization_vector, ciphertext, = authentication_tag] There's just a single recipient or just one signature. There's only one = place for headers and they are always protected. It's a (relatively) = simple and consistent processing model. The message can be processed or = not. There's real value in the simplicity.=20 =20 On Thu, Jul 2, 2015 at 1:36 AM, Carsten Bormann > wrote: I'm not sure the JOSE experience translates to COSE. In JOSE, there are two different forms, one array-based (a dot-joined sequence of base64 encodings of the array elements) and one map-based. COSE doesn't need that choice. All I can read from the JOSE experience cited here is a strong indicator that we want to go for arrays, not maps, at least for the outer = structure. Now whether that is shaped*) [pr, un, ciph, [r1, r2]] or [pr, un, ciph, r1] or [pr, un, ciph, *r1] (where *r1 means tha the contents of r1 is expanded right in place) becomes less of a complexity argument: [pr, un, ciph, [r1]] really isn't that much more complex than [pr, un, ciph, r1] except for that one 0x81 byte wasted; in a pinch, we can also go for [pr, un, ciph, r1, r2] (which is another way of saying: [pr, un, ciph, *[r1, r2]] ) Making the array variable size disables JOSE's hack of using the array size for distinguishing JWE from JWS. But we don't need that; CBOR has tags. Gr=C3=BC=C3=9Fe, Carsten *) I'm leaving msg_type out here, see other thread. =20 ------=_NextPart_000_0017_01D0B8CE.16DF4890 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From:<= /b> = Brian Campbell [mailto:bcampbell@pingidentity.com]
Sent: = Thursday, July 02, 2015 10:14 AM
To: Carsten = Bormann
Cc: Justin Richer; Jim Schaad; = cose@ietf.org
Subject: Re: [Cose] Issue: Encoding for a single = recipient or structure

 

Some things translate = more directly than others :)

Indeed the dot joined base64url = encoded segments are very array like. And with CBOR that encoding and = dot joining is unneeded.

The JOSE experience I'm suggesting this WG consider is = the relative simplicity afforded by compact serializations and the = widespread use they have seen.

[JL= S]=C2=A0 I don=E2=80=99t know how much of this is because it is easy, or = because that was the format that was being used by = =E2=80=9Ceverybody=E2=80=9D before it even came into the working = group.=C2=A0 Remember how many decisions boiled down to =E2=80=93 we = can=E2=80=99t change this, it would break all of the existing = code.


 
Conceptualizing the compact = serializations as arrays, you have this for = signatures/macs:

 

    [protected_header, = payload, signature]

and this = for encryption:


    [protected_header, = encrypted_key, initialization_vector, ciphertext, = authentication_tag]

There's just a single recipient or just one signature. = There's only one place for headers and they are always protected. It's a = (relatively) simple and consistent processing model. The message can be = processed or not. There's real value in the simplicity. =




 

On = Thu, Jul 2, 2015 at 1:36 AM, Carsten Bormann <cabo@tzi.org> = wrote:

I'm not = sure the JOSE experience translates to COSE.

In JOSE, there are = two different forms, one array-based (a dot-joined
sequence of base64 = encodings of the array elements) and one map-based.
COSE doesn't need = that choice.

All I can read from the JOSE experience cited here = is a strong indicator
that we want to go for arrays, not maps, at = least for the outer structure.

Now whether that is = shaped*)

[pr, un, ciph, [r1, r2]]

or

[pr, un, ciph, = r1]

or

[pr, un, ciph, *r1]

(where *r1 means tha the = contents of r1 is expanded right in place)

becomes less of a = complexity argument:
[pr, un, ciph, [r1]]
really isn't that much = more complex than
[pr, un, ciph, r1]
except for that one 0x81 byte = wasted; in a pinch, we can also go for

[pr, un, ciph, r1, = r2]
(which is another way of saying:
[pr, un, ciph, *[r1, = r2]]
)

Making the array variable size disables JOSE's hack of = using the array
size for distinguishing JWE from JWS.  But we = don't need that; CBOR has
tags.

Gr=C3=BC=C3=9Fe, = Carsten

*) I'm leaving msg_type out here, see other = thread.

 

------=_NextPart_000_0017_01D0B8CE.16DF4890-- From nobody Tue Jul 7 16:25: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 CCE9E1B2A2F for ; Tue, 7 Jul 2015 16:25:24 -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 91x4aMD4CZkn for ; Tue, 7 Jul 2015 16:25:23 -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 2183C1B2A13 for ; Tue, 7 Jul 2015 16:25:23 -0700 (PDT) Received: from hebrews (174-21-18-91.tukw.qwest.net [174.21.18.91]) (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 6F42238EE6; Tue, 7 Jul 2015 16:25:22 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" References: <559576A9.9090002@gmx.net> In-Reply-To: Date: Tue, 7 Jul 2015 16:25:39 -0700 Message-ID: <001001d0b90c$3c874af0$b595e0d0$@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: AQGMo9E7lz5K1VbQVek9kTd0WZ5EKwIS9FwIAQ3LxPSeP8TTEA== Content-Language: en-us Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] Key management for MACs (was Re: 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, 07 Jul 2015 23:25:25 -0000 > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Thursday, July 02, 2015 10:53 AM > To: Hannes Tschofenig; Brian Campbell; Jim Schaad > Cc: cose@ietf.org > Subject: RE: [Cose] Key management for MACs (was Re: Review of draft- > schaad-cose-msg-01) > > If MACs without key management were insecure, I'm sure that JWS [RFC > 7515] wouldn't have survived the SecDir review or the IESG review since it > has no key management for MACs, but it did. [JLS] There was no assumption that there was no key lifetime management for the case of JWS or JWE. The assumption was that the key management was being down outside of these documents. I am sure (or at least strongly hope) that nobody is suggesting that a single key was going to be negotiated between the sender and the receiver of a message and it would never be modified in the future. > > The question is what *additional* value key management adds in the MAC > case. http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/multi- forge-01.pdf provides a method to looking at how to attack a key. This would be done by looking at the recipient of the message as an oracle to see how it responds to messages. The more one uses the same key the more data there is to work with to attack keys. From this point of view, encryption can be better because traffic analysis might be all you get from re-using a key. Even doing something as simple as running the shared secret through a KDF (with perhaps a sequence number or time marker in the context) will make the system more secure as the same key is no longer being used to MAC every message. > > (I completely understand the value of key management in the encryption > case. If you're using a deterministic content encryption algorithm and > you're encrypting the same plaintext with the same key without key > management, the ciphertext values will match, allowing attackers to > correlate messages. Using a randomly generated content encryption key > means that encryptions of the same plaintext result in different ciphertext > values - preventing this correlation. But the payload in a MAC is not a > secret, so there's no equivalent benefit in the MAC case.) > > -- Mike > > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Thursday, July 02, 2015 10:37 AM > To: Brian Campbell; Jim Schaad > Cc: Mike Jones; cose@ietf.org > Subject: Re: [Cose] Key management for MACs (was Re: Review of draft- > schaad-cose-msg-01) > > > > > 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. > > It would be good to know what devices you have in mind in this discussion. > > I personally don't think we should target devices that cannot even do key > management for symmetric cryptography. I would even argue that we > should aim for devices that support a random number generator and are > also able to do public key crypto. > > We are not doing ourselves a flavor if we place artificial constraints on our > protocols that make them pretty insecure in practice. We already have > enough insecure IoT devices in the market. > > Here is the slide deck I presented in the LWIG group at the last IETF > meeting; it explains the performance of state-of-the-art crypto on common > Cortex M class MCUs. > https://www.ietf.org/proceedings/92/slides/slides-92-lwig-3.pdf > > Ciao > Hannes From nobody Wed Jul 8 05:29: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 622C81A9040 for ; Wed, 8 Jul 2015 05:29:51 -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 9JtghnP0iC3B for ; Wed, 8 Jul 2015 05:29:50 -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 15D5B1A1DE1 for ; Wed, 8 Jul 2015 05:29:31 -0700 (PDT) X-AuditID: 1209190d-f796f6d000005314-9e-559d17aa210a 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-2.mit.edu (Symantec Messaging Gateway) with SMTP id BF.69.21268.BA71D955; Wed, 8 Jul 2015 08:29:31 -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 t68CTUch002387 for ; Wed, 8 Jul 2015 08:29:30 -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 t68CTSYo020708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 8 Jul 2015 08:29:30 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_A01961EC-F02D-4C0C-81EC-8B7C4E3BA3DF" Message-Id: Date: Wed, 8 Jul 2015 08:29:28 -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+NgFrrHIsWRmVeSWpSXmKPExsUixCmqrLtafG6owfaPzBbTtk5ldWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxomDe1kL3ghUzNu9m6mB8RlfFyMnh4SAicSOeYvYIWwxiQv3 1rN1MXJxCAksZpJ4d+MOK0hCSOAIo8SSCSIQiS9MEvtuLwHrYBNQlZi/8hZTFyMHB7NAgkTv FFmQsDDQoJvvP7KB2LwCVhJH9jaygNgsAioS24/eBisXERCUuNtpDlGiJ/Ho6WN2kLCEgKzE 161yExh5ZyHMnIWkCMRmFtCWWLbwNTOErSmxv3s5C6a4hkTnt4msCxjZVjHKpuRW6eYmZuYU pybrFicn5uWlFuka6eVmluilppRuYgQHoyTvDsZ3B5UOMQpwMCrx8H6InBMqxJpYVlyZe4hR koNJSZQ37hFQiC8pP6UyI7E4I76oNCe1+BCjBAezkgjvec65oUK8KYmVValF+TApaQ4WJXHe TT/4QoQE0hNLUrNTUwtSi2CyMhwcShK83MCoExIsSk1PrUjLzClBSDNxcIIM5wEaXi0GMry4 IDG3ODMdIn+KUVFKnPcJSEIAJJFRmgfXC0sWrxjFgV4R5s0GqeIBJhq47ldAg5mABi/XnQUy uCQRISXVwGi/xmVa0Jp5ur9uH3ddxLXDKDRGkn2uxNXEv/w7Wndf3sSifPPZ2tZvzfV5W9sO THPqPnblwd9Omzv5W2MOud46XyR7suTsD0uHpVf8FigG7/VVibH7pPRk28so/3DlKsvn24T2 Bl1euM7UtuRiHaPotRnfHQ+93SjBvfhu7FG+zT62/9bUup9RYinOSDTUYi4qTgQAjyIidPEC AAA= Archived-At: Subject: [Cose] IETF93 Agenda 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, 08 Jul 2015 12:29:51 -0000 --Apple-Mail=_A01961EC-F02D-4C0C-81EC-8B7C4E3BA3DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi everyone,=20 This is what our current agenda is for IETF93: Opening & Welcome - 5min (Justin/Kepeng) Introduction to the COSE Working Group - 10min (Justin) Questions/transition - 5min ACE Requirements - 10min (Goran) Questions/transition - 5min COSE Messages Draft Current State - 10min (Jim) Issues and open discussion - 45min If you=E2=80=99d like a presentation slot, please let the chairs know. =E2=80=94 Justin= --Apple-Mail=_A01961EC-F02D-4C0C-81EC-8B7C4E3BA3DF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi everyone, 

This is what our current agenda is for IETF93:

Opening & Welcome - 5min (Justin/Kepeng)
Introduction to the COSE Working Group - = 10min (Justin)
 Questions/transition - 5min
ACE Requirements - 10min = (Goran)
 Questions/transition - 5min
COSE Messages Draft Current State - 10min = (Jim)
Issues and open = discussion - 45min


If = you=E2=80=99d like a presentation slot, please let the chairs = know.

 =E2=80= =94 Justin
= --Apple-Mail=_A01961EC-F02D-4C0C-81EC-8B7C4E3BA3DF-- From nobody Wed Jul 8 07:37:34 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 8969D1B36DD for ; Wed, 8 Jul 2015 07:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 fAy62ev_mMF7 for ; Wed, 8 Jul 2015 07:37:27 -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 021CA1B36CD for ; Wed, 8 Jul 2015 07:37:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 01500E2035; Wed, 8 Jul 2015 10:37: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 16915-06; Wed, 8 Jul 2015 10:37:16 -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 A364EE2034; Wed, 8 Jul 2015 10:37:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1436366236; bh=ZQiBuYs9YG3jzr0UGi5H1VbgBiO/if77yP/D8AXMyuE=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=hWp1nBpbIgh/O3zgrtQwF8eo9bhMRze0bnnzPIV09jkQfHM2knvp/OC4P2Rd0Z1L/ V2tFivxg8VBz9OwpMEgAiXOCyQlHnPGPYVqCSzwPn8i+unP0AhneMgzp2Mxk7FVkQD Jev7YvS2jqjqusqL5FerdX+so0+gfvcJxK3p82Dg= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t68EbFSh028137; Wed, 8 Jul 2015 10:37:15 -0400 From: Derek Atkins To: "Kepeng Li" References: <1B462EEC-67AF-4F19-B8F5-82BA36C59C8D@mit.edu> Date: Wed, 08 Jul 2015 10:37:15 -0400 In-Reply-To: (Kepeng Li's message of "Sat, 27 Jun 2015 22:45:26 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Justin Richer , 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: Wed, 08 Jul 2015 14:37:33 -0000 Well, I realize it's well after that deadline (sorry, I was on holiday this whole time), but I also approve of this as a starting point. Luckily my vote doesn't matter ;) -derek "Kepeng Li" writes: > Just to add that the deadline to provide your feedback is the end of 4th = Jul, > 2015. > > Thanks, > > Kind Regards > Kepeng (&Justin) > > =E5=8F=91=E4=BB=B6=E4=BA=BA: Justin Richer > =E6=97=A5=E6=9C=9F: Saturday, 27 June, 2015 10:18 am > =E8=87=B3: > =E4=B8=BB=E9=A2=98: [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 syn= tax > 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) > _______________________________________________ Cose mailing list=20 > Cose@ietf.org https://www.ietf.org/mailman/listinfo/cose > > _______________________________________________ > 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 Wed Jul 8 08:01: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 836FF1A000D for ; Wed, 8 Jul 2015 08:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3] 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 vHV28V-I0sMt for ; Wed, 8 Jul 2015 08:00:59 -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 550F81A0004 for ; Wed, 8 Jul 2015 08:00:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 383ABE2035; Wed, 8 Jul 2015 11:00:58 -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 17240-03; Wed, 8 Jul 2015 11:00:55 -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 4CFC7E2034; Wed, 8 Jul 2015 11:00:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1436367655; bh=pDZOqFGlW1ZVQg7sXM2Vh+TQ8sMRcmbmMz5XnrzOJZI=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=Sm0R4CBuNJWCiy/f3s9p4BSM4KW4dt0e7l1Yrx+2+3VmEx4vZbiQT1dTJoPAo5YDk arpQNkPczVtQYRNmpHnrv7x6DHod2O2uFltSesp+DV50hJLsyNA2fIZpsh7Jp3n5sH DukeQe7V06suZA5ZorG+AxO4n8LblkPgCh8uD0B4= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t68F0sjK029859; Wed, 8 Jul 2015 11:00:54 -0400 From: Derek Atkins To: Henrich =?utf-8?Q?P=C3=B6hls?= References: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> <009501d0b392$fb7cc680$f2765380$@augustcellars.com> <00d001d0b3b6$ce20f2f0$6a62d8d0$@augustcellars.com> <475F155D-6527-45D9-BC62-75CA0B34C706@2000grad.com> Date: Wed, 08 Jul 2015 11:00:54 -0400 In-Reply-To: <475F155D-6527-45D9-BC62-75CA0B34C706@2000grad.com> ("Henrich =?utf-8?Q?P=C3=B6hls=22's?= message of "Wed, 1 Jul 2015 17:13:55 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Jim Schaad , Dick Hardt , 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, 08 Jul 2015 15:01:00 -0000 Henrich P=C3=B6hls writes: > Dear Jim, > > On 01 Jul 2015, at 06:31, Jim Schaad wrote: > >> Part of the question is going to be where do you expect COSE to be >> used in the future. >>=20=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. > > Another application domain of COSE is integrity protection > (ECCsignatures, MACs), right? > I can think of use cases that benefit if you are capable of having a > compact and easily parseable representation of signed signed data. > An example could be if you facilitate signatures to check if data > originated at some sensor and also that it passed (and got vetted for) > by another constrained device (e.g. data concentrator). > > Just my thoughts. As I currently work towards finding a good > representation for cryptographically signed JSON messages to be > emitted by constrained devices, within the RERUM project, I was > following the discussions here. For this I would expect nested structures. E.g.: COSE_Signature(, payload: COSE_Signature(, payload: )) =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 Could we have a more compact representation of this? Possibly.. But I suspect the extra overhead of the nesting is not significantly more than the extra overhead of signaling a virtual-nesting. > Best, Henrich -derek --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Jul 8 08:09: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 6C5FA1A0029 for ; Wed, 8 Jul 2015 08:09:42 -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 CAo29fPoMxVx for ; Wed, 8 Jul 2015 08:09:41 -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 736351A001C for ; Wed, 8 Jul 2015 08:09:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id BECADE2036; Wed, 8 Jul 2015 11:09:38 -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 17222-08; Wed, 8 Jul 2015 11:09:36 -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 B097BE2034; Wed, 8 Jul 2015 11:09:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1436368176; bh=lsnfviLTGcBviv0ZtVmy77uGj8w2yjIjq/1Ms7VTC7Y=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=Ge0VJhOobY5yUmmyyJJQBNCUM7lAhtp8TD3hthGoD8SHTHuVXUlem7ZOuzc2QLwmX WcGQprxKMIpvYe3zUzrV7TF1djG/c6ABTsv6eKDpS3Bk7/viB3WLvtQ1+Jk8FEyPxy wkd2swgrj+ZXUtmcD4IigMMwhBNML91hjueyPtz4= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t68F9aV3030577; Wed, 8 Jul 2015 11:09:36 -0400 From: Derek Atkins To: "Jim Schaad" References: <002f01d0b388$57a1cc90$06e565b0$@augustcellars.com> Date: Wed, 08 Jul 2015 11:09:36 -0400 In-Reply-To: <002f01d0b388$57a1cc90$06e565b0$@augustcellars.com> (Jim Schaad's message of "Tue, 30 Jun 2015 15:58:54 -0700") 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: cose@ietf.org 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: Wed, 08 Jul 2015 15:09:42 -0000 "Jim Schaad" writes: > 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. I prefer AES-CMAC. > Jim -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Jul 8 09:27: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 4900B1A066C for ; Wed, 8 Jul 2015 09:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 KPy4Sr8iqF3p for ; Wed, 8 Jul 2015 09:27:10 -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 9E7631A066B for ; Wed, 8 Jul 2015 09:27:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 5FF9DE2035; Wed, 8 Jul 2015 12:27:08 -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 17726-08; Wed, 8 Jul 2015 12:27:06 -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 03117E2034; Wed, 8 Jul 2015 12:27:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1436372826; bh=mrjGBMAm5zEIP71UA974J9vu/lEr2VcVwB0k0xi6LOc=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=br/Snwz13soEN1wmwjb4Zj83JQUAp10Ve/ulHzkWs8ztlz96drjxPP9qM6ExEYiDP NjEAjPKvcyXqRuusYpe7jL7lXbVzrVlBxsQCw2DFqHDCccd+2+XygZZHh8WzPJGXcJ 0t7MO+j1TmGde1Sz6rZI/1pIm1NJytBAyHmeH9e0= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t68GR4oH002666; Wed, 8 Jul 2015 12:27:04 -0400 From: Derek Atkins To: Brian Campbell References: <002f01d0b388$57a1cc90$06e565b0$@augustcellars.com> <000a01d0b42c$4116d340$c34479c0$@augustcellars.com> Date: Wed, 08 Jul 2015 12:27:04 -0400 In-Reply-To: (Brian Campbell's message of "Wed, 1 Jul 2015 12:43:25 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Jim Schaad , cose@ietf.org 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: Wed, 08 Jul 2015 16:27:15 -0000 Brian Campbell writes: > I only represent a single data point but I've never seen anything other t= han > hash based MACs used in the applications I encounter. So #1 isn't real > convincing to me. > > #2 I can see. On the (extremely tiny) devices that I'm working with they provide an AES implementation in hardware, but they don't provide any hashes in hardware. This means I can implement an AES-CMAC and have it actually run relatively efficiently. Implementing any hash in software would take excessively long to run (assuming we could get an implementation to actually fit in the ROM). (For the record, we also have an ECDH replacement called Algebraic Eraser Diffie-Hellman, AEDH, which definitely does not require any Hash functionality). Also, all AEAD functonality is effectivtely using an AES-based MAC of some sort, be it CBC-MAC, CMAC, or a GF-based AES mac in GCM. -derek > On Wed, Jul 1, 2015 at 12:31 PM, Jim Schaad wrot= e: > > The motivation that I have is two-fold: >=20=20=20=20 > =C2=A0 >=20=20=20=20 > 1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0I have been told that this is = the more common way to do integrity > protection (i.e. AES based rather than hash based). >=20=20=20=20 > 2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yes there is probably going to be a = desire in the future to have a > minimal set of cryptographic primitives in silicon.=C2=A0 I do not cu= rrently > believe that one can completely get rid of hash functions if one want= s to > do ECDH key agreement, but for other configurations it would be possi= ble > to do AES only. >=20=20=20=20 > =C2=A0 >=20=20=20=20 > Jim >=20=20=20=20 > =C2=A0 >=20=20=20=20 > =C2=A0 >=20=20=20=20 > From: Brian Campbell [mailto:bcampbell@pingidentity.com] > Sent: Wednesday, July 01, 2015 8:35 AM > To: Mike Jones > Cc: Jim Schaad; cose@ietf.org > Subject: Re: [Cose] AES based MAC algorithm >=20=20=20=20 > =C2=A0 >=20=20=20=20 > What's the motivation for an AES based MAC (vs. say an HMAC)? Is it t= he > hope that a broader set of COSE could be supported by something that = only > has to support AES? Or something else?=C2=A0 >=20=20=20=20 > =C2=A0 >=20=20=20=20 > On Tue, Jun 30, 2015 at 5:20 PM, Mike Jones > wrote: >=20=20=20=20 > Do you have data on how commonly available implementations of the= se > algorithms are to help inform the choice?=C2=A0 As you know, in J= OSE we > drove the set of algorithm choices off of a survey of which algor= ithms > were implemented on which common development platforms.=C2=A0 (Se= e the > attached spreadsheet.) >=20=20=20=20=20=20=20=20 > I realize that in this case, the right sets of development platfo= rms > to survey may be different than the largely Web-targeted developm= ent > platforms that JOSE surveyed.=C2=A0 For COSE, the right tools are= more > likely to be embedded systems development platforms. >=20=20=20=20=20=20=20=20 > Anyway, if we can make this choice based on data, that would be g= ood.=C2=A0 > If the data shows that people will have to largely build AES-MAC = or > AES-CMAC from scratch because their platforms don't support eithe= r of > them, then I agree with your preference for AES-CMAC. >=20=20=20=20=20=20=20=20 > =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: Tuesday, June 30, 2015 3:59 PM > To: cose@ietf.org > Subject: [Cose] AES based MAC algorithm >=20=20=20=20=20=20=20=20 > In doing the work on getting algorithms into the document I ended= up > with a "Which one" question. >=20=20=20=20=20=20=20=20 > AES-MAC has historically been the block cipher MAC algorithm used= by > most people.=C2=A0 In part because it has been around the longest= .=C2=A0 It does > the traditional AES-CBC mode of encryption and then takes the last > block of the output as the MAC value. >=20=20=20=20=20=20=20=20 > AES-CMAC (also known as AES-OMAC1) is a variant of the same algor= ithm > which uses one extra encryption operation and an XOR operation at= the > end of the process to provide higher security than is available w= ith > AES-MAC.=C2=A0 Details of this algorithm can be found in RFC 4493. >=20=20=20=20=20=20=20=20 > Do people have a preference as to which of these two algorithms is > specified?=C2=A0 My personal preference leans towards using the n= ewer > algorithm as there is not a significant performance penalty and it > appears to have better security properties. >=20=20=20=20=20=20=20=20 > Jim > > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose >=20=20=20=20=20=20=20=20 > =C2=A0 > > _______________________________________________ > 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 Wed Jul 8 09:36: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 E16FF1A0AC8 for ; Wed, 8 Jul 2015 09:36:15 -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 UuztZKu5Tkfd for ; Wed, 8 Jul 2015 09:36:14 -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 2FD471A040B for ; Wed, 8 Jul 2015 09:36:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 07952E2035; Wed, 8 Jul 2015 12:36:13 -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 18077-01; Wed, 8 Jul 2015 12:36:11 -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 D94B2E2034; Wed, 8 Jul 2015 12:36:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1436373370; bh=+iT8bKFNdL2VfgQufoQNheLWFBlz4mwR6vZ0QNnnpJs=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=FlHr97Uk0Y9T9eXTQeh6/gyOQIWyOlHzmeQ8Lj3Y+mreDOIJ/ne/nF+4UGw8BvHpb MUUVvCEdr87gLU9x7X4XGKMfZY16O8+Q3VLGcirO02dUNpK++EuPoRMi9MMkSFjq/f 4RVOXJqn/4nbFV2/jv6yLIeY1zOEwZBncVbJDaAk= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t68GaA9w003245; Wed, 8 Jul 2015 12:36:10 -0400 From: Derek Atkins To: Sandeep Kumar References: <002f01d0b388$57a1cc90$06e565b0$@augustcellars.com> <00b401d0b864$21aeab40$650c01c0$@augustcellars.com> Date: Wed, 08 Jul 2015 12:36:10 -0400 In-Reply-To: (Sandeep Kumar's message of "Tue, 7 Jul 2015 11:35:30 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Jim Schaad , cose WG 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: Wed, 08 Jul 2015 16:36:16 -0000 Sandeep Kumar writes: > I support AES-CMAC as this is the preferred algorithm for MAC on systems = we > build. Would really like to see that gap filled in Cose, > AES-CCM uses AES-MAC (aka AES-CBC-MAC) but the construction is secure only > when used within AES-CCM. Off topic for COSE, but I was considering writing up a draft that specifies an AES-CCM+ that is really how to use AES-CTR + AES-CMAC in a construction similar to AES-CCM (i.e., AES-CCM but replace CBC-MAC with CMAC). Would you support me in that effort? :) > regards > Sandeep -derek > Philips Lighting > > On Tue, Jul 7, 2015 at 5:22 AM, Jim Schaad wrote: > > > -----Original Message----- > > From: Martin Thomson [mailto:martin.thomson@gmail.com] > > Sent: Wednesday, July 01, 2015 11:38 AM > > To: Jim Schaad > > Cc: cose WG > > Subject: Re: [Cose] AES based MAC algorithm > > > > On 30 June 2015 at 15:58, Jim Schaad wrote: > > > Do people have a preference as to which of these two algorithms is > > > specified? > > > > Objection: leading the witness.=C2=A0 I thought that neither would = be a good > > choice.=C2=A0 AEAD encompasses a MAC (neither of these), and the ha= shes that > > we have defined seem sufficient. >=20=20=20=20 > AES-CCM uses AES-MAC (not CMAC) for the purpose of computing the MAC = value > portion. >=20=20=20=20 > Jim >=20=20=20=20 > > > > This seems wholly speculative. >=20=20=20=20 > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Jul 8 09:44: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 81A0B1A1A40 for ; Wed, 8 Jul 2015 09:44:26 -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 IM6wTMQYuBAo for ; Wed, 8 Jul 2015 09:44:25 -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 6D8341A1A3D for ; Wed, 8 Jul 2015 09:44:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 3398EE2036; Wed, 8 Jul 2015 12:44:24 -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 18077-04; Wed, 8 Jul 2015 12:44:22 -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 DEA66E2034; Wed, 8 Jul 2015 12:44:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1436373861; bh=QS6KN9eqfJVCrMrFBCQIsoDFa2z2/fpGh5mbqbA3lNk=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=YzoWehnWEtH/vN8+OTm6yTX12N9kBkfYJtbojedx+beUZumo5IgTQ/sMPUnAc64mo /+lZHAfiaeQOg0W/nfwCuR/BJfcW4lLhLPFB5Ob9RoJKWM1RUf99m5fe1IKZmAukjN sseTpyCfY++WYrSsv9iW2EDgKQXR+A4nlPgqLv1I= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t68GiLA1003774; Wed, 8 Jul 2015 12:44:21 -0400 From: Derek Atkins To: Hannes Tschofenig References: <559576A9.9090002@gmx.net> Date: Wed, 08 Jul 2015 12:44:21 -0400 In-Reply-To: <559576A9.9090002@gmx.net> (Hannes Tschofenig's message of "Thu, 02 Jul 2015 19:36:41 +0200") 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 , Brian Campbell , Mike Jones , cose@ietf.org Subject: Re: [Cose] Key management for MACs (was Re: 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: Wed, 08 Jul 2015 16:44:26 -0000 Hannes Tschofenig writes: >> 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. > > It would be good to know what devices you have in mind in this discussion. > > I personally don't think we should target devices that cannot even do > key management for symmetric cryptography. I would even argue that we > should aim for devices that support a random number generator and are > also able to do public key crypto. I agree with all of this except for the RNG. You don't need an RNG for many use cases and can perform good security. But of course it does depend on the use-case. > We are not doing ourselves a flavor if we place artificial constraints > on our protocols that make them pretty insecure in practice. We already > have enough insecure IoT devices in the market. Sure.. Many IoT devices don't even try :) > Here is the slide deck I presented in the LWIG group at the last IETF > meeting; it explains the performance of state-of-the-art crypto on > common Cortex M class MCUs. I would quickly argue it's not "state-of-the-art" crypto. It's ECC. There are ... better... key agreement algorithms out there for IoT. > https://www.ietf.org/proceedings/92/slides/slides-92-lwig-3.pdf :) > Ciao > Hannes -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Wed Jul 8 10:37: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 58C4D1A1BB8 for ; Wed, 8 Jul 2015 10:37:19 -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 yE3BhT5rCjpT for ; Wed, 8 Jul 2015 10:37:17 -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 503841A1BD1 for ; Wed, 8 Jul 2015 10:37:17 -0700 (PDT) Received: from hebrews (174-21-18-91.tukw.qwest.net [174.21.18.91]) (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 4551D38F11; Wed, 8 Jul 2015 10:37:16 -0700 (PDT) From: "Jim Schaad" To: "'Derek Atkins'" , "'Hannes Tschofenig'" References: <559576A9.9090002@gmx.net> In-Reply-To: Date: Wed, 8 Jul 2015 10:37:33 -0700 Message-ID: <00b301d0b9a4$c62234d0$52669e70$@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: AQGMo9E7lz5K1VbQVek9kTd0WZ5EKwIS9FwIAZ9xFnKePG4f4A== Content-Language: en-us Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] Key management for MACs (was Re: 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: Wed, 08 Jul 2015 17:37:19 -0000 I will freely admit that I do not know what the sizes of constrained devices are today. Based on the talks that I have heard on what is a constrained device, I generally think of a range starting with a Z80 plus some side hardware for AES and work up from there. I generally don't think of 286's as being all of that constrained let alone something that can actually do 64-bit natively. At that point all one is looking at is power supply constraints. Jim > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: Wednesday, July 08, 2015 9:44 AM > To: Hannes Tschofenig > Cc: Brian Campbell; Jim Schaad; Mike Jones; cose@ietf.org > Subject: Re: [Cose] Key management for MACs (was Re: Review of draft- > schaad-cose-msg-01) > > Hannes Tschofenig writes: > > >> 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. > > > > It would be good to know what devices you have in mind in this > discussion. > > > > I personally don't think we should target devices that cannot even do > > key management for symmetric cryptography. I would even argue that we > > should aim for devices that support a random number generator and are > > also able to do public key crypto. > > I agree with all of this except for the RNG. You don't need an RNG for many > use cases and can perform good security. But of course it does depend on > the use-case. > > > We are not doing ourselves a flavor if we place artificial constraints > > on our protocols that make them pretty insecure in practice. We > > already have enough insecure IoT devices in the market. > > Sure.. Many IoT devices don't even try :) > > > Here is the slide deck I presented in the LWIG group at the last IETF > > meeting; it explains the performance of state-of-the-art crypto on > > common Cortex M class MCUs. > > I would quickly argue it's not "state-of-the-art" crypto. It's ECC. > There are ... better... key agreement algorithms out there for IoT. > > > https://www.ietf.org/proceedings/92/slides/slides-92-lwig-3.pdf > > :) > > > Ciao > > Hannes > > -derek > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant From nobody Wed Jul 8 10:44: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 02A941A1BFE for ; Wed, 8 Jul 2015 10:44:42 -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 YSY-2CtIGoII for ; Wed, 8 Jul 2015 10:44:40 -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 446191A1E0E for ; Wed, 8 Jul 2015 10:44:31 -0700 (PDT) Received: from hebrews (174-21-18-91.tukw.qwest.net [174.21.18.91]) (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 AF43E38EEB; Wed, 8 Jul 2015 10:44:30 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" References: <559576A9.9090002@gmx.net> <001001d0b90c$3c874af0$b595e0d0$@augustcellars.com> In-Reply-To: <001001d0b90c$3c874af0$b595e0d0$@augustcellars.com> Date: Wed, 8 Jul 2015 10:44:47 -0700 Message-ID: <00c501d0b9a5$c8f869d0$5ae93d70$@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: AQGMo9E7lz5K1VbQVek9kTd0WZ5EKwIS9FwIAQ3LxPQB/WXDmJ4xEk7w Content-Language: en-us Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] Key management for MACs (was Re: 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: Wed, 08 Jul 2015 17:44:42 -0000 Another case where key management for MACs can be very useful is the case of DH direct. This allows for creating of a new unique key for the MAC every time, while not needing to keep per connection secrets for everything. Just what security service do you exect to get from a MAC? That is going to control how you feel about doing key management. > -----Original Message----- > From: Cose [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Tuesday, July 07, 2015 4:26 PM > To: 'Mike Jones' > Cc: cose@ietf.org > Subject: Re: [Cose] Key management for MACs (was Re: Review of draft- > schaad-cose-msg-01) > > > > > -----Original Message----- > > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > > Sent: Thursday, July 02, 2015 10:53 AM > > To: Hannes Tschofenig; Brian Campbell; Jim Schaad > > Cc: cose@ietf.org > > Subject: RE: [Cose] Key management for MACs (was Re: Review of draft- > > schaad-cose-msg-01) > > > > If MACs without key management were insecure, I'm sure that JWS [RFC > > 7515] wouldn't have survived the SecDir review or the IESG review > > since it has no key management for MACs, but it did. > > [JLS] There was no assumption that there was no key lifetime management > for the case of JWS or JWE. The assumption was that the key management > was being down outside of these documents. I am sure (or at least strongly > hope) that nobody is suggesting that a single key was going to be > negotiated between the sender and the receiver of a message and it would > never be modified in the future. > > > > > The question is what *additional* value key management adds in the > MAC > > case. > > http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC- > GCM/multi- > forge-01.pdf > > provides a method to looking at how to attack a key. This would be done > by looking at the recipient of the message as an oracle to see how it > responds to messages. The more one uses the same key the more data > there is to work with to attack keys. From this point of view, encryption > can be better because traffic analysis might be all you get from re-using a > key. > > Even doing something as simple as running the shared secret through a KDF > (with perhaps a sequence number or time marker in the context) will make > the system more secure as the same key is no longer being used to MAC > every message. > > > > > (I completely understand the value of key management in the encryption > > case. If you're using a deterministic content encryption algorithm > > and you're encrypting the same plaintext with the same key without key > > management, the ciphertext values will match, allowing attackers to > > correlate messages. Using a randomly generated content encryption key > > means that encryptions of the same plaintext result in different > ciphertext > > values - preventing this correlation. But the payload in a MAC is not > > a secret, so there's no equivalent benefit in the MAC case.) > > > > -- Mike > > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > > Sent: Thursday, July 02, 2015 10:37 AM > > To: Brian Campbell; Jim Schaad > > Cc: Mike Jones; cose@ietf.org > > Subject: Re: [Cose] Key management for MACs (was Re: Review of draft- > > schaad-cose-msg-01) > > > > > > > > > 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. > > > > It would be good to know what devices you have in mind in this > discussion. > > > > I personally don't think we should target devices that cannot even do > > key management for symmetric cryptography. I would even argue that we > > should aim for devices that support a random number generator and are > > also able to do public key crypto. > > > > We are not doing ourselves a flavor if we place artificial constraints > > on > our > > protocols that make them pretty insecure in practice. We already have > > enough insecure IoT devices in the market. > > > > Here is the slide deck I presented in the LWIG group at the last IETF > > meeting; it explains the performance of state-of-the-art crypto on > > common Cortex M class MCUs. > > https://www.ietf.org/proceedings/92/slides/slides-92-lwig-3.pdf > > > > Ciao > > Hannes > > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Wed Jul 8 11:14: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 0C8631A6F17 for ; Wed, 8 Jul 2015 11:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_47=0.6, MIME_8BIT_HEADER=0.3, 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 TXOet7c6iptw for ; Wed, 8 Jul 2015 11:14:22 -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 ED5361A6EFE for ; Wed, 8 Jul 2015 11:14:21 -0700 (PDT) Received: from hebrews (174-21-18-91.tukw.qwest.net [174.21.18.91]) (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 59D7C38EFD; Wed, 8 Jul 2015 11:14:21 -0700 (PDT) From: "Jim Schaad" To: =?iso-8859-1?Q?'Henrich_P=F6hls'?= References: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> <009501d0b392$fb7cc680$f2765380$@augustcellars.com> <00d001d0b3b6$ce20f2f0$6a62d8d0$@augustcellars.com> <475F155D-6527-45D9-BC62-75CA0B34C706@2000grad.com> In-Reply-To: <475F155D-6527-45D9-BC62-75CA0B34C706@2000grad.com> Date: Wed, 8 Jul 2015 11:14:38 -0700 Message-ID: <000801d0b9a9$f43db240$dcb916c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQJBW2regVOc1KgJrCGEY9SFfcIRjgIjyzTpArNKyUYA0EcPdQJL5N93AtWHUysCrbMn0wGRZpBdAVmCPBucbYz08A== 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, 08 Jul 2015 18:14:23 -0000 > -----Original Message----- > From: Henrich P=F6hls [mailto:henrich@2000grad.com] > Sent: Wednesday, July 01, 2015 8:14 AM > To: Jim Schaad > Cc: Dick Hardt; cose@ietf.org > Subject: Re: [Cose] Issue: Encoding for a single recipient or = structure >=20 > Dear Jim, >=20 > On 01 Jul 2015, at 06:31, Jim Schaad wrote: >=20 > > 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. >=20 > Another application domain of COSE is integrity protection = (ECCsignatures, > MACs), right? > I can think of use cases that benefit if you are capable of having a compact > and easily parseable representation of signed signed data. > An example could be if you facilitate signatures to check if data originated > at some sensor and also that it passed (and got vetted for) by another > constrained device (e.g. data concentrator). >=20 > Just my thoughts. As I currently work towards finding a good > representation for cryptographically signed JSON messages to be = emitted > by constrained devices, within the RERUM project, I was following the > discussions here. Sorry -I had intended to respond to this message when I did the last = pass through and forgot. I can think of three different ways to handle this depending on what restrictions on wishes to impose on implementations. It will also = depend on what you are using for algorithms. For example, it might be that the = sensor is sending data to the vetter using a MAC algorithm rather than a = signature algorithm. In this case the vetter would just rebuild the message and = put a signature on it. Part of the data that it signs would then be the identifier of the sensor that the message came from. If one is using a signature algorithm on both the sensor and the vetter = one could do any of the following: 1) Just nest the signature structures like Derik suggested. This gives = you Sign(Sign(content, sensor), vetter) 2) Follow the same construct as the countersignature attribute in CMS. This means that a new unprotected attribute is created which would be a signature by the vetter on the signature of the sensor. This gives: Signed(content, sensor, unprotected-countersign(sensor-signature, vetter)) 3) It would be possible to do something similar to a countersignature, = but have it be a bit bigger in terms of what is signed. Have two signatures = on the content. The first is the normal signature of the sensor. The = second would be signature over the sensor payload plus a part of the sensors signature. This can be indicated by new protected attribute that = indicates that this the case. You would then end up with two signatures on the content and could validate either one, checking or not checking the = vetter's correctness as needed. Signed( sign(content, sensor), sign(content+sensor-signature, = vetter)) Jim >=20 > Best, Henrich From nobody Wed Jul 8 14:47: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 A4EE71A887C for ; Wed, 8 Jul 2015 14:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 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] 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 iVFcMuGNyOns for ; Wed, 8 Jul 2015 14:47:12 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (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 A95E11A887B for ; Wed, 8 Jul 2015 14:47:11 -0700 (PDT) Received: by lbnk3 with SMTP id k3so64294226lbn.1 for ; Wed, 08 Jul 2015 14:47:09 -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:date :message-id:subject:from:to:cc:content-type; bh=SzagaiZ2y9YghBqG/pyYoVsSWqacfYDaynzwvA/TBFc=; b=GhYwtrCV3n8Z/1JUNaIoex5yKFffK//oajMUBXMIBlYlSFOy7U00/3CKggLizrkW3L EsLfkji6fazRYmIXZC+e5leihAz31xtM2p3SMXFZ2cKvpMWgwjPT5BOIbE/KnU2hKCK4 n68WGLfskTzS+pl8WfFgYsC6DpOJWZdDq4VbtDR1H4HMhKy3iIqC7hs1eANCtRZehrcz rqE2yY1JVlM9aQZcq58VQr5Hw3LotiqPKkoQR/DB8gBl9WvVdUbNtQzCEyh+IV/MtBpQ 1iPDcR16KSeqe35mLV9OCWjsoHb62spQQG9p0zv4CHENnzKS1dBl8xR8Ptoa3t8rE7c/ fOCg== X-Gm-Message-State: ALoCoQmx0v+4Cv3Ks5h9scNvwwQA82Ik+KOHkTdp+7z6CC1wYYOZAt5DXJFR6WmfglZa48BY4gFx MIME-Version: 1.0 X-Received: by 10.152.37.102 with SMTP id x6mr11527893laj.69.1436392029746; Wed, 08 Jul 2015 14:47:09 -0700 (PDT) Received: by 10.152.87.112 with HTTP; Wed, 8 Jul 2015 14:47:09 -0700 (PDT) In-Reply-To: References: <002f01d0b388$57a1cc90$06e565b0$@augustcellars.com> <00b401d0b864$21aeab40$650c01c0$@augustcellars.com> Date: Wed, 8 Jul 2015 23:47:09 +0200 Message-ID: From: Samuel Erdtman To: Derek Atkins Content-Type: multipart/alternative; boundary=089e0160c154b10e1f051a641450 Archived-At: Cc: Jim Schaad , Sandeep Kumar , cose WG 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: Wed, 08 Jul 2015 21:47:14 -0000 --089e0160c154b10e1f051a641450 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I do not really have any strong preference regarding AES-MAC or AES-CMAC just a comment with regards to HMAC and constrained devices. During spring I got my hands on a TWN3 RFID reader, it has a C like scripting language that only supports bytes and byte-arrays and I wanted to do HOTP (HMAC) on it, so I ported the reference implementation to C with these constraints (only bytes) and then I where in the process of porting it to the scripting language and got halfway before the memory was full. My code was not highly optimised but I don=C2=B4t think I would be able to shrink it to half the s= ize, i.e. if there is no hardware support it can he hard to fit sha1. Best Regards //Samuel Erdtman On Wed, Jul 8, 2015 at 6:36 PM, Derek Atkins wrote: > Sandeep Kumar writes: > > > I support AES-CMAC as this is the preferred algorithm for MAC on system= s > we > > build. Would really like to see that gap filled in Cose, > > AES-CCM uses AES-MAC (aka AES-CBC-MAC) but the construction is secure > only > > when used within AES-CCM. > > Off topic for COSE, but I was considering writing up a draft that > specifies an AES-CCM+ that is really how to use AES-CTR + AES-CMAC in a > construction similar to AES-CCM (i.e., AES-CCM but replace CBC-MAC with > CMAC). Would you support me in that effort? :) > > > regards > > Sandeep > > -derek > > > Philips Lighting > > > > On Tue, Jul 7, 2015 at 5:22 AM, Jim Schaad > wrote: > > > > > -----Original Message----- > > > From: Martin Thomson [mailto:martin.thomson@gmail.com] > > > Sent: Wednesday, July 01, 2015 11:38 AM > > > To: Jim Schaad > > > Cc: cose WG > > > Subject: Re: [Cose] AES based MAC algorithm > > > > > > On 30 June 2015 at 15:58, Jim Schaad > wrote: > > > > Do people have a preference as to which of these two algorithms > is > > > > specified? > > > > > > Objection: leading the witness. I thought that neither would be = a > good > > > choice. AEAD encompasses a MAC (neither of these), and the hashe= s > that > > > we have defined seem sufficient. > > > > AES-CCM uses AES-MAC (not CMAC) for the purpose of computing the MA= C > value > > portion. > > > > Jim > > > > > > > > This seems wholly speculative. > > > > _______________________________________________ > > 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 > > -- > 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 > --089e0160c154b10e1f051a641450 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I do not really have any stro= ng preference regarding AES-MAC or AES-CMAC just a comment with regards to = HMAC and constrained devices. During spring I got my hands on a TWN3 RFID r= eader, it has a C like scripting language that only supports bytes and byte= -arrays and I wanted to do HOTP (HMAC) on it, so I ported the reference imp= lementation to C with these constraints (only bytes) and then I where in th= e process of porting it to the scripting language and got halfway before th= e memory was full. My code was not highly optimised but I don=C2=B4t think = I would be able to shrink it to half the size, i.e. if there is no hardware= support it can he hard to fit sha1.

Best Regards
<= div>//Samuel Erdtman

On Wed, Jul 8, 2015 at 6:36 PM, Derek Atkins <derek@ihtfp.c= om> wrote:
Sandeep Kumar <ietf@sandeep.de&g= t; writes:

> I support AES-CMAC as this is the preferred algorithm for MAC on syste= ms we
> build. Would really like to see that gap filled in Cose,
> AES-CCM uses AES-MAC (aka AES-CBC-MAC) but the construction is secure = only
> when used within AES-CCM.

Off topic for COSE, but I was considering writing up a draft that specifies an AES-CCM+ that is really how to use AES-CTR + AES-CMAC in a
construction similar to AES-CCM (i.e., AES-CCM but replace CBC-MAC with
CMAC).=C2=A0 Would you support me in that effort?=C2=A0 :)

> regards
> Sandeep

-derek

> Philips Lighting
>
> On Tue, Jul 7, 2015 at 5:22 AM, Jim Schaad <ietf@augustcellars.com> wrote:
>
>=C2=A0 =C2=A0 =C2=A0> -----Original Message-----
>=C2=A0 =C2=A0 =C2=A0> From: Martin Thomson [mailto:martin.thomson@gmail.com]
>=C2=A0 =C2=A0 =C2=A0> Sent: Wednesday, July 01, 2015 11:38 AM
>=C2=A0 =C2=A0 =C2=A0> To: Jim Schaad
>=C2=A0 =C2=A0 =C2=A0> Cc: cose WG
>=C2=A0 =C2=A0 =C2=A0> Subject: Re: [Cose] AES based MAC algorithm >=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> On 30 June 2015 at 15:58, Jim Schaad <ietf@augustcellars.com> wrote:<= br> >=C2=A0 =C2=A0 =C2=A0> > Do people have a preference as to which o= f these two algorithms is
>=C2=A0 =C2=A0 =C2=A0> > specified?
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Objection: leading the witness.=C2=A0 I though= t that neither would be a good
>=C2=A0 =C2=A0 =C2=A0> choice.=C2=A0 AEAD encompasses a MAC (neither = of these), and the hashes that
>=C2=A0 =C2=A0 =C2=A0> we have defined seem sufficient.
>
>=C2=A0 =C2=A0 =C2=A0AES-CCM uses AES-MAC (not CMAC) for the purpose of = computing the MAC value
>=C2=A0 =C2=A0 =C2=A0portion.
>
>=C2=A0 =C2=A0 =C2=A0Jim
>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> This seems wholly speculative.
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0Cose mailing list
>=C2=A0 =C2=A0 =C2=A0Cose@ietf.org<= br> >=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listi= nfo/cose
>
> _______________________________________________
> Cose mailing list
> Cose@ietf.org
> https://www.ietf.org/mailman/listinfo/cose

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0Derek Atkins=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0617-623-3745
=C2=A0 =C2=A0 =C2=A0 =C2=A0derek@ihtfp.c= om=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0www.ihtfp.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0Computer and Internet Security Consultant

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

--089e0160c154b10e1f051a641450-- From nobody Thu Jul 9 09:51:14 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 40DA61A0242 for ; Thu, 9 Jul 2015 09:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 6jcFzFgkbgvo for ; Thu, 9 Jul 2015 09:51:05 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 508BB1A01F7 for ; Thu, 9 Jul 2015 09:51:01 -0700 (PDT) Received: by igrv9 with SMTP id v9so228003131igr.1 for ; Thu, 09 Jul 2015 09:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lMyEuqvaamyacW+i1F2MiSN9nYND4lDEW8dqOphOEec=; b=aIJ59eU4UVF3pu2Yve95nHKDBTE1KkHv889ERt+wMN3ylpHYVdu020jtLtF9LXZlsh D3E7PiOI0oO9UkTzfmKgA+xd94kghEft5wWZKhy/HFehdHmIG8I4UyKfVSuzUku/zqFI zVnvd0Vw31Dho6EqqZW/MRBRUN1R6kCs1OdHk= 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=lMyEuqvaamyacW+i1F2MiSN9nYND4lDEW8dqOphOEec=; b=eMv0vcqVyOABOahI9x2eQEM3Ii6vhV15ni1SVgR+wZyQv3t0bhJUQJYK1veyosgUvj jWOUpkdqg14P7voWK5yZg0VtOknsFk3HvMpawWSUJHg2WKYm/Ot5O5+CtU8/PHS5tGL1 REobTi9pjsqSWotiJ905+k+gc6KNFCUcCjLUZOth/YxMvSrtu0FQO9y0MA972MjgUyNK IG/evmUtipnOxxQtb6K/SiuLt1jBRwIpYrYprmlOKn4G7vS2DYyx8A1p2YFJY7u26kOB FYQr2eatRWHoy7+y/6dTVbhk391PDoIi0SIuA4YtPIFzJAy7udup7B+xdusjw/HgybNO eqlQ== X-Gm-Message-State: ALoCoQmx14Tfi61tLnWs4upQYEuDXbXUId8d7ilRRLGfy3t2hv8c1/iqPg9TyGoAKN4Prj4SAqtB X-Received: by 10.107.159.66 with SMTP id i63mr28883252ioe.68.1436460660680; Thu, 09 Jul 2015 09:51:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Thu, 9 Jul 2015 09:50:31 -0700 (PDT) In-Reply-To: <008101d0b906$0e744e70$2b5ceb50$@augustcellars.com> References: <000201d0b0ed$755707c0$60051740$@augustcellars.com> <3C5E1125-371E-40E6-BD72-19C63F76DF58@mit.edu> <008101d0b906$0e744e70$2b5ceb50$@augustcellars.com> From: Brian Campbell Date: Thu, 9 Jul 2015 10:50:31 -0600 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=001a1141b9606a0d5c051a740f30 Archived-At: Cc: Mike Jones , Justin Richer , 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: Thu, 09 Jul 2015 16:51:13 -0000 --001a1141b9606a0d5c051a740f30 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I wasn't necessarily suggesting that a new/different term be used (and apologize for a general ignorance about CMS). I just wanted to reconcile how =E2=80=9Ckey management=E2=80=9D could be explicitly out of scope in th= e charter while unavoidably in scope for the document. On Tue, Jul 7, 2015 at 4:40 PM, Jim Schaad wrote: > I am more than willing to have a different term for =E2=80=9CKey Manageme= nt=E2=80=9D. > However, I have inherited the term from CMS (RFC 2630) where section 12.3 > talks about key management algorithms. > > > > What you re referring to below, I generally put under the term of key lif= e > cycle > > > > Jim > > > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Tuesday, July 07, 2015 1:36 PM > *To:* Justin Richer > *Cc:* Mike Jones; Jim Schaad; cose@ietf.org > *Subject:* Re: [Cose] Review of draft-schaad-cose-msg-01 > > > > [wearing my cowboy hat from Dallas:)] > > I think the term "key management" has gotten a little overloaded here. > > I believe the charter uses the term in the broader and traditional sense > that Wikipedia , for > example, talks about it, like "dealing with the generation, exchange, > storage, use, and replacement of keys" including "key servers [and] user > procedures." > > Whereas the term seemed to get somewhat co-opted in JOSE as a catch all t= o > cover all the message level key encryption, key encapsulation, and key > agreement bits that are needed to convey and protect a content encryption > key for encryption. And that usage has carried over into COSE. > > COSE needs "key management" in the latter sense of the word. Maybe it > should be called something else but it's a necessity for encryption. My > question the other day was about the what value there is in doing it for > MAC keys. > > I suspect the "Key management and binding of keys to identities are out o= f > scope" in the former sense in the charter is intended to keep COSE scope > reasonably constrained. > > > > > > > > > On Tue, Jul 7, 2015 at 1:54 PM, Justin Richer wrote: > > Perhaps I=E2=80=99m missing something, but as chair I feel the need to po= int out > this line in our current charter for you all to consider: > > > > Key management and binding of keys to identities are out of scope for the > > working group. > > > > =E2=80=94 Justin > > > > > > On Jul 7, 2015, at 3:50 PM, Mike Jones > wrote: > > > > Jim, I hadn=E2=80=99t seen an answer to this question. If the thread you= =E2=80=99re > referring to is =E2=80=9CKey management in the World of COSE=E2=80=9D, my= impression is > that some people talked about use cases, but there were no actual > conclusions drawn. > > > > Also, could you answer Brian Campbell=E2=80=99s question in the related t= hread > =E2=80=9CKey management for MACs (was Re: [Cose] Review of > draft-schaad-cose-msg-01)=E2=80=9D? As I said in my reply, I completely = understand > the value of key management for encryption, in which there are secrets to > protect, but not for MACs, where there are not. > > > > Thanks, > > -- Mike > > > > *From:* Mike Jones > *Sent:* Tuesday, June 30, 2015 2:54 PM > *To:* 'Jim Schaad'; cose@ietf.org > *Subject:* RE: [Cose] Review of draft-schaad-cose-msg-01 > > > > Jim, is the discussion you=E2=80=99re referring to for my issue 2 the thr= ead =E2=80=9CKey > management in the World of COSE=E2=80=9D or is there an additional thread= you=E2=80=99re > referring 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=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. > > > > *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 k= ey > 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=E2=80=99m fine with the optional ability to have key management for MAC= s, but > the default should be that no key management information is present in th= e > representation. The only algorithm represented by default should be the > MAC algorithm =E2=80=93 not even =E2=80=9Cdir=E2=80=9D (direct). I suspe= ct that this can be > cleanly done by omitting the key management layer entirely when it=E2=80= =99s not > used, rather than explicitly using =E2=80=9Cdir=E2=80=9D (direct). > > > > [JLS] See above. > > > > *3. Wrapped keys should be able to be represented as simply the wrapped > key value =E2=80=93 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 wrapp= ed > 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 oth= er > benefits, this will enable the use of the standard RFC 3394 AES Key Wrap > algorithms, in the same way that JOSE uses =E2=80=9CA128KW=E2=80=9D, 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 thi= s > simpler approach. Applications can then choose which method works best f= or > them. > > > > [JLS] I don=E2=80=99t understand this comment. This is not what the docu= ment says. > > > > *4. Simpler and more comprehensible examples are needed.* > > > > I would include examples for the simplest and likely most common use case= s: > > =C2=B7 HMAC without key management > > =C2=B7 Single signature > > =C2=B7 Encryption using AES Key Wrap for key management and AES GC= M 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'2ba937ca03d76c3dbad30cfcbaeef586f9c0f9ba616ad67e9205d385= 7 > > 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, =E2=80=A6 aa. The section numbers and names in which they appear a= re > 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=E2=80=99t 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? | > > to: > > | ciphertext | 7 | For COSE_encrypt | > > > > It=E2=80=99s cleaner not to reuse the same label value for different sema= ntic > meanings. If we do that, we might come to regret it as the spec evolves. > Besides, it=E2=80=99s not like using another short integer value here wil= l cause us > to run out of them in this context. > > > > [JLS] The TODO is a marker for future discussion =E2=80=93 There are bot= h > 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 f= or > 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=E2=80= =99t 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 =E2=80=9Cprotected=E2=80=9D and =E2=80= =9Cunprotected=E2=80=9D can=E2=80=99t be > included where their values can=E2=80=99t 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 =E2=80=9Ccrit=E2=80=9D is only for= defining > behavior of critical extensions =E2=80=93 not for making header parameter= s 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=E2=80=99t call the COSE Key passed by value =E2= =80=9Cjwk=E2=80=9D, since > that=E2=80=99s 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 =E2=80=9Cjku=E2=80=9D and = =E2=80=9Cjwk=E2=80=9D to =E2=80=9Cjku=E2=80=9D, > =E2=80=9Ccku=E2=80=9D, and =E2=80=9Cck=E2=80=9D 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 =E2=80=9Cprotected=E2=80=9D says = =E2=80=9CThe field MUST > NOT hold attributes about the payload being signed=E2=80=9D. Assuming th= at a > flattened syntax is added, this would then become something like =E2=80= =9CThe field > MUST NOT hold attributes about the payload being signed unless the > flattened serialization is being used=E2=80=9D. Other related statements > throughout the document would likewise need to be similarly updated. > > [JLS] But it is not current added =E2=80=93 so this is not currently an a= ctionable > 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=E2=80=99s association with the signing identity is described. Pa= rticular > methods are clearly beyond the scope of this specification but saying thi= s > 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=E2=80=99ll note that if issue 3 is resolved (*Wrapped keys should be ab= le 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 =E2=80=9Civ=E2=80=9D (initialization vector) field should a= lso be defined in > the list of parameters for the encryption object. Yes, not all algorithm= s > will use it, but many will. > > > > m. A =E2=80=9Ctag=E2=80=9D (authentication tag) field should be defined = in the list of > parameters for the encryption object. Yes, not all the algorithms will u= se > it, but many will. > > [JLS] Maybe true for =E2=80=98iv=E2=80=99, however =E2=80=98tag=E2=80=99 = 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 =E2=80=9Ckid=E2= =80=9D or other key > selection value. A =E2=80=9CSHOULD =E2=80=A6 unless =E2=80=A6=E2=80=9D c= onstruct like was used in similar > JOSE descriptions is probably the right thing to use here. > > [JLS] The =E2=80=A6unless=E2=80=A6 clause is confusing as hell so I do no= t 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 =E2=80=9CHow to compute a MAC=E2=80=9D 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 =E2=80=9Ckey_ops=E2=80=9D unnecessary= . Language > something like =E2=80=9CIt is strongly suggested that this element be pre= sent for > all keys unless this information is already know to the application throu= gh > other means=E2=80=9D should be used to capture this. > > > > The working group should also discuss whether it wants to carry forward > =E2=80=9Cuse=E2=80=9D 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=E2=80=99t see any good use for it that is not better served by =E2=80= =98key_ops=E2=80=99. This > is doubly true given that the W3C Crypto group > > > > q. I would define short numeric values that correspond to the defines > =E2=80=9Ckey_ops=E2=80=9D string values. I=E2=80=99d do the same for the= =E2=80=9Cuse=E2=80=9D 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 =E2=80=9CSHOULD=E2=80=9D be changed to = =E2=80=9CMUST=E2=80=9D. CBOR > doesn=E2=80=99t have the same legacy of lax parsers that we inherited fro= m > JavaScript/ECMAscript for JSON. Let=E2=80=99s not open the door to them! > > > > 9.5 COSE Algorithm Registry > > > > s. I would add an additional =E2=80=9CJOSE algorithm name=E2=80=9D field= to this > registry, whose value is the corresponding =E2=80=9CAlgorithm Name=E2=80= =9D entry in the > IANA JSON Web Signature and Encryption Algorithms registry at > http://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-= algorithms, > if such an entry exists. This will tie the two registries together so th= at > definitions of algorithms already defined by JOSE need not be repeated fo= r > 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 =E2=80=9Capplication/cose=E2=80=9D,= I would also > register one for a base64url encoded COSE message =E2=80=93 an idea first= described > to me by Joe Hildebrand. It could be called =E2=80=9Capplication/cose+ba= se64url=E2=80=9D > 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 reaso= n > to believe otherwise? > > > > 9.8.2 COSE Key Media Type > > > > u. =E2=80=9Capplication/jwk+json=E2=80=9D should be changed to something= like > =E2=80=9Capplication/cose-key=E2=80=9D and =E2=80=9Capplication/jwk-set+j= son=E2=80=9D should be changed to > something like =E2=80=9Capplication/cose-key-set=E2=80=9D. > > > > 11.2. Informative References > > > > v. The date on the AES-GCM reference (SP 800-38D) should be November 200= 7 > =E2=80=93 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 = =E2=80=9Cthe > ciphertext and tag outputs=E2=80=9D =E2=80=93 not a single combined outpu= t. 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 th= e > text =E2=80=9CThe final result c consists of the encrypted message follow= ed by the > encrypted authentication value U=E2=80=9D, which admits either implementa= tion. > Likewise, at least the .NET CCM implementation produces separate cipherte= xt > and authentication tag values. > > > > Whether the tag should be separate or automatically appended to the > ciphertext isn=E2=80=99t a hill I=E2=80=99m going to die on (although the= working group > should discuss this and make an explicit decision in this regard), but th= e > text describing the decision should at least be changed to be accurate. > > > > [JLS] Wrong reference =E2=80=93will correct. > > > > Appendix C. Examples > > > > x. The uses of strings and corresponding labels such as those that follo= w > are confusing =E2=80=93 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=E2=80=99t 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 =E2=80=9CHeader Algorithm=E2=80=9D to =E2=80= =9CHeader Parameter=E2=80=9D. (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=E2=80=99t = 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 > =E2=80=9Cname=E2=80=9D 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 =E2=80=9Ckty=E2=80=9D values (EC=3D= 1, RSA=3D2, oct=3D3) > with curve values (P256=3D4, P521=3D5). I would keep these separate. Al= so, > 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=E2= =80=99ll > post the pull request link once it=E2=80=99s been created. > > > > *CONCLUSIONS* > > > > I=E2=80=99d like to thank Jim for doing the work to produce a well-though= t-out > initial draft. I believe it provides a solid starting point for the COSE > work. > > > > I=E2=80=99d 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 > > > > _______________________________________________ > 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 > > > --001a1141b9606a0d5c051a740f30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I wasn't necessarily suggesting that a new/different t= erm be used (and apologize for a general ignorance about CMS). I just wante= d to reconcile how =E2=80=9Ckey management=E2=80=9D could be explicitly out= of scope in the charter while unavoidably in scope for the document.
<= br>

--001a1141b9606a0d5c051a740f30-- From nobody Thu Jul 9 10:46: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 17DA91A1A27 for ; Thu, 9 Jul 2015 10:46:03 -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 nIZj1PwZM1BU for ; Thu, 9 Jul 2015 10:45:54 -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 AA3531A1A25 for ; Thu, 9 Jul 2015 10:45:54 -0700 (PDT) Received: from hebrews (174-21-18-91.tukw.qwest.net [174.21.18.91]) (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 6ACBE2CA44; Thu, 9 Jul 2015 10:45:53 -0700 (PDT) From: "Jim Schaad" To: "'Brian Campbell'" References: <000201d0b0ed$755707c0$60051740$@augustcellars.com> <3C5E1125-371E-40E6-BD72-19C63F76DF58@mit.edu> <008101d0b906$0e744e70$2b5ceb50$@augustcellars.com> In-Reply-To: Date: Thu, 9 Jul 2015 10:46:11 -0700 Message-ID: <015f01d0ba6f$25306850$6f9138f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0160_01D0BA34.78DCDAF0" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQE1NDqbRmt1XQuFZCU3Rn0/gnMmSwIfoXgdAQMGW5MCFHPpTAHDdwSKAp1nJf4DCAJB5Z6ldZzw Archived-At: Cc: 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: Thu, 09 Jul 2015 17:46:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0160_01D0BA34.78DCDAF0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable It may be that it needs to be a different term, others might raise the = same issue. I feel off at the moment because I think I probably wrote = that sentence in the charter as was not being consistent. =20 Jim =20 =20 From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 Sent: Thursday, July 09, 2015 9:51 AM To: Jim Schaad Cc: Justin Richer; Mike Jones; cose@ietf.org Subject: Re: [Cose] Review of draft-schaad-cose-msg-01 =20 I wasn't necessarily suggesting that a new/different term be used (and = apologize for a general ignorance about CMS). I just wanted to reconcile = how =E2=80=9Ckey management=E2=80=9D could be explicitly out of scope in = the charter while unavoidably in scope for the document.=20 =20 On Tue, Jul 7, 2015 at 4:40 PM, Jim Schaad > wrote: I am more than willing to have a different term for =E2=80=9CKey = Management=E2=80=9D. However, I have inherited the term from CMS (RFC = 2630) where section 12.3 talks about key management algorithms. =20 What you re referring to below, I generally put under the term of key = life cycle =20 Jim =20 =20 From: Brian Campbell [mailto:bcampbell@pingidentity.com = ]=20 Sent: Tuesday, July 07, 2015 1:36 PM To: Justin Richer Cc: Mike Jones; Jim Schaad; cose@ietf.org =20 Subject: Re: [Cose] Review of draft-schaad-cose-msg-01 =20 [wearing my cowboy hat from Dallas:)] I think the term "key management" has gotten a little overloaded here.=20 I believe the charter uses the term in the broader and traditional sense = that Wikipedia , for = example, talks about it, like "dealing with the generation, exchange, = storage, use, and replacement of keys" including "key servers [and] user = procedures."=20 Whereas the term seemed to get somewhat co-opted in JOSE as a catch all = to cover all the message level key encryption, key encapsulation, and = key agreement bits that are needed to convey and protect a content = encryption key for encryption. And that usage has carried over into = COSE.=20 COSE needs "key management" in the latter sense of the word. Maybe it = should be called something else but it's a necessity for encryption. My = question the other day was about the what value there is in doing it for = MAC keys.=20 I suspect the "Key management and binding of keys to identities are out = of scope" in the former sense in the charter is intended to keep COSE = scope reasonably constrained. =20 =20 =20 =20 On Tue, Jul 7, 2015 at 1:54 PM, Justin Richer > wrote: Perhaps I=E2=80=99m missing something, but as chair I feel the need to = point out this line in our current charter for you all to consider: =20 Key management and binding of keys to identities are out of scope for = the working group. =20 =E2=80=94 Justin =20 =20 On Jul 7, 2015, at 3:50 PM, Mike Jones > wrote: =20 Jim, I hadn=E2=80=99t seen an answer to this question. If the thread = you=E2=80=99re referring to is =E2=80=9CKey management in the World of = COSE=E2=80=9D, my impression is that some people talked about use cases, = but there were no actual conclusions drawn. =20 Also, could you answer Brian Campbell=E2=80=99s question in the related = thread =E2=80=9CKey management for MACs (was Re: [Cose] Review of = draft-schaad-cose-msg-01)=E2=80=9D? As I said in my reply, I completely = understand the value of key management for encryption, in which there = are secrets to protect, but not for MACs, where there are not. =20 Thanks, -- Mike =20 From: Mike Jones=20 Sent: Tuesday, June 30, 2015 2:54 PM To: 'Jim Schaad'; cose@ietf.org =20 Subject: RE: [Cose] Review of draft-schaad-cose-msg-01 =20 Jim, is the discussion you=E2=80=99re referring to for my issue 2 the = thread =E2=80=9CKey management in the World of COSE=E2=80=9D or is there = an additional thread you=E2=80=99re referring to? =20 From: Jim Schaad [mailto:ietf@augustcellars.com]=20 Sent: Saturday, June 27, 2015 8:25 AM To: Mike Jones; cose@ietf.org =20 Subject: RE: [Cose] Review of draft-schaad-cose-msg-01 =20 =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 2. HMACs should be optimized for the no-key-management case. =20 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. =20 I=E2=80=99m 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 =E2=80=93 not even = =E2=80=9Cdir=E2=80=9D (direct). I suspect that this can be cleanly done = by omitting the key management layer entirely when it=E2=80=99s not = used, rather than explicitly using =E2=80=9Cdir=E2=80=9D (direct). =20 [JLS] See above. =20 3. Wrapped keys should be able to be represented as simply the wrapped = key value =E2=80=93 not as an encrypted data structure with unnecessary = information. =20 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. =20 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 = =E2=80=9CA128KW=E2=80=9D, etc. =20 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. =20 [JLS] I don=E2=80=99t understand this comment. This is not what the = document says. =20 4. Simpler and more comprehensible examples are needed. =20 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 =20 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. =20 For instance, the Direct MAC example in C.1 should be changed from = beginning like this: =20 { 1: 3, 2: h'a10104', 4: h'546869732069732074686520636f6e74656e742e', 10: h'2ba937ca03d76c3dbad30cfcbaeef586f9c0f9ba616ad67e9205d3857 6ad9930', =20 to beginning like this: =20 { 1 (msg_type): 3 (MACed message), 2 (protected): h'a10104' (alg:HS256), 4 (payload): h'546869732069732074686520636f6e74656e742e', 10 (tag): = h'2ba937ca03d76c3dbad30cfcbaeef586f9c0f9ba616ad67e9205d3857 6ad9930', =20 [JLS] More examples are on the way in the future. =20 MINOR ISSUES =20 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, =E2=80=A6 aa. The section numbers and names in which they = appear are included in the write-up. =20 2. The COSE_MSG structure =20 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. =20 [JLS] I do not believe that this is required. If you implement a new = item, then you don=E2=80=99t have a pure implementation of this document = and the clause is implicit. =20 b. This syntax needs more explanation: COSE_Tagged_MSG =3D #6.999(COSE_MSG) ; Replace 999 with TBD1 =20 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. =20 [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. =20 c. Change: | ciphertext | 4 | TODO: Should we re-use the same as payload | | | | or not? | to: | ciphertext | 7 | For COSE_encrypt | =20 It=E2=80=99s 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=E2=80=99s not like using another short = integer value here will cause us to run out of them in this context. =20 [JLS] The TODO is a marker for future discussion =E2=80=93 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=E2=80=99t know what the answer for this is yet. =20 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. =20 The new text makes it clearer that =E2=80=9Cprotected=E2=80=9D and = =E2=80=9Cunprotected=E2=80=9D can=E2=80=99t be included where their = values can=E2=80=99t be used. [JLS] That text does not make it any clearer to me. =20 3.1. COSE Headers =20 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. =20 The language should make it clear that =E2=80=9Ccrit=E2=80=9D is only = for defining behavior of critical extensions =E2=80=93 not for making = header parameters defined by this spec critical. [JLS] This does not make things clearer tome. =20 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 | | | | | | | =20 It still makes sense to be able to represent URLs to JWK and COSE Key = objects. But we shouldn=E2=80=99t call the COSE Key passed by value = =E2=80=9Cjwk=E2=80=9D, since that=E2=80=99s misleading. [JLS] Thus the open issue marker. =20 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? =20 I would keep all of them, other than changing =E2=80=9Cjku=E2=80=9D and = =E2=80=9Cjwk=E2=80=9D to =E2=80=9Cjku=E2=80=9D, =E2=80=9Ccku=E2=80=9D, = and =E2=80=9Cck=E2=80=9D per (f) above. [JLS] This will be a discussion issue. =20 h. Open Issue 2. I am currently torn on the question "Should epk and = iv/nonce be algorithm specific or generic headers?" =20 I would define common labels for them since they are commonly used = across multiple algorithms. =20 4. Signing Structure =20 i. The description of =E2=80=9Cprotected=E2=80=9D says = =E2=80=9CThe field MUST NOT hold attributes about the payload being = signed=E2=80=9D. Assuming that a flattened syntax is added, this would = then become something like =E2=80=9CThe field MUST NOT hold attributes = about the payload being signed unless the flattened serialization is = being used=E2=80=9D. Other related statements throughout the document = would likewise need to be similarly updated. [JLS] But it is not current added =E2=80=93 so this is not currently an = actionable statement. =20 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. =20 There needs to be a reference to a place where the process of verifying = the key=E2=80=99s 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? =20 5. Encryption Object =20 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. =20 I=E2=80=99ll 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. =20 l. A generic =E2=80=9Civ=E2=80=9D (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. =20 m. A =E2=80=9Ctag=E2=80=9D (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 =E2=80=98iv=E2=80=99, however =E2=80=98tag=E2=80=99 = is part of the ciphertext. =20 5.1.1. Direct Encryption =20 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. =20 SHOULD is too strong here because in some protocols, the shared secret = will already be known by methods other than an included = =E2=80=9Ckid=E2=80=9D or other key selection value. A =E2=80=9CSHOULD = =E2=80=A6 unless =E2=80=A6=E2=80=9D construct like was used in similar = JOSE descriptions is probably the right thing to use here. [JLS] The =E2=80=A6unless=E2=80=A6 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. =20 6. MAC Objects =20 o. The =E2=80=9CHow to compute a MAC=E2=80=9D instructions say: 5. Encrypt and encode the MAC key for each recipient of the message. =20 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. =20 7. Key Structure =20 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. =20 Like in (n), the application may know the key usage from application = context, rendering the inclusion of =E2=80=9Ckey_ops=E2=80=9D = unnecessary. Language something like =E2=80=9CIt is strongly suggested = that this element be present for all keys unless this information is = already know to the application through other means=E2=80=9D should be = used to capture this. =20 The working group should also discuss whether it wants to carry forward = =E2=80=9Cuse=E2=80=9D 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=E2=80=99t see any good use for it that is not better served by = =E2=80=98key_ops=E2=80=99. This is doubly true given that the W3C = Crypto group =20 q. I would define short numeric values that correspond to the defines = =E2=80=9Ckey_ops=E2=80=9D string values. I=E2=80=99d do the same for = the =E2=80=9Cuse=E2=80=9D values. [JLS] Yes this will be happening going forward. =20 8. CBOR Encoder Restrictions =20 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. =20 I would strongly prefer that the =E2=80=9CSHOULD=E2=80=9D be changed to = =E2=80=9CMUST=E2=80=9D. CBOR doesn=E2=80=99t have the same legacy of = lax parsers that we inherited from JavaScript/ECMAscript for JSON. = Let=E2=80=99s not open the door to them! =20 9.5 COSE Algorithm Registry =20 s. I would add an additional =E2=80=9CJOSE algorithm name=E2=80=9D = field to this registry, whose value is the corresponding = =E2=80=9CAlgorithm Name=E2=80=9D entry in the IANA JSON Web Signature = and Encryption Algorithms registry at = http://www.iana.org/assignments/jose/jose.xhtml#web-signature-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. =20 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? =20 9.8.1 COSE Security Message =20 t. Besides registering the MIME type = =E2=80=9Capplication/cose=E2=80=9D, I would also register one for a = base64url encoded COSE message =E2=80=93 an idea first described to me = by Joe Hildebrand. It could be called = =E2=80=9Capplication/cose+base64url=E2=80=9D 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? =20 9.8.2 COSE Key Media Type =20 u. =E2=80=9Capplication/jwk+json=E2=80=9D should be changed to = something like =E2=80=9Capplication/cose-key=E2=80=9D and = =E2=80=9Capplication/jwk-set+json=E2=80=9D should be changed to = something like =E2=80=9Capplication/cose-key-set=E2=80=9D. =20 11.2. Informative References =20 v. The date on the AES-GCM reference (SP 800-38D) should be November = 2007 =E2=80=93 not June 2015. =20 Appendix A. AEAD and AE Algorithms =20 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]. =20 The last sentence is not true, as written. The AES-GCM spec describes = =E2=80=9Cthe ciphertext and tag outputs=E2=80=9D =E2=80=93 not a single = combined output. Common implementations correspond to this, such as the = implementation of GCM in .NET. =20 The CCM description in RFC 3610 Section 2.4 describes the output using = the text =E2=80=9CThe final result c consists of the encrypted message = followed by the encrypted authentication value U=E2=80=9D, which admits = either implementation. Likewise, at least the .NET CCM implementation = produces separate ciphertext and authentication tag values. =20 Whether the tag should be separate or automatically appended to the = ciphertext isn=E2=80=99t a hill I=E2=80=99m 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. =20 [JLS] Wrong reference =E2=80=93will correct. =20 Appendix C. Examples =20 x. The uses of strings and corresponding labels such as those that = follow are confusing =E2=80=93 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" }, =20 There are similar strings in some of the other examples that I also = couldn=E2=80=99t wrap my head around. [JLS] My code does not match the spec here. Originally they were = strings. =20 Appendix D. COSE Header Algorithm Label Table =20 y. I would change the term =E2=80=9CHeader Algorithm=E2=80=9D to = =E2=80=9CHeader Parameter=E2=80=9D. (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=E2=80=99t = think that some of the terms I am currently using are sufficiently = distinct to make it easy to figure things out. =20 z. In Appendix D and Appendix E, I would call out that the names in the = =E2=80=9Cname=E2=80=9D columns correspond to names defined in RFC 7518. [JLS] These tables are disappearing as part of the add the algorithms to = the document exercise. =20 Appendix F. COSE General Values =20 aa. This seems confused, as it mixes =E2=80=9Ckty=E2=80=9D 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. =20 NITS =20 I will be submitting spelling and grammar corrections as a GitHub pull = request against the spec repository rather than detail them here. = I=E2=80=99ll post the pull request link once it=E2=80=99s been created. =20 CONCLUSIONS =20 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 I=E2=80=99d be willing to produce specific proposed edits for any/all of = the above issues and comments, should the editors find that useful.=20 =20 Best wishes, -- Mike =20 _______________________________________________ Cose mailing list Cose@ietf.org =20 https://www.ietf.org/mailman/listinfo/cose =20 _______________________________________________ Cose mailing list Cose@ietf.org =20 https://www.ietf.org/mailman/listinfo/cose =20 =20 ------=_NextPart_000_0160_01D0BA34.78DCDAF0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

It may be that it needs to be a different term, others might raise the = same issue.=C2=A0 I feel off at the moment because I think I probably = wrote that sentence in the charter as was not being = consistent.

 

Jim

 

 

From:<= /b> = Brian Campbell [mailto:bcampbell@pingidentity.com]
Sent: = Thursday, July 09, 2015 9:51 AM
To: Jim Schaad
Cc: = Justin Richer; Mike Jones; cose@ietf.org
Subject: Re: [Cose] = Review of draft-schaad-cose-msg-01

 

I wasn't necessarily suggesting that a = new/different term be used (and apologize for a general ignorance about = CMS). I just wanted to reconcile how =E2=80=9Ckey management=E2=80=9D = could be explicitly out of scope in the charter while unavoidably in = scope for the document.

 

On Tue, = Jul 7, 2015 at 4:40 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

I am more than willing to have a different term for =E2=80=9CKey = Management=E2=80=9D.  However, I have inherited the term from CMS = (RFC 2630) where section 12.3 talks about key management = algorithms.

 

What you re referring to below, I generally put under the term of key = life cycle

 

Jim

 

 

From:<= /b> = Brian Campbell [mailto:bcampbell@pingidentity.com]
Sent: = Tuesday, July 07, 2015 1:36 PM
To: Justin Richer
Cc: = Mike Jones; Jim Schaad; cose@ietf.org
Subject: Re: [Cose] Review = of draft-schaad-cose-msg-01

 <= /o:p>

[wearing my = cowboy hat from Dallas:)]

I think the term = "key management" has gotten a little overloaded here. =

I believe the = charter uses the term in the broader and traditional sense that Wikipedia, for example, talks about it, like = "dealing with the generation, exchange, storage, use, and = replacement of keys" including "key servers [and] user = procedures."

Whereas the term = seemed to get somewhat co-opted in JOSE as a catch all to cover all the = message level key encryption, key encapsulation, and key agreement bits = that are needed to convey and protect a content encryption key for = encryption. And that usage has carried over into COSE. =

COSE needs = "key management" in the latter sense of the word. Maybe it = should be called something else but it's a necessity for encryption. My = question the other day was about the what value there is in doing it for = MAC keys.

I suspect = the "Key management and binding of keys to identities are out of = scope" in the former sense in the charter is intended to keep COSE = scope reasonably constrained. 

 <= /o:p>


  =  

 <= /o:p>

On Tue, Jul = 7, 2015 at 1:54 PM, Justin Richer <jricher@mit.edu> = wrote:

Perhaps = I=E2=80=99m missing something, but as chair I feel the need to point out = this line in our current charter for you all to = consider:

 <= /o:p>

Key management and binding of keys to identities are =
out of scope for the
working =
group.

 <= /o:p>

 =E2=80= =94 Justin

 <= /o:p>

 <= /o:p>

On Jul 7, = 2015, at 3:50 PM, Mike Jones <Michael.Jones@microsoft.com> = wrote:

 <= /o:p>

Jim, I hadn=E2=80=99t seen an answer to this = question.  If the thread you=E2=80=99re referring to is = =E2=80=9CKey management in the World of COSE=E2=80=9D, my impression is = that some people talked about use cases, but there were no actual = conclusions drawn.

 

Also, could you answer Brian Campbell=E2=80=99s = question in the related thread =E2=80=9CKey management for MACs (was Re: = [Cose] Review of draft-schaad-cose-msg-01)=E2=80=9D?  As I said in = my reply, I completely understand the value of key management for = encryption, in which there are secrets to protect, but not for MACs, = where there are not.

 

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;       Thanks,

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

 

From: Mike = Jones
Sent: Tuesday, June 30, 2015 2:54 PM
To: 'Jim = Schaad'; cose@ietf.org
Subject: RE: [Cose] Review = of draft-schaad-cose-msg-01

 <= /o:p>

Jim, is the discussion you=E2=80=99re referring = to for my issue 2 the thread =E2=80=9CKey management in the World of = COSE=E2=80=9D or is there an additional thread you=E2=80=99re referring = 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

 <= /o:p>

 

 

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>

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

 <= /o:p>

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.

 <= /o:p>

I=E2=80=99m = 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 =E2=80=93 not even =E2=80=9Cdir=E2=80=9D = (direct).  I suspect that this can be cleanly done by omitting the = key management layer entirely when it=E2=80=99s not used, rather than = explicitly using =E2=80=9Cdir=E2=80=9D (direct).

 

[JLS] See above.

 <= /o:p>

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

 <= /o:p>

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.

 <= /o:p>

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 =E2=80=9CA128KW=E2=80=9D, = etc.

 <= /o:p>

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=E2=80=99t understand this comment.  = This is not what the document says.

 <= /o:p>

4.  = Simpler and more comprehensible examples are = needed.

 <= /o:p>

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

=C2=B7        = HMAC without key management

=C2=B7        = Single signature

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

 <= /o:p>

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.

 <= /o:p>

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

 <= /o:p>

  = {

  =    1: 3,

  =    2: h'a10104',

  =    4: = h'546869732069732074686520636f6e74656e742e',

  =    10: = h'2ba937ca03d76c3dbad30cfcbaeef586f9c0f9ba616ad67e9205d3857

  = 6ad9930',

 <= /o:p>

to = beginning like this:

 <= /o:p>

  = {

  =    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.

 <= /o:p>

MINOR = ISSUES

 <= /o:p>

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, =E2=80=A6 aa.  The section numbers and names in which they = appear are included in the write-up.

 <= /o:p>

2.  = The COSE_MSG structure

 <= /o:p>

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=E2=80=99t have a pure implementation of this document and the clause = is implicit.

 <= /o:p>

b.  = This syntax needs more explanation:

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

 <= /o:p>

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.

 <= /o:p>

[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;    |

 <= /o:p>

It=E2=80=99s= 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=E2=80=99s not like using another short = integer value here will cause us to run out of them in this = context.

 <= /o:p>

[JLS]  The TODO is a marker for future = discussion =E2=80=93 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=E2=80=99t 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 =E2=80=9Cprotected=E2=80=9D and = =E2=80=9Cunprotected=E2=80=9D can=E2=80=99t be included where their = values can=E2=80=99t be used.

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

 <= /o:p>

3.1.  = COSE Headers

 <= /o:p>

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.

 <= /o:p>

The = language should make it clear that =E2=80=9Ccrit=E2=80=9D is only for = defining behavior of critical extensions =E2=80=93 not for making header = parameters defined by this spec critical.

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

 <= /o:p>

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     |

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

 <= /o:p>

It still = makes sense to be able to represent URLs to JWK and COSE Key = objects.  But we shouldn=E2=80=99t call the COSE Key passed by = value =E2=80=9Cjwk=E2=80=9D, since that=E2=80=99s = 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?

 <= /o:p>

I would = keep all of them, other than changing =E2=80=9Cjku=E2=80=9D and = =E2=80=9Cjwk=E2=80=9D to =E2=80=9Cjku=E2=80=9D, =E2=80=9Ccku=E2=80=9D, = and =E2=80=9Cck=E2=80=9D per (f) above.

[JLS] This will be a discussion = issue.

 <= /o:p>

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

  =      algorithm specific or generic = headers?"

 <= /o:p>

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

 <= /o:p>

4.  = Signing Structure

 <= /o:p>

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

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

 <= /o:p>

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.

 <= /o:p>

There needs = to be a reference to a place where the process of verifying the = key=E2=80=99s 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?

 <= /o:p>

5.  = Encryption Object

 <= /o:p>

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.

 <= /o:p>

I=E2=80=99ll= 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.

 <= /o:p>

l.  A = generic =E2=80=9Civ=E2=80=9D (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.

 <= /o:p>

m.  A = =E2=80=9Ctag=E2=80=9D (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 =E2=80=98iv=E2=80=99, however = =E2=80=98tag=E2=80=99 is part of the ciphertext.

 <= /o:p>

5.1.1. = Direct Encryption

 <= /o:p>

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.

 <= /o:p>

SHOULD is = too strong here because in some protocols, the shared secret will = already be known by methods other than an included =E2=80=9Ckid=E2=80=9D = or other key selection value.  A =E2=80=9CSHOULD =E2=80=A6 unless = =E2=80=A6=E2=80=9D construct like was used in similar JOSE descriptions = is probably the right thing to use here.

[JLS] The =E2=80=A6unless=E2=80=A6 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.

 <= /o:p>

6.  = MAC Objects

 <= /o:p>

o.  = The =E2=80=9CHow to compute a MAC=E2=80=9D instructions = say:

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

 <= /o:p>

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.

 <= /o:p>

7.  = Key Structure

 <= /o:p>

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.

 <= /o:p>

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

 <= /o:p>

The working = group should also discuss whether it wants to carry forward = =E2=80=9Cuse=E2=80=9D 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=E2=80=99t see any good use for it that is = not better served by =E2=80=98key_ops=E2=80=99.  This is doubly = true given that the W3C Crypto group

 <= /o:p>

q.  I = would define short numeric values that correspond to the defines = =E2=80=9Ckey_ops=E2=80=9D string values.  I=E2=80=99d do the same = for the =E2=80=9Cuse=E2=80=9D values.

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

 <= /o:p>

8.  = CBOR Encoder Restrictions

 <= /o:p>

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.

 <= /o:p>

I would = strongly prefer that the =E2=80=9CSHOULD=E2=80=9D be changed to = =E2=80=9CMUST=E2=80=9D.  CBOR doesn=E2=80=99t have the same legacy = of lax parsers that we inherited from JavaScript/ECMAscript for = JSON.  Let=E2=80=99s not open the door to them!

 <= /o:p>

9.5  = COSE Algorithm Registry

 <= /o:p>

s.  I = would add an additional =E2=80=9CJOSE algorithm name=E2=80=9D field to = this registry, whose value is the corresponding =E2=80=9CAlgorithm = Name=E2=80=9D entry in the IANA JSON Web Signature and Encryption = Algorithms registry at http://www.iana.org/assignments/jose/jose.xhtml#web-sig= nature-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.

 <= /o:p>

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?

 <= /o:p>

9.8.1  = COSE Security Message

 <= /o:p>

t.  = Besides registering the MIME type =E2=80=9Capplication/cose=E2=80=9D, I = would also register one for a base64url encoded COSE message =E2=80=93 = an idea first described to me by Joe Hildebrand.  It could be = called =E2=80=9Capplication/cose+base64url=E2=80=9D 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?

 <= /o:p>

9.8.2  = COSE Key Media Type

 <= /o:p>

u.  = =E2=80=9Capplication/jwk+json=E2=80=9D should be changed to something = like =E2=80=9Capplication/cose-key=E2=80=9D and = =E2=80=9Capplication/jwk-set+json=E2=80=9D should be changed to = something like = =E2=80=9Capplication/cose-key-set=E2=80=9D.

 <= /o:p>

11.2.  = Informative References

 <= /o:p>

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

 <= /o:p>

Appendix = A.  AEAD and AE Algorithms

 <= /o:p>

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].

 <= /o:p>

The last = sentence is not true, as written.  The AES-GCM spec describes = =E2=80=9Cthe ciphertext and tag = outputs=E2=80=9D =E2=80=93 not a single combined output.  = Common implementations correspond to this, such as the implementation of = GCM in .NET.

 <= /o:p>

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

 <= /o:p>

Whether the = tag should be separate or automatically appended to the ciphertext = isn=E2=80=99t a hill I=E2=80=99m 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.

 <= /o:p>

[JLS] Wrong reference =E2=80=93will = correct.

 <= /o:p>

Appendix = C.  Examples

 <= /o:p>

x.  = The uses of strings and corresponding labels such as those that follow = are confusing =E2=80=93 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"

         = },

 <= /o:p>

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

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

 <= /o:p>

Appendix = D.  COSE Header Algorithm Label Table

 <= /o:p>

y.  I = would change the term =E2=80=9CHeader Algorithm=E2=80=9D to = =E2=80=9CHeader Parameter=E2=80=9D.  (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=E2=80=99t think that some of the terms I = am currently using are sufficiently distinct to make it easy to figure = things out.

 <= /o:p>

z.  In = Appendix D and Appendix E, I would call out that the names in the = =E2=80=9Cname=E2=80=9D columns correspond to names defined in RFC = 7518.

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

 <= /o:p>

Appendix = F.  COSE General Values

 <= /o:p>

aa.  = This seems confused, as it mixes =E2=80=9Ckty=E2=80=9D 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.

 <= /o:p>

NITS<= o:p>

 <= /o:p>

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

 <= /o:p>

CONCLUSIO= NS

 <= /o:p>

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.

 <= /o:p>

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

 <= /o:p>

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

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

 <= /o:p>

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

 <= /o:p>


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

 <= /o:p>

 

------=_NextPart_000_0160_01D0BA34.78DCDAF0-- From nobody Thu Jul 9 11:04: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 421061B2A9B for ; Thu, 9 Jul 2015 11:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 j0GCCjQAV3sx for ; Thu, 9 Jul 2015 11:04:26 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0E2B1B2AED for ; Thu, 9 Jul 2015 11:04:25 -0700 (PDT) Received: by iebmu5 with SMTP id mu5so181304847ieb.1 for ; Thu, 09 Jul 2015 11:04:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=DbXkjG9zR6uShwygQZ6b0auO8Gg6hjk9K2QmQRovG38=; b=oVqp8HyojdkEt+IIrRdRftBBQzWN5ujHvMjdu67sP/HFVL8R80EWvYzqGmwvow0LLi LJYhHc+KvSHO54JH2bYlq/td5KdekV8yszv1P2uFNB7UgLr68gb8brD71Ri9M5hLtwOu STlKmCUCrXPmD2pb7vSEwqjO71w+dlXl4UujY= 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=DbXkjG9zR6uShwygQZ6b0auO8Gg6hjk9K2QmQRovG38=; b=fsar9MA/NS2oPI92gP9ub2b7WgBxofnur3xcsb0lWBradg/zqKmsKfmTV0vPO2tebh AeReyWeCtQ+fjqm0UhVN+hkOKKpQVhKmZR+kcWLvSDvDpuUEtN5WmoBgYQkSv5ntObs5 uUj0v3A3h77aDtXNAGtLbs0WPD91B+NZhO5NTsQTIwZkaMhhgjj/wK4mYzQjOAyeaP/p wx2hfFyel1aY2ol6vIwqZc/ButJ/PS9q3HH+AOnAYWBolfGO7lshdmPIL6eyjHv933tT rbLzLnqBAuVlklZHDxeNXAumz2MyHXJEAlzWODJiLco8THi4wB05l7LdNyagC54V6zcA 5ByA== X-Gm-Message-State: ALoCoQkbSRruAXS7V/v3pQ/kyOHCwEkSt6ArkSfKRiVuebfPPb7tKgveza2crHLcVuloi+aapyFm X-Received: by 10.107.159.66 with SMTP id i63mr29239519ioe.68.1436465065062; Thu, 09 Jul 2015 11:04:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Thu, 9 Jul 2015 11:03:55 -0700 (PDT) In-Reply-To: <015f01d0ba6f$25306850$6f9138f0$@augustcellars.com> References: <000201d0b0ed$755707c0$60051740$@augustcellars.com> <3C5E1125-371E-40E6-BD72-19C63F76DF58@mit.edu> <008101d0b906$0e744e70$2b5ceb50$@augustcellars.com> <015f01d0ba6f$25306850$6f9138f0$@augustcellars.com> From: Brian Campbell Date: Thu, 9 Jul 2015 12:03:55 -0600 Message-ID: To: Jim Schaad , Kathleen Moriarty Content-Type: multipart/alternative; boundary=001a1141b960ef97d3051a7515d9 Archived-At: Cc: 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: Thu, 09 Jul 2015 18:04:34 -0000 --001a1141b960ef97d3051a7515d9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yeah, maybe so. Kathleen (cc'd) just cited "management [being] explicitly out-of-scope for COSE as stated in the charter" at http://www.ietf.org/mail-archive/web/jose/current/msg05169.html So perhaps the charter needs to be clarified or a new term used in the draft. On Thu, Jul 9, 2015 at 11:46 AM, Jim Schaad wrote: > It may be that it needs to be a different term, others might raise the > same issue. I feel off at the moment because I think I probably wrote th= at > sentence in the charter as was not being consistent. > > > > Jim > > > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Thursday, July 09, 2015 9:51 AM > *To:* Jim Schaad > *Cc:* Justin Richer; Mike Jones; cose@ietf.org > > *Subject:* Re: [Cose] Review of draft-schaad-cose-msg-01 > > > > I wasn't necessarily suggesting that a new/different term be used (and > apologize for a general ignorance about CMS). I just wanted to reconcile > how =E2=80=9Ckey management=E2=80=9D could be explicitly out of scope in = the charter while > unavoidably in scope for the document. > > > > On Tue, Jul 7, 2015 at 4:40 PM, Jim Schaad wrote= : > > I am more than willing to have a different term for =E2=80=9CKey Manageme= nt=E2=80=9D. > However, I have inherited the term from CMS (RFC 2630) where section 12.3 > talks about key management algorithms. > > > > What you re referring to below, I generally put under the term of key lif= e > cycle > > > > Jim > > > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Tuesday, July 07, 2015 1:36 PM > *To:* Justin Richer > *Cc:* Mike Jones; Jim Schaad; cose@ietf.org > *Subject:* Re: [Cose] Review of draft-schaad-cose-msg-01 > > > > [wearing my cowboy hat from Dallas:)] > > I think the term "key management" has gotten a little overloaded here. > > I believe the charter uses the term in the broader and traditional sense > that Wikipedia , for > example, talks about it, like "dealing with the generation, exchange, > storage, use, and replacement of keys" including "key servers [and] user > procedures." > > Whereas the term seemed to get somewhat co-opted in JOSE as a catch all t= o > cover all the message level key encryption, key encapsulation, and key > agreement bits that are needed to convey and protect a content encryption > key for encryption. And that usage has carried over into COSE. > > COSE needs "key management" in the latter sense of the word. Maybe it > should be called something else but it's a necessity for encryption. My > question the other day was about the what value there is in doing it for > MAC keys. > > I suspect the "Key management and binding of keys to identities are out o= f > scope" in the former sense in the charter is intended to keep COSE scope > reasonably constrained. > > > > > > > > > On Tue, Jul 7, 2015 at 1:54 PM, Justin Richer wrote: > > Perhaps I=E2=80=99m missing something, but as chair I feel the need to po= int out > this line in our current charter for you all to consider: > > > > Key management and binding of keys to identities are out of scope for the > > working group. > > > > =E2=80=94 Justin > > > > > > On Jul 7, 2015, at 3:50 PM, Mike Jones > wrote: > > > > Jim, I hadn=E2=80=99t seen an answer to this question. If the thread you= =E2=80=99re > referring to is =E2=80=9CKey management in the World of COSE=E2=80=9D, my= impression is > that some people talked about use cases, but there were no actual > conclusions drawn. > > > > Also, could you answer Brian Campbell=E2=80=99s question in the related t= hread > =E2=80=9CKey management for MACs (was Re: [Cose] Review of > draft-schaad-cose-msg-01)=E2=80=9D? As I said in my reply, I completely = understand > the value of key management for encryption, in which there are secrets to > protect, but not for MACs, where there are not. > > > > Thanks, > > -- Mike > > > > *From:* Mike Jones > *Sent:* Tuesday, June 30, 2015 2:54 PM > *To:* 'Jim Schaad'; cose@ietf.org > *Subject:* RE: [Cose] Review of draft-schaad-cose-msg-01 > > > > Jim, is the discussion you=E2=80=99re referring to for my issue 2 the thr= ead =E2=80=9CKey > management in the World of COSE=E2=80=9D or is there an additional thread= you=E2=80=99re > referring 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=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. > > > > *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 k= ey > 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=E2=80=99m fine with the optional ability to have key management for MAC= s, but > the default should be that no key management information is present in th= e > representation. The only algorithm represented by default should be the > MAC algorithm =E2=80=93 not even =E2=80=9Cdir=E2=80=9D (direct). I suspe= ct that this can be > cleanly done by omitting the key management layer entirely when it=E2=80= =99s not > used, rather than explicitly using =E2=80=9Cdir=E2=80=9D (direct). > > > > [JLS] See above. > > > > *3. Wrapped keys should be able to be represented as simply the wrapped > key value =E2=80=93 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 wrapp= ed > 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 oth= er > benefits, this will enable the use of the standard RFC 3394 AES Key Wrap > algorithms, in the same way that JOSE uses =E2=80=9CA128KW=E2=80=9D, 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 thi= s > simpler approach. Applications can then choose which method works best f= or > them. > > > > [JLS] I don=E2=80=99t understand this comment. This is not what the docu= ment says. > > > > *4. Simpler and more comprehensible examples are needed.* > > > > I would include examples for the simplest and likely most common use case= s: > > =C2=B7 HMAC without key management > > =C2=B7 Single signature > > =C2=B7 Encryption using AES Key Wrap for key management and AES GC= M 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'2ba937ca03d76c3dbad30cfcbaeef586f9c0f9ba616ad67e9205d385= 7 > > 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, =E2=80=A6 aa. The section numbers and names in which they appear a= re > 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=E2=80=99t 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? | > > to: > > | ciphertext | 7 | For COSE_encrypt | > > > > It=E2=80=99s cleaner not to reuse the same label value for different sema= ntic > meanings. If we do that, we might come to regret it as the spec evolves. > Besides, it=E2=80=99s not like using another short integer value here wil= l cause us > to run out of them in this context. > > > > [JLS] The TODO is a marker for future discussion =E2=80=93 There are bot= h > 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 f= or > 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=E2=80= =99t 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 =E2=80=9Cprotected=E2=80=9D and =E2=80= =9Cunprotected=E2=80=9D can=E2=80=99t be > included where their values can=E2=80=99t 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 =E2=80=9Ccrit=E2=80=9D is only for= defining > behavior of critical extensions =E2=80=93 not for making header parameter= s 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=E2=80=99t call the COSE Key passed by value =E2= =80=9Cjwk=E2=80=9D, since > that=E2=80=99s 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 =E2=80=9Cjku=E2=80=9D and = =E2=80=9Cjwk=E2=80=9D to =E2=80=9Cjku=E2=80=9D, > =E2=80=9Ccku=E2=80=9D, and =E2=80=9Cck=E2=80=9D 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 =E2=80=9Cprotected=E2=80=9D says = =E2=80=9CThe field MUST > NOT hold attributes about the payload being signed=E2=80=9D. Assuming th= at a > flattened syntax is added, this would then become something like =E2=80= =9CThe field > MUST NOT hold attributes about the payload being signed unless the > flattened serialization is being used=E2=80=9D. Other related statements > throughout the document would likewise need to be similarly updated. > > [JLS] But it is not current added =E2=80=93 so this is not currently an a= ctionable > 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=E2=80=99s association with the signing identity is described. Pa= rticular > methods are clearly beyond the scope of this specification but saying thi= s > 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=E2=80=99ll note that if issue 3 is resolved (*Wrapped keys should be ab= le 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 =E2=80=9Civ=E2=80=9D (initialization vector) field should a= lso be defined in > the list of parameters for the encryption object. Yes, not all algorithm= s > will use it, but many will. > > > > m. A =E2=80=9Ctag=E2=80=9D (authentication tag) field should be defined = in the list of > parameters for the encryption object. Yes, not all the algorithms will u= se > it, but many will. > > [JLS] Maybe true for =E2=80=98iv=E2=80=99, however =E2=80=98tag=E2=80=99 = 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 =E2=80=9Ckid=E2= =80=9D or other key > selection value. A =E2=80=9CSHOULD =E2=80=A6 unless =E2=80=A6=E2=80=9D c= onstruct like was used in similar > JOSE descriptions is probably the right thing to use here. > > [JLS] The =E2=80=A6unless=E2=80=A6 clause is confusing as hell so I do no= t 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 =E2=80=9CHow to compute a MAC=E2=80=9D 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 =E2=80=9Ckey_ops=E2=80=9D unnecessary= . Language > something like =E2=80=9CIt is strongly suggested that this element be pre= sent for > all keys unless this information is already know to the application throu= gh > other means=E2=80=9D should be used to capture this. > > > > The working group should also discuss whether it wants to carry forward > =E2=80=9Cuse=E2=80=9D 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=E2=80=99t see any good use for it that is not better served by =E2=80= =98key_ops=E2=80=99. This > is doubly true given that the W3C Crypto group > > > > q. I would define short numeric values that correspond to the defines > =E2=80=9Ckey_ops=E2=80=9D string values. I=E2=80=99d do the same for the= =E2=80=9Cuse=E2=80=9D 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 =E2=80=9CSHOULD=E2=80=9D be changed to = =E2=80=9CMUST=E2=80=9D. CBOR > doesn=E2=80=99t have the same legacy of lax parsers that we inherited fro= m > JavaScript/ECMAscript for JSON. Let=E2=80=99s not open the door to them! > > > > 9.5 COSE Algorithm Registry > > > > s. I would add an additional =E2=80=9CJOSE algorithm name=E2=80=9D field= to this > registry, whose value is the corresponding =E2=80=9CAlgorithm Name=E2=80= =9D entry in the > IANA JSON Web Signature and Encryption Algorithms registry at > http://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-= algorithms, > if such an entry exists. This will tie the two registries together so th= at > definitions of algorithms already defined by JOSE need not be repeated fo= r > 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 =E2=80=9Capplication/cose=E2=80=9D,= I would also > register one for a base64url encoded COSE message =E2=80=93 an idea first= described > to me by Joe Hildebrand. It could be called =E2=80=9Capplication/cose+ba= se64url=E2=80=9D > 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 reaso= n > to believe otherwise? > > > > 9.8.2 COSE Key Media Type > > > > u. =E2=80=9Capplication/jwk+json=E2=80=9D should be changed to something= like > =E2=80=9Capplication/cose-key=E2=80=9D and =E2=80=9Capplication/jwk-set+j= son=E2=80=9D should be changed to > something like =E2=80=9Capplication/cose-key-set=E2=80=9D. > > > > 11.2. Informative References > > > > v. The date on the AES-GCM reference (SP 800-38D) should be November 200= 7 > =E2=80=93 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 = =E2=80=9Cthe > ciphertext and tag outputs=E2=80=9D =E2=80=93 not a single combined outpu= t. 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 th= e > text =E2=80=9CThe final result c consists of the encrypted message follow= ed by the > encrypted authentication value U=E2=80=9D, which admits either implementa= tion. > Likewise, at least the .NET CCM implementation produces separate cipherte= xt > and authentication tag values. > > > > Whether the tag should be separate or automatically appended to the > ciphertext isn=E2=80=99t a hill I=E2=80=99m going to die on (although the= working group > should discuss this and make an explicit decision in this regard), but th= e > text describing the decision should at least be changed to be accurate. > > > > [JLS] Wrong reference =E2=80=93will correct. > > > > Appendix C. Examples > > > > x. The uses of strings and corresponding labels such as those that follo= w > are confusing =E2=80=93 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=E2=80=99t 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 =E2=80=9CHeader Algorithm=E2=80=9D to =E2=80= =9CHeader Parameter=E2=80=9D. (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=E2=80=99t = 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 > =E2=80=9Cname=E2=80=9D 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 =E2=80=9Ckty=E2=80=9D values (EC=3D= 1, RSA=3D2, oct=3D3) > with curve values (P256=3D4, P521=3D5). I would keep these separate. Al= so, > 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=E2= =80=99ll > post the pull request link once it=E2=80=99s been created. > > > > *CONCLUSIONS* > > > > I=E2=80=99d like to thank Jim for doing the work to produce a well-though= t-out > initial draft. I believe it provides a solid starting point for the COSE > work. > > > > I=E2=80=99d 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 > > > > _______________________________________________ > 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 > > > > > --001a1141b960ef97d3051a7515d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yeah, maybe so. Kathleen (cc'd) just cited &= quot;management [being] explicitly out-of-scope for COSE as stated in the c= harter" at http://www.ietf.org/mail-archive/web/jose/current/msg05169= .html

So perhaps the charter needs to be clarified or a n= ew term used in the draft.

On Thu, Jul 9, 2015 at 11:46 AM, Jim Schaad <ietf@augustcellars.com> wrote:

It may be that it needs to be a different term, oth= ers might raise the same issue.=C2=A0 I feel off at the moment because I th= ink I probably wrote that sentence in the charter as was not being consiste= nt.

= =C2=A0

Jim=

=C2=A0

=C2=A0<= /p>

From: Brian = Campbell [mailto:bcampbell@pingidentity.com]
Sent: Thursday, July 09, 2= 015 9:51 AM
To: Jim Schaad
Cc: Justin Richer; Mike Jone= s; cose@ietf.org


Subject: Re: [Cose] Review of draf= t-schaad-cose-msg-01

=C2=A0

I wasn't necessarily sugg= esting that a new/different term be used (and apologize for a general ignor= ance about CMS). I just wanted to reconcile how =E2=80=9Ckey management=E2= =80=9D could be explicitly out of scope in the charter while unavoidably in= scope for the document.

=C2=A0

On Tue, Jul 7= , 2015 at 4:40 PM, Jim Schaad <ietf@augustcellars.com> wrote:

<= blockquote style=3D"border:none;border-left:solid #cccccc 1.0pt;padding:0in= 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">

I am more than willing to have a different term for= =E2=80=9CKey Management=E2=80=9D.=C2=A0 However, I have inherited the term= from CMS (RFC 2630) where section 12.3 talks about key management algorith= ms.

=C2=A0

What you re ref= erring to below, I generally put under the term of key life cycle=

=C2=A0

Jim

=

=C2=A0

=C2=A0

From: Brian Campbell [mai= lto:bcampbe= ll@pingidentity.com]
Sent: Tuesday, July 07, 2015 1:36 PMTo: Justin Richer
Cc: Mike Jones; Jim Schaad; cose@ietf.org
Subject: Re: [Cose] Review of draft-schaad-cose-msg-01

=C2=A0

[wearing my cow= boy hat from Dallas:)]

I think the term "key management&qu= ot; has gotten a little overloaded here.

I believe= the charter uses the term in the broader and traditional sense that Wikipe= dia, for example, talks about it, like "dealing with the generatio= n, exchange, storage, use, and replacement of keys" including "ke= y servers [and] user procedures."

=

Whereas the= term seemed to get somewhat co-opted in JOSE as a catch all to cover all t= he message level key encryption, key encapsulation, and key agreement bits = that are needed to convey and protect a content encryption key for encrypti= on. And that usage has carried over into COSE.

COSE needs "key management" in the latter sense of the word. Ma= ybe it should be called something else but it's a necessity for encrypt= ion. My question the other day was about the what value there is in doing i= t for MAC keys.

I suspe= ct the "Key management and binding of keys to identities are out of sc= ope" in the former sense in the charter is intended to keep COSE scope= reasonably constrained.=C2=A0

=C2=A0


=C2=A0 =C2=A0

=C2=A0

On Tue, Jul 7, 2015 = at 1:54 PM, Justin Richer <jricher@mit.edu> wrote:

Perhaps I=E2=80=99m missing something, but as chai= r I feel the need to point out this line in our current charter for you all= to consider:

=C2=A0= 

Key management and binding of k=
eys to identities are out of scope for the
working group.

=C2=A0

=C2=A0=E2=80=94 Justin

=C2=A0

=C2=A0<= u>

<= div>

On Jul 7, 2015, at 3:50 PM, Mike Jones= <Micha= el.Jones@microsoft.com> wrote:

=C2=A0

Jim, I hadn=E2=80=99t seen = an answer to this question.=C2=A0 If the thread you=E2=80=99re referring to= is =E2=80=9CKey management in the World of COSE=E2=80=9D, my impression is= that some people talked about use cases, but there were no actual conclusi= ons drawn.

=C2=A0

Also, could you answer Brian Campbell=E2=80=99s quest= ion in the related thread =E2=80=9CKey management for MACs (was Re: [Cose] = Review of draft-schaad-cose-msg-01)=E2=80=9D?=C2=A0 As I said in my reply, = I completely understand the value of key management for encryption, in whic= h there are secrets to protect, but not for MACs, where there are not.

= =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 Thanks,

=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

<= div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0= in 0in">

From: Mike Jones
Sent:<= /b> Tuesday, June 30, 2015 2:54 PM
To: 'Jim Schaad'; cose@ietf.org
Subj= ect: RE: [Cose] Review of draft-schaad-cose-msg-01=

=C2=A0

Jim, is the discussion you=E2=80= =99re referring to for my issue 2 the thread =E2=80=9CKey management in the= World of COSE=E2=80=9D or is there an additional thread you=E2=80=99re ref= erring to?

=C2=A0

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

=C2=A0

=C2=A0

=C2=A0

=

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

=C2=A0

In response to the call for adoption, I=E2=80=99m subm= itting 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=9Cke= eping simple things simple=E2=80=9D.=C2=A0 Particularly in constrained envi= ronments, it=E2=80=99s likely to be normal for implementations to use only = the parts of COSE they their application needs.=C2=A0 I believe that we sho= uld therefore optimize the representations we define for the common cases, = while making it possible to also gracefully accommodate less common, if pos= sibly 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

2.=C2=A0 HMACs should be optimized for t= he no-key-management case.

=C2= =A0

Particularly for constrained de= vices, it is unlikely that applications will want to pay the performance pe= nalty of generating and encrypting a key management key to perform a MAC op= eration.=C2=A0 Heck, they may not have credible random number generation in= the first place!=C2=A0 And they are likewise unlikely to want to pay the m= essage size penalty of carrying the encrypted key.

=C2=A0

I=E2=80=99m = fine with the optional ability to have key management for MACs, but the def= ault should be that no key management information is present in the represe= ntation.=C2=A0 The only algorithm represented by default should be the MAC = algorithm =E2=80=93 not even =E2=80=9Cdir=E2=80=9D (direct).=C2=A0 I suspec= t that this can be cleanly done by omitting the key management layer entire= ly when it=E2=80=99s not used, rather than explicitly using =E2=80=9Cdir=E2= =80=9D (direct).

=C2=A0

[JLS] See above.

=C2=A0

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

=C2=A0

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

=C2=A0

A simple way to achieve this is to define an e= ncrypted_key field to represent the wrapped key, when appropriate for the a= lgorithm.=C2=A0 Among other benefits, this will enable the use of the stand= ard RFC 3394 AES Key Wrap algorithms, in the same way that JOSE uses =E2=80= =9CA128KW=E2=80=9D, etc.

=C2=A0<= /u>

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.=C2=A0 Applications can then= choose which method works best for them.

=C2=A0

[JLS] I don=E2=80=99t understand = this comment.=C2=A0 This is not what the document says.

=C2=A0

= 4.=C2=A0 Simpler and more comprehensible examples are needed.=

=C2=A0

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

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = HMAC without key management

=C2=B7=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Single signature

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Encryption using AES Ke= y Wrap for key management and AES GCM for content encryption<= /p>

=C2=A0

Al= so, to be comprehensible to most readers, the examples need to include both= symbolic and numeric identifiers for all fields.=C2=A0 Also, decoded repre= sentations for encoded values need to be shown.

=C2=A0

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

=C2=A0

=C2=A0=C2=A0 {

=C2=A0= =C2=A0=C2=A0=C2=A0 1: 3,

=C2=A0=C2= =A0=C2=A0=C2=A0 2: h'a10104',

=C2=A0=C2=A0=C2=A0=C2=A0 4: h'546869732069732074686520636f6e74656e74= 2e',

=C2=A0=C2=A0=C2=A0=C2=A0 1= 0: h'2ba937ca03d76c3dbad30cfcbaeef586f9c0f9ba616ad67e9205d3857

=C2=A0=C2=A0 6ad9930',

=C2=A0

to b= eginning like this:

=C2=A0

=C2=A0=C2=A0 {

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

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

=C2= =A0=C2=A0=C2=A0=C2=A0 4 (payload): h'546869732069732074686520636f6e7465= 6e742e',

=C2=A0=C2=A0=C2=A0=C2= =A0 10 (tag): h'2ba937ca03d76c3dbad30cfcbaeef586f9c0f9ba616ad67e9205d38= 57

=C2=A0=C2=A0 6ad9930',

=C2=A0

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

=C2=A0

MINOR IS= SUES

=C2=A0

These issues are organized by section number, providin= g comments on the spec text in the order of appearance.=C2=A0 27 issues are= described, labeled a, b, c, =E2=80=A6 aa.=C2=A0 The section numbers and na= mes in which they appear are included in the write-up.

=C2=A0

2.=C2=A0= The COSE_MSG structure

=C2=A0

a.=C2=A0 Change:

=C2= =A0=C2=A0 Implementations MUST be prepared to find an integer under this la= bel

=C2=A0=C2=A0 which does not correspond to the v= alues 1 to 3.=C2=A0 If this is found

=C2=A0=C2=A0 t= hen the client MUST stop attempting to parse the structure and fail.=

to:

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

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

<= span style=3D"font-family:"Courier New"">=C2=A0=C2=A0 then the cl= ient MUST stop attempting to parse the structure and fail,=

=C2=A0=C2=A0 unless it understands and implements the extension lab= el value.

=C2=A0

= =C2=A0

b.=C2=A0 This syntax needs m= ore explanation:

=C2=A0=C2=A0 COSE_= Tagged_MSG =3D #6.999(COSE_MSG)=C2=A0=C2=A0 ; Replace 999 with TBD1<= u>

=C2=A0

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

=C2=A0

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

<= p class=3D"MsoNormal">=C2=A0=

c.=C2=A0 Change:

=C2=A0=C2=A0 |= ciphertext=C2=A0 | 4=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | TODO: Should we re-us= e the same as payload |

=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 | or not?=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 |

to:

=C2=A0=C2=A0 | ciphertext=C2=A0 | 7=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 | For COSE_encrypt=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

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

=C2=A0

[JLS]=C2=A0 The TODO is a marker for future discussion =E2= =80=93 There are both advantages and disadvantages to re-using the same lab= el.=C2=A0 On one hand, it is easy for programs to always look in the same l= ocation for the content independent of what type of content it is.=C2=A0 Th= is may make things easier for items which have detached content depending o= n how the API handles this.=C2=A0 On the other hand, an API might want to h= ave them separate.=C2=A0=C2=A0 I don=E2=80=99t know what the answer for thi= s is yet.

=C2=A0

d.=C2=A0 Chan= ge:

=C2=A0 These two buckets

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

=C2=A0=C2=A0 except for keys.=C2=A0 While these buck= ets can be present, they may not

=C2=A0=C2=A0 all b= e usable in all instances.

t= o:

=C2=A0 These two buckets

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

=C2=A0=C2=A0 except for keys.=C2=A0 While these buckets a= re defined, they may not

=C2=A0=C2=A0 be usable or = used in all instances.

=C2=A0<= /p>

The new text makes it clearer that =E2=80=9Cprote= cted=E2=80=9D and =E2=80=9Cunprotected=E2=80=9D can=E2=80=99t be included w= here their values can=E2=80=99t be used.

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

=C2=A0

3.1.=C2=A0 COSE Headers

=C2=A0

e.=C2=A0 Ch= ange:

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

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 an appl= ication which is processing a message is required to

to:

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

= =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 defined by extensions to this specification that=

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

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 understand.

=C2=A0

The language should make it clear that = =E2=80=9Ccrit=E2=80=9D is only for defining behavior of critical extensions= =E2=80=93 not for making header parameters defined by this spec critical.<= u>

[JLS] Thi= s does not make things clearer tome.

=C2=A0

f.=C2=A0 In Table 2= , change:

=C2=A0=C2=A0 | jku=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= | *=C2=A0=C2=A0=C2=A0=C2=A0 | tstr=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 | URL to COSE key object= =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 | = jwk=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | *=C2=A0=C2=A0=C2=A0=C2=A0 | COSE_Key |= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | contains a C= OSE key not |

=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 | a JWK key=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |

to:=

=C2=A0=C2=A0 | jku=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | *=C2=A0=C2=A0= =C2=A0=C2=A0 | tstr=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 | URL to JWK [RFC 7517] =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| cku=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 | *=C2=A0=C2=A0=C2=A0=C2=A0 | tstr=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 | URL to = COSE key object=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 | ck=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0| *=C2=A0=C2=A0=C2=A0= =C2=A0 | COSE_Key |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 | contains a COSE key=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 |

=C2=A0

It still makes sense to be able to represent URLs = to JWK and COSE Key objects.=C2=A0 But we shouldn=E2=80=99t call the COSE K= ey passed by value =E2=80=9Cjwk=E2=80=9D, since that=E2=80=99s misleading.<= u>

[JLS] Thu= s the open issue marker.

=C2=A0

g.=C2=A0 =C2=A0=C2=A0=C2=A0Open Issue 1.=C2=A0 Which of the following ite= ms do we want to have standardized in

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

=C2=A0

I would keep all of them, other than changi= ng =E2=80=9Cjku=E2=80=9D and =E2=80=9Cjwk=E2=80=9D to =E2=80=9Cjku=E2=80=9D= , =E2=80=9Ccku=E2=80=9D, and =E2=80=9Cck=E2=80=9D per (f) above.<= /u>

[JLS] This will be = a discussion issue.

=C2=A0

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

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 algorithm s= pecific or generic headers?"

= =C2=A0

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

=C2=A0

4.=C2=A0 Signing Structure

=C2= =A0

i.=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 The description of =E2=80=9Cprotec= ted=E2=80=9D says =E2=80=9CThe field MUST NOT hold attributes about the pay= load being signed=E2=80=9D.=C2=A0 Assuming that a flattened syntax is added= , this would then become something like =E2=80=9CThe field MUST NOT hold at= tributes about the payload being signed unless the flattened serialization = is being used=E2=80=9D.=C2=A0 Other related statements throughout the docum= ent would likewise need to be similarly updated.

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

=C2=A0

j.=C2=A0 The end of the signing section says:

=C2=A0= =C2=A0 In addition to performing the signature verification, one must also<= /span>

=C2=A0=C2=A0 perform the appropriate checks to ensu= re that the key is correctly

=C2=A0=C2=A0 paired wi= th the signing identity and that the appropriate

= =C2=A0=C2=A0 authorization is done.

=C2=A0

There needs to be a = reference to a place where the process of verifying the key=E2=80=99s assoc= iation with the signing identity is described.=C2=A0 Particular methods are= clearly beyond the scope of this specification but saying this little abou= t the process will likely just leave many people confused.

[JLS] What do you think t= his should reference?

=C2=A0=

5.=C2=A0 Encryption Object<= u>

=C2=A0

k.=C2=A0 The introduction to this section says:

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

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

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

=C2=A0=C2=A0protect the text.=C2=A0 This is differen= t from the approach used by both

=C2=A0=C2=A0 [RFC5= 652] and [RFC7516] where different structures are used for the

=C2=A0=C2=A0 plain text and for the different key management te= chniques.

=C2=A0

I=E2=80=99ll 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.<= /u>

[JLS] But currently= not an actionable statement.

=C2=A0

l.=C2=A0 A generic =E2=80= =9Civ=E2=80=9D (initialization vector) field should also be defined in the = list of parameters for the encryption object.=C2=A0 Yes, not all algorithms= will use it, but many will.

=C2=A0=

m.=C2=A0 A =E2=80=9Ctag=E2=80=9D (= authentication tag) field should be defined in the list of parameters for t= he encryption object.=C2=A0 Yes, not all the algorithms will use it, but ma= ny will.

= [JLS] Maybe true for =E2=80=98iv=E2=80=99, however =E2=80=98tag=E2=80=99 is= part of the ciphertext.

=C2= =A0

5.1.1.=C2=A0 Direct Encryption<= u>

=C2=A0

n.=C2=A0 The spec says:

=C2=A0=C2=A0 o=C2=A0 A= t a minimum, the 'unprotected' field MUST contain the 'alg'=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 parameter and SHOUL= D contain a parameter identifying the shared

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 secret.

=C2=A0

SHOULD is too strong he= re because in some protocols, the shared secret will already be known by me= thods other than an included =E2=80=9Ckid=E2=80=9D or other key selection v= alue.=C2=A0 A =E2=80=9CSHOULD =E2=80=A6 unless =E2=80=A6=E2=80=9D construct= like was used in similar JOSE descriptions is probably the right thing to = use here.

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

=C2=A0

6.=C2=A0 MA= C Objects

=C2=A0

<= p class=3D"MsoNormal">o.=C2=A0 The =E2=80=9CHow to compute a MAC=E2=80=9D i= nstructions say:

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

=C2=A0

This is n= ot correct when direct key management or no key management is used.=C2=A0 P= lease revise to accurately include these cases as well.

[JLS} This is correct for th= e current document.

=C2=A0

7.=C2=A0 Key Structure=

=C2=A0

p= .=C2=A0 The spec says:

=C2=A0=C2=A0 The "key_ops&quo= t; element is preferred over the "use" element as the

=C2=A0=C2=A0 information provided that way is more finely deta= iled about the

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

=C2=A0

Like in (n), the ap= plication may know the key usage from application context, rendering the in= clusion of =E2=80=9Ckey_ops=E2=80=9D unnecessary.=C2=A0 Language something = like =E2=80=9CIt is strongly suggested that this element be present for all= keys unless this information is already know to the application through ot= her means=E2=80=9D should be used to capture this.

=C2=A0

The working = group should also discuss whether it wants to carry forward =E2=80=9Cuse=E2= =80=9D for JWK compatibility, even if it is deprecated.=C2=A0 I personally = would be in favor of doing so.

[JLS] If you think this, then please open it as a dis= cussion issue.=C2=A0 I don=E2=80=99t see any good use for it that is not be= tter served by =E2=80=98key_ops=E2=80=99.=C2=A0 This is doubly true given t= hat the W3C Crypto group

=C2= =A0

q.=C2=A0 I would define short n= umeric values that correspond to the defines =E2=80=9Ckey_ops=E2=80=9D stri= ng values.=C2=A0 I=E2=80=99d do the same for the =E2=80=9Cuse=E2=80=9D valu= es.

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

=C2=A0

8.=C2=A0 CBOR= Encoder Restrictions

=C2=A0=

r.=C2=A0 The spec says:

=

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

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 same la= bel is used twice as a key for the same map.

=C2=A0

I would str= ongly prefer that the =E2=80=9CSHOULD=E2=80=9D be changed to =E2=80=9CMUST= =E2=80=9D.=C2=A0 CBOR doesn=E2=80=99t have the same legacy of lax parsers t= hat we inherited from JavaScript/ECMAscript for JSON.=C2=A0 Let=E2=80=99s n= ot open the door to them!

=C2=A0=

9.5=C2=A0 COSE Algorithm Registry<= /u>

=C2=A0

s.=C2=A0 I would add an additional =E2=80=9CJOSE algorithm name=E2= =80=9D field to this registry, whose value is the corresponding =E2=80=9CAl= gorithm Name=E2=80=9D entry in the IANA JSON Web Signature and Encryption A= lgorithms registry at http://www.ian= a.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms, = if such an entry exists.=C2=A0 This will tie the two registries together so= that definitions of algorithms already defined by JOSE need not be repeate= d for COSE.

=C2=A0

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

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

=C2=A0

9.8.1=C2=A0 COSE Security Message

=C2=A0

t.=C2=A0 Be= sides registering the MIME type =E2=80=9Capplication/cose=E2=80=9D, I would= also register one for a base64url encoded COSE message =E2=80=93 an idea f= irst described to me by Joe Hildebrand.=C2=A0 It could be called =E2=80=9Ca= pplication/cose+base64url=E2=80=9D or something of that ilk.<= /p>

[JLS]=C2=A0 I would exp= ect the media-type reviewers to object to that because this is a transport = encoding not a content encoding.=C2=A0 Do you have a reason to believe othe= rwise?

=C2=A0<= /p>

9.8.2=C2=A0 COSE Key Media Type

=

=C2=A0

u.=C2= =A0 =E2=80=9Capplication/jwk+json=E2=80=9D should be changed to something l= ike =E2=80=9Capplication/cose-key=E2=80=9D and =E2=80=9Capplication/jwk-set= +json=E2=80=9D should be changed to something like =E2=80=9Capplication/cos= e-key-set=E2=80=9D.

=C2=A0

11.2.=C2=A0 Informative References

=C2=A0

v.=C2=A0 The date on the AES-GCM reference (SP 800-38D) should be Novem= ber 2007 =E2=80=93 not June 2015.

= =C2=A0

Appendix A.=C2=A0 AEAD and A= E Algorithms

=C2=A0

w.=C2=A0 The spec says:

=C2=A0 T= his authentication value may be:

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

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 decrypter and then compared b= y the decryptor.=C2=A0 This tag value may

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 be either placed at the end of the cipher text (th= e decision we

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 made) = or kept separately (the decision made by the JOSE working<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 group).=C2=A0 This is the approach fo= llowed by AES-GCM [AES-GCM] and

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 AES-CCM [RFC3610].

=C2=A0

The last sentence is not= true, as written.=C2=A0 The AES-GCM spec describes =E2=80=9Cthe ciphertext and tag outputs=E2=80=9D =E2=80=93= not a single combined output.=C2=A0 Common implementations correspond to t= his, such as the implementation of GCM in .NET.

=C2=A0

The CCM descr= iption in RFC 3610 Section 2.4 describes the output using the text =E2=80= =9CThe final result c consists of the encrypted message followed by the enc= rypted authentication value U=E2=80=9D, which admits either implementation.= =C2=A0 Likewise, at least the .NET CCM implementation produces separate cip= hertext and authentication tag values.

=C2=A0

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

=C2=A0

[JLS] Wrong reference =E2=80=93will correct.=

=C2=A0

Appendix C.=C2=A0 Examples

= =C2=A0

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

= =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 3: {

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 5: "bilbo.baggins@hobbiton.example"<= /p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 },=

=C2=A0

T= here are similar strings in some of the other examples that I also couldn= =E2=80=99t wrap my head around.

[JLS] My code does not match the spec here.=C2=A0 Or= iginally they were strings.

= =C2=A0

Appendix D.=C2=A0 COSE Heade= r Algorithm Label Table

=C2=A0

y.=C2=A0 I would change the term =E2=80= =9CHeader Algorithm=E2=80=9D to =E2=80=9CHeader Parameter=E2=80=9D.=C2=A0 (= I suspect this was a cut-and-paste error.)

[JLS] I have not settled on a consistent = set of terms for this yet.=C2=A0 I need to do so and then make a pass to co= rrect them all.=C2=A0 I don=E2=80=99t think that some of the terms I am cur= rently using are sufficiently distinct to make it easy to figure things out= .

=C2=A0

z.=C2=A0 In Appendix D and Appendix E, I would call ou= t that the names in the =E2=80=9Cname=E2=80=9D columns correspond to names = defined in RFC 7518.

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

=C2=A0

Appendix F.=C2=A0 COSE = General Values

=C2=A0=

aa.=C2=A0 This seems confused, as it mixes =E2= =80=9Ckty=E2=80=9D values (EC=3D1, RSA=3D2, oct=3D3) with curve values (P25= 6=3D4, P521=3D5).=C2=A0 I would keep these separate.=C2=A0 Also, wherever t= he curve names are defined, I would also include P384, as JOSE did.<= u>

[JLS] That may h= appen in the future.=C2=A0 I just needed a table to put things in for now.<= /span>

=C2=A0

NITS

=C2= =A0

I will be submitting spelling a= nd grammar corrections as a GitHub pull request against the spec repository= rather than detail them here.=C2=A0 I=E2=80=99ll post the pull request lin= k once it=E2=80=99s been created.

= =C2=A0

CONCLUSIONS=

=C2=A0

I=E2=80=99d like to thank Jim for doing the work to produce a well-thoug= ht-out initial draft.=C2=A0 I believe it provides a solid starting point fo= r the COSE work.

=C2=A0

I=E2=80=99d be willing to produce specific pro= posed edits for any/all of the above issues and comments, should the editor= s find that useful.

=C2=A0<= u>

=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 Best wishes,

=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

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

=C2=A0

<= /div>


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

=C2=A0

=C2=A0


--001a1141b960ef97d3051a7515d9-- From nobody Thu Jul 9 14:00: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 DC2AF1A017D for ; Thu, 9 Jul 2015 14:00:38 -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 4_iYU1bJ_dZo for ; Thu, 9 Jul 2015 14:00:38 -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 305871A0203 for ; Thu, 9 Jul 2015 14:00:36 -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 t69L0X5i027121 for ; Thu, 9 Jul 2015 23:00:33 +0200 (CEST) Received: from alma.local (p5DCCC755.dip0.t-ipconnect.de [93.204.199.85]) (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 3mS8zP2K7gz3GWN; Thu, 9 Jul 2015 23:00:33 +0200 (CEST) Message-ID: <559EE0EF.2030008@tzi.org> Date: Thu, 09 Jul 2015 23:00:31 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: cose@ietf.org References: <000201d0b0ed$755707c0$60051740$@augustcellars.com> <3C5E1125-371E-40E6-BD72-19C63F76DF58@mit.edu> <008101d0b906$0e744e70$2b5ceb50$@augustcellars.com> <015f01d0ba6f$25306850$6f9138f0$@augustcellars.com> In-Reply-To: <015f01d0ba6f$25306850$6f9138f0$@augustcellars.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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: Thu, 09 Jul 2015 21:00:39 -0000 We just had a discussion at the IoT directorate that maybe we need a document explaining terms that historically have been causing confusion, because of their widely varying meanings. "Key management" was one of the terms cited -- it certainly qualifies. Grüße, Carsten Jim Schaad wrote: > It may be that it needs to be a different term, others might raise the > same issue. I feel off at the moment because I think I probably wrote > that sentence in the charter as was not being consistent. From nobody Fri Jul 10 02:36: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 033851A8A76 for ; Fri, 10 Jul 2015 02:36:42 -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 f0buJfMQLBDB for ; Fri, 10 Jul 2015 02:36:41 -0700 (PDT) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C089C1A8A74 for ; Fri, 10 Jul 2015 02:36:40 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 2548469A11; Fri, 10 Jul 2015 12:36:38 +0300 (EEST) Date: Fri, 10 Jul 2015 12:36:37 +0300 From: Ilari Liusvaara To: Jim Schaad Message-ID: <20150710093637.GA9976@LK-Perkele-VII> References: <559576A9.9090002@gmx.net> <001001d0b90c$3c874af0$b595e0d0$@augustcellars.com> <00c501d0b9a5$c8f869d0$5ae93d70$@augustcellars.com> <000f01d0baad$8a781b20$9f685160$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <000f01d0baad$8a781b20$9f685160$@augustcellars.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: 'Brian Campbell' , cose@ietf.org Subject: Re: [Cose] Key management for MACs (was Re: 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: Fri, 10 Jul 2015 09:36:43 -0000 On Thu, Jul 09, 2015 at 06:12:49PM -0700, Jim Schaad wrote: > > Looking at the new signature formats coming out of CFRG, I am not sure > what the lengths of the signatures are, AFAICT, 64 or 112-114 bytes (packable to 112 with some bit shuffling). One proposal allows half-length hash, giving 48 or 84 bytes. Public keys are 32 or 57 bytes. (All can be defined on intermediate size curves too, for intermediate signature/pubkey size at intermediate security). -Ilari From nobody Fri Jul 10 06:07:51 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 352781AC3B3 for ; Fri, 10 Jul 2015 06:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 G7SqBNQTuayU for ; Fri, 10 Jul 2015 06:07:49 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E6D51AC3A0 for ; Fri, 10 Jul 2015 06:07:49 -0700 (PDT) Received: by igpy18 with SMTP id y18so12399260igp.0 for ; Fri, 10 Jul 2015 06:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qIi7Ewu0WOEM8v5kOggt9MoRGM/szrS/2bActNIfuwc=; b=DJ+MnQZNLox8KlJQ+ECK88UBs9W95xGeb3nosBxRkpIaX9bo9zKgyTTI9eZWHHJjQP pN0EjOlmjNOwW7EV+gFMmJGJcgmryvQKJlWS4uhJ4Fcz/quw8Q/O/XHRBPq54OQ6Nqoa y6A6k3HSFiZdDcPbXJ9alDiMs5NlOuxlJ0/SE= 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=qIi7Ewu0WOEM8v5kOggt9MoRGM/szrS/2bActNIfuwc=; b=GUupCtyzfvPPtAGircZYP5kzJyaSC0j6KulTNZgoPb3dJncDGqP64TLgj0nXuxpCIi 39RyrvWH1VMknhUw85AyomTzUDffPoEWOlVcazMKxl62EHW8UJK2uVVaIkpRYF5U4OQf DufIgdw5mQmYAFUy9pqPqLa+fuFbwoMlmZrxYNIU715KFUEFWkMnavTS1avofMwCFKTv QwZWUaU4Zl3PQUqRfjDHNg4BKosbcPO/fM8yPvXiEL1KtClHJw9r2kYOUPC6EA+7qxIX 7GSnu4cLM88nfCPG5lmvcFBm1BS4pEqn+uWDEUA6aNBcJ8w4kJ3K/Ea+wdy3rprIS4CK JZyg== X-Gm-Message-State: ALoCoQl7welp/7ls1BciGAS02nt6UBS+AdthKwtHGjt2ceZ+ISTWZ+LyXsJ9NM7YIVxvqVrHo5VD X-Received: by 10.50.79.169 with SMTP id k9mr2997969igx.63.1436533668499; Fri, 10 Jul 2015 06:07:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Fri, 10 Jul 2015 06:07:19 -0700 (PDT) In-Reply-To: References: <559576A9.9090002@gmx.net> From: Brian Campbell Date: Fri, 10 Jul 2015 07:07:19 -0600 Message-ID: To: Derek Atkins Content-Type: multipart/alternative; boundary=089e013a01c804e6d0051a850f90 Archived-At: Cc: Jim Schaad , Hannes Tschofenig , Mike Jones , cose@ietf.org Subject: Re: [Cose] Key management for MACs (was Re: 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: Fri, 10 Jul 2015 13:07:50 -0000 --089e013a01c804e6d0051a850f90 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 8, 2015 at 10:44 AM, Derek Atkins wrote: > Hannes Tschofenig writes: > > We are not doing ourselves a flavor if we place artificial constraints > > on our protocols that make them pretty insecure in practice. We already > > have enough insecure IoT devices in the market. > > Sure.. Many IoT devices don't even try :) > I just want us to be cognizant of the possibility that a dense complicated crypto messaging syntax will probably not change that situation. If it's not easy and approachable, it has the potential to be ignored. --089e013a01c804e6d0051a850f90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Jul 8, 2015 at 10:44 AM, Derek Atkins <derek@ihtfp.com> wrote:
Hannes Tschofenig <hannes.tschofeni= g@gmx.net> writes:
> We are not doing ourselves a flavor if we place artificia= l constraints
> on our protocols that make them pretty insecure in practice. We alread= y
> have enough insecure IoT devices in the market.

Sure.. Many IoT devices don't even try :)

I just want us to be cognizan= t of the possibility that a dense complicated crypto messaging syntax will = probably not change that situation. If it's not easy and approachable, = it has the potential to be ignored.
=C2=A0
=
--089e013a01c804e6d0051a850f90-- From nobody Fri Jul 10 06:12: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 33A691AC3AC for ; Fri, 10 Jul 2015 06:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 d7B5Qo7mffuI for ; Fri, 10 Jul 2015 06:12:56 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D706E1AC3B8 for ; Fri, 10 Jul 2015 06:12:48 -0700 (PDT) Received: by igrv9 with SMTP id v9so12301292igr.1 for ; Fri, 10 Jul 2015 06:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=srJp4TlnXyxGHa6uWQg7DU1asNYZcqOJbXovQlbzIPQ=; b=ioG2E0EjxWxkEPNgtKSEMPIqNYDpY++/Ur1Sw9nYoDp5K2x4T2ow+FnfnQBX17VK4B KwizBTkDUmquWXcjoUBhuCcOCiKqQelNTHuO9JJDv82znceWE7gVUo4J7AkZ5KI+O3fh KTPKwvifpc001TpEQjZCzJ2SQkpiJ/v7lS+SM= 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=srJp4TlnXyxGHa6uWQg7DU1asNYZcqOJbXovQlbzIPQ=; b=NKvBd779QvfJXHYidLyMFvUwJX0zWpMBWp4mXECojKGWxUlm9jYgc6FOoWDAE9iHLG ccrrESec2prFg8KwfpH6wRJzp0OFF5JHLXNBk7sxyVoxoxk5vH6WZ09FKiAv37+LX3Pr xJ2wgIVNLfVmWoC5FdgWH1YlwMA0b/pY+XHUx2lYp6e4MIW1lnbvGuiogHgxeHvBnI3U sMPlQ8ccL/jxg94xX3QWYhCUHvGebmPhmtVtByitm0yt0cTZwNtr9T74zGud3s8k77uI xp6+4ZZRrSnqvirv3qGtiXuveWqst5NHZJGTVCu5E6hU42JEgKWFM6Q0M4sGY6caBRA3 UlnA== X-Gm-Message-State: ALoCoQkmArjX4h0uiRU10lpnuU0WP+TY/tHgJL6PN1evEV29u1jOjoOPuRhEcHw9nTY492CMDG+N X-Received: by 10.50.111.231 with SMTP id il7mr3221407igb.23.1436533968280; Fri, 10 Jul 2015 06:12:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Fri, 10 Jul 2015 06:12:18 -0700 (PDT) In-Reply-To: <001601d0b908$c33baf90$49b30eb0$@augustcellars.com> References: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> <009501d0b392$fb7cc680$f2765380$@augustcellars.com> <00d001d0b3b6$ce20f2f0$6a62d8d0$@augustcellars.com> <559392F7.30000@tzi.org> <5594EA07.3030508@tzi.org> <001601d0b908$c33baf90$49b30eb0$@augustcellars.com> From: Brian Campbell Date: Fri, 10 Jul 2015 07:12:18 -0600 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=047d7b4142c8e33dac051a852036 Archived-At: Cc: Carsten Bormann , Justin Richer , 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: Fri, 10 Jul 2015 13:12:57 -0000 --047d7b4142c8e33dac051a852036 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 7, 2015 at 4:58 PM, Jim Schaad wrote: > > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Thursday, July 02, 2015 10:14 AM > *To:* Carsten Bormann > *Cc:* Justin Richer; Jim Schaad; cose@ietf.org > *Subject:* Re: [Cose] Issue: Encoding for a single recipient or structure > > > The JOSE experience I'm suggesting this WG consider is the relative > simplicity afforded by compact serializations and the widespread use they > have seen. > > [JLS] I don=E2=80=99t know how much of this is because it is easy, or be= cause > that was the format that was being used by =E2=80=9Ceverybody=E2=80=9D be= fore it even came > into the working group. Remember how many decisions boiled down to =E2= =80=93 we > can=E2=80=99t change this, it would break all of the existing code. > > > That the format was being used suggests that it provided utility to those that were using it. --047d7b4142c8e33dac051a852036 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 7, 2015 at 4:58 PM, Jim Schaad <ietf@aug= ustcellars.com> wrote:

=C2=A0

=C2=A0

From:= = Brian Campbell [mailto:bcampbell@pingidentity.com]
Sent: Thursday, July= 02, 2015 10:14 AM
To: Carsten Bormann
Cc: Justin Riche= r; Jim Schaad; cose@ietf= .org
Subject: Re: [Cose] Issue: Encoding for= a single recipient or structure


<= /span>

The JOSE e= xperience I'm suggesting this WG consider is the relative simplicity af= forded by compact serializations and the widespread use they have seen.

[JLS]=C2=A0 I don=E2=80=99t know how much of this i= s because it is easy, or because that was the format that was being used by= =E2=80=9Ceverybody=E2=80=9D before it even came into the working group.=C2= =A0 Remember how many decisions boiled down to =E2=80=93 we can=E2=80=99t c= hange this, it would break all of the existing code.

=C2=A0

<= /div>


That the forma= t was being used suggests that it provided utility to those that were using= it.
--047d7b4142c8e33dac051a852036-- From nobody Fri Jul 10 06:28:34 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 D5F721A8F43 for ; Fri, 10 Jul 2015 06:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 QbrWLiM_SN7p for ; Fri, 10 Jul 2015 06:28:28 -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 A1ED71A9026 for ; Fri, 10 Jul 2015 06:28:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 2F0C5E2035; Fri, 10 Jul 2015 09:28:27 -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 02237-01; Fri, 10 Jul 2015 09:28:25 -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 F3FA4E2034; Fri, 10 Jul 2015 09:28:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1436534905; bh=oTQtV7wCS5ugUILMh6rA5mOWyoREjJbbr6xpbsQIvC8=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=iuicb6eA6lphhZSfX822avbH8/mRTZj36h104WmYKOw8ocR1ghBfDDWGsZxSXSZWx +/eEYHIsjqc4KWjXH/Q73i0mcuP8O/u8hXvXi4Uw6D1R+TR9BN3vGH0go0TRDAVXBk JxPXuzDh7bHbZLL0CIsha4mFRhW+KYp26x6GT99U= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t6ADSO0w001195; Fri, 10 Jul 2015 09:28:24 -0400 From: Derek Atkins To: Brian Campbell References: <559576A9.9090002@gmx.net> <001001d0b90c$3c874af0$b595e0d0$@augustcellars.com> <00c501d0b9a5$c8f869d0$5ae93d70$@augustcellars.com> Date: Fri, 10 Jul 2015 09:28:24 -0400 In-Reply-To: (Brian Campbell's message of "Thu, 9 Jul 2015 16:37:29 -0600") 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 , Mike Jones , cose@ietf.org Subject: Re: [Cose] Key management for MACs (was Re: 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: Fri, 10 Jul 2015 13:28:33 -0000 Brian Campbell writes: > If I were able to do DH, I'd have a public/private key and I guess I never > would have thought about doing a key agreement and MAC. I'd probably just sign > with my key. Maybe I'm just not very creative. But while having options is > good, having too many options can be problematic. Being able to do DH does not imply being able to sign. They are different protocols and not every public-key method can be used for both operations. > Doing a MAC with RSA OAEP key encryption or ECDH-ES key agreement, to me > anyway, seems to provide little value and a big opportunity for confusion and > security problems. I don't believe it's an option that should be provided. Performing a MAC using the output of a DH (be it ECDH, AEDH, or raw DH) can still tell you that the transmission has not been modified between you and the party you're talking to. You're right that it tells you nothing about the party you're talking to (i.e., without authentication of the DH keys you have no idea if you're talking to a MITM or the real endpoint). However, using DH + MAC does tell you that you're not being spoofed by a "passive" eavesdropper. So IMHO it does have some benefit. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Jul 10 07:14: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 8E59E1B2C09 for ; Fri, 10 Jul 2015 07:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.179 X-Spam-Level: X-Spam-Status: No, score=-1.179 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HELO_MISMATCH_ORG=0.611, 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 Z-ip4wB-Zzsb for ; Fri, 10 Jul 2015 07:14:26 -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 3AD021B2C5B for ; Fri, 10 Jul 2015 07:14:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 3729FE2034; Fri, 10 Jul 2015 10:14:17 -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 02208-08; Fri, 10 Jul 2015 10:14:15 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 14C54E2046; Fri, 10 Jul 2015 10:14:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1436537655; bh=S2cPyU+FZGK8Cf7yRkYVqudwZ3rp8hc51zZNRMZRJKg=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=dRZPpQmkcXal/2vUwq3LE0OFfaShRNjjLhTHPc1o5DZNssWh5AH3SBF+qWRV1zNd5 z69P59wwS05Y7L5w7Oz2+Zso1o2CPOrnO622W7zVw0Pf7SbuWiNK5uH53Ci9Bo4mmH z+GG6zQ2t31TszcI1OekFYYuFv3hs3QtzmbJWukc= Received: from 192.168.248.204 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Fri, 10 Jul 2015 10:14:15 -0400 Message-ID: In-Reply-To: References: <559576A9.9090002@gmx.net> Date: Fri, 10 Jul 2015 10:14:15 -0400 From: "Derek Atkins" To: "Brian Campbell" 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 , Hannes Tschofenig , Derek Atkins , Mike Jones , cose@ietf.org Subject: Re: [Cose] Key management for MACs (was Re: 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: Fri, 10 Jul 2015 14:14:27 -0000 On Fri, July 10, 2015 9:07 am, Brian Campbell wrote: > On Wed, Jul 8, 2015 at 10:44 AM, Derek Atkins wrote: > >> Hannes Tschofenig writes: >> > We are not doing ourselves a flavor if we place artificial constraints >> > on our protocols that make them pretty insecure in practice. We >> already >> > have enough insecure IoT devices in the market. >> >> Sure.. Many IoT devices don't even try :) >> > > I just want us to be cognizant of the possibility that a dense complicated > crypto messaging syntax will probably not change that situation. If it's > not easy and approachable, it has the potential to be ignored. That's only half the problem. Many people ignore security because there is this belief "I can't reasonably run those algorithms on my devices." So I would augment this to say that it not only needs to be easy and approachable, but it also needs to be implementable on the hardware. That often rules out many cryptographic algorithms (like RSA and DH, and sometimes even ECC) depending on space, power, and timing constraints of the devices. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Jul 10 09:21: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 B93361B2CF9 for ; Fri, 10 Jul 2015 09:21:15 -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 4mCl2foEFsnN for ; Fri, 10 Jul 2015 09:21:11 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E71B1B2CFA for ; Fri, 10 Jul 2015 09:21:11 -0700 (PDT) X-AuditID: 12074424-f79b46d000001e7f-fa-559ff0f6309c 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-7.mit.edu (Symantec Messaging Gateway) with SMTP id 39.9B.07807.6F0FF955; Fri, 10 Jul 2015 12:21:10 -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 t6AGL9AG007275 for ; Fri, 10 Jul 2015 12:21:10 -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 t6AGL8U5011548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 10 Jul 2015 12:21:09 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_9F0EC9FF-B1F1-487B-8948-7A41181702F1" Message-Id: <00ED6606-C4CE-4B47-9D53-476A5D39B249@mit.edu> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Date: Fri, 10 Jul 2015 12:21:07 -0400 References: To: cose@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.2098) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixCmqrPvtw/xQg1f9ihbTtk5ldWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxr7vM5gK3ilXXOs6x9LA2CPfxcjJISFgInFg/wRWCFtM4sK9 9WxdjFwcQgKLmSS61/9ignCOMkqc2/SOFcL5yiTx/fE9sBY2AVWJ6WtamEBsZoEEiWtntrGD 2LwCVhIz5ixkgbD1JB49fQwWFxZQlDh5chNYPQtQ788dN9hAbCGg+hWPzwHN5OAQERCUuNtp DhLmFLCW2H6ojxEkLCEgK/F1q9wERv5ZSJbNQrIAIq4tsWzha2YIW1Nif/dyFkxxDYnObxNZ FzCyrWKUTcmt0s1NzMwpTk3WLU5OzMtLLdI118vNLNFLTSndxAgKYXYXlR2MzYeUDjEKcDAq 8fAGsM0PFWJNLCuuzD3EKMnBpCTKm/IaKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEt3sVUI43 JbGyKrUoHyYlzcGiJM676QdfiJBAemJJanZqakFqEUxWhoNDSYJ3w3ugRsGi1PTUirTMnBKE NBMHJ8hwHqDhnSA1vMUFibnFmekQ+VOMilLivNwgCQGQREZpHlwvLMW8YhQHekWYNwKkigeY nuC6XwENZgIaHC09D2RwSSJCSqqBUfdf2uzt2dLFrFPNMr89ejbr7MKib2vOPHww46aYjN3d 6VLTfLx7eDg1A18p9C6d8H6Cn/GFsx/3PP93WqbuamIbq7DF0YaIP4tni+WVTCsO0ru05bfu mcaYL/qOR3PYVi1mktWbsbzv4WPdqh9FxbmMmutnCvSv5bJauV+tT2Pzc/MjP/z36CixFGck GmoxFxUnAgDk1kC0DAMAAA== Archived-At: Subject: Re: [Cose] IETF93 Agenda 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, 10 Jul 2015 16:21:15 -0000 --Apple-Mail=_9F0EC9FF-B1F1-487B-8948-7A41181702F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi again everyone, Mike Jones has asked for some time during the meeting as well, so = here=E2=80=99s the new Agenda: IETF 93 COSE Meeting Agenda Opening & Welcome - 5min (Justin/Kepeng) Introduction to the COSE Working Group - 10min (Justin) > Questions/transition - 5min ACE Requirements - 10min (Goran) > Questions/transition - 5min Key issues and choices for COSE - 10min (Mike) > Questions/transition - 5min COSE Messages Draft Current State - 10min (Jim) Issues and open discussion - 30min =E2=80=94 Justin > On Jul 8, 2015, at 8:29 AM, Justin Richer wrote: >=20 > Hi everyone,=20 >=20 > This is what our current agenda is for IETF93: >=20 > Opening & Welcome - 5min (Justin/Kepeng) > Introduction to the COSE Working Group - 10min (Justin) > Questions/transition - 5min > ACE Requirements - 10min (Goran) > Questions/transition - 5min > COSE Messages Draft Current State - 10min (Jim) > Issues and open discussion - 45min >=20 >=20 > If you=E2=80=99d like a presentation slot, please let the chairs know. >=20 > =E2=80=94 Justin > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose --Apple-Mail=_9F0EC9FF-B1F1-487B-8948-7A41181702F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi again everyone,

Mike Jones has asked for some time during the meeting as = well, so here=E2=80=99s the new Agenda:

IETF 93

COSE Meeting Agenda


Opening & Welcome - 5min (Justin/Kepeng)
Introduction to the COSE Working Group - 10min (Justin)
 > Questions/transition - 5min
ACE Requirements - 10min (Goran)
 > Questions/transition - 5min
Key issues and choices for COSE - 10min (Mike)
 > Questions/transition - 5min
COSE Messages Draft Current State - 10min (Jim)
Issues and open discussion - 30min


 =E2=80=94 Justin

On = Jul 8, 2015, at 8:29 AM, Justin Richer <jricher@MIT.EDU> = wrote:

Hi = everyone, 

This = is what our current agenda is for IETF93:

Opening & = Welcome - 5min (Justin/Kepeng)
Introduction to the COSE Working Group - 10min = (Justin)
 Questions/transition - 5min
ACE Requirements - 10min = (Goran)
 Questions/transition - 5min
COSE Messages Draft Current State - 10min = (Jim)
Issues and open = discussion - 45min


If = you=E2=80=99d like a presentation slot, please let the chairs = know.

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

= --Apple-Mail=_9F0EC9FF-B1F1-487B-8948-7A41181702F1-- From nobody Fri Jul 10 09:58: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 6F1DD1B2A52 for ; Fri, 10 Jul 2015 09:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 NLUG7Y_tEXDn for ; Fri, 10 Jul 2015 09:58:48 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC051B2A3F for ; Fri, 10 Jul 2015 09:58:48 -0700 (PDT) Received: by iecvh10 with SMTP id vh10so200514888iec.3 for ; Fri, 10 Jul 2015 09:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BUyaFtfNA8cjryiReXl603W9xM+ydcOVzLk8yA0SQ3Q=; b=NEVPTHPMJUfLjP2vTnFJadV+O1qrkaooiw93QJL9N8sZ+e+bHn9j7SJ4uS7AKy7DsF 9LILn8l1BUb4C3cois2sJ/7NdKkGgnu3zmXH5ekP8FUoCdwd1jwj2MXvg14lxRAJK7xv x8Twb9G+Vuydcl4l8tvOlxW7DsL+h3NkU0NRY= 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=BUyaFtfNA8cjryiReXl603W9xM+ydcOVzLk8yA0SQ3Q=; b=efZBqKa7SMTU+6dWb1tKun4myveINNybhLECf8MPSLlwevXFyWz3XdhGtoCSe0LWfU 0gVPKvLLgxu3z4C8ggXjjsLXqKrisH6hylSOZcYKgupoKmoqxNhnQp5QkUbJJZdPN4eT O7s7j9y1Kl9J8ndx7pYo/SRAeno5CNbUhNuGttgyZSu5RshFHUbL4wHglv/aSp4ADcW4 1E/IX/FFy/qSE133ifQHkPzeBT2X1qgSMv65EFDDkL0nmRV79T4g/qWRFiLMPNN3UviK 1ng1SL7I3zTd2MbtfrNwGkCuqRkdY08pwfNVXsmJ1ec42on3rIoU16nCBobzrn+gHc/7 n5iw== X-Gm-Message-State: ALoCoQmxDdYxE1sbrQtpd0JUEsj+yLgn7Q9K3T3y09oBYDVQcD/Ff7z+HlDINMYJDvB1rFdhsosi X-Received: by 10.50.30.226 with SMTP id v2mr4118847igh.3.1436547527602; Fri, 10 Jul 2015 09:58:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Fri, 10 Jul 2015 09:58:18 -0700 (PDT) In-Reply-To: <000001d0b908$4d282d60$e7788820$@augustcellars.com> References: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> <009501d0b392$fb7cc680$f2765380$@augustcellars.com> <00d001d0b3b6$ce20f2f0$6a62d8d0$@augustcellars.com> <559392F7.30000@tzi.org> <000001d0b908$4d282d60$e7788820$@augustcellars.com> From: Brian Campbell Date: Fri, 10 Jul 2015 10:58:18 -0600 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=047d7b86d50216189e051a884976 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: Fri, 10 Jul 2015 16:58:50 -0000 --047d7b86d50216189e051a884976 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To dismiss that as argument from antecedent would be to miss the main thrust of what was said. There may well be other reasons (those that you've cited) for lack of use of the JOSE JSON serializations, but some of us anyway have seen significant real world use of compact serializations of JOSE and have not encountered the need for the additional features offered by the JSON serializations. I'm starting to fell as though I'm in the minority here, however, so I'll eventually stop harping about it. I was just looking for the WG to consider the value and success of the simpler side of JOSE. On Tue, Jul 7, 2015 at 4:57 PM, Jim Schaad wrote: > One needs to be careful with arguing from antecedent. Beware of black > swans. > > > > I can think of a number of reasons why JOSE is not used. The fact that > everything is base64 encoded and that detached content are not > enthusiastically supported are high among these. > > > > I know that MILE glanced at using JOSE since they were thinking of moving > to JSON, but the form did not match how they were currently setup, and th= e > base64 of all content was a problem. > > > > I expect that the world of compact devices are going to want to do > something along the lines of RFC 4108 which does firmware update packages > in CMS. This is likely to want multiple signatures and lots of binary > content. Moving to JOSE is a problem on the second account and so would = be > unlikely to show up on anybody=E2=80=99s radar. > > > > My opinion is that if people really care about having a =E2=80=9Cspeciali= zed=E2=80=9D > single recipient version, then by far the best course is to go back to > using arrays at the top level and do the unrolling approach. This is the > smallest message size and yet is still a simple way to decode things. If > we keep maps at the top level, I see no benefits of trying to have a sing= le > recipient version at the savings of a single byte in the message and > additional complications. One can keep that extra message byte and say = =E2=80=93 > only process the first recipient structure even if there are more than on= e. > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Wednesday, July 01, 2015 1:40 PM > *To:* Carsten Bormann > *Cc:* Jim Schaad; cose@ietf.org > *Subject:* Re: [Cose] Issue: Encoding for a single recipient or structure > > > > In my own experience with JOSE, the need for single recipient case is > overwhelming majority and the simplicity the compact serialization afford= ed > for that case are a major win. My own implementation supports only the > compact serializations (and thus only a single recipient or signature) an= d > it is used widely in my employer's products and services as well as being > open source. No one has ever even asked about the JSON serializations > (which support multiple signatures/recipients). > > I understand the allure of consistently treating something that could hav= e > more than one thing as always potentially having more than one. > > But there is real value in making the most common cases simple, which > shouldn't be discounted. > > > > > > On Wed, Jul 1, 2015 at 1:12 AM, Carsten Bormann wrote: > > Jim Schaad wrote: > > If one believes that it is only for use in constrained environments, > > then it is unlikely that there is a need for multiple recipients. > > Actually, we do have scenarios with fan-out (both via proxy and per > multicast), and those are actually a strong motivator for object security= . > > The minimal-bytes alternative is to mix in the map entries for a single > recipient with those for the headers etc. Both JSON and CBOR do not > have a defined sequence of map entries, so this means the recipient has > to piece the info together as it comes in. We'd also need a separate > set of labels. Not my favorite. > > If we keep together that map, what we could still do is turn > > ? recipients =3D> [+{COSE_encrypt_fields}] > > back (we had something like that earlier) into > > ? recipients =3D> [+{COSE_encrypt_fields}] / {COSE_encrypt_fields} > > Saves that 0x81 byte in the single-receiver case. > > Gr=C3=BC=C3=9Fe, Carsten > > > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > > --047d7b86d50216189e051a884976 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a113fc47c656549051a8c98ce-- From nobody Fri Jul 10 15:33: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 3C7761A0062 for ; Fri, 10 Jul 2015 15:33: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 OQqXPYdGikQS for ; Fri, 10 Jul 2015 15:33:21 -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 2C2F81A009B for ; Fri, 10 Jul 2015 15:33:11 -0700 (PDT) Received: from hebrews (174-21-18-91.tukw.qwest.net [174.21.18.91]) (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 F118138EF2; Fri, 10 Jul 2015 15:33:09 -0700 (PDT) From: "Jim Schaad" To: "'Brian Campbell'" References: <559576A9.9090002@gmx.net> <001001d0b90c$3c874af0$b595e0d0$@augustcellars.com> <00c501d0b9a5$c8f869d0$5ae93d70$@augustcellars.com> <20150710171118.GA20991@LK-Perkele-VII> <00b601d0bb3d$37fe0d60$a7fa2820$@augustcellars.com> In-Reply-To: Date: Fri, 10 Jul 2015 15:33:27 -0700 Message-ID: <002201d0bb60$71d6a010$5583e030$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01D0BB25.C57927A0" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQGMo9E7lz5K1VbQVek9kTd0WZ5EKwIS9FwIAQ3LxPQB/WXDmAHiZZGnAshjO7UB4sdSXwJU7d8kAjX17XgCSHbyJZ3JgJVQ Archived-At: Cc: 'Ilari Liusvaara' , cose@ietf.org Subject: Re: [Cose] Key management for MACs (was Re: 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: Fri, 10 Jul 2015 22:33:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0023_01D0BB25.C57927A0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 Sent: Friday, July 10, 2015 3:07 PM To: Jim Schaad Cc: Ilari Liusvaara; cose@ietf.org Subject: Re: [Cose] Key management for MACs (was Re: Review of = draft-schaad-cose-msg-01) =20 And my question was about ephemeral-static DH and RSA-OAEP (both of = which are used in the MAC example at = https://cose-wg.github.io/cose-spec/#rfc.appendix.C.1.4) . Without the = statement of origin, I don't see what value there is? It would be static-static DH not ES DH. Otherwise =E2=80=93 yes it is = the same as RSA =20 On Fri, Jul 10, 2015 at 12:21 PM, Jim Schaad > wrote: > -----Original Message----- > From: Ilari Liusvaara [mailto:ilari.liusvaara@elisanet.fi = ] > Sent: Friday, July 10, 2015 10:11 AM > To: Derek Atkins > Cc: Brian Campbell; Jim Schaad; Mike Jones; cose@ietf.org = =20 > Subject: Re: [Cose] Key management for MACs (was Re: Review of draft- > schaad-cose-msg-01) > > On Fri, Jul 10, 2015 at 09:28:24AM -0400, Derek Atkins wrote: > > > > Performing a MAC using the output of a DH (be it ECDH, AEDH, or raw > > DH) can still tell you that the transmission has not been modified > > between you and the party you're talking to. You're right that it > > tells you nothing about the party you're talking to (i.e., without > > authentication of the DH keys you have no idea if you're talking to = a > > MITM or the real endpoint). However, using DH + MAC does tell you > > that you're not being spoofed by a "passive" eavesdropper. > > > > So IMHO it does have some benefit. > > It occurs to me that any sort of asymmetric key management with MACs = is > unsafe, since knowing just public key enables message forgery. We are going to need to have a consistent definition of message forgery = for this to be a true statement. Can one have a forgery from an = anonymous person? If you don't make a statement about who is sending = the message, which may not be done in this case, then I have a problem = with saying something is a forgery. To have origination, one needs to use static-static DH. Without this = one does not have statement of origin. > > This does not straightforwardly extend to symmetric schems (like key > wrapping), but are those useful with MACs? Depends to a large extent on what you are doing for key roll over of = your shared secrets. If you don't do it very often, then as I stated = in my last message it can improve security as some attacks can be easier = to detect. jim > > > -Ilari _______________________________________________ Cose mailing list Cose@ietf.org =20 https://www.ietf.org/mailman/listinfo/cose =20 ------=_NextPart_000_0023_01D0BB25.C57927A0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

 

From:<= /b> = Brian Campbell [mailto:bcampbell@pingidentity.com]
Sent: = Friday, July 10, 2015 3:07 PM
To: Jim Schaad
Cc: = Ilari Liusvaara; cose@ietf.org
Subject: Re: [Cose] Key = management for MACs (was Re: Review of = draft-schaad-cose-msg-01)

 

And my question was about = ephemeral-static DH and RSA-OAEP (both of which are used in the MAC = example at https://= cose-wg.github.io/cose-spec/#rfc.appendix.C.1.4) . Without the = statement of origin, I don't see what value there = is?

It would be static-static DH not ES DH.=C2=A0 Otherwise =E2=80=93 yes = it is the same as RSA

 

On Fri, = Jul 10, 2015 at 12:21 PM, Jim Schaad <ietf@augustcellars.com> = wrote:



> -----Original Message-----
> From: = Ilari Liusvaara [mailto:ilari.liusvaara@elisanet.fi]
> Sent: Friday, July 10, 2015 10:11 AM
> To: Derek = Atkins
> Cc: Brian Campbell; Jim Schaad; Mike Jones; cose@ietf.org
> Subject: Re: = [Cose] Key management for MACs (was Re: Review of draft-
> = schaad-cose-msg-01)
>
> On Fri, Jul 10, 2015 at 09:28:24AM = -0400, Derek Atkins wrote:
> >
> > Performing a MAC = using the output of a DH (be it ECDH, AEDH, or raw
> > DH) can = still tell you that the transmission has not been modified
> > = between you and the party you're talking to.  You're right that = it
> > tells you nothing about the party you're talking to = (i.e., without
> > authentication of the DH keys you have no = idea if you're talking to a
> > MITM or the real = endpoint).  However, using DH + MAC does tell you
> > that = you're not being spoofed by a "passive" eavesdropper.
> = >
> > So IMHO it does have some benefit.
>
> It = occurs to me that any sort of asymmetric key management with MACs = is
> unsafe, since knowing just public key enables message = forgery.

We are going to need to have a consistent definition of = message forgery for this to be a true statement.  Can one have a = forgery from an anonymous person?  If you don't make a statement = about who is sending the message, which may not be done in this case, = then I have a problem with saying something is a forgery.

To have = origination, one needs to use static-static DH.  Without this one = does not have statement of origin.

>
> This does not = straightforwardly extend to symmetric schems (like key
> = wrapping), but are those useful with MACs?

Depends to a large = extent on what you are doing for key roll over of your shared = secrets.   If you don't do it very often, then as I stated in = my last message it can improve security as some attacks can be easier to = detect.

jim

>
>
> = -Ilari


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

 

------=_NextPart_000_0023_01D0BB25.C57927A0-- From nobody Fri Jul 10 15:34: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 857D41A00B4 for ; Fri, 10 Jul 2015 15:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 1eWavDoKvv-l for ; Fri, 10 Jul 2015 15:34:35 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 970191A009E for ; Fri, 10 Jul 2015 15:34:35 -0700 (PDT) Received: by igcqs7 with SMTP id qs7so22622745igc.0 for ; Fri, 10 Jul 2015 15:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IGK6kppwBA4sV373sDqklVb5PWYqn9jO4nR30om6bY0=; b=B3nKJPnCQhLOe6gQPiGZsG/HwWLsiHrZNNrQ5Uk1tRrzDWiCiW3prQbNbSs5wEa5n6 cxF4SribPlnihLsxomod2qoSZWNz+cHixp9Ry9oLurCDR1KncgfRxIqixGikfmx6GxSJ KWgbLzo+GWwODtVgCe/KaCM5ffwQPbatwdyhU= 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=IGK6kppwBA4sV373sDqklVb5PWYqn9jO4nR30om6bY0=; b=bd1UnBLNEgyaYh3v760WFvtmSpq7/6YwMxD+WBmtKTnusqhXfSONLZXy2Ew0kaCnLF x2Bb+gVOv34Mil6Iu1xSZk1yuU78ZHIUDB2j/HepLhd4rUdN1B8xsMN+pPsl6hN+GAqx HtSxZ2LIltftW3Hn6fG4dISSaEQ0bXvtA7WJW4hMqSr+knT8bBfb9dOU1FcMUASksy61 C0CTykn/1DuDyyLTFEKCk01+TqdihrOzEZyHGEwsvwXUH5GKd1v82kw+XM3VXLOQ4Ih3 NRI5DA67leAjdOgoREHTJrhmgLdgrtjxKq0PMwiYtp/wgdy3KwEolJnq0SEuMXFrcmjD +//A== X-Gm-Message-State: ALoCoQlfeb85nqFUqV05TdJv0iML3RYDuAwLbk/H4MaUMIAEjc5KVL3I3GLUbq60y/jx4yg4LQ6W X-Received: by 10.50.30.226 with SMTP id v2mr1017471igh.3.1436567674968; Fri, 10 Jul 2015 15:34:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Fri, 10 Jul 2015 15:34:05 -0700 (PDT) In-Reply-To: <001401d0bb5f$a98fdf90$fcaf9eb0$@augustcellars.com> References: <559576A9.9090002@gmx.net> <001001d0b90c$3c874af0$b595e0d0$@augustcellars.com> <00c501d0b9a5$c8f869d0$5ae93d70$@augustcellars.com> <000f01d0baad$8a781b20$9f685160$@augustcellars.com> <001401d0bb5f$a98fdf90$fcaf9eb0$@augustcellars.com> From: Brian Campbell Date: Fri, 10 Jul 2015 16:34:05 -0600 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=047d7b86d502f67ece051a8cf91c Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] Key management for MACs (was Re: 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: Fri, 10 Jul 2015 22:34:36 -0000 --047d7b86d502f67ece051a8cf91c Content-Type: text/plain; charset=UTF-8 Really, there's no overhead from the key management part? > I've admittedly not done the comparison but the message size overhead > seems like it'd be similar with something like ECDSA (admittedly not RSA). > > > > ECDSA = 2 * SHA-256 or 32 bytes > > Truncated AES-CMAC is 8 bytes (64 bits) > > > --047d7b86d502f67ece051a8cf91c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Really, there's no overhead from the key management pa= rt?

=C2=A0

I've admittedly not done the comparis= on but the message size overhead seems like it'd be similar with someth= ing like ECDSA (admittedly not RSA).

=C2=A0

ECDSA =3D 2 * SHA-256 or 32 bytes

Truncated AES-CMAC is 8 bytes (64 bits)

=C2=A0

--047d7b86d502f67ece051a8cf91c-- From nobody Fri Jul 10 15:37: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 7D23D1A0130 for ; Fri, 10 Jul 2015 15:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 eBfpwr4rrYZv for ; Fri, 10 Jul 2015 15:37:25 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51C981A00B4 for ; Fri, 10 Jul 2015 15:37:25 -0700 (PDT) Received: by ietj16 with SMTP id j16so32006624iet.0 for ; Fri, 10 Jul 2015 15:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5TQXcqrkJT3a7GN+rBhh/fczCV8raoQDwxIiOzRJPD4=; b=fZSmzmuybPa+o02h2syFi9QK1tKjWrxIK9R8Pj9dNFbVnvtRKdYzrA8C9Yh4ppjR9h YwWIrGWah5fSOS7QWBGPZg3a+JtJfneQJSJxZ8QK1onVEBZO0tJcDLdvkkUfk8pSfWaY j0zJ0fQHlkshxgXbr3RKuyN3njMwsOokFXqpk= 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=5TQXcqrkJT3a7GN+rBhh/fczCV8raoQDwxIiOzRJPD4=; b=hpADlIyRvH9Nfw6Uv7kF883QH5JMlXzIS7E2yITLiVQAcwtq3jRi5pIjYI2y3BnXk7 Tdc6OYVUQ4F1MNithcQNTow6aaEATRLlkCB/09CDhn32Y2Tz+vmzsvmLwrSTpT9pcITa vaDBFwHIOc1qUz2EkDBSS6gJKHCj1H95DNdh7+rfHWhflLhBIdrRmdKt1AMs+5gIcaNT yvDFu967urdiaHTmjjzEkc/pSdUAmvMbWqOOfdaqMRHz+iI/8oJKH81daZKD54EaG1gL 263yVRGeLK7vl5BtWKPvcYFIplLFfNicK57T5iSwSA4P/0QvfTsm9yM9ljrdX+vvnebh as8Q== X-Gm-Message-State: ALoCoQkwvpioE3aXeERD7kTo/IVsWnTktuoI2DoW0CujyeI9/HTY/SU/3NkM/sdCXnXRfp1NmPdT X-Received: by 10.50.13.34 with SMTP id e2mr1073439igc.23.1436567843282; Fri, 10 Jul 2015 15:37:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Fri, 10 Jul 2015 15:36:53 -0700 (PDT) In-Reply-To: <002201d0bb60$71d6a010$5583e030$@augustcellars.com> References: <559576A9.9090002@gmx.net> <001001d0b90c$3c874af0$b595e0d0$@augustcellars.com> <00c501d0b9a5$c8f869d0$5ae93d70$@augustcellars.com> <20150710171118.GA20991@LK-Perkele-VII> <00b601d0bb3d$37fe0d60$a7fa2820$@augustcellars.com> <002201d0bb60$71d6a010$5583e030$@augustcellars.com> From: Brian Campbell Date: Fri, 10 Jul 2015 16:36:53 -0600 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=089e01182d041072b3051a8d047a Archived-At: Cc: Ilari Liusvaara , cose@ietf.org Subject: Re: [Cose] Key management for MACs (was Re: 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: Fri, 10 Jul 2015 22:37:26 -0000 --089e01182d041072b3051a8d047a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 10, 2015 at 4:33 PM, Jim Schaad wrote: > > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Friday, July 10, 2015 3:07 PM > *To:* Jim Schaad > *Cc:* Ilari Liusvaara; cose@ietf.org > *Subject:* Re: [Cose] Key management for MACs (was Re: Review of > draft-schaad-cose-msg-01) > > > > And my question was about ephemeral-static DH and RSA-OAEP (both of which > are used in the MAC example at > https://cose-wg.github.io/cose-spec/#rfc.appendix.C.1.4) . Without the > statement of origin, I don't see what value there is? > > It would be static-static DH not ES DH. Otherwise =E2=80=93 yes it is th= e same as > RSA > So back to what I was originally saying - that RSA and the same as RSA are the key management modes that I'm suggesting not be used for MAC. --089e01182d041072b3051a8d047a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 10, 2015 at 4:33 PM, Jim Schaad <ietf@augustcellars.c= om> wrote:

=C2=A0

=C2=A0

From: Brian Campbell [mailto:bcampbell@pingidentity.com]
Sent= : Friday, July 10, 2015 3:07 PM
To: Jim Schaad
Cc: = Ilari Liusvaara; cose@ie= tf.org
Subject: Re: [Cose] Key management fo= r MACs (was Re: Review of draft-schaad-cose-msg-01)

=C2=A0


So back to= what I was originally saying - that RSA and the same as RSA are the key ma= nagement modes that I'm suggesting not be used for MAC.

--089e01182d041072b3051a8d047a-- From nobody Fri Jul 10 16:08: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 66DC61A034C for ; Fri, 10 Jul 2015 16:08:05 -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 GsVChoP5lVYh for ; Fri, 10 Jul 2015 16:08:03 -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 6E7041A035F for ; Fri, 10 Jul 2015 16:07:52 -0700 (PDT) Received: from hebrews (174-21-18-91.tukw.qwest.net [174.21.18.91]) (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 99AFA38F3F; Fri, 10 Jul 2015 16:07:51 -0700 (PDT) From: "Jim Schaad" To: "'Brian Campbell'" References: <559576A9.9090002@gmx.net> <001001d0b90c$3c874af0$b595e0d0$@augustcellars.com> <00c501d0b9a5$c8f869d0$5ae93d70$@augustcellars.com> <000f01d0baad$8a781b20$9f685160$@augustcellars.com> <001401d0bb5f$a98fdf90$fcaf9eb0$@augustcellars.com> In-Reply-To: Date: Fri, 10 Jul 2015 16:08:10 -0700 Message-ID: <003001d0bb65$4a55c390$df014ab0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01D0BB2A.9DF89940" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQGMo9E7lz5K1VbQVek9kTd0WZ5EKwIS9FwIAQ3LxPQB/WXDmAHiZZGnAshjO7UBc0IGzgHgFhm5AhFvASIB8EROkp3UkcDA Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] Key management for MACs (was Re: 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: Fri, 10 Jul 2015 23:08:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0031_01D0BB2A.9DF89940 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The overhead on key management is going to be based a lot on what you = are doing. =20 If you are doing direct shared secret =E2=80=93then you have a kid If you are doing ECDH-SS =E2=80=93 then you need two kids and a nonce = (which can be very short) If you are doing ECDSA =E2=80=93 then you need a kid =20 This means that to be the same size you have 24 bytes to express a = second kid (which could be implicit) and a nonce (which can be a short = as 2 or 3 bytes). I don=E2=80=99t think you need that much space = =E2=80=93 so yes, it would be smaller. =20 =20 The overhead from the basic messages (MAC vs Sign) is going to be about = the same in both cases. =20 From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 Sent: Friday, July 10, 2015 3:34 PM To: Jim Schaad Cc: cose@ietf.org Subject: Re: [Cose] Key management for MACs (was Re: Review of = draft-schaad-cose-msg-01) =20 Really, there's no overhead from the key management part? =20 =20 I've admittedly not done the comparison but the message size overhead = seems like it'd be similar with something like ECDSA (admittedly not = RSA). =20 ECDSA =3D 2 * SHA-256 or 32 bytes Truncated AES-CMAC is 8 bytes (64 bits) =20 ------=_NextPart_000_0031_01D0BB2A.9DF89940 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The overhead on key management is going to be based a lot on what you = are doing.

 

If you are doing direct shared secret =E2=80=93then you have a = kid

If you are doing ECDH-SS =E2=80=93 then you need two kids and a nonce = (which can be very short)

If you are doing ECDSA =E2=80=93 then you need a = kid

 

This means that to be the same size you have 24 bytes to express a = second kid (which could be implicit) and a nonce (which can be a short = as 2 or 3 bytes).=C2=A0 I don=E2=80=99t think you need that much space = =E2=80=93 so yes, it would be smaller.=C2=A0

 

The overhead from the basic messages (MAC vs Sign) is going to be about = the same in both cases.

 

From:<= /b> = Brian Campbell [mailto:bcampbell@pingidentity.com]
Sent: = Friday, July 10, 2015 3:34 PM
To: Jim Schaad
Cc: = cose@ietf.org
Subject: Re: [Cose] Key management for MACs (was = Re: Review of = draft-schaad-cose-msg-01)

 

Really, = there's no overhead from the key management = part?

 

 <= /o:p>

I've = admittedly not done the comparison but the message size overhead seems = like it'd be similar with something like ECDSA (admittedly not = RSA).

 

ECDSA =3D 2 * SHA-256 or 32 bytes

Truncated AES-CMAC is 8 bytes (64 bits)

 <= /o:p>

------=_NextPart_000_0031_01D0BB2A.9DF89940-- From nobody Fri Jul 10 16:11:47 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 E255B1A036B for ; Fri, 10 Jul 2015 16:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 9rYdX3Qr96JN for ; Fri, 10 Jul 2015 16:11:43 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0111.outbound.protection.outlook.com [65.55.169.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05EA71A036A for ; Fri, 10 Jul 2015 16:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9dS69CSlWBMrnQouOtDSAAzpDmkzRwXqKG3VubpVuvo=; b=hHuixU1fYW+VVWWX9ak2555xxdg7IdEldenIETSH7WsDaSGqhY/qt1V9v0qXrXWoSGrUGGkOnvB0K7kbaIYRuaNjheR9xLvVZd6yapMyR9Il2J/f9CgfrEeYPOfbPESNzApQoaDEy8VtRvzUuSPmjPmYxqwHGCXoTGYGD/Io24g= 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.213.10; Fri, 10 Jul 2015 23:11: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.0213.000; Fri, 10 Jul 2015 23:11:40 +0000 From: Mike Jones To: Jim Schaad , 'Brian Campbell' Thread-Topic: [Cose] Key management for MACs (was Re: Review of draft-schaad-cose-msg-01) Thread-Index: AQHQtO7otSq2x1sR40SvzKRDC45tbp3IdCkggAg6cYCAATMYgIAB5ByAgAArZoCAAVtFAIAACPoAgAABvYCAAAmGAIAAACHA Date: Fri, 10 Jul 2015 23:11:39 +0000 Message-ID: References: <559576A9.9090002@gmx.net> <001001d0b90c$3c874af0$b595e0d0$@augustcellars.com> <00c501d0b9a5$c8f869d0$5ae93d70$@augustcellars.com> <000f01d0baad$8a781b20$9f685160$@augustcellars.com> <001401d0bb5f$a98fdf90$fcaf9eb0$@augustcellars.com> <003001d0bb65$4a55c390$df014ab0$@augustcellars.com> In-Reply-To: <003001d0bb65$4a55c390$df014ab0$@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:ed31::2] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:vSVWhI52UZ8RNJc5RouuF3oa3JsCDxQOoac9jiEuThoxwaaxDmgKXnA3IjD0ojr3rZhzsHjilrvN08j30n7BhI1tqAHm8DYND5WH1FGRUCnXcES1GJRFbDmmvTrPNY8HNFqXTEGWITCSL8Zid2yYJQ==; 24:1Orm2XzSCs7H/BW3fqRamNa0egU9AHVf21qMp8/mNoPZCZFevfWKIbzYe5SzbgihHtK+qn14VJq0+AFNiGxBysBGkNWixjzvsEa6meUl6oo=; 20:4dQYUZQsgNNQhyc2YBdCAd4NrGsodEr7wsNrGRQOz0z7B1g8FnBzaac4gkcKFVb0QzZ7ar3G3lnACfklVK3d8Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; by2pr03mb442: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); 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: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(5002640100001)(46102003)(77156002)(33656002)(76576001)(77096005)(122556002)(15975445007)(102836002)(74316001)(62966003)(92566002)(99286002)(5001770100001)(93886004)(106116001)(76176999)(230783001)(2656002)(86612001)(189998001)(2950100001)(16236675004)(19580395003)(19580405001)(87936001)(2900100001)(5003600100002)(86362001)(19625215002)(40100003)(50986999)(54356999)(19300405004)(5001960100002)(3826002); 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_BY2PR03MB442B5A56792D5543C067232F59F0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2015 23:11:39.9186 (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: "cose@ietf.org" Subject: Re: [Cose] Key management for MACs (was Re: 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: Fri, 10 Jul 2015 23:11:46 -0000 --_000_BY2PR03MB442B5A56792D5543C067232F59F0BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGVyIG15IGlzc3VlIDIsIEkgYmVsaWV2ZSB0aGF0IHRoZSBkZWZhdWx0IGtleSBtYW5hZ2VtZW50 IG1vZGUgc2hvdWxkIGJlIOKAnG5vIGtleSBtYW5hZ2VtZW504oCdIOKAkyB3aGF0IHdlIGNhbGxl ZCDigJxkaXJlY3TigJ0gaW4gSk9TRS4gIElmIGRldmVsb3BlcnMgd2FudCB0byBhbHNvIGFkZCBp dCBpbiwgbW9yZSBwb3dlciB0byB0aGVtLg0KDQpZZXMsIGtleSByb3RhdGlvbiB3aWxsIGhhdmUg dG8gb2NjYXNpb25hbGx5IGJlIGRvbmUgdG8gbWFrZSB0aGlzIHNhZmUuICBUaGF04oCZcyBhbHdh eXMgYmVlbiBhIGdpdmVuLiAgKEFuZCB5ZXMsIHRoYXTigJlzIHBhcnQgb2YgdGhlIG1lYW5pbmcg b2Yg4oCca2V5IG1hbmFnZW1lbnTigJ0gdGhhdCBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgd29y a2luZyBncm91cCwgYnV0IGlzIGNsZWFybHkgbmVjZXNzYXJ5IGZvciBhbnkgc2VjdXJlIGFwcGxp Y2F0aW9uLikNCg0KVGhlIG92ZXJoZWFkIHlvdeKAmXJlIG5vdCB0YWxraW5nIGFib3V0IGJlbG93 IEppbSBpcyB0aGUgY29tcHV0YXRpb24gdGltZSBhbmQgcG93ZXIgb3ZlcmhlYWQgb2YgZ2VuZXJh dGluZyB0aGUgZXBoZW1lcmFsIGtleSBhbmQgZW5jcnlwdGluZyBpdC4gIElmIHRoaXMgaXNu4oCZ dCBhYnNvbHV0ZWx5IG5lY2Vzc2FyeSwgaXTigJlzIGJldHRlciB0byBub3QgZG8gaXQuICBKT1NF IHNlZW1zIHRvIGJlIHdvcmtpbmcgZmluZSB3aXRob3V0IHRoaXMgZXZlbiBiZWluZyBhbiBvcHRp b27igKYNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogQ29zZSBbbWFpbHRvOmNvc2UtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEppbSBTY2hhYWQNClNlbnQ6IEZyaWRheSwgSnVseSAx MCwgMjAxNSA0OjA4IFBNDQpUbzogJ0JyaWFuIENhbXBiZWxsJw0KQ2M6IGNvc2VAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbQ29zZV0gS2V5IG1hbmFnZW1lbnQgZm9yIE1BQ3MgKHdhcyBSZTogUmV2 aWV3IG9mIGRyYWZ0LXNjaGFhZC1jb3NlLW1zZy0wMSkNCg0KVGhlIG92ZXJoZWFkIG9uIGtleSBt YW5hZ2VtZW50IGlzIGdvaW5nIHRvIGJlIGJhc2VkIGEgbG90IG9uIHdoYXQgeW91IGFyZSBkb2lu Zy4NCg0KSWYgeW91IGFyZSBkb2luZyBkaXJlY3Qgc2hhcmVkIHNlY3JldCDigJN0aGVuIHlvdSBo YXZlIGEga2lkDQpJZiB5b3UgYXJlIGRvaW5nIEVDREgtU1Mg4oCTIHRoZW4geW91IG5lZWQgdHdv IGtpZHMgYW5kIGEgbm9uY2UgKHdoaWNoIGNhbiBiZSB2ZXJ5IHNob3J0KQ0KSWYgeW91IGFyZSBk b2luZyBFQ0RTQSDigJMgdGhlbiB5b3UgbmVlZCBhIGtpZA0KDQpUaGlzIG1lYW5zIHRoYXQgdG8g YmUgdGhlIHNhbWUgc2l6ZSB5b3UgaGF2ZSAyNCBieXRlcyB0byBleHByZXNzIGEgc2Vjb25kIGtp ZCAod2hpY2ggY291bGQgYmUgaW1wbGljaXQpIGFuZCBhIG5vbmNlICh3aGljaCBjYW4gYmUgYSBz aG9ydCBhcyAyIG9yIDMgYnl0ZXMpLiAgSSBkb27igJl0IHRoaW5rIHlvdSBuZWVkIHRoYXQgbXVj aCBzcGFjZSDigJMgc28geWVzLCBpdCB3b3VsZCBiZSBzbWFsbGVyLg0KDQpUaGUgb3ZlcmhlYWQg ZnJvbSB0aGUgYmFzaWMgbWVzc2FnZXMgKE1BQyB2cyBTaWduKSBpcyBnb2luZyB0byBiZSBhYm91 dCB0aGUgc2FtZSBpbiBib3RoIGNhc2VzLg0KDQpGcm9tOiBCcmlhbiBDYW1wYmVsbCBbbWFpbHRv OmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tXQ0KU2VudDogRnJpZGF5LCBKdWx5IDEwLCAyMDE1 IDM6MzQgUE0NClRvOiBKaW0gU2NoYWFkDQpDYzogY29zZUBpZXRmLm9yZzxtYWlsdG86Y29zZUBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQ29zZV0gS2V5IG1hbmFnZW1lbnQgZm9yIE1BQ3MgKHdh cyBSZTogUmV2aWV3IG9mIGRyYWZ0LXNjaGFhZC1jb3NlLW1zZy0wMSkNCg0KUmVhbGx5LCB0aGVy ZSdzIG5vIG92ZXJoZWFkIGZyb20gdGhlIGtleSBtYW5hZ2VtZW50IHBhcnQ/DQoNCg0KSSd2ZSBh ZG1pdHRlZGx5IG5vdCBkb25lIHRoZSBjb21wYXJpc29uIGJ1dCB0aGUgbWVzc2FnZSBzaXplIG92 ZXJoZWFkIHNlZW1zIGxpa2UgaXQnZCBiZSBzaW1pbGFyIHdpdGggc29tZXRoaW5nIGxpa2UgRUNE U0EgKGFkbWl0dGVkbHkgbm90IFJTQSkuDQoNCkVDRFNBID0gMiAqIFNIQS0yNTYgb3IgMzIgYnl0 ZXMNClRydW5jYXRlZCBBRVMtQ01BQyBpcyA4IGJ5dGVzICg2NCBiaXRzKQ0KDQo= --_000_BY2PR03MB442B5A56792D5543C067232F59F0BY2PR03MB442namprd_ 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 IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1 NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNv QWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNw YW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQi Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRG NzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QZXIgbXkgaXNzdWUgMiwg SSBiZWxpZXZlIHRoYXQgdGhlIGRlZmF1bHQga2V5IG1hbmFnZW1lbnQgbW9kZSBzaG91bGQgYmUg 4oCcbm8ga2V5IG1hbmFnZW1lbnTigJ0g4oCTIHdoYXQgd2UgY2FsbGVkIOKAnGRpcmVjdOKAnSBp biBKT1NFLiZuYnNwOyBJZiBkZXZlbG9wZXJzIHdhbnQgdG8gYWxzbw0KIGFkZCBpdCBpbiwgbW9y ZSBwb3dlciB0byB0aGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WWVzLCBrZXkgcm90YXRpb24gd2lsbCBoYXZlIHRv IG9jY2FzaW9uYWxseSBiZSBkb25lIHRvIG1ha2UgdGhpcyBzYWZlLiZuYnNwOyBUaGF04oCZcyBh bHdheXMgYmVlbiBhIGdpdmVuLiZuYnNwOyAoQW5kIHllcywgdGhhdOKAmXMgcGFydCBvZiB0aGUg bWVhbmluZyBvZiDigJxrZXkgbWFuYWdlbWVudOKAnQ0KIHRoYXQgaXMgb3V0IG9mIHNjb3BlIGZv ciB0aGlzIHdvcmtpbmcgZ3JvdXAsIGJ1dCBpcyBjbGVhcmx5IG5lY2Vzc2FyeSBmb3IgYW55IHNl Y3VyZSBhcHBsaWNhdGlvbi4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgb3ZlcmhlYWQgeW914oCZcmUgbm90IHRh bGtpbmcgYWJvdXQgYmVsb3cgSmltIGlzIHRoZSBjb21wdXRhdGlvbiB0aW1lIGFuZCBwb3dlciBv dmVyaGVhZCBvZiBnZW5lcmF0aW5nIHRoZSBlcGhlbWVyYWwga2V5IGFuZCBlbmNyeXB0aW5nIGl0 LiZuYnNwOyBJZiB0aGlzIGlzbuKAmXQNCiBhYnNvbHV0ZWx5IG5lY2Vzc2FyeSwgaXTigJlzIGJl dHRlciB0byBub3QgZG8gaXQuJm5ic3A7IEpPU0Ugc2VlbXMgdG8gYmUgd29ya2luZyBmaW5lIHdp dGhvdXQgdGhpcyBldmVuIGJlaW5nIGFuIG9wdGlvbuKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBDb3Nl IFttYWlsdG86Y29zZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KaW0g U2NoYWFkPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSnVseSAxMCwgMjAxNSA0OjA4IFBNPGJy Pg0KPGI+VG86PC9iPiAnQnJpYW4gQ2FtcGJlbGwnPGJyPg0KPGI+Q2M6PC9iPiBjb3NlQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQ29zZV0gS2V5IG1hbmFnZW1lbnQgZm9yIE1B Q3MgKHdhcyBSZTogUmV2aWV3IG9mIGRyYWZ0LXNjaGFhZC1jb3NlLW1zZy0wMSk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIG92ZXJoZWFkIG9uIGtleSBtYW5hZ2VtZW50IGlz IGdvaW5nIHRvIGJlIGJhc2VkIGEgbG90IG9uIHdoYXQgeW91IGFyZSBkb2luZy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PklmIHlvdSBhcmUgZG9pbmcgZGlyZWN0IHNoYXJlZCBzZWNyZXQg4oCTdGhlbiB5b3UgaGF2ZSBh IGtpZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiB5b3UgYXJlIGRvaW5nIEVDREgt U1Mg4oCTIHRoZW4geW91IG5lZWQgdHdvIGtpZHMgYW5kIGEgbm9uY2UgKHdoaWNoIGNhbiBiZSB2 ZXJ5IHNob3J0KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiB5b3UgYXJlIGRvaW5n IEVDRFNBIOKAkyB0aGVuIHlvdSBuZWVkIGEga2lkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIG1lYW5zIHRoYXQg dG8gYmUgdGhlIHNhbWUgc2l6ZSB5b3UgaGF2ZSAyNCBieXRlcyB0byBleHByZXNzIGEgc2Vjb25k IGtpZCAod2hpY2ggY291bGQgYmUgaW1wbGljaXQpIGFuZCBhIG5vbmNlICh3aGljaCBjYW4gYmUg YSBzaG9ydCBhcyAyIG9yIDMgYnl0ZXMpLiZuYnNwOw0KIEkgZG9u4oCZdCB0aGluayB5b3UgbmVl ZCB0aGF0IG11Y2ggc3BhY2Ug4oCTIHNvIHllcywgaXQgd291bGQgYmUgc21hbGxlci4mbmJzcDsg PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5UaGUgb3ZlcmhlYWQgZnJvbSB0aGUgYmFzaWMgbWVzc2FnZXMgKE1BQyB2cyBT aWduKSBpcyBnb2luZyB0byBiZSBhYm91dCB0aGUgc2FtZSBpbiBib3RoIGNhc2VzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEJyaWFuIENhbXBiZWxsIFs8 YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iPm1haWx0bzpiY2FtcGJl bGxAcGluZ2lkZW50aXR5LmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdWx5 IDEwLCAyMDE1IDM6MzQgUE08YnI+DQo8Yj5Ubzo8L2I+IEppbSBTY2hhYWQ8YnI+DQo8Yj5DYzo8 L2I+IDxhIGhyZWY9Im1haWx0bzpjb3NlQGlldGYub3JnIj5jb3NlQGlldGYub3JnPC9hPjxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW0Nvc2VdIEtleSBtYW5hZ2VtZW50IGZvciBNQUNzICh3YXMg UmU6IFJldmlldyBvZiBkcmFmdC1zY2hhYWQtY29zZS1tc2ctMDEpPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlYWxseSwgdGhlcmUncyBubyBv dmVyaGVhZCBmcm9tIHRoZSBrZXkgbWFuYWdlbWVudCBwYXJ0PzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5JJ3ZlIGFkbWl0dGVkbHkgbm90IGRvbmUgdGhlIGNvbXBhcmlz b24gYnV0IHRoZSBtZXNzYWdlIHNpemUgb3ZlcmhlYWQgc2VlbXMgbGlrZSBpdCdkIGJlIHNpbWls YXIgd2l0aCBzb21ldGhpbmcgbGlrZSBFQ0RTQSAoYWRtaXR0ZWRseSBub3QgUlNBKS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkVDRFNBID0gMiAqIFNIQS0yNTYgb3IgMzIgYnl0ZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UcnVuY2F0ZWQgQUVTLUNNQUMgaXMgOCBieXRlcyAoNjQgYml0cyk8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BY2PR03MB442B5A56792D5543C067232F59F0BY2PR03MB442namprd_-- From nobody Sat Jul 11 05:10: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 DCF221A92F3 for ; Sat, 11 Jul 2015 05:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 LE5Of-JrbrVc for ; Sat, 11 Jul 2015 05:10:45 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::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 909A51A9096 for ; Sat, 11 Jul 2015 05:10:45 -0700 (PDT) Received: by igpy18 with SMTP id y18so29757507igp.0 for ; Sat, 11 Jul 2015 05:10:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WkBkSG5Ribuzeni5PU+xLlIiBxVGmkVI7xXNZ+c0ZIU=; b=TD6ANNDWYOCb1bO8ks5yV4LdTAnFgRBsMSwwfDajkyZ3RdCzASID1Ukd063bgf2vlB 1nmYKS5icHJxFYKjRLsEN5SzVec5jyeMCZy3m/IyZuvLki3EpPG+r4j/8GtLz0HuPZnE 5Y4B3AfVaLM3N5a/SCACJ0RXygAUHg+0Fjaj8= 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=WkBkSG5Ribuzeni5PU+xLlIiBxVGmkVI7xXNZ+c0ZIU=; b=eNawUS8KZJJfUJO+j1ZX9HO48wIWqSO8y7MfW1axTtu2O0ACs2RlDxAzoE6hyI90SJ dw3MtPVgiqxzO3xN/wkvoa2NMST7bQUSx1W4wDJPTQ94rZXb2EZXjq7eGTKo2FU0Qz2a u6v2F6ZJojNHjqkPEgSflj6Wm3ZtpNBQyzo/OALMtivseZs+hVE7e64xZ+kY7+IxSd/0 yGyS0k9LvyjPej/AO0QDRP5iiIOqqACYMq/z1vJxVUPLEJBHu+F3tv6s/x1I6qPcqeJL oUmf2G9ItQPpekyS20WwmHftiOV6tAksAtfvONVUu+XANdn75sSVaWXGbmVAcbm+7QH1 0g6Q== X-Gm-Message-State: ALoCoQlVO6jeg+rt/RD87WvldfGMSMcg+hdqVh2/uiOxuRmXMCHgwIb2qE/VSAuXsGOsnoMxDr5G X-Received: by 10.50.30.226 with SMTP id v2mr3183137igh.3.1436616644726; Sat, 11 Jul 2015 05:10:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Sat, 11 Jul 2015 05:10:15 -0700 (PDT) In-Reply-To: <003001d0bb65$4a55c390$df014ab0$@augustcellars.com> References: <559576A9.9090002@gmx.net> <001001d0b90c$3c874af0$b595e0d0$@augustcellars.com> <00c501d0b9a5$c8f869d0$5ae93d70$@augustcellars.com> <000f01d0baad$8a781b20$9f685160$@augustcellars.com> <001401d0bb5f$a98fdf90$fcaf9eb0$@augustcellars.com> <003001d0bb65$4a55c390$df014ab0$@augustcellars.com> From: Brian Campbell Date: Sat, 11 Jul 2015 06:10:15 -0600 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=047d7b86d502c9b311051a986028 Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] Key management for MACs (was Re: 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, 11 Jul 2015 12:10:47 -0000 --047d7b86d502c9b311051a986028 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The context around the overhead was signing vs. key agreement - so ECDH-SS + MAC vs. ECDSA. I was presuming that ECDH-SS would need a random MAC key and key wrap it using the agreed key. So the wrapped key was part of the overhead I had in mind when I said I thought they'd be similar. But yeah, okay, a ECDH-SS with a KDF would be smaller. On Fri, Jul 10, 2015 at 5:08 PM, Jim Schaad wrote: > The overhead on key management is going to be based a lot on what you are > doing. > > > > If you are doing direct shared secret =E2=80=93then you have a kid > > If you are doing ECDH-SS =E2=80=93 then you need two kids and a nonce (wh= ich can > be very short) > > If you are doing ECDSA =E2=80=93 then you need a kid > > > > This means that to be the same size you have 24 bytes to express a second > kid (which could be implicit) and a nonce (which can be a short as 2 or 3 > bytes). I don=E2=80=99t think you need that much space =E2=80=93 so yes,= it would be > smaller. > > > > The overhead from the basic messages (MAC vs Sign) is going to be about > the same in both cases. > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Friday, July 10, 2015 3:34 PM > *To:* Jim Schaad > *Cc:* cose@ietf.org > *Subject:* Re: [Cose] Key management for MACs (was Re: Review of > draft-schaad-cose-msg-01) > > > > Really, there's no overhead from the key management part? > > > > > > I've admittedly not done the comparison but the message size overhead > seems like it'd be similar with something like ECDSA (admittedly not RSA)= . > > > > ECDSA =3D 2 * SHA-256 or 32 bytes > > Truncated AES-CMAC is 8 bytes (64 bits) > > > > --047d7b86d502c9b311051a986028 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The context around the overhead was signing vs. key agreem= ent - so ECDH-SS + MAC vs. ECDSA. I was presuming that ECDH-SS would need a= random MAC key and key wrap it using the agreed key.=C2=A0 So the wrapped = key was part of the overhead I had in mind when I said I thought they'd= be similar. But yeah, okay, a=C2=A0 ECDH-SS with a KDF would be smaller.= =C2=A0


= On Fri, Jul 10, 2015 at 5:08 PM, Jim Schaad <ietf@augustcellars.com= > wrote:

The overhead on key management is going to be based a lot on what you = are doing.

=C2=A0

If you a= re doing direct shared secret =E2=80=93then you have a kid

If you are doing ECDH-SS =E2= =80=93 then you need two kids and a nonce (which can be very short)<= u>

If you are doing ECD= SA =E2=80=93 then you need a kid

=C2=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:#1f497d">This means that to be the same size you have 24 bytes to expr= ess a second kid (which could be implicit) and a nonce (which can be a shor= t as 2 or 3 bytes).=C2=A0 I don=E2=80=99t think you need that much space = =E2=80=93 so yes, it would be smaller.=C2=A0

=C2=A0

The overhead from the basic messages (MAC vs Sig= n) is going to be about the same in both cases.

=C2=A0

From: Brian Campbell [ma= ilto:bcampb= ell@pingidentity.com]
Sent: Friday, July 10, 2015 3:34 PM
To: Jim Schaad
Cc: cose@ietf.org
Subject: Re: [Cos= e] Key management for MACs (was Re: Review of draft-schaad-cose-msg-01)<= /u>

=C2= =A0

Really, there's no overhead f= rom the key management part?

<= div>

=C2=A0

= =C2=A0

I've = admittedly not done the comparison but the message size overhead seems like= it'd be similar with something like ECDSA (admittedly not RSA).=

= =C2=A0

ECDSA = =3D 2 * SHA-256 or 32 bytes

= Truncated AES-CMAC is 8 bytes (64 bits)=

=C2=A0

=
--047d7b86d502c9b311051a986028-- From nobody Mon Jul 13 10:36:54 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 69ADB1B2CB8 for ; Mon, 13 Jul 2015 10:36:53 -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 NeRXwrAIlx_i for ; Mon, 13 Jul 2015 10:36:52 -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 CD77F1B2CBA for ; Mon, 13 Jul 2015 10:36:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 46739E2035; Mon, 13 Jul 2015 13:36:49 -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 26566-02; Mon, 13 Jul 2015 13:36:47 -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 49BF9E2034; Mon, 13 Jul 2015 13:36:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1436809007; bh=gSmjAtGAzy47owrDbl6GS92hpTBDS7jeEWJCgk6ygq4=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=fl8IGy4rbcNbG/UpTtmyoOxG2wmcYhB3T2bcJofaLg+MefuvdpkfL8tzNrtoMQK3b sO9qtj4MKX0FIF3X0wfImZHbT80GpT7cmwccy37dqE8pnIzK/EY8BI9ConqmtMwRCH TFZj/RJfRF76hrhU86f0mnvnb5VWZpv4Rckizs24= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t6DHajOZ003076; Mon, 13 Jul 2015 13:36:45 -0400 From: Derek Atkins To: Ilari Liusvaara References: <559576A9.9090002@gmx.net> <001001d0b90c$3c874af0$b595e0d0$@augustcellars.com> <00c501d0b9a5$c8f869d0$5ae93d70$@augustcellars.com> <20150710171118.GA20991@LK-Perkele-VII> Date: Mon, 13 Jul 2015 13:36:45 -0400 In-Reply-To: <20150710171118.GA20991@LK-Perkele-VII> (Ilari Liusvaara's message of "Fri, 10 Jul 2015 20:11:18 +0300") 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 , Brian Campbell , Derek Atkins , Mike Jones , cose@ietf.org Subject: Re: [Cose] Key management for MACs (was Re: 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, 13 Jul 2015 17:36:53 -0000 Ilari Liusvaara writes: > On Fri, Jul 10, 2015 at 09:28:24AM -0400, Derek Atkins wrote: >> >> Performing a MAC using the output of a DH (be it ECDH, AEDH, or raw DH) >> can still tell you that the transmission has not been modified between >> you and the party you're talking to. You're right that it tells you >> nothing about the party you're talking to (i.e., without authentication >> of the DH keys you have no idea if you're talking to a MITM or the real >> endpoint). However, using DH + MAC does tell you that you're not being >> spoofed by a "passive" eavesdropper. >> >> So IMHO it does have some benefit. > > It occurs to me that any sort of asymmetric key management with MACs > is unsafe, since knowing just public key enables message forgery. Pardon? I don't understand that. Just knowing your Public Key does not mean I can send messages that appear to come from you. The key used for the MAC is the derived shared secret, so I would need to know your Private Key as well in order to generate the correct shared secret. At worst I could record and replay the session, assuming the other end also uses a static public/private keypair. Or I could act as an active man-in-the-middle. > This does not straightforwardly extend to symmetric schems (like > key wrapping), but are those useful with MACs? > > > -Ilari -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Jul 13 10:47: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 7B6FB1B2CC3 for ; Mon, 13 Jul 2015 10:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 oavCLJsIAbYT for ; Mon, 13 Jul 2015 10:47:54 -0700 (PDT) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 773381B2CB5 for ; Mon, 13 Jul 2015 10:47:54 -0700 (PDT) Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 1E50069BF9; Mon, 13 Jul 2015 20:47:52 +0300 (EEST) Date: Mon, 13 Jul 2015 20:47:52 +0300 From: Ilari Liusvaara To: Derek Atkins Message-ID: <20150713174752.GA22814@LK-Perkele-VII> References: <559576A9.9090002@gmx.net> <001001d0b90c$3c874af0$b595e0d0$@augustcellars.com> <00c501d0b9a5$c8f869d0$5ae93d70$@augustcellars.com> <20150710171118.GA20991@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: Jim Schaad , Brian Campbell , Mike Jones , cose@ietf.org Subject: Re: [Cose] Key management for MACs (was Re: 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, 13 Jul 2015 17:47:56 -0000 On Mon, Jul 13, 2015 at 01:36:45PM -0400, Derek Atkins wrote: > Ilari Liusvaara writes: > > > > It occurs to me that any sort of asymmetric key management with MACs > > is unsafe, since knowing just public key enables message forgery. > > Pardon? I don't understand that. Just knowing your Public Key does not > mean I can send messages that appear to come from you. The key used for > the MAC is the derived shared secret, so I would need to know your > Private Key as well in order to generate the correct shared secret. Forgot about static-static DH (which might actually be useful, given that it can cut down number of keys asymptotically). There's also MAC keyed by dynamic DH key (one protocol I cooked up a while back did that). But from message perspective, it would be static-static. But many asymmetric crypto primitives are not useful there, given that those allow to agree or transport a known key, rendering the MAC pretty much meaningless. -Ilari From nobody Sun Jul 19 05:20: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 4727B1ACDB6 for ; Sun, 19 Jul 2015 05:20:29 -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 PA-E85usaviS for ; Sun, 19 Jul 2015 05:20:27 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BBC31ACDC7 for ; Sun, 19 Jul 2015 05:20:27 -0700 (PDT) X-AuditID: 1209190e-f79c76d000002631-45-55ab960a86cf 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-3.mit.edu (Symantec Messaging Gateway) with SMTP id 9D.35.09777.A069BA55; Sun, 19 Jul 2015 08:20:26 -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 t6JCKPaC016755 for ; Sun, 19 Jul 2015 08:20:26 -0400 Received: from dhcp-89fd.meeting.ietf.org (dhcp-89fd.meeting.ietf.org [31.133.137.253]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t6JCKNhP020009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 19 Jul 2015 08:20:25 -0400 From: Justin Richer Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <9850F0C0-1BCB-4F22-A925-73A7A6A2B5BF@mit.edu> Date: Sun, 19 Jul 2015 14:20:21 +0200 To: cose@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBIsWRmVeSWpSXmKPExsUixCmqrcs1bXWoQdcfOYtpW6eyOjB6LFny kymAMYrLJiU1J7MstUjfLoEr403LLtaC0xwVm7/1MzUwfmPrYuTkkBAwkdi9eS4LhC0mceHe eqA4F4eQwGImifsXr7ODJIQEjjJKXLvlA5F4wSRxdtYKRpAEm4CqxPQ1LUwgNrOAusSfeZeY IWxtiWULXwPZHBzCAgoS/xeXgIR5BawkVmzdB7aYBaj1x6fzbCAlIgKCEnc7zSFK9CR6zn1h hLhHVmLrm1amCYx8s5AsmIVkwSwkLQsYmVcxyqbkVunmJmbmFKcm6xYnJ+blpRbpGuvlZpbo paaUbmIEB5gk3w7GrweVDjEKcDAq8fBafFkVKsSaWFZcmXuIUZKDSUmU94rz6lAhvqT8lMqM xOKM+KLSnNTiQ4wSHMxKIryBgUA53pTEyqrUonyYlDQHi5I476YffCFCAumJJanZqakFqUUw WRkODiUJ3mlTgBoFi1LTUyvSMnNKENJMHJwgw3mAhj8BqeEtLkjMLc5Mh8ifYlSUEufdDZIQ AElklObB9cISwCtGcaBXhHn3glTxAJMHXPcroMFMQIM7V68AGVySiJCSamAsfbny+roVcu94 ZCa0yW54X6T/VDTggnXdw2XZP4z1uYu6HQpP1bxfdqdDNi+5kXEC35yi3VcNJosVhRmFf33z 4+nV+81h4X0bHR46y7iHClwql963dAvXW97isOOflaR8g1VUXXI/2pcdSOdgPFX5mWPZ841r dwXc5H+zOZKBJUmv9MNSXnklluKMREMt5qLiRADD629p2wIAAA== Archived-At: Subject: [Cose] IETF93 Meeting Reminder 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, 19 Jul 2015 12:20:29 -0000 Hi everyone, and to those currently in Prague, V=C3=ADtejte v =C4=8Cesk=C3= =A9 republice! As a reminder, we=E2=80=99re meeting tomorrow, Monday morning during the = first session in the Berlin/Brussels room. We=E2=80=99re sharing the = room with IPSECME, who are going to start off at 9am. We=E2=80=99ll be = picking up as soon as they wrap. Ostensibly this gives us a starting = time of 10am, but we don=E2=80=99t anticipate that the IPSECME meeting = is going to take the full hour.=20 The upshot of this is that we will more than likely be starting the COSE = meeting at some point before 10am in order to give us the most time. As = such, we=E2=80=99re asking that everyone be there early. I=E2=80=99m = going to be there right around 9am, and I would recommend that COSE = folks come no later than 9:30, if not earlier. Basically, as soon as the = previous WG is done and we=E2=80=99ve had a few minutes to transition = things over, we=E2=80=99re going to get started, whether or not you=E2=80=99= re there. :) See you all bright and early tomorrow, =E2=80=94 Justin= From nobody Mon Jul 20 08:46: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 3890C1A9024; Mon, 20 Jul 2015 08:46:12 -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] 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 ELzQMcpICY-B; Mon, 20 Jul 2015 08:46:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E131A8BC2; Mon, 20 Jul 2015 08:46:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150720154611.11031.96989.idtracker@ietfa.amsl.com> Date: Mon, 20 Jul 2015 08:46:11 -0700 Archived-At: Cc: cose@ietf.org Subject: [Cose] I-D Action: draft-ietf-cose-msg-02.txt 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: Mon, 20 Jul 2015 15:46:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CBOR Object Signing and Encryption Working Group of the IETF. Title : CBOR Encoded Message Syntax Author : Jim Schaad Filename : draft-ietf-cose-msg-02.txt Pages : 76 Date : 2015-07-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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cose-msg/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cose-msg-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cose-msg-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 21 09:46: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 5F7D71B2FDE for ; Tue, 21 Jul 2015 09:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_08=1.651, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 72Nf9G0mJE9n for ; Tue, 21 Jul 2015 09:44:45 -0700 (PDT) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext3.iad.github.net [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8B801B2FD6 for ; Tue, 21 Jul 2015 09:44:45 -0700 (PDT) Date: Tue, 21 Jul 2015 09:44:44 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1437497084; bh=ftLmcGMIq9ixEG/7e5IaHvCrUOP3T7jkhH1l7N4OrMg=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=lUdW1qoX8VLgU/Wm6832qYW5NaJtefapkf5lvzE6YKzeRaqpeMJopaqYKmE3+8J4T ORoxBW9Eb4UdZ4RnG/LnoR2KIBWuc25NyNEp9hrmI7wvS/6DEz23x3Y5gQrERiRUOW +PJ7oSBjI4k7LuuOVycEoMi+Ifx1SwSL+AFzgVt0= From: Justin Richer To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_55ae76fc5cc79_42053ff77c08b2a04556e2"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jricher X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: X-Mailman-Approved-At: Tue, 21 Jul 2015 09:46:42 -0700 Subject: Re: [Cose] [cose-issues] Notifications not sent to the IETF Mailing List (#1) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 16:44:47 -0000 ----==_mimepart_55ae76fc5cc79_42053ff77c08b2a04556e2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Testing, testing.... --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/1#issuecomment-123397874 ----==_mimepart_55ae76fc5cc79_42053ff77c08b2a04556e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Testing, testing....

—
Reply to this email directly or view it on GitHub.

----==_mimepart_55ae76fc5cc79_42053ff77c08b2a04556e2-- From nobody Wed Jul 22 02:45: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 08BDD1A1A58 for ; Wed, 22 Jul 2015 02:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_08=1.651, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 kmLoyIAP4Erm for ; Wed, 22 Jul 2015 02:45:13 -0700 (PDT) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext3.iad.github.net [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 897541A1A10 for ; Wed, 22 Jul 2015 02:45:13 -0700 (PDT) Date: Wed, 22 Jul 2015 02:45:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1437558312; bh=MNCya1eaR73Xc+njL1l+j7lUEGSvU06nxCUN+I4KMVA=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=vsV/SMBOeq2hHr+PklLKHTsHj9bIlXOGWZKqBviJmIdlaCO8OB4rlOUqQ5U3mooQ3 uqX+CO44expJ9CA8k5JerZcBrPOm+xt/z8a+eltMukMPz1D/CpuwB1Y8jz88NrAcSf AI4lTA5zNpIsX68z05797/bw9vGgXQtRuXPFiucs= From: Brian Campbell To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_55af662874fe1_71453ff9cf0c129c932727"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: b---c X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: Re: [Cose] [cose-issues] Notifications not sent to the IETF Mailing List (#1) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 09:45:15 -0000 ----==_mimepart_55af662874fe1_71453ff9cf0c129c932727 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit This is also a test comment... --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/1#issuecomment-123644895 ----==_mimepart_55af662874fe1_71453ff9cf0c129c932727 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

This is also a test comment...

—
Reply to this email directly or view it on GitHub.

----==_mimepart_55af662874fe1_71453ff9cf0c129c932727-- From nobody Wed Jul 22 04:26: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 B9E521B2BF3 for ; Wed, 22 Jul 2015 04:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.454 X-Spam-Level: X-Spam-Status: No, score=-5.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 evAsqCSph1_H for ; Wed, 22 Jul 2015 04:26:53 -0700 (PDT) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext2.iad.github.net [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16FCF1ACE6D for ; Wed, 22 Jul 2015 04:26:52 -0700 (PDT) Date: Wed, 22 Jul 2015 04:26:52 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1437564412; bh=tIiIly7iPeVbL7Twk0VDwRqBPBLEQLDubEAV/Rfj9Co=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=hONaWygS0mRfwSG+tY70lCvsrZynfq6SPlZLn5TDw1OiYEpvlBj5/27HhR9uY79nz 5/Ws4db8w4qKAffS6LlROLq13fIBEdxpXA8VOSBcUROhYAG34xYu5GOV6dTf+2TYWE 9mEjT12SWQR4RKaeuAwrmV/rMc0Ibp7oUtvqpbCU= From: Justin Richer To: cose-wg/cose-issues Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_55af7dfc4d63f_47693f89bea9f2b83793441"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: jricher X-GitHub-Recipient: cose-ietf X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: cose@ietf.org Archived-At: Subject: Re: [COSE] [cose-issues] Notifications not sent to the IETF Mailing List (#1) X-BeenThere: cose@ietf.org X-Mailman-Version: 2.1.15 Reply-To: cose-wg/cose-issues List-Id: CBOR Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 11:26:55 -0000 ----==_mimepart_55af7dfc4d63f_47693f89bea9f2b83793441 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit At Monday's face to face, we announced that we'd be using GitHub to track document development including issues against the drafts. I think that's finally set up properly. If this message goes through, then the working group's issue tracker is at: https://github.com/cose-wg/cose-issues/issues/ and all new issues and comments should get automatically posted to the list directly from the tracker. Since this auto-posts to the list, we're considering that all actions on GitHub are covered by the IETF Note Well, which is posted on the issue tracker's main project page: https://github.com/cose-wg/cose-issues/ We'll be migrating current issues in the near future, but feel free to start filing things over here. While comments and issues are generally posted to the list automatically, we have found that it's not an entirely reliable mechanism. As such, we're asking people to continue to have most of the discussion of an issue on the mailing list. Crossing my fingers and hoping the right thing happens when I click this button... --- Reply to this email directly or view it on GitHub: https://github.com/cose-wg/cose-issues/issues/1#issuecomment-123677417 ----==_mimepart_55af7dfc4d63f_47693f89bea9f2b83793441 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

At Monday's face to face, we announced that we'd be using GitHub to track document development including issues against the drafts. I think that's finally set up properly. If this message goes through, then the working group's issue tracker is at:

https://github.com/cose-wg/cose-issues/issues/

and all new issues and comments should get automatically posted to the list directly from the tracker. Since this auto-posts to the list, we're considering that all actions on GitHub are covered by the IETF Note Well, which is posted on the issue tracker's main project page:

https://github.com/cose-wg/cose-issues/

We'll be migrating current issues in the near future, but feel free to start filing things over here.

While comments and issues are generally posted to the list automatically, we have found that it's not an entirely reliable mechanism. As such, we're asking people to continue to have most of the discussion of an issue on the mailing list.

Crossing my fingers and hoping the right thing happens when I click this button...

—
Reply to this email directly or view it on GitHub.

----==_mimepart_55af7dfc4d63f_47693f89bea9f2b83793441-- From nobody Wed Jul 22 05: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 3D2251B32CC for ; Wed, 22 Jul 2015 05:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 bz8paFKJ0KDz for ; Wed, 22 Jul 2015 05: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 AE7C01A1A38 for ; Wed, 22 Jul 2015 05:47:30 -0700 (PDT) Received: from hebrews (dhcp-a241.meeting.ietf.org [31.133.162.65]) (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 0A58038F12 for ; Wed, 22 Jul 2015 05:47:27 -0700 (PDT) From: "Jim Schaad" To: Date: Wed, 22 Jul 2015 14:47:22 +0200 Message-ID: <003a01d0c47c$9e2b96f0$da82c4d0$@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: AdDEe0jHAGLvBjr/SfS8EclQF2mIGg== Content-Language: en-us Archived-At: Subject: [COSE] Replacement of the term "Key Management" 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, 22 Jul 2015 12:47:36 -0000 There is a problem with the document currently in that it uses the term "Key management" to deal with the general process of getting content encryption keys from a sender to a recipient. I use this term because it is what I am used to from CMS where the term is used for this purpose. When the charter was being written, the statement that we are not doing "Key Management" was placed in into it as a statement that the COSE working group is not doing Key Lifecycle protocols (i.e. how you distribute keys from a trusted server to a client or how pubic keys are transferred from a client to a server with appropriate identity binding). This conflict needs to get resolved either by clarifying the charter or changing the term that is being used in the document. I propose that we switch from "Key Management" to "Content Key Management" in the document so that it clear it is not lifecycle management. This term is correct for two deep messages and can be finessed for three deep messages which are not expected to be used in any event. Do any other people have suggestions for a better term? Jim From nobody Wed Jul 22 05:53: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 60F571A1A92 for ; Wed, 22 Jul 2015 05:53:07 -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 nw6a7DONebRu for ; Wed, 22 Jul 2015 05:53:06 -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 8ADFC1B3305 for ; Wed, 22 Jul 2015 05:53:04 -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 t6MCqwaC015819; Wed, 22 Jul 2015 14:52:58 +0200 (CEST) Received: from alma.local (dhcp-99b6.meeting.ietf.org [31.133.153.182]) (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 3mbxXp5jcLzDKHd; Wed, 22 Jul 2015 14:52:58 +0200 (CEST) Message-ID: <55AF9228.9030805@tzi.org> Date: Wed, 22 Jul 2015 14:52:56 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: Jim Schaad References: <003a01d0c47c$9e2b96f0$da82c4d0$@augustcellars.com> In-Reply-To: <003a01d0c47c$9e2b96f0$da82c4d0$@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] Replacement of the term "Key Management" 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, 22 Jul 2015 12:53:07 -0000 Key conveyance? Grüße, Carsten Jim Schaad wrote: > There is a problem with the document currently in that it uses the term "Key > management" to deal with the general process of getting content encryption > keys from a sender to a recipient. I use this term because it is what I am > used to from CMS where the term is used for this purpose. > > When the charter was being written, the statement that we are not doing "Key > Management" was placed in into it as a statement that the COSE working group > is not doing Key Lifecycle protocols (i.e. how you distribute keys from a > trusted server to a client or how pubic keys are transferred from a client > to a server with appropriate identity binding). > > This conflict needs to get resolved either by clarifying the charter or > changing the term that is being used in the document. I propose that we > switch from "Key Management" to "Content Key Management" in the document so > that it clear it is not lifecycle management. This term is correct for two > deep messages and can be finessed for three deep messages which are not > expected to be used in any event. > > Do any other people have suggestions for a better term? > > Jim > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > From nobody Wed Jul 22 06:12: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 AC2F41B3355 for ; Wed, 22 Jul 2015 06:12: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 Vr9zUvu-_bu0 for ; Wed, 22 Jul 2015 06:12: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 E00D71B3367 for ; Wed, 22 Jul 2015 06:11:36 -0700 (PDT) Received: from hebrews (dhcp-a241.meeting.ietf.org [31.133.162.65]) (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 F0A6538EEA for ; Wed, 22 Jul 2015 06:11:35 -0700 (PDT) From: "Jim Schaad" To: Date: Wed, 22 Jul 2015 15:11:54 +0200 Message-ID: <004901d0c47f$fcf83500$f6e89f00$@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: AdDEf4m8vr8WA+IcS8mTH+lwsO/k6A== Content-Language: en-us Archived-At: Subject: [COSE] Pull Request #59 - Assign integer tags to CCM 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, 22 Jul 2015 13:12:11 -0000 I have done the edits to assign integer tags to the CCM modes that we discussed at the F2F meeting. Looking at the editors copy on github and you will be able to see what I did. The one example using CCM has been updated. In doing the update, I noticed that I missed a parameter that needed to be specified for CCM which deals with the maximum possible message length. I have done an arbitrary choice of basically the maximum and minimum possible lengths as viable options. People should look and see if any of these should be removed. (As noted in the document the message length and none length are directly related. Making one larger decreases the size of the other.) Jim From nobody Wed Jul 22 08:05: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 2D75D1A0052 for ; Wed, 22 Jul 2015 08:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 qTppgxBMqP7J for ; Wed, 22 Jul 2015 08:05:40 -0700 (PDT) Received: from smtpcmd02111.aruba.it (smtpcmd02111.aruba.it [62.149.158.111]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8BB1A004B for ; Wed, 22 Jul 2015 08:05:39 -0700 (PDT) Received: from dell-tcastaldi ([31.130.224.109]) by smtpcmd02.ad.aruba.it with bizsmtp id vT5c1q0162NEPrz01T5dWA; Wed, 22 Jul 2015 17:05:38 +0200 Date: Wed, 22 Jul 2015 17:05:38 +0200 (CEST) From: Meetecho Team To: cose@ietf.org Message-ID: <1315968767.1.1437577538222.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_0_1756201167.1437577538154" Archived-At: Subject: [COSE] Meetecho recordings of COSE WG session 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, 22 Jul 2015 15:05:41 -0000 ------=_Part_0_1756201167.1437577538154 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the COSE WG session at IETF 93 is available at the following URL: http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#COSE In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team ------=_Part_0_1756201167.1437577538154-- From nobody Wed Jul 22 21:54:03 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 010301A1A91 for ; Wed, 22 Jul 2015 21:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 iv0P3tstizTK for ; Wed, 22 Jul 2015 21:54:00 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 813731A1A8C for ; Wed, 22 Jul 2015 21:54:00 -0700 (PDT) Received: by ietj16 with SMTP id j16so183652414iet.0 for ; Wed, 22 Jul 2015 21:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YYL+//fg4hcO5SsOmV/Wu7a/nwarIuM37PmJfjz2WBI=; b=QovcymIZU2VPvhqWre5fBFBOiPUHy4FAYMuchsAv7llq4th2ItsjPSrsiGL1KLN7pm QVtr3dSm4Iagcs8NtwSUmjNAFS2qy/wQCRMphl1DD6oBui9V+x6Q+ousa//uAUlQft2g FotXpNK62F0udkQ27BVzM26vzD2BCV3dHaAv4= 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=YYL+//fg4hcO5SsOmV/Wu7a/nwarIuM37PmJfjz2WBI=; b=MlBmTeYjfGgTCasc4CiTsUhe/IrbcpvDYLlBrUUw72Jv42F15JtHvKdsE8a2wI3ftE is6po3DvoX/43X8o7V8hticfWFXA+4/kxqTguSp/SjDrkm7eTmb5+gQuMpK8P3pyKDso DWytBOzAWLqlGEK/kjkKvOSEtZxiqZ25p9K7K6yDWjJ6SN3kZwS++wDKUjPo70d6UNWK aeLJHLJ82ca6MqpemkIDPHys+5mFlHtMYzyVNJzCIRGzWrR6e1oD9D/JS2oU5aa012WY /zjWkgfFVks8YB8myYf4DOkLnTJXoHUlb+Zxc9+fcrnBhOR21Xi3+iSeCoTnUW6yrIdq UrlQ== X-Gm-Message-State: ALoCoQku/u4syBXikJa/dUB32aH1MqdjFgqMz6Aoa29hAeqQm8Nj5xjfmq+uU6s8LLR2Oa3GV0J2 X-Received: by 10.107.14.148 with SMTP id 142mr9479976ioo.175.1437627240037; Wed, 22 Jul 2015 21:54:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Wed, 22 Jul 2015 21:53:30 -0700 (PDT) In-Reply-To: <55AF9228.9030805@tzi.org> References: <003a01d0c47c$9e2b96f0$da82c4d0$@augustcellars.com> <55AF9228.9030805@tzi.org> From: Brian Campbell Date: Thu, 23 Jul 2015 06:53:30 +0200 Message-ID: To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a113fc47cf65f1c051b83acbf Archived-At: Cc: Jim Schaad , cose@ietf.org Subject: Re: [COSE] Replacement of the term "Key Management" 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, 23 Jul 2015 04:54:02 -0000 --001a113fc47cf65f1c051b83acbf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I sort of like "Key Conveyance" On Wed, Jul 22, 2015 at 2:52 PM, Carsten Bormann wrote: > Key conveyance? > > Gr=C3=BC=C3=9Fe, Carsten > > > Jim Schaad wrote: > > There is a problem with the document currently in that it uses the term > "Key > > management" to deal with the general process of getting content > encryption > > keys from a sender to a recipient. I use this term because it is what = I > am > > used to from CMS where the term is used for this purpose. > > > > When the charter was being written, the statement that we are not doing > "Key > > Management" was placed in into it as a statement that the COSE working > group > > is not doing Key Lifecycle protocols (i.e. how you distribute keys from= a > > trusted server to a client or how pubic keys are transferred from a > client > > to a server with appropriate identity binding). > > > > This conflict needs to get resolved either by clarifying the charter or > > changing the term that is being used in the document. I propose that = we > > switch from "Key Management" to "Content Key Management" in the documen= t > so > > that it clear it is not lifecycle management. This term is correct for > two > > deep messages and can be finessed for three deep messages which are not > > expected to be used in any event. > > > > Do any other people have suggestions for a better term? > > > > Jim > > > > > > _______________________________________________ > > COSE mailing list > > COSE@ietf.org > > https://www.ietf.org/mailman/listinfo/cose > > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > --001a113fc47cf65f1c051b83acbf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I sort of like "Key Conveyance"



On Wed, Jul 22,= 2015 at 2:52 PM, Carsten Bormann <cabo@tzi.org> wrote:
Key conveyance?

Gr=C3=BC=C3=9Fe, Carsten


Jim Schaad wrote:
> There is a problem with the document currently in that it uses the ter= m "Key
> management" to deal with the general process of getting content e= ncryption
> keys from a sender to a recipient.=C2=A0 I use this term because it is= what I am
> used to from CMS where the term is used for this purpose.
>
> When the charter was being written, the statement that we are not doin= g "Key
> Management" was placed in into it as a statement that the COSE wo= rking group
> is not doing Key Lifecycle protocols (i.e. how you distribute keys fro= m a
> trusted server to a client or how pubic keys are transferred from a cl= ient
> to a server with appropriate identity binding).
>
> This conflict needs to get resolved either by clarifying the charter o= r
> changing the term that is being used in the document.=C2=A0 =C2=A0I pr= opose that we
> switch from "Key Management" to "Content Key Management= " in the document so
> that it clear it is not lifecycle management.=C2=A0 This term is corre= ct for two
> deep messages and can be finessed for three deep messages which are no= t
> expected to be used in any event.
>
> Do any other people have suggestions for a better term?
>
> Jim
>
>
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose
>

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

--001a113fc47cf65f1c051b83acbf-- From nobody Wed Jul 22 22:00:47 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 D4C731A1A27 for ; Wed, 22 Jul 2015 22:00:45 -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 2xDgoAwrmlKw for ; Wed, 22 Jul 2015 22:00:43 -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 17B181A1ABC for ; Wed, 22 Jul 2015 22:00:43 -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.231.11; Thu, 23 Jul 2015 05:00:29 +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.0225.018; Thu, 23 Jul 2015 05:00:29 +0000 From: Mike Jones To: Brian Campbell , Carsten Bormann Thread-Topic: [COSE] Replacement of the term "Key Management" Thread-Index: AdDEe0jHAGLvBjr/SfS8EclQF2mIGgAAgukAACGMIgAAAD58xQ== Date: Thu, 23 Jul 2015 05:00:29 +0000 Message-ID: References: <003a01d0c47c$9e2b96f0$da82c4d0$@augustcellars.com> <55AF9228.9030805@tzi.org>, 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: [166.170.37.164] x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:lmfSnks5haHMAnhBFIHxgxcQMQHM7ApIBOaN/HObfGokg/oKbHEHHWHHF9uQzGe1d6IF5bK1d+6lCkjyxfBAC7s8gI+dN1yQ6wYblLs/FMCd//9POCKpTVb6gBEJS+17xYckdNp3oWADF8rPTNc+aA==; 24:5Ui0lPl72y/YVFRdtlEbtAkzqevUX2LDff9n74Nzr6eTAioDtxyyTJvQQ/dQbFMdGelyPYjS1hPUiw5+eShMTqBWvUvErkp/i4ANHOg5OGk=; 20:x+XyvKcvYkraPZiadot1B9OazO+vYx/2W75FZ9Sa3wvcnu6NLl9bwNURYdwkUjRuXJozf99ZjLRKBtBNF8Cnxg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB444; by2pr03mb444: X-MS-Exchange-Organization-RulesExecuted 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: 06469BCC91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(5001770100001)(19580405001)(102836002)(50986999)(15975445007)(46102003)(189998001)(76576001)(19580395003)(99286002)(2950100001)(5003600100002)(54356999)(5001960100002)(122556002)(66066001)(74316001)(86362001)(62966003)(40100003)(10090500001)(77156002)(33656002)(5001920100001)(5002640100001)(2900100001)(16236675004)(76176999)(77096005)(2656002)(92566002)(87936001)(19617315012); 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_BY2PR03MB442E7AEAA16659FC7A55A19F5820BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2015 05:00:29.5581 (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: Jim Schaad , "cose@ietf.org" Subject: Re: [COSE] Replacement of the term "Key Management" 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, 23 Jul 2015 05:00:46 -0000 --_000_BY2PR03MB442E7AEAA16659FC7A55A19F5820BY2PR03MB442namprd_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable That works for me too. -- Mike ________________________________ From: Brian Campbell Sent: =FD7/=FD23/=FD2015 6:54 AM To: Carsten Bormann Cc: Jim Schaad; cose@ietf.org Subject: Re: [COSE] Replacement of the term "Key Management" I sort of like "Key Conveyance" On Wed, Jul 22, 2015 at 2:52 PM, Carsten Bormann > wrote: Key conveyance? Gr=FC?e, Carsten Jim Schaad wrote: > There is a problem with the document currently in that it uses the term "= Key > management" to deal with the general process of getting content encryptio= n > keys from a sender to a recipient. I use this term because it is what I = am > used to from CMS where the term is used for this purpose. > > When the charter was being written, the statement that we are not doing "= Key > Management" was placed in into it as a statement that the COSE working gr= oup > is not doing Key Lifecycle protocols (i.e. how you distribute keys from a > trusted server to a client or how pubic keys are transferred from a clien= t > to a server with appropriate identity binding). > > This conflict needs to get resolved either by clarifying the charter or > changing the term that is being used in the document. I propose that we > switch from "Key Management" to "Content Key Management" in the document = so > that it clear it is not lifecycle management. This term is correct for t= wo > deep messages and can be finessed for three deep messages which are not > expected to be used in any event. > > Do any other people have suggestions for a better term? > > Jim > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > _______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose --_000_BY2PR03MB442E7AEAA16659FC7A55A19F5820BY2PR03MB442namprd_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
That works fo= r me too.

-- Mike
From: Brian Campbell
Sent: =FD7/= =FD23/=FD2015 6:54 AM
To: Carsten Bormann
Cc: Jim Schaad; cose@ietf.org
Subject: Re: [= COSE] Replacement of the term "Key Management"

I sort of like "Key Conveyance"



On Wed, Jul 22, 2015 at 2:52 PM, Carsten Bormann= <cabo@tzi.org><= /span> wrote:
Key conveyance?

Gr=FCße, Carsten


Jim Schaad wrote:
> There is a problem with the document currently in that it uses the ter= m "Key
> management" to deal with the general process of getting content e= ncryption
> keys from a sender to a recipient.  I use this term because it is= what I am
> used to from CMS where the term is used for this purpose.
>
> When the charter was being written, the statement that we are not doin= g "Key
> Management" was placed in into it as a statement that the COSE wo= rking group
> is not doing Key Lifecycle protocols (i.e. how you distribute keys fro= m a
> trusted server to a client or how pubic keys are transferred from a cl= ient
> to a server with appropriate identity binding).
>
> This conflict needs to get resolved either by clarifying the charter o= r
> changing the term that is being used in the document.   I pr= opose that we
> switch from "Key Management" to "Content Key Management= " in the document so
> that it clear it is not lifecycle management.  This term is corre= ct for two
> deep messages and can be finessed for three deep messages which are no= t
> expected to be used in any event.
>
> Do any other people have suggestions for a better term?
>
> Jim
>
>
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose
>

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

--_000_BY2PR03MB442E7AEAA16659FC7A55A19F5820BY2PR03MB442namprd_-- From nobody Thu Jul 23 03:05: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 2FB3F1A026A for ; Thu, 23 Jul 2015 03:05:39 -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 pokLMqcbY076 for ; Thu, 23 Jul 2015 03:05:37 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05CE71A0250 for ; Thu, 23 Jul 2015 03:05:33 -0700 (PDT) X-AuditID: 1209190e-f79c76d000002631-f9-55b0bc6c720b 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-3.mit.edu (Symantec Messaging Gateway) with SMTP id 8D.00.09777.C6CB0B55; Thu, 23 Jul 2015 06:05:32 -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 t6NA5WQs014085 for ; Thu, 23 Jul 2015 06:05:32 -0400 Received: from [10.162.249.131] (cst-prg-45-1.cust.vodafone.cz [46.135.45.1]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t6NA5TsU030112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 23 Jul 2015 06:05:31 -0400 Date: Thu, 23 Jul 2015 12:05:28 +0200 Message-ID: Importance: normal From: Justin Richer To: cose@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_1338441853299700" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPIsWRmVeSWpSXmKPExsUixCmqrJuzZ0OowcNLphbTtk5ldWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRtfBR8wFF+Qqjt3iaWC8ItvFyMkhIWAisf7rW1YIW0ziwr31 bF2MXBxCAouZJHp/rGSBcI4ySpw7/pEVwrnHJPGqcy47SAuLgKrEnJWTmUFsYQEric63hxhB bF4BN4nDt48AxTk4OAWEJLp2SYCE2YDKp69pYQIJiwgIStztNIeoFpQ4OfMJC4jNLBAqcfzS PeYJjLyzkKRmIUlB2OoSf+ZdgrIVJaZ0P2SfBTSVWUBNYlmrErLwAka2VYyyKblVurmJmTnF qcm6xcmJeXmpRbrGermZJXqpKaWbGMHhKMm3g/HrQaVDjAIcjEo8vAu8NoQKsSaWFVfmHmKU 5GBSEuU9uQsoxJeUn1KZkVicEV9UmpNafIhRgoNZSYT3ynygHG9KYmVValE+TEqag0VJnHfT D74QIYH0xJLU7NTUgtQimKwMB4eSBO8LkKGCRanpqRVpmTklCGkmDk6Q4TxAw2+D1PAWFyTm FmemQ+RPMSpKifO+A0kIgCQySvPgemHp4hWjONArwhAreICpBq77FdBgJqDBPH1gg0sSEVJS DYxu9lpTkufb7p5y586U86IbXIw+/3pwJdRIdvn2gy0S4WedqmI2GVVPDs9pt51ZfmKB9SXB eS72BYsUNjC/nu9Wx7H0uWrTXoUY/eN71ZnWThKp59N/k70r4eTFX29bZv46kqd4udXegOtP 1Tp3Q9GIdwr3JNfWHTnrHZCs4+9uoPxym/NakVYlluKMREMt5qLiRACeibhD8gIAAA== Archived-At: Subject: Re: [COSE] Meetecho recordings of COSE WG session 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, 23 Jul 2015 10:05:39 -0000 ----_com.android.email_1338441853299700 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CiAgICAKSnVzdCBhIGhlYWRzIHVwOiBzaW5jZSB3ZSBzaGFyZWQgdGhlIHNlc3Npb24gdGltZSB3 aXRoIElQU0VDTUUsIG91ciBzZXNzaW9uIHdhcyByZWNvcmRlZCB1bmRlciB0aGUgSVBTRUNNRSBo ZWFkaW5nIGFsb25nIHdpdGggdGhlaXJzLiBUaGUgQ09TRSBzZXNzaW9uIHN0YXJ0cyBhdCBhYm91 dCBvbmUgaG91ciBpbiB0byB0aGUgdHdvIGFuZCBhIGhhbGYgaG91ciBzZXNzaW9uIHJlY29yZGlu Zy4gQXMgYW4gdW5mb3J0dW5hdGUgc2lkZSBlZmZlY3QsIHRoZSBsb2dzIGZvciB0aGUgQ09TRSBY TVBQIGNoYXQgcm9vbSB3ZXJlbid0IHJlY29yZGVkLsKgCi0tIEp1c3RpbgovIFNlbnQgZnJvbSBt eSBwaG9uZSAvCgotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tCkZyb206IE1lZXRl Y2hvIFRlYW0gPGlldGZAbWVldGVjaG8uY29tPiAKRGF0ZTogNy8yMi8yMDE1ICA1OjA1IFBNICAo R01UKzAxOjAwKSAKVG86IGNvc2VAaWV0Zi5vcmcgClN1YmplY3Q6IFtDT1NFXSBNZWV0ZWNobyBy ZWNvcmRpbmdzIG9mIENPU0UgV0cgc2Vzc2lvbiAKCkRlYXIgYWxsLAoKdGhlIGZ1bGwgcmVjb3Jk aW5nIChzeW5jaHJvbml6ZWQgdmlkZW8sIGF1ZGlvLCBzbGlkZXMgYW5kIGphYmJlciByb29tKSBv ZiB0aGUgCkNPU0UgV0cgc2Vzc2lvbiBhdCBJRVRGIDkzIGlzIGF2YWlsYWJsZSBhdCB0aGUgZm9s bG93aW5nIFVSTDoKaHR0cDovL2lldGY5My5jb25mLm1lZXRlY2hvLmNvbS9pbmRleC5waHAvUmVj b3JkZWRfU2Vzc2lvbnMjQ09TRQoKSW4gY2FzZSBvZiBwcm9ibGVtcyB3aXRoIHRoZSBwbGF5b3V0 LCBqdXN0IGRyb3AgYW4gZS1tYWlsIHRvIGlldGYtc3VwcG9ydEBtZWV0ZWNoby5jb20uCgpGb3Ig dGhlIGNoYWlyKHMpOiBwbGVhc2UgZmVlbCBmcmVlIHRvIHB1dCB0aGUgbGluayB0byB0aGUgcmVj b3JkaW5nIGluIHRoZSBtaW51dGVzLAppZiB5b3UgdGhpbmsgdGhpcyBtaWdodCBiZSB1c2VmdWwu CgpDaGVlcnMsCnRoZSBNZWV0ZWNobyBUZWFtCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCkNPU0UgbWFpbGluZyBsaXN0CkNPU0VAaWV0Zi5vcmcKaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlCg== ----_com.android.email_1338441853299700 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT4KICAgIAo8ZGl2Pkp1c3QgYSBoZWFk cyB1cDogc2luY2Ugd2Ugc2hhcmVkIHRoZSBzZXNzaW9uIHRpbWUgd2l0aCBJUFNFQ01FLCBvdXIg c2Vzc2lvbiB3YXMgcmVjb3JkZWQgdW5kZXIgdGhlIElQU0VDTUUgaGVhZGluZyBhbG9uZyB3aXRo IHRoZWlycy4gVGhlIENPU0Ugc2Vzc2lvbiBzdGFydHMgYXQgYWJvdXQgb25lIGhvdXIgaW4gdG8g dGhlIHR3byBhbmQgYSBoYWxmIGhvdXIgc2Vzc2lvbiByZWNvcmRpbmcuIEFzIGFuIHVuZm9ydHVu YXRlIHNpZGUgZWZmZWN0LCB0aGUgbG9ncyBmb3IgdGhlIENPU0UgWE1QUCBjaGF0IHJvb20gd2Vy ZW4ndCByZWNvcmRlZC4mbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IGlkPSJjb21wb3Nl cl9zaWduYXR1cmUiPjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4 dC9odG1sOyBjaGFyc2V0PVVURi04Ij48ZGl2PCBkaXY9IiI+PGRpdj48ZGl2Pi0tIEp1c3Rpbjwv ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+LyBTZW50IGZyb20gbXkgcGhvbmUgLzwvZGl2PjwvZGl2 PjxkaXY+PC9kaXY+PC9kaXY8PjwvZGl2Pjxicj48YnI+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2Fn ZSAtLS0tLS0tLTxicj5Gcm9tOiBNZWV0ZWNobyBUZWFtICZsdDtpZXRmQG1lZXRlY2hvLmNvbSZn dDsgPGJyPkRhdGU6IDcvMjIvMjAxNSAgNTowNSBQTSAgKEdNVCswMTowMCkgPGJyPlRvOiBjb3Nl QGlldGYub3JnIDxicj5TdWJqZWN0OiBbQ09TRV0gTWVldGVjaG8gcmVjb3JkaW5ncyBvZiBDT1NF IFdHIHNlc3Npb24gPGJyPjxicj5EZWFyIGFsbCw8YnI+PGJyPnRoZSBmdWxsIHJlY29yZGluZyAo c3luY2hyb25pemVkIHZpZGVvLCBhdWRpbywgc2xpZGVzIGFuZCBqYWJiZXIgcm9vbSkgb2YgdGhl IDxicj5DT1NFIFdHIHNlc3Npb24gYXQgSUVURiA5MyBpcyBhdmFpbGFibGUgYXQgdGhlIGZvbGxv d2luZyBVUkw6PGJyPmh0dHA6Ly9pZXRmOTMuY29uZi5tZWV0ZWNoby5jb20vaW5kZXgucGhwL1Jl Y29yZGVkX1Nlc3Npb25zI0NPU0U8YnI+PGJyPkluIGNhc2Ugb2YgcHJvYmxlbXMgd2l0aCB0aGUg cGxheW91dCwganVzdCBkcm9wIGFuIGUtbWFpbCB0byBpZXRmLXN1cHBvcnRAbWVldGVjaG8uY29t Ljxicj48YnI+Rm9yIHRoZSBjaGFpcihzKTogcGxlYXNlIGZlZWwgZnJlZSB0byBwdXQgdGhlIGxp bmsgdG8gdGhlIHJlY29yZGluZyBpbiB0aGUgbWludXRlcyw8YnI+aWYgeW91IHRoaW5rIHRoaXMg bWlnaHQgYmUgdXNlZnVsLjxicj48YnI+Q2hlZXJzLDxicj50aGUgTWVldGVjaG8gVGVhbTxicj48 YnI+PGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj5DT1NFIG1haWxpbmcgbGlzdDxicj5DT1NFQGlldGYub3JnPGJyPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY29zZTxicj48L2JvZHk+PC9odG1sPg== ----_com.android.email_1338441853299700-- From nobody Thu Jul 23 03:40: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 19B6B1A1AE1 for ; Thu, 23 Jul 2015 03:40:21 -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, MIME_QP_LONG_LINE=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 y9b-x4czofb9 for ; Thu, 23 Jul 2015 03:40:17 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (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 680D51A1A34 for ; Thu, 23 Jul 2015 03:40:17 -0700 (PDT) Received: by wicgb10 with SMTP id gb10so136757014wic.1 for ; Thu, 23 Jul 2015 03:40:16 -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=hTf+kQMmmA/YcngJzUlMztA21cMR9hwHWw3bvD+F2HI=; b=Ov5Pdbvh1QrhL8fcqxImlQuLtkfv0BQ2dfqq2nZbvhEN30N09YMMEP2M1Myt653Fv6 35L5gPvAVvfoMn68aE8OuLAKSY4DAoUp6Pn88OVb74WUG7FY5MU6WL3kkgr3wB2otGUu KaxqlMAwXwexJxB74Eegw3pj4UFkjhJxvy/ztRMx1zW/vC6lCa4UduibmjCgsZQzA7oy xXAgE8hvndA88xGMntpKjp4RxOpznr+rjKd13RPfzaeuDmazNT34goA1CGgIvHUVkyaS BqYjMiilIGiTa5/ZVdi77cptUkt6Admo1rmEJ2F76cvGox/Kr466y0a0BN7RsNXYBKt2 yu8w== X-Gm-Message-State: ALoCoQnhnYZ8J66Jn2NuriydOhZBES59Xr+gavufjAG+5Z95dkDwseA40FqLjvR5g4a+bVn0lCFg X-Received: by 10.180.77.200 with SMTP id u8mr16083347wiw.70.1437648016033; Thu, 23 Jul 2015 03:40:16 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:c13a:bf3f:1e38:2a71? ([2001:67c:370:136:c13a:bf3f:1e38:2a71]) by smtp.gmail.com with ESMTPSA id x6sm26528904wiy.6.2015.07.23.03.40.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Jul 2015 03:40:14 -0700 (PDT) Content-Type: multipart/signed; boundary=Apple-Mail-7EF5C583-37DA-4F23-845B-C09ADE964DAD; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: John Bradley X-Mailer: iPhone Mail (13A4305g) In-Reply-To: Date: Thu, 23 Jul 2015 12:40:10 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <003a01d0c47c$9e2b96f0$da82c4d0$@augustcellars.com> <55AF9228.9030805@tzi.org> To: Mike Jones Archived-At: Cc: Carsten Bormann , Brian Campbell , Jim Schaad , "cose@ietf.org" Subject: Re: [COSE] Replacement of the term "Key Management" 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, 23 Jul 2015 10:40:21 -0000 --Apple-Mail-7EF5C583-37DA-4F23-845B-C09ADE964DAD Content-Type: multipart/alternative; boundary=Apple-Mail-F347F7B6-0F75-41DA-A7DD-9D5F28903D1D Content-Transfer-Encoding: 7bit --Apple-Mail-F347F7B6-0F75-41DA-A7DD-9D5F28903D1D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable How about content key establishment. Is it always conveyed and never agree= d? I don't care deeply and can live with Conveyance. =20 John B. =20 Sent from my iPhone > On Jul 23, 2015, at 7:00 AM, Mike Jones wrot= e: >=20 > That works for me too. >=20 > -- Mike > From: Brian Campbell > Sent: =E2=80=8E7/=E2=80=8E23/=E2=80=8E2015 6:54 AM > To: Carsten Bormann > Cc: Jim Schaad; cose@ietf.org > Subject: Re: [COSE] Replacement of the term "Key Management" >=20 > I sort of like "Key Conveyance"=20 >=20 >=20 >=20 >> On Wed, Jul 22, 2015 at 2:52 PM, Carsten Bormann wrote: >> Key conveyance? >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >> Jim Schaad wrote: >> > There is a problem with the document currently in that it uses the term= "Key >> > management" to deal with the general process of getting content encrypt= ion >> > keys from a sender to a recipient. I use this term because it is what I= am >> > used to from CMS where the term is used for this purpose. >> > >> > When the charter was being written, the statement that we are not doing= "Key >> > Management" was placed in into it as a statement that the COSE working g= roup >> > is not doing Key Lifecycle protocols (i.e. how you distribute keys from= a >> > trusted server to a client or how pubic keys are transferred from a cli= ent >> > to a server with appropriate identity binding). >> > >> > This conflict needs to get resolved either by clarifying the charter or= >> > changing the term that is being used in the document. I propose that w= e >> > switch from "Key Management" to "Content Key Management" in the documen= t so >> > that it clear it is not lifecycle management. This term is correct for= two >> > deep messages and can be finessed for three deep messages which are not= >> > expected to be used in any event. >> > >> > Do any other people have suggestions for a better term? >> > >> > Jim >> > >> > >> > _______________________________________________ >> > COSE mailing list >> > COSE@ietf.org >> > https://www.ietf.org/mailman/listinfo/cose >> > >>=20 >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose --Apple-Mail-F347F7B6-0F75-41DA-A7DD-9D5F28903D1D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
How about content key establishment. &= nbsp; Is it always conveyed and never agreed?  I don't care deeply and c= an live with Conveyance.  

John B.  

Sent from my iPhone

On Jul 23, 2015, at 7:00 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
That works for= me too.

-- Mike
From: Brian Campbell
Sent: =E2=80= =8E7/=E2=80=8E23/=E2=80=8E2015 6:54 AM
To: Carsten Bormann
Cc: Jim Schaad; cose@ietf.org
Subject: Re: [C= OSE] Replacement of the term "Key Management"

I sort of like "Key Conveyance"



On Wed, Jul 22, 2015 at 2:52 PM, Carsten Bormann <= span dir=3D"ltr"> <cabo@tzi.org> wrote:
Key conveyance?

Gr=C3=BC=C3=9Fe, Carsten


Jim Schaad wrote:
> There is a problem with the document currently in that it uses the term= "Key
> management" to deal with the general process of getting content encrypt= ion
> keys from a sender to a recipient.  I use this term because it is w= hat I am
> used to from CMS where the term is used for this purpose.
>
> When the charter was being written, the statement that we are not doing= "Key
> Management" was placed in into it as a statement that the COSE working g= roup
> is not doing Key Lifecycle protocols (i.e. how you distribute keys from= a
> trusted server to a client or how pubic keys are transferred from a cli= ent
> to a server with appropriate identity binding).
>
> This conflict needs to get resolved either by clarifying the charter or=
> changing the term that is being used in the document.   I pro= pose that we
> switch from "Key Management" to "Content Key Management" in the documen= t so
> that it clear it is not lifecycle management.  This term is correc= t for two
> deep messages and can be finessed for three deep messages which are not=
> expected to be used in any event.
>
> Do any other people have suggestions for a better term?
>
> Jim
>
>
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose
>

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

____________________= ___________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman= /listinfo/cose
= --Apple-Mail-F347F7B6-0F75-41DA-A7DD-9D5F28903D1D-- --Apple-Mail-7EF5C583-37DA-4F23-845B-C09ADE964DAD Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHBDCCBwAw ggXooAMCAQICAkgHMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTQwMzI0MjM1NjIzWhcNMTYwMzI1MDkzOTMxWjCBnzEZMBcGA1UEDRMQcXpGMDFYWUNaTUwz ODdoRDELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEiMCAGCSqGSIb3DQEJ ARYTamJyYWRsZXlAaWNsb3VkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALUy 9KOEBlgvo55mGu8RI3AUwHiDreyC8uNKrJyRzXnVWkx9BFOch86GhDhh7jrsCVM/wu69k716Sf1H eMOlTh3TlBp5ylIh+TFf5CMrGew6TeQ9X/shGrLdNKCrBG3/w+n5c33sdiRVfa0+wEPhUGk3X90v Su4DNheZDgxYPNOQTGExk/oWsPVTjF47ubPd1RI1EHJxqy8tEbaDe+hjOiLcajZxLfy5/thjavCb z8lCnibAMXyJU8qiG8N9lZbrCly+Po5oBYvi2Om7H4N1Ry78ufELEJwsB4NebgEb8uV+qMMhnBu8 R8DZpXzVrQWdwxzT4d+xwvZZgMuIqsOD7zcCAwEAAaOCA1UwggNRMAkGA1UdEwQCMAAwCwYDVR0P BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUlA2+gZSQ+xSG IFo9cOM/hrDl7O8wHwYDVR0jBBgwFoAUrlWDb+wxyrn3HfqvazHzyB3jrLswgZkGA1UdEQSBkTCB joETamJyYWRsZXlAaWNsb3VkLmNvbYETamJyYWRsZXlAaWNsb3VkLmNvbYEXam9obi5icmFkbGV5 QHdpbmdhYS5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgQ9qYnJhZGxleUBtZS5jb22BEGpicmFkbGV5 QG1hYy5jb22BE2picmFkbGV5QHdpbmdhYS5jb20wggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQB gbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBk ZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIB ARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDIg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVs eWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYD VR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQC7HBJX W64HhQdVgv4THWMRU+C3PAC7RK4Ca8kaM03XjJc6bJ3CCssvDOeB4cUADDqhXth0fkfR+1niM5pF feciZyWN23eG8Z53poS6w8otVZTYxI5CuZIHoCPCWr2oRV5eBcCRx7/Ezoe9Vn934stA6O3e00Jl Q0a87dZP9sOAlysHkNpnRcO37JImKDxhCu6RYonBjBQcy4ikZutQqqI0uCGEoYj9JwmWVj8DSWLO ZbLcQ0kjGg/inHGVcZC+19kI/TyfjwgEOnTIb8E163XJ6xO3yPD4Rbx1qxEY4O8iLtViOBYL4stL u+N+71s7n0p36jMG389tH7nDtHIWKvrZMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICSAcwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTUwNzIzMTA0MDEwWjAjBgkqhkiG9w0BCQQxFgQUaESel2DZbriVd7e1 qMu8WrlbBGAwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgJIBzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIC SAcwDQYJKoZIhvcNAQEBBQAEggEAXpZwGD5CgE7cOfdo2Aju1qTCUfDIBt9MUVHdaiACIixIkHCc 3Ct295KYcUpXIEIzfUfkRCTG1hmkAOWiMcO7yyI89VpQMK4mUYoTipZDoEq8/+XWijmUQnvjqsr9 kled4O0lafAlnava7c1I8+tvYaAJODVkXvXiXsMJb42dlDh4U9w7c0l0NHU6I+cAiGMQpVYHfCZ+ spyQVw7U5bgaOUXdQyLPKYlkMTw+K89F6Jv58jtk9z2arrxgmWrqrDYiR/ob3kPLNFaQqZLEqkDQ Ns04cci+ntjA1i1R+q1DE/dPGq8vhFV4DpcR1ICYfg++HqUbDiWqrY4bGzU+hkS8FgAAAAAAAA== --Apple-Mail-7EF5C583-37DA-4F23-845B-C09ADE964DAD-- From nobody Thu Jul 23 04:35: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 D1F8D1A710C for ; Thu, 23 Jul 2015 04:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 y5nsnnbEty9x for ; Thu, 23 Jul 2015 04:35:28 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (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 172991AC419 for ; Thu, 23 Jul 2015 04:35:27 -0700 (PDT) Received: by igbpg9 with SMTP id pg9so11532065igb.0 for ; Thu, 23 Jul 2015 04:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7L6FumFyUKsD+skIV7U0/VKCjamr8vfZQR6uvCdlKN0=; b=aw2ba8LH5CUvFW38pwR8U0spbqikm0YTa0fanUj04qzeBKLQCFr4CgSzZMLW9gy8N5 aEGdOutPeePAXMIG3L2Qux5cYmltxSFVjTGQDABJ7wabZ60XqLF0HI/cgjhIdg4YvJhx bI8nOZX9bKDaobClGYKtcDuKyuSTndTaIWtEo= 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=7L6FumFyUKsD+skIV7U0/VKCjamr8vfZQR6uvCdlKN0=; b=cvvN9pJiAlgG0OBBg1M7Tk4EBNlkhGxjzMZsB2PSsPh1Cu+ZWzPJB4VPgnSJT4qgQH VATCr0NtsCZ5y5Ci146hXpmrznRBbPQSf9La+FwqtqTz5dL/jAtrPHolvik/1dT6ORvd lG+8DxGcfvDclIMZCbRoPvtQ0oHje+AfIakZ7DY5Vch6wte17TXJvOolnWJVyiJArqe3 rEjL50Z2sUFUIwD7pOAaeidpm0VEs/UvwTyqfB3lvkMtaLD6VjejvUOSWv2cpE+IyLoc UxVwGwJjfuI9MBn1JdSRXatP/GDZqoBypi0k5/Py/nuxjico3DOwvArKm8Zq1o7kqbTw g5Yw== X-Gm-Message-State: ALoCoQk2dng9tFQpvVl/F+0Oy6gNcihN2kal47pN+Cir2zAl1ryu5/OsOQ9alwyQxe1L6b+QpNyZ X-Received: by 10.50.56.10 with SMTP id w10mr14138403igp.3.1437651327507; Thu, 23 Jul 2015 04:35:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Thu, 23 Jul 2015 04:34:58 -0700 (PDT) In-Reply-To: References: <003a01d0c47c$9e2b96f0$da82c4d0$@augustcellars.com> <55AF9228.9030805@tzi.org> From: Brian Campbell Date: Thu, 23 Jul 2015 13:34:58 +0200 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=089e0158b064b001b9051b894811 Archived-At: Cc: Mike Jones , "cose@ietf.org" , Carsten Bormann , Jim Schaad Subject: Re: [COSE] Replacement of the term "Key Management" 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, 23 Jul 2015 11:35:31 -0000 --089e0158b064b001b9051b894811 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable One could reasonably consider agreement as a kind of conveyance, no? I did anyway. But my grasp of language is known to be suspect so perhaps my interpretation isn't one to rely on. Maybe key establishment is a better term. On Thu, Jul 23, 2015 at 12:40 PM, John Bradley wrote: > How about content key establishment. Is it always conveyed and never > agreed? I don't care deeply and can live with Conveyance. > > John B. > > Sent from my iPhone > > On Jul 23, 2015, at 7:00 AM, Mike Jones > wrote: > > That works for me too. > > -- Mike > ------------------------------ > From: Brian Campbell > Sent: =E2=80=8E7/=E2=80=8E23/=E2=80=8E2015 6:54 AM > To: Carsten Bormann > Cc: Jim Schaad ; cose@ietf.org > Subject: Re: [COSE] Replacement of the term "Key Management" > > I sort of like "Key Conveyance" > > > > On Wed, Jul 22, 2015 at 2:52 PM, Carsten Bormann wrote: > >> Key conveyance? >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> >> Jim Schaad wrote: >> > There is a problem with the document currently in that it uses the ter= m >> "Key >> > management" to deal with the general process of getting content >> encryption >> > keys from a sender to a recipient. I use this term because it is what >> I am >> > used to from CMS where the term is used for this purpose. >> > >> > When the charter was being written, the statement that we are not doin= g >> "Key >> > Management" was placed in into it as a statement that the COSE working >> group >> > is not doing Key Lifecycle protocols (i.e. how you distribute keys fro= m >> a >> > trusted server to a client or how pubic keys are transferred from a >> client >> > to a server with appropriate identity binding). >> > >> > This conflict needs to get resolved either by clarifying the charter o= r >> > changing the term that is being used in the document. I propose that >> we >> > switch from "Key Management" to "Content Key Management" in the >> document so >> > that it clear it is not lifecycle management. This term is correct fo= r >> two >> > deep messages and can be finessed for three deep messages which are no= t >> > expected to be used in any event. >> > >> > Do any other people have suggestions for a better term? >> > >> > Jim >> > >> > >> > _______________________________________________ >> > COSE mailing list >> > COSE@ietf.org >> > https://www.ietf.org/mailman/listinfo/cose >> >> > >> >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose >> >> > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > --089e0158b064b001b9051b894811 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One could reasonably consider agreement as a kind of conve= yance, no? I did anyway. But my grasp of language is known to be suspect so= perhaps my interpretation isn't one to rely on. Maybe key establishmen= t is a better term.

On Thu, Jul 23, 2015 at 12:40 PM, John Bradley <ve7jtb@ve7jtb.= com> wrote:
How about content key establishment. =C2=A0 Is it always conveyed a= nd never agreed?=C2=A0 I don't care deeply and can live with Conveyance= . =C2=A0

John B. =C2=A0

Sent from my iPhone=

On Jul 23, 2015, at 7:00 AM, Mike Jon= es <Mic= hael.Jones@microsoft.com> wrote:

That works for= me too.

-- Mike
From: Brian Campbell
Sent: =E2=80= =8E7/=E2=80=8E23/=E2=80=8E2015 6:54 AM
To: Carsten Bormann
Cc: Jim Schaad; cose@ietf.org=
Subject: Re: [C= OSE] Replacement of the term "Key Management"

I sort of like "Key Conveyance"



On Wed, Jul 22, 2015 at 2:52 PM, Carsten Bormann= <cabo@tzi.org><= /span> wrote:
Key conveyance?

Gr=C3=BC=C3=9Fe, Carsten


Jim Schaad wrote:
> There is a problem with the document currently in that it uses the ter= m "Key
> management" to deal with the general process of getting content e= ncryption
> keys from a sender to a recipient.=C2=A0 I use this term because it is= what I am
> used to from CMS where the term is used for this purpose.
>
> When the charter was being written, the statement that we are not doin= g "Key
> Management" was placed in into it as a statement that the COSE wo= rking group
> is not doing Key Lifecycle protocols (i.e. how you distribute keys fro= m a
> trusted server to a client or how pubic keys are transferred from a cl= ient
> to a server with appropriate identity binding).
>
> This conflict needs to get resolved either by clarifying the charter o= r
> changing the term that is being used in the document.=C2=A0 =C2=A0I pr= opose that we
> switch from "Key Management" to "Content Key Management= " in the document so
> that it clear it is not lifecycle management.=C2=A0 This term is corre= ct for two
> deep messages and can be finessed for three deep messages which are no= t
> expected to be used in any event.
>
> Do any other people have suggestions for a better term?
>
> Jim
>
>
> _______________________________________________
> COSE mailing list
> COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose
>

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

_______________________________________________
<= span>COSE mailing list
COSE@ietf.org
https://www.ietf= .org/mailman/listinfo/cose

--089e0158b064b001b9051b894811-- From nobody Thu Jul 23 05: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 9B6A51AC3C2 for ; Thu, 23 Jul 2015 05:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 gPM1UmbW4T1x for ; Thu, 23 Jul 2015 05:54:32 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D7621AC445 for ; Thu, 23 Jul 2015 05:54:06 -0700 (PDT) Received: by igr7 with SMTP id 7so93221688igr.0 for ; Thu, 23 Jul 2015 05:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=D624xkcpbvmdqKESJYU1sp1inmbEm0zT5jWtn1GpZhU=; b=UPS8QOCbIMEbCziofNYrtAjZ63pwX7DwWIfhtwewfbeNkVdis2O+kEXUZftutT/pic kMGJtw616w1ZNQPfhlptE7mzDdkEbcZ9u8/UQr7a0DVqz7KlIA5VWjzMZSdj8AbwmuYm KromZ+nJf2fqu60lgLKCg+YN/WQwI9J65DwhI= 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=D624xkcpbvmdqKESJYU1sp1inmbEm0zT5jWtn1GpZhU=; b=JTsOB7gRaD2GN+O7R8lKLGQeScCKS1EV7sh6EaRjtEe7NPxCsH8i6+1iZ1aE2tIPDz kmk8mi4D3leGXOzo7yYxmkovN1ybA48SaLixWzGtDds57B8GP7TNi0cr9COTqftzRpEO rq2KRSmz4x/HuKXJ8LQ++Tkum/pBcriXBDG9dXeoiKkgtu3hYct+UQ7Z+X8jlzbNVssl /ZCpig6w3ZlLtt27+NxRyVCDGd6UQdVILEBLfFX/6RKhSF5Xc8w3MxToJL7P4s3nOYhH QSRUA7gqXMIbpPF92a61EEimUDqhzQhgNqNy2K/wSw+egDF/lMAVtbONFNKqOmhal/Ta JnJw== X-Gm-Message-State: ALoCoQmMHQ2J2ffdgZeEj524soqqu6tYndzd0Rw7lhOrsliKOfzXRIdSA3fmae/ih94iY+jxm4ui X-Received: by 10.50.111.231 with SMTP id il7mr43162343igb.23.1437656046070; Thu, 23 Jul 2015 05:54:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Thu, 23 Jul 2015 05:53:36 -0700 (PDT) In-Reply-To: References: <003a01d0c47c$9e2b96f0$da82c4d0$@augustcellars.com> <55AF9228.9030805@tzi.org> From: Brian Campbell Date: Thu, 23 Jul 2015 14:53:36 +0200 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=047d7b4142c8ef98fd051b8a615c Archived-At: Cc: Mike Jones , "cose@ietf.org" , Carsten Bormann , Jim Schaad Subject: Re: [COSE] Replacement of the term "Key Management" 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, 23 Jul 2015 12:54:34 -0000 --047d7b4142c8ef98fd051b8a615c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable RFC 4949 , which I only just learned about from overhearing it mentioned in the saag meeting, has the text below for "key establishment". The second definition seems to fit for COSE. It seems a fine color for the bikeshed. $ key establishment (algorithm or protocol) 1. (I) A procedure that combines the key-generation and key- distribution steps needed to set up or install a secure communication association. 2. (I) A procedure that results in keying material being shared among two or more system entities. [A9042 , SP56 ] Tutorial: The two basic techniques for key establishment are "key agreement" and "key transport". On Thu, Jul 23, 2015 at 1:34 PM, Brian Campbell wrote: > One could reasonably consider agreement as a kind of conveyance, no? I di= d > anyway. But my grasp of language is known to be suspect so perhaps my > interpretation isn't one to rely on. Maybe key establishment is a better > term. > > On Thu, Jul 23, 2015 at 12:40 PM, John Bradley wrote: > >> How about content key establishment. Is it always conveyed and never >> agreed? I don't care deeply and can live with Conveyance. >> >> John B. >> >> Sent from my iPhone >> >> On Jul 23, 2015, at 7:00 AM, Mike Jones >> wrote: >> >> That works for me too. >> >> -- Mike >> ------------------------------ >> From: Brian Campbell >> Sent: =E2=80=8E7/=E2=80=8E23/=E2=80=8E2015 6:54 AM >> To: Carsten Bormann >> Cc: Jim Schaad ; cose@ietf.org >> Subject: Re: [COSE] Replacement of the term "Key Management" >> >> I sort of like "Key Conveyance" >> >> >> >> On Wed, Jul 22, 2015 at 2:52 PM, Carsten Bormann wrote: >> >>> Key conveyance? >>> >>> Gr=C3=BC=C3=9Fe, Carsten >>> >>> >>> Jim Schaad wrote: >>> > There is a problem with the document currently in that it uses the >>> term "Key >>> > management" to deal with the general process of getting content >>> encryption >>> > keys from a sender to a recipient. I use this term because it is wha= t >>> I am >>> > used to from CMS where the term is used for this purpose. >>> > >>> > When the charter was being written, the statement that we are not >>> doing "Key >>> > Management" was placed in into it as a statement that the COSE workin= g >>> group >>> > is not doing Key Lifecycle protocols (i.e. how you distribute keys >>> from a >>> > trusted server to a client or how pubic keys are transferred from a >>> client >>> > to a server with appropriate identity binding). >>> > >>> > This conflict needs to get resolved either by clarifying the charter = or >>> > changing the term that is being used in the document. I propose tha= t >>> we >>> > switch from "Key Management" to "Content Key Management" in the >>> document so >>> > that it clear it is not lifecycle management. This term is correct >>> for two >>> > deep messages and can be finessed for three deep messages which are n= ot >>> > expected to be used in any event. >>> > >>> > Do any other people have suggestions for a better term? >>> > >>> > Jim >>> > >>> > >>> > _______________________________________________ >>> > COSE mailing list >>> > COSE@ietf.org >>> > https://www.ietf.org/mailman/listinfo/cose >>> >>> > >>> >>> _______________________________________________ >>> COSE mailing list >>> COSE@ietf.org >>> https://www.ietf.org/mailman/listinfo/cose >>> >>> >> >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose >> >> > --047d7b4142c8ef98fd051b8a615c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Jul 23, 2015 at = 1:34 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
One could reaso= nably consider agreement as a kind of conveyance, no? I did anyway. But my = grasp of language is known to be suspect so perhaps my interpretation isn&#= 39;t one to rely on. Maybe key establishment is a better term.

On Thu, Jul 23, 2015 at 12:40 PM, John Bradley <ve7jtb= @ve7jtb.com> wrote:
How about content key establishment. =C2=A0 Is it always co= nveyed and never agreed?=C2=A0 I don't care deeply and can live with Co= nveyance. =C2=A0

John B. =C2=A0

Sent from m= y iPhone

On Jul 23, 2015, at 7:00 AM, Mike Jones &l= t;Michael.= Jones@microsoft.com> wrote:

<= div>
That works for= me too.

-- Mike
From: Brian Campbell
Sent: =E2=80= =8E7/=E2=80=8E23/=E2=80=8E2015 6:54 AM
To: Carsten Bormann
Cc: Jim Schaad; cose@ietf.org=
Subject: Re: [C= OSE] Replacement of the term "Key Management"

I sort of like "Key Conveyance"



On Wed, Jul 22, 2015 at 2:52 PM, Carsten Bormann= <cabo@tzi.org><= /span> wrote:
Key conveyance?

Gr=C3=BC=C3=9Fe, Carsten


Jim Schaad wrote:
> There is a problem with the document currently in that it uses the ter= m "Key
> management" to deal with the general process of getting content e= ncryption
> keys from a sender to a recipient.=C2=A0 I use this term because it is= what I am
> used to from CMS where the term is used for this purpose.
>
> When the charter was being written, the statement that we are not doin= g "Key
> Management" was placed in into it as a statement that the COSE wo= rking group
> is not doing Key Lifecycle protocols (i.e. how you distribute keys fro= m a
> trusted server to a client or how pubic keys are transferred from a cl= ient
> to a server with appropriate identity binding).
>
> This conflict needs to get resolved either by clarifying the charter o= r
> changing the term that is being used in the document.=C2=A0 =C2=A0I pr= opose that we
> switch from "Key Management" to "Content Key Management= " in the document so
> that it clear it is not lifecycle management.=C2=A0 This term is corre= ct for two
> deep messages and can be finessed for three deep messages which are no= t
> expected to be used in any event.
>
> Do any other people have suggestions for a better term?
>
> Jim
>
>
> _______________________________________________
> COSE mailing list
> COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose
>

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

_______________________________________________
COSE mai= ling list
COSE@ietf.org
https://www.ietf.org/mailman/= listinfo/cose

--047d7b4142c8ef98fd051b8a615c-- From nobody Thu Jul 23 06:01:06 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 0C7DC1A0217 for ; Thu, 23 Jul 2015 06:01:05 -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 xi4nGKqEYQ2I for ; Thu, 23 Jul 2015 06:01:02 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96BDE1AC3C4 for ; Thu, 23 Jul 2015 06:01:02 -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 t6ND0qG4025338; Thu, 23 Jul 2015 15:00:52 +0200 (CEST) Received: from alma.local (unknown [IPv6:2001:67c:370:152:dc0a:11a3:c52a:7c28]) (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 3mcYgS1kDYzDMRP; Thu, 23 Jul 2015 15:00:52 +0200 (CEST) Message-ID: <55B0E582.6060007@tzi.org> Date: Thu, 23 Jul 2015 15:00:50 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.1 (Macintosh/20150514) MIME-Version: 1.0 To: Brian Campbell References: <003a01d0c47c$9e2b96f0$da82c4d0$@augustcellars.com> <55AF9228.9030805@tzi.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: John Bradley , Mike Jones , Jim Schaad , "cose@ietf.org" Subject: Re: [COSE] Replacement of the term "Key Management" 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, 23 Jul 2015 13:01:05 -0000 "Key establishment" sounds like the establishment of state. That is the "management" that the charter tries to exclude. I was trying to find a term that expresses the statelessness of the expression of the key within the COSE object. But, of course, I also ultimately don't care, as long as we don't use the no-no term "key management". Grüße, Carsten Brian Campbell wrote: > RFC 4949 , which I only just > learned about from overhearing it mentioned in the saag meeting, has the > text below for "key establishment". The second definition seems to fit > for COSE. It seems a fine color for the bikeshed. > > $ key establishment (algorithm or protocol) > 1. (I) A procedure that combines the key-generation and key- > distribution steps needed to set up or install a secure > communication association. > > 2. (I) A procedure that results in keying material being shared > among two or more system entities. [A9042 , SP56 ] > > Tutorial: The two basic techniques for key establishment are "key > agreement" and "key transport". > > > > On Thu, Jul 23, 2015 at 1:34 PM, Brian Campbell > > wrote: > > One could reasonably consider agreement as a kind of conveyance, no? > I did anyway. But my grasp of language is known to be suspect so > perhaps my interpretation isn't one to rely on. Maybe key > establishment is a better term. > > On Thu, Jul 23, 2015 at 12:40 PM, John Bradley > wrote: > > How about content key establishment. Is it always conveyed and > never agreed? I don't care deeply and can live with Conveyance. > > John B. > > Sent from my iPhone > > On Jul 23, 2015, at 7:00 AM, Mike Jones > > wrote: > >> That works for me too. >> >> -- Mike >> ------------------------------------------------------------------------ >> From: Brian Campbell >> Sent: ‎7/‎23/‎2015 6:54 AM >> To: Carsten Bormann >> Cc: Jim Schaad ; cose@ietf.org >> >> Subject: Re: [COSE] Replacement of the term "Key Management" >> >> I sort of like "Key Conveyance" >> >> >> >> On Wed, Jul 22, 2015 at 2:52 PM, Carsten Bormann > > wrote: >> >> Key conveyance? >> >> Grüße, Carsten >> >> >> Jim Schaad wrote: >> > There is a problem with the document currently in that >> it uses the term "Key >> > management" to deal with the general process of getting >> content encryption >> > keys from a sender to a recipient. I use this term >> because it is what I am >> > used to from CMS where the term is used for this purpose. >> > >> > When the charter was being written, the statement that >> we are not doing "Key >> > Management" was placed in into it as a statement that >> the COSE working group >> > is not doing Key Lifecycle protocols (i.e. how you >> distribute keys from a >> > trusted server to a client or how pubic keys are >> transferred from a client >> > to a server with appropriate identity binding). >> > >> > This conflict needs to get resolved either by clarifying >> the charter or >> > changing the term that is being used in the document. >> I propose that we >> > switch from "Key Management" to "Content Key Management" >> in the document so >> > that it clear it is not lifecycle management. This term >> is correct for two >> > deep messages and can be finessed for three deep >> messages which are not >> > expected to be used in any event. >> > >> > Do any other people have suggestions for a better term? >> > >> > Jim >> > >> > >> > _______________________________________________ >> > COSE mailing list >> > COSE@ietf.org >> > https://www.ietf.org/mailman/listinfo/cose >> >> > >> >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose >> >> >> >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose > > > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Tue Jul 28 06:55:23 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 9EC561A90F1 for ; Tue, 28 Jul 2015 06:55:13 -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 9SSWCY-7wMBK for ; Tue, 28 Jul 2015 06:55:09 -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 C37021A8F34 for ; Tue, 28 Jul 2015 06:55:08 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (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 B554B38F1F for ; Tue, 28 Jul 2015 06:55:07 -0700 (PDT) From: "Jim Schaad" To: Date: Tue, 28 Jul 2015 06:55:31 -0700 Message-ID: <022201d0c93d$123c15a0$36b440e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AdDJOTZf1+B4RKv7Q5WcMb0pibKXcw== Archived-At: Subject: [COSE] Arrays vs maps at the top level 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, 28 Jul 2015 13:55:13 -0000 As I stated in a previous response to Carsten that I was keeping the question of arrays vs maps at the top level because I felt that there was not a lot of strong arguments either way and it was a bit of a weak consensus. There have been a number of changes that we have made that have changed the number of bytes of overhead. This may change some people's opinions. The overhead differences are now as follows: MAP ARRAY Direct Encryption 12 10 Signature 12 10 MAC Direct 14 11 The removal of AAD, IV and TAG as independent fields makes the array size smaller in those cases where it is not used. The shrinkage is less for MAP since the assumption of them not being there for recipient structures was already built in. The last time I did this analysis the sizes were basically equal. There is now an advantage for arrays in all cases. For encryption and mac - going from direct to any other key management technique will increase the size of MAP w/o a corresponding increase in the size of Array since all fields already exist for it. Based on implementation experience, I have also found that doing the array version is much simpler from a couple of perspectives. - It is much easier to look at the array to see what is and what is not present than for maps. This has become very true with the loss of text labels since the tag 1 is not unique. It means different things in different places. This makes things harder to look at. - It is easier to get a comparison routine working correctly. Since maps are randomly placed but arrays are fixed, it is simpler to do automated comparisons. There may still be issues with the protected/unprotected maps. But that is more likely to be under the program than library control so it is easier to control from the outside. There are still issues where one may need to do sorting of these maps to do comparisons. However removing one layer of problems seems to be goodness. - At the f2f, Carsten raised the fact that for an array version, since the message type is in a fixed location, code can examine this value when it is in an array and processing can be aborted at an earlier point if the message structure type is not supported. Based on these arguments and the new numbers, I want to move back to arrays from maps for the top level objects. Jim From nobody Tue Jul 28 08:48:51 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 92BBF1ACD3A for ; Tue, 28 Jul 2015 08:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pP0rjQnAju-5 for ; Tue, 28 Jul 2015 08:48:46 -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 4B3311ACD30 for ; Tue, 28 Jul 2015 08:48: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.231.11; Tue, 28 Jul 2015 15:48:30 +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.0231.011; Tue, 28 Jul 2015 15:48:30 +0000 From: Mike Jones To: Jim Schaad , "cose@ietf.org" Thread-Topic: [COSE] Arrays vs maps at the top level Thread-Index: AdDJOTZf1+B4RKv7Q5WcMb0pibKXcwAE6Mc3 Date: Tue, 28 Jul 2015 15:48:29 +0000 Message-ID: References: <022201d0c93d$123c15a0$36b440e0$@augustcellars.com> In-Reply-To: <022201d0c93d$123c15a0$36b440e0$@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:M1B1zOr76km+GATF7IfJ3W/RQo10ZFqIXiE2S7TXdsrtVTHI4FVRG7wAS+/Pi+HbOdHLK8PCU1dGqVGWDLUB8PrXAauAYNKznJOtG1wMfmEvmieVvZdNB+bVgdx9Sn4szSvU422KL4zsuuD9OSl6Hw==; 24:A0cf18ug5nEgDno24UaYDsJdte3qJSBqJ3wQJKmXsH+/nz62Vg21py88cU9YovyWOmKzqfURmNnQi0koy5UTWBn9n4aDmxDgmWPfCbQxsSg=; 20:RNVvwhQm0SdK61y9NDMV3Xof8SQ4yM+7jSpVzOlanPihT48QhEs2aunqnqMUM4hyZxCEjKRSa9/T9dIWLNdAjg== 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: 06515DA04B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(76576001)(66066001)(86362001)(16236675004)(33656002)(76176999)(19625215002)(19617315012)(107886002)(99286002)(2501003)(10090500001)(5001770100001)(5001960100002)(46102003)(102836002)(77096005)(122556002)(40100003)(54356999)(2656002)(575784001)(5003600100002)(87936001)(77156002)(5002640100001)(15975445007)(50986999)(62966003)(92566002)(189998001)(2950100001)(2900100001)(74316001)(19580395003)(19580405001); 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_BY2PR03MB44213ACC2D7FB912D7E0889F58D0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2015 15:48:29.9683 (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: Re: [COSE] Arrays vs maps at the top level 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, 28 Jul 2015 15:48:49 -0000 --_000_BY2PR03MB44213ACC2D7FB912D7E0889F58D0BY2PR03MB442namprd_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Sounds reasonable. What would the structure of the top level arrays be? -- Mike ________________________________ From: Jim Schaad Sent: =FD7/=FD28/=FD2015 6:55 AM To: cose@ietf.org Subject: [COSE] Arrays vs maps at the top level As I stated in a previous response to Carsten that I was keeping the question of arrays vs maps at the top level because I felt that there was not a lot of strong arguments either way and it was a bit of a weak consensus. There have been a number of changes that we have made that have changed the number of bytes of overhead. This may change some people's opinions. The overhead differences are now as follows: MAP ARRAY Direct Encryption 12 10 Signature 12 10 MAC Direct 14 11 The removal of AAD, IV and TAG as independent fields makes the array size smaller in those cases where it is not used. The shrinkage is less for MAP since the assumption of them not being there for recipient structures was already built in. The last time I did this analysis the sizes were basically equal. There is now an advantage for arrays in all cases. For encryption and mac - going from direct to any other key management techniqu= e will increase the size of MAP w/o a corresponding increase in the size of Array since all fields already exist for it. Based on implementation experience, I have also found that doing the array version is much simpler from a couple of perspectives. - It is much easier to look at the array to see what is and what is not present than for maps. This has become very true with the loss of text labels since the tag 1 is not unique. It means different things in different places. This makes things harder to look at. - It is easier to get a comparison routine working correctly. Since maps are randomly placed but arrays are fixed, it is simpler to do automated comparisons. There may still be issues with the protected/unprotected maps. But that is more likely to be under the program than library control so it is easier to control from the outside. There are still issues where one may need to do sorting of these maps to do comparisons. However removing one layer of problems seems to be goodness. - At the f2f, Carsten raised the fact that for an array version, since the message type is in a fixed location, code can examine this value when it is in an array and processing can be aborted at an earlier point if the messag= e structure type is not supported. Based on these arguments and the new numbers, I want to move back to arrays from maps for the top level objects. Jim _______________________________________________ COSE mailing list COSE@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.Jones%40microsoft= .com%7c8f8e25f384c34d399a5e08d297542ef3%7c72f988bf86f141af91ab2d7cd011db47%= 7c1&sdata=3DosT3Dn21g%2flV0L0erjQCWZsUxVoBNYRhRqCfN7cvRmM%3d --_000_BY2PR03MB44213ACC2D7FB912D7E0889F58D0BY2PR03MB442namprd_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Sounds reason= able. What would the structure of the top level arrays be?

-- Mike
From: Jim Schaad
Sent: =FD7/= =FD28/=FD2015 6:55 AM
To: cose@ietf.org
Subject: [COSE= ] Arrays vs maps at the top level

As I stated in a previous response to Carsten that= I was keeping the
question of arrays vs maps at the top level because I felt that there was not a lot of strong arguments either way and it was a bit of a weak
consensus.

There have been a number of changes that we have made that have changed the=
number of bytes of overhead.  This may change some people's opinions.&= nbsp; The
overhead differences are now as follows:

            &nb= sp;           MAP &n= bsp;           ARRAY
Direct Encryption       12   &= nbsp;          10
Signature           =     12         =      10
MAC Direct           = ;   14          = ;    11

The removal of AAD, IV and TAG as independent fields makes the array size smaller in those cases where it is not used.  The shrinkage is less fo= r MAP
since the assumption of them not being there for recipient structures was already built in.   The last time I did this analysis the sizes w= ere
basically equal.  There is now an advantage for arrays in all cases.&n= bsp; For
encryption and mac - going from direct to any other key management techniqu= e
will increase the size of MAP w/o a corresponding increase in the size of Array since all fields already exist for it.

Based on implementation experience, I have also found that doing the array<= br> version is much simpler from a couple of perspectives.

- It is much easier to look at the array to see what is and what is not
present than for maps.  This has become very true with the loss of tex= t
labels since the tag 1 is not unique.  It means different things in different places.  This makes things harder to look at.

- It is easier to get a comparison routine working correctly.  Since m= aps
are randomly placed but arrays are fixed, it is simpler to do automated
comparisons.   There may still be issues with the protected/unpro= tected
maps.  But that is more likely to be under the program than library co= ntrol
so it is easier to control from the outside.  There are still issues w= here
one may need to do sorting of these maps to do comparisons.  However removing one layer of problems seems to be goodness.

- At the f2f, Carsten raised the fact that for an array version, since the<= br> message type is in a fixed location, code can examine this value when it is=
in an array and processing can be aborted at an earlier point if the messag= e
structure type is not supported.

Based on these arguments and the new numbers, I want to move back to arrays=
from maps for the top level objects.

Jim



_______________________________________________
COSE mailing list
COSE@ietf.org
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fww= w.ietf.org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichael.Jones%4= 0microsoft.com%7c8f8e25f384c34d399a5e08d297542ef3%7c72f988bf86f141af91ab2d7= cd011db47%7c1&sdata=3DosT3Dn21g%2flV0L0erjQCWZsUxVoBNYRhRqCfN7cvRmM%3d<= /a>
 --_000_BY2PR03MB44213ACC2D7FB912D7E0889F58D0BY2PR03MB442namprd_-- From nobody Tue Jul 28 09:33: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 AF4981ACDF5 for ; Tue, 28 Jul 2015 09:33:31 -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 qQjv--02o5TL for ; Tue, 28 Jul 2015 09:33:29 -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 463F51ACDF2 for ; Tue, 28 Jul 2015 09:33:29 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (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 6294438F02; Tue, 28 Jul 2015 09:33:28 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , References: <022201d0c93d$123c15a0$36b440e0$@augustcellars.com> In-Reply-To: Date: Tue, 28 Jul 2015 09:33:52 -0700 Message-ID: <026601d0c953$3128cb50$937a61f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0267_01D0C918.84CDC3E0" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQEINhblT3H2MKFRpgnHLaMPnVEXAwEDIOpgn3ohCkA= Archived-At: Subject: Re: [COSE] Arrays vs maps at the top level 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, 28 Jul 2015 16:33:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0267_01D0C918.84CDC3E0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable The only change in the grammar is from map to array. Nothing else is re-ordered. =20 From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 Sent: Tuesday, July 28, 2015 8:48 AM To: Jim Schaad; cose@ietf.org Subject: RE: [COSE] Arrays vs maps at the top level =20 Sounds reasonable. What would the structure of the top level arrays be? -- Mike _____ =20 From: Jim Schaad =20 Sent: =FD7/=FD28/=FD2015 6:55 AM To: cose@ietf.org =20 Subject: [COSE] Arrays vs maps at the top level As I stated in a previous response to Carsten that I was keeping the question of arrays vs maps at the top level because I felt that there = was not a lot of strong arguments either way and it was a bit of a weak consensus. There have been a number of changes that we have made that have changed = the number of bytes of overhead. This may change some people's opinions. = The overhead differences are now as follows: MAP ARRAY Direct Encryption 12 10 Signature 12 10 MAC Direct 14 11 The removal of AAD, IV and TAG as independent fields makes the array = size smaller in those cases where it is not used. The shrinkage is less for = MAP since the assumption of them not being there for recipient structures = was already built in. The last time I did this analysis the sizes were basically equal. There is now an advantage for arrays in all cases. = For encryption and mac - going from direct to any other key management = technique will increase the size of MAP w/o a corresponding increase in the size = of Array since all fields already exist for it. Based on implementation experience, I have also found that doing the = array version is much simpler from a couple of perspectives. - It is much easier to look at the array to see what is and what is not present than for maps. This has become very true with the loss of text labels since the tag 1 is not unique. It means different things in different places. This makes things harder to look at. - It is easier to get a comparison routine working correctly. Since = maps are randomly placed but arrays are fixed, it is simpler to do automated comparisons. There may still be issues with the protected/unprotected maps. But that is more likely to be under the program than library = control so it is easier to control from the outside. There are still issues = where one may need to do sorting of these maps to do comparisons. However removing one layer of problems seems to be goodness. - At the f2f, Carsten raised the fact that for an array version, since = the message type is in a fixed location, code can examine this value when it = is in an array and processing can be aborted at an earlier point if the = message structure type is not supported. Based on these arguments and the new numbers, I want to move back to = arrays from maps for the top level objects. Jim _______________________________________________ COSE mailing list COSE@ietf.org =20 https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie= tf.or g%2fmailman%2flistinfo%2fcose &data=3D01%7c01%7cMichael.Jones%40microsoft.com%7c8f8e25f384c34d399a5e08d= 29754 2ef3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DosT3Dn21g%2flV0L0erjQ= CWZsU xVoBNYRhRqCfN7cvRmM%3d ------=_NextPart_000_0267_01D0C918.84CDC3E0 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

The only change in the grammar is from map to array.=A0 Nothing else = is re-ordered.

 

From: Mike = Jones [mailto:Michael.Jones@microsoft.com]
Sent: Tuesday, = July 28, 2015 8:48 AM
To: Jim Schaad; = cose@ietf.org
Subject: RE: [COSE] Arrays vs maps at the top = level

 

Sounds = reasonable. What would the structure of the top level arrays = be?

-- Mike

From: = Jim Schaad
Sent: = =FD7/=FD28/= =FD2015 6:55 AM
To: = cose@ietf.org
Subject: = [COSE] = Arrays vs maps at the top level

As I stated in a = previous response to Carsten that I was keeping the
question of = arrays vs maps at the top level because I felt that there was
not a = lot of strong arguments either way and it was a bit of a = weak
consensus.

There have been a number of changes that we = have made that have changed the
number of bytes of overhead.  = This may change some people's opinions.  The
overhead = differences are now as = follows:

         &nb= sp;           &nbs= p;  = MAP           &nbs= p; ARRAY
Direct Encryption       = 12            = ;  = 10
Signature         &nbs= p;     = 12            = ;  10
MAC = Direct           &= nbsp;  = 14            = ;  11

The removal of AAD, IV and TAG as independent fields = makes the array size
smaller in those cases where it is not = used.  The shrinkage is less for MAP
since the assumption of = them not being there for recipient structures was
already built = in.   The last time I did this analysis the sizes = were
basically equal.  There is now an advantage for arrays in = all cases.  For
encryption and mac - going from direct to any = other key management technique
will increase the size of MAP w/o a = corresponding increase in the size of
Array since all fields already = exist for it.

Based on implementation experience, I have also = found that doing the array
version is much simpler from a couple of = perspectives.

- It is much easier to look at the array to see = what is and what is not
present than for maps.  This has become = very true with the loss of text
labels since the tag 1 is not = unique.  It means different things in
different places.  = This makes things harder to look at.

- It is easier to get a = comparison routine working correctly.  Since maps
are randomly = placed but arrays are fixed, it is simpler to do = automated
comparisons.   There may still be issues with the = protected/unprotected
maps.  But that is more likely to be under = the program than library control
so it is easier to control from the = outside.  There are still issues where
one may need to do = sorting of these maps to do comparisons.  However
removing one = layer of problems seems to be goodness.

- At the f2f, Carsten = raised the fact that for an array version, since the
message type is = in a fixed location, code can examine this value when it is
in an = array and processing can be aborted at an earlier point if the = message
structure type is not supported.

Based on these = arguments and the new numbers, I want to move back to arrays
from = maps for the top level = objects.

Jim



______________________________________= _________
COSE mailing list
COSE@ietf.org
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%= 2f%2fwww.ietf.org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichae= l.Jones%40microsoft.com%7c8f8e25f384c34d399a5e08d297542ef3%7c72f988bf86f1= 41af91ab2d7cd011db47%7c1&sdata=3DosT3Dn21g%2flV0L0erjQCWZsUxVoBNYRhRq= CfN7cvRmM%3d

------=_NextPart_000_0267_01D0C918.84CDC3E0-- From nobody Wed Jul 29 07:24:03 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 940771A6F27 for ; Wed, 29 Jul 2015 07:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 9r2ef-w7kdXd for ; Wed, 29 Jul 2015 07:23:56 -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 2A3731A21B1 for ; Wed, 29 Jul 2015 07:23:56 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (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 7A92738EFE for ; Wed, 29 Jul 2015 07:23:55 -0700 (PDT) From: "Jim Schaad" To: References: <022201d0c93d$123c15a0$36b440e0$@augustcellars.com> <026601d0c953$3128cb50$937a61f0$@augustcellars.com> In-Reply-To: <026601d0c953$3128cb50$937a61f0$@augustcellars.com> Date: Wed, 29 Jul 2015 07:24:19 -0700 Message-ID: <03d601d0ca0a$41d3d5f0$c57b81d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03D7_01D0C9CF.95760F60" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQEINhblT3H2MKFRpgnHLaMPnVEXAwEDIOpgAk2vEk+faSG3oA== Archived-At: Subject: Re: [COSE] Arrays vs maps at the top level 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, 29 Jul 2015 14:24:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03D7_01D0C9CF.95760F60 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable The set of changes can be found in pull request #61 =20 From: COSE [mailto:cose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Tuesday, July 28, 2015 9:34 AM To: 'Mike Jones'; cose@ietf.org Subject: Re: [COSE] Arrays vs maps at the top level =20 The only change in the grammar is from map to array. Nothing else is re-ordered. =20 From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 Sent: Tuesday, July 28, 2015 8:48 AM To: Jim Schaad; cose@ietf.org =20 Subject: RE: [COSE] Arrays vs maps at the top level =20 Sounds reasonable. What would the structure of the top level arrays be? -- Mike _____ =20 From: Jim Schaad =20 Sent: =FD7/=FD28/=FD2015 6:55 AM To: cose@ietf.org =20 Subject: [COSE] Arrays vs maps at the top level As I stated in a previous response to Carsten that I was keeping the question of arrays vs maps at the top level because I felt that there = was not a lot of strong arguments either way and it was a bit of a weak consensus. There have been a number of changes that we have made that have changed = the number of bytes of overhead. This may change some people's opinions. = The overhead differences are now as follows: MAP ARRAY Direct Encryption 12 10 Signature 12 10 MAC Direct 14 11 The removal of AAD, IV and TAG as independent fields makes the array = size smaller in those cases where it is not used. The shrinkage is less for = MAP since the assumption of them not being there for recipient structures = was already built in. The last time I did this analysis the sizes were basically equal. There is now an advantage for arrays in all cases. = For encryption and mac - going from direct to any other key management = technique will increase the size of MAP w/o a corresponding increase in the size = of Array since all fields already exist for it. Based on implementation experience, I have also found that doing the = array version is much simpler from a couple of perspectives. - It is much easier to look at the array to see what is and what is not present than for maps. This has become very true with the loss of text labels since the tag 1 is not unique. It means different things in different places. This makes things harder to look at. - It is easier to get a comparison routine working correctly. Since = maps are randomly placed but arrays are fixed, it is simpler to do automated comparisons. There may still be issues with the protected/unprotected maps. But that is more likely to be under the program than library = control so it is easier to control from the outside. There are still issues = where one may need to do sorting of these maps to do comparisons. However removing one layer of problems seems to be goodness. - At the f2f, Carsten raised the fact that for an array version, since = the message type is in a fixed location, code can examine this value when it = is in an array and processing can be aborted at an earlier point if the = message structure type is not supported. Based on these arguments and the new numbers, I want to move back to = arrays from maps for the top level objects. Jim _______________________________________________ COSE mailing list COSE@ietf.org =20 https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie= tf.or g%2fmailman%2flistinfo%2fcose &data=3D01%7c01%7cMichael.Jones%40microsoft.com%7c8f8e25f384c34d399a5e08d= 29754 2ef3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DosT3Dn21g%2flV0L0erjQ= CWZsU xVoBNYRhRqCfN7cvRmM%3d ------=_NextPart_000_03D7_01D0C9CF.95760F60 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

The set of changes can be found in pull request = #61

 

From: COSE = [mailto:cose-bounces@ietf.org] On Behalf Of Jim = Schaad
Sent: Tuesday, July 28, 2015 9:34 AM
To: = 'Mike Jones'; cose@ietf.org
Subject: Re: [COSE] Arrays vs maps = at the top level

 

The only change in the grammar is from map to array.  Nothing = else is re-ordered.

 

From: Mike = Jones [mailto:Michael.Jones@microsof= t.com]
Sent: Tuesday, July 28, 2015 8:48 AM
To: = Jim Schaad; cose@ietf.org
Subject: RE: = [COSE] Arrays vs maps at the top = level

 

Sounds = reasonable. What would the structure of the top level arrays = be?

-- Mike

From: = Jim Schaad
Sent: = =FD7/=FD28/= =FD2015 6:55 AM
To: = cose@ietf.org
Subject: = [COSE] = Arrays vs maps at the top level

As I stated in a = previous response to Carsten that I was keeping the
question of = arrays vs maps at the top level because I felt that there was
not a = lot of strong arguments either way and it was a bit of a = weak
consensus.

There have been a number of changes that we = have made that have changed the
number of bytes of overhead.  = This may change some people's opinions.  The
overhead = differences are now as = follows:

         &nb= sp;           &nbs= p;  = MAP           &nbs= p; ARRAY
Direct Encryption       = 12            = ;  = 10
Signature         &nbs= p;     = 12            = ;  10
MAC = Direct           &= nbsp;  = 14            = ;  11

The removal of AAD, IV and TAG as independent fields = makes the array size
smaller in those cases where it is not = used.  The shrinkage is less for MAP
since the assumption of = them not being there for recipient structures was
already built = in.   The last time I did this analysis the sizes = were
basically equal.  There is now an advantage for arrays in = all cases.  For
encryption and mac - going from direct to any = other key management technique
will increase the size of MAP w/o a = corresponding increase in the size of
Array since all fields already = exist for it.

Based on implementation experience, I have also = found that doing the array
version is much simpler from a couple of = perspectives.

- It is much easier to look at the array to see = what is and what is not
present than for maps.  This has become = very true with the loss of text
labels since the tag 1 is not = unique.  It means different things in
different places.  = This makes things harder to look at.

- It is easier to get a = comparison routine working correctly.  Since maps
are randomly = placed but arrays are fixed, it is simpler to do = automated
comparisons.   There may still be issues with the = protected/unprotected
maps.  But that is more likely to be under = the program than library control
so it is easier to control from the = outside.  There are still issues where
one may need to do = sorting of these maps to do comparisons.  However
removing one = layer of problems seems to be goodness.

- At the f2f, Carsten = raised the fact that for an array version, since the
message type is = in a fixed location, code can examine this value when it is
in an = array and processing can be aborted at an earlier point if the = message
structure type is not supported.

Based on these = arguments and the new numbers, I want to move back to arrays
from = maps for the top level = objects.

Jim



______________________________________= _________
COSE mailing list
COSE@ietf.org
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%= 2f%2fwww.ietf.org%2fmailman%2flistinfo%2fcose&data=3D01%7c01%7cMichae= l.Jones%40microsoft.com%7c8f8e25f384c34d399a5e08d297542ef3%7c72f988bf86f1= 41af91ab2d7cd011db47%7c1&sdata=3DosT3Dn21g%2flV0L0erjQCWZsUxVoBNYRhRq= CfN7cvRmM%3d

------=_NextPart_000_03D7_01D0C9CF.95760F60-- From nobody Thu Jul 30 14:40:05 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 AAB1A1ACE5E for ; Thu, 30 Jul 2015 14:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 w7ZGJH6R8KBT for ; Thu, 30 Jul 2015 14:40:03 -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 4AE4C1ACE71 for ; Thu, 30 Jul 2015 14:40:03 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (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 AE20B2CA36 for ; Thu, 30 Jul 2015 14:40:02 -0700 (PDT) From: "Jim Schaad" To: Date: Thu, 30 Jul 2015 14:40:26 -0700 Message-ID: <012401d0cb10$595321c0$0bf96540$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AdDLED50W9v0rNheRayu4lA/Ma3zGg== Archived-At: Subject: [COSE] Key Management is an ambiguous term 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, 30 Jul 2015 21:40:04 -0000 Github did not send this mail out. Issue #2 Key Management is an ambiguous term https://github.com/cose-wg/cose-issues/issues/2 The term "Key Management" is an ambiguous term and needs to either be clarified or removed from the message specification. The problem is that the charter also uses the term "Key Management" where it should have use the term "Key Lifecycle" or similar. This is a problem because we use the same term when dealing with how content keys are identified, transported or derived. However since the charter says that key management is out of scope we are going to get in trouble if we continue to use that term. To date the suggested replacements are: Content Key Management Key Conveyance Key Establishment None of them are good terms and there is no consensus on any of these terms. There is however consensus on "Pick one and go with it". People are free to add to the list in this issue. I will do some type of random choice unless I see one I really like on 15 August and just update the document. From nobody Thu Jul 30 15:32: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 80D061ACF60 for ; Thu, 30 Jul 2015 15:32:03 -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 m41xE_tQ8lpe for ; Thu, 30 Jul 2015 15:32:02 -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 6B79E1ACF58 for ; Thu, 30 Jul 2015 15:32:02 -0700 (PDT) Received: from hebrews (c-24-21-96-37.hsd1.or.comcast.net [24.21.96.37]) (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 D989F2CA3D for ; Thu, 30 Jul 2015 15:32:01 -0700 (PDT) From: "Jim Schaad" To: Date: Thu, 30 Jul 2015 15:32:25 -0700 Message-ID: <012901d0cb17$9c840b10$d58c2130$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AdDLFYVQBaFhIPMqQIC5i6cbL8YD+Q== Archived-At: Subject: [COSE] RSA Algorithm Decisions 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, 30 Jul 2015 22:32:03 -0000 I am currently in the process of updating/expanding the text for RSA. This message is what I am using the control the decision process. * The world of IoT is not interested (or so close to not interested) in using RSA that it could be ignored from that point of view. Therefore RSA is being included as for completeness as anything else. There may be some other items that port over and use RSA, but it is expected that most are going to use EC instead. * There is no legacy that needs to be supported for COSE. This means that there is no pressing need to support any of the RSA v1.5 algorithms. Any code that needs to have RSA can use the "modern" versions. * We do want to support both public keys and private keys in the COSE key structure. * There is sufficient reason to support all three if the "standard" SHA-2 hash algorithms with all of the RSA algorithms. This means that PSS and OAEP for SHA-256, SHA-384 and SHA-512. * As IoT does not have an interest in these algorithms, there is no reason to waste precious one byte algorithm identifiers on them. They will get two byte algorithm identifiers. If anyone has problems with this, please let me know. Jim
To dismiss that as argument from antecedent woul= d be to miss the main thrust of what was said.

There may well= be other reasons (those that you've cited) for lack of use of the JOSE= JSON serializations, but some of us anyway have seen significant real worl= d use of compact serializations of JOSE and have not encountered the need f= or the additional features offered by the JSON serializations.

I'm starting to fell as though I'm in the minority here, how= ever, so I'll eventually stop harping about it. I was just looking for = the WG to consider the value and success of the simpler side of JOSE.
<= br>

On Tue, Jul 7, 2015 at 4:57 PM, Jim Schaad <ietf@augustcellars.com= > wrote:

One needs to be careful with arguing from antecede= nt.=C2=A0 Beware of black swans.

=C2=A0

I can think of a number of reasons why JOSE is not = used.=C2=A0 The fact that everything is base64 encoded and that detached co= ntent are not enthusiastically supported are high among these.

=C2=A0=

I know that MILE glan= ced at using JOSE since they were thinking of moving to JSON, but the form = did not match how they were currently setup, and the base64 of all content = was a problem.

=C2=A0

I expect that the world of compact devices are going to want to do= something along the lines of RFC 4108 which does firmware update packages = in CMS.=C2=A0 This is likely to want multiple signatures and lots of binary= content.=C2=A0 Moving to JOSE is a problem on the second account and so wo= uld be unlikely to show up on anybody=E2=80=99s radar.=

=C2=A0<= /p>

My opinion is that if people = really care about having a =E2=80=9Cspecialized=E2=80=9D single recipient v= ersion, then by far the best course is to go back to using arrays at the to= p level and do the unrolling approach.=C2=A0 This is the smallest message s= ize and yet is still a simple way to decode things.=C2=A0 If we keep maps a= t the top level, I see no benefits of trying to have a single recipient ver= sion at the savings of a single =C2=A0byte in the message and additional co= mplications.=C2=A0 One can keep that extra message byte and say =E2=80=93 o= nly process the first recipient structure even if there are more than one.<= u>

= =C2=A0

From: Brian Campbell [mailto:<= a href=3D"mailto:bcampbell@pingidentity.com" target=3D"_blank">bcampbell@pi= ngidentity.com]
Sent: Wednesday, July 01, 2015 1:40 PM
To: Carsten Bormann
Cc: Jim Schaad; cose@ietf.org
Subject: Re: [= Cose] Issue: Encoding for a single recipient or structure

=C2=A0

In my own = experience with JOSE, the need for single recipient case is overwhelming ma= jority and the simplicity the compact serialization afforded for that case = are a major win. My own implementation supports only the compact serializat= ions (and thus only a single recipient or signature) and it is used widely = in my employer's products and services as well as being open source. No= one has ever even asked about the JSON serializations (which support multi= ple signatures/recipients).

I understand the allure of consisten= tly treating something that could have more than one thing as always potent= ially having more than one.

<= p class=3D"MsoNormal">But there is real value in making the most common cas= es simple, which shouldn't be discounted.

<= p class=3D"MsoNormal" style=3D"margin-bottom:12pt">=C2=A0

=

= =C2=A0

On Wed, Jul 1, 2015 at 1:12 AM= , Carsten Bormann <cab= o@tzi.org> wrote:

Ji= m Schaad wrote:
> If one believes that it is only for use in constrai= ned environments,
> then it is unlikely that there is a need for mult= iple recipients.

Actually, we do have scenarios with fan-out (both v= ia proxy and per
multicast), and those are actually a strong motivator f= or object security.

The minimal-bytes alternative is to mix in the m= ap entries for a single
recipient with those for the headers etc.=C2=A0 = Both JSON and CBOR do not
have a defined sequence of map entries, so thi= s means the recipient has
to piece the info together as it comes in.=C2= =A0 We'd also need a separate
set of labels.=C2=A0 Not my favorite.<= br>
If we keep together that map, what we could still do is turn

= =C2=A0 =C2=A0 =C2=A0 =C2=A0? recipients =3D> [+{COSE_encrypt_fields}]
back (we had something like that earlier) into

=C2=A0 =C2=A0 = =C2=A0 =C2=A0? recipients =3D> [+{COSE_encrypt_fields}] / {COSE_encrypt_= fields}

Saves that 0x81 byte in the single-receiver case.

Gr= =C3=BC=C3=9Fe, Carsten

_______________________________________________
Cose mailing list
<= a href=3D"mailto:Cose@ietf.org" target=3D"_blank">Cose@ietf.org
https:= //www.ietf.org/mailman/listinfo/cose

=C2=A0


--047d7b86d50216189e051a884976-- From nobody Fri Jul 10 10:01: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 109E01B2A44 for ; Fri, 10 Jul 2015 10:01:20 -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 fNGjFHnaal8A for ; Fri, 10 Jul 2015 10:01:18 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0104.outbound.protection.outlook.com [65.55.169.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFD481A0277 for ; Fri, 10 Jul 2015 10:01:17 -0700 (PDT) Received: from BL2PR03MB434.namprd03.prod.outlook.com (10.141.92.22) by BL2PR03MB562.namprd03.prod.outlook.com (10.141.91.27) with Microsoft SMTP Server (TLS) id 15.1.201.16; Fri, 10 Jul 2015 17:01:16 +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; Fri, 10 Jul 2015 17:01:15 +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; Fri, 10 Jul 2015 17:01:14 +0000 From: Mike Jones To: Brian Campbell , Jim Schaad Thread-Topic: [Cose] Issue: Encoding for a single recipient or structure Thread-Index: AdCDmTM3cpCIVDijSSWQU/yxCPpImgv5+bgAAAR4DgAAACbLYAABcMGAAAAkBNAAAG0fgAAGzAIAAAWjLoAAHDN3AAEyiT2AAIpUdgAAABKhEA== Date: Fri, 10 Jul 2015 17:01:14 +0000 Message-ID: References: <001b01d08399$434ab9b0$c9e02d10$@augustcellars.com> <009501d0b392$fb7cc680$f2765380$@augustcellars.com> <00d001d0b3b6$ce20f2f0$6a62d8d0$@augustcellars.com> <559392F7.30000@tzi.org> <000001d0b908$4d282d60$e7788820$@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: [50.47.90.173] x-microsoft-exchange-diagnostics: 1; BL2PR03MB434; 5:X+r/7UDYLNdMv35O7LiQO31f73601OI8zGyF+Ms4Gm4YTBFWh9+JV1BNSFC9EX0FNZOHDUPgH5fwO6rhr0KK3L0/4qLE5H36cYxoNpaY4QWOkfiL5xlpUaa1LxmEBQgmQkRSmIgyZa2aLTyYc8t6EA==; 24:2lUgoLR6Qy/adH/cl7Hxlt0loZ7d/C3TO7u/lt/UMHTwIzvYIMzjKVTyx5M0kD6gWjLwLAyARNzCvRTj4iPA+gdMp9WjCJvtvVR8esGwlTs=; 20:sxhdwLaAIjTLQMzABNN1AwZh1DqqNYp4d9eEz2EGgb19zSnHMxY4ZfJEPahje4JOWcbfvbFs2xHEi/SqURBsXg== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB434; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB562; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); 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: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(19580405001)(19580395003)(19609705001)(76176999)(54356999)(50986999)(46102003)(19625215002)(33656002)(74316001)(86362001)(2656002)(87936001)(92566002)(5002640100001)(76576001)(93886004)(2950100001)(16236675004)(2900100001)(5003600100002)(15975445007)(19300405004)(77096005)(5001960100002)(102836002)(189998001)(62966003)(77156002)(5001770100001)(19617315012)(66066001)(122556002)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB434; H:BL2PR03MB433.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BL2PR03MB4335BB434C6A02E49C4B003F59F0BL2PR03MB433namprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2015 17:01:14.7166 (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; BL2PR03MB562; 2:PcbfUMxxM5R1jpvLVXL3GyWJpnrTAzwFPd/WLVhJQ78BsuO7KcxmQMzZbft7ScD/; 3:JRM3dK5wh4qEgTpNrXlqSfpgHpvJsHygxWMVUXGux7q5J8aoE1AcYYs5XgnStmpwAGC5mc+i+UqOxsIouu5OrXPLwNd5c00Qbxy7MROLLD9oIkoa1y+Wego6TTcgF54eH+r/5jfRxNZV6d8fUTfx1A==; 25:e9NchRGcqMQw24t87WDRajq7aw8C9srGmaLx9hBAFYv+v/QRCtGs+O/9/3ae3UFP8wzxxEmtWRqQWIKlaaaPIG1TZA+T9SGrOX9T/gNxvk9T5mtLwcvCbnJfhoNqZlmLADaM0l279Ud03Cc3IsKhQd8CeLs9+0AbtFXwz928jtuVGaZs3tu1YKBW7CkRCgPVR6Bmm4t4PmqmmvQtuPq7U4ByG/Z30LT2KiFfOPp8j0nspUNUHonhlqqmuaCidHDYb1hCrLp539ejfHNPooKRmg==; 23:aJvtAMsU3hVb+PNTDrxe5jwejcc+Jx8TksGcPfsJRwbm9zPfgkfLfvA1Pwqs/SjfWNNDCv0AQqQlTY+6OUZxygQLTTPGJS7YufotfxNfxBPtxcwXjlrOT8RAsf9uxA13wbV66AdFOT8O3EymR2/3BvE8/hLeqDGenfschkLN+kUeBlvz1SfpoIM1XCJk9jqSmYoTzbOY1M2RY+LSa+yOdxZ9g1gg99jsGivK8wTr1L0UK9ax7a+KFoSrcS4D5j7Q X-OriginatorOrg: microsoft.com 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: Fri, 10 Jul 2015 17:01:21 -0000 --_000_BL2PR03MB4335BB434C6A02E49C4B003F59F0BL2PR03MB433namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IHRoaW5rIHlvdeKAmXJlIGluIHRoZSBtaW5vcml0eSwgQnJpYW4uICBJIHRoaW5r IHlvdeKAmXJlIGRvaW5nIGEgZ29vZCBqb2IgbWFraW5nIHRoZSBjYXNlIGZvciBzaW1wbGljaXR5 LCBhbmQgb3RoZXJzIGFyZSBoYXBweSB3aXRoIHlvdSB0YWtpbmcgdGhlIGxlYWQgaW4gdGhhdCBy ZWdhcmQuDQoNCkZyb206IENvc2UgW21haWx0bzpjb3NlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBCcmlhbiBDYW1wYmVsbA0KU2VudDogRnJpZGF5LCBKdWx5IDEwLCAyMDE1IDk6NTgg QU0NClRvOiBKaW0gU2NoYWFkDQpDYzogY29zZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtDb3Nl XSBJc3N1ZTogRW5jb2RpbmcgZm9yIGEgc2luZ2xlIHJlY2lwaWVudCBvciBzdHJ1Y3R1cmUNCg0K VG8gZGlzbWlzcyB0aGF0IGFzIGFyZ3VtZW50IGZyb20gYW50ZWNlZGVudCB3b3VsZCBiZSB0byBt aXNzIHRoZSBtYWluIHRocnVzdCBvZiB3aGF0IHdhcyBzYWlkLg0KVGhlcmUgbWF5IHdlbGwgYmUg b3RoZXIgcmVhc29ucyAodGhvc2UgdGhhdCB5b3UndmUgY2l0ZWQpIGZvciBsYWNrIG9mIHVzZSBv ZiB0aGUgSk9TRSBKU09OIHNlcmlhbGl6YXRpb25zLCBidXQgc29tZSBvZiB1cyBhbnl3YXkgaGF2 ZSBzZWVuIHNpZ25pZmljYW50IHJlYWwgd29ybGQgdXNlIG9mIGNvbXBhY3Qgc2VyaWFsaXphdGlv bnMgb2YgSk9TRSBhbmQgaGF2ZSBub3QgZW5jb3VudGVyZWQgdGhlIG5lZWQgZm9yIHRoZSBhZGRp dGlvbmFsIGZlYXR1cmVzIG9mZmVyZWQgYnkgdGhlIEpTT04gc2VyaWFsaXphdGlvbnMuDQpJJ20g c3RhcnRpbmcgdG8gZmVsbCBhcyB0aG91Z2ggSSdtIGluIHRoZSBtaW5vcml0eSBoZXJlLCBob3dl dmVyLCBzbyBJJ2xsIGV2ZW50dWFsbHkgc3RvcCBoYXJwaW5nIGFib3V0IGl0LiBJIHdhcyBqdXN0 IGxvb2tpbmcgZm9yIHRoZSBXRyB0byBjb25zaWRlciB0aGUgdmFsdWUgYW5kIHN1Y2Nlc3Mgb2Yg dGhlIHNpbXBsZXIgc2lkZSBvZiBKT1NFLg0KDQpPbiBUdWUsIEp1bCA3LCAyMDE1IGF0IDQ6NTcg UE0sIEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb208bWFpbHRvOmlldGZAYXVndXN0 Y2VsbGFycy5jb20+PiB3cm90ZToNCk9uZSBuZWVkcyB0byBiZSBjYXJlZnVsIHdpdGggYXJndWlu ZyBmcm9tIGFudGVjZWRlbnQuICBCZXdhcmUgb2YgYmxhY2sgc3dhbnMuDQoNCkkgY2FuIHRoaW5r IG9mIGEgbnVtYmVyIG9mIHJlYXNvbnMgd2h5IEpPU0UgaXMgbm90IHVzZWQuICBUaGUgZmFjdCB0 aGF0IGV2ZXJ5dGhpbmcgaXMgYmFzZTY0IGVuY29kZWQgYW5kIHRoYXQgZGV0YWNoZWQgY29udGVu dCBhcmUgbm90IGVudGh1c2lhc3RpY2FsbHkgc3VwcG9ydGVkIGFyZSBoaWdoIGFtb25nIHRoZXNl Lg0KDQpJIGtub3cgdGhhdCBNSUxFIGdsYW5jZWQgYXQgdXNpbmcgSk9TRSBzaW5jZSB0aGV5IHdl cmUgdGhpbmtpbmcgb2YgbW92aW5nIHRvIEpTT04sIGJ1dCB0aGUgZm9ybSBkaWQgbm90IG1hdGNo IGhvdyB0aGV5IHdlcmUgY3VycmVudGx5IHNldHVwLCBhbmQgdGhlIGJhc2U2NCBvZiBhbGwgY29u dGVudCB3YXMgYSBwcm9ibGVtLg0KDQpJIGV4cGVjdCB0aGF0IHRoZSB3b3JsZCBvZiBjb21wYWN0 IGRldmljZXMgYXJlIGdvaW5nIHRvIHdhbnQgdG8gZG8gc29tZXRoaW5nIGFsb25nIHRoZSBsaW5l cyBvZiBSRkMgNDEwOCB3aGljaCBkb2VzIGZpcm13YXJlIHVwZGF0ZSBwYWNrYWdlcyBpbiBDTVMu ICBUaGlzIGlzIGxpa2VseSB0byB3YW50IG11bHRpcGxlIHNpZ25hdHVyZXMgYW5kIGxvdHMgb2Yg YmluYXJ5IGNvbnRlbnQuICBNb3ZpbmcgdG8gSk9TRSBpcyBhIHByb2JsZW0gb24gdGhlIHNlY29u ZCBhY2NvdW50IGFuZCBzbyB3b3VsZCBiZSB1bmxpa2VseSB0byBzaG93IHVwIG9uIGFueWJvZHni gJlzIHJhZGFyLg0KDQpNeSBvcGluaW9uIGlzIHRoYXQgaWYgcGVvcGxlIHJlYWxseSBjYXJlIGFi b3V0IGhhdmluZyBhIOKAnHNwZWNpYWxpemVk4oCdIHNpbmdsZSByZWNpcGllbnQgdmVyc2lvbiwg dGhlbiBieSBmYXIgdGhlIGJlc3QgY291cnNlIGlzIHRvIGdvIGJhY2sgdG8gdXNpbmcgYXJyYXlz IGF0IHRoZSB0b3AgbGV2ZWwgYW5kIGRvIHRoZSB1bnJvbGxpbmcgYXBwcm9hY2guICBUaGlzIGlz IHRoZSBzbWFsbGVzdCBtZXNzYWdlIHNpemUgYW5kIHlldCBpcyBzdGlsbCBhIHNpbXBsZSB3YXkg dG8gZGVjb2RlIHRoaW5ncy4gIElmIHdlIGtlZXAgbWFwcyBhdCB0aGUgdG9wIGxldmVsLCBJIHNl ZSBubyBiZW5lZml0cyBvZiB0cnlpbmcgdG8gaGF2ZSBhIHNpbmdsZSByZWNpcGllbnQgdmVyc2lv biBhdCB0aGUgc2F2aW5ncyBvZiBhIHNpbmdsZSAgYnl0ZSBpbiB0aGUgbWVzc2FnZSBhbmQgYWRk aXRpb25hbCBjb21wbGljYXRpb25zLiAgT25lIGNhbiBrZWVwIHRoYXQgZXh0cmEgbWVzc2FnZSBi eXRlIGFuZCBzYXkg4oCTIG9ubHkgcHJvY2VzcyB0aGUgZmlyc3QgcmVjaXBpZW50IHN0cnVjdHVy ZSBldmVuIGlmIHRoZXJlIGFyZSBtb3JlIHRoYW4gb25lLg0KDQpGcm9tOiBCcmlhbiBDYW1wYmVs bCBbbWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGlu Z2lkZW50aXR5LmNvbT5dDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMDEsIDIwMTUgMTo0MCBQTQ0K VG86IENhcnN0ZW4gQm9ybWFubg0KQ2M6IEppbSBTY2hhYWQ7IGNvc2VAaWV0Zi5vcmc8bWFpbHRv OmNvc2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0Nvc2VdIElzc3VlOiBFbmNvZGluZyBmb3Ig YSBzaW5nbGUgcmVjaXBpZW50IG9yIHN0cnVjdHVyZQ0KDQpJbiBteSBvd24gZXhwZXJpZW5jZSB3 aXRoIEpPU0UsIHRoZSBuZWVkIGZvciBzaW5nbGUgcmVjaXBpZW50IGNhc2UgaXMgb3ZlcndoZWxt aW5nIG1ham9yaXR5IGFuZCB0aGUgc2ltcGxpY2l0eSB0aGUgY29tcGFjdCBzZXJpYWxpemF0aW9u IGFmZm9yZGVkIGZvciB0aGF0IGNhc2UgYXJlIGEgbWFqb3Igd2luLiBNeSBvd24gaW1wbGVtZW50 YXRpb24gc3VwcG9ydHMgb25seSB0aGUgY29tcGFjdCBzZXJpYWxpemF0aW9ucyAoYW5kIHRodXMg b25seSBhIHNpbmdsZSByZWNpcGllbnQgb3Igc2lnbmF0dXJlKSBhbmQgaXQgaXMgdXNlZCB3aWRl bHkgaW4gbXkgZW1wbG95ZXIncyBwcm9kdWN0cyBhbmQgc2VydmljZXMgYXMgd2VsbCBhcyBiZWlu ZyBvcGVuIHNvdXJjZS4gTm8gb25lIGhhcyBldmVyIGV2ZW4gYXNrZWQgYWJvdXQgdGhlIEpTT04g c2VyaWFsaXphdGlvbnMgKHdoaWNoIHN1cHBvcnQgbXVsdGlwbGUgc2lnbmF0dXJlcy9yZWNpcGll bnRzKS4NCkkgdW5kZXJzdGFuZCB0aGUgYWxsdXJlIG9mIGNvbnNpc3RlbnRseSB0cmVhdGluZyBz b21ldGhpbmcgdGhhdCBjb3VsZCBoYXZlIG1vcmUgdGhhbiBvbmUgdGhpbmcgYXMgYWx3YXlzIHBv dGVudGlhbGx5IGhhdmluZyBtb3JlIHRoYW4gb25lLg0KQnV0IHRoZXJlIGlzIHJlYWwgdmFsdWUg aW4gbWFraW5nIHRoZSBtb3N0IGNvbW1vbiBjYXNlcyBzaW1wbGUsIHdoaWNoIHNob3VsZG4ndCBi ZSBkaXNjb3VudGVkLg0KDQoNCk9uIFdlZCwgSnVsIDEsIDIwMTUgYXQgMToxMiBBTSwgQ2Fyc3Rl biBCb3JtYW5uIDxjYWJvQHR6aS5vcmc8bWFpbHRvOmNhYm9AdHppLm9yZz4+IHdyb3RlOg0KSmlt IFNjaGFhZCB3cm90ZToNCj4gSWYgb25lIGJlbGlldmVzIHRoYXQgaXQgaXMgb25seSBmb3IgdXNl IGluIGNvbnN0cmFpbmVkIGVudmlyb25tZW50cywNCj4gdGhlbiBpdCBpcyB1bmxpa2VseSB0aGF0 IHRoZXJlIGlzIGEgbmVlZCBmb3IgbXVsdGlwbGUgcmVjaXBpZW50cy4NCg0KQWN0dWFsbHksIHdl IGRvIGhhdmUgc2NlbmFyaW9zIHdpdGggZmFuLW91dCAoYm90aCB2aWEgcHJveHkgYW5kIHBlcg0K bXVsdGljYXN0KSwgYW5kIHRob3NlIGFyZSBhY3R1YWxseSBhIHN0cm9uZyBtb3RpdmF0b3IgZm9y IG9iamVjdCBzZWN1cml0eS4NCg0KVGhlIG1pbmltYWwtYnl0ZXMgYWx0ZXJuYXRpdmUgaXMgdG8g bWl4IGluIHRoZSBtYXAgZW50cmllcyBmb3IgYSBzaW5nbGUNCnJlY2lwaWVudCB3aXRoIHRob3Nl IGZvciB0aGUgaGVhZGVycyBldGMuICBCb3RoIEpTT04gYW5kIENCT1IgZG8gbm90DQpoYXZlIGEg ZGVmaW5lZCBzZXF1ZW5jZSBvZiBtYXAgZW50cmllcywgc28gdGhpcyBtZWFucyB0aGUgcmVjaXBp ZW50IGhhcw0KdG8gcGllY2UgdGhlIGluZm8gdG9nZXRoZXIgYXMgaXQgY29tZXMgaW4uICBXZSdk IGFsc28gbmVlZCBhIHNlcGFyYXRlDQpzZXQgb2YgbGFiZWxzLiAgTm90IG15IGZhdm9yaXRlLg0K DQpJZiB3ZSBrZWVwIHRvZ2V0aGVyIHRoYXQgbWFwLCB3aGF0IHdlIGNvdWxkIHN0aWxsIGRvIGlz IHR1cm4NCg0KICAgICAgID8gcmVjaXBpZW50cyA9PiBbK3tDT1NFX2VuY3J5cHRfZmllbGRzfV0N Cg0KYmFjayAod2UgaGFkIHNvbWV0aGluZyBsaWtlIHRoYXQgZWFybGllcikgaW50bw0KDQogICAg ICAgPyByZWNpcGllbnRzID0+IFsre0NPU0VfZW5jcnlwdF9maWVsZHN9XSAvIHtDT1NFX2VuY3J5 cHRfZmllbGRzfQ0KDQpTYXZlcyB0aGF0IDB4ODEgYnl0ZSBpbiB0aGUgc2luZ2xlLXJlY2VpdmVy IGNhc2UuDQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkNvc2UgbWFpbGluZyBsaXN0DQpDb3NlQGlldGYub3JnPG1h aWx0bzpDb3NlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jb3NlDQoNCg0K --_000_BL2PR03MB4335BB434C6A02E49C4B003F59F0BL2PR03MB433namprd_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5JIGRvbuKAmXQgdGhpbmsgeW914oCZcmUgaW4gdGhlIG1pbm9yaXR5LCBCcmlhbi4mbmJz cDsgSSB0aGluayB5b3XigJlyZSBkb2luZyBhIGdvb2Qgam9iIG1ha2luZyB0aGUgY2FzZSBmb3Ig c2ltcGxpY2l0eSwgYW5kIG90aGVycyBhcmUgaGFwcHkgd2l0aCB5b3UgdGFraW5nIHRoZSBsZWFk DQogaW4gdGhhdCByZWdhcmQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiBDb3NlIFttYWlsdG86Y29zZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5CcmlhbiBDYW1wYmVsbDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1bHkgMTAsIDIw MTUgOTo1OCBBTTxicj4NCjxiPlRvOjwvYj4gSmltIFNjaGFhZDxicj4NCjxiPkNjOjwvYj4gY29z ZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0Nvc2VdIElzc3VlOiBFbmNvZGlu ZyBmb3IgYSBzaW5nbGUgcmVjaXBpZW50IG9yIHN0cnVjdHVyZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij5UbyBkaXNtaXNzIHRoYXQgYXMgYXJndW1lbnQgZnJvbSBhbnRlY2VkZW50IHdvdWxkIGJl IHRvIG1pc3MgdGhlIG1haW4gdGhydXN0IG9mIHdoYXQgd2FzIHNhaWQuDQo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij5UaGVyZSBtYXkgd2VsbCBiZSBvdGhlciByZWFzb25zICh0aG9zZSB0aGF0IHlvdSd2ZSBj aXRlZCkgZm9yIGxhY2sgb2YgdXNlIG9mIHRoZSBKT1NFIEpTT04gc2VyaWFsaXphdGlvbnMsIGJ1 dCBzb21lIG9mIHVzIGFueXdheSBoYXZlIHNlZW4gc2lnbmlmaWNhbnQgcmVhbCB3b3JsZCB1c2Ug b2YgY29tcGFjdCBzZXJpYWxpemF0aW9ucyBvZiBKT1NFIGFuZCBoYXZlDQogbm90IGVuY291bnRl cmVkIHRoZSBuZWVkIGZvciB0aGUgYWRkaXRpb25hbCBmZWF0dXJlcyBvZmZlcmVkIGJ5IHRoZSBK U09OIHNlcmlhbGl6YXRpb25zLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkknbSBzdGFydGlu ZyB0byBmZWxsIGFzIHRob3VnaCBJJ20gaW4gdGhlIG1pbm9yaXR5IGhlcmUsIGhvd2V2ZXIsIHNv IEknbGwgZXZlbnR1YWxseSBzdG9wIGhhcnBpbmcgYWJvdXQgaXQuIEkgd2FzIGp1c3QgbG9va2lu ZyBmb3IgdGhlIFdHIHRvIGNvbnNpZGVyIHRoZSB2YWx1ZSBhbmQgc3VjY2VzcyBvZiB0aGUgc2lt cGxlciBzaWRlIG9mIEpPU0UuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBKdWwgNywgMjAxNSBhdCA0OjU3IFBNLCBK aW0gU2NoYWFkICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmlldGZAYXVndXN0Y2VsbGFycy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T25lIG5lZWRzIHRvIGJlIGNhcmVmdWwg d2l0aCBhcmd1aW5nIGZyb20gYW50ZWNlZGVudC4mbmJzcDsgQmV3YXJlIG9mIGJsYWNrIHN3YW5z Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkkgY2FuIHRoaW5rIG9mIGEgbnVtYmVyIG9mIHJlYXNvbnMgd2h5IEpP U0UgaXMgbm90IHVzZWQuJm5ic3A7IFRoZSBmYWN0IHRoYXQgZXZlcnl0aGluZyBpcyBiYXNlNjQg ZW5jb2RlZA0KIGFuZCB0aGF0IGRldGFjaGVkIGNvbnRlbnQgYXJlIG5vdCBlbnRodXNpYXN0aWNh bGx5IHN1cHBvcnRlZCBhcmUgaGlnaCBhbW9uZyB0aGVzZS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGtub3cg dGhhdCBNSUxFIGdsYW5jZWQgYXQgdXNpbmcgSk9TRSBzaW5jZSB0aGV5IHdlcmUgdGhpbmtpbmcg b2YgbW92aW5nIHRvIEpTT04sIGJ1dCB0aGUgZm9ybSBkaWQNCiBub3QgbWF0Y2ggaG93IHRoZXkg d2VyZSBjdXJyZW50bHkgc2V0dXAsIGFuZCB0aGUgYmFzZTY0IG9mIGFsbCBjb250ZW50IHdhcyBh IHByb2JsZW0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBleHBlY3QgdGhhdCB0aGUgd29ybGQgb2YgY29tcGFj dCBkZXZpY2VzIGFyZSBnb2luZyB0byB3YW50IHRvIGRvIHNvbWV0aGluZyBhbG9uZyB0aGUgbGlu ZXMgb2YgUkZDDQogNDEwOCB3aGljaCBkb2VzIGZpcm13YXJlIHVwZGF0ZSBwYWNrYWdlcyBpbiBD TVMuJm5ic3A7IFRoaXMgaXMgbGlrZWx5IHRvIHdhbnQgbXVsdGlwbGUgc2lnbmF0dXJlcyBhbmQg bG90cyBvZiBiaW5hcnkgY29udGVudC4mbmJzcDsgTW92aW5nIHRvIEpPU0UgaXMgYSBwcm9ibGVt IG9uIHRoZSBzZWNvbmQgYWNjb3VudCBhbmQgc28gd291bGQgYmUgdW5saWtlbHkgdG8gc2hvdyB1 cCBvbiBhbnlib2R54oCZcyByYWRhci48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NeSBvcGluaW9uIGlzIHRoYXQg aWYgcGVvcGxlIHJlYWxseSBjYXJlIGFib3V0IGhhdmluZyBhIOKAnHNwZWNpYWxpemVk4oCdIHNp bmdsZSByZWNpcGllbnQgdmVyc2lvbiwgdGhlbg0KIGJ5IGZhciB0aGUgYmVzdCBjb3Vyc2UgaXMg dG8gZ28gYmFjayB0byB1c2luZyBhcnJheXMgYXQgdGhlIHRvcCBsZXZlbCBhbmQgZG8gdGhlIHVu cm9sbGluZyBhcHByb2FjaC4mbmJzcDsgVGhpcyBpcyB0aGUgc21hbGxlc3QgbWVzc2FnZSBzaXpl IGFuZCB5ZXQgaXMgc3RpbGwgYSBzaW1wbGUgd2F5IHRvIGRlY29kZSB0aGluZ3MuJm5ic3A7IElm IHdlIGtlZXAgbWFwcyBhdCB0aGUgdG9wIGxldmVsLCBJIHNlZSBubyBiZW5lZml0cyBvZiB0cnlp bmcgdG8gaGF2ZSBhDQogc2luZ2xlIHJlY2lwaWVudCB2ZXJzaW9uIGF0IHRoZSBzYXZpbmdzIG9m IGEgc2luZ2xlICZuYnNwO2J5dGUgaW4gdGhlIG1lc3NhZ2UgYW5kIGFkZGl0aW9uYWwgY29tcGxp Y2F0aW9ucy4mbmJzcDsgT25lIGNhbiBrZWVwIHRoYXQgZXh0cmEgbWVzc2FnZSBieXRlIGFuZCBz YXkg4oCTIG9ubHkgcHJvY2VzcyB0aGUgZmlyc3QgcmVjaXBpZW50IHN0cnVjdHVyZSBldmVuIGlm IHRoZXJlIGFyZSBtb3JlIHRoYW4gb25lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBw dDtib3JkZXItY29sb3I6LW1vei11c2UtdGV4dC1jb2xvciAtbW96LXVzZS10ZXh0LWNvbG9yIC1t b3otdXNlLXRleHQtY29sb3IgYmx1ZSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW47Ym9yZGVyLWNvbG9yOi1tb3otdXNlLXRleHQtY29sb3IgLW1vei11c2UtdGV4dC1jb2xvciI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEJyaWFuIENhbXBi ZWxsIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0 YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+XQ0KPGJyPg0KPGI+ U2VudDo8L2I+IFdlZG5lc2RheSwgSnVseSAwMSwgMjAxNSAxOjQwIFBNPGJyPg0KPGI+VG86PC9i PiBDYXJzdGVuIEJvcm1hbm48YnI+DQo8Yj5DYzo8L2I+IEppbSBTY2hhYWQ7IDxhIGhyZWY9Im1h aWx0bzpjb3NlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y29zZUBpZXRmLm9yZzwvYT48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtDb3NlXSBJc3N1ZTogRW5jb2RpbmcgZm9yIGEgc2luZ2xl IHJlY2lwaWVudCBvciBzdHJ1Y3R1cmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+SW4gbXkgb3duIGV4cGVyaWVuY2Ugd2l0 aCBKT1NFLCB0aGUgbmVlZCBmb3Igc2luZ2xlIHJlY2lwaWVudCBjYXNlIGlzIG92ZXJ3aGVsbWlu ZyBtYWpvcml0eSBhbmQgdGhlIHNpbXBsaWNpdHkgdGhlIGNvbXBhY3Qgc2VyaWFsaXphdGlvbiBh ZmZvcmRlZCBmb3IgdGhhdCBjYXNlIGFyZSBhIG1ham9yIHdpbi4gTXkgb3duDQogaW1wbGVtZW50 YXRpb24gc3VwcG9ydHMgb25seSB0aGUgY29tcGFjdCBzZXJpYWxpemF0aW9ucyAoYW5kIHRodXMg b25seSBhIHNpbmdsZSByZWNpcGllbnQgb3Igc2lnbmF0dXJlKSBhbmQgaXQgaXMgdXNlZCB3aWRl bHkgaW4gbXkgZW1wbG95ZXIncyBwcm9kdWN0cyBhbmQgc2VydmljZXMgYXMgd2VsbCBhcyBiZWlu ZyBvcGVuIHNvdXJjZS4gTm8gb25lIGhhcyBldmVyIGV2ZW4gYXNrZWQgYWJvdXQgdGhlIEpTT04g c2VyaWFsaXphdGlvbnMgKHdoaWNoDQogc3VwcG9ydCBtdWx0aXBsZSBzaWduYXR1cmVzL3JlY2lw aWVudHMpLiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox Mi4wcHQiPkkgdW5kZXJzdGFuZCB0aGUgYWxsdXJlIG9mIGNvbnNpc3RlbnRseSB0cmVhdGluZyBz b21ldGhpbmcgdGhhdCBjb3VsZCBoYXZlIG1vcmUgdGhhbiBvbmUgdGhpbmcgYXMgYWx3YXlzIHBv dGVudGlhbGx5IGhhdmluZyBtb3JlIHRoYW4gb25lLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QnV0 IHRoZXJlIGlzIHJlYWwgdmFsdWUgaW4gbWFraW5nIHRoZSBtb3N0IGNvbW1vbiBjYXNlcyBzaW1w bGUsIHdoaWNoIHNob3VsZG4ndCBiZSBkaXNjb3VudGVkLg0KPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPk9uIFdlZCwgSnVsIDEsIDIwMTUgYXQgMToxMiBBTSwgQ2Fyc3RlbiBC b3JtYW5uICZsdDs8YSBocmVmPSJtYWlsdG86Y2Fib0B0emkub3JnIiB0YXJnZXQ9Il9ibGFuayI+ Y2Fib0B0emkub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0O2JvcmRlci1jb2xvcjotbW96LXVz ZS10ZXh0LWNvbG9yIC1tb3otdXNlLXRleHQtY29sb3IgLW1vei11c2UtdGV4dC1jb2xvciByZ2Io MjA0LDIwNCwyMDQpIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SmltIFNjaGFhZCB3cm90ZTo8 YnI+DQomZ3Q7IElmIG9uZSBiZWxpZXZlcyB0aGF0IGl0IGlzIG9ubHkgZm9yIHVzZSBpbiBjb25z dHJhaW5lZCBlbnZpcm9ubWVudHMsPGJyPg0KJmd0OyB0aGVuIGl0IGlzIHVubGlrZWx5IHRoYXQg dGhlcmUgaXMgYSBuZWVkIGZvciBtdWx0aXBsZSByZWNpcGllbnRzLjxicj4NCjxicj4NCkFjdHVh bGx5LCB3ZSBkbyBoYXZlIHNjZW5hcmlvcyB3aXRoIGZhbi1vdXQgKGJvdGggdmlhIHByb3h5IGFu ZCBwZXI8YnI+DQptdWx0aWNhc3QpLCBhbmQgdGhvc2UgYXJlIGFjdHVhbGx5IGEgc3Ryb25nIG1v dGl2YXRvciBmb3Igb2JqZWN0IHNlY3VyaXR5Ljxicj4NCjxicj4NClRoZSBtaW5pbWFsLWJ5dGVz IGFsdGVybmF0aXZlIGlzIHRvIG1peCBpbiB0aGUgbWFwIGVudHJpZXMgZm9yIGEgc2luZ2xlPGJy Pg0KcmVjaXBpZW50IHdpdGggdGhvc2UgZm9yIHRoZSBoZWFkZXJzIGV0Yy4mbmJzcDsgQm90aCBK U09OIGFuZCBDQk9SIGRvIG5vdDxicj4NCmhhdmUgYSBkZWZpbmVkIHNlcXVlbmNlIG9mIG1hcCBl bnRyaWVzLCBzbyB0aGlzIG1lYW5zIHRoZSByZWNpcGllbnQgaGFzPGJyPg0KdG8gcGllY2UgdGhl IGluZm8gdG9nZXRoZXIgYXMgaXQgY29tZXMgaW4uJm5ic3A7IFdlJ2QgYWxzbyBuZWVkIGEgc2Vw YXJhdGU8YnI+DQpzZXQgb2YgbGFiZWxzLiZuYnNwOyBOb3QgbXkgZmF2b3JpdGUuPGJyPg0KPGJy Pg0KSWYgd2Uga2VlcCB0b2dldGhlciB0aGF0IG1hcCwgd2hhdCB3ZSBjb3VsZCBzdGlsbCBkbyBp cyB0dXJuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PyByZWNpcGllbnRz ID0mZ3Q7IFsmIzQzO3tDT1NFX2VuY3J5cHRfZmllbGRzfV08YnI+DQo8YnI+DQpiYWNrICh3ZSBo YWQgc29tZXRoaW5nIGxpa2UgdGhhdCBlYXJsaWVyKSBpbnRvPGJyPg0KPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7PyByZWNpcGllbnRzID0mZ3Q7IFsmIzQzO3tDT1NFX2VuY3J5cHRf ZmllbGRzfV0gLyB7Q09TRV9lbmNyeXB0X2ZpZWxkc308YnI+DQo8YnI+DQpTYXZlcyB0aGF0IDB4 ODEgYnl0ZSBpbiB0aGUgc2luZ2xlLXJlY2VpdmVyIGNhc2UuPGJyPg0KPGJyPg0KR3LDvMOfZSwg Q2Fyc3RlbjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KQ29zZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Q29zZUBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPkNvc2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb3NlPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_BL2PR03MB4335BB434C6A02E49C4B003F59F0BL2PR03MB433namprd_-- From nobody Fri Jul 10 10:11:34 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 8F8411B2A3E for ; Fri, 10 Jul 2015 10:11:33 -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 6GvMtgXa6vX2 for ; Fri, 10 Jul 2015 10:11:31 -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 818E91B2A4B for ; Fri, 10 Jul 2015 10:11:31 -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 118CE81817; Fri, 10 Jul 2015 20:11:19 +0300 (EEST) Date: Fri, 10 Jul 2015 20:11:18 +0300 From: Ilari Liusvaara To: Derek Atkins Message-ID: <20150710171118.GA20991@LK-Perkele-VII> References: <559576A9.9090002@gmx.net> <001001d0b90c$3c874af0$b595e0d0$@augustcellars.com> <00c501d0b9a5$c8f869d0$5ae93d70$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: Cc: Jim Schaad , Brian Campbell , Mike Jones , cose@ietf.org Subject: Re: [Cose] Key management for MACs (was Re: 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: Fri, 10 Jul 2015 17:11:33 -0000 On Fri, Jul 10, 2015 at 09:28:24AM -0400, Derek Atkins wrote: > > Performing a MAC using the output of a DH (be it ECDH, AEDH, or raw DH) > can still tell you that the transmission has not been modified between > you and the party you're talking to. You're right that it tells you > nothing about the party you're talking to (i.e., without authentication > of the DH keys you have no idea if you're talking to a MITM or the real > endpoint). However, using DH + MAC does tell you that you're not being > spoofed by a "passive" eavesdropper. > > So IMHO it does have some benefit. It occurs to me that any sort of asymmetric key management with MACs is unsafe, since knowing just public key enables message forgery. This does not straightforwardly extend to symmetric schems (like key wrapping), but are those useful with MACs? -Ilari From nobody Fri Jul 10 11:21: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 551EE1B2A7B for ; Fri, 10 Jul 2015 11:21:03 -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 2ecTVSccsszj for ; Fri, 10 Jul 2015 11:21:02 -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 01F8F1B2A72 for ; Fri, 10 Jul 2015 11:21:01 -0700 (PDT) Received: from hebrews (174-21-18-91.tukw.qwest.net [174.21.18.91]) (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 1E4F92CA4C; Fri, 10 Jul 2015 11:21:01 -0700 (PDT) From: "Jim Schaad" To: "'Ilari Liusvaara'" References: <559576A9.9090002@gmx.net> <001001d0b90c$3c874af0$b595e0d0$@augustcellars.com> <00c501d0b9a5$c8f869d0$5ae93d70$@augustcellars.com> <20150710171118.GA20991@LK-Perkele-VII> In-Reply-To: <20150710171118.GA20991@LK-Perkele-VII> Date: Fri, 10 Jul 2015 11:21:19 -0700 Message-ID: <00b601d0bb3d$37fe0d60$a7fa2820$@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: AQGMo9E7lz5K1VbQVek9kTd0WZ5EKwIS9FwIAQ3LxPQB/WXDmAHiZZGnAshjO7UB4sdSXwJU7d8kne0seAA= Archived-At: Cc: cose@ietf.org Subject: Re: [Cose] Key management for MACs (was Re: 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: Fri, 10 Jul 2015 18:21:03 -0000 > -----Original Message----- > From: Ilari Liusvaara [mailto:ilari.liusvaara@elisanet.fi] > Sent: Friday, July 10, 2015 10:11 AM > To: Derek Atkins > Cc: Brian Campbell; Jim Schaad; Mike Jones; cose@ietf.org > Subject: Re: [Cose] Key management for MACs (was Re: Review of draft- > schaad-cose-msg-01) >=20 > On Fri, Jul 10, 2015 at 09:28:24AM -0400, Derek Atkins wrote: > > > > Performing a MAC using the output of a DH (be it ECDH, AEDH, or raw > > DH) can still tell you that the transmission has not been modified > > between you and the party you're talking to. You're right that it > > tells you nothing about the party you're talking to (i.e., without > > authentication of the DH keys you have no idea if you're talking to = a > > MITM or the real endpoint). However, using DH + MAC does tell you > > that you're not being spoofed by a "passive" eavesdropper. > > > > So IMHO it does have some benefit. >=20 > It occurs to me that any sort of asymmetric key management with MACs = is > unsafe, since knowing just public key enables message forgery. We are going to need to have a consistent definition of message forgery = for this to be a true statement. Can one have a forgery from an = anonymous person? If you don't make a statement about who is sending = the message, which may not be done in this case, then I have a problem = with saying something is a forgery. To have origination, one needs to use static-static DH. Without this = one does not have statement of origin. >=20 > This does not straightforwardly extend to symmetric schems (like key > wrapping), but are those useful with MACs? Depends to a large extent on what you are doing for key roll over of = your shared secrets. If you don't do it very often, then as I stated = in my last message it can improve security as some attacks can be easier = to detect. jim >=20 >=20 > -Ilari From nobody Fri Jul 10 12:08: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 505FA1B2A88 for ; Fri, 10 Jul 2015 12:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 c5X6qc49-TJa for ; Fri, 10 Jul 2015 12:08:50 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::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 0BF231B2A87 for ; Fri, 10 Jul 2015 12:08:50 -0700 (PDT) Received: by igrv9 with SMTP id v9so19436892igr.1 for ; Fri, 10 Jul 2015 12:08:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9CymgDb3FkaI5/3qg/JxUkOdOH6mMJLOTDs6Mhr55vw=; b=KM+W3/Dk1+owfXfOacSzaH9E2yjKHnFNBqgKg52aquzLOqmV+eH4PA4Kki9fU+foqm oUL6ef2ApCZZ1C+WlmBuzMi9Jzbj9N1fe7XYq8FLikDU8GgMqM65pCVyUmHLIJOEFyaK vX28USgGBlMaYai1eSHwV87msQZ5QswdBWuHM= 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=9CymgDb3FkaI5/3qg/JxUkOdOH6mMJLOTDs6Mhr55vw=; b=g4MRVkt2EIXg4hXuCG3vh/tHUZRcyZthxFwiP5D5VA5xhrSonVCdrPO+zc/YJzPzso wFY8FcEX0g7dR19YJkUmwBabIKdbbKgFGlKjHi1GSfw1tJ+dgvUeYpFUIRdIteR+PqaU amjsEazcygpTpPSrgngTfQyeFTNUTtZdb+EjVsdnyEpagVxsUtJHB7ITUOBYHBF2JhTk b2jhloqxDMdtgVDORDfg736lgczreA6/va0jCmHhpBnC3yDI2Y1ClOVtbqSw9ZlcsQV0 Gn/6+jpcbwRC2TH06otDKzuDZM80fRmRS+VWMQYywne818OF691cMsCj+2420wRjRdW7 Blqw== X-Gm-Message-State: ALoCoQnVWwbArowqIFDCuTh80v/QWp5n1fz0WvWbwdFCb2bLL4pLm8WrZFkmcYg5k4tT/qFa+C7k X-Received: by 10.50.18.39 with SMTP id t7mr327254igd.3.1436555329437; Fri, 10 Jul 2015 12:08:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Fri, 10 Jul 2015 12:08:20 -0700 (PDT) In-Reply-To: References: <559576A9.9090002@gmx.net> From: Brian Campbell Date: Fri, 10 Jul 2015 13:08:20 -0600 Message-ID: To: Derek Atkins Content-Type: multipart/alternative; boundary=089e014947ac1c9fd6051a8a1ad4 Archived-At: Cc: Jim Schaad , Hannes Tschofenig , Mike Jones , cose@ietf.org Subject: Re: [Cose] Key management for MACs (was Re: 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: Fri, 10 Jul 2015 19:08:52 -0000 --089e014947ac1c9fd6051a8a1ad4 Content-Type: text/plain; charset=UTF-8 That's fair, Derek. I just hope the WG keeps both in mind. On Fri, Jul 10, 2015 at 8:14 AM, Derek Atkins wrote: > > On Fri, July 10, 2015 9:07 am, Brian Campbell wrote: > > On Wed, Jul 8, 2015 at 10:44 AM, Derek Atkins wrote: > > > >> Hannes Tschofenig writes: > >> > We are not doing ourselves a flavor if we place artificial constraints > >> > on our protocols that make them pretty insecure in practice. We > >> already > >> > have enough insecure IoT devices in the market. > >> > >> Sure.. Many IoT devices don't even try :) > >> > > > > I just want us to be cognizant of the possibility that a dense > complicated > > crypto messaging syntax will probably not change that situation. If it's > > not easy and approachable, it has the potential to be ignored. > > That's only half the problem. Many people ignore security because there > is this belief "I can't reasonably run those algorithms on my devices." > > So I would augment this to say that it not only needs to be easy and > approachable, but it also needs to be implementable on the hardware. That > often rules out many cryptographic algorithms (like RSA and DH, and > sometimes even ECC) depending on space, power, and timing constraints of > the devices. > > -derek > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > > --089e014947ac1c9fd6051a8a1ad4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That's fair, Derek. I just hope the WG keeps both in m= ind.

On Fri, J= ul 10, 2015 at 8:14 AM, Derek Atkins <derek@ihtfp.com> wrote:<= br>
<= br> On Fri, July 10, 2015 9:07 am, Brian Campbell wrote:
> On Wed, Jul 8, 2015 at 10:44 AM, Derek Atkins <derek@ihtfp.com> wrote:
>
>> Hannes Tschofenig <hannes.tschofenig@gmx.net> writes:
>> > We are not doing ourselves a flavor if we place artificial co= nstraints
>> > on our protocols that make them pretty insecure in practice. = We
>> already
>> > have enough insecure IoT devices in the market.
>>
>> Sure.. Many IoT devices don't even try :)
>>
>
> I just want us to be cognizant of the possibility that a dense complic= ated
> crypto messaging syntax will probably not change that situation. If it= 's
> not easy and approachable, it has the potential to be ignored.

That's only half the problem.=C2=A0 Many people ignore secu= rity because there
is this belief "I can't reasonably run those algorithms on my devi= ces."

So I would augment this to say that it not only needs to be easy and
approachable, but it also needs to be implementable on the hardware.=C2=A0 = That
often rules out many cryptographic algorithms (like RSA and DH, and
sometimes even ECC) depending on space, power, and timing constraints of the devices.

-derek
--
=C2=A0 =C2=A0 =C2=A0 =C2=A0Derek Atkins=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0617-623-3745
=C2=A0 =C2=A0 =C2=A0 =C2=A0derek@ihtfp.c= om=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0www.ihtfp.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0Computer and Internet Security Consultant


--089e014947ac1c9fd6051a8a1ad4-- From nobody Fri Jul 10 12:32: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 993171B2A5B for ; Fri, 10 Jul 2015 12:32:17 -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 A1rMyfXukqbk for ; Fri, 10 Jul 2015 12:32:15 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0722.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:722]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 831771B2A8A for ; Fri, 10 Jul 2015 12:32:15 -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; Fri, 10 Jul 2015 19:31: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; Fri, 10 Jul 2015 19:31:51 +0000 From: Mike Jones To: Brian Campbell , Derek Atkins Thread-Topic: [Cose] Key management for MACs (was Re: Review of draft-schaad-cose-msg-01) Thread-Index: AQHQuZ1WtSq2x1sR40SvzKRDC45tbp3Ur3mAgAASs4CAAFIqAIAABpOR Date: Fri, 10 Jul 2015 19:31:51 +0000 Message-ID: References: <559576A9.9090002@gmx.net> , 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: [167.220.23.11] x-microsoft-exchange-diagnostics: 1; BL2PR03MB433; 5:aLcgXySlF7HFjPeWoHHvNY25kn/Q8zM/4JmhuhPy3tdziyQmB9ToYi1kM8oH3sLXp/FAB23BQGqi/iOaIgdza/Se0A0GJ72UTyDpj6LEZ/IzKidkY3K0d66aFu8WWCAkGHyfM3rm8JAQY+r9kVUkMw==; 24:YPqTMIHBSrDNHA5MMT/6GYuUOxyNoniTnEAJEpcHz3rb4crnSvtaW1eCOTfMXC9LUmiKCDEVcUfK1lB/NY5JlxnINAM9IkJpLwqPM1/Gh9c=; 20:iB6wD7w8M7S6b2N8gHP2j47MoLW+6WsyE/PEsRLCbW8zrd/jpVfLzxtEwr+6pwqQWBdrVDpvrSrDUf1ZaBOJKw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB433; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); 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: 06339BAE63 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(74316001)(99286002)(33656002)(92566002)(106116001)(19580395003)(19580405001)(93886004)(2656002)(230783001)(87936001)(86612001)(76176999)(86362001)(16236675004)(66066001)(50986999)(54356999)(5001960100002)(46102003)(5003600100002)(76576001)(189998001)(77156002)(5001920100001)(122556002)(40100003)(2900100001)(16601075003)(2950100001)(19617315012)(62966003)(5002640100001)(5001770100001)(15975445007)(102836002)(77096005); 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_BL2PR03MB4337E817F064C5DAB0A74C8F59F0BL2PR03MB433namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2015 19:31:51.8254 (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 , Hannes Tschofenig , "cose@ietf.org" Subject: Re: [Cose] Key management for MACs (was Re: 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: Fri, 10 Jul 2015 19:32:17 -0000 --_000_BL2PR03MB4337E817F064C5DAB0A74C8F59F0BL2PR03MB433namprd_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable +1 ________________________________ From: Brian Campbell Sent: =FD7/=FD10/=FD2015 12:08 PM To: Derek Atkins Cc: Hannes Tschofenig; Jim Schaad; Mike Jones; co= se@ietf.org Subject: Re: [Cose] Key management for MACs (was Re: Review of draft-schaad= -cose-msg-01) That's fair, Derek. I just hope the WG keeps both in mind. On Fri, Jul 10, 2015 at 8:14 AM, Derek Atkins > wrote: On Fri, July 10, 2015 9:07 am, Brian Campbell wrote: > On Wed, Jul 8, 2015 at 10:44 AM, Derek Atkins > wrote: > >> Hannes Tschofenig > writes: >> > We are not doing ourselves a flavor if we place artificial constraints >> > on our protocols that make them pretty insecure in practice. We >> already >> > have enough insecure IoT devices in the market. >> >> Sure.. Many IoT devices don't even try :) >> > > I just want us to be cognizant of the possibility that a dense complicate= d > crypto messaging syntax will probably not change that situation. If it's > not easy and approachable, it has the potential to be ignored. That's only half the problem. Many people ignore security because there is this belief "I can't reasonably run those algorithms on my devices." So I would augment this to say that it not only needs to be easy and approachable, but it also needs to be implementable on the hardware. That often rules out many cryptographic algorithms (like RSA and DH, and sometimes even ECC) depending on space, power, and timing constraints of the devices. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant --_000_BL2PR03MB4337E817F064C5DAB0A74C8F59F0BL2PR03MB433namprd_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
+1
From: Brian Campbell
Sent: =FD7/= =FD10/=FD2015 12:08 PM
To: Derek Atkins
Cc: Hannes Tschofenig; Jim Schaad; Mike Jones; cose@ietf.org Subject: Re: [= Cose] Key management for MACs (was Re: Review of draft-schaad-cose-msg-01)<= /span>

That's fair, Derek. I just hope the WG keeps both in mind.=

On Fri, Jul 10, 2015 at 8:14 AM, Derek Atkins <derek@ihtfp.com> wrote:

On Fri, July 10, 2015 9:07 am, Brian Campbell wrote:
> On Wed, Jul 8, 2015 at 10:44 AM, Derek Atkins <derek@ihtfp.com> wrote:
>
>> Hannes Tschofenig <hannes.tschofenig@gmx.net> writes:
>> > We are not doing ourselves a flavor if we place artificial co= nstraints
>> > on our protocols that make them pretty insecure in practice. = We
>> already
>> > have enough insecure IoT devices in the market.
>>
>> Sure.. Many IoT devices don't even try :)
>>
>
> I just want us to be cognizant of the possibility that a dense complic= ated
> crypto messaging syntax will probably not change that situation. If it= 's
> not easy and approachable, it has the potential to be ignored.

That's only half the problem.  Many people ignore security because the= re
is this belief "I can't reasonably run those algorithms on my devices.= "

So I would augment this to say that it not only needs to be easy and
approachable, but it also needs to be implementable on the hardware.  = That
often rules out many cryptographic algorithms (like RSA and DH, and
sometimes even ECC) depending on space, power, and timing constraints of the devices.

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


--_000_BL2PR03MB4337E817F064C5DAB0A74C8F59F0BL2PR03MB433namprd_-- From nobody Fri Jul 10 15:09: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 A4C771A000F for ; Fri, 10 Jul 2015 15:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 CiV5-Fki9VCf for ; Fri, 10 Jul 2015 15:09:02 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3C861A009D for ; Fri, 10 Jul 2015 15:07:18 -0700 (PDT) Received: by igrv9 with SMTP id v9so22612575igr.1 for ; Fri, 10 Jul 2015 15:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+2s9cWjgZpxi+HjZI0QsJV9ocq7gZrGJo89ZzNFIIlY=; b=Zmc/zAVt44hv5f2UqeEKZoJY69QARc7+Yb1thjucACU+3vKM2sxi38WcPOx644BEwN bCw6IeTBE6Q6Z59938yQvnB0Lmfyd51LxR9/V8EF0s6t7l6CRn875f1ZpPIxVN/2qXku PwQxq/qW0qP3MYkuuYLfRT/DjTyxJ7b7sx+iU= 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=+2s9cWjgZpxi+HjZI0QsJV9ocq7gZrGJo89ZzNFIIlY=; b=gG3a5DYK2gzoClxx1JKJc9cWgX/9kCPGgrBFm2ccio3ziFr1wZ/MguF3bccXJ1wfv+ FgKpGL3PcLAIqXR+nYrVPnCi+JPwBSiLnritze8S5VUhveyrYltEvrrbxRS4H+VbFXZE aPsk2N9f4a/ffVjQtkQ2gKahg2NIHzM3wwQPd4QlmMkH+B6aAElWve8ej+4F2syllh24 9ToTiawmn8GI/65Yqlo5KZBBSBntIQJPspP+Nlae5aqwXB6cGg0JKJwNnsCFl7HNijY8 dex1oM8u3eSX5hQwYWEXTyjOnkew8iXbzwNSQiQ0HYj7CsTNurg5nzgUyZg2mURqdVe8 Qs0w== X-Gm-Message-State: ALoCoQlvFiwggV5O4K4G1pWYExpgNumY2oNT9VMPzhBZYq3di05Ah5+JdpYLQsYlUZ5bTt4R3vhu X-Received: by 10.107.14.148 with SMTP id 142mr6900222ioo.175.1436566038069; Fri, 10 Jul 2015 15:07:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.96.199 with HTTP; Fri, 10 Jul 2015 15:06:48 -0700 (PDT) In-Reply-To: <00b601d0bb3d$37fe0d60$a7fa2820$@augustcellars.com> References: <559576A9.9090002@gmx.net> <001001d0b90c$3c874af0$b595e0d0$@augustcellars.com> <00c501d0b9a5$c8f869d0$5ae93d70$@augustcellars.com> <20150710171118.GA20991@LK-Perkele-VII> <00b601d0bb3d$37fe0d60$a7fa2820$@augustcellars.com> From: Brian Campbell Date: Fri, 10 Jul 2015 16:06:48 -0600 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=001a113fc47c656549051a8c98ce Archived-At: Cc: Ilari Liusvaara , cose@ietf.org Subject: Re: [Cose] Key management for MACs (was Re: 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: Fri, 10 Jul 2015 22:09:03 -0000 --001a113fc47c656549051a8c98ce Content-Type: text/plain; charset=UTF-8 And my question was about ephemeral-static DH and RSA-OAEP (both of which are used in the MAC example at https://cose-wg.github.io/cose-spec/#rfc.appendix.C.1.4) . Without the statement of origin, I don't see what value there is? On Fri, Jul 10, 2015 at 12:21 PM, Jim Schaad wrote: > > > > -----Original Message----- > > From: Ilari Liusvaara [mailto:ilari.liusvaara@elisanet.fi] > > Sent: Friday, July 10, 2015 10:11 AM > > To: Derek Atkins > > Cc: Brian Campbell; Jim Schaad; Mike Jones; cose@ietf.org > > Subject: Re: [Cose] Key management for MACs (was Re: Review of draft- > > schaad-cose-msg-01) > > > > On Fri, Jul 10, 2015 at 09:28:24AM -0400, Derek Atkins wrote: > > > > > > Performing a MAC using the output of a DH (be it ECDH, AEDH, or raw > > > DH) can still tell you that the transmission has not been modified > > > between you and the party you're talking to. You're right that it > > > tells you nothing about the party you're talking to (i.e., without > > > authentication of the DH keys you have no idea if you're talking to a > > > MITM or the real endpoint). However, using DH + MAC does tell you > > > that you're not being spoofed by a "passive" eavesdropper. > > > > > > So IMHO it does have some benefit. > > > > It occurs to me that any sort of asymmetric key management with MACs is > > unsafe, since knowing just public key enables message forgery. > > We are going to need to have a consistent definition of message forgery > for this to be a true statement. Can one have a forgery from an anonymous > person? If you don't make a statement about who is sending the message, > which may not be done in this case, then I have a problem with saying > something is a forgery. > > To have origination, one needs to use static-static DH. Without this one > does not have statement of origin. > > > > > This does not straightforwardly extend to symmetric schems (like key > > wrapping), but are those useful with MACs? > > Depends to a large extent on what you are doing for key roll over of your > shared secrets. If you don't do it very often, then as I stated in my > last message it can improve security as some attacks can be easier to > detect. > > jim > > > > > > > -Ilari > > _______________________________________________ > Cose mailing list > Cose@ietf.org > https://www.ietf.org/mailman/listinfo/cose > --001a113fc47c656549051a8c98ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
And my question was about ephemeral-static DH and RSA-OAEP= (both of which are used in the MAC example at https://cose-wg.github.io/cose-spec= /#rfc.appendix.C.1.4) . Without the statement of origin, I don't se= e what value there is?



On Fri, Jul 10, 2015 at 12:21 PM, Jim Schaad <= ietf@augustcellars.com> wrote:


> -----Original Message-----
> From: Ilari Liusvaara [mailto:ilari.liusvaara@elisanet.fi]
> Sent: Friday, July 10, 2015 10:11 AM
> To: Derek Atkins
> Cc: Brian Campbell; Jim Schaad; Mike Jones; cose@ietf.org
> Subject: Re: [Cose] Key management for MACs (was Re: Review of draft-<= br> > schaad-cose-msg-01)
>
> On Fri, Jul 10, 2015 at 09:28:24AM -0400, Dere= k Atkins wrote:
> >
> > Performing a MAC using the output of a DH (be it ECDH, AEDH, or r= aw
> > DH) can still tell you that the transmission has not been modifie= d
> > between you and the party you're talking to.=C2=A0 You're= right that it
> > tells you nothing about the party you're talking to (i.e., wi= thout
> > authentication of the DH keys you have no idea if you're talk= ing to a
> > MITM or the real endpoint).=C2=A0 However, using DH + MAC does te= ll you
> > that you're not being spoofed by a "passive" eavesd= ropper.
> >
> > So IMHO it does have some benefit.
>
> It occurs to me that any sort of asymmetric key management with MACs i= s
> unsafe, since knowing just public key enables message forgery.

We are going to need to have a consistent definition of message forg= ery for this to be a true statement.=C2=A0 Can one have a forgery from an a= nonymous person?=C2=A0 If you don't make a statement about who is sendi= ng the message, which may not be done in this case, then I have a problem w= ith saying something is a forgery.

To have origination, one needs to use static-static DH.=C2=A0 Without this = one does not have statement of origin.

>
> This does not straightforwardly extend to symmetric schems (like key > wrapping), but are those useful with MACs?

Depends to a large extent on what you are doing for key roll over of= your shared secrets.=C2=A0 =C2=A0If you don't do it very often, then a= s I stated in my last message it can improve security as some attacks can b= e easier to detect.

jim

>
>
> -Ilari

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


On T= ue, Jul 7, 2015 at 4:40 PM, Jim Schaad <ietf@augustcellars.com>= ; wrote:

I am = more than willing to have a different term for =E2=80=9CKey Management=E2= =80=9D.=C2=A0 However, I have inherited the term from CMS (RFC 2630) where = section 12.3 talks about key management algorithms.

=C2=A0

What you re referring to below, I generall= y put under the term of key life cycle

=C2=A0

Jim

=C2=A0

=C2=A0

From: Brian Campbell [mailto:bcampbell@pingidentity.com]
= Sent: Tuesday, July 07, 2015 1:36 PM
To: Justin Richer
= Cc: Mike Jones; Jim Schaad; cose@ietf.org
Subject: Re: [Cose= ] Review of draft-schaad-cose-msg-01

<= /div>

=C2=A0

[wearing my cowboy = hat from Dallas:)]

I think the term "key ma= nagement" has gotten a little overloaded here.

I believe the charter uses the term in the broader and tradi= tional sense that Wikipedia, for example, talks about it, like "de= aling with the generation, exchange, storage, use, and replacement of keys&= quot; including "key servers [and] user procedures."

Whereas the term seemed to get somewhat co-opted = in JOSE as a catch all to cover all the message level key encryption, key e= ncapsulation, and key agreement bits that are needed to convey and protect = a content encryption key for encryption. And that usage has carried over in= to COSE.

COSE needs "key ma= nagement" in the latter sense of the word. Maybe it should be called s= omething else but it's a necessity for encryption. My question the othe= r day was about the what value there is in doing it for MAC keys.

I suspect the "Key manageme= nt and binding of keys to identities are out of scope" in the former s= ense in the charter is intended to keep COSE scope reasonably constrained.= =C2=A0

=C2=A0<= /p>


=C2=A0 =C2=A0

= =C2=A0

On Tue, Jul 7, 2015 at 1:54 PM= , Justin Richer <jr= icher@mit.edu> wrote:

Perhaps I=E2=80=99m miss= ing something, but as chair I feel the need to point out this line in our c= urrent charter for you all to consider:

=C2=A0

Key management and binding of keys to iden=
tities are out of scope for the
working =
group.

=C2=A0

=C2=A0= =E2=80=94 Justin

= =C2=A0

=C2=A0

=
<= div>

On Jul 7, 2015, at 3:50 PM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:

<= u>=C2=A0

Jim, I hadn=E2=80=99t seen an answer = to this question.=C2=A0 If the thread you=E2=80=99re referring to is =E2=80= =9CKey management in the World of COSE=E2=80=9D, my impression is that some= people talked about use cases, but there were no actual conclusions drawn.=

=C2=A0

Also, could you answer Brian Campbell=E2=80=99s question in the= related thread =E2=80=9CKey management for MACs (was Re: [Cose] Review of = draft-schaad-cose-msg-01)=E2=80=9D?=C2=A0 As I said in my reply, I complete= ly understand the value of key management for encryption, in which there ar= e secrets to protect, but not for MACs, where there are not.<= u>

=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= Thanks,

=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

From: Mike Jones
Sent: Tuesday,= June 30, 2015 2:54 PM
To: 'Jim Schaad'; cose@ietf.org
Subject: RE:= [Cose] Review of draft-schaad-cose-msg-01

=C2=A0

<= span style=3D"color:#1f497d">Jim, is the discussion you=E2=80=99re referrin= g to for my issue 2 the thread =E2=80=9CKey management in the World of COSE= =E2=80=9D or is there an additional thread you=E2=80=99re referring to?

= =C2=A0

From= : Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Saturday, J= une 27, 2015 8:25 AM
To: Mike Jones; cose@ietf.org
Subject: RE: [Cose] Revi= ew of draft-schaad-cose-msg-01

=C2=A0

=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 th= e following review feedback on draft-schaad-cose-msg-01.=C2=A0 M= ost of the major comments are motivated by the goal of =E2=80=9Ckeeping sim= ple things simple=E2=80=9D.=C2=A0 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.=C2=A0 I believe that we should there= fore optimize the representations we define for the common cases, while mak= ing it possible to also gracefully accommodate less common, if possibly mor= e general cases as well.

=C2=A0<= /u>

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 J= OSE.=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 individual merits.= =C2=A0 That said, here=E2=80=99s my review=E2=80=A6

=C2=A0

MAJOR IS= SUES

=C2=A0

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

=C2=A0=

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

=C2=A0

Unless we do the same for COSE, I=E2=80=99m sure we=E2=80=99ll rec= eive the same feedback that requiring the =E2=80=9Crecipients=E2=80=9D arra= y in use cases where it will always contain one element is unnecessarily co= mplicated.=C2=A0 We should do this now.

=C2=A0

While the argument agai= nst 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 argume= nt.=C2=A0 Applications will choose or build an implementation that fits the= ir use case =E2=80=93 either one that supports single or multiple recipient= s.=C2=A0 Application profiles will choose one or the other representation a= nd will generally not call for both.

=C2=A0

The way to achieve this is= to define a flattened representation as JOSE did, in which header paramete= rs 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.<= /u>

=C2=A0

[JL= S] This was discussed on the mailing list.=C2=A0 There are a number of trad= e-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 are looking at= both the message size and the code size as criteria when making decisions.=

=C2=A0

2.=C2=A0 HMACs should be optimized for the no-key-ma= nagement case.

=C2=A0=

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

=C2=A0

I=E2=80=99m fine with t= he optional ability to have key management for MACs, but the default should= be that no key management information is present in the representation.=C2= =A0 The only algorithm represented by default should be the MAC algorithm = =E2=80=93 not even =E2=80=9Cdir=E2=80=9D (direct).=C2=A0 I suspect that thi= s can be cleanly done by omitting the key management layer entirely when it= =E2=80=99s not used, rather than explicitly using =E2=80=9Cdir=E2=80=9D (di= rect).

= =C2=A0

[JLS] See above.

=C2=A0=

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

=C2=A0

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

=C2=A0

A simple way to achieve this is to define an encrypted_k= ey field to represent the wrapped key, when appropriate for the algorithm.= =C2=A0 Among other benefits, this will enable the use of the standard RFC 3= 394 AES Key Wrap algorithms, in the same way that JOSE uses =E2=80=9CA128KW= =E2=80=9D, etc.

=C2=A0

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.=C2=A0 Applications can then choose w= hich method works best for them.

=C2=A0

[JLS] I don=E2=80=99t understand this comm= ent.=C2=A0 This is not what the document says.

=C2=A0

4.=C2= =A0 Simpler and more comprehensible examples are needed.<= /p>

=C2=A0

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

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 H= MAC without key management

=C2=B7=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Single signature

=C2=B7=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Encryption using AES Key Wra= p for key management and AES GCM for content encryption

=C2=A0

Also, t= o be comprehensible to most readers, the examples need to include both symb= olic and numeric identifiers for all fields.=C2=A0 Also, decoded representa= tions for encoded values need to be shown.

=C2=A0

For instance, the Di= rect MAC example in C.1 should be changed from beginning like this:<= u>

=C2=A0

=C2=A0=C2=A0 {

=C2=A0=C2=A0=C2= =A0=C2=A0 1: 3,

=C2=A0=C2=A0=C2=A0= =C2=A0 2: h'a10104',

=C2=A0= =C2=A0=C2=A0=C2=A0 4: h'546869732069732074686520636f6e74656e742e',<= u>

=C2=A0=C2=A0=C2=A0=C2=A0 10: h'= 2ba937ca03d76c3dbad30cfcbaeef586f9c0f9ba616ad67e9205d3857

=

=C2=A0=C2=A0 6ad9930',

=C2=A0

to beginning = like this:

=C2=A0

=

=C2=A0=C2=A0 {

=C2=A0=C2=A0=C2=A0=C2=A0 1 (msg_type): 3 (MACed message),<= /p>

=C2=A0=C2=A0=C2=A0=C2=A0 2 (protected): h'a10= 104' (alg:HS256),

=C2=A0=C2=A0= =C2=A0=C2=A0 4 (payload): h'546869732069732074686520636f6e74656e742e= 9;,

=C2=A0=C2=A0=C2=A0=C2=A0 10 (ta= g): h'2ba937ca03d76c3dbad30cfcbaeef586f9c0f9ba616ad67e9205d3857<= u>

=C2=A0=C2=A0 6ad9930',

=C2=A0=

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

=C2=A0

MINOR ISSUES

=C2=A0

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

=C2=A0

2.=C2=A0 The COSE_= MSG structure

=C2=A0<= /p>

a.=C2=A0 Change:

=C2=A0=C2=A0 Im= plementations MUST be prepared to find an integer under this label

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

=C2=A0=C2=A0 then the clie= nt MUST stop attempting to parse the structure and fail.

to:

=C2=A0=C2=A0 Implementati= ons MUST be prepared to find an integer under this label

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

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

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

=C2=A0

[JLS] I = do not believe that this is required.=C2=A0 If you implement a new item, th= en you don=E2=80=99t have a pure implementation of this document and the cl= ause is implicit.

=C2=A0<= /u>

b.=C2=A0 This syntax needs more explan= ation:

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

=

=C2=A0

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

=C2=A0

[JLS]=C2=A0 This falls in to the question o= f normative reference on CDDL.=C2=A0 If it is a normative reference, this i= s not necessary as you are expected to understand CDDL.=C2=A0 If CDDL is in= formational, then it would be required.

=C2=A0

c.=C2=A0 Change:

<= span style=3D"font-family:"Courier New"">=C2=A0=C2=A0 | ciphertex= t=C2=A0 | 4=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | TODO: Should we re-use the same= as payload |

=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 | or not?=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 |

to:<= /u>

=C2=A0=C2=A0 | ciphertext=C2=A0 | 7=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 | For COSE_encrypt=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

It=E2=80=99s cleaner= not to reuse the same label value for different semantic meanings.=C2=A0 I= f we do that, we might come to regret it as the spec evolves.=C2=A0 Besides= , it=E2=80=99s not like using another short integer value here will cause u= s to run out of them in this context.

=C2=A0

[JLS]=C2=A0 The TODO is a marker for future discussion =E2=80=93 There are= both advantages and disadvantages to re-using the same label.=C2=A0 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.=C2=A0 This may make thin= gs easier for items which have detached content depending on how the API ha= ndles this.=C2=A0 On the other hand, an API might want to have them separat= e.=C2=A0=C2=A0 I don=E2=80=99t know what the answer for this is yet.=

=C2=A0

d.=C2=A0 Change:

=C2=A0 These two buckets

=C2=A0=C2=A0 are avai= lable for use in all of the structures in this document

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

=C2=A0=C2=A0 all be usable in all = instances.

to:=

=C2=A0 These two buckets

=C2=A0=C2=A0 are defin= ed for use in all of the structures in this document

=C2=A0=C2=A0 be usable or used in all inst= ances.

=C2=A0

The new text makes it clearer that =E2=80=9Cprotected=E2=80=9D an= d =E2=80=9Cunprotected=E2=80=9D can=E2=80=99t be included where their value= s can=E2=80=99t be used.

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

=C2=A0

3.1.=C2=A0 COSE Headers

=C2=A0

e.=C2=A0 Change:<= /u>

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

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

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 understand.

to:

=C2=A0 The field is used to indicate which protecte= d header keys

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 define= d by extensions to this specification that

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 an application that is processing a message is req= uired to

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 understand.=

=C2=A0

The language should make it clear that =E2=80=9Ccrit=E2= =80=9D is only for defining behavior of critical extensions =E2=80=93 not f= or making header parameters defined by this spec critical.

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

=C2=A0<= u>

f.=C2=A0 In Table 2, change:=

=C2=A0=C2=A0 | jku=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | *=C2=A0=C2=A0= =C2=A0=C2=A0 | tstr=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 | URL to COSE key object=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 | jwk=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 | *=C2=A0=C2=A0=C2=A0=C2=A0 | COSE_Key |=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | contains a COSE key not |

=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 | a JWK key=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |<= /span>

to:

=C2=A0= =C2=A0 | jku=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | *=C2=A0=C2=A0=C2=A0=C2=A0 | ts= tr=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 | URL to JWK [RFC 7517] =C2=A0=C2=A0|<= /p>

=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| cku=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 | *=C2=A0=C2=A0=C2=A0=C2=A0 | tstr=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 | URL to COSE key ob= ject=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= | ck=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0| *=C2=A0=C2=A0=C2=A0=C2=A0 | COS= E_Key |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | conta= ins a COSE key=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 |

=C2=A0

It still makes sense to be able to represent URLs to JWK an= d COSE Key objects.=C2=A0 But we shouldn=E2=80=99t call the COSE Key passed= by value =E2=80=9Cjwk=E2=80=9D, since that=E2=80=99s misleading.=

[JLS] Thus the ope= n issue marker.

=C2=A0

g.=C2= =A0 =C2=A0=C2=A0=C2=A0Open Issue 1.=C2=A0 Which of the following items do w= e want to have standardized in

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this document: jku, jwk, x5c, x5t, x5t#S2= 56, x5u, zip?

=C2=A0<= /p>

I would keep all of them, other than changing =E2= =80=9Cjku=E2=80=9D and =E2=80=9Cjwk=E2=80=9D to =E2=80=9Cjku=E2=80=9D, =E2= =80=9Ccku=E2=80=9D, and =E2=80=9Cck=E2=80=9D per (f) above.

[JLS] This will be a dis= cussion issue.

=C2=A0=

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

<= p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 algorithm specif= ic or generic headers?"

=C2=A0=

I would define common labels for t= hem since they are commonly used across multiple algorithms.<= /p>

=C2=A0

4.= =C2=A0 Signing Structure

=C2=A0<= /u>

i.=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 The description of =E2=80=9Cprotected=E2= =80=9D says =E2=80=9CThe field MUST NOT hold attributes about the payload b= eing signed=E2=80=9D.=C2=A0 Assuming that a flattened syntax is added, this= would then become something like =E2=80=9CThe field MUST NOT hold attribut= es about the payload being signed unless the flattened serialization is bei= ng used=E2=80=9D.=C2=A0 Other related statements throughout the document wo= uld likewise need to be similarly updated.

[JLS] But it is not current added =E2=80= =93 so this is not currently an actionable statement.<= /p>

=C2=A0

j.= =C2=A0 The end of the signing section says:

=C2=A0=C2=A0 I= n addition to performing the signature verification, one must also

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

=C2=A0=C2=A0 paired with the s= igning identity and that the appropriate

=C2=A0= =C2=A0 authorization is done.

=C2=A0

There needs to be a refere= nce to a place where the process of verifying the key=E2=80=99s association= with the signing identity is described.=C2=A0 Particular methods are clear= ly 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 sh= ould reference?

=C2=A0

5.=C2=A0 Encryption Object=

=C2=A0

k= .=C2=A0 The introduction to this section says:

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

=C2=A0=C2=A0 doing an encryption in COSE.=C2=A0 In C= OSE, we use the same techniques and

=C2=A0=C2=A0 st= ructures for encrypting both the plain text and the keys used to<= /u>

=C2=A0=C2=A0protect the text.=C2=A0 This is different from th= e approach used by both

=C2=A0=C2=A0 [RFC5652] and = [RFC7516] where different structures are used for the<= /p>

=C2=A0=C2=A0 plain text and for the different key management techniques.=

=C2=A0

I=E2=80=99ll note that if issue 3 is resolved (Wrapp= ed 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 a= ctionable statement.

=C2=A0<= u>

l.=C2=A0 A generic =E2=80=9Civ=E2= =80=9D (initialization vector) field should also be defined in the list of = parameters for the encryption object.=C2=A0 Yes, not all algorithms will us= e it, but many will.

=C2=A0<= u>

m.=C2=A0 A =E2=80=9Ctag=E2=80=9D (authenti= cation tag) field should be defined in the list of parameters for the encry= ption object.=C2=A0 Yes, not all the algorithms will use it, but many will.=

[JLS] Ma= ybe true for =E2=80=98iv=E2=80=99, however =E2=80=98tag=E2=80=99 is part of= the ciphertext.

=C2=A0

5.1.1.=C2=A0 Direct Encryption

=C2=A0

n.=C2=A0 The spec says:

=C2=A0=C2=A0 o=C2=A0 At a mini= mum, the 'unprotected' field MUST contain the 'alg'<= u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 parameter and SHOULD contai= n a parameter identifying the shared

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 secret.

= =C2=A0

SHOULD is too strong here be= cause in some protocols, the shared secret will already be known by methods= other than an included =E2=80=9Ckid=E2=80=9D or other key selection value.= =C2=A0 A =E2=80=9CSHOULD =E2=80=A6 unless =E2=80=A6=E2=80=9D construct like= was used in similar JOSE descriptions is probably the right thing to use h= ere.

[JLS= ] The =E2=80=A6unless=E2=80=A6 clause is confusing as hell so I do not plan= to include it.=C2=A0 The definition of SHOULD means that put it there unle= ss you have a good reason not to do so.

=C2=A0

6.=C2=A0 MAC Obj= ects

=C2=A0

o.=C2=A0 The =E2=80=9CHow to compute a MAC=E2=80=9D instru= ctions say:

=C2=A0=C2=A0 5.=C2=A0 Encrypt and encode the M= AC key for each recipient of the message.

=C2=A0

This is not c= orrect when direct key management or no key management is used.=C2=A0 Pleas= e revise to accurately include these cases as well.

[JLS} This is correct for the cu= rrent document.

=C2=A0

7.=C2=A0 Key Structure

=

=C2=A0

p.=C2= =A0 The spec says:

=C2=A0=C2=A0 The "key_ops" el= ement is preferred over the "use" element as the=

=C2=A0=C2=A0 information provided that way is more finely detailed = about the

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

=C2=A0= =C2=A0 present for all keys.

=C2=A0

Like in (n), the applicatio= n may know the key usage from application context, rendering the inclusion = of =E2=80=9Ckey_ops=E2=80=9D unnecessary.=C2=A0 Language something like =E2= =80=9CIt is strongly suggested that this element be present for all keys un= less this information is already know to the application through other mean= s=E2=80=9D should be used to capture this.

=C2=A0

The working group sh= ould also discuss whether it wants to carry forward =E2=80=9Cuse=E2=80=9D f= or JWK compatibility, even if it is deprecated.=C2=A0 I personally would be= in favor of doing so.

[JLS] If you think this, then please open it as a discussion= issue.=C2=A0 I don=E2=80=99t see any good use for it that is not better se= rved by =E2=80=98key_ops=E2=80=99.=C2=A0 This is doubly true given that the= W3C Crypto group

=C2=A0<= /u>

q.=C2=A0 I would define short numeric = values that correspond to the defines =E2=80=9Ckey_ops=E2=80=9D string valu= es.=C2=A0 I=E2=80=99d do the same for the =E2=80=9Cuse=E2=80=9D values.<= /u>

[JLS] Yes th= is will be happening going forward.

=C2=A0

8.=C2=A0 CBOR Encode= r Restrictions

=C2=A0=

r.=C2=A0 The spec says:

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

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

=C2=A0

I would strongly = prefer that the =E2=80=9CSHOULD=E2=80=9D be changed to =E2=80=9CMUST=E2=80= =9D.=C2=A0 CBOR doesn=E2=80=99t have the same legacy of lax parsers that we= inherited from JavaScript/ECMAscript for JSON.=C2=A0 Let=E2=80=99s not ope= n the door to them!

=C2=A0

9.5=C2=A0 COSE Algorithm Registry=

=C2=A0

s.=C2=A0 I would add an additional =E2=80=9CJOSE algorithm name=E2=80=9D= field to this registry, whose value is the corresponding =E2=80=9CAlgorith= m Name=E2=80=9D entry in the IANA JSON Web Signature and Encryption Algorit= hms registry at http://www.iana.org/= assignments/jose/jose.xhtml#web-signature-encryption-algorithms, if suc= h an entry exists.=C2=A0 This will tie the two registries together so that = definitions of algorithms already defined by JOSE need not be repeated for = COSE.

=C2=A0

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

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

=C2=A0

9.8.1=C2=A0 COSE Security Message

=C2=A0

t.=C2=A0 Besides = registering the MIME type =E2=80=9Capplication/cose=E2=80=9D, I would also = register one for a base64url encoded COSE message =E2=80=93 an idea first d= escribed to me by Joe Hildebrand.=C2=A0 It could be called =E2=80=9Capplica= tion/cose+base64url=E2=80=9D or something of that ilk.

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

=C2=A0

9.8.2=C2=A0 COSE Key Media Type

=C2=A0

u.=C2=A0 = =E2=80=9Capplication/jwk+json=E2=80=9D should be changed to something like = =E2=80=9Capplication/cose-key=E2=80=9D and =E2=80=9Capplication/jwk-set+jso= n=E2=80=9D should be changed to something like =E2=80=9Capplication/cose-ke= y-set=E2=80=9D.

=C2=A0

11.2.=C2=A0 Informative References

=C2=A0

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

=C2= =A0

Appendix A.=C2=A0 AEAD and AE A= lgorithms

=C2=A0

<= p class=3D"MsoNormal">w.=C2=A0 The spec says:

=C2=A0 This = authentication value may be:

=C2=A0=C2=A0 o=C2=A0 A= separately generated tag computed by both the encrypter and<= u>

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

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 be either placed at the end of the cipher text (the deci= sion we

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 made) or kep= t separately (the decision made by the JOSE working

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

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 AES-CCM [RFC3610].

= =C2=A0

The last sentence is not tru= e, as written.=C2=A0 The AES-GCM spec describes =E2=80=9Cthe ciphertext and tag outputs=E2=80=9D =E2=80=93 not= a single combined output.=C2=A0 Common implementations correspond to this,= such as the implementation of GCM in .NET.

=C2=A0

The CCM description= in RFC 3610 Section 2.4 describes the output using the text =E2=80=9CThe f= inal result c consists of the encrypted message followed by the encrypted a= uthentication value U=E2=80=9D, which admits either implementation.=C2=A0 L= ikewise, at least the .NET CCM implementation produces separate ciphertext = and authentication tag values.

=C2= =A0

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

=C2=A0

[JLS] Wrong reference =E2=80=93will correct.

=C2=A0

Appendix C.=C2=A0 Examples

=C2= =A0

x.=C2=A0 The uses of strings an= d corresponding labels such as those that follow are confusing =E2=80=93 es= pecially since key ID values are binary in COSE.=C2=A0 A fragment of such a= n example that confused me was:

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 3: {

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

=

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 },

=C2=A0

Ther= e are similar strings in some of the other examples that I also couldn=E2= =80=99t wrap my head around.

[JLS] My code does not match the spec here.=C2=A0 Origi= nally they were strings.

=C2= =A0

Appendix D.=C2=A0 COSE Header A= lgorithm Label Table

=C2=A0<= u>

y.=C2=A0 I would change the term =E2=80=9C= Header Algorithm=E2=80=9D to =E2=80=9CHeader Parameter=E2=80=9D.=C2=A0 (I s= uspect this was a cut-and-paste error.)

[JLS] I have not settled on a consistent set= of terms for this yet.=C2=A0 I need to do so and then make a pass to corre= ct them all.=C2=A0 I don=E2=80=99t think that some of the terms I am curren= tly using are sufficiently distinct to make it easy to figure things out.

=C2=A0

z.=C2=A0 In Appendix D and Appendix E, I would call out t= hat the names in the =E2=80=9Cname=E2=80=9D columns correspond to names def= ined in RFC 7518.

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

=C2=A0

Appendix F.=C2=A0 COSE Gen= eral Values

=C2=A0

aa.=C2=A0 This seems confused, as it mixes =E2=80= =9Ckty=E2=80=9D values (EC=3D1, RSA=3D2, oct=3D3) with curve values (P256= =3D4, P521=3D5).=C2=A0 I would keep these separate.=C2=A0 Also, wherever th= e curve names are defined, I would also include P384, as JOSE did.

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

=C2=A0

NITS

=C2= =A0

I will be submitting spelling a= nd grammar corrections as a GitHub pull request against the spec repository= rather than detail them here.=C2=A0 I=E2=80=99ll post the pull request lin= k once it=E2=80=99s been created.

= =C2=A0

CONCLUSIONS=

=C2=A0

I=E2=80=99d like to thank Jim for doing the work to produce a well-thoug= ht-out initial draft.=C2=A0 I believe it provides a solid starting point fo= r the COSE work.

=C2=A0

I=E2=80=99d be willing to produce specific pro= posed edits for any/all of the above issues and comments, should the editor= s find that useful.

=C2=A0<= u>

=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 Best wishes,

=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

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

=C2=A0

<= /div>


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

=C2=A0