From rbarnes@bbn.com Mon Jul 2 11:06:59 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0578221F86BE for ; Mon, 2 Jul 2012 11:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.536 X-Spam-Level: X-Spam-Status: No, score=-106.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXzjvbwXQcxo for ; Mon, 2 Jul 2012 11:06:58 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 35B9021F858E for ; Mon, 2 Jul 2012 11:06:58 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:63083) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sll1a-000B7w-Lj for jose@ietf.org; Mon, 02 Jul 2012 14:07:02 -0400 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Jul 2012 14:07:02 -0400 References: <32228A90-A4D4-493A-93AC-2F30643C3187@bbn.com> To: jose@ietf.org Message-Id: <140C6B2D-8BE8-4202-91F4-65D6693D3D79@bbn.com> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [jose] Fwd: [Cfrg] Question from JOSE working group X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 18:06:59 -0000 FYI, trying to recruit some additional crypto expertise on this = question. --Richard Begin forwarded message: > From: "Richard L. Barnes" > Subject: [Cfrg] Question from JOSE working group > Date: July 2, 2012 2:00:11 PM EDT > To: cfrg@irtf.org >=20 > Dear CFRG, >=20 > This is a request for input on a crypto question that has come up in = the JOSE working group. >=20 > The question is whether there is any benefit to applying integrity = protection to cryptographic parameters attached to a = signed/authenticated/encrypted object. By "cryptographic parameters" = here, I mean public keys, wrapped symmetric keys, algorithm identifiers, = etc. >=20 > For historical background: >=20 > CMS does not provide parameter protection [RFC5652]. The content that = is signed / authenticated / encrypted is precisely the protected content = (eContent). Optionally, an application may add signed attributes. In = the case of SignedData and AuthenticatedData, if signed attributes are = present, then they must include the message digest that was signed or = authenticated; not a parameter, but an intermediate result. >=20 > IKE and TLS does not provide integrity protection for parameters = [RFC4306][RFC5246]. Algorithm negotiation is done in parallel with key = agreement in the initial phase of IKEv2 Algorithm negotiation in TLS = is done in the ClientHello / ServerHello messages, which are sent before = the secure channel is established. When TLS client certificates are = used, the client demonstrates its possession of the relevant private key = by signing the handshake messages, which provides an integrity check on = cryptographic parameters as a side-effect. However, the parameters for = this signature (the public key and signature/hash algorithms) are not = protected. >=20 > PKIX is an intermediate case. The signature algorithm used to sign / = verify the certificate is included in the certificate body (under the = signature) as well as ouside the signature. >=20 > Back to today: >=20 > The current draft specifications for JOSE [JWS][JWE] require integrity = protection for parameters. The creator of an object constructs a = "header" value including the cryptographic parameters used to generate = the object. This header value is prepended to the protected content = before the content is signed / authenticated (JWS), or attached as = "Associated Data" to the encrypted content (JWE). (JWE only allows AEAD = algorithms.) >=20 > So the questions for this group are the following:=20 > -- Does applying integrity protection to cryptographic parameters = result in a meaningful increase the security of an secure object format? = =20 > -- What are the classes of attack that this integrity protection would = address? > -- Does parameter protection create any additional security = vulnerabilities? >=20 > Any input would be very helpful for the group to decide on a way = forward. >=20 > Thanks a lot, > --Richard >=20 >=20 > [RFC5652] > [RFC4306] > [RFC5246] > [RFC5280] > [JWS] > [JWE] >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From ben@adida.net Mon Jul 2 11:21:15 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EB721F87AD for ; Mon, 2 Jul 2012 11:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+ykCma9N-Ci for ; Mon, 2 Jul 2012 11:21:14 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2F01621F87AB for ; Mon, 2 Jul 2012 11:21:14 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 54A5C20BFD for ; Mon, 2 Jul 2012 14:21:19 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 02 Jul 2012 14:21:19 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=9tm+4xqLBeRtlDAdcB9YOw TxLVA=; b=GA+Ea2FOe2Kh03C577MuWOruE9DFsGDVBOzsS+kteO1q56eVEtT3lM j6qqbH1o4Je1k8K8nOdkeT2tXMC74fIYR0ClC2ikfzVFiGjsvIIc4xt4KEbWR+qC i6QoDmZ38KqTJKojqax85ttkL6l8/ENQ47W6pdz9sTDkcNZFv59eA= X-Sasl-enc: SZTMD/JY6SDdwekB/9ftyOOYE9f1eJxaF/e5Kvam4BS3 1341253279 Received: from host-7-163.mv.mozilla.com (unknown [63.245.220.240]) by mail.messagingengine.com (Postfix) with ESMTPA id F141C482722 for ; Mon, 2 Jul 2012 14:21:18 -0400 (EDT) Message-ID: <4FF1E6A0.3060606@adida.net> Date: Mon, 02 Jul 2012 11:21:20 -0700 From: Ben Adida User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: jose@ietf.org References: <32228A90-A4D4-493A-93AC-2F30643C3187@bbn.com> <140C6B2D-8BE8-4202-91F4-65D6693D3D79@bbn.com> In-Reply-To: <140C6B2D-8BE8-4202-91F4-65D6693D3D79@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [jose] Fwd: [Cfrg] Question from JOSE working group X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 18:21:15 -0000 My take: yes, there is value. The crypto parameters will trigger different processing on the payload, and that *might* be usable, by some crafty cryptanalyst, as an oracle. It would be more conservative (and thus safer) to follow one rule: there are only two execution paths that can be triggered by the recipient of a crypto blob. (1) error, or (2) processing of payload according to authenticated sender's specifications. -Ben On 7/2/12 11:07 AM, Richard L. Barnes wrote: > FYI, trying to recruit some additional crypto expertise on this question. > > --Richard > > > Begin forwarded message: > >> From: "Richard L. Barnes" >> Subject: [Cfrg] Question from JOSE working group >> Date: July 2, 2012 2:00:11 PM EDT >> To: cfrg@irtf.org >> >> Dear CFRG, >> >> This is a request for input on a crypto question that has come up in the JOSE working group. >> >> The question is whether there is any benefit to applying integrity protection to cryptographic parameters attached to a signed/authenticated/encrypted object. By "cryptographic parameters" here, I mean public keys, wrapped symmetric keys, algorithm identifiers, etc. >> >> For historical background: >> >> CMS does not provide parameter protection [RFC5652]. The content that is signed / authenticated / encrypted is precisely the protected content (eContent). Optionally, an application may add signed attributes. In the case of SignedData and AuthenticatedData, if signed attributes are present, then they must include the message digest that was signed or authenticated; not a parameter, but an intermediate result. >> >> IKE and TLS does not provide integrity protection for parameters [RFC4306][RFC5246]. Algorithm negotiation is done in parallel with key agreement in the initial phase of IKEv2 Algorithm negotiation in TLS is done in the ClientHello / ServerHello messages, which are sent before the secure channel is established. When TLS client certificates are used, the client demonstrates its possession of the relevant private key by signing the handshake messages, which provides an integrity check on cryptographic parameters as a side-effect. However, the parameters for this signature (the public key and signature/hash algorithms) are not protected. >> >> PKIX is an intermediate case. The signature algorithm used to sign / verify the certificate is included in the certificate body (under the signature) as well as ouside the signature. >> >> Back to today: >> >> The current draft specifications for JOSE [JWS][JWE] require integrity protection for parameters. The creator of an object constructs a "header" value including the cryptographic parameters used to generate the object. This header value is prepended to the protected content before the content is signed / authenticated (JWS), or attached as "Associated Data" to the encrypted content (JWE). (JWE only allows AEAD algorithms.) >> >> So the questions for this group are the following: >> -- Does applying integrity protection to cryptographic parameters result in a meaningful increase the security of an secure object format? >> -- What are the classes of attack that this integrity protection would address? >> -- Does parameter protection create any additional security vulnerabilities? >> >> Any input would be very helpful for the group to decide on a way forward. >> >> Thanks a lot, >> --Richard >> >> >> [RFC5652] >> [RFC4306] >> [RFC5246] >> [RFC5280] >> [JWS] >> [JWE] >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Mon Jul 2 11:21:22 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069B021F87B4 for ; Mon, 2 Jul 2012 11:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.26 X-Spam-Level: X-Spam-Status: No, score=-5.26 tagged_above=-999 required=5 tests=[AWL=1.339, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qp5bV7o5fIp for ; Mon, 2 Jul 2012 11:21:21 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1D421F87B3 for ; Mon, 2 Jul 2012 11:21:21 -0700 (PDT) Received: from mail76-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.23; Mon, 2 Jul 2012 18:19:29 +0000 Received: from mail76-tx2 (localhost [127.0.0.1]) by mail76-tx2-R.bigfish.com (Postfix) with ESMTP id 157332C02BC; Mon, 2 Jul 2012 18:19:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -33 X-BigFish: VS-33(zf7Iz9371I1b0bM542M1432Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail76-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail76-tx2 (localhost.localdomain [127.0.0.1]) by mail76-tx2 (MessageSwitch) id 1341253167165357_28945; Mon, 2 Jul 2012 18:19:27 +0000 (UTC) Received: from TX2EHSMHS043.bigfish.com (unknown [10.9.14.248]) by mail76-tx2.bigfish.com (Postfix) with ESMTP id 24CFF120044; Mon, 2 Jul 2012 18:19:27 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS043.bigfish.com (10.9.99.143) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 2 Jul 2012 18:19:25 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0309.003; Mon, 2 Jul 2012 18:21:21 +0000 From: Mike Jones To: "Richard L. Barnes" , "jose@ietf.org" Thread-Topic: [jose] Fwd: [Cfrg] Question from JOSE working group Thread-Index: AQHNWH2DQEDIOoHj2kaDBtHFC7NBAZcWTYKQ Date: Mon, 2 Jul 2012 18:21:20 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366572DF5@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <32228A90-A4D4-493A-93AC-2F30643C3187@bbn.com> <140C6B2D-8BE8-4202-91F4-65D6693D3D79@bbn.com> In-Reply-To: <140C6B2D-8BE8-4202-91F4-65D6693D3D79@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] Fwd: [Cfrg] Question from JOSE working group X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 18:21:22 -0000 You should reply-all into the cfrg thread, saying that XMLDSIG does integri= ty protect the algorithm and other parameters, since you're giving them oth= er examples of choices made by systems. -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard L. Barnes Sent: Monday, July 02, 2012 11:07 AM To: jose@ietf.org Subject: [jose] Fwd: [Cfrg] Question from JOSE working group FYI, trying to recruit some additional crypto expertise on this question. --Richard Begin forwarded message: > From: "Richard L. Barnes" > Subject: [Cfrg] Question from JOSE working group > Date: July 2, 2012 2:00:11 PM EDT > To: cfrg@irtf.org >=20 > Dear CFRG, >=20 > This is a request for input on a crypto question that has come up in the = JOSE working group. >=20 > The question is whether there is any benefit to applying integrity protec= tion to cryptographic parameters attached to a signed/authenticated/encrypt= ed object. By "cryptographic parameters" here, I mean public keys, wrapped= symmetric keys, algorithm identifiers, etc. >=20 > For historical background: >=20 > CMS does not provide parameter protection [RFC5652]. The content that is= signed / authenticated / encrypted is precisely the protected content (eCo= ntent). Optionally, an application may add signed attributes. In the case= of SignedData and AuthenticatedData, if signed attributes are present, the= n they must include the message digest that was signed or authenticated; no= t a parameter, but an intermediate result. >=20 > IKE and TLS does not provide integrity protection for parameters [RFC4306= ][RFC5246]. Algorithm negotiation is done in parallel with key agreement i= n the initial phase of IKEv2 Algorithm negotiation in TLS is done in the = ClientHello / ServerHello messages, which are sent before the secure channe= l is established. When TLS client certificates are used, the client demons= trates its possession of the relevant private key by signing the handshake = messages, which provides an integrity check on cryptographic parameters as = a side-effect. However, the parameters for this signature (the public key = and signature/hash algorithms) are not protected. >=20 > PKIX is an intermediate case. The signature algorithm used to sign / ver= ify the certificate is included in the certificate body (under the signatur= e) as well as ouside the signature. >=20 > Back to today: >=20 > The current draft specifications for JOSE [JWS][JWE] require integrity pr= otection for parameters. The creator of an object constructs a "header" va= lue including the cryptographic parameters used to generate the object. Th= is header value is prepended to the protected content before the content is= signed / authenticated (JWS), or attached as "Associated Data" to the encr= ypted content (JWE). (JWE only allows AEAD algorithms.) >=20 > So the questions for this group are the following:=20 > -- Does applying integrity protection to cryptographic parameters result = in a meaningful increase the security of an secure object format? =20 > -- What are the classes of attack that this integrity protection would ad= dress? > -- Does parameter protection create any additional security vulnerabiliti= es? >=20 > Any input would be very helpful for the group to decide on a way forward. >=20 > Thanks a lot, > --Richard >=20 >=20 > [RFC5652] > [RFC4306] > [RFC5246] > [RFC5280] > [JWS] > [JWE] >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From rbarnes@bbn.com Mon Jul 2 11:26:29 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE3C11E80E5 for ; Mon, 2 Jul 2012 11:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.537 X-Spam-Level: X-Spam-Status: No, score=-106.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLeqY5qjRYRS for ; Mon, 2 Jul 2012 11:26:28 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 11A6D11E80D1 for ; Mon, 2 Jul 2012 11:26:27 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:63215) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SllKQ-0006VC-SS; Mon, 02 Jul 2012 14:26:30 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366572DF5@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 2 Jul 2012 14:26:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <32228A90-A4D4-493A-93AC-2F30643C3187@bbn.com> <140C6B2D-8BE8-4202-91F4-65D6693D3D79@bbn.com> <4E1F6AAD24975D4BA5B168042967394366572DF5@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1278) Cc: "jose@ietf.org" Subject: Re: [jose] Fwd: [Cfrg] Question from JOSE working group X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 18:26:29 -0000 I'm actually not that familiar with DSig; you're welcome to comment. --Richard On Jul 2, 2012, at 2:21 PM, Mike Jones wrote: > You should reply-all into the cfrg thread, saying that XMLDSIG does = integrity protect the algorithm and other parameters, since you're = giving them other examples of choices made by systems. >=20 > -- Mike >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Richard L. Barnes > Sent: Monday, July 02, 2012 11:07 AM > To: jose@ietf.org > Subject: [jose] Fwd: [Cfrg] Question from JOSE working group >=20 > FYI, trying to recruit some additional crypto expertise on this = question. >=20 > --Richard >=20 >=20 > Begin forwarded message: >=20 >> From: "Richard L. Barnes" >> Subject: [Cfrg] Question from JOSE working group >> Date: July 2, 2012 2:00:11 PM EDT >> To: cfrg@irtf.org >>=20 >> Dear CFRG, >>=20 >> This is a request for input on a crypto question that has come up in = the JOSE working group. >>=20 >> The question is whether there is any benefit to applying integrity = protection to cryptographic parameters attached to a = signed/authenticated/encrypted object. By "cryptographic parameters" = here, I mean public keys, wrapped symmetric keys, algorithm identifiers, = etc. >>=20 >> For historical background: >>=20 >> CMS does not provide parameter protection [RFC5652]. The content = that is signed / authenticated / encrypted is precisely the protected = content (eContent). Optionally, an application may add signed = attributes. In the case of SignedData and AuthenticatedData, if signed = attributes are present, then they must include the message digest that = was signed or authenticated; not a parameter, but an intermediate = result. >>=20 >> IKE and TLS does not provide integrity protection for parameters = [RFC4306][RFC5246]. Algorithm negotiation is done in parallel with key = agreement in the initial phase of IKEv2 Algorithm negotiation in TLS = is done in the ClientHello / ServerHello messages, which are sent before = the secure channel is established. When TLS client certificates are = used, the client demonstrates its possession of the relevant private key = by signing the handshake messages, which provides an integrity check on = cryptographic parameters as a side-effect. However, the parameters for = this signature (the public key and signature/hash algorithms) are not = protected. >>=20 >> PKIX is an intermediate case. The signature algorithm used to sign / = verify the certificate is included in the certificate body (under the = signature) as well as ouside the signature. >>=20 >> Back to today: >>=20 >> The current draft specifications for JOSE [JWS][JWE] require = integrity protection for parameters. The creator of an object = constructs a "header" value including the cryptographic parameters used = to generate the object. This header value is prepended to the protected = content before the content is signed / authenticated (JWS), or attached = as "Associated Data" to the encrypted content (JWE). (JWE only allows = AEAD algorithms.) >>=20 >> So the questions for this group are the following:=20 >> -- Does applying integrity protection to cryptographic parameters = result in a meaningful increase the security of an secure object format? = =20 >> -- What are the classes of attack that this integrity protection = would address? >> -- Does parameter protection create any additional security = vulnerabilities? >>=20 >> Any input would be very helpful for the group to decide on a way = forward. >>=20 >> Thanks a lot, >> --Richard >>=20 >>=20 >> [RFC5652] >> [RFC4306] >> [RFC5246] >> [RFC5280] >> [JWS] >> [JWE] = >>=20 >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Mon Jul 2 11:33:58 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E6E11E80EF for ; Mon, 2 Jul 2012 11:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.78 X-Spam-Level: X-Spam-Status: No, score=-3.78 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JN7zlyLfo3Jv for ; Mon, 2 Jul 2012 11:33:58 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9900011E80F3 for ; Mon, 2 Jul 2012 11:33:57 -0700 (PDT) Received: from mail88-db3-R.bigfish.com (10.3.81.226) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Mon, 2 Jul 2012 18:32:05 +0000 Received: from mail88-db3 (localhost [127.0.0.1]) by mail88-db3-R.bigfish.com (Postfix) with ESMTP id 4F4CE4E05CE; Mon, 2 Jul 2012 18:32:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -32 X-BigFish: VS-32(zz9371I1b0bM542M1432Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah) Received-SPF: pass (mail88-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail88-db3 (localhost.localdomain [127.0.0.1]) by mail88-db3 (MessageSwitch) id 1341253919606124_15011; Mon, 2 Jul 2012 18:31:59 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.249]) by mail88-db3.bigfish.com (Postfix) with ESMTP id 900AC240137; Mon, 2 Jul 2012 18:31:59 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 2 Jul 2012 18:31:58 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0298.005; Mon, 2 Jul 2012 18:33:32 +0000 From: Mike Jones To: "cfrg@irtf.org" Thread-Topic: [Cfrg] Question from JOSE working group Thread-Index: Ac1YgS4wo9tuM20zQ029ZMkY7eroAQ== Date: Mon, 2 Jul 2012 18:33:31 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366572E8A@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] [Cfrg] Question from JOSE working group X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 18:33:58 -0000 Dear cfrg, Since Richard is providing examples of choices made by other systems, I'll = add that XML DSIG http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124/ does= integrity protect the algorithm and other parameters. -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard L. Barnes Sent: Monday, July 02, 2012 11:07 AM To: jose@ietf.org Subject: [jose] Fwd: [Cfrg] Question from JOSE working group FYI, trying to recruit some additional crypto expertise on this question. --Richard Begin forwarded message: > From: "Richard L. Barnes" > Subject: [Cfrg] Question from JOSE working group > Date: July 2, 2012 2:00:11 PM EDT > To: cfrg@irtf.org >=20 > Dear CFRG, >=20 > This is a request for input on a crypto question that has come up in the = JOSE working group. >=20 > The question is whether there is any benefit to applying integrity protec= tion to cryptographic parameters attached to a signed/authenticated/encrypt= ed object. By "cryptographic parameters" here, I mean public keys, wrapped= symmetric keys, algorithm identifiers, etc. >=20 > For historical background: >=20 > CMS does not provide parameter protection [RFC5652]. The content that is= signed / authenticated / encrypted is precisely the protected content (eCo= ntent). Optionally, an application may add signed attributes. In the case= of SignedData and AuthenticatedData, if signed attributes are present, the= n they must include the message digest that was signed or authenticated; no= t a parameter, but an intermediate result. >=20 > IKE and TLS does not provide integrity protection for parameters [RFC4306= ][RFC5246]. Algorithm negotiation is done in parallel with key agreement i= n the initial phase of IKEv2 Algorithm negotiation in TLS is done in the = ClientHello / ServerHello messages, which are sent before the secure channe= l is established. When TLS client certificates are used, the client demons= trates its possession of the relevant private key by signing the handshake = messages, which provides an integrity check on cryptographic parameters as = a side-effect. However, the parameters for this signature (the public key = and signature/hash algorithms) are not protected. >=20 > PKIX is an intermediate case. The signature algorithm used to sign / ver= ify the certificate is included in the certificate body (under the signatur= e) as well as ouside the signature. >=20 > Back to today: >=20 > The current draft specifications for JOSE [JWS][JWE] require integrity pr= otection for parameters. The creator of an object constructs a "header" va= lue including the cryptographic parameters used to generate the object. Th= is header value is prepended to the protected content before the content is= signed / authenticated (JWS), or attached as "Associated Data" to the encr= ypted content (JWE). (JWE only allows AEAD algorithms.) >=20 > So the questions for this group are the following:=20 > -- Does applying integrity protection to cryptographic parameters result = in a meaningful increase the security of an secure object format? =20 > -- What are the classes of attack that this integrity protection would ad= dress? > -- Does parameter protection create any additional security vulnerabiliti= es? >=20 > Any input would be very helpful for the group to decide on a way forward. >=20 > Thanks a lot, > --Richard >=20 >=20 > [RFC5652] > [RFC4306] > [RFC5246] > [RFC5280] > [JWS] > [JWE] >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From housley@vigilsec.com Mon Jul 2 12:43:17 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C22411E8083 for ; Mon, 2 Jul 2012 12:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.933 X-Spam-Level: X-Spam-Status: No, score=-101.933 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtLxSOluGEHW for ; Mon, 2 Jul 2012 12:43:16 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id A14F821F8704 for ; Mon, 2 Jul 2012 12:43:16 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 9415BF24047; Mon, 2 Jul 2012 15:43:32 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id v9HIBgaxHh9Q; Mon, 2 Jul 2012 15:43:13 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-10-63.washdc.fios.verizon.net [96.255.10.63]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 7F04DF24040; Mon, 2 Jul 2012 15:43:31 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Jul 2012 15:43:20 -0400 Message-Id: To: "cfrg@irtf.org" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: "jose@ietf.org" Subject: Re: [jose] [Cfrg] Question from JOSE working group X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 19:43:17 -0000 In the CMS signature processing, the hash algorithm is covered by the = signature. The hash algorithm is a signed attribute, and the collection = of signed attributes is hashed as part of the signature process. Other parameters of the signature algorithm, if any, are not integrity = protected. The thinking is that the signature algorithm is seriously = flawed is a change to the parameters will make an invalid signature seem = valid. Russ Begin forwarded message: > From: "Richard L. Barnes" > Subject: [Cfrg] Question from JOSE working group > Date: July 2, 2012 2:00:11 PM EDT > To: cfrg@irtf.org >=20 > Dear CFRG, >=20 > This is a request for input on a crypto question that has come up in = the JOSE working group. >=20 > The question is whether there is any benefit to applying integrity = protection to cryptographic parameters attached to a = signed/authenticated/encrypted object. By "cryptographic parameters" = here, I mean public keys, wrapped symmetric keys, algorithm identifiers, = etc. >=20 > For historical background: >=20 > CMS does not provide parameter protection [RFC5652]. The content that = is signed / authenticated / encrypted is precisely the protected content = (eContent). Optionally, an application may add signed attributes. In = the case of SignedData and AuthenticatedData, if signed attributes are = present, then they must include the message digest that was signed or = authenticated; not a parameter, but an intermediate result. >=20 > IKE and TLS does not provide integrity protection for parameters = [RFC4306][RFC5246]. Algorithm negotiation is done in parallel with key = agreement in the initial phase of IKEv2 Algorithm negotiation in TLS = is done in the ClientHello / ServerHello messages, which are sent before = the secure channel is established. When TLS client certificates are = used, the client demonstrates its possession of the relevant private key = by signing the handshake messages, which provides an integrity check on = cryptographic parameters as a side-effect. However, the parameters for = this signature (the public key and signature/hash algorithms) are not = protected. >=20 > PKIX is an intermediate case. The signature algorithm used to sign / = verify the certificate is included in the certificate body (under the = signature) as well as ouside the signature. >=20 > Back to today: >=20 > The current draft specifications for JOSE [JWS][JWE] require integrity = protection for parameters. The creator of an object constructs a = "header" value including the cryptographic parameters used to generate = the object. This header value is prepended to the protected content = before the content is signed / authenticated (JWS), or attached as = "Associated Data" to the encrypted content (JWE). (JWE only allows AEAD = algorithms.) >=20 > So the questions for this group are the following:=20 > -- Does applying integrity protection to cryptographic parameters = result in a meaningful increase the security of an secure object format? = =20 > -- What are the classes of attack that this integrity protection would = address? > -- Does parameter protection create any additional security = vulnerabilities? >=20 > Any input would be very helpful for the group to decide on a way = forward. >=20 > Thanks a lot, > --Richard >=20 >=20 > [RFC5652] > [RFC4306] > [RFC5246] > [RFC5280] > [JWS] > [JWE] >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ Cfrg mailing list Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg From rbarnes@bbn.com Mon Jul 2 13:02:10 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE4211E80A3; Mon, 2 Jul 2012 13:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.54 X-Spam-Level: X-Spam-Status: No, score=-106.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUFRYLspSw3C; Mon, 2 Jul 2012 13:02:09 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 55A8D11E8083; Mon, 2 Jul 2012 13:02:09 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:63483) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Slmoy-0008Oa-Rl; Mon, 02 Jul 2012 16:02:08 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Mon, 2 Jul 2012 16:02:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <41F795C1-BD4F-4732-8F1A-62F909E9AA07@bbn.com> References: To: Russ Housley X-Mailer: Apple Mail (2.1278) Cc: "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [jose] [Cfrg] Question from JOSE working group X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 20:02:10 -0000 Actually, the inclusion of the hash algorithm under the signature is = optional: " signedAttrs is a collection of attributes that are signed. The field is optional, but it MUST be present if the content type of the EncapsulatedContentInfo value being signed is not id-data. [...] If the field is present, it MUST contain, at a minimum, the following two attributes: ... A message-digest attribute, having as its value the message digest of the content. Section 11.2 defines the message-digest attribute. " Since "id-data" means "no more ASN.1 structure", for JOSE, the content = type is effectively always "id-data". --Richard On Jul 2, 2012, at 3:43 PM, Russ Housley wrote: > In the CMS signature processing, the hash algorithm is covered by the = signature. The hash algorithm is a signed attribute, and the collection = of signed attributes is hashed as part of the signature process. >=20 > Other parameters of the signature algorithm, if any, are not integrity = protected. The thinking is that the signature algorithm is seriously = flawed is a change to the parameters will make an invalid signature seem = valid. >=20 > Russ >=20 >=20 > Begin forwarded message: >=20 >> From: "Richard L. Barnes" >> Subject: [Cfrg] Question from JOSE working group >> Date: July 2, 2012 2:00:11 PM EDT >> To: cfrg@irtf.org >>=20 >> Dear CFRG, >>=20 >> This is a request for input on a crypto question that has come up in = the JOSE working group. >>=20 >> The question is whether there is any benefit to applying integrity = protection to cryptographic parameters attached to a = signed/authenticated/encrypted object. By "cryptographic parameters" = here, I mean public keys, wrapped symmetric keys, algorithm identifiers, = etc. >>=20 >> For historical background: >>=20 >> CMS does not provide parameter protection [RFC5652]. The content = that is signed / authenticated / encrypted is precisely the protected = content (eContent). Optionally, an application may add signed = attributes. In the case of SignedData and AuthenticatedData, if signed = attributes are present, then they must include the message digest that = was signed or authenticated; not a parameter, but an intermediate = result. >>=20 >> IKE and TLS does not provide integrity protection for parameters = [RFC4306][RFC5246]. Algorithm negotiation is done in parallel with key = agreement in the initial phase of IKEv2 Algorithm negotiation in TLS = is done in the ClientHello / ServerHello messages, which are sent before = the secure channel is established. When TLS client certificates are = used, the client demonstrates its possession of the relevant private key = by signing the handshake messages, which provides an integrity check on = cryptographic parameters as a side-effect. However, the parameters for = this signature (the public key and signature/hash algorithms) are not = protected. >>=20 >> PKIX is an intermediate case. The signature algorithm used to sign / = verify the certificate is included in the certificate body (under the = signature) as well as ouside the signature. >>=20 >> Back to today: >>=20 >> The current draft specifications for JOSE [JWS][JWE] require = integrity protection for parameters. The creator of an object = constructs a "header" value including the cryptographic parameters used = to generate the object. This header value is prepended to the protected = content before the content is signed / authenticated (JWS), or attached = as "Associated Data" to the encrypted content (JWE). (JWE only allows = AEAD algorithms.) >>=20 >> So the questions for this group are the following:=20 >> -- Does applying integrity protection to cryptographic parameters = result in a meaningful increase the security of an secure object format? = =20 >> -- What are the classes of attack that this integrity protection = would address? >> -- Does parameter protection create any additional security = vulnerabilities? >>=20 >> Any input would be very helpful for the group to decide on a way = forward. >>=20 >> Thanks a lot, >> --Richard >>=20 >>=20 >> [RFC5652] >> [RFC4306] >> [RFC5246] >> [RFC5280] >> [JWS] >> [JWE] = >>=20 >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From rbarnes@bbn.com Mon Jul 2 13:05:01 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEFC11E80A3; Mon, 2 Jul 2012 13:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.542 X-Spam-Level: X-Spam-Status: No, score=-106.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUczTBbxY51O; Mon, 2 Jul 2012 13:04:59 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE8411E80B3; Mon, 2 Jul 2012 13:04:59 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:63493) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Slmrm-000CY1-FH; Mon, 02 Jul 2012 16:05:02 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <32228A90-A4D4-493A-93AC-2F30643C3187@bbn.com> Date: Mon, 2 Jul 2012 16:05:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <76A75405-ACBB-474F-AE9A-845F1AA65E54@bbn.com> References: <32228A90-A4D4-493A-93AC-2F30643C3187@bbn.com> To: cfrg@irtf.org X-Mailer: Apple Mail (2.1278) Cc: jose@ietf.org Subject: Re: [jose] [Cfrg] Question from JOSE working group X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 20:05:01 -0000 Here's my analysis of the question, as it stands right now. =46rom what I can tell, parameter protection is at best a marginal = improvement, and at worst actively harmful: 1. The possible benefits are a corner case 2. The JW* syntax increases vulnerability to chosen-prefix attacks 3. The JWE syntax creates operational risks in multiple-recipient = scenarios 1. The possible benefits are a corner case A JOSE object is defined by three main things: The algorithm A = (including associated parameters), the key K, and the message M. An = attack on the integrity of a JOSE object is a transformation of these = parameters and the integrity check value A(K,M) such that the attacker = can create another valid integrity check value A'(K',M'), causing the = recipient to accept a bogus integrity check value. Obviously, An attack = is only relevant if either the key or the message changes, since the = algorithm holds no inherent meaning. For example, in the attack (A,K,M)-->(A,K,M'), the recipient would accept a bogus message under the correct key. Under = the attack (A,K,M)-->(A,K',M) the recipient would accept a correct message, but under the wrong key. = There are obviously seven different attacks in this model (excluding the = trivial "attack").=20 There is value in parameter protection only in cases where an attacker = can mount a successful attack against an object with unprotected = parameters, but cannot attack an object with protected parameters. So = we should examine each of the seven different types of attacker = capabilities here and see whether they extend to protected objects. =46rom the perspective of this model, the impact of adding integrity = protection on the parameters is to add them to the message M. So we can = immediately note that parameter protection is useless against the four = attacks in which the message M is modified. If the attacker can change = the protected content, then he can also change the protected parameter = values, since they are, aftera all, just more content octets. We can also ignore the two attacks where neither the key K nor the = message M changes, since these don't represent a meaningful attack. So the only possible benefit is from the two remaining cases where the = key changes, but the message does not. That is, parameter protection = has value only if one of the following implications is *false*: (1) (A,K,M)-->(A,K',M) =3D=3D> (A,K,M)-->(A,K',M') (2) (A,K,M)-->(A',K',M) =3D=3D> (A,K,M)-->(A',K',M') In these cases, in order to overcome the parameter integrity protection, = the attacker would need to be able to modify the part of the message = containing the parameters. Only if the attacker is unable to make this = modification does the protection have value.=20 I don't know whether these implications are true or false in general, = but there are at least some cases in which they are true. For example: -- Implication (1) is true for HMAC: If you can change the key, then you = have effectively broken the hash function, so you should be able to = change the content as well. -- Implication (1) is true for RSA-PSS, because the security of RSA-PSS = is equivalent to the factoring problem [RSAPSS] The change of algorithm question in implication (2) is an exotic one, = and AFAICT, there's not much literature on it. ISTM most likely to = arise in the context of related algorithms, e.g., elliptic curves of the = same size with different parameters. (This could, of course, be = mitigated by requiring named curves, one per field size!) Other than = that, it seems like the differences in mathematics would make it = unlikely that a valid key for one algorithm would collide. Of course, = the assumption here is=20 Summing up all of the above: Parameter protection seems to only be = useful under highly constrained assumptions on attacker capabilities. 2. The JWS syntax increases vulnerability to chosen-prefix attacks There has been a lot of press lately about Flame's use of a = chosen-prefix attack against MD5 to generate bogus code-signing = certificates [Flame-MD5]. In general, chosen-prefix attacks have been a = fairly fruitful avenue of attack against hash functions, with MD5 = clearly broken, and significant progress having been made against SHA-1 = [SHA1Prefix]. In the JWS signing process, the header value is prepended to the content = before the whole thing is digested and signed/authenticated. In = practice, for a given signer, the JWS header is likely to be predictable = to an attacker. So JWS has a built-in predictable prefix that can be = exploited for chosen-prefix attacks. JWS also defeats efforts that applications might make to mitigate = chosen-prefix attacks. In PKIX, for example, the recommended mitigation = to MD5's weaknesses is to randomize the fields that come early in the = certificate, so that the length of the available prefix is minimized = [RFC4270]. In JWS, however, even if an application put unpredictable = things early in the content body, the JWS signing process prepends = something predictable, so the efforts of the application are for naught. = =20 Thus, if the JOSE format ultimately does protect parameters, then it = will need to include a mandatory random element at the beginning of the = protected header. 3. The JWE syntax creates operational risks in multiple-recipient = scenarios One of the major use-cases for JOSE is for encrypting messages to be = received by multiple entities holding different private keys. In this = context, integrity-protecting parameters causes a couple of operational = concerns, arising from the fact that the wrapped key is included under = the integrity check. First, if there is any delay between the sending of the original object = and the transmission of wrapped keys, then the sender needs to cache the = entire object and re-process it to compute a new integrity check value = whenever a new recipient is added. Moreover, the object needs to be = cached in plaintext, exposing it to risks of being stolen on the = originating host while it resides in cache. By contrast, without parameter protection, only the encryption key needs = to be cached; the content itself can be deleted. So even though there = is a risk that the cached key will leak, it can at least be separated = from the protected content, to reduce the ultimate risk that the content = will be exposed. Reference: [RSAPSS] [Flame-MD5] = [SHA1Prefix] [RFC4270] On Jul 2, 2012, at 2:00 PM, Richard L. Barnes wrote: > Dear CFRG, >=20 > This is a request for input on a crypto question that has come up in = the JOSE working group. >=20 > The question is whether there is any benefit to applying integrity = protection to cryptographic parameters attached to a = signed/authenticated/encrypted object. By "cryptographic parameters" = here, I mean public keys, wrapped symmetric keys, algorithm identifiers, = etc. >=20 > For historical background: >=20 > CMS does not provide parameter protection [RFC5652]. The content that = is signed / authenticated / encrypted is precisely the protected content = (eContent). Optionally, an application may add signed attributes. In = the case of SignedData and AuthenticatedData, if signed attributes are = present, then they must include the message digest that was signed or = authenticated; not a parameter, but an intermediate result. >=20 > IKE and TLS does not provide integrity protection for parameters = [RFC4306][RFC5246]. Algorithm negotiation is done in parallel with key = agreement in the initial phase of IKEv2 Algorithm negotiation in TLS = is done in the ClientHello / ServerHello messages, which are sent before = the secure channel is established. When TLS client certificates are = used, the client demonstrates its possession of the relevant private key = by signing the handshake messages, which provides an integrity check on = cryptographic parameters as a side-effect. However, the parameters for = this signature (the public key and signature/hash algorithms) are not = protected. >=20 > PKIX is an intermediate case. The signature algorithm used to sign / = verify the certificate is included in the certificate body (under the = signature) as well as ouside the signature. >=20 > Back to today: >=20 > The current draft specifications for JOSE [JWS][JWE] require integrity = protection for parameters. The creator of an object constructs a = "header" value including the cryptographic parameters used to generate = the object. This header value is prepended to the protected content = before the content is signed / authenticated (JWS), or attached as = "Associated Data" to the encrypted content (JWE). (JWE only allows AEAD = algorithms.) >=20 > So the questions for this group are the following:=20 > -- Does applying integrity protection to cryptographic parameters = result in a meaningful increase the security of an secure object format? = =20 > -- What are the classes of attack that this integrity protection would = address? > -- Does parameter protection create any additional security = vulnerabilities? >=20 > Any input would be very helpful for the group to decide on a way = forward. >=20 > Thanks a lot, > --Richard >=20 >=20 > [RFC5652] > [RFC4306] > [RFC5246] > [RFC5280] > [JWS] > [JWE] >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From ve7jtb@ve7jtb.com Mon Jul 2 14:00:50 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC0B11E812B for ; Mon, 2 Jul 2012 14:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.445 X-Spam-Level: X-Spam-Status: No, score=-3.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcbY54TMuZVK for ; Mon, 2 Jul 2012 14:00:49 -0700 (PDT) Received: from mail-yw0-f53.google.com (mail-yw0-f53.google.com [209.85.213.53]) by ietfa.amsl.com (Postfix) with ESMTP id 51E7311E80BA for ; Mon, 2 Jul 2012 14:00:49 -0700 (PDT) Received: by yhp26 with SMTP id 26so6385946yhp.26 for ; Mon, 02 Jul 2012 14:00:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=fzwH74rjM6ItPpQlPsp/w3h7yB88b5FwALlmXFB2Z0Q=; b=fogBqtNY6I/4ZUfOwRv9A3lUVWyiF4Pd3hhDPIY42qwa9Ricg7g+paT8AQo/UN0rqF XdT2K0EJRmuUJHjagvGfB017z4Z7SNpk4zmbRE7k434YbCEVGYttJlZz0oBJ8p9+jB7I DcrKT6I0pBJx3MlFqIxUr9UZU7G+3Batd2beIfOpXqG8I9uP1Vu0NZuExAyhIV48GKRb cL79vZG+6NfWaChsstUULsvzy4mB0mw8e8JauecvE8x56Qnwo7Rnfzg24lW2YiONr+5n b2CwF0xsnN1a/ur4eTU5ks3QNEEuIETDRH7uf1DKPX+frnxzu8tgXyjp74pf4nurvccN VELQ== Received: by 10.236.181.71 with SMTP id k47mr11483069yhm.69.1341262854613; Mon, 02 Jul 2012 14:00:54 -0700 (PDT) Received: from [192.168.1.211] (190-20-50-6.baf.movistar.cl. [190.20.50.6]) by mx.google.com with ESMTPS id p14sm12672864ani.8.2012.07.02.14.00.51 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jul 2012 14:00:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_0EFAC52B-FD4E-418E-89B3-6A239AD3520A"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <76A75405-ACBB-474F-AE9A-845F1AA65E54@bbn.com> Date: Mon, 2 Jul 2012 17:00:43 -0400 Message-Id: References: <32228A90-A4D4-493A-93AC-2F30643C3187@bbn.com> <76A75405-ACBB-474F-AE9A-845F1AA65E54@bbn.com> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnMEtrX/VL+IwTkOgtqm1QN3LMu0Uy5GIZZHoJPhK9mU7veBMYuJjXDtHwWaartnaz8wuGo Cc: cfrg@irtf.org, jose@ietf.org Subject: Re: [jose] [Cfrg] Question from JOSE working group X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 21:00:50 -0000 --Apple-Mail=_0EFAC52B-FD4E-418E-89B3-6A239AD3520A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Richard, Chosen-prefix attacks require the text of both messages to be the same = up to the point where the attacker can insert the collision function = blocks. If the header is not integrity protected the attacker is able to insert = collision function blocks at the start of the plan text. I have a hard = time seeing the attacker controlling the entire plaintext as "better" in = any way. If anything JWS and JWE should be including a nonce or timestamp in the = header to prevent this attack. That requires integrity protecting the = header with the nonce. JOSE was constructed to make no assumptions about the plaintext. Saying = the protocol using JOSE should deal with it in the plaintext is not all = that useful if arbitrary bodes are allowed for signing and encrypting. That is one reason CMS allows for the integrity protect of additional = attributes. Regards John Bradley On 2012-07-02, at 4:05 PM, Richard L. Barnes wrote: > Here's my analysis of the question, as it stands right now. >=20 > =46rom what I can tell, parameter protection is at best a marginal = improvement, and at worst actively harmful: > 1. The possible benefits are a corner case > 2. The JW* syntax increases vulnerability to chosen-prefix attacks > 3. The JWE syntax creates operational risks in multiple-recipient = scenarios >=20 >=20 > 1. The possible benefits are a corner case >=20 > A JOSE object is defined by three main things: The algorithm A = (including associated parameters), the key K, and the message M. An = attack on the integrity of a JOSE object is a transformation of these = parameters and the integrity check value A(K,M) such that the attacker = can create another valid integrity check value A'(K',M'), causing the = recipient to accept a bogus integrity check value. Obviously, An attack = is only relevant if either the key or the message changes, since the = algorithm holds no inherent meaning. For example, in the attack > (A,K,M)-->(A,K,M'), > the recipient would accept a bogus message under the correct key. = Under the attack > (A,K,M)-->(A,K',M) > the recipient would accept a correct message, but under the wrong key. = There are obviously seven different attacks in this model (excluding = the trivial "attack").=20 >=20 > There is value in parameter protection only in cases where an attacker = can mount a successful attack against an object with unprotected = parameters, but cannot attack an object with protected parameters. So = we should examine each of the seven different types of attacker = capabilities here and see whether they extend to protected objects. >=20 > =46rom the perspective of this model, the impact of adding integrity = protection on the parameters is to add them to the message M. So we can = immediately note that parameter protection is useless against the four = attacks in which the message M is modified. If the attacker can change = the protected content, then he can also change the protected parameter = values, since they are, aftera all, just more content octets. >=20 > We can also ignore the two attacks where neither the key K nor the = message M changes, since these don't represent a meaningful attack. >=20 > So the only possible benefit is from the two remaining cases where the = key changes, but the message does not. That is, parameter protection = has value only if one of the following implications is *false*: > (1) (A,K,M)-->(A,K',M) =3D=3D> (A,K,M)-->(A,K',M') > (2) (A,K,M)-->(A',K',M) =3D=3D> (A,K,M)-->(A',K',M') > In these cases, in order to overcome the parameter integrity = protection, the attacker would need to be able to modify the part of the = message containing the parameters. Only if the attacker is unable to = make this modification does the protection have value.=20 >=20 > I don't know whether these implications are true or false in general, = but there are at least some cases in which they are true. For example: > -- Implication (1) is true for HMAC: If you can change the key, then = you have effectively broken the hash function, so you should be able to = change the content as well. > -- Implication (1) is true for RSA-PSS, because the security of = RSA-PSS is equivalent to the factoring problem [RSAPSS] >=20 > The change of algorithm question in implication (2) is an exotic one, = and AFAICT, there's not much literature on it. ISTM most likely to = arise in the context of related algorithms, e.g., elliptic curves of the = same size with different parameters. (This could, of course, be = mitigated by requiring named curves, one per field size!) Other than = that, it seems like the differences in mathematics would make it = unlikely that a valid key for one algorithm would collide. Of course, = the assumption here is=20 >=20 > Summing up all of the above: Parameter protection seems to only be = useful under highly constrained assumptions on attacker capabilities. >=20 >=20 >=20 > 2. The JWS syntax increases vulnerability to chosen-prefix attacks >=20 > There has been a lot of press lately about Flame's use of a = chosen-prefix attack against MD5 to generate bogus code-signing = certificates [Flame-MD5]. In general, chosen-prefix attacks have been a = fairly fruitful avenue of attack against hash functions, with MD5 = clearly broken, and significant progress having been made against SHA-1 = [SHA1Prefix]. >=20 > In the JWS signing process, the header value is prepended to the = content before the whole thing is digested and signed/authenticated. In = practice, for a given signer, the JWS header is likely to be predictable = to an attacker. So JWS has a built-in predictable prefix that can be = exploited for chosen-prefix attacks. >=20 > JWS also defeats efforts that applications might make to mitigate = chosen-prefix attacks. In PKIX, for example, the recommended mitigation = to MD5's weaknesses is to randomize the fields that come early in the = certificate, so that the length of the available prefix is minimized = [RFC4270]. In JWS, however, even if an application put unpredictable = things early in the content body, the JWS signing process prepends = something predictable, so the efforts of the application are for naught. = =20 >=20 > Thus, if the JOSE format ultimately does protect parameters, then it = will need to include a mandatory random element at the beginning of the = protected header. >=20 >=20 >=20 > 3. The JWE syntax creates operational risks in multiple-recipient = scenarios >=20 > One of the major use-cases for JOSE is for encrypting messages to be = received by multiple entities holding different private keys. In this = context, integrity-protecting parameters causes a couple of operational = concerns, arising from the fact that the wrapped key is included under = the integrity check. >=20 > First, if there is any delay between the sending of the original = object and the transmission of wrapped keys, then the sender needs to = cache the entire object and re-process it to compute a new integrity = check value whenever a new recipient is added. Moreover, the object = needs to be cached in plaintext, exposing it to risks of being stolen on = the originating host while it resides in cache. >=20 > By contrast, without parameter protection, only the encryption key = needs to be cached; the content itself can be deleted. So even though = there is a risk that the cached key will leak, it can at least be = separated from the protected content, to reduce the ultimate risk that = the content will be exposed. >=20 >=20 >=20 > Reference: > [RSAPSS] > [Flame-MD5] = > [SHA1Prefix] = > [RFC4270] >=20 >=20 > On Jul 2, 2012, at 2:00 PM, Richard L. Barnes wrote: >=20 >> Dear CFRG, >>=20 >> This is a request for input on a crypto question that has come up in = the JOSE working group. >>=20 >> The question is whether there is any benefit to applying integrity = protection to cryptographic parameters attached to a = signed/authenticated/encrypted object. By "cryptographic parameters" = here, I mean public keys, wrapped symmetric keys, algorithm identifiers, = etc. >>=20 >> For historical background: >>=20 >> CMS does not provide parameter protection [RFC5652]. The content = that is signed / authenticated / encrypted is precisely the protected = content (eContent). Optionally, an application may add signed = attributes. In the case of SignedData and AuthenticatedData, if signed = attributes are present, then they must include the message digest that = was signed or authenticated; not a parameter, but an intermediate = result. >>=20 >> IKE and TLS does not provide integrity protection for parameters = [RFC4306][RFC5246]. Algorithm negotiation is done in parallel with key = agreement in the initial phase of IKEv2 Algorithm negotiation in TLS = is done in the ClientHello / ServerHello messages, which are sent before = the secure channel is established. When TLS client certificates are = used, the client demonstrates its possession of the relevant private key = by signing the handshake messages, which provides an integrity check on = cryptographic parameters as a side-effect. However, the parameters for = this signature (the public key and signature/hash algorithms) are not = protected. >>=20 >> PKIX is an intermediate case. The signature algorithm used to sign / = verify the certificate is included in the certificate body (under the = signature) as well as ouside the signature. >>=20 >> Back to today: >>=20 >> The current draft specifications for JOSE [JWS][JWE] require = integrity protection for parameters. The creator of an object = constructs a "header" value including the cryptographic parameters used = to generate the object. This header value is prepended to the protected = content before the content is signed / authenticated (JWS), or attached = as "Associated Data" to the encrypted content (JWE). (JWE only allows = AEAD algorithms.) >>=20 >> So the questions for this group are the following:=20 >> -- Does applying integrity protection to cryptographic parameters = result in a meaningful increase the security of an secure object format? = =20 >> -- What are the classes of attack that this integrity protection = would address? >> -- Does parameter protection create any additional security = vulnerabilities? >>=20 >> Any input would be very helpful for the group to decide on a way = forward. >>=20 >> Thanks a lot, >> --Richard >>=20 >>=20 >> [RFC5652] >> [RFC4306] >> [RFC5246] >> [RFC5280] >> [JWS] >> [JWE] = >>=20 >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_0EFAC52B-FD4E-418E-89B3-6A239AD3520A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcw MjIxMDA0NFowIwYJKoZIhvcNAQkEMRYEFIlu0dssk7OSCNMRXB5C3EBu2WVoMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AHhFUYdIiIBuBdCE7dfvFXMFtbioMV4f0wtfqxb9OA1mfcGcbYXkTrr0n+O9gSG+KDInVHVZXdUk jZqqhc5iHHy5MibfofwVK6d17zfyv5lDHw/EwCzLYp+wkqEuIT1JIc7NvMRCyAhQaMo/3kvtYwTx LKS/OhL4xVKat+rcfOv/WhOB9DA4+kQqttx5gWjMuHcnFOKiwToEU9xVTOgYuYBYIdFZ3g+5KGi9 O/8KqYP72ZMSOi8YR5ka+8DmDNQRhTnd4eLJN43rDQVq1wgK3sJWX73h6CtglwMJ1Sohul3hlddw 9ZNTpbe7IGMWqcFnWwVReJ/qCR9qtmuK0UWt93wAAAAAAAA= --Apple-Mail=_0EFAC52B-FD4E-418E-89B3-6A239AD3520A-- From ve7jtb@ve7jtb.com Mon Jul 2 15:40:18 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889D811E80CE for ; Mon, 2 Jul 2012 15:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+I8+NF1xfMi for ; Mon, 2 Jul 2012 15:40:18 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E10BC11E8072 for ; Mon, 2 Jul 2012 15:40:17 -0700 (PDT) Received: by yenq13 with SMTP id q13so5157214yen.31 for ; Mon, 02 Jul 2012 15:40:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=FuPEUNz0RGOQrNcWpZg0OOUvqTMZEbrFDMuLSYRDCSs=; b=ChSUvqrajy3tiM11N4ahAo/CktwfT4o+6fiY/2JZUxxalZNz/5XPTizPqIEeYaOko9 CmjC1kOxZC5ifqiBhjICCgWpODPpLGDdqQ7yJqPonho6CImk+0ZLYXOFSQ5oskfzjT4s FEjnlVM7gwA343Za5Nvw+9HXg46kmJW9sCEeS43WuI6WrLtlezvrT5q5JB8pkpMJhwnw nkRacqK36zrtGs6AizWwmRTYQUAnieYX89i8u4vp6NkFOhmbWl/gUtqg9CIJHlUCI/dq dKzOtX+VEDDcQrJTl1GTKCP8O75Sg3CSAWXU90TsvIVsAV/GZha7ryTGb+qPfHIdJp5+ jgDQ== Received: by 10.236.165.74 with SMTP id d50mr17236527yhl.118.1341268823767; Mon, 02 Jul 2012 15:40:23 -0700 (PDT) Received: from [192.168.1.211] (190-20-50-6.baf.movistar.cl. [190.20.50.6]) by mx.google.com with ESMTPS id k67sm27822393yhj.18.2012.07.02.15.40.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jul 2012 15:40:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_303FD340-641E-4FAF-A220-52B7E32A1446"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <7DF2365FF07C0E4E89419D65CCC93C9E018FF3683736@EXCHANGE11.campus.tue.nl> Date: Mon, 2 Jul 2012 18:40:03 -0400 Message-Id: <58091EAC-6E16-48FD-A698-A4BF64C60DEB@ve7jtb.com> References: <32228A90-A4D4-493A-93AC-2F30643C3187@bbn.com> <76A75405-ACBB-474F-AE9A-845F1AA65E54@bbn.com> <7DF2365FF07C0E4E89419D65CCC93C9E018FF3683736@EXCHANGE11.campus.tue.nl> To: "Weger, B.M.M. de" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmNso9+DQDpQ564/x5sLjZVZiIrEFUCYz8n0TusUGOpNufdR1kK6wW6/0vmhi1s2rwOo9JQ Cc: "Richard L. Barnes" , "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [jose] [Cfrg] Question from JOSE working group X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 22:40:18 -0000 --Apple-Mail=_303FD340-641E-4FAF-A220-52B7E32A1446 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes sorry JOSE would not be susceptible to chosen prefix unless we allow = the attacker to control the entire plaintext. As it is now the header is controlled by the signer. I think Richard was referring to an identical prefix attack being = possible due to the header without a nonce or date stamp being = relatively deterministic. In ether event integrity protecting the header is not increasing the = vulnerability. Thanks few the correction. Regards John Bradley On 2012-07-02, at 6:19 PM, Weger, B.M.M. de wrote: > Hi John, >=20 >> Chosen-prefix attacks require the text of both messages to be the = same up >> to the point where the attacker can insert the collision function = blocks. >=20 > Correction:=20 > It's identical-prefix attacks that require the text of both messages = to be=20 > the same up to the point where the attacker can insert the collision = blocks. > That's exactly why these attacks are called "identical-prefix". >=20 > Chosen-prefix attacks allow the attacker to choose whatever he wants = in > each of the two messages up to the point where ... etc. >=20 > Chosen-prefix attacks fail if the attacker has no sufficient control = over /=20 > cannot sufficiently predict this part of the messages. >=20 > Grtz, > Benne de Weger --Apple-Mail=_303FD340-641E-4FAF-A220-52B7E32A1446 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcw MjIyNDAwNFowIwYJKoZIhvcNAQkEMRYEFFdYaQHhBYLl3i25wurn8OWIVWtZMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AFqvB2U0cHbFa9cEsolUQuiyHnytCgZNpRaxYKYVHlyFydKfgEMdNOdFDsvgHL1spxgDy4FIo6/5 KtZwi4gPeBxQkrsyAzYP+fNiJ8oNst1eKPs0wbgdU9LLnIuPAS1Zh09D/Y1EGRxH1biWYVkA4wME 39K+f56HHWoQMhAxLC9wszRx0m3wdtSsyStnkXI4IjLgIuJb3P8gE+SUkzmB5DGYOTornIBr9hSi g1X5h9oSKIJ+/hMYeptqffUoQhhYkhhRkg9W/oJfriSt+c6LBZvWAj04JRvWOVxRXeAJookJuYty EEbZPAuQ00Ov4XSFEEMVlyL0C5+pJ5NgK4htJocAAAAAAAA= --Apple-Mail=_303FD340-641E-4FAF-A220-52B7E32A1446-- From b.m.m.d.weger@TUE.nl Mon Jul 2 15:19:18 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A56821F85AE for ; Mon, 2 Jul 2012 15:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYsJZ38ruiaN for ; Mon, 2 Jul 2012 15:19:18 -0700 (PDT) Received: from mailhost.tue.nl (mailhost.tue.nl [131.155.3.8]) by ietfa.amsl.com (Postfix) with ESMTP id CE8F321F859F for ; Mon, 2 Jul 2012 15:19:17 -0700 (PDT) Received: from kweetal.tue.nl (localhost [127.0.0.1]) by mailhost.tue.nl (Postfix) with ESMTP id 9E8CC287CD; Tue, 3 Jul 2012 00:19:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at tue.nl Received: from mailhost.tue.nl ([131.155.3.8]) by kweetal.tue.nl (kweetal.tue.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8YbOYJk52Cg; Tue, 3 Jul 2012 00:19:21 +0200 (CEST) Received: from webmail10.campus.tue.nl (Webmail10.campus.tue.nl [131.155.6.46]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailhost.tue.nl (Postfix) with ESMTPS id 767F8287CC; Tue, 3 Jul 2012 00:19:21 +0200 (CEST) Received: from EXCHANGE11.campus.tue.nl ([131.155.6.31]) by webmail10.campus.tue.nl ([131.155.6.46]) with mapi; Tue, 3 Jul 2012 00:19:21 +0200 From: "Weger, B.M.M. de" To: John Bradley , "Richard L. Barnes" Date: Tue, 3 Jul 2012 00:19:20 +0200 Thread-Topic: [Cfrg] [jose] Question from JOSE working group Thread-Index: Ac1Ylc9XRxClBkD6TOaghE+skesfSgACSsqw Message-ID: <7DF2365FF07C0E4E89419D65CCC93C9E018FF3683736@EXCHANGE11.campus.tue.nl> References: <32228A90-A4D4-493A-93AC-2F30643C3187@bbn.com> <76A75405-ACBB-474F-AE9A-845F1AA65E54@bbn.com> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 02 Jul 2012 16:42:05 -0700 Cc: "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [jose] [Cfrg] Question from JOSE working group X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 22:19:18 -0000 Hi John, > Chosen-prefix attacks require the text of both messages to be the same up > to the point where the attacker can insert the collision function blocks. Correction:=20 It's identical-prefix attacks that require the text of both messages to be= =20 the same up to the point where the attacker can insert the collision blocks= . That's exactly why these attacks are called "identical-prefix". Chosen-prefix attacks allow the attacker to choose whatever he wants in each of the two messages up to the point where ... etc. Chosen-prefix attacks fail if the attacker has no sufficient control over /= =20 cannot sufficiently predict this part of the messages. Grtz, Benne de Weger From housley@vigilsec.com Tue Jul 3 08:01:44 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F4C11E8153 for ; Tue, 3 Jul 2012 08:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.154 X-Spam-Level: X-Spam-Status: No, score=-102.154 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Z6f1+M8oBRH for ; Tue, 3 Jul 2012 08:01:43 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 7157711E814E for ; Tue, 3 Jul 2012 08:01:43 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id B7722F24046; Tue, 3 Jul 2012 11:02:09 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id H3o0moNMwZka; Tue, 3 Jul 2012 11:01:33 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-10-63.washdc.fios.verizon.net [96.255.10.63]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id E144FF2403D; Tue, 3 Jul 2012 11:02:05 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <41F795C1-BD4F-4732-8F1A-62F909E9AA07@bbn.com> Date: Tue, 3 Jul 2012 11:01:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1499CA50-2239-4102-BA1A-04104EAC57DF@vigilsec.com> References: <41F795C1-BD4F-4732-8F1A-62F909E9AA07@bbn.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1084) Cc: "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [jose] [Cfrg] Question from JOSE working group X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 15:01:45 -0000 Richard: > Actually, the inclusion of the hash algorithm under the signature is = optional: > " > signedAttrs is a collection of attributes that are signed. The > field is optional, but it MUST be present if the content type of > the EncapsulatedContentInfo value being signed is not id-data. > [...] If the field is present, it MUST > contain, at a minimum, the following two attributes: >=20 > ... >=20 > A message-digest attribute, having as its value the message > digest of the content. Section 11.2 defines the = message-digest > attribute. > " >=20 > Since "id-data" means "no more ASN.1 structure", for JOSE, the content = type is effectively always "id-data". In practice, there are other attributes that one wants signed, such as = signing-time, so the algorithm identifier gets included. Russ From ietf@augustcellars.com Tue Jul 3 10:45:08 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE1B11E8175 for ; Tue, 3 Jul 2012 10:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.381 X-Spam-Level: X-Spam-Status: No, score=-3.381 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKxh9ZlqCtPn for ; Tue, 3 Jul 2012 10:45:05 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id C531111E815E for ; Tue, 3 Jul 2012 10:45:05 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 984CF2CA0E; Tue, 3 Jul 2012 10:45:13 -0700 (PDT) From: "Jim Schaad" To: "'Russ Housley'" , "'Richard L.Barnes'" References: <41F795C1-BD4F-4732-8F1A-62F909E9AA07@bbn.com> <1499CA50-2239-4102-BA1A-04104EAC57DF@vigilsec.com> In-Reply-To: <1499CA50-2239-4102-BA1A-04104EAC57DF@vigilsec.com> Date: Tue, 3 Jul 2012 10:43:51 -0700 Message-ID: <03b301cd5943$693f2800$3bbd7800$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDe91NbMO1Nq06fh8taxrYdt/CHCALpPHJBAWJNYUmY0jtbkA== Content-Language: en-us Cc: cfrg@irtf.org, jose@ietf.org Subject: Re: [jose] [Cfrg] Question from JOSE working group X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 17:45:08 -0000 I would also note that when PKCS#7 was designed, the hash algorithm was always protected independent the presence of signed attributes. Either the hash algorithm was in the signed attributes or it was in the RSA signature block encoding. It was only with the introduction of other algorithms that this was no longer true. Jim > -----Original Message----- > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of > Russ Housley > Sent: Tuesday, July 03, 2012 8:02 AM > To: Richard L.Barnes > Cc: cfrg@irtf.org; jose@ietf.org > Subject: Re: [Cfrg] Question from JOSE working group > > Richard: > > > Actually, the inclusion of the hash algorithm under the signature is optional: > > " > > signedAttrs is a collection of attributes that are signed. The > > field is optional, but it MUST be present if the content type of > > the EncapsulatedContentInfo value being signed is not id-data. > > [...] If the field is present, it MUST > > contain, at a minimum, the following two attributes: > > > > ... > > > > A message-digest attribute, having as its value the message > > digest of the content. Section 11.2 defines the message-digest > > attribute. > > " > > > > Since "id-data" means "no more ASN.1 structure", for JOSE, the content > type is effectively always "id-data". > > In practice, there are other attributes that one wants signed, such as signing- > time, so the algorithm identifier gets included. > > Russ > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From rbarnes@bbn.com Tue Jul 3 12:58:27 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9A521F86D5; Tue, 3 Jul 2012 12:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.543 X-Spam-Level: X-Spam-Status: No, score=-106.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45E5ZNi-Ei77; Tue, 3 Jul 2012 12:58:26 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 57A7421F854E; Tue, 3 Jul 2012 12:58:26 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:52297) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sm9F1-000LaW-UK; Tue, 03 Jul 2012 15:58:31 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <03b301cd5943$693f2800$3bbd7800$@augustcellars.com> Date: Tue, 3 Jul 2012 15:58:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7C1A94EE-8633-4FA7-A936-E82FDA6A5FB9@bbn.com> References: <41F795C1-BD4F-4732-8F1A-62F909E9AA07@bbn.com> <1499CA50-2239-4102-BA1A-04104EAC57DF@vigilsec.com> <03b301cd5943$693f2800$3bbd7800$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1278) Cc: cfrg@irtf.org, 'Russ Housley' , jose@ietf.org Subject: Re: [jose] [Cfrg] Question from JOSE working group X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 19:58:27 -0000 More precisely: RSASSA-PKCS1-v1_5 includes the hash algorithm under the signature RSASSA-PSS (introduced in PKCS#1 v2.1) does not include the hash = algorithm Doesn't this seem to argue against the need to protect parameters, since = the security of RSASSA-PSS is tightly related to the RSA problem itself? = =20 On Jul 3, 2012, at 1:43 PM, Jim Schaad wrote: > I would also note that when PKCS#7 was designed, the hash algorithm = was > always protected independent the presence of signed attributes. = Either the > hash algorithm was in the signed attributes or it was in the RSA = signature > block encoding. It was only with the introduction of other = algorithms that > this was no longer true. >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf = Of >> Russ Housley >> Sent: Tuesday, July 03, 2012 8:02 AM >> To: Richard L.Barnes >> Cc: cfrg@irtf.org; jose@ietf.org >> Subject: Re: [Cfrg] Question from JOSE working group >>=20 >> Richard: >>=20 >>> Actually, the inclusion of the hash algorithm under the signature is > optional: >>> " >>> signedAttrs is a collection of attributes that are signed. The >>> field is optional, but it MUST be present if the content type of >>> the EncapsulatedContentInfo value being signed is not id-data. >>> [...] If the field is present, it MUST >>> contain, at a minimum, the following two attributes: >>>=20 >>> ... >>>=20 >>> A message-digest attribute, having as its value the message >>> digest of the content. Section 11.2 defines the = message-digest >>> attribute. >>> " >>>=20 >>> Since "id-data" means "no more ASN.1 structure", for JOSE, the = content >> type is effectively always "id-data". >>=20 >> In practice, there are other attributes that one wants signed, such = as > signing- >> time, so the algorithm identifier gets included. >>=20 >> Russ >>=20 >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg >=20 From ietf@augustcellars.com Tue Jul 3 14:29:31 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444B511E80A3 for ; Tue, 3 Jul 2012 14:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.429 X-Spam-Level: X-Spam-Status: No, score=-3.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1iBG0OHunpG for ; Tue, 3 Jul 2012 14:29:30 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 535D521F86C3 for ; Tue, 3 Jul 2012 14:29:30 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 1EE362CA15; Tue, 3 Jul 2012 14:29:39 -0700 (PDT) From: "Jim Schaad" To: "'Richard L. Barnes'" References: <41F795C1-BD4F-4732-8F1A-62F909E9AA07@bbn.com> <1499CA50-2239-4102-BA1A-04104EAC57DF@vigilsec.com> <03b301cd5943$693f2800$3bbd7800$@augustcellars.com> <7C1A94EE-8633-4FA7-A936-E82FDA6A5FB9@bbn.com> In-Reply-To: <7C1A94EE-8633-4FA7-A936-E82FDA6A5FB9@bbn.com> Date: Tue, 3 Jul 2012 14:28:16 -0700 Message-ID: <03c801cd5962$c3182920$49487b60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDe91NbMO1Nq06fh8taxrYdt/CHCALpPHJBAWJNYUkCIgYT+gJ3iACymK2qUNA= Content-Language: en-us Cc: cfrg@irtf.org, jose@ietf.org Subject: Re: [jose] [Cfrg] Question from JOSE working group X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 21:29:31 -0000 As I said - with the introduction of new signature algorithms led to the fact that the hash algorithm was no longer protected. If you are looking at breaking an RSA signature, you have two ways of going about it. You can either break the hash in some way - or you can factor the RSA keys. The RSA problem is related to the factoring of the keys and has little to do with attacking the hash algorithm. If I could get you to substitute my hash algorithm for the actual hash algorithm used, and they had the same hash value for different messages then the RSA problem is not relevant for the purposes of the attack. The PKCS#1.5 RSA defended against this by placing the hash algorithm identifier in as part of the "to be signed" value. This was both good - the hash algorithm was defended and bad - there were lots of known bits fixed bits in the signature block for lots of signatures. There can be operational/convention steps that deal with this - for example there is a suggested practice that the hash algorithm used in the RSA-PSS signature operation and the one computing the hash of the message should be the same. But there is no current requirement that these steps be followed. (Oops - need to file an erratum on RFC 4056 about what to do for a hash algorithm if signed attributes are not used.) The reason for writing RFC 6211 was precisely the issue of protecting the hash algorithm used in the signature operation in those cases where it was not completely obvious (i.e DSA which only permitted one signature algorithm) or it was not included in the cryptographic block (RSA v1.5). Jim > -----Original Message----- > From: Richard L. Barnes [mailto:rbarnes@bbn.com] > Sent: Tuesday, July 03, 2012 12:59 PM > To: Jim Schaad > Cc: 'Russ Housley'; cfrg@irtf.org; jose@ietf.org > Subject: Re: [Cfrg] Question from JOSE working group > > More precisely: > RSASSA-PKCS1-v1_5 includes the hash algorithm under the signature > RSASSA-PSS (introduced in PKCS#1 v2.1) does not include the hash algorithm > > Doesn't this seem to argue against the need to protect parameters, since the > security of RSASSA-PSS is tightly related to the RSA problem itself? > > > On Jul 3, 2012, at 1:43 PM, Jim Schaad wrote: > > > I would also note that when PKCS#7 was designed, the hash algorithm > > was always protected independent the presence of signed attributes. > > Either the hash algorithm was in the signed attributes or it was in the RSA > signature > > block encoding. It was only with the introduction of other algorithms that > > this was no longer true. > > > > Jim > > > > > >> -----Original Message----- > >> From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf > >> Of Russ Housley > >> Sent: Tuesday, July 03, 2012 8:02 AM > >> To: Richard L.Barnes > >> Cc: cfrg@irtf.org; jose@ietf.org > >> Subject: Re: [Cfrg] Question from JOSE working group > >> > >> Richard: > >> > >>> Actually, the inclusion of the hash algorithm under the signature is > > optional: > >>> " > >>> signedAttrs is a collection of attributes that are signed. The > >>> field is optional, but it MUST be present if the content type of > >>> the EncapsulatedContentInfo value being signed is not id-data. > >>> [...] If the field is present, it MUST > >>> contain, at a minimum, the following two attributes: > >>> > >>> ... > >>> > >>> A message-digest attribute, having as its value the message > >>> digest of the content. Section 11.2 defines the message-digest > >>> attribute. > >>> " > >>> > >>> Since "id-data" means "no more ASN.1 structure", for JOSE, the > >>> content > >> type is effectively always "id-data". > >> > >> In practice, there are other attributes that one wants signed, such > >> as > > signing- > >> time, so the algorithm identifier gets included. > >> > >> Russ > >> > >> _______________________________________________ > >> Cfrg mailing list > >> Cfrg@irtf.org > >> http://www.irtf.org/mailman/listinfo/cfrg > > From internet-drafts@ietf.org Fri Jul 6 10:04:39 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B17E21F8757; Fri, 6 Jul 2012 10:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elyjPohSJeg0; Fri, 6 Jul 2012 10:04:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C2421F873C; Fri, 6 Jul 2012 10:04:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p2 Message-ID: <20120706170421.22941.55393.idtracker@ietfa.amsl.com> Date: Fri, 06 Jul 2012 10:04:21 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-signature-03.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 17:04:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Signature (JWS) Author(s) : Michael B. Jones John Bradley Nat Sakimura Filename : draft-ietf-jose-json-web-signature-03.txt Pages : 39 Date : 2012-07-06 Abstract: JSON Web Signature (JWS) is a means of representing content secured with digital signatures or Message Authentication Codes (MACs) using JavaScript Object Notation (JSON) data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-signature-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Jul 6 10:06:52 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2EE21F876E; Fri, 6 Jul 2012 10:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmH79XW-pNEu; Fri, 6 Jul 2012 10:06:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDA221F8786; Fri, 6 Jul 2012 10:06:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p2 Message-ID: <20120706170651.27182.85006.idtracker@ietfa.amsl.com> Date: Fri, 06 Jul 2012 10:06:51 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-03.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 17:06:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Encryption (JWE) Author(s) : Michael B. Jones Eric Rescorla Joe Hildebrand Filename : draft-ietf-jose-json-web-encryption-03.txt Pages : 44 Date : 2012-07-06 Abstract: JSON Web Encryption (JWE) is a means of representing encrypted content using JavaScript Object Notation (JSON) data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. Related digital signature and MAC capabilities are described in the separate JSON Web Signature (JWS) specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Jul 6 10:09:03 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F3821F8620; Fri, 6 Jul 2012 10:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RP8-liORyehk; Fri, 6 Jul 2012 10:09:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7FF21F864E; Fri, 6 Jul 2012 10:09:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p2 Message-ID: <20120706170902.30018.16189.idtracker@ietfa.amsl.com> Date: Fri, 06 Jul 2012 10:09:02 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-key-03.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 17:09:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Key (JWK) Author(s) : Michael B. Jones Filename : draft-ietf-jose-json-web-key-03.txt Pages : 11 Date : 2012-07-06 Abstract: A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a public key. This specification also defines a JSON Web Key Set (JWK Set) JSON data structure for representing a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-key-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-key-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Jul 6 10:11:11 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B177221F87BE; Fri, 6 Jul 2012 10:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJEUwqAQ4zVw; Fri, 6 Jul 2012 10:11:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0C521F8736; Fri, 6 Jul 2012 10:11:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p2 Message-ID: <20120706171111.32654.15344.idtracker@ietfa.amsl.com> Date: Fri, 06 Jul 2012 10:11:11 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-03.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 17:11:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Algorithms (JWA) Author(s) : Michael B. Jones Filename : draft-ietf-jose-json-web-algorithms-03.txt Pages : 39 Date : 2012-07-06 Abstract: The JSON Web Algorithms (JWA) specification enumerates cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-algorithms-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Michael.Jones@microsoft.com Fri Jul 6 10:26:32 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417CB21F8656 for ; Fri, 6 Jul 2012 10:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.774 X-Spam-Level: X-Spam-Status: No, score=-3.774 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrT0MgXZLY0q for ; Fri, 6 Jul 2012 10:26:26 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2238D21F8658 for ; Fri, 6 Jul 2012 10:26:25 -0700 (PDT) Received: from mail87-db3-R.bigfish.com (10.3.81.246) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Jul 2012 17:24:33 +0000 Received: from mail87-db3 (localhost [127.0.0.1]) by mail87-db3-R.bigfish.com (Postfix) with ESMTP id A8C63260595 for ; Fri, 6 Jul 2012 17:24:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VS-20(zzc85fhzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail87-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail87-db3 (localhost.localdomain [127.0.0.1]) by mail87-db3 (MessageSwitch) id 1341595470911932_3619; Fri, 6 Jul 2012 17:24:30 +0000 (UTC) Received: from DB3EHSMHS011.bigfish.com (unknown [10.3.81.239]) by mail87-db3.bigfish.com (Postfix) with ESMTP id D2BC52A0019 for ; Fri, 6 Jul 2012 17:24:30 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS011.bigfish.com (10.3.87.111) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Jul 2012 17:24:30 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0309.003; Fri, 6 Jul 2012 17:26:21 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Updated versions of JOSE and JWT specifications Thread-Index: Ac1bnHVXNgbMo6FzRA29BOMAiVSszA== Date: Fri, 6 Jul 2012 17:26:20 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366579EA5@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366579EA5TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [jose] Updated versions of JOSE and JWT specifications X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 17:26:32 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366579EA5TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New versions of the JSON WEB {Signature,Encryption,Key,Algorithms,Token} (J= WS, JWE, JWK, JWA, JWT) specifications have been released. These versions = incorporate numerous suggestions from working group members and developers = that clarify the intent of the specifications and make them easier to read = and implement. In particular, the JWE spec now includes encryption and key= derivation examples for a number of algorithms that have been verified in = multiple independent implementations. I've worked to close out all the former "TBD" items in the specs, bringing = them up to an editorially complete state, in preparation for working group = last call. As with previous releases, see the "Open Issues" sections for a= small number of discussion points that I believe merit working group atten= tion. I also applied the changes made to the JOSE specs to the related individual= submission JWS JSON Serialization and JWE JSON Serialization specs, which = enable multiple recipients. The working group specifications are available at: * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-03 * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-03 * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-03 * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-03 * http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-01 The individual submission specifications are available at: * http://tools.ietf.org/html/draft-jones-json-web-signature-json-ser= ialization-02 * http://tools.ietf.org/html/draft-jones-json-web-encryption-json-se= rialization-02 The document history entries (also in the specifications) are as follows: http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-03 * Added the cty (content type) header parameter for declaring type info= rmation about the secured content, as opposed to the typ (type) header para= meter, which declares type information about this object. * Added "Collision Resistant Namespace" to the terminology section. * Reference ITU.X690.1994 for DER encoding. * Added an example JWS using ECDSA P-521 SHA-512. This has particular i= llustrative value because of the use of the 521 bit integers in the key and= signature values. This is also an example in which the payload is not a ba= se64url encoded JSON object. * Added an example x5c value. * No longer say "the UTF-8 representation of the JWS Secured Input (whi= ch is the same as the ASCII representation)". Just call it "the ASCII repre= sentation of the JWS Secured Input". * Added Registration Template sections for defined registries. * Added Registry Contents sections to populate registry values. * Changed name of the JSON Web Signature and Encryption "typ" Values re= gistry to be the JSON Web Signature and Encryption Type Values registry, si= nce it is used for more than just values of the typ parameter. * Moved registries JSON Web Signature and Encryption Header Parameters = and JSON Web Signature and Encryption Type Values to the JWS specification. * Numerous editorial improvements. http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-03 * Added the kdf (key derivation function) header parameter to provide c= rypto agility for key derivation. The default KDF remains the Concat KDF wi= th the SHA-256 digest function. * Reordered encryption steps so that the Encoded JWE Header is always c= reated before it is needed as an input to the AEAD "additional authenticate= d data" parameter. * Added the cty (content type) header parameter for declaring type info= rmation about the secured content, as opposed to the typ (type) header para= meter, which declares type information about this object. * Moved description of how to determine whether a header is for a JWS o= r a JWE from the JWT spec to the JWE spec. * Added complete encryption examples for both AEAD and non-AEAD algorit= hms. * Added complete key derivation examples. * Added "Collision Resistant Namespace" to the terminology section. * Reference ITU.X690.1994 for DER encoding. * Added Registry Contents sections to populate registry values. * Numerous editorial improvements. http://tools.ietf.org/html/draft-ietf-jose-json-web-key-03 * Clarified that kid values need not be unique within a JWK Set. * Moved JSON Web Key Parameters registry to the JWK specification. * Added "Collision Resistant Namespace" to the terminology section. * Changed registration requirements from RFC Required to Specification = Required with Expert Review. * Added Registration Template sections for defined registries. * Added Registry Contents sections to populate registry values. * Numerous editorial improvements. http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-03 * Always use a 128 bit "authentication tag" size for AES GCM, regardles= s of the key size. * Specified that use of a 128 bit IV is REQUIRED with AES CBC. It was p= reviously RECOMMENDED. * Removed key size language for ECDSA algorithms, since the key size is= implied by the algorithm being used. * Stated that the int key size must be the same as the hash output size= (and not larger, as was previously allowed) so that its size is defined fo= r key generation purposes. * Added the kdf (key derivation function) header parameter to provide c= rypto agility for key derivation. The default KDF remains the Concat KDF wi= th the SHA-256 digest function. * Clarified that the mod and exp values are unsigned. * Added Implementation Requirements columns to algorithm tables and Imp= lementation Requirements entries to algorithm registries. * Changed AES Key Wrap to RECOMMENDED. * Moved registries JSON Web Signature and Encryption Header Parameters = and JSON Web Signature and Encryption Type Values to the JWS specification. * Moved JSON Web Key Parameters registry to the JWK specification. * Changed registration requirements from RFC Required to Specification = Required with Expert Review. * Added Registration Template sections for defined registries. * Added Registry Contents sections to populate registry values. * No longer say "the UTF-8 representation of the JWS Secured Input (whi= ch is the same as the ASCII representation)". Just call it "the ASCII repre= sentation of the JWS Secured Input". * Added "Collision Resistant Namespace" to the terminology section. * Numerous editorial improvements. http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-01 * Added the cty (content type) header parameter for declaring type info= rmation about the secured content, as opposed to the typ (type) header para= meter, which declares type information about this object. This significantl= y simplified nested JWTs. * Moved description of how to determine whether a header is for a JWS o= r a JWE from the JWT spec to the JWE spec. * Changed registration requirements from RFC Required to Specification = Required with Expert Review. * Added Registration Template sections for defined registries. * Added Registry Contents sections to populate registry values. * Added "Collision Resistant Namespace" to the terminology section. * Numerous editorial improvements. http://tools.ietf.org/html/draft-jones-json-web-signature-json-serializatio= n-02 * Tracked editorial changes made to the JWS spec. http://tools.ietf.org/html/draft-jones-json-web-encryption-json-serializati= on-02 * Updated examples to track updated algorithm properties in the JWA spe= c. * Tracked editorial changes made to the JWE spec. Special thanks to Axel Nennker, Emmanuel Raviart, Brian Campbell, and Edmun= d Jay for validating the JWE examples! -- Mike --_000_4E1F6AAD24975D4BA5B168042967394366579EA5TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

New versions of the JSON WEB {Signature,Encryption,K= ey,Algorithms,Token} (JWS, JWE, JWK, JWA, JWT) specifications have been rel= eased.  These versions incorporate numerous suggestions from working g= roup members and developers that clarify the intent of the specifications and make them easier to read and implemen= t.  In particular, the JWE spec now includes encryption and key deriva= tion examples for a number of algorithms that have been verified in multipl= e independent implementations.

 

I’ve worked to close out all the former “= ;TBD” items in the specs, bringing them up to an editorially complete= state, in preparation for working group last call.  As with previous = releases, see the “Open Issues” sections for a small number of discussion points that I believe merit working group attention.

 

I also applied the changes made to the JOSE specs to= the related individual submission JWS JSON Serialization and JWE JSON Seri= alization specs, which enable multiple recipients.

 

The working group specifications are available at:

·        http://tools.ietf.org/html/draft-ietf-jose= -json-web-signature-03

·        http://tools.ietf.org/html/draft-ietf-jos= e-json-web-encryption-03

·        http://tools.ietf.org/html/draft-ietf-jose-json-= web-key-03

·        http://tools.ietf.org/html/draft-ietf-jos= e-json-web-algorithms-03

·        http://tools.ietf.org/html/draft-ietf-oauth-j= son-web-token-01

 

The individual submission specifications are availab= le at:

·        http://tools.ietf.org/html/= draft-jones-json-web-signature-json-serialization-02

·        http://tools.ietf.org/html= /draft-jones-json-web-encryption-json-serialization-02

 

The document history entries (also in the specificat= ions) are as follows:

 

http://tools.ietf.org/html/draft-ietf-jose-json-we= b-signature-03

  • Added the cty (content type) header parameter for declaring = type information about the secured content, as opposed to the typ (type) header parameter, which declares type i= nformation about this object.
  • Added "Collision Resistant Namespace" t= o the terminology section.
  • Reference ITU.X690.1994 for DER encoding.
  • Added an example JWS using ECDSA P-521 SHA-512. T= his has particular illustrative value because of the use of the 521 bit int= egers in the key and signature values. This is also an example in which the payload= is not a base64url encoded JSON object.
  • Added an example x5c value.
  • No longer say "the UTF-8 representation of t= he JWS Secured Input (which is the same as the ASCII representation)".= Just call it "the ASCII representation of the JWS Secured Input".
  • Added Registration Template sections for defined registries.
  • Added Registry Contents sections to populate regi= stry values.
  • Changed name of the JSON Web Signature and Encryp= tion "typ" Values registry to be the JSON Web Signature and Encry= ption Type Values registry, since it is used for more than just values of the typ<= /span> parameter.
  • Moved registries JSON Web Signature and Encryptio= n Header Parameters and JSON Web Signature and Encryption Type Values to th= e JWS specification.
  • Numerous editorial improvements.

 

http://tools.ietf.org/html/draft-ietf-jose-json-w= eb-encryption-03

  • Added the kdf (key derivation function) header parameter to = provide crypto agility for key derivation. The default KDF remains the Concat KDF with the SHA-256 digest function.
  • Re= ordered encryption steps so that the Encoded JWE Header is always created b= efore it is needed as an input to the AEAD "additional authenticated data" parameter.
  • Added the cty (content type) header parameter for declaring = type information about the secured content, as opposed to the typ (type) header parameter, which declares type i= nformation about this object.
  • Moved description of how to determine whether a h= eader is for a JWS or a JWE from the JWT spec to the JWE spec.
  • Added complete encryption examples for both AEAD = and non-AEAD algorithms.
  • Added complete key derivation examples.
  • Added "Collision Resistant Namespace" t= o the terminology section.
  • Reference ITU.X690.1994 for DER encoding.
  • Added Registry Contents sections to populate regi= stry values.
  • Numerous editorial improvements.

 

http://tools.ietf.org/html/draft-ietf-jose-json-web-key-= 03

  • Clarified that kid values need not be unique within a JWK Set.
  • Moved JSON Web Key Parameters registry to the JWK= specification.
  • Added "Collision Resistant Namespace" t= o the terminology section.
  • Changed registration requirements from RFC Requir= ed to Specification Required with Expert Review.
  • Added Registration Template sections for defined = registries.
  • Added Registry Contents sections to populate regi= stry values.
  • Numerous editorial improvements.

 

http://tools.ietf.org/html/draft-ietf-jose-json-w= eb-algorithms-03

  • Always use a 128 bit "authentication tag" size for AES GCM, re= gardless of the key size.
  • Specified that use of a 128 bit IV is REQUIRED wi= th AES CBC. It was previously RECOMMENDED.
  • Removed key size language for ECDSA algorithms, s= ince the key size is implied by the algorithm being used.
  • Stated that the int key size must be the same as the hash output s= ize (and not larger, as was previously allowed) so that its size is defined for key generation purposes.
  • Added the kdf (key derivation function) header parameter to = provide crypto agility for key derivation. The default KDF remains the Concat KDF with the SHA-256 digest function.
  • Cl= arified that the mod and exp values are unsigned.
  • Added Implementation Requirements columns to algo= rithm tables and Implementation Requirements entries to algorithm registrie= s.
  • Changed AES Key Wrap to RECOMMENDED.
  • Moved registries JSON Web Signature and Encryptio= n Header Parameters and JSON Web Signature and Encryption Type Values to th= e JWS specification.
  • Moved JSON Web Key Parameters registry to the JWK= specification.
  • Changed registration requirements from RFC Requir= ed to Specification Required with Expert Review.
  • Added Registration Template sections for defined = registries.
  • Added Registry Contents sections to populate regi= stry values.
  • No longer say "the UTF-8 representation of t= he JWS Secured Input (which is the same as the ASCII representation)".= Just call it "the ASCII representation of the JWS Secured Input".
  • Added "Collision Resistant Namespace" to the terminology sec= tion.
  • Numerous editorial improvements.

 

http://tools.ietf.org/html/draft-ietf-oauth-json-web-= token-01

  • Added the cty (content type) header parameter for declaring = type information about the secured content, as opposed to the typ (type) header parameter, which declares type i= nformation about this object. This significantly simplified nested JWTs.
  • Moved description of how to determine whether a h= eader is for a JWS or a JWE from the JWT spec to the JWE spec.
  • Changed registration requirements from RFC Requir= ed to Specification Required with Expert Review.
  • Added Registration Template sections for defined = registries.
  • Added Registry Contents sections to populate regi= stry values.
  • Added "Collision Resistant Namespace" t= o the terminology section.
  • Numerous editorial improvements.

 

http://tools.ietf.org/html/draft-jo= nes-json-web-signature-json-serialization-02

  • Tracked editorial changes made to the JWS spec.

    •  

    http://tools.ietf.org/html/draft-j= ones-json-web-encryption-json-serialization-02

    • Updated examples to track updated algorithm properties in the JWA spec.
    • Tracked editorial changes made to the JWE spec.

     

    Special thanks to Axel Nennker, Emmanuel Raviart, Br= ian Campbell, and Edmund Jay for validating the JWE examples!

     

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

     

--_000_4E1F6AAD24975D4BA5B168042967394366579EA5TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Fri Jul 6 10:31:12 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C06121F865A for ; Fri, 6 Jul 2012 10:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.768 X-Spam-Level: X-Spam-Status: No, score=-3.768 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4u+WIiGS3Xdg for ; Fri, 6 Jul 2012 10:31:08 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id DDC4A21F85CF for ; Fri, 6 Jul 2012 10:31:07 -0700 (PDT) Received: from mail262-ch1-R.bigfish.com (10.43.68.245) by CH1EHSOBE007.bigfish.com (10.43.70.57) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Jul 2012 17:29:16 +0000 Received: from mail262-ch1 (localhost [127.0.0.1]) by mail262-ch1-R.bigfish.com (Postfix) with ESMTP id 5274E1C000AD; Fri, 6 Jul 2012 17:29:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz9371Ic85fh148cI542M1418Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail262-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail262-ch1 (localhost.localdomain [127.0.0.1]) by mail262-ch1 (MessageSwitch) id 1341595753310385_29334; Fri, 6 Jul 2012 17:29:13 +0000 (UTC) Received: from CH1EHSMHS011.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.235]) by mail262-ch1.bigfish.com (Postfix) with ESMTP id 4A1DF1A80048; Fri, 6 Jul 2012 17:29:13 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS011.bigfish.com (10.43.70.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Jul 2012 17:29:12 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0298.005; Fri, 6 Jul 2012 17:31:19 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: Comments on draft-ietf-jose-json-web-key-02 Thread-Index: Ac1bnR9r6ocLDUY1SjuKsbPs53w7OA== Date: Fri, 6 Jul 2012 17:31:18 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366579F15@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366579F15TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Comments on draft-ietf-jose-json-web-key-02 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 17:31:12 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366579F15TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for taking the time to provide the detailed feedback. Responses inl= ine... -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Saturday, May 19, 2012 3:34 PM To: Mike Jones Cc: jose@ietf.org Subject: Comments on draft-ietf-jose-json-web-key-02 My apologies for introducing you to the term algorithm families. We don't = use it in the same way and thus I think that you should generally remove it= from the text. To me it is a very wide term and somewhat nebulous. Thus = I think of all of the DH algorithms as being in a family - but that family = could also include the ECDH algorithm as well as DSA depending on how one i= s using it. Thus for me an algorithm family is not restricted to a specifi= c instance (or small set of instances) such a DH & DSA but could be as larg= e as all key agreement algorithms. As such it does not really match how you are using it in much of the text. Left in for the current draft for lack of a better term. I did remove as m= any uses of the term as possible. Slightly more detailed: You can define an RSA key You can define an RSA-OAEP key The second one has all of the fields of the first, however it may have addi= tional fields defined that deal specifically with RSA-OAEP. The difference= is going to be a question of restriction of usage of the key to a single a= lgorithm vs allowing for all RSA algorithms. Parameters could be defined in the JWA spec to specify parameters enabling = those possible restrictions if the working group deems it useful/necessary.= The JWK spec already makes it clear that algorithm-specific parameters ma= y be required, so this wouldn't change the model. Here are some more comments Abstract 1. I am not a fan of the word enumerated in the last sentence. This word = implies to me that the list is not expandable. I would recommend something= along the lines of "An initial set of ... can be found in ..." Done here, plus in JWE, JWS, JWA, JWE-JS, and JWS-JS 2. JSON needs to be expanded on first use Done here, plus in JWE, JWS, JWA, JWE-JS, JWS-JS, JWT, OAuth JWT Bearer, an= d SWD Section 1 1. JSON needs to be expanded on first use. (Doing it on second use should= be fine and clearer) Done 2. See enumerated comment above Done 3. Don't use non-goals. The wording "The goals of this document do not in= clude ..." (Minor) Done 4. It is fine to tell me what documents they are used in. I don't know th= at we need to say what the fields are. (Minor) Done Section 2 1. The phrase "For the purpose of this document" should be removed unless = this term is used in other ways elsewhere. Not changed, because in some other contexts, the same term is used to refer= to the non URL safe encoding. Section 4 1. In para #2 - the use of "algorithm family" is incorrect. They members = are going to be required for the specific key being represented not to the = family - consider the case of RSA and RSA-OAEP - these are both in the same= family, but the fields required are different. Reworded to not use the term "algorithm family" 2. Do you believe that all of the algorithm members are defined in the JWA document - or only for some algorithms. Text should probably say they are defined for the algorithms defined for the algorithms in JWA. Done 3. I don't believe that para #3 is enforceable by parsers as they have bee= n presented to me. Please prove me wrong. Section 2.2 of http://tools.ietf.org/html/rfc4627 says "The names within an= object SHOULD be unique." So this should be enforced by conforming parser= s. I'd be interested in data saying that parsers exist that are non-confor= ming to this RFC 4627 "SHOULD". If so, we should add appropriate warnings = to the Security Considerations section. 4. Let's look at the sentence "If present, they MUST be understood by im= plementations using them." I believe that this is an incorrect assertion. (Not to mention that it is totally uncheckable.) Consider the following situation: Implementation A creates a JWK and files it with Implementation B. A does = not understand the "exist-date" property. Implementation B adds the "exist-date" property and puts it at a URL. Implementation C pulls the JWK from the URL, understand the "exist-date" property. According to the MUST, the JWK cannot be used as it is not understood by al= l of the implementations. The only entity that you can make the requirement on is the consumer. One = assumes that the "provider" would/might understand the field or it would no= t be there but it could have been added in transit and thus that is not the= case. I believe that for your example, the text is correct as written, since in c= ontext, "them" refers to the additional members, not the JWK as a whole. A= t no point in your example did an implementation use a JWK with an addition= al member that it did not understand. I understand that the assertion may not be enforceable apart from conforman= ce suites that check what implementations do when given new parameters, and= I understand that in the general case, programmatic enforcement would be t= he equivalent of solving the halting problem. That's not an argument, howe= ver, that in security contexts, that having this requirement isn't the righ= t thing to do. 5. I find the last sentence of para #4 to be unreadable. I would start by= breaking it into two sentences and potentially move the first one into the= JWA document (that about parameters for keys). Simplified Section 4.1 1. Do you want to point to the JWA document or to the registry for the set = of defined algorithms? Clarified that some names are defined in JWA whereas all names not containi= ng a collision resistant namespace should be registered. 2. In para #1 I would remove the sentence starting "Specific additional..." as this is not part of the definition of the "alg" parameter and is covered= in section 4.0 Done 3. The last two sentences in para #1 can be combined together. This is just a personal stylistic thing I suppose, but I prefer two short d= eclarative sentences to a conjunction of the two. Section 4.2 1. Presentation suggestion - if you use a bulleted list for the values it = will be easier to see what the list of defined values is. Done 2. See point #3 in section 4.1 Ditto Section 4.3 1. Is there a requirement that the kid be unique in a JWK Set? I think th= at the answer should be called out in text either way. Good point. Added text saying that it need not be unique, and providing an= example providing rationale for that choice. 2. Is the string case sensitive? It is now. :-) 3. Move the sentence "When used..." to a new paragraph. (suggestion) Done Section 6.1 1. Please make things easy for IANA - create a table with the fields across= the top and the values down the table. This will allow them to do their j= ob without having to go through the entire document and for us to be able t= o easily validate that they got it correct. Done here, plus in JWA and JWT Section 6.2 1. Please put in a registration section for the items you are registering i= n Section 4 in the JWK table. You can refer to JWA for creation of the tab= le. Done here, plus in JWS, JWE, JWA, and JWT Appendix A 1. I am not sure why this appendix is in this document. To give credit to the inventors of the precursor spec that resulted in the = JWK spec. I've added their names to make this intent clearer. --_000_4E1F6AAD24975D4BA5B168042967394366579F15TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for taking t= he time to provide the detailed feedback.  Responses inline…

 

-----Original Message-----
From: Jim Schaad [mailto= :ietf@augustcellars.com]
Sent: Saturday, May 19, 2012 3:34 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: Comments on draft-ietf-jose-json-web-key-02

 

<no hat>

 

My apologies for introducing you to the term algo= rithm families.  We don't use it in the same way and thus I think that= you should generally remove it from the text.  To me it is a very wid= e term and somewhat nebulous.  Thus I think of all of the DH algorithms as being in a family - but that family could a= lso include the ECDH algorithm as well as DSA depending on how one is using= it.  Thus for me an algorithm family is not restricted to a specific = instance (or small set of instances) such a DH & DSA but could be as large

as all key agreement algorithms.   As s= uch it does not really match how you

are using it in much of the text.

 

Left in for the cur= rent draft for lack of a better term.  I did remove as many uses of th= e term as possible.

 

Slightly more detailed:

 

You can define an RSA key

You can define an RSA-OAEP key

 

The second one has all of the fields of the first= , however it may have additional fields defined that deal specifically with= RSA-OAEP.  The difference is going to be a question of restriction of= usage of the key to a single algorithm vs allowing for all RSA algorithms.

 

Parameters could be= defined in the JWA spec to specify parameters enabling those possible rest= rictions if the working group deems it useful/necessary.  The JWK spec= already makes it clear that algorithm-specific parameters may be required, so this wouldn’t change the model.<= /o:p>

 

Here are some more comments

 

Abstract

 

1.  I am not a fan of the word enumerated in= the last sentence.  This word implies to me that the list is not expa= ndable.  I would recommend something along the lines of "An initi= al set of ... can be found in ..."

 

Done here, plus in = JWE, JWS, JWA, JWE-JS, and JWS-JS

 

2.  JSON needs to be expanded on first use

 

Done here, plus in = JWE, JWS, JWA, JWE-JS, JWS-JS, JWT, OAuth JWT Bearer, and SWD

 

Section 1

 

1.  JSON needs to be expanded on first use.&= nbsp; (Doing it on second use should be fine and clearer)

 

Done

 

2.  See enumerated comment above<= /p>

 

Done

 

3.  Don't use non-goals.  The wording &= quot;The goals of this document do not include ..."  (Minor)=

 

Done

 

4.  It is fine to tell me what documents the= y are used in.  I don't know that we need to say what the fields are.&= nbsp; (Minor)

 

Done

 

Section 2

 

1.  The phrase "For the purpose of this= document" should be removed unless this term is used in other ways el= sewhere.

 

Not changed, becaus= e in some other contexts, the same term is used to refer to the non URL saf= e encoding.

 

Section 4

 

1.  In para #2 - the use of "algorithm = family" is incorrect.  They members are going to be required for = the specific key being represented not to the family - consider the case of= RSA and RSA-OAEP - these are both in the same family, but the fields required are different.

 

Reworded to not use= the term “algorithm family”

 

2.  Do you believe that all of the algorithm= members are defined in the JWA

document - or only for some algorithms. &nbs= p; Text should probably say they are

defined for the algorithms defined for the algori= thms in JWA.

 

Done

 

3.  I don't believe that para #3 is enforcea= ble by parsers as they have been presented to me.  Please prove me wro= ng.

 

Section 2.2 of http://tools.ietf.org/htm= l/rfc4627 says “The names within an object SHOULD be unique.”&nb= sp; So this should be enforced by conforming parsers.  I’d be in= terested in data saying that parsers exist that are non-conforming to this = RFC 4627 “SHOULD”.  If so, we should add appropriate warni= ngs to the Security Considerations section.

 

4.  Let's look at the sentence  "I= f present, they MUST  be understood by implementations using them.&quo= t;  I believe that this is an incorrect assertion.

(Not to mention that it is totally uncheckable.)&= nbsp; Consider the following

situation:

 

Implementation A creates a JWK and files it with = Implementation B.  A does not understand the "exist-date" pr= operty.

Implementation B adds the "exist-date" = property and puts it at a URL.

Implementation C pulls the JWK from the URL, unde= rstand the "exist-date"

property.

According to the MUST, the JWK cannot be used as = it is not understood by all of the implementations.

 

The only entity that you can make the requirement= on is the consumer.  One assumes that the "provider" would/= might understand the field or it would not be there but it could have been = added in transit and thus that is not the case.

 

I believe that for = your example, the text is correct as written, since in context, “them= ” refers to the additional members, not the JWK as a whole.  At = no point in your example did an implementation use a JWK with an additional member that it did not understand.

 

I understand that t= he assertion may not be enforceable apart from conformance suites that chec= k what implementations do when given new parameters, and I understand that = in the general case, programmatic enforcement would be the equivalent of solving the halting problem.  That’s= not an argument, however, that in security contexts, that having this requ= irement isn’t the right thing to do.

 

5.  I find the last sentence of para #4 to b= e unreadable.  I would start by breaking it into two sentences and pot= entially move the first one into the JWA document (that about parameters fo= r keys).

 

Simplified

 

Section 4.1

 

1. Do you want to point to the JWA document or to= the registry for the set of defined algorithms?

 

Clarified that some= names are defined in JWA whereas all names not containing a collision resi= stant namespace should be registered.

 

2. In para #1 I would remove the sentence startin= g "Specific additional..."

as this is not part of the definition of the &quo= t;alg" parameter and is covered in section 4.0

 

Done

 

3.  The last two sentences in para #1 can be= combined together.

 

This is just a pers= onal stylistic thing I suppose, but I prefer two short declarative sentence= s to a conjunction of the two.

 

Section 4.2

 

1.  Presentation suggestion - if you use a b= ulleted list for the values it will be easier to see what the list of defin= ed values is.

 

Done

 

2.  See point #3 in section 4.1

 

Ditto

 

Section 4.3

 

1.  Is there a requirement that the kid be u= nique in a JWK Set?  I think that the answer should be called out in t= ext either way.

 

Good point.  A= dded text saying that it need not be unique, and providing an example provi= ding rationale for that choice.

 

2.  Is the string case sensitive?=

 

It is now. :-)=

 

3.  Move the sentence "When used...&quo= t; to a new paragraph.  (suggestion)

 

Done

 

Section 6.1

 

1. Please make things easy for IANA - create a ta= ble with the fields across the top and the values down the table.  Thi= s will allow them to do their job without having to go through the entire d= ocument and for us to be able to easily validate that they got it correct.

 

Done here, plus in = JWA and JWT

 

Section 6.2

 

1. Please put in a registration section for the i= tems you are registering in Section 4 in the JWK table.  You can refer= to JWA for creation of the table.

 

Done here, plus in = JWS, JWE, JWA, and JWT

 

Appendix A

 

1.  I am not sure why this appendix is in th= is document.

 

To give credit to t= he inventors of the precursor spec that resulted in the JWK spec.  I&#= 8217;ve added their names to make this intent clearer.

 

--_000_4E1F6AAD24975D4BA5B168042967394366579F15TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Fri Jul 6 10:32:30 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904B821F865A for ; Fri, 6 Jul 2012 10:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.765 X-Spam-Level: X-Spam-Status: No, score=-3.765 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaMicKSBucdS for ; Fri, 6 Jul 2012 10:32:28 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 2804D21F85CF for ; Fri, 6 Jul 2012 10:32:28 -0700 (PDT) Received: from mail98-am1-R.bigfish.com (10.3.201.236) by AM1EHSOBE009.bigfish.com (10.3.204.29) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Jul 2012 17:30:36 +0000 Received: from mail98-am1 (localhost [127.0.0.1]) by mail98-am1-R.bigfish.com (Postfix) with ESMTP id 02A82C02F2; Fri, 6 Jul 2012 17:30:36 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VS-27(zz9371Ic85fh148cI542Mzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail98-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail98-am1 (localhost.localdomain [127.0.0.1]) by mail98-am1 (MessageSwitch) id 1341595833690779_25422; Fri, 6 Jul 2012 17:30:33 +0000 (UTC) Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.241]) by mail98-am1.bigfish.com (Postfix) with ESMTP id A1B91380047; Fri, 6 Jul 2012 17:30:33 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Jul 2012 17:30:32 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0309.003; Fri, 6 Jul 2012 17:32:36 +0000 From: Mike Jones To: Sean Turner Thread-Topic: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt Thread-Index: Ac1bnUyad8s5BDFlSJ21HdU0De1eaQ== Date: Fri, 6 Jul 2012 17:32:35 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366579F40@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366579F40TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 17:32:30 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366579F40TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for taking the time to provide the detailed feedback. Responses inl= ine... -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Sean Turn= er Sent: Monday, May 28, 2012 10:36 AM Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt Here's some comments (again I'll try not to duplicate Jim's): 1) s2 & Requirements Language: The RFC editor is going to move the Requirem= ents Language section later on so you might as well save them the trouble a= nd just make it part of s2. Done here, plus in JWE, JWS, JWA, JWT, JWE-JS, JWS-JS, and SWD 2) s3: This is probably a style thing, but I think it's probably better to = talk about the structure first and then provide an example. It's just goin= g to make everybody ask you to define/explain x in that section. I tried to do this and couldn't find a better location. The spec is so sho= rt, that you're never more than a page from the example to the normative te= xt anyway. :-) Besides, given that all the meaty parts (the actual algorit= hm specifications) have moved to the JWA spec, the descriptions would proba= bly be pretty abstract without an example to root them in. Left as is, at = least for now. 3) s4: Totally agree with Jim's comment #4 on this section. Applies to s5 as well. Addressed, per Jim's comments 4) s4: Same concerns as for algorithms about the collision resistant namesp= ace and how the registry is set up. Addressed, per Jim's comments 5) s4.2: Assume "both" should be defined here. At least for Elliptic Curve keys, I believe that there's a potential vulner= ability with using the same key for both signing and encryption. So I'm re= luctant to define "both". The simplest way to indicate both may be to omit= the parameter. This could also be represented by repeating the key with "= use":"sig" and "use":"enc" in the key set. What do others in the working g= roup think about these possibilities? 6) s7: If the kid is not supposed to be generated in a way to make it uniqu= e it's worth pointing this out in s7. Done spt _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B168042967394366579F40TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for taking t= he time to provide the detailed feedback.  Responses inline…

 

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Sean Turner
Sent: Monday, May 28, 2012 10:36 AM
Cc: jose@ietf.org
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt

 

Here's some comments (again I'll try not to dupli= cate Jim's):

 

1) s2 & Requirements Language: The RFC editor= is going to move the Requirements Language section later on so you might a= s well save them the trouble and just make it part of s2.

 

Done here, plus in = JWE, JWS, JWA, JWT, JWE-JS, JWS-JS, and SWD

 

2) s3: This is probably a style thing, but I thin= k it's probably better to talk about the structure first and then provide a= n example.  It's just going to make everybody ask you to define/explai= n x in that section.

 

I tried to do this = and couldn’t find a better location.  The spec is so short, that= you’re never more than a page from the example to the normative text= anyway. :-)  Besides, given that all the meaty parts (the actual algorithm specifications) have moved to the JWA spec, the desc= riptions would probably be pretty abstract without an example to root them = in.  Left as is, at least for now.

 

3) s4: Totally agree with Jim's comment #4 on thi= s section.  Applies to

s5 as well.

 

Addressed, per Jim&= #8217;s comments

 

4) s4: Same concerns as for algorithms about the = collision resistant namespace and how the registry is set up.

 

Addressed, per Jim&= #8217;s comments

 

5) s4.2: Assume "both" should be define= d here.

 

At least for Ellipt= ic Curve keys, I believe that there’s a potential vulnerability with = using the same key for both signing and encryption.  So I’m relu= ctant to define “both”.  The simplest way to indicate both may be to omit the parameter.  This could also be represented by= repeating the key with “use”:”sig” and “use&= #8221;:”enc” in the key set.  What do others in the workin= g group think about these possibilities?

 

6) s7: If the kid is not supposed to be generated= in a way to make it unique it's worth pointing this out in s7.<= /p>

 

Done

 

spt

_______________________________________________

jose mailing list

jose@ietf.org

https://www.iet= f.org/mailman/listinfo/jose

 

--_000_4E1F6AAD24975D4BA5B168042967394366579F40TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Fri Jul 6 10:40:48 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98FD411E8099 for ; Fri, 6 Jul 2012 10:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.763 X-Spam-Level: X-Spam-Status: No, score=-3.763 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEBc2CUb56hP for ; Fri, 6 Jul 2012 10:40:41 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id F230E21F864B for ; Fri, 6 Jul 2012 10:40:40 -0700 (PDT) Received: from mail65-am1-R.bigfish.com (10.3.201.248) by AM1EHSOBE010.bigfish.com (10.3.204.30) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Jul 2012 17:38:49 +0000 Received: from mail65-am1 (localhost [127.0.0.1]) by mail65-am1-R.bigfish.com (Postfix) with ESMTP id 0C502240413; Fri, 6 Jul 2012 17:38:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: VS-30(zz9371Ic85fh1454I168aJ148cI542Mzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail65-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail65-am1 (localhost.localdomain [127.0.0.1]) by mail65-am1 (MessageSwitch) id 1341596326404611_17184; Fri, 6 Jul 2012 17:38:46 +0000 (UTC) Received: from AM1EHSMHS017.bigfish.com (unknown [10.3.201.250]) by mail65-am1.bigfish.com (Postfix) with ESMTP id 5F8C9340047; Fri, 6 Jul 2012 17:38:46 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS017.bigfish.com (10.3.207.155) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Jul 2012 17:38:37 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0309.003; Fri, 6 Jul 2012 17:40:40 +0000 From: Mike Jones To: 'Jim Schaad' Thread-Topic: Comments on draft-ietf-jose-json-web-algorithms-02 Thread-Index: Ac1bnm0yDdR4osWGShO4zuEBHYQsVA== Date: Fri, 6 Jul 2012 17:40:40 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366579FC3@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366579FC3TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 17:40:48 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366579FC3TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for taking the time to provide the detailed feedback. Responses inl= ine... -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, May 21, 2012 3:46 PM To: Mike Jones Cc: jose@ietf.org Subject: Comments on draft-ietf-jose-json-web-algorithms-02 Here are comments this document Abstract 1. Since I called it out for JWK I will make the comment that I do not hav= e a problem with enumerate in this document. Noted Section 1 1. Just a comment - I am not sure why you feel the name to create a specif= ic acronym for this document but it does not really matter. It provides a shorthand name to refer to this document from others. 2. Need to expand JSON if you are going to use it. Not done here, because the word "JSON" here is used as part of a name, rath= er than as a reference to a specification or kind of data structure. I did= expand it the first time it is used to refer to the RFC 4627 data structur= es, in all the documents. 3. New paragraph for sentence starting with "Enumerating..." Separate jus= tification from what this document does and hash. Done 4. Move last sentence to the end of the first paragraph Done Section 2 1. In general I would like to see this duplicated into this document. Readers should not have to reference another document for this purpose. Done Section 3.1 1. I am not overly happy with the existence of a "none" algorithm. Does i= t really need to exist? Yes. It is already widely used in contexts where content can be either sig= ned or plaintext. And while it used to be defined in JWT, you'd earlier su= ggested that it be moved here, since it is of broader applicability than ju= st JWTs. Section 3.2 1. You may want to reference RFC4231 as well. It contains test vectors an= d such for the SHA2 HMACs If this spec were about implementing the SHA2 HMAC algorithms, I would agre= e, but since it's only about using them, I don't think this reference is ne= cessary. Feel free to push back on this, however... 2. HMAC SHA-256 is a MAC function not a hash function (para #2) Removed use of the incorrect designation 3. I have not yet read the updated JWS document, but I do worry about the = fact that this document is saying that the output should be base64url encod= ed. If the JWS document says the same thing injudiciously then one could e= asily see that people might double encode the result. I don't think there's a problem, as both documents make a clear distinction= between the "JWS Signature" value and the "Encoded JWS Signature" value, a= nd are careful to use the right term in the right place. (But obviously se= nd me corrections if you find a place where the wrong term is used.) 4. I have a real problem with people saying that UTF-8 and ASCII are the s= ame. They aren't and saying that they are does not make it so. They actually are the same in this case, since the JWS Secured Input consis= ts of only 7-bit ASCII characters (since they contain only base64url encode= d content and periods characters) that are represented the same in both enc= odings. But I agree that the previous text was potentially confusing and o= verly verbose. The text now only uses the phrase "the ASCII representation= of the JWS Secured Input", both here, and in the JWS spec. 5. I find it confusing to constantly refer to the JWS specification throug= hout this text. For one thing it makes it harder to refer to these documen= ts for other uses in JSON of these algorithms (such as for an encrypt and M= AC algorithm). These defined terms have now been incorporated into this document, per your= comment on Section 2, so there should be no longer any need to refer to th= e JWS spec to understand this section. Section 3.3 1. I am not sure why there is a reference to both RFC 3447 and FIPS 186-3. RSA v1.5 is fully defined and described in 3447. I eliminated the redundant reference 2. I would move the justification of PKCS v1.5 to security considerations = and not put it here. Done Section 3.4 1. I am not sure that the statement on key sizes makes any sense given tha= t a key size is implied by the group being used. Removed 2. Given that we are using JSON as the basic structure - why not use a JSO= N structure rather than concatenate - just the question of size? The concatenation is the standard representation produced by most implement= ations. I added a note to this effect in the spec. (And yes, the size is = better as well.) 3. If you are doing a guide for idiots - then you need to give the array s= izes for R and S for each of the algorithms Done for all the signing/MAC algorithms. This is especially important for = ES512, where the signature output size is a 132 byte array, which might sur= prise some people. (It's the concatenation two 66 byte arrays, each repres= enting a 521 bit integer.) In fact, I added an example of ES512 to the spe= c for this very reason. 4. I have never see the R,S pair be referred to as a point before. I beli= eve it is just an ordered pair of integers and not a point on the field. The "point" terminology is used by XML DSIG 2.0, at least about the (x, y) = pair. See http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124/#sec-ECKeyVa= lue. I could be wrong that (R, S) are also a point, but given that the P-5= 21 signature is a pair of 521-bit integers, it sure seems like it is. Any = ECDSA experts care to weigh in? 5. The following sentence puzzles me "The ECDSA validator will then determ= ine if the digital signature is valid, given the inputs." This sentence is just after the steps of how to do validation so saying it will then be validated does not make sense to= me. Deleted Section 3.5 1. I would put the justification for plaintext JWS in JWS not here. In fac= t I would almost prefer a version of JWS that omitted the alg parameter to = say that it has no security than what is done here. I think this entire se= ction should be moved into JWS. Since "none" is an algorithm, it's in the JWA spec. Section 3.5 describes = how to create a JWS using it, just like Sections 3.2, 3.3, 3.4 describe how= to create JWSs using other algorithms. I've changed the title of this sec= tion to 'Using the Algorithm "none"' to make it more parallel and removed t= he justification text. A modified version of it appears in a new paragraph= in the Security Considerations section, making it clear that since this al= gorithm provides no integrity protection, and that it should only be used i= n certain contexts. Section 3.6 1. I don't see the purpose of the last paragraph in this section. It has = nothing to do with algorithms. This subsection is not only about algorithms - it's about extensions to JWS= , the parameters registry for which is also in the JWA spec because it's sh= ared between JWS and JWE. The first and second paragraphs of this subsecti= on is about extensions via algorithms and has a reference to that JWA regis= try. The third paragraph is about extensions via parameters, and has a ref= erence to that JWA registry. Not that 3.6 is parallel to 4.11 which has th= e same content for JWEs. All that being said, I'd be open to a different editorial structuring, if s= omeone wants to make an alternative proposal. Section 4.5 1. RSA-OAEP is under specified. There are a number of parameters for OAEP= that must be defined to go with it. These include the mask function and a= hash function. Look at RFC 3447 for the details. This is now fully specified. The description now reads: RSA using Optimal= Asymmetric Encryption Padding (OAEP), as defined in RFC 3447, with the def= ault parameters specified by RFC 3447 in Section A.2.1 Section 4.6 1. I would rephrase the last paragraph as being you must re-generate a new= EPK for each key agreement done rather than saying that you cannot reuse t= hem. The way specified might say that you can never re-use them rather tha= n you should only rarely re-use them and in an unpredictable manner. Done 2. I strongly disagree with setting OtherInfo parameters to be empty. We need to define and fill in the AlgorithmId at a minimum. Note that this ca= n be an implicit computation and does not need to be carried as extra data. At a minimum I would suggest something along the lines of JOSE-### where ##= # is the number of bits to get generated. Per my response to Sean's related comment, it's not clear to me what additi= onal value these parameters add in our usage of the algorithm. If we belie= ve that the content master key is undeterminable by an attacker (a requirem= ent for any security at all!) then adding a constant AlgorithmID to the com= putation I don't believe changes the security properties. (That being said= , we *could* use the "alg" value "ECDH-ES" as the AlgorithmID if people fel= t better about doing this.) Also given that the text now says (per your previous comment) that "A new e= pk (ephemeral public key) value MUST be generated for each key agreement tr= ansaction", it's not clear that adding parameters identifying the participa= ting parties adds any security value either. That being said, I'd be glad = to learn why I'm wrong. If there are good security reasons for requiring PartyUInfo and PartyVInfo = values, do you have suggestions on how to create acceptable values without = carrying more parameters in the header? (I've already suggested that we co= uld use the "alg" value "ECDH-ES" as the AlgorithmID, which wouldn't requir= e more parameters.) For instance, I don't want to blindly follow XML ENC's lead and punt the is= sue by requiring that conforming uses provide explicit PartyUInfo and Party= VInfo values. Finally, I'll note that the KDF function used by TLS http://tools.ietf.org/= html/rfc5246#section-5 uses no party parameters. Why do we need them then? 3. Same comment as above about key sizes - key sizes are specified by the = curve being used. Deleted Section 4.8 1. Use of an IV is REQUIRED not RECOMMENDED Done. Now reads: Use of an initialization vector of size 128 bits is REQU= IRED with this algorithm. Section 4.9 1. Specification of the data to be processed needs to be in JWE not in thi= s document. It should just specify that there are the following inputs: Additional data and data to be encrypted. Interesting question of is this where the key is generated or not - I would ignore that issue. The computation of the "additional authenticated data" value is now only in= the JWE spec and referenced from this section of JWA Section 4.10 1. Is this section needed? It is a duplicate of the same data in section 3.2 (or it should be) Now references Section 3.2 and only describes the differences Section 4.11 1. for last paragraph see comment on 3.6 Same response as for 3.6 Section 6.1 1. I would move this registry to either the signature or encryption docume= nts and not put it here. What does this document populate it with? Done Section 6.2 1. Make life easy for IANA and me - create a table of the values Done both here and in the other documents 2. Can an algorithm have more than one usage? Yes, clarified in doc Section 6.3 1. This registry should be in either the encryption or signature draft Done - now in JWS Section 6.4 1. This registry should be in the JWK document Done Section 6.5 1. Make life easy for IANA and me - create a table of the values Done both here and in the other documents --_000_4E1F6AAD24975D4BA5B168042967394366579FC3TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for taking t= he time to provide the detailed feedback.  Responses inline…

 

-----Original Message-----
From: Jim Schaad [mailto= :ietf@augustcellars.com]
Sent: Monday, May 21, 2012 3:46 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: Comments on draft-ietf-jose-json-web-algorithms-02

 

Here are comments this document

 

Abstract

 

1.  Since I called it out for JWK I will mak= e the comment that I do not have a problem with enumerate in this document.=

 

Noted

 

Section 1

 

1.  Just a comment - I am not sure why you f= eel the name to create a specific acronym for this document but it does not= really matter.

 

It provides a short= hand name to refer to this document from others.

 

2.  Need to expand JSON if you are going to = use it.

 

Not done here, beca= use the word “JSON” here is used as part of a name, rather than= as a reference to a specification or kind of data structure.  I did e= xpand it the first time it is used to refer to the RFC 4627 data structures, in all the documents.

 

3.  New paragraph for sentence starting with= "Enumerating..."  Separate justification from what this doc= ument does and hash.

 

Done

 

4.  Move last sentence to the end of the fir= st paragraph

 

Done

 

Section 2

 

1.  In general I would like to see this dupl= icated into this document.

Readers should not have to reference another docu= ment for this purpose.

 

Done

 

Section 3.1

 

1.  I am not overly happy with the existence= of a "none" algorithm.  Does it really need to exist?<= /o:p>

 

Yes.  It is al= ready widely used in contexts where content can be either signed or plainte= xt.  And while it used to be defined in JWT, you’d earlier sugge= sted that it be moved here, since it is of broader applicability than just JWTs.

 

Section 3.2

 

1.  You may want to reference RFC4231 as wel= l.  It contains test vectors and such for the SHA2 HMACs

 

If this spec were a= bout implementing the SHA2 HMAC algorithms, I would agree, but since itR= 17;s only about using them, I don’t think this reference is necessary= .  Feel free to push back on this, however…

 

2.  HMAC SHA-256 is a MAC function not a has= h function (para #2)

 

Removed use of the = incorrect designation

 

3.  I have not yet read the updated JWS docu= ment, but I do worry about the fact that this document is saying that the o= utput should be base64url encoded.  If the JWS document says the same = thing injudiciously then one could easily see that people might double encode the result.

 

I don’t think= there’s a problem, as both documents make a clear distinction betwee= n the “JWS Signature” value and the “Encoded JWS Signatur= e” value, and are careful to use the right term in the right place.&n= bsp; (But obviously send me corrections if you find a place where the wrong ter= m is used.)

 

4.  I have a real problem with people saying= that UTF-8 and ASCII are the same.  They aren't and saying that they = are does not make it so.

 

They actually are t= he same in this case, since the JWS Secured Input consists of only 7-bit AS= CII characters (since they contain only base64url encoded content and perio= ds characters) that are represented the same in both encodings.  But I agree that the previous text was p= otentially confusing and overly verbose.  The text now only uses the p= hrase “the ASCII representation of the JWS Secured Input”, both= here, and in the JWS spec.

 

5.  I find it confusing to constantly refer = to the JWS specification throughout this text.  For one thing it makes= it harder to refer to these documents for other uses in JSON of these algo= rithms (such as for an encrypt and MAC algorithm).

 

These defined terms= have now been incorporated into this document, per your comment on Section= 2, so there should be no longer any need to refer to the JWS spec to under= stand this section.

 

Section 3.3

 

1.  I am not sure why there is a reference t= o both RFC 3447 and FIPS 186-3.

RSA v1.5 is fully defined and described in 3447.<= o:p>

 

I eliminated the re= dundant reference

 

2.  I would move the justification of PKCS v= 1.5 to security considerations and not put it here.

 

Done

 

Section 3.4

 

1.  I am not sure that the statement on key = sizes makes any sense given that a key size is implied by the group being u= sed.

 

Removed<= /span>

 

2.  Given that we are using JSON as the basi= c structure - why not use a JSON structure rather than concatenate - just t= he question of size?

 

The concatenation i= s the standard representation produced by most implementations.  I add= ed a note to this effect in the spec.  (And yes, the size is better as= well.)

 

3.  If you are doing a guide for idiots - th= en you need to give the array sizes for R and S for each of the algorithms<= o:p>

 

Done for all the si= gning/MAC algorithms.  This is especially important for ES512, where t= he signature output size is a 132 byte array, which might surprise some peo= ple.  (It’s the concatenation two 66 byte arrays, each representing a 521 bit integer.)  In fact, I added an ex= ample of ES512 to the spec for this very reason.

 

4.  I have never see the R,S pair be referre= d to as a point before.  I believe it is just an ordered pair of integ= ers and not a point on the field.

 

The “point= 221; terminology is used by XML DSIG 2.0, at least about the (x, y) pair.&n= bsp; See http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124/#sec-ECKeyV= alue.  I could be wrong that (R, S) = are also a point, but given that the P-521 signature is a pair of 521-bit integers, it sure seems like it is.  A= ny ECDSA experts care to weigh in?

 

5.  The following sentence puzzles me "= The ECDSA validator will then determine if the digital signature is

   valid, given the inputs." =   This sentence is just after the steps of how

to do validation so saying it will then be valida= ted does not make sense to me.

 

Deleted<= /span>

 

Section 3.5

 

1. I would put the justification for plaintext JW= S in JWS not here.  In fact I would almost prefer a version of JWS tha= t omitted the alg parameter to say that it has no security than what is don= e here.  I think this entire section should be moved into JWS.

 

Since “none&#= 8221; is an algorithm, it’s in the JWA spec.  Section 3.5 descri= bes how to create a JWS using it, just like Sections 3.2, 3.3, 3.4 describe= how to create JWSs using other algorithms.  I’ve changed the title of this section to ‘Using the Algorithm "none"' to m= ake it more parallel and removed the justification text.  A modified v= ersion of it appears in a new paragraph in the Security Considerations sect= ion, making it clear that since this algorithm provides no integrity protection, and that it should only be used in certain contex= ts.

 

Section 3.6

 

1.  I don't see the purpose of the last para= graph in this section.  It has nothing to do with algorithms.

 

This subsection is = not only about algorithms – it’s about extensions to JWS, the p= arameters registry for which is also in the JWA spec because it’s sha= red between JWS and JWE.  The first and second paragraphs of this subsection is about extensions via algorithms and has a reference = to that JWA registry.  The third paragraph is about extensions via par= ameters, and has a reference to that JWA registry.  Not that 3.6 is pa= rallel to 4.11 which has the same content for JWEs.

 

All that being said= , I’d be open to a different editorial structuring, if someone wants = to make an alternative proposal.

 

Section 4.5

 

1.  RSA-OAEP is under specified.  There= are a number of parameters for OAEP that must be defined to go with it.&nb= sp; These include the mask function and a hash function.  Look at RFC = 3447 for the details.

 

This is now fully s= pecified.  The description now reads:  RSA using Optimal Asymmetr= ic Encryption Padding (OAEP), as defined in RFC 3447, with the default para= meters specified by RFC 3447 in Section A.2.1

 

Section 4.6

 

1.  I would rephrase the last paragraph as b= eing you must re-generate a new EPK for each key agreement done rather than= saying that you cannot reuse them.  The way specified might say that = you can never re-use them rather than you should only rarely re-use them and in an unpredictable manner.

 

Done

 

2.  I strongly disagree with setting OtherIn= fo parameters to be empty.   We

need to define and fill in the AlgorithmId at a m= inimum.  Note that this can be an implicit computation and does not ne= ed to be carried as extra data.

At a minimum I would suggest something along the = lines of JOSE-### where ### is the number of bits to get generated.

 

Per my response to = Sean’s related comment, it's not clear to me what additional value th= ese parameters add in our usage of the algorithm.  If we believe that = the content master key is undeterminable by an attacker (a requirement for any security at all!) then adding a constant A= lgorithmID to the computation I don't believe changes the security properti= es.  (That being said, we *could* use the “alg” value &quo= t;ECDH-ES" as the AlgorithmID if people felt better about doing this.)

 

Also given that the= text now says (per your previous comment) that "A new epk (ephemeral = public key) value MUST be generated for each key agreement transaction"= ;, it's not clear that adding parameters identifying the participating parties adds any security value either.  That being= said, I'd be glad to learn why I'm wrong.

 

If there are good s= ecurity reasons for requiring PartyUInfo and PartyVInfo values, do you have= suggestions on how to create acceptable values without carrying more param= eters in the header?  (I've already suggested that we could use the “alg” value "ECDH-ES"= ; as the AlgorithmID, which wouldn't require more parameters.)

 

For instance, I don= 't want to blindly follow XML ENC's lead and punt the issue by requiring th= at conforming uses provide explicit PartyUInfo and PartyVInfo values.<= /o:p>

 

Finally, I'll note = that the KDF function used by TLS http://tools.ietf.= org/html/rfc5246#section-5 uses no party parameters.  Why do we ne= ed them then?

 

3.  Same comment as above about key sizes - = key sizes are specified by the curve being used.

 

Deleted<= /span>

 

Section 4.8

 

1. Use of an IV is REQUIRED not RECOMMENDED<= /o:p>

 

Done.  Now rea= ds:  Use of an initialization vector of size 128 bits is REQUIRED with= this algorithm.

 

Section 4.9

 

1.  Specification of the data to be processe= d needs to be in JWE not in this document.  It should just specify tha= t there are the following inputs:

Additional data and data to be encrypted. &n= bsp; Interesting question of is this

where the key is generated or not - I would ignor= e that issue.

 

The computation of = the “additional authenticated data” value is now only in the JW= E spec and referenced from this section of JWA

 

Section 4.10

 

1.  Is this section needed?  It is a du= plicate of the same data in section

3.2 (or it should be)

 

Now references Sect= ion 3.2 and only describes the differences

 

Section 4.11

 

1.  for last paragraph see comment on 3.6

 

Same response as fo= r 3.6

 

Section 6.1

 

1.  I would move this registry to either the= signature or encryption documents and not put it here.  What does thi= s document populate it with?

 

Done

 

Section 6.2

 

1.  Make life easy for IANA and me - create = a table of the values

 

Done both here and = in the other documents

 

2.  Can an algorithm have more than one usag= e?

 

Yes, clarified in d= oc

 

Section 6.3

 

1.  This registry should be in either the en= cryption or signature draft

 

Done – now in= JWS

 

Section 6.4

 

1.  This registry should be in the JWK docum= ent

 

Done

 

Section 6.5

 

1.  Make life easy for IANA and me - create = a table of the values

 

Done both here and = in the other documents

 

--_000_4E1F6AAD24975D4BA5B168042967394366579FC3TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Fri Jul 6 10:53:42 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8087421F8622 for ; Fri, 6 Jul 2012 10:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=-1.312, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_SAVELE=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-d-b7NTZZ7i for ; Fri, 6 Jul 2012 10:53:31 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9F421F8570 for ; Fri, 6 Jul 2012 10:53:31 -0700 (PDT) Received: from mail100-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Jul 2012 17:51:39 +0000 Received: from mail100-ch1 (localhost [127.0.0.1]) by mail100-ch1-R.bigfish.com (Postfix) with ESMTP id 94F384E0210; Fri, 6 Jul 2012 17:51:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -37 X-BigFish: VS-37(zz9371Ic85fh1454I168aJ148cI542M1418Izz1202hzz1033IL8275bh30d1K8275dh5eeeKz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail100-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail100-ch1 (localhost.localdomain [127.0.0.1]) by mail100-ch1 (MessageSwitch) id 1341596997139731_24230; Fri, 6 Jul 2012 17:49:57 +0000 (UTC) Received: from CH1EHSMHS013.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail100-ch1.bigfish.com (Postfix) with ESMTP id 1FEA74402D7; Fri, 6 Jul 2012 17:49:57 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS013.bigfish.com (10.43.70.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Jul 2012 17:49:56 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0298.005; Fri, 6 Jul 2012 17:52:04 +0000 From: Mike Jones To: 'Sean Turner' , "jose@ietf.org" Thread-Topic: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-02.txt Thread-Index: Ac1bn/p6saRq5xK4S46UlSE1iY4F/Q== Date: Fri, 6 Jul 2012 17:52:03 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366579FF6@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366579FF6TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-02.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 17:53:42 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366579FF6TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for taking the time to provide the detailed feedback. Responses inl= ine... -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Sean Turn= er Sent: Monday, May 28, 2012 10:36 AM To: jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-02.txt Here are some comments (I'll try not to duplicate Jim's): 1) s1/s6: (wherever the registry gets established): s1 contains the following: in the face of changes in the set of required, recommended, optional, and deprecated algorithms over time. Did you intend for the registry to include a column indicating the whether = the algorithm is required, recommended, optional or deprecated? Good idea - Done 2) General: In other specs, we would give a hint to implementers with + and= - to indicate which direction the algs were headed: + moving up the suppor= t ladder and - moving down the support ladder. E.g., SHOULD+ would indicat= e that in the next version that alg was probably going to be a MUST. Is th= is worth adopting here? Good idea - Done 3) s2 & Requirements Language: The RFC editor is going to move the Requirem= ents Language section later on so you might as well save them the trouble a= nd just make it part of s2. Done 4) s3: Expand MAC Done 5) Alg Names: It's probably worth pointing out that the alg parameter value= s isn't limited to 5 characters. Done 6) s3.1: This is related to #1: Should we just add a column to indicate the= support level? Done 7) s3.1: Add a column for key size too? Not done, since a value for this column is not needed in all cases 8) s3.1: HMAC SHA-256 is the default? UGH! Neither RSA SHA-256 nor ECDSA P-256 SHA-256 are required because in some ca= ses, deployments may only want to use RSA because it's commonly deployed, w= hereas in other cases, deployments may only want to use Elliptic Curve for = size and computational speed reasons. Thus, since there's no clear choice = for asymmetric algorithms, neither is required (although both are RECOMMEND= ED). Whereas, there's a clear choice for symmetric algorithms. 9) s3.2: Consider a reference to RFC 6234 because it contains sample code f= or the listed HMACs. If this spec were about implementing the HMAC algorithms, I would definitel= y add this, but given it's about using the algorithms, the reference seems = unnecessary (just as I believe Jim's suggested reference to RFC 4231 was). = But like I told Jim about 4231, feel free to push back on this... 10) s3.2: Add reference to 4648 when you first mention base64url. Also nee= d to specify the alphabet you're going to use - I'd point to the section an= d not assume "url" is enough. Base64url Encoding is defined in the terminology section, and does include = a 4648 reference. 11) s3.2: Add a normative reference to RFC 3629 for UTF-8. The first use of UTF-8 does include a 3629 reference - again, in the termin= ology section. 12) s3.2: Two steps for the HMAC: I think it would be clearer to talk about= this in terms of 2104. I think that means: The HMAC SHA-256 MAC is generated as follows: - text, see [RFC2104], is the bytes of the UTF-8 representation of the JWS = Secured Input - use HMAC-256 as the hash algorithm H The output is then base64url encoded and is used as the Encoded JWS Signatu= re for that JWS. Ditto for the validation bit. Completed rewrote this part to simplify it, based upon your input above 13) FIPS references: Consider using DSS and SHS instead of FIPS.186-3 and F= IPS.180-3. Done 14) Not sure we need the following: Note that while Section 8 of RFC 3447 [RFC3447] explicitly calls for people not to adopt RSASSA-PKCS1 for new applications and instead requests that people transition to RSASSA-PSS, for interoperability reasons, this specification does use RSASSA-PKCS1 because it commonly implemented. RFC 3447 is informational and I believe it's essentially an RSA Labs docume= nt. If you're going to keep this then maybe we need to be clearer that RFC= 3447 says this and that it's an RSA spec. Per Jim's comment, this text has been removed and a modified form of it now= appears in the Security Considerations section. 15) s3.4: The 160-bit key is which key public or private? And, why isn't t= he key size linked to the curve? 256 for P-256, 384 for P-384, and 521 for= P-521. Removed per Jim's comment, since the key size is implied by the algorithm. 16) s3.4: I'm not sure if this is worth pointing out or not, but other EC k= ey format specs include one extra byte at the beginning to indicate the key= type: uncompressed, compressed, hybrid, etc. This isn't a key representation - it's signature output. 17) s3.4: In this step: 2. The output of the base64url decoding MUST be a 64 byte array. Add that: If decoding does not result in a 64 byte array, the JWS MUST be r= ejected. Done 18) s3.4: I'm no cryptographer, but I think the following is wrong if you m= ean the validator needs to be given k in addition to the public key and r,s= : The consequence of this is that one must validate an ECDSA digital signature by submitting the previously specified inputs to an ECDSA validator. SHS points to ASNI for signature verification and I don't have that handy s= o I went to the Suite B implementers guide (http://www.nsa.gov/ia/_files/ecdsa.pdf) to look for the signature ECDSA ve= rification steps. I didn't see k as being needed when you verify. Reworded to hopefully eliminate the potential confusion 19) s3.5: Is this section for authenticated encryption algs or because the = lower layers are taking care of authentication/integrity? Reworded, per Jim's comment. (It's because integrity is being provided by = other means or isn't necessary in the use cases for this feature.) 20) s3.1/s3.6, s4.1-3/s4.11, s5.1/s.5.4, and s6.*: A couple of things about= these paragraphs made me scratch my head: 20.1) Registry: Normally, we set up a registry to restrict the values used = in a protocol. This sets the MTI, establishes a registry with RFC required= , and then lets everybody off the hook with an well-known/collision-resista= nt URI. It seems like nobody would ever go the RFC route - ever. A couple= of thoughts: - Do we need the following: "URI that contains a collision resistant namesp= ace"? Implementations are free to support whatever they want and I'm sure = somebody will ask you to define what "a collision resistant namespace" is. "Collision Resistant Namespace" was already defined in JWT. I've added the= definition to JWS, JWE, JWK, and JWA as well. The registries are only needed in this case to prevent collisions when name= s not containing a collision-resistant namespace, such as "example" are def= ined. It's perfectly fine to use names like http://schemas.xmlsoap.org/ws/= 2005/05/identity/claims/privatepersonalidentifier or urn:oasis:names:tc:SAM= L:2.0:assertion or 73a7c4e8-8296-43e3-ba77-46730a3e9e57 (a GUID) without us= ing the registries, as no name conflicts will arise. - Maybe the registry should just be Specification Required + Expert review?= That way it's more of level playing field. I can't see anybody ever doin= g an RFC if all they need is a collision resistant namespace. Done - On the other hand are you trying to say that the MTI alg must be set in a= standards track RFC but other values maybe specified in elsewhere? No. This was just language that was cut-and-pasted in while writing the sp= ec. It's been changed now, per your comment above. Please review. 20.2) Algorithm naming: Being new to the block, I'm trying to understand wh= y we can't reuse an already well know identifier for the algs. (just picki= ng on the first set of algs but this applies to them all) HMAC-SHA256 is pretty well understood so I'm wondering whether it is really= worth saving five bytes over HS256? Ditto for RSAwithSHA* and ECDSAwithSH= A*; I guess you're saving more with these, but I question whether it's rea= lly worth adding yet another way to name an alg. This was a result of a consensus decision among the collaborators who joint= ly developed the JWT spec, which was also publicly reviewed and confirmed s= hortly thereafter at the Internet Identity Workshop in November, 2010. Giv= en that some browsers have (short) URI length restrictions and we wanted to= be able to use JWTs in URI query parameters, keeping the representations c= ompact was a core goal of the specification. 20.3) Duplication identifiers (might partially go away based on 20.2): (just picking on the first set of algs but this applies to them all) What a= re we going to do about duplicate identifiers? Right now HMAC-SHA256, HMAC= -SHA384, and HMAC-SHA512 are defined as well as ECDSA/RSA with SHA-256, etc= . in XMLDsig. There's also some defined by RSA in RFC 4231. Don't we need= to say something about preferring one over the other? The registry and the use of collision resistant namespaces is intended to p= revent collisions. 21) s4.1: Technically, for encryption RSA is RSAES-PKCS1-v1_5 or RSAES-OAEP= so: | RSA1_5 | RSAES-PKCS1-1.5 [RFC3447] | | RSA-OAEP | RSAES-Optimal Asymmetric Encryption Padding (OAEP) | | | (OAEP) [RFC3447] | Done Actually you can replace: ", as defined in [XXXX]" in the tables in s4.1 an= d s4.2 with "[XXXX]" - just to make it less wordy. And you only need to ex= pand AES, CBC, and GCM once ;) Done and done 22) s4.1: Need to add ECDH-ES with different curves. If you're going to al= low ECDSA P-521, then matching it with ECDH-ES P-521 makes sense. Are there specific additional curve/hash function combinations that you'd l= ike to make the case to the working group to add? The current set was moti= vated by the choices in NIST Suite B. 23) s4.1/s4.6: Err...I don't think you should set OtherInfo to zero!? If we= 're using s5.8.1 then at a minimum it's AlgorithmID || PartyUInfo || PartyV= Info. It's not clear to me what additional value these parameters add in our usag= e of the algorithm. If we believe that the randomly generated ephemeral ke= y is undeterminable by an attacker (a requirement for any security at all!)= then adding a constant AlgorithmID to the computation I don't believe chan= ges the security properties. (That being said, we *could* use the "alg" va= lue "ECDH-ES" as the AlgorithmID if people felt better about doing this.) Also given that the text now says (per a comment of Jim's) that "A new epk = (ephemeral public key) value MUST be generated for each key agreement trans= action", it's not clear that adding parameters identifying the participatin= g parties adds any security value either. That being said, I'd be glad to = learn why I'm wrong. If there are good security reasons for requiring PartyUInfo and PartyVInfo = values, do you have suggestions on how to create acceptable values without = carrying more parameters in the header? (I've already suggested that we co= uld use the alg value "ECDH-ES" as the AlgorithmID, which wouldn't require = more parameters.) For instance, I don't want to blindly follow XML ENC's lead and punt the is= sue by requiring that conforming uses provide explicit PartyUInfo and Party= VInfo values. Finally, I'll note that the KDF function used by TLS http://tools.ietf.org/= html/rfc5246#section-5 uses no party parameters. Why do we need them then? 24) s4.2: Some folks like AES-CCM - worth adding? This could be added if the WG wants to. I'd want us to look at how widely = deployed it is when determining whether it should be any more than OPTIONAL= . 25) s4.2: r/RSA-PKCS1-1.5/RSAES-PKCS1-v1_5 Done 26) s4.2: Seems like we should pair up 128 kw/cbc and 256 kw/cbc. When you= pick a set of algs they ought to be matched. Added this to the Security Considerations: Algorithms of matching strength should be used together whe= never possible. For instance, when AES Key Wrap is used with a given key si= ze, using the same key size for AES CBC or GCM is recommended. Likewise, when AES CBC is used with a 128 bit key, using HM= AC SHA-256 as the integrity algorithm is recommended, whereas when AES CBC is used with a 256 bit key, using HMAC SHA-512 as the integrity algorithm is recommended. 27) s4.3: r//>/ Done 28) s4.3: I think this is a cut/paste error: r/It is RECOMMENDED that implementations also support the RSA SHA-256 and ECDSA P-256 SHA-256 algorithms./It is RECOMMENDED that implementations also support the HMAC SHA-256 and HMAC SHA-384 algorithms. Replaced by the table values 29) s4.3: (no action required) Curious that plain old SHA-* isn't used here= . I guess I'll figure out why when I get to the other specs. It's because the integrity calculation uses a key - the Content Integrity K= ey (CIK) 30) s4.4: r/RSA using RSA-PKCS1-1.5 padding, as defined in RFC 3447 [RFC3447]/RSAES-PKCS1-v1_5 [RFC3447] Done 31) s4.5: r/RSA using Optimal Asymmetric Encryption Padding (OAEP), as defi= ned in RFC 3447 [RFC3447]/RSAES-OAEP [RFC3447] Done 32) s4.5: Way underspecified - SHA1 is the default hash alg in 3447 - need = to profile the values in 3447. Now specifies use of default parameters, as this is the version of OAEP tha= t is most widely deployed, per my response to Jim's comment. Other "alg" v= alues could be defined for OAEP with different parameters if people believe= it's useful and those parameter combinations are widely enough available. 33) s4.6: EC key size again - why isn't it 256-bit? And which key are we ta= lking about? Removed, as per comment 15 34) s4.7: Need to specify a MTI. If you link it to the key size of the key= being wrapped then it's easy: 128 key being wrapped MUST use 128 key to wr= ap, 256 ... MTI now specified in "Implementation Requirements" column. Also, see my re= sponse to #26. 35) s5.2.1: We've got a bunch of ways to name the curve :( I think you hav= e to say the curves are as defined in the DSS. Brainpool has curves that a= lso use some similar p256, p384, etc. Done 36) s5.3: If you're going to use RSAES-OAEP or RSASSA-PSS there's a whole b= unch more parameters that can be included (see RFC 4055). Are they not goi= ng to be used? See my response to #32 37) s5.3.2: Should we specifying that e=3D65537 must be used? I've added this to the Security Considerations: Keys used with RSAES-PKCS1-v1_5 must follow the constraints= in Section 7.2 of . In particular, = keys with a low public key exponent value must not be used. 38) s7: Because you're starting from scratch you're going to need to greatl= y expand this section. However, you can avoid a lot of this by listing all= the references for the algs used in this spec and say that the security co= nsiderations from those reference apply. Done - referencing DSS names Need to say that the key size/hash alg combo should be matched. Some might= find SP800-57 Part 1 useful. See my answer to #26 Need to explain that really large keys can be a DOS. Some text you might m= assage: Receiving agents that validate signatures and sending agents that encrypt messages need to be cautious of cryptographic processing usage when validating signatures and encrypting messages using keys larger than those mandated in this specification. An attacker could send certificates with keys that would result in excessive cryptographic processing, for example, keys larger than those mandated in this specification, which could swamp the processing element. Agents that use such keys without first validating the certificate to a trust anchor are advised to have some sort of cryptographic resource management system to prevent such attacks. Thanks - incorporated Some other motherhood and apple pie that you might also include: All of the security issues faced by any cryptographic application must be faced by a JWS/JWE agent. Among these issues are protecting the user's private key, preventing various attacks, and helping the user avoid mistakes such as inadvertently encrypting a message for the wrong recipient. The entire list of security considerations is beyond the scope of this document, but some significant concerns are listed here. Thanks - incorporated spt _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B168042967394366579FF6TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for taking t= he time to provide the detailed feedback.  Responses inline…

 

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Sean Turner
Sent: Monday, May 28, 2012 10:36 AM
To: jose@ietf.org
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-02.txt<= o:p>

 

Here are some comments (I'll try not to duplicate= Jim's):

 

1) s1/s6: (wherever the registry gets established= ): s1 contains the

following:

 

  in the face of changes in

  the set of required, recommended, optional= , and deprecated algorithms

  over time.

 

Did you intend for the registry to include a colu= mn indicating the whether the algorithm is required, recommended, optional = or deprecated?

 

Good idea - Done

 

2) General: In other specs, we would give a hint = to implementers with + and - to indicate which direction the algs were = headed: + moving up the support ladder and - moving down the support la= dder.  E.g., SHOULD+ would indicate that in the next version that alg was probably going to be a MUST.  Is this w= orth adopting here?

 

Good idea - Done

 

3) s2 & Requirements Language: The RFC editor= is going to move the Requirements Language section later on so you might a= s well save them the trouble and just make it part of s2.

 

Done

 

4) s3: Expand MAC

 

Done

 

5) Alg Names: It's probably worth pointing out th= at the alg parameter values isn't limited to 5 characters.

 

Done

 

6) s3.1: This is related to #1: Should we just ad= d a column to indicate the support level?

 

Done

 

7) s3.1: Add a column for key size too?

 

Not done, since a v= alue for this column is not needed in all cases

 

8) s3.1: HMAC SHA-256 is the default?  UGH!<= o:p>

 

Neither RSA SHA-256= nor ECDSA P-256 SHA-256 are required because in some cases, deployments ma= y only want to use RSA because it’s commonly deployed, whereas in oth= er cases, deployments may only want to use Elliptic Curve for size and computational speed reasons.  Thus, since= there’s no clear choice for asymmetric algorithms, neither is requir= ed (although both are RECOMMENDED).  Whereas, there’s a clear ch= oice for symmetric algorithms.

 

9) s3.2: Consider a reference to RFC 6234 because= it contains sample code for the listed HMACs.

 

If this spec were a= bout implementing the HMAC algorithms, I would definitely add this, but giv= en it’s about using the algorithms, the reference seems unnecessary (= just as I believe Jim’s suggested reference to RFC 4231 was).  But like I told Jim about 4231, feel free to push = back on this…

 

10) s3.2: Add reference to 4648 when you first me= ntion base64url.  Also need to specify the alphabet you're going to us= e - I'd point to the section and not assume "url" is enough.=

 

Base64url Encoding = is defined in the terminology section, and does include a 4648 reference.

 

11) s3.2: Add a normative reference to RFC 3629 f= or UTF-8.

 

The first use of UT= F-8 does include a 3629 reference – again, in the terminology section= .

 

12) s3.2: Two steps for the HMAC: I think it woul= d be clearer to talk about this in terms of 2104.  I think that means:=

 

The HMAC SHA-256 MAC is generated as follows:

 

- text, see [RFC2104], is the bytes of the UTF-8 = representation of the JWS Secured Input

 

- use HMAC-256 as the hash algorithm H=

 

The output is then base64url encoded and is used = as the Encoded JWS Signature for that JWS.

 

Ditto for the validation bit.

 

Completed rewrote t= his part to simplify it, based upon your input above

 

13) FIPS references: Consider using DSS and SHS i= nstead of FIPS.186-3 and FIPS.180-3.

 

Done

 

14) Not sure we need the following:

 

  Note that while Section 8 of RFC 3447 [RFC= 3447] explicitly calls for

  people not to adopt RSASSA-PKCS1 for new a= pplications and instead

  requests that people transition to RSASSA-= PSS, for interoperability

  reasons, this specification does use RSASS= A-PKCS1 because it commonly

  implemented.

 

RFC 3447 is informational and I believe it's esse= ntially an RSA Labs document.  If you're going to keep this then maybe= we need to be clearer that RFC 3447 says this and that it's an RSA spec.

 

Per Jim’s com= ment, this text has been removed and a modified form of it now appears in t= he Security Considerations section.

 

15) s3.4: The 160-bit key is which key public or = private?  And, why isn't the key size linked to the curve?  256 f= or P-256, 384 for P-384, and 521 for P-521.

 

Removed per JimR= 17;s comment, since the key size is implied by the algorithm.

 

16) s3.4: I'm not sure if this is worth pointing = out or not, but other EC key format specs include one extra byte at the beg= inning to indicate the key type: uncompressed, compressed, hybrid, etc.

 

This isn’t a = key representation – it’s signature output.

 

17) s3.4: In this step:

 

  2.  The output of the base64url decod= ing MUST be a 64 byte array.

 

Add that: If decoding does not result in a 64 byt= e array, the JWS MUST be rejected.

 

Done

 

18) s3.4: I'm no cryptographer, but I think the f= ollowing is wrong if you mean the validator needs to be given k in addition= to the public key and r,s:

 

  The consequence of this is that one must v= alidate an ECDSA digital

  signature by submitting the previously spe= cified inputs to an ECDSA

  validator.

 

SHS points to ASNI for signature verification and= I don't have that handy so I went to the Suite B implementers guide

(http://www.nsa.gov= /ia/_files/ecdsa.pdf) to look for the signature ECDSA verificati= on steps.  I didn't see k as being needed when you verify.

 

Reworded to hopeful= ly eliminate the potential confusion

 

19) s3.5: Is this section for authenticated encry= ption algs or because the lower layers are taking care of authentication/in= tegrity?

 

Reworded, per Jim&#= 8217;s comment.  (It’s because integrity is being provided by ot= her means or isn’t necessary in the use cases for this feature.)=

 

20) s3.1/s3.6, s4.1-3/s4.11, s5.1/s.5.4, and s6.*= : A couple of things about these paragraphs made me scratch my head:

 

20.1) Registry: Normally, we set up a registry to= restrict the values used in a protocol.  This sets the MTI, establish= es a registry with RFC required, and then lets everybody off the hook with = an well-known/collision-resistant URI.  It seems like nobody would ever go the RFC route - ever.  A couple of= thoughts:

 

- Do we need the following: "URI that contai= ns a collision resistant namespace"?  Implementations are free to= support whatever they want and I'm sure somebody will ask you to define wh= at "a collision resistant namespace" is.

 

“Collision Re= sistant Namespace” was already defined in JWT.  I’ve added= the definition to JWS, JWE, JWK, and JWA as well.

 

The registries are = only needed in this case to prevent collisions when names not containing a = collision-resistant namespace, such as “example” are defined.&n= bsp; It’s perfectly fine to use names like http://schemas.xmlsoap.org/ws/2005/05/identity/clai= ms/privatepersonalidentifier or urn:oasis= :names:tc:SAML:2.0:assertion or 73a7c4e8-8296-43e3-ba77-46730a3e9e57 (a GUID) without using the registries, as no name conflicts will arise.

 

- Maybe the registry should just be Specification= Required + Expert review?  That way it's more of level playing fi= eld.  I can't see anybody ever doing an RFC if all they need is a coll= ision resistant namespace.

 

Done

 

- On the other hand are you trying to say that th= e MTI alg must be set in a standards track RFC but other values maybe speci= fied in elsewhere?

 

No.  This was = just language that was cut-and-pasted in while writing the spec.  It&#= 8217;s been changed now, per your comment above.  Please review.<= /o:p>

 

20.2) Algorithm naming: Being new to the block, I= 'm trying to understand why we can't reuse an already well know identifier = for the algs.  (just picking on the first set of algs but this applies= to them all)

HMAC-SHA256 is pretty well understood so I'm wond= ering whether it is really worth saving five bytes over HS256?  Ditto = for RSAwithSHA* and ECDSAwithSHA*;  I guess you're saving more with th= ese, but I question whether it's really worth adding yet another way to name an alg.

 

This was a result o= f a consensus decision among the collaborators who jointly developed the JW= T spec, which was also publicly reviewed and confirmed shortly thereafter a= t the Internet Identity Workshop in November, 2010.  Given that some browsers have (short) URI length res= trictions and we wanted to be able to use JWTs in URI query parameters, kee= ping the representations compact was a core goal of the specification.=

 

20.3) Duplication identifiers (might partially go= away based on 20.2):

(just picking on the first set of algs but this a= pplies to them all) What are we going to do about duplicate identifiers?&nb= sp; Right now HMAC-SHA256, HMAC-SHA384, and HMAC-SHA512 are defined as well= as ECDSA/RSA with SHA-256, etc. in XMLDsig.  There's also some defined by RSA in RFC 4231.  Don't we need to say s= omething about preferring one over the other?

 

The registry and th= e use of collision resistant namespaces is intended to prevent collisions.<= o:p>

 

21) s4.1: Technically, for encryption RSA is RSAE= S-PKCS1-v1_5 or RSAES-OAEP so:

 

  | RSA1_5    | RSAES-PKCS1-1= .5 [RFC3447]          &nb= sp;            =       |

  | RSA-OAEP  | RSAES-Optimal Asymmetri= c Encryption Padding (OAEP)    |

  |       &nbs= p;   | (OAEP) [RFC3447]      &= nbsp;           &nbs= p;            &= nbsp;      |

 

Done

 

Actually you can replace: ", as defined in [= XXXX]" in the tables in s4.1 and s4.2 with "[XXXX]" - just t= o make it less wordy.  And you only need to expand AES, CBC, and GCM o= nce ;)

 

Done and done<= /o:p>

 

22) s4.1: Need to add ECDH-ES with different curv= es.  If you're going to allow ECDSA P-521, then matching it with ECDH-= ES P-521 makes sense.

 

Are there specific = additional curve/hash function combinations that you’d like to make t= he case to the working group to add?  The current set was motivated by= the choices in NIST Suite B.

 

23) s4.1/s4.6: Err...I don't think you should set= OtherInfo to zero!? If we're using s5.8.1 then at a minimum it's Algorithm= ID || PartyUInfo || PartyVInfo.

 

It's not clear to m= e what additional value these parameters add in our usage of the algorithm.=   If we believe that the randomly generated ephemeral key is undetermi= nable by an attacker (a requirement for any security at all!) then adding a constant AlgorithmID to the computation I = don't believe changes the security properties.  (That being said, we *= could* use the “alg” value "ECDH-ES" as the Algorithm= ID if people felt better about doing this.)

 

Also given that the= text now says (per a comment of Jim's) that "A new epk (ephemeral pub= lic key) value MUST be generated for each key agreement transaction", = it's not clear that adding parameters identifying the participating parties adds any security value either.  That being= said, I'd be glad to learn why I'm wrong.

 

If there are good s= ecurity reasons for requiring PartyUInfo and PartyVInfo values, do you have= suggestions on how to create acceptable values without carrying more param= eters in the header?  (I've already suggested that we could use the alg value "ECDH-ES" as the Algor= ithmID, which wouldn't require more parameters.)

 

For instance, I don= 't want to blindly follow XML ENC's lead and punt the issue by requiring th= at conforming uses provide explicit PartyUInfo and PartyVInfo values.<= /o:p>

 

Finally, I'll note = that the KDF function used by TLS http://tool= s.ietf.org/html/rfc5246#section-5 uses no= party parameters.  Why do we need them then?

 

24) s4.2: Some folks like AES-CCM - worth adding?=

 

This could be added= if the WG wants to.  I’d want us to look at how widely deployed= it is when determining whether it should be any more than OPTIONAL.

 

25) s4.2: r/RSA-PKCS1-1.5/RSAES-PKCS1-v1_5

 

Done

 

26) s4.2: Seems like we should pair up 128 kw/cbc= and 256 kw/cbc.  When you pick a set of algs they ought to be matched= .

 

Added this to the S= ecurity Considerations:

 

   &= nbsp;            Alg= orithms of matching strength should be used together whenever possible.

   &= nbsp;            For= instance, when AES Key Wrap is used with a given key size,

   &= nbsp;            usi= ng the same key size for AES CBC or GCM is recommended.

   &= nbsp;            Lik= ewise, when AES CBC is used with a 128 bit key, using HMAC SHA-256

   &= nbsp;            as = the integrity algorithm is recommended, whereas when

   &= nbsp;            AES= CBC is used with a 256 bit key, using HMAC SHA-512

   &= nbsp;            as = the integrity algorithm is recommended.

 

27) s4.3: r//>/

 

Done

 

28) s4.3: I think this is a cut/paste error:=

 

    r/It is RECOMMENDED that<= /o:p>

    implementations also support t= he RSA SHA-256 and ECDSA P-256 SHA-256

    algorithms./It is RECOMMENDED = that

    implementations also support t= he HMAC SHA-256 and HMAC SHA-384

    algorithms.

 

Replaced by the tab= le values

 

29) s4.3: (no action required) Curious that plain= old SHA-* isn't used here.  I guess I'll figure out why when I get to= the other specs.

 

It’s because = the integrity calculation uses a key – the Content Integrity Key (CIK= )

 

30) s4.4: r/RSA using RSA-PKCS1-1.5 padding, as d= efined in RFC 3447

[RFC3447]/RSAES-PKCS1-v1_5 [RFC3447]

 

Done

 

31) s4.5: r/RSA using Optimal Asymmetric Encrypti= on Padding (OAEP), as defined in RFC 3447 [RFC3447]/RSAES-OAEP [RFC3447]

 

Done

 

32) s4.5: Way underspecified - SHA1 is the defaul= t hash alg in 3447 - need to profile the values in 3447.

 

Now specifies use o= f default parameters, as this is the version of OAEP that is most widely de= ployed, per my response to Jim’s comment.  Other “alg̶= 1; values could be defined for OAEP with different parameters if people believe it’s useful and those parameter combinations are w= idely enough available.

 

33) s4.6: EC key size again - why isn't it 256-bi= t? And which key are we talking about?

 

Removed, as per com= ment 15

 

34) s4.7: Need to specify a MTI.  If you lin= k it to the key size of the key being wrapped then it's easy: 128 key being= wrapped MUST use 128 key to wrap, 256 ...

 

MTI now specified i= n “Implementation Requirements” column.  Also, see my resp= onse to #26.

 

35) s5.2.1: We've got a bunch of ways to name the= curve :(  I think you have to say the curves are as defined in the DS= S.  Brainpool has curves that also use some similar p256, p384, etc.

 

Done

 

36) s5.3: If you're going to use RSAES-OAEP or RS= ASSA-PSS there's a whole bunch more parameters that can be included (see RF= C 4055).  Are they not going to be used?

 

See my response to = #32

 

37) s5.3.2: Should we specifying that e=3D65537 m= ust be used?

 

I’ve added th= is to the Security Considerations:

 

   &= nbsp;            Key= s used with RSAES-PKCS1-v1_5 must follow the constraints in

   &= nbsp;            Sec= tion 7.2 of <xref target=3D"RFC3447"/>.  In particular= , keys with

   &= nbsp;            a l= ow public key exponent value must not be used.

 

38) s7: Because you're starting from scratch you'= re going to need to greatly expand this section.  However, you can avo= id a lot of this by listing all the references for the algs used in this sp= ec and say that the security considerations from those reference apply.

 

Done – refere= ncing DSS names

 

Need to say that the key size/hash alg combo shou= ld be matched.  Some might find SP800-57 Part 1 useful.

 

See my answer to #2= 6

 

Need to explain that really large keys can be a D= OS.  Some text you might massage:

 

Receiving agents that validate signatures and sen= ding agents that

  encrypt messages need to be cautious of cr= yptographic processing

  usage when validating signatures and encry= pting messages using keys

  larger than those mandated in this specifi= cation.  An attacker could

  send certificates with keys that would res= ult in excessive

  cryptographic processing, for example, key= s larger than those

  mandated in this specification, which coul= d swamp the processing

  element.  Agents that use such keys w= ithout first validating the

  certificate to a trust anchor are advised = to have some sort of

  cryptographic resource management system t= o prevent such attacks.

 

Thanks – inco= rporated

 

Some other motherhood and apple pie that you migh= t also include:

 

  All of the security issues faced by any cr= yptographic application

  must be faced by a JWS/JWE agent.  Am= ong these issues are protecting

  the user's private key, preventing various= attacks, and helping the

  user avoid mistakes such as inadvertently = encrypting a message for

  the wrong recipient.  The entire list= of security considerations is

  beyond the scope of this document, but som= e significant concerns are

  listed here.

 

Thanks – inco= rporated

 

spt

_______________________________________________

jose mailing list

jose@ietf.org

https://www.iet= f.org/mailman/listinfo/jose

 

--_000_4E1F6AAD24975D4BA5B168042967394366579FF6TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Fri Jul 6 11:00:41 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF67E21F86D8 for ; Fri, 6 Jul 2012 11:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=-1.292, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_SAVELE=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+7Y9LuNMuRo for ; Fri, 6 Jul 2012 11:00:37 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 6C48621F86C2 for ; Fri, 6 Jul 2012 11:00:37 -0700 (PDT) Received: from mail129-co1-R.bigfish.com (10.243.78.236) by CO1EHSOBE009.bigfish.com (10.243.66.72) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Jul 2012 17:58:45 +0000 Received: from mail129-co1 (localhost [127.0.0.1]) by mail129-co1-R.bigfish.com (Postfix) with ESMTP id 8B49F80347; Fri, 6 Jul 2012 17:58:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VS-26(zz9371Ic85fh542Mzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail129-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail129-co1 (localhost.localdomain [127.0.0.1]) by mail129-co1 (MessageSwitch) id 1341597523500578_3403; Fri, 6 Jul 2012 17:58:43 +0000 (UTC) Received: from CO1EHSMHS023.bigfish.com (unknown [10.243.78.227]) by mail129-co1.bigfish.com (Postfix) with ESMTP id 786389C004C; Fri, 6 Jul 2012 17:58:43 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS023.bigfish.com (10.243.66.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Jul 2012 17:58:43 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0309.003; Fri, 6 Jul 2012 18:00:50 +0000 From: Mike Jones To: Sean Turner , "jose@ietf.org" Thread-Topic: [jose] I-D Action: draft-ietf-jose-json-web-encryption-02.txt Thread-Index: Ac1boTn1EW43t3LmTm2bj2wPf/b6gA== Date: Fri, 6 Jul 2012 18:00:50 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436657A039@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436657A039TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-02.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 18:00:41 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436657A039TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks once again for the detailed read, Sean. Responses inline... -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Sean Turn= er Sent: Monday, May 28, 2012 10:36 AM To: jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-02.txt Here are some comments: 1) s2 & Requirements Language: The RFC editor is going to move the Requirem= ents Language section later on so you might as well save them the trouble a= nd just make it part of s2. Done 2) General: Don't you also need to point to the JWK spec in the abstract/in= tro for the key formats? I guess I could go either way on this one. Done 3) s3: This is probably a style thing but I'd move the example after discus= sing the actual format. It'll stop people from asking for this or that to = be defined/referenced in the example section. Yes, it's a style thing. In my experience, developers grok things quicker = if they have an example to start their brains down the right paths. Hence,= the current order. 3) throughout: r/RSA-PKCS1_1.5/RSAES-PKCS1-1.5 Replaced with RSAES-PKCS1-V1_5 4) s3.1/3.2: If we up the IV to 128 in json-web-algorithms, then this shoul= d be updated too. Examples replaced with real ones :-) 5) s3.1: Is this a JWK Set or just a JWK? It was a set, but it's no longer in the example. 6) s4: Contains the following: The Header Parameter Names within this object MUST be unique; JWEs with duplicate Header Parameter Names MUST be rejected. I'd prefer to see that if this is actually enforceable (not sure it is) tha= t an error gets thrown or the message gets rejected. I agree that this needs to be enforced. Section 2.2 of http://tools.ietf.o= rg/html/rfc4627 says "The names within an object SHOULD be unique." So thi= s should be enforced by conforming parsers. I'd be interested in data sayi= ng that parsers exist that are non-conforming to this RFC 4627 "SHOULD". I= f so, we should add appropriate warnings to the Security Considerations sec= tion. 7) s4: How are the different types of parameters (res,pub,priv) named? Is there going to be some kind of designator in front of them? If so, then= I would definitely try to get an early review from some Apps folks because= they're deprecating X-. All the current reserved parameters have names not containing a collision r= esistant namespace and are reserved in the IANA registry. Public names eit= her must contain a collision resistant namespace, such as a URL, OID, or GU= ID, or be registered. Private names are the wild west, to be used only bet= ween consenting adults. 8) s4.1.1-s4.1.3: Same concerns about the registry setup as the other docs. See my response to the related comment in the JWA doc 9) s4.1.1/s4.1.2: contains the following: The processing of the "alg/enc" header parameter requires that the value MUST be one that is both supported .. Not sure what this means? Hopefully clarified. Now says: The algorithm specified by the "alg" value= MUST be supported by the implementation and there MUST be a key for use wi= th that algorithm associated with the intended recipient or the JWE MUST be= rejected. 10) s4.1.?: Isn't there a requirement that either the key be included or a = reference to the key be included? Which one is MTI? Neither. They could have been exchanged out of band. 11) s4.1.7/s4.1.9: add normative reference to [RFC3986] for absolute URL. = And I think they call it a URI. Done 12) s4.1.8: Add reference to RFC5280: X.509 public key certificate or certi= ficate chain [RFC5280] Done 13) s4.1.8: Ack! PEM. Replace the reference to PEM with RFC 4648 and point= er to s4. The formulation you suggest is incomplete because it doesn't include the --= ---BEGIN CERTIFICATE----- / -----END CERTIFICATE----- annotations that PEM= uses to delimit the certificates in the certificate chain. Are you OK lea= ving this as-is, or do you want to suggest different wording? See the exam= ple at http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-03#app= endix-B that's intended to make the format crystal clear. 14) s4.1.8: I think you need to specify what first means. Network byte ord= er. I'm confused about this one. Are you talking about the "first certificate"= in 4.1.9? I don't think network byte order applies here. 15) s4.1.11: r/base64-encoded (not base64url encoded)/base64-encoded, [RFC4= 648] Section 4 (not base64url encoded), Done 16) s4.1.11: let's just do DER: r/DER/BER/DER [X.690] Done and add the following normative reference [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). Done or: r/DER/BER PKIX certificate value/PKIX certificate value [RFC5280]. 17) s7: Same concern I had in web-algorithms about OtherInfo being zero. Essentially the same response, since we're requiring generation of a random= Content Master Key (CMK). Note that we are using Label values of "Encrypt= ion" and "Integrity" to differentiate these cases. 18) s7: If the kid and thumbprints are not supposed to be generated in a wa= y to make them unique it's worth pointing this out in s7. I might suggest = something along the lines of: While hash algorithms provide collision resistance, this property is not needed for key identifiers or thumbprints. I'm confused by this comment as well. Section 7 (Key Derivation) doesn't h= ave much to do with the Key ID or X.509 Thumbprint parameters. That being = said, I did clarify that the "kid" value need not be unique. 19) s11.1: encoding considerations: isn't it base64url encoded? Added: Encoding considerations: JWE values are enc= oded as a series of base64url encoded values (some of= which may be the empty string) separated by period ('.') cha= racters applications that use this media type: is it just OpenId connec= t or can this be generalized a bit? Now says "OpenID Connect and other applications using encrypted JWTs". To = be clear, the JWS spec stabilized first and so JWS adoption is ahead of JWE= adoption at the moment. More applications to come... :-) spt _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B16804296739436657A039TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks once again f= or the detailed read, Sean.  Responses inline...

 

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Sean Turner
Sent: Monday, May 28, 2012 10:36 AM
To: jose@ietf.org
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-02.txt<= o:p>

 

Here are some comments:

 

1) s2 & Requirements Language: The RFC editor= is going to move the Requirements Language section later on so you might a= s well save them the trouble and just make it part of s2.

 

Done

 

2) General: Don't you also need to point to the J= WK spec in the abstract/intro for the key formats?  I guess I could go= either way on this one.

 

Done

 

3) s3: This is probably a style thing but I'd mov= e the example after discussing the actual format.  It'll stop people f= rom asking for this or that to be defined/referenced in the example section= .

 

Yes, it’s a s= tyle thing.  In my experience, developers grok things quicker if they = have an example to start their brains down the right paths.  Hence, th= e current order.

 

3) throughout: r/RSA-PKCS1_1.5/RSAES-PKCS1-1.5

 

Replaced with RSAES= -PKCS1-V1_5

 

4) s3.1/3.2: If we up the IV to 128 in json-web-a= lgorithms, then this should be updated too.

 

Examples replaced w= ith real ones :-)

 

5) s3.1: Is this a JWK Set or just a JWK?

 

It was a set, but i= t’s no longer in the example.

 

6) s4: Contains the following:

 

  The Header Parameter Names within this obj= ect

  MUST be unique; JWEs with duplicate Header= Parameter Names MUST be

  rejected.

 

I'd prefer to see that if this is actually enforc= eable (not sure it is) that an error gets thrown or the message gets reject= ed.

 

I agree that this n= eeds to be enforced.  Section 2.2 of http://tools.ietf.org= /html/rfc4627 says “The names within an object SHOULD be u= nique.”  So this should be enforced by conforming parsers.  I’d be interest= ed in data saying that parsers exist that are non-conforming to this RFC 46= 27 “SHOULD”.  If so, we should add appropriate warnings to= the Security Considerations section.

 

7) s4: How are the different types of parameters = (res,pub,priv) named?

Is there going to be some kind of designator in f= ront of them?  If so, then I would definitely try to get an early revi= ew from some Apps folks because they're deprecating X-.

 

All the current res= erved parameters have names not containing a collision resistant namespace = and are reserved in the IANA registry.  Public names either must conta= in a collision resistant namespace, such as a URL, OID, or GUID, or be registered.  Private names are the wild= west, to be used only between consenting adults.

 

8) s4.1.1-s4.1.3: Same concerns about the registr= y setup as the other docs.

 

See my response to = the related comment in the JWA doc

 

9) s4.1.1/s4.1.2: contains the following:

 

  The processing of the "alg/enc" = header parameter requires that

  the value MUST be one that is both support= ed ..

 

Not sure what this means?

 

Hopefully clarified= .  Now says:  The algorithm specified by the “alg” va= lue MUST be supported by the implementation and there MUST be a key for use= with that algorithm associated with the intended recipient or the JWE MUST be rejected.

 

10) s4.1.?: Isn't there a requirement that either= the key be included or a reference to the key be included?  Which one= is MTI?

 

Neither.  They= could have been exchanged out of band.

 

11) s4.1.7/s4.1.9: add normative reference to [RF= C3986] for absolute URL.  And I think they call it a URI.

 

Done

 

12) s4.1.8: Add reference to RFC5280: X.509 publi= c key certificate or certificate chain [RFC5280]

 

Done

 

13) s4.1.8: Ack! PEM.  Replace the reference= to PEM with RFC 4648 and pointer to s4.

 

The formulation you= suggest is incomplete because it doesn’t include the -----BEGIN CERT= IFICATE----- /  -----END CERTIFICATE----- annotations that PEM uses to= delimit the certificates in the certificate chain.  Are you OK leaving this as-is, or do you want to suggest different wording= ?  See the example at http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-03#appendix-B= that’s intended to make the format crystal clear.

 

14) s4.1.8: I think you need to specify what firs= t means.  Network byte order.

 

I’m confused = about this one.  Are you talking about the “first certificate= 221; in 4.1.9?  I don’t think network byte order applies here.

 

15) s4.1.11: r/base64-encoded (not base64url enco= ded)/base64-encoded, [RFC4648] Section 4 (not base64url encoded),

 

Done

 

16) s4.1.11: let's just do DER: r/DER/BER/DER [X.= 690]

 

Done

 

and add the following normative reference

 

   [X.690]  ITU-T Recommendation X= .690 (2002) | ISO/IEC 8825-1:2002,

        &= nbsp;   Information technology - ASN.1 encoding rules:=

        &= nbsp;   Specification of Basic Encoding Rules (BER), Canonical

        &= nbsp;   Encoding Rules (CER) and Distinguished Encoding Rules

        &= nbsp;   (DER).

 

Done

 

or: r/DER/BER PKIX certificate value/PKIX certifi= cate value [RFC5280].

 

17) s7: Same concern I had in web-algorithms abou= t OtherInfo being zero.

 

Essentially the sam= e response, since we’re requiring generation of a random Content Mast= er Key (CMK).  Note that we are using Label values of “Encryptio= n” and “Integrity” to differentiate these cases.

 

18) s7: If the kid and thumbprints are not suppos= ed to be generated in a way to make them unique it's worth pointing this ou= t in s7.  I might suggest something along the lines of:

 

   While hash algorithms provide collis= ion resistance, this property

   is not needed for key identifiers or= thumbprints.

 

I’m confused = by this comment as well.  Section 7 (Key Derivation) doesn’t hav= e much to do with the Key ID or X.509 Thumbprint parameters.  That bei= ng said, I did clarify that the “kid” value need not be unique.=

 

19) s11.1: encoding considerations: isn't it base= 64url encoded?

 

Added:

   &= nbsp;           &nbs= p;            &= nbsp;   Encoding considerations: JWE values are encoded as a=

   &= nbsp;           &nbs= p;            &= nbsp;   series of base64url encoded values (some of which may be = the

   &= nbsp;           &nbs= p;            &= nbsp;   empty string) separated by period ('.') characters

 

        &= nbsp;   applications that use this media type: is it just OpenId = connect or can this be generalized a bit?

 

Now says “Ope= nID Connect and other applications using encrypted JWTs”.  To be= clear, the JWS spec stabilized first and so JWS adoption is ahead of JWE a= doption at the moment.  More applications to come… :-)

 

spt

 

_______________________________________________

jose mailing list

jose@ietf.org

https://www.iet= f.org/mailman/listinfo/jose

 

--_000_4E1F6AAD24975D4BA5B16804296739436657A039TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Fri Jul 6 11:02:37 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0B021F86E0 for ; Fri, 6 Jul 2012 11:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.721 X-Spam-Level: X-Spam-Status: No, score=-3.721 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOiUI26AbWwC for ; Fri, 6 Jul 2012 11:02:35 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0851921F86E5 for ; Fri, 6 Jul 2012 11:02:34 -0700 (PDT) Received: from mail76-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Jul 2012 18:00:38 +0000 Received: from mail76-va3 (localhost [127.0.0.1]) by mail76-va3-R.bigfish.com (Postfix) with ESMTP id A6C73200375; Fri, 6 Jul 2012 18:00:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VS-27(zz9371Ic85fh542M111aIzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail76-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail76-va3 (localhost.localdomain [127.0.0.1]) by mail76-va3 (MessageSwitch) id 1341597635600304_3713; Fri, 6 Jul 2012 18:00:35 +0000 (UTC) Received: from VA3EHSMHS012.bigfish.com (unknown [10.7.14.253]) by mail76-va3.bigfish.com (Postfix) with ESMTP id 85284100126; Fri, 6 Jul 2012 18:00:35 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS012.bigfish.com (10.7.99.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Jul 2012 18:00:33 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0309.003; Fri, 6 Jul 2012 18:02:38 +0000 From: Mike Jones To: Sean Turner , "jose@ietf.org" Thread-Topic: [jose] I-D Action: draft-ietf-jose-json-web-signature-02.txt Thread-Index: Ac1boYIc2GQq6CGDQQGFcZ99MzZ2hQ== Date: Fri, 6 Jul 2012 18:02:37 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436657A064@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436657A064TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-signature-02.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 18:02:37 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436657A064TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks again. Responses inline... -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Sean Turn= er Sent: Monday, May 28, 2012 10:36 AM To: jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-signature-02.txt Here are some comments on the draft (a lot of these are duplicates from web-encryption): 1) s2 & Requirements Language: The RFC editor is going to move the Requirem= ents Language section later on so you might as well save them the trouble a= nd just make it part of s2. Done 2) s3: This is probably a style thing, but I think it's probably better to = talk about the structure first and then provide an example. It's just goin= g to make everybody ask you to define/explain x in that section. See JWE response 3) s4: Contains the following: The Header Parameter Names within this object MUST be unique; JWEs with duplicate Header Parameter Names MUST be rejected. I'd prefer to see that if this is actually enforceable (not sure it is) tha= t an error gets thrown or the message gets rejected. See JWE response Also just checking that this means you can only send one signature type per= object. That is you can't send one JSON object that is signed with both R= SA and ECDSA? See draft-jones-json-web-signature-json-serialization for multi-signature c= apability 4) s4: How are the different types of parameters (res,pub,priv) named? Is there going to be some kind of designator in front of them? If so, then= I would definitely try to get an early review from some Apps folks because= they're deprecating X-. See JWE response 5) s4.1/4.1.1: Same concerns about the registry setup as the other docs. See JWE response 6) s4.1.2/s4.1.4: Add normative reference to [RFC3986] for absolute URL. And I think they call it a URI. Done 7) s4.1.4: Add reference to RFC5280: X.509 public key certificate or certif= icate chain [RFC5280] Done 8) s4.1.4: Ack! PEM. Replace the reference to PEM with RFC 4648 and pointe= r to s4. See JWE response 9) s4.1.6: let's just do DER: r/DER/BER/DER [X.690] Done and add the following normative reference [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). Done or: r/DER/BER PKIX certificate value/PKIX certificate value [RFC5280]. 10) s7: If the kid and thumbprints are not supposed to be generated in a wa= y to make them unique it's worth pointing this out in s7. I might suggest = something along the lines of: While hash algorithms provide collision resistance, this property is not needed for key identifiers or thumbprints. I'm just as confused here as for your equivalent comment in JWE. Section 7= is the IANA Considerations. Try again??? 11) s11.1: encoding considerations: isn't it base64url encoded? Same text used as JWE applications that use this media type: is it just OpenId connec= t or can this be generalized a bit? Now reads: OpenID Connect, Mozilla Browser ID, Salesforce, Google, numerou= s others that use signed JWTs spt _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B16804296739436657A064TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks again. = Responses inline...

 

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Sean Turner
Sent: Monday, May 28, 2012 10:36 AM
To: jose@ietf.org
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-signature-02.txt

 

Here are some comments on the draft (a lot of the= se are duplicates from

web-encryption):

 

1) s2 & Requirements Language: The RFC editor= is going to move the Requirements Language section later on so you might a= s well save them the trouble and just make it part of s2.

 

Done

 

2) s3: This is probably a style thing, but I thin= k it's probably better to talk about the structure first and then provide a= n example.  It's just going to make everybody ask you to define/explai= n x in that section.

 

See JWE response

 

3) s4: Contains the following:

 

  The Header Parameter Names within this obj= ect

  MUST be unique; JWEs with duplicate Header= Parameter Names MUST be

  rejected.

 

I'd prefer to see that if this is actually enforc= eable (not sure it is) that an error gets thrown or the message gets reject= ed.

 

See JWE response

 

Also just checking that this means you can only s= end one signature type per object.  That is you can't send one JSON ob= ject that is signed with both RSA and ECDSA?

 

See draft-jones-jso= n-web-signature-json-serialization for multi-signature capability

 

4) s4: How are the different types of parameters = (res,pub,priv) named?

Is there going to be some kind of designator in f= ront of them?  If so, then I would definitely try to get an early revi= ew from some Apps folks because they're deprecating X-.

 

See JWE response

 

5) s4.1/4.1.1: Same concerns about the registry s= etup as the other docs.

 

See JWE response

 

6) s4.1.2/s4.1.4: Add normative reference to [RFC= 3986] for absolute URL.

  And I think they call it a URI.<= /o:p>

 

Done

 

7) s4.1.4: Add reference to RFC5280: X.509 public= key certificate or certificate chain [RFC5280]

 

Done

 

8) s4.1.4: Ack! PEM.  Replace the reference = to PEM with RFC 4648 and pointer to s4.

 

See JWE response

 

9) s4.1.6: let's just do DER: r/DER/BER/DER [X.69= 0]

 

Done

 

and add the following normative reference

 

   [X.690]  ITU-T Recommendation X= .690 (2002) | ISO/IEC 8825-1:2002,

        &= nbsp;   Information technology - ASN.1 encoding rules:=

        &= nbsp;   Specification of Basic Encoding Rules (BER), Canonical

        &= nbsp;   Encoding Rules (CER) and Distinguished Encoding Rules

        &= nbsp;   (DER).

 

Done

 

or: r/DER/BER PKIX certificate value/PKIX certifi= cate value [RFC5280].

 

10) s7: If the kid and thumbprints are not suppos= ed to be generated in a way to make them unique it's worth pointing this ou= t in s7.  I might suggest something along the lines of:

 

   While hash algorithms provide collis= ion resistance, this property

   is not needed for key identifiers or= thumbprints.

 

I’m just as c= onfused here as for your equivalent comment in JWE.  Section 7 is the = IANA Considerations.  Try again???

 

11) s11.1: encoding considerations: isn't it base= 64url encoded?

 

Same text used as J= WE

 

        &= nbsp;   applications that use this media type: is it just OpenId = connect or can this be generalized a bit?

 

Now reads:  Op= enID Connect, Mozilla Browser ID, Salesforce, Google, numerous others that = use signed JWTs

 

spt

_______________________________________________

jose mailing list

jose@ietf.org

https://www.iet= f.org/mailman/listinfo/jose

 

--_000_4E1F6AAD24975D4BA5B16804296739436657A064TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Fri Jul 6 11:13:28 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B3B21F859B for ; Fri, 6 Jul 2012 11:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.719 X-Spam-Level: X-Spam-Status: No, score=-3.719 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7Ae17o4+Bwy for ; Fri, 6 Jul 2012 11:13:21 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id E870221F859A for ; Fri, 6 Jul 2012 11:13:19 -0700 (PDT) Received: from mail45-db3-R.bigfish.com (10.3.81.225) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Jul 2012 18:11:27 +0000 Received: from mail45-db3 (localhost [127.0.0.1]) by mail45-db3-R.bigfish.com (Postfix) with ESMTP id CF3F64C04EE; Fri, 6 Jul 2012 18:11:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VS-26(zz9371Ic85fh542Mzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail45-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail45-db3 (localhost.localdomain [127.0.0.1]) by mail45-db3 (MessageSwitch) id 1341598284659064_4262; Fri, 6 Jul 2012 18:11:24 +0000 (UTC) Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.241]) by mail45-db3.bigfish.com (Postfix) with ESMTP id 9EDF8360050; Fri, 6 Jul 2012 18:11:24 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Jul 2012 18:11:24 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0309.003; Fri, 6 Jul 2012 18:13:14 +0000 From: Mike Jones To: Jim Schaad , "jose@ietf.org" Thread-Topic: json-web-encryption -02 comments Thread-Index: Ac1bou6sddjZ9RUfROOHcwSTWeLOfg== Date: Fri, 6 Jul 2012 18:13:13 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436657A0E4@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436657A0E4TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] json-web-encryption -02 comments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 18:13:28 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436657A0E4TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks once again. Responses inline... -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Thursday, June 07, 2012 11:56 AM To: jose@ietf.org; draft-ietf-jose-json-web-encryption@tools.ietf.org Subject: json-web-encryption -02 comments Introduction 1. I would separate the introduction into two paragraphs. One to address = the general encryption issue and one to address the compact serialization i= ssues. This will allow for an easier addition/removal to deal with other s= erialization issues. I'm somewhat confused by this comment, as the introduction doesn't discuss = serialization. That concept isn't introduced until the "JWE Compact Serial= ization" term definition in Section 2 and the presentation of the compact s= erialization in Section 3. 2. I find sentence #2 confusing since this document is defining how to do = the encryption process so we are not really dealing with pre-encrypted cont= ent which is what this appears to me to say. Like JWS, this sentence has been clarified to: It represents this content = using JavaScript Object Notation (JSON) data str= uctures. 3. What do you mean by the type of content being encrypted? This could ei= ther mean the format of the content (i.e. JSON vs Mime) or the type of cont= ent (i.e. a JSON token vs a JSON signature object). This now reads: The JWE cryptographic mechanisms encrypt and provide integ= rity protection for arbitrary sequences of bytes. 4. I think a new paragraph should start with "Cryptographic algorithms..." this is a new topic. (What is not in this document.) Done Section 3 1. Simple clarity s/confidentiality of the contents of the Plaintext/confi= dentiality of the Plaintext/ Done Section 4 - JWE Header 1. Do we think parsers can enforce the uniqueness requirement? See my response in the JWK comments 2. What does it mean to reject a JWE? Should it decrypt and say it is a b= ad decrypt or should it fail to decrypt? It should return an error and return no decrypted data Section 4.1.1 1. You should be constant about what you call the encryption key, master = key or JWE Encrypted key. A search and replace should be done to make them= constant. Now using the term Content Master Key (CMK) here. Note that the Content En= cryption Key (CMK) is distinct from (and derived from) the CMK. 2. Refer to the registry not to the document for the list of algorithms. Moved the document reference to be adjacent to the registry reference, sayi= ng that both apply Section 4.1.2 1. See comment 2 above Ditto 2. the encryption algorithm is not used to secure the cipher text. It is = used to produce the cipher text Corrected 3. Why does the enc algorithm not require the existence of a key for it's = use? Because the CEK is derived from the CMK, and so always exists Section 4.1.4 1. (Curiosity question) Other than "size" is there a reason that an iv mus= t be base64url encoded? Interesting question. I'd say that this is because we can't assume the exi= stence of bignum libraries to convert between very large integers and the b= yte sequence, or that JSON parsers won't choke on very large integers. 2. The presence of this parameter MUST be specified for all content encryp= tion algorithms. It is, in JWA. Also clarified that it is REQUIRED with some "enc" algorith= ms. Section 4.1.5 1. See comment 2 above - alternate language would be say MUST be absent un= less otherwise specified by the algorithm. It is, in JWA. Also clarified that it is REQUIRED with some "alg" algorith= ms. 2. epk should talk about key agreement algorithms not a specific algorithm= . Done 3. Content of the key should be specified by the algorithm and not by this= document. Done Section 4.1.6 1. Should specify the use the "alg" registry for the zip parameter (in cas= e a new one comes into existence) and this algorithm should be registered a= s the only algorithm. This could be done, but it is counter to an explicit working group decision= to support only one compression algorithm. I'd be glad to do this if the = WG decides to open the door to the possibility of additional algorithms. Section 4.1.7 1. Should make clear that this is the way of identifying what private key = is needed to decrypt the content. Added: this can be used to determine the private key needed to decrypt the = JWE 2. Should this be used? It implies that the decryptor needs to do the following: a) Get the keys b) For each key - i) Do I have the private key for this? ii) Does it match the algorithm? iii) Does it work? c) if no function keys found then ---??? Also, the decryptor might use "kid" and/or "use" parameters for deciding wh= ich key(s) to use. Obviously, if no applicable key can be located, the dec= ryption will fail. Section 4.1.8 1. See comment 1 above. Ditto Section 4.1.9 1. I would eliminate the (implicit) requirement that the certificate be va= lidated before decryption. There is no reason that a client should not be = able to decrypt a message to themselves if their certificate has been revok= ed or is expired. This is just a requirement at send time. What do others in the working group think of potentially relaxing this requ= irement? If we do relax it, what alternative language should be used? Section 4.1.11 1. I don't understand the format used here. The data could be either enco= ded as a string or an array of strings or something else that is a concaten= ated string form. I've added an example to clarify this. See http://tools.ietf.org/html/draf= t-ietf-jose-json-web-signature-03#appendix-B 2. Why is this not base64url encoded given that all other locations are? So we're using a standard encoding for certificate chains 3. See comment 1 above Ditto Section 4.1.12 1. This is so underspecified that I would know how to go about using it. Any code that I wrote would therefore ignore it. Added: When used with a JWK, the "kid" value MAY be used to match a JWK= "kid" parameter value. Section 4.1.13 1. The list of possible typ values should apparently include the mime regi= stry as well. This is neither in the value registry (which should probably= be setup to avoid collisions with mime types) or a URI. See the new Section 7.2 in JWS Section 4.2 1. Should re-iterate the "if you don't know it then reject it" sentence he= re - it has been a long time since we have seen it. (Ditto for section 4.3) I understand why you're saying this, but we did say "Implementations MUST u= nderstand the entire contents of the header; otherwise, the JWE MUST be rej= ected" in the enclosing section introduction (Section 4), so I'm reluctant = to repeat it in 4.2 and especially reluctant to repeat it again so soon in = 4.3. Section 5 1. I disagree with the concept of using a key agree algorithm to create th= e CMK. Look at CMS to see how they handle key agree algorithms to create a key wrap key The key wrap key is unnecessary, as far as I can tell, at least when there'= s a single recipient. It results in an additional encryption step that see= ms to me to add no additional security. However, per James Manger's note and my response to it, I do understand tha= t value of having a CMK in the multiple recipients case. I've added this t= opic to the list of open issues for the working group to discuss. 2. In step 8 - when did you create the encoded JWE header? In step 9. :-) Yes, I'd already seen this and fixed it. 3. Separate the serialization format from the encryption algorithm. This = may just affect step 14. Done 4. Note previous discussion on only documenting AEAD algorithms I'm not sure what change you're asking for here? Section 6 1. Separate serialization from message decryption. If alternate serializa= tions are used then step 1 fails. Done 2. Note that you have imposed some additional restrictions on the JSE head= er in step three - specifically that no duplicate fields exist. This is no= t in the decryption process. It's input validation for the decryption process, just like step 2 was Section 7 1. If you are using the NIST KDF function, then the length of the output k= ey should really be included in the OtherInfo Again, per my earlier responses to you and Sean on this topic from your JWA= comments, since the CMK is randomly generated for each encryption, I belie= ve that the additional parameters add no security value. Adding a key leng= th would only make sense if we were going to use this same CMK to generate = other keys using the same Label ("Encryption" or "Integrity") but with a di= fferent key length. But we never will, so I believe that the parameter is = superfluous. Section 8.1 1. Refer to the registry not to the document (ditto for section 8.2) Done Section 11.1 1. Should there be an optional parameter which describes which serializati= on method is being used? This could be introduced if the working group adopts a second serialization= method, such as the JSON Serialization defined in draft-jones-json-web-enc= ryption-json-serialization, or one of the other candidates. However, a bet= ter approach might be to define a different media type value, such as appli= cation/jwe-js for the different serialization. Of course, if we have a pure JSON serialization, one could argue for just u= sing the application/json media type. 2. Check with IANA if you or the IESG should be listed under the contact s= ection. Will do --_000_4E1F6AAD24975D4BA5B16804296739436657A0E4TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks once again.&= nbsp; Responses inline…

 

-----Original Message-----
From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Thursday, June 07, 2012 11:56 AM
To: jose@ietf.org; draft-ietf-jose-json-web-encryption@tools.ietf.org
Subject: json-web-encryption -02 comments

 

Introduction

 

1.  I would separate the introduction into t= wo paragraphs.  One to address the general encryption issue and one to= address the compact serialization issues.  This will allow for an eas= ier addition/removal to deal with other serialization issues.

 

I’m somewhat = confused by this comment, as the introduction doesn’t discuss seriali= zation.  That concept isn’t introduced until the “JWE Comp= act Serialization” term definition in Section 2 and the presentation of the compact serialization in Section 3.

 

2.  I find sentence #2 confusing since this = document is defining how to do the encryption process so we are not really = dealing with pre-encrypted content which is what this appears to me to say.=

 

Like JWS, this sent= ence has been clarified to:  It represents this content using JavaScri= pt Object Notation (JSON) <xref target=3D"RFC4627"/> data s= tructures.

 

3.  What do you mean by the type of content = being encrypted?  This could either mean the format of the content (i.= e. JSON vs Mime) or the type of content (i.e. a JSON token vs a JSON signat= ure object).

 

This now reads:&nbs= p; The JWE cryptographic mechanisms encrypt and provide integrity protectio= n for arbitrary sequences of bytes.

 

4.  I think a new paragraph should start wit= h "Cryptographic algorithms..."

this is a new topic.  (What is not in this d= ocument.)

 

Done

 

Section 3

 

1.  Simple clarity s/confidentiality of the = contents of the Plaintext/confidentiality of the Plaintext/

 

Done

 

Section 4 - JWE Header

 

1.  Do we think parsers can enforce the uniq= ueness requirement?

 

See my response in = the JWK comments

 

2.  What does it mean to reject a JWE? = Should it decrypt and say it is a bad decrypt or should it fail to decrypt= ?

 

It should return an= error and return no decrypted data

 

Section 4.1.1

 

1.  You should be constant about what  = you call the encryption key, master key or JWE Encrypted key.  A searc= h and replace should be done to make them constant.

 

Now using the term = Content Master Key (CMK) here.  Note that the Content Encryption Key (= CMK) is distinct from (and derived from) the CMK.

 

2.  Refer to the registry not to the documen= t for the list of algorithms.

 

Moved the document = reference to be adjacent to the registry reference, saying that both apply<= o:p>

 

Section 4.1.2

 

1. See comment 2 above

 

Ditto

 

2.  the encryption algorithm is not used to = secure the cipher text.  It is used to produce the cipher text

 

Corrected

 

3.  Why does the enc algorithm not require t= he existence of a key for it's use?

 

Because the CEK is = derived from the CMK, and so always exists

 

Section 4.1.4

 

1.  (Curiosity question) Other than "si= ze" is there a reason that an iv must be base64url encoded?=

 

Interesting questio= n.  I’d say that this is because we can’t assume the exist= ence of bignum libraries to convert between very large integers and the byt= e sequence, or that JSON parsers won’t choke on very large integers.

 

2.  The presence of this parameter MUST be s= pecified for all content encryption algorithms.

 

It is, in JWA. = ; Also clarified that it is REQUIRED with some “enc” algorithms= .

 

Section 4.1.5

 

1.  See comment 2 above - alternate language= would be say MUST be absent unless otherwise specified by the algorithm.

 

It is, in JWA. = ; Also clarified that it is REQUIRED with some “alg” algorithms= .

 

2.  epk should talk about key agreement algo= rithms not a specific algorithm.

 

Done

 

3.  Content of the key should be specified b= y the algorithm and not by this document.

 

Done

 

Section 4.1.6

 

1.  Should specify the use the "alg&quo= t; registry for the zip parameter (in case a new one comes into existence) = and this algorithm should be registered as the only algorithm.

 

This could be done,= but it is counter to an explicit working group decision to support only on= e compression algorithm.  I’d be glad to do this if the WG decid= es to open the door to the possibility of additional algorithms.

 

Section 4.1.7

 

1.  Should make clear that this is the way o= f identifying what private key is needed to decrypt the content.=

 

Added: this can be = used to determine the private key needed to decrypt the JWE

 

2.  Should this be used?  It implies th= at the decryptor needs to do the

following:

a) Get the keys

b) For each key -

   i) Do I have the private key for thi= s?

   ii) Does it match the algorithm?

   iii) Does it work?

c) if no function keys found then ---???

 

Also, the decryptor= might use “kid” and/or “use” parameters for decidi= ng which key(s) to use.  Obviously, if no applicable key can be locate= d, the decryption will fail.

 

Section 4.1.8

 

1.  See comment 1 above.

 

Ditto

 

Section 4.1.9

 

1.  I would eliminate the (implicit) require= ment that the certificate be validated before decryption.  There is no= reason that a client should not be able to decrypt a message to themselves= if their certificate has been revoked or is expired.  This is just a requirement at send time.

 

What do others in t= he working group think of potentially relaxing this requirement?  If w= e do relax it, what alternative language should be used?<= /p>

 

Section 4.1.11

 

1.  I don't understand the format used here.=   The data could be either encoded as a string or an array of strings = or something else that is a concatenated string form.

 

I’ve added an= example to clarify this.  See http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-03#appendix-B=

 

2.  Why is this not base64url encoded given = that all other locations are?

 

So we’re usin= g a standard encoding for certificate chains

 

3. See comment 1 above

 

Ditto

 

Section 4.1.12

 

1.  This is so underspecified that I would k= now how to go about using it.

Any code that I wrote would therefore ignore it.<= o:p>

 

Added:   =   When used with a JWK, the “kid” value MAY be used to mat= ch a JWK “kid” parameter value.

 

Section 4.1.13

 

1.  The list of possible typ values should a= pparently include the mime registry as well.  This is neither in the v= alue registry (which should probably be setup to avoid collisions with mime= types) or a URI.

 

See the new Section= 7.2 in JWS

 

Section 4.2

 

1.  Should re-iterate the "if you don't= know it then reject it" sentence here - it has been a long time since= we have seen it.

 

(Ditto for section 4.3)

 

I understand why yo= u’re saying this, but we did say “Implementations MUST understa= nd the entire contents of the header; otherwise, the JWE MUST be rejected&#= 8221; in the enclosing section introduction (Section 4), so I’m reluctant to repeat it in 4.2 and especially reluctant to rep= eat it again so soon in 4.3.

 

Section 5

 

1.  I disagree with the concept of using a k= ey agree algorithm to create the

CMK.   Look at CMS to see how they hand= le key agree algorithms to create a

key wrap key

 

The key wrap key is= unnecessary, as far as I can tell, at least when there’s a single re= cipient.  It results in an additional encryption step that seems to me= to add no additional security.

 

However, per James = Manger’s note and my response to it, I do understand that value of ha= ving a CMK in the multiple recipients case.  I’ve added this top= ic to the list of open issues for the working group to discuss.

 

2.  In step 8 - when did you create the enco= ded JWE header?

 

In step 9. :-) = ; Yes, I’d already seen this and fixed it.

 

3.  Separate the serialization format from t= he encryption algorithm.  This may just affect step 14.

 

Done

 

4.  Note previous discussion on only documen= ting AEAD algorithms

 

I’m not sure = what change you’re asking for here?

 

Section 6

 

1.  Separate serialization from message decr= yption.  If alternate serializations are used then step 1 fails.<= /o:p>

 

Done

 

2.  Note that you have imposed some addition= al restrictions on the JSE header in step three - specifically that no dupl= icate fields exist.  This is not in the decryption process.=

 

It’s input va= lidation for the decryption process, just like step 2 was=

 

Section 7

 

1.  If you are using the NIST KDF function, = then the length of the output key should really be included in the OtherInf= o

 

Again, per my earli= er responses to you and Sean on this topic from your JWA comments, since th= e CMK is randomly generated for each encryption, I believe that the additio= nal parameters add no security value.  Adding a key length would only make sense if we were going to use this sam= e CMK to generate other keys using the same Label (“Encryption”= or “Integrity”) but with a different key length.  But we = never will, so I believe that the parameter is superfluous.

 

Section 8.1

 

1.  Refer to the registry not to the documen= t (ditto for section 8.2)

 

Done

 

Section 11.1

 

1.  Should there be an optional parameter wh= ich describes which serialization method is being used?

 

This could be intro= duced if the working group adopts a second serialization method, such as th= e JSON Serialization defined in draft-jones-json-web-encryption-json-serial= ization, or one of the other candidates.  However, a better approach might be to define a different media type value= , such as application/jwe-js for the different serialization.

 

Of course, if we ha= ve a pure JSON serialization, one could argue for just using the applicatio= n/json media type.

 

2.  Check with IANA if you or the IESG shoul= d be listed under the contact section.

 

Will do<= /span>

 

--_000_4E1F6AAD24975D4BA5B16804296739436657A0E4TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Fri Jul 6 11:19:43 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F17E11E808F for ; Fri, 6 Jul 2012 11:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[AWL=1.381, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wzcYDCJ8WF0 for ; Fri, 6 Jul 2012 11:19:41 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id B619C11E8079 for ; Fri, 6 Jul 2012 11:19:40 -0700 (PDT) Received: from mail19-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Jul 2012 18:17:49 +0000 Received: from mail19-va3 (localhost [127.0.0.1]) by mail19-va3-R.bigfish.com (Postfix) with ESMTP id C622960347; Fri, 6 Jul 2012 18:17:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VS-23(zz9371Ic85dh1432I1447Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail19-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail19-va3 (localhost.localdomain [127.0.0.1]) by mail19-va3 (MessageSwitch) id 1341598667367552_30986; Fri, 6 Jul 2012 18:17:47 +0000 (UTC) Received: from VA3EHSMHS045.bigfish.com (unknown [10.7.14.236]) by mail19-va3.bigfish.com (Postfix) with ESMTP id 4C833440049; Fri, 6 Jul 2012 18:17:47 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS045.bigfish.com (10.7.99.55) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Jul 2012 18:17:47 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0298.005; Fri, 6 Jul 2012 18:19:51 +0000 From: Mike Jones To: "Manger, James H" , "jose@ietf.org" Thread-Topic: "typ":"JWS" Thread-Index: Ac1bo+eR3uJ/e84/QIKtmQBKUu+SSw== Date: Fri, 6 Jul 2012 18:19:50 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436657A131@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436657A131TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] "typ":"JWS" X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 18:19:43 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436657A131TK5EX14MBXC283r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for the thought on this, James. In the -03 drafts there is now a clear distinction between "typ" (type) - i= nformation about this object and the new "cty" (content type) - information= about the secured object. Besides being semantically cleaner, this also s= implified nested JWTs. I then was able to make changes in the spirit of the ones you suggested bel= ow, although using slightly different wording in some cases. -- Mike From: Manger, James H [mailto:James.H.Manger@team.telstra.com] Sent: Tuesday, May 15, 2012 5:40 PM To: Mike Jones; jose@ietf.org Subject: RE: "typ":"JWS" >> draft-ietf-jose-json-web-signature-02 =A77.2 registers the "JWS" type va= lue (for the "typ" header field) >> ... >> Perhaps "typ":"JWS" is more useful in a JWE header when encrypting signe= d content (sign-then-encrypt). If this is the intention, then mentioning th= e "JWS" type value when defining the "typ" header for a JWS is misleading. = It would be better to mention it where the JWE spec defines "typ". >> ... > Your second paragraph correctly describes the intended usage. For instan= ce, see http://tools.ietf.org/html/draft-jones-json-web-token-10#section-5.= 1 for this usage in action. The value is registered per the working group = decision relating "typ" values to MIME types. Good. So let's say that. Suggested text changes: * draft-ietf-jose-json-web-signature-02, section 4.1.8 "typ" (Type) Header = Parameter: delete the 2nd sentence because signing a signature is not what = we are talking about (and JWS-JS recommends a different approach for multip= le signatures anyway). * section 7.1 Registration of application/jws MIME Media Type: add a phrase= explicitly stating the syntax (since the spec mentions two: compact, and J= WS JS) so the section says: This specification registers the "application/jws" MIME Media Type [RFC 2= 045] to identify content that uses the JWS compact serialization. * section 7.2 Registration of "JWS" Type Value: mention the intended use of= encrypting signed content by adding this sentence. The "typ" parameter can be set to "JWS" in a JSON Web Encryption [JWE] he= ader when encrypting signed content. * draft-ietf-jose-json-web-encryption-02, section 4.1.13 "typ" (Type) Heade= r Parameter, section 11.1 Registration of application/jwe MIME Media Type, = section 11.2 Registration of "JWE" type Value: make equivalent changes. -- James Manger --_000_4E1F6AAD24975D4BA5B16804296739436657A131TK5EX14MBXC283r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks for the thought= on this, James.

 

In the -03 drafts ther= e is now a clear distinction between “typ” (type) - information= about this object and the new “cty” (content type) – inf= ormation about the secured object.  Besides being semantically cleaner= , this also simplified nested JWTs.

 

I then was able to mak= e changes in the spirit of the ones you suggested below, although using sli= ghtly different wording in some cases.

 

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

 

From: Manger, = James H [mailto:James.H= .Manger@team.telstra.com]
Sent: Tuesday, May 15, 2012 5:40 PM
To: Mike Jones; jose@ietf.org Subject: RE: "typ":"JWS"

 

>>= ; draft-ietf-jose-json-web-signature-02 =A77.2 registers the “JWSR= 21; type value (for the “typ” header field)

>>= ; …

>>= ; Perhaps “typ”:”JWS” is more useful in a JWE heade= r when encrypting signed content (sign-then-encrypt). If this is the intent= ion, then mentioning the “JWS” type value when defining the = 220;typ” header for a JWS is misleading. It would be better to mention it where the JWE sp= ec defines “typ”.

>>= ; …

&n= bsp;

> Your second paragraph correctly describe= s the intended usage.  For instance, see http://tools.ietf.org/html/draft-jones-json-web-token-10#secti= on-5.1 for this usage in action.  Th= e value is registered per the working group decision relating “typ” values to MIME types.

&n= bsp;

Good. S= o let’s say that. Suggested text changes:

&n= bsp;

* draft= -ietf-jose-json-web-signature-02, section 4.1.8 “typ” (Type) He= ader Parameter: delete the 2nd sentence because signing a signature is not = what we are talking about (and JWS-JS recommends a different approach for multiple signatures anyway).

&n= bsp;

* secti= on 7.1 Registration of application/jws MIME Media Type: add a phrase explic= itly stating the syntax (since the spec mentions two: compact, and JWS JS) = so the section says:

  = This specification registers the "application/jws" MIME Media Typ= e [RFC 2045]

  = to identify content that uses the JWS compact serialization.

&n= bsp;

* secti= on 7.2 Registration of "JWS" Type Value: mention the intended use= of encrypting signed content by adding this sentence.

  = The “typ” parameter can be set to “JWS” in a JSON W= eb Encryption [JWE] header when encrypting signed content.

&n= bsp;

* draft= -ietf-jose-json-web-encryption-02, section 4.1.13 “typ” (Type) = Header Parameter, section 11.1 Registration of application/jwe MIME Media T= ype, section 11.2 Registration of “JWE” type Value: make equivalent changes.

&n= bsp;

--=

James M= anger

&n= bsp;

--_000_4E1F6AAD24975D4BA5B16804296739436657A131TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Fri Jul 6 11:20:29 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31AC011E808F for ; Fri, 6 Jul 2012 11:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.873 X-Spam-Level: X-Spam-Status: No, score=-3.873 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock9=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lm73qi8hz9AZ for ; Fri, 6 Jul 2012 11:20:27 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2B811E8079 for ; Fri, 6 Jul 2012 11:20:27 -0700 (PDT) Received: from mail44-tx2-R.bigfish.com (10.9.14.247) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Jul 2012 18:18:36 +0000 Received: from mail44-tx2 (localhost [127.0.0.1]) by mail44-tx2-R.bigfish.com (Postfix) with ESMTP id B5A973E02C4; Fri, 6 Jul 2012 18:18:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zz98dI9371I542M1432I111aIzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail44-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail44-tx2 (localhost.localdomain [127.0.0.1]) by mail44-tx2 (MessageSwitch) id 134159871322415_19947; Fri, 6 Jul 2012 18:18:33 +0000 (UTC) Received: from TX2EHSMHS042.bigfish.com (unknown [10.9.14.253]) by mail44-tx2.bigfish.com (Postfix) with ESMTP id EC263380046; Fri, 6 Jul 2012 18:18:32 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS042.bigfish.com (10.9.99.142) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Jul 2012 18:18:32 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0309.003; Fri, 6 Jul 2012 18:20:40 +0000 From: Mike Jones To: "'Richard L. Barnes'" Thread-Topic: [jose] Second compute JWE computation example Thread-Index: Ac1bpAQ9j/fYV68DSByk0M/19F8hcA== Date: Fri, 6 Jul 2012 18:20:39 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436657A162@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "'jose@ietf.org'" Subject: Re: [jose] Second compute JWE computation example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 18:20:29 -0000 This is now in the spec. Thanks again, -- Mike -----Original Message----- From: Mike Jones=20 Sent: Friday, June 29, 2012 10:48 AM To: Richard L. Barnes Cc: jose@ietf.org Subject: RE: [jose] Second compute JWE computation example Good catch. I'll add to the JWA spec that RSA-OAEP specifies the use of OA= EP padding with the default parameters defined by PKCS #1 v2.1 (RFC 3447) i= n Section A.2.1. -- Mike -----Original Message----- From: Richard L. Barnes [mailto:rbarnes@bbn.com] Sent: Friday, June 29, 2012 10:20 AM To: Mike Jones Cc: jose@ietf.org Subject: Re: [jose] Second compute JWE computation example This seems underspecified. What parameters are you using for OAEP? IIRC, = it requires a digest algorithm and a masking generation function. I don't = see either of those specified in JWS or JWA. On Jun 29, 2012, at 11:20 AM, Mike Jones wrote: > Dear working group members, > =20 > A second complete JWE computation example is included below. As I'd prev= iously written, I'm adding example encryption computations to the JWE spec = to aid implementers. These values have been verified by two independent im= plementations. > =20 > This example uses the header values: > {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} > =20 > This example verifies both the use of RSA-OAEP and the use of AES-GCM - i= ncluding the use of the Additional Authenticated Data parameter and the Aut= hentication Tag output. > =20 > Note that because the RSA-OAEP computation uses random values, the encryp= ted key computation will not be repeatable, although all resulting values w= ill be decryptable to retrieve the original key value. > =20 > I'd be interested in hearing results from any of you who also try this JW= E with your implementation. > =20 > Enjoy, > -- Mike > =20 > CMK (CEK) > [177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, 154,=20 > 212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, 122,=20 > 234, 64, 252] IV [227, 197, 117, 252, 2, 219, 233, 68, 180, 225, 77,=20 > 219] Plaintext [76, 105, 118, 101, 32, 108, 111, 110, 103, 32, 97,=20 > 110, 100, 32, 112, 114, 111, 115, 112, 101, 114, 46] Header=20 > {"alg":"RSA-OAEP","enc":"A256GCM","iv":"48V1_ALb6US04U3b"} > Header Bytes > [123, 34, 97, 108, 103, 34, 58, 34, 82, 83, 65, 45, 79, 65, 69, 80,=20 > 34, 44, 34, 101, 110, 99, 34, 58, 34, 65, 50, 53, 54, 71, 67, 77, 34,=20 > 44, 34, 105, 118, 34, 58, 34, 52, 56, 86, 49, 95, 65, 76, 98, 54, 85,=20 > 83, 48, 52, 85, 51, 98, 34, 125] Encoded Header=20 > eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTMD > RVM2IifQ > BEGIN RSA KEY PARAMETERS > Exponent > [1, 0, 1] > Modulus > [161, 168, 84, 34, 133, 176, 208, 173, 46, 176, 163, 110, 57, 30, 135,=20 > 227, 9, 31, 226, 128, 84, 92, 116, 241, 70, 248, 27, 227, 193, 62, 5,=20 > 91, 241, 145, 224, 205, 141, 176, 184, 133, 239, 43, 81, 103, 9, 161,=20 > 153, 157, 179, 104, 123, 51, 189, 34, 152, 69, 97, 69, 78, 93, 140,=20 > 131, 87, 182, 169, 101, 92, 142, 3, 22, 167, 8, 212, 56, 35, 79, 210,=20 > 222, 192, 208, 252, 49, 109, 138, 173, 253, 210, 166, 201, 63, 102,=20 > 74, 5, 158, 41, 90, 144, 108, 160, 79, 10, 89, 222, 231, 172, 31, 227,=20 > 197, 0, 19, 72, 81, 138, 78, 136, 221, 121, 118, 196, 17, 146, 10,=20 > 244, 188, 72, 113, 55, 221, 162, 217, 171, 27, 57, 233, 210, 101, 236,=20 > 154, 199, 56, 138, 239, 101, 48, 198, 186, 202, 160, 76, 111, 234, 71,=20 > 57, 183, 5, 211, 171, 136, 126, 64, 40, 75, 58, 89, 244, 254, 107, 84,=20 > 103, 7, 236, 69, 163, 18, 180, 251, 58, 153, 46, 151, 174, 12, 103,=20 > 197, 181, 161, 162, 55, 250, 235, 123, 110, 17, 11, 158, 24, 47, 133,=20 > 8, 199, 235, 107, 126, 130, 246, 73, 195, 20, 108, 202, 176, 214, 187,=20 > 45, 146, 182, 118, 54, 32, 200, 61, 201, 71, 243, 1, 255, 131, 84, 37,=20 > 111, 211, 168, 228, 45, 192, 118, 27, 197, 235, 232, 36, 10, 230, 248,=20 > 190, 82, 182, 140, 35, 204, 108, 190, 253, 186, 186, 27] D (private=20 > key exponent) [144, 183, 109, 34, 62, 134, 108, 57, 44, 252, 10, 66,=20 > 73, 54, 16, 181, 233, 92, 54, 219, 101, 42, 35, 178, 63, 51, 43, 92,=20 > 119, 136, 251, 41, 53, 23, 191, 164, 164, 60, 88, 227, 229, 152, 228,=20 > 213, 149, 228, 169, 237, 104, 71, 151, 75, 88, 252, 216, 77, 251, 231,=20 > 28, 97, 88, 193, 215, 202, 248, 216, 121, 195, 211, 245, 250, 112, 71,=20 > 243, 61, 129, 95, 39, 244, 122, 225, 217, 169, 211, 165, 48, 253, 220,=20 > 59, 122, 219, 42, 86, 223, 32, 236, 39, 48, 103, 78, 122, 216, 187,=20 > 88, 176, 89, 24, 1, 42, 177, 24, 99, 142, 170, 1, 146, 43, 3, 108, 64,=20 > 194, 121, 182, 95, 187, 134, 71, 88, 96, 134, 74, 131, 167, 69, 106,=20 > 143, 121, 27, 72, 44, 245, 95, 39, 194, 179, 175, 203, 122, 16, 112,=20 > 183, 17, 200, 202, 31, 17, 138, 156, 184, 210, 157, 184, 154, 131,=20 > 128, 110, 12, 85, 195, 122, 241, 79, 251, 229, 183, 117, 21, 123, 133,=20 > 142, 220, 153, 9, 59, 57, 105, 81, 255, 138, 77, 82, 54, 62, 216, 38,=20 > 249, 208, 17, 197, 49, 45, 19, 232, 157, 251, 131, 137, 175, 72, 126,=20 > 43, 229, 69, 179, 117, 82, 157, 213, 83, 35, 57, 210, 197, 252, 171,=20 > 143, 194, 11, 47, 163, 6, 253, 75, 252, 96, 11, 187, 84, 130, 210, 7,=20 > 121, 78, 91, 79, 57, 251, 138, 132, 220, 60, 224, 173, 56, 224, 201]=20 > The remaining RSA key parameters are included for completeness, but=20 > should not be needed DP [100, 175, 152, 192, 78, 221, 137, 72, 116,=20 > 169, 29, 109, 71, 188, 60, 88, 123, 104, 148, 60, 119, 49, 159, 206,=20 > 78, 140, 34, 22, 248, 31, 121, 13, 210, 138, 183, 172, 94, 57, 189,=20 > 129, 158, 74, 46, 19, 23, 190, 143, 174, 207, 226, 148, 37, 96, 241,=20 > 75, 154, 69, 67, 243, 52, 122, 247, 104, 213, 210, 162, 69, 56, 213,=20 > 195, 252, 120, 55, 42, 178, 92, 243, 57, 157, 66, 207, 145, 202, 84,=20 > 243, 110, 235, 158, 150, 115, 0, 146, 169, 118, 21, 128, 130, 170,=20 > 215, 24, 160, 4, 9, 1, 244, 94, 222, 45, 107, 57, 227, 157, 223, 243,=20 > 86, 144, 38, 101, 154, 186, 209, 99, 204, 4, 199, 202, 114, 225] DQ=20 > [14, 173, 32, 126, 2, 117, 13, 209, 70, 94, 34, 239, 64, 70, 103, 184,=20 > 161, 13, 209, 69, 38, 176, 144, 113, 146, 60, 157, 115, 120, 248, 101,=20 > 135, 65, 136, 196, 64, 203, 206, 177, 210, 241, 194, 143, 44, 28, 50,=20 > 86, 24, 131, 140, 168, 11, 134, 25, 107, 216, 77, 85, 203, 35, 168,=20 > 13, 197, 122, 34, 245, 246, 185, 60, 131, 164, 39, 219, 212, 237, 209,=20 > 200, 252, 170, 172, 133, 167, 63, 111, 52, 48, 84, 124, 32, 34, 37,=20 > 87, 132, 72, 232, 201, 13, 147, 216, 29, 209, 216, 242, 253, 91, 250,=20 > 143, 153, 217, 126, 109, 188, 188, 126, 76, 39, 164, 127, 186, 49,=20 > 201, 226, 131, 82, 162, 150, 142, 43] InverseQ [84, 131, 41, 49, 134,=20 > 207, 127, 142, 221, 79, 92, 63, 204, 53, 23, 124, 248, 166, 177, 39,=20 > 160, 156, 195, 128, 215, 52, 218, 95, 182, 134, 147, 255, 46, 173,=20 > 142, 145, 243, 230, 86, 212, 92, 84, 236, 9, 86, 3, 34, 214, 201, 186,=20 > 170, 234, 221, 122, 84, 87, 123, 133, 7, 116, 203, 167, 229, 80, 174,=20 > 18, 148, 236, 157, 7, 173, 96, 193, 169, 206, 177, 113, 142, 0, 235,=20 > 252, 217, 193, 234, 208, 77, 222, 47, 129, 235, 181, 153, 20, 184,=20 > 171, 231, 62, 179, 39, 177, 69, 5, 149, 245, 29, 201, 181, 115, 199,=20 > 40, 243, 244, 145, 127, 95, 38, 152, 215, 134, 171, 116, 180, 163,=20 > 127, 130, 255, 20, 214] P [214, 190, 118, 94, 78, 58, 115, 226, 236,=20 > 124, 30, 79, 227, 141, 169, 237, 171, 93, 61, 74, 241, 65, 44, 184,=20 > 154, 216, 191, 181, 146, 55, 50, 7, 246, 18, 225, 85, 109, 74, 3, 6,=20 > 246, 145, 67, 228, 150, 198, 70, 228, 154, 129, 51, 47, 178, 87, 174,=20 > 132, 129, 141, 42, 202, 221, 130, 16, 129, 135, 76, 131, 32, 4, 61,=20 > 51, 227, 94, 255, 225, 35, 111, 245, 121, 52, 143, 85, 151, 243, 47,=20 > 73, 95, 124, 217, 244, 220, 133, 234, 88, 94, 76, 12, 91, 168, 81,=20 > 129, 52, 135, 54, 246, 190, 26, 229, 55, 250, 202, 173, 183, 195, 35,=20 > 5, 27, 78, 184, 227, 130, 39, 145, 111, 0, 186, 10, 93] Q [192, 182,=20 > 247, 231, 30, 225, 153, 5, 153, 177, 98, 102, 7, 251, 229, 123, 206,=20 > 226, 134, 6, 117, 245, 47, 37, 4, 68, 78, 44, 139, 25, 27, 134, 178,=20 > 101, 87, 189, 30, 47, 96, 13, 80, 142, 6, 101, 3, 117, 160, 216, 85,=20 > 52, 141, 199, 255, 5, 203, 13, 88, 97, 175, 87, 26, 177, 167, 13, 236,=20 > 52, 208, 157, 188, 113, 21, 40, 120, 16, 127, 140, 162, 53, 162, 102,=20 > 180, 58, 187, 245, 79, 214, 151, 33, 108, 74, 193, 222, 32, 191, 17,=20 > 72, 152, 229, 171, 221, 4, 75, 244, 161, 1, 71, 57, 54, 69, 171, 84,=20 > 6, 121, 131, 100, 148, 200, 1, 252, 19, 179, 72, 58, 241, 70, 71, 190,=20 > 215] END RSA KEY PARAMETERS Encrypted Key [142, 252, 40, 202, 21, 177,=20 > 56, 198, 232, 7, 151, 49, 95, 169, 220, 2, 46, 214, 167, 116, 57, 20,=20 > 164, 109, 150, 98, 49, 223, 154, 95, 71, 209, 233, 17, 174, 142, 203,=20 > 232, 132, 167, 17, 42, 51, 125, 22, 221, 135, 17, 67, 197, 148, 246,=20 > 139, 145, 160, 238, 99, 119, 171, 95, 117, 202, 87, 251, 101, 254, 58,=20 > 215, 135, 195, 135, 103, 49, 119, 76, 46, 49, 198, 27, 31, 58, 44,=20 > 192, 222, 21, 16, 13, 216, 161, 179, 236, 65, 143, 38, 43, 218, 195,=20 > 76, 140, 243, 71, 243, 79, 124, 216, 208, 242, 171, 34, 245, 57, 154,=20 > 93, 76, 230, 204, 234, 82, 117, 248, 39, 13, 62, 60, 215, 8, 51, 248,=20 > 254, 47, 150, 36, 46, 27, 247, 98, 77, 56, 92, 44, 19, 39, 12, 77, 54,=20 > 101, 194, 126, 86, 0, 64, 239, 95, 211, 64, 26, 219, 93, 211, 36, 154,=20 > 250, 117, 177, 213, 232, 142, 184, 216, 92, 20, 248, 69, 175, 180, 71,=20 > 205, 221, 235, 224, 95, 113, 5, 33, 86, 18, 157, 61, 199, 8, 121, 0,=20 > 0, 135, 65, 67, 220, 164, 15, 230, 155, 71, 53, 64, 253, 209, 169,=20 > 255, 34, 64, 101, 7, 43, 102, 227, 83, 171, 52, 225, 119, 253, 182,=20 > 96, 195, 225, 34, 156, 211, 202, 7, 194, 255, 137, 59, 170, 172, 72,=20 > 234, 222, 203, 123, 249, 121, 254, 143, 173, 105, 65, 187, 189, 163,=20 > 64, 151, 145, 99, 17] Encoded Encrypted Key=20 > jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3YcRQ8WU9o > uRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0yM80fzT3zY > 0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYAQO9f00Aa21 > 3TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzVA_dGp_yJA > ZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjEQ > Additional Authenticated Data > eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTMD > RVM2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3 > YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0y > M80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYAQ > O9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzV > A_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjE > Q > Additional Authenticated Data Bytes > [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, 116,=20 > 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, 73, 54,=20 > 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 76, 67, 74, 112,=20 > 100, 105, 73, 54, 73, 106, 81, 52, 86, 106, 70, 102, 81, 85, 120, 105,=20 > 78, 108, 86, 84, 77, 68, 82, 86, 77, 50, 73, 105, 102, 81, 46, 106,=20 > 118, 119, 111, 121, 104, 87, 120, 79, 77, 98, 111, 66, 53, 99, 120,=20 > 88, 54, 110, 99, 65, 105, 55, 87, 112, 51, 81, 53, 70, 75, 82, 116,=20 > 108, 109, 73, 120, 51, 53, 112, 102, 82, 57, 72, 112, 69, 97, 54, 79,=20 > 121, 45, 105, 69, 112, 120, 69, 113, 77, 51, 48, 87, 51, 89, 99, 82,=20 > 81, 56, 87, 85, 57, 111, 117, 82, 111, 79, 53, 106, 100, 54, 116, 102,=20 > 100, 99, 112, 88, 45, 50, 88, 45, 79, 116, 101, 72, 119, 52, 100, 110,=20 > 77, 88, 100, 77, 76, 106, 72, 71, 71, 120, 56, 54, 76, 77, 68, 101,=20 > 70, 82, 65, 78, 50, 75, 71, 122, 55, 69, 71, 80, 74, 105, 118, 97,=20 > 119, 48, 121, 77, 56, 48, 102, 122, 84, 51, 122, 89, 48, 80, 75, 114,=20 > 73, 118, 85, 53, 109, 108, 49, 77, 53, 115, 122, 113, 85, 110, 88, 52,=20 > 74, 119, 48, 45, 80, 78, 99, 73, 77, 95, 106, 45, 76, 53, 89, 107, 76,=20 > 104, 118, 51, 89, 107, 48, 52, 88, 67, 119, 84, 74, 119, 120, 78, 78,=20 > 109, 88, 67, 102, 108, 89, 65, 81, 79, 57, 102, 48, 48, 65, 97, 50,=20 > 49, 51, 84, 74, 74, 114, 54, 100, 98, 72, 86, 54, 73, 54, 52, 50, 70,=20 > 119, 85, 45, 69, 87, 118, 116, 69, 102, 78, 51, 101, 118, 103, 88, 51,=20 > 69, 70, 73, 86, 89, 83, 110, 84, 51, 72, 67, 72, 107, 65, 65, 73, 100,=20 > 66, 81, 57, 121, 107, 68, 45, 97, 98, 82, 122, 86, 65, 95, 100, 71,=20 > 112, 95, 121, 74, 65, 90, 81, 99, 114, 90, 117, 78, 84, 113, 122, 84,=20 > 104, 100, 95, 50, 50, 89, 77, 80, 104, 73, 112, 122, 84, 121, 103,=20 > 102, 67, 95, 52, 107, 55, 113, 113, 120, 73, 54, 116, 55, 76, 101, 95,=20 > 108, 53, 95, 111, 45, 116, 97, 85, 71, 55, 118, 97, 78, 65, 108, 53,=20 > 70, 106, 69, 81] Ciphertext [253, 237, 181, 180, 97, 161, 105, 207,=20 > 233, 120, 65, 100, 45, 122, 246, 116, 195, 212, 102, 37, 36, 175]=20 > Encoded Ciphertext _e21tGGhac_peEFkLXr2dMPUZiUkrw Authentication Tag=20 > (Integrity Value) [97, 182, 82, 120, 112, 141, 13, 144, 106, 1, 220,=20 > 233, 68, 233, 114, 139] Encoded Authentication Tag (Encoded Integrity > Value) YbZSeHCNDZBqAdzpROlyiw JWE > eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6IjQ4VjFfQUxiNlVTMD > RVM2IifQ.jvwoyhWxOMboB5cxX6ncAi7Wp3Q5FKRtlmIx35pfR9HpEa6Oy-iEpxEqM30W3 > YcRQ8WU9ouRoO5jd6tfdcpX-2X-OteHw4dnMXdMLjHGGx86LMDeFRAN2KGz7EGPJivaw0y > M80fzT3zY0PKrIvU5ml1M5szqUnX4Jw0-PNcIM_j-L5YkLhv3Yk04XCwTJwxNNmXCflYAQ > O9f00Aa213TJJr6dbHV6I642FwU-EWvtEfN3evgX3EFIVYSnT3HCHkAAIdBQ9ykD-abRzV > A_dGp_yJAZQcrZuNTqzThd_22YMPhIpzTygfC_4k7qqxI6t7Le_l5_o-taUG7vaNAl5FjE > Q._e21tGGhac_peEFkLXr2dMPUZiUkrw.YbZSeHCNDZBqAdzpROlyiw > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Fri Jul 6 11:20:45 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B2111E809F for ; Fri, 6 Jul 2012 11:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.737 X-Spam-Level: X-Spam-Status: No, score=-3.737 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBl0RAhwv8ML for ; Fri, 6 Jul 2012 11:20:44 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3C51C11E8079 for ; Fri, 6 Jul 2012 11:20:43 -0700 (PDT) Received: from mail151-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Jul 2012 18:18:51 +0000 Received: from mail151-va3 (localhost [127.0.0.1]) by mail151-va3-R.bigfish.com (Postfix) with ESMTP id 447C23A02F6; Fri, 6 Jul 2012 18:18:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VS-26(zz9371I542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail151-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail151-va3 (localhost.localdomain [127.0.0.1]) by mail151-va3 (MessageSwitch) id 134159873057184_3027; Fri, 6 Jul 2012 18:18:50 +0000 (UTC) Received: from VA3EHSMHS006.bigfish.com (unknown [10.7.14.236]) by mail151-va3.bigfish.com (Postfix) with ESMTP id 0A8D4200E8; Fri, 6 Jul 2012 18:18:50 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS006.bigfish.com (10.7.99.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Jul 2012 18:18:48 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0309.003; Fri, 6 Jul 2012 18:20:55 +0000 From: Mike Jones To: "Manger, James H" , "jose@ietf.org" Thread-Topic: JWE: key agreement algorithms and the content master key Thread-Index: Ac1bpBDaDvuhbN4KRsyceQDdEvhsQw== Date: Fri, 6 Jul 2012 18:20:54 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436657A16C@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] JWE: key agreement algorithms and the content master key X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 18:20:45 -0000 In response to Jim Schaad's and Sean's comments, the draft now specifies th= at an ephemeral public key must be randomly generated per key agreement tra= nsaction. So your concern that JWE key agreement might generate the same C= MK for all messages exchanged between two parties will not happen. As for generating a CMK, rather than using the agreed upon key, I've added = this to the list of open issues to be discussed by the working group. I ca= n see why you would want this for the multiple recipients case. Best wishes, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Man= ger, James H Sent: Tuesday, May 29, 2012 6:53 PM To: jose@ietf.org Subject: [jose] JWE: key agreement algorithms and the content master key One option for constructing an encrypted message (JWE) is to use a key agre= ement mechanism. The draft says: when key agreement is employed, use the key agreement algorithm to compute the value of the Content Master Key (CMK) when key agreement is employed, let the JWE Encrypted Key be an empty byte array Is this a good approach? It differs from the approach in Crypto Message Syntax Standard (CMS) [rfc56= 52#section-6.2.2], where the secret that the key agreement mechanism genera= tes is used to encrypt a randomly chosen CMK. Sharing the ciphertext when encrypting for multiple recipients (as done in = the JWE-JS serialization) presumably cannot work when JWE key agreement is = used since the CMK is per-recipient, not per-message. The JWE key agreement might also generates the same CMK for all messages ex= changed between two parties. That sounds unacceptable. Perhaps this is avoi= dable by assuming/requiring the sender uses a per-message ephemeral key pai= r? I am inclined to stick with the CMS approach. It adds about 32 chars to the= message (for a 128-bit key) and a key wrapping step. -- James Manger _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From rbarnes@bbn.com Fri Jul 6 11:22:19 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB89011E808F for ; Fri, 6 Jul 2012 11:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.542 X-Spam-Level: X-Spam-Status: No, score=-106.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADdJiBmsjWkY for ; Fri, 6 Jul 2012 11:22:19 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 253EC11E8079 for ; Fri, 6 Jul 2012 11:22:19 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:61708) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SnDAl-000E99-Vt; Fri, 06 Jul 2012 14:22:32 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436657A131@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 6 Jul 2012 14:22:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B16804296739436657A131@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1278) Cc: "Manger, James H" , "jose@ietf.org" Subject: [jose] Nested JWT (was: Re: "typ":"JWS") X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 18:22:20 -0000 Not sure what the appropriate list is for this, so I'm just going to ask = it here: What is a "nested JWT"? I'm guessing it's a JWT claim set wrapped in = JWS multiple times, as in the example we were discussing earlier? Why would you want to do that instead of having parallel signatures? On Jul 6, 2012, at 2:19 PM, Mike Jones wrote: > Thanks for the thought on this, James. > =20 > In the -03 drafts there is now a clear distinction between =93typ=94 = (type) - information about this object and the new =93cty=94 (content = type) =96 information about the secured object. Besides being = semantically cleaner, this also simplified nested JWTs. > =20 > I then was able to make changes in the spirit of the ones you = suggested below, although using slightly different wording in some = cases. > =20 > -- = Mike > =20 > From: Manger, James H [mailto:James.H.Manger@team.telstra.com]=20 > Sent: Tuesday, May 15, 2012 5:40 PM > To: Mike Jones; jose@ietf.org > Subject: RE: "typ":"JWS" > =20 > >> draft-ietf-jose-json-web-signature-02 =A77.2 registers the =93JWS=94 = type value (for the =93typ=94 header field) > >> =85 > >> Perhaps =93typ=94:=94JWS=94 is more useful in a JWE header when = encrypting signed content (sign-then-encrypt). If this is the intention, = then mentioning the =93JWS=94 type value when defining the =93typ=94 = header for a JWS is misleading. It would be better to mention it where = the JWE spec defines =93typ=94. > >> =85 > =20 > > Your second paragraph correctly describes the intended usage. For = instance, see = http://tools.ietf.org/html/draft-jones-json-web-token-10#section-5.1 for = this usage in action. The value is registered per the working group = decision relating =93typ=94 values to MIME types. > =20 > Good. So let=92s say that. Suggested text changes: > =20 > * draft-ietf-jose-json-web-signature-02, section 4.1.8 =93typ=94 = (Type) Header Parameter: delete the 2nd sentence because signing a = signature is not what we are talking about (and JWS-JS recommends a = different approach for multiple signatures anyway). > =20 > * section 7.1 Registration of application/jws MIME Media Type: add a = phrase explicitly stating the syntax (since the spec mentions two: = compact, and JWS JS) so the section says: > This specification registers the "application/jws" MIME Media Type = [RFC 2045] > to identify content that uses the JWS compact serialization. > =20 > * section 7.2 Registration of "JWS" Type Value: mention the intended = use of encrypting signed content by adding this sentence. > The =93typ=94 parameter can be set to =93JWS=94 in a JSON Web = Encryption [JWE] header when encrypting signed content. > =20 > * draft-ietf-jose-json-web-encryption-02, section 4.1.13 =93typ=94 = (Type) Header Parameter, section 11.1 Registration of application/jwe = MIME Media Type, section 11.2 Registration of =93JWE=94 type Value: make = equivalent changes. > =20 > -- > James Manger > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Fri Jul 6 11:22:37 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE8911E809F for ; Fri, 6 Jul 2012 11:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.735 X-Spam-Level: X-Spam-Status: No, score=-3.735 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFHDlVI70RXm for ; Fri, 6 Jul 2012 11:22:35 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id 17E5111E8079 for ; Fri, 6 Jul 2012 11:22:35 -0700 (PDT) Received: from mail47-db3-R.bigfish.com (10.3.81.247) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Jul 2012 18:20:42 +0000 Received: from mail47-db3 (localhost [127.0.0.1]) by mail47-db3-R.bigfish.com (Postfix) with ESMTP id ACFDB80547; Fri, 6 Jul 2012 18:20:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VS-21(zz9371Ic85fhzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail47-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail47-db3 (localhost.localdomain [127.0.0.1]) by mail47-db3 (MessageSwitch) id 1341598840332878_6845; Fri, 6 Jul 2012 18:20:40 +0000 (UTC) Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.234]) by mail47-db3.bigfish.com (Postfix) with ESMTP id 4DB3C2E003F; Fri, 6 Jul 2012 18:20:40 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Jul 2012 18:20:40 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0298.005; Fri, 6 Jul 2012 18:22:45 +0000 From: Mike Jones To: "Manger, James H" , "jose@ietf.org" Thread-Topic: MUST understand ALL header fields Thread-Index: Ac1bpFGsDo+RPNtVSUCtA/itrmlQRA== Date: Fri, 6 Jul 2012 18:22:45 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436657A1B2@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436657A1B2TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 18:22:37 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436657A1B2TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Since this is a security protocol, the way I see it, use of a not-understoo= d parameter SHOULD break implementations if they're not prepared to handle = them (or at least them cause them to reject the input). For example, if we= hypothetically added an audience restriction parameter, ignoring it would = be a security error. (The need for audience restriction is being heavily d= iscussed in the OAuth WG right now, and real exploits that have occurred fo= r the lack of it, so this example is real and fresh on my mind.) If not un= derstood, a token containing an audience restriction MUST be rejected. On your second point, I don't think the working group wanted to recreate th= e whole of certificate semantics in JSON. Hence the intentionally limited = capabilities of JWK, for instance. Those limitations even made it into the= WG charter. But if you want to propose specific certificate-related addit= ions to the WG, have at it. -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Manger, J= ames H Sent: Tuesday, May 15, 2012 7:56 AM To: jose@ietf.org Subject: [jose] MUST understand ALL header fields draft-ietf-jose-json-web-signature-02 and draft-ietf-jose-json-web-encrypti= on-02 say: Implementations MUST understand the entire contents of the header; otherwise, the {JWS|JWE} MUST be rejected. We should drop this restriction. Firstly, most implementations will ignore it. I had a quick glance at some existing implementations (magical/jwt-python, = markrcote/jwt, jsontoken) and all appear to ignore this requirement. It cannot add any security when it is ignored. It does cause massive compat= ibility headaches for anyone wanting to define another header parameter, si= nce a new parameter will break some implementations. Secondly, a couple of parameters are defined for X.509 certs, but none for = OCSP responses, CRLs, timestamps etc. It is inevitable that a cert-based sc= heme will need these extra pieces of info. With the "MUST understand everyt= hing" rule, we have to define all the extra info that might be needed right= now. If we need to be able to break backward compatibility we should define a me= chanism explicitly for that. -- James Manger --_000_4E1F6AAD24975D4BA5B16804296739436657A1B2TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Since this is a securi= ty protocol, the way I see it, use of a not-understood parameter SHOULD bre= ak implementations if they’re not prepared to handle them (or at leas= t them cause them to reject the input).  For example, if we hypothetically added an audience restriction parameter, ign= oring it would be a security error.  (The need for audience restrictio= n is being heavily discussed in the OAuth WG right now, and real exploits t= hat have occurred for the lack of it, so this example is real and fresh on my mind.)  If not understood, a = token containing an audience restriction MUST be rejected.

 

On your second point, = I don’t think the working group wanted to recreate the whole of certi= ficate semantics in JSON.  Hence the intentionally limited capabilitie= s of JWK, for instance.  Those limitations even made it into the WG charter.  But if you want to propose specific cer= tificate-related additions to the WG, have at it.

 

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

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Manger, James H
Sent: Tuesday, May 15, 2012 7:56 AM
To: jose@ietf.org
Subject: [jose] MUST understand ALL header fields<= /p>

 

draft-ietf-jose-json-web-signat= ure-02 and draft-ietf-jose-json-web-encryption-02 say:

 

   Implementations MU= ST understand the entire contents of the

   header; otherwise,= the {JWS|JWE} MUST be rejected.

 

We should drop this restriction= .

 

Firstly, most implementations w= ill ignore it.

I had a quick glance at some ex= isting implementations (magical/jwt-python, markrcote/jwt, jsontoken) and a= ll appear to ignore this requirement.

It cannot add any security when= it is ignored. It does cause massive compatibility headaches for anyone wa= nting to define another header parameter, since a new parameter will break = some implementations.

 

Secondly, a couple of parameter= s are defined for X.509 certs, but none for OCSP responses, CRLs, timestamp= s etc. It is inevitable that a cert-based scheme will need these extra piec= es of info. With the “MUST understand everything” rule, we have to define all the extra info that might be= needed right now.

 

If we need to be able to break = backward compatibility we should define a mechanism explicitly for that.

 

--

James Manger<= /p>

 

--_000_4E1F6AAD24975D4BA5B16804296739436657A1B2TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Fri Jul 6 11:23:56 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5FED21F86C4 for ; Fri, 6 Jul 2012 11:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.233 X-Spam-Level: X-Spam-Status: No, score=-5.233 tagged_above=-999 required=5 tests=[AWL=1.365, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+n+RkPoEoOw for ; Fri, 6 Jul 2012 11:23:56 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id B798421F86A2 for ; Fri, 6 Jul 2012 11:23:55 -0700 (PDT) Received: from mail232-va3-R.bigfish.com (10.7.14.244) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Jul 2012 18:22:04 +0000 Received: from mail232-va3 (localhost [127.0.0.1]) by mail232-va3-R.bigfish.com (Postfix) with ESMTP id E72C35002FA; Fri, 6 Jul 2012 18:22:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VS-22(zz9371Ic89bhc857h111aIzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail232-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail232-va3 (localhost.localdomain [127.0.0.1]) by mail232-va3 (MessageSwitch) id 1341598921487015_31419; Fri, 6 Jul 2012 18:22:01 +0000 (UTC) Received: from VA3EHSMHS013.bigfish.com (unknown [10.7.14.237]) by mail232-va3.bigfish.com (Postfix) with ESMTP id 74F5360004C; Fri, 6 Jul 2012 18:22:01 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS013.bigfish.com (10.7.99.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Jul 2012 18:21:59 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0298.005; Fri, 6 Jul 2012 18:24:03 +0000 From: Mike Jones To: "Manger, James H" , "jose@ietf.org" Thread-Topic: Complete JWE computation example Thread-Index: Ac1bpHxDj4i+nfsqRlCSPUHG0/+Khw== Date: Fri, 6 Jul 2012 18:24:03 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436657A1D8@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436657A1D8TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] Complete JWE computation example X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 18:23:57 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436657A1D8TK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmXZlIG5vdyBkZWZpbmVkIHRoZSBrZXkgc2l6ZXMgZm9yIHRoZSDigJxpbnTigJ0gYWxnb3Jp dGhtcyBpbiBKV0EuDQoNClNlZSBteSByZXBsaWVzIHRvIEppbSBhbmQgU2VhbiBhYm91dCB0aGUg Q29uY2F0IEtERi4NCg0KQWxzbywgc2VlIG15IHJlcGx5IHRvIEppbSBhYm91dCByZXF1aXJpbmcg YSDigJxraWTigJ0gdmFsdWUuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGFua3MgYWdhaW4sDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlr ZQ0KDQpGcm9tOiBNYW5nZXIsIEphbWVzIEggW21haWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRl bHN0cmEuY29tXTxtYWlsdG86W21haWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29t XT4NClNlbnQ6IFdlZG5lc2RheSwgSnVuZSAyNywgMjAxMiAxMToyMyBQTQ0KVG86IE1pa2UgSm9u ZXM7IGpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogQ29t cGxldGUgSldFIGNvbXB1dGF0aW9uIGV4YW1wbGUNCg0KVGhlIGNhbGN1bGF0aW9ucyBpbiB0aGVz ZSBleGFtcGxlcyB3b3JrZWQgZm9yIG1lIHRvby4gUHJvdmlkaW5nIGJpbmFyeSB2YWx1ZXMgYXMg Y29tbWEtc2VwYXJhdGVkIGRlY2ltYWwgdmFsdWVzIGZvciBlYWNoIGJ5dGUgaXMgYSBiaXQgYW5u b3lpbmcuIEkgZ3Vlc3MgdGhpcyBpcyBhIEphdmFTY3JpcHQgdGhpbmcuDQoNClRoZSBrZXkgZGVy aXZhdGlvbiBjYW5ub3QgcmVhbGx5IGNhbGwgaXRzZWxmIHRoZSBDb25jYXQgS0RGIGZyb20gTklT VCA4MDAgNTZBLiBMZWF2aW5nIHRoZSBBbGdvcml0aG1JRCwgUGFydHlVSW5mbyAoc2VuZGVyIGlk KSwgYW5kIFBhcnR5VkluZm8gKHJlY2VpdmVyIGlkKSBlbXB0eSBpcyBub3QgYWxsb3dlZC4gQWRk aXRpb25hbGx5LCB0aGUgTklTVCBzcGVj4oCZcyB3YXkgb2YgZGVyaXZpbmcgYW4gSE1BQyBhbmQg QUVTIGtleSB3b3VsZCBiZSB0byBydW4gdGhlIEtERiBvbmNlIHRvIGdlbmVyYXRlIGVub3VnaCBi aXRzIGZvciBib3RoIGtleXMgKOKAnGNvbmNhdGVuYXRlZOKAnSkuIEpXRSwgaW4gY29udHJhc3Qs IHJ1bnMgdGhlIEtERiB0d2ljZSB0byBnZXQgdGhlIEhNQUMgYW5kIEFFUyBrZXlzIHNlcGFyYXRl bHkuDQoNCk5vdGhpbmcgYWN0dWFsbHkgc3BlY2lmaWVzIHRoZSBhY3R1YWwga2V5IHNpemUgZm9y IHRoZSBIUzI1NiBjYWxjdWxhdGlvbi4gSldBIG9ubHkgc2F5cyAyNTYtYml0cyBpcyB0aGUgbWlu aW11bSBrZXkgbGVuZ3RoLg0KDQpQbGVhc2UgcHV0IGEga2V5IGlkIGluIHRoZSBoZWFkZXIuIEpX RSBkZWNyeXB0aW9uIHN0ZXAgNSBzYXlzIOKAnHZlcmlmeSB0aGF0IHRoZSBKV0UgSGVhZGVyIHJl ZmVyZW5jZXMgYSBrZXkga25vd24gdG8gdGhlIHJlY2lwaWVudOKAnSB3aGljaCBpcyBhIGJpdCBo YXJkIHdpdGggbm8ga2V5IHJlZmVyZW5jZS4gRXZlcnlvbmUgc2hvdWxkIHN1cHBvcnQga2V5IHJv bGxvdmVyIChldmVuIGlmIG1hbnVhbGx5KSB3aGljaCBiYXNpY2FsbHkgbmVlZHMgYSBrZXkgaWQg c28gaXQgbWF5IGFzIHdlbGwgYmUgbWFuZGF0b3J5LiBJZiB0aGUga2V5IGlkIGlzIGNvbnZleWVk IG91dC1vZi1iYW5kIChvciBtZXJlbHkgaW1wbGllZCkgaXQgaXNu4oCZdCBwcm90ZWN0ZWQgYnkg dGhlIGludGVncml0eSBjaGVjayDigJMgd2hpY2ggYWxtb3N0IHN0YXJ0cyB0byB1bmRvIHRoZSBh cmd1bWVudCBmb3IgaW50ZWdyaXR5LXByb3RlY3Rpb24gb2YgdGhlIGhlYWRlci4NCg0KDQotLQ0K SmFtZXMgTWFuZ2VyDQoNCkZyb206IGpvc2UtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86am9zZS1i b3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ108bWFpbHRvOltt YWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXT4gT24gQmVoYWxmIE9mIE1pa2UgSm9uZXMNClNl bnQ6IFdlZG5lc2RheSwgMjcgSnVuZSAyMDEyIDEwOjMzIEFNDQpUbzogam9zZUBpZXRmLm9yZzxt YWlsdG86am9zZUBpZXRmLm9yZz4NClN1YmplY3Q6IFtqb3NlXSBDb21wbGV0ZSBKV0UgY29tcHV0 YXRpb24gZXhhbXBsZQ0KDQpEZWFyIHdvcmtpbmcgZ3JvdXAgbWVtYmVycywNCg0KRm9yIHRoZSBu ZXh0IHJvdW5kIG9mIHRoZSBKT1NFIEpXRSBzcGVjLCBJ4oCZbSBhZGRpbmcgZXhhbXBsZSBlbmNy eXB0aW9uIGNvbXB1dGF0aW9ucyB0byBhaWQgaW1wbGVtZW50ZXJzLiAgQW4gZXhhbXBsZSBKV0Ug Y29tcHV0YXRpb24gaXMgaW5jbHVkZWQgYmVsb3csIGluIGNhc2UgeW914oCZZCBsaWtlIHRvIGNv bXBhcmUgeW91ciBpbXBsZW1lbnRhdGlvbnMgYWdhaW5zdCB0aGVzZS4gIFRoZXNlIHZhbHVlcyBo YXZlIGFscmVhZHkgYmVlbiB2ZXJpZmllZCBieSB0d28gaW5kZXBlbmRlbnQgaW1wbGVtZW50YXRp b25zLg0KDQpUaGlzIGV4YW1wbGUgdXNlcyB0aGUgaGVhZGVyIHZhbHVlczoNCiAgICB7ImFsZyI6 IlJTQTFfNSIsImVuYyI6IkExMjhDQkMiLCJpbnQiOiJIUzI1NiIsIml2IjoiQXhZOERDdERhR2xz YkdsamIzUm9aUSJ9DQrigKYNCg== --_000_4E1F6AAD24975D4BA5B16804296739436657A1D8TK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRl LCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPknigJl2ZSBub3cgZGVmaW5lZCB0aGUga2V5IHNpemVzIGZvciB0aGUg4oCcaW504oCd IGFsZ29yaXRobXMgaW4gSldBLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ U2VlIG15IHJlcGxpZXMgdG8gSmltIGFuZCBTZWFuIGFib3V0IHRoZSBDb25jYXQgS0RGLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+QWxzbywgc2VlIG15IHJlcGx5IHRvIEpp bSBhYm91dCByZXF1aXJpbmcgYSDigJxraWTigJ0gdmFsdWUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhh bmtzIGFnYWluLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IE1hbmdlciwgSmFtZXMgSA0KPGEgaHJlZj0ibWFpbHRvOlttYWls dG86SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbV0iPlttYWlsdG86SmFtZXMuSC5NYW5n ZXJAdGVhbS50ZWxzdHJhLmNvbV08L2E+DQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBK dW5lIDI3LCAyMDEyIDExOjIzIFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzOyA8YSBocmVm PSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUkU6IENvbXBsZXRlIEpXRSBjb21wdXRhdGlvbiBleGFtcGxlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5UaGUgY2FsY3VsYXRpb25zIGluIHRoZXNlIGV4YW1wbGVzIHdvcmtl ZCBmb3IgbWUgdG9vLiBQcm92aWRpbmcgYmluYXJ5IHZhbHVlcyBhcyBjb21tYS1zZXBhcmF0ZWQg ZGVjaW1hbCB2YWx1ZXMgZm9yIGVhY2ggYnl0ZSBpcyBhIGJpdCBhbm5veWluZy4gSSBndWVzcyB0 aGlzIGlzIGEgSmF2YVNjcmlwdCB0aGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUFVIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhlIGtleSBkZXJpdmF0aW9uIGNhbm5v dCByZWFsbHkgY2FsbCBpdHNlbGYgdGhlIENvbmNhdCBLREYgZnJvbSBOSVNUIDgwMCA1NkEuIExl YXZpbmcgdGhlIEFsZ29yaXRobUlELCBQYXJ0eVVJbmZvIChzZW5kZXIgaWQpLCBhbmQgUGFydHlW SW5mbyAocmVjZWl2ZXIgaWQpIGVtcHR5IGlzIG5vdCBhbGxvd2VkLiBBZGRpdGlvbmFsbHksIHRo ZQ0KIE5JU1Qgc3BlY+KAmXMgd2F5IG9mIGRlcml2aW5nIGFuIEhNQUMgYW5kIEFFUyBrZXkgd291 bGQgYmUgdG8gcnVuIHRoZSBLREYgb25jZSB0byBnZW5lcmF0ZSBlbm91Z2ggYml0cyBmb3IgYm90 aCBrZXlzICjigJxjb25jYXRlbmF0ZWTigJ0pLiBKV0UsIGluIGNvbnRyYXN0LCBydW5zIHRoZSBL REYgdHdpY2UgdG8gZ2V0IHRoZSBITUFDIGFuZCBBRVMga2V5cyBzZXBhcmF0ZWx5LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5O b3RoaW5nIGFjdHVhbGx5IHNwZWNpZmllcyB0aGUgYWN0dWFsIGtleSBzaXplIGZvciB0aGUgSFMy NTYgY2FsY3VsYXRpb24uIEpXQSBvbmx5IHNheXMgMjU2LWJpdHMgaXMgdGhlIG1pbmltdW0ga2V5 IGxlbmd0aC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1BVSIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+UGxlYXNlIHB1dCBhIGtleSBpZCBpbiB0aGUgaGVhZGVyLiBKV0UgZGVj cnlwdGlvbiBzdGVwIDUgc2F5cyDigJx2ZXJpZnkgdGhhdCB0aGUgSldFIEhlYWRlciByZWZlcmVu Y2VzIGEga2V5IGtub3duIHRvIHRoZSByZWNpcGllbnTigJ0gd2hpY2ggaXMgYSBiaXQgaGFyZCB3 aXRoIG5vIGtleSByZWZlcmVuY2UuIEV2ZXJ5b25lIHNob3VsZCBzdXBwb3J0DQoga2V5IHJvbGxv dmVyIChldmVuIGlmIG1hbnVhbGx5KSB3aGljaCBiYXNpY2FsbHkgbmVlZHMgYSBrZXkgaWQgc28g aXQgbWF5IGFzIHdlbGwgYmUgbWFuZGF0b3J5LiBJZiB0aGUga2V5IGlkIGlzIGNvbnZleWVkIG91 dC1vZi1iYW5kIChvciBtZXJlbHkgaW1wbGllZCkgaXQgaXNu4oCZdCBwcm90ZWN0ZWQgYnkgdGhl IGludGVncml0eSBjaGVjayDigJMgd2hpY2ggYWxtb3N0IHN0YXJ0cyB0byB1bmRvIHRoZSBhcmd1 bWVudCBmb3IgaW50ZWdyaXR5LXByb3RlY3Rpb24NCiBvZiB0aGUgaGVhZGVyLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4tLTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmpvc2UtYm91bmNlc0Bp ZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmpvc2UtYm91bmNlc0BpZXRmLm9y Zzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5bbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ108L3NwYW4+PC9hPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TWlrZSBKb25lczxi cj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIDI3IEp1bmUgMjAxMiAxMDozMyBBTTxicj4NCjxi PlRvOjwvYj4gPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+am9zZUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbam9zZV0gQ29tcGxldGUgSldFIGNv bXB1dGF0aW9uIGV4YW1wbGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgd29ya2luZyBncm91cCBtZW1i ZXJzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgdGhlIG5leHQgcm91bmQgb2YgdGhlIEpP U0UgSldFIHNwZWMsIEnigJltIGFkZGluZyBleGFtcGxlIGVuY3J5cHRpb24gY29tcHV0YXRpb25z IHRvIGFpZCBpbXBsZW1lbnRlcnMuJm5ic3A7IEFuIGV4YW1wbGUgSldFIGNvbXB1dGF0aW9uIGlz IGluY2x1ZGVkIGJlbG93LCBpbiBjYXNlIHlvdeKAmWQgbGlrZSB0byBjb21wYXJlIHlvdXIgaW1w bGVtZW50YXRpb25zIGFnYWluc3QgdGhlc2UuJm5ic3A7IFRoZXNlIHZhbHVlcyBoYXZlDQogYWxy ZWFkeSBiZWVuIHZlcmlmaWVkIGJ5IHR3byBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbnMuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgZXhhbXBsZSB1c2VzIHRoZSBoZWFkZXIgdmFsdWVz OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHsmcXVvdDthbGcmcXVvdDs6JnF1b3Q7UlNBMV81JnF1b3Q7LCZxdW90O2VuYyZxdW90OzomcXVv dDtBMTI4Q0JDJnF1b3Q7LCZxdW90O2ludCZxdW90OzomcXVvdDtIUzI1NiZxdW90OywmcXVvdDtp diZxdW90OzomcXVvdDtBeFk4REN0RGFHbHNiR2xqYjNSb1pRJnF1b3Q7fTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPuKApjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B16804296739436657A1D8TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Fri Jul 6 11:24:49 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20BA611E808F for ; Fri, 6 Jul 2012 11:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 tagged_above=-999 required=5 tests=[AWL=1.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Lv9rD2zQ1YT for ; Fri, 6 Jul 2012 11:24:46 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 66D2711E8079 for ; Fri, 6 Jul 2012 11:24:46 -0700 (PDT) Received: from mail168-va3-R.bigfish.com (10.7.14.254) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Jul 2012 18:22:54 +0000 Received: from mail168-va3 (localhost [127.0.0.1]) by mail168-va3-R.bigfish.com (Postfix) with ESMTP id 8D126605DD; Fri, 6 Jul 2012 18:22:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VS-27(zz9371Ic85fh542M1447Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail168-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail168-va3 (localhost.localdomain [127.0.0.1]) by mail168-va3 (MessageSwitch) id 1341598956284502_1942; Fri, 6 Jul 2012 18:22:36 +0000 (UTC) Received: from VA3EHSMHS032.bigfish.com (unknown [10.7.14.242]) by mail168-va3.bigfish.com (Postfix) with ESMTP id 416013801DD; Fri, 6 Jul 2012 18:22:36 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS032.bigfish.com (10.7.99.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Jul 2012 18:22:36 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0309.003; Fri, 6 Jul 2012 18:24:43 +0000 From: Mike Jones To: "'Manger, James H'" , "jose@ietf.org" Thread-Topic: JWK: comments on jku, kid, use, mod.. Thread-Index: Ac1bpJNMzQ175g8/SVKEQMKYXMXfzg== Date: Fri, 6 Jul 2012 18:24:42 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436657A1FB@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436657A1FBTK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] JWK: comments on jku, kid, use, mod.. X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 18:24:49 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436657A1FBTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the comments, James. Responses inline... -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Manger, J= ames H Sent: Sunday, May 20, 2012 7:12 PM To: jose@ietf.org Subject: [jose] JWK: comments on jku, kid, use, mod.. A "jku" value is a URL pointing to a 1 or more JSON Web Keys. A "kid" value= (key id) is really needed to pick the right key from the set. Consequently= the spec should say [in JWS section 4.1.2 "jku" (JWK Set URL) Header Param= eter]: Producers MUST include a "kid" parameter when including a "jku" paramet= er. Per the new text in Section 4.3, there are many potential ways for applicat= ions to select the right key(s), including the "use" parameter, the "alg" p= arameter, and yes, the "kid" parameter. Applications can also simply try a= ll the keys and see if any of them work. As such, mandating the use of the= "kid" parameter when one is often not needed, would be overkill. "jku" makes sense for a JWS -- the receiver uses the "jku" URL to get the p= ublic key to verify the JWS signature. I'm not sure it makes sense in a JWE= , though. The receiver needs a private key to decrypt, not the public key t= hat "jku" points to. At best, "jku" in a JWE acts as an key id -- but we ha= ve a separate "kid" field. I think we should drop the "jku" parameter from = the JWE spec. You're correct about the difference between uses for JWS and JWE. Per a co= mment from Jim Schaad, added the language "this can be used to determine th= e private key needed to decrypt the JWE". The "use" (key use) parameter [JWK 4.2] should be a JSON array of strings, = not a single string. It is nice crypto hygiene to have only 1 use for a key= . However, multiple uses are common in practise and are not so atrocious th= at we should forbid it at a syntax level. Particularly given that "other va= lues [than "sig" and "enc"] MAY be used". See my response to Sean Turner's related comments on the "use" parameter. = Also as background, in XMLDSIG this value is a singleton - not a set - and = the use that you would express as ["sig", "enc"] there is instead expressed= as omitting the value. (Not that we need to always follow XMLDSIG, by any= means. :)) I would add the word "unsigned" when defining the "mod" and "exp" fields fo= r an RSA key[JWA sections 5.3.1 and 5.3.2] to explicitly avoid confusion gi= ven that other specs use signed representations (eg 2's complement) for the= se keys: It is represented as the base64url encoding of the value's *unsigned* big endian representation. Done I am not sure if adding "unsigned" would clarify the definitions of "x" and= "y" for elliptic curve keys since they are not always integers (depends on= the type of curve). Do others in the working group have authoritative information in this regar= d? If so, can you please provide us a reference? -- James Manger _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B16804296739436657A1FBTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the comm= ents, James.  Responses inline…

 

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Manger, James H
Sent: Sunday, May 20, 2012 7:12 PM
To: jose@ietf.org
Subject: [jose] JWK: comments on jku, kid, use, mod..

 

A "jku" value is a URL pointing to a 1 = or more JSON Web Keys. A "kid" value (key id) is really needed to= pick the right key from the set. Consequently the spec should say [in JWS = section 4.1.2 "jku" (JWK Set URL) Header Parameter]:

 

    Producers MUST include a "= ;kid" parameter when including a "jku" parameter.=

 

Per the new text in= Section 4.3, there are many potential ways for applications to select the = right key(s), including the “use” parameter, the “algR= 21; parameter, and yes, the “kid” parameter.  Applications= can also simply try all the keys and see if any of them work.  As such, m= andating the use of the “kid” parameter when one is often not n= eeded, would be overkill.

 

"jku" makes sense for a JWS -- the rece= iver uses the "jku" URL to get the public key to verify the JWS s= ignature. I'm not sure it makes sense in a JWE, though. The receiver needs = a private key to decrypt, not the public key that "jku" points to. At best, "jku" in a JWE acts as an key id -- but we h= ave a separate "kid" field. I think we should drop the "jku&= quot; parameter from the JWE spec.

 

You’re correc= t about the difference between uses for JWS and JWE.  Per a comment fr= om Jim Schaad, added the language “this can be used to determine the = private key needed to decrypt the JWE”.

 

The "use" (key use) parameter [JWK 4.2]= should be a JSON array of strings, not a single string. It is nice crypto = hygiene to have only 1 use for a key. However, multiple uses are common in = practise and are not so atrocious that we should forbid it at a syntax level. Particularly given that "other values [t= han "sig" and "enc"] MAY be used".

 

See my response to = Sean Turner’s related comments on the “use” parameter.&nb= sp; Also as background, in XMLDSIG this value is a singleton – not a = set – and the use that you would express as [“sig”, ̶= 0;enc”] there is instead expressed as omitting the value.  (Not that we need to alw= ays follow XMLDSIG, by any means. J)

 

I would add the word "unsigned" when de= fining the "mod" and "exp" fields for an RSA key[JWA se= ctions 5.3.1 and 5.3.2] to explicitly avoid confusion given that other spec= s use signed representations (eg 2's complement) for these keys:=

 

   It is represented as the base64url e= ncoding of the value's

   *unsigned* big endian representation= .

 

Done

 

I am not sure if adding "unsigned" woul= d clarify the definitions of "x" and "y" for elliptic c= urve keys since they are not always integers (depends on the type of curve)= .

 

Do others in the wo= rking group have authoritative information in this regard?  If so, can= you please provide us a reference?=

 

--

James Manger

 

 

_______________________________________________

jose mailing list

jose@ietf.org

https://www.iet= f.org/mailman/listinfo/jose

 

--_000_4E1F6AAD24975D4BA5B16804296739436657A1FBTK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Fri Jul 6 11:25:22 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD35A11E8079 for ; Fri, 6 Jul 2012 11:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.766 X-Spam-Level: X-Spam-Status: No, score=-3.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vi5m41ozEFMR for ; Fri, 6 Jul 2012 11:25:21 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 3E66411E809F for ; Fri, 6 Jul 2012 11:25:21 -0700 (PDT) Received: from mail270-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Jul 2012 18:23:29 +0000 Received: from mail270-va3 (localhost [127.0.0.1]) by mail270-va3-R.bigfish.com (Postfix) with ESMTP id 791DA240103; Fri, 6 Jul 2012 18:23:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -32 X-BigFish: VS-32(zzbb2dI98dI9371Ic89bh1431J936eI542M1432Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail270-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail270-va3 (localhost.localdomain [127.0.0.1]) by mail270-va3 (MessageSwitch) id 1341599007492849_3211; Fri, 6 Jul 2012 18:23:27 +0000 (UTC) Received: from VA3EHSMHS018.bigfish.com (unknown [10.7.14.243]) by mail270-va3.bigfish.com (Postfix) with ESMTP id 764E0380045; Fri, 6 Jul 2012 18:23:27 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS018.bigfish.com (10.7.99.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Jul 2012 18:23:26 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0298.005; Fri, 6 Jul 2012 18:25:34 +0000 From: Mike Jones To: Juraj Somorovsky Thread-Topic: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-02.txt Thread-Index: Ac1bpKnWlbRyM2odT3OuWNp8zDcsxA== Date: Fri, 6 Jul 2012 18:25:33 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436657A222@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-02.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 18:25:23 -0000 Hi Juraj, Looking at this again, it seems to me that because JWE provides integrity p= rotection for the algorithm, it should be impossible for you to replace "RS= A-OAEP" with "RSA1_5" in the header because then the integrity check will f= ail. Thus, the attack that you describe below is prevented by the integrit= y protection of the header. Hence, correct JWE implementations do no provide the OAEP decryption oracle= that you describe. However if I'm missing something, please point it out = to me, since if there's an issue, I'd like to understand it and how to miti= gate it. Best wishes, -- Mike P.S. Can you provide me a good reference or two that you'd suggest that I = cite for countermeasures to Bleichenbacher's attack? -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jur= aj Somorovsky Sent: Monday, May 14, 2012 5:16 AM To: internet-drafts@ietf.org Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-02.txt Hi, I just wanted to mention that I am still against the usage of PKCS1 v1.5 in= the specification (which is vulnerable to the Bleichenbacher's attack). Th= ere are two more motivations to omit it: 1) If you have a server, which has a vulnerable RSA1_5 implementation (this= is e.g. the case in NimbusJWT as described in this thread: http://www.mail-archive.com/jose@ietf.org/msg00157.html), you can use this = server also to decrypt messages encrypted with RSA-OAEP. You just have to t= ake the original message and replace the "alg" header parameter value "RSA-= OAEP" with the value "RSA1_5". This way, you can force the server to act as= an RSA1_5 oracle and decrypt also the message encrypted with RSA-OAEP (you= just need more oracle queries). (tested with NimbusJWT) 2) The next motivation is the work by Bardou, Focard, Kawamoto, Steel, and = Tsay (http://hal.inria.fr/docs/00/69/19/58/PDF/RR-7944.pdf), who improved t= he Bleichenbacher's attack and made it even more practical. I would thus propose to remove RSA1_5. Otherewise, also the clients' messages using RSA-OAEP will be vulnerable to the Bleichenbacher's attack. If you want to leave RSA1_5 in your standard, I would propose to explicitly= include the information about the countermeasures to the Bleichenbacher's = attack and a notice that RSA-OAEP should not be used with the same key as R= SA1_5. Thanks Regards Juraj On 05/13/2012 01:45 AM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Javascript Object Signing and Encry= ption Working Group of the IETF. >=20 > Title : JSON Web Algorithms (JWA) > Author(s) : Michael B. Jones > Filename : draft-ietf-jose-json-web-algorithms-02.txt > Pages : 26 > Date : 2012-05-12 >=20 > The JSON Web Algorithms (JWA) specification enumerates cryptographic > algorithms and identifiers to be used with the JSON Web Signature > (JWS) and JSON Web Encryption (JWE) specifications. >=20 >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-algorithm > s-02.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-jose-json-web-algorithms > -02.txt >=20 > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms/ >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose -- M.Sc. Juraj Somorovsky Lehrstuhl f=FCr Netz- und Datensicherheit Ruhr Universit=E4t Bochum ----------------------------------- Universit=E4tsstr. 150, Geb. ID 2/411 D-44780 Bochum Telefon: +49 (0) 234 / 32-26551 Fax: +49 (0) 234 / 32-14347 http://www.nds.rub.de _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Fri Jul 6 11:27:09 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42BF011E809F for ; Fri, 6 Jul 2012 11:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.764 X-Spam-Level: X-Spam-Status: No, score=-3.764 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5JENVp7G6ZQ for ; Fri, 6 Jul 2012 11:27:08 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1990D11E8079 for ; Fri, 6 Jul 2012 11:27:07 -0700 (PDT) Received: from mail37-db3-R.bigfish.com (10.3.81.252) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 6 Jul 2012 18:25:15 +0000 Received: from mail37-db3 (localhost [127.0.0.1]) by mail37-db3-R.bigfish.com (Postfix) with ESMTP id D6E8916048A; Fri, 6 Jul 2012 18:25:15 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zz98dI9371I542M1432I1447Izz1202hzz1033IL8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail37-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail37-db3 (localhost.localdomain [127.0.0.1]) by mail37-db3 (MessageSwitch) id 1341599115238363_3265; Fri, 6 Jul 2012 18:25:15 +0000 (UTC) Received: from DB3EHSMHS007.bigfish.com (unknown [10.3.81.243]) by mail37-db3.bigfish.com (Postfix) with ESMTP id 3779920049; Fri, 6 Jul 2012 18:25:15 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS007.bigfish.com (10.3.87.107) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 6 Jul 2012 18:25:11 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0298.005; Fri, 6 Jul 2012 18:27:03 +0000 From: Mike Jones To: "Richard L. Barnes" Thread-Topic: Nested JWT (was: Re: [jose] "typ":"JWS") Thread-Index: AQHNW6RTy17iT3k5l0KLVKfXYwOy5pcckmow Date: Fri, 6 Jul 2012 18:27:02 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436657A250@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436657A131@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "Manger, James H" , "jose@ietf.org" Subject: Re: [jose] Nested JWT (was: Re: "typ":"JWS") X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 18:27:09 -0000 I'll reply to this on the OAuth list, since JWT is an OAuth spec. -----Original Message----- From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20 Sent: Friday, July 06, 2012 11:23 AM To: Mike Jones Cc: Manger, James H; jose@ietf.org Subject: Nested JWT (was: Re: [jose] "typ":"JWS") Not sure what the appropriate list is for this, so I'm just going to ask it= here: What is a "nested JWT"? I'm guessing it's a JWT claim set wrapped in JWS m= ultiple times, as in the example we were discussing earlier? Why would you want to do that instead of having parallel signatures? On Jul 6, 2012, at 2:19 PM, Mike Jones wrote: > Thanks for the thought on this, James. > =20 > In the -03 drafts there is now a clear distinction between "typ" (type) -= information about this object and the new "cty" (content type) - informati= on about the secured object. Besides being semantically cleaner, this also= simplified nested JWTs. > =20 > I then was able to make changes in the spirit of the ones you suggested b= elow, although using slightly different wording in some cases. > =20 > --=20 > Mike > =20 > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > Sent: Tuesday, May 15, 2012 5:40 PM > To: Mike Jones; jose@ietf.org > Subject: RE: "typ":"JWS" > =20 > >> draft-ietf-jose-json-web-signature-02 =A77.2 registers the "JWS" type= =20 > >> value (for the "typ" header field) . Perhaps "typ":"JWS" is more=20 > >> useful in a JWE header when encrypting signed content (sign-then-encry= pt). If this is the intention, then mentioning the "JWS" type value when de= fining the "typ" header for a JWS is misleading. It would be better to ment= ion it where the JWE spec defines "typ". > >> . > =20 > > Your second paragraph correctly describes the intended usage. For inst= ance, see http://tools.ietf.org/html/draft-jones-json-web-token-10#section-= 5.1 for this usage in action. The value is registered per the working grou= p decision relating "typ" values to MIME types. > =20 > Good. So let's say that. Suggested text changes: > =20 > * draft-ietf-jose-json-web-signature-02, section 4.1.8 "typ" (Type) Heade= r Parameter: delete the 2nd sentence because signing a signature is not wha= t we are talking about (and JWS-JS recommends a different approach for mult= iple signatures anyway). > =20 > * section 7.1 Registration of application/jws MIME Media Type: add a phra= se explicitly stating the syntax (since the spec mentions two: compact, and= JWS JS) so the section says: > This specification registers the "application/jws" MIME Media Type [RFC= 2045] > to identify content that uses the JWS compact serialization. > =20 > * section 7.2 Registration of "JWS" Type Value: mention the intended use = of encrypting signed content by adding this sentence. > The "typ" parameter can be set to "JWS" in a JSON Web Encryption [JWE] = header when encrypting signed content. > =20 > * draft-ietf-jose-json-web-encryption-02, section 4.1.13 "typ" (Type) Hea= der Parameter, section 11.1 Registration of application/jwe MIME Media Type= , section 11.2 Registration of "JWE" type Value: make equivalent changes. > =20 > -- > James Manger > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From rbarnes@bbn.com Fri Jul 6 11:34:31 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20E821F864C for ; Fri, 6 Jul 2012 11:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.543 X-Spam-Level: X-Spam-Status: No, score=-106.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kM4LbT0xJPMc for ; Fri, 6 Jul 2012 11:34:31 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C65A221F8637 for ; Fri, 6 Jul 2012 11:34:30 -0700 (PDT) Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:61740) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SnDMb-000EGC-Ek; Fri, 06 Jul 2012 14:34:45 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436657A1B2@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 6 Jul 2012 14:34:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B16804296739436657A1B2@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1278) Cc: "Manger, James H" , "jose@ietf.org" Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 18:34:31 -0000 There are obviously examples on both sides. Parameters that restrict = validity have to be understood, parameters that increase availability or = otherwise help out can be safely ignored. Cf. critical vs. non-critical = extensions in X.509. ISTM that there are basically three design options: 1. Require that implementations MUST ignore unknown fields 2. Require that implementations MUST reject an object with an unknown = field 3. Add an extension system like PKIX has, where individual extensions = can be critical or not. For example: { ... "ext1": "val1", "ext2": "val2", "critical": ["ext2"], } Option (2) really just ensures that the current format has *no* = extensibility; option (1) at least allows for "permissive" extensions. = The choice we make now depends on whether we think there's a lot of = "restrictive" extensions coming. If so, then we should do option (3). = If not, then we should do option (1) for now, with a note that you = should only do permissive extensions. If there's a need for (3) later, = it can be added in a new version of the format. --Richard On Jul 6, 2012, at 2:22 PM, Mike Jones wrote: > Since this is a security protocol, the way I see it, use of a = not-understood parameter SHOULD break implementations if they=92re not = prepared to handle them (or at least them cause them to reject the = input). For example, if we hypothetically added an audience restriction = parameter, ignoring it would be a security error. (The need for = audience restriction is being heavily discussed in the OAuth WG right = now, and real exploits that have occurred for the lack of it, so this = example is real and fresh on my mind.) If not understood, a token = containing an audience restriction MUST be rejected. > =20 > On your second point, I don=92t think the working group wanted to = recreate the whole of certificate semantics in JSON. Hence the = intentionally limited capabilities of JWK, for instance. Those = limitations even made it into the WG charter. But if you want to = propose specific certificate-related additions to the WG, have at it. > =20 > -- = Mike > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Manger, James H > Sent: Tuesday, May 15, 2012 7:56 AM > To: jose@ietf.org > Subject: [jose] MUST understand ALL header fields > =20 > draft-ietf-jose-json-web-signature-02 and = draft-ietf-jose-json-web-encryption-02 say: > =20 > Implementations MUST understand the entire contents of the > header; otherwise, the {JWS|JWE} MUST be rejected. > =20 > We should drop this restriction. > =20 > Firstly, most implementations will ignore it. > I had a quick glance at some existing implementations = (magical/jwt-python, markrcote/jwt, jsontoken) and all appear to ignore = this requirement. > It cannot add any security when it is ignored. It does cause massive = compatibility headaches for anyone wanting to define another header = parameter, since a new parameter will break some implementations. > =20 > Secondly, a couple of parameters are defined for X.509 certs, but none = for OCSP responses, CRLs, timestamps etc. It is inevitable that a = cert-based scheme will need these extra pieces of info. With the =93MUST = understand everything=94 rule, we have to define all the extra info that = might be needed right now. > =20 > If we need to be able to break backward compatibility we should define = a mechanism explicitly for that. > =20 > -- > James Manger > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From James.H.Manger@team.telstra.com Sat Jul 7 05:20:37 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7CB21F8661 for ; Sat, 7 Jul 2012 05:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.03 X-Spam-Level: X-Spam-Status: No, score=-1.03 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOPIeUyNzodu for ; Sat, 7 Jul 2012 05:20:36 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 4751921F865A for ; Sat, 7 Jul 2012 05:20:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,543,1336312800"; d="scan'208";a="80093301" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipocni.tcif.telstra.com.au with ESMTP; 07 Jul 2012 22:20:54 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6764"; a="75703654" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcbni.tcif.telstra.com.au with ESMTP; 07 Jul 2012 22:20:53 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Sat, 7 Jul 2012 22:20:52 +1000 From: "Manger, James H" To: Mike Jones , "jose@ietf.org" Date: Sat, 7 Jul 2012 22:20:50 +1000 Thread-Topic: JWK: comments on jku, kid, use, mod.. Thread-Index: Ac1bpJNMzQ175g8/SVKEQMKYXMXfzgAj26Rg Message-ID: <255B9BB34FB7D647A506DC292726F6E114F77C56AD@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739436657A1FB@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436657A1FB@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] JWK: comments on jku, kid, use, mod.. X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2012 12:20:37 -0000 TWlrZSwNCg0KPj4gQSAiamt1IiB2YWx1ZSBpcyBhIFVSTCBwb2ludGluZyB0byBhIDEgb3IgbW9y ZSBKU09OIFdlYiBLZXlzLiBBICJraWQiIHZhbHVlIChrZXkgaWQpIGlzIHJlYWxseSBuZWVkZWQg dG8gcGljayB0aGUgcmlnaHQga2V5IGZyb20gdGhlIHNldC4gQ29uc2VxdWVudGx5IHRoZSBzcGVj IHNob3VsZCBzYXkgW2luIEpXUyBzZWN0aW9uIDQuMS4yICJqa3UiIChKV0sgU2V0IFVSTCkgSGVh ZGVyIFBhcmFtZXRlcl06DQo+Pg0KPj7CoMKgwqAgUHJvZHVjZXJzIE1VU1QgaW5jbHVkZSBhICJr aWQiIHBhcmFtZXRlciB3aGVuIGluY2x1ZGluZyBhICJqa3UiIHBhcmFtZXRlci4NCg0KPiBQZXIg dGhlIG5ldyB0ZXh0IGluIFNlY3Rpb24gNC4zLCB0aGVyZSBhcmUgbWFueSBwb3RlbnRpYWwgd2F5 cyBmb3IgYXBwbGljYXRpb25zIHRvIHNlbGVjdCB0aGUgcmlnaHQga2V5KHMpLCBpbmNsdWRpbmcg dGhlIOKAnHVzZeKAnSBwYXJhbWV0ZXIsIHRoZSDigJxhbGfigJ0gcGFyYW1ldGVyLCBhbmQgeWVz LCB0aGUg4oCca2lk4oCdIHBhcmFtZXRlci7CoCBBcHBsaWNhdGlvbnMgY2FuIGFsc28gc2ltcGx5 IHRyeSBhbGwgdGhlIGtleXMgYW5kIHNlZSBpZiBhbnkgb2YgdGhlbSB3b3JrLsKgIEFzIHN1Y2gs IG1hbmRhdGluZyB0aGUgdXNlIG9mIHRoZSDigJxraWTigJ0gcGFyYW1ldGVyIHdoZW4gb25lIGlz IG9mdGVuIG5vdCBuZWVkZWQsIHdvdWxkIGJlIG92ZXJraWxsLg0KDQoNCj4gdHJ5IGFsbCB0aGUg a2V5cyBhbmQgc2VlIGlmIGFueSBvZiB0aGVtIHdvcmsNCg0KV2hhdCEhDQpJbiBhIEpXUywgdGhl IHNpZ25lciBrbm93cyB0aGUgcmlnaHQgdmVyaWZpY2F0aW9uIGtleSBzbyBpdCBzaG91bGQgdW5h bWJpZ3VvdXNseSBpZGVudGlmeSBpdC4gIEp1c3QgcG9pbnRpbmcgdG8gYSBzZXQgb2Yga2V5cyBh bmQgc2F5aW5nICJpdHMgb25lIG9mIHRob3NlLCB5b3Ugd29yayBpdCBvdXQiIGlzIHNpbGx5Lg0K DQpXaGVuIGNyZWF0aW5nIGEgSldFIGFuIGFwcCBjYW4gdXNlICJhbGciIGFuZCAidXNlIiB0byBw aWNrIGEgcHVibGljIGtleSBmb3IgYSByZWNpcGllbnQgKGFzc3VtaW5nIGl0IGhhcyBhIGprdSBV UkkgZm9yIHRoZSByZWNpcGllbnQgLS0gdGhvdWdoIGhvdyBpdCBnZXRzIHRoYXQgaXMgcHJvYmFi bHkgb3V0LW9mLXNjb3BlIGZvciB0aGUgSldFIG1lc3NhZ2Ugc3ludGF4KS4gVGhlIHNlbmRlciBz aG91bGQgdGVsbCB0aGUgcmVjaXBpZW50IHdoaWNoIHNwZWNpZmljIGtleSBpdCBjaG9zZS4gVXNp bmcgdGhlIHJlY2lwaWVudCdzIGxhYmVscyBmb3IgaXRzIG93biBrZXkgKGllIHRoZSBraWQgdmFs dWUpIHNvdW5kcyBsaWtlIGEgc2Vuc2libGUgY2hvaWNlLg0KDQoNCiAgIEtleSBJRCB2YWx1ZXMg d2l0aGluIGEgSldLIFNldCBuZWVkIG5vdCBiZSB1bmlxdWU7IGZvcg0KICAgaW5zdGFuY2UsIGlu IHNvbWUgY29udGV4dHMgZGlmZmVyZW50IGtleXMgdXNpbmcgdGhlIHNhbWUgS2V5IElEIHZhbHVl DQogICBtaWdodCBiZSBwcmVzZW50LCB3aXRoIHRoZSBrZXlzIGJlaW5nIGRpc2FtYmlndWF0ZWQg dXNpbmcgb3RoZXINCiAgIGluZm9ybWF0aW9uLCBzdWNoIGFzIHRoZSAiYWxnIiBvciAidXNlIiB2 YWx1ZXMuDQogICBbZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS0wM10NCg0KQWxsb3dpbmcg dGhlIHNhbWUga2lkIHRvIGJlIHVzZWQgZm9yIG11bHRpcGxlIGtleXMgZGVmZWF0cyB0aGUgcG9p bnQgb2YgdGhlIGZpZWxkLiBUaGlzIGlzIGEgY29tcGxldGVseSB1bm5lY2Vzc2FyeSBkZWdyZWUg b2YgZnJlZWRvbS4NCg0KDQo+PiAiamt1IiBtYWtlcyBzZW5zZSBmb3IgYSBKV1MgLS0gdGhlIHJl Y2VpdmVyIHVzZXMgdGhlICJqa3UiIFVSTCB0byBnZXQgdGhlIHB1YmxpYyBrZXkgdG8gdmVyaWZ5 IHRoZSBKV1Mgc2lnbmF0dXJlLiBJJ20gbm90IHN1cmUgaXQgbWFrZXMgc2Vuc2UgaW4gYSBKV0Us IHRob3VnaC4gVGhlIHJlY2VpdmVyIG5lZWRzIGEgcHJpdmF0ZSBrZXkgdG8gZGVjcnlwdCwgbm90 IHRoZSBwdWJsaWMga2V5IHRoYXQgImprdSIgcG9pbnRzIHRvLiBBdCBiZXN0LCAiamt1IiBpbiBh IEpXRSBhY3RzIGFzIGFuIGtleSBpZCAtLSBidXQgd2UgaGF2ZSBhIHNlcGFyYXRlICJraWQiIGZp ZWxkLiBJIHRoaW5rIHdlIHNob3VsZCBkcm9wIHRoZSAiamt1IiBwYXJhbWV0ZXIgZnJvbSB0aGUg SldFIHNwZWMuDQoNCj4gWW914oCZcmUgY29ycmVjdCBhYm91dCB0aGUgZGlmZmVyZW5jZSBiZXR3 ZWVuIHVzZXMgZm9yIEpXUyBhbmQgSldFLsKgIFBlciBhIGNvbW1lbnQgZnJvbSBKaW0gU2NoYWFk LCBhZGRlZCB0aGUgbGFuZ3VhZ2Ug4oCcdGhpcyBjYW4gYmUgdXNlZCB0byBkZXRlcm1pbmUgdGhl IHByaXZhdGUga2V5IG5lZWRlZCB0byBkZWNyeXB0IHRoZSBKV0XigJ0uDQoNCmprdSBjYW5ub3Qg YmUgdXNlZCB0byAiZGV0ZXJtaW5lIHRoZSBwcml2YXRlIGtleSBuZWVkZWQiIHNpbmNlIGl0IHBv aW50cyB0byBhIHNldCBvZiBrZXlzLCBub3QgYSBzcGVjaWZpYyBrZXkuIA0KDQpJZiB5b3UgcmVh bGx5IHdhbnQgdG8gdXNlIGprdSwgaW5zdGVhZCBvZiBraWQsIHBlcmhhcHMgd2UgbmVlZCB0byBk ZWZpbmUgYSBmcmFnbWVudCBpZCBmb3Igamt1IFVSSXMgdG8gaWRlbnRpZnkgb25lIGtleSBpbiB0 aGUgc2V0Lg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From James.H.Manger@team.telstra.com Sat Jul 7 07:29:43 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDC121F85B1 for ; Sat, 7 Jul 2012 07:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.026 X-Spam-Level: X-Spam-Status: No, score=-1.026 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZLcwWBRJ3Vm for ; Sat, 7 Jul 2012 07:29:42 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id E864021F85A3 for ; Sat, 7 Jul 2012 07:29:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,543,1336312800"; d="scan'208,217";a="81252892" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 08 Jul 2012 00:30:00 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6764"; a="74681006" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcdvi.tcif.telstra.com.au with ESMTP; 08 Jul 2012 00:29:58 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Sun, 8 Jul 2012 00:29:46 +1000 From: "Manger, James H" To: Mike Jones , "jose@ietf.org" Date: Sun, 8 Jul 2012 00:29:45 +1000 Thread-Topic: "typ":"JWS" Thread-Index: Ac1bo+eR3uJ/e84/QIKtmQBKUu+SSwAm+2AQ Message-ID: <255B9BB34FB7D647A506DC292726F6E114F77C56B0@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739436657A131@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436657A131@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E114F77C56B0WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [jose] "typ":"JWS" X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2012 14:29:43 -0000 --_000_255B9BB34FB7D647A506DC292726F6E114F77C56B0WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCcdHlw4oCdIGlzIHN0aWxsIGNvbmZ1c2luZy4gVGhlIGRlZmluaXRpb24gaXM6DQoNCiAgVGhl ICJ0eXAiICh0eXBlKSBoZWFkZXIgcGFyYW1ldGVyIGlzIHVzZWQgdG8gZGVjbGFyZQ0KIHRoZSB0 eXBlIG9mIHRoaXMgb2JqZWN0Lg0KDQpGaXJzdCBhIG1pbm9yIGlzc3VlLiBEb2VzIOKAnHRoaXMg b2JqZWN04oCdIHJlZmVyIHRvIHRoZSBKU09OIG9iamVjdCB0aGF0IGhvbGRzIHRoZSDigJx0eXDi gJ0gZmllbGQsIG9yIHRoZSBiaWdnZXIgZG90LXNlcGFyYXRlZC1iYXNlNjQtYmxvYnMgaXQgaXMg cGFydCBvZiwgb3IgYW4gZXZlbiBoaWdoZXItbGV2ZWwgYXBwbGljYXRpb24tc3BlY2lmaWMgdGhp bmc/DQoNClRoZSBKV0UgYW5kIEpXUyBzcGVjcyBzYXksIHJlc3BlY3RpdmVseSwg4oCcdHlw4oCd OuKAnUpXReKAnSBhbmQg4oCcdHlw4oCdOuKAnUpXU+KAnSBNQVkgYmUgdXNlZC4NClRoaXMgYWxt b3N0IHN1Z2dlc3RzIHlvdSBjYW4gdXNlIHRoZSDigJx0eXDigJ0gZmllbGQgdG8gZGlzdGluZ3Vp c2ggd2hldGhlciB5b3UgaGF2ZSBhIEpXRSBvciBKV1Mgb3Igc29tZSBvdGhlciBmdXR1cmUgdmFy aWV0eSBvZiBKT1NFIG1lc3NhZ2UgKHBsYWluLCBjaGVja3N1bW1lZOKApikg4oCUIGluc3RlYWQg b2YgbmVlZGluZyB0byByZWNvZ25pemUgdGhlIOKAnGFsZ+KAnSB2YWx1ZS4gVGhhdCBkb2VzbuKA mXQgd29yayBob3dldmVyLiBGaXJzdGx5LCDigJx0eXDigJ0gaXMgT1BUSU9OQUwuIFNlY29uZGx5 LCBldmVuIHdoZW4g4oCcdHlw4oCdIGlzIHByZXNlbnQgaW4gYSBKV0UgbWVzc2FnZSwgaXRzIHZh bHVlIE1BWSBiZSDigJxKV0XigJ0g4oCUIG5vdCBNVVNULiBUaGUg4oCcdHlw4oCdIHZhbHVlIE1B WSBhbHNvIGJlIGEgbWVkaWEgdHlwZSAocGVyaGFwcyDigJx0eXDigJ064oCdYXBwbGljYXRpb24v andl4oCdPyksIG9yIGEgdmFsdWUgdGhhdCBTSE9VTEQgYmUgcmVnaXN0ZXJlZCwgb3IgYW55IGFy Yml0cmFyeSBVUkkuDQoNClRoZSBKV1Qgc3BlYyBbZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10 b2tlbi0wMV0gdGhlbiBSRUNPTU1FTkRTIHRoYXQg4oCcdHlw4oCdOuKAnUpXVOKAnSBiZSB1c2Vk ICppbiBhIEpXRSBvciBKV1MgaGVhZGVyKi4NCg0KU28gaW4gYSBKV0UgbWVzc2FnZSwgd2hlbiBk byB5b3UgdXNlIOKAnHR5cOKAnTrigJ1KV0XigJ0sIHdoZW4gZG8geW91IHVzZSDigJx0eXDigJ06 4oCdSldU4oCdLCBhbmQgd2hlbiBkbyB5b3Ugb21pdCBpdD8NCg0KDQpUaGUgZm9sbG93aW5nIG1h a2Ugc2Vuc2UgdG8gbWUsIGJ1dCBhcmUgbm90IHdoYXQgaXMgc3BlY2lmaWVkOg0KMSogVGhlIGhl YWRlciBmb3IgYSBzaWduZWQgc2V0IG9mIGNsYWltczoNCiAgICAgIHsg4oCcdHlw4oCdOuKAnUpX U+KAnSwg4oCcY3R54oCdOuKAnUpXVOKAnSwg4oCcYWxn4oCdOuKAnUhTMjU24oCdLCDigKZ9DQoy KiBUaGUgaGVhZGVyIGZvciBhbiBlbmNyeXB0ZWQgc2V0IG9mIGNsYWltczoNCiAgICAgIHsg4oCc dHlw4oCdOuKAnUpXReKAnSwg4oCcY3R54oCdOuKAnUpXVOKAnSwg4oCcYWxn4oCdOuKAnVJTQS1P QUVQ4oCdLCDigKZ9DQozKiBUaGUgaGVhZGVyIGZvciBhIHNpZ25lZC10aGVuLWVuY3J5cHRlZCBz ZXQgb2YgY2xhaW1zOg0KICAgICAgeyDigJx0eXDigJ064oCdSldF4oCdLCDigJxjdHnigJ064oCd SldT4oCdLCDigJxhbGfigJ064oCdUlNBLU9BRVDigJ0sIOKApn0NCjNiKiBUaGVuIGFmdGVyIGRl Y3J5cHRpbmcgdGhlIGNpcGhlcnRleHQgeW91IHNlZSB0aGUgaGVhZGVyOg0KICAgICAgeyDigJx0 eXDigJ064oCdSldT4oCdLCDigJxjdHnigJ064oCdSldU4oCdLCDigJxhbGfigJ064oCdSFMyNTbi gJ0sIOKApn0NCg0KDQpUaGVyZSBhcmUgMyBwaWVjZXMgb2YgaW5mb3JtYXRpb24gd2UgbmVlZCBp biBhIEpPU0UgbWVzc2FnZSBpbiB0aGlzIGFyZWE6DQoxKiBXaGljaCB2YXJpZXR5IG9mIEpPU0Ug bWVzc2FnZSBpcyB0aGlzOiBzaWduZWQsIGVuY3J5cHRlZCwgdW5wcm90ZWN0ZWQsIG9yIHNvbWUg ZnV0dXJlIHZhcmlldHk/DQoyKiBJcyB0aGVyZSBhbm90aGVyIEpPU0UgbGF5ZXIgYWZ0ZXIgdGhp cyBvbmUgKGVnIHNpZ25lZC10aGVuLWVuY3J5cHRlZCBhcyAyIEpPU0UgbGF5ZXJzKT8NCjMqIE9w dGlvbmFsbHksIG1ldGFkYXRhIGFib3V0IHRoZSBmaW5hbCBjb250ZW50IChlZyBtZWRpYSB0eXBl KS4NCg0K4oCcY3R54oCdIGZpdHMgaW50byAjMy4g4oCcY3R54oCdIGNvdWxkIGFsbW9zdCAoYnV0 IHBvb3JseSkgZml0ICMyIGlmIGl0IHdhcyBSRVFVSVJFRCB3aGVuIHRoZXJlIGlzIGFub3RoZXIg Sk9TRSBsYXllciBhbmQgdGhlIEpPU0UgY29udGVudC10eXBlcyB3ZXJlIGVhc2lseSBkaXN0aW5n dWlzaGVkIGZyb20gYW55IG90aGVyIGNvbnRlbnQgdHlwZS4gQSBzZXBhcmF0ZSBmbGFnIHdvdWxk IGJlIGEgYmV0dGVyIGZpdCBmb3IgIzIgKGVnIOKAnGVtYuKAnTp0cnVlKS4gU29tZSB2YWx1ZXMg b2Yg4oCcdHlw4oCdIGZpdCAjMSwgYnV0IG5vdCBpbiBnZW5lcmFsLg0KDQotLQ0KSmFtZXMgTWFu Z2VyDQoNCkZyb206IE1pa2UgSm9uZXMgW21haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b21dDQpTZW50OiBTYXR1cmRheSwgNyBKdWx5IDIwMTIgNDoyMCBBTQ0KVG86IE1hbmdlciwgSmFt ZXMgSDsgam9zZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6ICJ0eXAiOiJKV1MiDQoNClRoYW5rcyBm b3IgdGhlIHRob3VnaHQgb24gdGhpcywgSmFtZXMuDQoNCkluIHRoZSAtMDMgZHJhZnRzIHRoZXJl IGlzIG5vdyBhIGNsZWFyIGRpc3RpbmN0aW9uIGJldHdlZW4g4oCcdHlw4oCdICh0eXBlKSAtIGlu Zm9ybWF0aW9uIGFib3V0IHRoaXMgb2JqZWN0IGFuZCB0aGUgbmV3IOKAnGN0eeKAnSAoY29udGVu dCB0eXBlKSDigJMgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHNlY3VyZWQgb2JqZWN0LiAgQmVzaWRl cyBiZWluZyBzZW1hbnRpY2FsbHkgY2xlYW5lciwgdGhpcyBhbHNvIHNpbXBsaWZpZWQgbmVzdGVk IEpXVHMuDQoNCkkgdGhlbiB3YXMgYWJsZSB0byBtYWtlIGNoYW5nZXMgaW4gdGhlIHNwaXJpdCBv ZiB0aGUgb25lcyB5b3Ugc3VnZ2VzdGVkIGJlbG93LCBhbHRob3VnaCB1c2luZyBzbGlnaHRseSBk aWZmZXJlbnQgd29yZGluZyBpbiBzb21lIGNhc2VzLg0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQo= --_000_255B9BB34FB7D647A506DC292726F6E114F77C56B0WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjojMDAzMzY2O30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQ YXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsN CgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNt Ow0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4u QmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMDAyMDYwO30NCnNwYW4uRW1haWxTdHls ZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0 ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBw dCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9o ZWFkPjxib2R5IGxhbmc9RU4tQVUgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdv cmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0Qn PuKAnHR5cOKAnSBpcyBzdGlsbCBjb25mdXNpbmcuIFRoZSBkZWZpbml0aW9uIGlzOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J3BhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+wqAgVGhlICZxdW90O3R5cCZx dW90OyAodHlwZSkgaGVhZGVyIHBhcmFtZXRlciBpcyB1c2VkIHRvIGRlY2xhcmU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7Y29sb3I6YmxhY2snPiDCoHRoZSB0eXBlIG9mIHRoaXMgb2JqZWN0LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOiMxRjQ5N0QnPkZpcnN0IGEgbWlub3IgaXNzdWUuIERvZXMg4oCcdGhpcyBvYmpl Y3TigJ0gcmVmZXIgdG8gdGhlIEpTT04gb2JqZWN0IHRoYXQgaG9sZHMgdGhlIOKAnHR5cOKAnSBm aWVsZCwgb3IgdGhlIGJpZ2dlciBkb3Qtc2VwYXJhdGVkLWJhc2U2NC1ibG9icyBpdCBpcyBwYXJ0 IG9mLCBvciBhbiBldmVuIGhpZ2hlci1sZXZlbCBhcHBsaWNhdGlvbi1zcGVjaWZpYyB0aGluZz88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5UaGUgSldFIGFuZCBKV1Mgc3BlY3Mgc2F5LCBy ZXNwZWN0aXZlbHksIOKAnHR5cOKAnTrigJ1KV0XigJ0gYW5kIOKAnHR5cOKAnTrigJ1KV1PigJ0g TUFZIGJlIHVzZWQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6IzFGNDk3RCc+VGhpcyBhbG1vc3Qgc3VnZ2VzdHMgeW91IGNhbiB1c2Ug dGhlIOKAnHR5cOKAnSBmaWVsZCB0byBkaXN0aW5ndWlzaCB3aGV0aGVyIHlvdSBoYXZlIGEgSldF IG9yIEpXUyBvciBzb21lIG90aGVyIGZ1dHVyZSB2YXJpZXR5IG9mIEpPU0UgbWVzc2FnZSAocGxh aW4sIGNoZWNrc3VtbWVk4oCmKSDigJQgaW5zdGVhZCBvZiBuZWVkaW5nIHRvIHJlY29nbml6ZSB0 aGUg4oCcYWxn4oCdIHZhbHVlLiBUaGF0IGRvZXNu4oCZdCB3b3JrIGhvd2V2ZXIuIEZpcnN0bHks IOKAnHR5cOKAnSBpcyBPUFRJT05BTC4gU2Vjb25kbHksIGV2ZW4gd2hlbiDigJx0eXDigJ0gaXMg cHJlc2VudCBpbiBhIEpXRSBtZXNzYWdlLCBpdHMgdmFsdWUgTUFZIGJlIOKAnEpXReKAnSDigJQg bm90IE1VU1QuIFRoZSDigJx0eXDigJ0gdmFsdWUgTUFZIGFsc28gYmUgYSBtZWRpYSB0eXBlIChw ZXJoYXBzIOKAnHR5cOKAnTrigJ1hcHBsaWNhdGlvbi9qd2XigJ0/KSwgb3IgYSB2YWx1ZSB0aGF0 IFNIT1VMRCBiZSByZWdpc3RlcmVkLCBvciBhbnkgYXJiaXRyYXJ5IFVSSS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjojMUY0OTdEJz5UaGUgSldUIHNwZWMgW2RyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWIt dG9rZW4tMDFdIHRoZW4gUkVDT01NRU5EUyB0aGF0IOKAnHR5cOKAnTrigJ1KV1TigJ0gYmUgdXNl ZCAqPGI+aW4gYSBKV0Ugb3IgSldTIGhlYWRlcjwvYj4qLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMx RjQ5N0QnPlNvIGluIGEgSldFIG1lc3NhZ2UsIHdoZW4gZG8geW91IHVzZSDigJx0eXDigJ064oCd SldF4oCdLCB3aGVuIGRvIHlvdSB1c2Ug4oCcdHlw4oCdOuKAnUpXVOKAnSwgYW5kIHdoZW4gZG8g eW91IG9taXQgaXQ/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3 RCc+VGhlIGZvbGxvd2luZyBtYWtlIHNlbnNlIHRvIG1lLCBidXQgYXJlIG5vdCB3aGF0IGlzIHNw ZWNpZmllZDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjojMUY0OTdEJz4xKiBUaGUgaGVhZGVyIGZvciBhIHNpZ25lZCBzZXQgb2YgY2xh aW1zOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOiMxRjQ5N0QnPsKgwqDCoMKgwqAgeyDigJx0eXDigJ064oCdSldT4oCdLCDigJxjdHni gJ064oCdSldU4oCdLCDigJxhbGfigJ064oCdSFMyNTbigJ0sIOKApn08bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4yKiBU aGUgaGVhZGVyIGZvciBhbiBlbmNyeXB0ZWQgc2V0IG9mIGNsYWltczo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz7CoMKg wqDCoCDCoHsg4oCcdHlw4oCdOuKAnUpXReKAnSwg4oCcY3R54oCdOuKAnUpXVOKAnSwg4oCcYWxn 4oCdOuKAnVJTQS1PQUVQ4oCdLCDigKZ9PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+MyogVGhlIGhlYWRlciBmb3IgYSBz aWduZWQtdGhlbi1lbmNyeXB0ZWQgc2V0IG9mIGNsYWltczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz7CoMKgwqDCoCDC oHsg4oCcdHlw4oCdOuKAnUpXReKAnSwg4oCcY3R54oCdOuKAnUpXU+KAnSwg4oCcYWxn4oCdOuKA nVJTQS1PQUVQ4oCdLCDigKZ9PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+M2IqIFRoZW4gYWZ0ZXIgZGVjcnlwdGluZyB0 aGUgY2lwaGVydGV4dCB5b3Ugc2VlIHRoZSBoZWFkZXI6PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+wqDCoMKgwqAgwqB7 IOKAnHR5cOKAnTrigJ1KV1PigJ0sIOKAnGN0eeKAnTrigJ1KV1TigJ0sIOKAnGFsZ+KAnTrigJ1I UzI1NuKAnSwg4oCmfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5 N0QnPlRoZXJlIGFyZSAzIHBpZWNlcyBvZiBpbmZvcm1hdGlvbiB3ZSBuZWVkIGluIGEgSk9TRSBt ZXNzYWdlIGluIHRoaXMgYXJlYTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4xKiBXaGljaCB2YXJpZXR5IG9mIEpPU0Ug bWVzc2FnZSBpcyB0aGlzOiBzaWduZWQsIGVuY3J5cHRlZCwgdW5wcm90ZWN0ZWQsIG9yIHNvbWUg ZnV0dXJlIHZhcmlldHk/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+MiogSXMgdGhlcmUgYW5vdGhlciBKT1NFIGxheWVy IGFmdGVyIHRoaXMgb25lIChlZyBzaWduZWQtdGhlbi1lbmNyeXB0ZWQgYXMgMiBKT1NFIGxheWVy cyk/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6IzFGNDk3RCc+MyogT3B0aW9uYWxseSwgbWV0YWRhdGEgYWJvdXQgdGhlIGZpbmFsIGNv bnRlbnQgKGVnIG1lZGlhIHR5cGUpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPuKAnGN0 eeKAnSBmaXRzIGludG8gIzMuIOKAnGN0eeKAnSBjb3VsZCBhbG1vc3QgKGJ1dCBwb29ybHkpIGZp dCAjMiBpZiBpdCB3YXMgUkVRVUlSRUQgd2hlbiB0aGVyZSBpcyBhbm90aGVyIEpPU0UgbGF5ZXIg YW5kIHRoZSBKT1NFIGNvbnRlbnQtdHlwZXMgd2VyZSBlYXNpbHkgZGlzdGluZ3Vpc2hlZCBmcm9t IGFueSBvdGhlciBjb250ZW50IHR5cGUuIEEgc2VwYXJhdGUgZmxhZyB3b3VsZCBiZSBhIGJldHRl ciBmaXQgZm9yICMyIChlZyDigJxlbWLigJ06dHJ1ZSkuIFNvbWUgdmFsdWVzIG9mIOKAnHR5cOKA nSBmaXQgIzEsIGJ1dCBub3QgaW4gZ2VuZXJhbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMx RjQ5N0QnPi0tPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6IzFGNDk3RCc+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+PGRpdj48ZGl2IHN0 eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi Jz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBNaWtlIEpvbmVzIFttYWlsdG86 TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tXSA8YnI+PGI+U2VudDo8L2I+IFNhdHVyZGF5LCA3 IEp1bHkgMjAxMiA0OjIwIEFNPGJyPjxiPlRvOjwvYj4gTWFuZ2VyLCBKYW1lcyBIOyBqb3NlQGll dGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSRTogJnF1b3Q7dHlwJnF1b3Q7OiZxdW90O0pXUyZx dW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J2NvbG9yOiMwMDIwNjAnPlRoYW5rcyBmb3IgdGhlIHRob3VnaHQgb24gdGhpcywgSmFt ZXMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdjb2xvcjojMDAyMDYwJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMwMDIwNjAnPklu IHRoZSAtMDMgZHJhZnRzIHRoZXJlIGlzIG5vdyBhIGNsZWFyIGRpc3RpbmN0aW9uIGJldHdlZW4g 4oCcdHlw4oCdICh0eXBlKSAtIGluZm9ybWF0aW9uIGFib3V0IHRoaXMgb2JqZWN0IGFuZCB0aGUg bmV3IOKAnGN0eeKAnSAoY29udGVudCB0eXBlKSDigJMgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHNl Y3VyZWQgb2JqZWN0LiZuYnNwOyBCZXNpZGVzIGJlaW5nIHNlbWFudGljYWxseSBjbGVhbmVyLCB0 aGlzIGFsc28gc2ltcGxpZmllZCBuZXN0ZWQgSldUcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMwMDIwNjAnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nY29sb3I6IzAwMjA2MCc+SSB0aGVuIHdhcyBhYmxlIHRvIG1ha2UgY2hhbmdl cyBpbiB0aGUgc3Bpcml0IG9mIHRoZSBvbmVzIHlvdSBzdWdnZXN0ZWQgYmVsb3csIGFsdGhvdWdo IHVzaW5nIHNsaWdodGx5IGRpZmZlcmVudCB3b3JkaW5nIGluIHNvbWUgY2FzZXMuPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdj b2xvcjojMDAyMDYwJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9yOiMwMDIwNjAnPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_255B9BB34FB7D647A506DC292726F6E114F77C56B0WSMSG3153Vsrv_-- From ietf@augustcellars.com Sun Jul 8 15:57:18 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED59121F875E for ; Sun, 8 Jul 2012 15:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.226 X-Spam-Level: X-Spam-Status: No, score=-3.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9j5d6WKOhpO2 for ; Sun, 8 Jul 2012 15:57:17 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id ECCE121F875D for ; Sun, 8 Jul 2012 15:57:13 -0700 (PDT) Received: from Tobias (50-39-234-129.bvtn.or.frontiernet.net [50.39.234.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id D2EFF2CA1E; Sun, 8 Jul 2012 15:57:35 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , "'Sean Turner'" References: <4E1F6AAD24975D4BA5B168042967394366579F40@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366579F40@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Sun, 8 Jul 2012 15:55:26 -0700 Message-ID: <001b01cd5d5c$e2c35940$a84a0bc0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01CD5D22.36665600" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKMlqi8yA9kD7Vv49OkQjPMmkyAFJWf87HA Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 22:57:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001C_01CD5D22.36665600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Comments below From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Friday, July 06, 2012 10:33 AM To: Sean Turner Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt Thanks for taking the time to provide the detailed feedback. Responses inline. -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Sean Turner Sent: Monday, May 28, 2012 10:36 AM Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt Here's some comments (again I'll try not to duplicate Jim's): 1) s2 & Requirements Language: The RFC editor is going to move the Requirements Language section later on so you might as well save them the trouble and just make it part of s2. Done here, plus in JWE, JWS, JWA, JWT, JWE-JS, JWS-JS, and SWD 2) s3: This is probably a style thing, but I think it's probably better to talk about the structure first and then provide an example. It's just going to make everybody ask you to define/explain x in that section. I tried to do this and couldn't find a better location. The spec is so short, that you're never more than a page from the example to the normative text anyway. :-) Besides, given that all the meaty parts (the actual algorithm specifications) have moved to the JWA spec, the descriptions would probably be pretty abstract without an example to root them in. Left as is, at least for now. 3) s4: Totally agree with Jim's comment #4 on this section. Applies to s5 as well. Addressed, per Jim's comments 4) s4: Same concerns as for algorithms about the collision resistant namespace and how the registry is set up. Addressed, per Jim's comments 5) s4.2: Assume "both" should be defined here. At least for Elliptic Curve keys, I believe that there's a potential vulnerability with using the same key for both signing and encryption. So I'm reluctant to define "both". The simplest way to indicate both may be to omit the parameter. This could also be represented by repeating the key with "use":"sig" and "use":"enc" in the key set. What do others in the working group think about these possibilities? [JLS] If you are asking for input, why is not in the open issues section? 6) s7: If the kid is not supposed to be generated in a way to make it unique it's worth pointing this out in s7. Done [JLS] Please point me to the text that does this. I don't see it. spt _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose ------=_NextPart_000_001C_01CD5D22.36665600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Comments below

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Mike Jones
Sent: Friday, July 06, 2012 10:33 = AM
To: Sean Turner
Cc: = jose@ietf.org
Subject: Re: [jose] I-D Action: = draft-ietf-jose-json-web-key-02.txt

 

Thanks for taking the time to provide the = detailed feedback.  Responses inline…

 

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.= org] On Behalf Of Sean Turner
Sent: Monday, May 28, 2012 10:36 = AM
Cc: jose@ietf.org
Subject: = Re: [jose] I-D Action: = draft-ietf-jose-json-web-key-02.txt

 

Here's = some comments (again I'll try not to duplicate Jim's):

 

1) s2 = & Requirements Language: The RFC editor is going to move the = Requirements Language section later on so you might as well save them = the trouble and just make it part of s2.

 

Done here, plus in = JWE, JWS, JWA, JWT, JWE-JS, JWS-JS, and SWD

 

2) s3: This is probably a style thing, but I think = it's probably better to talk about the structure first and then provide = an example.  It's just going to make everybody ask you to = define/explain x in that section.

 

I tried to do this = and couldn’t find a better location.  The spec is so short, = that you’re never more than a page from the example to the = normative text anyway. :-)  Besides, given that all the meaty parts = (the actual algorithm specifications) have moved to the JWA spec, the = descriptions would probably be pretty abstract without an example to = root them in.  Left as is, at least for = now.

 

3) s4: Totally agree with Jim's comment #4 on this = section.  Applies to

s5 as = well.

 

Addressed, per = Jim’s comments

 

4) s4: = Same concerns as for algorithms about the collision resistant namespace = and how the registry is set up.

 

Addressed, per = Jim’s comments

 

5) = s4.2: Assume "both" should be defined here.

 

At least for Elliptic = Curve keys, I believe that there’s a potential vulnerability with = using the same key for both signing and encryption.  So I’m = reluctant to define “both”.  The simplest way to = indicate both may be to omit the parameter.  This could also be = represented by repeating the key with = “use”:”sig” and = “use”:”enc” in the key set.  What do others = in the working group think about these = possibilities?

 

[JLS]  If you = are asking for input, why is not in the open issues = section?

 

6) s7: = If the kid is not supposed to be generated in a way to make it unique = it's worth pointing this out in s7.

 

Done

 

[JLS] Please point me = to the text that does this.  I don’t see = it.

 

spt

_______________________________________________=

jose mailing list

jose@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/jose

 

------=_NextPart_000_001C_01CD5D22.36665600-- From ietf@augustcellars.com Sun Jul 8 15:57:20 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30FC21F8764 for ; Sun, 8 Jul 2012 15:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.35 X-Spam-Level: X-Spam-Status: No, score=-3.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmcNReFA0JOR for ; Sun, 8 Jul 2012 15:57:14 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 9726221F875B for ; Sun, 8 Jul 2012 15:57:14 -0700 (PDT) Received: from Tobias (50-39-234-129.bvtn.or.frontiernet.net [50.39.234.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id E20222CA21; Sun, 8 Jul 2012 15:57:36 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" References: <4E1F6AAD24975D4BA5B168042967394366579F15@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366579F15@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Sun, 8 Jul 2012 15:56:19 -0700 Message-ID: <002301cd5d5c$e36edb80$aa4c9280$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01CD5D22.37149760" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJX5M/VJt2HR8o6/IyQZq2axBfNmZYJQtVg Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] Comments on draft-ietf-jose-json-web-key-02 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 22:57:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0024_01CD5D22.37149760 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Comments on responses and some additional comments as well. If the security sections references the XML DSig document as having important security considerations, then it needs to be normative and not informative. Jim From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, July 06, 2012 10:31 AM To: Jim Schaad Cc: jose@ietf.org Subject: RE: Comments on draft-ietf-jose-json-web-key-02 Thanks for taking the time to provide the detailed feedback. Responses inline. -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Saturday, May 19, 2012 3:34 PM To: Mike Jones Cc: jose@ietf.org Subject: Comments on draft-ietf-jose-json-web-key-02 My apologies for introducing you to the term algorithm families. We don't use it in the same way and thus I think that you should generally remove it from the text. To me it is a very wide term and somewhat nebulous. Thus I think of all of the DH algorithms as being in a family - but that family could also include the ECDH algorithm as well as DSA depending on how one is using it. Thus for me an algorithm family is not restricted to a specific instance (or small set of instances) such a DH & DSA but could be as large as all key agreement algorithms. As such it does not really match how you are using it in much of the text. Left in for the current draft for lack of a better term. I did remove as many uses of the term as possible. Slightly more detailed: You can define an RSA key You can define an RSA-OAEP key The second one has all of the fields of the first, however it may have additional fields defined that deal specifically with RSA-OAEP. The difference is going to be a question of restriction of usage of the key to a single algorithm vs allowing for all RSA algorithms. Parameters could be defined in the JWA spec to specify parameters enabling those possible restrictions if the working group deems it useful/necessary. The JWK spec already makes it clear that algorithm-specific parameters may be required, so this wouldn't change the model. Here are some more comments Abstract 1. I am not a fan of the word enumerated in the last sentence. This word implies to me that the list is not expandable. I would recommend something along the lines of "An initial set of ... can be found in ..." Done here, plus in JWE, JWS, JWA, JWE-JS, and JWS-JS [JLS] This change was not made in the JWA document. Section 2 1. The phrase "For the purpose of this document" should be removed unless this term is used in other ways elsewhere. Not changed, because in some other contexts, the same term is used to refer to the non URL safe encoding. [JLS] Is it used in a different way in this document? One can automatically assumed that if you are defining a term, that it is for the purposes of this document and, unless generally accepted, is not applicable to other documents. Purely for curiosity, where is the phrase base64url encoding used to mean something else in a different document? Section 4 1. In para #2 - the use of "algorithm family" is incorrect. They members are going to be required for the specific key being represented not to the family - consider the case of RSA and RSA-OAEP - these are both in the same family, but the fields required are different. Reworded to not use the term "algorithm family" [JLS] Suggest "In addition to the common parameters, each JWK will have members that are specific to the key being represented. These members represent the parameters of the key. Section 5 of the JSON Web Algorithm (JWA) specifies a number of public keys and their associated members." 2. Do you believe that all of the algorithm members are defined in the JWA document - or only for some algorithms. Text should probably say they are defined for the algorithms defined for the algorithms in JWA. Done 3. I don't believe that para #3 is enforceable by parsers as they have been presented to me. Please prove me wrong. Section 2.2 of http://tools.ietf.org/html/rfc4627 says "The names within an object SHOULD be unique." So this should be enforced by conforming parsers. I'd be interested in data saying that parsers exist that are non-conforming to this RFC 4627 "SHOULD". If so, we should add appropriate warnings to the Security Considerations section. [JLS] Stating that they should be unique is more of a requirement on the generation side and not the parsing side of the specification. I do not believe that this statement in way says that parsers should reject objects for which duplicate member names exist. 4. Let's look at the sentence "If present, they MUST be understood by implementations using them." I believe that this is an incorrect assertion. (Not to mention that it is totally uncheckable.) Consider the following situation: Implementation A creates a JWK and files it with Implementation B. A does not understand the "exist-date" property. Implementation B adds the "exist-date" property and puts it at a URL. Implementation C pulls the JWK from the URL, understand the "exist-date" property. According to the MUST, the JWK cannot be used as it is not understood by all of the implementations. The only entity that you can make the requirement on is the consumer. One assumes that the "provider" would/might understand the field or it would not be there but it could have been added in transit and thus that is not the case. I believe that for your example, the text is correct as written, since in context, "them" refers to the additional members, not the JWK as a whole. At no point in your example did an implementation use a JWK with an additional member that it did not understand. [JLS] This is precisely the statement that I made above, the mandating that the field is understood by consumers of the JWK is possible, but it is not possible to mandate that all implementations involved in the transaction understand all of the fields. I understand that the assertion may not be enforceable apart from conformance suites that check what implementations do when given new parameters, and I understand that in the general case, programmatic enforcement would be the equivalent of solving the halting problem. That's not an argument, however, that in security contexts, that having this requirement isn't the right thing to do. [JLS] I have not made an argument for removing it, but for stating that it is the consumer on which the restriction is placed on not on all implementations. 5. I find the last sentence of para #4 to be unreadable. I would start by breaking it into two sentences and potentially move the first one into the JWA document (that about parameters for keys). Simplified [JLS] I think it can be simplified even more. For one thing it is not clear if the member name must be unique between kinds of keys. Thus can you have a "x" for both DH and ECDH (or do they fall into the same family?). [JLS] Given that only fields dealing with either generic items or a specific key are represented in a JWK object. It would make more sense to have the restriction on member names than on generic members and not on members that are specific to a public key. Section 4.1 1. Do you want to point to the JWA document or to the registry for the set of defined algorithms? Clarified that some names are defined in JWA whereas all names not containing a collision resistant namespace should be registered. [JLS] OK - let me be more pointed in my comment. I think you should point at the registry and not at the other document for the list of defined algorithms. Additionally, I think you should point at the registry for the set of generic members defined and ignore the set of key specific members defined in this document. 2. In para #1 I would remove the sentence starting "Specific additional..." as this is not part of the definition of the "alg" parameter and is covered in section 4.0 Done 3. The last two sentences in para #1 can be combined together. This is just a personal stylistic thing I suppose, but I prefer two short declarative sentences to a conjunction of the two. [JLS] as oppose to "The "alg" value MUST be a case-sensitive string. Section 4.2 1. Presentation suggestion - if you use a bulleted list for the values it will be easier to see what the list of defined values is. Done 2. See point #3 in section 4.1 Ditto Section 4.3 1. Is there a requirement that the kid be unique in a JWK Set? I think that the answer should be called out in text either way. Good point. Added text saying that it need not be unique, and providing an example providing rationale for that choice. [JLS] Ok - I see documentation on how to handle the situation if there are multiple KIDs that have the same value, but I am missing the rationale that you have stated as being present. A rationale would be WHY one would have multiple keys with the same KID value. 2. Is the string case sensitive? It is now. :-) 3. Move the sentence "When used..." to a new paragraph. (suggestion) Done Section 6.1 1. Please make things easy for IANA - create a table with the fields across the top and the values down the table. This will allow them to do their job without having to go through the entire document and for us to be able to easily validate that they got it correct. Done here, plus in JWA and JWT [JLS] Section 6.1.1 - Under the Parameter Name: field, you should have a note for IANA that the name is case-sensitive and have a comment that names that match in a case-insensitive manner SHOULD or SHOULD NOT be accepted. (Copy note to all of the reset of the tables as well). [JLS] Section 6.1.1 - are there any longevity requirements on the URI that is specified? If we refer to an RFC then we know that it will "always" exist. This is not necessarily true if one refers to a document on a personal website. Section 6.2 1. Please put in a registration section for the items you are registering in Section 4 in the JWK table. You can refer to JWA for creation of the table. Done here, plus in JWS, JWE, JWA, and JWT Appendix A 1. I am not sure why this appendix is in this document. To give credit to the inventors of the precursor spec that resulted in the JWK spec. I've added their names to make this intent clearer. ------=_NextPart_000_0024_01CD5D22.37149760 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Comments on responses and some additional = comments as well.

 

If the security sections = references the XML DSig document as having important security = considerations, then it needs to be normative and not = informative.

 

Jim

 

 

From:= = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Friday, = July 06, 2012 10:31 AM
To: Jim Schaad
Cc: = jose@ietf.org
Subject: RE: Comments on = draft-ietf-jose-json-web-key-02

 

Thanks for taking the time to provide the = detailed feedback.  Responses inline…

 

-----Original Message-----
From: Jim Schaad [mailto:ietf@augustcellar= s.com]
Sent: Saturday, May 19, 2012 3:34 PM
To: Mike = Jones
Cc: jose@ietf.org
Subject: Comments on = draft-ietf-jose-json-web-key-02

 

<no = hat>

 

My apologies for introducing you to the term = algorithm families.  We don't use it in the same way and thus I = think that you should generally remove it from the text.  To me it = is a very wide term and somewhat nebulous.  Thus I think of all of = the DH algorithms as being in a family - but that family could also = include the ECDH algorithm as well as DSA depending on how one is using = it.  Thus for me an algorithm family is not restricted to a = specific instance (or small set of instances) such a DH & DSA but = could be as large

as all key = agreement algorithms.   As such it does not really match how = you

are using it in much of the = text.

 

Left in for the = current draft for lack of a better term.  I did remove as many uses = of the term as possible.

 

Slightly more detailed:

 

You = can define an RSA key

You can = define an RSA-OAEP key

 

The = second one has all of the fields of the first, however it may have = additional fields defined that deal specifically with RSA-OAEP.  = The difference is going to be a question of restriction of usage of the = key to a single algorithm vs allowing for all RSA = algorithms.

 

Parameters could be defined in the JWA spec to = specify parameters enabling those possible restrictions if the working = group deems it useful/necessary.  The JWK spec already makes it = clear that algorithm-specific parameters may be required, so this = wouldn’t change the model.

 

Here = are some more comments

 

Abstract

 

1.  I am not a fan of the word enumerated in = the last sentence.  This word implies to me that the list is not = expandable.  I would recommend something along the lines of = "An initial set of ... can be found in ..."

 

Done here, plus in JWE, JWS, JWA, JWE-JS, and = JWS-JS

 

[JLS] This change was = not made in the JWA document.

 

Section 2

 

1.  The phrase "For the purpose of this = document" should be removed unless this term is used in other ways = elsewhere.

 

Not changed, because = in some other contexts, the same term is used to refer to the non URL = safe encoding.

 

[JLS] Is it used in a = different way in this document?   One can automatically = assumed that if you are defining a term, that it is for the purposes of = this document and, unless generally accepted, is not applicable to other = documents. 

 

Purely for curiosity, = where is the phrase base64url encoding used to mean something else in a = different document?

 

Section 4

 

1.  In para #2 - the use of "algorithm = family" is incorrect.  They members are going to be required = for the specific key being represented not to the family - consider the = case of RSA and RSA-OAEP - these are both in the same family, but the = fields required are different.

 

Reworded to not use = the term “algorithm family”

 

[JLS] =   Suggest “In addition to the common parameters, each = JWK will have members that are specific to the key being = represented.  These members represent the parameters of the = key.   Section 5 of the JSON Web Algorithm (JWA) specifies a = number of public keys and their associated = members.”

 

2.  Do you believe that all of the algorithm = members are defined in the JWA

document - or only for some algorithms.   = Text should probably say they are

defined for the algorithms defined for the = algorithms in JWA.

 

Done

 

3.  I don't believe that para #3 is = enforceable by parsers as they have been presented to me.  Please = prove me wrong.

 

Section 2.2 of = http://tools.ietf.org/html/rf= c4627 says “The names within an object SHOULD = be unique.”  So this = should be enforced by conforming parsers.  I’d be interested = in data saying that parsers exist that are non-conforming to this RFC = 4627 “SHOULD”.  If so, we should add appropriate = warnings to the Security Considerations section.

 

[JLS] Stating that = they should be unique is more of a requirement on the generation side = and not the parsing side of the specification.  I do not believe = that this statement in way says that parsers should reject objects for = which duplicate member names exist.

 

4.  Let's look at the sentence  "If = present, they MUST  be understood by implementations using = them."  I believe that this is an incorrect = assertion.

(Not to mention that it = is totally uncheckable.)  Consider the following

situation:

 

Implementation A creates a JWK and files it with = Implementation B.  A does not understand the "exist-date" = property.

Implementation B adds = the "exist-date" property and puts it at a = URL.

Implementation C pulls the = JWK from the URL, understand the "exist-date"

property.

According to the MUST, the JWK cannot be used as it = is not understood by all of the implementations.

 

The = only entity that you can make the requirement on is the consumer.  = One assumes that the "provider" would/might understand the = field or it would not be there but it could have been added in transit = and thus that is not the case.

 

I believe that for = your example, the text is correct as written, since in context, = “them” refers to the additional members, not the JWK as a = whole.  At no point in your example did an implementation use a JWK = with an additional member that it did not = understand.

 

[JLS] This is = precisely the statement that I made above, the mandating that the field = is understood by consumers of the JWK is possible, but it is not = possible to mandate that all implementations involved in the transaction = understand all of the fields.

 

I understand that the = assertion may not be enforceable apart from conformance suites that = check what implementations do when given new parameters, and I = understand that in the general case, programmatic enforcement would be = the equivalent of solving the halting problem.  That’s not an = argument, however, that in security contexts, that having this = requirement isn’t the right thing to do.

 

[JLS] I have not made = an argument for removing it, but for stating that it is the consumer on = which the restriction is placed on not on all = implementations.

 

5.  I find the last sentence of para #4 to be = unreadable.  I would start by breaking it into two sentences and = potentially move the first one into the JWA document (that about = parameters for keys).

 

Simplified

 

[JLS]  I think = it can be simplified even more.  For one thing it is not clear if = the member name must be unique between kinds of keys.  Thus can you = have a “x” for both DH and ECDH (or do they fall into the = same family?).

 

[JLS] Given that only = fields dealing with either generic items or a specific key are = represented in a JWK object.  It would make more sense to have the = restriction on member names than on generic members and not on members = that are specific to a public key.

Section 4.1

 

1. Do = you want to point to the JWA document or to the registry for the set of = defined algorithms?

 

Clarified that some = names are defined in JWA whereas all names not containing a collision = resistant namespace should be registered.

 

[JLS] OK – let = me be more pointed in my comment.  I think you should point at the = registry and not at the other document for the list of defined = algorithms.  Additionally, I think you should point at the registry = for the set of generic members defined and ignore the set of key = specific members defined in this document.

 

2. In para #1 I would remove the sentence starting = "Specific additional..."

as this is not part of the definition of the = "alg" parameter and is covered in section 4.0

 

Done

 

3.  The last two sentences in para #1 can be = combined together.

 

This is just a = personal stylistic thing I suppose, but I prefer two short declarative = sentences to a conjunction of the two.

 

[JLS] as oppose to = “The “alg” value MUST be a case-sensitive = string.

 

Section 4.2

 

1.  Presentation suggestion - if you use a = bulleted list for the values it will be easier to see what the list of = defined values is.

 

Done

 

2.  See point #3 in section = 4.1

 

Ditto

 

Section 4.3

 

1.  Is there a requirement that the kid be = unique in a JWK Set?  I think that the answer should be called out = in text either way.

 

Good point.  = Added text saying that it need not be unique, and providing an example = providing rationale for that choice.

 

[JLS]  Ok = – I see documentation on how to handle the situation if there are = multiple KIDs that have the same value, but I am missing the rationale = that you have stated as being present.  A rationale would be WHY = one would have multiple keys with the same KID = value.

 

2.  Is the string case = sensitive?

 

It is now. = :-)

 

3.  Move the sentence "When used..." = to a new paragraph.  (suggestion)

 

Done

 

Section 6.1

 

1. = Please make things easy for IANA - create a table with the fields across = the top and the values down the table.  This will allow them to do = their job without having to go through the entire document and for us to = be able to easily validate that they got it correct.

 

Done here, plus in = JWA and JWT

 

[JLS] Section 6.1.1 = – Under the Parameter Name: field, you should have a note for IANA = that the name is case-sensitive and have a comment that names that match = in a case-insensitive manner SHOULD or SHOULD NOT be accepted. (Copy = note to all of the reset of the tables as well).

 

[JLS] Section 6.1.1 = – are there any longevity requirements on the URI that is = specified?  If we refer to an RFC then we know that it will = “always” exist.  This is not necessarily true if one = refers to a document on a personal website.

 

Section 6.2

 

1. = Please put in a registration section for the items you are registering = in Section 4 in the JWK table.  You can refer to JWA for creation = of the table.

 

Done here, plus in = JWS, JWE, JWA, and JWT

 

Appendix A

 

1.  I am not sure why this appendix is in this = document.

 

To give credit to the = inventors of the precursor spec that resulted in the JWK spec.  = I’ve added their names to make this intent = clearer.

 

------=_NextPart_000_0024_01CD5D22.37149760-- From James.H.Manger@team.telstra.com Sun Jul 8 17:42:20 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E1921F87E4 for ; Sun, 8 Jul 2012 17:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.275 X-Spam-Level: X-Spam-Status: No, score=-0.275 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_05=-1.11, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3Y6zikLCKu9 for ; Sun, 8 Jul 2012 17:42:20 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id B02F721F87D0 for ; Sun, 8 Jul 2012 17:42:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,549,1336312800"; d="scan'208";a="86317459" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipoani.tcif.telstra.com.au with ESMTP; 09 Jul 2012 10:42:40 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6766"; a="23515257" Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipcani.tcif.telstra.com.au with ESMTP; 09 Jul 2012 10:42:39 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Mon, 9 Jul 2012 10:42:39 +1000 From: "Manger, James H" To: "Richard L. Barnes" , Mike Jones Date: Mon, 9 Jul 2012 10:42:37 +1000 Thread-Topic: [jose] MUST understand ALL header fields Thread-Index: Ac1bpgeiqfUywbShQaqjlcj8YSloiABvaTFw Message-ID: <255B9BB34FB7D647A506DC292726F6E114F78D4ADF@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739436657A1B2@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 00:42:20 -0000 TWlrZSwNCg0KPj4gICAgSW1wbGVtZW50YXRpb25zIE1VU1QgdW5kZXJzdGFuZCB0aGUgZW50aXJl IGNvbnRlbnRzIG9mIHRoZQ0KPj4gICAgaGVhZGVyOyBvdGhlcndpc2UsIHRoZSB7SldTfEpXRX0g TVVTVCBiZSByZWplY3RlZC4NCj4+DQo+PiBXZSBzaG91bGQgZHJvcCB0aGlzIHJlc3RyaWN0aW9u Lg0KDQpNaWtlIHJlcGxpZWQ6DQo+IFNpbmNlIHRoaXMgaXMgYSBzZWN1cml0eSBwcm90b2NvbCwg dGhlIHdheSBJIHNlZSBpdCwgdXNlIG9mIGEgbm90LQ0KPiB1bmRlcnN0b29kIHBhcmFtZXRlciBT SE9VTEQgYnJlYWsgaW1wbGVtZW50YXRpb25zIGlmIHRoZXnigJlyZSBub3QNCj4gcHJlcGFyZWQg dG8gaGFuZGxlIHRoZW0gKG9yIGF0IGxlYXN0IHRoZW0gY2F1c2UgdGhlbSB0byByZWplY3QgdGhl DQo+IGlucHV0KS4gIEZvciBleGFtcGxlLCBpZiB3ZSBoeXBvdGhldGljYWxseSBhZGRlZCBhbiBh dWRpZW5jZQ0KPiByZXN0cmljdGlvbiBwYXJhbWV0ZXIsIGlnbm9yaW5nIGl0IHdvdWxkIGJlIGEg c2VjdXJpdHkgZXJyb3IuICAoVGhlDQo+IG5lZWQgZm9yIGF1ZGllbmNlIHJlc3RyaWN0aW9uIGlz IGJlaW5nIGhlYXZpbHkgZGlzY3Vzc2VkIGluIHRoZSBPQXV0aA0KPiBXRyByaWdodCBub3csIGFu ZCByZWFsIGV4cGxvaXRzIHRoYXQgaGF2ZSBvY2N1cnJlZCBmb3IgdGhlIGxhY2sgb2YgaXQsDQo+ IHNvIHRoaXMgZXhhbXBsZSBpcyByZWFsIGFuZCBmcmVzaCBvbiBteSBtaW5kLikgIElmIG5vdCB1 bmRlcnN0b29kLCBhDQo+IHRva2VuIGNvbnRhaW5pbmcgYW4gYXVkaWVuY2UgcmVzdHJpY3Rpb24g TVVTVCBiZSByZWplY3RlZC4NCg0KDQpDb25zaWRlciBhbiBlY29zeXN0ZW0gd2l0aCBodW5kcmVk cyBvZiBzZXJ2ZXJzIGFuZCB0aG91c2FuZHMgb2YgY2xpZW50IGFwcHMgYWxsIHVzaW5nIGEgcHJv dG9jb2wgaW52b2x2aW5nIEpPU0UgbWVzc2FnZXMgdGhhdCBoYXMgYmVlbiBvcGVyYXRpbmcgZm9y IGEgZmV3IHllYXJzLiBBIHJlc2VhcmNoZXIgZmluZHMgYSB2dWxuZXJhYmlsaXR5IGluIHRoZSBw cm90b2NvbCBhbmQgcmVzcG9uc2libHkgZGlzY2xvc2VzIGl0IHRvIHNlbGVjdGVkIHNlcnZlcnMu IFRoZSBmaXggaXMgdG8gYWRkIGFuIGF1ZGllbmNlIHJlc3RyaWN0aW9uIHBhcmFtZXRlciAiYXVk Ii4NCg0KV2hhdCBzaG91bGQgYSBzZXJ2ZXIgZG8/DQoNCklmIGl0IGFkZHMgdGhlICJhdWQiIHBh cmFtZXRlciBpbW1lZGlhdGVseSwgZXZlcnkgKGNvbXBsaWFudCkgY2xpZW50IGFwcCB3aWxsIGlt bWVkaWF0ZWx5IGJyZWFrLiBUaGUgb3V0YWdlIHdpbGwgbGFzdCB1bnRpbCBldmVyeSBhcHAgaXMg dXBkYXRlZCwgd2hpY2ggd2lsbCB0YWtlcyB3ZWVrcywgbW9udGhz4oCmPyBUb3RhbCBzeXN0ZW0g c2h1dGRvd24gdG8gZml4IGEgZmxhdyB0aGF0IGlzIGN1cnJlbnRseSB0aGVvcmV0aWNhbOKApiBo ZWFkcyB3aWxsIHJvbGUuDQoNCklmIGEgc2VydmVyIGFubm91bmNlcyB0aGF0IGl0IHdpbGwgYWRk IHRoZSAiYXVkIiBwYXJhbWV0ZXIgaW4sIHNheSwgMyBtb250aHMgdG8gZ2l2ZSB0aW1lIGZvciBh cHAgdXBkYXRlcyB0aGVuIGl0IGhhcyBqdXN0IGRpc2Nsb3NlZCBhIHZ1bG5lcmFiaWxpdHkgYW5k IGdpdmVuIGF0dGFja2VycyBhIDMgbW9udGggd2luZG93IHRvIGV4cGxvaXQgaXQuIE1hbnkgd2ls bCBjbGFtb3VyIGZvciBhbiBpbW1lZGlhdGUgZml4OyBtYW55IHdpbGwgc2F5IHRoZXkgbmVlZCBs b25nZXIgdG8gZml4IGFwcHM7IGl0IHdpbGwgc3RpbGwgYnJlYWsgZm9yIG1hbnkgdXNlcnMgaW4g MyBtb250aHPigKYgaGVhZHMgd2lsbCByb2xlLg0KDQpPbiB0aGUgb3RoZXIgaGFuZCwgaWYgdGhl IHNwZWMgc2F5cyB1bmtub3duIHBhcmFtZXRlcnMgTVVTVCBiZSBpZ25vcmVkIHRoZW4gdGhlIHNl cnZlciBjYW4gaW1tZWRpYXRlbHkgYWRkIHRoZSAiYXVkIiBwYXJhbWV0ZXIsIGFuZCBpbW1lZGlh dGVseSB0ZWxsIGNsaWVudCBhcHBzIHRvIHN0YXJ0IHN1cHBvcnRpbmcgaXQuIEVhY2ggYXBwIGlz IHByb3RlY3RlZCBhcyBzb29uIGFzIGl0IGFkZHMgc3VwcG9ydC4NCklmIGFjdHVhbCBleHBsb2l0 cyBuZWVkIHRvIGJlIHN0b3BwZWQgdGhlIHNlcnZlciBjYW4gc3RpbGwgc2h1dGRvd24gdGhlIHdo b2xlIHN5c3RlbSwgb3IganVzdCBzZWxlY3RlZCBjbGllbnQgYXBwcywgb3Igc2VsZWN0ZWQgdXNl cnMuDQoNCg0KWC41MDkgY2VydGlmaWNhdGVzIGFyZSBhbiBpbnRlcmVzdGluZyBleGFtcGxlIGZv ciBjb21wYXJpc29uLiBDZXJ0cyBhcmUgc2VjdXJpdHktcmVsYXRlZCwganVzdCBsaWtlIEpPU0Ug bWVzc2FnZXMuIENlcnRzIGFsbG93IHVucmVjb2duaXNlZCBhZGRpdGlvbnMgKGVnIG5vbi1jcml0 aWNhbCBleHRlbnNpb25zKS4gVGhlc2UgaGF2ZSBiZWVuIHZlcnkgd2lkZWx5IHVzZWQgdG8gZGVw bG95IG5ldyBmdW5jdGlvbmFsaXR5Lg0KDQpUaGUgWC41MDkgc3BlYyAob3IgYXQgbGVhc3QgaXRz IElFVEYgcHJvZmlsZSkgaGFzIG9uZSBpdGVtIHRoYXQgTVVTVCBiZSB1bmRlcnN0b29kIGlmIGFk ZGVkOiB0aGUgbmFtZS1jb25zdHJhaW50cyBleHRlbnNpb24uIFRoaXMgZXh0ZW5zaW9uIHNob3Vs ZCBiZSByZWFsbHkgdXNlZnVsIGZvciBzZWN1cml0eS4gSG93ZXZlciwgYmVjYXVzZSBhZGRpbmcg aXQgaW4gdGhlIHNwZWMtY29tcGxpYW50IE1VU1QtdW5kZXJzdGFuZCBtYW5uZXIgd2lsbCBicmVh ayBzb21lIGNsaWVudHMsIGl0IGhhcyBiYXJlbHkgYmVlbiBkZXBsb3llZCBmb3Igb3ZlciBhIGRl Y2FkZS4NCg0KDQpMZXRzIGRyb3AgdGhlICJNVVNUIHVuZGVyc3RhbmQgZXZlcnl0aGluZyIgcmVx dWlyZW1lbnQuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From ietf@augustcellars.com Sun Jul 8 22:17:13 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4956821F8818 for ; Sun, 8 Jul 2012 22:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.412 X-Spam-Level: X-Spam-Status: No, score=-3.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOgCPIld+3c4 for ; Sun, 8 Jul 2012 22:17:05 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id C260F21F8803 for ; Sun, 8 Jul 2012 22:17:05 -0700 (PDT) Received: from Tobias (50-39-234-129.bvtn.or.frontiernet.net [50.39.234.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 558D82CA03; Sun, 8 Jul 2012 22:17:28 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" References: <4E1F6AAD24975D4BA5B168042967394366579FC3@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366579FC3@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Sun, 8 Jul 2012 22:16:09 -0700 Message-ID: <008701cd5d91$f3cbe740$db63b5c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0088_01CD5D57.4773ED10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHrEbFlExgZBQrw4w5tA27sA4p9CJbi/s2Q Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 05:17:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0088_01CD5D57.4773ED10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Responses to previous comments and some new comments. Open issue feedback - Do AES ECB - no From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, July 06, 2012 10:41 AM To: 'Jim Schaad' Cc: jose@ietf.org Subject: RE: Comments on draft-ietf-jose-json-web-algorithms-02 Thanks for taking the time to provide the detailed feedback. Responses inline. -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, May 21, 2012 3:46 PM To: Mike Jones Cc: jose@ietf.org Subject: Comments on draft-ietf-jose-json-web-algorithms-02 Here are comments this document Abstract 1. Since I called it out for JWK I will make the comment that I do not have a problem with enumerate in this document. Noted [JLS] On the other had since you said it was addressed in the mail for the JWK document and it is not changed I do have a problem there. Section 1 1. Just a comment - I am not sure why you feel the name to create a specific acronym for this document but it does not really matter. It provides a shorthand name to refer to this document from others. 2. Need to expand JSON if you are going to use it. Not done here, because the word "JSON" here is used as part of a name, rather than as a reference to a specification or kind of data structure. I did expand it the first time it is used to refer to the RFC 4627 data structures, in all the documents. [JLS] The rules state that it is to be expanded on the first use. If it is not done on the first use then the RFC editor will do so. It should be ok in the key document since it is done almost immediately after the first use. As it currently stands it does not follow this rule. 3. New paragraph for sentence starting with "Enumerating..." Separate justification from what this document does and hash. Done 4. Move last sentence to the end of the first paragraph Done Section 2 1. In general I would like to see this duplicated into this document. Readers should not have to reference another document for this purpose. Done [JLS] However only the relevant terms should be included. If JWE Ciphertext is never used then it does not need to be included at this point. Section 3.1 1. I am not overly happy with the existence of a "none" algorithm. Does it really need to exist? Yes. It is already widely used in contexts where content can be either signed or plaintext. And while it used to be defined in JWT, you'd earlier suggested that it be moved here, since it is of broader applicability than just JWTs. [JLS] I don't disagree with it being here rather than in the JWT document. However there is a question if it would be better represented as having an absent alg parameter rather than having a "none" algorithm. It would accomplish the same thing and be less suggested if an actual signature/MAC algorithm existing on the document. Section 3.2 1. You may want to reference RFC4231 as well. It contains test vectors and such for the SHA2 HMACs If this spec were about implementing the SHA2 HMAC algorithms, I would agree, but since it's only about using them, I don't think this reference is necessary. Feel free to push back on this, however. 3. I have not yet read the updated JWS document, but I do worry about the fact that this document is saying that the output should be base64url encoded. If the JWS document says the same thing injudiciously then one could easily see that people might double encode the result. I don't think there's a problem, as both documents make a clear distinction between the "JWS Signature" value and the "Encoded JWS Signature" value, and are careful to use the right term in the right place. (But obviously send me corrections if you find a place where the wrong term is used.) 4. I have a real problem with people saying that UTF-8 and ASCII are the same. They aren't and saying that they are does not make it so. They actually are the same in this case, since the JWS Secured Input consists of only 7-bit ASCII characters (since they contain only base64url encoded content and periods characters) that are represented the same in both encodings. But I agree that the previous text was potentially confusing and overly verbose. The text now only uses the phrase "the ASCII representation of the JWS Secured Input", both here, and in the JWS spec. [JLS] Do you know this to be a true statement for all future encodings of JWS values as oppose to the current one that is defined in JWS. For example, in the documents proposed by myself and Richard this is not a true statement. Instead the header is UTF8 encoded and that value is processed without having done the ASCII encoding from base64url. 5. I find it confusing to constantly refer to the JWS specification throughout this text. For one thing it makes it harder to refer to these documents for other uses in JSON of these algorithms (such as for an encrypt and MAC algorithm). These defined terms have now been incorporated into this document, per your comment on Section 2, so there should be no longer any need to refer to the JWS spec to understand this section. [JLS] That does not address my concern. If you do a combo HMAC and encrypt algorithm are you going to suddenly turn the header and content into a JWS Secured Input? (And do they suddenly become US ASCII strings?) Section 3.4 4. I have never see the R,S pair be referred to as a point before. I believe it is just an ordered pair of integers and not a point on the field. The "point" terminology is used by XML DSIG 2.0, at least about the (x, y) pair. See http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124/#sec-ECKeyValue. I could be wrong that (R, S) are also a point, but given that the P-521 signature is a pair of 521-bit integers, it sure seems like it is. Any ECDSA experts care to weigh in? [JLS] A fast review of the algorithm on Wikipedia confirms what I was thinking. The value of R is obtained from a point on the field (using just k) and the value S is then computed from the value of x and the hash value. This means that (r,s) is not a point on the field. Section 3.6 1. I don't see the purpose of the last paragraph in this section. It has nothing to do with algorithms. This subsection is not only about algorithms - it's about extensions to JWS, the parameters registry for which is also in the JWA spec because it's shared between JWS and JWE. The first and second paragraphs of this subsection is about extensions via algorithms and has a reference to that JWA registry. The third paragraph is about extensions via parameters, and has a reference to that JWA registry. Not that 3.6 is parallel to 4.11 which has the same content for JWEs. All that being said, I'd be open to a different editorial structuring, if someone wants to make an alternative proposal. Section 4.5 1. RSA-OAEP is under specified. There are a number of parameters for OAEP that must be defined to go with it. These include the mask function and a hash function. Look at RFC 3447 for the details. This is now fully specified. The description now reads: RSA using Optimal Asymmetric Encryption Padding (OAEP), as defined in RFC 3447, with the default parameters specified by RFC 3447 in Section A.2.1 [JLS] It is strongly recommended that the hash function for OAEP and the hash function for the content be the same values. Additionally, why would we recommend using SHA1 for any of these parameters given that it is not recommended for any other purpose? Section 4.6 2. I strongly disagree with setting OtherInfo parameters to be empty. We need to define and fill in the AlgorithmId at a minimum. Note that this can be an implicit computation and does not need to be carried as extra data. At a minimum I would suggest something along the lines of JOSE-### where ### is the number of bits to get generated. Per my response to Sean's related comment, it's not clear to me what additional value these parameters add in our usage of the algorithm. If we believe that the content master key is undeterminable by an attacker (a requirement for any security at all!) then adding a constant AlgorithmID to the computation I don't believe changes the security properties. (That being said, we *could* use the "alg" value "ECDH-ES" as the AlgorithmID if people felt better about doing this.) Also given that the text now says (per your previous comment) that "A new epk (ephemeral public key) value MUST be generated for each key agreement transaction", it's not clear that adding parameters identifying the participating parties adds any security value either. That being said, I'd be glad to learn why I'm wrong. If there are good security reasons for requiring PartyUInfo and PartyVInfo values, do you have suggestions on how to create acceptable values without carrying more parameters in the header? (I've already suggested that we could use the "alg" value "ECDH-ES" as the AlgorithmID, which wouldn't require more parameters.) For instance, I don't want to blindly follow XML ENC's lead and punt the issue by requiring that conforming uses provide explicit PartyUInfo and PartyVInfo values. Finally, I'll note that the KDF function used by TLS http://tools.ietf.org/html/rfc5246#section-5 uses no party parameters. Why do we need them then? [JLS] The object of having the algorithm identifier be present is to make sure that if you are doing two kdfs from the same key pairs for different purposes that they will never end up generating the same key values (or a prefix of the same key values). While it is not immediate obvious that this is going to be possible with the JOSE documents, it is a known security issue and one that is easily addressed. One way would be as I suggested above and used a string with the number of bits. Another way would be to use the algorithm that the key is going to be used for (which is how it is defined). Thus this should be the ACUTAL content encryption algorithm used (i.e. AES128GW or AES128CBC+HS256). At this point I now would say that the KDF MUST have the ability to have a PartyUInfo value specified. When the KDF was implicit in the key agreement algorithm tag it did not matter. At that point if someone defined a new static-static version of ECDH then they would be required to define what KDF function was to be used and could then require that the PartyUInfo field be defined in the KDF function that required. As it stands now, the KDF is no longer tied to the key agreement algorithm and must therefore meet the necessary security requirements for a static-static version of DH as well as the ephemeral static versions. (On the other hand it still may be implicit, but this was not completely obvious as there is a kdf function that would be used in some cases leading to a confusion about what the kdf function was actually being used for.) For TLS, both the PartyUInfo and the PartyVInfo values are present and used when computing the key from the master secret. Since they are present at that point they do not need to be present when computing the master secret itself. When using TLS to compute other secrets - such as a TLS Unque value, the equivalent of the algorithm ID is used at that point to make sure that all such keys computed are going to be unique to that purpose. Section 4.11 1. for last paragraph see comment on 3.6 Same response as for 3.6 Section 6.1 1. I would move this registry to either the signature or encryption documents and not put it here. What does this document populate it with? Done Section 6.2 1. Make life easy for IANA and me - create a table of the values Done both here and in the other documents [JLS] What is the purpose of putting the Implementation Requirements into the table? Different applications may have different requirements and these requirements may change over time. It does not make sense to require the table to be updated every time the set of requirements change. The only exception to that might be an obsoleted or do not use field, but even that can be somewhat iffy. Section 6.3 1. This registry should be in either the encryption or signature draft Done - now in JWS Section 6.4 1. This registry should be in the JWK document Done Section 6.5 1. Make life easy for IANA and me - create a table of the values Done both here and in the other documents ------=_NextPart_000_0088_01CD5D57.4773ED10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Responses to previous comments and some new = comments.

 

 

Open issue feedback = – Do AES ECB – no

 

 

From:= = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Friday, = July 06, 2012 10:41 AM
To: 'Jim Schaad'
Cc: = jose@ietf.org
Subject: RE: Comments on = draft-ietf-jose-json-web-algorithms-02

<= p class=3DMsoNormal> 

Thanks for taking the time to provide the = detailed feedback.  Responses inline…

 

-----Original Message-----
From: Jim Schaad [mailto:ietf@augustcellar= s.com]
Sent: Monday, May 21, 2012 3:46 PM
To: Mike = Jones
Cc: jose@ietf.org
Subject: Comments on = draft-ietf-jose-json-web-algorithms-02

 

Here = are comments this document

 

Abstract

 

1.  Since I called it out for JWK I will make = the comment that I do not have a problem with enumerate in this = document.

 

Noted

 

[JLS] On the other = had since you said it was addressed in the mail for the JWK document and = it is not changed I do have a problem there.

 

Section 1

 

1.  Just a comment - I am not sure why you = feel the name to create a specific acronym for this document but it does = not really matter.

 

It provides a = shorthand name to refer to this document from = others.

 

2.  Need to expand JSON if you are going to = use it.

 

Not done here, = because the word “JSON” here is used as part of a name, = rather than as a reference to a specification or kind of data = structure.  I did expand it the first time it is used to refer to = the RFC 4627 data structures, in all the = documents.

 

[JLS]  The rules = state that it is to be expanded on the first use.  If it is not = done on the first use then the RFC editor will do so.  It should be = ok in the key document since it is done almost immediately after the = first use.  As it currently stands it does not follow this = rule.

 

3.  New paragraph for sentence starting with = "Enumerating..."  Separate justification from what this = document does and hash.

 

Done

 

4.  Move last sentence to the end of the first = paragraph

 

Done

 

Section 2

 

1.  In general I would like to see this = duplicated into this document.

Readers should not have to reference another = document for this purpose.

 

Done

 

[JLS] However only = the relevant terms should be included.  If JWE Ciphertext is never = used then it does not need to be included at this = point.

 

Section 3.1

 

1.  I am not overly happy with the existence = of a "none" algorithm.  Does it really need to = exist?

 

Yes.  It is = already widely used in contexts where content can be either signed or = plaintext.  And while it used to be defined in JWT, you’d = earlier suggested that it be moved here, since it is of broader = applicability than just JWTs.

 

[JLS] I don’t = disagree with it being here rather than in the JWT document.  = However there is a question if it would be better represented as having = an absent alg parameter rather than having a “none” = algorithm.  It would accomplish the same thing and be less = suggested if an actual signature/MAC algorithm existing on the = document.

 

Section 3.2

 

1.  You may want to reference RFC4231 as = well.  It contains test vectors and such for the SHA2 = HMACs

 

If this spec were = about implementing the SHA2 HMAC algorithms, I would agree, but since = it’s only about using them, I don’t think this reference is = necessary.  Feel free to push back on this, = however…

 

3.  I have not yet read the updated JWS = document, but I do worry about the fact that this document is saying = that the output should be base64url encoded.  If the JWS document = says the same thing injudiciously then one could easily see that people = might double encode the result.

 

I don’t think = there’s a problem, as both documents make a clear distinction = between the “JWS Signature” value and the “Encoded JWS = Signature” value, and are careful to use the right term in the = right place.  (But obviously send me corrections if you find a = place where the wrong term is used.)

 

4.  I have a real problem with people saying = that UTF-8 and ASCII are the same.  They aren't and saying that = they are does not make it so.

 

They actually are the = same in this case, since the JWS Secured Input consists of only 7-bit = ASCII characters (since they contain only base64url encoded content and = periods characters) that are represented the same in both = encodings.  But I agree that the previous text was potentially = confusing and overly verbose.  The text now only uses the phrase = “the ASCII representation of the JWS Secured Input”, both = here, and in the JWS spec.

 

[JLS] Do you know = this to be a true statement for all future encodings of JWS values as = oppose to the current one that is defined in JWS.  For example, in = the documents proposed by myself and Richard this is not a true = statement.  Instead the header is UTF8 encoded and that value is = processed without having done the ASCII encoding from = base64url.

 

5.  I find it confusing to constantly refer to = the JWS specification throughout this text.  For one thing it makes = it harder to refer to these documents for other uses in JSON of these = algorithms (such as for an encrypt and MAC algorithm).

 

These defined terms = have now been incorporated into this document, per your comment on = Section 2, so there should be no longer any need to refer to the JWS = spec to understand this section.

 

[JLS] That does not = address my concern.  If you do a combo HMAC and encrypt algorithm = are you going to suddenly turn the header and content into a JWS Secured = Input? (And do they suddenly become US ASCII = strings?)

 

 

Section 3.4

 

4.  I have never see the R,S pair be referred = to as a point before.  I believe it is just an ordered pair of = integers and not a point on the field.

 

The = “point” terminology is used by XML DSIG 2.0, at least about = the (x, y) pair.  See http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124/#sec-ECKeyValue.  I could be wrong that (R, S) are = also a point, but given that the P-521 signature is a pair of 521-bit = integers, it sure seems like it is.  Any ECDSA experts care to = weigh in?

 

[JLS] A fast review = of the algorithm on Wikipedia confirms what I was thinking.  The = value of R is obtained from a point on the field  (using just k) = and the value S is then computed from the value of x and the hash = value.  This means that (r,s) is not a point on the field. =

 

Section 3.6

 

1.  I don't see the purpose of the last = paragraph in this section.  It has nothing to do with = algorithms.

 

This subsection is = not only about algorithms – it’s about extensions to JWS, = the parameters registry for which is also in the JWA spec because = it’s shared between JWS and JWE.  The first and second = paragraphs of this subsection is about extensions via algorithms and has = a reference to that JWA registry.  The third paragraph is about = extensions via parameters, and has a reference to that JWA = registry.  Not that 3.6 is parallel to 4.11 which has the same = content for JWEs.

 

All that being said, = I’d be open to a different editorial structuring, if someone wants = to make an alternative proposal.

 

Section 4.5

 

1.  RSA-OAEP is under specified.  There = are a number of parameters for OAEP that must be defined to go with = it.  These include the mask function and a hash function.  = Look at RFC 3447 for the details.

 

This is now fully = specified.  The description now reads:  RSA using Optimal = Asymmetric Encryption Padding (OAEP), as defined in RFC 3447, with the = default parameters specified by RFC 3447 in Section = A.2.1

 

[JLS] It is strongly = recommended that the hash function for OAEP and the hash function for = the content be the same values.  Additionally, why would we = recommend using SHA1 for any of these parameters given that it is not = recommended for any other purpose?

 

Section 4.6

 

2.  I strongly disagree with setting OtherInfo = parameters to be empty.   We

need to define and fill in the AlgorithmId at a = minimum.  Note that this can be an implicit computation and does = not need to be carried as extra data.

At a minimum I would suggest something along the = lines of JOSE-### where ### is the number of bits to get = generated.

 

Per my response to = Sean’s related comment, it's not clear to me what additional value = these parameters add in our usage of the algorithm.  If we believe = that the content master key is undeterminable by an attacker (a = requirement for any security at all!) then adding a constant AlgorithmID = to the computation I don't believe changes the security = properties.  (That being said, we *could* use the “alg” = value "ECDH-ES" as the AlgorithmID if people felt better about = doing this.)

 

Also given that the = text now says (per your previous comment) that "A new epk = (ephemeral public key) value MUST be generated for each key agreement = transaction", it's not clear that adding parameters identifying the = participating parties adds any security value either.  That being = said, I'd be glad to learn why I'm wrong.

 

If there are good = security reasons for requiring PartyUInfo and PartyVInfo values, do you = have suggestions on how to create acceptable values without carrying = more parameters in the header?  (I've already suggested that we = could use the “alg” value "ECDH-ES" as the = AlgorithmID, which wouldn't require more = parameters.)

 

For instance, I don't = want to blindly follow XML ENC's lead and punt the issue by requiring = that conforming uses provide explicit PartyUInfo and PartyVInfo = values.

 

Finally, I'll note = that the KDF function used by TLS http://tools.ietf.o= rg/html/rfc5246#section-5 uses no party parameters.  Why do we = need them then?

 

[JLS] The object of = having the algorithm identifier be present is to make sure that if you = are doing two kdfs from the same key pairs for different purposes that = they will never end up generating the same key values (or a prefix of = the same key values).   While it is not immediate obvious that = this is going to be possible with the JOSE documents, it is a known = security issue and one that is easily addressed.  One way would be = as I suggested above and used a string with the number of bits.  = Another way would be to use the algorithm that the key is going to be = used for (which is how it is defined).  Thus this should be the = ACUTAL content encryption algorithm used (i.e. AES128GW or = AES128CBC+HS256).

 

At this point I now = would say that the KDF MUST have the ability to have a PartyUInfo value = specified.  When the KDF was implicit in the key agreement = algorithm tag it did not matter.  At that point if someone defined = a new static-static version of ECDH then they would be required to = define what KDF function was to be used and could then require that the = PartyUInfo field be defined in the KDF function that required.  As = it stands now, the KDF is no longer tied to the key agreement algorithm = and must therefore meet the necessary security requirements for a = static-static version of DH as well as the ephemeral static = versions.  (On the other hand it still may be implicit, but this = was not completely obvious as there is a kdf function that would be used = in some cases leading to a confusion about what the kdf function was = actually being used for.)

 

For TLS, both the = PartyUInfo and the PartyVInfo values are present and used when computing = the key from the master secret.  Since they are present at that = point they do not need to be present when computing the master secret = itself.   When using TLS to compute other secrets – such = as a TLS Unque value, the equivalent of the algorithm ID is used at that = point to make sure that all such keys computed are going to be unique to = that purpose.

 

 

Section 4.11

 

1.  for last paragraph see comment on = 3.6

 

Same response as for = 3.6

 

Section 6.1

 

1.  I would move this registry to either the = signature or encryption documents and not put it here.  What does = this document populate it with?

 

Done

 

Section 6.2

 

1.  Make life easy for IANA and me - create a = table of the values

 

Done both here and in = the other documents

 

[JLS] What is the = purpose of putting the Implementation Requirements into the table?  = Different applications may have different requirements and these = requirements may change over time.  It does not make sense to = require the table to be updated every time the set of requirements = change.  The only exception to that might be an obsoleted or do not = use field, but even that can be somewhat iffy.

 

Section 6.3

 

1.  This registry should be in either the = encryption or signature draft

 

Done – now in = JWS

 

Section 6.4

 

1.  This registry should be in the JWK = document

 

Done

 

Section 6.5

 

1.  Make life easy for IANA and me - create a = table of the values

 

Done both here and in = the other documents

 

------=_NextPart_000_0088_01CD5D57.4773ED10-- From breno@google.com Mon Jul 9 09:44:23 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5860511E8149 for ; Mon, 9 Jul 2012 09:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.253 X-Spam-Level: X-Spam-Status: No, score=-102.253 tagged_above=-999 required=5 tests=[AWL=0.723, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wzugkVxuV0q for ; Mon, 9 Jul 2012 09:44:22 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC1E11E813E for ; Mon, 9 Jul 2012 09:44:22 -0700 (PDT) Received: by ggnc4 with SMTP id c4so11290822ggn.31 for ; Mon, 09 Jul 2012 09:44:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=iVD7gSfVcQUsHcvaydiLRWDdgz8IxB9ZMOLTkg4wDN8=; b=mjNExLEuuoBXbgpjnOsiKfDU3OGrccgIae/osrUyMmp5tgEvoxzXKtA5NN5KBYqstR WyVh+li+ygSed6nRPYa0CeWWYwC/gTDtLfJgC3QtBvtTtDxmQIoyURhyFF5pYBXjvYWv NhWLspWxcm8G4BZ9b1+iFF+rOLsN7Hv5TW7tU5CJ/AcH5bPVfv6PkKf8bL2kqB5I/rs7 NrtFIt8h0SpCn54/A831N9K3VhUR7eRm/L/9i1AH5Bv+2+aPkQWUfLsGGhRPAZSFHf9n cM30zcQNWUG1G5PUxHJzqxJA5bJfiYuTqLeLXgLZktYfim/2mTVpSbG2XF6ThcbJbUBK cDmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=iVD7gSfVcQUsHcvaydiLRWDdgz8IxB9ZMOLTkg4wDN8=; b=bK5R0Dr+ytdDL4Qx+KXCKhYomAMvEatZZJqOvo/cNSyNFUpqKBxKTjUDwd1SPcA3Gz ed8uTcrYT4dXIP25mRWrum3mPAoYGjQCvIlODiPbPc9xGetp5SUjmRvnTmRO9rbsYMQM YCdXzL8/AMbXRT3BOdT/gh3CUQh7O/V9phEt8DsRmAjuQaKqFWtzAWBtcdOXgieO4XRa Xa5SCYmMOuQy3pyDaTCyeWcqH4Aw2YPgu25Tn2SMjLO0d33hMD6hInDXanr1fUtF1cwN h1kAxT41otq59Dauf2Sa/ZZl74P7sWM1NKzhx6OoMDCbm6FBsGsWRydIuqSzcu7J12Nm Z4wA== Received: by 10.50.237.1 with SMTP id uy1mr9133786igc.18.1341852286820; Mon, 09 Jul 2012 09:44:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.237.1 with SMTP id uy1mr9133770igc.18.1341852286617; Mon, 09 Jul 2012 09:44:46 -0700 (PDT) Received: by 10.231.17.194 with HTTP; Mon, 9 Jul 2012 09:44:46 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F78D4ADF@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739436657A1B2@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F78D4ADF@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 9 Jul 2012 09:44:46 -0700 Message-ID: From: Breno de Medeiros To: "Manger, James H" Content-Type: multipart/alternative; boundary=f46d04478753e287aa04c4685420 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnR4/EXzKfM3fckJedwt59lrhpB7GR5WIpGL48klsTSt8fHmrIZHbiNJ9UObhYjM244PzejkoeUc9AHvj1fIfTYpSKOm0a///YpB4v5kPXRZA+A8hAHYhrzHf2HYRA/TY5gSUO4JMXV93qLXBxSaiym4yHdxkQgzwzimjzHHep7anCW/8g= Cc: "Richard L. Barnes" , Mike Jones , "jose@ietf.org" Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 16:44:23 -0000 --f46d04478753e287aa04c4685420 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable At some point, the spec said that servers should reject tokens with unknown parameters in the envelope (which describes the security context) but tolerate them in the body. On Sun, Jul 8, 2012 at 5:42 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > Mike, > > >> Implementations MUST understand the entire contents of the > >> header; otherwise, the {JWS|JWE} MUST be rejected. > >> > >> We should drop this restriction. > > Mike replied: > > Since this is a security protocol, the way I see it, use of a not- > > understood parameter SHOULD break implementations if they=92re not > > prepared to handle them (or at least them cause them to reject the > > input). For example, if we hypothetically added an audience > > restriction parameter, ignoring it would be a security error. (The > > need for audience restriction is being heavily discussed in the OAuth > > WG right now, and real exploits that have occurred for the lack of it, > > so this example is real and fresh on my mind.) If not understood, a > > token containing an audience restriction MUST be rejected. > > > Consider an ecosystem with hundreds of servers and thousands of client > apps all using a protocol involving JOSE messages that has been operating > for a few years. A researcher finds a vulnerability in the protocol and > responsibly discloses it to selected servers. The fix is to add an audien= ce > restriction parameter "aud". > > What should a server do? > > If it adds the "aud" parameter immediately, every (compliant) client app > will immediately break. The outage will last until every app is updated, > which will takes weeks, months=85? Total system shutdown to fix a flaw th= at > is currently theoretical=85 heads will role. > > If a server announces that it will add the "aud" parameter in, say, 3 > months to give time for app updates then it has just disclosed a > vulnerability and given attackers a 3 month window to exploit it. Many wi= ll > clamour for an immediate fix; many will say they need longer to fix apps; > it will still break for many users in 3 months=85 heads will role. > > On the other hand, if the spec says unknown parameters MUST be ignored > then the server can immediately add the "aud" parameter, and immediately > tell client apps to start supporting it. Each app is protected as soon as > it adds support. > If actual exploits need to be stopped the server can still shutdown the > whole system, or just selected client apps, or selected users. > > > X.509 certificates are an interesting example for comparison. Certs are > security-related, just like JOSE messages. Certs allow unrecognised > additions (eg non-critical extensions). These have been very widely used = to > deploy new functionality. > > The X.509 spec (or at least its IETF profile) has one item that MUST be > understood if added: the name-constraints extension. This extension shoul= d > be really useful for security. However, because adding it in the > spec-compliant MUST-understand manner will break some clients, it has > barely been deployed for over a decade. > > > Lets drop the "MUST understand everything" requirement. > > -- > James Manger > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --=20 --Breno --f46d04478753e287aa04c4685420 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable At some point, the spec said that servers should reject tokens with unknown= parameters in the envelope (which describes the security context) but tole= rate them in the body.


On Sun, Jul 8, 2012 at 5:42 PM, Manger, James H <James.H.Man= ger@team.telstra.com> wrote:

>> =A0 =A0Implementations MUST understand the entire contents of the<= br> >> =A0 =A0header; otherwise, the {JWS|JWE} MUST be rejected.
>>
>> We should drop this restriction.

Mike replied:
> Since this is a security protocol, the way I see it,= use of a not-
> understood parameter SHOULD break implementations if they=92re not
> prepared to handle them (or at least them cause them to reject the
> input). =A0For example, if we hypothetically added an audience
> restriction parameter, ignoring it would be a security error. =A0(The<= br> > need for audience restriction is being heavily discussed in the OAuth<= br> > WG right now, and real exploits that have occurred for the lack of it,=
> so this example is real and fresh on my mind.) =A0If not understood, a=
> token containing an audience restriction MUST be rejected.


Consider an ecosystem with hundreds of servers and thousands of clien= t apps all using a protocol involving JOSE messages that has been operating= for a few years. A researcher finds a vulnerability in the protocol and re= sponsibly discloses it to selected servers. The fix is to add an audience r= estriction parameter "aud".

What should a server do?

If it adds the "aud" parameter immediately, every (compliant) cli= ent app will immediately break. The outage will last until every app is upd= ated, which will takes weeks, months=85? Total system shutdown to fix a fla= w that is currently theoretical=85 heads will role.

If a server announces that it will add the "aud" parameter in, sa= y, 3 months to give time for app updates then it has just disclosed a vulne= rability and given attackers a 3 month window to exploit it. Many will clam= our for an immediate fix; many will say they need longer to fix apps; it wi= ll still break for many users in 3 months=85 heads will role.

On the other hand, if the spec says unknown parameters MUST be ignored then= the server can immediately add the "aud" parameter, and immediat= ely tell client apps to start supporting it. Each app is protected as soon = as it adds support.
If actual exploits need to be stopped the server can still shutdown the who= le system, or just selected client apps, or selected users.


X.509 certificates are an interesting example for comparison. Certs are sec= urity-related, just like JOSE messages. Certs allow unrecognised additions = (eg non-critical extensions). These have been very widely used to deploy ne= w functionality.

The X.509 spec (or at least its IETF profile) has one item that MUST be und= erstood if added: the name-constraints extension. This extension should be = really useful for security. However, because adding it in the spec-complian= t MUST-understand manner will break some clients, it has barely been deploy= ed for over a decade.


Lets drop the "MUST understand everything" requirement.

--
James Manger
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



--
= --Breno
--f46d04478753e287aa04c4685420-- From Michael.Jones@microsoft.com Mon Jul 9 09:55:09 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A239421F8820 for ; Mon, 9 Jul 2012 09:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nd+0isb4lsiR for ; Mon, 9 Jul 2012 09:55:03 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 74B7321F881D for ; Mon, 9 Jul 2012 09:55:00 -0700 (PDT) Received: from mail98-ch1-R.bigfish.com (10.43.68.234) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.23; Mon, 9 Jul 2012 16:53:08 +0000 Received: from mail98-ch1 (localhost [127.0.0.1]) by mail98-ch1-R.bigfish.com (Postfix) with ESMTP id 95095160208; Mon, 9 Jul 2012 16:53:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VS-23(zz98dI9371Ic85fh1432Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail98-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail98-ch1 (localhost.localdomain [127.0.0.1]) by mail98-ch1 (MessageSwitch) id 1341852786298915_7597; Mon, 9 Jul 2012 16:53:06 +0000 (UTC) Received: from CH1EHSMHS020.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail98-ch1.bigfish.com (Postfix) with ESMTP id 462F260099; Mon, 9 Jul 2012 16:53:06 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS020.bigfish.com (10.43.70.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 9 Jul 2012 16:53:05 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0298.005; Mon, 9 Jul 2012 16:54:41 +0000 From: Mike Jones To: Breno de Medeiros , "Manger, James H" Thread-Topic: [jose] MUST understand ALL header fields Thread-Index: Ac1bpFGsDo+RPNtVSUCtA/itrmlQRAAAbGEAAHFuV4AAIZpLAAAAOjwA Date: Mon, 9 Jul 2012 16:54:41 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436657D19C@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436657A1B2@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F78D4ADF@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436657D19CTK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "Richard L. Barnes" , "jose@ietf.org" Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 16:55:09 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436657D19CTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I suspect what you're remembering is this distinction in the JWT spec. Abo= ut claims, http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-01#se= ction-4 says: "When used in a security-related context, implementations MUST understand a= nd support all of the claims present; otherwise, the JWT MUST be rejected f= or processing." Whereas about the headers, http://tools.ietf.org/html/draft-ietf-oauth-json= -web-token-01#section-5 says: "Implementations MUST understand the entire contents of the header; otherwi= se, the JWT MUST be rejected for processing." Best wishes= , -- Mike From: Breno de Medeiros [mailto:breno@google.com] Sent: Monday, July 09, 2012 9:45 AM To: Manger, James H Cc: Richard L. Barnes; Mike Jones; jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields At some point, the spec said that servers should reject tokens with unknown= parameters in the envelope (which describes the security context) but tole= rate them in the body. On Sun, Jul 8, 2012 at 5:42 PM, Manger, James H > wrote: Mike, >> Implementations MUST understand the entire contents of the >> header; otherwise, the {JWS|JWE} MUST be rejected. >> >> We should drop this restriction. Mike replied: > Since this is a security protocol, the way I see it, use of a not- > understood parameter SHOULD break implementations if they're not > prepared to handle them (or at least them cause them to reject the > input). For example, if we hypothetically added an audience > restriction parameter, ignoring it would be a security error. (The > need for audience restriction is being heavily discussed in the OAuth > WG right now, and real exploits that have occurred for the lack of it, > so this example is real and fresh on my mind.) If not understood, a > token containing an audience restriction MUST be rejected. Consider an ecosystem with hundreds of servers and thousands of client apps= all using a protocol involving JOSE messages that has been operating for a= few years. A researcher finds a vulnerability in the protocol and responsi= bly discloses it to selected servers. The fix is to add an audience restric= tion parameter "aud". What should a server do? If it adds the "aud" parameter immediately, every (compliant) client app wi= ll immediately break. The outage will last until every app is updated, whic= h will takes weeks, months...? Total system shutdown to fix a flaw that is = currently theoretical... heads will role. If a server announces that it will add the "aud" parameter in, say, 3 month= s to give time for app updates then it has just disclosed a vulnerability a= nd given attackers a 3 month window to exploit it. Many will clamour for an= immediate fix; many will say they need longer to fix apps; it will still b= reak for many users in 3 months... heads will role. On the other hand, if the spec says unknown parameters MUST be ignored then= the server can immediately add the "aud" parameter, and immediately tell c= lient apps to start supporting it. Each app is protected as soon as it adds= support. If actual exploits need to be stopped the server can still shutdown the who= le system, or just selected client apps, or selected users. X.509 certificates are an interesting example for comparison. Certs are sec= urity-related, just like JOSE messages. Certs allow unrecognised additions = (eg non-critical extensions). These have been very widely used to deploy ne= w functionality. The X.509 spec (or at least its IETF profile) has one item that MUST be und= erstood if added: the name-constraints extension. This extension should be = really useful for security. However, because adding it in the spec-complian= t MUST-understand manner will break some clients, it has barely been deploy= ed for over a decade. Lets drop the "MUST understand everything" requirement. -- James Manger _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose -- --Breno --_000_4E1F6AAD24975D4BA5B16804296739436657D19CTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I suspect what you’= re remembering is this distinction in the JWT spec.  About claims, http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-01#section-4= says:

 <= /p>

 <= /p>

Whereas about the headers= , http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-01#section-5= says:

 <= /p>

 <= /p>

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

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

 <= /p>

From: Breno de= Medeiros [mailto:breno@google.com]
Sent: Monday, July 09, 2012 9:45 AM
To: Manger, James H
Cc: Richard L. Barnes; Mike Jones; jose@ietf.org
Subject: Re: [jose] MUST understand ALL header fields

 

At some point, the spec said that servers should rej= ect tokens with unknown parameters in the envelope (which describes the sec= urity context) but tolerate them in the body.

 

On Sun, Jul 8, 2012 at 5:42 PM, Manger, James H <= James.= H.Manger@team.telstra.com> wrote:

Mike,


>>    Implementations MUST understand the entire contents o= f the
>>    header; otherwise, the {JWS|JWE} MUST be rejected. >>
>> We should drop this restriction.

Mike replied:

> Since this is a = security protocol, the way I see it, use of a not-
> understood parameter SHOULD break implementations if they’re not=
> prepared to handle them (or at least them cause them to reject the
> input).  For example, if we hypothetically added an audience
> restriction parameter, ignoring it would be a security error.  (T= he
> need for audience restriction is being heavily discussed in the OAuth<= br> > WG right now, and real exploits that have occurred for the lack of it,=
> so this example is real and fresh on my mind.)  If not understood= , a
> token containing an audience restriction MUST be rejected.

Consider an ecosystem with hundreds of servers and t= housands of client apps all using a protocol involving JOSE messages that h= as been operating for a few years. A researcher finds a vulnerability in th= e protocol and responsibly discloses it to selected servers. The fix is to add an audience restriction paramete= r "aud".

What should a server do?

If it adds the "aud" parameter immediately, every (compliant) cli= ent app will immediately break. The outage will last until every app is upd= ated, which will takes weeks, months…? Total system shutdown to fix a= flaw that is currently theoretical… heads will role.

If a server announces that it will add the "aud" parameter in, sa= y, 3 months to give time for app updates then it has just disclosed a vulne= rability and given attackers a 3 month window to exploit it. Many will clam= our for an immediate fix; many will say they need longer to fix apps; it will still break for many users in 3 months= 230; heads will role.

On the other hand, if the spec says unknown parameters MUST be ignored then= the server can immediately add the "aud" parameter, and immediat= ely tell client apps to start supporting it. Each app is protected as soon = as it adds support.
If actual exploits need to be stopped the server can still shutdown the who= le system, or just selected client apps, or selected users.


X.509 certificates are an interesting example for comparison. Certs are sec= urity-related, just like JOSE messages. Certs allow unrecognised additions = (eg non-critical extensions). These have been very widely used to deploy ne= w functionality.

The X.509 spec (or at least its IETF profile) has one item that MUST be und= erstood if added: the name-constraints extension. This extension should be = really useful for security. However, because adding it in the spec-complian= t MUST-understand manner will break some clients, it has barely been deployed for over a decade.


Lets drop the "MUST understand everything" requirement.


--
James Manger
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



 

--
--Breno

--_000_4E1F6AAD24975D4BA5B16804296739436657D19CTK5EX14MBXC283r_-- From breno@google.com Mon Jul 9 10:05:01 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7400911E8100 for ; Mon, 9 Jul 2012 10:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.356 X-Spam-Level: X-Spam-Status: No, score=-102.356 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hp18+bUW+gjS for ; Mon, 9 Jul 2012 10:05:00 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 605C711E80E8 for ; Mon, 9 Jul 2012 10:05:00 -0700 (PDT) Received: by ghbg16 with SMTP id g16so11334660ghb.31 for ; Mon, 09 Jul 2012 10:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=q5FVqXc9vdZM3P/vWBcOjXO2fL+9PnZvywfylB0yfsA=; b=CfVPKo55J7/qPyOf6rhqNq3NNA9R9o+I6yOFlgNrqih33reqA0Wg5LjM580TaM5pLB cVFeQbTFG+4C79W3ALp84AwkQtDSNDTH3udFPQ4H3wwI7SuXPaoaGXQ1uUwX7antqame 8BzTMnZb31qnqQGlE9XLnhvedOd6GgeEiv9wSUQhQlDVLlo3S00JY4Xlk+yEchJDrqdL CrNX/JXpENvXcfMWGmiw6RYNiJXhgSji8MHWIX1FuTQlf3CcyDfycaVncwt3rvT3mI72 ZPJKrLQ2FYR4LkxoxtryedpuhAGl9rNFGqr6D/noXQ/Yee/1JG2yL3YHzY4uhiiF9Six QLnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=q5FVqXc9vdZM3P/vWBcOjXO2fL+9PnZvywfylB0yfsA=; b=Zi3q9EXLI6rkBzyg4GNpXcA6X0FG4DgtwlsmZ0+hCFZg50ErO1ijp0WBcdk28vj3Yk /rEKoQ1xc0mkDfTK9qcrSt/zF2LpVDQ6llwQjd2QOgNbj9HElcffQmK6GKecX+btiPuE JAX62w4DoPKp//d2L58zDc3yZ8IBIQEJkxlQ+uMsvDVTHi3IAeGH2RuAIswCK02rSlcg thbECmBBBlhRUVxTHNOf+O7fhQkRq1+v/L6NgACiSWNVvxYewZiC9/EAxHIC8N7OocGK 9Jj13q8SgnRgH3QlDOSsX6JkRIryPtYNdkTxCSngpqb3dsOrFE0UyUbrGpoYlhLR6bj5 YS8g== Received: by 10.50.237.1 with SMTP id uy1mr9188999igc.18.1341853525143; Mon, 09 Jul 2012 10:05:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.237.1 with SMTP id uy1mr9188988igc.18.1341853525008; Mon, 09 Jul 2012 10:05:25 -0700 (PDT) Received: by 10.231.17.194 with HTTP; Mon, 9 Jul 2012 10:05:24 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436657D19C@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436657A1B2@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F78D4ADF@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436657D19C@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 9 Jul 2012 10:05:24 -0700 Message-ID: From: Breno de Medeiros To: Mike Jones Content-Type: multipart/alternative; boundary=f46d04478753b2e2e104c4689e6d X-System-Of-Record: true X-Gm-Message-State: ALoCoQkdvc3Xka/qHeW/i4ogCdtsJtZYW1GXpyVZka+9ohQ4DVVqkf5mN7iRbrVVodCYR0v0nsWzvRdhG4aiRbHITpP6HBm2BzxeXiEiUg1c+qRPtu9M/UefiUyby7NpUWt4qbkIda47hrjsPlav3RXGNufz25r27yhqjOc7RWuAF8O5sE1fk0w= Cc: "Richard L. Barnes" , "Manger, James H" , "jose@ietf.org" Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 17:05:01 -0000 --f46d04478753b2e2e104c4689e6d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hmmm... "when used in a security-related context" is quite vague. If this wasn't a security-context, there'd be no need for crypto. I think for the first part, it'd be more helpful to say: "Implementations SHOULD ignore unknown claims in JWT payload unless the security context of their application requires otherwise." On Mon, Jul 9, 2012 at 9:54 AM, Mike Jones wro= te: > I suspect what you=92re remembering is this distinction in the JWT spec. > About claims, > http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-01#section-4sa= ys: > **** > > ** ** > > =93When used in a security-related context, implementations MUST understa= nd > and support all of the claims present; otherwise, the JWT MUST be rejecte= d > for processing.=94**** > > ** ** > > Whereas about the headers, > http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-01#section-5sa= ys: > **** > > ** ** > > =93Implementations MUST understand the entire contents of the header; > otherwise, the JWT MUST be rejected for processing.=94**** > > ** ** > > Best > wishes,**** > > -- Mike**= * > * > > ** ** > > *From:* Breno de Medeiros [mailto:breno@google.com] > *Sent:* Monday, July 09, 2012 9:45 AM > *To:* Manger, James H > *Cc:* Richard L. Barnes; Mike Jones; jose@ietf.org > *Subject:* Re: [jose] MUST understand ALL header fields**** > > ** ** > > At some point, the spec said that servers should reject tokens with > unknown parameters in the envelope (which describes the security context) > but tolerate them in the body.**** > > ** ** > > On Sun, Jul 8, 2012 at 5:42 PM, Manger, James H < > James.H.Manger@team.telstra.com> wrote:**** > > Mike,**** > > > >> Implementations MUST understand the entire contents of the > >> header; otherwise, the {JWS|JWE} MUST be rejected. > >> > >> We should drop this restriction.**** > > Mike replied:**** > > > Since this is a security protocol, the way I see it, use of a not- > > understood parameter SHOULD break implementations if they=92re not > > prepared to handle them (or at least them cause them to reject the > > input). For example, if we hypothetically added an audience > > restriction parameter, ignoring it would be a security error. (The > > need for audience restriction is being heavily discussed in the OAuth > > WG right now, and real exploits that have occurred for the lack of it, > > so this example is real and fresh on my mind.) If not understood, a > > token containing an audience restriction MUST be rejected. > > **** > > Consider an ecosystem with hundreds of servers and thousands of client > apps all using a protocol involving JOSE messages that has been operating > for a few years. A researcher finds a vulnerability in the protocol and > responsibly discloses it to selected servers. The fix is to add an audien= ce > restriction parameter "aud". > > What should a server do? > > If it adds the "aud" parameter immediately, every (compliant) client app > will immediately break. The outage will last until every app is updated, > which will takes weeks, months=85? Total system shutdown to fix a flaw th= at > is currently theoretical=85 heads will role. > > If a server announces that it will add the "aud" parameter in, say, 3 > months to give time for app updates then it has just disclosed a > vulnerability and given attackers a 3 month window to exploit it. Many wi= ll > clamour for an immediate fix; many will say they need longer to fix apps; > it will still break for many users in 3 months=85 heads will role. > > On the other hand, if the spec says unknown parameters MUST be ignored > then the server can immediately add the "aud" parameter, and immediately > tell client apps to start supporting it. Each app is protected as soon as > it adds support. > If actual exploits need to be stopped the server can still shutdown the > whole system, or just selected client apps, or selected users. > > > X.509 certificates are an interesting example for comparison. Certs are > security-related, just like JOSE messages. Certs allow unrecognised > additions (eg non-critical extensions). These have been very widely used = to > deploy new functionality. > > The X.509 spec (or at least its IETF profile) has one item that MUST be > understood if added: the name-constraints extension. This extension shoul= d > be really useful for security. However, because adding it in the > spec-compliant MUST-understand manner will break some clients, it has > barely been deployed for over a decade. > > > Lets drop the "MUST understand everything" requirement.**** > > > -- > James Manger > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > > > **** > > ** ** > > -- > --Breno**** > --=20 --Breno --f46d04478753b2e2e104c4689e6d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hmmm... "when used in a security-related context" =A0is quite vag= ue. If this wasn't a security-context, there'd be no need for crypt= o. I think for the first part, it'd be more helpful to say:

"Implementations SHOULD ignore unknown claims in JWT payload unle= ss the security context of their application requires otherwise."


On Mon, Jul = 9, 2012 at 9:54 AM, Mike Jones <Michael.Jones@microsoft.com&= gt; wrote:

I suspect what you=92re r= emembering is this distinction in the JWT spec.=A0 About claims, http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-01#section-4= says:

=A0<= /p>

=A0<= /p>

Whereas about the headers= , http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-01#section-5= says:

=A0<= /p>

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Best wishes,

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

=A0<= /p>

From: Breno de= Medeiros [mailto:bre= no@google.com]
Sent: Monday, July 09, 2012 9:45 AM
To: Manger, James H
Cc: Richard L. Barnes; Mike Jones; jose@ietf.org
Subject: Re: [jose] MUST understand ALL header fields<= /span>

=A0

At some point, the spec said that servers should rej= ect tokens with unknown parameters in the envelope (which describes the sec= urity context) but tolerate them in the body.

=A0

On Sun, Jul 8, 2012 at 5:42 PM, Manger, James H <= James.= H.Manger@team.telstra.com> wrote:

Mike,


>> =A0 =A0Implementations MUST understand the entire contents of the<= br> >> =A0 =A0header; otherwise, the {JWS|JWE} MUST be rejected.
>>
>> We should drop this restriction.

Mike replied:

> Since this is a = security protocol, the way I see it, use of a not-
> understood parameter SHOULD break implementations if they=92re not
> prepared to handle them (or at least them cause them to reject the
> input). =A0For example, if we hypothetically added an audience
> restriction parameter, ignoring it would be a security error. =A0(The<= br> > need for audience restriction is being heavily discussed in the OAuth<= br> > WG right now, and real exploits that have occurred for the lack of it,=
> so this example is real and fresh on my mind.) =A0If not understood, a=
> token containing an audience restriction MUST be rejected.

Consider an ecosystem with hundreds of servers and t= housands of client apps all using a protocol involving JOSE messages that h= as been operating for a few years. A researcher finds a vulnerability in th= e protocol and responsibly discloses it to selected servers. The fix is to add an audience restriction paramete= r "aud".

What should a server do?

If it adds the "aud" parameter immediately, every (compliant) cli= ent app will immediately break. The outage will last until every app is upd= ated, which will takes weeks, months=85? Total system shutdown to fix a fla= w that is currently theoretical=85 heads will role.

If a server announces that it will add the "aud" parameter in, sa= y, 3 months to give time for app updates then it has just disclosed a vulne= rability and given attackers a 3 month window to exploit it. Many will clam= our for an immediate fix; many will say they need longer to fix apps; it will still break for many users in 3 months=85= heads will role.

On the other hand, if the spec says unknown parameters MUST be ignored then= the server can immediately add the "aud" parameter, and immediat= ely tell client apps to start supporting it. Each app is protected as soon = as it adds support.
If actual exploits need to be stopped the server can still shutdown the who= le system, or just selected client apps, or selected users.


X.509 certificates are an interesting example for comparison. Certs are sec= urity-related, just like JOSE messages. Certs allow unrecognised additions = (eg non-critical extensions). These have been very widely used to deploy ne= w functionality.

The X.509 spec (or at least its IETF profile) has one item that MUST be und= erstood if added: the name-constraints extension. This extension should be = really useful for security. However, because adding it in the spec-complian= t MUST-understand manner will break some clients, it has barely been deployed for over a decade.


Lets drop the "MUST understand everything" requirement.=


--
James Manger
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



=A0

--
--Breno




--
--Breno
--f46d04478753b2e2e104c4689e6d-- From Michael.Jones@microsoft.com Mon Jul 9 11:40:30 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9C221F8830 for ; Mon, 9 Jul 2012 11:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXsB3D84eZB1 for ; Mon, 9 Jul 2012 11:40:26 -0700 (PDT) Received: from DB3EHSOBE004.bigfish.com (mail-db3.bigfish.com [94.245.120.74]) by ietfa.amsl.com (Postfix) with ESMTP id 59E9121F882C for ; Mon, 9 Jul 2012 11:40:21 -0700 (PDT) Received: from mail56-db3-R.bigfish.com (10.3.81.234) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.23; Mon, 9 Jul 2012 18:38:29 +0000 Received: from mail56-db3 (localhost [127.0.0.1]) by mail56-db3-R.bigfish.com (Postfix) with ESMTP id DC0504E04CF; Mon, 9 Jul 2012 18:38:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zz98dI9371Ic85fh179dN1432Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail56-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail56-db3 (localhost.localdomain [127.0.0.1]) by mail56-db3 (MessageSwitch) id 1341859105913101_18010; Mon, 9 Jul 2012 18:38:25 +0000 (UTC) Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.252]) by mail56-db3.bigfish.com (Postfix) with ESMTP id DC49F16004D; Mon, 9 Jul 2012 18:38:25 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS010.bigfish.com (10.3.87.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 9 Jul 2012 18:38:25 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0309.003; Mon, 9 Jul 2012 18:40:30 +0000 From: Mike Jones To: Breno de Medeiros Thread-Topic: [jose] MUST understand ALL header fields Thread-Index: Ac1bpFGsDo+RPNtVSUCtA/itrmlQRAAAbGEAAHFuV4AAIZpLAAAAOjwAAAB+PgAAA08CIA== Date: Mon, 9 Jul 2012 18:40:29 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436657D604@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436657A1B2@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F78D4ADF@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436657D19C@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436657D604TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "Richard L. Barnes" , "Manger, James H" , "jose@ietf.org" Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 18:40:30 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436657D604TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (Moving this discussion to the OAuth list, since JWT is an OAuth spec) From: Breno de Medeiros [mailto:breno@google.com] Sent: Monday, July 09, 2012 10:05 AM To: Mike Jones Cc: Manger, James H; Richard L. Barnes; jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields Hmmm... "when used in a security-related context" is quite vague. If this = wasn't a security-context, there'd be no need for crypto. I think for the f= irst part, it'd be more helpful to say: "Implementations SHOULD ignore unknown claims in JWT payload unless the sec= urity context of their application requires otherwise." On Mon, Jul 9, 2012 at 9:54 AM, Mike Jones > wrote: I suspect what you're remembering is this distinction in the JWT spec. Abo= ut claims, http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-01#se= ction-4 says: "When used in a security-related context, implementations MUST understand a= nd support all of the claims present; otherwise, the JWT MUST be rejected f= or processing." Whereas about the headers, http://tools.ietf.org/html/draft-ietf-oauth-json= -web-token-01#section-5 says: "Implementations MUST understand the entire contents of the header; otherwi= se, the JWT MUST be rejected for processing." Best wishes= , -- Mike From: Breno de Medeiros [mailto:breno@google.com] Sent: Monday, July 09, 2012 9:45 AM To: Manger, James H Cc: Richard L. Barnes; Mike Jones; jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields At some point, the spec said that servers should reject tokens with unknown= parameters in the envelope (which describes the security context) but tole= rate them in the body. On Sun, Jul 8, 2012 at 5:42 PM, Manger, James H > wrote: Mike, >> Implementations MUST understand the entire contents of the >> header; otherwise, the {JWS|JWE} MUST be rejected. >> >> We should drop this restriction. Mike replied: > Since this is a security protocol, the way I see it, use of a not- > understood parameter SHOULD break implementations if they're not > prepared to handle them (or at least them cause them to reject the > input). For example, if we hypothetically added an audience > restriction parameter, ignoring it would be a security error. (The > need for audience restriction is being heavily discussed in the OAuth > WG right now, and real exploits that have occurred for the lack of it, > so this example is real and fresh on my mind.) If not understood, a > token containing an audience restriction MUST be rejected. Consider an ecosystem with hundreds of servers and thousands of client apps= all using a protocol involving JOSE messages that has been operating for a= few years. A researcher finds a vulnerability in the protocol and responsi= bly discloses it to selected servers. The fix is to add an audience restric= tion parameter "aud". What should a server do? If it adds the "aud" parameter immediately, every (compliant) client app wi= ll immediately break. The outage will last until every app is updated, whic= h will takes weeks, months...? Total system shutdown to fix a flaw that is = currently theoretical... heads will role. If a server announces that it will add the "aud" parameter in, say, 3 month= s to give time for app updates then it has just disclosed a vulnerability a= nd given attackers a 3 month window to exploit it. Many will clamour for an= immediate fix; many will say they need longer to fix apps; it will still b= reak for many users in 3 months... heads will role. On the other hand, if the spec says unknown parameters MUST be ignored then= the server can immediately add the "aud" parameter, and immediately tell c= lient apps to start supporting it. Each app is protected as soon as it adds= support. If actual exploits need to be stopped the server can still shutdown the who= le system, or just selected client apps, or selected users. X.509 certificates are an interesting example for comparison. Certs are sec= urity-related, just like JOSE messages. Certs allow unrecognised additions = (eg non-critical extensions). These have been very widely used to deploy ne= w functionality. The X.509 spec (or at least its IETF profile) has one item that MUST be und= erstood if added: the name-constraints extension. This extension should be = really useful for security. However, because adding it in the spec-complian= t MUST-understand manner will break some clients, it has barely been deploy= ed for over a decade. Lets drop the "MUST understand everything" requirement. -- James Manger _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose -- --Breno -- --Breno --_000_4E1F6AAD24975D4BA5B16804296739436657D604TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(Moving this discussion t= o the OAuth list, since JWT is an OAuth spec)

 <= /p>

From: Breno de= Medeiros [mailto:breno@google.com]
Sent: Monday, July 09, 2012 10:05 AM
To: Mike Jones
Cc: Manger, James H; Richard L. Barnes; jose@ietf.org
Subject: Re: [jose] MUST understand ALL header fields

 

Hmmm... "when used in a security-related contex= t"  is quite vague. If this wasn't a security-context, there'd be= no need for crypto. I think for the first part, it'd be more helpful to sa= y:

 

"Implementations SHOULD ignore unknown claims i= n JWT payload unless the security context of their application requires oth= erwise."

 

On Mon, Jul 9, 2012 at 9:54 AM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:

I suspect what you’re remembering= is this distinction in the JWT spec.  About claims, http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-01#section-4= says:

 

“When used in a security-related context, = implementations MUST understand and support all of the claims present; othe= rwise, the JWT MUST be rejected for processing.”

 

Whereas about the headers, http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-01#section-5= says:

 

“Implementations MUST understand the entir= e contents of the header; otherwise, the JWT MUST be rejected for processin= g.”

 

      &nb= sp;            =             &nb= sp;            =             &nb= sp;       Best wishes,

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

 

From: Breno de Medeiros [mai= lto:breno@google.com<= /a>]
Sent: Monday, July 09, 2012 9:45 AM
To: Manger, James H
Cc: Richard L. Barnes; Mike Jones; jose@ietf.org
Subject: Re: [jose] MUST understand ALL header fields

 

At some point, the spec said that servers should reject tokens wit= h unknown parameters in the envelope (which describes the security context)= but tolerate them in the body.

 

On Sun, Jul 8, 2012 at 5:42 PM, Manger, James H <James.H.Manger@team.= telstra.com> wrote:

Mike,


>>    Implementations MUST understand the entire contents o= f the
>>    header; otherwise, the {JWS|JWE} MUST be rejected. >>
>> We should drop this restriction.

Mike replied:

> Since this is a security protocol, the way I see it, use of a not-<= br> > understood parameter SHOULD break implementations if they’re not=
> prepared to handle them (or at least them cause them to reject the
> input).  For example, if we hypothetically added an audience
> restriction parameter, ignoring it would be a security error.  (T= he
> need for audience restriction is being heavily discussed in the OAuth<= br> > WG right now, and real exploits that have occurred for the lack of it,=
> so this example is real and fresh on my mind.)  If not understood= , a
> token containing an audience restriction MUST be rejected.<= /p>

Consider an ecosystem with hundreds of servers and thousands of cl= ient apps all using a protocol involving JOSE messages that has been operat= ing for a few years. A researcher finds a vulnerability in the protocol and responsibly discloses it to selected s= ervers. The fix is to add an audience restriction parameter "aud"= .

What should a server do?

If it adds the "aud" parameter immediately, every (compliant) cli= ent app will immediately break. The outage will last until every app is upd= ated, which will takes weeks, months…? Total system shutdown to fix a= flaw that is currently theoretical… heads will role.

If a server announces that it will add the "aud" parameter in, sa= y, 3 months to give time for app updates then it has just disclosed a vulne= rability and given attackers a 3 month window to exploit it. Many will clam= our for an immediate fix; many will say they need longer to fix apps; it will still break for many users in 3 months= 230; heads will role.

On the other hand, if the spec says unknown parameters MUST be ignored then= the server can immediately add the "aud" parameter, and immediat= ely tell client apps to start supporting it. Each app is protected as soon = as it adds support.
If actual exploits need to be stopped the server can still shutdown the who= le system, or just selected client apps, or selected users.


X.509 certificates are an interesting example for comparison. Certs are sec= urity-related, just like JOSE messages. Certs allow unrecognised additions = (eg non-critical extensions). These have been very widely used to deploy ne= w functionality.

The X.509 spec (or at least its IETF profile) has one item that MUST be und= erstood if added: the name-constraints extension. This extension should be = really useful for security. However, because adding it in the spec-complian= t MUST-understand manner will break some clients, it has barely been deployed for over a decade.


Lets drop the "MUST understand everything" requirement.


--
James Manger
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



 

--
--Breno



 

--
--Breno

--_000_4E1F6AAD24975D4BA5B16804296739436657D604TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Mon Jul 9 16:55:33 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11ABD21F85B1 for ; Mon, 9 Jul 2012 16:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.797 X-Spam-Level: X-Spam-Status: No, score=-3.797 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ocv-Uej+bzAJ for ; Mon, 9 Jul 2012 16:55:32 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 6283021F85D8 for ; Mon, 9 Jul 2012 16:55:30 -0700 (PDT) Received: from mail87-am1-R.bigfish.com (10.3.201.227) by AM1EHSOBE009.bigfish.com (10.3.204.29) with Microsoft SMTP Server id 14.1.225.23; Mon, 9 Jul 2012 23:53:36 +0000 Received: from mail87-am1 (localhost [127.0.0.1]) by mail87-am1-R.bigfish.com (Postfix) with ESMTP id 9724B1E046D for ; Mon, 9 Jul 2012 23:53:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VS-20(zzc85fhzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail87-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail87-am1 (localhost.localdomain [127.0.0.1]) by mail87-am1 (MessageSwitch) id 1341878013269771_7335; Mon, 9 Jul 2012 23:53:33 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.231]) by mail87-am1.bigfish.com (Postfix) with ESMTP id 3F5433A0061 for ; Mon, 9 Jul 2012 23:53:33 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 9 Jul 2012 23:53:33 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0298.005; Mon, 9 Jul 2012 23:55:41 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: JSON Serialization Documents Renamed Thread-Index: Ac1eLlgtAGPlmPzpTnSS7vOnKp5UdA== Date: Mon, 9 Jul 2012 23:55:40 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436657E213@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436657E213TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [jose] JSON Serialization Documents Renamed X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 23:55:33 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436657E213TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I renamed the JSON Serialization documents so they have "jose" in the docum= ent name. Jim Schaad tells me that then they'll automatically be added to = the JOSE Related Documents list at http://datatracker.ietf.org/wg/jose/. N= o normative changes were made. These documents use the JWS and JWE crypto calculations, but enable multipl= e parallel signatures and multiple recipients. The new versions are: * http://tools.ietf.org/html/draft-jones-jose-jws-json-serializatio= n-00 * http://tools.ietf.org/html/draft-jones-jose-jwe-json-serializatio= n-00 -- Mike --_000_4E1F6AAD24975D4BA5B16804296739436657E213TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I renamed the JSON Serialization documents so they h= ave "jose" in the document name.  Jim Schaad tells me that t= hen they’ll automatically be added to the JOSE Related Documents list= at http://datatracker.ietf.or= g/wg/jose/.  No normative changes were made.

 

These documents use the JWS and JWE crypto calculati= ons, but enable multiple parallel signatures and multiple recipients.<= /o:p>

 

The new versions are:

·         http://= tools.ietf.org/html/draft-jones-jose-jws-json-serialization-00

·         http://= tools.ietf.org/html/draft-jones-jose-jwe-json-serialization-00

 

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

 

--_000_4E1F6AAD24975D4BA5B16804296739436657E213TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Mon Jul 9 17:00:10 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8350D21F8652 for ; Mon, 9 Jul 2012 17:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.794 X-Spam-Level: X-Spam-Status: No, score=-3.794 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzeViE5-SAdE for ; Mon, 9 Jul 2012 17:00:09 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6FC21F864F for ; Mon, 9 Jul 2012 17:00:08 -0700 (PDT) Received: from mail171-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.23; Mon, 9 Jul 2012 23:58:16 +0000 Received: from mail171-ch1 (localhost [127.0.0.1]) by mail171-ch1-R.bigfish.com (Postfix) with ESMTP id 4D5681E0309 for ; Mon, 9 Jul 2012 23:58:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -7 X-BigFish: VS-7(z691L6caIzc85fh4015I14ffIzz1202hzz8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail171-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail171-ch1 (localhost.localdomain [127.0.0.1]) by mail171-ch1 (MessageSwitch) id 1341878294311092_4797; Mon, 9 Jul 2012 23:58:14 +0000 (UTC) Received: from CH1EHSMHS015.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.241]) by mail171-ch1.bigfish.com (Postfix) with ESMTP id 4A567260044 for ; Mon, 9 Jul 2012 23:58:14 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 9 Jul 2012 23:58:13 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0309.003; Tue, 10 Jul 2012 00:00:29 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Minor release this week for JOSE specs Thread-Index: Ac1eLwNmPBWwq0vhQ/aC2toJHOmrsA== Date: Tue, 10 Jul 2012 00:00:28 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436657E262@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436657E262TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [jose] Minor release this week for JOSE specs X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 00:00:10 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436657E262TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, The -03 drafts of our specs were a "major release" - incorporating changes = resulting from almost 200 comments on the specs, including some very major = changes/additions like adding testable encryption examples. Since last wee= k's release, some additional comments have been trickling in on the -03 dra= fts. I should have time to do a "minor release" this week. If there are issues = with the current drafts that you'd like see corrected or cataloged before V= ancouver, please try to get them to me by mid-week. That should enable me = to turn the crank before next Monday's submission cut-off. Thanks, -- Mike --_000_4E1F6AAD24975D4BA5B16804296739436657E262TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

The -03 drafts of our specs were a “major rele= ase” – incorporating changes resulting from almost 200 comments= on the specs, including some very major changes/additions like adding test= able encryption examples.  Since last week’s release, some additional comments have been trickling in on the -03 drafts.

 

I should have time to do a “minor release̶= 1; this week.  If there are issues with the current drafts that you= 217;d like see corrected or cataloged before Vancouver, please try to get t= hem to me by mid-week.  That should enable me to turn the crank before next Monday’s submission cut-off.

 

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

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

 

--_000_4E1F6AAD24975D4BA5B16804296739436657E262TK5EX14MBXC283r_-- From bcampbell@pingidentity.com Mon Jul 9 19:19:33 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8D821F8644 for ; Mon, 9 Jul 2012 19:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.986 X-Spam-Level: X-Spam-Status: No, score=-5.986 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEogYwUqAuxr for ; Mon, 9 Jul 2012 19:19:33 -0700 (PDT) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by ietfa.amsl.com (Postfix) with ESMTP id AFEEA21F85F7 for ; Mon, 9 Jul 2012 19:19:32 -0700 (PDT) Received: from mail-vc0-f173.google.com ([209.85.220.173]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKT/uRTqj2unh1uko+FCtULbM9F3EgBV0l@postini.com; Mon, 09 Jul 2012 19:19:59 PDT Received: by vcbfo13 with SMTP id fo13so9541966vcb.32 for ; Mon, 09 Jul 2012 19:19:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=5RuOy3/wwd9blTcKmOgDN7fegmmvYlHsTUNuXrSRPhI=; b=CcK4AQ4NsQbfZRxsTuLTnEnaxHlBgRE+2rerItnc0UT/CLq2HbHvtvtwGzHajs8Vlh 348fmb5uNnetmc1tBPS9/OwJv1wQn+eavBlU/TFv46/2Ig9f6ziM7O8TPhX2CzljHQ0/ +3zjbQiumj8k47Lyt9lI0miFNeciH22gy1utfiM7lauTBlZizj8J1Obve0m4/QwYxxj0 fZuMvtGD2q+f/xAhByQaiB7WPd1+9JG6AlcPdr7Jhn61Tdq9QcGbZB4T4Tfe1aShiETJ YeaaMNYrMXREvFnQltlgPalqqcCtJ+RPoyWUaSG4mheOLQTZAr/q2CDHpxEORrOlEnmy GAkw== Received: by 10.220.240.18 with SMTP id ky18mr20236315vcb.74.1341886797624; Mon, 09 Jul 2012 19:19:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.34.107 with HTTP; Mon, 9 Jul 2012 19:19:27 -0700 (PDT) From: Brian Campbell Date: Mon, 9 Jul 2012 20:19:27 -0600 Message-ID: To: Mike Jones Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk7TOGDeQjq5skQrhK8mRSCaeI30k2MnyNcTUZ1Kd1nMYcs6DlZ9Z2HSUMHeks21w6u+zsD Cc: "jose@ietf.org" Subject: [jose] nit on Base64url (was Re: Minor release this week for JOSE specs) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 02:19:33 -0000 A minor thing but both JWS and JWE use the term Base64url in the Terminology section before it is actually introduced/defined. The two drafts might read a little better if the Base64url definition came earlier in the Terminology sections before the Encoded JWX XXXXX definitions. On Mon, Jul 9, 2012 at 6:00 PM, Mike Jones wr= ote: > Hi all, > > > > The -03 drafts of our specs were a =93major release=94 =96 incorporating = changes > resulting from almost 200 comments on the specs, including some very majo= r > changes/additions like adding testable encryption examples. Since last > week=92s release, some additional comments have been trickling in on the = -03 > drafts. > > > > I should have time to do a =93minor release=94 this week. If there are i= ssues > with the current drafts that you=92d like see corrected or cataloged befo= re > Vancouver, please try to get them to me by mid-week. That should enable = me > to turn the crank before next Monday=92s submission cut-off. > > > > Thanks, > > -- Mike > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > From turners@ieca.com Tue Jul 10 07:18:32 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D369F21F8628 for ; Tue, 10 Jul 2012 07:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.206 X-Spam-Level: X-Spam-Status: No, score=-102.206 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiOW5XFWVVVg for ; Tue, 10 Jul 2012 07:18:32 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.56.150.9]) by ietfa.amsl.com (Postfix) with ESMTP id 36A8F21F8627 for ; Tue, 10 Jul 2012 07:18:32 -0700 (PDT) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id 51700A87AE1E0; Tue, 10 Jul 2012 09:19:00 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway14.websitewelcome.com (Postfix) with ESMTP id 3E5B1A87AE198 for ; Tue, 10 Jul 2012 09:19:00 -0500 (CDT) Received: from [96.231.119.66] (port=33535 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SobHG-0007U3-PW; Tue, 10 Jul 2012 09:18:59 -0500 Message-ID: <4FFC39D1.40802@ieca.com> Date: Tue, 10 Jul 2012 10:18:57 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B168042967394366579F40@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366579F40@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.119.66]:33535 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 14:18:33 -0000 On 7/6/12 1:32 PM, Mike Jones wrote: > Thanks for taking the time to provide the detailed feedback. Responses > inline… > > -----Original Message----- > From: jose-bounces@ietf.org > [mailto:jose-bounces@ietf.org] > On Behalf Of Sean Turner > Sent: Monday, May 28, 2012 10:36 AM > Cc: jose@ietf.org > Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt > > Here's some comments (again I'll try not to duplicate Jim's): > > 1) s2 & Requirements Language: The RFC editor is going to move the > Requirements Language section later on so you might as well save them > the trouble and just make it part of s2. > > Done here, plus in JWE, JWS, JWA, JWT, JWE-JS, JWS-JS, and SWD Thanks. I know this seems silly, but it's nice to save them some time. > 2) s3: This is probably a style thing, but I think it's probably better > to talk about the structure first and then provide an example. It's > just going to make everybody ask you to define/explain x in that section. > > I tried to do this and couldn’t find a better location. The spec is so > short, that you’re never more than a page from the example to the > normative text anyway. :-) Besides, given that all the meaty parts (the > actual algorithm specifications) have moved to the JWA spec, the > descriptions would probably be pretty abstract without an example to > root them in. Left as is, at least for now. ack > 3) s4: Totally agree with Jim's comment #4 on this section. Applies to > > s5 as well. > > Addressed, per Jim’s comments ack > 4) s4: Same concerns as for algorithms about the collision resistant > namespace and how the registry is set up. > > Addressed, per Jim’s comments ack > 5) s4.2: Assume "both" should be defined here. > > At least for Elliptic Curve keys, I believe that there’s a potential > vulnerability with using the same key for both signing and encryption. > So I’m reluctant to define “both”. The simplest way to indicate both > may be to omit the parameter. This could also be represented by > repeating the key with “use”:”sig” and “use”:”enc” in the key set. What > do others in the working group think about these possibilities? Okay so I think I was a little confused here. Implementations will know the context of "alg" etc. based on which JW* they're in. Both really wouldn't make sense in that case. But, that makes me think that the registry needs to be clear about which JW* the algs apply to and that means adding a new column/bullet in 6.1.1 and then filled out for all in 6.1.2 for: Usage: Indicate which JW* construct the algorithm applies to. For example: JWS. I suspect there will be some people who will just look at the registry and not at the tables in s4. > 6) s7: If the kid is not supposed to be generated in a way to make it > unique it's worth pointing this out in s7. > > Done ack > spt > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > From turners@ieca.com Tue Jul 10 07:22:34 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E0711E80C8 for ; Tue, 10 Jul 2012 07:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.207 X-Spam-Level: X-Spam-Status: No, score=-102.207 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+c-kJSCGWBN for ; Tue, 10 Jul 2012 07:22:34 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.56.142.20]) by ietfa.amsl.com (Postfix) with ESMTP id A56B211E808E for ; Tue, 10 Jul 2012 07:22:33 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id EF421ABF460CE; Tue, 10 Jul 2012 09:23:00 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway02.websitewelcome.com (Postfix) with ESMTP id E3E23ABF460A5 for ; Tue, 10 Jul 2012 09:23:00 -0500 (CDT) Received: from [96.231.119.66] (port=38073 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SobL9-0000ri-Qc; Tue, 10 Jul 2012 09:23:00 -0500 Message-ID: <4FFC3AC2.1070403@ieca.com> Date: Tue, 10 Jul 2012 10:22:58 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B168042967394366579F40@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FFC39D1.40802@ieca.com> In-Reply-To: <4FFC39D1.40802@ieca.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.119.66]:38073 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 14:22:34 -0000 Sorry about this but disregard the response to #5 I was thinking about the algorithms draft. spt On 7/10/12 10:18 AM, Sean Turner wrote: > On 7/6/12 1:32 PM, Mike Jones wrote: >> Thanks for taking the time to provide the detailed feedback. Responses >> inline… >> >> -----Original Message----- >> From: jose-bounces@ietf.org >> [mailto:jose-bounces@ietf.org] >> On Behalf Of Sean Turner >> Sent: Monday, May 28, 2012 10:36 AM >> Cc: jose@ietf.org >> Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt >> >> Here's some comments (again I'll try not to duplicate Jim's): >> >> 1) s2 & Requirements Language: The RFC editor is going to move the >> Requirements Language section later on so you might as well save them >> the trouble and just make it part of s2. >> >> Done here, plus in JWE, JWS, JWA, JWT, JWE-JS, JWS-JS, and SWD > > Thanks. I know this seems silly, but it's nice to save them some time. > >> 2) s3: This is probably a style thing, but I think it's probably better >> to talk about the structure first and then provide an example. It's >> just going to make everybody ask you to define/explain x in that section. >> >> I tried to do this and couldn’t find a better location. The spec is so >> short, that you’re never more than a page from the example to the >> normative text anyway. :-) Besides, given that all the meaty parts (the >> actual algorithm specifications) have moved to the JWA spec, the >> descriptions would probably be pretty abstract without an example to >> root them in. Left as is, at least for now. > > ack > >> 3) s4: Totally agree with Jim's comment #4 on this section. Applies to >> >> s5 as well. >> >> Addressed, per Jim’s comments > > ack > >> 4) s4: Same concerns as for algorithms about the collision resistant >> namespace and how the registry is set up. >> >> Addressed, per Jim’s comments > > ack > >> 5) s4.2: Assume "both" should be defined here. >> >> At least for Elliptic Curve keys, I believe that there’s a potential >> vulnerability with using the same key for both signing and encryption. >> So I’m reluctant to define “both”. The simplest way to indicate both >> may be to omit the parameter. This could also be represented by >> repeating the key with “use”:”sig” and “use”:”enc” in the key set. What >> do others in the working group think about these possibilities? > > Okay so I think I was a little confused here. Implementations will know > the context of "alg" etc. based on which JW* they're in. Both really > wouldn't make sense in that case. But, that makes me think that the > registry needs to be clear about which JW* the algs apply to and that > means adding a new column/bullet in 6.1.1 and then filled out for all in > 6.1.2 for: > > Usage: > Indicate which JW* construct the algorithm applies to. For > example: JWS. > > I suspect there will be some people who will just look at the registry > and not at the tables in s4. > >> 6) s7: If the kid is not supposed to be generated in a way to make it >> unique it's worth pointing this out in s7. >> >> Done > > ack > >> spt >> >> _______________________________________________ >> >> jose mailing list >> >> jose@ietf.org >> >> https://www.ietf.org/mailman/listinfo/jose >> > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > From Michael.Jones@microsoft.com Tue Jul 10 11:33:48 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F3E21F8610 for ; Tue, 10 Jul 2012 11:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.792 X-Spam-Level: X-Spam-Status: No, score=-3.792 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dvs8arl8PivM for ; Tue, 10 Jul 2012 11:33:47 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 9749421F86D7 for ; Tue, 10 Jul 2012 11:33:47 -0700 (PDT) Received: from mail128-co1-R.bigfish.com (10.243.78.233) by CO1EHSOBE008.bigfish.com (10.243.66.71) with Microsoft SMTP Server id 14.1.225.23; Tue, 10 Jul 2012 18:31:55 +0000 Received: from mail128-co1 (localhost [127.0.0.1]) by mail128-co1-R.bigfish.com (Postfix) with ESMTP id BC07020459; Tue, 10 Jul 2012 18:31:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: VS-30(zzbb2dI98dI9371I148cI542M1432Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail128-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail128-co1 (localhost.localdomain [127.0.0.1]) by mail128-co1 (MessageSwitch) id 1341945113825026_31605; Tue, 10 Jul 2012 18:31:53 +0000 (UTC) Received: from CO1EHSMHS024.bigfish.com (unknown [10.243.78.225]) by mail128-co1.bigfish.com (Postfix) with ESMTP id C7513A80046; Tue, 10 Jul 2012 18:31:53 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS024.bigfish.com (10.243.66.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 10 Jul 2012 18:31:53 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.53]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0309.003; Tue, 10 Jul 2012 18:34:11 +0000 From: Mike Jones To: Sean Turner Thread-Topic: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt Thread-Index: Ac1bnUyad8s5BDFlSJ21HdU0De1eaQDCaS6AAAAj6QAACJTCwA== Date: Tue, 10 Jul 2012 18:34:10 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436657EE6E@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366579F40@TK5EX14MBXC283.redmond.corp.microsoft.com> <4FFC39D1.40802@ieca.com> <4FFC3AC2.1070403@ieca.com> In-Reply-To: <4FFC3AC2.1070403@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 18:33:49 -0000 See the "Algorithm Usage Location(s)" entries in the registry entries at ht= tp://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-03#section-6.1= .2 for the very thing you asked for in 5. :-) Best wishes, -- Mike -----Original Message----- From: Sean Turner [mailto:turners@ieca.com]=20 Sent: Tuesday, July 10, 2012 7:23 AM To: Mike Jones Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt Sorry about this but disregard the response to #5 I was thinking about the = algorithms draft. spt On 7/10/12 10:18 AM, Sean Turner wrote: > On 7/6/12 1:32 PM, Mike Jones wrote: >> Thanks for taking the time to provide the detailed feedback. =20 >> Responses inline... >> >> -----Original Message----- >> From: jose-bounces@ietf.org =20 >> [mailto:jose-bounces@ietf.org]=20 >> >> On Behalf Of Sean Turner >> Sent: Monday, May 28, 2012 10:36 AM >> Cc: jose@ietf.org >> Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt >> >> Here's some comments (again I'll try not to duplicate Jim's): >> >> 1) s2 & Requirements Language: The RFC editor is going to move the=20 >> Requirements Language section later on so you might as well save them=20 >> the trouble and just make it part of s2. >> >> Done here, plus in JWE, JWS, JWA, JWT, JWE-JS, JWS-JS, and SWD > > Thanks. I know this seems silly, but it's nice to save them some time. > >> 2) s3: This is probably a style thing, but I think it's probably=20 >> better to talk about the structure first and then provide an example. =20 >> It's just going to make everybody ask you to define/explain x in that se= ction. >> >> I tried to do this and couldn't find a better location. The spec is=20 >> so short, that you're never more than a page from the example to the=20 >> normative text anyway. :-) Besides, given that all the meaty parts=20 >> (the actual algorithm specifications) have moved to the JWA spec, the=20 >> descriptions would probably be pretty abstract without an example to=20 >> root them in. Left as is, at least for now. > > ack > >> 3) s4: Totally agree with Jim's comment #4 on this section. Applies=20 >> to >> >> s5 as well. >> >> Addressed, per Jim's comments > > ack > >> 4) s4: Same concerns as for algorithms about the collision resistant=20 >> namespace and how the registry is set up. >> >> Addressed, per Jim's comments > > ack > >> 5) s4.2: Assume "both" should be defined here. >> >> At least for Elliptic Curve keys, I believe that there's a potential=20 >> vulnerability with using the same key for both signing and encryption. >> So I'm reluctant to define "both". The simplest way to indicate both=20 >> may be to omit the parameter. This could also be represented by=20 >> repeating the key with "use":"sig" and "use":"enc" in the key set. =20 >> What do others in the working group think about these possibilities? > > Okay so I think I was a little confused here. Implementations will=20 > know the context of "alg" etc. based on which JW* they're in. Both=20 > really wouldn't make sense in that case. But, that makes me think=20 > that the registry needs to be clear about which JW* the algs apply to=20 > and that means adding a new column/bullet in 6.1.1 and then filled out=20 > for all in > 6.1.2 for: > > Usage: > Indicate which JW* construct the algorithm applies to. For > example: JWS. > > I suspect there will be some people who will just look at the registry=20 > and not at the tables in s4. > >> 6) s7: If the kid is not supposed to be generated in a way to make it=20 >> unique it's worth pointing this out in s7. >> >> Done > > ack > >> spt >> >> _______________________________________________ >> >> jose mailing list >> >> jose@ietf.org >> >> https://www.ietf.org/mailman/listinfo/jose >> > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > From Michael.Jones@microsoft.com Fri Jul 13 14:19:08 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7B211E80FD for ; Fri, 13 Jul 2012 14:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.286 X-Spam-Level: X-Spam-Status: No, score=-5.286 tagged_above=-999 required=5 tests=[AWL=1.312, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ih+SMiGU6gUW for ; Fri, 13 Jul 2012 14:19:03 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7C59B11E8097 for ; Fri, 13 Jul 2012 14:19:03 -0700 (PDT) Received: from mail83-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 13 Jul 2012 21:19:39 +0000 Received: from mail83-tx2 (localhost [127.0.0.1]) by mail83-tx2-R.bigfish.com (Postfix) with ESMTP id 717122400EC; Fri, 13 Jul 2012 21:19:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VS-27(zz9371Ic85fh148cI542Mzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail83-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail83-tx2 (localhost.localdomain [127.0.0.1]) by mail83-tx2 (MessageSwitch) id 134221437782573_20536; Fri, 13 Jul 2012 21:19:37 +0000 (UTC) Received: from TX2EHSMHS037.bigfish.com (unknown [10.9.14.254]) by mail83-tx2.bigfish.com (Postfix) with ESMTP id 1068F3A0047; Fri, 13 Jul 2012 21:19:37 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS037.bigfish.com (10.9.99.137) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 13 Jul 2012 21:19:36 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0298.005; Fri, 13 Jul 2012 21:19:34 +0000 From: Mike Jones To: Jim Schaad , 'Sean Turner' Thread-Topic: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt Thread-Index: Ac1bnUyad8s5BDFlSJ21HdU0De1eaQBv3bIAAPNaJzA= Date: Fri, 13 Jul 2012 21:19:34 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436672B78B@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366579F40@TK5EX14MBXC283.redmond.corp.microsoft.com> <001b01cd5d5c$e2c35940$a84a0bc0$@augustcellars.com> In-Reply-To: <001b01cd5d5c$e2c35940$a84a0bc0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436672B78BTK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 21:19:08 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436672B78BTK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Responses inline... From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Sunday, July 08, 2012 3:55 PM To: Mike Jones; 'Sean Turner' Cc: jose@ietf.org Subject: RE: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt Comments below From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Mike Jone= s Sent: Friday, July 06, 2012 10:33 AM To: Sean Turner Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt Thanks for taking the time to provide the detailed feedback. Responses inl= ine... -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Sean Turn= er Sent: Monday, May 28, 2012 10:36 AM Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt Here's some comments (again I'll try not to duplicate Jim's): 1) s2 & Requirements Language: The RFC editor is going to move the Requirem= ents Language section later on so you might as well save them the trouble a= nd just make it part of s2. Done here, plus in JWE, JWS, JWA, JWT, JWE-JS, JWS-JS, and SWD 2) s3: This is probably a style thing, but I think it's probably better to = talk about the structure first and then provide an example. It's just goin= g to make everybody ask you to define/explain x in that section. I tried to do this and couldn't find a better location. The spec is so sho= rt, that you're never more than a page from the example to the normative te= xt anyway. :-) Besides, given that all the meaty parts (the actual algorit= hm specifications) have moved to the JWA spec, the descriptions would proba= bly be pretty abstract without an example to root them in. Left as is, at = least for now. 3) s4: Totally agree with Jim's comment #4 on this section. Applies to s5 as well. Addressed, per Jim's comments 4) s4: Same concerns as for algorithms about the collision resistant namesp= ace and how the registry is set up. Addressed, per Jim's comments 5) s4.2: Assume "both" should be defined here. At least for Elliptic Curve keys, I believe that there's a potential vulner= ability with using the same key for both signing and encryption. So I'm re= luctant to define "both". The simplest way to indicate both may be to omit= the parameter. This could also be represented by repeating the key with "= use":"sig" and "use":"enc" in the key set. What do others in the working g= roup think about these possibilities? [JLS] If you are asking for input, why is not in the open issues section? I'll add this to the Open Issues section. 6) s7: If the kid is not supposed to be generated in a way to make it uniqu= e it's worth pointing this out in s7. Done [JLS] Please point me to the text that does this. I don't see it. http://tools.ietf.org/html/draft-ietf-jose-json-web-key-03#section-4.3 "Key ID values within a JWK Set need not be unique; for instance, in some c= ontexts different keys using the same Key ID value might be present, with t= he keys being disambiguated using other information, such as the "alg" or "= use" values." spt _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B16804296739436672B78BTK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Responses inline…= ;

 

From: Jim Scha= ad [mailto:ietf@augustcellars.com]
Sent: Sunday, July 08, 2012 3:55 PM
To: Mike Jones; 'Sean Turner'
Cc: jose@ietf.org
Subject: RE: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt<= o:p>

 

Comments below

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, July 06, 2012 10:33 AM
To: Sean Turner
Cc: jose@ietf.org
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt<= o:p>

 

Thanks for taking t= he time to provide the detailed feedback.  Responses inline…

 

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Sean Turner
Sent: Monday, May 28, 2012 10:36 AM
Cc: jose@ietf.org
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt

 

Here's some comments (again I'll try not to dupli= cate Jim's):

 

1) s2 & Requirements Language: The RFC editor= is going to move the Requirements Language section later on so you might a= s well save them the trouble and just make it part of s2.

 

Done here, plus in = JWE, JWS, JWA, JWT, JWE-JS, JWS-JS, and SWD

 

2) s3: This is probably a style thing, but I thin= k it's probably better to talk about the structure first and then provide a= n example.  It's just going to make everybody ask you to define/explai= n x in that section.

 

I tried to do this = and couldn’t find a better location.  The spec is so short, that= you’re never more than a page from the example to the normative text= anyway. :-)  Besides, given that all the meaty parts (the actual algorithm specifications) have moved to the JWA spec, the desc= riptions would probably be pretty abstract without an example to root them = in.  Left as is, at least for now.

 

3) s4: Totally agree with Jim's comment #4 on thi= s section.  Applies to

s5 as well.

 

Addressed, per Jim&= #8217;s comments

 

4) s4: Same concerns as for algorithms about the = collision resistant namespace and how the registry is set up.

 

Addressed, per Jim&= #8217;s comments

 

5) s4.2: Assume "both" should be define= d here.

 

At least for Ellipt= ic Curve keys, I believe that there’s a potential vulnerability with = using the same key for both signing and encryption.  So I’m relu= ctant to define “both”.  The simplest way to indicate both may be to omit the parameter.  This could also be represented by= repeating the key with “use”:”sig” and “use&= #8221;:”enc” in the key set.  What do others in the workin= g group think about these possibilities?

 

[JLS]  If you = are asking for input, why is not in the open issues section?

 

I’ll add this to= the Open Issues section.

 

6) s7: If the kid is not supposed to be generated= in a way to make it unique it's worth pointing this out in s7.<= /p>

 

Done

 

[JLS] Please point = me to the text that does this.  I don’t see it.

 

http://tools.ietf.org/html/draft-ietf-jose-json-web-key-03#= section-4.3

“Key ID values w= ithin a JWK Set need not be unique; for instance, in some contexts differen= t keys using the same Key ID value might be present, with the keys being disambiguated using other information, such a= s the "alg" or "use" values.”

 

spt

_______________________________________________

jose mailing list

jose@ietf.org

https://www.iet= f.org/mailman/listinfo/jose

 

--_000_4E1F6AAD24975D4BA5B16804296739436672B78BTK5EX14MBXC285r_-- From Michael.Jones@microsoft.com Fri Jul 13 14:19:45 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2123011E8116 for ; Fri, 13 Jul 2012 14:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.3 X-Spam-Level: X-Spam-Status: No, score=-5.3 tagged_above=-999 required=5 tests=[AWL=1.298, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id julu4ty467hv for ; Fri, 13 Jul 2012 14:19:33 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id BC4F011E8097 for ; Fri, 13 Jul 2012 14:19:32 -0700 (PDT) Received: from mail91-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE012.bigfish.com (10.9.40.32) with Microsoft SMTP Server id 14.1.225.23; Fri, 13 Jul 2012 21:20:09 +0000 Received: from mail91-tx2 (localhost [127.0.0.1]) by mail91-tx2-R.bigfish.com (Postfix) with ESMTP id 84C861A01CD; Fri, 13 Jul 2012 21:20:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz9371Ic85fh148cI542M1418Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail91-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail91-tx2 (localhost.localdomain [127.0.0.1]) by mail91-tx2 (MessageSwitch) id 1342214406724142_12316; Fri, 13 Jul 2012 21:20:06 +0000 (UTC) Received: from TX2EHSMHS042.bigfish.com (unknown [10.9.14.237]) by mail91-tx2.bigfish.com (Postfix) with ESMTP id AC29BC007F; Fri, 13 Jul 2012 21:20:06 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS042.bigfish.com (10.9.99.142) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 13 Jul 2012 21:20:06 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0298.005; Fri, 13 Jul 2012 21:19:53 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: Comments on draft-ietf-jose-json-web-key-02 Thread-Index: Ac1bnR9r6ocLDUY1SjuKsbPs53w7OABv8OOAAPOzazA= Date: Fri, 13 Jul 2012 21:19:52 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436672B792@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366579F15@TK5EX14MBXC283.redmond.corp.microsoft.com> <002301cd5d5c$e36edb80$aa4c9280$@augustcellars.com> In-Reply-To: <002301cd5d5c$e36edb80$aa4c9280$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436672B792TK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Comments on draft-ietf-jose-json-web-key-02 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 21:19:45 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436672B792TK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Responses inline... From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Sunday, July 08, 2012 3:56 PM To: Mike Jones Cc: jose@ietf.org Subject: RE: Comments on draft-ietf-jose-json-web-key-02 Comments on responses and some additional comments as well. If the security sections references the XML DSig document as having importa= nt security considerations, then it needs to be normative and not informati= ve. Will do Jim From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, July 06, 2012 10:31 AM To: Jim Schaad Cc: jose@ietf.org Subject: RE: Comments on draft-ietf-jose-json-web-key-02 Thanks for taking the time to provide the detailed feedback. Responses inl= ine... -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Saturday, May 19, 2012 3:34 PM To: Mike Jones Cc: jose@ietf.org Subject: Comments on draft-ietf-jose-json-web-key-02 My apologies for introducing you to the term algorithm families. We don't = use it in the same way and thus I think that you should generally remove it= from the text. To me it is a very wide term and somewhat nebulous. Thus = I think of all of the DH algorithms as being in a family - but that family = could also include the ECDH algorithm as well as DSA depending on how one i= s using it. Thus for me an algorithm family is not restricted to a specifi= c instance (or small set of instances) such a DH & DSA but could be as larg= e as all key agreement algorithms. As such it does not really match how you are using it in much of the text. Left in for the current draft for lack of a better term. I did remove as m= any uses of the term as possible. Slightly more detailed: You can define an RSA key You can define an RSA-OAEP key The second one has all of the fields of the first, however it may have addi= tional fields defined that deal specifically with RSA-OAEP. The difference= is going to be a question of restriction of usage of the key to a single a= lgorithm vs allowing for all RSA algorithms. Parameters could be defined in the JWA spec to specify parameters enabling = those possible restrictions if the working group deems it useful/necessary.= The JWK spec already makes it clear that algorithm-specific parameters ma= y be required, so this wouldn't change the model. Here are some more comments Abstract 1. I am not a fan of the word enumerated in the last sentence. This word = implies to me that the list is not expandable. I would recommend something= along the lines of "An initial set of ... can be found in ..." Done here, plus in JWE, JWS, JWA, JWE-JS, and JWS-JS [JLS] This change was not made in the JWA document. Correct, because you wrote "I do not have a problem with enumerate in this = document" in your May 21st message on JWA. I made a typo when I wrote that= I applied it to JWA above. (Also, I actually think that in JWA, the word = "enumerates" works well.) Section 2 1. The phrase "For the purpose of this document" should be removed unless = this term is used in other ways elsewhere. Not changed, because in some other contexts, the same term is used to refer= to the non URL safe encoding. [JLS] Is it used in a different way in this document? One can automatical= ly assumed that if you are defining a term, that it is for the purposes of = this document and, unless generally accepted, is not applicable to other do= cuments. Purely for curiosity, where is the phrase base64url encoding used to mean s= omething else in a different document? OK, I'll delete the phrase. The term "base64 encoding" often (usually) mea= ns something different, but not the term "base64url encoding". Section 4 1. In para #2 - the use of "algorithm family" is incorrect. They members = are going to be required for the specific key being represented not to the = family - consider the case of RSA and RSA-OAEP - these are both in the same= family, but the fields required are different. Reworded to not use the term "algorithm family" [JLS] Suggest "In addition to the common parameters, each JWK will have m= embers that are specific to the key being represented. These members repre= sent the parameters of the key. Section 5 of the JSON Web Algorithm (JWA)= specifies a number of public keys and their associated members." Good 2. Do you believe that all of the algorithm members are defined in the JWA document - or only for some algorithms. Text should probably say they are defined for the algorithms defined for the algorithms in JWA. Done 3. I don't believe that para #3 is enforceable by parsers as they have bee= n presented to me. Please prove me wrong. Section 2.2 of http://tools.ietf.org/html/rfc4627 says "The names within an= object SHOULD be unique." So this should be enforced by conforming parser= s. I'd be interested in data saying that parsers exist that are non-confor= ming to this RFC 4627 "SHOULD". If so, we should add appropriate warnings = to the Security Considerations section. [JLS] Stating that they should be unique is more of a requirement on the ge= neration side and not the parsing side of the specification. I do not beli= eve that this statement in way says that parsers should reject objects for = which duplicate member names exist. Parsers that accept input with duplicate member names are violating a SHOUL= D, as I see it. In any event, tightening this to "MUST be unique" is appro= priate in our specs, since I'll grant you that relying on a SHOULD is inapp= ropriate in a security context. If this requires secondary parsing or usin= g a hardened parser to ensure member uniqueness, that's part of the price o= f having a correct implementation. (And consider the alternative - we *rea= lly* don't want to go down the path of having to make statements like "If t= here are multiple "alg" values, then..."!) We started talking about these security considerations at http://tools.ietf= .org/html/draft-ietf-jose-json-web-signature-03#section-8.2. I'll tighten = this up. 4. Let's look at the sentence "If present, they MUST be understood by im= plementations using them." I believe that this is an incorrect assertion. (Not to mention that it is totally uncheckable.) Consider the following situation: Implementation A creates a JWK and files it with Implementation B. A does = not understand the "exist-date" property. Implementation B adds the "exist-date" property and puts it at a URL. Implementation C pulls the JWK from the URL, understand the "exist-date" property. According to the MUST, the JWK cannot be used as it is not understood by al= l of the implementations. The only entity that you can make the requirement on is the consumer. One = assumes that the "provider" would/might understand the field or it would no= t be there but it could have been added in transit and thus that is not the= case. I believe that for your example, the text is correct as written, since in c= ontext, "them" refers to the additional members, not the JWK as a whole. A= t no point in your example did an implementation use a JWK with an addition= al member that it did not understand. [JLS] This is precisely the statement that I made above, the mandating that= the field is understood by consumers of the JWK is possible, but it is not= possible to mandate that all implementations involved in the transaction u= nderstand all of the fields. Maybe we can talk about this in person in Vancouver, because I think I'm st= ill missing something in what you're trying to achieve here. In your examp= le, the JWK created by A and the JWK created by B by adding the "exist-date= " property to A are different JWKs, because they have different fields. At= no point did any party, producer or consumer, use a JWK whose fields it di= d not all understand. (I'll grant you that if A were to use B's JWK, the "= must understand" would be violated, but that's exactly the intent.) I understand that the assertion may not be enforceable apart from conforman= ce suites that check what implementations do when given new parameters, and= I understand that in the general case, programmatic enforcement would be t= he equivalent of solving the halting problem. That's not an argument, howe= ver, that in security contexts, that having this requirement isn't the righ= t thing to do. [JLS] I have not made an argument for removing it, but for stating that it = is the consumer on which the restriction is placed on not on all implementa= tions. You don't think that's equally important for producers to understand all th= e fields of the JWKs they're producing? 5. I find the last sentence of para #4 to be unreadable. I would start by= breaking it into two sentences and potentially move the first one into the= JWA document (that about parameters for keys). Simplified [JLS] I think it can be simplified even more. For one thing it is not cle= ar if the member name must be unique between kinds of keys. Thus can you h= ave a "x" for both DH and ECDH (or do they fall into the same family?). Agreed. I'll simplify this further to just say "Member names SHOULD ...". = I'll also add "Member names used for representing key parameters for diffe= rent kinds of keys need not be distinct", per your question about uniquenes= s. [JLS] Given that only fields dealing with either generic items or a specifi= c key are represented in a JWK object. It would make more sense to have th= e restriction on member names than on generic members and not on members th= at are specific to a public key. Agreed - I believe my wording above addresses this. Section 4.1 1. Do you want to point to the JWA document or to the registry for the set = of defined algorithms? Clarified that some names are defined in JWA whereas all names not containi= ng a collision resistant namespace should be registered. [JLS] OK - let me be more pointed in my comment. I think you should point = at the registry and not at the other document for the list of defined algor= ithms. Additionally, I think you should point at the registry for the set = of generic members defined and ignore the set of key specific members defin= ed in this document. OK, I'll reword this (and similar locations) to make the registry be the pr= imary reference and to add, on a secondary basis, that the JWA document pro= vides the initial contents for the registry. (I believe we continue to nee= d the JWA reference to help reviewers of the current specs, especially sinc= e the registry won't be created until the specs are approved as RFCs.) 2. In para #1 I would remove the sentence starting "Specific additional..." as this is not part of the definition of the "alg" parameter and is covered= in section 4.0 Done 3. The last two sentences in para #1 can be combined together. This is just a personal stylistic thing I suppose, but I prefer two short d= eclarative sentences to a conjunction of the two. [JLS] as oppose to "The "alg" value MUST be a case-sensitive string. OK, I agree that that wording's better. I'll make that change where applic= able. Section 4.2 1. Presentation suggestion - if you use a bulleted list for the values it = will be easier to see what the list of defined values is. Done 2. See point #3 in section 4.1 Ditto Section 4.3 1. Is there a requirement that the kid be unique in a JWK Set? I think th= at the answer should be called out in text either way. Good point. Added text saying that it need not be unique, and providing an= example providing rationale for that choice. [JLS] Ok - I see documentation on how to handle the situation if there are= multiple KIDs that have the same value, but I am missing the rationale tha= t you have stated as being present. A rationale would be WHY one would hav= e multiple keys with the same KID value. The rationale was in the "for instance" text. We could beef up the rationa= le if you have better suggested wording. As another example, imagine "kid" values like "Current", "Upcoming", and "D= eprecated", used for key rollover guidance. You could apply that label to = all keys where the classification fits. If there are multiple "Current" ke= ys, then in this example they might be differentiated either by having diff= erent "alg" or "use" values, or some combination of both. (There might onl= y be one current RSASA signing key and one current ECDSA signing key, but b= oth would be "Current".) 2. Is the string case sensitive? It is now. :-) 3. Move the sentence "When used..." to a new paragraph. (suggestion) Done Section 6.1 1. Please make things easy for IANA - create a table with the fields across= the top and the values down the table. This will allow them to do their j= ob without having to go through the entire document and for us to be able t= o easily validate that they got it correct. Done here, plus in JWA and JWT [JLS] Section 6.1.1 - Under the Parameter Name: field, you should have a no= te for IANA that the name is case-sensitive and have a comment that names t= hat match in a case-insensitive manner SHOULD or SHOULD NOT be accepted. (C= opy note to all of the reset of the tables as well). Will do (with SHOULD NOT) [JLS] Section 6.1.1 - are there any longevity requirements on the URI that = is specified? If we refer to an RFC then we know that it will "always" exi= st. This is not necessarily true if one refers to a document on a personal= website. Is there best-practice text on this issue that anyone is aware of that we c= an reuse? (The current text is reused from the OAuth Core spec, which has = already undergone IETF last call, and so seemed like a good place to start = from.) Section 6.2 1. Please put in a registration section for the items you are registering i= n Section 4 in the JWK table. You can refer to JWA for creation of the tab= le. Done here, plus in JWS, JWE, JWA, and JWT Appendix A 1. I am not sure why this appendix is in this document. To give credit to the inventors of the precursor spec that resulted in the = JWK spec. I've added their names to make this intent clearer. --_000_4E1F6AAD24975D4BA5B16804296739436672B792TK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Responses inline…= ;

 

From: Jim Scha= ad [mailto:ietf@augustcellars.com]
Sent: Sunday, July 08, 2012 3:56 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: RE: Comments on draft-ietf-jose-json-web-key-02<= /span>

 

Comments on responses = and some additional comments as well.

 

If the security sectio= ns references the XML DSig document as having important security considerat= ions, then it needs to be normative and not informative.<= /p>

 

Will do

 

Jim<= /p>

 

 

From: Mike Jon= es [mailto:Michael.Jon= es@microsoft.com]
Sent: Friday, July 06, 2012 10:31 AM
To: Jim Schaad
Cc: jose@ietf.org
Subject: RE: Comments on draft-ietf-jose-json-web-key-02<= /span>

 

Thanks for taking t= he time to provide the detailed feedback.  Responses inline…

 

-----Original Message-----
From: Jim Schaad [mailto= :ietf@augustcellars.com]
Sent: Saturday, May 19, 2012 3:34 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: Comments on draft-ietf-jose-json-web-key-02

 

<no hat>

 

My apologies for introducing you to the term algo= rithm families.  We don't use it in the same way and thus I think that= you should generally remove it from the text.  To me it is a very wid= e term and somewhat nebulous.  Thus I think of all of the DH algorithms as being in a family - but that family could a= lso include the ECDH algorithm as well as DSA depending on how one is using= it.  Thus for me an algorithm family is not restricted to a specific = instance (or small set of instances) such a DH & DSA but could be as large

as all key agreement algorithms.   As s= uch it does not really match how you

are using it in much of the text.

 

Left in for the cur= rent draft for lack of a better term.  I did remove as many uses of th= e term as possible.

 

Slightly more detailed:

 

You can define an RSA key

You can define an RSA-OAEP key

 

The second one has all of the fields of the first= , however it may have additional fields defined that deal specifically with= RSA-OAEP.  The difference is going to be a question of restriction of= usage of the key to a single algorithm vs allowing for all RSA algorithms.

 

Parameters could be= defined in the JWA spec to specify parameters enabling those possible rest= rictions if the working group deems it useful/necessary.  The JWK spec= already makes it clear that algorithm-specific parameters may be required, so this wouldn’t change the model.<= /o:p>

 

Here are some more comments

 

Abstract

 

1.  I am not a fan of the word enumerated in= the last sentence.  This word implies to me that the list is not expa= ndable.  I would recommend something along the lines of "An initi= al set of ... can be found in ..."

 

Done here, plus in = JWE, JWS, JWA, JWE-JS, and JWS-JS

 

[JLS] This change w= as not made in the JWA document.

 

Correct, because yo= u wrote “I do not have a problem with enumerate in this docume= nt” in your May 21st message= on JWA.  I made a typo when I wrote that I applied it to JWA above.  (Also, I actually think that in JWA, the word ̶= 0;enumerates” works well.)

 

Section 2

 

1.  The phrase "For the purpose of this= document" should be removed unless this term is used in other ways el= sewhere.

 

Not changed, becaus= e in some other contexts, the same term is used to refer to the non URL saf= e encoding.

 

[JLS] Is it used in= a different way in this document?   One can automatically assume= d that if you are defining a term, that it is for the purposes of this docu= ment and, unless generally accepted, is not applicable to other documents. 

 

Purely for curiosit= y, where is the phrase base64url encoding used to mean something else in a = different document?

 

OK, I’ll dele= te the phrase.  The term “base64 encoding” often (usually)= means something different, but not the term “base64url encoding̶= 1;.

 

Section 4

 

1.  In para #2 - the use of "algorithm = family" is incorrect.  They members are going to be required for = the specific key being represented not to the family - consider the case of= RSA and RSA-OAEP - these are both in the same family, but the fields required are different.

 

Reworded to not use= the term “algorithm family”

 

[JLS]   S= uggest “In addition to the common parameters, each JWK will have memb= ers that are specific to the key being represented.  These members rep= resent the parameters of the key.   Section 5 of the JSON Web Algorithm (JWA) specifies a number of public keys and their associated= members.”

 

Good

 

2.  Do you believe that all of the algorithm= members are defined in the JWA

document - or only for some algorithms. &nbs= p; Text should probably say they are

defined for the algorithms defined for the algori= thms in JWA.

 

Done

 

3.  I don't believe that para #3 is enforcea= ble by parsers as they have been presented to me.  Please prove me wro= ng.

 

Section 2.2 of http://tools.ietf.org/htm= l/rfc4627 says “The names within an object SHOULD be unique.”&nb= sp; So this should be enforced by conforming parsers.  I’d be in= terested in data saying that parsers exist that are non-conforming to this = RFC 4627 “SHOULD”.  If so, we should add appropriate warni= ngs to the Security Considerations section.

 

[JLS] Stating that = they should be unique is more of a requirement on the generation side and n= ot the parsing side of the specification.  I do not believe that this = statement in way says that parsers should reject objects for which duplicate member names exist.

 

Parsers that accept= input with duplicate member names are violating a SHOULD, as I see it.&nbs= p; In any event, tightening this to “MUST be unique” is appropr= iate in our specs, since I’ll grant you that relying on a SHOULD is inappropriate in a security context.  If this requires= secondary parsing or using a hardened parser to ensure member uniqueness, = that’s part of the price of having a correct implementation.  (A= nd consider the alternative – we *really* don’t want to go down the path of having to make statements like = 220;If there are multiple “alg” values, then…”!)

 

We started talking = about these security considerations at http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-03#section-8.= 2.  I’ll tighten this up.

 

4.  Let's look at the sentence  "I= f present, they MUST  be understood by implementations using them.&quo= t;  I believe that this is an incorrect assertion.

(Not to mention that it is totally uncheckable.)&= nbsp; Consider the following

situation:

 

Implementation A creates a JWK and files it with = Implementation B.  A does not understand the "exist-date" pr= operty.

Implementation B adds the "exist-date" = property and puts it at a URL.

Implementation C pulls the JWK from the URL, unde= rstand the "exist-date"

property.

According to the MUST, the JWK cannot be used as = it is not understood by all of the implementations.

 

The only entity that you can make the requirement= on is the consumer.  One assumes that the "provider" would/= might understand the field or it would not be there but it could have been = added in transit and thus that is not the case.

 

I believe that for = your example, the text is correct as written, since in context, “them= ” refers to the additional members, not the JWK as a whole.  At = no point in your example did an implementation use a JWK with an additional member that it did not understand.

 

[JLS] This is preci= sely the statement that I made above, the mandating that the field is under= stood by consumers of the JWK is possible, but it is not possible to mandat= e that all implementations involved in the transaction understand all of the fields.

 

Maybe we can talk a= bout this in person in Vancouver, because I think I’m still missing s= omething in what you’re trying to achieve here.  In your example= , the JWK created by A and the JWK created by B by adding the “exist-date” property to A are different JWKs, because the= y have different fields.  At no point did any party, producer or consu= mer, use a JWK whose fields it did not all understand.  (I’ll gr= ant you that if A were to use B’s JWK, the “must understandR= 21; would be violated, but that’s exactly the intent.)=

 

I understand that t= he assertion may not be enforceable apart from conformance suites that chec= k what implementations do when given new parameters, and I understand that = in the general case, programmatic enforcement would be the equivalent of solving the halting problem.  That’s= not an argument, however, that in security contexts, that having this requ= irement isn’t the right thing to do.

 

[JLS] I have not ma= de an argument for removing it, but for stating that it is the consumer on = which the restriction is placed on not on all implementations.

 

You don’t thi= nk that’s equally important for producers to understand all the field= s of the JWKs they’re producing?

 

5.  I find the last sentence of para #4 to b= e unreadable.  I would start by breaking it into two sentences and pot= entially move the first one into the JWA document (that about parameters fo= r keys).

 

Simplified

 

[JLS]  I think= it can be simplified even more.  For one thing it is not clear if the= member name must be unique between kinds of keys.  Thus can you have = a “x” for both DH and ECDH (or do they fall into the same family?).

 

Agreed.  IR= 17;ll simplify this further to just say “Member names SHOULD …&= #8221;.  I’ll also add “Member names used for representing= key parameters for different kinds of keys need not be distinct”, pe= r your question about uniqueness.

 

[JLS] Given that on= ly fields dealing with either generic items or a specific key are represent= ed in a JWK object.  It would make more sense to have the restriction = on member names than on generic members and not on members that are specific to a public key.

 

Agreed – I be= lieve my wording above addresses this.

 

Section 4.1

 

1. Do you want to point to the JWA document or to= the registry for the set of defined algorithms?

 

Clarified that some= names are defined in JWA whereas all names not containing a collision resi= stant namespace should be registered.

 

[JLS] OK – le= t me be more pointed in my comment.  I think you should point at the r= egistry and not at the other document for the list of defined algorithms.&n= bsp; Additionally, I think you should point at the registry for the set of generic members defined and ignore the set of key specific = members defined in this document.

 

OK, I’ll rewo= rd this (and similar locations) to make the registry be the primary referen= ce and to add, on a secondary basis, that the JWA document provides the ini= tial contents for the registry.  (I believe we continue to need the JWA reference to help reviewers of the current spe= cs, especially since the registry won’t be created until the specs ar= e approved as RFCs.)

 

2. In para #1 I would remove the sentence startin= g "Specific additional..."

as this is not part of the definition of the &quo= t;alg" parameter and is covered in section 4.0

 

Done

 

3.  The last two sentences in para #1 can be= combined together.

 

This is just a pers= onal stylistic thing I suppose, but I prefer two short declarative sentence= s to a conjunction of the two.

 

[JLS] as oppose to = “The “alg” value MUST be a case-sensitive string.<= span style=3D"color:#1F497D">

 

OK, I agree that th= at wording’s better.  I’ll make that change where applicab= le.

 

Section 4.2

 

1.  Presentation suggestion - if you use a b= ulleted list for the values it will be easier to see what the list of defin= ed values is.

 

Done

 

2.  See point #3 in section 4.1

 

Ditto

 

Section 4.3

 

1.  Is there a requirement that the kid be u= nique in a JWK Set?  I think that the answer should be called out in t= ext either way.

 

Good point.  A= dded text saying that it need not be unique, and providing an example provi= ding rationale for that choice.

 

[JLS]  Ok R= 11; I see documentation on how to handle the situation if there are multipl= e KIDs that have the same value, but I am missing the rationale that you ha= ve stated as being present.  A rationale would be WHY one would have multiple keys with the same KID value.

 

The rationale was i= n the “for instance” text.  We could beef up the rationale= if you have better suggested wording.

 

As another example,= imagine “kid” values like “Current”, “Upcomi= ng”, and “Deprecated”, used for key rollover guidance.&nb= sp; You could apply that label to all keys where the classification fits.&n= bsp; If there are multiple “Current” keys, then in this example they might be differentia= ted either by having different “alg” or “use” value= s, or some combination of both.  (There might only be one current RSAS= A signing key and one current ECDSA signing key, but both would be “C= urrent”.)

 

2.  Is the string case sensitive?=

 

It is now. :-)=

 

3.  Move the sentence "When used...&quo= t; to a new paragraph.  (suggestion)

 

Done

 

Section 6.1

 

1. Please make things easy for IANA - create a ta= ble with the fields across the top and the values down the table.  Thi= s will allow them to do their job without having to go through the entire d= ocument and for us to be able to easily validate that they got it correct.

 

Done here, plus in = JWA and JWT

 

[JLS] Section 6.1.1= – Under the Parameter Name: field, you should have a note for IANA t= hat the name is case-sensitive and have a comment that names that match in = a case-insensitive manner SHOULD or SHOULD NOT be accepted. (Copy note to all of the reset of the tables as well).

 

Will do (with SHOUL= D NOT)

 

[JLS] Section 6.1.1= – are there any longevity requirements on the URI that is specified?=  If we refer to an RFC then we know that it will “always”= exist.  This is not necessarily true if one refers to a document on a personal website.

 

Is there best-pract= ice text on this issue that anyone is aware of that we can reuse?  (Th= e current text is reused from the OAuth Core spec, which has already underg= one IETF last call, and so seemed like a good place to start from.)

 

Section 6.2

 

1. Please put in a registration section for the i= tems you are registering in Section 4 in the JWK table.  You can refer= to JWA for creation of the table.

 

Done here, plus in = JWS, JWE, JWA, and JWT

 

Appendix A

 

1.  I am not sure why this appendix is in th= is document.

 

To give credit to t= he inventors of the precursor spec that resulted in the JWK spec.  I&#= 8217;ve added their names to make this intent clearer.

 

--_000_4E1F6AAD24975D4BA5B16804296739436672B792TK5EX14MBXC285r_-- From Michael.Jones@microsoft.com Fri Jul 13 14:20:36 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE98F11E80FF for ; Fri, 13 Jul 2012 14:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.814 X-Spam-Level: X-Spam-Status: No, score=-3.814 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kHmIvc3sU2n for ; Fri, 13 Jul 2012 14:20:24 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id 7660D11E8097 for ; Fri, 13 Jul 2012 14:20:23 -0700 (PDT) Received: from mail58-db3-R.bigfish.com (10.3.81.250) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.23; Fri, 13 Jul 2012 21:21:00 +0000 Received: from mail58-db3 (localhost [127.0.0.1]) by mail58-db3-R.bigfish.com (Postfix) with ESMTP id 0C7B012063C; Fri, 13 Jul 2012 21:21:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -33 X-BigFish: VS-33(zz9371I936eIc85fh1454I168aJ148cI542M1418I1447Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail58-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail58-db3 (localhost.localdomain [127.0.0.1]) by mail58-db3 (MessageSwitch) id 1342214456444306_22150; Fri, 13 Jul 2012 21:20:56 +0000 (UTC) Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.249]) by mail58-db3.bigfish.com (Postfix) with ESMTP id 608F81E0044; Fri, 13 Jul 2012 21:20:56 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 13 Jul 2012 21:20:55 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0309.003; Fri, 13 Jul 2012 21:20:46 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: Comments on draft-ietf-jose-json-web-algorithms-02 Thread-Index: Ac1bnm0yDdR4osWGShO4zuEBHYQsVAB84WuAAOhbxxA= Date: Fri, 13 Jul 2012 21:20:46 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436672B7CD@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366579FC3@TK5EX14MBXC283.redmond.corp.microsoft.com> <008701cd5d91$f3cbe740$db63b5c0$@augustcellars.com> In-Reply-To: <008701cd5d91$f3cbe740$db63b5c0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436672B7CDTK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 21:20:36 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436672B7CDTK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Responses inline... From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Sunday, July 08, 2012 10:16 PM To: Mike Jones Cc: jose@ietf.org Subject: RE: Comments on draft-ietf-jose-json-web-algorithms-02 Responses to previous comments and some new comments. Open issue feedback - Do AES ECB - no From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, July 06, 2012 10:41 AM To: 'Jim Schaad' Cc: jose@ietf.org Subject: RE: Comments on draft-ietf-jose-json-web-algorithms-02 Thanks for taking the time to provide the detailed feedback. Responses inl= ine... -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, May 21, 2012 3:46 PM To: Mike Jones Cc: jose@ietf.org Subject: Comments on draft-ietf-jose-json-web-algorithms-02 Here are comments this document Abstract 1. Since I called it out for JWK I will make the comment that I do not hav= e a problem with enumerate in this document. Noted [JLS] On the other had since you said it was addressed in the mail for the = JWK document and it is not changed I do have a problem there. Saying in the JWK feedback that it was addressed in JWA was a typo in my e-= mail on my part. I intentionally did not change away from the word "enumer= ates" in JWA both since you said that you *didn't* have a problem with it, = and because I believe it accurately conveys what the JWA document does. Bu= t I'd be open to an alternative description if you'd like to supply wording= that's even clearer. Section 1 1. Just a comment - I am not sure why you feel the name to create a specif= ic acronym for this document but it does not really matter. It provides a shorthand name to refer to this document from others. 2. Need to expand JSON if you are going to use it. Not done here, because the word "JSON" here is used as part of a name, rath= er than as a reference to a specification or kind of data structure. I did= expand it the first time it is used to refer to the RFC 4627 data structur= es, in all the documents. [JLS] The rules state that it is to be expanded on the first use. If it i= s not done on the first use then the RFC editor will do so. It should be o= k in the key document since it is done almost immediately after the first u= se. As it currently stands it does not follow this rule. How would adding a sentence like this work for you? "All these specifications utilize JavaScript Object Notation (JSON) [RFC462= 7] based data structures." 3. New paragraph for sentence starting with "Enumerating..." Separate jus= tification from what this document does and hash. Done 4. Move last sentence to the end of the first paragraph Done Section 2 1. In general I would like to see this duplicated into this document. Readers should not have to reference another document for this purpose. Done [JLS] However only the relevant terms should be included. If JWE Ciphertex= t is never used then it does not need to be included at this point. Agreed. I already did a pass and removed unused terms. In the example of = JWE Ciphertext, this term is used in the definition of JWE Header, which is= used in the body of the specification, and so is necessary. If you find s= ome that are not used directly or indirectly, please point them out, and I'= ll remove them. Section 3.1 1. I am not overly happy with the existence of a "none" algorithm. Does i= t really need to exist? Yes. It is already widely used in contexts where content can be either sig= ned or plaintext. And while it used to be defined in JWT, you'd earlier su= ggested that it be moved here, since it is of broader applicability than ju= st JWTs. [JLS] I don't disagree with it being here rather than in the JWT document. = However there is a question if it would be better represented as having an= absent alg parameter rather than having a "none" algorithm. It would acco= mplish the same thing and be less suggested if an actual signature/MAC algo= rithm existing on the document. The due diligence that users of "alg":"none" have to perform is actually n= o less than the due diligence that they have to apply when using any other = "alg" value. At some future time, for instance, if HMAC SHA-256 is broken,= then using "HS256" would be arguably be worse than using "none", because "= HS256" might provide the illusion of security, where in fact, there would b= e none - sort of like if someone were to propose to use "HMD5" now. That t= here's no security is at least apparent with "none". :) Algorithms must always be used that are security-appropriate given the need= s of the application in the particular context and the current state of cry= ptography/cryptanalysis. Having a "none" algorithm doesn't change that. Section 3.2 1. You may want to reference RFC4231 as well. It contains test vectors an= d such for the SHA2 HMACs If this spec were about implementing the SHA2 HMAC algorithms, I would agre= e, but since it's only about using them, I don't think this reference is ne= cessary. Feel free to push back on this, however... 3. I have not yet read the updated JWS document, but I do worry about the = fact that this document is saying that the output should be base64url encod= ed. If the JWS document says the same thing injudiciously then one could e= asily see that people might double encode the result. I don't think there's a problem, as both documents make a clear distinction= between the "JWS Signature" value and the "Encoded JWS Signature" value, a= nd are careful to use the right term in the right place. (But obviously se= nd me corrections if you find a place where the wrong term is used.) 4. I have a real problem with people saying that UTF-8 and ASCII are the s= ame. They aren't and saying that they are does not make it so. They actually are the same in this case, since the JWS Secured Input consis= ts of only 7-bit ASCII characters (since they contain only base64url encode= d content and periods characters) that are represented the same in both enc= odings. But I agree that the previous text was potentially confusing and o= verly verbose. The text now only uses the phrase "the ASCII representation= of the JWS Secured Input", both here, and in the JWS spec. [JLS] Do you know this to be a true statement for all future encodings of J= WS values as oppose to the current one that is defined in JWS. For example= , in the documents proposed by myself and Richard this is not a true statem= ent. Instead the header is UTF8 encoded and that value is processed withou= t having done the ASCII encoding from base64url. It's true of all of the JOSE working group documents. If the working decid= es to change this, at that point we would, of course, make an appropriate c= ompanion change to these statements. 5. I find it confusing to constantly refer to the JWS specification throug= hout this text. For one thing it makes it harder to refer to these documen= ts for other uses in JSON of these algorithms (such as for an encrypt and M= AC algorithm). These defined terms have now been incorporated into this document, per your= comment on Section 2, so there should be no longer any need to refer to th= e JWS spec to understand this section. [JLS] That does not address my concern. If you do a combo HMAC and encrypt= algorithm are you going to suddenly turn the header and content into a JWS= Secured Input? (And do they suddenly become US ASCII strings?) Actually, I suspect that the JWS Secured Input would be the concatenation o= f the header, encrypted key, and ciphertext, just as is done now, assuming = that a JWS-based computation is done within the composite algorithm to comp= ute the JWE Integrity Value. There's actually nothing about the JWS comput= ation that requires that the secured value is ASCII; by the point the HMAC = computation is done, the secured input is a byte array. (The text about "b= ytes of the ASCII representation of..." is about how to create the byte val= ues for that array, given the particular choices in the current specificati= ons.) Is there are particular wording change that you'd suggest that doesn't chan= ge the semantics of the specifications, but would be easier for developers = to understand? Section 3.4 4. I have never see the R,S pair be referred to as a point before. I beli= eve it is just an ordered pair of integers and not a point on the field. The "point" terminology is used by XML DSIG 2.0, at least about the (x, y) = pair. See http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124/#sec-ECKeyVa= lue. I could be wrong that (R, S) are also a point, but given that the P-5= 21 signature is a pair of 521-bit integers, it sure seems like it is. Any = ECDSA experts care to weigh in? [JLS] A fast review of the algorithm on Wikipedia confirms what I was think= ing. The value of R is obtained from a point on the field (using just k) = and the value S is then computed from the value of x and the hash value. T= his means that (r,s) is not a point on the field. OK, I'll reword. Thanks for the research. Section 3.6 1. I don't see the purpose of the last paragraph in this section. It has = nothing to do with algorithms. This subsection is not only about algorithms - it's about extensions to JWS= , the parameters registry for which is also in the JWA spec because it's sh= ared between JWS and JWE. The first and second paragraphs of this subsecti= on is about extensions via algorithms and has a reference to that JWA regis= try. The third paragraph is about extensions via parameters, and has a ref= erence to that JWA registry. Not that 3.6 is parallel to 4.11 which has th= e same content for JWEs. All that being said, I'd be open to a different editorial structuring, if s= omeone wants to make an alternative proposal. Section 4.5 1. RSA-OAEP is under specified. There are a number of parameters for OAEP= that must be defined to go with it. These include the mask function and a= hash function. Look at RFC 3447 for the details. This is now fully specified. The description now reads: RSA using Optimal= Asymmetric Encryption Padding (OAEP), as defined in RFC 3447, with the def= ault parameters specified by RFC 3447 in Section A.2.1 [JLS] It is strongly recommended that the hash function for OAEP and the ha= sh function for the content be the same values. Additionally, why would we= recommend using SHA1 for any of these parameters given that it is not reco= mmended for any other purpose? This has to do with the working group's goal of having developers actually = be able to deploy the resulting specification. Using the .NET Framework as= an example (because it's one that I'm familiar with), the RSA encryption c= hoices available are PKCS 1-1.5 and OAEP with the default parameters. A .N= ET JWE implementation would be extremely difficult if we stray from what's = actually deployed. If you look at PHP, Ruby, Python, OpenSSL, MacOS, Android, iOS, Windows Pho= ne, etc. as actually deployed, you'll find similar limitations. (In fact, = you will not find OAEP support at all on some of these developer platforms.= ) We could delete OAEP entirely on that basis if the working group chooses, o= r make it DEPRECATED, rather than OPTIONAL, but I don't believe that defini= ng variants using non-default parameters would be useful, given that they c= ouldn't be used on most development platforms. On a related note, some colleagues and I have started to gather data on wha= t JWA algorithms are implemented on what development platforms. I'll send = a separate note shortly requesting presentation time during the meeting to = discuss and help refine the data that we've gathered. Section 4.6 2. I strongly disagree with setting OtherInfo parameters to be empty. We need to define and fill in the AlgorithmId at a minimum. Note that this ca= n be an implicit computation and does not need to be carried as extra data. At a minimum I would suggest something along the lines of JOSE-### where ##= # is the number of bits to get generated. Per my response to Sean's related comment, it's not clear to me what additi= onal value these parameters add in our usage of the algorithm. If we belie= ve that the content master key is undeterminable by an attacker (a requirem= ent for any security at all!) then adding a constant AlgorithmID to the com= putation I don't believe changes the security properties. (That being said= , we *could* use the "alg" value "ECDH-ES" as the AlgorithmID if people fel= t better about doing this.) Also given that the text now says (per your previous comment) that "A new e= pk (ephemeral public key) value MUST be generated for each key agreement tr= ansaction", it's not clear that adding parameters identifying the participa= ting parties adds any security value either. That being said, I'd be glad = to learn why I'm wrong. If there are good security reasons for requiring PartyUInfo and PartyVInfo = values, do you have suggestions on how to create acceptable values without = carrying more parameters in the header? (I've already suggested that we co= uld use the "alg" value "ECDH-ES" as the AlgorithmID, which wouldn't requir= e more parameters.) For instance, I don't want to blindly follow XML ENC's lead and punt the is= sue by requiring that conforming uses provide explicit PartyUInfo and Party= VInfo values. Finally, I'll note that the KDF function used by TLS http://tools.ietf.org/= html/rfc5246#section-5 uses no party parameters. Why do we need them then? [JLS] The object of having the algorithm identifier be present is to make s= ure that if you are doing two kdfs from the same key pairs for different pu= rposes that they will never end up generating the same key values (or a pre= fix of the same key values). While it is not immediate obvious that this = is going to be possible with the JOSE documents, it is a known security iss= ue and one that is easily addressed. One way would be as I suggested above= and used a string with the number of bits. Another way would be to use th= e algorithm that the key is going to be used for (which is how it is define= d). Thus this should be the ACUTAL content encryption algorithm used (i.e.= AES128GW or AES128CBC+HS256). I suspect that using the concatenation of the "enc" and "int" values as the= AlgorithmID, as you suggest above, is the right solution when doing Key De= rivation. This is already on the Open Issues list to discuss on the mailin= g list and in Vancouver. At this point I now would say that the KDF MUST have the ability to have a = PartyUInfo value specified. When the KDF was implicit in the key agreement= algorithm tag it did not matter. At that point if someone defined a new s= tatic-static version of ECDH then they would be required to define what KDF= function was to be used and could then require that the PartyUInfo field b= e defined in the KDF function that required. As it stands now, the KDF is = no longer tied to the key agreement algorithm and must therefore meet the n= ecessary security requirements for a static-static version of DH as well as= the ephemeral static versions. (On the other hand it still may be implici= t, but this was not completely obvious as there is a kdf function that woul= d be used in some cases leading to a confusion about what the kdf function = was actually being used for.) Key Agreement and Key Derivation are different cases. In the case of Key A= greement, the KDF *is* tightly bound to the algorithm definition. See the = definition of "ECDH-ES" in http://tools.ietf.org/html/draft-ietf-jose-json-= web-algorithms-03#section-4.1. Note also that use of a unique random ephem= eral public key is required, so unless your keygen algorithm is broken, the= re's no chance of generating the same derived keys. I believe it's already clear in http://tools.ietf.org/html/draft-ietf-jose-= json-web-encryption-03#section-4.1.4 that the "kdf" member is used in the K= ey Derivation case - not the Key Agreement case. But we can tighten this l= anguage further, if you'd like to suggest better wording. For TLS, both the PartyUInfo and the PartyVInfo values are present and used= when computing the key from the master secret. Since they are present at = that point they do not need to be present when computing the master secret = itself. When using TLS to compute other secrets - such as a TLS Unque val= ue, the equivalent of the algorithm ID is used at that point to make sure t= hat all such keys computed are going to be unique to that purpose. I believe you're discussing the Key Derivation case in the above paragraph.= Again, I think that using the concatenation of the "enc" and "int" values= as the AlgorithmID may be the right outcome for Key Derivation. But just = as in the Key Agreement case, given that a unique random CMK value MUST be = used, there's no chance of generating the same derived keys for other parti= es, unless the keygen algorithm generates duplicate keys (in which case you= have bigger problems). That being said, if there's a way of utilizing PartyUInfo and PartyVInfo va= lues in the KDF computation that doesn't involve carrying them as additiona= l header parameter values, I'd certainly personally be open to that as well= . Section 4.11 1. for last paragraph see comment on 3.6 Same response as for 3.6 Section 6.1 1. I would move this registry to either the signature or encryption docume= nts and not put it here. What does this document populate it with? Done Section 6.2 1. Make life easy for IANA and me - create a table of the values Done both here and in the other documents [JLS] What is the purpose of putting the Implementation Requirements into t= he table? Different applications may have different requirements and these= requirements may change over time. It does not make sense to require the = table to be updated every time the set of requirements change. The only ex= ception to that might be an obsoleted or do not use field, but even that ca= n be somewhat iffy. Sean Turner had suggested this. Apparently it is done in other specificati= ons and registries. (Examples, Sean?) It's certainly easier for implement= ers to understand, because they'll always be able to count on the registry'= s implementation status to be up to date. This can change, for instance, a= s algorithms move from OPTIONAL to RECOMMENDED to REQUIRED, or when they mo= ve from any of those states to DEPRECATED. Section 6.3 1. This registry should be in either the encryption or signature draft Done - now in JWS Section 6.4 1. This registry should be in the JWK document Done Section 6.5 1. Make life easy for IANA and me - create a table of the values Done both here and in the other documents --_000_4E1F6AAD24975D4BA5B16804296739436672B7CDTK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Responses inline…= ;

 

From: Jim Scha= ad [mailto:ietf@augustcellars.com]
Sent: Sunday, July 08, 2012 10:16 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: RE: Comments on draft-ietf-jose-json-web-algorithms-02=

 

Responses to previous = comments and some new comments.

 

 

Open issue feedback &#= 8211; Do AES ECB – no

 

 

From: Mike Jon= es [mailto:Michael.Jon= es@microsoft.com]
Sent: Friday, July 06, 2012 10:41 AM
To: 'Jim Schaad'
Cc: jose@ietf.org
Subject: RE: Comments on draft-ietf-jose-json-web-algorithms-02=

 

Thanks for taking t= he time to provide the detailed feedback.  Responses inline…

 

-----Original Message-----
From: Jim Schaad [mailto= :ietf@augustcellars.com]
Sent: Monday, May 21, 2012 3:46 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: Comments on draft-ietf-jose-json-web-algorithms-02

 

Here are comments this document

 

Abstract

 

1.  Since I called it out for JWK I will mak= e the comment that I do not have a problem with enumerate in this document.=

 

Noted

 

[JLS] On the other = had since you said it was addressed in the mail for the JWK document and it= is not changed I do have a problem there.

 

Saying in the JWK f= eedback that it was addressed in JWA was a typo in my e-mail on my part.&nb= sp; I intentionally did not change away from the word “enumeratesR= 21; in JWA both since you said that you *didn’t* have a problem with it, and because I believe it accurately conveys what the JW= A document does.  But I’d be open to an alternative description = if you’d like to supply wording that’s even clearer.=

 

Section 1

 

1.  Just a comment - I am not sure why you f= eel the name to create a specific acronym for this document but it does not= really matter.

 

It provides a short= hand name to refer to this document from others.

 

2.  Need to expand JSON if you are going to = use it.

 

Not done here, beca= use the word “JSON” here is used as part of a name, rather than= as a reference to a specification or kind of data structure.  I did e= xpand it the first time it is used to refer to the RFC 4627 data structures, in all the documents.

 

[JLS]  The rul= es state that it is to be expanded on the first use.  If it is not don= e on the first use then the RFC editor will do so.  It should be ok in= the key document since it is done almost immediately after the first use.  As it currently stands it does not follow this = rule.

 

How would adding a = sentence like this work for you?

“All these sp= ecifications utilize JavaScript Object Notation (JSON) [RFC4627] based data= structures.”

 

3.  New paragraph for sentence starting with= "Enumerating..."  Separate justification from what this doc= ument does and hash.

 

Done

 

4.  Move last sentence to the end of the fir= st paragraph

 

Done

 

Section 2

 

1.  In general I would like to see this dupl= icated into this document.

Readers should not have to reference another docu= ment for this purpose.

 

Done

 

[JLS] However only = the relevant terms should be included.  If JWE Ciphertext is never use= d then it does not need to be included at this point.

 

Agreed.  I alr= eady did a pass and removed unused terms.  In the example of JWE Ciphe= rtext, this term is used in the definition of JWE Header, which is used in = the body of the specification, and so is necessary.  If you find some that are not used directly or indirectly, please point th= em out, and I’ll remove them.

 

Section 3.1

 

1.  I am not overly happy with the existence= of a "none" algorithm.  Does it really need to exist?<= /o:p>

 

Yes.  It is al= ready widely used in contexts where content can be either signed or plainte= xt.  And while it used to be defined in JWT, you’d earlier sugge= sted that it be moved here, since it is of broader applicability than just JWTs.

 

[JLS] I don’t= disagree with it being here rather than in the JWT document.  However= there is a question if it would be better represented as having an absent = alg parameter rather than having a “none” algorithm.  It would accomplish the same thing and be less suggested if an actual sign= ature/MAC algorithm existing on the document.

 

The due diligence t= hat users of  “alg”:“none” have to perform is = actually no less than the due diligence that they have to apply when using = any other “alg” value.  At some future time, for instance,= if HMAC SHA-256 is broken, then using “HS256” would be arguably be wor= se than using “none”, because “HS256” might provide= the illusion of security, where in fact, there would be none – sort = of like if someone were to propose to use “HMD5” now.  Tha= t there’s no security is at least apparent with “none”. J<= /o:p>

 

Algorithms must alw= ays be used that are security-appropriate given the needs of the applicatio= n in the particular context and the current state of cryptography/cryptanal= ysis.  Having a “none” algorithm doesn’t change that.

 

Section 3.2

 

1.  You may want to reference RFC4231 as wel= l.  It contains test vectors and such for the SHA2 HMACs

 

If this spec were a= bout implementing the SHA2 HMAC algorithms, I would agree, but since itR= 17;s only about using them, I don’t think this reference is necessary= .  Feel free to push back on this, however…

 

3.  I have not yet read the updated JWS docu= ment, but I do worry about the fact that this document is saying that the o= utput should be base64url encoded.  If the JWS document says the same = thing injudiciously then one could easily see that people might double encode the result.

 

I don’t think= there’s a problem, as both documents make a clear distinction betwee= n the “JWS Signature” value and the “Encoded JWS Signatur= e” value, and are careful to use the right term in the right place.&n= bsp; (But obviously send me corrections if you find a place where the wrong ter= m is used.)

 

4.  I have a real problem with people saying= that UTF-8 and ASCII are the same.  They aren't and saying that they = are does not make it so.

 

They actually are t= he same in this case, since the JWS Secured Input consists of only 7-bit AS= CII characters (since they contain only base64url encoded content and perio= ds characters) that are represented the same in both encodings.  But I agree that the previous text was p= otentially confusing and overly verbose.  The text now only uses the p= hrase “the ASCII representation of the JWS Secured Input”, both= here, and in the JWS spec.

 

[JLS] Do you know t= his to be a true statement for all future encodings of JWS values as oppose= to the current one that is defined in JWS.  For example, in the docum= ents proposed by myself and Richard this is not a true statement.  Instead the header is UTF8 encoded and that= value is processed without having done the ASCII encoding from base64url.<= o:p>

 

It’s true of = all of the JOSE working group documents.  If the working decides to ch= ange this, at that point we would, of course, make an appropriate companion= change to these statements.

 

5.  I find it confusing to constantly refer = to the JWS specification throughout this text.  For one thing it makes= it harder to refer to these documents for other uses in JSON of these algo= rithms (such as for an encrypt and MAC algorithm).

 

These defined terms= have now been incorporated into this document, per your comment on Section= 2, so there should be no longer any need to refer to the JWS spec to under= stand this section.

 

[JLS] That does not= address my concern.  If you do a combo HMAC and encrypt algorithm are= you going to suddenly turn the header and content into a JWS Secured Input= ? (And do they suddenly become US ASCII strings?)

 

Actually, I suspect= that the JWS Secured Input would be the concatenation of the header, encry= pted key, and ciphertext, just as is done now, assuming that a JWS-based co= mputation is done within the composite algorithm to compute the JWE Integrity Value.  There’s actually= nothing about the JWS computation that requires that the secured value is = ASCII; by the point the HMAC computation is done, the secured input is a by= te array.  (The text about “bytes of the ASCII representation of…” is about how to create the byte values for= that array, given the particular choices in the current specifications.)

 

Is there are partic= ular wording change that you’d suggest that doesn’t change the = semantics of the specifications, but would be easier for developers to unde= rstand?

 

Section 3.4

 

4.  I have never see the R,S pair be referre= d to as a point before.  I believe it is just an ordered pair of integ= ers and not a point on the field.

 

The “point= 221; terminology is used by XML DSIG 2.0, at least about the (x, y) pair.&n= bsp; See http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124/#sec-ECKeyV= alue.  I could be wrong that (R, S) = are also a point, but given that the P-521 signature is a pair of 521-bit integers, it sure seems like it is.  A= ny ECDSA experts care to weigh in?

 

[JLS] A fast review= of the algorithm on Wikipedia confirms what I was thinking.  The valu= e of R is obtained from a point on the field  (using just k) and the v= alue S is then computed from the value of x and the hash value.  This means that (r,s) is not a point on the field. <= o:p>

 

OK, I’ll rewo= rd.  Thanks for the research.

 

Section 3.6

 

1.  I don't see the purpose of the last para= graph in this section.  It has nothing to do with algorithms.

 

This subsection is = not only about algorithms – it’s about extensions to JWS, the p= arameters registry for which is also in the JWA spec because it’s sha= red between JWS and JWE.  The first and second paragraphs of this subsection is about extensions via algorithms and has a reference = to that JWA registry.  The third paragraph is about extensions via par= ameters, and has a reference to that JWA registry.  Not that 3.6 is pa= rallel to 4.11 which has the same content for JWEs.

 

All that being said= , I’d be open to a different editorial structuring, if someone wants = to make an alternative proposal.

 

Section 4.5

 

1.  RSA-OAEP is under specified.  There= are a number of parameters for OAEP that must be defined to go with it.&nb= sp; These include the mask function and a hash function.  Look at RFC = 3447 for the details.

 

This is now fully s= pecified.  The description now reads:  RSA using Optimal Asymmetr= ic Encryption Padding (OAEP), as defined in RFC 3447, with the default para= meters specified by RFC 3447 in Section A.2.1

 

[JLS] It is strongl= y recommended that the hash function for OAEP and the hash function for the= content be the same values.  Additionally, why would we recommend usi= ng SHA1 for any of these parameters given that it is not recommended for any other purpose?

 

This has to do with= the working group’s goal of having developers actually be able to de= ploy the resulting specification.  Using the .NET Framework as an exam= ple (because it’s one that I’m familiar with), the RSA encryption choices available are PKCS 1-1.5 and OAEP with the defa= ult parameters.  A .NET JWE implementation would be extremely difficul= t if we stray from what’s actually deployed.

 

If you look at PHP,= Ruby, Python, OpenSSL, MacOS, Android, iOS, Windows Phone, etc. as actuall= y deployed, you’ll find similar limitations.  (In fact, you will= not find OAEP support at all on some of these developer platforms.)

 

We could delete OAE= P entirely on that basis if the working group chooses, or make it DEPRECATE= D, rather than OPTIONAL, but I don’t believe that defining variants u= sing non-default parameters would be useful, given that they couldn’t be used on most development platforms.=

 

On a related note, = some colleagues and I have started to gather data on what JWA algorithms ar= e implemented on what development platforms.  I’ll send a separa= te note shortly requesting presentation time during the meeting to discuss and help refine the data that we’ve gathered.=

 

Section 4.6

 

2.  I strongly disagree with setting OtherIn= fo parameters to be empty.   We

need to define and fill in the AlgorithmId at a m= inimum.  Note that this can be an implicit computation and does not ne= ed to be carried as extra data.

At a minimum I would suggest something along the = lines of JOSE-### where ### is the number of bits to get generated.

 

Per my response to = Sean’s related comment, it's not clear to me what additional value th= ese parameters add in our usage of the algorithm.  If we believe that = the content master key is undeterminable by an attacker (a requirement for any security at all!) then adding a constant A= lgorithmID to the computation I don't believe changes the security properti= es.  (That being said, we *could* use the “alg” value &quo= t;ECDH-ES" as the AlgorithmID if people felt better about doing this.)

 

Also given that the= text now says (per your previous comment) that "A new epk (ephemeral = public key) value MUST be generated for each key agreement transaction"= ;, it's not clear that adding parameters identifying the participating parties adds any security value either.  That being= said, I'd be glad to learn why I'm wrong.

 

If there are good s= ecurity reasons for requiring PartyUInfo and PartyVInfo values, do you have= suggestions on how to create acceptable values without carrying more param= eters in the header?  (I've already suggested that we could use the “alg” value "ECDH-ES"= ; as the AlgorithmID, which wouldn't require more parameters.)

 

For instance, I don= 't want to blindly follow XML ENC's lead and punt the issue by requiring th= at conforming uses provide explicit PartyUInfo and PartyVInfo values.<= /o:p>

 

Finally, I'll note = that the KDF function used by TLS http://tools.ietf.= org/html/rfc5246#section-5 uses no party parameters.  Why do we ne= ed them then?

 

[JLS] The object of= having the algorithm identifier be present is to make sure that if you are= doing two kdfs from the same key pairs for different purposes that they wi= ll never end up generating the same key values (or a prefix of the same key values).   While it is n= ot immediate obvious that this is going to be possible with the JOSE docume= nts, it is a known security issue and one that is easily addressed.  O= ne way would be as I suggested above and used a string with the number of bits.  Another way would be to use the algo= rithm that the key is going to be used for (which is how it is defined).&nb= sp; Thus this should be the ACUTAL content encryption algorithm used (i.e. = AES128GW or AES128CBC+HS256).

 

I suspect that usin= g the concatenation of the “enc” and “int” values a= s the AlgorithmID, as you suggest above, is the right solution when doing K= ey Derivation.  This is already on the Open Issues list to discuss on the mailing list and in Vancouver.

 

At this point I now= would say that the KDF MUST have the ability to have a PartyUInfo value sp= ecified.  When the KDF was implicit in the key agreement algorithm tag= it did not matter.  At that point if someone defined a new static-static version of ECDH then they would be required to= define what KDF function was to be used and could then require that the Pa= rtyUInfo field be defined in the KDF function that required.  As it st= ands now, the KDF is no longer tied to the key agreement algorithm and must therefore meet the necessary security= requirements for a static-static version of DH as well as the ephemeral st= atic versions.  (On the other hand it still may be implicit, but this = was not completely obvious as there is a kdf function that would be used in some cases leading to a confusion abo= ut what the kdf function was actually being used for.)

 

Key Agreement and K= ey Derivation are different cases.  In the case of Key Agreement, the = KDF *is* tightly bound to the algorithm definition.  See the definitio= n of “ECDH-ES” in http://tools.ietf.org/h= tml/draft-ietf-jose-json-web-algorithms-03#section-4.1.  Note also that use of a unique random ephemeral public key is required, so unless your ke= ygen algorithm is broken, there’s no chance of generating the same de= rived keys.

 

I believe it’= s already clear in http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-03#section-4= .1.4 that the “kdf” member is used in the Key Derivation ca= se – not the Key Agreement case.  But we can tighten this langua= ge further, if you’d like to suggest better wording.

 

For TLS, both the P= artyUInfo and the PartyVInfo values are present and used when computing the= key from the master secret.  Since they are present at that point the= y do not need to be present when computing the master secret itself.   When using TLS to compute other secr= ets – such as a TLS Unque value, the equivalent of the algorithm ID i= s used at that point to make sure that all such keys computed are going to = be unique to that purpose.

 

I believe you’= ;re discussing the Key Derivation case in the above paragraph.  Again,= I think that using the concatenation of the “enc” and “i= nt” values as the AlgorithmID may be the right outcome for Key Deriva= tion.  But just as in the Key Agreement case, given that a unique random CMK valu= e MUST be used, there’s no chance of generating the same derived keys= for other parties, unless the keygen algorithm generates duplicate keys (i= n which case you have bigger problems).

 

That being said, if= there’s a way of utilizing PartyUInfo and PartyVInfo values in the K= DF computation that doesn’t involve carrying them as additional heade= r parameter values, I’d certainly personally be open to that as well.

 

Section 4.11

 

1.  for last paragraph see comment on 3.6

 

Same response as fo= r 3.6

 

Section 6.1

 

1.  I would move this registry to either the= signature or encryption documents and not put it here.  What does thi= s document populate it with?

 

Done

 

Section 6.2

 

1.  Make life easy for IANA and me - create = a table of the values

 

Done both here and = in the other documents

 

[JLS] What is the p= urpose of putting the Implementation Requirements into the table?  Dif= ferent applications may have different requirements and these requirements = may change over time.  It does not make sense to require the table to be updated every time the set of requirements chan= ge.  The only exception to that might be an obsoleted or do not use fi= eld, but even that can be somewhat iffy.

 

Sean Turner had sug= gested this.  Apparently it is done in other specifications and regist= ries.  (Examples, Sean?)  It’s certainly easier for impleme= nters to understand, because they’ll always be able to count on the registry’s implementation status to be up to date.  This= can change, for instance, as algorithms move from OPTIONAL to RECOMMENDED = to REQUIRED, or when they move from any of those states to DEPRECATED.=

 

Section 6.3

 

1.  This registry should be in either the en= cryption or signature draft

 

Done – now in= JWS

 

Section 6.4

 

1.  This registry should be in the JWK docum= ent

 

Done

 

Section 6.5

 

1.  Make life easy for IANA and me - create = a table of the values

 

Done both here and = in the other documents

 

--_000_4E1F6AAD24975D4BA5B16804296739436672B7CDTK5EX14MBXC285r_-- From Michael.Jones@microsoft.com Fri Jul 13 14:21:50 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373C711E8108 for ; Fri, 13 Jul 2012 14:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.812 X-Spam-Level: X-Spam-Status: No, score=-3.812 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wL1h-G9elM3q for ; Fri, 13 Jul 2012 14:21:49 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id ECD5E11E8097 for ; Fri, 13 Jul 2012 14:21:48 -0700 (PDT) Received: from mail109-am1-R.bigfish.com (10.3.201.244) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Fri, 13 Jul 2012 21:22:25 +0000 Received: from mail109-am1 (localhost [127.0.0.1]) by mail109-am1-R.bigfish.com (Postfix) with ESMTP id 3D9F53A022D; Fri, 13 Jul 2012 21:22:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -35 X-BigFish: VS-35(z691L6caIz98dI9371I542M1432I4015I14ffIzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail109-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail109-am1 (localhost.localdomain [127.0.0.1]) by mail109-am1 (MessageSwitch) id 1342214542842948_22955; Fri, 13 Jul 2012 21:22:22 +0000 (UTC) Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.231]) by mail109-am1.bigfish.com (Postfix) with ESMTP id CBA7740004A; Fri, 13 Jul 2012 21:22:22 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 13 Jul 2012 21:22:22 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0309.003; Fri, 13 Jul 2012 21:22:08 +0000 From: Mike Jones To: Brian Campbell Thread-Topic: nit on Base64url (was Re: [jose] Minor release this week for JOSE specs) Thread-Index: AQHNXkKCyO41wbhf80qhJCqGG3fTvJcnvmTg Date: Fri, 13 Jul 2012 21:22:07 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436672B7F9@TK5EX14MBXC285.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] nit on Base64url (was Re: Minor release this week for JOSE specs) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 21:21:50 -0000 OK -----Original Message----- From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 Sent: Monday, July 09, 2012 7:19 PM To: Mike Jones Cc: jose@ietf.org Subject: nit on Base64url (was Re: [jose] Minor release this week for JOSE = specs) A minor thing but both JWS and JWE use the term Base64url in the Terminolog= y section before it is actually introduced/defined. The two drafts might re= ad a little better if the Base64url definition came earlier in the Terminol= ogy sections before the Encoded JWX XXXXX definitions. On Mon, Jul 9, 2012 at 6:00 PM, Mike Jones wr= ote: > Hi all, > > > > The -03 drafts of our specs were a "major release" - incorporating=20 > changes resulting from almost 200 comments on the specs, including=20 > some very major changes/additions like adding testable encryption=20 > examples. Since last week's release, some additional comments have=20 > been trickling in on the -03 drafts. > > > > I should have time to do a "minor release" this week. If there are=20 > issues with the current drafts that you'd like see corrected or=20 > cataloged before Vancouver, please try to get them to me by mid-week. =20 > That should enable me to turn the crank before next Monday's submission c= ut-off. > > > > =20 > Thanks, > > --=20 > Mike > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > From mamille2@cisco.com Fri Jul 13 15:54:15 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F216811E8136 for ; Fri, 13 Jul 2012 15:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.581 X-Spam-Level: X-Spam-Status: No, score=-10.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQ49VFzjMYJw for ; Fri, 13 Jul 2012 15:54:13 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4766211E80CB for ; Fri, 13 Jul 2012 15:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=5161; q=dns/txt; s=iport; t=1342220090; x=1343429690; h=from:to:subject:date:message-id:references:mime-version; bh=p+n+ZsTYe16yUaaUzXkBPqWAgn4+mhjokBHJ+riP1Aw=; b=NoAUzgTOZHEUOfiAmQ0JCiHH/McnQ4dMKEuyDiiAmzHLRc4SVsVzrTAf Kp5N0PyROtaS1cVU1+LBJYqTeZB95cIT8FBnfU/4mtKy2ktFc/LPgstql hY81PyKUEFl59XobVTGhBFrx4GAj84wNKFm/KNh04WCjEjJqL8S3xKlCg A=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALylAFCtJV2Y/2dsb2JhbABFuCOBB4IgAQEBAwEBAQEPAVsQCwIBTgIlCxsKAgQTDhSHZQYLm2CgHJBSYAOOTIEhhU2BEo0OgWaCXw X-IronPort-AV: E=Sophos;i="4.77,582,1336348800"; d="sig'?p7s'?scan'208";a="101765141" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 13 Jul 2012 22:54:50 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6DMso9X006662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 13 Jul 2012 22:54:50 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.238]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Fri, 13 Jul 2012 17:54:50 -0500 From: "Matt Miller (mamille2)" To: "jose@ietf.org" Thread-Topic: [xmpp] UPDATED: draft-miller-xmpp-e2e Thread-Index: AQHNYUpgVg15xKZpeU+80MUlENbqxA== Date: Fri, 13 Jul 2012 22:54:49 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 1.3.3 x-originating-ip: [64.101.72.24] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19036.004 x-tm-as-result: No--35.770400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-10-988187897" MIME-Version: 1.0 Subject: [jose] Fwd: [xmpp] UPDATED: draft-miller-xmpp-e2e X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 22:54:15 -0000 --Apple-Mail-10-988187897 Content-Type: multipart/signed; boundary=Apple-Mail-9-988187887; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-9-988187887 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI ... Begin forwarded message: > An update to draft-miller-xmpp-e2e is now available. This is still = using JW*, but uses key wrapping instead of "alg":"none". There is still = some partial header use, for the exchange of the Session Master Key = (SMK). >=20 > No, this is not addressing every single concern everyone might have = brought up on- or off-list, but at least demonstrates something (I = think) is more inline with JWE. >=20 >=20 > < http://tools.ietf.org/html/draft-miller-xmpp-e2e-02 > >=20 >=20 > - m&m >=20 > Matt Miller - > Cisco Systems, Inc. >=20 > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp - m&m Matt Miller - Cisco Systems, Inc. --Apple-Mail-9-988187887 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcxMzIyNTUy NFowIwYJKoZIhvcNAQkEMRYEFFe7blfSWVroARUMiQz2eJHWaAkEMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQAz3/cB6jUW/LdsDVrE6VsxahD0X8p1vyatk7kaMm9P6nwDSZKOXlSh0lVL 6rJfgdlTpAvzZ/eHLMri3f1oNW+/sRx2w9LzqLY1H18QUigxyEntmg+ry6pzUQYRRlZergdMUIpj BbgGLMHbUveYc88TcdV9SaYCygqIfL2YBRp0IlbHMiu/4zyXdmLbObusJXSOpAn5ii5hsbWmAIS0 8kEyhI9ANpOfmsi6yZAePlBXgTbpJY2s8vQAU+mlSoASJqj8hIeGjdrRr2SHTmaPZkHRqI8Y2phr xEf4OHaod3YwJCsU+V2ugeF7l3zaUnjaKilJmW3uWnIWjf5QTYpdBkQNAAAAAAAA --Apple-Mail-9-988187887-- --Apple-Mail-10-988187897 Content-Type: application/pgp-signature; x-mac-type=70674453; name="PGP.sig" Content-Description: This is a digitally signed message part Content-Disposition: inline; filename="PGP.sig" Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJQAKdcAAoJEJq6Ou0cgrSPIQ4H/iVozwTk1J7fAYoUwp354vkW EuBzTbCmkr7aVNRXPA3wTEJbce3waPtb6wpCz2x8amlGhf4wFbuAJ1PFtHQjtMZi 369Tx9/cbdH4vzX6pquCJPdV8V5sBtgBc9Dhd1txFOCMRoklUUGqFVM1/ONZY9ig OTjEGnsTuU0zPmnNp8/by6PgFh1QEUF/jfOwL5omdgMQ1t8HcVL4C8IgPI05F6UP 2xvrt1yfbFVJ5QYzxCgPJYym9CGSdM0k982F8+863BY11ItQKbmucp0JMMU1ohMN o0n+LON0pQSY8xvz4E2izMISuiCixYUBe9vqfdWrQi9euv7GEKQxW7l7nv9qTMA= =i5gO -----END PGP SIGNATURE----- --Apple-Mail-10-988187897-- From ietf@augustcellars.com Fri Jul 13 16:40:07 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB96121F8597 for ; Fri, 13 Jul 2012 16:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.446 X-Spam-Level: X-Spam-Status: No, score=-3.446 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZveJEHymSHo for ; Fri, 13 Jul 2012 16:39:58 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id F350F21F8595 for ; Fri, 13 Jul 2012 16:39:57 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 915FA2CA0A; Fri, 13 Jul 2012 16:40:34 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" References: <4E1F6AAD24975D4BA5B168042967394366579F15@TK5EX14MBXC283.redmond.corp.microsoft.com> <002301cd5d5c$e36edb80$aa4c9280$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436672B792@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436672B792@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Fri, 13 Jul 2012 16:39:12 -0700 Message-ID: <00f001cd6150$b7049060$250db120$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F1_01CD6116.0ABB1520" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJX5M/VJt2HR8o6/IyQZq2axBfNmQHzaWAkAshNP/yV7PROQA== Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] Comments on draft-ietf-jose-json-web-key-02 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 23:40:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F1_01CD6116.0ABB1520 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Additional Notes From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, July 13, 2012 2:20 PM To: Jim Schaad Cc: jose@ietf.org Subject: RE: Comments on draft-ietf-jose-json-web-key-02 Responses inline. From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Sunday, July 08, 2012 3:56 PM To: Mike Jones Cc: jose@ietf.org Subject: RE: Comments on draft-ietf-jose-json-web-key-02 Comments on responses and some additional comments as well. If the security sections references the XML DSig document as having important security considerations, then it needs to be normative and not informative. Will do Jim From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, July 06, 2012 10:31 AM To: Jim Schaad Cc: jose@ietf.org Subject: RE: Comments on draft-ietf-jose-json-web-key-02 Thanks for taking the time to provide the detailed feedback. Responses inline. -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Saturday, May 19, 2012 3:34 PM To: Mike Jones Cc: jose@ietf.org Subject: Comments on draft-ietf-jose-json-web-key-02 My apologies for introducing you to the term algorithm families. We don't use it in the same way and thus I think that you should generally remove it from the text. To me it is a very wide term and somewhat nebulous. Thus I think of all of the DH algorithms as being in a family - but that family could also include the ECDH algorithm as well as DSA depending on how one is using it. Thus for me an algorithm family is not restricted to a specific instance (or small set of instances) such a DH & DSA but could be as large as all key agreement algorithms. As such it does not really match how you are using it in much of the text. Left in for the current draft for lack of a better term. I did remove as many uses of the term as possible. Slightly more detailed: You can define an RSA key You can define an RSA-OAEP key The second one has all of the fields of the first, however it may have additional fields defined that deal specifically with RSA-OAEP. The difference is going to be a question of restriction of usage of the key to a single algorithm vs allowing for all RSA algorithms. Parameters could be defined in the JWA spec to specify parameters enabling those possible restrictions if the working group deems it useful/necessary. The JWK spec already makes it clear that algorithm-specific parameters may be required, so this wouldn't change the model. Here are some more comments Abstract 1. I am not a fan of the word enumerated in the last sentence. This word implies to me that the list is not expandable. I would recommend something along the lines of "An initial set of ... can be found in ..." Done here, plus in JWE, JWS, JWA, JWE-JS, and JWS-JS [JLS] This change was not made in the JWA document. Correct, because you wrote "I do not have a problem with enumerate in this document" in your May 21st message on JWA. I made a typo when I wrote that I applied it to JWA above. (Also, I actually think that in JWA, the word "enumerates" works well.) [JLS2] I did not re-read the note on the alg document until after I finished this review. I agreed in the other message that it did not need to be changed, but I was going based on the comment in this message. It is not a problem. Section 2 1. The phrase "For the purpose of this document" should be removed unless this term is used in other ways elsewhere. Not changed, because in some other contexts, the same term is used to refer to the non URL safe encoding. [JLS] Is it used in a different way in this document? One can automatically assumed that if you are defining a term, that it is for the purposes of this document and, unless generally accepted, is not applicable to other documents. Purely for curiosity, where is the phrase base64url encoding used to mean something else in a different document? OK, I'll delete the phrase. The term "base64 encoding" often (usually) means something different, but not the term "base64url encoding". Section 4 1. In para #2 - the use of "algorithm family" is incorrect. They members are going to be required for the specific key being represented not to the family - consider the case of RSA and RSA-OAEP - these are both in the same family, but the fields required are different. Reworded to not use the term "algorithm family" [JLS] Suggest "In addition to the common parameters, each JWK will have members that are specific to the key being represented. These members represent the parameters of the key. Section 5 of the JSON Web Algorithm (JWA) specifies a number of public keys and their associated members." Good 2. Do you believe that all of the algorithm members are defined in the JWA document - or only for some algorithms. Text should probably say they are defined for the algorithms defined for the algorithms in JWA. Done 3. I don't believe that para #3 is enforceable by parsers as they have been presented to me. Please prove me wrong. Section 2.2 of http://tools.ietf.org/html/rfc4627 says "The names within an object SHOULD be unique." So this should be enforced by conforming parsers. I'd be interested in data saying that parsers exist that are non-conforming to this RFC 4627 "SHOULD". If so, we should add appropriate warnings to the Security Considerations section. [JLS] Stating that they should be unique is more of a requirement on the generation side and not the parsing side of the specification. I do not believe that this statement in way says that parsers should reject objects for which duplicate member names exist. Parsers that accept input with duplicate member names are violating a SHOULD, as I see it. In any event, tightening this to "MUST be unique" is appropriate in our specs, since I'll grant you that relying on a SHOULD is inappropriate in a security context. If this requires secondary parsing or using a hardened parser to ensure member uniqueness, that's part of the price of having a correct implementation. (And consider the alternative - we *really* don't want to go down the path of having to make statements like "If there are multiple "alg" values, then."!) We started talking about these security considerations at http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-03#section-8.2 . I'll tighten this up. 4. Let's look at the sentence "If present, they MUST be understood by implementations using them." I believe that this is an incorrect assertion. (Not to mention that it is totally uncheckable.) Consider the following situation: Implementation A creates a JWK and files it with Implementation B. A does not understand the "exist-date" property. Implementation B adds the "exist-date" property and puts it at a URL. Implementation C pulls the JWK from the URL, understand the "exist-date" property. According to the MUST, the JWK cannot be used as it is not understood by all of the implementations. The only entity that you can make the requirement on is the consumer. One assumes that the "provider" would/might understand the field or it would not be there but it could have been added in transit and thus that is not the case. I believe that for your example, the text is correct as written, since in context, "them" refers to the additional members, not the JWK as a whole. At no point in your example did an implementation use a JWK with an additional member that it did not understand. [JLS] This is precisely the statement that I made above, the mandating that the field is understood by consumers of the JWK is possible, but it is not possible to mandate that all implementations involved in the transaction understand all of the fields. Maybe we can talk about this in person in Vancouver, because I think I'm still missing something in what you're trying to achieve here. In your example, the JWK created by A and the JWK created by B by adding the "exist-date" property to A are different JWKs, because they have different fields. At no point did any party, producer or consumer, use a JWK whose fields it did not all understand. (I'll grant you that if A were to use B's JWK, the "must understand" would be violated, but that's exactly the intent.) [JLS2] So we now have a situation where A publishes, B updates, C encrypts to the B version and sends to A which then fails the decrypt. I understand that the assertion may not be enforceable apart from conformance suites that check what implementations do when given new parameters, and I understand that in the general case, programmatic enforcement would be the equivalent of solving the halting problem. That's not an argument, however, that in security contexts, that having this requirement isn't the right thing to do. [JLS] I have not made an argument for removing it, but for stating that it is the consumer on which the restriction is placed on not on all implementations. You don't think that's equally important for producers to understand all the fields of the JWKs they're producing? [JLS2] What does it mean? Are we talking about the program that publishes or the program that decrypts? I think that a producing program should not generate something it cannot consume, but that is different that if we are talking about a person's system. In this case the production and consumption programs may be different and have different abilities to understand fields. I would be perfectly willing for producers to be able to publish JWKs with fields that they do not "understand". 5. I find the last sentence of para #4 to be unreadable. I would start by breaking it into two sentences and potentially move the first one into the JWA document (that about parameters for keys). Simplified [JLS] I think it can be simplified even more. For one thing it is not clear if the member name must be unique between kinds of keys. Thus can you have a "x" for both DH and ECDH (or do they fall into the same family?). Agreed. I'll simplify this further to just say "Member names SHOULD .". I'll also add "Member names used for representing key parameters for different kinds of keys need not be distinct", per your question about uniqueness. [JLS] Given that only fields dealing with either generic items or a specific key are represented in a JWK object. It would make more sense to have the restriction on member names than on generic members and not on members that are specific to a public key. Agreed - I believe my wording above addresses this. [JLS2] No I don't agree that is true. I asked what I thought was a question about changing the requirements. The current text says that specific members need to be registered. I asked if we should only require that generic members be registered. This would be a change in policy which might make the registry cleaner and easier to maintain, at the cost of some potential issues way down the road. Section 4.1 1. Do you want to point to the JWA document or to the registry for the set of defined algorithms? Clarified that some names are defined in JWA whereas all names not containing a collision resistant namespace should be registered. [JLS] OK - let me be more pointed in my comment. I think you should point at the registry and not at the other document for the list of defined algorithms. Additionally, I think you should point at the registry for the set of generic members defined and ignore the set of key specific members defined in this document. OK, I'll reword this (and similar locations) to make the registry be the primary reference and to add, on a secondary basis, that the JWA document provides the initial contents for the registry. (I believe we continue to need the JWA reference to help reviewers of the current specs, especially since the registry won't be created until the specs are approved as RFCs.) 2. In para #1 I would remove the sentence starting "Specific additional..." as this is not part of the definition of the "alg" parameter and is covered in section 4.0 Done 3. The last two sentences in para #1 can be combined together. This is just a personal stylistic thing I suppose, but I prefer two short declarative sentences to a conjunction of the two. [JLS] as oppose to "The "alg" value MUST be a case-sensitive string. OK, I agree that that wording's better. I'll make that change where applicable. Section 4.2 1. Presentation suggestion - if you use a bulleted list for the values it will be easier to see what the list of defined values is. Done 2. See point #3 in section 4.1 Ditto Section 4.3 1. Is there a requirement that the kid be unique in a JWK Set? I think that the answer should be called out in text either way. Good point. Added text saying that it need not be unique, and providing an example providing rationale for that choice. [JLS] Ok - I see documentation on how to handle the situation if there are multiple KIDs that have the same value, but I am missing the rationale that you have stated as being present. A rationale would be WHY one would have multiple keys with the same KID value. The rationale was in the "for instance" text. We could beef up the rationale if you have better suggested wording. As another example, imagine "kid" values like "Current", "Upcoming", and "Deprecated", used for key rollover guidance. You could apply that label to all keys where the classification fits. If there are multiple "Current" keys, then in this example they might be differentiated either by having different "alg" or "use" values, or some combination of both. (There might only be one current RSASA signing key and one current ECDSA signing key, but both would be "Current".) [JLS2] There is a rational about why there exists a kid field. There is not a rational about why the kids are not a requirement that they be unique. I don't know that I have a good reason for why the fields should not be unique within a single key set. This is the reason for asking for a rational to be provided. 2. Is the string case sensitive? It is now. :-) 3. Move the sentence "When used..." to a new paragraph. (suggestion) Done Section 6.1 1. Please make things easy for IANA - create a table with the fields across the top and the values down the table. This will allow them to do their job without having to go through the entire document and for us to be able to easily validate that they got it correct. Done here, plus in JWA and JWT [JLS] Section 6.1.1 - Under the Parameter Name: field, you should have a note for IANA that the name is case-sensitive and have a comment that names that match in a case-insensitive manner SHOULD or SHOULD NOT be accepted. (Copy note to all of the reset of the tables as well). Will do (with SHOULD NOT) [JLS] Section 6.1.1 - are there any longevity requirements on the URI that is specified? If we refer to an RFC then we know that it will "always" exist. This is not necessarily true if one refers to a document on a personal website. Is there best-practice text on this issue that anyone is aware of that we can reuse? (The current text is reused from the OAuth Core spec, which has already undergone IETF last call, and so seemed like a good place to start from.) [JLS2] This is a think question and not a requirement to change the document. Section 6.2 1. Please put in a registration section for the items you are registering in Section 4 in the JWK table. You can refer to JWA for creation of the table. Done here, plus in JWS, JWE, JWA, and JWT Appendix A 1. I am not sure why this appendix is in this document. To give credit to the inventors of the precursor spec that resulted in the JWK spec. I've added their names to make this intent clearer. ------=_NextPart_000_00F1_01CD6116.0ABB1520 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Additional Notes

 

From:= = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Friday, = July 13, 2012 2:20 PM
To: Jim Schaad
Cc: = jose@ietf.org
Subject: RE: Comments on = draft-ietf-jose-json-web-key-02

 

Responses inline…

 

From:= = Jim Schaad [mailto:ietf@augustcellar= s.com]
Sent: Sunday, July 08, 2012 3:56 PM
To: = Mike Jones
Cc: jose@ietf.org
Subject: RE: = Comments on = draft-ietf-jose-json-web-key-02

 

Comments on responses and some additional = comments as well.

 

If the security sections = references the XML DSig document as having important security = considerations, then it needs to be normative and not = informative.

 

Will = do

 

Jim

 

 

From:= = Mike Jones [mailto:Michael.Jone= s@microsoft.com]
Sent: Friday, July 06, 2012 10:31 = AM
To: Jim Schaad
Cc: jose@ietf.org
Subject: RE: = Comments on = draft-ietf-jose-json-web-key-02

 

Thanks for taking the time to provide the = detailed feedback.  Responses inline…

 

-----Original Message-----
From: Jim Schaad [mailto:ietf@augustcellar= s.com]
Sent: Saturday, May 19, 2012 3:34 PM
To: Mike = Jones
Cc: jose@ietf.org
Subject: Comments on = draft-ietf-jose-json-web-key-02

 

<no = hat>

 

My apologies for introducing you to the term = algorithm families.  We don't use it in the same way and thus I = think that you should generally remove it from the text.  To me it = is a very wide term and somewhat nebulous.  Thus I think of all of = the DH algorithms as being in a family - but that family could also = include the ECDH algorithm as well as DSA depending on how one is using = it.  Thus for me an algorithm family is not restricted to a = specific instance (or small set of instances) such a DH & DSA but = could be as large

as all key = agreement algorithms.   As such it does not really match how = you

are using it in much of the = text.

 

Left in for the = current draft for lack of a better term.  I did remove as many uses = of the term as possible.

 

Slightly more detailed:

 

You = can define an RSA key

You can = define an RSA-OAEP key

 

The = second one has all of the fields of the first, however it may have = additional fields defined that deal specifically with RSA-OAEP.  = The difference is going to be a question of restriction of usage of the = key to a single algorithm vs allowing for all RSA = algorithms.

 

Parameters could be defined in the JWA spec to = specify parameters enabling those possible restrictions if the working = group deems it useful/necessary.  The JWK spec already makes it = clear that algorithm-specific parameters may be required, so this = wouldn’t change the model.

 

Here = are some more comments

 

Abstract

 

1.  I am not a fan of the word enumerated in = the last sentence.  This word implies to me that the list is not = expandable.  I would recommend something along the lines of = "An initial set of ... can be found in ..."

 

Done here, plus in JWE, JWS, JWA, JWE-JS, and = JWS-JS

 

[JLS] This change was = not made in the JWA document.

 

Correct, because you = wrote “I do not have a problem with enumerate in this = document” in your May = 21st message on JWA.  I made a typo when I wrote that I = applied it to JWA above.  (Also, I actually think that in JWA, the = word “enumerates” works well.)

 

[JLS2] I did not = re-read the note on the alg document until after I finished this review. =   I agreed in the other message that it did not need to be = changed, but I was going based on the comment in this message.  It = is not a problem.

 

Section 2

 

1.  The phrase "For the purpose of this = document" should be removed unless this term is used in other ways = elsewhere.

 

Not changed, because = in some other contexts, the same term is used to refer to the non URL = safe encoding.

 

[JLS] Is it used in a = different way in this document?   One can automatically = assumed that if you are defining a term, that it is for the purposes of = this document and, unless generally accepted, is not applicable to other = documents. 

 

Purely for curiosity, = where is the phrase base64url encoding used to mean something else in a = different document?

 

OK, I’ll delete = the phrase.  The term “base64 encoding” often (usually) = means something different, but not the term “base64url = encoding”.

 

Section 4

 

1.  In para #2 - the use of "algorithm = family" is incorrect.  They members are going to be required = for the specific key being represented not to the family - consider the = case of RSA and RSA-OAEP - these are both in the same family, but the = fields required are different.

 

Reworded to not use = the term “algorithm family”

 

[JLS] =   Suggest “In addition to the common parameters, each = JWK will have members that are specific to the key being = represented.  These members represent the parameters of the = key.   Section 5 of the JSON Web Algorithm (JWA) specifies a = number of public keys and their associated = members.”

 

Good

 

2.  Do you believe that all of the algorithm = members are defined in the JWA

document - or only for some algorithms.   = Text should probably say they are

defined for the algorithms defined for the = algorithms in JWA.

 

Done

 

3.  I don't believe that para #3 is = enforceable by parsers as they have been presented to me.  Please = prove me wrong.

 

Section 2.2 of = http://tools.ietf.org/html/rf= c4627 says “The names within an object SHOULD = be unique.”  So this = should be enforced by conforming parsers.  I’d be interested = in data saying that parsers exist that are non-conforming to this RFC = 4627 “SHOULD”.  If so, we should add appropriate = warnings to the Security Considerations section.

 

[JLS] Stating that = they should be unique is more of a requirement on the generation side = and not the parsing side of the specification.  I do not believe = that this statement in way says that parsers should reject objects for = which duplicate member names exist.

 

Parsers that accept = input with duplicate member names are violating a SHOULD, as I see = it.  In any event, tightening this to “MUST be unique” = is appropriate in our specs, since I’ll grant you that relying on = a SHOULD is inappropriate in a security context.  If this requires = secondary parsing or using a hardened parser to ensure member = uniqueness, that’s part of the price of having a correct = implementation.  (And consider the alternative – we = *really* don’t want to go down the path of having to make = statements like “If there are multiple “alg” values, = then…”!)

 

We started talking = about these security considerations at http://tools.ietf.org/html/draft-ietf-jose-json-web-signatur= e-03#section-8.2.  I’ll tighten this = up.

 

4.  Let's look at the sentence  "If = present, they MUST  be understood by implementations using = them."  I believe that this is an incorrect = assertion.

(Not to mention that it = is totally uncheckable.)  Consider the following

situation:

 

Implementation A creates a JWK and files it with = Implementation B.  A does not understand the "exist-date" = property.

Implementation B adds = the "exist-date" property and puts it at a = URL.

Implementation C pulls the = JWK from the URL, understand the "exist-date"

property.

According to the MUST, the JWK cannot be used as it = is not understood by all of the implementations.

 

The = only entity that you can make the requirement on is the consumer.  = One assumes that the "provider" would/might understand the = field or it would not be there but it could have been added in transit = and thus that is not the case.

 

I believe that for = your example, the text is correct as written, since in context, = “them” refers to the additional members, not the JWK as a = whole.  At no point in your example did an implementation use a JWK = with an additional member that it did not = understand.

 

[JLS] This is = precisely the statement that I made above, the mandating that the field = is understood by consumers of the JWK is possible, but it is not = possible to mandate that all implementations involved in the transaction = understand all of the fields.

 

Maybe we can talk = about this in person in Vancouver, because I think I’m still = missing something in what you’re trying to achieve here.  In = your example, the JWK created by A and the JWK created by B by adding = the “exist-date” property to A are different JWKs, because = they have different fields.  At no point did any party, producer or = consumer, use a JWK whose fields it did not all understand.  = (I’ll grant you that if A were to use B’s JWK, the = “must understand” would be violated, but that’s = exactly the intent.)

 

[JLS2] So we now have = a situation where A publishes, B updates, C encrypts to the B version = and sends to A which then fails the decrypt.

 

I understand that the = assertion may not be enforceable apart from conformance suites that = check what implementations do when given new parameters, and I = understand that in the general case, programmatic enforcement would be = the equivalent of solving the halting problem.  That’s not an = argument, however, that in security contexts, that having this = requirement isn’t the right thing to do.

 

[JLS] I have not made = an argument for removing it, but for stating that it is the consumer on = which the restriction is placed on not on all = implementations.

 

You don’t think = that’s equally important for producers to understand all the = fields of the JWKs they’re producing?

 

[JLS2] What does it = mean?  Are we talking about the program that publishes or the = program that decrypts?   I think that a producing program = should not generate something it cannot consume, but that is different = that if we are talking about a person’s system.  In this case = the production and consumption programs may be different and have = different abilities to understand fields.  I would be perfectly = willing for producers to be able to publish JWKs with fields that they = do not “understand”.

 

5.  I find the last sentence of para #4 to be = unreadable.  I would start by breaking it into two sentences and = potentially move the first one into the JWA document (that about = parameters for keys).

 

Simplified

 

[JLS]  I think = it can be simplified even more.  For one thing it is not clear if = the member name must be unique between kinds of keys.  Thus can you = have a “x” for both DH and ECDH (or do they fall into the = same family?).

 

Agreed.  = I’ll simplify this further to just say “Member names SHOULD = …”.  I’ll also add “Member names used for = representing key parameters for different kinds of keys need not be = distinct”, per your question about = uniqueness.

 

[JLS] Given that only = fields dealing with either generic items or a specific key are = represented in a JWK object.  It would make more sense to have the = restriction on member names than on generic members and not on members = that are specific to a public key.

 

Agreed – I = believe my wording above addresses this.

 

[JLS2] No I = don’t agree that is true.  I asked what I thought was a = question about changing the requirements.  The current text says = that specific members need to be registered.  I asked if we should = only require that generic members be registered.  This would be a = change in policy which might make the registry cleaner and easier to = maintain, at the cost of some potential issues way down the = road.

 

Section 4.1

 

1. Do = you want to point to the JWA document or to the registry for the set of = defined algorithms?

 

Clarified that some = names are defined in JWA whereas all names not containing a collision = resistant namespace should be registered.

 

[JLS] OK – let = me be more pointed in my comment.  I think you should point at the = registry and not at the other document for the list of defined = algorithms.  Additionally, I think you should point at the registry = for the set of generic members defined and ignore the set of key = specific members defined in this document.

 

OK, I’ll reword = this (and similar locations) to make the registry be the primary = reference and to add, on a secondary basis, that the JWA document = provides the initial contents for the registry.  (I believe we = continue to need the JWA reference to help reviewers of the current = specs, especially since the registry won’t be created until the = specs are approved as RFCs.)

 

2. In para #1 I would remove the sentence starting = "Specific additional..."

as this is not part of the definition of the = "alg" parameter and is covered in section 4.0

 

Done

 

3.  The last two sentences in para #1 can be = combined together.

 

This is just a = personal stylistic thing I suppose, but I prefer two short declarative = sentences to a conjunction of the two.

 

[JLS] as oppose to = “The “alg” value MUST be a case-sensitive = string.

 

OK, I agree that that = wording’s better.  I’ll make that change where = applicable.

 

Section 4.2

 

1.  Presentation suggestion - if you use a = bulleted list for the values it will be easier to see what the list of = defined values is.

 

Done

 

2.  See point #3 in section = 4.1

 

Ditto

 

Section 4.3

 

1.  Is there a requirement that the kid be = unique in a JWK Set?  I think that the answer should be called out = in text either way.

 

Good point.  = Added text saying that it need not be unique, and providing an example = providing rationale for that choice.

 

[JLS]  Ok = – I see documentation on how to handle the situation if there are = multiple KIDs that have the same value, but I am missing the rationale = that you have stated as being present.  A rationale would be WHY = one would have multiple keys with the same KID = value.

 

The rationale was in = the “for instance” text.  We could beef up the = rationale if you have better suggested wording.

 

As another example, = imagine “kid” values like “Current”, = “Upcoming”, and “Deprecated”, used for key = rollover guidance.  You could apply that label to all keys where = the classification fits.  If there are multiple = “Current” keys, then in this example they might be = differentiated either by having different “alg” or = “use” values, or some combination of both.  (There = might only be one current RSASA signing key and one current ECDSA = signing key, but both would be = “Current”.)

 

[JLS2]  There is = a rational about why there exists a kid field.  There is not a = rational about why the kids are not a requirement that they be = unique.  I don’t know that I have a good reason for why the = fields should not be unique within a single key set.   This is = the reason for asking for a rational to be = provided.

 

2.  Is the string case = sensitive?

 

It is now. = :-)

 

3.  Move the sentence "When used..." = to a new paragraph.  (suggestion)

 

Done

 

Section 6.1

 

1. = Please make things easy for IANA - create a table with the fields across = the top and the values down the table.  This will allow them to do = their job without having to go through the entire document and for us to = be able to easily validate that they got it correct.

 

Done here, plus in = JWA and JWT

 

[JLS] Section 6.1.1 = – Under the Parameter Name: field, you should have a note for IANA = that the name is case-sensitive and have a comment that names that match = in a case-insensitive manner SHOULD or SHOULD NOT be accepted. (Copy = note to all of the reset of the tables as well).

 

Will do (with SHOULD = NOT)

 

[JLS] Section 6.1.1 = – are there any longevity requirements on the URI that is = specified?  If we refer to an RFC then we know that it will = “always” exist.  This is not necessarily true if one = refers to a document on a personal website.

 

Is there = best-practice text on this issue that anyone is aware of that we can = reuse?  (The current text is reused from the OAuth Core spec, which = has already undergone IETF last call, and so seemed like a good place to = start from.)

 

[JLS2] This is a = think question and not a requirement to change the = document.

 

Section 6.2

 

1. = Please put in a registration section for the items you are registering = in Section 4 in the JWK table.  You can refer to JWA for creation = of the table.

 

Done here, plus in = JWS, JWE, JWA, and JWT

 

Appendix A

 

1.  I am not sure why this appendix is in this = document.

 

To give credit to the = inventors of the precursor spec that resulted in the JWK spec.  = I’ve added their names to make this intent = clearer.

 

------=_NextPart_000_00F1_01CD6116.0ABB1520-- From ietf@augustcellars.com Fri Jul 13 16:54:58 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29EC921F859E for ; Fri, 13 Jul 2012 16:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgV39yuHQJaT for ; Fri, 13 Jul 2012 16:54:37 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 68F2021F859B for ; Fri, 13 Jul 2012 16:54:37 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id D3C922CA16; Fri, 13 Jul 2012 16:55:13 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" References: <4E1F6AAD24975D4BA5B168042967394366579FC3@TK5EX14MBXC283.redmond.corp.microsoft.com> <008701cd5d91$f3cbe740$db63b5c0$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436672B7CD@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436672B7CD@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Fri, 13 Jul 2012 16:53:54 -0700 Message-ID: <00f801cd6152$c3299ff0$497cdfd0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F9_01CD6118.16D3C8A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHrEbFlExgZBQrw4w5tA27sA4p9CAG3lvDNAOrlAnCW12o0wA== Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 23:54:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F9_01CD6118.16D3C8A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, July 13, 2012 2:21 PM To: Jim Schaad Cc: jose@ietf.org Subject: RE: Comments on draft-ietf-jose-json-web-algorithms-02 Responses inline. From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Sunday, July 08, 2012 10:16 PM To: Mike Jones Cc: jose@ietf.org Subject: RE: Comments on draft-ietf-jose-json-web-algorithms-02 Responses to previous comments and some new comments. Open issue feedback - Do AES ECB - no From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, July 06, 2012 10:41 AM To: 'Jim Schaad' Cc: jose@ietf.org Subject: RE: Comments on draft-ietf-jose-json-web-algorithms-02 Thanks for taking the time to provide the detailed feedback. Responses inline. -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, May 21, 2012 3:46 PM To: Mike Jones Cc: jose@ietf.org Subject: Comments on draft-ietf-jose-json-web-algorithms-02 Here are comments this document Abstract 1. Since I called it out for JWK I will make the comment that I do not have a problem with enumerate in this document. Noted [JLS] On the other had since you said it was addressed in the mail for the JWK document and it is not changed I do have a problem there. Saying in the JWK feedback that it was addressed in JWA was a typo in my e-mail on my part. I intentionally did not change away from the word "enumerates" in JWA both since you said that you *didn't* have a problem with it, and because I believe it accurately conveys what the JWA document does. But I'd be open to an alternative description if you'd like to supply wording that's even clearer. Section 1 1. Just a comment - I am not sure why you feel the name to create a specific acronym for this document but it does not really matter. It provides a shorthand name to refer to this document from others. 2. Need to expand JSON if you are going to use it. Not done here, because the word "JSON" here is used as part of a name, rather than as a reference to a specification or kind of data structure. I did expand it the first time it is used to refer to the RFC 4627 data structures, in all the documents. [JLS] The rules state that it is to be expanded on the first use. If it is not done on the first use then the RFC editor will do so. It should be ok in the key document since it is done almost immediately after the first use. As it currently stands it does not follow this rule. How would adding a sentence like this work for you? "All these specifications utilize JavaScript Object Notation (JSON) [RFC4627] based data structures." [JLS2] that would address the problem. 3. New paragraph for sentence starting with "Enumerating..." Separate justification from what this document does and hash. Done 4. Move last sentence to the end of the first paragraph Done Section 2 1. In general I would like to see this duplicated into this document. Readers should not have to reference another document for this purpose. Done [JLS] However only the relevant terms should be included. If JWE Ciphertext is never used then it does not need to be included at this point. Agreed. I already did a pass and removed unused terms. In the example of JWE Ciphertext, this term is used in the definition of JWE Header, which is used in the body of the specification, and so is necessary. If you find some that are not used directly or indirectly, please point them out, and I'll remove them. Section 3.1 1. I am not overly happy with the existence of a "none" algorithm. Does it really need to exist? Yes. It is already widely used in contexts where content can be either signed or plaintext. And while it used to be defined in JWT, you'd earlier suggested that it be moved here, since it is of broader applicability than just JWTs. [JLS] I don't disagree with it being here rather than in the JWT document. However there is a question if it would be better represented as having an absent alg parameter rather than having a "none" algorithm. It would accomplish the same thing and be less suggested if an actual signature/MAC algorithm existing on the document. The due diligence that users of "alg":"none" have to perform is actually no less than the due diligence that they have to apply when using any other "alg" value. At some future time, for instance, if HMAC SHA-256 is broken, then using "HS256" would be arguably be worse than using "none", because "HS256" might provide the illusion of security, where in fact, there would be none - sort of like if someone were to propose to use "HMD5" now. That there's no security is at least apparent with "none". J Algorithms must always be used that are security-appropriate given the needs of the application in the particular context and the current state of cryptography/cryptanalysis. Having a "none" algorithm doesn't change that. [JLS] I would disagree based on past history. But will no press the issue, Section 3.2 1. You may want to reference RFC4231 as well. It contains test vectors and such for the SHA2 HMACs If this spec were about implementing the SHA2 HMAC algorithms, I would agree, but since it's only about using them, I don't think this reference is necessary. Feel free to push back on this, however. 3. I have not yet read the updated JWS document, but I do worry about the fact that this document is saying that the output should be base64url encoded. If the JWS document says the same thing injudiciously then one could easily see that people might double encode the result. I don't think there's a problem, as both documents make a clear distinction between the "JWS Signature" value and the "Encoded JWS Signature" value, and are careful to use the right term in the right place. (But obviously send me corrections if you find a place where the wrong term is used.) 4. I have a real problem with people saying that UTF-8 and ASCII are the same. They aren't and saying that they are does not make it so. They actually are the same in this case, since the JWS Secured Input consists of only 7-bit ASCII characters (since they contain only base64url encoded content and periods characters) that are represented the same in both encodings. But I agree that the previous text was potentially confusing and overly verbose. The text now only uses the phrase "the ASCII representation of the JWS Secured Input", both here, and in the JWS spec. [JLS] Do you know this to be a true statement for all future encodings of JWS values as oppose to the current one that is defined in JWS. For example, in the documents proposed by myself and Richard this is not a true statement. Instead the header is UTF8 encoded and that value is processed without having done the ASCII encoding from base64url. It's true of all of the JOSE working group documents. If the working decides to change this, at that point we would, of course, make an appropriate companion change to these statements. 5. I find it confusing to constantly refer to the JWS specification throughout this text. For one thing it makes it harder to refer to these documents for other uses in JSON of these algorithms (such as for an encrypt and MAC algorithm). These defined terms have now been incorporated into this document, per your comment on Section 2, so there should be no longer any need to refer to the JWS spec to understand this section. [JLS] That does not address my concern. If you do a combo HMAC and encrypt algorithm are you going to suddenly turn the header and content into a JWS Secured Input? (And do they suddenly become US ASCII strings?) Actually, I suspect that the JWS Secured Input would be the concatenation of the header, encrypted key, and ciphertext, just as is done now, assuming that a JWS-based computation is done within the composite algorithm to compute the JWE Integrity Value. There's actually nothing about the JWS computation that requires that the secured value is ASCII; by the point the HMAC computation is done, the secured input is a byte array. (The text about "bytes of the ASCII representation of." is about how to create the byte values for that array, given the particular choices in the current specifications.) Is there are particular wording change that you'd suggest that doesn't change the semantics of the specifications, but would be easier for developers to understand? [JLS2] My point is that you can write all of this text purely in terms of - this is the input that you are dealing with. I don't care what the input is or where it came from, this is the input value. This is the output value. Based on the input value you get this output value by doing this. Again - I don't care what the using specification calls these fields because it does not matter in terms of implementing the crypto function that does algorithm FOO. Section 3.4 4. I have never see the R,S pair be referred to as a point before. I believe it is just an ordered pair of integers and not a point on the field. The "point" terminology is used by XML DSIG 2.0, at least about the (x, y) pair. See http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124/#sec-ECKeyValue. I could be wrong that (R, S) are also a point, but given that the P-521 signature is a pair of 521-bit integers, it sure seems like it is. Any ECDSA experts care to weigh in? [JLS] A fast review of the algorithm on Wikipedia confirms what I was thinking. The value of R is obtained from a point on the field (using just k) and the value S is then computed from the value of x and the hash value. This means that (r,s) is not a point on the field. OK, I'll reword. Thanks for the research. Section 3.6 1. I don't see the purpose of the last paragraph in this section. It has nothing to do with algorithms. This subsection is not only about algorithms - it's about extensions to JWS, the parameters registry for which is also in the JWA spec because it's shared between JWS and JWE. The first and second paragraphs of this subsection is about extensions via algorithms and has a reference to that JWA registry. The third paragraph is about extensions via parameters, and has a reference to that JWA registry. Not that 3.6 is parallel to 4.11 which has the same content for JWEs. All that being said, I'd be open to a different editorial structuring, if someone wants to make an alternative proposal. Section 4.5 1. RSA-OAEP is under specified. There are a number of parameters for OAEP that must be defined to go with it. These include the mask function and a hash function. Look at RFC 3447 for the details. This is now fully specified. The description now reads: RSA using Optimal Asymmetric Encryption Padding (OAEP), as defined in RFC 3447, with the default parameters specified by RFC 3447 in Section A.2.1 [JLS] It is strongly recommended that the hash function for OAEP and the hash function for the content be the same values. Additionally, why would we recommend using SHA1 for any of these parameters given that it is not recommended for any other purpose? This has to do with the working group's goal of having developers actually be able to deploy the resulting specification. Using the .NET Framework as an example (because it's one that I'm familiar with), the RSA encryption choices available are PKCS 1-1.5 and OAEP with the default parameters. A .NET JWE implementation would be extremely difficult if we stray from what's actually deployed. If you look at PHP, Ruby, Python, OpenSSL, MacOS, Android, iOS, Windows Phone, etc. as actually deployed, you'll find similar limitations. (In fact, you will not find OAEP support at all on some of these developer platforms.) We could delete OAEP entirely on that basis if the working group chooses, or make it DEPRECATED, rather than OPTIONAL, but I don't believe that defining variants using non-default parameters would be useful, given that they couldn't be used on most development platforms. On a related note, some colleagues and I have started to gather data on what JWA algorithms are implemented on what development platforms. I'll send a separate note shortly requesting presentation time during the meeting to discuss and help refine the data that we've gathered. [JLS2] I think that defining the set of algorithms based on the fact that Microsoft does not have people who understand what is necessary for crypto code is probably a bad idea. If we go with what is deployed then we should not do OAEP and just have RSA v1.5 anyway since as you stated there is not universal deployment of OAEP anyway. Section 4.6 2. I strongly disagree with setting OtherInfo parameters to be empty. We need to define and fill in the AlgorithmId at a minimum. Note that this can be an implicit computation and does not need to be carried as extra data. At a minimum I would suggest something along the lines of JOSE-### where ### is the number of bits to get generated. Per my response to Sean's related comment, it's not clear to me what additional value these parameters add in our usage of the algorithm. If we believe that the content master key is undeterminable by an attacker (a requirement for any security at all!) then adding a constant AlgorithmID to the computation I don't believe changes the security properties. (That being said, we *could* use the "alg" value "ECDH-ES" as the AlgorithmID if people felt better about doing this.) Also given that the text now says (per your previous comment) that "A new epk (ephemeral public key) value MUST be generated for each key agreement transaction", it's not clear that adding parameters identifying the participating parties adds any security value either. That being said, I'd be glad to learn why I'm wrong. If there are good security reasons for requiring PartyUInfo and PartyVInfo values, do you have suggestions on how to create acceptable values without carrying more parameters in the header? (I've already suggested that we could use the "alg" value "ECDH-ES" as the AlgorithmID, which wouldn't require more parameters.) For instance, I don't want to blindly follow XML ENC's lead and punt the issue by requiring that conforming uses provide explicit PartyUInfo and PartyVInfo values. Finally, I'll note that the KDF function used by TLS http://tools.ietf.org/html/rfc5246#section-5 uses no party parameters. Why do we need them then? [JLS] The object of having the algorithm identifier be present is to make sure that if you are doing two kdfs from the same key pairs for different purposes that they will never end up generating the same key values (or a prefix of the same key values). While it is not immediate obvious that this is going to be possible with the JOSE documents, it is a known security issue and one that is easily addressed. One way would be as I suggested above and used a string with the number of bits. Another way would be to use the algorithm that the key is going to be used for (which is how it is defined). Thus this should be the ACUTAL content encryption algorithm used (i.e. AES128GW or AES128CBC+HS256). I suspect that using the concatenation of the "enc" and "int" values as the AlgorithmID, as you suggest above, is the right solution when doing Key Derivation. This is already on the Open Issues list to discuss on the mailing list and in Vancouver. At this point I now would say that the KDF MUST have the ability to have a PartyUInfo value specified. When the KDF was implicit in the key agreement algorithm tag it did not matter. At that point if someone defined a new static-static version of ECDH then they would be required to define what KDF function was to be used and could then require that the PartyUInfo field be defined in the KDF function that required. As it stands now, the KDF is no longer tied to the key agreement algorithm and must therefore meet the necessary security requirements for a static-static version of DH as well as the ephemeral static versions. (On the other hand it still may be implicit, but this was not completely obvious as there is a kdf function that would be used in some cases leading to a confusion about what the kdf function was actually being used for.) Key Agreement and Key Derivation are different cases. In the case of Key Agreement, the KDF *is* tightly bound to the algorithm definition. See the definition of "ECDH-ES" in http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-03#section-4. 1. Note also that use of a unique random ephemeral public key is required, so unless your keygen algorithm is broken, there's no chance of generating the same derived keys. I believe it's already clear in http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-03#section-4. 1.4 that the "kdf" member is used in the Key Derivation case - not the Key Agreement case. But we can tighten this language further, if you'd like to suggest better wording. For TLS, both the PartyUInfo and the PartyVInfo values are present and used when computing the key from the master secret. Since they are present at that point they do not need to be present when computing the master secret itself. When using TLS to compute other secrets - such as a TLS Unque value, the equivalent of the algorithm ID is used at that point to make sure that all such keys computed are going to be unique to that purpose. I believe you're discussing the Key Derivation case in the above paragraph. Again, I think that using the concatenation of the "enc" and "int" values as the AlgorithmID may be the right outcome for Key Derivation. But just as in the Key Agreement case, given that a unique random CMK value MUST be used, there's no chance of generating the same derived keys for other parties, unless the keygen algorithm generates duplicate keys (in which case you have bigger problems). That being said, if there's a way of utilizing PartyUInfo and PartyVInfo values in the KDF computation that doesn't involve carrying them as additional header parameter values, I'd certainly personally be open to that as well. Section 4.11 1. for last paragraph see comment on 3.6 Same response as for 3.6 Section 6.1 1. I would move this registry to either the signature or encryption documents and not put it here. What does this document populate it with? Done Section 6.2 1. Make life easy for IANA and me - create a table of the values Done both here and in the other documents [JLS] What is the purpose of putting the Implementation Requirements into the table? Different applications may have different requirements and these requirements may change over time. It does not make sense to require the table to be updated every time the set of requirements change. The only exception to that might be an obsoleted or do not use field, but even that can be somewhat iffy. Sean Turner had suggested this. Apparently it is done in other specifications and registries. (Examples, Sean?) It's certainly easier for implementers to understand, because they'll always be able to count on the registry's implementation status to be up to date. This can change, for instance, as algorithms move from OPTIONAL to RECOMMENDED to REQUIRED, or when they move from any of those states to DEPRECATED. [JLS2] OK - I note that he asked the question about this, but I don't really see any recommendation that it be done. Section 6.3 1. This registry should be in either the encryption or signature draft Done - now in JWS Section 6.4 1. This registry should be in the JWK document Done Section 6.5 1. Make life easy for IANA and me - create a table of the values Done both here and in the other documents ------=_NextPart_000_00F9_01CD6118.16D3C8A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From:= = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Friday, = July 13, 2012 2:21 PM
To: Jim Schaad
Cc: = jose@ietf.org
Subject: RE: Comments on = draft-ietf-jose-json-web-algorithms-02

<= p class=3DMsoNormal> 

Responses inline…

 

From:= = Jim Schaad [mailto:ietf@augustcellar= s.com]
Sent: Sunday, July 08, 2012 10:16 PM
To: = Mike Jones
Cc: jose@ietf.org
Subject: RE: = Comments on = draft-ietf-jose-json-web-algorithms-02

<= p class=3DMsoNormal> 

Responses to previous comments and some new = comments.

 

 

Open issue feedback = – Do AES ECB – no

 

 

From:= = Mike Jones [mailto:Michael.Jone= s@microsoft.com]
Sent: Friday, July 06, 2012 10:41 = AM
To: 'Jim Schaad'
Cc: jose@ietf.org
Subject: RE: = Comments on = draft-ietf-jose-json-web-algorithms-02

<= p class=3DMsoNormal> 

Thanks for taking the time to provide the = detailed feedback.  Responses inline…

 

-----Original Message-----
From: Jim Schaad [mailto:ietf@augustcellar= s.com]
Sent: Monday, May 21, 2012 3:46 PM
To: Mike = Jones
Cc: jose@ietf.org
Subject: Comments on = draft-ietf-jose-json-web-algorithms-02

 

Here = are comments this document

 

Abstract

 

1.  Since I called it out for JWK I will make = the comment that I do not have a problem with enumerate in this = document.

 

Noted

 

[JLS] On the other = had since you said it was addressed in the mail for the JWK document and = it is not changed I do have a problem there.

 

Saying in the JWK = feedback that it was addressed in JWA was a typo in my e-mail on my = part.  I intentionally did not change away from the word = “enumerates” in JWA both since you said that you = *didn’t* have a problem with it, and because I believe it = accurately conveys what the JWA document does.  But I’d be = open to an alternative description if you’d like to supply wording = that’s even clearer.

 

Section 1

 

1.  Just a comment - I am not sure why you = feel the name to create a specific acronym for this document but it does = not really matter.

 

It provides a = shorthand name to refer to this document from = others.

 

2.  Need to expand JSON if you are going to = use it.

 

Not done here, = because the word “JSON” here is used as part of a name, = rather than as a reference to a specification or kind of data = structure.  I did expand it the first time it is used to refer to = the RFC 4627 data structures, in all the = documents.

 

[JLS]  The rules = state that it is to be expanded on the first use.  If it is not = done on the first use then the RFC editor will do so.  It should be = ok in the key document since it is done almost immediately after the = first use.  As it currently stands it does not follow this = rule.

 

How would adding a = sentence like this work for you?

“All these = specifications utilize JavaScript Object Notation (JSON) [RFC4627] based = data structures.”

 

[JLS2] that would = address the problem.

 

3.  New paragraph for sentence starting with = "Enumerating..."  Separate justification from what this = document does and hash.

 

Done

 

4.  Move last sentence to the end of the first = paragraph

 

Done

 

Section 2

 

1.  In general I would like to see this = duplicated into this document.

Readers should not have to reference another = document for this purpose.

 

Done

 

[JLS] However only = the relevant terms should be included.  If JWE Ciphertext is never = used then it does not need to be included at this = point.

 

Agreed.  I = already did a pass and removed unused terms.  In the example of JWE = Ciphertext, this term is used in the definition of JWE Header, which is = used in the body of the specification, and so is necessary.  If you = find some that are not used directly or indirectly, please point them = out, and I’ll remove them.

 

Section 3.1

 

1.  I am not overly happy with the existence = of a "none" algorithm.  Does it really need to = exist?

 

Yes.  It is = already widely used in contexts where content can be either signed or = plaintext.  And while it used to be defined in JWT, you’d = earlier suggested that it be moved here, since it is of broader = applicability than just JWTs.

 

[JLS] I don’t = disagree with it being here rather than in the JWT document.  = However there is a question if it would be better represented as having = an absent alg parameter rather than having a “none” = algorithm.  It would accomplish the same thing and be less = suggested if an actual signature/MAC algorithm existing on the = document.

 

The due diligence = that users of  “alg”:“none” have to perform = is actually no less than the due diligence that they have to apply when = using any other “alg” value.  At some future time, for = instance, if HMAC SHA-256 is broken, then using “HS256” = would be arguably be worse than using “none”, because = “HS256” might provide the illusion of security, where in = fact, there would be none – sort of like if someone were to = propose to use “HMD5” now.  That there’s no = security is at least apparent with “none”. J

 

Algorithms must = always be used that are security-appropriate given the needs of the = application in the particular context and the current state of = cryptography/cryptanalysis.  Having a “none” algorithm = doesn’t change that.

 

[JLS] I would = disagree based on past history.  But will no press the = issue,

 

Section 3.2

 

1.  You may want to reference RFC4231 as = well.  It contains test vectors and such for the SHA2 = HMACs

 

If this spec were = about implementing the SHA2 HMAC algorithms, I would agree, but since = it’s only about using them, I don’t think this reference is = necessary.  Feel free to push back on this, = however…

 

3.  I have not yet read the updated JWS = document, but I do worry about the fact that this document is saying = that the output should be base64url encoded.  If the JWS document = says the same thing injudiciously then one could easily see that people = might double encode the result.

 

I don’t think = there’s a problem, as both documents make a clear distinction = between the “JWS Signature” value and the “Encoded JWS = Signature” value, and are careful to use the right term in the = right place.  (But obviously send me corrections if you find a = place where the wrong term is used.)

 

4.  I have a real problem with people saying = that UTF-8 and ASCII are the same.  They aren't and saying that = they are does not make it so.

 

They actually are the = same in this case, since the JWS Secured Input consists of only 7-bit = ASCII characters (since they contain only base64url encoded content and = periods characters) that are represented the same in both = encodings.  But I agree that the previous text was potentially = confusing and overly verbose.  The text now only uses the phrase = “the ASCII representation of the JWS Secured Input”, both = here, and in the JWS spec.

 

[JLS] Do you know = this to be a true statement for all future encodings of JWS values as = oppose to the current one that is defined in JWS.  For example, in = the documents proposed by myself and Richard this is not a true = statement.  Instead the header is UTF8 encoded and that value is = processed without having done the ASCII encoding from = base64url.

 

It’s true of = all of the JOSE working group documents.  If the working decides to = change this, at that point we would, of course, make an appropriate = companion change to these statements.

 

5.  I find it confusing to constantly refer to = the JWS specification throughout this text.  For one thing it makes = it harder to refer to these documents for other uses in JSON of these = algorithms (such as for an encrypt and MAC algorithm).

 

These defined terms = have now been incorporated into this document, per your comment on = Section 2, so there should be no longer any need to refer to the JWS = spec to understand this section.

 

[JLS] That does not = address my concern.  If you do a combo HMAC and encrypt algorithm = are you going to suddenly turn the header and content into a JWS Secured = Input? (And do they suddenly become US ASCII = strings?)

 

Actually, I suspect = that the JWS Secured Input would be the concatenation of the header, = encrypted key, and ciphertext, just as is done now, assuming that a = JWS-based computation is done within the composite algorithm to compute = the JWE Integrity Value.  There’s actually nothing about the = JWS computation that requires that the secured value is ASCII; by the = point the HMAC computation is done, the secured input is a byte = array.  (The text about “bytes of the ASCII representation = of…” is about how to create the byte values for that array, = given the particular choices in the current = specifications.)

 

Is there are = particular wording change that you’d suggest that doesn’t = change the semantics of the specifications, but would be easier for = developers to understand?

 

[JLS2]  My point = is that you can write all of this text purely in terms of -  this = is the input that you are dealing with.  I don’t care what = the input is or where it came from, this is the input value.  This = is the output value.  Based on the input value you get this output = value by doing this.  Again – I don’t care what the = using specification calls these fields because it does not matter in = terms of implementing the crypto function that does algorithm = FOO.

 

Section 3.4

 

4.  I have never see the R,S pair be referred = to as a point before.  I believe it is just an ordered pair of = integers and not a point on the field.

 

The = “point” terminology is used by XML DSIG 2.0, at least about = the (x, y) pair.  See http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124/#sec-ECKeyValue.  I could be wrong that (R, S) are = also a point, but given that the P-521 signature is a pair of 521-bit = integers, it sure seems like it is.  Any ECDSA experts care to = weigh in?

 

[JLS] A fast review = of the algorithm on Wikipedia confirms what I was thinking.  The = value of R is obtained from a point on the field  (using just k) = and the value S is then computed from the value of x and the hash = value.  This means that (r,s) is not a point on the field. =

 

OK, I’ll = reword.  Thanks for the research.

 

Section 3.6

 

1.  I don't see the purpose of the last = paragraph in this section.  It has nothing to do with = algorithms.

 

This subsection is = not only about algorithms – it’s about extensions to JWS, = the parameters registry for which is also in the JWA spec because = it’s shared between JWS and JWE.  The first and second = paragraphs of this subsection is about extensions via algorithms and has = a reference to that JWA registry.  The third paragraph is about = extensions via parameters, and has a reference to that JWA = registry.  Not that 3.6 is parallel to 4.11 which has the same = content for JWEs.

 

All that being said, = I’d be open to a different editorial structuring, if someone wants = to make an alternative proposal.

 

Section 4.5

 

1.  RSA-OAEP is under specified.  There = are a number of parameters for OAEP that must be defined to go with = it.  These include the mask function and a hash function.  = Look at RFC 3447 for the details.

 

This is now fully = specified.  The description now reads:  RSA using Optimal = Asymmetric Encryption Padding (OAEP), as defined in RFC 3447, with the = default parameters specified by RFC 3447 in Section = A.2.1

 

[JLS] It is strongly = recommended that the hash function for OAEP and the hash function for = the content be the same values.  Additionally, why would we = recommend using SHA1 for any of these parameters given that it is not = recommended for any other purpose?

 

This has to do with = the working group’s goal of having developers actually be able to = deploy the resulting specification.  Using the .NET Framework as an = example (because it’s one that I’m familiar with), the RSA = encryption choices available are PKCS 1-1.5 and OAEP with the default = parameters.  A .NET JWE implementation would be extremely difficult = if we stray from what’s actually deployed.

 

If you look at PHP, = Ruby, Python, OpenSSL, MacOS, Android, iOS, Windows Phone, etc. as = actually deployed, you’ll find similar limitations.  (In = fact, you will not find OAEP support at all on some of these developer = platforms.)

 

We could delete OAEP = entirely on that basis if the working group chooses, or make it = DEPRECATED, rather than OPTIONAL, but I don’t believe that = defining variants using non-default parameters would be useful, given = that they couldn’t be used on most development = platforms.

 

On a related note, = some colleagues and I have started to gather data on what JWA algorithms = are implemented on what development platforms.  I’ll send a = separate note shortly requesting presentation time during the meeting to = discuss and help refine the data that we’ve = gathered.

 

[JLS2] I think that = defining the set of algorithms based on the fact that Microsoft does not = have people who understand what is necessary for crypto code is probably = a bad idea.  If we go with what is deployed then we should not do = OAEP and just have RSA v1.5 anyway since as you stated there is not = universal deployment of OAEP anyway.

 

Section 4.6

 

2.  I strongly disagree with setting OtherInfo = parameters to be empty.   We

need to define and fill in the AlgorithmId at a = minimum.  Note that this can be an implicit computation and does = not need to be carried as extra data.

At a minimum I would suggest something along the = lines of JOSE-### where ### is the number of bits to get = generated.

 

Per my response to = Sean’s related comment, it's not clear to me what additional value = these parameters add in our usage of the algorithm.  If we believe = that the content master key is undeterminable by an attacker (a = requirement for any security at all!) then adding a constant AlgorithmID = to the computation I don't believe changes the security = properties.  (That being said, we *could* use the “alg” = value "ECDH-ES" as the AlgorithmID if people felt better about = doing this.)

 

Also given that the = text now says (per your previous comment) that "A new epk = (ephemeral public key) value MUST be generated for each key agreement = transaction", it's not clear that adding parameters identifying the = participating parties adds any security value either.  That being = said, I'd be glad to learn why I'm wrong.

 

If there are good = security reasons for requiring PartyUInfo and PartyVInfo values, do you = have suggestions on how to create acceptable values without carrying = more parameters in the header?  (I've already suggested that we = could use the “alg” value "ECDH-ES" as the = AlgorithmID, which wouldn't require more = parameters.)

 

For instance, I don't = want to blindly follow XML ENC's lead and punt the issue by requiring = that conforming uses provide explicit PartyUInfo and PartyVInfo = values.

 

Finally, I'll note = that the KDF function used by TLS http://tools.ietf.o= rg/html/rfc5246#section-5 uses no party parameters.  Why do we = need them then?

 

[JLS] The object of = having the algorithm identifier be present is to make sure that if you = are doing two kdfs from the same key pairs for different purposes that = they will never end up generating the same key values (or a prefix of = the same key values).   While it is not immediate obvious that = this is going to be possible with the JOSE documents, it is a known = security issue and one that is easily addressed.  One way would be = as I suggested above and used a string with the number of bits.  = Another way would be to use the algorithm that the key is going to be = used for (which is how it is defined).  Thus this should be the = ACUTAL content encryption algorithm used (i.e. AES128GW or = AES128CBC+HS256).

 

I suspect that using = the concatenation of the “enc” and “int” values = as the AlgorithmID, as you suggest above, is the right solution when = doing Key Derivation.  This is already on the Open Issues list to = discuss on the mailing list and in Vancouver.

 

At this point I now = would say that the KDF MUST have the ability to have a PartyUInfo value = specified.  When the KDF was implicit in the key agreement = algorithm tag it did not matter.  At that point if someone defined = a new static-static version of ECDH then they would be required to = define what KDF function was to be used and could then require that the = PartyUInfo field be defined in the KDF function that required.  As = it stands now, the KDF is no longer tied to the key agreement algorithm = and must therefore meet the necessary security requirements for a = static-static version of DH as well as the ephemeral static = versions.  (On the other hand it still may be implicit, but this = was not completely obvious as there is a kdf function that would be used = in some cases leading to a confusion about what the kdf function was = actually being used for.)

 

Key Agreement and Key = Derivation are different cases.  In the case of Key Agreement, the = KDF *is* tightly bound to the algorithm definition.  See the = definition of “ECDH-ES” in http://tools.ietf.org/html/draft-ietf-jose-json-web-algorit= hms-03#section-4.1.  Note = also that use of a unique random ephemeral public key is required, so = unless your keygen algorithm is broken, there’s no chance of = generating the same derived keys.

 

I believe it’s = already clear in http://tools.ietf.org/html/draft-ietf-jose-json-web-encry= ption-03#section-4.1.4 that the “kdf” member is used in = the Key Derivation case – not the Key Agreement case.  But we = can tighten this language further, if you’d like to suggest better = wording.

 

For TLS, both the = PartyUInfo and the PartyVInfo values are present and used when computing = the key from the master secret.  Since they are present at that = point they do not need to be present when computing the master secret = itself.   When using TLS to compute other secrets – such = as a TLS Unque value, the equivalent of the algorithm ID is used at that = point to make sure that all such keys computed are going to be unique to = that purpose.

 

I believe = you’re discussing the Key Derivation case in the above = paragraph.  Again, I think that using the concatenation of the = “enc” and “int” values as the AlgorithmID may be = the right outcome for Key Derivation.  But just as in the Key = Agreement case, given that a unique random CMK value MUST be used, = there’s no chance of generating the same derived keys for other = parties, unless the keygen algorithm generates duplicate keys (in which = case you have bigger problems).

 

That being said, if = there’s a way of utilizing PartyUInfo and PartyVInfo values in the = KDF computation that doesn’t involve carrying them as additional = header parameter values, I’d certainly personally be open to that = as well.

 

Section 4.11

 

1.  for last paragraph see comment on = 3.6

 

Same response as for = 3.6

 

Section 6.1

 

1.  I would move this registry to either the = signature or encryption documents and not put it here.  What does = this document populate it with?

 

Done

 

Section 6.2

 

1.  Make life easy for IANA and me - create a = table of the values

 

Done both here and in = the other documents

 

[JLS] What is the = purpose of putting the Implementation Requirements into the table?  = Different applications may have different requirements and these = requirements may change over time.  It does not make sense to = require the table to be updated every time the set of requirements = change.  The only exception to that might be an obsoleted or do not = use field, but even that can be somewhat iffy.

 

Sean Turner had = suggested this.  Apparently it is done in other specifications and = registries.  (Examples, Sean?)  It’s certainly easier = for implementers to understand, because they’ll always be able to = count on the registry’s implementation status to be up to = date.  This can change, for instance, as algorithms move from = OPTIONAL to RECOMMENDED to REQUIRED, or when they move from any of those = states to DEPRECATED.

 

[JLS2] OK – I = note that he asked the question about this, but I don’t really see = any recommendation that it be done.

 

Section 6.3

 

1.  This registry should be in either the = encryption or signature draft

 

Done – now in = JWS

 

Section 6.4

 

1.  This registry should be in the JWK = document

 

Done

 

Section 6.5

 

1.  Make life easy for IANA and me - create a = table of the values

 

Done both here and in = the other documents

 

------=_NextPart_000_00F9_01CD6118.16D3C8A0-- From Michael.Jones@microsoft.com Fri Jul 13 17:29:33 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D90B21F857D for ; Fri, 13 Jul 2012 17:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.807 X-Spam-Level: X-Spam-Status: No, score=-3.807 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27z7-EeQM90b for ; Fri, 13 Jul 2012 17:29:19 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id F020721F8579 for ; Fri, 13 Jul 2012 17:29:18 -0700 (PDT) Received: from mail152-ch1-R.bigfish.com (10.43.68.244) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.23; Sat, 14 Jul 2012 00:29:55 +0000 Received: from mail152-ch1 (localhost [127.0.0.1]) by mail152-ch1-R.bigfish.com (Postfix) with ESMTP id 9E88D4404EE; Sat, 14 Jul 2012 00:29:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz9371Ic85fh148cI542M1418Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail152-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail152-ch1 (localhost.localdomain [127.0.0.1]) by mail152-ch1 (MessageSwitch) id 1342225793467396_14616; Sat, 14 Jul 2012 00:29:53 +0000 (UTC) Received: from CH1EHSMHS007.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.231]) by mail152-ch1.bigfish.com (Postfix) with ESMTP id 700E52E0044; Sat, 14 Jul 2012 00:29:53 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 14 Jul 2012 00:29:53 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0298.005; Sat, 14 Jul 2012 00:29:51 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: Comments on draft-ietf-jose-json-web-key-02 Thread-Index: Ac1bnR9r6ocLDUY1SjuKsbPs53w7OABv8OOAAPOzazAACUECAAAAeKZQ Date: Sat, 14 Jul 2012 00:29:51 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436672BD8E@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366579F15@TK5EX14MBXC283.redmond.corp.microsoft.com> <002301cd5d5c$e36edb80$aa4c9280$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436672B792@TK5EX14MBXC285.redmond.corp.microsoft.com> <00f001cd6150$b7049060$250db120$@augustcellars.com> In-Reply-To: <00f001cd6150$b7049060$250db120$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436672BD8ETK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Comments on draft-ietf-jose-json-web-key-02 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 00:29:33 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436672BD8ETK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [mbj2] Additional responses... From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Friday, July 13, 2012 4:39 PM To: Mike Jones Cc: jose@ietf.org Subject: RE: Comments on draft-ietf-jose-json-web-key-02 Additional Notes From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, July 13, 2012 2:20 PM To: Jim Schaad Cc: jose@ietf.org Subject: RE: Comments on draft-ietf-jose-json-web-key-02 Responses inline... From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Sunday, July 08, 2012 3:56 PM To: Mike Jones Cc: jose@ietf.org Subject: RE: Comments on draft-ietf-jose-json-web-key-02 Comments on responses and some additional comments as well. If the security sections references the XML DSig document as having importa= nt security considerations, then it needs to be normative and not informati= ve. Will do Jim From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, July 06, 2012 10:31 AM To: Jim Schaad Cc: jose@ietf.org Subject: RE: Comments on draft-ietf-jose-json-web-key-02 Thanks for taking the time to provide the detailed feedback. Responses inl= ine... -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Saturday, May 19, 2012 3:34 PM To: Mike Jones Cc: jose@ietf.org Subject: Comments on draft-ietf-jose-json-web-key-02 My apologies for introducing you to the term algorithm families. We don't = use it in the same way and thus I think that you should generally remove it= from the text. To me it is a very wide term and somewhat nebulous. Thus = I think of all of the DH algorithms as being in a family - but that family = could also include the ECDH algorithm as well as DSA depending on how one i= s using it. Thus for me an algorithm family is not restricted to a specifi= c instance (or small set of instances) such a DH & DSA but could be as larg= e as all key agreement algorithms. As such it does not really match how you are using it in much of the text. Left in for the current draft for lack of a better term. I did remove as m= any uses of the term as possible. Slightly more detailed: You can define an RSA key You can define an RSA-OAEP key The second one has all of the fields of the first, however it may have addi= tional fields defined that deal specifically with RSA-OAEP. The difference= is going to be a question of restriction of usage of the key to a single a= lgorithm vs allowing for all RSA algorithms. Parameters could be defined in the JWA spec to specify parameters enabling = those possible restrictions if the working group deems it useful/necessary.= The JWK spec already makes it clear that algorithm-specific parameters ma= y be required, so this wouldn't change the model. Here are some more comments Abstract 1. I am not a fan of the word enumerated in the last sentence. This word = implies to me that the list is not expandable. I would recommend something= along the lines of "An initial set of ... can be found in ..." Done here, plus in JWE, JWS, JWA, JWE-JS, and JWS-JS [JLS] This change was not made in the JWA document. Correct, because you wrote "I do not have a problem with enumerate in this = document" in your May 21st message on JWA. I made a typo when I wrote that= I applied it to JWA above. (Also, I actually think that in JWA, the word = "enumerates" works well.) [JLS2] I did not re-read the note on the alg document until after I finishe= d this review. I agreed in the other message that it did not need to be c= hanged, but I was going based on the comment in this message. It is not a = problem. Section 2 1. The phrase "For the purpose of this document" should be removed unless = this term is used in other ways elsewhere. Not changed, because in some other contexts, the same term is used to refer= to the non URL safe encoding. [JLS] Is it used in a different way in this document? One can automatical= ly assumed that if you are defining a term, that it is for the purposes of = this document and, unless generally accepted, is not applicable to other do= cuments. Purely for curiosity, where is the phrase base64url encoding used to mean s= omething else in a different document? OK, I'll delete the phrase. The term "base64 encoding" often (usually) mea= ns something different, but not the term "base64url encoding". Section 4 1. In para #2 - the use of "algorithm family" is incorrect. They members = are going to be required for the specific key being represented not to the = family - consider the case of RSA and RSA-OAEP - these are both in the same= family, but the fields required are different. Reworded to not use the term "algorithm family" [JLS] Suggest "In addition to the common parameters, each JWK will have m= embers that are specific to the key being represented. These members repre= sent the parameters of the key. Section 5 of the JSON Web Algorithm (JWA)= specifies a number of public keys and their associated members." Good 2. Do you believe that all of the algorithm members are defined in the JWA document - or only for some algorithms. Text should probably say they are defined for the algorithms defined for the algorithms in JWA. Done 3. I don't believe that para #3 is enforceable by parsers as they have bee= n presented to me. Please prove me wrong. Section 2.2 of http://tools.ietf.org/html/rfc4627 says "The names within an= object SHOULD be unique." So this should be enforced by conforming parser= s. I'd be interested in data saying that parsers exist that are non-confor= ming to this RFC 4627 "SHOULD". If so, we should add appropriate warnings = to the Security Considerations section. [JLS] Stating that they should be unique is more of a requirement on the ge= neration side and not the parsing side of the specification. I do not beli= eve that this statement in way says that parsers should reject objects for = which duplicate member names exist. Parsers that accept input with duplicate member names are violating a SHOUL= D, as I see it. In any event, tightening this to "MUST be unique" is appro= priate in our specs, since I'll grant you that relying on a SHOULD is inapp= ropriate in a security context. If this requires secondary parsing or usin= g a hardened parser to ensure member uniqueness, that's part of the price o= f having a correct implementation. (And consider the alternative - we *rea= lly* don't want to go down the path of having to make statements like "If t= here are multiple "alg" values, then..."!) We started talking about these security considerations at http://tools.ietf= .org/html/draft-ietf-jose-json-web-signature-03#section-8.2. I'll tighten = this up. 4. Let's look at the sentence "If present, they MUST be understood by im= plementations using them." I believe that this is an incorrect assertion. (Not to mention that it is totally uncheckable.) Consider the following situation: Implementation A creates a JWK and files it with Implementation B. A does = not understand the "exist-date" property. Implementation B adds the "exist-date" property and puts it at a URL. Implementation C pulls the JWK from the URL, understand the "exist-date" property. According to the MUST, the JWK cannot be used as it is not understood by al= l of the implementations. The only entity that you can make the requirement on is the consumer. One = assumes that the "provider" would/might understand the field or it would no= t be there but it could have been added in transit and thus that is not the= case. I believe that for your example, the text is correct as written, since in c= ontext, "them" refers to the additional members, not the JWK as a whole. A= t no point in your example did an implementation use a JWK with an addition= al member that it did not understand. [JLS] This is precisely the statement that I made above, the mandating that= the field is understood by consumers of the JWK is possible, but it is not= possible to mandate that all implementations involved in the transaction u= nderstand all of the fields. Maybe we can talk about this in person in Vancouver, because I think I'm st= ill missing something in what you're trying to achieve here. In your examp= le, the JWK created by A and the JWK created by B by adding the "exist-date= " property to A are different JWKs, because they have different fields. At= no point did any party, producer or consumer, use a JWK whose fields it di= d not all understand. (I'll grant you that if A were to use B's JWK, the "= must understand" would be violated, but that's exactly the intent.) [JLS2] So we now have a situation where A publishes, B updates, C encrypts = to the B version and sends to A which then fails the decrypt. [mbj2] Correct. If A doesn't understand the fields of the JWK that it's us= ing, that's the intended outcome. I understand that the assertion may not be enforceable apart from conforman= ce suites that check what implementations do when given new parameters, and= I understand that in the general case, programmatic enforcement would be t= he equivalent of solving the halting problem. That's not an argument, howe= ver, that in security contexts, that having this requirement isn't the righ= t thing to do. [JLS] I have not made an argument for removing it, but for stating that it = is the consumer on which the restriction is placed on not on all implementa= tions. You don't think that's equally important for producers to understand all th= e fields of the JWKs they're producing? [JLS2] What does it mean? Are we talking about the program that publishes = or the program that decrypts? I think that a producing program should not= generate something it cannot consume, but that is different that if we are= talking about a person's system. In this case the production and consumpt= ion programs may be different and have different abilities to understand fi= elds. I would be perfectly willing for producers to be able to publish JWK= s with fields that they do not "understand". [mbj2] The intent is that all programs using any JOSE-specified data struct= ure must understand all of that data structure or reject the input. I unde= rstand that, for extensibility reasons, some may disagree with this require= ment, and we could have that discussion, but I don't think there's anything= ambiguous about the current "must understand" wording. (If there is, plea= se let me know, and I'll tighten it up.) 5. I find the last sentence of para #4 to be unreadable. I would start by= breaking it into two sentences and potentially move the first one into the= JWA document (that about parameters for keys). Simplified [JLS] I think it can be simplified even more. For one thing it is not cle= ar if the member name must be unique between kinds of keys. Thus can you h= ave a "x" for both DH and ECDH (or do they fall into the same family?). Agreed. I'll simplify this further to just say "Member names SHOULD ...". = I'll also add "Member names used for representing key parameters for diffe= rent kinds of keys need not be distinct", per your question about uniquenes= s. [JLS] Given that only fields dealing with either generic items or a specifi= c key are represented in a JWK object. It would make more sense to have th= e restriction on member names than on generic members and not on members th= at are specific to a public key. Agreed - I believe my wording above addresses this. [JLS2] No I don't agree that is true. I asked what I thought was a questio= n about changing the requirements. The current text says that specific mem= bers need to be registered. I asked if we should only require that generic= members be registered. This would be a change in policy which might make = the registry cleaner and easier to maintain, at the cost of some potential = issues way down the road. [mbj2] I would personally prefer that members of both kinds be registered, = in part, so people can go to the registry and find references to all the me= mbers that they can expect to find in a JWK. As you wrote, I think this wi= ll save potential problems down the road. Section 4.1 1. Do you want to point to the JWA document or to the registry for the set = of defined algorithms? Clarified that some names are defined in JWA whereas all names not containi= ng a collision resistant namespace should be registered. [JLS] OK - let me be more pointed in my comment. I think you should point = at the registry and not at the other document for the list of defined algor= ithms. Additionally, I think you should point at the registry for the set = of generic members defined and ignore the set of key specific members defin= ed in this document. OK, I'll reword this (and similar locations) to make the registry be the pr= imary reference and to add, on a secondary basis, that the JWA document pro= vides the initial contents for the registry. (I believe we continue to nee= d the JWA reference to help reviewers of the current specs, especially sinc= e the registry won't be created until the specs are approved as RFCs.) 2. In para #1 I would remove the sentence starting "Specific additional..." as this is not part of the definition of the "alg" parameter and is covered= in section 4.0 Done 3. The last two sentences in para #1 can be combined together. This is just a personal stylistic thing I suppose, but I prefer two short d= eclarative sentences to a conjunction of the two. [JLS] as oppose to "The "alg" value MUST be a case-sensitive string. OK, I agree that that wording's better. I'll make that change where applic= able. Section 4.2 1. Presentation suggestion - if you use a bulleted list for the values it = will be easier to see what the list of defined values is. Done 2. See point #3 in section 4.1 Ditto Section 4.3 1. Is there a requirement that the kid be unique in a JWK Set? I think th= at the answer should be called out in text either way. Good point. Added text saying that it need not be unique, and providing an= example providing rationale for that choice. [JLS] Ok - I see documentation on how to handle the situation if there are= multiple KIDs that have the same value, but I am missing the rationale tha= t you have stated as being present. A rationale would be WHY one would hav= e multiple keys with the same KID value. The rationale was in the "for instance" text. We could beef up the rationa= le if you have better suggested wording. As another example, imagine "kid" values like "Current", "Upcoming", and "D= eprecated", used for key rollover guidance. You could apply that label to = all keys where the classification fits. If there are multiple "Current" ke= ys, then in this example they might be differentiated either by having diff= erent "alg" or "use" values, or some combination of both. (There might onl= y be one current RSASA signing key and one current ECDSA signing key, but b= oth would be "Current".) [JLS2] There is a rational about why there exists a kid field. There is n= ot a rational about why the kids are not a requirement that they be unique.= I don't know that I have a good reason for why the fields should not be u= nique within a single key set. This is the reason for asking for a ration= al to be provided. [mbj2] OK - I can try to add rationale like that above. 2. Is the string case sensitive? It is now. :-) 3. Move the sentence "When used..." to a new paragraph. (suggestion) Done Section 6.1 1. Please make things easy for IANA - create a table with the fields across= the top and the values down the table. This will allow them to do their j= ob without having to go through the entire document and for us to be able t= o easily validate that they got it correct. Done here, plus in JWA and JWT [JLS] Section 6.1.1 - Under the Parameter Name: field, you should have a no= te for IANA that the name is case-sensitive and have a comment that names t= hat match in a case-insensitive manner SHOULD or SHOULD NOT be accepted. (C= opy note to all of the reset of the tables as well). Will do (with SHOULD NOT) [JLS] Section 6.1.1 - are there any longevity requirements on the URI that = is specified? If we refer to an RFC then we know that it will "always" exi= st. This is not necessarily true if one refers to a document on a personal= website. Is there best-practice text on this issue that anyone is aware of that we c= an reuse? (The current text is reused from the OAuth Core spec, which has = already undergone IETF last call, and so seemed like a good place to start = from.) [JLS2] This is a think question and not a requirement to change the documen= t. Section 6.2 1. Please put in a registration section for the items you are registering i= n Section 4 in the JWK table. You can refer to JWA for creation of the tab= le. Done here, plus in JWS, JWE, JWA, and JWT Appendix A 1. I am not sure why this appendix is in this document. To give credit to the inventors of the precursor spec that resulted in the = JWK spec. I've added their names to make this intent clearer. --_000_4E1F6AAD24975D4BA5B16804296739436672BD8ETK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[mbj2] Additional resp= onses…

 

From: Jim Scha= ad [mailto:ietf@augustcellars.com]
Sent: Friday, July 13, 2012 4:39 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: RE: Comments on draft-ietf-jose-json-web-key-02<= /span>

 

Additional Notes<= /o:p>

 

From: Mike Jon= es [mailto:Michael.Jon= es@microsoft.com]
Sent: Friday, July 13, 2012 2:20 PM
To: Jim Schaad
Cc: jose@ietf.org
Subject: RE: Comments on draft-ietf-jose-json-web-key-02<= /span>

 

Responses inline…= ;

 

From: Jim Scha= ad [mailto:ietf@augustcella= rs.com]
Sent: Sunday, July 08, 2012 3:56 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: RE: Comments on draft-ietf-jose-json-web-key-02<= /span>

 

Comments on responses = and some additional comments as well.

 

If the security sectio= ns references the XML DSig document as having important security considerat= ions, then it needs to be normative and not informative.<= /p>

 

Will do

 

Jim<= /p>

 

 

From: Mike Jon= es [mailto:Michael.Jon= es@microsoft.com]
Sent: Friday, July 06, 2012 10:31 AM
To: Jim Schaad
Cc: jose@ietf.org
Subject: RE: Comments on draft-ietf-jose-json-web-key-02<= /span>

 

Thanks for taking t= he time to provide the detailed feedback.  Responses inline…

 

-----Original Message-----
From: Jim Schaad [mailto= :ietf@augustcellars.com]
Sent: Saturday, May 19, 2012 3:34 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: Comments on draft-ietf-jose-json-web-key-02

 

<no hat>

 

My apologies for introducing you to the term algo= rithm families.  We don't use it in the same way and thus I think that= you should generally remove it from the text.  To me it is a very wid= e term and somewhat nebulous.  Thus I think of all of the DH algorithms as being in a family - but that family could a= lso include the ECDH algorithm as well as DSA depending on how one is using= it.  Thus for me an algorithm family is not restricted to a specific = instance (or small set of instances) such a DH & DSA but could be as large

as all key agreement algorithms.   As s= uch it does not really match how you

are using it in much of the text.

 

Left in for the cur= rent draft for lack of a better term.  I did remove as many uses of th= e term as possible.

 

Slightly more detailed:

 

You can define an RSA key

You can define an RSA-OAEP key

 

The second one has all of the fields of the first= , however it may have additional fields defined that deal specifically with= RSA-OAEP.  The difference is going to be a question of restriction of= usage of the key to a single algorithm vs allowing for all RSA algorithms.

 

Parameters could be= defined in the JWA spec to specify parameters enabling those possible rest= rictions if the working group deems it useful/necessary.  The JWK spec= already makes it clear that algorithm-specific parameters may be required, so this wouldn’t change the model.<= /o:p>

 

Here are some more comments

 

Abstract

 

1.  I am not a fan of the word enumerated in= the last sentence.  This word implies to me that the list is not expa= ndable.  I would recommend something along the lines of "An initi= al set of ... can be found in ..."

 

Done here, plus in = JWE, JWS, JWA, JWE-JS, and JWS-JS

 

[JLS] This change w= as not made in the JWA document.

 

Correct, because yo= u wrote “I do not have a problem with enumerate in this docume= nt” in your May 21st message= on JWA.  I made a typo when I wrote that I applied it to JWA above.  (Also, I actually think that in JWA, the word ̶= 0;enumerates” works well.)

 

[JLS2] I did not re= -read the note on the alg document until after I finished this review. &nbs= p; I agreed in the other message that it did not need to be changed, b= ut I was going based on the comment in this message.  It is not a problem.

 

Section 2

 

1.  The phrase "For the purpose of this= document" should be removed unless this term is used in other ways el= sewhere.

 

Not changed, becaus= e in some other contexts, the same term is used to refer to the non URL saf= e encoding.

 

[JLS] Is it used in= a different way in this document?   One can automatically assume= d that if you are defining a term, that it is for the purposes of this docu= ment and, unless generally accepted, is not applicable to other documents. 

 

Purely for curiosit= y, where is the phrase base64url encoding used to mean something else in a = different document?

 

OK, I’ll dele= te the phrase.  The term “base64 encoding” often (usually)= means something different, but not the term “base64url encoding̶= 1;.

 

Section 4

 

1.  In para #2 - the use of "algorithm = family" is incorrect.  They members are going to be required for = the specific key being represented not to the family - consider the case of= RSA and RSA-OAEP - these are both in the same family, but the fields required are different.

 

Reworded to not use= the term “algorithm family”

 

[JLS]   S= uggest “In addition to the common parameters, each JWK will have memb= ers that are specific to the key being represented.  These members rep= resent the parameters of the key.   Section 5 of the JSON Web Algorithm (JWA) specifies a number of public keys and their associated= members.”

 

Good

 

2.  Do you believe that all of the algorithm= members are defined in the JWA

document - or only for some algorithms. &nbs= p; Text should probably say they are

defined for the algorithms defined for the algori= thms in JWA.

 

Done

 

3.  I don't believe that para #3 is enforcea= ble by parsers as they have been presented to me.  Please prove me wro= ng.

 

Section 2.2 of http://tools.ietf.org/htm= l/rfc4627 says “The names within an object SHOULD be unique.”&nb= sp; So this should be enforced by conforming parsers.  I’d be in= terested in data saying that parsers exist that are non-conforming to this = RFC 4627 “SHOULD”.  If so, we should add appropriate warni= ngs to the Security Considerations section.

 

[JLS] Stating that = they should be unique is more of a requirement on the generation side and n= ot the parsing side of the specification.  I do not believe that this = statement in way says that parsers should reject objects for which duplicate member names exist.

 

Parsers that accept= input with duplicate member names are violating a SHOULD, as I see it.&nbs= p; In any event, tightening this to “MUST be unique” is appropr= iate in our specs, since I’ll grant you that relying on a SHOULD is inappropriate in a security context.  If this requires= secondary parsing or using a hardened parser to ensure member uniqueness, = that’s part of the price of having a correct implementation.  (A= nd consider the alternative – we *really* don’t want to go down the path of having to make statements like = 220;If there are multiple “alg” values, then…”!)

 

We started talking = about these security considerations at http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-03#section-8.= 2.  I’ll tighten this up.

 

4.  Let's look at the sentence  "I= f present, they MUST  be understood by implementations using them.&quo= t;  I believe that this is an incorrect assertion.

(Not to mention that it is totally uncheckable.)&= nbsp; Consider the following

situation:

 

Implementation A creates a JWK and files it with = Implementation B.  A does not understand the "exist-date" pr= operty.

Implementation B adds the "exist-date" = property and puts it at a URL.

Implementation C pulls the JWK from the URL, unde= rstand the "exist-date"

property.

According to the MUST, the JWK cannot be used as = it is not understood by all of the implementations.

 

The only entity that you can make the requirement= on is the consumer.  One assumes that the "provider" would/= might understand the field or it would not be there but it could have been = added in transit and thus that is not the case.

 

I believe that for = your example, the text is correct as written, since in context, “them= ” refers to the additional members, not the JWK as a whole.  At = no point in your example did an implementation use a JWK with an additional member that it did not understand.

 

[JLS] This is preci= sely the statement that I made above, the mandating that the field is under= stood by consumers of the JWK is possible, but it is not possible to mandat= e that all implementations involved in the transaction understand all of the fields.

 

Maybe we can talk a= bout this in person in Vancouver, because I think I’m still missing s= omething in what you’re trying to achieve here.  In your example= , the JWK created by A and the JWK created by B by adding the “exist-date” property to A are different JWKs, because the= y have different fields.  At no point did any party, producer or consu= mer, use a JWK whose fields it did not all understand.  (I’ll gr= ant you that if A were to use B’s JWK, the “must understandR= 21; would be violated, but that’s exactly the intent.)=

 

[JLS2] So we now ha= ve a situation where A publishes, B updates, C encrypts to the B version an= d sends to A which then fails the decrypt.

 

[mbj2] Correct.&nbs= p; If A doesn’t understand the fields of the JWK that it’s usin= g, that’s the intended outcome.

 

I understand that t= he assertion may not be enforceable apart from conformance suites that chec= k what implementations do when given new parameters, and I understand that = in the general case, programmatic enforcement would be the equivalent of solving the halting problem.  That’s= not an argument, however, that in security contexts, that having this requ= irement isn’t the right thing to do.

 

[JLS] I have not ma= de an argument for removing it, but for stating that it is the consumer on = which the restriction is placed on not on all implementations.

 

You don’t thi= nk that’s equally important for producers to understand all the field= s of the JWKs they’re producing?

 

[JLS2] What does it= mean?  Are we talking about the program that publishes or the program= that decrypts?   I think that a producing program should not gen= erate something it cannot consume, but that is different that if we are talking about a person’s system.  In this case t= he production and consumption programs may be different and have different = abilities to understand fields.  I would be perfectly willing for prod= ucers to be able to publish JWKs with fields that they do not “understand”.

 

[mbj2] The intent i= s that all programs using any JOSE-specified data structure must understand= all of that data structure or reject the input.  I understand that, f= or extensibility reasons, some may disagree with this requirement, and we could have that discussion, but I don’= t think there’s anything ambiguous about the current “must unde= rstand” wording.  (If there is, please let me know, and I’= ll tighten it up.)

 

5.  I find the last sentence of para #4 to b= e unreadable.  I would start by breaking it into two sentences and pot= entially move the first one into the JWA document (that about parameters fo= r keys).

 

Simplified

 

[JLS]  I think= it can be simplified even more.  For one thing it is not clear if the= member name must be unique between kinds of keys.  Thus can you have = a “x” for both DH and ECDH (or do they fall into the same family?).

 

Agreed.  IR= 17;ll simplify this further to just say “Member names SHOULD …&= #8221;.  I’ll also add “Member names used for representing= key parameters for different kinds of keys need not be distinct”, pe= r your question about uniqueness.

 

[JLS] Given that on= ly fields dealing with either generic items or a specific key are represent= ed in a JWK object.  It would make more sense to have the restriction = on member names than on generic members and not on members that are specific to a public key.

 

Agreed – I be= lieve my wording above addresses this.

 

[JLS2] No I donR= 17;t agree that is true.  I asked what I thought was a question about = changing the requirements.  The current text says that specific member= s need to be registered.  I asked if we should only require that generic members be registered.  This would be a change i= n policy which might make the registry cleaner and easier to maintain, at t= he cost of some potential issues way down the road.

 

[mbj2] I would pers= onally prefer that members of both kinds be registered, in part, so people = can go to the registry and find references to all the members that they can= expect to find in a JWK.  As you wrote, I think this will save potential problems down the road.=

 

Section 4.1

 

1. Do you want to point to the JWA document or to= the registry for the set of defined algorithms?

 

Clarified that some= names are defined in JWA whereas all names not containing a collision resi= stant namespace should be registered.

 

[JLS] OK – le= t me be more pointed in my comment.  I think you should point at the r= egistry and not at the other document for the list of defined algorithms.&n= bsp; Additionally, I think you should point at the registry for the set of generic members defined and ignore the set of key specific = members defined in this document.

 

OK, I’ll rewo= rd this (and similar locations) to make the registry be the primary referen= ce and to add, on a secondary basis, that the JWA document provides the ini= tial contents for the registry.  (I believe we continue to need the JWA reference to help reviewers of the current spe= cs, especially since the registry won’t be created until the specs ar= e approved as RFCs.)

 

2. In para #1 I would remove the sentence startin= g "Specific additional..."

as this is not part of the definition of the &quo= t;alg" parameter and is covered in section 4.0

 

Done

 

3.  The last two sentences in para #1 can be= combined together.

 

This is just a pers= onal stylistic thing I suppose, but I prefer two short declarative sentence= s to a conjunction of the two.

 

[JLS] as oppose to = “The “alg” value MUST be a case-sensitive string.<= span style=3D"color:#1F497D">

 

OK, I agree that th= at wording’s better.  I’ll make that change where applicab= le.

 

Section 4.2

 

1.  Presentation suggestion - if you use a b= ulleted list for the values it will be easier to see what the list of defin= ed values is.

 

Done

 

2.  See point #3 in section 4.1

 

Ditto

 

Section 4.3

 

1.  Is there a requirement that the kid be u= nique in a JWK Set?  I think that the answer should be called out in t= ext either way.

 

Good point.  A= dded text saying that it need not be unique, and providing an example provi= ding rationale for that choice.

 

[JLS]  Ok R= 11; I see documentation on how to handle the situation if there are multipl= e KIDs that have the same value, but I am missing the rationale that you ha= ve stated as being present.  A rationale would be WHY one would have multiple keys with the same KID value.

 

The rationale was i= n the “for instance” text.  We could beef up the rationale= if you have better suggested wording.

 

As another example,= imagine “kid” values like “Current”, “Upcomi= ng”, and “Deprecated”, used for key rollover guidance.&nb= sp; You could apply that label to all keys where the classification fits.&n= bsp; If there are multiple “Current” keys, then in this example they might be differentia= ted either by having different “alg” or “use” value= s, or some combination of both.  (There might only be one current RSAS= A signing key and one current ECDSA signing key, but both would be “C= urrent”.)

 

[JLS2]  There = is a rational about why there exists a kid field.  There is not a rati= onal about why the kids are not a requirement that they be unique.  I = don’t know that I have a good reason for why the fields should not be unique within a single key set.   This is the reas= on for asking for a rational to be provided.

 

[mbj2] OK – I= can try to add rationale like that above.

 

2.  Is the string case sensitive?=

 

It is now. :-)=

 

3.  Move the sentence "When used...&quo= t; to a new paragraph.  (suggestion)

 

Done

 

Section 6.1

 

1. Please make things easy for IANA - create a ta= ble with the fields across the top and the values down the table.  Thi= s will allow them to do their job without having to go through the entire d= ocument and for us to be able to easily validate that they got it correct.

 

Done here, plus in = JWA and JWT

 

[JLS] Section 6.1.1= – Under the Parameter Name: field, you should have a note for IANA t= hat the name is case-sensitive and have a comment that names that match in = a case-insensitive manner SHOULD or SHOULD NOT be accepted. (Copy note to all of the reset of the tables as well).

 

Will do (with SHOUL= D NOT)

 

[JLS] Section 6.1.1= – are there any longevity requirements on the URI that is specified?=  If we refer to an RFC then we know that it will “always”= exist.  This is not necessarily true if one refers to a document on a personal website.

 

Is there best-pract= ice text on this issue that anyone is aware of that we can reuse?  (Th= e current text is reused from the OAuth Core spec, which has already underg= one IETF last call, and so seemed like a good place to start from.)

 

[JLS2] This is a th= ink question and not a requirement to change the document.

 

Section 6.2

 

1. Please put in a registration section for the i= tems you are registering in Section 4 in the JWK table.  You can refer= to JWA for creation of the table.

 

Done here, plus in = JWS, JWE, JWA, and JWT

 

Appendix A

 

1.  I am not sure why this appendix is in th= is document.

 

To give credit to t= he inventors of the precursor spec that resulted in the JWK spec.  I&#= 8217;ve added their names to make this intent clearer.

 

--_000_4E1F6AAD24975D4BA5B16804296739436672BD8ETK5EX14MBXC285r_-- From Michael.Jones@microsoft.com Fri Jul 13 17:30:26 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7A021F8634 for ; Fri, 13 Jul 2012 17:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.805 X-Spam-Level: X-Spam-Status: No, score=-3.805 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9H-MNb482Q3s for ; Fri, 13 Jul 2012 17:30:11 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 32A3021F858D for ; Fri, 13 Jul 2012 17:30:10 -0700 (PDT) Received: from mail6-am1-R.bigfish.com (10.3.201.226) by AM1EHSOBE008.bigfish.com (10.3.204.28) with Microsoft SMTP Server id 14.1.225.23; Sat, 14 Jul 2012 00:30:46 +0000 Received: from mail6-am1 (localhost [127.0.0.1]) by mail6-am1-R.bigfish.com (Postfix) with ESMTP id E57453405C3; Sat, 14 Jul 2012 00:30:46 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -33 X-BigFish: VS-33(zz9371I936eIc85fh1454I168aJ148cI542M1418I1447Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail6-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail6-am1 (localhost.localdomain [127.0.0.1]) by mail6-am1 (MessageSwitch) id 1342225844829366_4632; Sat, 14 Jul 2012 00:30:44 +0000 (UTC) Received: from AM1EHSMHS018.bigfish.com (unknown [10.3.201.240]) by mail6-am1.bigfish.com (Postfix) with ESMTP id C728E1C004B; Sat, 14 Jul 2012 00:30:44 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS018.bigfish.com (10.3.207.156) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 14 Jul 2012 00:30:44 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0309.003; Sat, 14 Jul 2012 00:30:41 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: Comments on draft-ietf-jose-json-web-algorithms-02 Thread-Index: Ac1bnm0yDdR4osWGShO4zuEBHYQsVAB84WuAAOhbxxAAB9gZAAAAcbXg Date: Sat, 14 Jul 2012 00:30:40 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436672BDB2@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366579FC3@TK5EX14MBXC283.redmond.corp.microsoft.com> <008701cd5d91$f3cbe740$db63b5c0$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436672B7CD@TK5EX14MBXC285.redmond.corp.microsoft.com> <00f801cd6152$c3299ff0$497cdfd0$@augustcellars.com> In-Reply-To: <00f801cd6152$c3299ff0$497cdfd0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436672BDB2TK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 00:30:26 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436672BDB2TK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [mbj2] Additional responses... From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Friday, July 13, 2012 4:54 PM To: Mike Jones Cc: jose@ietf.org Subject: RE: Comments on draft-ietf-jose-json-web-algorithms-02 From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, July 13, 2012 2:21 PM To: Jim Schaad Cc: jose@ietf.org Subject: RE: Comments on draft-ietf-jose-json-web-algorithms-02 Responses inline... From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Sunday, July 08, 2012 10:16 PM To: Mike Jones Cc: jose@ietf.org Subject: RE: Comments on draft-ietf-jose-json-web-algorithms-02 Responses to previous comments and some new comments. Open issue feedback - Do AES ECB - no From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, July 06, 2012 10:41 AM To: 'Jim Schaad' Cc: jose@ietf.org Subject: RE: Comments on draft-ietf-jose-json-web-algorithms-02 Thanks for taking the time to provide the detailed feedback. Responses inl= ine... -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, May 21, 2012 3:46 PM To: Mike Jones Cc: jose@ietf.org Subject: Comments on draft-ietf-jose-json-web-algorithms-02 Here are comments this document Abstract 1. Since I called it out for JWK I will make the comment that I do not hav= e a problem with enumerate in this document. Noted [JLS] On the other had since you said it was addressed in the mail for the = JWK document and it is not changed I do have a problem there. Saying in the JWK feedback that it was addressed in JWA was a typo in my e-= mail on my part. I intentionally did not change away from the word "enumer= ates" in JWA both since you said that you *didn't* have a problem with it, = and because I believe it accurately conveys what the JWA document does. Bu= t I'd be open to an alternative description if you'd like to supply wording= that's even clearer. Section 1 1. Just a comment - I am not sure why you feel the name to create a specif= ic acronym for this document but it does not really matter. It provides a shorthand name to refer to this document from others. 2. Need to expand JSON if you are going to use it. Not done here, because the word "JSON" here is used as part of a name, rath= er than as a reference to a specification or kind of data structure. I did= expand it the first time it is used to refer to the RFC 4627 data structur= es, in all the documents. [JLS] The rules state that it is to be expanded on the first use. If it i= s not done on the first use then the RFC editor will do so. It should be o= k in the key document since it is done almost immediately after the first u= se. As it currently stands it does not follow this rule. How would adding a sentence like this work for you? "All these specifications utilize JavaScript Object Notation (JSON) [RFC462= 7] based data structures." [JLS2] that would address the problem. 3. New paragraph for sentence starting with "Enumerating..." Separate jus= tification from what this document does and hash. Done 4. Move last sentence to the end of the first paragraph Done Section 2 1. In general I would like to see this duplicated into this document. Readers should not have to reference another document for this purpose. Done [JLS] However only the relevant terms should be included. If JWE Ciphertex= t is never used then it does not need to be included at this point. Agreed. I already did a pass and removed unused terms. In the example of = JWE Ciphertext, this term is used in the definition of JWE Header, which is= used in the body of the specification, and so is necessary. If you find s= ome that are not used directly or indirectly, please point them out, and I'= ll remove them. Section 3.1 1. I am not overly happy with the existence of a "none" algorithm. Does i= t really need to exist? Yes. It is already widely used in contexts where content can be either sig= ned or plaintext. And while it used to be defined in JWT, you'd earlier su= ggested that it be moved here, since it is of broader applicability than ju= st JWTs. [JLS] I don't disagree with it being here rather than in the JWT document. = However there is a question if it would be better represented as having an= absent alg parameter rather than having a "none" algorithm. It would acco= mplish the same thing and be less suggested if an actual signature/MAC algo= rithm existing on the document. The due diligence that users of "alg":"none" have to perform is actually n= o less than the due diligence that they have to apply when using any other = "alg" value. At some future time, for instance, if HMAC SHA-256 is broken,= then using "HS256" would be arguably be worse than using "none", because "= HS256" might provide the illusion of security, where in fact, there would b= e none - sort of like if someone were to propose to use "HMD5" now. That t= here's no security is at least apparent with "none". :) Algorithms must always be used that are security-appropriate given the need= s of the application in the particular context and the current state of cry= ptography/cryptanalysis. Having a "none" algorithm doesn't change that. [JLS] I would disagree based on past history. But will no press the issue, Section 3.2 1. You may want to reference RFC4231 as well. It contains test vectors an= d such for the SHA2 HMACs If this spec were about implementing the SHA2 HMAC algorithms, I would agre= e, but since it's only about using them, I don't think this reference is ne= cessary. Feel free to push back on this, however... 3. I have not yet read the updated JWS document, but I do worry about the = fact that this document is saying that the output should be base64url encod= ed. If the JWS document says the same thing injudiciously then one could e= asily see that people might double encode the result. I don't think there's a problem, as both documents make a clear distinction= between the "JWS Signature" value and the "Encoded JWS Signature" value, a= nd are careful to use the right term in the right place. (But obviously se= nd me corrections if you find a place where the wrong term is used.) 4. I have a real problem with people saying that UTF-8 and ASCII are the s= ame. They aren't and saying that they are does not make it so. They actually are the same in this case, since the JWS Secured Input consis= ts of only 7-bit ASCII characters (since they contain only base64url encode= d content and periods characters) that are represented the same in both enc= odings. But I agree that the previous text was potentially confusing and o= verly verbose. The text now only uses the phrase "the ASCII representation= of the JWS Secured Input", both here, and in the JWS spec. [JLS] Do you know this to be a true statement for all future encodings of J= WS values as oppose to the current one that is defined in JWS. For example= , in the documents proposed by myself and Richard this is not a true statem= ent. Instead the header is UTF8 encoded and that value is processed withou= t having done the ASCII encoding from base64url. It's true of all of the JOSE working group documents. If the working decid= es to change this, at that point we would, of course, make an appropriate c= ompanion change to these statements. 5. I find it confusing to constantly refer to the JWS specification throug= hout this text. For one thing it makes it harder to refer to these documen= ts for other uses in JSON of these algorithms (such as for an encrypt and M= AC algorithm). These defined terms have now been incorporated into this document, per your= comment on Section 2, so there should be no longer any need to refer to th= e JWS spec to understand this section. [JLS] That does not address my concern. If you do a combo HMAC and encrypt= algorithm are you going to suddenly turn the header and content into a JWS= Secured Input? (And do they suddenly become US ASCII strings?) Actually, I suspect that the JWS Secured Input would be the concatenation o= f the header, encrypted key, and ciphertext, just as is done now, assuming = that a JWS-based computation is done within the composite algorithm to comp= ute the JWE Integrity Value. There's actually nothing about the JWS comput= ation that requires that the secured value is ASCII; by the point the HMAC = computation is done, the secured input is a byte array. (The text about "b= ytes of the ASCII representation of..." is about how to create the byte val= ues for that array, given the particular choices in the current specificati= ons.) Is there are particular wording change that you'd suggest that doesn't chan= ge the semantics of the specifications, but would be easier for developers = to understand? [JLS2] My point is that you can write all of this text purely in terms of = - this is the input that you are dealing with. I don't care what the inpu= t is or where it came from, this is the input value. This is the output va= lue. Based on the input value you get this output value by doing this. Ag= ain - I don't care what the using specification calls these fields because = it does not matter in terms of implementing the crypto function that does a= lgorithm FOO. [mbj2] OK, I understand your point. I've been using the names somewhat lik= e variable names in mathematical presentations - so that there's a shorthan= d name for a specific value or function, but I'll look at whether it might = be simpler in some cases to rely on direct explanations of input/output com= putations rather than relying on the variable names for those values or fun= ctions. Section 3.4 4. I have never see the R,S pair be referred to as a point before. I beli= eve it is just an ordered pair of integers and not a point on the field. The "point" terminology is used by XML DSIG 2.0, at least about the (x, y) = pair. See http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124/#sec-ECKeyVa= lue. I could be wrong that (R, S) are also a point, but given that the P-5= 21 signature is a pair of 521-bit integers, it sure seems like it is. Any = ECDSA experts care to weigh in? [JLS] A fast review of the algorithm on Wikipedia confirms what I was think= ing. The value of R is obtained from a point on the field (using just k) = and the value S is then computed from the value of x and the hash value. T= his means that (r,s) is not a point on the field. OK, I'll reword. Thanks for the research. Section 3.6 1. I don't see the purpose of the last paragraph in this section. It has = nothing to do with algorithms. This subsection is not only about algorithms - it's about extensions to JWS= , the parameters registry for which is also in the JWA spec because it's sh= ared between JWS and JWE. The first and second paragraphs of this subsecti= on is about extensions via algorithms and has a reference to that JWA regis= try. The third paragraph is about extensions via parameters, and has a ref= erence to that JWA registry. Not that 3.6 is parallel to 4.11 which has th= e same content for JWEs. All that being said, I'd be open to a different editorial structuring, if s= omeone wants to make an alternative proposal. Section 4.5 1. RSA-OAEP is under specified. There are a number of parameters for OAEP= that must be defined to go with it. These include the mask function and a= hash function. Look at RFC 3447 for the details. This is now fully specified. The description now reads: RSA using Optimal= Asymmetric Encryption Padding (OAEP), as defined in RFC 3447, with the def= ault parameters specified by RFC 3447 in Section A.2.1 [JLS] It is strongly recommended that the hash function for OAEP and the ha= sh function for the content be the same values. Additionally, why would we= recommend using SHA1 for any of these parameters given that it is not reco= mmended for any other purpose? This has to do with the working group's goal of having developers actually = be able to deploy the resulting specification. Using the .NET Framework as= an example (because it's one that I'm familiar with), the RSA encryption c= hoices available are PKCS 1-1.5 and OAEP with the default parameters. A .N= ET JWE implementation would be extremely difficult if we stray from what's = actually deployed. If you look at PHP, Ruby, Python, OpenSSL, MacOS, Android, iOS, Windows Pho= ne, etc. as actually deployed, you'll find similar limitations. (In fact, = you will not find OAEP support at all on some of these developer platforms.= ) We could delete OAEP entirely on that basis if the working group chooses, o= r make it DEPRECATED, rather than OPTIONAL, but I don't believe that defini= ng variants using non-default parameters would be useful, given that they c= ouldn't be used on most development platforms. On a related note, some colleagues and I have started to gather data on wha= t JWA algorithms are implemented on what development platforms. I'll send = a separate note shortly requesting presentation time during the meeting to = discuss and help refine the data that we've gathered. [JLS2] I think that defining the set of algorithms based on the fact that M= icrosoft does not have people who understand what is necessary for crypto c= ode is probably a bad idea. If we go with what is deployed then we should = not do OAEP and just have RSA v1.5 anyway since as you stated there is not = universal deployment of OAEP anyway. [mbj2] From your response, I think you took my example out of context. The= current algorithm set wasn't developed with only Microsoft in mind. It wa= s developed with all the common developer platforms in mind. (PHP, Ruby, P= ython, OpenSSL, MacOS, Android, iOS, Windows Phone, Java, BouncyCastle, Obj= ective C, Windows, etc. - and if you think that I'm missing some, please le= t me know.) A bunch of us sat down at the Internet Identity Workshop and t= ried to systematically look across the developer documentation for the plat= forms above and determine what algorithms should actually be usable on most= platforms and for which algorithms the deployment status is spottier. Tha= t's the basis of the current REQUIRED/RECOMMENDED/OPTIONAL designations (an= d the basis of why some algorithms aren't listed at all). Using the OAEP example, indeed, OAEP is presently optional in JWA precisely= because it's not universally deployed. The working group can obviously fine tune the algorithm set and Implementat= ion Requirements. If people believe we should add/subtract or change requi= rements for specific algorithms, by all means, let's have that discussion. Section 4.6 2. I strongly disagree with setting OtherInfo parameters to be empty. We need to define and fill in the AlgorithmId at a minimum. Note that this ca= n be an implicit computation and does not need to be carried as extra data. At a minimum I would suggest something along the lines of JOSE-### where ##= # is the number of bits to get generated. Per my response to Sean's related comment, it's not clear to me what additi= onal value these parameters add in our usage of the algorithm. If we belie= ve that the content master key is undeterminable by an attacker (a requirem= ent for any security at all!) then adding a constant AlgorithmID to the com= putation I don't believe changes the security properties. (That being said= , we *could* use the "alg" value "ECDH-ES" as the AlgorithmID if people fel= t better about doing this.) Also given that the text now says (per your previous comment) that "A new e= pk (ephemeral public key) value MUST be generated for each key agreement tr= ansaction", it's not clear that adding parameters identifying the participa= ting parties adds any security value either. That being said, I'd be glad = to learn why I'm wrong. If there are good security reasons for requiring PartyUInfo and PartyVInfo = values, do you have suggestions on how to create acceptable values without = carrying more parameters in the header? (I've already suggested that we co= uld use the "alg" value "ECDH-ES" as the AlgorithmID, which wouldn't requir= e more parameters.) For instance, I don't want to blindly follow XML ENC's lead and punt the is= sue by requiring that conforming uses provide explicit PartyUInfo and Party= VInfo values. Finally, I'll note that the KDF function used by TLS http://tools.ietf.org/= html/rfc5246#section-5 uses no party parameters. Why do we need them then? [JLS] The object of having the algorithm identifier be present is to make s= ure that if you are doing two kdfs from the same key pairs for different pu= rposes that they will never end up generating the same key values (or a pre= fix of the same key values). While it is not immediate obvious that this = is going to be possible with the JOSE documents, it is a known security iss= ue and one that is easily addressed. One way would be as I suggested above= and used a string with the number of bits. Another way would be to use th= e algorithm that the key is going to be used for (which is how it is define= d). Thus this should be the ACUTAL content encryption algorithm used (i.e.= AES128GW or AES128CBC+HS256). I suspect that using the concatenation of the "enc" and "int" values as the= AlgorithmID, as you suggest above, is the right solution when doing Key De= rivation. This is already on the Open Issues list to discuss on the mailin= g list and in Vancouver. At this point I now would say that the KDF MUST have the ability to have a = PartyUInfo value specified. When the KDF was implicit in the key agreement= algorithm tag it did not matter. At that point if someone defined a new s= tatic-static version of ECDH then they would be required to define what KDF= function was to be used and could then require that the PartyUInfo field b= e defined in the KDF function that required. As it stands now, the KDF is = no longer tied to the key agreement algorithm and must therefore meet the n= ecessary security requirements for a static-static version of DH as well as= the ephemeral static versions. (On the other hand it still may be implici= t, but this was not completely obvious as there is a kdf function that woul= d be used in some cases leading to a confusion about what the kdf function = was actually being used for.) Key Agreement and Key Derivation are different cases. In the case of Key A= greement, the KDF *is* tightly bound to the algorithm definition. See the = definition of "ECDH-ES" in http://tools.ietf.org/html/draft-ietf-jose-json-= web-algorithms-03#section-4.1. Note also that use of a unique random ephem= eral public key is required, so unless your keygen algorithm is broken, the= re's no chance of generating the same derived keys. I believe it's already clear in http://tools.ietf.org/html/draft-ietf-jose-= json-web-encryption-03#section-4.1.4 that the "kdf" member is used in the K= ey Derivation case - not the Key Agreement case. But we can tighten this l= anguage further, if you'd like to suggest better wording. For TLS, both the PartyUInfo and the PartyVInfo values are present and used= when computing the key from the master secret. Since they are present at = that point they do not need to be present when computing the master secret = itself. When using TLS to compute other secrets - such as a TLS Unque val= ue, the equivalent of the algorithm ID is used at that point to make sure t= hat all such keys computed are going to be unique to that purpose. I believe you're discussing the Key Derivation case in the above paragraph.= Again, I think that using the concatenation of the "enc" and "int" values= as the AlgorithmID may be the right outcome for Key Derivation. But just = as in the Key Agreement case, given that a unique random CMK value MUST be = used, there's no chance of generating the same derived keys for other parti= es, unless the keygen algorithm generates duplicate keys (in which case you= have bigger problems). That being said, if there's a way of utilizing PartyUInfo and PartyVInfo va= lues in the KDF computation that doesn't involve carrying them as additiona= l header parameter values, I'd certainly personally be open to that as well= . Section 4.11 1. for last paragraph see comment on 3.6 Same response as for 3.6 Section 6.1 1. I would move this registry to either the signature or encryption docume= nts and not put it here. What does this document populate it with? Done Section 6.2 1. Make life easy for IANA and me - create a table of the values Done both here and in the other documents [JLS] What is the purpose of putting the Implementation Requirements into t= he table? Different applications may have different requirements and these= requirements may change over time. It does not make sense to require the = table to be updated every time the set of requirements change. The only ex= ception to that might be an obsoleted or do not use field, but even that ca= n be somewhat iffy. Sean Turner had suggested this. Apparently it is done in other specificati= ons and registries. (Examples, Sean?) It's certainly easier for implement= ers to understand, because they'll always be able to count on the registry'= s implementation status to be up to date. This can change, for instance, a= s algorithms move from OPTIONAL to RECOMMENDED to REQUIRED, or when they mo= ve from any of those states to DEPRECATED. [JLS2] OK - I note that he asked the question about this, but I don't reall= y see any recommendation that it be done. [mbj2] It made the spec easier to understand and simpler, so as an editor, = it seemed like a good idea to me. Section 6.3 1. This registry should be in either the encryption or signature draft Done - now in JWS Section 6.4 1. This registry should be in the JWK document Done Section 6.5 1. Make life easy for IANA and me - create a table of the values Done both here and in the other documents --_000_4E1F6AAD24975D4BA5B16804296739436672BDB2TK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[mbj2] Additional resp= onses…

 

From: Jim Scha= ad [mailto:ietf@augustcellars.com]
Sent: Friday, July 13, 2012 4:54 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: RE: Comments on draft-ietf-jose-json-web-algorithms-02=

 

 

 

From: Mike Jon= es [mailto:Michael.Jon= es@microsoft.com]
Sent: Friday, July 13, 2012 2:21 PM
To: Jim Schaad
Cc: jose@ietf.org
Subject: RE: Comments on draft-ietf-jose-json-web-algorithms-02=

 

Responses inline…= ;

 

From: Jim Scha= ad [mailto:ietf@augustcella= rs.com]
Sent: Sunday, July 08, 2012 10:16 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: RE: Comments on draft-ietf-jose-json-web-algorithms-02=

 

Responses to previous = comments and some new comments.

 

 

Open issue feedback &#= 8211; Do AES ECB – no

 

 

From: Mike Jon= es [mailto:Michael.Jon= es@microsoft.com]
Sent: Friday, July 06, 2012 10:41 AM
To: 'Jim Schaad'
Cc: jose@ietf.org
Subject: RE: Comments on draft-ietf-jose-json-web-algorithms-02=

 

Thanks for taking t= he time to provide the detailed feedback.  Responses inline…

 

-----Original Message-----
From: Jim Schaad [mailto= :ietf@augustcellars.com]
Sent: Monday, May 21, 2012 3:46 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: Comments on draft-ietf-jose-json-web-algorithms-02

 

Here are comments this document

 

Abstract

 

1.  Since I called it out for JWK I will mak= e the comment that I do not have a problem with enumerate in this document.=

 

Noted

 

[JLS] On the other = had since you said it was addressed in the mail for the JWK document and it= is not changed I do have a problem there.

 

Saying in the JWK f= eedback that it was addressed in JWA was a typo in my e-mail on my part.&nb= sp; I intentionally did not change away from the word “enumeratesR= 21; in JWA both since you said that you *didn’t* have a problem with it, and because I believe it accurately conveys what the JW= A document does.  But I’d be open to an alternative description = if you’d like to supply wording that’s even clearer.=

 

Section 1

 

1.  Just a comment - I am not sure why you f= eel the name to create a specific acronym for this document but it does not= really matter.

 

It provides a short= hand name to refer to this document from others.

 

2.  Need to expand JSON if you are going to = use it.

 

Not done here, beca= use the word “JSON” here is used as part of a name, rather than= as a reference to a specification or kind of data structure.  I did e= xpand it the first time it is used to refer to the RFC 4627 data structures, in all the documents.

 

[JLS]  The rul= es state that it is to be expanded on the first use.  If it is not don= e on the first use then the RFC editor will do so.  It should be ok in= the key document since it is done almost immediately after the first use.  As it currently stands it does not follow this = rule.

 

How would adding a = sentence like this work for you?

“All these sp= ecifications utilize JavaScript Object Notation (JSON) [RFC4627] based data= structures.”

 

[JLS2] that would a= ddress the problem.

 

3.  New paragraph for sentence starting with= "Enumerating..."  Separate justification from what this doc= ument does and hash.

 

Done

 

4.  Move last sentence to the end of the fir= st paragraph

 

Done

 

Section 2

 

1.  In general I would like to see this dupl= icated into this document.

Readers should not have to reference another docu= ment for this purpose.

 

Done

 

[JLS] However only = the relevant terms should be included.  If JWE Ciphertext is never use= d then it does not need to be included at this point.

 

Agreed.  I alr= eady did a pass and removed unused terms.  In the example of JWE Ciphe= rtext, this term is used in the definition of JWE Header, which is used in = the body of the specification, and so is necessary.  If you find some that are not used directly or indirectly, please point th= em out, and I’ll remove them.

 

Section 3.1

 

1.  I am not overly happy with the existence= of a "none" algorithm.  Does it really need to exist?<= /o:p>

 

Yes.  It is al= ready widely used in contexts where content can be either signed or plainte= xt.  And while it used to be defined in JWT, you’d earlier sugge= sted that it be moved here, since it is of broader applicability than just JWTs.

 

[JLS] I don’t= disagree with it being here rather than in the JWT document.  However= there is a question if it would be better represented as having an absent = alg parameter rather than having a “none” algorithm.  It would accomplish the same thing and be less suggested if an actual sign= ature/MAC algorithm existing on the document.

 

The due diligence t= hat users of  “alg”:“none” have to perform is = actually no less than the due diligence that they have to apply when using = any other “alg” value.  At some future time, for instance,= if HMAC SHA-256 is broken, then using “HS256” would be arguably be wor= se than using “none”, because “HS256” might provide= the illusion of security, where in fact, there would be none – sort = of like if someone were to propose to use “HMD5” now.  Tha= t there’s no security is at least apparent with “none”. J<= /o:p>

 

Algorithms must alw= ays be used that are security-appropriate given the needs of the applicatio= n in the particular context and the current state of cryptography/cryptanal= ysis.  Having a “none” algorithm doesn’t change that.

 

[JLS] I would disag= ree based on past history.  But will no press the issue,

 

Section 3.2

 

1.  You may want to reference RFC4231 as wel= l.  It contains test vectors and such for the SHA2 HMACs

 

If this spec were a= bout implementing the SHA2 HMAC algorithms, I would agree, but since itR= 17;s only about using them, I don’t think this reference is necessary= .  Feel free to push back on this, however…

 

3.  I have not yet read the updated JWS docu= ment, but I do worry about the fact that this document is saying that the o= utput should be base64url encoded.  If the JWS document says the same = thing injudiciously then one could easily see that people might double encode the result.

 

I don’t think= there’s a problem, as both documents make a clear distinction betwee= n the “JWS Signature” value and the “Encoded JWS Signatur= e” value, and are careful to use the right term in the right place.&n= bsp; (But obviously send me corrections if you find a place where the wrong ter= m is used.)

 

4.  I have a real problem with people saying= that UTF-8 and ASCII are the same.  They aren't and saying that they = are does not make it so.

 

They actually are t= he same in this case, since the JWS Secured Input consists of only 7-bit AS= CII characters (since they contain only base64url encoded content and perio= ds characters) that are represented the same in both encodings.  But I agree that the previous text was p= otentially confusing and overly verbose.  The text now only uses the p= hrase “the ASCII representation of the JWS Secured Input”, both= here, and in the JWS spec.

 

[JLS] Do you know t= his to be a true statement for all future encodings of JWS values as oppose= to the current one that is defined in JWS.  For example, in the docum= ents proposed by myself and Richard this is not a true statement.  Instead the header is UTF8 encoded and that= value is processed without having done the ASCII encoding from base64url.<= o:p>

 

It’s true of = all of the JOSE working group documents.  If the working decides to ch= ange this, at that point we would, of course, make an appropriate companion= change to these statements.

 

5.  I find it confusing to constantly refer = to the JWS specification throughout this text.  For one thing it makes= it harder to refer to these documents for other uses in JSON of these algo= rithms (such as for an encrypt and MAC algorithm).

 

These defined terms= have now been incorporated into this document, per your comment on Section= 2, so there should be no longer any need to refer to the JWS spec to under= stand this section.

 

[JLS] That does not= address my concern.  If you do a combo HMAC and encrypt algorithm are= you going to suddenly turn the header and content into a JWS Secured Input= ? (And do they suddenly become US ASCII strings?)

 

Actually, I suspect= that the JWS Secured Input would be the concatenation of the header, encry= pted key, and ciphertext, just as is done now, assuming that a JWS-based co= mputation is done within the composite algorithm to compute the JWE Integrity Value.  There’s actually= nothing about the JWS computation that requires that the secured value is = ASCII; by the point the HMAC computation is done, the secured input is a by= te array.  (The text about “bytes of the ASCII representation of…” is about how to create the byte values for= that array, given the particular choices in the current specifications.)

 

Is there are partic= ular wording change that you’d suggest that doesn’t change the = semantics of the specifications, but would be easier for developers to unde= rstand?

 

[JLS2]  My poi= nt is that you can write all of this text purely in terms of -  this i= s the input that you are dealing with.  I don’t care what the in= put is or where it came from, this is the input value.  This is the output value.  Based on the input value you get this output va= lue by doing this.  Again – I don’t care what the using sp= ecification calls these fields because it does not matter in terms of imple= menting the crypto function that does algorithm FOO.

 

[mbj2] OK, I unders= tand your point.  I’ve been using the names somewhat like variab= le names in mathematical presentations – so that there’s a shor= thand name for a specific value or function, but I’ll look at whether it might be simpler in some cases to rely on direct explanation= s of input/output computations rather than relying on the variable names fo= r those values or functions.

 

Section 3.4

 

4.  I have never see the R,S pair be referre= d to as a point before.  I believe it is just an ordered pair of integ= ers and not a point on the field.

 

The “point= 221; terminology is used by XML DSIG 2.0, at least about the (x, y) pair.&n= bsp; See http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124/#sec-ECKeyV= alue.  I could be wrong that (R, S) = are also a point, but given that the P-521 signature is a pair of 521-bit integers, it sure seems like it is.  A= ny ECDSA experts care to weigh in?

 

[JLS] A fast review= of the algorithm on Wikipedia confirms what I was thinking.  The valu= e of R is obtained from a point on the field  (using just k) and the v= alue S is then computed from the value of x and the hash value.  This means that (r,s) is not a point on the field. <= o:p>

 

OK, I’ll rewo= rd.  Thanks for the research.

 

Section 3.6

 

1.  I don't see the purpose of the last para= graph in this section.  It has nothing to do with algorithms.

 

This subsection is = not only about algorithms – it’s about extensions to JWS, the p= arameters registry for which is also in the JWA spec because it’s sha= red between JWS and JWE.  The first and second paragraphs of this subsection is about extensions via algorithms and has a reference = to that JWA registry.  The third paragraph is about extensions via par= ameters, and has a reference to that JWA registry.  Not that 3.6 is pa= rallel to 4.11 which has the same content for JWEs.

 

All that being said= , I’d be open to a different editorial structuring, if someone wants = to make an alternative proposal.

 

Section 4.5

 

1.  RSA-OAEP is under specified.  There= are a number of parameters for OAEP that must be defined to go with it.&nb= sp; These include the mask function and a hash function.  Look at RFC = 3447 for the details.

 

This is now fully s= pecified.  The description now reads:  RSA using Optimal Asymmetr= ic Encryption Padding (OAEP), as defined in RFC 3447, with the default para= meters specified by RFC 3447 in Section A.2.1

 

[JLS] It is strongl= y recommended that the hash function for OAEP and the hash function for the= content be the same values.  Additionally, why would we recommend usi= ng SHA1 for any of these parameters given that it is not recommended for any other purpose?

 

This has to do with= the working group’s goal of having developers actually be able to de= ploy the resulting specification.  Using the .NET Framework as an exam= ple (because it’s one that I’m familiar with), the RSA encryption choices available are PKCS 1-1.5 and OAEP with the defa= ult parameters.  A .NET JWE implementation would be extremely difficul= t if we stray from what’s actually deployed.

 

If you look at PHP,= Ruby, Python, OpenSSL, MacOS, Android, iOS, Windows Phone, etc. as actuall= y deployed, you’ll find similar limitations.  (In fact, you will= not find OAEP support at all on some of these developer platforms.)

 

We could delete OAE= P entirely on that basis if the working group chooses, or make it DEPRECATE= D, rather than OPTIONAL, but I don’t believe that defining variants u= sing non-default parameters would be useful, given that they couldn’t be used on most development platforms.=

 

On a related note, = some colleagues and I have started to gather data on what JWA algorithms ar= e implemented on what development platforms.  I’ll send a separa= te note shortly requesting presentation time during the meeting to discuss and help refine the data that we’ve gathered.=

 

[JLS2] I think that= defining the set of algorithms based on the fact that Microsoft does not h= ave people who understand what is necessary for crypto code is probably a b= ad idea.  If we go with what is deployed then we should not do OAEP and just have RSA v1.5 anyway since as you stat= ed there is not universal deployment of OAEP anyway.

 

[mbj2] From your re= sponse, I think you took my example out of context.  The current algor= ithm set wasn’t developed with only Microsoft in mind.  It was d= eveloped with all the common developer platforms in mind.  (PHP, Ruby, Python, OpenSSL, MacOS, Android, iOS, Windows Phon= e, Java, BouncyCastle, Objective C, Windows, etc. – and if you think = that I’m missing some, please let me know.)  A bunch of us sat d= own at the Internet Identity Workshop and tried to systematically look across the developer documentation for the platforms above and determ= ine what algorithms should actually be usable on most platforms and for whi= ch algorithms the deployment status is spottier.  That’s the bas= is of the current REQUIRED/RECOMMENDED/OPTIONAL designations (and the basis of why some algorithms aren’t listed at = all).

 

Using the OAEP exam= ple, indeed, OAEP is presently optional in JWA precisely because it’s= not universally deployed.

 

The working group c= an obviously fine tune the algorithm set and Implementation Requirements.&n= bsp; If people believe we should add/subtract or change requirements for sp= ecific algorithms, by all means, let’s have that discussion.

 

Section 4.6

 

2.  I strongly disagree with setting OtherIn= fo parameters to be empty.   We

need to define and fill in the AlgorithmId at a m= inimum.  Note that this can be an implicit computation and does not ne= ed to be carried as extra data.

At a minimum I would suggest something along the = lines of JOSE-### where ### is the number of bits to get generated.

 

Per my response to = Sean’s related comment, it's not clear to me what additional value th= ese parameters add in our usage of the algorithm.  If we believe that = the content master key is undeterminable by an attacker (a requirement for any security at all!) then adding a constant A= lgorithmID to the computation I don't believe changes the security properti= es.  (That being said, we *could* use the “alg” value &quo= t;ECDH-ES" as the AlgorithmID if people felt better about doing this.)

 

Also given that the= text now says (per your previous comment) that "A new epk (ephemeral = public key) value MUST be generated for each key agreement transaction"= ;, it's not clear that adding parameters identifying the participating parties adds any security value either.  That being= said, I'd be glad to learn why I'm wrong.

 

If there are good s= ecurity reasons for requiring PartyUInfo and PartyVInfo values, do you have= suggestions on how to create acceptable values without carrying more param= eters in the header?  (I've already suggested that we could use the “alg” value "ECDH-ES"= ; as the AlgorithmID, which wouldn't require more parameters.)

 

For instance, I don= 't want to blindly follow XML ENC's lead and punt the issue by requiring th= at conforming uses provide explicit PartyUInfo and PartyVInfo values.<= /o:p>

 

Finally, I'll note = that the KDF function used by TLS http://tools.ietf.= org/html/rfc5246#section-5 uses no party parameters.  Why do we ne= ed them then?

 

[JLS] The object of= having the algorithm identifier be present is to make sure that if you are= doing two kdfs from the same key pairs for different purposes that they wi= ll never end up generating the same key values (or a prefix of the same key values).   While it is n= ot immediate obvious that this is going to be possible with the JOSE docume= nts, it is a known security issue and one that is easily addressed.  O= ne way would be as I suggested above and used a string with the number of bits.  Another way would be to use the algo= rithm that the key is going to be used for (which is how it is defined).&nb= sp; Thus this should be the ACUTAL content encryption algorithm used (i.e. = AES128GW or AES128CBC+HS256).

 

I suspect that usin= g the concatenation of the “enc” and “int” values a= s the AlgorithmID, as you suggest above, is the right solution when doing K= ey Derivation.  This is already on the Open Issues list to discuss on the mailing list and in Vancouver.

 

At this point I now= would say that the KDF MUST have the ability to have a PartyUInfo value sp= ecified.  When the KDF was implicit in the key agreement algorithm tag= it did not matter.  At that point if someone defined a new static-static version of ECDH then they would be required to= define what KDF function was to be used and could then require that the Pa= rtyUInfo field be defined in the KDF function that required.  As it st= ands now, the KDF is no longer tied to the key agreement algorithm and must therefore meet the necessary security= requirements for a static-static version of DH as well as the ephemeral st= atic versions.  (On the other hand it still may be implicit, but this = was not completely obvious as there is a kdf function that would be used in some cases leading to a confusion abo= ut what the kdf function was actually being used for.)

 

Key Agreement and K= ey Derivation are different cases.  In the case of Key Agreement, the = KDF *is* tightly bound to the algorithm definition.  See the definitio= n of “ECDH-ES” in http://tools.ietf.org/h= tml/draft-ietf-jose-json-web-algorithms-03#section-4.1.  Note also that use of a unique random ephemeral public key is required, so unless your ke= ygen algorithm is broken, there’s no chance of generating the same de= rived keys.

 

I believe it’= s already clear in http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-03#section-4= .1.4 that the “kdf” member is used in the Key Derivation ca= se – not the Key Agreement case.  But we can tighten this langua= ge further, if you’d like to suggest better wording.

 

For TLS, both the P= artyUInfo and the PartyVInfo values are present and used when computing the= key from the master secret.  Since they are present at that point the= y do not need to be present when computing the master secret itself.   When using TLS to compute other secr= ets – such as a TLS Unque value, the equivalent of the algorithm ID i= s used at that point to make sure that all such keys computed are going to = be unique to that purpose.

 

I believe you’= ;re discussing the Key Derivation case in the above paragraph.  Again,= I think that using the concatenation of the “enc” and “i= nt” values as the AlgorithmID may be the right outcome for Key Deriva= tion.  But just as in the Key Agreement case, given that a unique random CMK valu= e MUST be used, there’s no chance of generating the same derived keys= for other parties, unless the keygen algorithm generates duplicate keys (i= n which case you have bigger problems).

 

That being said, if= there’s a way of utilizing PartyUInfo and PartyVInfo values in the K= DF computation that doesn’t involve carrying them as additional heade= r parameter values, I’d certainly personally be open to that as well.

 

Section 4.11

 

1.  for last paragraph see comment on 3.6

 

Same response as fo= r 3.6

 

Section 6.1

 

1.  I would move this registry to either the= signature or encryption documents and not put it here.  What does thi= s document populate it with?

 

Done

 

Section 6.2

 

1.  Make life easy for IANA and me - create = a table of the values

 

Done both here and = in the other documents

 

[JLS] What is the p= urpose of putting the Implementation Requirements into the table?  Dif= ferent applications may have different requirements and these requirements = may change over time.  It does not make sense to require the table to be updated every time the set of requirements chan= ge.  The only exception to that might be an obsoleted or do not use fi= eld, but even that can be somewhat iffy.

 

Sean Turner had sug= gested this.  Apparently it is done in other specifications and regist= ries.  (Examples, Sean?)  It’s certainly easier for impleme= nters to understand, because they’ll always be able to count on the registry’s implementation status to be up to date.  This= can change, for instance, as algorithms move from OPTIONAL to RECOMMENDED = to REQUIRED, or when they move from any of those states to DEPRECATED.=

 

[JLS2] OK – I= note that he asked the question about this, but I don’t really see a= ny recommendation that it be done.

 

[mbj2] It made the = spec easier to understand and simpler, so as an editor, it seemed like a go= od idea to me.

 

Section 6.3

 

1.  This registry should be in either the en= cryption or signature draft

 

Done – now in= JWS

 

Section 6.4

 

1.  This registry should be in the JWK docum= ent

 

Done

 

Section 6.5

 

1.  Make life easy for IANA and me - create = a table of the values

 

Done both here and = in the other documents

 

--_000_4E1F6AAD24975D4BA5B16804296739436672BDB2TK5EX14MBXC285r_-- From internet-drafts@ietf.org Mon Jul 16 16:06:48 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C9C21F880E; Mon, 16 Jul 2012 16:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLq5ZWl3SeY2; Mon, 16 Jul 2012 16:06:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36EC321F8841; Mon, 16 Jul 2012 16:06:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716230647.31340.60590.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 16:06:47 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-signature-04.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 23:06:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Signature (JWS) Author(s) : Michael B. Jones John Bradley Nat Sakimura Filename : draft-ietf-jose-json-web-signature-04.txt Pages : 39 Date : 2012-07-16 Abstract: JSON Web Signature (JWS) is a means of representing content secured with digital signatures or Message Authentication Codes (MACs) using JavaScript Object Notation (JSON) data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-signature-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 16 16:08:02 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B187B21F8851; Mon, 16 Jul 2012 16:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEZoRBLtWvrb; Mon, 16 Jul 2012 16:08:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED68421F8855; Mon, 16 Jul 2012 16:08:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716230801.1381.58778.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 16:08:01 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-04.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 23:08:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Encryption (JWE) Author(s) : Michael B. Jones Eric Rescorla Joe Hildebrand Filename : draft-ietf-jose-json-web-encryption-04.txt Pages : 44 Date : 2012-07-16 Abstract: JSON Web Encryption (JWE) is a means of representing encrypted content using JavaScript Object Notation (JSON) data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. Related digital signature and MAC capabilities are described in the separate JSON Web Signature (JWS) specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 16 16:09:23 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F9C21F884A; Mon, 16 Jul 2012 16:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOEtlAYvRUDC; Mon, 16 Jul 2012 16:09:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56EDE21F88C1; Mon, 16 Jul 2012 16:09:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716230922.2324.99825.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 16:09:22 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-key-04.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 23:09:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Key (JWK) Author(s) : Michael B. Jones Filename : draft-ietf-jose-json-web-key-04.txt Pages : 12 Date : 2012-07-16 Abstract: A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a public key. This specification also defines a JSON Web Key Set (JWK Set) JSON data structure for representing a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-key-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-key-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 16 16:10:55 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E260821F88E3; Mon, 16 Jul 2012 16:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dagh51dtwcpl; Mon, 16 Jul 2012 16:10:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27FC21F88E5; Mon, 16 Jul 2012 16:10:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716231050.3432.72949.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 16:10:50 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-04.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 23:10:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Algorithms (JWA) Author(s) : Michael B. Jones Filename : draft-ietf-jose-json-web-algorithms-04.txt Pages : 41 Date : 2012-07-16 Abstract: The JSON Web Algorithms (JWA) specification enumerates cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-algorithms-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ietf@augustcellars.com Mon Jul 16 18:31:24 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6114D11E809A for ; Mon, 16 Jul 2012 18:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.481 X-Spam-Level: X-Spam-Status: No, score=-3.481 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UR3y50LYuRMJ for ; Mon, 16 Jul 2012 18:31:17 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 4702711E8099 for ; Mon, 16 Jul 2012 18:31:17 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 223FD2CA0B; Mon, 16 Jul 2012 18:32:01 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , References: <4E1F6AAD24975D4BA5B16804296739436657A0E4@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436657A0E4@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 16 Jul 2012 18:30:29 -0700 Message-ID: <01f301cd63bb$c7188700$55499500$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01F4_01CD6381.1AC2AFB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGtLrAIoIGfL58fGmSZztiMIaNvZZdlie4g Content-Language: en-us Subject: Re: [jose] json-web-encryption -02 comments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 01:31:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01F4_01CD6381.1AC2AFB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In section 4 - There is an interesting question about the following: { alg:"none", enc:"AES128GCM" } This returns different results depending on which test you are using for determining if the header is a JWE or a JWS. This belies the last sentence in paragraph #2. In Section 4.1.1 It is stated that the value of "alg" is case sensitive. It is stated that it may be a URI. URIs say that there may be case insensitive portions of the URI value. This needs to be reconciled. From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, July 06, 2012 11:13 AM To: Jim Schaad; jose@ietf.org Subject: RE: json-web-encryption -02 comments Thanks once again. Responses inline. -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Thursday, June 07, 2012 11:56 AM To: jose@ietf.org; draft-ietf-jose-json-web-encryption@tools.ietf.org Subject: json-web-encryption -02 comments Introduction 1. I would separate the introduction into two paragraphs. One to address the general encryption issue and one to address the compact serialization issues. This will allow for an easier addition/removal to deal with other serialization issues. I'm somewhat confused by this comment, as the introduction doesn't discuss serialization. That concept isn't introduced until the "JWE Compact Serialization" term definition in Section 2 and the presentation of the compact serialization in Section 3. [JLS] And I am suggesting that the introduction SHOULD address the fact that a serialization method is presented in this document. The process of encryption and the process of serialization are separate things and both are covered in this document. This should be documented in the abstract. This should also be picked up in the abstract as well. 2. I find sentence #2 confusing since this document is defining how to do the encryption process so we are not really dealing with pre-encrypted content which is what this appears to me to say. Like JWS, this sentence has been clarified to: It represents this content using JavaScript Object Notation (JSON) data structures. [JLS] I think that I find the concept that it represents the content as JSON to be weird, since the final formatting is actually dotted notation if you are looking at the "compact encryption format" that was covered in this document. 3. What do you mean by the type of content being encrypted? This could either mean the format of the content (i.e. JSON vs Mime) or the type of content (i.e. a JSON token vs a JSON signature object). This now reads: The JWE cryptographic mechanisms encrypt and provide integrity protection for arbitrary sequences of bytes. [JLS] I find this confusing. A MAC also provides integrity protection and that is in a different document. Section 3 1. Simple clarity s/confidentiality of the contents of the Plaintext/confidentiality of the Plaintext/ Done Section 4 - JWE Header 1. Do we think parsers can enforce the uniqueness requirement? See my response in the JWK comments 2. What does it mean to reject a JWE? Should it decrypt and say it is a bad decrypt or should it fail to decrypt? It should return an error and return no decrypted data [JLS] This response would eliminate that ability to do a stream based decode. That would return decrypted data and then return the error. Section 4.1.1 1. You should be constant about what you call the encryption key, master key or JWE Encrypted key. A search and replace should be done to make them constant. Now using the term Content Master Key (CMK) here. Note that the Content Encryption Key (CMK) is distinct from (and derived from) the CMK. 2. Refer to the registry not to the document for the list of algorithms. Moved the document reference to be adjacent to the registry reference, saying that both apply Section 4.1.2 1. See comment 2 above Ditto 2. the encryption algorithm is not used to secure the cipher text. It is used to produce the cipher text Corrected 3. Why does the enc algorithm not require the existence of a key for it's use? Because the CEK is derived from the CMK, and so always exists [JLS] and how is that key known? Is a wrapped key always required in this case. Section 4.1.4 2. The presence of this parameter MUST be specified for all content encryption algorithms. It is, in JWA. Also clarified that it is REQUIRED with some "enc" algorithms. Section 4.1.5 1. See comment 2 above - alternate language would be say MUST be absent unless otherwise specified by the algorithm. It is, in JWA. Also clarified that it is REQUIRED with some "alg" algorithms. [JLS] Then I assume that the following is legal { alg:"RSA1_5", epk:{.}, .} 2. epk should talk about key agreement algorithms not a specific algorithm. Done 3. Content of the key should be specified by the algorithm and not by this document. Done Section 4.1.6 1. Should specify the use the "alg" registry for the zip parameter (in case a new one comes into existence) and this algorithm should be registered as the only algorithm. This could be done, but it is counter to an explicit working group decision to support only one compression algorithm. I'd be glad to do this if the WG decides to open the door to the possibility of additional algorithms. [JLS] I do not feel that this means that it should not be registered. It merely means that we will only register one, and we will make the bar very high for the ability to register a second one. Otherwise this should be a Boolean with a value of true. It either is or is not compressed. Section 4.1.7 1. Should make clear that this is the way of identifying what private key is needed to decrypt the content. Added: this can be used to determine the private key needed to decrypt the JWE 2. Should this be used? It implies that the decryptor needs to do the following: a) Get the keys b) For each key - i) Do I have the private key for this? ii) Does it match the algorithm? iii) Does it work? c) if no function keys found then ---??? Also, the decryptor might use "kid" and/or "use" parameters for deciding which key(s) to use. Obviously, if no applicable key can be located, the decryption will fail. Section 4.1.8 1. See comment 1 above. Ditto Section 4.1.9 1. I would eliminate the (implicit) requirement that the certificate be validated before decryption. There is no reason that a client should not be able to decrypt a message to themselves if their certificate has been revoked or is expired. This is just a requirement at send time. What do others in the working group think of potentially relaxing this requirement? If we do relax it, what alternative language should be used? Section 4.1.11 1. I don't understand the format used here. The data could be either encoded as a string or an array of strings or something else that is a concatenated string form. I've added an example to clarify this. See http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-03#appendix-B [JLS] That is nice that you have added an example. However this does not mean that the text should not be clarified. I think that you really want to say that this field is an array of strings, each element in the array being a base64url encoded certificate. The certificates are ordered such that certificate i is issued by certificate i+1. Is it legal for a partial chain to be presented or must the full chain always be presented? Is there a reason that you are not just using the PEM encoding in this location as well? If there is a requirement for having a chain of certificates in this location, why is there not a requirement for having an array of certificates in the x5t case? As a recipient I should never need more than the EE certificate in order to map from a public key to a private key. Other than letting me know what the chain was that the sender used to validate my certificate, I don't know what the reasoning behind sending the chain would be. 2. Why is this not base64url encoded given that all other locations are? So we're using a standard encoding for certificate chains [JLS] A standard encoding would be using the PEM string or using a CMS certs only. Changing the base64url to remove trailing characters is not really an issue. Unless the new JavaScript CryptoAPIs (as an example) take a base64 encoded certificate as input the user code is going to deal with the encoding/decoding question anyway. 3. See comment 1 above Ditto Section 4.1.12 1. This is so underspecified that I would know how to go about using it. Any code that I wrote would therefore ignore it. Added: When used with a JWK, the "kid" value MAY be used to match a JWK "kid" parameter value. [JLS] This does nothing to change my statement above. In fact it enforces it. Section 4.1.13 1. The list of possible typ values should apparently include the mime registry as well. This is neither in the value registry (which should probably be setup to avoid collisions with mime types) or a URI. See the new Section 7.2 in JWS [JLS] I do not believe that mime types and subtypes are case insensitive values in MIME itself. This needs to be resolved. Section 4.2 1. Should re-iterate the "if you don't know it then reject it" sentence here - it has been a long time since we have seen it. (Ditto for section 4.3) I understand why you're saying this, but we did say "Implementations MUST understand the entire contents of the header; otherwise, the JWE MUST be rejected" in the enclosing section introduction (Section 4), so I'm reluctant to repeat it in 4.2 and especially reluctant to repeat it again so soon in 4.3. Section 5 1. I disagree with the concept of using a key agree algorithm to create the CMK. Look at CMS to see how they handle key agree algorithms to create a key wrap key The key wrap key is unnecessary, as far as I can tell, at least when there's a single recipient. It results in an additional encryption step that seems to me to add no additional security. However, per James Manger's note and my response to it, I do understand that value of having a CMK in the multiple recipients case. I've added this topic to the list of open issues for the working group to discuss. 2. In step 8 - when did you create the encoded JWE header? In step 9. :-) Yes, I'd already seen this and fixed it. 3. Separate the serialization format from the encryption algorithm. This may just affect step 14. Done 4. Note previous discussion on only documenting AEAD algorithms I'm not sure what change you're asking for here? [JLS] I am asking that there only be one set of steps for doing this, and it is for AEAD algorithms. Section 6 1. Separate serialization from message decryption. If alternate serializations are used then step 1 fails. Done 2. Note that you have imposed some additional restrictions on the JSE header in step three - specifically that no duplicate fields exist. This is not in the decryption process. It's input validation for the decryption process, just like step 2 was Section 7 1. If you are using the NIST KDF function, then the length of the output key should really be included in the OtherInfo Again, per my earlier responses to you and Sean on this topic from your JWA comments, since the CMK is randomly generated for each encryption, I believe that the additional parameters add no security value. Adding a key length would only make sense if we were going to use this same CMK to generate other keys using the same Label ("Encryption" or "Integrity") but with a different key length. But we never will, so I believe that the parameter is superfluous. Section 8.1 1. Refer to the registry not to the document (ditto for section 8.2) Done Section 11.1 1. Should there be an optional parameter which describes which serialization method is being used? This could be introduced if the working group adopts a second serialization method, such as the JSON Serialization defined in draft-jones-json-web-encryption-json-serialization, or one of the other candidates. However, a better approach might be to define a different media type value, such as application/jwe-js for the different serialization. Of course, if we have a pure JSON serialization, one could argue for just using the application/json media type. 2. Check with IANA if you or the IESG should be listed under the contact section. Will do ------=_NextPart_000_01F4_01CD6381.1AC2AFB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In section 4 –

There is an interesting = question about the following:

{ = alg:”none”, enc:”AES128GCM” = }

 

This returns different = results depending on which test you are using for determining if the = header is a JWE or a JWS.  This belies the last sentence in = paragraph #2.

 

In Section = 4.1.1

 

It is stated that the = value of “alg” is case sensitive.  It is stated that it = may be a URI.  URIs say that there may be case insensitive portions = of the URI value.  This needs to be = reconciled.

 

 

 

 

From:= = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Friday, = July 06, 2012 11:13 AM
To: Jim Schaad; = jose@ietf.org
Subject: RE: json-web-encryption -02 = comments

 

Thanks once again.  Responses = inline…

 

-----Original Message-----
From: Jim Schaad [mailto:ietf@augustcellar= s.com]
Sent: Thursday, June 07, 2012 11:56 AM
To: jose@ietf.org; draft-= ietf-jose-json-web-encryption@tools.ietf.org
Subject: = json-web-encryption -02 comments

 

Introduction

 

1.  I would separate the introduction into two = paragraphs.  One to address the general encryption issue and one to = address the compact serialization issues.  This will allow for an = easier addition/removal to deal with other serialization = issues.

 

I’m somewhat = confused by this comment, as the introduction doesn’t discuss = serialization.  That concept isn’t introduced until the = “JWE Compact Serialization” term definition in Section 2 and = the presentation of the compact serialization in Section = 3.

 

[JLS] And I am = suggesting that the introduction SHOULD address the fact that a = serialization method is presented in this document.  The process of = encryption and the process of serialization are separate things and both = are covered in this document.  This should be documented in the = abstract.

 

This should also be = picked up in the abstract as well.

 

2.  I find sentence #2 confusing since this = document is defining how to do the encryption process so we are not = really dealing with pre-encrypted content which is what this appears to = me to say.

 

Like JWS, this = sentence has been clarified to:  It represents this content using = JavaScript Object Notation (JSON) <xref = target=3D"RFC4627"/> data = structures.

 

[JLS] I think that I = find the concept that it represents the content as JSON to be weird, = since the final formatting is actually dotted notation if you are = looking at the “compact encryption format” that was covered = in this document.

 

3.  What do you mean by the type of content = being encrypted?  This could either mean the format of the content = (i.e. JSON vs Mime) or the type of content (i.e. a JSON token vs a JSON = signature object).

 

This now reads:  = The JWE cryptographic mechanisms encrypt and provide integrity = protection for arbitrary sequences of bytes.

 

[JLS] I find this = confusing.  A MAC also provides integrity protection and that is in = a different document.

 

 

Section 3

 

1.  Simple clarity s/confidentiality of the = contents of the Plaintext/confidentiality of the = Plaintext/

 

Done

 

Section 4 - JWE Header

 

1.  Do we think parsers can enforce the = uniqueness requirement?

 

See my response in = the JWK comments

 

2.  What does it mean to reject a JWE?  = Should it decrypt and say it is a bad decrypt or should it fail to = decrypt?

 

It should return an = error and return no decrypted data

 

[JLS] This response = would eliminate that ability to do a stream based decode.  That = would return decrypted data and then return the = error.

 

Section 4.1.1

 

1.  You should be constant about what  = you call the encryption key, master key or JWE Encrypted key.  A = search and replace should be done to make them = constant.

 

Now using the term = Content Master Key (CMK) here.  Note that the Content Encryption = Key (CMK) is distinct from (and derived from) the = CMK.

 

2.  Refer to the registry not to the document = for the list of algorithms.

 

Moved the document = reference to be adjacent to the registry reference, saying that both = apply

 

Section 4.1.2

 

1. See = comment 2 above

 

Ditto

 

2.  the encryption algorithm is not used to = secure the cipher text.  It is used to produce the cipher = text

 

Corrected

 

3.  Why does the enc algorithm not require the = existence of a key for it's use?

 

Because the CEK is = derived from the CMK, and so always exists

 

[JLS] and how is that = key known?  Is a wrapped key always required in this case.  =

 

Section 4.1.4

 

 

2.  The presence of this parameter MUST be = specified for all content encryption algorithms.

 

It is, in JWA.  = Also clarified that it is REQUIRED with some “enc” = algorithms.

 

Section 4.1.5

 

1.  See comment 2 above - alternate language = would be say MUST be absent unless otherwise specified by the = algorithm.

 

It is, in JWA.  = Also clarified that it is REQUIRED with some “alg” = algorithms.

 

[JLS] Then I assume = that the following is legal

{ = alg:”RSA1_5”, epk:{…}, = …}

 

2.  epk should talk about key agreement = algorithms not a specific algorithm.

 

Done

 

3.  Content of the key should be specified by = the algorithm and not by this document.

 

Done

 

Section 4.1.6

 

1.  Should specify the use the "alg" = registry for the zip parameter (in case a new one comes into existence) = and this algorithm should be registered as the only = algorithm.

 

This could be done, = but it is counter to an explicit working group decision to support only = one compression algorithm.  I’d be glad to do this if the WG = decides to open the door to the possibility of additional = algorithms.

 

[JLS]  I do not = feel that this means that it should not be registered.  It merely = means that we will only register one, and we will make the bar very high = for the ability to register a second one.  Otherwise this should be = a Boolean with a value of true.  It either is or is not = compressed.

 

Section 4.1.7

 

1.  Should make clear that this is the way of = identifying what private key is needed to decrypt the = content.

 

Added: this can be = used to determine the private key needed to decrypt the = JWE

 

2.  Should this be used?  It implies that = the decryptor needs to do the

following:

a) = Get the keys

b) For each key = -

   i) Do I have the = private key for this?

   = ii) Does it match the algorithm?

   iii) Does it work?

c) if no function keys found then = ---???

 

Also, the decryptor = might use “kid” and/or “use” parameters for = deciding which key(s) to use.  Obviously, if no applicable key can = be located, the decryption will fail.

 

Section 4.1.8

 

1.  See comment 1 above.

 

Ditto

 

Section 4.1.9

 

1.  I would eliminate the (implicit) = requirement that the certificate be validated before decryption.  = There is no reason that a client should not be able to decrypt a message = to themselves if their certificate has been revoked or is expired.  = This is just a requirement at send time.

 

What do others in the = working group think of potentially relaxing this requirement?  If = we do relax it, what alternative language should be = used?

 

Section 4.1.11

 

1.  I don't understand the format used = here.  The data could be either encoded as a string or an array of = strings or something else that is a concatenated string = form.

 

I’ve added an = example to clarify this.  See http://tools.ietf.org/html/draft-ietf-jose-json-web-signature= -03#appendix-B

 

[JLS] That is nice = that you have added an example.  However this does not mean that = the text should not be clarified.  I think that you really want to = say that this field is an array of strings, each element in the array = being a base64url encoded certificate.  The certificates are = ordered such that certificate i is issued by certificate i+1. =

 

Is it legal for a = partial chain to be presented or must the full chain always be = presented?

 

Is there a reason = that you are not just using the PEM encoding in this location as = well?

 

If there is a = requirement for having a chain of certificates in this location, why is = there not a requirement for having an array of certificates in the x5t = case?

 

As a recipient I = should never need more than the EE certificate in order to map from a = public key to a private key.   Other than letting me know what = the chain was that the sender used to validate my certificate, I = don’t know what the reasoning behind sending the chain would = be.

 

2.  Why is this not base64url encoded given = that all other locations are?

 

So we’re using = a standard encoding for certificate chains

 

[JLS] A standard = encoding would be using the PEM string or using a CMS certs only.  =  Changing the base64url to remove trailing characters is not really = an issue.   Unless the new JavaScript CryptoAPIs (as an = example) take a base64 encoded certificate as input the user code is = going to deal with the encoding/decoding question = anyway.

 

3. See comment 1 above

 

Ditto

 

Section 4.1.12

 

1.  This is so underspecified that I would = know how to go about using it.

Any = code that I wrote would therefore ignore it.

 

Added: =     When used with a JWK, the “kid” value MAY = be used to match a JWK “kid” parameter = value.

 

[JLS] This does = nothing to change my statement above.  In fact it enforces = it. 

 

Section 4.1.13

 

1.  The list of possible typ values should = apparently include the mime registry as well.  This is neither in = the value registry (which should probably be setup to avoid collisions = with mime types) or a URI.

 

See the new Section 7.2 in = JWS

 

[JLS] I do not = believe that mime types and subtypes are case insensitive values in MIME = itself.  This needs to be resolved.

 

Section 4.2

 

1.  Should re-iterate the "if you don't = know it then reject it" sentence here - it has been a long time = since we have seen it.

 

(Ditto = for section 4.3)

 

I understand why = you’re saying this, but we did say “Implementations MUST = understand the entire contents of the header; otherwise, the JWE MUST be = rejected” in the enclosing section introduction (Section 4), so = I’m reluctant to repeat it in 4.2 and especially reluctant to = repeat it again so soon in 4.3.

 

Section 5

 

1.  I disagree with the concept of using a key = agree algorithm to create the

CMK.   Look at CMS to see how they handle = key agree algorithms to create a

key wrap key

 

The key wrap key is = unnecessary, as far as I can tell, at least when there’s a single = recipient.  It results in an additional encryption step that seems = to me to add no additional security.

 

However, per James = Manger’s note and my response to it, I do understand that value of = having a CMK in the multiple recipients case.  I’ve added = this topic to the list of open issues for the working group to = discuss.

 

2.  In step 8 - when did you create the = encoded JWE header?

 

In step 9. :-)  = Yes, I’d already seen this and fixed it.

 

3.  Separate the serialization format from the = encryption algorithm.  This may just affect step = 14.

 

Done

 

4.  Note previous discussion on only = documenting AEAD algorithms

 

I’m not sure = what change you’re asking for here?

 

[JLS] I am asking = that there only be one set of steps for doing this, and it is for AEAD = algorithms. 

 

Section 6

 

1.  Separate serialization from message = decryption.  If alternate serializations are used then step 1 = fails.

 

Done

 

2.  Note that you have imposed some additional = restrictions on the JSE header in step three - specifically that no = duplicate fields exist.  This is not in the decryption = process.

 

It’s input = validation for the decryption process, just like step 2 = was

 

Section 7

 

1.  If you are using the NIST KDF function, = then the length of the output key should really be included in the = OtherInfo

 

Again, per my earlier = responses to you and Sean on this topic from your JWA comments, since = the CMK is randomly generated for each encryption, I believe that the = additional parameters add no security value.  Adding a key length = would only make sense if we were going to use this same CMK to generate = other keys using the same Label (“Encryption” or = “Integrity”) but with a different key length.  But we = never will, so I believe that the parameter is = superfluous.

 

Section 8.1

 

1.  Refer to the registry not to the document = (ditto for section 8.2)

 

Done

 

Section 11.1

 

1.  Should there be an optional parameter = which describes which serialization method is being = used?

 

This could be = introduced if the working group adopts a second serialization method, = such as the JSON Serialization defined in = draft-jones-json-web-encryption-json-serialization, or one of the other = candidates.  However, a better approach might be to define a = different media type value, such as application/jwe-js for the different = serialization.

 

Of course, if we have = a pure JSON serialization, one could argue for just using the = application/json media type.

 

2.  Check with IANA if you or the IESG should = be listed under the contact section.

 

Will = do

 

------=_NextPart_000_01F4_01CD6381.1AC2AFB0-- From Michael.Jones@microsoft.com Mon Jul 16 18:47:28 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B5221F8680 for ; Mon, 16 Jul 2012 18:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.789 X-Spam-Level: X-Spam-Status: No, score=-3.789 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FT5HdyRAJppk for ; Mon, 16 Jul 2012 18:47:26 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id A437C21F867F for ; Mon, 16 Jul 2012 18:47:25 -0700 (PDT) Received: from mail40-db3-R.bigfish.com (10.3.81.232) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Tue, 17 Jul 2012 01:48:10 +0000 Received: from mail40-db3 (localhost [127.0.0.1]) by mail40-db3-R.bigfish.com (Postfix) with ESMTP id CE16D34042A for ; Tue, 17 Jul 2012 01:48:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VS-19(zzc89bhc857hzz1202hzz1033IL8275eh8275bh8275dha1495iz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail40-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail40-db3 (localhost.localdomain [127.0.0.1]) by mail40-db3 (MessageSwitch) id 1342489688284927_28007; Tue, 17 Jul 2012 01:48:08 +0000 (UTC) Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.252]) by mail40-db3.bigfish.com (Postfix) with ESMTP id 41A5A18003F for ; Tue, 17 Jul 2012 01:48:08 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 17 Jul 2012 01:48:04 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0298.005; Tue, 17 Jul 2012 01:48:03 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Pre-IETF 84 versions of JOSE and JWT specifications Thread-Index: Ac1jvi7UzNEBrsZqQ5eOGepqIcCCOQ== Date: Tue, 17 Jul 2012 01:48:02 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943667349B0@TK5EX14MBXC285.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943667349B0TK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [jose] Pre-IETF 84 versions of JOSE and JWT specifications X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 01:47:28 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943667349B0TK5EX14MBXC285r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmXZlIG1hZGUgYSBtaW5vciByZWxlYXNlIG9mIHRoZSBKU09OIFdFQiB7U2lnbmF0dXJlLEVu Y3J5cHRpb24sS2V5LEFsZ29yaXRobXMsVG9rZW59IChKV1MsIEpXRSwgSldLLCBKV0EsIEpXVCkg d29ya2luZyBncm91cCBzcGVjaWZpY2F0aW9ucyBhbmQgdGhlIEpXUyBhbmQgSldFIEpTT04gU2Vy aWFsaXphdGlvbiAoSldTLUpTLCBKV0UtSlMpIGluZGl2aWR1YWwgc3VibWlzc2lvbiBzcGVjaWZp Y2F0aW9ucyBpbiBwcmVwYXJhdGlvbiBmb3IgSUVURiA4NCBpbiBWYW5jb3V2ZXIsIEJDPGh0dHA6 Ly93d3cuaWV0Zi5vcmcvbWVldGluZy84NC9pbmRleC5odG1sPi4gIFRoZXNlIHZlcnNpb25zIGlu Y29ycG9yYXRlIGZlZWRiYWNrIGZyb20gd29ya2luZyBncm91cCBtZW1iZXJzIHNpbmNlIHRoZSBt YWpvciByZWxlYXNlIG9uIEp1bHkgNnRoPGh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvLz9wPTc1OT4s IGFuZCB1cGRhdGUgdGhlIGxpc3RzIG9mIG9wZW4gaXNzdWVzIGluIHByZXBhcmF0aW9uIGZvciBk aXNjdXNzaW9ucyBpbiBWYW5jb3V2ZXIgKGFuZCBvbiB0aGUgd29ya2luZyBncm91cCBtYWlsaW5n IGxpc3RzKS4NCg0KT25lIHNpZ25pZmljYW50IGFkZGl0aW9uIGlzIHRoYXQgdGhlIEpXVCBhbmQg SldFLUpTIHNwZWNzIGJvdGggbm93IGNvbnRhaW4gY29tcGxldGUsIHRlc3RhYmxlIGV4YW1wbGVz IHdpdGggZW5jcnlwdGVkIHJlc3VsdHMuICBObyBub3JtYXRpdmUgY2hhbmdlcyB3ZXJlIG1hZGUu DQoNClRoZSB3b3JraW5nIGdyb3VwIHNwZWNpZmljYXRpb25zIGFyZSBhdmFpbGFibGUgYXQ6DQoN CsK3ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNv bi13ZWItc2lnbmF0dXJlLTA0DQoNCsK3ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItZW5jcnlwdGlvbi0wNA0KDQrCtyAgICAgICAgaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS0wNA0K DQrCtyAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpz b24td2ViLWFsZ29yaXRobXMtMDQNCg0KwrcgICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMDINCg0KVGhlIGluZGl2aWR1YWwg c3VibWlzc2lvbiBzcGVjaWZpY2F0aW9ucyBhcmUgYXZhaWxhYmxlIGF0Og0KDQrCtyAgICAgICAg aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtam9zZS1qd3MtanNvbi1zZXJp YWxpemF0aW9uLTAxDQoNCsK3ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1qb25lcy1qb3NlLWp3ZS1qc29uLXNlcmlhbGl6YXRpb24tMDENCg0KVGhlIGRvY3VtZW50IGhp c3RvcnkgZW50cmllcyAoYWxzbyBpbiB0aGUgc3BlY2lmaWNhdGlvbnMpIGFyZSBhcyBmb2xsb3dz Og0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIt c2lnbmF0dXJlLTA0DQoNCiAgKiAgIENvbXBsZXRlZCBKU09OIFNlY3VyaXR5IENvbnNpZGVyYXRp b25zIHNlY3Rpb24sIGluY2x1ZGluZyBjb25zaWRlcmF0aW9ucyBhYm91dCByZWplY3RpbmcgaW5w dXQgd2l0aCBkdXBsaWNhdGUgbWVtYmVyIG5hbWVzLg0KICAqICAgQ29tcGxldGVkIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIG9uIHRoZSB1c2Ugb2YgYSBTSEEtMSBoYXNoIHdoZW4gY29tcHV0aW5n IHg1dCAoeC41MDkgY2VydGlmaWNhdGUgdGh1bWJwcmludCkgdmFsdWVzLg0KICAqICAgUmVmZXIg dG8gdGhlIHJlZ2lzdHJpZXMgYXMgdGhlIHByaW1hcnkgc291cmNlcyBvZiBkZWZpbmVkIHZhbHVl cyBhbmQgdGhlbiBzZWNvbmRhcmlseSByZWZlcmVuY2UgdGhlIHNlY3Rpb25zIGRlZmluaW5nIHRo ZSBpbml0aWFsIGNvbnRlbnRzIG9mIHRoZSByZWdpc3RyaWVzLg0KICAqICAgTm9ybWF0aXZlbHkg cmVmZXJlbmNlIFhNTCBEU0lHIDIuMCBbVzNDLkNS4oCReG1sZHNpZ+KAkWNvcmUy4oCRMjAxMjAx MjRdIGZvciBpdHMgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuDQogICogICBBZGRlZCB0aGlzIGxh bmd1YWdlIHRvIFJlZ2lzdHJhdGlvbiBUZW1wbGF0ZXM6ICJUaGlzIG5hbWUgaXMgY2FzZSBzZW5z aXRpdmUuIE5hbWVzIHRoYXQgbWF0Y2ggb3RoZXIgcmVnaXN0ZXJlZCBuYW1lcyBpbiBhIGNhc2Ug aW5zZW5zaXRpdmUgbWFubmVyIFNIT1VMRCBOT1QgYmUgYWNjZXB0ZWQuIg0KICAqICAgUmVmZXJl bmNlIGRyYWZ0LWpvbmVzLWpvc2UtandzLWpzb24tc2VyaWFsaXphdGlvbiBpbnN0ZWFkIG9mIGRy YWZ0LWpvbmVzLWpzb24td2ViLXNpZ25hdHVyZS1qc29uLXNlcmlhbGl6YXRpb24uDQogICogICBE ZXNjcmliZWQgYWRkaXRpb25hbCBvcGVuIGlzc3Vlcy4NCiAgKiAgIEFwcGxpZWQgZWRpdG9yaWFs IHN1Z2dlc3Rpb25zLg0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpv c2UtanNvbi13ZWItZW5jcnlwdGlvbi0wNA0KDQogICogICBSZWZlciB0byB0aGUgcmVnaXN0cmll cyBhcyB0aGUgcHJpbWFyeSBzb3VyY2VzIG9mIGRlZmluZWQgdmFsdWVzIGFuZCB0aGVuIHNlY29u ZGFyaWx5IHJlZmVyZW5jZSB0aGUgc2VjdGlvbnMgZGVmaW5pbmcgdGhlIGluaXRpYWwgY29udGVu dHMgb2YgdGhlIHJlZ2lzdHJpZXMuDQogICogICBOb3JtYXRpdmVseSByZWZlcmVuY2UgWE1MIEVu Y3J5cHRpb24gMS4xIFtXM0MuQ1LigJF4bWxlbmPigJFjb3JlMeKAkTIwMTIwMzEzXSBmb3IgaXRz IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLg0KICAqICAgUmVmZXJlbmNlIGRyYWZ0LWpvbmVzLWpv c2UtandlLWpzb24tc2VyaWFsaXphdGlvbiBpbnN0ZWFkIG9mIGRyYWZ0LWpvbmVzLWpzb24td2Vi LWVuY3J5cHRpb24tanNvbi1zZXJpYWxpemF0aW9uLg0KICAqICAgRGVzY3JpYmVkIGFkZGl0aW9u YWwgb3BlbiBpc3N1ZXMuDQogICogICBBcHBsaWVkIGVkaXRvcmlhbCBzdWdnZXN0aW9ucy4NCg0K aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS0w NA0KDQogICogICBSZWZlciB0byB0aGUgcmVnaXN0cmllcyBhcyB0aGUgcHJpbWFyeSBzb3VyY2Vz IG9mIGRlZmluZWQgdmFsdWVzIGFuZCB0aGVuIHNlY29uZGFyaWx5IHJlZmVyZW5jZSB0aGUgc2Vj dGlvbnMgZGVmaW5pbmcgdGhlIGluaXRpYWwgY29udGVudHMgb2YgdGhlIHJlZ2lzdHJpZXMuDQog ICogICBOb3JtYXRpdmVseSByZWZlcmVuY2UgWE1MIERTSUcgMi4wIFtXM0MuQ1LigJF4bWxkc2ln 4oCRY29yZTLigJEyMDEyMDEyNF0gZm9yIGl0cyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy4NCiAg KiAgIEFkZGVkIHRoaXMgbGFuZ3VhZ2UgdG8gUmVnaXN0cmF0aW9uIFRlbXBsYXRlczogIlRoaXMg bmFtZSBpcyBjYXNlIHNlbnNpdGl2ZS4gTmFtZXMgdGhhdCBtYXRjaCBvdGhlciByZWdpc3RlcmVk IG5hbWVzIGluIGEgY2FzZSBpbnNlbnNpdGl2ZSBtYW5uZXIgU0hPVUxEIE5PVCBiZSBhY2NlcHRl ZC4iDQogICogICBEZXNjcmliZWQgYWRkaXRpb25hbCBvcGVuIGlzc3Vlcy4NCiAgKiAgIEFwcGxp ZWQgZWRpdG9yaWFsIHN1Z2dlc3Rpb25zLg0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcy0wNA0KDQogICogICBBZGRlZCB0ZXh0 IHJlcXVpcmluZyB0aGF0IGFueSBsZWFkaW5nIHplcm8gYnl0ZXMgYmUgcmV0YWluZWQgaW4gYmFz ZTY0dXJsIGVuY29kZWQga2V5IHZhbHVlIHJlcHJlc2VudGF0aW9ucyBmb3IgZml4ZWQtbGVuZ3Ro IHZhbHVlcy4NCiAgKiAgIEFkZGVkIHRoaXMgbGFuZ3VhZ2UgdG8gUmVnaXN0cmF0aW9uIFRlbXBs YXRlczogIlRoaXMgbmFtZSBpcyBjYXNlIHNlbnNpdGl2ZS4gTmFtZXMgdGhhdCBtYXRjaCBvdGhl ciByZWdpc3RlcmVkIG5hbWVzIGluIGEgY2FzZSBpbnNlbnNpdGl2ZSBtYW5uZXIgU0hPVUxEIE5P VCBiZSBhY2NlcHRlZC4iDQogICogICBEZXNjcmliZWQgYWRkaXRpb25hbCBvcGVuIGlzc3Vlcy4N CiAgKiAgIEFwcGxpZWQgZWRpdG9yaWFsIHN1Z2dlc3Rpb25zLg0KDQpodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTAyDQoNCiAgKiAgIEFk ZGVkIGFuIGV4YW1wbGUgb2YgYW4gZW5jcnlwdGVkIEpXVC4NCiAgKiAgIEFkZGVkIHRoaXMgbGFu Z3VhZ2UgdG8gUmVnaXN0cmF0aW9uIFRlbXBsYXRlczogIlRoaXMgbmFtZSBpcyBjYXNlIHNlbnNp dGl2ZS4gTmFtZXMgdGhhdCBtYXRjaCBvdGhlciByZWdpc3RlcmVkIG5hbWVzIGluIGEgY2FzZSBp bnNlbnNpdGl2ZSBtYW5uZXIgU0hPVUxEIE5PVCBiZSBhY2NlcHRlZC4iDQogICogICBBcHBsaWVk IGVkaXRvcmlhbCBzdWdnZXN0aW9ucy4NCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtam9uZXMtam9zZS1qd3MtanNvbi1zZXJpYWxpemF0aW9uLTAxDQoNCiAgKiAgIEdlbmVyYWxp emVkIGxhbmd1YWdlIHRvIHJlZmVyIHRvIE1lc3NhZ2UgQXV0aGVudGljYXRpb24gQ29kZXMgKE1B Q3MpIHJhdGhlciB0aGFuIEhhc2gtYmFzZWQgTWVzc2FnZSBBdXRoZW50aWNhdGlvbiBDb2RlcyAo SE1BQ3MpLg0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1qb3NlLWp3 ZS1qc29uLXNlcmlhbGl6YXRpb24tMDENCg0KICAqICAgQWRkZWQgYSBjb21wbGV0ZSBKV0UtSlMg ZXhhbXBsZS4NCiAgKiAgIEdlbmVyYWxpemVkIGxhbmd1YWdlIHRvIHJlZmVyIHRvIE1lc3NhZ2Ug QXV0aGVudGljYXRpb24gQ29kZXMgKE1BQ3MpIHJhdGhlciB0aGFuIEhhc2gtYmFzZWQgTWVzc2Fn ZSBBdXRoZW50aWNhdGlvbiBDb2RlcyAoSE1BQ3MpLg0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCg== --_000_4E1F6AAD24975D4BA5B1680429673943667349B0TK5EX14MBXC285r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9z ZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 IjsNCgljb2xvcjojMDAzMzY2O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFn cmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1h cmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJ bWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxT dHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0 aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MzI5MjYyMTk0Ow0KCW1zby1saXN0LXRl bXBsYXRlLWlkczotNzg0MjcwOTM4O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlk aS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXtt c28tbGlzdC1pZDo4ODI5ODc0Njc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOjc2ODM1NzA2MCA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBs MTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28t bGlzdC1pZDo5NDA4MzYzMDk7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi04NzE0MDY4Njt9DQpA bGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MTA0MTkwNjQ4MDsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTg0MDIzNzA4ODt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDM6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDQNCgl7bXNvLWxpc3QtaWQ6MTQxNjg1NDg5NjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 MjIxMjU5MTcwO30NCkBsaXN0IGw0OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDQ6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsNDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsNDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs NDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsNDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNQ0KCXttc28tbGlzdC1pZDox NTQ2NTk5MTgyOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czotMjA0NDQyODYzMCA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5 MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsNTpsZXZlbDEN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs NTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGw1OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDU6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDU6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDU6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsNTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNg0KCXttc28tbGlzdC1pZDox ODc5NjU5MTY2Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNjg1NzE4ODA0O30NCkBsaXN0IGw2 OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDY6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9 DQpAbGlzdCBsNjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNjpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNjpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsNjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsNjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNjpsZXZlbDgN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNjpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsNw0KCXttc28tbGlzdC1pZDoxOTA5NzI1Njc3Ow0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczotMTQ3OTY3MTQzMDt9DQpAbGlzdCBsNzpsZXZlbDENCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGw3OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNv LWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDc6bGV2ZWwzDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDc6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDc6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDc6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDc6bGV2ZWw3DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDc6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDc6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJl2ZSBtYWRlIGEgbWlu b3IgcmVsZWFzZSBvZiB0aGUgSlNPTiBXRUIge1NpZ25hdHVyZSxFbmNyeXB0aW9uLEtleSxBbGdv cml0aG1zLFRva2VufSAoSldTLCBKV0UsIEpXSywgSldBLCBKV1QpIHdvcmtpbmcgZ3JvdXAgc3Bl Y2lmaWNhdGlvbnMgYW5kIHRoZSBKV1MgYW5kIEpXRSBKU09OIFNlcmlhbGl6YXRpb24gKEpXUy1K UywgSldFLUpTKSBpbmRpdmlkdWFsIHN1Ym1pc3Npb24gc3BlY2lmaWNhdGlvbnMgaW4NCiBwcmVw YXJhdGlvbiBmb3IgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tZWV0aW5nLzg0L2luZGV4 Lmh0bWwiPklFVEYgODQgaW4gVmFuY291dmVyLCBCQzwvYT4uJm5ic3A7IFRoZXNlIHZlcnNpb25z IGluY29ycG9yYXRlIGZlZWRiYWNrIGZyb20gd29ya2luZyBncm91cCBtZW1iZXJzIHNpbmNlIHRo ZQ0KPGEgaHJlZj0iaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9NzU5Ij5tYWpvciByZWxlYXNl IG9uIEp1bHkgNjxzdXA+dGg8L3N1cD48L2E+LCBhbmQgdXBkYXRlIHRoZSBsaXN0cyBvZiBvcGVu IGlzc3VlcyBpbiBwcmVwYXJhdGlvbiBmb3IgZGlzY3Vzc2lvbnMgaW4gVmFuY291dmVyIChhbmQg b24gdGhlIHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0cykuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uZSBzaWduaWZpY2FudCBhZGRpdGlvbiBpcyB0aGF0IHRoZSBKV1QgYW5kIEpXRS1KUyBz cGVjcyBib3RoIG5vdyBjb250YWluIGNvbXBsZXRlLCB0ZXN0YWJsZSBleGFtcGxlcyB3aXRoIGVu Y3J5cHRlZCByZXN1bHRzLiZuYnNwOyBObyBub3JtYXRpdmUgY2hhbmdlcyB3ZXJlIG1hZGUuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB3b3JraW5nIGdyb3VwIHNwZWNpZmljYXRpb25zIGFy ZSBhdmFpbGFibGUgYXQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsNSBsZXZlbDEgbGZvMSI+PCFb aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1zaWduYXR1cmUtMDQi Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1zaWdu YXR1cmUtMDQ8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsNSBsZXZlbDEgbGZvMSI+PCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxhIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1lbmNyeXB0aW9uLTA0Ij5o dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItZW5jcnlw dGlvbi0wNDwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omw1IGxldmVsMSBsZm8xIj48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PGEgaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS0wNCI+aHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS0wNDwvYT48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0Omw1IGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXMtMDQiPmh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zLTA0PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVu dDotLjI1aW47bXNvLWxpc3Q6bDUgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTAyIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTAyPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUgaW5kaXZpZHVhbCBzdWJtaXNzaW9uIHNwZWNpZmljYXRpb25zIGFyZSBh dmFpbGFibGUgYXQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+PCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxhIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVzLWpvc2UtandzLWpzb24tc2VyaWFsaXphdGlvbi0w MSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtam9zZS1qd3MtanNvbi1z ZXJpYWxpemF0aW9uLTAxPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIi PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1qb3NlLWp3ZS1qc29uLXNlcmlhbGl6 YXRpb24tMDEiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVzLWpvc2Utandl LWpzb24tc2VyaWFsaXphdGlvbi0wMTwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGRv Y3VtZW50IGhpc3RvcnkgZW50cmllcyAoYWxzbyBpbiB0aGUgc3BlY2lmaWNhdGlvbnMpIGFyZSBh cyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItc2lnbmF0dXJlLTA0Ij5odHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItc2lnbmF0dXJl LTA0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0i ZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1saXN0 Omw0IGxldmVsMSBsZm8zIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5D b21wbGV0ZWQgSlNPTiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLCBpbmNsdWRpbmcg Y29uc2lkZXJhdGlvbnMgYWJvdXQgcmVqZWN0aW5nIGlucHV0IHdpdGggZHVwbGljYXRlIG1lbWJl cg0KIG5hbWVzLiA8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iY29sb3I6YmxhY2s7bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzMiPjxzcGFuIGxhbmc9IkVO IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNvbXBsZXRlZCBzZWN1cml0eSBjb25zaWRlcmF0aW9u cyBvbiB0aGUgdXNlIG9mIGEgU0hBLTEgaGFzaCB3aGVuIGNvbXB1dGluZw0KPC9zcGFuPjx0dD48 c3BhbiBsYW5nPSJFTiI+eDV0PC9zcGFuPjwvdHQ+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+ICh4LjUwOSBjZXJ0aWZpY2F0ZSB0aHVtYnByaW50KSB2YWx1ZXMuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6Ymxh Y2s7bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPlJlZmVyIHRvIHRoZSByZWdpc3RyaWVzIGFzIHRoZSBwcmltYXJ5IHNvdXJjZXMg b2YgZGVmaW5lZCB2YWx1ZXMgYW5kIHRoZW4gc2Vjb25kYXJpbHkgcmVmZXJlbmNlIHRoZSBzZWN0 aW9ucyBkZWZpbmluZw0KIHRoZSBpbml0aWFsIGNvbnRlbnRzIG9mIHRoZSByZWdpc3RyaWVzLiA8 bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6 YmxhY2s7bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPk5vcm1hdGl2ZWx5IHJlZmVyZW5jZSBYTUwgRFNJRyAyLjAgW1czQy5DUuKA kXhtbGRzaWfigJFjb3JlMuKAkTIwMTIwMTI0XSBmb3IgaXRzIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zLg0KPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImNvbG9yOmJsYWNrO21zby1saXN0Omw0IGxldmVsMSBsZm8zIj48c3BhbiBsYW5nPSJFTiIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5BZGRlZCB0aGlzIGxhbmd1YWdlIHRvIFJlZ2lzdHJhdGlvbiBU ZW1wbGF0ZXM6ICZxdW90O1RoaXMgbmFtZSBpcyBjYXNlIHNlbnNpdGl2ZS4gTmFtZXMgdGhhdCBt YXRjaCBvdGhlciByZWdpc3RlcmVkIG5hbWVzDQogaW4gYSBjYXNlIGluc2Vuc2l0aXZlIG1hbm5l ciBTSE9VTEQgTk9UIGJlIGFjY2VwdGVkLiZxdW90OyA8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLWxpc3Q6bDQgbGV2ZWwx IGxmbzMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJlZmVyZW5jZSBk cmFmdC1qb25lcy1qb3NlLWp3cy1qc29uLXNlcmlhbGl6YXRpb24gaW5zdGVhZCBvZiBkcmFmdC1q b25lcy1qc29uLXdlYi1zaWduYXR1cmUtanNvbi1zZXJpYWxpemF0aW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbGlz dDpsNCBsZXZlbDEgbGZvMyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RGVzY3JpYmVkIGFkZGl0aW9uYWwgb3BlbiBpc3N1ZXMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2xp PjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLWxpc3Q6bDQgbGV2 ZWwxIGxmbzMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFwcGxpZWQg ZWRpdG9yaWFsIHN1Z2dlc3Rpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpz b24td2ViLWVuY3J5cHRpb24tMDQiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtam9zZS1qc29uLXdlYi1lbmNyeXB0aW9uLTA0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0 eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImNvbG9yOmJsYWNrO21zby1saXN0OmwyIGxldmVsMSBsZm80Ij48c3BhbiBsYW5nPSJF TiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SZWZlciB0byB0aGUgcmVnaXN0cmllcyBhcyB0aGUg cHJpbWFyeSBzb3VyY2VzIG9mIGRlZmluZWQgdmFsdWVzIGFuZCB0aGVuIHNlY29uZGFyaWx5IHJl ZmVyZW5jZSB0aGUgc2VjdGlvbnMgZGVmaW5pbmcNCiB0aGUgaW5pdGlhbCBjb250ZW50cyBvZiB0 aGUgcmVnaXN0cmllcy4gPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1saXN0OmwyIGxldmVsMSBsZm80Ij48c3BhbiBsYW5n PSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Ob3JtYXRpdmVseSByZWZlcmVuY2UgWE1MIEVu Y3J5cHRpb24gMS4xIFtXM0MuQ1LigJF4bWxlbmPigJFjb3JlMeKAkTIwMTIwMzEzXSBmb3IgaXRz IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLg0KPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1saXN0OmwyIGxldmVsMSBsZm80 Ij48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SZWZlcmVuY2UgZHJhZnQt am9uZXMtam9zZS1qd2UtanNvbi1zZXJpYWxpemF0aW9uIGluc3RlYWQgb2YgZHJhZnQtam9uZXMt anNvbi13ZWItZW5jcnlwdGlvbi1qc29uLXNlcmlhbGl6YXRpb24uDQo8bzpwPjwvbzpwPjwvc3Bh bj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLWxpc3Q6 bDIgbGV2ZWwxIGxmbzQiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRl c2NyaWJlZCBhZGRpdGlvbmFsIG9wZW4gaXNzdWVzLg0KPG86cD48L286cD48L3NwYW4+PC9saT48 bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1saXN0OmwyIGxldmVs MSBsZm80Ij48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BcHBsaWVkIGVk aXRvcmlhbCBzdWdnZXN0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29u LXdlYi1rZXktMDQiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1q c29uLXdlYi1rZXktMDQ8L2E+PG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6 MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6Ymxh Y2s7bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzUiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPlJlZmVyIHRvIHRoZSByZWdpc3RyaWVzIGFzIHRoZSBwcmltYXJ5IHNvdXJjZXMg b2YgZGVmaW5lZCB2YWx1ZXMgYW5kIHRoZW4gc2Vjb25kYXJpbHkgcmVmZXJlbmNlIHRoZSBzZWN0 aW9ucyBkZWZpbmluZw0KIHRoZSBpbml0aWFsIGNvbnRlbnRzIG9mIHRoZSByZWdpc3RyaWVzLiA8 bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6 YmxhY2s7bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzUiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPk5vcm1hdGl2ZWx5IHJlZmVyZW5jZSBYTUwgRFNJRyAyLjAgW1czQy5DUuKA kXhtbGRzaWfigJFjb3JlMuKAkTIwMTIwMTI0XSBmb3IgaXRzIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zLg0KPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImNvbG9yOmJsYWNrO21zby1saXN0OmwzIGxldmVsMSBsZm81Ij48c3BhbiBsYW5nPSJFTiIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5BZGRlZCB0aGlzIGxhbmd1YWdlIHRvIFJlZ2lzdHJhdGlvbiBU ZW1wbGF0ZXM6ICZxdW90O1RoaXMgbmFtZSBpcyBjYXNlIHNlbnNpdGl2ZS4gTmFtZXMgdGhhdCBt YXRjaCBvdGhlciByZWdpc3RlcmVkIG5hbWVzDQogaW4gYSBjYXNlIGluc2Vuc2l0aXZlIG1hbm5l ciBTSE9VTEQgTk9UIGJlIGFjY2VwdGVkLiZxdW90OyA8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLWxpc3Q6bDMgbGV2ZWwx IGxmbzUiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlc2NyaWJlZCBh ZGRpdGlvbmFsIG9wZW4gaXNzdWVzLg0KPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1saXN0OmwzIGxldmVsMSBsZm81Ij48 c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BcHBsaWVkIGVkaXRvcmlhbCBz dWdnZXN0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdv cml0aG1zLTA0Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNv bi13ZWItYWxnb3JpdGhtcy0wNDwvYT48bzpwPjwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2lu LXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xv cjpibGFjazttc28tbGlzdDpsMCBsZXZlbDEgbGZvNiI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+QWRkZWQgdGV4dCByZXF1aXJpbmcgdGhhdCBhbnkgbGVhZGluZyB6ZXJv IGJ5dGVzIGJlIHJldGFpbmVkIGluIGJhc2U2NHVybCBlbmNvZGVkIGtleSB2YWx1ZSByZXByZXNl bnRhdGlvbnMgZm9yIGZpeGVkLWxlbmd0aA0KIHZhbHVlcy4gPG86cD48L286cD48L3NwYW4+PC9s aT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1saXN0OmwwIGxl dmVsMSBsZm82Ij48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BZGRlZCB0 aGlzIGxhbmd1YWdlIHRvIFJlZ2lzdHJhdGlvbiBUZW1wbGF0ZXM6ICZxdW90O1RoaXMgbmFtZSBp cyBjYXNlIHNlbnNpdGl2ZS4gTmFtZXMgdGhhdCBtYXRjaCBvdGhlciByZWdpc3RlcmVkIG5hbWVz DQogaW4gYSBjYXNlIGluc2Vuc2l0aXZlIG1hbm5lciBTSE9VTEQgTk9UIGJlIGFjY2VwdGVkLiZx dW90OyA8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i Y29sb3I6YmxhY2s7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzYiPjxzcGFuIGxhbmc9IkVOIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkRlc2NyaWJlZCBhZGRpdGlvbmFsIG9wZW4gaXNzdWVzLg0KPG86 cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJs YWNrO21zby1saXN0OmwwIGxldmVsMSBsZm82Ij48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5BcHBsaWVkIGVkaXRvcmlhbCBzdWdnZXN0aW9ucy48bzpwPjwvbzpwPjwvc3Bh bj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMDIiPmh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMDI8L2E+PG86cD48L286cD48 L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLWxpc3Q6bDYgbGV2ZWwxIGxmbzciPjxz cGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFkZGVkIGFuIGV4YW1wbGUgb2Yg YW4gZW5jcnlwdGVkIEpXVC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbGlzdDpsNiBsZXZlbDEgbGZvNyI+PHNwYW4g bGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QWRkZWQgdGhpcyBsYW5ndWFnZSB0byBS ZWdpc3RyYXRpb24gVGVtcGxhdGVzOiAmcXVvdDtUaGlzIG5hbWUgaXMgY2FzZSBzZW5zaXRpdmUu IE5hbWVzIHRoYXQgbWF0Y2ggb3RoZXIgcmVnaXN0ZXJlZCBuYW1lcw0KIGluIGEgY2FzZSBpbnNl bnNpdGl2ZSBtYW5uZXIgU0hPVUxEIE5PVCBiZSBhY2NlcHRlZC4mcXVvdDsgPG86cD48L286cD48 L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1s aXN0Omw2IGxldmVsMSBsZm83Ij48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5BcHBsaWVkIGVkaXRvcmlhbCBzdWdnZXN0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwv dWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpv bmVzLWpvc2UtandzLWpzb24tc2VyaWFsaXphdGlvbi0wMSI+aHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtam9uZXMtam9zZS1qd3MtanNvbi1zZXJpYWxpemF0aW9uLTAxPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1saXN0Omw3IGxldmVsMSBs Zm84Ij48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5HZW5lcmFsaXplZCBs YW5ndWFnZSB0byByZWZlciB0byBNZXNzYWdlIEF1dGhlbnRpY2F0aW9uIENvZGVzIChNQUNzKSBy YXRoZXIgdGhhbiBIYXNoLWJhc2VkIE1lc3NhZ2UgQXV0aGVudGljYXRpb24NCiBDb2RlcyAoSE1B Q3MpLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtam9zZS1qd2UtanNvbi1zZXJpYWxpemF0 aW9uLTAxIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1qb3NlLWp3ZS1q c29uLXNlcmlhbGl6YXRpb24tMDE8L2E+PG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdp bi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29s b3I6YmxhY2s7bXNvLWxpc3Q6bDcgbGV2ZWwxIGxmbzgiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkFkZGVkIGEgY29tcGxldGUgSldFLUpTIGV4YW1wbGUuDQo8bzpwPjwv bzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7 bXNvLWxpc3Q6bDcgbGV2ZWwxIGxmbzgiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkdlbmVyYWxpemVkIGxhbmd1YWdlIHRvIHJlZmVyIHRvIE1lc3NhZ2UgQXV0aGVudGlj YXRpb24gQ29kZXMgKE1BQ3MpIHJhdGhlciB0aGFuIEhhc2gtYmFzZWQgTWVzc2FnZSBBdXRoZW50 aWNhdGlvbg0KIENvZGVzIChITUFDcykuPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B1680429673943667349B0TK5EX14MBXC285r_-- From hdknr@ic-tact.co.jp Mon Jul 16 22:25:47 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55CD711E80A2 for ; Mon, 16 Jul 2012 22:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9V7DaBX96HnP for ; Mon, 16 Jul 2012 22:25:46 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8097311E809C for ; Mon, 16 Jul 2012 22:25:46 -0700 (PDT) Received: by ghbg16 with SMTP id g16so15511ghb.31 for ; Mon, 16 Jul 2012 22:26:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=Sc0vBkEbfO1jvRSQ0bD66uNbgDPAVOvm28q3eDv3WH8=; b=cfoH4wpuoYSomxDMQh+99ryIcA3ucWBcUMJz1bhCphhCi53rEgxkwkqhaHRyEPzkye YmviNaZxCasCxC2Dl1e/g9uQ9/qArmZ6s2GYSSNu4TtyxFbsEMoFBfebr2uahZHcdzBt 1r/xOsSjZUgr+thn8OlAAalhLR8cA1Haeekbfa5kucRL3feqHeC5B0usFo4VsaaILqN1 RsyGyvPGlc8oz0YAgDLMHvK6rCYXnHrkKWJcLvgaUGaBcZFsgSVzOEY/yr/3UQeVKov5 SY19UuHYVvDa99GXI4W/ihqGv2PGMpVPacw4zPfdO0oY/J0lLWYzzH3XcMaKmJzszWkP rkfA== MIME-Version: 1.0 Received: by 10.66.84.129 with SMTP id z1mr2670949pay.4.1342502792028; Mon, 16 Jul 2012 22:26:32 -0700 (PDT) Received: by 10.66.249.197 with HTTP; Mon, 16 Jul 2012 22:26:31 -0700 (PDT) Date: Tue, 17 Jul 2012 14:26:31 +0900 Message-ID: From: hideki nara To: "jose@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnc3jSmRSBY57eguQ4tK/Sbb5ozrlDo7puJmTkctUulMuA0WAJJExpdOGKYi80QyIiYA3dg Cc: Jim Schaad Subject: [jose] JWS header x5c is a JSON arrary? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 05:25:47 -0000 Hi all, In http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-03#section-4.1.6 , "The certificate or certificate chain is represented as an array of certificate values. " But, Appendix B gives us a text stream which seems to be the same one as the return from "x5u" . (http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-03#appendix-B ) Am I missing anything between lines ? I like the same format as the return of x5u anyway. --- hdknr From ietf@augustcellars.com Mon Jul 16 22:49:41 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D07A11E80B6 for ; Mon, 16 Jul 2012 22:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJpH94jNamru for ; Mon, 16 Jul 2012 22:49:40 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id B633511E809C for ; Mon, 16 Jul 2012 22:49:40 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 6051C2CA1F for ; Mon, 16 Jul 2012 22:50:26 -0700 (PDT) From: "Jim Schaad" To: Date: Mon, 16 Jul 2012 22:49:01 -0700 Message-ID: <024b01cd63df$e043a9c0$a0cafd40$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac1j35gx13pv4HaTTraqGj/jBEaDVA== Content-Language: en-us Subject: [jose] Vancouver Agenda X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 05:49:41 -0000 I have posted a preliminary agenda. Please feel free to bash it either in public or in private. The list of open issues is extracted from my list and from the list of open issues in the documents. The order of the issues is totally arbitrary and the order that they are addressed at the meeting will probably be different than the order currently listed. If you have issues you want to add please let me know If you want to start discussing the issues on the mailing list now - That is a good thing and is strongly encouraged Jim From Michael.Jones@microsoft.com Tue Jul 17 13:22:15 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11AF021F8702 for ; Tue, 17 Jul 2012 13:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.279 X-Spam-Level: X-Spam-Status: No, score=-5.279 tagged_above=-999 required=5 tests=[AWL=1.320, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d--wM8o76saG for ; Tue, 17 Jul 2012 13:22:14 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 607A321F86FF for ; Tue, 17 Jul 2012 13:22:14 -0700 (PDT) Received: from mail63-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.23; Tue, 17 Jul 2012 20:23:02 +0000 Received: from mail63-tx2 (localhost [127.0.0.1]) by mail63-tx2-R.bigfish.com (Postfix) with ESMTP id 579263200AD; Tue, 17 Jul 2012 20:23:02 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz9371I1454I542M4015Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail63-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail63-tx2 (localhost.localdomain [127.0.0.1]) by mail63-tx2 (MessageSwitch) id 1342556581266047_13664; Tue, 17 Jul 2012 20:23:01 +0000 (UTC) Received: from TX2EHSMHS032.bigfish.com (unknown [10.9.14.239]) by mail63-tx2.bigfish.com (Postfix) with ESMTP id 3E06C220061; Tue, 17 Jul 2012 20:23:01 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS032.bigfish.com (10.9.99.132) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 17 Jul 2012 20:23:01 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0298.005; Tue, 17 Jul 2012 20:23:00 +0000 From: Mike Jones To: Jim Schaad , "jose@ietf.org" Thread-Topic: [jose] Vancouver Agenda Thread-Index: Ac1j35gx13pv4HaTTraqGj/jBEaDVAAei3aQ Date: Tue, 17 Jul 2012 20:22:59 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436673796D@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <024b01cd63df$e043a9c0$a0cafd40$@augustcellars.com> In-Reply-To: <024b01cd63df$e043a9c0$a0cafd40$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] Vancouver Agenda X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 20:22:15 -0000 I'd like to request 5-10 minutes to discuss the JSON Serialization specific= ations. Logically, this should probably go either before or after Richard'= s JSMS discussion. Thanks, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Monday, July 16, 2012 10:49 PM To: jose@ietf.org Subject: [jose] Vancouver Agenda I have posted a preliminary agenda. Please feel free to bash it either in = public or in private. The list of open issues is extracted from my list and from the list of open= issues in the documents. The order of the issues is totally arbitrary and= the order that they are addressed at the meeting will probably be differen= t than the order currently listed. If you have issues you want to add please let me know If you want to start discussing the issues on the mailing list now - That i= s a good thing and is strongly encouraged Jim _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From rbarnes@bbn.com Wed Jul 18 06:40:11 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E693021F865C for ; Wed, 18 Jul 2012 06:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.609 X-Spam-Level: X-Spam-Status: No, score=-106.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJ8tZ1yM8kWP for ; Wed, 18 Jul 2012 06:40:11 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0701521F8659 for ; Wed, 18 Jul 2012 06:40:11 -0700 (PDT) Received: from dhcp89-089-123.bbn.com ([128.89.89.123]:59454) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SrUUu-000ASI-Lc for jose@ietf.org; Wed, 18 Jul 2012 09:41:00 -0400 From: Richard L. Barnes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Jul 2012 09:40:59 -0400 Message-Id: <6D454DBB-B4F8-46F5-BA21-E475534F65CD@bbn.com> To: jose@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [jose] JSON parsing pitfalls X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 13:40:12 -0000 I noticed the other day a widespread flaw in JSON parsers that makes = JSON parsing a lossy operation. I haven't worked out the implications, = but it seems worth thinking about, so I thought I would run it by the = group. The problem is that JSON does not require that field names MUST be = unique, only that they SHOULD. =46rom RFC 4627: " An object structure is represented as a pair of curly brackets surrounding zero or more name/value pairs (or members). A name is a string. A single colon comes after each name, separating the name from the value. A single comma separates a value from a following name. The names within an object SHOULD be unique. " Unfortunately, most JSON parsers are parsing into object constructs = where each field name references only one value. However, they will = happily parse JSON objects containing redundant fields -- they just set = each field value to the last value they saw for that name. So for = example, if we parse the following object ... { "foo": 1, "bar": 2, "foo": "This above all: to thine own self be = true." } ... then most parsers will return an object with two fields, which would = stringify to the following: { "foo": "This above all: to thine own self be true.", "bar": 2 } A demonstration in four languages is at the bottom of this message. =20 Like I said at the top, I'm not sure exactly what the implications of = this ambiguity are for this protocol. Thoughts? --Richard -----BEGIN json-error.sh----- #!/bin/bash BADHEADER=3D'{"typ":"JWT", "alg":"HS256", "alg":"hmac-md5"}' ###### Python python < EOF -----END json-error.sh-----= From Michael.Jones@microsoft.com Wed Jul 18 08:18:09 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F30D21F861A for ; Wed, 18 Jul 2012 08:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.79 X-Spam-Level: X-Spam-Status: No, score=-3.79 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiOQUjlY4thD for ; Wed, 18 Jul 2012 08:18:06 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 38FE621F85F3 for ; Wed, 18 Jul 2012 08:18:06 -0700 (PDT) Received: from mail261-va3-R.bigfish.com (10.7.14.236) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Wed, 18 Jul 2012 15:18:56 +0000 Received: from mail261-va3 (localhost [127.0.0.1]) by mail261-va3-R.bigfish.com (Postfix) with ESMTP id D0145400DA; Wed, 18 Jul 2012 15:18:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VS-26(zz9371Ic85fh542Mzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail261-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail261-va3 (localhost.localdomain [127.0.0.1]) by mail261-va3 (MessageSwitch) id 1342624716270432_15185; Wed, 18 Jul 2012 15:18:36 +0000 (UTC) Received: from VA3EHSMHS002.bigfish.com (unknown [10.7.14.236]) by mail261-va3.bigfish.com (Postfix) with ESMTP id DA3931C40044; Wed, 18 Jul 2012 15:18:22 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS002.bigfish.com (10.7.99.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 18 Jul 2012 15:18:20 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0298.005; Wed, 18 Jul 2012 15:18:01 +0000 From: Mike Jones To: Richard L.Barnes , "jose@ietf.org" Thread-Topic: [jose] JSON parsing pitfalls Thread-Index: AQHNZOr+GFvQ0EPSlUGfXxZ9fPMlapcvJQQA Date: Wed, 18 Jul 2012 15:18:00 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366739218@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <6D454DBB-B4F8-46F5-BA21-E475534F65CD@bbn.com> In-Reply-To: <6D454DBB-B4F8-46F5-BA21-E475534F65CD@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366739218TK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] JSON parsing pitfalls X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 15:18:09 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366739218TK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a known issue and already addressed in the specifications. Uniform= ly, each JSON structure definition includes language like "JWSs with duplic= ate Header Parameter Names MUST be rejected" (http://tools.ietf.org/html/dr= aft-ietf-jose-json-web-signature-04#section-4). Also, there is a Security = Considerations section specifically about JSON parsing issues (http://tools= .ietf.org/html/draft-ietf-jose-json-web-signature-04#section-8.2), which sa= ys: Strict JSON validation is a security requirement. If malformed JSON is rece= ived, then the intent of the sender is impossible to reliably discern. Ambi= guous and potentially exploitable situations could arise if the JSON parser= used does not reject malformed JSON syntax. Section 2.2 of the JavaScript Object Notation (JSON) specification [RFC4627= ] states "The names within an object SHOULD be unique", whereas this specif= ication states that "Header Parameter Names within this object MUST be uniq= ue; JWSs with duplicate Header Parameter Names MUST be rejected". Thus, thi= s specification requires that the Section 2.2 "SHOULD" be treated as a "MUS= T". Ambiguous and potentially exploitable situations could arise if the JSO= N parser used does not enforce the uniqueness of member names. It's entirely possible that a hardened JSON parser will need to be used tha= t rejects this and other kinds of malformed JSON if the native parser doesn= 't. We've tried to be very explicit about this in the specifications. Cheers, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard L.Barnes Sent: Wednesday, July 18, 2012 6:41 AM To: jose@ietf.org Subject: [jose] JSON parsing pitfalls I noticed the other day a widespread flaw in JSON parsers that makes JSON p= arsing a lossy operation. I haven't worked out the implications, but it se= ems worth thinking about, so I thought I would run it by the group. The problem is that JSON does not require that field names MUST be unique, = only that they SHOULD. From RFC 4627: " An object structure is represented as a pair of curly brackets surrounding zero or more name/value pairs (or members). A name is a string. A single colon comes after each name, separating the name from the value. A single comma separates a value from a following name. The names within an object SHOULD be unique. " Unfortunately, most JSON parsers are parsing into object constructs where e= ach field name references only one value. However, they will happily parse= JSON objects containing redundant fields -- they just set each field value= to the last value they saw for that name. So for example, if we parse the= following object ... { "foo": 1, "bar": 2, "foo": "This above all: to thine own self be true." }= ... then most parsers will return an object with two fields, which would s= tringify to the following: { "foo": "This above all: to thine own self be true.", "bar": 2 } A demonst= ration in four languages is at the bottom of this message. Like I said at the top, I'm not sure exactly what the implications of this = ambiguity are for this protocol. Thoughts? --Richard -----BEGIN json-error.sh----- #!/bin/bash BADHEADER=3D'{"typ":"JWT", "alg":"HS256", "alg":"hmac-md5"}' ###### Python python < EOF -----END json-error.sh----- _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B168042967394366739218TK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is a known issue and already addressed in th= e specifications.  Uniformly, each JSON structure definition includes = language like "JWSs with duplicate Header Parameter Names MUST be reje= cted" (http://tools.ietf.org/html/draft-ietf-jose-json-web= -signature-04#section-4).  Also, there is a Security Considerations section specifically about JSON p= arsing issues (http://tools.ietf.org/html/draft-ietf-jose-jso= n-web-signature-04#section-8.2), which says:

 

Strict JSON validation= is a security requirement. If malformed JSON is received, then the intent = of the sender is impossible to reliably discern. Ambiguous and potentially = exploitable situations could arise if the JSON parser used does not reject malformed JSON syntax.

Section 2.2 of the Jav= aScript Object Notation (JSON) specification [RFC4627] states "The nam= es within an object SHOULD be unique", whereas this specification stat= es that "Header Parameter Names within this object MUST be unique; JWSs with duplicate Header Parameter Names MUST be rejecte= d". Thus, this specification requires that the Section 2.2 "SHOUL= D" be treated as a "MUST". Ambiguous and potentially exploit= able situations could arise if the JSON parser used does not enforce the uniqueness of member names.

 

It’s entirely possible that a hardened JSON= parser will need to be used that rejects this and other kinds of malformed= JSON if the native parser doesn’t.  We’ve tried to be ver= y explicit about this in the specifications.

 

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; Cheers,

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

 

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard L.Barnes
Sent: Wednesday, July 18, 2012 6:41 AM
To: jose@ietf.org
Subject: [jose] JSON parsing pitfalls

 

I noticed the other day a widespread flaw in JSON= parsers that makes JSON parsing a lossy operation.  I haven't worked = out the implications, but it seems worth thinking about, so I thought I wou= ld run it by the group.

 

The problem is that JSON does not require that fi= eld names MUST be unique, only that they SHOULD.  From RFC 4627:<= /o:p>

"

   An object structure is represented a= s a pair of curly brackets

   surrounding zero or more name/value = pairs (or members).  A name is a

   string.  A single colon comes a= fter each name, separating the name

   from the value.  A single comma= separates a value from a following

   name.  The names within an obje= ct SHOULD be unique.

"

 

Unfortunately, most JSON parsers are parsing into= object constructs where each field name references only one value.  H= owever, they will happily parse JSON objects containing redundant fields --= they just set each field value to the last value they saw for that name.  So for example, if we parse the f= ollowing object ...

{ "foo": 1, "bar": 2, "f= oo": "This above all: to thine own self be true." } ... then= most parsers will return an object with two fields, which would stringify = to the following:

{ "foo": "This above all: to thine= own self be true.", "bar": 2 } A demonstration in four lang= uages is at the bottom of this message. 

 

Like I said at the top, I'm not sure exactly what= the implications of this ambiguity are for this protocol.  Thoughts?<= o:p>

 

--Richard

 

 

 

 

-----BEGIN json-error.sh-----

#!/bin/bash

 

BADHEADER=3D'{"typ":"JWT", &q= uot;alg":"HS256", "alg":"hmac-md5"}'

 

###### Python

python <<EOF

import json

str =3D '$BADHEADER'

obj =3D json.loads(str)

print obj

EOF

 

###### Perl

perl <<EOF

use JSON qw(to_json from_json);

\$str =3D '$BADHEADER';

\$obj =3D from_json(\$str);

printf "%s\n", to_json(\$obj);

EOF

 

###### Javascript (NodeJS / JSC)

node <<EOF

var str =3D '$BADHEADER';

var obj =3D JSON.parse(str);

console.log(JSON.stringify(obj));

EOF

 

###### PHP

php <<EOF

<?

\$str =3D '$BADHEADER';

\$obj =3D json_decode(\$str);

echo json_encode(\$obj) . "\n";

?>

EOF

-----END json-error.sh-----

_______________________________________________

jose mailing list

jose@ietf.org

https://www.iet= f.org/mailman/listinfo/jose

 

--_000_4E1F6AAD24975D4BA5B168042967394366739218TK5EX14MBXC285r_-- From Michael.Jones@microsoft.com Wed Jul 18 08:43:43 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA3421F8797 for ; Wed, 18 Jul 2012 08:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.789 X-Spam-Level: X-Spam-Status: No, score=-3.789 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pC5ljoTrUlwK for ; Wed, 18 Jul 2012 08:43:35 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id EDDEF21F8659 for ; Wed, 18 Jul 2012 08:43:34 -0700 (PDT) Received: from mail93-co1-R.bigfish.com (10.243.78.232) by CO1EHSOBE009.bigfish.com (10.243.66.72) with Microsoft SMTP Server id 14.1.225.23; Wed, 18 Jul 2012 15:44:25 +0000 Received: from mail93-co1 (localhost [127.0.0.1]) by mail93-co1-R.bigfish.com (Postfix) with ESMTP id 3DED1240348; Wed, 18 Jul 2012 15:44:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -32 X-BigFish: VS-32(zz9371Ic85fh542M1418I1453Mzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail93-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail93-co1 (localhost.localdomain [127.0.0.1]) by mail93-co1 (MessageSwitch) id 1342626262518858_2286; Wed, 18 Jul 2012 15:44:22 +0000 (UTC) Received: from CO1EHSMHS019.bigfish.com (unknown [10.243.78.245]) by mail93-co1.bigfish.com (Postfix) with ESMTP id 7BDC6440044; Wed, 18 Jul 2012 15:44:22 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS019.bigfish.com (10.243.66.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 18 Jul 2012 15:44:21 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0298.005; Wed, 18 Jul 2012 15:44:05 +0000 From: Mike Jones To: Jim Schaad , "jose@ietf.org" Thread-Topic: json-web-encryption -02 comments Thread-Index: Ac1bou6sddjZ9RUfROOHcwSTWeLOfgIGNEKAAE9LAUA= Date: Wed, 18 Jul 2012 15:44:04 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366739287@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436657A0E4@TK5EX14MBXC283.redmond.corp.microsoft.com> <01f301cd63bb$c7188700$55499500$@augustcellars.com> In-Reply-To: <01f301cd63bb$c7188700$55499500$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366739287TK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] json-web-encryption -02 comments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 15:43:43 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366739287TK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Replies inline... From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, July 16, 2012 6:30 PM To: Mike Jones; jose@ietf.org Subject: RE: json-web-encryption -02 comments In section 4 - There is an interesting question about the following: { alg:"none", enc:"AES128GCM" } This returns different results depending on which test you are using for de= termining if the header is a JWE or a JWS. This belies the last sentence i= n paragraph #2. Your example is an invalid input - either invalid as a JWS because it inclu= des the extra "enc" member or invalid as a JWE because "none" is not a vali= d encryption method. In either case, the input MUST be rejected. The sentence you are referring to reads: "Both methods will yield the same= result." I will change this to "Both methods will yield the same result f= or all valid inputs." (By the way, I suspect you were thinking of the example above in the contex= t of enabling the option of direct symmetric encryption without using a CMK= , per Open Issue 6 in JWA, which is good. :) I plan to make a proposal on = syntax for that later today.) In Section 4.1.1 It is stated that the value of "alg" is case sensitive. It is stated that = it may be a URI. URIs say that there may be case insensitive portions of t= he URI value. This needs to be reconciled. The intent is still that these fields be compared in a case sensitive manne= r. These are not URIs you dereference - they are URIs used as identifiers.= We could add text something to the effect of "When a StringOrURI value is= a URI and the URI scheme includes portions that are matched in a case inse= nsitive manner, this specification requires those portions of the URI be ex= pressed using only lowercase characters, so a case-sensitive equality test = will be effective." I'd add similar text to the registry instructions for = these fields as well. Does that clarification work for you? -- Mike From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, July 06, 2012 11:13 AM To: Jim Schaad; jose@ietf.org Subject: RE: json-web-encryption -02 comments Thanks once again. Responses inline... -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Thursday, June 07, 2012 11:56 AM To: jose@ietf.org; draft-ietf-jose-json-web-encryptio= n@tools.ietf.org Subject: json-web-encryption -02 comments Introduction 1. I would separate the introduction into two paragraphs. One to address = the general encryption issue and one to address the compact serialization i= ssues. This will allow for an easier addition/removal to deal with other s= erialization issues. I'm somewhat confused by this comment, as the introduction doesn't discuss = serialization. That concept isn't introduced until the "JWE Compact Serial= ization" term definition in Section 2 and the presentation of the compact s= erialization in Section 3. [JLS] And I am suggesting that the introduction SHOULD address the fact tha= t a serialization method is presented in this document. The process of enc= ryption and the process of serialization are separate things and both are c= overed in this document. This should be documented in the abstract. This should also be picked up in the abstract as well. 2. I find sentence #2 confusing since this document is defining how to do = the encryption process so we are not really dealing with pre-encrypted cont= ent which is what this appears to me to say. Like JWS, this sentence has been clarified to: It represents this content = using JavaScript Object Notation (JSON) data str= uctures. [JLS] I think that I find the concept that it represents the content as JSO= N to be weird, since the final formatting is actually dotted notation if yo= u are looking at the "compact encryption format" that was covered in this d= ocument. 3. What do you mean by the type of content being encrypted? This could ei= ther mean the format of the content (i.e. JSON vs Mime) or the type of cont= ent (i.e. a JSON token vs a JSON signature object). This now reads: The JWE cryptographic mechanisms encrypt and provide integ= rity protection for arbitrary sequences of bytes. [JLS] I find this confusing. A MAC also provides integrity protection and = that is in a different document. Section 3 1. Simple clarity s/confidentiality of the contents of the Plaintext/confi= dentiality of the Plaintext/ Done Section 4 - JWE Header 1. Do we think parsers can enforce the uniqueness requirement? See my response in the JWK comments 2. What does it mean to reject a JWE? Should it decrypt and say it is a b= ad decrypt or should it fail to decrypt? It should return an error and return no decrypted data [JLS] This response would eliminate that ability to do a stream based decod= e. That would return decrypted data and then return the error. Section 4.1.1 1. You should be constant about what you call the encryption key, master = key or JWE Encrypted key. A search and replace should be done to make them= constant. Now using the term Content Master Key (CMK) here. Note that the Content En= cryption Key (CMK) is distinct from (and derived from) the CMK. 2. Refer to the registry not to the document for the list of algorithms. Moved the document reference to be adjacent to the registry reference, sayi= ng that both apply Section 4.1.2 1. See comment 2 above Ditto 2. the encryption algorithm is not used to secure the cipher text. It is = used to produce the cipher text Corrected 3. Why does the enc algorithm not require the existence of a key for it's = use? Because the CEK is derived from the CMK, and so always exists [JLS] and how is that key known? Is a wrapped key always required in this = case. Section 4.1.4 2. The presence of this parameter MUST be specified for all content encryp= tion algorithms. It is, in JWA. Also clarified that it is REQUIRED with some "enc" algorith= ms. Section 4.1.5 1. See comment 2 above - alternate language would be say MUST be absent un= less otherwise specified by the algorithm. It is, in JWA. Also clarified that it is REQUIRED with some "alg" algorith= ms. [JLS] Then I assume that the following is legal { alg:"RSA1_5", epk:{...}, ...} 2. epk should talk about key agreement algorithms not a specific algorithm= . Done 3. Content of the key should be specified by the algorithm and not by this= document. Done Section 4.1.6 1. Should specify the use the "alg" registry for the zip parameter (in cas= e a new one comes into existence) and this algorithm should be registered a= s the only algorithm. This could be done, but it is counter to an explicit working group decision= to support only one compression algorithm. I'd be glad to do this if the = WG decides to open the door to the possibility of additional algorithms. [JLS] I do not feel that this means that it should not be registered. It = merely means that we will only register one, and we will make the bar very = high for the ability to register a second one. Otherwise this should be a = Boolean with a value of true. It either is or is not compressed. Section 4.1.7 1. Should make clear that this is the way of identifying what private key = is needed to decrypt the content. Added: this can be used to determine the private key needed to decrypt the = JWE 2. Should this be used? It implies that the decryptor needs to do the following: a) Get the keys b) For each key - i) Do I have the private key for this? ii) Does it match the algorithm? iii) Does it work? c) if no function keys found then ---??? Also, the decryptor might use "kid" and/or "use" parameters for deciding wh= ich key(s) to use. Obviously, if no applicable key can be located, the dec= ryption will fail. Section 4.1.8 1. See comment 1 above. Ditto Section 4.1.9 1. I would eliminate the (implicit) requirement that the certificate be va= lidated before decryption. There is no reason that a client should not be = able to decrypt a message to themselves if their certificate has been revok= ed or is expired. This is just a requirement at send time. What do others in the working group think of potentially relaxing this requ= irement? If we do relax it, what alternative language should be used? Section 4.1.11 1. I don't understand the format used here. The data could be either enco= ded as a string or an array of strings or something else that is a concaten= ated string form. I've added an example to clarify this. See http://tools.ietf.org/html/draf= t-ietf-jose-json-web-signature-03#appendix-B [JLS] That is nice that you have added an example. However this does not m= ean that the text should not be clarified. I think that you really want to= say that this field is an array of strings, each element in the array bein= g a base64url encoded certificate. The certificates are ordered such that = certificate i is issued by certificate i+1. Is it legal for a partial chain to be presented or must the full chain alwa= ys be presented? Is there a reason that you are not just using the PEM encoding in this loca= tion as well? If there is a requirement for having a chain of certificates in this locati= on, why is there not a requirement for having an array of certificates in t= he x5t case? As a recipient I should never need more than the EE certificate in order to= map from a public key to a private key. Other than letting me know what = the chain was that the sender used to validate my certificate, I don't know= what the reasoning behind sending the chain would be. 2. Why is this not base64url encoded given that all other locations are? So we're using a standard encoding for certificate chains [JLS] A standard encoding would be using the PEM string or using a CMS cert= s only. Changing the base64url to remove trailing characters is not reall= y an issue. Unless the new JavaScript CryptoAPIs (as an example) take a b= ase64 encoded certificate as input the user code is going to deal with the = encoding/decoding question anyway. 3. See comment 1 above Ditto Section 4.1.12 1. This is so underspecified that I would know how to go about using it. Any code that I wrote would therefore ignore it. Added: When used with a JWK, the "kid" value MAY be used to match a JWK= "kid" parameter value. [JLS] This does nothing to change my statement above. In fact it enforces = it. Section 4.1.13 1. The list of possible typ values should apparently include the mime regi= stry as well. This is neither in the value registry (which should probably= be setup to avoid collisions with mime types) or a URI. See the new Section 7.2 in JWS [JLS] I do not believe that mime types and subtypes are case insensitive va= lues in MIME itself. This needs to be resolved. Section 4.2 1. Should re-iterate the "if you don't know it then reject it" sentence he= re - it has been a long time since we have seen it. (Ditto for section 4.3) I understand why you're saying this, but we did say "Implementations MUST u= nderstand the entire contents of the header; otherwise, the JWE MUST be rej= ected" in the enclosing section introduction (Section 4), so I'm reluctant = to repeat it in 4.2 and especially reluctant to repeat it again so soon in = 4.3. Section 5 1. I disagree with the concept of using a key agree algorithm to create th= e CMK. Look at CMS to see how they handle key agree algorithms to create a key wrap key The key wrap key is unnecessary, as far as I can tell, at least when there'= s a single recipient. It results in an additional encryption step that see= ms to me to add no additional security. However, per James Manger's note and my response to it, I do understand tha= t value of having a CMK in the multiple recipients case. I've added this t= opic to the list of open issues for the working group to discuss. 2. In step 8 - when did you create the encoded JWE header? In step 9. :-) Yes, I'd already seen this and fixed it. 3. Separate the serialization format from the encryption algorithm. This = may just affect step 14. Done 4. Note previous discussion on only documenting AEAD algorithms I'm not sure what change you're asking for here? [JLS] I am asking that there only be one set of steps for doing this, and i= t is for AEAD algorithms. Section 6 1. Separate serialization from message decryption. If alternate serializa= tions are used then step 1 fails. Done 2. Note that you have imposed some additional restrictions on the JSE head= er in step three - specifically that no duplicate fields exist. This is no= t in the decryption process. It's input validation for the decryption process, just like step 2 was Section 7 1. If you are using the NIST KDF function, then the length of the output k= ey should really be included in the OtherInfo Again, per my earlier responses to you and Sean on this topic from your JWA= comments, since the CMK is randomly generated for each encryption, I belie= ve that the additional parameters add no security value. Adding a key leng= th would only make sense if we were going to use this same CMK to generate = other keys using the same Label ("Encryption" or "Integrity") but with a di= fferent key length. But we never will, so I believe that the parameter is = superfluous. Section 8.1 1. Refer to the registry not to the document (ditto for section 8.2) Done Section 11.1 1. Should there be an optional parameter which describes which serializati= on method is being used? This could be introduced if the working group adopts a second serialization= method, such as the JSON Serialization defined in draft-jones-json-web-enc= ryption-json-serialization, or one of the other candidates. However, a bet= ter approach might be to define a different media type value, such as appli= cation/jwe-js for the different serialization. Of course, if we have a pure JSON serialization, one could argue for just u= sing the application/json media type. 2. Check with IANA if you or the IESG should be listed under the contact s= ection. Will do --_000_4E1F6AAD24975D4BA5B168042967394366739287TK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Replies inline…<= o:p>

 

From: Jim Scha= ad [mailto:ietf@augustcellars.com]
Sent: Monday, July 16, 2012 6:30 PM
To: Mike Jones; jose@ietf.org
Subject: RE: json-web-encryption -02 comments

 

In section 4 –

There is an interestin= g question about the following:

{ alg:”none̶= 1;, enc:”AES128GCM” }

 

This returns different= results depending on which test you are using for determining if the heade= r is a JWE or a JWS.  This belies the last sentence in paragraph #2.

 

Your example is an inv= alid input – either invalid as a JWS because it includes the extra &#= 8220;enc” member or invalid as a JWE because “none” is no= t a valid encryption method.  In either case, the input MUST be reject= ed.

 

The sentence you are r= eferring to reads:  “Both methods will yield the same result.”  I will change this to “Bo= th methods will yield the same result for all valid inputs.= 221;

 

(By the way, I suspect= you were thinking of the example above in the context of enabling the opti= on of direct symmetric encryption without using a CMK, per Open Issue 6 in = JWA, which is good. J  I plan to make a proposal on syntax for that l= ater today.)

 

In Section 4.1.1<= /o:p>

 

It is stated that the = value of “alg” is case sensitive.  It is stated that it ma= y be a URI.  URIs say that there may be case insensitive portions of t= he URI value.  This needs to be reconciled.

 

The intent is still th= at these fields be compared in a case sensitive manner.  These are not= URIs you dereference – they are URIs used as identifiers.  We c= ould add text something to the effect of “When a StringOrURI value is a URI and the URI scheme includes portions that are matched in a = case insensitive manner, this specification requires those portions of the = URI be expressed using only lowercase characters, so a case-sensitive equal= ity test will be effective.”  I’d add similar text to the registry instructions for these fields as well.&nb= sp; Does that clarification work for you?

 

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

 

From: Mike Jon= es [mailto:Michael.Jon= es@microsoft.com]
Sent: Friday, July 06, 2012 11:13 AM
To: Jim Schaad; jose@ietf.org Subject: RE: json-web-encryption -02 comments

 

Thanks once again.&= nbsp; Responses inline…

 

-----Original Message-----
From: Jim Schaad [mailto= :ietf@augustcellars.com]
Sent: Thursday, June 07, 2012 11:56 AM
To: jose@ietf.org; draft-ietf-jose-json-web-encryption@tools.ietf.org
Subject: json-web-encryption -02 comments

 

Introduction

 

1.  I would separate the introduction into t= wo paragraphs.  One to address the general encryption issue and one to= address the compact serialization issues.  This will allow for an eas= ier addition/removal to deal with other serialization issues.

 

I’m somewhat = confused by this comment, as the introduction doesn’t discuss seriali= zation.  That concept isn’t introduced until the “JWE Comp= act Serialization” term definition in Section 2 and the presentation of the compact serialization in Section 3.

 

[JLS] And I am sugg= esting that the introduction SHOULD address the fact that a serialization m= ethod is presented in this document.  The process of encryption and th= e process of serialization are separate things and both are covered in this document.  This should be documented in = the abstract.

 

This should also be= picked up in the abstract as well.

 

2.  I find sentence #2 confusing since this = document is defining how to do the encryption process so we are not really = dealing with pre-encrypted content which is what this appears to me to say.=

 

Like JWS, this sent= ence has been clarified to:  It represents this content using JavaScri= pt Object Notation (JSON) <xref target=3D"RFC4627"/> data s= tructures.

 

[JLS] I think that = I find the concept that it represents the content as JSON to be weird, sinc= e the final formatting is actually dotted notation if you are looking at th= e “compact encryption format” that was covered in this document.

 

3.  What do you mean by the type of content = being encrypted?  This could either mean the format of the content (i.= e. JSON vs Mime) or the type of content (i.e. a JSON token vs a JSON signat= ure object).

 

This now reads:&nbs= p; The JWE cryptographic mechanisms encrypt and provide integrity protectio= n for arbitrary sequences of bytes.

 

[JLS] I find this c= onfusing.  A MAC also provides integrity protection and that is in a d= ifferent document.

 

 

Section 3

 

1.  Simple clarity s/confidentiality of the = contents of the Plaintext/confidentiality of the Plaintext/

 

Done

 

Section 4 - JWE Header

 

1.  Do we think parsers can enforce the uniq= ueness requirement?

 

See my response in = the JWK comments

 

2.  What does it mean to reject a JWE? = Should it decrypt and say it is a bad decrypt or should it fail to decrypt= ?

 

It should return an= error and return no decrypted data

 

[JLS] This response= would eliminate that ability to do a stream based decode.  That would= return decrypted data and then return the error.

 

Section 4.1.1

 

1.  You should be constant about what  = you call the encryption key, master key or JWE Encrypted key.  A searc= h and replace should be done to make them constant.

 

Now using the term = Content Master Key (CMK) here.  Note that the Content Encryption Key (= CMK) is distinct from (and derived from) the CMK.

 

2.  Refer to the registry not to the documen= t for the list of algorithms.

 

Moved the document = reference to be adjacent to the registry reference, saying that both apply<= o:p>

 

Section 4.1.2

 

1. See comment 2 above

 

Ditto

 

2.  the encryption algorithm is not used to = secure the cipher text.  It is used to produce the cipher text

 

Corrected

 

3.  Why does the enc algorithm not require t= he existence of a key for it's use?

 

Because the CEK is = derived from the CMK, and so always exists

 

[JLS] and how is th= at key known?  Is a wrapped key always required in this case. 

 

Section 4.1.4

 

 

2.  The presence of this parameter MUST be s= pecified for all content encryption algorithms.

 

It is, in JWA. = ; Also clarified that it is REQUIRED with some “enc” algorithms= .

 

Section 4.1.5

 

1.  See comment 2 above - alternate language= would be say MUST be absent unless otherwise specified by the algorithm.

 

It is, in JWA. = ; Also clarified that it is REQUIRED with some “alg” algorithms= .

 

[JLS] Then I assume= that the following is legal

{ alg:”RSA1_5= ”, epk:{…}, …}

 

2.  epk should talk about key agreement algo= rithms not a specific algorithm.

 

Done

 

3.  Content of the key should be specified b= y the algorithm and not by this document.

 

Done

 

Section 4.1.6

 

1.  Should specify the use the "alg&quo= t; registry for the zip parameter (in case a new one comes into existence) = and this algorithm should be registered as the only algorithm.

 

This could be done,= but it is counter to an explicit working group decision to support only on= e compression algorithm.  I’d be glad to do this if the WG decid= es to open the door to the possibility of additional algorithms.

 

[JLS]  I do no= t feel that this means that it should not be registered.  It merely me= ans that we will only register one, and we will make the bar very high for = the ability to register a second one.  Otherwise this should be a Boolean with a value of true.  It either is or is no= t compressed.

 

Section 4.1.7

 

1.  Should make clear that this is the way o= f identifying what private key is needed to decrypt the content.=

 

Added: this can be = used to determine the private key needed to decrypt the JWE

 

2.  Should this be used?  It implies th= at the decryptor needs to do the

following:

a) Get the keys

b) For each key -

   i) Do I have the private key for thi= s?

   ii) Does it match the algorithm?

   iii) Does it work?

c) if no function keys found then ---???

 

Also, the decryptor= might use “kid” and/or “use” parameters for decidi= ng which key(s) to use.  Obviously, if no applicable key can be locate= d, the decryption will fail.

 

Section 4.1.8

 

1.  See comment 1 above.

 

Ditto

 

Section 4.1.9

 

1.  I would eliminate the (implicit) require= ment that the certificate be validated before decryption.  There is no= reason that a client should not be able to decrypt a message to themselves= if their certificate has been revoked or is expired.  This is just a requirement at send time.

 

What do others in t= he working group think of potentially relaxing this requirement?  If w= e do relax it, what alternative language should be used?<= /p>

 

Section 4.1.11

 

1.  I don't understand the format used here.=   The data could be either encoded as a string or an array of strings = or something else that is a concatenated string form.

 

I’ve added an= example to clarify this.  See http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-03#appendix-B=

 

[JLS] That is nice = that you have added an example.  However this does not mean that the t= ext should not be clarified.  I think that you really want to say that= this field is an array of strings, each element in the array being a base64url encoded certificate.  The certificates= are ordered such that certificate i is issued by certificate i+1.

 

Is it legal for a p= artial chain to be presented or must the full chain always be presented?

 

Is there a reason t= hat you are not just using the PEM encoding in this location as well?<= /o:p>

 

If there is a requi= rement for having a chain of certificates in this location, why is there no= t a requirement for having an array of certificates in the x5t case?

 

As a recipient I sh= ould never need more than the EE certificate in order to map from a public = key to a private key.   Other than letting me know what the chain= was that the sender used to validate my certificate, I don’t know what the reasoning behind sending the chain would be.

 

2.  Why is this not base64url encoded given = that all other locations are?

 

So we’re usin= g a standard encoding for certificate chains

 

[JLS] A standard en= coding would be using the PEM string or using a CMS certs only.   = ;Changing the base64url to remove trailing characters is not really an issu= e.   Unless the new JavaScript CryptoAPIs (as an example) take a base64 encoded certificate as input the user code is go= ing to deal with the encoding/decoding question anyway.

 

3. See comment 1 above

 

Ditto

 

Section 4.1.12

 

1.  This is so underspecified that I would k= now how to go about using it.

Any code that I wrote would therefore ignore it.<= o:p>

 

Added:   =   When used with a JWK, the “kid” value MAY be used to mat= ch a JWK “kid” parameter value.

 

[JLS] This does not= hing to change my statement above.  In fact it enforces it. 

 

Section 4.1.13

 

1.  The list of possible typ values should a= pparently include the mime registry as well.  This is neither in the v= alue registry (which should probably be setup to avoid collisions with mime= types) or a URI.

 

See the new Section= 7.2 in JWS

 

[JLS] I do not beli= eve that mime types and subtypes are case insensitive values in MIME itself= .  This needs to be resolved.

 

Section 4.2

 

1.  Should re-iterate the "if you don't= know it then reject it" sentence here - it has been a long time since= we have seen it.

 

(Ditto for section 4.3)

 

I understand why yo= u’re saying this, but we did say “Implementations MUST understa= nd the entire contents of the header; otherwise, the JWE MUST be rejected&#= 8221; in the enclosing section introduction (Section 4), so I’m reluctant to repeat it in 4.2 and especially reluctant to rep= eat it again so soon in 4.3.

 

Section 5

 

1.  I disagree with the concept of using a k= ey agree algorithm to create the

CMK.   Look at CMS to see how they hand= le key agree algorithms to create a

key wrap key

 

The key wrap key is= unnecessary, as far as I can tell, at least when there’s a single re= cipient.  It results in an additional encryption step that seems to me= to add no additional security.

 

However, per James = Manger’s note and my response to it, I do understand that value of ha= ving a CMK in the multiple recipients case.  I’ve added this top= ic to the list of open issues for the working group to discuss.

 

2.  In step 8 - when did you create the enco= ded JWE header?

 

In step 9. :-) = ; Yes, I’d already seen this and fixed it.

 

3.  Separate the serialization format from t= he encryption algorithm.  This may just affect step 14.

 

Done

 

4.  Note previous discussion on only documen= ting AEAD algorithms

 

I’m not sure = what change you’re asking for here?

 

[JLS] I am asking t= hat there only be one set of steps for doing this, and it is for AEAD algor= ithms. 

 

Section 6

 

1.  Separate serialization from message decr= yption.  If alternate serializations are used then step 1 fails.<= /o:p>

 

Done

 

2.  Note that you have imposed some addition= al restrictions on the JSE header in step three - specifically that no dupl= icate fields exist.  This is not in the decryption process.=

 

It’s input va= lidation for the decryption process, just like step 2 was=

 

Section 7

 

1.  If you are using the NIST KDF function, = then the length of the output key should really be included in the OtherInf= o

 

Again, per my earli= er responses to you and Sean on this topic from your JWA comments, since th= e CMK is randomly generated for each encryption, I believe that the additio= nal parameters add no security value.  Adding a key length would only make sense if we were going to use this sam= e CMK to generate other keys using the same Label (“Encryption”= or “Integrity”) but with a different key length.  But we = never will, so I believe that the parameter is superfluous.

 

Section 8.1

 

1.  Refer to the registry not to the documen= t (ditto for section 8.2)

 

Done

 

Section 11.1

 

1.  Should there be an optional parameter wh= ich describes which serialization method is being used?

 

This could be intro= duced if the working group adopts a second serialization method, such as th= e JSON Serialization defined in draft-jones-json-web-encryption-json-serial= ization, or one of the other candidates.  However, a better approach might be to define a different media type value= , such as application/jwe-js for the different serialization.

 

Of course, if we ha= ve a pure JSON serialization, one could argue for just using the applicatio= n/json media type.

 

2.  Check with IANA if you or the IESG shoul= d be listed under the contact section.

 

Will do<= /span>

 

--_000_4E1F6AAD24975D4BA5B168042967394366739287TK5EX14MBXC285r_-- From Axel.Nennker@telekom.de Wed Jul 18 09:25:21 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911E521F87C3 for ; Wed, 18 Jul 2012 09:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnS6Y3cYu1QI for ; Wed, 18 Jul 2012 09:25:20 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id E35CA21F87C0 for ; Wed, 18 Jul 2012 09:25:19 -0700 (PDT) Received: from he113415.emea1.cds.t-internal.com ([10.125.65.81]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 18 Jul 2012 18:26:09 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.220]) by HE113415.emea1.cds.t-internal.com ([2002:7cd:4151::7cd:4151]) with mapi; Wed, 18 Jul 2012 18:26:08 +0200 From: To: , Date: Wed, 18 Jul 2012 18:26:07 +0200 Thread-Topic: [jose] JSON parsing pitfalls Thread-Index: Ac1k6vvwUPY9B4CBQ82Jpb4XxDa/ogAFbn5A Message-ID: References: <6D454DBB-B4F8-46F5-BA21-E475534F65CD@bbn.com> In-Reply-To: <6D454DBB-B4F8-46F5-BA21-E475534F65CD@bbn.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [jose] JSON parsing pitfalls X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 16:25:21 -0000 The"official" JSON-Java code here does not have this issue: https://github.com/douglascrockford/JSON-java Axel -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard L.Barnes Sent: Wednesday, July 18, 2012 3:41 PM To: jose@ietf.org Subject: [jose] JSON parsing pitfalls I noticed the other day a widespread flaw in JSON parsers that makes JSON p= arsing a lossy operation. I haven't worked out the implications, but it se= ems worth thinking about, so I thought I would run it by the group. The problem is that JSON does not require that field names MUST be unique, = only that they SHOULD. From RFC 4627: " An object structure is represented as a pair of curly brackets surrounding zero or more name/value pairs (or members). A name is a string. A single colon comes after each name, separating the name from the value. A single comma separates a value from a following name. The names within an object SHOULD be unique. " Unfortunately, most JSON parsers are parsing into object constructs where e= ach field name references only one value. However, they will happily parse= JSON objects containing redundant fields -- they just set each field value= to the last value they saw for that name. So for example, if we parse the= following object ... { "foo": 1, "bar": 2, "foo": "This above all: to thine own self be true." } ... then most parsers will return an object with two fields, which would st= ringify to the following: { "foo": "This above all: to thine own self be true.", "bar": 2 } A demonstration in four languages is at the bottom of this message. =20 Like I said at the top, I'm not sure exactly what the implications of this = ambiguity are for this protocol. Thoughts? --Richard -----BEGIN json-error.sh----- #!/bin/bash BADHEADER=3D'{"typ":"JWT", "alg":"HS256", "alg":"hmac-md5"}' ###### Python python < EOF -----END json-error.sh----- _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From rbarnes@bbn.com Wed Jul 18 16:29:41 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7A111E80D5 for ; Wed, 18 Jul 2012 16:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.609 X-Spam-Level: X-Spam-Status: No, score=-106.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TTDyykPQJa3 for ; Wed, 18 Jul 2012 16:29:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id F2B5611E80C7 for ; Wed, 18 Jul 2012 16:29:39 -0700 (PDT) Received: from [128.89.253.162] (port=60960) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SrdhO-000M98-9e; Wed, 18 Jul 2012 19:30:30 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366739218@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Wed, 18 Jul 2012 19:30:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <41182A52-96C6-4692-B469-32523E11C33D@bbn.com> References: <6D454DBB-B4F8-46F5-BA21-E475534F65CD@bbn.com> <4E1F6AAD24975D4BA5B168042967394366739218@TK5EX14MBXC285.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1278) Cc: "jose@ietf.org" Subject: Re: [jose] JSON parsing pitfalls X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 23:29:41 -0000 Doesn't it seem like requiring special JSON parsing kind of negates the = point of using JSON? Perhaps we could make better use of JSON, e.g., by using a data = structure with explicit ordering, e.g.: [ ["tag1", "val1"], ["tag2", "val2"], ... ] Slightly less convenient at the application layer, but at least you can = still use your JSON parser. On Jul 18, 2012, at 11:18 AM, Mike Jones wrote: > This is a known issue and already addressed in the specifications. = Uniformly, each JSON structure definition includes language like "JWSs = with duplicate Header Parameter Names MUST be rejected" = (http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-04#section-= 4). Also, there is a Security Considerations section specifically about = JSON parsing issues = (http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-04#section-= 8.2), which says: > =20 > Strict JSON validation is a security requirement. If malformed JSON is = received, then the intent of the sender is impossible to reliably = discern. Ambiguous and potentially exploitable situations could arise if = the JSON parser used does not reject malformed JSON syntax. > Section 2.2 of the JavaScript Object Notation (JSON) specification = [RFC4627] states "The names within an object SHOULD be unique", whereas = this specification states that "Header Parameter Names within this = object MUST be unique; JWSs with duplicate Header Parameter Names MUST = be rejected". Thus, this specification requires that the Section 2.2 = "SHOULD" be treated as a "MUST". Ambiguous and potentially exploitable = situations could arise if the JSON parser used does not enforce the = uniqueness of member names. > =20 > It=92s entirely possible that a hardened JSON parser will need to be = used that rejects this and other kinds of malformed JSON if the native = parser doesn=92t. We=92ve tried to be very explicit about this in the = specifications. > =20 > Cheers, > -- Mike > =20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Richard L.Barnes > Sent: Wednesday, July 18, 2012 6:41 AM > To: jose@ietf.org > Subject: [jose] JSON parsing pitfalls > =20 > I noticed the other day a widespread flaw in JSON parsers that makes = JSON parsing a lossy operation. I haven't worked out the implications, = but it seems worth thinking about, so I thought I would run it by the = group. > =20 > The problem is that JSON does not require that field names MUST be = unique, only that they SHOULD. =46rom RFC 4627: > " > An object structure is represented as a pair of curly brackets > surrounding zero or more name/value pairs (or members). A name is = a > string. A single colon comes after each name, separating the name > from the value. A single comma separates a value from a following > name. The names within an object SHOULD be unique. > " > =20 > Unfortunately, most JSON parsers are parsing into object constructs = where each field name references only one value. However, they will = happily parse JSON objects containing redundant fields -- they just set = each field value to the last value they saw for that name. So for = example, if we parse the following object ... > { "foo": 1, "bar": 2, "foo": "This above all: to thine own self be = true." } ... then most parsers will return an object with two fields, = which would stringify to the following: > { "foo": "This above all: to thine own self be true.", "bar": 2 } A = demonstration in four languages is at the bottom of this message.=20 > =20 > Like I said at the top, I'm not sure exactly what the implications of = this ambiguity are for this protocol. Thoughts? > =20 > --Richard > =20 > =20 > =20 > =20 > -----BEGIN json-error.sh----- > #!/bin/bash > =20 > BADHEADER=3D'{"typ":"JWT", "alg":"HS256", "alg":"hmac-md5"}' > =20 > ###### Python > python < import json > str =3D '$BADHEADER' > obj =3D json.loads(str) > print obj > EOF > =20 > ###### Perl > perl < use JSON qw(to_json from_json); > \$str =3D '$BADHEADER'; > \$obj =3D from_json(\$str); > printf "%s\n", to_json(\$obj); > EOF > =20 > ###### Javascript (NodeJS / JSC) > node < var str =3D '$BADHEADER'; > var obj =3D JSON.parse(str); > console.log(JSON.stringify(obj)); > EOF > =20 > ###### PHP > php < \$str =3D '$BADHEADER'; > \$obj =3D json_decode(\$str); > echo json_encode(\$obj) . "\n"; > ?> > EOF > -----END json-error.sh----- > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Wed Jul 18 18:03:19 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CE521F8650 for ; Wed, 18 Jul 2012 18:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.787 X-Spam-Level: X-Spam-Status: No, score=-3.787 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1nwDQz5Yw7P for ; Wed, 18 Jul 2012 18:03:17 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id AB65021F864F for ; Wed, 18 Jul 2012 18:03:16 -0700 (PDT) Received: from mail250-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Jul 2012 01:04:07 +0000 Received: from mail250-va3 (localhost [127.0.0.1]) by mail250-va3-R.bigfish.com (Postfix) with ESMTP id 9D6401680088 for ; Thu, 19 Jul 2012 01:04:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -6 X-BigFish: VS-6(zzc85fhdf9M14ffIzz1202hzz8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail250-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail250-va3 (localhost.localdomain [127.0.0.1]) by mail250-va3 (MessageSwitch) id 1342659845750941_18101; Thu, 19 Jul 2012 01:04:05 +0000 (UTC) Received: from VA3EHSMHS003.bigfish.com (unknown [10.7.14.239]) by mail250-va3.bigfish.com (Postfix) with ESMTP id B542B1A40043 for ; Thu, 19 Jul 2012 01:04:05 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS003.bigfish.com (10.7.99.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 19 Jul 2012 01:04:05 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0298.005; Thu, 19 Jul 2012 01:04:04 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Symmetric encryption and key agreement with and without a separate CMK Thread-Index: Ac1lSl6h5FqQOPItQGiuikwTjR9Qtg== Date: Thu, 19 Jul 2012 01:04:03 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436673A0B7@TK5EX14MBXC285.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436673A0B7TK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [jose] Symmetric encryption and key agreement with and without a separate CMK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 01:03:19 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436673A0B7TK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I've been thinking about two of our open issues, which are closely related,= and am writing to make a proposal to resolve both of them. The issues are= : (1) Currently we specify methods for using symmetric keys to key wrap a sep= arate Content Master Key (CMK), but no means of using the symmetric key as = the CMK directly. Some applications need this functionality, both for size= and for efficiency reasons. (2) Currently we specify methods for performing key agreement and directly = using the resulting key as the CMK to perform block encryption, but no mean= s of using the agreed-upon key to wrap a separate CMK. When doing key agre= ement for multiple recipients, a separate CMK is needed. Thus, I propose that we define methods for filling in both of the holes abo= ve, as follows: (a) Define "alg":"dir" (direct) to mean that the symmetric key is directly = used as the CMK for the block encryption and integrity calculations, rather= than as a key to wrap the CMK value. (b) Define "alg":"ECDH-ES+A128KW" and "alg":"ECDH-ES+A256KW" to mean that t= he result of the key agreement is respectively used as the 128 bit or 256 b= it AES Key Wrap key to wrap the CMK. Doing this will enable all four flavors, whereas we're currently missing 2 = and 3 below: 1. The symmetric key used to wrap a separate CMK 2. The symmetric key used as the CMK 3. The key agreement result used to wrap a separate CMK 4. The key agreement result used as the CMK I recognize that flavors 2 and 4 are not usable with multiple recipients wh= en methods such as JWE JSON Serialization are used (which counts on a commo= n CMK value to enable a common ciphertext value). A note to that effect wo= uld be added to the JWA definitions of "alg":"ECDH-ES" and "alg":"dir" and = it would be pointed out in the JWE-JS spec that "alg" values that utilize a= separate CMK MUST be used when the plaintext is encrypted to multiple reci= pients. Comments? -- Mike --_000_4E1F6AAD24975D4BA5B16804296739436673A0B7TK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I’ve been thinking about two of our open issue= s, which are closely related, and am writing to make a proposal to resolve = both of them.  The issues are:

 

(1) Currently we specify methods for using symmetric= keys to key wrap a separate Content Master Key (CMK), but no means of usin= g the symmetric key as the CMK directly.  Some applications need this = functionality, both for size and for efficiency reasons.

 

(2) Currently we specify methods for performing key = agreement and directly using the resulting key as the CMK to perform block = encryption, but no means of using the agreed-upon key to wrap a separate CM= K.  When doing key agreement for multiple recipients, a separate CMK is needed.

 

Thus, I propose that we define methods for filling i= n both of the holes above, as follows:

 

(a) Define “alg”:”dir” (dire= ct) to mean that the symmetric key is directly used as the CMK for the bloc= k encryption and integrity calculations, rather than as a key to wrap the C= MK value.

 

(b) Define “alg”:”ECDH-ES+A128= KW” and “alg”:”ECDH-ES+A256KW” to mean th= at the result of the key agreement is respectively used as the 128 bit or 2= 56 bit AES Key Wrap key to wrap the CMK.

 

Doing this will enable all four flavors, whereas we&= #8217;re currently missing 2 and 3 below:

1.  The symmetric key used to wrap a separate C= MK

2.  The symmetric key used as the CMK

3.  The key agreement result used to wrap a sep= arate CMK

4.  The key agreement result used as the CMK

 

I recognize that flavors 2 and 4 are not usable with= multiple recipients when methods such as JWE JSON Serialization are used (= which counts on a common CMK value to enable a common ciphertext value).&nb= sp; A note to that effect would be added to the JWA definitions of “alg”:“ECDH-ES” and R= 20;alg”:”dir” and it would be pointed out in the JWE-JS s= pec that “alg” values that utilize a separate CMK MUST be used = when the plaintext is encrypted to multiple recipients.

 

Comments?

 

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

 

 

--_000_4E1F6AAD24975D4BA5B16804296739436673A0B7TK5EX14MBXC285r_-- From ietf@augustcellars.com Wed Jul 18 19:48:32 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7ED11E8096 for ; Wed, 18 Jul 2012 19:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOdtWLLT4M4k for ; Wed, 18 Jul 2012 19:48:24 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id E5F8621F8532 for ; Wed, 18 Jul 2012 19:48:23 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 669102CA06; Wed, 18 Jul 2012 19:49:09 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , References: <4E1F6AAD24975D4BA5B16804296739436657A0E4@TK5EX14MBXC283.redmond.corp.microsoft.com> <01f301cd63bb$c7188700$55499500$@augustcellars.com> <4E1F6AAD24975D4BA5B168042967394366739287@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366739287@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Wed, 18 Jul 2012 19:47:42 -0700 Message-ID: <02ec01cd6558$df733810$9e59a830$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02ED_01CD651E.33257710" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGtLrAIoIGfL58fGmSZztiMIaNvZQGU8PVMAZiF+mKXVuZGUA== Content-Language: en-us Subject: Re: [jose] json-web-encryption -02 comments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 02:48:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02ED_01CD651E.33257710 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, July 18, 2012 8:44 AM To: Jim Schaad; jose@ietf.org Subject: RE: json-web-encryption -02 comments Replies inline. From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, July 16, 2012 6:30 PM To: Mike Jones; jose@ietf.org Subject: RE: json-web-encryption -02 comments In section 4 - There is an interesting question about the following: { alg:"none", enc:"AES128GCM" } This returns different results depending on which test you are using for determining if the header is a JWE or a JWS. This belies the last sentence in paragraph #2. Your example is an invalid input - either invalid as a JWS because it includes the extra "enc" member or invalid as a JWE because "none" is not a valid encryption method. In either case, the input MUST be rejected. [JLS2] It is not clear to me that this is a correct statement. My implementation does understand both alg and enc - I don't see anything that says they must occur only in the correct contexts. This is also going to be effected by the discussion of permit or deny for unknown headers that is being discussed elsewhere. The sentence you are referring to reads: "Both methods will yield the same result." I will change this to "Both methods will yield the same result for all valid inputs." [JLS2] So you are comfortable with the fact that different implementations may respond with different error messages based on how they go about doing the checking of what the structure is going to be. - Specifically if they think that a signed or an encrypted message is going to come first. (By the way, I suspect you were thinking of the example above in the context of enabling the option of direct symmetric encryption without using a CMK, per Open Issue 6 in JWA, which is good. J I plan to make a proposal on syntax for that later today.) In Section 4.1.1 It is stated that the value of "alg" is case sensitive. It is stated that it may be a URI. URIs say that there may be case insensitive portions of the URI value. This needs to be reconciled. The intent is still that these fields be compared in a case sensitive manner. These are not URIs you dereference - they are URIs used as identifiers. We could add text something to the effect of "When a StringOrURI value is a URI and the URI scheme includes portions that are matched in a case insensitive manner, this specification requires those portions of the URI be expressed using only lowercase characters, so a case-sensitive equality test will be effective." I'd add similar text to the registry instructions for these fields as well. Does that clarification work for you? [JLS2] by itself it does not deal with all of the possible issues. I don't think it matters that they are for de-reference or not. The issue is the same in all cases. However besides the issue of case, there are also questions on using quoting characters, equivalent characters, utf8 encoding, I don't know if there is a problem with doing canonicalization of order of composite characters or not. -- Mike From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, July 06, 2012 11:13 AM To: Jim Schaad; jose@ietf.org Subject: RE: json-web-encryption -02 comments Thanks once again. Responses inline. -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Thursday, June 07, 2012 11:56 AM To: jose@ietf.org; draft-ietf-jose-json-web-encryption@tools.ietf.org Subject: json-web-encryption -02 comments Introduction 1. I would separate the introduction into two paragraphs. One to address the general encryption issue and one to address the compact serialization issues. This will allow for an easier addition/removal to deal with other serialization issues. I'm somewhat confused by this comment, as the introduction doesn't discuss serialization. That concept isn't introduced until the "JWE Compact Serialization" term definition in Section 2 and the presentation of the compact serialization in Section 3. [JLS] And I am suggesting that the introduction SHOULD address the fact that a serialization method is presented in this document. The process of encryption and the process of serialization are separate things and both are covered in this document. This should be documented in the abstract. This should also be picked up in the abstract as well. 2. I find sentence #2 confusing since this document is defining how to do the encryption process so we are not really dealing with pre-encrypted content which is what this appears to me to say. Like JWS, this sentence has been clarified to: It represents this content using JavaScript Object Notation (JSON) data structures. [JLS] I think that I find the concept that it represents the content as JSON to be weird, since the final formatting is actually dotted notation if you are looking at the "compact encryption format" that was covered in this document. 3. What do you mean by the type of content being encrypted? This could either mean the format of the content (i.e. JSON vs Mime) or the type of content (i.e. a JSON token vs a JSON signature object). This now reads: The JWE cryptographic mechanisms encrypt and provide integrity protection for arbitrary sequences of bytes. [JLS] I find this confusing. A MAC also provides integrity protection and that is in a different document. Section 3 1. Simple clarity s/confidentiality of the contents of the Plaintext/confidentiality of the Plaintext/ Done Section 4 - JWE Header 1. Do we think parsers can enforce the uniqueness requirement? See my response in the JWK comments 2. What does it mean to reject a JWE? Should it decrypt and say it is a bad decrypt or should it fail to decrypt? It should return an error and return no decrypted data [JLS] This response would eliminate that ability to do a stream based decode. That would return decrypted data and then return the error. Section 4.1.1 1. You should be constant about what you call the encryption key, master key or JWE Encrypted key. A search and replace should be done to make them constant. Now using the term Content Master Key (CMK) here. Note that the Content Encryption Key (CMK) is distinct from (and derived from) the CMK. 2. Refer to the registry not to the document for the list of algorithms. Moved the document reference to be adjacent to the registry reference, saying that both apply Section 4.1.2 1. See comment 2 above Ditto 2. the encryption algorithm is not used to secure the cipher text. It is used to produce the cipher text Corrected 3. Why does the enc algorithm not require the existence of a key for it's use? Because the CEK is derived from the CMK, and so always exists [JLS] and how is that key known? Is a wrapped key always required in this case. Section 4.1.4 2. The presence of this parameter MUST be specified for all content encryption algorithms. It is, in JWA. Also clarified that it is REQUIRED with some "enc" algorithms. Section 4.1.5 1. See comment 2 above - alternate language would be say MUST be absent unless otherwise specified by the algorithm. It is, in JWA. Also clarified that it is REQUIRED with some "alg" algorithms. [JLS] Then I assume that the following is legal { alg:"RSA1_5", epk:{.}, .} 2. epk should talk about key agreement algorithms not a specific algorithm. Done 3. Content of the key should be specified by the algorithm and not by this document. Done Section 4.1.6 1. Should specify the use the "alg" registry for the zip parameter (in case a new one comes into existence) and this algorithm should be registered as the only algorithm. This could be done, but it is counter to an explicit working group decision to support only one compression algorithm. I'd be glad to do this if the WG decides to open the door to the possibility of additional algorithms. [JLS] I do not feel that this means that it should not be registered. It merely means that we will only register one, and we will make the bar very high for the ability to register a second one. Otherwise this should be a Boolean with a value of true. It either is or is not compressed. Section 4.1.7 1. Should make clear that this is the way of identifying what private key is needed to decrypt the content. Added: this can be used to determine the private key needed to decrypt the JWE 2. Should this be used? It implies that the decryptor needs to do the following: a) Get the keys b) For each key - i) Do I have the private key for this? ii) Does it match the algorithm? iii) Does it work? c) if no function keys found then ---??? Also, the decryptor might use "kid" and/or "use" parameters for deciding which key(s) to use. Obviously, if no applicable key can be located, the decryption will fail. Section 4.1.8 1. See comment 1 above. Ditto Section 4.1.9 1. I would eliminate the (implicit) requirement that the certificate be validated before decryption. There is no reason that a client should not be able to decrypt a message to themselves if their certificate has been revoked or is expired. This is just a requirement at send time. What do others in the working group think of potentially relaxing this requirement? If we do relax it, what alternative language should be used? Section 4.1.11 1. I don't understand the format used here. The data could be either encoded as a string or an array of strings or something else that is a concatenated string form. I've added an example to clarify this. See http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-03#appendix-B [JLS] That is nice that you have added an example. However this does not mean that the text should not be clarified. I think that you really want to say that this field is an array of strings, each element in the array being a base64url encoded certificate. The certificates are ordered such that certificate i is issued by certificate i+1. Is it legal for a partial chain to be presented or must the full chain always be presented? Is there a reason that you are not just using the PEM encoding in this location as well? If there is a requirement for having a chain of certificates in this location, why is there not a requirement for having an array of certificates in the x5t case? As a recipient I should never need more than the EE certificate in order to map from a public key to a private key. Other than letting me know what the chain was that the sender used to validate my certificate, I don't know what the reasoning behind sending the chain would be. 2. Why is this not base64url encoded given that all other locations are? So we're using a standard encoding for certificate chains [JLS] A standard encoding would be using the PEM string or using a CMS certs only. Changing the base64url to remove trailing characters is not really an issue. Unless the new JavaScript CryptoAPIs (as an example) take a base64 encoded certificate as input the user code is going to deal with the encoding/decoding question anyway. 3. See comment 1 above Ditto Section 4.1.12 1. This is so underspecified that I would know how to go about using it. Any code that I wrote would therefore ignore it. Added: When used with a JWK, the "kid" value MAY be used to match a JWK "kid" parameter value. [JLS] This does nothing to change my statement above. In fact it enforces it. Section 4.1.13 1. The list of possible typ values should apparently include the mime registry as well. This is neither in the value registry (which should probably be setup to avoid collisions with mime types) or a URI. See the new Section 7.2 in JWS [JLS] I do not believe that mime types and subtypes are case insensitive values in MIME itself. This needs to be resolved. Section 4.2 1. Should re-iterate the "if you don't know it then reject it" sentence here - it has been a long time since we have seen it. (Ditto for section 4.3) I understand why you're saying this, but we did say "Implementations MUST understand the entire contents of the header; otherwise, the JWE MUST be rejected" in the enclosing section introduction (Section 4), so I'm reluctant to repeat it in 4.2 and especially reluctant to repeat it again so soon in 4.3. Section 5 1. I disagree with the concept of using a key agree algorithm to create the CMK. Look at CMS to see how they handle key agree algorithms to create a key wrap key The key wrap key is unnecessary, as far as I can tell, at least when there's a single recipient. It results in an additional encryption step that seems to me to add no additional security. However, per James Manger's note and my response to it, I do understand that value of having a CMK in the multiple recipients case. I've added this topic to the list of open issues for the working group to discuss. 2. In step 8 - when did you create the encoded JWE header? In step 9. :-) Yes, I'd already seen this and fixed it. 3. Separate the serialization format from the encryption algorithm. This may just affect step 14. Done 4. Note previous discussion on only documenting AEAD algorithms I'm not sure what change you're asking for here? [JLS] I am asking that there only be one set of steps for doing this, and it is for AEAD algorithms. Section 6 1. Separate serialization from message decryption. If alternate serializations are used then step 1 fails. Done 2. Note that you have imposed some additional restrictions on the JSE header in step three - specifically that no duplicate fields exist. This is not in the decryption process. It's input validation for the decryption process, just like step 2 was Section 7 1. If you are using the NIST KDF function, then the length of the output key should really be included in the OtherInfo Again, per my earlier responses to you and Sean on this topic from your JWA comments, since the CMK is randomly generated for each encryption, I believe that the additional parameters add no security value. Adding a key length would only make sense if we were going to use this same CMK to generate other keys using the same Label ("Encryption" or "Integrity") but with a different key length. But we never will, so I believe that the parameter is superfluous. Section 8.1 1. Refer to the registry not to the document (ditto for section 8.2) Done Section 11.1 1. Should there be an optional parameter which describes which serialization method is being used? This could be introduced if the working group adopts a second serialization method, such as the JSON Serialization defined in draft-jones-json-web-encryption-json-serialization, or one of the other candidates. However, a better approach might be to define a different media type value, such as application/jwe-js for the different serialization. Of course, if we have a pure JSON serialization, one could argue for just using the application/json media type. 2. Check with IANA if you or the IESG should be listed under the contact section. Will do ------=_NextPart_000_02ED_01CD651E.33257710 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From:= = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: = Wednesday, July 18, 2012 8:44 AM
To: Jim Schaad; = jose@ietf.org
Subject: RE: json-web-encryption -02 = comments

 

Replies inline…

 

From:= = Jim Schaad [mailto:ietf@augustcellar= s.com]
Sent: Monday, July 16, 2012 6:30 PM
To: = Mike Jones; jose@ietf.org
Subject: RE: = json-web-encryption -02 comments

 

In section 4 –

There is an interesting = question about the following:

{ = alg:”none”, enc:”AES128GCM” = }

 

This returns different = results depending on which test you are using for determining if the = header is a JWE or a JWS.  This belies the last sentence in = paragraph #2.

 

Your example is an = invalid input – either invalid as a JWS because it includes the = extra “enc” member or invalid as a JWE because = “none” is not a valid encryption method.  In either = case, the input MUST be rejected.

 

[JLS2] It is not clear = to me that this is a correct statement.  My implementation does = understand both alg and enc – I don’t see anything that says = they must occur only in the correct contexts.  This is also going = to be effected by the discussion of permit or deny for unknown headers = that is being discussed elsewhere.

 

The sentence you are = referring to reads:  “Both methods will yield the same result.”  I will change this to = “= Both methods will yield the same result for all valid = inputs.”

 

[JLS2] So you are = comfortable with the fact that different implementations may respond = with different error messages based on how they go about doing the = checking of what the structure is going to be.  – = Specifically if they think that a signed or an encrypted message is = going to come first.

 

(By the way, I suspect = you were thinking of the example above in the context of enabling the = option of direct symmetric encryption without using a CMK, per Open = Issue 6 in JWA, which is good. J  I plan to make a proposal on syntax for = that later today.)

 

In Section = 4.1.1

 

It is stated that the = value of “alg” is case sensitive.  It is stated that it = may be a URI.  URIs say that there may be case insensitive portions = of the URI value.  This needs to be = reconciled.

 

The intent is still that = these fields be compared in a case sensitive manner.  These are not = URIs you dereference – they are URIs used as identifiers.  We = could add text something to the effect of “When a StringOrURI = value is a URI and the URI scheme includes portions that are matched in = a case insensitive manner, this specification requires those portions of = the URI be expressed using only lowercase characters, so a = case-sensitive equality test will be effective.”  I’d = add similar text to the registry instructions for these fields as = well.  Does that clarification work for = you?

 

[JLS2] by itself it does = not deal with all of the possible issues.  I don’t think it = matters that they are for de-reference or not.  The issue is the = same in all cases.  However besides the issue of case, there are = also questions on using quoting characters, equivalent characters, utf8 = encoding, I don’t know if there is a problem with doing = canonicalization of order of composite characters or = not.

 

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

 

From:= = Mike Jones [mailto:Michael.Jone= s@microsoft.com]
Sent: Friday, July 06, 2012 11:13 = AM
To: Jim Schaad; jose@ietf.org
Subject: RE: = json-web-encryption -02 comments

 

Thanks once again.  Responses = inline…

 

-----Original Message-----
From: Jim Schaad [mailto:ietf@augustcellar= s.com]
Sent: Thursday, June 07, 2012 11:56 AM
To: jose@ietf.org; draft-= ietf-jose-json-web-encryption@tools.ietf.org
Subject: = json-web-encryption -02 comments

 

Introduction

 

1.  I would separate the introduction into two = paragraphs.  One to address the general encryption issue and one to = address the compact serialization issues.  This will allow for an = easier addition/removal to deal with other serialization = issues.

 

I’m somewhat = confused by this comment, as the introduction doesn’t discuss = serialization.  That concept isn’t introduced until the = “JWE Compact Serialization” term definition in Section 2 and = the presentation of the compact serialization in Section = 3.

 

[JLS] And I am = suggesting that the introduction SHOULD address the fact that a = serialization method is presented in this document.  The process of = encryption and the process of serialization are separate things and both = are covered in this document.  This should be documented in the = abstract.

 

This should also be = picked up in the abstract as well.

 

2.  I find sentence #2 confusing since this = document is defining how to do the encryption process so we are not = really dealing with pre-encrypted content which is what this appears to = me to say.

 

Like JWS, this = sentence has been clarified to:  It represents this content using = JavaScript Object Notation (JSON) <xref = target=3D"RFC4627"/> data = structures.

 

[JLS] I think that I = find the concept that it represents the content as JSON to be weird, = since the final formatting is actually dotted notation if you are = looking at the “compact encryption format” that was covered = in this document.

 

3.  What do you mean by the type of content = being encrypted?  This could either mean the format of the content = (i.e. JSON vs Mime) or the type of content (i.e. a JSON token vs a JSON = signature object).

 

This now reads:  = The JWE cryptographic mechanisms encrypt and provide integrity = protection for arbitrary sequences of bytes.

 

[JLS] I find this = confusing.  A MAC also provides integrity protection and that is in = a different document.

 

 

Section 3

 

1.  Simple clarity s/confidentiality of the = contents of the Plaintext/confidentiality of the = Plaintext/

 

Done

 

Section 4 - JWE Header

 

1.  Do we think parsers can enforce the = uniqueness requirement?

 

See my response in = the JWK comments

 

2.  What does it mean to reject a JWE?  = Should it decrypt and say it is a bad decrypt or should it fail to = decrypt?

 

It should return an = error and return no decrypted data

 

[JLS] This response = would eliminate that ability to do a stream based decode.  That = would return decrypted data and then return the = error.

 

Section 4.1.1

 

1.  You should be constant about what  = you call the encryption key, master key or JWE Encrypted key.  A = search and replace should be done to make them = constant.

 

Now using the term = Content Master Key (CMK) here.  Note that the Content Encryption = Key (CMK) is distinct from (and derived from) the = CMK.

 

2.  Refer to the registry not to the document = for the list of algorithms.

 

Moved the document = reference to be adjacent to the registry reference, saying that both = apply

 

Section 4.1.2

 

1. See = comment 2 above

 

Ditto

 

2.  the encryption algorithm is not used to = secure the cipher text.  It is used to produce the cipher = text

 

Corrected

 

3.  Why does the enc algorithm not require the = existence of a key for it's use?

 

Because the CEK is = derived from the CMK, and so always exists

 

[JLS] and how is that = key known?  Is a wrapped key always required in this case.  =

 

Section 4.1.4

 

 

2.  The presence of this parameter MUST be = specified for all content encryption algorithms.

 

It is, in JWA.  = Also clarified that it is REQUIRED with some “enc” = algorithms.

 

Section 4.1.5

 

1.  See comment 2 above - alternate language = would be say MUST be absent unless otherwise specified by the = algorithm.

 

It is, in JWA.  = Also clarified that it is REQUIRED with some “alg” = algorithms.

 

[JLS] Then I assume = that the following is legal

{ = alg:”RSA1_5”, epk:{…}, = …}

 

2.  epk should talk about key agreement = algorithms not a specific algorithm.

 

Done

 

3.  Content of the key should be specified by = the algorithm and not by this document.

 

Done

 

Section 4.1.6

 

1.  Should specify the use the "alg" = registry for the zip parameter (in case a new one comes into existence) = and this algorithm should be registered as the only = algorithm.

 

This could be done, = but it is counter to an explicit working group decision to support only = one compression algorithm.  I’d be glad to do this if the WG = decides to open the door to the possibility of additional = algorithms.

 

[JLS]  I do not = feel that this means that it should not be registered.  It merely = means that we will only register one, and we will make the bar very high = for the ability to register a second one.  Otherwise this should be = a Boolean with a value of true.  It either is or is not = compressed.

 

Section 4.1.7

 

1.  Should make clear that this is the way of = identifying what private key is needed to decrypt the = content.

 

Added: this can be = used to determine the private key needed to decrypt the = JWE

 

2.  Should this be used?  It implies that = the decryptor needs to do the

following:

a) = Get the keys

b) For each key = -

   i) Do I have the = private key for this?

   = ii) Does it match the algorithm?

   iii) Does it work?

c) if no function keys found then = ---???

 

Also, the decryptor = might use “kid” and/or “use” parameters for = deciding which key(s) to use.  Obviously, if no applicable key can = be located, the decryption will fail.

 

Section 4.1.8

 

1.  See comment 1 above.

 

Ditto

 

Section 4.1.9

 

1.  I would eliminate the (implicit) = requirement that the certificate be validated before decryption.  = There is no reason that a client should not be able to decrypt a message = to themselves if their certificate has been revoked or is expired.  = This is just a requirement at send time.

 

What do others in the = working group think of potentially relaxing this requirement?  If = we do relax it, what alternative language should be = used?

 

Section 4.1.11

 

1.  I don't understand the format used = here.  The data could be either encoded as a string or an array of = strings or something else that is a concatenated string = form.

 

I’ve added an = example to clarify this.  See http://tools.ietf.org/html/draft-ietf-jose-json-web-signature= -03#appendix-B

 

[JLS] That is nice = that you have added an example.  However this does not mean that = the text should not be clarified.  I think that you really want to = say that this field is an array of strings, each element in the array = being a base64url encoded certificate.  The certificates are = ordered such that certificate i is issued by certificate i+1. =

 

Is it legal for a = partial chain to be presented or must the full chain always be = presented?

 

Is there a reason = that you are not just using the PEM encoding in this location as = well?

 

If there is a = requirement for having a chain of certificates in this location, why is = there not a requirement for having an array of certificates in the x5t = case?

 

As a recipient I = should never need more than the EE certificate in order to map from a = public key to a private key.   Other than letting me know what = the chain was that the sender used to validate my certificate, I = don’t know what the reasoning behind sending the chain would = be.

 

2.  Why is this not base64url encoded given = that all other locations are?

 

So we’re using = a standard encoding for certificate chains

 

[JLS] A standard = encoding would be using the PEM string or using a CMS certs only.  =  Changing the base64url to remove trailing characters is not really = an issue.   Unless the new JavaScript CryptoAPIs (as an = example) take a base64 encoded certificate as input the user code is = going to deal with the encoding/decoding question = anyway.

 

3. See comment 1 above

 

Ditto

 

Section 4.1.12

 

1.  This is so underspecified that I would = know how to go about using it.

Any = code that I wrote would therefore ignore it.

 

Added: =     When used with a JWK, the “kid” value MAY = be used to match a JWK “kid” parameter = value.

 

[JLS] This does = nothing to change my statement above.  In fact it enforces = it. 

 

Section 4.1.13

 

1.  The list of possible typ values should = apparently include the mime registry as well.  This is neither in = the value registry (which should probably be setup to avoid collisions = with mime types) or a URI.

 

See the new Section 7.2 in = JWS

 

[JLS] I do not = believe that mime types and subtypes are case insensitive values in MIME = itself.  This needs to be resolved.

 

Section 4.2

 

1.  Should re-iterate the "if you don't = know it then reject it" sentence here - it has been a long time = since we have seen it.

 

(Ditto = for section 4.3)

 

I understand why = you’re saying this, but we did say “Implementations MUST = understand the entire contents of the header; otherwise, the JWE MUST be = rejected” in the enclosing section introduction (Section 4), so = I’m reluctant to repeat it in 4.2 and especially reluctant to = repeat it again so soon in 4.3.

 

Section 5

 

1.  I disagree with the concept of using a key = agree algorithm to create the

CMK.   Look at CMS to see how they handle = key agree algorithms to create a

key wrap key

 

The key wrap key is = unnecessary, as far as I can tell, at least when there’s a single = recipient.  It results in an additional encryption step that seems = to me to add no additional security.

 

However, per James = Manger’s note and my response to it, I do understand that value of = having a CMK in the multiple recipients case.  I’ve added = this topic to the list of open issues for the working group to = discuss.

 

2.  In step 8 - when did you create the = encoded JWE header?

 

In step 9. :-)  = Yes, I’d already seen this and fixed it.

 

3.  Separate the serialization format from the = encryption algorithm.  This may just affect step = 14.

 

Done

 

4.  Note previous discussion on only = documenting AEAD algorithms

 

I’m not sure = what change you’re asking for here?

 

[JLS] I am asking = that there only be one set of steps for doing this, and it is for AEAD = algorithms. 

 

Section 6

 

1.  Separate serialization from message = decryption.  If alternate serializations are used then step 1 = fails.

 

Done

 

2.  Note that you have imposed some additional = restrictions on the JSE header in step three - specifically that no = duplicate fields exist.  This is not in the decryption = process.

 

It’s input = validation for the decryption process, just like step 2 = was

 

Section 7

 

1.  If you are using the NIST KDF function, = then the length of the output key should really be included in the = OtherInfo

 

Again, per my earlier = responses to you and Sean on this topic from your JWA comments, since = the CMK is randomly generated for each encryption, I believe that the = additional parameters add no security value.  Adding a key length = would only make sense if we were going to use this same CMK to generate = other keys using the same Label (“Encryption” or = “Integrity”) but with a different key length.  But we = never will, so I believe that the parameter is = superfluous.

 

Section 8.1

 

1.  Refer to the registry not to the document = (ditto for section 8.2)

 

Done

 

Section 11.1

 

1.  Should there be an optional parameter = which describes which serialization method is being = used?

 

This could be = introduced if the working group adopts a second serialization method, = such as the JSON Serialization defined in = draft-jones-json-web-encryption-json-serialization, or one of the other = candidates.  However, a better approach might be to define a = different media type value, such as application/jwe-js for the different = serialization.

 

Of course, if we have = a pure JSON serialization, one could argue for just using the = application/json media type.

 

2.  Check with IANA if you or the IESG should = be listed under the contact section.

 

Will = do

 

------=_NextPart_000_02ED_01CD651E.33257710-- From ve7jtb@ve7jtb.com Wed Jul 18 22:22:59 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A9121F8609 for ; Wed, 18 Jul 2012 22:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVcR0FLYQK3p for ; Wed, 18 Jul 2012 22:22:57 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0EA21F84F8 for ; Wed, 18 Jul 2012 22:22:57 -0700 (PDT) Received: by yhq56 with SMTP id 56so2617045yhq.31 for ; Wed, 18 Jul 2012 22:23:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=oDNzB+yvjdDsmxalO7wzHfyAeJ/0EV97y8e8Qr6tVmQ=; b=eIymJ+4pxAJX2s+Wi2vVIKzObY96zrBRwYKcXPIEtAdmm5LODW8n0jhlX4Y/dGfoDA pUwyNK8O6+qQvccGnlWoTQppeYoFxcUtHkZNC/2Cs9y9jrS9n5L+kmfJHU7wOq0QXq32 +1yi8FS+oXagp02f02co8Z/7RVIrLqB2UTKTRXXEHs7WIRsULmPryfRviPt/NrK629mT bL7e3mSPZTeg9f7nVEQuAd4typMihbFpxvcBiLsM1a0QeEHVtKpPr4K3IjszNcLMpdTV O3ezFgp8qiCQ1x6J/n/3pU0ZXYE0uBHSsH3nJHvfePxLqrOSkMUyzo+J8V3U+CW4mxPt nWog== Received: by 10.66.89.168 with SMTP id bp8mr933581pab.50.1342675429147; Wed, 18 Jul 2012 22:23:49 -0700 (PDT) Received: from [192.168.43.214] (mobile-198-228-220-143.mycingular.net. [198.228.220.143]) by mx.google.com with ESMTPS id og4sm1043922pbb.48.2012.07.18.22.23.43 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Jul 2012 22:23:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_05E0885C-F85C-4320-92DF-E238FBF6C5CD" From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436673A0B7@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Wed, 18 Jul 2012 23:23:39 -0600 Message-Id: References: <4E1F6AAD24975D4BA5B16804296739436673A0B7@TK5EX14MBXC285.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQl7yikXm49mbv0KfT5zgiF3QQvsjjvV+tAOcnyWHe1Zv9DQ5BMctoodr1xxgI1I/QjSEQFu Cc: "jose@ietf.org" Subject: Re: [jose] Symmetric encryption and key agreement with and without a separate CMK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 05:22:59 -0000 --Apple-Mail=_05E0885C-F85C-4320-92DF-E238FBF6C5CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I agree that is a reasonable approach. In the XMPP example from earlier it was method 2 that they were using = for multiple recipients, and that worked because the receiver requested = the key from the sender after receiving the message. So 2 may be useful in some multi recipient scenarios though probably not = all. John B. On 2012-07-18, at 7:04 PM, Mike Jones wrote: > Hi all, > =20 > I=92ve been thinking about two of our open issues, which are closely = related, and am writing to make a proposal to resolve both of them. The = issues are: > =20 > (1) Currently we specify methods for using symmetric keys to key wrap = a separate Content Master Key (CMK), but no means of using the symmetric = key as the CMK directly. Some applications need this functionality, = both for size and for efficiency reasons. > =20 > (2) Currently we specify methods for performing key agreement and = directly using the resulting key as the CMK to perform block encryption, = but no means of using the agreed-upon key to wrap a separate CMK. When = doing key agreement for multiple recipients, a separate CMK is needed. > =20 > Thus, I propose that we define methods for filling in both of the = holes above, as follows: > =20 > (a) Define =93alg=94:=94dir=94 (direct) to mean that the symmetric key = is directly used as the CMK for the block encryption and integrity = calculations, rather than as a key to wrap the CMK value. > =20 > (b) Define =93alg=94:=94ECDH-ES+A128KW=94 and =93alg=94:=94ECDH-ES+A256K= W=94 to mean that the result of the key agreement is respectively used = as the 128 bit or 256 bit AES Key Wrap key to wrap the CMK. > =20 > Doing this will enable all four flavors, whereas we=92re currently = missing 2 and 3 below: > 1. The symmetric key used to wrap a separate CMK > 2. The symmetric key used as the CMK > 3. The key agreement result used to wrap a separate CMK > 4. The key agreement result used as the CMK > =20 > I recognize that flavors 2 and 4 are not usable with multiple = recipients when methods such as JWE JSON Serialization are used (which = counts on a common CMK value to enable a common ciphertext value). A = note to that effect would be added to the JWA definitions of = =93alg=94:=93ECDH-ES=94 and =93alg=94:=94dir=94 and it would be pointed = out in the JWE-JS spec that =93alg=94 values that utilize a separate CMK = MUST be used when the plaintext is encrypted to multiple recipients. > =20 > Comments? > =20 > -- = Mike > =20 > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_05E0885C-F85C-4320-92DF-E238FBF6C5CD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I agree that is a reasonable = approach.

In the XMPP example from earlier it was = method 2 that they were using for multiple recipients, and that worked = because the receiver requested the key from the sender after receiving = the message.

So 2 may be useful in some multi = recipient scenarios though probably not = all.

John B.

On = 2012-07-18, at 7:04 PM, Mike Jones wrote:

Hi all,
 
I=92ve been thinking about two = of our open issues, which are closely related, and am writing to make a = proposal to resolve both of them.  The issues = are:
 
(1) Currently we = specify methods for using symmetric keys to key wrap a separate Content = Master Key (CMK), but no means of using the symmetric key as the CMK = directly.  Some applications need this functionality, both for size = and for efficiency reasons.
(2) Currently we specify methods for = performing key agreement and directly using the resulting key as the CMK = to perform block encryption, but no means of using the agreed-upon key = to wrap a separate CMK.  When doing key agreement for multiple = recipients, a separate CMK is needed.
 
Thus, I propose that we define = methods for filling in both of the holes above, as = follows:
 
(a) Define =93alg=94:=94dir=94 (direct) to mean that the = symmetric key is directly used as the CMK for the block encryption and = integrity calculations, rather than as a key to wrap the CMK = value.
 
(b) Define = =93alg=94:=94ECDH-ES+A128KW=94 and =93alg=94:=94ECDH-ES+A256KW=94 to = mean that the result of the key agreement is respectively used as the = 128 bit or 256 bit AES Key Wrap key to wrap the = CMK.
 
Doing this will = enable all four flavors, whereas we=92re currently missing 2 and 3 = below:
1.  The symmetric key used to wrap a = separate CMK
2.  The symmetric key = used as the CMK
3.  The key agreement = result used to wrap a separate CMK
4.  The key agreement result used as the = CMK
 
I recognize that = flavors 2 and 4 are not usable with multiple recipients when methods = such as JWE JSON Serialization are used (which counts on a common CMK = value to enable a common ciphertext value).  A note to that effect = would be added to the JWA definitions of =93alg=94:=93ECDH-ES=94 and = =93alg=94:=94dir=94 and it would be pointed out in the JWE-JS spec that = =93alg=94 values that utilize a separate CMK MUST be used when the = plaintext is encrypted to multiple recipients.
 
Comments?
 
 
 
___________________________________________= ____
jose mailing list
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436673A0B7@TK5EX14MBXC285.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-334495122-791714926-1342731442=:11469" Subject: Re: [jose] Symmetric encryption and key agreement with and without a separate CMK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 20:56:31 -0000 ---334495122-791714926-1342731442=:11469 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The proposal is fine as long as it's made clear that cases 2 and 4 are not = =0Auseable for multiple recipient scenarios.=0A=0A-- Edmund=0A=0A=0A=0A=0A_= _______________________________=0AFrom: Mike Jones =0ATo: "jose@ietf.org" =0ASent: Wed, July 18, 2012 6:04= :14 PM=0ASubject: [jose] Symmetric encryption and key agreement with and wi= thout a =0Aseparate CMK=0A=0A =0AHi all,=0A =0AI=E2=80=99ve been thinking a= bout two of our open issues, which are closely related, and =0Aam writing t= o make a proposal to resolve both of them. The issues are:=0A =0A(1) Curre= ntly we specify methods for using symmetric keys to key wrap a separate =0A= Content Master Key (CMK), but no means of using the symmetric key as the CM= K =0Adirectly. Some applications need this functionality, both for size an= d for =0Aefficiency reasons.=0A =0A(2) Currently we specify methods for pe= rforming key agreement and directly using =0Athe resulting key as the CMK t= o perform block encryption, but no means of using =0Athe agreed-upon key to= wrap a separate CMK. When doing key agreement for =0Amultiple recipients= , a separate CMK is needed.=0A =0AThus, I propose that we define methods fo= r filling in both of the holes above, =0Aas follows:=0A =0A(a) Define =E2= =80=9Calg=E2=80=9D:=E2=80=9Ddir=E2=80=9D (direct) to mean that the symmetri= c key is directly used =0Aas the CMK for the block encryption and integrity= calculations, rather than as a =0Akey to wrap the CMK value.=0A =0A(b) Def= ine =E2=80=9Calg=E2=80=9D:=E2=80=9DECDH-ES+A128KW=E2=80=9D and =E2=80=9Calg= =E2=80=9D:=E2=80=9DECDH-ES+A256KW=E2=80=9D to mean that the =0Aresult of th= e key agreement is respectively used as the 128 bit or 256 bit AES =0AKey W= rap key to wrap the CMK.=0A =0ADoing this will enable all four flavors, whe= reas we=E2=80=99re currently missing 2 and 3 =0Abelow:=0A1. The symmetric = key used to wrap a separate CMK=0A2. The symmetric key used as the CMK=0A3= . The key agreement result used to wrap a separate CMK=0A4. The key agree= ment result used as the CMK=0A =0AI recognize that flavors 2 and 4 are not = usable with multiple recipients when =0Amethods such as JWE JSON Serializat= ion are used (which counts on a common CMK =0Avalue to enable a common ciph= ertext value). A note to that effect would be =0Aadded to the JWA definit= ions of =E2=80=9Calg=E2=80=9D:=E2=80=9CECDH-ES=E2=80=9D and =E2=80=9Calg=E2= =80=9D:=E2=80=9Ddir=E2=80=9D and it would be =0Apointed out in the JWE-JS s= pec that =E2=80=9Calg=E2=80=9D values that utilize a separate CMK =0AMUST b= e used when the plaintext is encrypted to multiple recipients.=0A =0ACommen= ts?=0A =0A -= - Mike ---334495122-791714926-1342731442=:11469 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The proposal is fine as long as it's made clear that cases 2 and 4= are not useable for multiple recipient scenarios.

-- Edmund
=
From: Mike Jones <Michael.Jones@micro= soft.com>
To: "jose@= ietf.org" <jose@ietf.org>
Se= nt: Wed, July 18, 2012 6:04:14 PM
Subject: [jose] Symmetric encryption and key agreemen= t with and without a separate CMK

=0A=0A =0A =0A=0A=0A=0A
=0A

Hi all,

=0A

 = ;

=0A

I=E2=80=99ve been thinking about two of our= open issues, which are closely related, and am writing to make a proposal = to resolve both of them.  The issues are:

=0A

 

=0A

(1) Currently we specify methods fo= r using symmetric keys to key wrap a separate Content Master Key (CMK), but= no means of using the symmetric key as the CMK directly.  Some applic= ations need this functionality, both for size and for efficiency=0A reasons= .

=0A

 

=0A

(2) C= urrently we specify methods for performing key agreement and directly using= the resulting key as the CMK to perform block encryption, but no means of = using the agreed-upon key to wrap a separate CMK.  When doing key agre= ement for multiple=0A recipients, a separate CMK is needed.

=0A

 

=0A

Thus, I propose that w= e define methods for filling in both of the holes above, as follows:

= =0A

 

=0A

(a) Define = =E2=80=9Calg=E2=80=9D:=E2=80=9Ddir=E2=80=9D (direct) to mean that the symme= tric key is directly used as the CMK for the block encryption and integrity= calculations, rather than as a key to wrap the CMK value.

=0A

 

=0A

(b) Define =E2=80=9Cal= g=E2=80=9D:=E2=80=9DECDH-ES+A128KW=E2=80=9D and =E2=80=9Calg=E2=80=9D:=E2= =80=9DECDH-ES+A256KW=E2=80=9D to mean that the result of the key agreement = is respectively used as the 128 bit or 256 bit AES Key Wrap key to wrap the= CMK.

=0A

 

=0A

D= oing this will enable all four flavors, whereas we=E2=80=99re currently mis= sing 2 and 3 below:

=0A

1.  The symmetric ke= y used to wrap a separate CMK

=0A

2.  The sy= mmetric key used as the CMK

=0A

3.  The key = agreement result used to wrap a separate CMK

=0A

= 4.  The key agreement result used as the CMK

=0A

 

=0A

I recognize that flavors 2 and 4= are not usable with multiple recipients when methods such as JWE JSON Seri= alization are used (which counts on a common CMK value to enable a common c= iphertext value).  A note to that effect would be added=0A to the JWA = definitions of =E2=80=9Calg=E2=80=9D:=E2=80=9CECDH-ES=E2=80=9D and =E2=80= =9Calg=E2=80=9D:=E2=80=9Ddir=E2=80=9D and it would be pointed out in the JW= E-JS spec that =E2=80=9Calg=E2=80=9D values that utilize a separate CMK MUS= T be used when the plaintext is encrypted to multiple recipients.

=0A  

=0A

Comments?

= =0A

 

=0A

  = ;            &n= bsp;            = ;            &n= bsp;            = ;            -- Mike=

=0A

 

=0A

 = ;

=0A
=0A=0A=0A
=0A=0A=0A=0A
---334495122-791714926-1342731442=:11469-- From mamille2@cisco.com Thu Jul 19 14:44:11 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7F111E80A3 for ; Thu, 19 Jul 2012 14:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.584 X-Spam-Level: X-Spam-Status: No, score=-10.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRsmZB3+zvUR for ; Thu, 19 Jul 2012 14:44:10 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id E9B0211E80E9 for ; Thu, 19 Jul 2012 14:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=7733; q=dns/txt; s=iport; t=1342734304; x=1343943904; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GNpbPJ+xj45l1cax9GOzt7J5TyAzr8W6ihKu8xOr9u8=; b=CBkk3Qd9rRlN62HwCigLOXn4tIXxC9eaboJLa0tzu/sqO54CAN1FgGp/ BeWEZVnHQqFwjB5IJBe0QyWBOLFMkXBdFXprSo8MqGzCMgaq5kC3JtYoD VNx6Hnm3AqaQm1bDCU0fzEza3GQYpyfcj6wpE2ZfbHqx7GzVbTzdpSIZW Q=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADx/CFCtJV2c/2dsb2JhbABFuUmBB4IgAQEBAwEBAQEPAVsLBQsCAQgOCi4CJQslAgQOBQ4Uh2UGC55KoBOLTIYAYAOOVYEhhU6BE40QgWaCXw X-IronPort-AV: E=Sophos;i="4.77,617,1336348800"; d="sig'?p7s'?scan'208";a="103613034" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 19 Jul 2012 21:45:03 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6JLj3q8025742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jul 2012 21:45:03 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.238]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Thu, 19 Jul 2012 16:45:03 -0500 From: "Matt Miller (mamille2)" To: John Bradley Thread-Topic: [jose] Symmetric encryption and key agreement with and without a separate CMK Thread-Index: AQHNZW6xJN2IwR1Lw0WCUKEZJYqZFZcxeImA Date: Thu, 19 Jul 2012 21:45:02 +0000 Message-ID: <5E9D18F7-6E65-4E74-AFD0-5085ABB9128F@cisco.com> References: <4E1F6AAD24975D4BA5B16804296739436673A0B7@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 1.3.3 x-originating-ip: [64.101.72.28] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19050.003 x-tm-as-result: No--47.582700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-34--645099934" MIME-Version: 1.0 Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] Symmetric encryption and key agreement with and without a separate CMK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 21:44:11 -0000 --Apple-Mail-34--645099934 Content-Type: multipart/signed; boundary=Apple-Mail-33--645099941; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-33--645099941 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 18, 2012, at 23:23, John Bradley wrote: > I agree that is a reasonable approach. >=20 I don't know that I support a). I can't articulate exactly why, other = than to say it gives me the willies (-: > In the XMPP example from earlier it was method 2 that they were using = for multiple recipients, and that worked because the receiver requested = the key from the sender after receiving the message. >=20 That was true, now the CMK is wrapped by a separate "SMK" (Session = Master Key). See < http://tools.ietf.org/html/draft-miller-xmpp-e2e-02 = >, which I thought I had forwarded to this list (-: > So 2 may be useful in some multi recipient scenarios though probably = not all. >=20 > John B. >=20 > On 2012-07-18, at 7:04 PM, Mike Jones wrote: >=20 >> Hi all, >>=20 >> I=92ve been thinking about two of our open issues, which are closely = related, and am writing to make a proposal to resolve both of them. The = issues are: >>=20 >> (1) Currently we specify methods for using symmetric keys to key wrap = a separate Content Master Key (CMK), but no means of using the symmetric = key as the CMK directly. Some applications need this functionality, = both for size and for efficiency reasons. >>=20 >> (2) Currently we specify methods for performing key agreement and = directly using the resulting key as the CMK to perform block encryption, = but no means of using the agreed-upon key to wrap a separate CMK. When = doing key agreement for multiple recipients, a separate CMK is needed. >>=20 >> Thus, I propose that we define methods for filling in both of the = holes above, as follows: >>=20 >> (a) Define =93alg=94:=94dir=94 (direct) to mean that the symmetric = key is directly used as the CMK for the block encryption and integrity = calculations, rather than as a key to wrap the CMK value. >>=20 >> (b) Define =93alg=94:=94ECDH-ES+A128KW=94 and =93alg=94:=94ECDH-ES+A256= KW=94 to mean that the result of the key agreement is respectively used = as the 128 bit or 256 bit AES Key Wrap key to wrap the CMK. >>=20 >> Doing this will enable all four flavors, whereas we=92re currently = missing 2 and 3 below: >> 1. The symmetric key used to wrap a separate CMK >> 2. The symmetric key used as the CMK >> 3. The key agreement result used to wrap a separate CMK >> 4. The key agreement result used as the CMK >>=20 >> I recognize that flavors 2 and 4 are not usable with multiple = recipients when methods such as JWE JSON Serialization are used (which = counts on a common CMK value to enable a common ciphertext value). A = note to that effect would be added to the JWA definitions of = =93alg=94:=93ECDH-ES=94 and =93alg=94:=94dir=94 and it would be pointed = out in the JWE-JS spec that =93alg=94 values that utilize a separate CMK = MUST be used when the plaintext is encrypted to multiple recipients. >>=20 >> Comments? >>=20 >> -- = Mike >>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose - m&m Matt Miller - Cisco Systems, Inc. --Apple-Mail-33--645099941 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcxOTIxNDUy MFowIwYJKoZIhvcNAQkEMRYEFFxDs1Flcf2xc1Uyu8tSfJiGY3TqMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQAxTXHjgC2tpx7OvpRQEmvhNWNOOhB/W2ZnoWeqL4wc5xtqamYjyo3Rluts OWW1DgwyPvx7hpFbJCM4vLtRJ832C3lrBxsd1iz1BDjelTZgypNpRv9meEG44jgjsLRfzk4rhAii Y21z7JaDux3AOrVHy94OydOVe6MXnW4ZManBa1qH/fuKafJN0Pe5OkJik5GVOaC1dmX4SYcde/F5 lY3kjZR6eY0eQGDrh8dP0QCv3rnGjKOOPiIRSQ5uo2s+eaQsywxFAt+zcUFDonPwjzwpJN1pPOdG r0ASCN1bS+nenzuV/HxSyOfkx/hj2A8TkiLzohLwk4aubKVNvkP4/XbwAAAAAAAA --Apple-Mail-33--645099941-- --Apple-Mail-34--645099934 Content-Type: application/pgp-signature; x-mac-type=70674453; name="PGP.sig" Content-Description: This is a digitally signed message part Content-Disposition: inline; filename="PGP.sig" Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJQCH/wAAoJEJq6Ou0cgrSP8Y0IAJg6UIT5IVvQNDtaGiH4JsQ7 tFnCrsromaBHXWSyGVczGuCxQbb+8QtBVsz7pl+kVYJmczsZmxXJzqA951xE5tFA QJBvQYcFEYAmrJEUzK4j6AKptKRYQ+xxsdg9jRWexQeLSIxY74dtRAfBWM+1BACW AqXtZFDL+bVMjjM9+/xUyJlVY3/NCMr9rOAQSlC2bMX6A8UHqQ8ep96XUF5qtamZ 2vvp29er3YrbCpsNy1TZtjKxYs8ZhkqKEDekyBdFMTQwFZJjiDDuMVLmFhPr8voB Y0BCV0MiLwZA0XmYJhZcVjR9mWfSqp9dsyvlxYGg9gabnzjH9u+YaFKd+KGyl5g= =9qfQ -----END PGP SIGNATURE----- --Apple-Mail-34--645099934-- From ve7jtb@ve7jtb.com Thu Jul 19 14:57:09 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A67811E80A3 for ; Thu, 19 Jul 2012 14:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.826 X-Spam-Level: X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWmG5pUmCUHK for ; Thu, 19 Jul 2012 14:57:08 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 32BA711E80C1 for ; Thu, 19 Jul 2012 14:57:07 -0700 (PDT) Received: by qcsg15 with SMTP id g15so2787444qcs.27 for ; Thu, 19 Jul 2012 14:58:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=MjmwiSWXzPoP0e/9Zim9MPG4KErYYN2tS4cQzgdCUi8=; b=UQXsOxiGVDS1mYPikCMjdYZuDnXs5w8zciTWhYwCngtpIuAlRdQKHCnXbYa8NiouPa qJ1Pg+SRzEb5sh2rrPjHQPiZ6v9anbBFsgT0OcLDu6ws2cuKL0zv1H9LZnr2kN5nHZSF +qxVFzusqPRYpPWVp49uWLaUFG0Gac+seRLNKFVS6oK1+lUvk2i4eQ92kv6cvUy9GtVR v5YylxhnLI7peqLntBCK/fGCI7Kye94tTyEjt1wUBkBNhBFan95fZdn85b5xV27RVHnX 8D6w1/a/CqDFULFmEXPQYIXD1NxSQ7unvhAXF+nfdzQGuzTBSChckcudMph/9NXQ2qO7 3dDQ== Received: by 10.224.202.136 with SMTP id fe8mr6505464qab.17.1342735081571; Thu, 19 Jul 2012 14:58:01 -0700 (PDT) Received: from [172.16.163.11] ([66.110.180.66]) by mx.google.com with ESMTPS id z9sm3883548qae.15.2012.07.19.14.57.59 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jul 2012 14:58:00 -0700 (PDT) References: <4E1F6AAD24975D4BA5B16804296739436673A0B7@TK5EX14MBXC285.redmond.corp.microsoft.com> <5E9D18F7-6E65-4E74-AFD0-5085ABB9128F@cisco.com> In-Reply-To: <5E9D18F7-6E65-4E74-AFD0-5085ABB9128F@cisco.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-B536C8F9-02EF-4179-A3DF-21E99AC9032F; protocol="application/pkcs7-signature" Message-Id: X-Mailer: iPad Mail (9B206) From: John Bradley Date: Thu, 19 Jul 2012 15:57:57 -0600 To: "Matt Miller (mamille2)" X-Gm-Message-State: ALoCoQkV3l71SjUA3xU0XHDJYuxAJfdhoj0KB3b+zsY0LqoeqksU5t0kM4qz+DkDZd9X3QGwglY4 Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] Symmetric encryption and key agreement with and without a separate CMK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 21:57:09 -0000 --Apple-Mail-B536C8F9-02EF-4179-A3DF-21E99AC9032F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sorry I missed your post. I will have a look. =20 The idea with 1 is that it allows for the rotation of the key for the stream= cypher without the need to negotiate new shared secrets.=20 What bothers you about it.=20 We can meet up in Vancouver if you are coming=20 John B.=20 Sent from my iPad On 2012-07-19, at 3:45 PM, "Matt Miller (mamille2)" wro= te: >=20 > On Jul 18, 2012, at 23:23, John Bradley wrote: >=20 >> I agree that is a reasonable approach. >>=20 >=20 > I don't know that I support a). I can't articulate exactly why, other tha= n to say it gives me the willies (-: >=20 >> In the XMPP example from earlier it was method 2 that they were using for= multiple recipients, and that worked because the receiver requested the key= from the sender after receiving the message. >>=20 >=20 > That was true, now the CMK is wrapped by a separate "SMK" (Session Master K= ey). See < http://tools.ietf.org/html/draft-miller-xmpp-e2e-02 >, which I t= hought I had forwarded to this list (-: >=20 >> So 2 may be useful in some multi recipient scenarios though probably not a= ll. >>=20 >> John B. >>=20 >> On 2012-07-18, at 7:04 PM, Mike Jones wrote: >>=20 >>> Hi all, >>>=20 >>> I=E2=80=99ve been thinking about two of our open issues, which are close= ly related, and am writing to make a proposal to resolve both of them. The i= ssues are: >>>=20 >>> (1) Currently we specify methods for using symmetric keys to key wrap a s= eparate Content Master Key (CMK), but no means of using the symmetric key as= the CMK directly. Some applications need this functionality, both for size= and for efficiency reasons. >>>=20 >>> (2) Currently we specify methods for performing key agreement and direct= ly using the resulting key as the CMK to perform block encryption, but no me= ans of using the agreed-upon key to wrap a separate CMK. When doing key agr= eement for multiple recipients, a separate CMK is needed. >>>=20 >>> Thus, I propose that we define methods for filling in both of the holes a= bove, as follows: >>>=20 >>> (a) Define =E2=80=9Calg=E2=80=9D:=E2=80=9Ddir=E2=80=9D (direct) to mean t= hat the symmetric key is directly used as the CMK for the block encryption a= nd integrity calculations, rather than as a key to wrap the CMK value. >>>=20 >>> (b) Define =E2=80=9Calg=E2=80=9D:=E2=80=9DECDH-ES+A128KW=E2=80=9D and =E2= =80=9Calg=E2=80=9D:=E2=80=9DECDH-ES+A256KW=E2=80=9D to mean that the result o= f the key agreement is respectively used as the 128 bit or 256 bit AES Key W= rap key to wrap the CMK. >>>=20 >>> Doing this will enable all four flavors, whereas we=E2=80=99re currently= missing 2 and 3 below: >>> 1. The symmetric key used to wrap a separate CMK >>> 2. The symmetric key used as the CMK >>> 3. The key agreement result used to wrap a separate CMK >>> 4. The key agreement result used as the CMK >>>=20 >>> I recognize that flavors 2 and 4 are not usable with multiple recipients= when methods such as JWE JSON Serialization are used (which counts on a com= mon CMK value to enable a common ciphertext value). A note to that effect w= ould be added to the JWA definitions of =E2=80=9Calg=E2=80=9D:=E2=80=9CECDH-= ES=E2=80=9D and =E2=80=9Calg=E2=80=9D:=E2=80=9Ddir=E2=80=9D and it would be p= ointed out in the JWE-JS spec that =E2=80=9Calg=E2=80=9D values that utilize= a separate CMK MUST be used when the plaintext is encrypted to multiple rec= ipients. >>>=20 >>> Comments? >>>=20 >>> -- Mike >>>=20 >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 >=20 > - m&m >=20 > Matt Miller - > Cisco Systems, Inc. >=20 --Apple-Mail-B536C8F9-02EF-4179-A3DF-21E99AC9032F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVvjCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMIIHyTCCBbGgAwIBAgIBATANBgkqhkiG9w0B AQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM2WhcNMzYwOTE3MTk0NjM2WjB9MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDBiNsJvGxGfHiflXu1M5DycmLW wTYgIiRezul38kMKogZkpMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v/uqwQVlntsQGfQqedIXW eUyAN3rfOQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9ujPW3U3eCztKS5/CJi/6 tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6RtYTKqi5pquDSR3l8u/d 5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNiHzvEvqBTViVsUQn3qqvKv3b9bZvz ndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMMAv+Z6+hsTXBbKWWc3apdzK8BMewM69KN6Oqce+Zu 9ydmDBpI125C4z/eIT574Q1w+2OqqGwaVLRcJXrJosmLFqa7LH4XXgVNWG4SHQHuEhANxjJ/GP/8 9PrNbpHoNkm+Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN0nZPV/+Qt+OR0t3vwmC3 Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOzEmDyei+B26Nu/yYwl/WL 3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwIDAQABo4ICUjCCAk4wDAYDVR0T BAUwAwEB/zALBgNVHQ8EBAMCAa4wHQYDVR0OBBYEFE4L7xqkQFulF2mHMMo0aEPQQa7yMGQGA1Ud HwRdMFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMIIBXQYDVR0gBIIBVDCCAVAw ggFMBgsrBgEEAYG1NwEBATCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJt ZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20p IEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGlj eSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZI AYb4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVlIFNTTCBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAFmyZ9GYMNPXQhV59CuzaEE44HF7fpiUF S5Eyweg78T3dRAlbB0mKKctmArexmvclmAk8jhvh3TaHK0u7aNM5Zj2gJsfyOZEdUauCe37Vzlrk 4gNXcGmXCPleWKYK34wGmkUWFjgKXlf2Ysd6AgXmvB618p70qSmD+LIU424oh0TDkBreOKk8rENN ZEXO3SipXPJzewT4F+irsfMuXGRuczE6Eri8sxHkfY+BUZo7jYn0TZNmezwD7dOaHZrzZVD1oNB1 ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3fsNrarnDy0RLrHiQi+fHLB5LEUTINFInzQpd n4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZEoalHmdkrQYuL6lwhceWD3yJZfWOQ1QOq92l gDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+PwqyvqCUqDvr0tVk+vBtfAii6w0TiYiBKGHLHVK t+V9E9e4DGTANtLJL4YSjCMJwRuCO3NJo2pXh5Tl1njFmUNj403gdy3hZZlyaQQaRwnmDwFWJPsf vw55qVguucQJAX6Vum0ABj6y6koQOdjQK/W/7HW/lwLFCRsI3FU34oH7N4RDYiDK51ZLZer+bMEk kyShNOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14xggNsMIIDaAIBATCBkzCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgIeXDAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA3MTkyMTU3NTlaMCMGCSqGSIb3DQEJBDEWBBRGQtRs q+EduKmuT/4laIIaiUqYXjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDANBgkqhkiG9w0BAQEFAASCAQBnOsqHfnsnlrqdyyKuDpJ3s5ls2tdNzAmOuPu9 P61WYttbabb8YsM41hgOwgFuUhhjhfImQvtmboh+IQ82eu4vV/koo++tZRhn0OP1z7pBxByIewLA zARnBgFeHT+mdMM+rjmUSPo1hAahvQXHhbo4L+Cy4fEXRSQyWtEk//BdHC3edKnXWbU1uJccgxDY 5WtUcJMvIs8BoA+4p04cpKX/3eA/UObX6J8N/YHDWtTh2eSnqFp5JMgdrzsmhmOEQQjq82OI5EP0 KvetWvaPLjbdBWmkxmMt9e5qsWXQE/L76CFk8jArHQhpZnx70sqHQVHThW9RLDeBlxi4e5LGcr87 AAAAAAAA --Apple-Mail-B536C8F9-02EF-4179-A3DF-21E99AC9032F-- From Michael.Jones@microsoft.com Thu Jul 19 15:06:51 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFC221F85F4 for ; Thu, 19 Jul 2012 15:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.786 X-Spam-Level: X-Spam-Status: No, score=-3.786 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KR5TUqoolsXc for ; Thu, 19 Jul 2012 15:06:50 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id E816721F85F3 for ; Thu, 19 Jul 2012 15:06:49 -0700 (PDT) Received: from mail197-co1-R.bigfish.com (10.243.78.244) by CO1EHSOBE004.bigfish.com (10.243.66.67) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Jul 2012 22:07:43 +0000 Received: from mail197-co1 (localhost [127.0.0.1]) by mail197-co1-R.bigfish.com (Postfix) with ESMTP id 31D6E2004D7; Thu, 19 Jul 2012 22:07:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -35 X-BigFish: VS-35(zz98dI9371Ic89bh936eI542Mdf9M1432I14ffIzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h93fhd25hf0ah107ah) Received-SPF: pass (mail197-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail197-co1 (localhost.localdomain [127.0.0.1]) by mail197-co1 (MessageSwitch) id 1342735661452294_9649; Thu, 19 Jul 2012 22:07:41 +0000 (UTC) Received: from CO1EHSMHS029.bigfish.com (unknown [10.243.78.231]) by mail197-co1.bigfish.com (Postfix) with ESMTP id 6A31230004C; Thu, 19 Jul 2012 22:07:41 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS029.bigfish.com (10.243.66.39) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 19 Jul 2012 22:07:41 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0298.005; Thu, 19 Jul 2012 22:07:40 +0000 From: Mike Jones To: John Bradley , "Matt Miller (mamille2)" Thread-Topic: [jose] Symmetric encryption and key agreement with and without a separate CMK Thread-Index: AQHNZfmTHYi6UALHG0eHQvpILlzQ+pcxJ5dQ Date: Thu, 19 Jul 2012 22:07:39 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436673B633@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436673A0B7@TK5EX14MBXC285.redmond.corp.microsoft.com> <5E9D18F7-6E65-4E74-AFD0-5085ABB9128F@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Symmetric encryption and key agreement with and without a separate CMK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 22:06:51 -0000 TWF0dCwgaWYgeW91IGxvb2sgYXQgdGhlIGV4YW1wbGVzIGluIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1lbmNyeXB0aW9uLTA0I3NlY3Rpb24tMy4x IGFuZCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIt ZW5jcnlwdGlvbi0wNCNzZWN0aW9uLTMuMiwgeW91J2xsIHNlZSB0aGF0IHRoZSBlbmNyeXB0ZWQg a2V5IG9jY3VwaWVzIG1vcmUgdGhhbiBoYWxmIHRoZSB0b3RhbCBzcGFjZSBvZiB0aGUgSldFIGlu IHRob3NlIGV4YW1wbGVzIC0gMzQyIGNoYXJhY3RlcnMgb3V0IG9mIDU5NyBhbmQgNDc1IHJlc3Bl Y3RpdmVseSwgdG8gYmUgcHJlY2lzZS4gIFRoYXQncyBhIGJpZyBkZWFsIHdoZW4gb3BlcmF0aW5n IGluIHNwYWNlLWNvbnN0cmFpbmVkIGVudmlyb25tZW50cywgc3VjaCBhcyBwYXNzaW5nIEpXVHMg YXMgVVJJIHF1ZXJ5IHBhcmFtZXRlcnMgLSB3aGVyZSB0aGUgdG90YWwgVVJMIGxlbmd0aCBpcyBv ZnRlbiBsaW1pdGVkIHRvIDIwNDggY2hhcmFjdGVycyBvciBzb21ldGltZXMgbGVzcy4gIFBsdXMg dGhlcmUncyBhIHNpZ25pZmljYW50IHBlcmZvcm1hbmNlIGFkdmFudGFnZSBpbiBub3QgaGF2aW5n IHRvIGRvIHRoZSBrZXlnZW4gZm9yIHRoZSBDTUsgb3IgdHdvIGVuY3J5cHRpb25zLCByYXRoZXIg dGhhbiBvbmUuICBUaGUgZGlyZWN0IGVuY3J5cHRpb24gbW9kZSBtYXkgbm90IGJlIGZvciBldmVy eW9uZSwgYnV0IGZvciB0aG9zZSB0aGF0IG5lZWQgaXQsIGl0IGNhbiBiZSB0aGUgZGlmZmVyZW5j ZSBiZXR3ZWVuIG1lZXRpbmcgc3BhY2UgYW5kIHBlcmZvcm1hbmNlIGJ1ZGdldHMsIG9yIG5vdC4N Cg0KTGlrZSBKb2huLCBJJ2QgYmUgZ2xhZCB0byB0YWxrIHdpdGggeW91IGFib3V0IHRoaXMgaW4g VmFuY291dmVyLg0KDQoJCQkJQmVzdCB3aXNoZXMsDQoJCQkJLS0gTWlrZQ0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSm9obiBCcmFkbGV5IFttYWlsdG86dmU3anRiQHZlN2p0 Yi5jb21dIA0KU2VudDogVGh1cnNkYXksIEp1bHkgMTksIDIwMTIgMjo1OCBQTQ0KVG86IE1hdHQg TWlsbGVyIChtYW1pbGxlMikNCkNjOiBNaWtlIEpvbmVzOyBqb3NlQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW2pvc2VdIFN5bW1ldHJpYyBlbmNyeXB0aW9uIGFuZCBrZXkgYWdyZWVtZW50IHdpdGgg YW5kIHdpdGhvdXQgYSBzZXBhcmF0ZSBDTUsNCg0KU29ycnkgSSBtaXNzZWQgeW91ciBwb3N0LiAg SSB3aWxsIGhhdmUgYSBsb29rLiAgDQoNClRoZSBpZGVhIHdpdGggMSBpcyB0aGF0IGl0IGFsbG93 cyBmb3IgdGhlIHJvdGF0aW9uIG9mIHRoZSBrZXkgZm9yIHRoZSBzdHJlYW0gY3lwaGVyIHdpdGhv dXQgdGhlIG5lZWQgdG8gbmVnb3RpYXRlIG5ldyBzaGFyZWQgc2VjcmV0cy4gDQoNCldoYXQgYm90 aGVycyB5b3UgYWJvdXQgaXQuIA0KDQpXZSBjYW4gbWVldCB1cCBpbiBWYW5jb3V2ZXIgaWYgeW91 IGFyZSBjb21pbmcgDQoNCkpvaG4gQi4gDQoNClNlbnQgZnJvbSBteSBpUGFkDQoNCk9uIDIwMTIt MDctMTksIGF0IDM6NDUgUE0sICJNYXR0IE1pbGxlciAobWFtaWxsZTIpIiA8bWFtaWxsZTJAY2lz Y28uY29tPiB3cm90ZToNCg0KPiANCj4gT24gSnVsIDE4LCAyMDEyLCBhdCAyMzoyMywgSm9obiBC cmFkbGV5IHdyb3RlOg0KPiANCj4+IEkgYWdyZWUgdGhhdCBpcyBhIHJlYXNvbmFibGUgYXBwcm9h Y2guDQo+PiANCj4gDQo+IEkgZG9uJ3Qga25vdyB0aGF0IEkgc3VwcG9ydCBhKS4gIEkgY2FuJ3Qg YXJ0aWN1bGF0ZSBleGFjdGx5IHdoeSwgb3RoZXIgdGhhbiB0byBzYXkgaXQgZ2l2ZXMgbWUgdGhl IHdpbGxpZXMgKC06DQo+IA0KPj4gSW4gdGhlIFhNUFAgZXhhbXBsZSBmcm9tIGVhcmxpZXIgaXQg d2FzIG1ldGhvZCAyIHRoYXQgdGhleSB3ZXJlIHVzaW5nIGZvciBtdWx0aXBsZSByZWNpcGllbnRz LCBhbmQgdGhhdCB3b3JrZWQgYmVjYXVzZSB0aGUgcmVjZWl2ZXIgcmVxdWVzdGVkIHRoZSBrZXkg ZnJvbSB0aGUgc2VuZGVyIGFmdGVyIHJlY2VpdmluZyB0aGUgbWVzc2FnZS4NCj4+IA0KPiANCj4g VGhhdCB3YXMgdHJ1ZSwgbm93IHRoZSBDTUsgaXMgd3JhcHBlZCBieSBhIHNlcGFyYXRlICJTTUsi IChTZXNzaW9uIE1hc3RlciBLZXkpLiAgU2VlIDwgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtbWlsbGVyLXhtcHAtZTJlLTAyID4sIHdoaWNoIEkgdGhvdWdodCBJIGhhZCBmb3J3YXJk ZWQgdG8gdGhpcyBsaXN0ICgtOg0KPiANCj4+IFNvIDIgbWF5IGJlIHVzZWZ1bCBpbiBzb21lIG11 bHRpIHJlY2lwaWVudCBzY2VuYXJpb3MgdGhvdWdoIHByb2JhYmx5IG5vdCBhbGwuDQo+PiANCj4+ IEpvaG4gQi4NCj4+IA0KPj4gT24gMjAxMi0wNy0xOCwgYXQgNzowNCBQTSwgTWlrZSBKb25lcyB3 cm90ZToNCj4+IA0KPj4+IEhpIGFsbCwNCj4+PiANCj4+PiBJ4oCZdmUgYmVlbiB0aGlua2luZyBh Ym91dCB0d28gb2Ygb3VyIG9wZW4gaXNzdWVzLCB3aGljaCBhcmUgY2xvc2VseSByZWxhdGVkLCBh bmQgYW0gd3JpdGluZyB0byBtYWtlIGEgcHJvcG9zYWwgdG8gcmVzb2x2ZSBib3RoIG9mIHRoZW0u ICBUaGUgaXNzdWVzIGFyZToNCj4+PiANCj4+PiAoMSkgQ3VycmVudGx5IHdlIHNwZWNpZnkgbWV0 aG9kcyBmb3IgdXNpbmcgc3ltbWV0cmljIGtleXMgdG8ga2V5IHdyYXAgYSBzZXBhcmF0ZSBDb250 ZW50IE1hc3RlciBLZXkgKENNSyksIGJ1dCBubyBtZWFucyBvZiB1c2luZyB0aGUgc3ltbWV0cmlj IGtleSBhcyB0aGUgQ01LIGRpcmVjdGx5LiAgU29tZSBhcHBsaWNhdGlvbnMgbmVlZCB0aGlzIGZ1 bmN0aW9uYWxpdHksIGJvdGggZm9yIHNpemUgYW5kIGZvciBlZmZpY2llbmN5IHJlYXNvbnMuDQo+ Pj4gDQo+Pj4gKDIpIEN1cnJlbnRseSB3ZSBzcGVjaWZ5IG1ldGhvZHMgZm9yIHBlcmZvcm1pbmcg a2V5IGFncmVlbWVudCBhbmQgZGlyZWN0bHkgdXNpbmcgdGhlIHJlc3VsdGluZyBrZXkgYXMgdGhl IENNSyB0byBwZXJmb3JtIGJsb2NrIGVuY3J5cHRpb24sIGJ1dCBubyBtZWFucyBvZiB1c2luZyB0 aGUgYWdyZWVkLXVwb24ga2V5IHRvIHdyYXAgYSBzZXBhcmF0ZSBDTUsuICBXaGVuIGRvaW5nIGtl eSBhZ3JlZW1lbnQgZm9yIG11bHRpcGxlIHJlY2lwaWVudHMsIGEgc2VwYXJhdGUgQ01LIGlzIG5l ZWRlZC4NCj4+PiANCj4+PiBUaHVzLCBJIHByb3Bvc2UgdGhhdCB3ZSBkZWZpbmUgbWV0aG9kcyBm b3IgZmlsbGluZyBpbiBib3RoIG9mIHRoZSBob2xlcyBhYm92ZSwgYXMgZm9sbG93czoNCj4+PiAN Cj4+PiAoYSkgRGVmaW5lIOKAnGFsZ+KAnTrigJ1kaXLigJ0gKGRpcmVjdCkgdG8gbWVhbiB0aGF0 IHRoZSBzeW1tZXRyaWMga2V5IGlzIGRpcmVjdGx5IHVzZWQgYXMgdGhlIENNSyBmb3IgdGhlIGJs b2NrIGVuY3J5cHRpb24gYW5kIGludGVncml0eSBjYWxjdWxhdGlvbnMsIHJhdGhlciB0aGFuIGFz IGEga2V5IHRvIHdyYXAgdGhlIENNSyB2YWx1ZS4NCj4+PiANCj4+PiAoYikgRGVmaW5lIOKAnGFs Z+KAnTrigJ1FQ0RILUVTK0ExMjhLV+KAnSBhbmQg4oCcYWxn4oCdOuKAnUVDREgtRVMrQTI1NktX 4oCdIHRvIG1lYW4gdGhhdCB0aGUgcmVzdWx0IG9mIHRoZSBrZXkgYWdyZWVtZW50IGlzIHJlc3Bl Y3RpdmVseSB1c2VkIGFzIHRoZSAxMjggYml0IG9yIDI1NiBiaXQgQUVTIEtleSBXcmFwIGtleSB0 byB3cmFwIHRoZSBDTUsuDQo+Pj4gDQo+Pj4gRG9pbmcgdGhpcyB3aWxsIGVuYWJsZSBhbGwgZm91 ciBmbGF2b3JzLCB3aGVyZWFzIHdl4oCZcmUgY3VycmVudGx5IG1pc3NpbmcgMiBhbmQgMyBiZWxv dzoNCj4+PiAxLiAgVGhlIHN5bW1ldHJpYyBrZXkgdXNlZCB0byB3cmFwIGEgc2VwYXJhdGUgQ01L DQo+Pj4gMi4gIFRoZSBzeW1tZXRyaWMga2V5IHVzZWQgYXMgdGhlIENNSw0KPj4+IDMuICBUaGUg a2V5IGFncmVlbWVudCByZXN1bHQgdXNlZCB0byB3cmFwIGEgc2VwYXJhdGUgQ01LDQo+Pj4gNC4g IFRoZSBrZXkgYWdyZWVtZW50IHJlc3VsdCB1c2VkIGFzIHRoZSBDTUsNCj4+PiANCj4+PiBJIHJl Y29nbml6ZSB0aGF0IGZsYXZvcnMgMiBhbmQgNCBhcmUgbm90IHVzYWJsZSB3aXRoIG11bHRpcGxl IHJlY2lwaWVudHMgd2hlbiBtZXRob2RzIHN1Y2ggYXMgSldFIEpTT04gU2VyaWFsaXphdGlvbiBh cmUgdXNlZCAod2hpY2ggY291bnRzIG9uIGEgY29tbW9uIENNSyB2YWx1ZSB0byBlbmFibGUgYSBj b21tb24gY2lwaGVydGV4dCB2YWx1ZSkuICBBIG5vdGUgdG8gdGhhdCBlZmZlY3Qgd291bGQgYmUg YWRkZWQgdG8gdGhlIEpXQSBkZWZpbml0aW9ucyBvZiDigJxhbGfigJ064oCcRUNESC1FU+KAnSBh bmQg4oCcYWxn4oCdOuKAnWRpcuKAnSBhbmQgaXQgd291bGQgYmUgcG9pbnRlZCBvdXQgaW4gdGhl IEpXRS1KUyBzcGVjIHRoYXQg4oCcYWxn4oCdIHZhbHVlcyB0aGF0IHV0aWxpemUgYSBzZXBhcmF0 ZSBDTUsgTVVTVCBiZSB1c2VkIHdoZW4gdGhlIHBsYWludGV4dCBpcyBlbmNyeXB0ZWQgdG8gbXVs dGlwbGUgcmVjaXBpZW50cy4NCj4+PiANCj4+PiBDb21tZW50cz8NCj4+PiANCj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0t IE1pa2UNCj4+PiANCj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+IGpvc2UgbWFpbGluZyBsaXN0DQo+Pj4gam9zZUBpZXRmLm9yZw0K Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZQ0KPj4gDQo+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gam9zZSBt YWlsaW5nIGxpc3QNCj4+IGpvc2VAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vam9zZQ0KPiANCj4gDQo+IC0gbSZtDQo+IA0KPiBNYXR0IE1pbGxlciAt IDxtYW1pbGxlMkBjaXNjby5jb20+DQo+IENpc2NvIFN5c3RlbXMsIEluYy4NCj4gDQo= From dick.hardt@gmail.com Thu Jul 19 15:20:19 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71FB11E80A2 for ; Thu, 19 Jul 2012 15:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPcYDMdnQ+7m for ; Thu, 19 Jul 2012 15:20:13 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A9CA021F86C1 for ; Thu, 19 Jul 2012 15:20:12 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so5197080pbc.31 for ; Thu, 19 Jul 2012 15:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=fp32wKpQC/LTBuvsLiuqIdsfX3+Cs/SGdHZiOEHC9bo=; b=jNs4FytxVgQ7nAQkvblqGGOwp2XEDLZQs0YD//G8Z9k1YYx7whx8Ixoh2FQYrS0i3O gALyJGiCH/nCzrRAC+xoQDe2UT5MqXBAwvZt7DX1ZnMSmsWCUkWE3xscXLrQZ4Sw5xv+ 2bnSINQLL9//KikEg/7Ty1st1IyNmgKRN+vz1dXof/JfIvlOZkSHRGujQCpYqh85peLL 9pfChfJbXvOWKYTVM/vw1uROu4aCuIBdx9/XUkmJ4OIoPO80ZhIzvspdrHm4hNZWoq+P XJ85T4yIFG+ZvyV5EVIZKljk4r4gyasfjchiKKZJ3LXr9z04SzLVDk0brpWDwKsJaXcu /y0g== Received: by 10.68.222.9 with SMTP id qi9mr8514004pbc.164.1342736466820; Thu, 19 Jul 2012 15:21:06 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id pp2sm2567015pbb.1.2012.07.19.15.21.04 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jul 2012 15:21:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Dick Hardt In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436673B633@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Thu, 19 Jul 2012 15:21:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <44AF61D2-0FBF-41E0-91D4-D7F7A615679E@gmail.com> References: <4E1F6AAD24975D4BA5B16804296739436673A0B7@TK5EX14MBXC285.redmond.corp.microsoft.com> <5E9D18F7-6E65-4E74-AFD0-5085ABB9128F@cisco.com> <4E1F6AAD24975D4BA5B16804296739436673B633@TK5EX14MBXC285.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1278) Cc: John Bradley , "jose@ietf.org" , "Matt Miller \(mamille2\)" Subject: Re: [jose] Symmetric encryption and key agreement with and without a separate CMK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 22:20:19 -0000 As an implementor, I would like to transport multiple symmetric = encrypted tokens in less than 2000 bytes. -- Dick On Jul 19, 2012, at 3:07 PM, Mike Jones wrote: > Matt, if you look at the examples in = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-04#section-= 3.1 and = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-04#section-= 3.2, you'll see that the encrypted key occupies more than half the total = space of the JWE in those examples - 342 characters out of 597 and 475 = respectively, to be precise. That's a big deal when operating in = space-constrained environments, such as passing JWTs as URI query = parameters - where the total URL length is often limited to 2048 = characters or sometimes less. Plus there's a significant performance = advantage in not having to do the keygen for the CMK or two encryptions, = rather than one. The direct encryption mode may not be for everyone, = but for those that need it, it can be the difference between meeting = space and performance budgets, or not. >=20 > Like John, I'd be glad to talk with you about this in Vancouver. >=20 > Best wishes, > -- Mike >=20 > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 > Sent: Thursday, July 19, 2012 2:58 PM > To: Matt Miller (mamille2) > Cc: Mike Jones; jose@ietf.org > Subject: Re: [jose] Symmetric encryption and key agreement with and = without a separate CMK >=20 > Sorry I missed your post. I will have a look. =20 >=20 > The idea with 1 is that it allows for the rotation of the key for the = stream cypher without the need to negotiate new shared secrets.=20 >=20 > What bothers you about it.=20 >=20 > We can meet up in Vancouver if you are coming=20 >=20 > John B.=20 >=20 > Sent from my iPad >=20 > On 2012-07-19, at 3:45 PM, "Matt Miller (mamille2)" = wrote: >=20 >>=20 >> On Jul 18, 2012, at 23:23, John Bradley wrote: >>=20 >>> I agree that is a reasonable approach. >>>=20 >>=20 >> I don't know that I support a). I can't articulate exactly why, = other than to say it gives me the willies (-: >>=20 >>> In the XMPP example from earlier it was method 2 that they were = using for multiple recipients, and that worked because the receiver = requested the key from the sender after receiving the message. >>>=20 >>=20 >> That was true, now the CMK is wrapped by a separate "SMK" (Session = Master Key). See < http://tools.ietf.org/html/draft-miller-xmpp-e2e-02 = >, which I thought I had forwarded to this list (-: >>=20 >>> So 2 may be useful in some multi recipient scenarios though probably = not all. >>>=20 >>> John B. >>>=20 >>> On 2012-07-18, at 7:04 PM, Mike Jones wrote: >>>=20 >>>> Hi all, >>>>=20 >>>> I=92ve been thinking about two of our open issues, which are = closely related, and am writing to make a proposal to resolve both of = them. The issues are: >>>>=20 >>>> (1) Currently we specify methods for using symmetric keys to key = wrap a separate Content Master Key (CMK), but no means of using the = symmetric key as the CMK directly. Some applications need this = functionality, both for size and for efficiency reasons. >>>>=20 >>>> (2) Currently we specify methods for performing key agreement and = directly using the resulting key as the CMK to perform block encryption, = but no means of using the agreed-upon key to wrap a separate CMK. When = doing key agreement for multiple recipients, a separate CMK is needed. >>>>=20 >>>> Thus, I propose that we define methods for filling in both of the = holes above, as follows: >>>>=20 >>>> (a) Define =93alg=94:=94dir=94 (direct) to mean that the symmetric = key is directly used as the CMK for the block encryption and integrity = calculations, rather than as a key to wrap the CMK value. >>>>=20 >>>> (b) Define =93alg=94:=94ECDH-ES+A128KW=94 and = =93alg=94:=94ECDH-ES+A256KW=94 to mean that the result of the key = agreement is respectively used as the 128 bit or 256 bit AES Key Wrap = key to wrap the CMK. >>>>=20 >>>> Doing this will enable all four flavors, whereas we=92re currently = missing 2 and 3 below: >>>> 1. The symmetric key used to wrap a separate CMK >>>> 2. The symmetric key used as the CMK >>>> 3. The key agreement result used to wrap a separate CMK >>>> 4. The key agreement result used as the CMK >>>>=20 >>>> I recognize that flavors 2 and 4 are not usable with multiple = recipients when methods such as JWE JSON Serialization are used (which = counts on a common CMK value to enable a common ciphertext value). A = note to that effect would be added to the JWA definitions of = =93alg=94:=93ECDH-ES=94 and =93alg=94:=94dir=94 and it would be pointed = out in the JWE-JS spec that =93alg=94 values that utilize a separate CMK = MUST be used when the plaintext is encrypted to multiple recipients. >>>>=20 >>>> Comments? >>>>=20 >>>> -- = Mike >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >>=20 >> - m&m >>=20 >> Matt Miller - >> Cisco Systems, Inc. >>=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From James.H.Manger@team.telstra.com Thu Jul 19 23:55:55 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6EE21F85B4 for ; Thu, 19 Jul 2012 23:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTp3xH82xz0Y for ; Thu, 19 Jul 2012 23:55:54 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id ED50821F85AF for ; Thu, 19 Jul 2012 23:55:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,621,1336312800"; d="scan'208,217";a="81717677" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 20 Jul 2012 16:56:48 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6777"; a="77927935" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipccni.tcif.telstra.com.au with ESMTP; 20 Jul 2012 16:56:47 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Fri, 20 Jul 2012 16:56:46 +1000 From: "Manger, James H" To: Mike Jones , "jose@ietf.org" Date: Fri, 20 Jul 2012 16:56:45 +1000 Thread-Topic: [jose] Symmetric encryption and key agreement with and without a separate CMK Thread-Index: Ac1lSl6h5FqQOPItQGiuikwTjR9QtgA3xg5g Message-ID: <255B9BB34FB7D647A506DC292726F6E114F7E0F747@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739436673A0B7@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436673A0B7@TK5EX14MBXC285.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E114F7E0F747WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [jose] Symmetric encryption and key agreement with and without a separate CMK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 06:55:55 -0000 --_000_255B9BB34FB7D647A506DC292726F6E114F7E0F747WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 S2VlcCAjMTsgYWRkICMzOyBkcm9wICM0OyBhbmQgbWF5YmUgYWRkICMyLCBidXQgbm90IHdpdGgg YW4g4oCcYWxn4oCdOuKAnWRpcuKAnSBoYWNrLg0KDQojNCAoa2V5IGFncmVlbWVudCByZXN1bHQg dXNlZCBhcyB0aGUgQ01LKSBzYXZlcyB+NTAgY2hhcnMgKG9yIDI0IGNoYXJzPykgY29tcGFyZWQg dG8gIzMsIGJ1dCBvbmx5IHdoZW4geW91IGhhdmUgdXNlZCBodW5kcmVkcyBvZiBjaGFycyAocHJv YmFibHkgZG91YmUtYmFzZTY0LWVuY29kZWQpIHRvIHJlcHJlc2VudCBhbiBlcGhlbWVyYWwga2V5 LiBOb3Qgc3VyZSBpdCBpcyB3b3J0aHdoaWxlLg0KDQpUaGUg4oCcYWxn4oCdOuKAnWRpcuKAnSBo YWNrIGlzIG1ha2luZyBSaWNoYXJkIEJhcm5lc+KAmXMgSlNNUyBpZGVhcyBsb29rIGJldHRlciBh bmQgYmV0dGVyIChpZiBpdCBkaWRu4oCZdCBkcm9wIHRoZSBhdXRoZW50aWNhdGVkQXR0cmlidXRl cyBwYXJ0IG9mIENNUykuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0KDQoNCkZyb206IGpvc2UtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IE1pa2UgSm9uZXMNClNlbnQ6IFRodXJzZGF5LCAxOSBKdWx5IDIwMTIgMTE6MDQgQU0NClRvOiBq b3NlQGlldGYub3JnDQpTdWJqZWN0OiBbam9zZV0gU3ltbWV0cmljIGVuY3J5cHRpb24gYW5kIGtl eSBhZ3JlZW1lbnQgd2l0aCBhbmQgd2l0aG91dCBhIHNlcGFyYXRlIENNSw0KDQpIaSBhbGwsDQoN CknigJl2ZSBiZWVuIHRoaW5raW5nIGFib3V0IHR3byBvZiBvdXIgb3BlbiBpc3N1ZXMsIHdoaWNo IGFyZSBjbG9zZWx5IHJlbGF0ZWQsIGFuZCBhbSB3cml0aW5nIHRvIG1ha2UgYSBwcm9wb3NhbCB0 byByZXNvbHZlIGJvdGggb2YgdGhlbS4gIFRoZSBpc3N1ZXMgYXJlOg0KDQooMSkgQ3VycmVudGx5 IHdlIHNwZWNpZnkgbWV0aG9kcyBmb3IgdXNpbmcgc3ltbWV0cmljIGtleXMgdG8ga2V5IHdyYXAg YSBzZXBhcmF0ZSBDb250ZW50IE1hc3RlciBLZXkgKENNSyksIGJ1dCBubyBtZWFucyBvZiB1c2lu ZyB0aGUgc3ltbWV0cmljIGtleSBhcyB0aGUgQ01LIGRpcmVjdGx5LiAgU29tZSBhcHBsaWNhdGlv bnMgbmVlZCB0aGlzIGZ1bmN0aW9uYWxpdHksIGJvdGggZm9yIHNpemUgYW5kIGZvciBlZmZpY2ll bmN5IHJlYXNvbnMuDQoNCigyKSBDdXJyZW50bHkgd2Ugc3BlY2lmeSBtZXRob2RzIGZvciBwZXJm b3JtaW5nIGtleSBhZ3JlZW1lbnQgYW5kIGRpcmVjdGx5IHVzaW5nIHRoZSByZXN1bHRpbmcga2V5 IGFzIHRoZSBDTUsgdG8gcGVyZm9ybSBibG9jayBlbmNyeXB0aW9uLCBidXQgbm8gbWVhbnMgb2Yg dXNpbmcgdGhlIGFncmVlZC11cG9uIGtleSB0byB3cmFwIGEgc2VwYXJhdGUgQ01LLiAgV2hlbiBk b2luZyBrZXkgYWdyZWVtZW50IGZvciBtdWx0aXBsZSByZWNpcGllbnRzLCBhIHNlcGFyYXRlIENN SyBpcyBuZWVkZWQuDQoNClRodXMsIEkgcHJvcG9zZSB0aGF0IHdlIGRlZmluZSBtZXRob2RzIGZv ciBmaWxsaW5nIGluIGJvdGggb2YgdGhlIGhvbGVzIGFib3ZlLCBhcyBmb2xsb3dzOg0KDQooYSkg RGVmaW5lIOKAnGFsZ+KAnTrigJ1kaXLigJ0gKGRpcmVjdCkgdG8gbWVhbiB0aGF0IHRoZSBzeW1t ZXRyaWMga2V5IGlzIGRpcmVjdGx5IHVzZWQgYXMgdGhlIENNSyBmb3IgdGhlIGJsb2NrIGVuY3J5 cHRpb24gYW5kIGludGVncml0eSBjYWxjdWxhdGlvbnMsIHJhdGhlciB0aGFuIGFzIGEga2V5IHRv IHdyYXAgdGhlIENNSyB2YWx1ZS4NCg0KKGIpIERlZmluZSDigJxhbGfigJ064oCdRUNESC1FUytB MTI4S1figJ0gYW5kIOKAnGFsZ+KAnTrigJ1FQ0RILUVTK0EyNTZLV+KAnSB0byBtZWFuIHRoYXQg dGhlIHJlc3VsdCBvZiB0aGUga2V5IGFncmVlbWVudCBpcyByZXNwZWN0aXZlbHkgdXNlZCBhcyB0 aGUgMTI4IGJpdCBvciAyNTYgYml0IEFFUyBLZXkgV3JhcCBrZXkgdG8gd3JhcCB0aGUgQ01LLg0K DQpEb2luZyB0aGlzIHdpbGwgZW5hYmxlIGFsbCBmb3VyIGZsYXZvcnMsIHdoZXJlYXMgd2XigJly ZSBjdXJyZW50bHkgbWlzc2luZyAyIGFuZCAzIGJlbG93Og0KMS4gIFRoZSBzeW1tZXRyaWMga2V5 IHVzZWQgdG8gd3JhcCBhIHNlcGFyYXRlIENNSw0KMi4gIFRoZSBzeW1tZXRyaWMga2V5IHVzZWQg YXMgdGhlIENNSw0KMy4gIFRoZSBrZXkgYWdyZWVtZW50IHJlc3VsdCB1c2VkIHRvIHdyYXAgYSBz ZXBhcmF0ZSBDTUsNCjQuICBUaGUga2V5IGFncmVlbWVudCByZXN1bHQgdXNlZCBhcyB0aGUgQ01L DQoNCkkgcmVjb2duaXplIHRoYXQgZmxhdm9ycyAyIGFuZCA0IGFyZSBub3QgdXNhYmxlIHdpdGgg bXVsdGlwbGUgcmVjaXBpZW50cyB3aGVuIG1ldGhvZHMgc3VjaCBhcyBKV0UgSlNPTiBTZXJpYWxp emF0aW9uIGFyZSB1c2VkICh3aGljaCBjb3VudHMgb24gYSBjb21tb24gQ01LIHZhbHVlIHRvIGVu YWJsZSBhIGNvbW1vbiBjaXBoZXJ0ZXh0IHZhbHVlKS4gIEEgbm90ZSB0byB0aGF0IGVmZmVjdCB3 b3VsZCBiZSBhZGRlZCB0byB0aGUgSldBIGRlZmluaXRpb25zIG9mIOKAnGFsZ+KAnTrigJxFQ0RI LUVT4oCdIGFuZCDigJxhbGfigJ064oCdZGly4oCdIGFuZCBpdCB3b3VsZCBiZSBwb2ludGVkIG91 dCBpbiB0aGUgSldFLUpTIHNwZWMgdGhhdCDigJxhbGfigJ0gdmFsdWVzIHRoYXQgdXRpbGl6ZSBh IHNlcGFyYXRlIENNSyBNVVNUIGJlIHVzZWQgd2hlbiB0aGUgcGxhaW50ZXh0IGlzIGVuY3J5cHRl ZCB0byBtdWx0aXBsZSByZWNpcGllbnRzLg0KDQpDb21tZW50cz8NCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UN Cg== --_000_255B9BB34FB7D647A506DC292726F6E114F7E0F747WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJv ZHkgbGFuZz1FTi1BVSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rp b24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+S2VlcCAj MTsgYWRkICMzOyBkcm9wICM0OyBhbmQgbWF5YmUgYWRkICMyLCBidXQgbm90IHdpdGggYW4g4oCc YWxn4oCdOuKAnWRpcuKAnSBoYWNrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiM0IChr ZXkgYWdyZWVtZW50IHJlc3VsdCB1c2VkIGFzIHRoZSBDTUspIHNhdmVzIH41MCBjaGFycyAob3Ig MjQgY2hhcnM/KSBjb21wYXJlZCB0byAjMywgYnV0IG9ubHkgd2hlbiB5b3UgaGF2ZSB1c2VkIGh1 bmRyZWRzIG9mIGNoYXJzIChwcm9iYWJseSBkb3ViZS1iYXNlNjQtZW5jb2RlZCkgdG8gcmVwcmVz ZW50IGFuIGVwaGVtZXJhbCBrZXkuIE5vdCBzdXJlIGl0IGlzIHdvcnRod2hpbGUuPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3 RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6IzFGNDk3RCc+VGhlIOKAnGFsZ+KAnTrigJ1kaXLigJ0gaGFjayBpcyBtYWtp bmcgUmljaGFyZCBCYXJuZXPigJlzIEpTTVMgaWRlYXMgbG9vayBiZXR0ZXIgYW5kIGJldHRlciAo aWYgaXQgZGlkbuKAmXQgZHJvcCB0aGUgYXV0aGVudGljYXRlZEF0dHJpYnV0ZXMgcGFydCBvZiBD TVMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPi0tPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SmFtZXMgTWFu Z2VyPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxl ZnQ6MzYuMHB0Jz48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz4gam9zZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86am9zZS1ib3VuY2VzQGll dGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPk1pa2UgSm9uZXM8YnI+PGI+U2VudDo8L2I+IFRo dXJzZGF5LCAxOSBKdWx5IDIwMTIgMTE6MDQgQU08YnI+PGI+VG86PC9iPiBqb3NlQGlldGYub3Jn PGJyPjxiPlN1YmplY3Q6PC9iPiBbam9zZV0gU3ltbWV0cmljIGVuY3J5cHRpb24gYW5kIGtleSBh Z3JlZW1lbnQgd2l0aCBhbmQgd2l0aG91dCBhIHNlcGFyYXRlIENNSzxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+PG86cD4m bmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDozNi4w cHQnPjxzcGFuIGxhbmc9RU4tVVM+SGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+PHNwYW4gbGFuZz1FTi1VUz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJn aW4tbGVmdDozNi4wcHQnPjxzcGFuIGxhbmc9RU4tVVM+SeKAmXZlIGJlZW4gdGhpbmtpbmcgYWJv dXQgdHdvIG9mIG91ciBvcGVuIGlzc3Vlcywgd2hpY2ggYXJlIGNsb3NlbHkgcmVsYXRlZCwgYW5k IGFtIHdyaXRpbmcgdG8gbWFrZSBhIHByb3Bvc2FsIHRvIHJlc29sdmUgYm90aCBvZiB0aGVtLiZu YnNwOyBUaGUgaXNzdWVzIGFyZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQnPjxzcGFuIGxhbmc9RU4tVVM+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6 MzYuMHB0Jz48c3BhbiBsYW5nPUVOLVVTPigxKSBDdXJyZW50bHkgd2Ugc3BlY2lmeSBtZXRob2Rz IGZvciB1c2luZyBzeW1tZXRyaWMga2V5cyB0byBrZXkgd3JhcCBhIHNlcGFyYXRlIENvbnRlbnQg TWFzdGVyIEtleSAoQ01LKSwgYnV0IG5vIG1lYW5zIG9mIHVzaW5nIHRoZSBzeW1tZXRyaWMga2V5 IGFzIHRoZSBDTUsgZGlyZWN0bHkuJm5ic3A7IFNvbWUgYXBwbGljYXRpb25zIG5lZWQgdGhpcyBm dW5jdGlvbmFsaXR5LCBib3RoIGZvciBzaXplIGFuZCBmb3IgZWZmaWNpZW5jeSByZWFzb25zLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0 OjM2LjBwdCc+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQnPjxzcGFuIGxhbmc9RU4t VVM+KDIpIEN1cnJlbnRseSB3ZSBzcGVjaWZ5IG1ldGhvZHMgZm9yIHBlcmZvcm1pbmcga2V5IGFn cmVlbWVudCBhbmQgZGlyZWN0bHkgdXNpbmcgdGhlIHJlc3VsdGluZyBrZXkgYXMgdGhlIENNSyB0 byBwZXJmb3JtIGJsb2NrIGVuY3J5cHRpb24sIGJ1dCBubyBtZWFucyBvZiB1c2luZyB0aGUgYWdy ZWVkLXVwb24ga2V5IHRvIHdyYXAgYSBzZXBhcmF0ZSBDTUsuJm5ic3A7IFdoZW4gZG9pbmcga2V5 IGFncmVlbWVudCBmb3IgbXVsdGlwbGUgcmVjaXBpZW50cywgYSBzZXBhcmF0ZSBDTUsgaXMgbmVl ZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdp bi1sZWZ0OjM2LjBwdCc+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQnPjxzcGFuIGxh bmc9RU4tVVM+VGh1cywgSSBwcm9wb3NlIHRoYXQgd2UgZGVmaW5lIG1ldGhvZHMgZm9yIGZpbGxp bmcgaW4gYm90aCBvZiB0aGUgaG9sZXMgYWJvdmUsIGFzIGZvbGxvd3M6PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MzYuMHB0Jz48c3Bh biBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+PHNwYW4gbGFuZz1FTi1VUz4oYSkgRGVmaW5l IOKAnGFsZ+KAnTrigJ1kaXLigJ0gKGRpcmVjdCkgdG8gbWVhbiB0aGF0IHRoZSBzeW1tZXRyaWMg a2V5IGlzIGRpcmVjdGx5IHVzZWQgYXMgdGhlIENNSyBmb3IgdGhlIGJsb2NrIGVuY3J5cHRpb24g YW5kIGludGVncml0eSBjYWxjdWxhdGlvbnMsIHJhdGhlciB0aGFuIGFzIGEga2V5IHRvIHdyYXAg dGhlIENNSyB2YWx1ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQnPjxzcGFuIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MzYuMHB0 Jz48c3BhbiBsYW5nPUVOLVVTPihiKSBEZWZpbmUg4oCcYWxn4oCdOuKAnUVDREgtRVMrQTEyOEtX 4oCdIGFuZCDigJxhbGfigJ064oCdRUNESC1FUytBMjU2S1figJ0gdG8gbWVhbiB0aGF0IHRoZSBy ZXN1bHQgb2YgdGhlIGtleSBhZ3JlZW1lbnQgaXMgcmVzcGVjdGl2ZWx5IHVzZWQgYXMgdGhlIDEy OCBiaXQgb3IgMjU2IGJpdCBBRVMgS2V5IFdyYXAga2V5IHRvIHdyYXAgdGhlIENNSy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDozNi4w cHQnPjxzcGFuIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MzYuMHB0Jz48c3BhbiBsYW5nPUVOLVVTPkRv aW5nIHRoaXMgd2lsbCBlbmFibGUgYWxsIGZvdXIgZmxhdm9ycywgd2hlcmVhcyB3ZeKAmXJlIGN1 cnJlbnRseSBtaXNzaW5nIDIgYW5kIDMgYmVsb3c6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MzYuMHB0Jz48c3BhbiBsYW5nPUVOLVVT PjEuJm5ic3A7IFRoZSBzeW1tZXRyaWMga2V5IHVzZWQgdG8gd3JhcCBhIHNlcGFyYXRlIENNSzxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0 OjM2LjBwdCc+PHNwYW4gbGFuZz1FTi1VUz4yLiZuYnNwOyBUaGUgc3ltbWV0cmljIGtleSB1c2Vk IGFzIHRoZSBDTUs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tbGVmdDozNi4wcHQnPjxzcGFuIGxhbmc9RU4tVVM+My4mbmJzcDsgVGhlIGtleSBh Z3JlZW1lbnQgcmVzdWx0IHVzZWQgdG8gd3JhcCBhIHNlcGFyYXRlIENNSzxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+PHNw YW4gbGFuZz1FTi1VUz40LiZuYnNwOyBUaGUga2V5IGFncmVlbWVudCByZXN1bHQgdXNlZCBhcyB0 aGUgQ01LPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFy Z2luLWxlZnQ6MzYuMHB0Jz48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+PHNwYW4g bGFuZz1FTi1VUz5JIHJlY29nbml6ZSB0aGF0IGZsYXZvcnMgMiBhbmQgNCBhcmUgbm90IHVzYWJs ZSB3aXRoIG11bHRpcGxlIHJlY2lwaWVudHMgd2hlbiBtZXRob2RzIHN1Y2ggYXMgSldFIEpTT04g U2VyaWFsaXphdGlvbiBhcmUgdXNlZCAod2hpY2ggY291bnRzIG9uIGEgY29tbW9uIENNSyB2YWx1 ZSB0byBlbmFibGUgYSBjb21tb24gY2lwaGVydGV4dCB2YWx1ZSkuJm5ic3A7IEEgbm90ZSB0byB0 aGF0IGVmZmVjdCB3b3VsZCBiZSBhZGRlZCB0byB0aGUgSldBIGRlZmluaXRpb25zIG9mIOKAnGFs Z+KAnTrigJxFQ0RILUVT4oCdIGFuZCDigJxhbGfigJ064oCdZGly4oCdIGFuZCBpdCB3b3VsZCBi ZSBwb2ludGVkIG91dCBpbiB0aGUgSldFLUpTIHNwZWMgdGhhdCDigJxhbGfigJ0gdmFsdWVzIHRo YXQgdXRpbGl6ZSBhIHNlcGFyYXRlIENNSyBNVVNUIGJlIHVzZWQgd2hlbiB0aGUgcGxhaW50ZXh0 IGlzIGVuY3J5cHRlZCB0byBtdWx0aXBsZSByZWNpcGllbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+PHNwYW4gbGFu Zz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQnPjxzcGFuIGxhbmc9RU4tVVM+Q29tbWVudHM/PG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MzYu MHB0Jz48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+PHNwYW4gbGFuZz1FTi1VUz4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_255B9BB34FB7D647A506DC292726F6E114F7E0F747WSMSG3153Vsrv_-- From rbarnes@bbn.com Fri Jul 20 06:56:00 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E217C21F8608 for ; Fri, 20 Jul 2012 06:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZM79xrezrY8i for ; Fri, 20 Jul 2012 06:56:00 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id EDB0721F85EA for ; Fri, 20 Jul 2012 06:55:59 -0700 (PDT) Received: from ros-dhcp192-1-51-20.bbn.com ([192.1.51.20]:65396) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SsDhC-000JVO-Vl; Fri, 20 Jul 2012 09:56:43 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F7E0F747@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 20 Jul 2012 09:56:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B16804296739436673A0B7@TK5EX14MBXC285.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F7E0F747@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1278) Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] Symmetric encryption and key agreement with and without a separate CMK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 13:56:01 -0000 FWIW, I wouldn't be all that opposed to adding back in the = authenticatedAttributes. =20 I also note that this all becomes unnecessary if you can just have one = wrapped key value for many encrypted objects. That works fine in JSMS = using detached encryption info:=20 [tiny-encrypted-body-1], ..., [tiny-encrypted-body-n],=20 { "type": "EncryptedData", "algorithm": {name:"aes128-gcm", iv:"ZONce...lU-g"} "keys": /* wrapped keys */ } On Jul 20, 2012, at 2:56 AM, Manger, James H wrote: > Keep #1; add #3; drop #4; and maybe add #2, but not with an = =93alg=94:=94dir=94 hack. > =20 > #4 (key agreement result used as the CMK) saves ~50 chars (or 24 = chars?) compared to #3, but only when you have used hundreds of chars = (probably doube-base64-encoded) to represent an ephemeral key. Not sure = it is worthwhile. > =20 > The =93alg=94:=94dir=94 hack is making Richard Barnes=92s JSMS ideas = look better and better (if it didn=92t drop the authenticatedAttributes = part of CMS). > =20 > -- > James Manger > =20 > =20 > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Mike Jones > Sent: Thursday, 19 July 2012 11:04 AM > To: jose@ietf.org > Subject: [jose] Symmetric encryption and key agreement with and = without a separate CMK > =20 > Hi all, > =20 > I=92ve been thinking about two of our open issues, which are closely = related, and am writing to make a proposal to resolve both of them. The = issues are: > =20 > (1) Currently we specify methods for using symmetric keys to key wrap = a separate Content Master Key (CMK), but no means of using the symmetric = key as the CMK directly. Some applications need this functionality, = both for size and for efficiency reasons. > =20 > (2) Currently we specify methods for performing key agreement and = directly using the resulting key as the CMK to perform block encryption, = but no means of using the agreed-upon key to wrap a separate CMK. When = doing key agreement for multiple recipients, a separate CMK is needed. > =20 > Thus, I propose that we define methods for filling in both of the = holes above, as follows: > =20 > (a) Define =93alg=94:=94dir=94 (direct) to mean that the symmetric key = is directly used as the CMK for the block encryption and integrity = calculations, rather than as a key to wrap the CMK value. > =20 > (b) Define =93alg=94:=94ECDH-ES+A128KW=94 and =93alg=94:=94ECDH-ES+A256K= W=94 to mean that the result of the key agreement is respectively used = as the 128 bit or 256 bit AES Key Wrap key to wrap the CMK. > =20 > Doing this will enable all four flavors, whereas we=92re currently = missing 2 and 3 below: > 1. The symmetric key used to wrap a separate CMK > 2. The symmetric key used as the CMK > 3. The key agreement result used to wrap a separate CMK > 4. The key agreement result used as the CMK > =20 > I recognize that flavors 2 and 4 are not usable with multiple = recipients when methods such as JWE JSON Serialization are used (which = counts on a common CMK value to enable a common ciphertext value). A = note to that effect would be added to the JWA definitions of = =93alg=94:=93ECDH-ES=94 and =93alg=94:=94dir=94 and it would be pointed = out in the JWE-JS spec that =93alg=94 values that utilize a separate CMK = MUST be used when the plaintext is encrypted to multiple recipients. > =20 > Comments? > =20 > -- = Mike > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Fri Jul 20 10:47:35 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756B321F85E4 for ; Fri, 20 Jul 2012 10:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.784 X-Spam-Level: X-Spam-Status: No, score=-3.784 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joabjTTemgDr for ; Fri, 20 Jul 2012 10:47:34 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 46C5921F85E3 for ; Fri, 20 Jul 2012 10:47:34 -0700 (PDT) Received: from mail62-co1-R.bigfish.com (10.243.78.232) by CO1EHSOBE008.bigfish.com (10.243.66.71) with Microsoft SMTP Server id 14.1.225.23; Fri, 20 Jul 2012 17:48:30 +0000 Received: from mail62-co1 (localhost [127.0.0.1]) by mail62-co1-R.bigfish.com (Postfix) with ESMTP id 44138100448; Fri, 20 Jul 2012 17:48:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz9371Ic89bhdf9Mc857h4015I14ffIzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail62-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail62-co1 (localhost.localdomain [127.0.0.1]) by mail62-co1 (MessageSwitch) id 1342806508187826_29875; Fri, 20 Jul 2012 17:48:28 +0000 (UTC) Received: from CO1EHSMHS026.bigfish.com (unknown [10.243.78.251]) by mail62-co1.bigfish.com (Postfix) with ESMTP id 2C134C401ED; Fri, 20 Jul 2012 17:48:28 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS026.bigfish.com (10.243.66.36) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 20 Jul 2012 17:48:27 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0298.005; Fri, 20 Jul 2012 17:48:27 +0000 From: Mike Jones To: "Manger, James H" , "jose@ietf.org" Thread-Topic: [jose] Symmetric encryption and key agreement with and without a separate CMK Thread-Index: Ac1lSl6h5FqQOPItQGiuikwTjR9QtgA3xg5gAB1yjFA= Date: Fri, 20 Jul 2012 17:48:26 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436673D2D6@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436673A0B7@TK5EX14MBXC285.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F7E0F747@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F7E0F747@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436673D2D6TK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] Symmetric encryption and key agreement with and without a separate CMK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 17:47:35 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436673D2D6TK5EX14MBXC285r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHJlYXNvbiB3ZSBhbHJlYWR5IGhhdmUgIzQgKGRpcmVjdCB1c2Ugb2YgdGhlIGFncmVlZC11 cG9uIGtleSkgaXMgdGhhdCBpdCBzYXZlcyBhbiB1bm5lY2Vzc2FyeSBzZWNvbmQgZW5jcnlwdGlv biBzdGVwIGluIHRoZSBzaW5nbGUgcmVjaXBpZW50IGNhc2UuICBUaGVyZSBpcyBhbHNvIHNvbWUg c3BhY2UgYWR2YW50YWdlIGFzIHdlbGwsIGFzIHlvdSBwb2ludCBvdXQuDQoNCkRvIHlvdSBoYXZl IGFuIGFsdGVybmF0aXZlIHN5bnRheCBwcm9wb3NhbCB0byDigJxhbGfigJ064oCdZGly4oCdIGZv ciBleHByZXNzaW5nIGRpcmVjdCBzeW1tZXRyaWMgZW5jcnlwdGlvbiwgc2luY2UgYXBwYXJlbnRs eSB5b3UgZG9u4oCZdCBsaWtlIHRoYXQgc3ludGF4PyAgU2V2ZXJhbCBvdGhlcnMgaGF2ZSBzYWlk IHRoYXQgaXQgd291bGQgd29yayBmb3IgdGhlbeKApg0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGFua3MsDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtl DQoNCkZyb206IE1hbmdlciwgSmFtZXMgSCBbbWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVs c3RyYS5jb21dDQpTZW50OiBUaHVyc2RheSwgSnVseSAxOSwgMjAxMiAxMTo1NyBQTQ0KVG86IE1p a2UgSm9uZXM7IGpvc2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbam9zZV0gU3ltbWV0cmljIGVu Y3J5cHRpb24gYW5kIGtleSBhZ3JlZW1lbnQgd2l0aCBhbmQgd2l0aG91dCBhIHNlcGFyYXRlIENN Sw0KDQpLZWVwICMxOyBhZGQgIzM7IGRyb3AgIzQ7IGFuZCBtYXliZSBhZGQgIzIsIGJ1dCBub3Qg d2l0aCBhbiDigJxhbGfigJ064oCdZGly4oCdIGhhY2suDQoNCiM0IChrZXkgYWdyZWVtZW50IHJl c3VsdCB1c2VkIGFzIHRoZSBDTUspIHNhdmVzIH41MCBjaGFycyAob3IgMjQgY2hhcnM/KSBjb21w YXJlZCB0byAjMywgYnV0IG9ubHkgd2hlbiB5b3UgaGF2ZSB1c2VkIGh1bmRyZWRzIG9mIGNoYXJz IChwcm9iYWJseSBkb3ViZS1iYXNlNjQtZW5jb2RlZCkgdG8gcmVwcmVzZW50IGFuIGVwaGVtZXJh bCBrZXkuIE5vdCBzdXJlIGl0IGlzIHdvcnRod2hpbGUuDQoNClRoZSDigJxhbGfigJ064oCdZGly 4oCdIGhhY2sgaXMgbWFraW5nIFJpY2hhcmQgQmFybmVz4oCZcyBKU01TIGlkZWFzIGxvb2sgYmV0 dGVyIGFuZCBiZXR0ZXIgKGlmIGl0IGRpZG7igJl0IGRyb3AgdGhlIGF1dGhlbnRpY2F0ZWRBdHRy aWJ1dGVzIHBhcnQgb2YgQ01TKS4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQoNCg0KRnJvbTogam9z ZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86 am9zZS1ib3VuY2VzQGlldGYub3JnXTxtYWlsdG86W21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5v cmddPiBPbiBCZWhhbGYgT2YgTWlrZSBKb25lcw0KU2VudDogVGh1cnNkYXksIDE5IEp1bHkgMjAx MiAxMTowNCBBTQ0KVG86IGpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBbam9zZV0gU3ltbWV0cmljIGVuY3J5cHRpb24gYW5kIGtleSBhZ3JlZW1lbnQgd2l0aCBh bmQgd2l0aG91dCBhIHNlcGFyYXRlIENNSw0KDQpIaSBhbGwsDQoNCknigJl2ZSBiZWVuIHRoaW5r aW5nIGFib3V0IHR3byBvZiBvdXIgb3BlbiBpc3N1ZXMsIHdoaWNoIGFyZSBjbG9zZWx5IHJlbGF0 ZWQsIGFuZCBhbSB3cml0aW5nIHRvIG1ha2UgYSBwcm9wb3NhbCB0byByZXNvbHZlIGJvdGggb2Yg dGhlbS4gIFRoZSBpc3N1ZXMgYXJlOg0KDQooMSkgQ3VycmVudGx5IHdlIHNwZWNpZnkgbWV0aG9k cyBmb3IgdXNpbmcgc3ltbWV0cmljIGtleXMgdG8ga2V5IHdyYXAgYSBzZXBhcmF0ZSBDb250ZW50 IE1hc3RlciBLZXkgKENNSyksIGJ1dCBubyBtZWFucyBvZiB1c2luZyB0aGUgc3ltbWV0cmljIGtl eSBhcyB0aGUgQ01LIGRpcmVjdGx5LiAgU29tZSBhcHBsaWNhdGlvbnMgbmVlZCB0aGlzIGZ1bmN0 aW9uYWxpdHksIGJvdGggZm9yIHNpemUgYW5kIGZvciBlZmZpY2llbmN5IHJlYXNvbnMuDQoNCigy KSBDdXJyZW50bHkgd2Ugc3BlY2lmeSBtZXRob2RzIGZvciBwZXJmb3JtaW5nIGtleSBhZ3JlZW1l bnQgYW5kIGRpcmVjdGx5IHVzaW5nIHRoZSByZXN1bHRpbmcga2V5IGFzIHRoZSBDTUsgdG8gcGVy Zm9ybSBibG9jayBlbmNyeXB0aW9uLCBidXQgbm8gbWVhbnMgb2YgdXNpbmcgdGhlIGFncmVlZC11 cG9uIGtleSB0byB3cmFwIGEgc2VwYXJhdGUgQ01LLiAgV2hlbiBkb2luZyBrZXkgYWdyZWVtZW50 IGZvciBtdWx0aXBsZSByZWNpcGllbnRzLCBhIHNlcGFyYXRlIENNSyBpcyBuZWVkZWQuDQoNClRo dXMsIEkgcHJvcG9zZSB0aGF0IHdlIGRlZmluZSBtZXRob2RzIGZvciBmaWxsaW5nIGluIGJvdGgg b2YgdGhlIGhvbGVzIGFib3ZlLCBhcyBmb2xsb3dzOg0KDQooYSkgRGVmaW5lIOKAnGFsZ+KAnTri gJ1kaXLigJ0gKGRpcmVjdCkgdG8gbWVhbiB0aGF0IHRoZSBzeW1tZXRyaWMga2V5IGlzIGRpcmVj dGx5IHVzZWQgYXMgdGhlIENNSyBmb3IgdGhlIGJsb2NrIGVuY3J5cHRpb24gYW5kIGludGVncml0 eSBjYWxjdWxhdGlvbnMsIHJhdGhlciB0aGFuIGFzIGEga2V5IHRvIHdyYXAgdGhlIENNSyB2YWx1 ZS4NCg0KKGIpIERlZmluZSDigJxhbGfigJ064oCdRUNESC1FUytBMTI4S1figJ0gYW5kIOKAnGFs Z+KAnTrigJ1FQ0RILUVTK0EyNTZLV+KAnSB0byBtZWFuIHRoYXQgdGhlIHJlc3VsdCBvZiB0aGUg a2V5IGFncmVlbWVudCBpcyByZXNwZWN0aXZlbHkgdXNlZCBhcyB0aGUgMTI4IGJpdCBvciAyNTYg Yml0IEFFUyBLZXkgV3JhcCBrZXkgdG8gd3JhcCB0aGUgQ01LLg0KDQpEb2luZyB0aGlzIHdpbGwg ZW5hYmxlIGFsbCBmb3VyIGZsYXZvcnMsIHdoZXJlYXMgd2XigJlyZSBjdXJyZW50bHkgbWlzc2lu ZyAyIGFuZCAzIGJlbG93Og0KMS4gIFRoZSBzeW1tZXRyaWMga2V5IHVzZWQgdG8gd3JhcCBhIHNl cGFyYXRlIENNSw0KMi4gIFRoZSBzeW1tZXRyaWMga2V5IHVzZWQgYXMgdGhlIENNSw0KMy4gIFRo ZSBrZXkgYWdyZWVtZW50IHJlc3VsdCB1c2VkIHRvIHdyYXAgYSBzZXBhcmF0ZSBDTUsNCjQuICBU aGUga2V5IGFncmVlbWVudCByZXN1bHQgdXNlZCBhcyB0aGUgQ01LDQoNCkkgcmVjb2duaXplIHRo YXQgZmxhdm9ycyAyIGFuZCA0IGFyZSBub3QgdXNhYmxlIHdpdGggbXVsdGlwbGUgcmVjaXBpZW50 cyB3aGVuIG1ldGhvZHMgc3VjaCBhcyBKV0UgSlNPTiBTZXJpYWxpemF0aW9uIGFyZSB1c2VkICh3 aGljaCBjb3VudHMgb24gYSBjb21tb24gQ01LIHZhbHVlIHRvIGVuYWJsZSBhIGNvbW1vbiBjaXBo ZXJ0ZXh0IHZhbHVlKS4gIEEgbm90ZSB0byB0aGF0IGVmZmVjdCB3b3VsZCBiZSBhZGRlZCB0byB0 aGUgSldBIGRlZmluaXRpb25zIG9mIOKAnGFsZ+KAnTrigJxFQ0RILUVT4oCdIGFuZCDigJxhbGfi gJ064oCdZGly4oCdIGFuZCBpdCB3b3VsZCBiZSBwb2ludGVkIG91dCBpbiB0aGUgSldFLUpTIHNw ZWMgdGhhdCDigJxhbGfigJ0gdmFsdWVzIHRoYXQgdXRpbGl6ZSBhIHNlcGFyYXRlIENNSyBNVVNU IGJlIHVzZWQgd2hlbiB0aGUgcGxhaW50ZXh0IGlzIGVuY3J5cHRlZCB0byBtdWx0aXBsZSByZWNp cGllbnRzLg0KDQpDb21tZW50cz8NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg== --_000_4E1F6AAD24975D4BA5B16804296739436673D2D6TK5EX14MBXC285r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRl LCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPlRoZSByZWFzb24gd2UgYWxyZWFkeSBoYXZlICM0IChkaXJlY3QgdXNlIG9mIHRoZSBh Z3JlZWQtdXBvbiBrZXkpIGlzIHRoYXQgaXQgc2F2ZXMgYW4gdW5uZWNlc3Nhcnkgc2Vjb25kIGVu Y3J5cHRpb24gc3RlcCBpbiB0aGUgc2luZ2xlIHJlY2lwaWVudCBjYXNlLiZuYnNwOyBUaGVyZSBp cyBhbHNvIHNvbWUgc3BhY2UgYWR2YW50YWdlIGFzIHdlbGwsIGFzIHlvdSBwb2ludA0KIG91dC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkRvIHlvdSBoYXZlIGFuIGFsdGVy bmF0aXZlIHN5bnRheCBwcm9wb3NhbCB0byDigJxhbGfigJ064oCdZGly4oCdIGZvciBleHByZXNz aW5nIGRpcmVjdCBzeW1tZXRyaWMgZW5jcnlwdGlvbiwgc2luY2UgYXBwYXJlbnRseSB5b3UgZG9u 4oCZdCBsaWtlIHRoYXQgc3ludGF4PyZuYnNwOyBTZXZlcmFsIG90aGVycyBoYXZlIHNhaWQgdGhh dCBpdCB3b3VsZCB3b3JrIGZvciB0aGVt4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg LS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IE1hbmdlciwgSmFtZXMgSCBbbWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0u dGVsc3RyYS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMTksIDIwMTIg MTE6NTcgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM7IGpvc2VAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUkU6IFtqb3NlXSBTeW1tZXRyaWMgZW5jcnlwdGlvbiBhbmQga2V5IGFn cmVlbWVudCB3aXRoIGFuZCB3aXRob3V0IGEgc2VwYXJhdGUgQ01LPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5LZWVwICMxOyBhZGQgIzM7IGRyb3AgIzQ7IGFuZCBtYXliZSBhZGQgIzIs IGJ1dCBub3Qgd2l0aCBhbiDigJxhbGfigJ064oCdZGly4oCdIGhhY2suPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiM0IChrZXkg YWdyZWVtZW50IHJlc3VsdCB1c2VkIGFzIHRoZSBDTUspIHNhdmVzIH41MCBjaGFycyAob3IgMjQg Y2hhcnM/KSBjb21wYXJlZCB0byAjMywgYnV0IG9ubHkgd2hlbiB5b3UgaGF2ZSB1c2VkIGh1bmRy ZWRzIG9mIGNoYXJzIChwcm9iYWJseSBkb3ViZS1iYXNlNjQtZW5jb2RlZCkgdG8gcmVwcmVzZW50 IGFuIGVwaGVtZXJhbCBrZXkuDQogTm90IHN1cmUgaXQgaXMgd29ydGh3aGlsZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhl IOKAnGFsZ+KAnTrigJ1kaXLigJ0gaGFjayBpcyBtYWtpbmcgUmljaGFyZCBCYXJuZXPigJlzIEpT TVMgaWRlYXMgbG9vayBiZXR0ZXIgYW5kIGJldHRlciAoaWYgaXQgZGlkbuKAmXQgZHJvcCB0aGUg YXV0aGVudGljYXRlZEF0dHJpYnV0ZXMgcGFydCBvZiBDTVMpLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4tLTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1BVSIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEg aHJlZj0ibWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZyI+am9zZS1ib3VuY2VzQGlldGYub3Jn PC9hPiA8YSBocmVmPSJtYWlsdG86W21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddIj4NCltt YWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXTwvYT4gPGI+T24gQmVoYWxmIE9mIDwvYj5NaWtl IEpvbmVzPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCAxOSBKdWx5IDIwMTIgMTE6MDQgQU08 YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIj5qb3NlQGlldGYu b3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbam9zZV0gU3ltbWV0cmljIGVuY3J5cHRpb24g YW5kIGtleSBhZ3JlZW1lbnQgd2l0aCBhbmQgd2l0aG91dCBhIHNlcGFyYXRlIENNSzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48c3BhbiBsYW5nPSJFTi1BVSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkhpIGFsbCw8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj5J4oCZdmUgYmVlbiB0aGlua2luZyBhYm91dCB0d28gb2Ygb3VyIG9wZW4gaXNz dWVzLCB3aGljaCBhcmUgY2xvc2VseSByZWxhdGVkLCBhbmQgYW0gd3JpdGluZyB0byBtYWtlIGEg cHJvcG9zYWwgdG8gcmVzb2x2ZSBib3RoIG9mIHRoZW0uJm5ic3A7IFRoZSBpc3N1ZXMgYXJlOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPigxKSBDdXJyZW50bHkgd2Ugc3BlY2lmeSBtZXRob2RzIGZvciB1c2lu ZyBzeW1tZXRyaWMga2V5cyB0byBrZXkgd3JhcCBhIHNlcGFyYXRlIENvbnRlbnQgTWFzdGVyIEtl eSAoQ01LKSwgYnV0IG5vIG1lYW5zIG9mIHVzaW5nIHRoZSBzeW1tZXRyaWMga2V5IGFzIHRoZSBD TUsgZGlyZWN0bHkuJm5ic3A7IFNvbWUgYXBwbGljYXRpb25zIG5lZWQgdGhpcyBmdW5jdGlvbmFs aXR5LA0KIGJvdGggZm9yIHNpemUgYW5kIGZvciBlZmZpY2llbmN5IHJlYXNvbnMuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+KDIpIEN1cnJlbnRseSB3ZSBzcGVjaWZ5IG1ldGhvZHMgZm9yIHBlcmZvcm1pbmcg a2V5IGFncmVlbWVudCBhbmQgZGlyZWN0bHkgdXNpbmcgdGhlIHJlc3VsdGluZyBrZXkgYXMgdGhl IENNSyB0byBwZXJmb3JtIGJsb2NrIGVuY3J5cHRpb24sIGJ1dCBubyBtZWFucyBvZiB1c2luZyB0 aGUgYWdyZWVkLXVwb24ga2V5IHRvIHdyYXAgYSBzZXBhcmF0ZSBDTUsuJm5ic3A7IFdoZW4NCiBk b2luZyBrZXkgYWdyZWVtZW50IGZvciBtdWx0aXBsZSByZWNpcGllbnRzLCBhIHNlcGFyYXRlIENN SyBpcyBuZWVkZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGh1cywgSSBwcm9wb3NlIHRoYXQgd2UgZGVm aW5lIG1ldGhvZHMgZm9yIGZpbGxpbmcgaW4gYm90aCBvZiB0aGUgaG9sZXMgYWJvdmUsIGFzIGZv bGxvd3M6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+KGEpIERlZmluZSDigJxhbGfigJ064oCdZGly4oCdIChk aXJlY3QpIHRvIG1lYW4gdGhhdCB0aGUgc3ltbWV0cmljIGtleSBpcyBkaXJlY3RseSB1c2VkIGFz IHRoZSBDTUsgZm9yIHRoZSBibG9jayBlbmNyeXB0aW9uIGFuZCBpbnRlZ3JpdHkgY2FsY3VsYXRp b25zLCByYXRoZXIgdGhhbiBhcyBhIGtleSB0byB3cmFwIHRoZSBDTUsgdmFsdWUuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+KGIpIERlZmluZSDigJxhbGfigJ064oCdRUNESC1FUyYjNDM7QTEyOEtX4oCdIGFu ZCDigJxhbGfigJ064oCdRUNESC1FUyYjNDM7QTI1NktX4oCdIHRvIG1lYW4gdGhhdCB0aGUgcmVz dWx0IG9mIHRoZSBrZXkgYWdyZWVtZW50IGlzIHJlc3BlY3RpdmVseSB1c2VkIGFzIHRoZSAxMjgg Yml0IG9yIDI1NiBiaXQgQUVTIEtleSBXcmFwIGtleSB0byB3cmFwIHRoZSBDTUsuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+RG9pbmcgdGhpcyB3aWxsIGVuYWJsZSBhbGwgZm91ciBmbGF2b3JzLCB3aGVyZWFz IHdl4oCZcmUgY3VycmVudGx5IG1pc3NpbmcgMiBhbmQgMyBiZWxvdzo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4xLiZuYnNwOyBU aGUgc3ltbWV0cmljIGtleSB1c2VkIHRvIHdyYXAgYSBzZXBhcmF0ZSBDTUs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4yLiZuYnNw OyBUaGUgc3ltbWV0cmljIGtleSB1c2VkIGFzIHRoZSBDTUs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4zLiZuYnNwOyBUaGUga2V5 IGFncmVlbWVudCByZXN1bHQgdXNlZCB0byB3cmFwIGEgc2VwYXJhdGUgQ01LPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+NC4mbmJz cDsgVGhlIGtleSBhZ3JlZW1lbnQgcmVzdWx0IHVzZWQgYXMgdGhlIENNSzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPkkgcmVjb2duaXplIHRoYXQgZmxhdm9ycyAyIGFuZCA0IGFyZSBub3QgdXNhYmxlIHdpdGgg bXVsdGlwbGUgcmVjaXBpZW50cyB3aGVuIG1ldGhvZHMgc3VjaCBhcyBKV0UgSlNPTiBTZXJpYWxp emF0aW9uIGFyZSB1c2VkICh3aGljaCBjb3VudHMgb24gYSBjb21tb24gQ01LIHZhbHVlIHRvIGVu YWJsZSBhIGNvbW1vbiBjaXBoZXJ0ZXh0IHZhbHVlKS4mbmJzcDsgQSBub3RlIHRvDQogdGhhdCBl ZmZlY3Qgd291bGQgYmUgYWRkZWQgdG8gdGhlIEpXQSBkZWZpbml0aW9ucyBvZiDigJxhbGfigJ06 4oCcRUNESC1FU+KAnSBhbmQg4oCcYWxn4oCdOuKAnWRpcuKAnSBhbmQgaXQgd291bGQgYmUgcG9p bnRlZCBvdXQgaW4gdGhlIEpXRS1KUyBzcGVjIHRoYXQg4oCcYWxn4oCdIHZhbHVlcyB0aGF0IHV0 aWxpemUgYSBzZXBhcmF0ZSBDTUsgTVVTVCBiZSB1c2VkIHdoZW4gdGhlIHBsYWludGV4dCBpcyBl bmNyeXB0ZWQgdG8gbXVsdGlwbGUgcmVjaXBpZW50cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Db21tZW50 cz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg LS0gTWlrZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B16804296739436673D2D6TK5EX14MBXC285r_-- From ietf@augustcellars.com Fri Jul 20 14:41:31 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C2721F8517 for ; Fri, 20 Jul 2012 14:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q19OoxjPYAy3 for ; Fri, 20 Jul 2012 14:41:31 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id DB31C21F8513 for ; Fri, 20 Jul 2012 14:41:30 -0700 (PDT) Received: from Tobias (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id A0E3538EEE; Fri, 20 Jul 2012 14:42:27 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , "'Manger, James H'" , References: <4E1F6AAD24975D4BA5B16804296739436673A0B7@TK5EX14MBXC285.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F7E0F747@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436673D2D6@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436673D2D6@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Fri, 20 Jul 2012 14:40:55 -0700 Message-ID: <000f01cd66c0$5d32b290$179817b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01CD6685.B0D84760" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHv+7fqjs3d9kBuqgv5b3IYjSmwngJnVw1AAPcidCCW0pVTYA== Content-Language: en-us Subject: Re: [jose] Symmetric encryption and key agreement with and without a separate CMK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 21:41:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0010_01CD6685.B0D84760 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable It seems like the correct think should be = =E2=80=9Calg=E2=80=9D:=E2=80=9Dnone=E2=80=9D J =20 =20 From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Mike Jones Sent: Friday, July 20, 2012 10:48 AM To: Manger, James H; jose@ietf.org Subject: Re: [jose] Symmetric encryption and key agreement with and = without a separate CMK =20 The reason we already have #4 (direct use of the agreed-upon key) is = that it saves an unnecessary second encryption step in the single = recipient case. There is also some space advantage as well, as you = point out. =20 Do you have an alternative syntax proposal to = =E2=80=9Calg=E2=80=9D:=E2=80=9Ddir=E2=80=9D for expressing direct = symmetric encryption, since apparently you don=E2=80=99t like that = syntax? Several others have said that it would work for them=E2=80=A6 =20 Thanks, -- Mike =20 From: Manger, James H [mailto:James.H.Manger@team.telstra.com]=20 Sent: Thursday, July 19, 2012 11:57 PM To: Mike Jones; jose@ietf.org Subject: RE: [jose] Symmetric encryption and key agreement with and = without a separate CMK =20 Keep #1; add #3; drop #4; and maybe add #2, but not with an = =E2=80=9Calg=E2=80=9D:=E2=80=9Ddir=E2=80=9D hack. =20 #4 (key agreement result used as the CMK) saves ~50 chars (or 24 chars?) = compared to #3, but only when you have used hundreds of chars (probably = doube-base64-encoded) to represent an ephemeral key. Not sure it is = worthwhile. =20 The =E2=80=9Calg=E2=80=9D:=E2=80=9Ddir=E2=80=9D hack is making Richard = Barnes=E2=80=99s JSMS ideas look better and better (if it didn=E2=80=99t = drop the authenticatedAttributes part of CMS). =20 -- James Manger =20 =20 =20 From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Mike Jones Sent: Thursday, 19 July 2012 11:04 AM To: jose@ietf.org Subject: [jose] Symmetric encryption and key agreement with and without = a separate CMK =20 Hi all, =20 I=E2=80=99ve been thinking about two of our open issues, which are = closely related, and am writing to make a proposal to resolve both of = them. The issues are: =20 (1) Currently we specify methods for using symmetric keys to key wrap a = separate Content Master Key (CMK), but no means of using the symmetric = key as the CMK directly. Some applications need this functionality, = both for size and for efficiency reasons. =20 (2) Currently we specify methods for performing key agreement and = directly using the resulting key as the CMK to perform block encryption, = but no means of using the agreed-upon key to wrap a separate CMK. When = doing key agreement for multiple recipients, a separate CMK is needed. =20 Thus, I propose that we define methods for filling in both of the holes = above, as follows: =20 (a) Define =E2=80=9Calg=E2=80=9D:=E2=80=9Ddir=E2=80=9D (direct) to mean = that the symmetric key is directly used as the CMK for the block = encryption and integrity calculations, rather than as a key to wrap the = CMK value. =20 (b) Define =E2=80=9Calg=E2=80=9D:=E2=80=9DECDH-ES+A128KW=E2=80=9D and = =E2=80=9Calg=E2=80=9D:=E2=80=9DECDH-ES+A256KW=E2=80=9D to mean that the = result of the key agreement is respectively used as the 128 bit or 256 = bit AES Key Wrap key to wrap the CMK. =20 Doing this will enable all four flavors, whereas we=E2=80=99re currently = missing 2 and 3 below: 1. The symmetric key used to wrap a separate CMK 2. The symmetric key used as the CMK 3. The key agreement result used to wrap a separate CMK 4. The key agreement result used as the CMK =20 I recognize that flavors 2 and 4 are not usable with multiple recipients = when methods such as JWE JSON Serialization are used (which counts on a = common CMK value to enable a common ciphertext value). A note to that = effect would be added to the JWA definitions of = =E2=80=9Calg=E2=80=9D:=E2=80=9CECDH-ES=E2=80=9D and = =E2=80=9Calg=E2=80=9D:=E2=80=9Ddir=E2=80=9D and it would be pointed out = in the JWE-JS spec that =E2=80=9Calg=E2=80=9D values that utilize a = separate CMK MUST be used when the plaintext is encrypted to multiple = recipients. =20 Comments? =20 -- Mike ------=_NextPart_000_0010_01CD6685.B0D84760 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

It seems like the correct think should be = =E2=80=9Calg=E2=80=9D:=E2=80=9Dnone=E2=80=9D J

 

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Mike Jones
Sent: Friday, July 20, 2012 10:48 = AM
To: Manger, James H; jose@ietf.org
Subject: Re: = [jose] Symmetric encryption and key agreement with and without a = separate CMK

 

The reason we already have #4 (direct use of the = agreed-upon key) is that it saves an unnecessary second encryption step = in the single recipient case.  There is also some space advantage = as well, as you point out.

 

Do you have an = alternative syntax proposal to = =E2=80=9Calg=E2=80=9D:=E2=80=9Ddir=E2=80=9D for expressing direct = symmetric encryption, since apparently you don=E2=80=99t like that = syntax?  Several others have said that it would work for = them=E2=80=A6

 

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

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

 

From:= = Manger, James H [mailto:James.H.= Manger@team.telstra.com]
Sent: Thursday, July 19, 2012 = 11:57 PM
To: Mike Jones; jose@ietf.org
Subject: RE: = [jose] Symmetric encryption and key agreement with and without a = separate CMK

 

Keep #1; add #3; drop #4; and maybe = add #2, but not with an =E2=80=9Calg=E2=80=9D:=E2=80=9Ddir=E2=80=9D = hack.

 

#4 (key = agreement result used as the CMK) saves ~50 chars (or 24 chars?) = compared to #3, but only when you have used hundreds of chars (probably = doube-base64-encoded) to represent an ephemeral key. Not sure it is = worthwhile.

 

The = =E2=80=9Calg=E2=80=9D:=E2=80=9Ddir=E2=80=9D hack is making Richard = Barnes=E2=80=99s JSMS ideas look better and better (if it didn=E2=80=99t = drop the authenticatedAttributes part of CMS).

 

--

James = Manger

 

 

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.= org] On Behalf Of Mike Jones
Sent: Thursday, 19 = July 2012 11:04 AM
To: jose@ietf.org
Subject: = [jose] Symmetric encryption and key agreement with and without a = separate CMK

 

Hi all,

 

I=E2=80=99ve been thinking about two of our = open issues, which are closely related, and am writing to make a = proposal to resolve both of them.  The issues are:

 

(1) Currently we specify = methods for using symmetric keys to key wrap a separate Content Master = Key (CMK), but no means of using the symmetric key as the CMK = directly.  Some applications need this functionality, both for size = and for efficiency reasons.

 

(2) Currently we specify methods for = performing key agreement and directly using the resulting key as the CMK = to perform block encryption, but no means of using the agreed-upon key = to wrap a separate CMK.  When doing key agreement for multiple = recipients, a separate CMK is needed.

 

Thus, I propose that we define methods for = filling in both of the holes above, as follows:

 

(a) Define = =E2=80=9Calg=E2=80=9D:=E2=80=9Ddir=E2=80=9D (direct) to mean that the = symmetric key is directly used as the CMK for the block encryption and = integrity calculations, rather than as a key to wrap the CMK = value.

 

(b) Define = =E2=80=9Calg=E2=80=9D:=E2=80=9DECDH-ES+A128KW=E2=80=9D and = =E2=80=9Calg=E2=80=9D:=E2=80=9DECDH-ES+A256KW=E2=80=9D to mean that the = result of the key agreement is respectively used as the 128 bit or 256 = bit AES Key Wrap key to wrap the CMK.

 

Doing this will enable all four flavors, = whereas we=E2=80=99re currently missing 2 and 3 below:

1.  The symmetric key = used to wrap a separate CMK

2.  The symmetric key used as the = CMK

3.  The key agreement result used to = wrap a separate CMK

4.  The key agreement result used as the = CMK

 

I recognize that flavors 2 and 4 are not = usable with multiple recipients when methods such as JWE JSON = Serialization are used (which counts on a common CMK value to enable a = common ciphertext value).  A note to that effect would be added to = the JWA definitions of =E2=80=9Calg=E2=80=9D:=E2=80=9CECDH-ES=E2=80=9D = and =E2=80=9Calg=E2=80=9D:=E2=80=9Ddir=E2=80=9D and it would be pointed = out in the JWE-JS spec that =E2=80=9Calg=E2=80=9D values that utilize a = separate CMK MUST be used when the plaintext is encrypted to multiple = recipients.

 

Comments?

 

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

------=_NextPart_000_0010_01CD6685.B0D84760-- From tonynad@microsoft.com Fri Jul 20 14:50:49 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1290511E8086 for ; Fri, 20 Jul 2012 14:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=1.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVlLWzq6Itb3 for ; Fri, 20 Jul 2012 14:50:47 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 324E311E808C for ; Fri, 20 Jul 2012 14:50:47 -0700 (PDT) Received: from mail176-tx2-R.bigfish.com (10.9.14.253) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Fri, 20 Jul 2012 21:51:43 +0000 Received: from mail176-tx2 (localhost [127.0.0.1]) by mail176-tx2-R.bigfish.com (Postfix) with ESMTP id 668C740218 for ; Fri, 20 Jul 2012 21:51:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VS-25(zz9371Ic89bhdf9Mc857h4015I14ffIzz1202h1082kzz1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah107ah) Received-SPF: pass (mail176-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail176-tx2 (localhost.localdomain [127.0.0.1]) by mail176-tx2 (MessageSwitch) id 1342821101301370_30301; Fri, 20 Jul 2012 21:51:41 +0000 (UTC) Received: from TX2EHSMHS044.bigfish.com (unknown [10.9.14.238]) by mail176-tx2.bigfish.com (Postfix) with ESMTP id 457AE100049 for ; Fri, 20 Jul 2012 21:51:41 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS044.bigfish.com (10.9.99.144) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 20 Jul 2012 21:51:41 +0000 Received: from am1outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.2.298.5; Fri, 20 Jul 2012 21:51:40 +0000 Received: from mail84-am1-R.bigfish.com (10.3.201.227) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Fri, 20 Jul 2012 21:51:32 +0000 Received: from mail84-am1 (localhost [127.0.0.1]) by mail84-am1-R.bigfish.com (Postfix) with ESMTP id ABC50402E9 for ; Fri, 20 Jul 2012 21:51:31 +0000 (UTC) Received: from mail84-am1 (localhost.localdomain [127.0.0.1]) by mail84-am1 (MessageSwitch) id 1342821089333970_26772; Fri, 20 Jul 2012 21:51:29 +0000 (UTC) Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.234]) by mail84-am1.bigfish.com (Postfix) with ESMTP id 459ADE0043; Fri, 20 Jul 2012 21:51:29 +0000 (UTC) Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 20 Jul 2012 21:51:29 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.12.220]) by BL2PRD0310HT001.namprd03.prod.outlook.com ([10.255.97.36]) with mapi id 14.16.0175.005; Fri, 20 Jul 2012 21:51:26 +0000 From: Anthony Nadalin To: Jim Schaad , Mike Jones , "'Manger, James H'" , "jose@ietf.org" Thread-Topic: [jose] Symmetric encryption and key agreement with and without a separate CMK Thread-Index: AQHNZsCc8GZFreau1UGo3xlXI2eIWZcytbOw Date: Fri, 20 Jul 2012 21:51:25 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B16804296739436673A0B7@TK5EX14MBXC285.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F7E0F747@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436673D2D6@TK5EX14MBXC285.redmond.corp.microsoft.com> <000f01cd66c0$5d32b290$179817b0$@augustcellars.com> In-Reply-To: <000f01cd66c0$5d32b290$179817b0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.57] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E7555039C5BL2PRD0310MB362_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%AUGUSTCELLARS.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TEAM.TELSTRA.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC101.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Subject: Re: [jose] Symmetric encryption and key agreement with and without a separate CMK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 21:50:49 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E7555039C5BL2PRD0310MB362_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCcbm9uZeKAnSBpcyBub3QgaW5mb3JtYXRpdmUg4pi5IGF0IGFsbCwgYXQgbGVhc3QgdGhlIOKA nGRpcuKAnSBpcyB0ZWxsaW5nIHVzIHNvbWV0aGluZw0KDQpGcm9tOiBqb3NlLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKaW0gU2No YWFkDQpTZW50OiBGcmlkYXksIEp1bHkgMjAsIDIwMTIgMjo0MSBQTQ0KVG86IE1pa2UgSm9uZXM7 ICdNYW5nZXIsIEphbWVzIEgnOyBqb3NlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2pvc2VdIFN5 bW1ldHJpYyBlbmNyeXB0aW9uIGFuZCBrZXkgYWdyZWVtZW50IHdpdGggYW5kIHdpdGhvdXQgYSBz ZXBhcmF0ZSBDTUsNCg0KSXQgc2VlbXMgbGlrZSB0aGUgY29ycmVjdCB0aGluayBzaG91bGQgYmUg 4oCcYWxn4oCdOuKAnW5vbmXigJ0g4pi6DQoNCg0KRnJvbTogam9zZS1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYu b3JnXTxtYWlsdG86W21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddPiBPbiBCZWhhbGYgT2Yg TWlrZSBKb25lcw0KU2VudDogRnJpZGF5LCBKdWx5IDIwLCAyMDEyIDEwOjQ4IEFNDQpUbzogTWFu Z2VyLCBKYW1lcyBIOyBqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtqb3NlXSBTeW1tZXRyaWMgZW5jcnlwdGlvbiBhbmQga2V5IGFncmVlbWVudCB3aXRo IGFuZCB3aXRob3V0IGEgc2VwYXJhdGUgQ01LDQoNClRoZSByZWFzb24gd2UgYWxyZWFkeSBoYXZl ICM0IChkaXJlY3QgdXNlIG9mIHRoZSBhZ3JlZWQtdXBvbiBrZXkpIGlzIHRoYXQgaXQgc2F2ZXMg YW4gdW5uZWNlc3Nhcnkgc2Vjb25kIGVuY3J5cHRpb24gc3RlcCBpbiB0aGUgc2luZ2xlIHJlY2lw aWVudCBjYXNlLiAgVGhlcmUgaXMgYWxzbyBzb21lIHNwYWNlIGFkdmFudGFnZSBhcyB3ZWxsLCBh cyB5b3UgcG9pbnQgb3V0Lg0KDQpEbyB5b3UgaGF2ZSBhbiBhbHRlcm5hdGl2ZSBzeW50YXggcHJv cG9zYWwgdG8g4oCcYWxn4oCdOuKAnWRpcuKAnSBmb3IgZXhwcmVzc2luZyBkaXJlY3Qgc3ltbWV0 cmljIGVuY3J5cHRpb24sIHNpbmNlIGFwcGFyZW50bHkgeW91IGRvbuKAmXQgbGlrZSB0aGF0IHN5 bnRheD8gIFNldmVyYWwgb3RoZXJzIGhhdmUgc2FpZCB0aGF0IGl0IHdvdWxkIHdvcmsgZm9yIHRo ZW3igKYNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgVGhhbmtzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBNYW5nZXIsIEphbWVzIEgg W21haWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tXTxtYWlsdG86W21haWx0bzpK YW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tXT4NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDE5 LCAyMDEyIDExOjU3IFBNDQpUbzogTWlrZSBKb25lczsgam9zZUBpZXRmLm9yZzxtYWlsdG86am9z ZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbam9zZV0gU3ltbWV0cmljIGVuY3J5cHRpb24gYW5k IGtleSBhZ3JlZW1lbnQgd2l0aCBhbmQgd2l0aG91dCBhIHNlcGFyYXRlIENNSw0KDQpLZWVwICMx OyBhZGQgIzM7IGRyb3AgIzQ7IGFuZCBtYXliZSBhZGQgIzIsIGJ1dCBub3Qgd2l0aCBhbiDigJxh bGfigJ064oCdZGly4oCdIGhhY2suDQoNCiM0IChrZXkgYWdyZWVtZW50IHJlc3VsdCB1c2VkIGFz IHRoZSBDTUspIHNhdmVzIH41MCBjaGFycyAob3IgMjQgY2hhcnM/KSBjb21wYXJlZCB0byAjMywg YnV0IG9ubHkgd2hlbiB5b3UgaGF2ZSB1c2VkIGh1bmRyZWRzIG9mIGNoYXJzIChwcm9iYWJseSBk b3ViZS1iYXNlNjQtZW5jb2RlZCkgdG8gcmVwcmVzZW50IGFuIGVwaGVtZXJhbCBrZXkuIE5vdCBz dXJlIGl0IGlzIHdvcnRod2hpbGUuDQoNClRoZSDigJxhbGfigJ064oCdZGly4oCdIGhhY2sgaXMg bWFraW5nIFJpY2hhcmQgQmFybmVz4oCZcyBKU01TIGlkZWFzIGxvb2sgYmV0dGVyIGFuZCBiZXR0 ZXIgKGlmIGl0IGRpZG7igJl0IGRyb3AgdGhlIGF1dGhlbnRpY2F0ZWRBdHRyaWJ1dGVzIHBhcnQg b2YgQ01TKS4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQoNCg0KRnJvbTogam9zZS1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86am9zZS1ib3VuY2Vz QGlldGYub3JnXTxtYWlsdG86W21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddPiBPbiBCZWhh bGYgT2YgTWlrZSBKb25lcw0KU2VudDogVGh1cnNkYXksIDE5IEp1bHkgMjAxMiAxMTowNCBBTQ0K VG86IGpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbam9zZV0g U3ltbWV0cmljIGVuY3J5cHRpb24gYW5kIGtleSBhZ3JlZW1lbnQgd2l0aCBhbmQgd2l0aG91dCBh IHNlcGFyYXRlIENNSw0KDQpIaSBhbGwsDQoNCknigJl2ZSBiZWVuIHRoaW5raW5nIGFib3V0IHR3 byBvZiBvdXIgb3BlbiBpc3N1ZXMsIHdoaWNoIGFyZSBjbG9zZWx5IHJlbGF0ZWQsIGFuZCBhbSB3 cml0aW5nIHRvIG1ha2UgYSBwcm9wb3NhbCB0byByZXNvbHZlIGJvdGggb2YgdGhlbS4gIFRoZSBp c3N1ZXMgYXJlOg0KDQooMSkgQ3VycmVudGx5IHdlIHNwZWNpZnkgbWV0aG9kcyBmb3IgdXNpbmcg c3ltbWV0cmljIGtleXMgdG8ga2V5IHdyYXAgYSBzZXBhcmF0ZSBDb250ZW50IE1hc3RlciBLZXkg KENNSyksIGJ1dCBubyBtZWFucyBvZiB1c2luZyB0aGUgc3ltbWV0cmljIGtleSBhcyB0aGUgQ01L IGRpcmVjdGx5LiAgU29tZSBhcHBsaWNhdGlvbnMgbmVlZCB0aGlzIGZ1bmN0aW9uYWxpdHksIGJv dGggZm9yIHNpemUgYW5kIGZvciBlZmZpY2llbmN5IHJlYXNvbnMuDQoNCigyKSBDdXJyZW50bHkg d2Ugc3BlY2lmeSBtZXRob2RzIGZvciBwZXJmb3JtaW5nIGtleSBhZ3JlZW1lbnQgYW5kIGRpcmVj dGx5IHVzaW5nIHRoZSByZXN1bHRpbmcga2V5IGFzIHRoZSBDTUsgdG8gcGVyZm9ybSBibG9jayBl bmNyeXB0aW9uLCBidXQgbm8gbWVhbnMgb2YgdXNpbmcgdGhlIGFncmVlZC11cG9uIGtleSB0byB3 cmFwIGEgc2VwYXJhdGUgQ01LLiAgV2hlbiBkb2luZyBrZXkgYWdyZWVtZW50IGZvciBtdWx0aXBs ZSByZWNpcGllbnRzLCBhIHNlcGFyYXRlIENNSyBpcyBuZWVkZWQuDQoNClRodXMsIEkgcHJvcG9z ZSB0aGF0IHdlIGRlZmluZSBtZXRob2RzIGZvciBmaWxsaW5nIGluIGJvdGggb2YgdGhlIGhvbGVz IGFib3ZlLCBhcyBmb2xsb3dzOg0KDQooYSkgRGVmaW5lIOKAnGFsZ+KAnTrigJ1kaXLigJ0gKGRp cmVjdCkgdG8gbWVhbiB0aGF0IHRoZSBzeW1tZXRyaWMga2V5IGlzIGRpcmVjdGx5IHVzZWQgYXMg dGhlIENNSyBmb3IgdGhlIGJsb2NrIGVuY3J5cHRpb24gYW5kIGludGVncml0eSBjYWxjdWxhdGlv bnMsIHJhdGhlciB0aGFuIGFzIGEga2V5IHRvIHdyYXAgdGhlIENNSyB2YWx1ZS4NCg0KKGIpIERl ZmluZSDigJxhbGfigJ064oCdRUNESC1FUytBMTI4S1figJ0gYW5kIOKAnGFsZ+KAnTrigJ1FQ0RI LUVTK0EyNTZLV+KAnSB0byBtZWFuIHRoYXQgdGhlIHJlc3VsdCBvZiB0aGUga2V5IGFncmVlbWVu dCBpcyByZXNwZWN0aXZlbHkgdXNlZCBhcyB0aGUgMTI4IGJpdCBvciAyNTYgYml0IEFFUyBLZXkg V3JhcCBrZXkgdG8gd3JhcCB0aGUgQ01LLg0KDQpEb2luZyB0aGlzIHdpbGwgZW5hYmxlIGFsbCBm b3VyIGZsYXZvcnMsIHdoZXJlYXMgd2XigJlyZSBjdXJyZW50bHkgbWlzc2luZyAyIGFuZCAzIGJl bG93Og0KMS4gIFRoZSBzeW1tZXRyaWMga2V5IHVzZWQgdG8gd3JhcCBhIHNlcGFyYXRlIENNSw0K Mi4gIFRoZSBzeW1tZXRyaWMga2V5IHVzZWQgYXMgdGhlIENNSw0KMy4gIFRoZSBrZXkgYWdyZWVt ZW50IHJlc3VsdCB1c2VkIHRvIHdyYXAgYSBzZXBhcmF0ZSBDTUsNCjQuICBUaGUga2V5IGFncmVl bWVudCByZXN1bHQgdXNlZCBhcyB0aGUgQ01LDQoNCkkgcmVjb2duaXplIHRoYXQgZmxhdm9ycyAy IGFuZCA0IGFyZSBub3QgdXNhYmxlIHdpdGggbXVsdGlwbGUgcmVjaXBpZW50cyB3aGVuIG1ldGhv ZHMgc3VjaCBhcyBKV0UgSlNPTiBTZXJpYWxpemF0aW9uIGFyZSB1c2VkICh3aGljaCBjb3VudHMg b24gYSBjb21tb24gQ01LIHZhbHVlIHRvIGVuYWJsZSBhIGNvbW1vbiBjaXBoZXJ0ZXh0IHZhbHVl KS4gIEEgbm90ZSB0byB0aGF0IGVmZmVjdCB3b3VsZCBiZSBhZGRlZCB0byB0aGUgSldBIGRlZmlu aXRpb25zIG9mIOKAnGFsZ+KAnTrigJxFQ0RILUVT4oCdIGFuZCDigJxhbGfigJ064oCdZGly4oCd IGFuZCBpdCB3b3VsZCBiZSBwb2ludGVkIG91dCBpbiB0aGUgSldFLUpTIHNwZWMgdGhhdCDigJxh bGfigJ0gdmFsdWVzIHRoYXQgdXRpbGl6ZSBhIHNlcGFyYXRlIENNSyBNVVNUIGJlIHVzZWQgd2hl biB0aGUgcGxhaW50ZXh0IGlzIGVuY3J5cHRlZCB0byBtdWx0aXBsZSByZWNpcGllbnRzLg0KDQpD b21tZW50cz8NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg== --_000_B26C1EF377CB694EAB6BDDC8E624B6E7555039C5BL2PRD0310MB362_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPuKAnG5vbmXigJ0gaXMgbm90IGluZm9ybWF0aXZlIDwvc3Bhbj4NCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+TDwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+IGF0IGFsbCwgYXQgbGVhc3QgdGhlIOKAnGRpcuKAnSBp cyB0ZWxsaW5nIHVzIHNvbWV0aGluZw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gam9zZS1ib3VuY2VzQGlldGYub3JnIFttYWls dG86am9zZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KaW0gU2NoYWFk PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSnVseSAyMCwgMjAxMiAyOjQxIFBNPGJyPg0KPGI+ VG86PC9iPiBNaWtlIEpvbmVzOyAnTWFuZ2VyLCBKYW1lcyBIJzsgam9zZUBpZXRmLm9yZzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW2pvc2VdIFN5bW1ldHJpYyBlbmNyeXB0aW9uIGFuZCBrZXkg YWdyZWVtZW50IHdpdGggYW5kIHdpdGhvdXQgYSBzZXBhcmF0ZSBDTUs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+SXQgc2VlbXMgbGlrZSB0aGUgY29ycmVjdCB0aGluayBzaG91bGQgYmUg4oCcYWxn4oCdOuKA nW5vbmXigJ0NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9y OiMxRjQ5N0QiPko8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0 bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmciPmpvc2UtYm91bmNlc0BpZXRmLm9yZzwvYT4gPGEgaHJl Zj0ibWFpbHRvOlttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXSI+DQpbbWFpbHRvOmpvc2Ut Ym91bmNlc0BpZXRmLm9yZ108L2E+IDxiPk9uIEJlaGFsZiBPZiA8L2I+TWlrZSBKb25lczxicj4N CjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1bHkgMjAsIDIwMTIgMTA6NDggQU08YnI+DQo8Yj5Ubzo8 L2I+IE1hbmdlciwgSmFtZXMgSDsgPGEgaHJlZj0ibWFpbHRvOmpvc2VAaWV0Zi5vcmciPmpvc2VA aWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbam9zZV0gU3ltbWV0cmljIGVu Y3J5cHRpb24gYW5kIGtleSBhZ3JlZW1lbnQgd2l0aCBhbmQgd2l0aG91dCBhIHNlcGFyYXRlIENN SzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5UaGUgcmVhc29uIHdlIGFscmVhZHkgaGF2ZSAjNCAoZGlyZWN0 IHVzZSBvZiB0aGUgYWdyZWVkLXVwb24ga2V5KSBpcyB0aGF0IGl0IHNhdmVzIGFuIHVubmVjZXNz YXJ5IHNlY29uZCBlbmNyeXB0aW9uIHN0ZXAgaW4gdGhlIHNpbmdsZSByZWNpcGllbnQgY2FzZS4m bmJzcDsgVGhlcmUgaXMgYWxzbyBzb21lIHNwYWNlIGFkdmFudGFnZSBhcyB3ZWxsLCBhcyB5b3Ug cG9pbnQNCiBvdXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5EbyB5b3Ug aGF2ZSBhbiBhbHRlcm5hdGl2ZSBzeW50YXggcHJvcG9zYWwgdG8g4oCcYWxn4oCdOuKAnWRpcuKA nSBmb3IgZXhwcmVzc2luZyBkaXJlY3Qgc3ltbWV0cmljIGVuY3J5cHRpb24sIHNpbmNlIGFwcGFy ZW50bHkgeW91IGRvbuKAmXQgbGlrZSB0aGF0IHN5bnRheD8mbmJzcDsgU2V2ZXJhbCBvdGhlcnMg aGF2ZSBzYWlkIHRoYXQgaXQgd291bGQgd29yayBmb3IgdGhlbeKApjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNYW5nZXIsIEphbWVzIEgNCjxhIGhyZWY9Im1haWx0 bzpbbWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb21dIj5bbWFpbHRvOkphbWVz LkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb21dPC9hPg0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJz ZGF5LCBKdWx5IDE5LCAyMDEyIDExOjU3IFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzOyA8 YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUkU6IFtqb3NlXSBTeW1tZXRyaWMgZW5jcnlwdGlvbiBhbmQga2V5IGFncmVl bWVudCB3aXRoIGFuZCB3aXRob3V0IGEgc2VwYXJhdGUgQ01LPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5LZWVwICMxOyBhZGQgIzM7IGRyb3AgIzQ7IGFuZCBtYXliZSBhZGQgIzIsIGJ1 dCBub3Qgd2l0aCBhbiDigJxhbGfigJ064oCdZGly4oCdIGhhY2suPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiM0IChrZXkgYWdy ZWVtZW50IHJlc3VsdCB1c2VkIGFzIHRoZSBDTUspIHNhdmVzIH41MCBjaGFycyAob3IgMjQgY2hh cnM/KSBjb21wYXJlZCB0byAjMywgYnV0IG9ubHkgd2hlbiB5b3UgaGF2ZSB1c2VkIGh1bmRyZWRz IG9mIGNoYXJzIChwcm9iYWJseSBkb3ViZS1iYXNlNjQtZW5jb2RlZCkgdG8gcmVwcmVzZW50IGFu IGVwaGVtZXJhbCBrZXkuDQogTm90IHN1cmUgaXQgaXMgd29ydGh3aGlsZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhlIOKA nGFsZ+KAnTrigJ1kaXLigJ0gaGFjayBpcyBtYWtpbmcgUmljaGFyZCBCYXJuZXPigJlzIEpTTVMg aWRlYXMgbG9vayBiZXR0ZXIgYW5kIGJldHRlciAoaWYgaXQgZGlkbuKAmXQgZHJvcCB0aGUgYXV0 aGVudGljYXRlZEF0dHJpYnV0ZXMgcGFydCBvZiBDTVMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4tLTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1BVSIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJl Zj0ibWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZyI+am9zZS1ib3VuY2VzQGlldGYub3JnPC9h PiA8YSBocmVmPSJtYWlsdG86W21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddIj4NClttYWls dG86am9zZS1ib3VuY2VzQGlldGYub3JnXTwvYT4gPGI+T24gQmVoYWxmIE9mIDwvYj5NaWtlIEpv bmVzPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCAxOSBKdWx5IDIwMTIgMTE6MDQgQU08YnI+ DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIj5qb3NlQGlldGYub3Jn PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbam9zZV0gU3ltbWV0cmljIGVuY3J5cHRpb24gYW5k IGtleSBhZ3JlZW1lbnQgd2l0aCBhbmQgd2l0aG91dCBhIHNlcGFyYXRlIENNSzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBsYW5nPSJFTi1BVSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkhpIGFsbCw8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5J4oCZdmUgYmVlbiB0aGlua2luZyBhYm91dCB0d28gb2Ygb3VyIG9wZW4gaXNzdWVz LCB3aGljaCBhcmUgY2xvc2VseSByZWxhdGVkLCBhbmQgYW0gd3JpdGluZyB0byBtYWtlIGEgcHJv cG9zYWwgdG8gcmVzb2x2ZSBib3RoIG9mIHRoZW0uJm5ic3A7IFRoZSBpc3N1ZXMgYXJlOjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPigxKSBDdXJyZW50bHkgd2Ugc3BlY2lmeSBtZXRob2RzIGZvciB1c2luZyBz eW1tZXRyaWMga2V5cyB0byBrZXkgd3JhcCBhIHNlcGFyYXRlIENvbnRlbnQgTWFzdGVyIEtleSAo Q01LKSwgYnV0IG5vIG1lYW5zIG9mIHVzaW5nIHRoZSBzeW1tZXRyaWMga2V5IGFzIHRoZSBDTUsg ZGlyZWN0bHkuJm5ic3A7IFNvbWUgYXBwbGljYXRpb25zIG5lZWQgdGhpcyBmdW5jdGlvbmFsaXR5 LA0KIGJvdGggZm9yIHNpemUgYW5kIGZvciBlZmZpY2llbmN5IHJlYXNvbnMuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+KDIpIEN1cnJlbnRseSB3ZSBzcGVjaWZ5IG1ldGhvZHMgZm9yIHBlcmZvcm1pbmcga2V5 IGFncmVlbWVudCBhbmQgZGlyZWN0bHkgdXNpbmcgdGhlIHJlc3VsdGluZyBrZXkgYXMgdGhlIENN SyB0byBwZXJmb3JtIGJsb2NrIGVuY3J5cHRpb24sIGJ1dCBubyBtZWFucyBvZiB1c2luZyB0aGUg YWdyZWVkLXVwb24ga2V5IHRvIHdyYXAgYSBzZXBhcmF0ZSBDTUsuJm5ic3A7IFdoZW4NCiBkb2lu ZyBrZXkgYWdyZWVtZW50IGZvciBtdWx0aXBsZSByZWNpcGllbnRzLCBhIHNlcGFyYXRlIENNSyBp cyBuZWVkZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGh1cywgSSBwcm9wb3NlIHRoYXQgd2UgZGVmaW5l IG1ldGhvZHMgZm9yIGZpbGxpbmcgaW4gYm90aCBvZiB0aGUgaG9sZXMgYWJvdmUsIGFzIGZvbGxv d3M6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+KGEpIERlZmluZSDigJxhbGfigJ064oCdZGly4oCdIChkaXJl Y3QpIHRvIG1lYW4gdGhhdCB0aGUgc3ltbWV0cmljIGtleSBpcyBkaXJlY3RseSB1c2VkIGFzIHRo ZSBDTUsgZm9yIHRoZSBibG9jayBlbmNyeXB0aW9uIGFuZCBpbnRlZ3JpdHkgY2FsY3VsYXRpb25z LCByYXRoZXIgdGhhbiBhcyBhIGtleSB0byB3cmFwIHRoZSBDTUsgdmFsdWUuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+KGIpIERlZmluZSDigJxhbGfigJ064oCdRUNESC1FUyYjNDM7QTEyOEtX4oCdIGFuZCDi gJxhbGfigJ064oCdRUNESC1FUyYjNDM7QTI1NktX4oCdIHRvIG1lYW4gdGhhdCB0aGUgcmVzdWx0 IG9mIHRoZSBrZXkgYWdyZWVtZW50IGlzIHJlc3BlY3RpdmVseSB1c2VkIGFzIHRoZSAxMjggYml0 IG9yIDI1NiBiaXQgQUVTIEtleSBXcmFwIGtleSB0byB3cmFwIHRoZSBDTUsuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+RG9pbmcgdGhpcyB3aWxsIGVuYWJsZSBhbGwgZm91ciBmbGF2b3JzLCB3aGVyZWFzIHdl 4oCZcmUgY3VycmVudGx5IG1pc3NpbmcgMiBhbmQgMyBiZWxvdzo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4xLiZuYnNwOyBUaGUg c3ltbWV0cmljIGtleSB1c2VkIHRvIHdyYXAgYSBzZXBhcmF0ZSBDTUs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4yLiZuYnNwOyBU aGUgc3ltbWV0cmljIGtleSB1c2VkIGFzIHRoZSBDTUs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4zLiZuYnNwOyBUaGUga2V5IGFn cmVlbWVudCByZXN1bHQgdXNlZCB0byB3cmFwIGEgc2VwYXJhdGUgQ01LPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+NC4mbmJzcDsg VGhlIGtleSBhZ3JlZW1lbnQgcmVzdWx0IHVzZWQgYXMgdGhlIENNSzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PkkgcmVjb2duaXplIHRoYXQgZmxhdm9ycyAyIGFuZCA0IGFyZSBub3QgdXNhYmxlIHdpdGggbXVs dGlwbGUgcmVjaXBpZW50cyB3aGVuIG1ldGhvZHMgc3VjaCBhcyBKV0UgSlNPTiBTZXJpYWxpemF0 aW9uIGFyZSB1c2VkICh3aGljaCBjb3VudHMgb24gYSBjb21tb24gQ01LIHZhbHVlIHRvIGVuYWJs ZSBhIGNvbW1vbiBjaXBoZXJ0ZXh0IHZhbHVlKS4mbmJzcDsgQSBub3RlIHRvDQogdGhhdCBlZmZl Y3Qgd291bGQgYmUgYWRkZWQgdG8gdGhlIEpXQSBkZWZpbml0aW9ucyBvZiDigJxhbGfigJ064oCc RUNESC1FU+KAnSBhbmQg4oCcYWxn4oCdOuKAnWRpcuKAnSBhbmQgaXQgd291bGQgYmUgcG9pbnRl ZCBvdXQgaW4gdGhlIEpXRS1KUyBzcGVjIHRoYXQg4oCcYWxn4oCdIHZhbHVlcyB0aGF0IHV0aWxp emUgYSBzZXBhcmF0ZSBDTUsgTVVTVCBiZSB1c2VkIHdoZW4gdGhlIHBsYWludGV4dCBpcyBlbmNy eXB0ZWQgdG8gbXVsdGlwbGUgcmVjaXBpZW50cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Db21tZW50cz88 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0g TWlrZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B26C1EF377CB694EAB6BDDC8E624B6E7555039C5BL2PRD0310MB362_-- From Michael.Jones@microsoft.com Fri Jul 20 14:53:03 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1AA11E808C for ; Fri, 20 Jul 2012 14:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.782 X-Spam-Level: X-Spam-Status: No, score=-3.782 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGo3+zjgnGtN for ; Fri, 20 Jul 2012 14:53:00 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id CC28811E8086 for ; Fri, 20 Jul 2012 14:52:57 -0700 (PDT) Received: from mail120-db3-R.bigfish.com (10.3.81.246) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.23; Fri, 20 Jul 2012 21:53:54 +0000 Received: from mail120-db3 (localhost [127.0.0.1]) by mail120-db3-R.bigfish.com (Postfix) with ESMTP id 16761100366; Fri, 20 Jul 2012 21:53:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz9371Ic89bhdf9Mc857h4015I14ffIzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail120-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail120-db3 (localhost.localdomain [127.0.0.1]) by mail120-db3 (MessageSwitch) id 1342821232445497_30369; Fri, 20 Jul 2012 21:53:52 +0000 (UTC) Received: from DB3EHSMHS007.bigfish.com (unknown [10.3.81.241]) by mail120-db3.bigfish.com (Postfix) with ESMTP id 60B0A3A003F; Fri, 20 Jul 2012 21:53:52 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS007.bigfish.com (10.3.87.107) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 20 Jul 2012 21:53:52 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0309.003; Fri, 20 Jul 2012 21:53:49 +0000 From: Mike Jones To: Jim Schaad , "'Manger, James H'" , "jose@ietf.org" Thread-Topic: [jose] Symmetric encryption and key agreement with and without a separate CMK Thread-Index: AQHNZsHhPL0/5dkBo0ywhBYciF+4tpcytlGw Date: Fri, 20 Jul 2012 21:53:49 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436673D767@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436673A0B7@TK5EX14MBXC285.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F7E0F747@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436673D2D6@TK5EX14MBXC285.redmond.corp.microsoft.com> <000f01cd66c0$5d32b290$179817b0$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436673D767TK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] Symmetric encryption and key agreement with and without a separate CMK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 21:53:03 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436673D767TK5EX14MBXC285r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBJ4oCZZCBjb25zaWRlcmVkIOKAnG5vbmXigJ0sIGJ1dCByZWplY3RlZCBpdCBmb3Igc2V2 ZXJhbCByZWFzb25zLiAgRmlyc3QsIOKAnG5vbmXigJ0gaXMgYSBKV1MgYWxnb3JpdGhtIOKAkyBu b3QgYSBKV0UgYWxnb3JpdGhtLiAgSXQgYWxzbyBtZWFucyBzb21ldGhpbmcgY29tcGxldGVseSBk aWZmZXJlbnQgdGhhbiDigJxub25l4oCdIHVzZWQgaW4gdGhlIEpXUyBjYXNlLCBzbyBpdOKAmXMg YmV0dGVyIG5vdCB0byBvdmVybG9hZCB0aGUgdmFsdWUgYW5kIGludHJvZHVjZSBjb25mdXNpb24s IGJvdGggZm9yIGh1bWFucywgYW5kIGluIGltcGxlbWVudGF0aW9ucy4NCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0K DQpGcm9tOiBqb3NlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBBbnRob255IE5hZGFsaW4NClNlbnQ6IEZyaWRheSwgSnVseSAyMCwg MjAxMiAyOjUxIFBNDQpUbzogSmltIFNjaGFhZDsgTWlrZSBKb25lczsgJ01hbmdlciwgSmFtZXMg SCc7IGpvc2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbam9zZV0gU3ltbWV0cmljIGVuY3J5cHRp b24gYW5kIGtleSBhZ3JlZW1lbnQgd2l0aCBhbmQgd2l0aG91dCBhIHNlcGFyYXRlIENNSw0KDQri gJxub25l4oCdIGlzIG5vdCBpbmZvcm1hdGl2ZSDimLkgYXQgYWxsLCBhdCBsZWFzdCB0aGUg4oCc ZGly4oCdIGlzIHRlbGxpbmcgdXMgc29tZXRoaW5nDQoNCkZyb206IGpvc2UtYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmpvc2UtYm91bmNlc0Bp ZXRmLm9yZ108bWFpbHRvOlttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXT4gT24gQmVoYWxm IE9mIEppbSBTY2hhYWQNClNlbnQ6IEZyaWRheSwgSnVseSAyMCwgMjAxMiAyOjQxIFBNDQpUbzog TWlrZSBKb25lczsgJ01hbmdlciwgSmFtZXMgSCc7IGpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2pvc2VdIFN5bW1ldHJpYyBlbmNyeXB0aW9uIGFuZCBr ZXkgYWdyZWVtZW50IHdpdGggYW5kIHdpdGhvdXQgYSBzZXBhcmF0ZSBDTUsNCg0KSXQgc2VlbXMg bGlrZSB0aGUgY29ycmVjdCB0aGluayBzaG91bGQgYmUg4oCcYWxn4oCdOuKAnW5vbmXigJ0g4pi6 DQoNCg0KRnJvbTogam9zZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpqb3NlLWJvdW5jZXNAaWV0 Zi5vcmc+IFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXTxtYWlsdG86W21haWx0bzpqb3Nl LWJvdW5jZXNAaWV0Zi5vcmddPiBPbiBCZWhhbGYgT2YgTWlrZSBKb25lcw0KU2VudDogRnJpZGF5 LCBKdWx5IDIwLCAyMDEyIDEwOjQ4IEFNDQpUbzogTWFuZ2VyLCBKYW1lcyBIOyBqb3NlQGlldGYu b3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtqb3NlXSBTeW1tZXRyaWMg ZW5jcnlwdGlvbiBhbmQga2V5IGFncmVlbWVudCB3aXRoIGFuZCB3aXRob3V0IGEgc2VwYXJhdGUg Q01LDQoNClRoZSByZWFzb24gd2UgYWxyZWFkeSBoYXZlICM0IChkaXJlY3QgdXNlIG9mIHRoZSBh Z3JlZWQtdXBvbiBrZXkpIGlzIHRoYXQgaXQgc2F2ZXMgYW4gdW5uZWNlc3Nhcnkgc2Vjb25kIGVu Y3J5cHRpb24gc3RlcCBpbiB0aGUgc2luZ2xlIHJlY2lwaWVudCBjYXNlLiAgVGhlcmUgaXMgYWxz byBzb21lIHNwYWNlIGFkdmFudGFnZSBhcyB3ZWxsLCBhcyB5b3UgcG9pbnQgb3V0Lg0KDQpEbyB5 b3UgaGF2ZSBhbiBhbHRlcm5hdGl2ZSBzeW50YXggcHJvcG9zYWwgdG8g4oCcYWxn4oCdOuKAnWRp cuKAnSBmb3IgZXhwcmVzc2luZyBkaXJlY3Qgc3ltbWV0cmljIGVuY3J5cHRpb24sIHNpbmNlIGFw cGFyZW50bHkgeW91IGRvbuKAmXQgbGlrZSB0aGF0IHN5bnRheD8gIFNldmVyYWwgb3RoZXJzIGhh dmUgc2FpZCB0aGF0IGl0IHdvdWxkIHdvcmsgZm9yIHRoZW3igKYNCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhhbmtzLA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg LS0gTWlrZQ0KDQpGcm9tOiBNYW5nZXIsIEphbWVzIEggW21haWx0bzpKYW1lcy5ILk1hbmdlckB0 ZWFtLnRlbHN0cmEuY29tXTxtYWlsdG86W21haWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0 cmEuY29tXT4NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDE5LCAyMDEyIDExOjU3IFBNDQpUbzogTWlr ZSBKb25lczsgam9zZUBpZXRmLm9yZzxtYWlsdG86am9zZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJF OiBbam9zZV0gU3ltbWV0cmljIGVuY3J5cHRpb24gYW5kIGtleSBhZ3JlZW1lbnQgd2l0aCBhbmQg d2l0aG91dCBhIHNlcGFyYXRlIENNSw0KDQpLZWVwICMxOyBhZGQgIzM7IGRyb3AgIzQ7IGFuZCBt YXliZSBhZGQgIzIsIGJ1dCBub3Qgd2l0aCBhbiDigJxhbGfigJ064oCdZGly4oCdIGhhY2suDQoN CiM0IChrZXkgYWdyZWVtZW50IHJlc3VsdCB1c2VkIGFzIHRoZSBDTUspIHNhdmVzIH41MCBjaGFy cyAob3IgMjQgY2hhcnM/KSBjb21wYXJlZCB0byAjMywgYnV0IG9ubHkgd2hlbiB5b3UgaGF2ZSB1 c2VkIGh1bmRyZWRzIG9mIGNoYXJzIChwcm9iYWJseSBkb3ViZS1iYXNlNjQtZW5jb2RlZCkgdG8g cmVwcmVzZW50IGFuIGVwaGVtZXJhbCBrZXkuIE5vdCBzdXJlIGl0IGlzIHdvcnRod2hpbGUuDQoN ClRoZSDigJxhbGfigJ064oCdZGly4oCdIGhhY2sgaXMgbWFraW5nIFJpY2hhcmQgQmFybmVz4oCZ cyBKU01TIGlkZWFzIGxvb2sgYmV0dGVyIGFuZCBiZXR0ZXIgKGlmIGl0IGRpZG7igJl0IGRyb3Ag dGhlIGF1dGhlbnRpY2F0ZWRBdHRyaWJ1dGVzIHBhcnQgb2YgQ01TKS4NCg0KLS0NCkphbWVzIE1h bmdlcg0KDQoNCg0KRnJvbTogam9zZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpqb3NlLWJvdW5j ZXNAaWV0Zi5vcmc+IFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXTxtYWlsdG86W21haWx0 bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddPiBPbiBCZWhhbGYgT2YgTWlrZSBKb25lcw0KU2VudDog VGh1cnNkYXksIDE5IEp1bHkgMjAxMiAxMTowNCBBTQ0KVG86IGpvc2VAaWV0Zi5vcmc8bWFpbHRv Ompvc2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbam9zZV0gU3ltbWV0cmljIGVuY3J5cHRpb24gYW5k IGtleSBhZ3JlZW1lbnQgd2l0aCBhbmQgd2l0aG91dCBhIHNlcGFyYXRlIENNSw0KDQpIaSBhbGws DQoNCknigJl2ZSBiZWVuIHRoaW5raW5nIGFib3V0IHR3byBvZiBvdXIgb3BlbiBpc3N1ZXMsIHdo aWNoIGFyZSBjbG9zZWx5IHJlbGF0ZWQsIGFuZCBhbSB3cml0aW5nIHRvIG1ha2UgYSBwcm9wb3Nh bCB0byByZXNvbHZlIGJvdGggb2YgdGhlbS4gIFRoZSBpc3N1ZXMgYXJlOg0KDQooMSkgQ3VycmVu dGx5IHdlIHNwZWNpZnkgbWV0aG9kcyBmb3IgdXNpbmcgc3ltbWV0cmljIGtleXMgdG8ga2V5IHdy YXAgYSBzZXBhcmF0ZSBDb250ZW50IE1hc3RlciBLZXkgKENNSyksIGJ1dCBubyBtZWFucyBvZiB1 c2luZyB0aGUgc3ltbWV0cmljIGtleSBhcyB0aGUgQ01LIGRpcmVjdGx5LiAgU29tZSBhcHBsaWNh dGlvbnMgbmVlZCB0aGlzIGZ1bmN0aW9uYWxpdHksIGJvdGggZm9yIHNpemUgYW5kIGZvciBlZmZp Y2llbmN5IHJlYXNvbnMuDQoNCigyKSBDdXJyZW50bHkgd2Ugc3BlY2lmeSBtZXRob2RzIGZvciBw ZXJmb3JtaW5nIGtleSBhZ3JlZW1lbnQgYW5kIGRpcmVjdGx5IHVzaW5nIHRoZSByZXN1bHRpbmcg a2V5IGFzIHRoZSBDTUsgdG8gcGVyZm9ybSBibG9jayBlbmNyeXB0aW9uLCBidXQgbm8gbWVhbnMg b2YgdXNpbmcgdGhlIGFncmVlZC11cG9uIGtleSB0byB3cmFwIGEgc2VwYXJhdGUgQ01LLiAgV2hl biBkb2luZyBrZXkgYWdyZWVtZW50IGZvciBtdWx0aXBsZSByZWNpcGllbnRzLCBhIHNlcGFyYXRl IENNSyBpcyBuZWVkZWQuDQoNClRodXMsIEkgcHJvcG9zZSB0aGF0IHdlIGRlZmluZSBtZXRob2Rz IGZvciBmaWxsaW5nIGluIGJvdGggb2YgdGhlIGhvbGVzIGFib3ZlLCBhcyBmb2xsb3dzOg0KDQoo YSkgRGVmaW5lIOKAnGFsZ+KAnTrigJ1kaXLigJ0gKGRpcmVjdCkgdG8gbWVhbiB0aGF0IHRoZSBz eW1tZXRyaWMga2V5IGlzIGRpcmVjdGx5IHVzZWQgYXMgdGhlIENNSyBmb3IgdGhlIGJsb2NrIGVu Y3J5cHRpb24gYW5kIGludGVncml0eSBjYWxjdWxhdGlvbnMsIHJhdGhlciB0aGFuIGFzIGEga2V5 IHRvIHdyYXAgdGhlIENNSyB2YWx1ZS4NCg0KKGIpIERlZmluZSDigJxhbGfigJ064oCdRUNESC1F UytBMTI4S1figJ0gYW5kIOKAnGFsZ+KAnTrigJ1FQ0RILUVTK0EyNTZLV+KAnSB0byBtZWFuIHRo YXQgdGhlIHJlc3VsdCBvZiB0aGUga2V5IGFncmVlbWVudCBpcyByZXNwZWN0aXZlbHkgdXNlZCBh cyB0aGUgMTI4IGJpdCBvciAyNTYgYml0IEFFUyBLZXkgV3JhcCBrZXkgdG8gd3JhcCB0aGUgQ01L Lg0KDQpEb2luZyB0aGlzIHdpbGwgZW5hYmxlIGFsbCBmb3VyIGZsYXZvcnMsIHdoZXJlYXMgd2Xi gJlyZSBjdXJyZW50bHkgbWlzc2luZyAyIGFuZCAzIGJlbG93Og0KMS4gIFRoZSBzeW1tZXRyaWMg a2V5IHVzZWQgdG8gd3JhcCBhIHNlcGFyYXRlIENNSw0KMi4gIFRoZSBzeW1tZXRyaWMga2V5IHVz ZWQgYXMgdGhlIENNSw0KMy4gIFRoZSBrZXkgYWdyZWVtZW50IHJlc3VsdCB1c2VkIHRvIHdyYXAg YSBzZXBhcmF0ZSBDTUsNCjQuICBUaGUga2V5IGFncmVlbWVudCByZXN1bHQgdXNlZCBhcyB0aGUg Q01LDQoNCkkgcmVjb2duaXplIHRoYXQgZmxhdm9ycyAyIGFuZCA0IGFyZSBub3QgdXNhYmxlIHdp dGggbXVsdGlwbGUgcmVjaXBpZW50cyB3aGVuIG1ldGhvZHMgc3VjaCBhcyBKV0UgSlNPTiBTZXJp YWxpemF0aW9uIGFyZSB1c2VkICh3aGljaCBjb3VudHMgb24gYSBjb21tb24gQ01LIHZhbHVlIHRv IGVuYWJsZSBhIGNvbW1vbiBjaXBoZXJ0ZXh0IHZhbHVlKS4gIEEgbm90ZSB0byB0aGF0IGVmZmVj dCB3b3VsZCBiZSBhZGRlZCB0byB0aGUgSldBIGRlZmluaXRpb25zIG9mIOKAnGFsZ+KAnTrigJxF Q0RILUVT4oCdIGFuZCDigJxhbGfigJ064oCdZGly4oCdIGFuZCBpdCB3b3VsZCBiZSBwb2ludGVk IG91dCBpbiB0aGUgSldFLUpTIHNwZWMgdGhhdCDigJxhbGfigJ0gdmFsdWVzIHRoYXQgdXRpbGl6 ZSBhIHNlcGFyYXRlIENNSyBNVVNUIGJlIHVzZWQgd2hlbiB0aGUgcGxhaW50ZXh0IGlzIGVuY3J5 cHRlZCB0byBtdWx0aXBsZSByZWNpcGllbnRzLg0KDQpDb21tZW50cz8NCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1p a2UNCg== --_000_4E1F6AAD24975D4BA5B16804296739436673D767TK5EX14MBXC285r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5n czsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0Fj ZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIy DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+WWVzLCBJ 4oCZZCBjb25zaWRlcmVkIOKAnG5vbmXigJ0sIGJ1dCByZWplY3RlZCBpdCBmb3Igc2V2ZXJhbCBy ZWFzb25zLiZuYnNwOyBGaXJzdCwg4oCcbm9uZeKAnSBpcyBhIEpXUyBhbGdvcml0aG0g4oCTIG5v dCBhIEpXRSBhbGdvcml0aG0uJm5ic3A7IEl0IGFsc28gbWVhbnMgc29tZXRoaW5nIGNvbXBsZXRl bHkgZGlmZmVyZW50IHRoYW4g4oCcbm9uZeKAnSB1c2VkIGluIHRoZSBKV1MgY2FzZSwgc28gaXTi gJlzDQogYmV0dGVyIG5vdCB0byBvdmVybG9hZCB0aGUgdmFsdWUgYW5kIGludHJvZHVjZSBjb25m dXNpb24sIGJvdGggZm9yIGh1bWFucywgYW5kIGluIGltcGxlbWVudGF0aW9ucy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gam9z ZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5BbnRob255IE5hZGFsaW48YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBK dWx5IDIwLCAyMDEyIDI6NTEgUE08YnI+DQo8Yj5Ubzo8L2I+IEppbSBTY2hhYWQ7IE1pa2UgSm9u ZXM7ICdNYW5nZXIsIEphbWVzIEgnOyBqb3NlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbam9zZV0gU3ltbWV0cmljIGVuY3J5cHRpb24gYW5kIGtleSBhZ3JlZW1lbnQgd2l0aCBh bmQgd2l0aG91dCBhIHNlcGFyYXRlIENNSzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj7igJxub25l4oCdIGlz IG5vdCBpbmZvcm1hdGl2ZSA8L3NwYW4+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2Rp bmdzO2NvbG9yOiMxRjQ5N0QiPkw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiBh dCBhbGwsIGF0IGxlYXN0IHRoZSDigJxkaXLigJ0gaXMgdGVsbGluZyB1cyBzb21ldGhpbmcNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+DQo8YSBocmVmPSJtYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnIj5qb3NlLWJvdW5jZXNA aWV0Zi5vcmc8L2E+IDxhIGhyZWY9Im1haWx0bzpbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9y Z10iPg0KW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddPC9hPiA8Yj5PbiBCZWhhbGYgT2Yg PC9iPkppbSBTY2hhYWQ8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdWx5IDIwLCAyMDEyIDI6 NDEgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM7ICdNYW5nZXIsIEphbWVzIEgnOyA8YSBo cmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtqb3NlXSBTeW1tZXRyaWMgZW5jcnlwdGlvbiBhbmQga2V5IGFncmVlbWVu dCB3aXRoIGFuZCB3aXRob3V0IGEgc2VwYXJhdGUgQ01LPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkl0IHNl ZW1zIGxpa2UgdGhlIGNvcnJlY3QgdGhpbmsgc2hvdWxkIGJlIOKAnGFsZ+KAnTrigJ1ub25l4oCd DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdE Ij5KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8YSBocmVmPSJtYWlsdG86am9zZS1i b3VuY2VzQGlldGYub3JnIj5qb3NlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Im1haWx0 bzpbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10iPg0KW21haWx0bzpqb3NlLWJvdW5jZXNA aWV0Zi5vcmddPC9hPiA8Yj5PbiBCZWhhbGYgT2YgPC9iPk1pa2UgSm9uZXM8YnI+DQo8Yj5TZW50 OjwvYj4gRnJpZGF5LCBKdWx5IDIwLCAyMDEyIDEwOjQ4IEFNPGJyPg0KPGI+VG86PC9iPiBNYW5n ZXIsIEphbWVzIEg7IDxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIj5qb3NlQGlldGYub3Jn PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2pvc2VdIFN5bW1ldHJpYyBlbmNyeXB0aW9u IGFuZCBrZXkgYWdyZWVtZW50IHdpdGggYW5kIHdpdGhvdXQgYSBzZXBhcmF0ZSBDTUs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+VGhlIHJlYXNvbiB3ZSBhbHJlYWR5IGhhdmUgIzQgKGRpcmVjdCB1c2Ugb2Yg dGhlIGFncmVlZC11cG9uIGtleSkgaXMgdGhhdCBpdCBzYXZlcyBhbiB1bm5lY2Vzc2FyeSBzZWNv bmQgZW5jcnlwdGlvbiBzdGVwIGluIHRoZSBzaW5nbGUgcmVjaXBpZW50IGNhc2UuJm5ic3A7IFRo ZXJlIGlzIGFsc28gc29tZSBzcGFjZSBhZHZhbnRhZ2UgYXMgd2VsbCwgYXMgeW91IHBvaW50DQog b3V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RG8geW91IGhhdmUgYW4g YWx0ZXJuYXRpdmUgc3ludGF4IHByb3Bvc2FsIHRvIOKAnGFsZ+KAnTrigJ1kaXLigJ0gZm9yIGV4 cHJlc3NpbmcgZGlyZWN0IHN5bW1ldHJpYyBlbmNyeXB0aW9uLCBzaW5jZSBhcHBhcmVudGx5IHlv dSBkb27igJl0IGxpa2UgdGhhdCBzeW50YXg/Jm5ic3A7IFNldmVyYWwgb3RoZXJzIGhhdmUgc2Fp ZCB0aGF0IGl0IHdvdWxkIHdvcmsgZm9yIHRoZW3igKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gTWFuZ2VyLCBKYW1lcyBIDQo8YSBocmVmPSJtYWlsdG86W21haWx0 bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tXSI+W21haWx0bzpKYW1lcy5ILk1hbmdl ckB0ZWFtLnRlbHN0cmEuY29tXTwvYT4NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVs eSAxOSwgMjAxMiAxMTo1NyBQTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lczsgPGEgaHJlZj0i bWFpbHRvOmpvc2VAaWV0Zi5vcmciPmpvc2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJFOiBbam9zZV0gU3ltbWV0cmljIGVuY3J5cHRpb24gYW5kIGtleSBhZ3JlZW1lbnQgd2l0 aCBhbmQgd2l0aG91dCBhIHNlcGFyYXRlIENNSzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+S2VlcCAjMTsgYWRkICMzOyBkcm9wICM0OyBhbmQgbWF5YmUgYWRkICMyLCBidXQgbm90IHdp dGggYW4g4oCcYWxn4oCdOuKAnWRpcuKAnSBoYWNrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4jNCAoa2V5IGFncmVlbWVudCBy ZXN1bHQgdXNlZCBhcyB0aGUgQ01LKSBzYXZlcyB+NTAgY2hhcnMgKG9yIDI0IGNoYXJzPykgY29t cGFyZWQgdG8gIzMsIGJ1dCBvbmx5IHdoZW4geW91IGhhdmUgdXNlZCBodW5kcmVkcyBvZiBjaGFy cyAocHJvYmFibHkgZG91YmUtYmFzZTY0LWVuY29kZWQpIHRvIHJlcHJlc2VudCBhbiBlcGhlbWVy YWwga2V5Lg0KIE5vdCBzdXJlIGl0IGlzIHdvcnRod2hpbGUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoZSDigJxhbGfigJ06 4oCdZGly4oCdIGhhY2sgaXMgbWFraW5nIFJpY2hhcmQgQmFybmVz4oCZcyBKU01TIGlkZWFzIGxv b2sgYmV0dGVyIGFuZCBiZXR0ZXIgKGlmIGl0IGRpZG7igJl0IGRyb3AgdGhlIGF1dGhlbnRpY2F0 ZWRBdHRyaWJ1dGVzIHBhcnQgb2YgQ01TKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUFVIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t QVUiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0 bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmciPmpvc2UtYm91bmNlc0BpZXRmLm9yZzwvYT4gPGEgaHJl Zj0ibWFpbHRvOlttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXSI+DQpbbWFpbHRvOmpvc2Ut Ym91bmNlc0BpZXRmLm9yZ108L2E+IDxiPk9uIEJlaGFsZiBPZiA8L2I+TWlrZSBKb25lczxicj4N CjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgMTkgSnVseSAyMDEyIDExOjA0IEFNPGJyPg0KPGI+VG86 PC9iPiA8YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwvYT48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gW2pvc2VdIFN5bW1ldHJpYyBlbmNyeXB0aW9uIGFuZCBrZXkgYWdy ZWVtZW50IHdpdGggYW5kIHdpdGhvdXQgYSBzZXBhcmF0ZSBDTUs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g bGFuZz0iRU4tQVUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5IaSBhbGwsPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ SeKAmXZlIGJlZW4gdGhpbmtpbmcgYWJvdXQgdHdvIG9mIG91ciBvcGVuIGlzc3Vlcywgd2hpY2gg YXJlIGNsb3NlbHkgcmVsYXRlZCwgYW5kIGFtIHdyaXRpbmcgdG8gbWFrZSBhIHByb3Bvc2FsIHRv IHJlc29sdmUgYm90aCBvZiB0aGVtLiZuYnNwOyBUaGUgaXNzdWVzIGFyZTo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4oMSkgQ3VycmVudGx5IHdlIHNwZWNpZnkgbWV0aG9kcyBmb3IgdXNpbmcgc3ltbWV0cmlj IGtleXMgdG8ga2V5IHdyYXAgYSBzZXBhcmF0ZSBDb250ZW50IE1hc3RlciBLZXkgKENNSyksIGJ1 dCBubyBtZWFucyBvZiB1c2luZyB0aGUgc3ltbWV0cmljIGtleSBhcyB0aGUgQ01LIGRpcmVjdGx5 LiZuYnNwOyBTb21lIGFwcGxpY2F0aW9ucyBuZWVkIHRoaXMgZnVuY3Rpb25hbGl0eSwNCiBib3Ro IGZvciBzaXplIGFuZCBmb3IgZWZmaWNpZW5jeSByZWFzb25zLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPigy KSBDdXJyZW50bHkgd2Ugc3BlY2lmeSBtZXRob2RzIGZvciBwZXJmb3JtaW5nIGtleSBhZ3JlZW1l bnQgYW5kIGRpcmVjdGx5IHVzaW5nIHRoZSByZXN1bHRpbmcga2V5IGFzIHRoZSBDTUsgdG8gcGVy Zm9ybSBibG9jayBlbmNyeXB0aW9uLCBidXQgbm8gbWVhbnMgb2YgdXNpbmcgdGhlIGFncmVlZC11 cG9uIGtleSB0byB3cmFwIGEgc2VwYXJhdGUgQ01LLiZuYnNwOyBXaGVuDQogZG9pbmcga2V5IGFn cmVlbWVudCBmb3IgbXVsdGlwbGUgcmVjaXBpZW50cywgYSBzZXBhcmF0ZSBDTUsgaXMgbmVlZGVk LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPlRodXMsIEkgcHJvcG9zZSB0aGF0IHdlIGRlZmluZSBtZXRob2Rz IGZvciBmaWxsaW5nIGluIGJvdGggb2YgdGhlIGhvbGVzIGFib3ZlLCBhcyBmb2xsb3dzOjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPihhKSBEZWZpbmUg4oCcYWxn4oCdOuKAnWRpcuKAnSAoZGlyZWN0KSB0byBt ZWFuIHRoYXQgdGhlIHN5bW1ldHJpYyBrZXkgaXMgZGlyZWN0bHkgdXNlZCBhcyB0aGUgQ01LIGZv ciB0aGUgYmxvY2sgZW5jcnlwdGlvbiBhbmQgaW50ZWdyaXR5IGNhbGN1bGF0aW9ucywgcmF0aGVy IHRoYW4gYXMgYSBrZXkgdG8gd3JhcCB0aGUgQ01LIHZhbHVlLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPihi KSBEZWZpbmUg4oCcYWxn4oCdOuKAnUVDREgtRVMmIzQzO0ExMjhLV+KAnSBhbmQg4oCcYWxn4oCd OuKAnUVDREgtRVMmIzQzO0EyNTZLV+KAnSB0byBtZWFuIHRoYXQgdGhlIHJlc3VsdCBvZiB0aGUg a2V5IGFncmVlbWVudCBpcyByZXNwZWN0aXZlbHkgdXNlZCBhcyB0aGUgMTI4IGJpdCBvciAyNTYg Yml0IEFFUyBLZXkgV3JhcCBrZXkgdG8gd3JhcCB0aGUgQ01LLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkRv aW5nIHRoaXMgd2lsbCBlbmFibGUgYWxsIGZvdXIgZmxhdm9ycywgd2hlcmVhcyB3ZeKAmXJlIGN1 cnJlbnRseSBtaXNzaW5nIDIgYW5kIDMgYmVsb3c6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+MS4mbmJzcDsgVGhlIHN5bW1ldHJp YyBrZXkgdXNlZCB0byB3cmFwIGEgc2VwYXJhdGUgQ01LPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Mi4mbmJzcDsgVGhlIHN5bW1l dHJpYyBrZXkgdXNlZCBhcyB0aGUgQ01LPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+My4mbmJzcDsgVGhlIGtleSBhZ3JlZW1lbnQg cmVzdWx0IHVzZWQgdG8gd3JhcCBhIHNlcGFyYXRlIENNSzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjQuJm5ic3A7IFRoZSBrZXkg YWdyZWVtZW50IHJlc3VsdCB1c2VkIGFzIHRoZSBDTUs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JIHJlY29n bml6ZSB0aGF0IGZsYXZvcnMgMiBhbmQgNCBhcmUgbm90IHVzYWJsZSB3aXRoIG11bHRpcGxlIHJl Y2lwaWVudHMgd2hlbiBtZXRob2RzIHN1Y2ggYXMgSldFIEpTT04gU2VyaWFsaXphdGlvbiBhcmUg dXNlZCAod2hpY2ggY291bnRzIG9uIGEgY29tbW9uIENNSyB2YWx1ZSB0byBlbmFibGUgYSBjb21t b24gY2lwaGVydGV4dCB2YWx1ZSkuJm5ic3A7IEEgbm90ZSB0bw0KIHRoYXQgZWZmZWN0IHdvdWxk IGJlIGFkZGVkIHRvIHRoZSBKV0EgZGVmaW5pdGlvbnMgb2Yg4oCcYWxn4oCdOuKAnEVDREgtRVPi gJ0gYW5kIOKAnGFsZ+KAnTrigJ1kaXLigJ0gYW5kIGl0IHdvdWxkIGJlIHBvaW50ZWQgb3V0IGlu IHRoZSBKV0UtSlMgc3BlYyB0aGF0IOKAnGFsZ+KAnSB2YWx1ZXMgdGhhdCB1dGlsaXplIGEgc2Vw YXJhdGUgQ01LIE1VU1QgYmUgdXNlZCB3aGVuIHRoZSBwbGFpbnRleHQgaXMgZW5jcnlwdGVkIHRv IG11bHRpcGxlIHJlY2lwaWVudHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Q29tbWVudHM/PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B16804296739436673D767TK5EX14MBXC285r_-- From Michael.Jones@microsoft.com Fri Jul 20 15:14:14 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C131711E8073 for ; Fri, 20 Jul 2012 15:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.78 X-Spam-Level: X-Spam-Status: No, score=-3.78 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulfWIb9WNEky for ; Fri, 20 Jul 2012 15:14:02 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id 28FDF21F8476 for ; Fri, 20 Jul 2012 15:13:56 -0700 (PDT) Received: from mail116-db3-R.bigfish.com (10.3.81.235) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Fri, 20 Jul 2012 22:14:53 +0000 Received: from mail116-db3 (localhost [127.0.0.1]) by mail116-db3-R.bigfish.com (Postfix) with ESMTP id 5C42540152; Fri, 20 Jul 2012 22:14:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -33 X-BigFish: VS-33(zz9371Ic85fh542M1418I1453M111aIzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail116-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail116-db3 (localhost.localdomain [127.0.0.1]) by mail116-db3 (MessageSwitch) id 1342822490560250_26337; Fri, 20 Jul 2012 22:14:50 +0000 (UTC) Received: from DB3EHSMHS012.bigfish.com (unknown [10.3.81.227]) by mail116-db3.bigfish.com (Postfix) with ESMTP id 8670A40007D; Fri, 20 Jul 2012 22:14:50 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS012.bigfish.com (10.3.87.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 20 Jul 2012 22:14:49 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0298.005; Fri, 20 Jul 2012 22:14:47 +0000 From: Mike Jones To: Jim Schaad , "jose@ietf.org" Thread-Topic: json-web-encryption -02 comments Thread-Index: Ac1bou6sddjZ9RUfROOHcwSTWeLOfgIGNEKAAE9LAUAAF/yTAABawEJQ Date: Fri, 20 Jul 2012 22:14:46 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436673D83D@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436657A0E4@TK5EX14MBXC283.redmond.corp.microsoft.com> <01f301cd63bb$c7188700$55499500$@augustcellars.com> <4E1F6AAD24975D4BA5B168042967394366739287@TK5EX14MBXC285.redmond.corp.microsoft.com> <02ec01cd6558$df733810$9e59a830$@augustcellars.com> In-Reply-To: <02ec01cd6558$df733810$9e59a830$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436673D83DTK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] json-web-encryption -02 comments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 22:14:14 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436673D83DTK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [mbj2] Replies inline... From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Wednesday, July 18, 2012 7:48 PM To: Mike Jones; jose@ietf.org Subject: RE: json-web-encryption -02 comments From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, July 18, 2012 8:44 AM To: Jim Schaad; jose@ietf.org Subject: RE: json-web-encryption -02 comments Replies inline... From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, July 16, 2012 6:30 PM To: Mike Jones; jose@ietf.org Subject: RE: json-web-encryption -02 comments In section 4 - There is an interesting question about the following: { alg:"none", enc:"AES128GCM" } This returns different results depending on which test you are using for de= termining if the header is a JWE or a JWS. This belies the last sentence i= n paragraph #2. Your example is an invalid input - either invalid as a JWS because it inclu= des the extra "enc" member or invalid as a JWE because "none" is not a vali= d encryption method. In either case, the input MUST be rejected. [JLS2] It is not clear to me that this is a correct statement. My implemen= tation does understand both alg and enc - I don't see anything that says th= ey must occur only in the correct contexts. This is also going to be effec= ted by the discussion of permit or deny for unknown headers that is being d= iscussed elsewhere. [mbj2] Fair enough - I'll make this more explicit so that it's clear that f= or a JWS only JWS fields must be used and similarly for JWE. Actually, you= r example provides good support for the current position that not-understoo= d values must be rejected. The sentence you are referring to reads: "Both methods will yield the same= result." I will change this to "Both methods will yield the same result f= or all valid inputs." [JLS2] So you are comfortable with the fact that different implementations = may respond with different error messages based on how they go about doing = the checking of what the structure is going to be. - Specifically if they = think that a signed or an encrypted message is going to come first. [mbj2] Yes. First, we're not specifying error messages - only accept/rejec= t behaviors. And whether the implementation uses "alg":"none" to start JWS= processing and rejects the input because of the invalid "enc" member or wh= ether it uses the presence of the "enc" member to start JWE processing and = rejects the input because of the invalid "alg" value, the result is still t= he same - rejecting the input. (By the way, I suspect you were thinking of the example above in the contex= t of enabling the option of direct symmetric encryption without using a CMK= , per Open Issue 6 in JWA, which is good. :) I plan to make a proposal on = syntax for that later today.) In Section 4.1.1 It is stated that the value of "alg" is case sensitive. It is stated that = it may be a URI. URIs say that there may be case insensitive portions of t= he URI value. This needs to be reconciled. The intent is still that these fields be compared in a case sensitive manne= r. These are not URIs you dereference - they are URIs used as identifiers.= We could add text something to the effect of "When a StringOrURI value is= a URI and the URI scheme includes portions that are matched in a case inse= nsitive manner, this specification requires those portions of the URI be ex= pressed using only lowercase characters, so a case-sensitive equality test = will be effective." I'd add similar text to the registry instructions for = these fields as well. Does that clarification work for you? [JLS2] by itself it does not deal with all of the possible issues. I don't= think it matters that they are for de-reference or not. The issue is the = same in all cases. However besides the issue of case, there are also quest= ions on using quoting characters, equivalent characters, utf8 encoding, I d= on't know if there is a problem with doing canonicalization of order of com= posite characters or not. [mbj2] I'll clarify this then to indicate that comparison is to be done on = the values provided as-is, with no escape processing or canonicalization pe= rformed of any kind (other than the escape processing involved in parsing t= he JSON string itself). Thanks again for helping to clarify the specs. -- Mike -- Mike From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, July 06, 2012 11:13 AM To: Jim Schaad; jose@ietf.org Subject: RE: json-web-encryption -02 comments Thanks once again. Responses inline... -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Thursday, June 07, 2012 11:56 AM To: jose@ietf.org; draft-ietf-jose-json-web-encryptio= n@tools.ietf.org Subject: json-web-encryption -02 comments Introduction 1. I would separate the introduction into two paragraphs. One to address = the general encryption issue and one to address the compact serialization i= ssues. This will allow for an easier addition/removal to deal with other s= erialization issues. I'm somewhat confused by this comment, as the introduction doesn't discuss = serialization. That concept isn't introduced until the "JWE Compact Serial= ization" term definition in Section 2 and the presentation of the compact s= erialization in Section 3. [JLS] And I am suggesting that the introduction SHOULD address the fact tha= t a serialization method is presented in this document. The process of enc= ryption and the process of serialization are separate things and both are c= overed in this document. This should be documented in the abstract. This should also be picked up in the abstract as well. 2. I find sentence #2 confusing since this document is defining how to do = the encryption process so we are not really dealing with pre-encrypted cont= ent which is what this appears to me to say. Like JWS, this sentence has been clarified to: It represents this content = using JavaScript Object Notation (JSON) data str= uctures. [JLS] I think that I find the concept that it represents the content as JSO= N to be weird, since the final formatting is actually dotted notation if yo= u are looking at the "compact encryption format" that was covered in this d= ocument. 3. What do you mean by the type of content being encrypted? This could ei= ther mean the format of the content (i.e. JSON vs Mime) or the type of cont= ent (i.e. a JSON token vs a JSON signature object). This now reads: The JWE cryptographic mechanisms encrypt and provide integ= rity protection for arbitrary sequences of bytes. [JLS] I find this confusing. A MAC also provides integrity protection and = that is in a different document. Section 3 1. Simple clarity s/confidentiality of the contents of the Plaintext/confi= dentiality of the Plaintext/ Done Section 4 - JWE Header 1. Do we think parsers can enforce the uniqueness requirement? See my response in the JWK comments 2. What does it mean to reject a JWE? Should it decrypt and say it is a b= ad decrypt or should it fail to decrypt? It should return an error and return no decrypted data [JLS] This response would eliminate that ability to do a stream based decod= e. That would return decrypted data and then return the error. Section 4.1.1 1. You should be constant about what you call the encryption key, master = key or JWE Encrypted key. A search and replace should be done to make them= constant. Now using the term Content Master Key (CMK) here. Note that the Content En= cryption Key (CMK) is distinct from (and derived from) the CMK. 2. Refer to the registry not to the document for the list of algorithms. Moved the document reference to be adjacent to the registry reference, sayi= ng that both apply Section 4.1.2 1. See comment 2 above Ditto 2. the encryption algorithm is not used to secure the cipher text. It is = used to produce the cipher text Corrected 3. Why does the enc algorithm not require the existence of a key for it's = use? Because the CEK is derived from the CMK, and so always exists [JLS] and how is that key known? Is a wrapped key always required in this = case. Section 4.1.4 2. The presence of this parameter MUST be specified for all content encryp= tion algorithms. It is, in JWA. Also clarified that it is REQUIRED with some "enc" algorith= ms. Section 4.1.5 1. See comment 2 above - alternate language would be say MUST be absent un= less otherwise specified by the algorithm. It is, in JWA. Also clarified that it is REQUIRED with some "alg" algorith= ms. [JLS] Then I assume that the following is legal { alg:"RSA1_5", epk:{...}, ...} 2. epk should talk about key agreement algorithms not a specific algorithm= . Done 3. Content of the key should be specified by the algorithm and not by this= document. Done Section 4.1.6 1. Should specify the use the "alg" registry for the zip parameter (in cas= e a new one comes into existence) and this algorithm should be registered a= s the only algorithm. This could be done, but it is counter to an explicit working group decision= to support only one compression algorithm. I'd be glad to do this if the = WG decides to open the door to the possibility of additional algorithms. [JLS] I do not feel that this means that it should not be registered. It = merely means that we will only register one, and we will make the bar very = high for the ability to register a second one. Otherwise this should be a = Boolean with a value of true. It either is or is not compressed. Section 4.1.7 1. Should make clear that this is the way of identifying what private key = is needed to decrypt the content. Added: this can be used to determine the private key needed to decrypt the = JWE 2. Should this be used? It implies that the decryptor needs to do the following: a) Get the keys b) For each key - i) Do I have the private key for this? ii) Does it match the algorithm? iii) Does it work? c) if no function keys found then ---??? Also, the decryptor might use "kid" and/or "use" parameters for deciding wh= ich key(s) to use. Obviously, if no applicable key can be located, the dec= ryption will fail. Section 4.1.8 1. See comment 1 above. Ditto Section 4.1.9 1. I would eliminate the (implicit) requirement that the certificate be va= lidated before decryption. There is no reason that a client should not be = able to decrypt a message to themselves if their certificate has been revok= ed or is expired. This is just a requirement at send time. What do others in the working group think of potentially relaxing this requ= irement? If we do relax it, what alternative language should be used? Section 4.1.11 1. I don't understand the format used here. The data could be either enco= ded as a string or an array of strings or something else that is a concaten= ated string form. I've added an example to clarify this. See http://tools.ietf.org/html/draf= t-ietf-jose-json-web-signature-03#appendix-B [JLS] That is nice that you have added an example. However this does not m= ean that the text should not be clarified. I think that you really want to= say that this field is an array of strings, each element in the array bein= g a base64url encoded certificate. The certificates are ordered such that = certificate i is issued by certificate i+1. Is it legal for a partial chain to be presented or must the full chain alwa= ys be presented? Is there a reason that you are not just using the PEM encoding in this loca= tion as well? If there is a requirement for having a chain of certificates in this locati= on, why is there not a requirement for having an array of certificates in t= he x5t case? As a recipient I should never need more than the EE certificate in order to= map from a public key to a private key. Other than letting me know what = the chain was that the sender used to validate my certificate, I don't know= what the reasoning behind sending the chain would be. 2. Why is this not base64url encoded given that all other locations are? So we're using a standard encoding for certificate chains [JLS] A standard encoding would be using the PEM string or using a CMS cert= s only. Changing the base64url to remove trailing characters is not reall= y an issue. Unless the new JavaScript CryptoAPIs (as an example) take a b= ase64 encoded certificate as input the user code is going to deal with the = encoding/decoding question anyway. 3. See comment 1 above Ditto Section 4.1.12 1. This is so underspecified that I would know how to go about using it. Any code that I wrote would therefore ignore it. Added: When used with a JWK, the "kid" value MAY be used to match a JWK= "kid" parameter value. [JLS] This does nothing to change my statement above. In fact it enforces = it. Section 4.1.13 1. The list of possible typ values should apparently include the mime regi= stry as well. This is neither in the value registry (which should probably= be setup to avoid collisions with mime types) or a URI. See the new Section 7.2 in JWS [JLS] I do not believe that mime types and subtypes are case insensitive va= lues in MIME itself. This needs to be resolved. Section 4.2 1. Should re-iterate the "if you don't know it then reject it" sentence he= re - it has been a long time since we have seen it. (Ditto for section 4.3) I understand why you're saying this, but we did say "Implementations MUST u= nderstand the entire contents of the header; otherwise, the JWE MUST be rej= ected" in the enclosing section introduction (Section 4), so I'm reluctant = to repeat it in 4.2 and especially reluctant to repeat it again so soon in = 4.3. Section 5 1. I disagree with the concept of using a key agree algorithm to create th= e CMK. Look at CMS to see how they handle key agree algorithms to create a key wrap key The key wrap key is unnecessary, as far as I can tell, at least when there'= s a single recipient. It results in an additional encryption step that see= ms to me to add no additional security. However, per James Manger's note and my response to it, I do understand tha= t value of having a CMK in the multiple recipients case. I've added this t= opic to the list of open issues for the working group to discuss. 2. In step 8 - when did you create the encoded JWE header? In step 9. :-) Yes, I'd already seen this and fixed it. 3. Separate the serialization format from the encryption algorithm. This = may just affect step 14. Done 4. Note previous discussion on only documenting AEAD algorithms I'm not sure what change you're asking for here? [JLS] I am asking that there only be one set of steps for doing this, and i= t is for AEAD algorithms. Section 6 1. Separate serialization from message decryption. If alternate serializa= tions are used then step 1 fails. Done 2. Note that you have imposed some additional restrictions on the JSE head= er in step three - specifically that no duplicate fields exist. This is no= t in the decryption process. It's input validation for the decryption process, just like step 2 was Section 7 1. If you are using the NIST KDF function, then the length of the output k= ey should really be included in the OtherInfo Again, per my earlier responses to you and Sean on this topic from your JWA= comments, since the CMK is randomly generated for each encryption, I belie= ve that the additional parameters add no security value. Adding a key leng= th would only make sense if we were going to use this same CMK to generate = other keys using the same Label ("Encryption" or "Integrity") but with a di= fferent key length. But we never will, so I believe that the parameter is = superfluous. Section 8.1 1. Refer to the registry not to the document (ditto for section 8.2) Done Section 11.1 1. Should there be an optional parameter which describes which serializati= on method is being used? This could be introduced if the working group adopts a second serialization= method, such as the JSON Serialization defined in draft-jones-json-web-enc= ryption-json-serialization, or one of the other candidates. However, a bet= ter approach might be to define a different media type value, such as appli= cation/jwe-js for the different serialization. Of course, if we have a pure JSON serialization, one could argue for just u= sing the application/json media type. 2. Check with IANA if you or the IESG should be listed under the contact s= ection. Will do --_000_4E1F6AAD24975D4BA5B16804296739436673D83DTK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[mbj2] Replies inline…

 

From: Jim Scha= ad [mailto:ietf@augustcellars.com]
Sent: Wednesday, July 18, 2012 7:48 PM
To: Mike Jones; jose@ietf.org
Subject: RE: json-web-encryption -02 comments

 

 

From: Mike Jon= es [mailto:Michael.Jon= es@microsoft.com]
Sent: Wednesday, July 18, 2012 8:44 AM
To: Jim Schaad; jose@ietf.org Subject: RE: json-web-encryption -02 comments

 

Replies inline…<= o:p>

 

From: Jim Scha= ad [mailto:ietf@augustcella= rs.com]
Sent: Monday, July 16, 2012 6:30 PM
To: Mike Jones; jose@ietf.org Subject: RE: json-web-encryption -02 comments

 

In section 4 –

There is an interestin= g question about the following:

{ alg:”none̶= 1;, enc:”AES128GCM” }

 

This returns different= results depending on which test you are using for determining if the heade= r is a JWE or a JWS.  This belies the last sentence in paragraph #2.

 

Your example is an inv= alid input – either invalid as a JWS because it includes the extra &#= 8220;enc” member or invalid as a JWE because “none” is no= t a valid encryption method.  In either case, the input MUST be reject= ed.

 

[JLS2] It is not clear= to me that this is a correct statement.  My implementation does under= stand both alg and enc – I don’t see anything that says they mu= st occur only in the correct contexts.  This is also going to be effected by the discussion of permit or deny for unknown heade= rs that is being discussed elsewhere.

 

[mbj2] Fair enough = 211; I’ll make this more explicit so that it’s clear that for a= JWS only JWS fields must be used and similarly for JWE.  Actually, yo= ur example provides good support for the current position that not-understood values must be rejected.

 

The sentence you are r= eferring to reads:  “Both methods will yield the same result.”  I will change this to “Bo= th methods will yield the same result for all valid inputs.= 221;

 

[JLS2] So you are comf= ortable with the fact that different implementations may respond with diffe= rent error messages based on how they go about doing the checking of what t= he structure is going to be.  – Specifically if they think that a signed or an encrypted message is going to come first= .

 

[mbj2] Yes.  Firs= t, we’re not specifying error messages – only accept/reject beh= aviors.  And whether the implementation uses “alg”:”= none” to start JWS processing and rejects the input because of the in= valid “enc” member or whether it uses the presence of the “enc” member to = start JWE processing and rejects the input because of the invalid “al= g” value, the result is still the same – rejecting the input.

 

(By the way, I suspect= you were thinking of the example above in the context of enabling the opti= on of direct symmetric encryption without using a CMK, per Open Issue 6 in = JWA, which is good. J  I plan to make a proposal on syntax for that l= ater today.)

 

In Section 4.1.1<= /o:p>

 

It is stated that the = value of “alg” is case sensitive.  It is stated that it ma= y be a URI.  URIs say that there may be case insensitive portions of t= he URI value.  This needs to be reconciled.

 

The intent is still th= at these fields be compared in a case sensitive manner.  These are not= URIs you dereference – they are URIs used as identifiers.  We c= ould add text something to the effect of “When a StringOrURI value is a URI and the URI scheme includes portions that are matched in a = case insensitive manner, this specification requires those portions of the = URI be expressed using only lowercase characters, so a case-sensitive equal= ity test will be effective.”  I’d add similar text to the registry instructions for these fields as well.&nb= sp; Does that clarification work for you?

 

[JLS2] by itself it do= es not deal with all of the possible issues.  I don’t think it m= atters that they are for de-reference or not.  The issue is the same i= n all cases.  However besides the issue of case, there are also questions on using quoting characters, equivalent characters, utf= 8 encoding, I don’t know if there is a problem with doing canonicaliz= ation of order of composite characters or not.

 

[mbj2] I’ll clar= ify this then to indicate that comparison is to be done on the values provi= ded as-is, with no escape processing or canonicalization performed of any k= ind (other than the escape processing involved in parsing the JSON string itself).

 

Thanks again for helpi= ng to clarify the specs.

 

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

 

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

 

From: Mike Jon= es [mailto:Michael.Jon= es@microsoft.com]
Sent: Friday, July 06, 2012 11:13 AM
To: Jim Schaad; jose@ietf.org Subject: RE: json-web-encryption -02 comments

 

Thanks once again.&= nbsp; Responses inline…

 

-----Original Message-----
From: Jim Schaad [mailto= :ietf@augustcellars.com]
Sent: Thursday, June 07, 2012 11:56 AM
To: jose@ietf.org; draft-ietf-jose-json-web-encryption@tools.ietf.org
Subject: json-web-encryption -02 comments

 

Introduction

 

1.  I would separate the introduction into t= wo paragraphs.  One to address the general encryption issue and one to= address the compact serialization issues.  This will allow for an eas= ier addition/removal to deal with other serialization issues.

 

I’m somewhat = confused by this comment, as the introduction doesn’t discuss seriali= zation.  That concept isn’t introduced until the “JWE Comp= act Serialization” term definition in Section 2 and the presentation of the compact serialization in Section 3.

 

[JLS] And I am sugg= esting that the introduction SHOULD address the fact that a serialization m= ethod is presented in this document.  The process of encryption and th= e process of serialization are separate things and both are covered in this document.  This should be documented in = the abstract.

 

This should also be= picked up in the abstract as well.

 

2.  I find sentence #2 confusing since this = document is defining how to do the encryption process so we are not really = dealing with pre-encrypted content which is what this appears to me to say.=

 

Like JWS, this sent= ence has been clarified to:  It represents this content using JavaScri= pt Object Notation (JSON) <xref target=3D"RFC4627"/> data s= tructures.

 

[JLS] I think that = I find the concept that it represents the content as JSON to be weird, sinc= e the final formatting is actually dotted notation if you are looking at th= e “compact encryption format” that was covered in this document.

 

3.  What do you mean by the type of content = being encrypted?  This could either mean the format of the content (i.= e. JSON vs Mime) or the type of content (i.e. a JSON token vs a JSON signat= ure object).

 

This now reads:&nbs= p; The JWE cryptographic mechanisms encrypt and provide integrity protectio= n for arbitrary sequences of bytes.

 

[JLS] I find this c= onfusing.  A MAC also provides integrity protection and that is in a d= ifferent document.

 

 

Section 3

 

1.  Simple clarity s/confidentiality of the = contents of the Plaintext/confidentiality of the Plaintext/

 

Done

 

Section 4 - JWE Header

 

1.  Do we think parsers can enforce the uniq= ueness requirement?

 

See my response in = the JWK comments

 

2.  What does it mean to reject a JWE? = Should it decrypt and say it is a bad decrypt or should it fail to decrypt= ?

 

It should return an= error and return no decrypted data

 

[JLS] This response= would eliminate that ability to do a stream based decode.  That would= return decrypted data and then return the error.

 

Section 4.1.1

 

1.  You should be constant about what  = you call the encryption key, master key or JWE Encrypted key.  A searc= h and replace should be done to make them constant.

 

Now using the term = Content Master Key (CMK) here.  Note that the Content Encryption Key (= CMK) is distinct from (and derived from) the CMK.

 

2.  Refer to the registry not to the documen= t for the list of algorithms.

 

Moved the document = reference to be adjacent to the registry reference, saying that both apply<= o:p>

 

Section 4.1.2

 

1. See comment 2 above

 

Ditto

 

2.  the encryption algorithm is not used to = secure the cipher text.  It is used to produce the cipher text

 

Corrected

 

3.  Why does the enc algorithm not require t= he existence of a key for it's use?

 

Because the CEK is = derived from the CMK, and so always exists

 

[JLS] and how is th= at key known?  Is a wrapped key always required in this case. 

 

Section 4.1.4

 

 

2.  The presence of this parameter MUST be s= pecified for all content encryption algorithms.

 

It is, in JWA. = ; Also clarified that it is REQUIRED with some “enc” algorithms= .

 

Section 4.1.5

 

1.  See comment 2 above - alternate language= would be say MUST be absent unless otherwise specified by the algorithm.

 

It is, in JWA. = ; Also clarified that it is REQUIRED with some “alg” algorithms= .

 

[JLS] Then I assume= that the following is legal

{ alg:”RSA1_5= ”, epk:{…}, …}

 

2.  epk should talk about key agreement algo= rithms not a specific algorithm.

 

Done

 

3.  Content of the key should be specified b= y the algorithm and not by this document.

 

Done

 

Section 4.1.6

 

1.  Should specify the use the "alg&quo= t; registry for the zip parameter (in case a new one comes into existence) = and this algorithm should be registered as the only algorithm.

 

This could be done,= but it is counter to an explicit working group decision to support only on= e compression algorithm.  I’d be glad to do this if the WG decid= es to open the door to the possibility of additional algorithms.

 

[JLS]  I do no= t feel that this means that it should not be registered.  It merely me= ans that we will only register one, and we will make the bar very high for = the ability to register a second one.  Otherwise this should be a Boolean with a value of true.  It either is or is no= t compressed.

 

Section 4.1.7

 

1.  Should make clear that this is the way o= f identifying what private key is needed to decrypt the content.=

 

Added: this can be = used to determine the private key needed to decrypt the JWE

 

2.  Should this be used?  It implies th= at the decryptor needs to do the

following:

a) Get the keys

b) For each key -

   i) Do I have the private key for thi= s?

   ii) Does it match the algorithm?

   iii) Does it work?

c) if no function keys found then ---???

 

Also, the decryptor= might use “kid” and/or “use” parameters for decidi= ng which key(s) to use.  Obviously, if no applicable key can be locate= d, the decryption will fail.

 

Section 4.1.8

 

1.  See comment 1 above.

 

Ditto

 

Section 4.1.9

 

1.  I would eliminate the (implicit) require= ment that the certificate be validated before decryption.  There is no= reason that a client should not be able to decrypt a message to themselves= if their certificate has been revoked or is expired.  This is just a requirement at send time.

 

What do others in t= he working group think of potentially relaxing this requirement?  If w= e do relax it, what alternative language should be used?<= /p>

 

Section 4.1.11

 

1.  I don't understand the format used here.=   The data could be either encoded as a string or an array of strings = or something else that is a concatenated string form.

 

I’ve added an= example to clarify this.  See http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-03#appendix-B=

 

[JLS] That is nice = that you have added an example.  However this does not mean that the t= ext should not be clarified.  I think that you really want to say that= this field is an array of strings, each element in the array being a base64url encoded certificate.  The certificates= are ordered such that certificate i is issued by certificate i+1.

 

Is it legal for a p= artial chain to be presented or must the full chain always be presented?

 

Is there a reason t= hat you are not just using the PEM encoding in this location as well?<= /o:p>

 

If there is a requi= rement for having a chain of certificates in this location, why is there no= t a requirement for having an array of certificates in the x5t case?

 

As a recipient I sh= ould never need more than the EE certificate in order to map from a public = key to a private key.   Other than letting me know what the chain= was that the sender used to validate my certificate, I don’t know what the reasoning behind sending the chain would be.

 

2.  Why is this not base64url encoded given = that all other locations are?

 

So we’re usin= g a standard encoding for certificate chains

 

[JLS] A standard en= coding would be using the PEM string or using a CMS certs only.   = ;Changing the base64url to remove trailing characters is not really an issu= e.   Unless the new JavaScript CryptoAPIs (as an example) take a base64 encoded certificate as input the user code is go= ing to deal with the encoding/decoding question anyway.

 

3. See comment 1 above

 

Ditto

 

Section 4.1.12

 

1.  This is so underspecified that I would k= now how to go about using it.

Any code that I wrote would therefore ignore it.<= o:p>

 

Added:   =   When used with a JWK, the “kid” value MAY be used to mat= ch a JWK “kid” parameter value.

 

[JLS] This does not= hing to change my statement above.  In fact it enforces it. 

 

Section 4.1.13

 

1.  The list of possible typ values should a= pparently include the mime registry as well.  This is neither in the v= alue registry (which should probably be setup to avoid collisions with mime= types) or a URI.

 

See the new Section= 7.2 in JWS

 

[JLS] I do not beli= eve that mime types and subtypes are case insensitive values in MIME itself= .  This needs to be resolved.

 

Section 4.2

 

1.  Should re-iterate the "if you don't= know it then reject it" sentence here - it has been a long time since= we have seen it.

 

(Ditto for section 4.3)

 

I understand why yo= u’re saying this, but we did say “Implementations MUST understa= nd the entire contents of the header; otherwise, the JWE MUST be rejected&#= 8221; in the enclosing section introduction (Section 4), so I’m reluctant to repeat it in 4.2 and especially reluctant to rep= eat it again so soon in 4.3.

 

Section 5

 

1.  I disagree with the concept of using a k= ey agree algorithm to create the

CMK.   Look at CMS to see how they hand= le key agree algorithms to create a

key wrap key

 

The key wrap key is= unnecessary, as far as I can tell, at least when there’s a single re= cipient.  It results in an additional encryption step that seems to me= to add no additional security.

 

However, per James = Manger’s note and my response to it, I do understand that value of ha= ving a CMK in the multiple recipients case.  I’ve added this top= ic to the list of open issues for the working group to discuss.

 

2.  In step 8 - when did you create the enco= ded JWE header?

 

In step 9. :-) = ; Yes, I’d already seen this and fixed it.

 

3.  Separate the serialization format from t= he encryption algorithm.  This may just affect step 14.

 

Done

 

4.  Note previous discussion on only documen= ting AEAD algorithms

 

I’m not sure = what change you’re asking for here?

 

[JLS] I am asking t= hat there only be one set of steps for doing this, and it is for AEAD algor= ithms. 

 

Section 6

 

1.  Separate serialization from message decr= yption.  If alternate serializations are used then step 1 fails.<= /o:p>

 

Done

 

2.  Note that you have imposed some addition= al restrictions on the JSE header in step three - specifically that no dupl= icate fields exist.  This is not in the decryption process.=

 

It’s input va= lidation for the decryption process, just like step 2 was=

 

Section 7

 

1.  If you are using the NIST KDF function, = then the length of the output key should really be included in the OtherInf= o

 

Again, per my earli= er responses to you and Sean on this topic from your JWA comments, since th= e CMK is randomly generated for each encryption, I believe that the additio= nal parameters add no security value.  Adding a key length would only make sense if we were going to use this sam= e CMK to generate other keys using the same Label (“Encryption”= or “Integrity”) but with a different key length.  But we = never will, so I believe that the parameter is superfluous.

 

Section 8.1

 

1.  Refer to the registry not to the documen= t (ditto for section 8.2)

 

Done

 

Section 11.1

 

1.  Should there be an optional parameter wh= ich describes which serialization method is being used?

 

This could be intro= duced if the working group adopts a second serialization method, such as th= e JSON Serialization defined in draft-jones-json-web-encryption-json-serial= ization, or one of the other candidates.  However, a better approach might be to define a different media type value= , such as application/jwe-js for the different serialization.

 

Of course, if we ha= ve a pure JSON serialization, one could argue for just using the applicatio= n/json media type.

 

2.  Check with IANA if you or the IESG shoul= d be listed under the contact section.

 

Will do<= /span>

 

--_000_4E1F6AAD24975D4BA5B16804296739436673D83DTK5EX14MBXC285r_-- From ietf@augustcellars.com Sat Jul 21 19:19:25 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E2321F853D for ; Sat, 21 Jul 2012 19:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azoGChqGaOoB for ; Sat, 21 Jul 2012 19:19:24 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 61C7E21F852A for ; Sat, 21 Jul 2012 19:19:24 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 39C3738EFF; Sat, 21 Jul 2012 19:20:24 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , Date: Sat, 21 Jul 2012 19:19:00 -0700 Message-ID: <005a01cd67b0$5b8e2640$12aa72c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac1no8DPsHtTwtBdSd++h2edICTnBA== Content-Language: en-us Subject: [jose] JSE/JWE algorithm factoring X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 02:19:25 -0000 Here is another proposal for the people who originally designed the system to take pot shots at, but one which I think might clean up a few things. If you look at signature algorithms, you need to specify the following items: 1. Where do you find the key to use 2. What is the public key operation you are using, and 3. What is the cryptographic hash function you are using. We now normally combine items 2 and 3 together to make a single signature algorithm. If you look at a complete MAC and at encryption systems, you need to specify a subset of the following items: 1. Where is the key you need to use. 2. What is the public key operation you are using. 3. What is the KDF function to go from the public key result to a symmetric key. 4. What is the key wrap algorithm to go from a symmetric key to a symmetric key 5. What is the content algorithm being used with the symmetric key. For the purposes of this discussion, I am ignoring the issues with doing a composite AEAD algorithm and assuming that is atomically specified. If we then look at the different scenarios that need to be supported we do the following: a) Directly encrypt or MAC with a known symmetric key: items 2, 3 and 4 are omitted, item 5 is specified and item 1 is optionally specified. b) Use known symmetric key and random CEK: items 2 and 3 are omitted, items 4 and 5 are specified, item 1 is optionally specified c) Use a key agreement algorithm but not a random CEK: Items 4 is omitted. Items 2, 3, and 5 are specified, item 1 is optionally specified. d) For a traditional key transport algorithm: items 3 and 4 are omitted. Items 2 and 5 are specified and items 1 is optionally specified. e) For RSA-KEM with a random CEK: Items 2, 3, 4 and 5 are specified and item 1 is optionally omitted. You also need to look at the data fields that need to be provided. For signature algorithms, the output field is the signature value itself. For the complete MAC/Encryption case you have three different fields: 1. The encrypted content field 2. The random CEK encrypted some how 3. The authentication value to be used. Using the same scenarios as above, the encrypted content is present for encryption cases and not for MAC cases a) Only field 3 is present b) Both data fields 2 and 3 are present c) Only field 3 is present d) Both data fields 2 and 3 are present e) There are two different versions of 2 present (one for a completely random value and one for the random CEK) as well as field 3. Ok - that is the background information, now for the proposal: 1) We specify that if algorithm 2 requires an algorithm 3 then they will be specified together as a single algorithm name 2) Any algorithm name not required is omitted. The steps of how to process will deal with the case of an omitted name. The only place where this presents some interesting issues is when looking for a key to be used and deciding what type of key is going to be needed. There will be a couple of extra steps over what is currently needed as more than one field will need to be examined before you know if you are looking for a public key algorithm or a symmetric key algorithm. 3) Each of the algorithms 2, 4 and 5 will be specified as their own distinct field names. Algorithm name 2 will be overloaded by additionally specifying a signature algorithm in this field. 4) Algorithm 5 will specify both MAC and content encryption algorithm. 5) Any encryption/MAC algorithm which does not use a random CEK value is not appropriate for use in cases where there is going to be more than one recipient. 6) How do I figure out if it is signed, MAC-ed or encrypted? If content algorithm is absent, then treat as signed. If content algorithm field contains a MAC algorithm treat as MAC-ed. If content algorithm contains an encryption algorithm treat as encrypted. Otherwise treat as unknown object. There is an issue that needs to be dealt with for the dot notation that is currently being used. If you have a full MAC item (with a random CEK) then the current dot structure is insufficient to handle that case. I can see a couple of possible answers: 1) Allow MACs to have either 2 or 3 dots depending on the situation. 2) Allow the number of dotted fields to vary for all types depending on the algorithms being used. This means that there could be anywhere from 2 to 4 dots depending on the set of items selected. 3) Make all of them fixed at 3 dots and take the hit of the extra character in some cases. 4) Leave signed at 2 dots, but make MAC and encryption always be 3 dots. An example of each scenario above: {"pkAlg":"RSAv1.5-SHA256"} {"cAlg":"HMAC-SHA256"} {"cAlg":"HMAC-SHA256", "cwAlg":"AES-WRAP-256"} {"pkAlg":"ECDH-256-KDF1", "cAlg":"HMAC-SHA256"} {"pkAlg":"ECDH-256-KDF1","cwAlg":"AES-WRAP-256","cAlg":"AES128"} {"pkAlg":"RSAv1.5","cAlg":"AES128"} {"pkAlg":"RSA-KEM-KDF1","cwAlg":"AES-WRAP-256","cAlg":"HMAC-SHA256"} I am completely unwedded to the names of anything in the examples, I just choose some simple short names that are representative and easy for me to remember: pkAlg - public key algorithm - either a signature algorithm, a key agreement/key derivation pair or a key transport algorithm (also a key transport + key derivation for RSA-KEM) cwAlg - key wrap algorithm cAlg - content algorithm - either an AEAD algorithm or a MAC algorithm jim From ietf@augustcellars.com Sat Jul 21 19:58:26 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1909421F846F for ; Sat, 21 Jul 2012 19:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.522 X-Spam-Level: X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4lcTH0H10bS for ; Sat, 21 Jul 2012 19:58:25 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 3035321F846D for ; Sat, 21 Jul 2012 19:58:25 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 665B638F07 for ; Sat, 21 Jul 2012 19:59:25 -0700 (PDT) From: "Jim Schaad" To: References: <005a01cd67b0$5b8e2640$12aa72c0$@augustcellars.com> In-Reply-To: <005a01cd67b0$5b8e2640$12aa72c0$@augustcellars.com> Date: Sat, 21 Jul 2012 19:58:01 -0700 Message-ID: <006401cd67b5$cee29630$6ca7c290$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFWdvosCN5oUN1jbpGPIyDC6pDmHJgifQ5g Content-Language: en-us Subject: Re: [jose] JSE/JWE algorithm factoring X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 02:58:26 -0000 After having sent this message and while mowing my driveway, I did come up with an additional option for the dotted notation question. One could restrict the use of MAC to a small subset of the scenarios below (basically just the first) and the number of data fields would then be the same as the current document since that is currently the only option that is permitted. This would require a change in the algorithm descriptions, but not in the dotted notation. Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Jim Schaad > Sent: Saturday, July 21, 2012 7:19 PM > To: 'Mike Jones'; jose@ietf.org > Subject: [jose] JSE/JWE algorithm factoring > > > > Here is another proposal for the people who originally designed the system > to take pot shots at, but one which I think might clean up a few things. > > If you look at signature algorithms, you need to specify the following > items: > > 1. Where do you find the key to use > 2. What is the public key operation you are using, and > 3. What is the cryptographic hash function you are using. > > We now normally combine items 2 and 3 together to make a single signature > algorithm. > > > If you look at a complete MAC and at encryption systems, you need to > specify > a subset of the following items: > > 1. Where is the key you need to use. > 2. What is the public key operation you are using. > 3. What is the KDF function to go from the public key result to a symmetric > key. > 4. What is the key wrap algorithm to go from a symmetric key to a symmetric > key > 5. What is the content algorithm being used with the symmetric key. > > For the purposes of this discussion, I am ignoring the issues with doing a > composite AEAD algorithm and assuming that is atomically specified. > > If we then look at the different scenarios that need to be supported we do > the following: > > a) Directly encrypt or MAC with a known symmetric key: items 2, 3 and 4 are > omitted, item 5 is specified and item 1 is optionally specified. > b) Use known symmetric key and random CEK: items 2 and 3 are omitted, > items > 4 and 5 are specified, item 1 is optionally specified > c) Use a key agreement algorithm but not a random CEK: Items 4 is omitted. > Items 2, 3, and 5 are specified, item 1 is optionally specified. > d) For a traditional key transport algorithm: items 3 and 4 are omitted. > Items 2 and 5 are specified and items 1 is optionally specified. > e) For RSA-KEM with a random CEK: Items 2, 3, 4 and 5 are specified and item > 1 is optionally omitted. > > You also need to look at the data fields that need to be provided. For > signature algorithms, the output field is the signature value itself. For > the complete MAC/Encryption case you have three different fields: > > 1. The encrypted content field > 2. The random CEK encrypted some how > 3. The authentication value to be used. > > Using the same scenarios as above, the encrypted content is present for > encryption cases and not for MAC cases > > a) Only field 3 is present > b) Both data fields 2 and 3 are present > c) Only field 3 is present > d) Both data fields 2 and 3 are present > e) There are two different versions of 2 present (one for a completely > random value and one for the random CEK) as well as field 3. > > Ok - that is the background information, now for the proposal: > > 1) We specify that if algorithm 2 requires an algorithm 3 then they will be > specified together as a single algorithm name > 2) Any algorithm name not required is omitted. The steps of how to process > will deal with the case of an omitted name. The only place where this > presents some interesting issues is when looking for a key to be used and > deciding what type of key is going to be needed. There will be a couple of > extra steps over what is currently needed as more than one field will need > to be examined before you know if you are looking for a public key algorithm > or a symmetric key algorithm. > 3) Each of the algorithms 2, 4 and 5 will be specified as their own > distinct field names. Algorithm name 2 will be overloaded by additionally > specifying a signature algorithm in this field. > 4) Algorithm 5 will specify both MAC and content encryption algorithm. > 5) Any encryption/MAC algorithm which does not use a random CEK value is > not appropriate for use in cases where there is going to be more than one > recipient. > 6) How do I figure out if it is signed, MAC-ed or encrypted? If content > algorithm is absent, then treat as signed. If content algorithm field > contains a MAC algorithm treat as MAC-ed. If content algorithm contains an > encryption algorithm treat as encrypted. Otherwise treat as unknown > object. > > There is an issue that needs to be dealt with for the dot notation that is > currently being used. If you have a full MAC item (with a random CEK) then > the current dot structure is insufficient to handle that case. I can see a > couple of possible answers: > > 1) Allow MACs to have either 2 or 3 dots depending on the situation. > 2) Allow the number of dotted fields to vary for all types depending on the > algorithms being used. This means that there could be anywhere from 2 to 4 > dots depending on the set of items selected. > 3) Make all of them fixed at 3 dots and take the hit of the extra character > in some cases. > 4) Leave signed at 2 dots, but make MAC and encryption always be 3 dots. > > An example of each scenario above: > > {"pkAlg":"RSAv1.5-SHA256"} > {"cAlg":"HMAC-SHA256"} > {"cAlg":"HMAC-SHA256", "cwAlg":"AES-WRAP-256"} > {"pkAlg":"ECDH-256-KDF1", "cAlg":"HMAC-SHA256"} > {"pkAlg":"ECDH-256-KDF1","cwAlg":"AES-WRAP-256","cAlg":"AES128"} > {"pkAlg":"RSAv1.5","cAlg":"AES128"} > {"pkAlg":"RSA-KEM-KDF1","cwAlg":"AES-WRAP-256","cAlg":"HMAC- > SHA256"} > > I am completely unwedded to the names of anything in the examples, I just > choose some simple short names that are representative and easy for me to > remember: > pkAlg - public key algorithm - either a signature algorithm, a key > agreement/key derivation pair or a key transport algorithm (also a key > transport + key derivation for RSA-KEM) > cwAlg - key wrap algorithm > cAlg - content algorithm - either an AEAD algorithm or a MAC algorithm > > jim > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From James.H.Manger@team.telstra.com Sun Jul 22 19:10:06 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95CBF21F857D for ; Sun, 22 Jul 2012 19:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oc6qEykZTh7I for ; Sun, 22 Jul 2012 19:10:06 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 9D69F21F855F for ; Sun, 22 Jul 2012 19:10:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,636,1336312800"; d="scan'208";a="81952145" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 23 Jul 2012 12:10:01 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6780"; a="78152292" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipccni.tcif.telstra.com.au with ESMTP; 23 Jul 2012 12:09:59 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Mon, 23 Jul 2012 12:09:58 +1000 From: "Manger, James H" To: Jim Schaad , "jose@ietf.org" Date: Mon, 23 Jul 2012 12:09:57 +1000 Thread-Topic: [jose] JSE/JWE algorithm factoring Thread-Index: Ac1no8DPsHtTwtBdSd++h2edICTnBAAzFYxQ Message-ID: <255B9BB34FB7D647A506DC292726F6E114F7E0FFED@WSMSG3153V.srv.dir.telstra.com> References: <005a01cd67b0$5b8e2640$12aa72c0$@augustcellars.com> In-Reply-To: <005a01cd67b0$5b8e2640$12aa72c0$@augustcellars.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] JSE/JWE algorithm factoring X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 02:10:06 -0000 SmltLA0KDQo+IEhlcmUgaXMgYW5vdGhlciBwcm9wb3NhbCBmb3IgdGhlIHBlb3BsZSB3aG8gb3Jp Z2luYWxseSBkZXNpZ25lZCB0aGUNCj4gc3lzdGVtIHRvIHRha2UgcG90IHNob3RzIGF0LCBidXQg b25lIHdoaWNoIEkgdGhpbmsgbWlnaHQgY2xlYW4gdXAgYQ0KPiBmZXcgdGhpbmdzLg0KPiDigKYN Cj4geyJwa0FsZyI6IlJTQXYxLjUtU0hBMjU2In0NCj4geyJjQWxnIjoiSE1BQy1TSEEyNTYifQ0K PiB7ImNBbGciOiJITUFDLVNIQTI1NiIsICJjd0FsZyI6IkFFUy1XUkFQLTI1NiJ9DQo+IHsicGtB bGciOiJFQ0RILTI1Ni1LREYxIiwgImNBbGciOiJITUFDLVNIQTI1NiJ9DQo+IHsicGtBbGciOiJF Q0RILTI1Ni1LREYxIiwiY3dBbGciOiJBRVMtV1JBUC0yNTYiLCJjQWxnIjoiQUVTMTI4In0NCj4g eyJwa0FsZyI6IlJTQXYxLjUiLCJjQWxnIjoiQUVTMTI4In0NCj4geyJwa0FsZyI6IlJTQS1LRU0t S0RGMSIsImN3QWxnIjoiQUVTLVdSQVAtMjU2IiwiY0FsZyI6IkhNQUMtU0hBMjU2In0NCg0KDQpT byB0byBwcm9jZXNzIHN1Y2ggYSB2YWx1ZSwgdGhlIHJlY2lwaWVudDoNCiogTG9va3MgZm9yIHRo ZSBwcmVzZW5jZSBvciBhYnNlbmNlIG9mIDMgaGVhZGVyIGZpZWxkcyAoInBrQWxnIiwgImNBbGci LCAiY3dBbGciKSDigJQgZ2l2aW5nIDggcG9zc2libGUgY29tYmluYXRpb25zDQoqIERldGVybWlu ZXMgaWYgdGhlICJjQWxnIiB2YWx1ZSBpcyBhIE1BQyBvciBlbmNyeXB0aW9uIGFsZ29yaXRobSBv ciB1bnJlY29nbml6ZWQg4oCUIHRyaXBsaW5nIHRoZSA0IGNvbWJpbmF0aW9ucyB3aGVuICJjQWxn IiBpcyBwcmVzZW50DQoNClRoYXQgZ2l2ZXMgMTYgcG9zc2libGUgIm1vZGVzIi4gVGhlIGNvZGUg Y2FuIG5vdyB1c2UgYSBzd2l0Y2ggc3RhdGVtZW50IGZvciB0aGUgbW9kZS1zcGVjaWZpYyBwcm9j ZXNzaW5nLiBCZXR0ZXIgaG9wZSB0aGF0IGZ1dHVyZSBtb2RlcyBmaXQgd2l0aGluIHRoaXMgbW9k ZWw6IGVnIGEgY2hlY2tzdW0gbWlnaHQgaGF2ZSB0byBwcmV0ZW5kIHRvIGJlIGEgTUFDIGFsZ29y aXRobTsgbW9kZSB0aGF0IGp1c3QgY29tcHJlc3NlcyBkYXRhICh1aG1t4oCmKS4NCg0KV291bGRu J3QgaXQgYmUgc2ltcGxlciB0byBoYXZlIGEgc3BlY2lmaWMgZmllbGQgdG8gaW5kaWNhdGUgdGhl IG1vZGU/IEVhY2ggbW9kZSBkZWZpbmVzIGhvdyBtYW55IGRvdC1zZXBhcmF0ZWQgc2VnbWVudHMg dGhlcmUgYXJlLCB3aGF0IHRoZXkgaG9sZCwgYW5kIHdoaWNoIG90aGVyIGhlYWRlciBmaWVsZHMg aW5kaWNhdGUgdGhlIGFsZ3MgdGhlIG1vZGUgdXNlcy4gSWYgeW91IGRvbid0IHJlY29nbml6ZSB0 aGUgbW9kZSB5b3UgY2Fubm90IHByb2Nlc3MgdGhlIG1lc3NhZ2UuDQoNCkV4YW1wbGVzOg0KeyJ0 Ijoic2lnIiwgInNpZyI6IlJTQXYxLjUtU0hBMjU2In0NCnsidCI6Im1hYyIsICJtYWMiOiJITUFD LVNIQTI1NiJ9DQp7InQiOiJ3cmFwLW1hYyIsICJtYWMiOiJITUFDLVNIQTI1NiIsICJ3cmFwIjoi QUVTLVdSQVAtMjU2In0NCnsidCI6ImFncmVlLW1hYyIsICJrYWciOiJFQ0RILTI1Ni1LREYxIiwg Im1hYyI6IkhNQUMtU0hBMjU2In0NCnsidCI6ImFncmVlLXdyYXAtZW5jIiwgImthZyI6IkVDREgt MjU2LUtERjEiLCAid3JhcCI6IkFFUy1XUkFQLTI1NiIsICJlbmMiOiJBRVMxMjgifQ0KeyJ0Ijoi dHJhbnNwb3J0LWVuYyIsICJrdCI6IlJTQXYxLjUiLCAiZW5jIjoiQUVTMTI4In0NCnsidCI6InRy YW5zcG9ydC13cmFwLW1hYyIsICJrdCI6IlJTQS1LRU0tS0RGMSIsICJ3cmFwIjoiQUVTLVdSQVAt MjU2IiwgIm1hYyI6IkhNQUMtU0hBMjU2In0NCg0KV2FudCBhIG1vZGUgdGhhdCBqdXN0IGNvbXBy ZXNzZXMgZGF0YT8gRGVmaW5lICJ0IjoiemlwIi4NCldhbnQgYSBNQUMgbW9kZSB3aXRoIHRoZSBz YW1lIHN0cnVjdHVyZSBhcyAidCI6Im1hYyIgYnV0IHdoZXJlIHVucmVjb2duaXplZCBmaWVsZHMg TVVTVCBiZSB1bmRlcnN0b29kPyBEZWZpbmUgInQiOiJtYWMhIi4NCg0KLS0NCkphbWVzIE1hbmdl cg0K From James.H.Manger@team.telstra.com Sun Jul 22 20:27:51 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503EE21F8691 for ; Sun, 22 Jul 2012 20:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lo77+7MOWpxm for ; Sun, 22 Jul 2012 20:27:50 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6F521F8624 for ; Sun, 22 Jul 2012 20:27:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,637,1336312800"; d="scan'208";a="82172960" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipocni.tcif.telstra.com.au with ESMTP; 23 Jul 2012 13:27:49 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6780"; a="78121059" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcbni.tcif.telstra.com.au with ESMTP; 23 Jul 2012 13:27:48 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Mon, 23 Jul 2012 13:27:48 +1000 From: "Manger, James H" To: Mike Jones , "jose@ietf.org" Date: Mon, 23 Jul 2012 13:27:47 +1000 Thread-Topic: [jose] Symmetric encryption and key agreement with and without a separate CMK Thread-Index: Ac1lSl6h5FqQOPItQGiuikwTjR9QtgA3xg5gAB1yjFAAdkQbIA== Message-ID: <255B9BB34FB7D647A506DC292726F6E114F7E101BC@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739436673A0B7@TK5EX14MBXC285.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F7E0F747@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436673D2D6@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436673D2D6@TK5EX14MBXC285.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] Symmetric encryption and key agreement with and without a separate CMK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 03:27:51 -0000 TWlrZSwNCg0KPiAoYSkgRGVmaW5lIOKAnGFsZ+KAnTrigJ1kaXLigJ0gKGRpcmVjdCkgdG8gbWVh biB0aGF0IHRoZQ0KPiAgICAgc3ltbWV0cmljIGtleSBpcyBkaXJlY3RseSB1c2VkIGFzIHRoZSBD TUsgZm9yDQo+ICAgICB0aGUgYmxvY2sgZW5jcnlwdGlvbiBhbmQgaW50ZWdyaXR5IGNhbGN1bGF0 aW9ucywNCj4gICAgIHJhdGhlciB0aGFuIGFzIGEga2V5IHRvIHdyYXAgdGhlIENNSyB2YWx1ZS4N Cg0KPiBEbyB5b3UgaGF2ZSBhbiBhbHRlcm5hdGl2ZSBzeW50YXggcHJvcG9zYWwgdG8gImFsZyI6 ImRpciINCj4gZm9yIGV4cHJlc3NpbmcgZGlyZWN0IHN5bW1ldHJpYyBlbmNyeXB0aW9uLA0KPiBz aW5jZSBhcHBhcmVudGx5IHlvdSBkb27igJl0IGxpa2UgdGhhdCBzeW50YXg/DQo+IFNldmVyYWwg b3RoZXJzIGhhdmUgc2FpZCB0aGF0IGl0IHdvdWxkIHdvcmsgZm9yIHRoZW3igKYNCg0KDQpUaGUg Y3VycmVudCBKV1MvSldFIG1vZGVsIHB1dHMgdGhlICJwcmltYXJ5IiBhbGdvcml0aG0gaW4gdGhl ICJhbGciIGZpZWxkLiBZb3UgZGV0ZXJtaW5lIGhvdyB0byBwcm9jZXNzIHRoZSBtZXNzYWdlIGJ5 IGRldGVybWluaW5nIHdoYXQgc29ydCBvZiBhbGdvcml0aG0gdGhlICJhbGciIHZhbHVlIGlzLg0K V2l0aCB0aGlzIG1vZGVsLCBkaXJlY3QgZW5jcnlwdGlvbiB3aXRoIGEgcHJlLWVzdGFibGlzaGVk IHN5bW1ldHJpYyBrZXkgc2hvdWxkIHB1dCB0aGUgQUVBRCBhbGdvcml0aG0gaW4gdGhlICJhbGci IGZpZWxkLiBUaGF0IGlzLCByZW5hbWUgdGhlICJlbmMiIGZpZWxkIHRvICJhbGciIHdoZW4gZG9p bmcgZW5jcnlwdGlvbiBkaXJlY3RseSB3aXRoIGEgcHJlLWVzdGFibGlzaGVkIHN5bW1ldHJpYyBr ZXkuDQpFeGFtcGxlOiB7ImFsZyI6IkEyNTZHQ00iLCDigKZ9DQoNCg0KSSB0aGluayBpdCB3b3Vs ZCBiZSBiZXR0ZXIgdG8gaGF2ZSBhIGRlZGljYXRlZCBmaWVsZCAoZWcgInQiKSB0byBzcGVjaWZ5 IHRoZSBtb2RlIChlZyAidCI6InNpZyIgZm9yIHdpdGggYSBkaWdpdGFsbHkgc2lnbmVkIG1lc3Nh Z2UpLiBGb3IgZGlyZWN0IHN5bW1ldHJpYyBlbmNyeXB0aW9uIGRlZmluZSBhIG5ldyBtb2RlIHZh bHVlLCBlZyAidCI6ImVuYyIuIA0KRXhhbXBsZTogeyJ0OiJlbmMiLCAiZW5jIjoiQTI1NkdDTSIs IOKApn0NCg0KLS0NCkphbWVzIE1hbmdlcg0K From ietf@augustcellars.com Sun Jul 22 22:07:00 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A74421F86C8 for ; Sun, 22 Jul 2012 22:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.45 X-Spam-Level: X-Spam-Status: No, score=-3.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lx4kV9O-jji7 for ; Sun, 22 Jul 2012 22:06:59 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD0A21F86C5 for ; Sun, 22 Jul 2012 22:06:59 -0700 (PDT) Received: from Tobias (50-39-234-129.bvtn.or.frontiernet.net [50.39.234.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 197692CA1F; Sun, 22 Jul 2012 22:06:57 -0700 (PDT) From: "Jim Schaad" To: "'Manger, James H'" , References: <005a01cd67b0$5b8e2640$12aa72c0$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F7E0FFED@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F7E0FFED@WSMSG3153V.srv.dir.telstra.com> Date: Sun, 22 Jul 2012 22:05:32 -0700 Message-ID: <008301cd6890$ca175b00$5e461100$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFWdvosCN5oUN1jbpGPIyDC6pDmHAFwkqzEmBir5AA= Content-Language: en-us Subject: Re: [jose] JSE/JWE algorithm factoring X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 05:07:00 -0000 > -----Original Message----- > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > Sent: Sunday, July 22, 2012 7:10 PM > To: Jim Schaad; jose@ietf.org > Subject: RE: [jose] JSE/JWE algorithm factoring >=20 > Jim, >=20 > > Here is another proposal for the people who originally designed the > > system to take pot shots at, but one which I think might clean up a > > few things. > > > > {"pkAlg":"RSAv1.5-SHA256"} > > {"cAlg":"HMAC-SHA256"} > > {"cAlg":"HMAC-SHA256", "cwAlg":"AES-WRAP-256"} > > {"pkAlg":"ECDH-256-KDF1", "cAlg":"HMAC-SHA256"} > > {"pkAlg":"ECDH-256-KDF1","cwAlg":"AES-WRAP-256","cAlg":"AES128"} > > {"pkAlg":"RSAv1.5","cAlg":"AES128"} > > {"pkAlg":"RSA-KEM-KDF1","cwAlg":"AES-WRAP-256","cAlg":"HMAC- > SHA256"} >=20 >=20 > So to process such a value, the recipient: > * Looks for the presence or absence of 3 header fields ("pkAlg", = "cAlg", > "cwAlg") giving 8 possible combinations > * Determines if the "cAlg" value is a MAC or encryption algorithm or > unrecognized tripling the 4 combinations when "cAlg" is present >=20 > That gives 16 possible "modes". The code can now use a switch = statement for > the mode-specific processing. Better hope that future modes fit within = this > model: eg a checksum might have to pretend to be a MAC algorithm; mode > that just compresses data (uhmm ). If this is the way that you are going to define modes then you have = vastly understated the number of modes that might exist. =20 5 types of pkAlg (sig, key agree, key transport, RSA-KEM like, unknown, = absent) 3 types of cwAlg (known, unknown, absent) 4 types of cAlg (encryption, mac, unknown, absent) 5 or 6 ways to retrieve the key information Total =3D somewhere around 300? However some of the things that you add are binary - either you = understand and do it or you don't. Adding Zip does not double the = number of modes, just the number of test cases if you are being = exhaustive in testing. In practice however the number of test cases = that need to be added is dependent on the number of code paths that are = modified not on the complete possible tree of values. >=20 > Wouldn't it be simpler to have a specific field to indicate the mode? = Each > mode defines how many dot-separated segments there are, what they = hold, > and which other header fields indicate the algs the mode uses. If you = don't > recognize the mode you cannot process the message. I agree that having modes can be useful, but I am not sure that it is = going to help in this situation. The code for dealing with the above is = actually very simple logic if (pkAlg exists) { if (pkAlg is a signature algorithm) do signature processing and = return else if (pkAlg is a known algorithm) { find the key process the value } Else throw an error } If (cwAlg exists ) { If unknown algorithm throw error If no key then find the key Process the value } If (cAlg exists) { If unknown alg then throw error If no key known then find the key If encryption alg then process as encryption and return If mac alg then process as mac and return } Throw an error There are a large number of test cases, but that is different than = modes. Some of the modes currently make no sense. Why have a cwAlg and = no cAlg? We are not currently in the business of transporting keys for = later use. It might make sense later but not now. If the cAlg is = unknown - who cares about the rest of the algs as you can't go anywhere = with it anyway. >=20 > Examples: > {"t":"sig", "sig":"RSAv1.5-SHA256"} > {"t":"mac", "mac":"HMAC-SHA256"} > {"t":"wrap-mac", "mac":"HMAC-SHA256", "wrap":"AES-WRAP-256"} > {"t":"agree-mac", "kag":"ECDH-256-KDF1", "mac":"HMAC-SHA256"} > {"t":"agree-wrap-enc", "kag":"ECDH-256-KDF1", "wrap":"AES-WRAP-256", > "enc":"AES128"} {"t":"transport-enc", "kt":"RSAv1.5", "enc":"AES128"} > {"t":"transport-wrap-mac", "kt":"RSA-KEM-KDF1", "wrap":"AES-WRAP-256", > "mac":"HMAC-SHA256"} >=20 > Want a mode that just compresses data? Define "t":"zip". > Want a MAC mode with the same structure as "t":"mac" but where > unrecognized fields MUST be understood? Define "t":"mac!". And now you also start getting compounded modes - want a mode that is = both agree-wrap-enc and zipped - then you start getting a huge number of = possible strings to deal with.=20 That is not to say that having some level of modes is not a good idea. = I would be more than willing to see the typ field become both mandatory = and slightly more useful - i.e. encryption vs signature vs mac as the = processing can be very different in the different cases. Jim >=20 > -- > James Manger From James.H.Manger@team.telstra.com Sun Jul 22 23:19:12 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2198821F8620 for ; Sun, 22 Jul 2012 23:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJW3rx6ZcG9U for ; Sun, 22 Jul 2012 23:19:11 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id DDA4421F85F9 for ; Sun, 22 Jul 2012 23:19:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,637,1336312800"; d="scan'208";a="85537601" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipocvi.tcif.telstra.com.au with ESMTP; 23 Jul 2012 16:19:11 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6780"; a="76606814" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcbvi.tcif.telstra.com.au with ESMTP; 23 Jul 2012 16:19:09 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Mon, 23 Jul 2012 16:19:09 +1000 From: "Manger, James H" To: Jim Schaad , "jose@ietf.org" Date: Mon, 23 Jul 2012 16:19:07 +1000 Thread-Topic: [jose] JSE/JWE algorithm factoring Thread-Index: AQFWdvosCN5oUN1jbpGPIyDC6pDmHAFwkqzEmBir5ACAAAYYsA== Message-ID: <255B9BB34FB7D647A506DC292726F6E114F7F01463@WSMSG3153V.srv.dir.telstra.com> References: <005a01cd67b0$5b8e2640$12aa72c0$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F7E0FFED@WSMSG3153V.srv.dir.telstra.com> <008301cd6890$ca175b00$5e461100$@augustcellars.com> In-Reply-To: <008301cd6890$ca175b00$5e461100$@augustcellars.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] JSE/JWE algorithm factoring X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 06:19:12 -0000 PiA+IFdvdWxkbid0IGl0IGJlIHNpbXBsZXIgdG8gaGF2ZSBhIHNwZWNpZmljIGZpZWxkIHRvIGlu ZGljYXRlIHRoZSBtb2RlPw0KPiA+IEVhY2ggbW9kZSBkZWZpbmVzIGhvdyBtYW55IGRvdC1zZXBh cmF0ZWQgc2VnbWVudHMgdGhlcmUgYXJlLCB3aGF0IHRoZXkNCj4gPiBob2xkLCBhbmQgd2hpY2gg b3RoZXIgaGVhZGVyIGZpZWxkcyBpbmRpY2F0ZSB0aGUgYWxncyB0aGUgbW9kZSB1c2VzLg0KPiA+ IElmIHlvdSBkb24ndCByZWNvZ25pemUgdGhlIG1vZGUgeW91IGNhbm5vdCBwcm9jZXNzIHRoZSBt ZXNzYWdlLg0KDQo+IEkgYWdyZWUgdGhhdCBoYXZpbmcgbW9kZXMgY2FuIGJlIHVzZWZ1bCwgYnV0 IEkgYW0gbm90IHN1cmUgdGhhdCBpdCBpcw0KPiBnb2luZyB0byBoZWxwIGluIHRoaXMgc2l0dWF0 aW9uLiAgVGhlIGNvZGUgZm9yIGRlYWxpbmcgd2l0aCB0aGUgYWJvdmUNCj4gaXMgYWN0dWFsbHkg dmVyeSBzaW1wbGUgbG9naWMNCj4gDQo+IGlmIChwa0FsZyBleGlzdHMpIHsNCj4gICAgaWYgKHBr QWxnIGlzIGEgc2lnbmF0dXJlIGFsZ29yaXRobSkgZG8gc2lnbmF0dXJlIHByb2Nlc3NpbmcgYW5k DQo+IHJldHVybg0KPiAgIGVsc2UgaWYgKHBrQWxnIGlzIGEga25vd24gYWxnb3JpdGhtKSB7DQo+ ICAgICBmaW5kIHRoZSBrZXkNCj4gICAgIHByb2Nlc3MgdGhlIHZhbHVlDQo+ICAgfQ0KPiAgRWxz ZSB0aHJvdyBhbiBlcnJvcg0KPiB9DQo+IA0KPiBJZiAoY3dBbGcgZXhpc3RzICkgew0KPiAgICBJ ZiB1bmtub3duIGFsZ29yaXRobSB0aHJvdyBlcnJvcg0KPiAgICAgSWYgbm8ga2V5ICB0aGVuIGZp bmQgdGhlIGtleQ0KPiAgICBQcm9jZXNzIHRoZSB2YWx1ZQ0KPiB9DQo+IA0KPiBJZiAoY0FsZyBl eGlzdHMpIHsNCj4gICBJZiB1bmtub3duIGFsZyB0aGVuIHRocm93IGVycm9yDQo+ICAgSWYgbm8g a2V5IGtub3duIHRoZW4gZmluZCB0aGUga2V5DQo+ICAgSWYgZW5jcnlwdGlvbiBhbGcgdGhlbiBw cm9jZXNzIGFzIGVuY3J5cHRpb24gYW5kIHJldHVybg0KPiAgIElmIG1hYyBhbGcgdGhlbiBwcm9j ZXNzIGFzIG1hYyBhbmQgcmV0dXJuDQo+IH0NCj4gDQo+IFRocm93IGFuIGVycm9yDQoNCg0KU28g bGV0J3Mgc2F5IHdlIHB1Ymxpc2ggSk9TRSB2MTsgeW91IGltcGxlbWVudCB0aGlzIGNvZGU7IHRo ZW4gNiBtb250aHMgbGF0ZXIgSk9TRSB2MiBhZGRzIHRoZSBvcHRpb24gdG8gY29tcHJlc3MgdGhl IGRhdGEgYmVmb3JlIHNpZ25pbmcgaXQgKGJ5IGFsbG93aW5nICJ6aXAiOiJERUZMQVRFIiBpbiBh IEpXUykuIFlvdXIgY29kZSBoYXBwaWx5IHByb2Nlc3NlcyB0aGUgbWVzc2FnZTsgdmVyaWZpZXMg dGhlIHNpZ25hdHVyZTsgdGhlbiByZXR1cm5zIERFRkxBVEUgZ2liYmVyaXNoIGluc3RlYWQgb2Yg dGhlIGV4cGVjdGVkIGNvbnRlbnQuIFl1Y2suDQpBICJNVVNUIHVuZGVyc3RhbmQgZXZlcnl0aGlu ZyIgcnVsZSAoaWYgc3BlY2lmaWVkIGFuZCAqSU1QTEVNRU5URUQgZXZlcnl3aGVyZSopIG1pZ2h0 IHNhdmUgeW91IGJ5IHRyaWdnZXJpbmcgYW4gInVuc3VwcG9ydGVkIGZpZWxkIiBlcnJvciwgYnV0 IHN1Y2ggYSBydWxlIGlzIHdyb25nIGZvciBsb3RzIG9mIG90aGVyIHJlYXNvbnMuDQpBIGJldHRl ciBhcHByb2FjaCBpcyBmb3IgSk9TRSB2MiB0byBkZWZpbmVzICJ0Ijoic2lnMiIuIFByb2Nlc3Np bmcgaXMgdGhlIHNhbWUgYXMgInQiOiJzaWciIGJ1dCBpZiBhICJ6aXAiIGZpZWxkIGlzIHByZXNl bnQgdGhlIGNvbnRlbnQgaXMgY29tcHJlc3NlZC4gWW91ciBvbGQgY29kZSBsb29rcyBhdCAidCI6 InNpZzIiIGFuZCBpbW1lZGlhdGVseSByZXR1cm5zICJ1bnN1cHBvcnRlZCBtb2RlIi4NCg0KUmVs eWluZyBvbiB0aGUgcHJlc2VuY2UvYWJzZW5jZSBhbmQgdmFsdWVzIG9mIDMgZmllbGRzIChwa0Fs ZywgY3dBbGcsIGNBbGcpIGlzIG5vdCBleHRlbnNpYmxlIHRvIG5ldyBtb2Rlcy4NCg0KDQo+IEFu ZCBub3cgeW91IGFsc28gc3RhcnQgZ2V0dGluZyBjb21wb3VuZGVkIG1vZGVzIC0gd2FudCBhIG1v ZGUgdGhhdCBpcw0KPiBib3RoIGFncmVlLXdyYXAtZW5jIGFuZCB6aXBwZWQgLSB0aGVuIHlvdSBz dGFydCBnZXR0aW5nIGEgaHVnZSBudW1iZXINCj4gb2YgcG9zc2libGUgc3RyaW5ncyB0byBkZWFs IHdpdGguDQoNCk5vdCBpbiBwcmFjdGljZS4gT25lIG1vZGUgc3RyaW5nIGNhbiBjb3ZlciBsb3Rz IG9mICJzdWItbW9kZXMiIChlZyB6aXBwZWQgb3Igbm90KSwgYXMgbG9uZyBhcyB0aGUgc3ViLW1v ZGVzIGFyZSBzcGVjaWZpZWQgd2hlbiB0aGUgbW9kZSBzdHJpbmcgaXMgZGVmaW5lZC4gWW91IG9u bHkgbmVlZCBhIG5ldyBtb2RlIHN0cmluZyB3aGVuIHlvdSB3YW50IHNvbWV0aGluZyBuZXcgdGhh dCBjb3VsZCBvdGhlcndpc2UgYmUgbWlzaW50ZXJwcmV0ZWQuIEluc3RlYWQgb2YgZXZlcnkgZmll bGQgKGFib3V0IHRoZSBzdHJ1Y3R1cmUsIGFib3V0IHRoZSBrZXlzLCBhYm91dCByZXZvY2F0aW9u IGluZm8sIGFib3V0IGtleSBkaXNjb3Zlcnkgb3B0aW9ucywgbWV0YWRhdGEgYWJvdXQgdGhlIGNv bnRlbnTigKYpIG5lZWRpbmcgdG8gYmUgIk1VU1QgdW5kZXJzdGFuZCIsIG9ubHkgdGhlIG1vZGUg c3RyaW5nIG5lZWRzIHRvIGJlIHVuZGVyc3Rvb2QuDQoNCg0KV2UgY291bGQgcGljayBtb2RlIHN0 cmluZ3MgY29ycmVzcG9uZGluZyB0byB0aGUgdG9wLWxldmVsIGNvbnRlbnRUeXBlIGluIENNUyAo ZWcgU2lnbmVkRGF0YSwgRW5jcnlwdGVkRGF0YSwgQXV0aGVudGljYXRlZERhdGEsIEF1dGhFbnZl bG9wZWREYXRhLCBDb21wcmVzc2VkRGF0YSwg4oCmKS4NCk9yIHdlIGNvdWxkIGJlIGEgYml0IG1v cmUgc3BlY2lmaWMgYW5kIHBpY2sgbW9kZSBzdHJpbmdzIHRoYXQgY292ZXIgcGFydGljdWxhciBr ZXkgZXN0YWJsaXNobWVudCB0ZWNobmlxdWVzIChlZyBBdXRoRW52ZWxvcGVkRGF0YS5LZXlUcmFu c3BvcnQsIEF1dGhFbnZlbG9wZWREYXRhLktleUFncmVlbWVudCwgQXV0aEVudmVsb3BlZERhdGEu U3ltbWV0cmljS0VLLCBBdXRoRW52ZWxvcGVkRGF0YS5QYXNzd29yZCwgQXV0aEVudmVsb3BlZERh dGEuSUJFLCDigKYpLiBJIHByZWZlciB0aGUgbGF0dGVyIChzaW5jZSB3ZSBhcmUgb25seSBsaWtl bHkgdG8gc3BlY2lmeSBhIHN1YnNldCBvZiBrZXkgZXN0YWJsaXNobWVudCB0ZWNobmlxdWVzIGF0 IGZpcnN0KS4NCg0KDQogDQo+IFRoYXQgaXMgbm90IHRvIHNheSB0aGF0IGhhdmluZyBzb21lIGxl dmVsIG9mIG1vZGVzIGlzIG5vdCBhIGdvb2QgaWRlYS4NCj4gSSB3b3VsZCBiZSBtb3JlIHRoYW4g d2lsbGluZyB0byBzZWUgdGhlIHR5cCBmaWVsZCBiZWNvbWUgYm90aCBtYW5kYXRvcnkNCj4gYW5k IHNsaWdodGx5IG1vcmUgdXNlZnVsIC0gaS5lLiBlbmNyeXB0aW9uIHZzIHNpZ25hdHVyZSB2cyBt YWMgYXMgdGhlDQo+IHByb2Nlc3NpbmcgY2FuIGJlIHZlcnkgZGlmZmVyZW50IGluIHRoZSBkaWZm ZXJlbnQgY2FzZXMuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From Michael.Jones@microsoft.com Mon Jul 23 21:51:09 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2B121F8569 for ; Mon, 23 Jul 2012 21:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.779 X-Spam-Level: X-Spam-Status: No, score=-3.779 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YADCh3jN4uJw for ; Mon, 23 Jul 2012 21:51:03 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2086521F8554 for ; Mon, 23 Jul 2012 21:50:59 -0700 (PDT) Received: from mail71-db3-R.bigfish.com (10.3.81.236) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.23; Tue, 24 Jul 2012 04:50:59 +0000 Received: from mail71-db3 (localhost [127.0.0.1]) by mail71-db3-R.bigfish.com (Postfix) with ESMTP id D387D26013B for ; Tue, 24 Jul 2012 04:50:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VS0(zzc85fhzz1202hzz8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah34h) Received-SPF: pass (mail71-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail71-db3 (localhost.localdomain [127.0.0.1]) by mail71-db3 (MessageSwitch) id 1343105455427526_4417; Tue, 24 Jul 2012 04:50:55 +0000 (UTC) Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.238]) by mail71-db3.bigfish.com (Postfix) with ESMTP id 630132A0048 for ; Tue, 24 Jul 2012 04:50:55 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 24 Jul 2012 04:50:54 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0309.003; Tue, 24 Jul 2012 04:50:00 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Platform support for JWA algorithms Thread-Index: Ac1pV7QbyAXFlB7QQ1KpJ/BLf5eMAA== Date: Tue, 24 Jul 2012 04:49:59 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366741FA4@TK5EX14MBXC285.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/mixed; boundary="_004_4E1F6AAD24975D4BA5B168042967394366741FA4TK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [jose] Platform support for JWA algorithms X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 04:51:09 -0000 --_004_4E1F6AAD24975D4BA5B168042967394366741FA4TK5EX14MBXC285r_ Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366741FA4TK5EX14MBXC285r_" --_000_4E1F6AAD24975D4BA5B168042967394366741FA4TK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've been doing some investigation into the state of support for the JWA al= gorithms in common Web development platforms. The attached table is the da= ta gathered to date. I'll be leading a discussion based upon this data during our session at IET= F 84. If any of you have more data that I should add, or believe that ther= e are additional columns or rows we should track, please let me know. Thanks to Roland Hedberg, Axel Nennker, Emmanuel Raviart, Nov Matake, Justi= n Richer, and Edmund Jay for the data they provided, based upon their imple= mentation experiences. -- Mike Usage Param Name Param Val Description .NET OSX iOS Java JCA BouncyCastle Android PHP PHPSecLib Python MCrypto2 PyCrypto Ruby OpenSSL node.js JWS/JWE alg/int HS256 HMAC w/ SHA-256 hash YES YES YES YES YES YES YES YES YES YES YES YES YES JWS/JWE alg/int HS384 HMAC w/ SHA-384 hash YES YES YES YES YES YES YES YES YES YES YES YES YES JWS/JWE alg/int HS512 HMAC w/ SHA-512 hash YES YES YES YES YES YES YES YES YES YES YES YES YES JWS alg RS256 RSA w/ SHA-256 hash YES YES YES YES YES YES NO YES YES YES YES YES YES JWS alg RS384 RSA w/ SHA-384 hash YES YES YES YES YES YES NO YES YES YES YES YES YES JWS alg RS512 RSA w/ SHA-512 hash YES YES YES YES YES YES NO YES YES YES YES YES YES JWS alg ES256 ECDSA w/ P-256 curve and SHA-256 hash YES NO* NO NO* YES YES NO NO YES NO YES YES JWS alg ES384 ECDSA w/ P-384 curve and SHA-384 hash YES NO* NO NO* YES YES NO NO YES NO YES YES JWS alg ES512 ECDSA w/ P-521 curve and SHA-512 hash YES NO* NO NO* YES YES NO NO YES NO YES YES JWE alg RSA1_5 RSAES-PKCS1-V1_5 YES YES* YES YES YES YES YES YES YES YES YES YES JWE alg RSA-OAEP RSAES OAEP YES YES* YES NO YES YES NO YES YES YES YES YES JWE alg ECDH-ES Elliptic Curve Diffie-Hellman Ephemeral Static NO* NO NO* YES* YES* NO NO YES* NO YES YES JWE alg A128KW AES Key Wrap w/ 128 bit key NO YES YES YES YES NO NO YES YES YES* YES* JWE alg A256KW AES Key Wrap w/ 256 bit key NO YES YES YES YES NO NO YES YES YES* YES* JWE enc A128CBC AES CBC w/ 128 bit key YES YES YES YES YES YES YES YES YES YES JWE enc A256CBC AES CBC w/ 256 bit key YES YES YES YES YES YES YES YES YES YES JWE enc A128GCM AES GCM w/ 128 bit key NO NO* NO NO YES YES NO NO NO* NO YES YES JWE enc A256GCM AES GCM w/ 256 bit key NO NO* NO NO YES YES NO NO NO* NO YES YES JWE kdf CS256 Concat Key Distribution Function (KDF) NO NO NO NO NO NO NO NO NO NO NO JWE kdf CS384 Concat Key Distribution Function (KDF) NO NO NO NO NO NO NO NO NO NO NO JWE kdf CS512 Concat Key Distribution Function (KDF) NO NO NO NO NO NO NO NO NO NO NO YES - Support built into library/platform BouncyCastle is a crypto lib for Java NO - Not supported in library/platform Android uses BouncyCastle (blank) - Unknown PHPSecLib is a crypto lib for PHP * - Answer is a first impression but requires more research MCrypto2 is a crypto lib for Python PyCrypto is a crypto lib for Python PHP version 5.2 PHPSecLib version 0.3.0 PyCrypto version 2.6 --_000_4E1F6AAD24975D4BA5B168042967394366741FA4TK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve been doing some investigation into the st= ate of support for the JWA algorithms in common Web development platforms.&= nbsp; The attached table is the data gathered to date.

 

I’ll be leading a discussion based upon this d= ata during our session at IETF 84.  If any of you have more data that = I should add, or believe that there are additional columns or rows we shoul= d track, please let me know.

 

Thanks to Roland Hedberg, Axel Nennker, Emmanuel Rav= iart, Nov Matake, Justin Richer, and Edmund Jay for the data they provided,= based upon their implementation experiences.

 

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

 

Usage

Param Name=

Param Val<= /span>

Description

.NET

OSX=

iOS=

Java JCA

BouncyCastle

Android

PHP=

PHPSecLib<= /span>

Python

MCrypto2

PyCrypto

Ruby

OpenSSL

node.js

JWS/JWE

alg/int

HS256

HMAC w/ SHA-256 hash 

YES<= /p>

YES =

YES =

YES =

YES =

YES =

YES<= /p>

YES<= /p>

 =

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

JWS/JWE

alg/int

HS384

HMAC w/ SHA-384 hash

YES<= /p>

YES<= /p>

YES =

YES =

YES =

YES =

YES<= /p>

YES<= /p>

 =

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

JWS/JWE

alg/int

HS512

HMAC w/ SHA-512 hash

YES<= /p>

YES =

YES =

YES =

YES =

YES =

YES<= /p>

YES<= /p>

 =

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

JWS

alg

RS256

RSA w/ SHA-256 hash

YES<= /p>

YES =

YES =

YES =

YES =

YES =

NO

YES<= /p>

 =

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

JWS

alg

RS384

RSA w/ SHA-384 hash 

YES<= /p>

YES =

YES =

YES =

YES =

YES =

NO

YES<= /p>

 =

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

JWS

alg

RS512

RSA w/ SHA-512 hash

YES<= /p>

YES =

YES =

YES =

YES =

YES =

NO

YES<= /p>

 =

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

JWS

alg

ES256

ECDSA w/ P-256 curve and SHA-256 ha= sh

YES<= /p>

NO*

NO

NO*

YES =

YES =

NO

NO

 =

YES<= /p>

NO

 =

YES<= /p>

YES<= /p>

JWS

alg

ES384

ECDSA w/ P-384 curve and SHA-384 ha= sh 

YES<= /p>

NO* 

NO

NO*

YES =

YES =

NO

NO

 =

YES<= /p>

NO

 =

YES<= /p>

YES<= /p>

JWS

alg

ES512

ECDSA w/ P-521 curve and SHA-512 ha= sh

YES<= /p>

NO* 

NO

NO*

YES =

YES =

NO

NO

 =

YES<= /p>

NO

 =

YES<= /p>

YES<= /p>

JWE

alg

RSA1_5

RSAES-PKCS1-V1_5<= /p>

YES<= /p>

YES* <= /p>

YES =

YES =

YES =

YES =

YES<= /p>

YES<= /p>

 =

YES<= /p>

YES<= /p>

 =

YES<= /p>

YES<= /p>

JWE

alg

RSA-OAEP

RSAES OAEP

YES<= /p>

YES* <= /p>

YES =

NO

YES =

YES =

NO

YES<= /p>

 =

YES<= /p>

YES<= /p>

 =

YES<= /p>

YES<= /p>

JWE

alg

ECDH-ES

Elliptic Curve Diffie-Hellman Ephem= eral Static

 =

NO*

NO

NO*

YES* <= /p>

YES* <= /p>

NO

NO

 =

YES*

NO

 =

YES<= /p>

YES<= /p>

JWE

alg

A128KW

AES Key Wrap w/ 128 bit key

NO

YES =

YES =

 =

YES =

YES =

NO

NO

 =

YES<= /p>

YES<= /p>

 =

YES*

YES*

JWE

alg

A256KW

AES Key Wrap w/ 256 bit key

NO

YES =

YES =

 =

YES =

YES =

NO

NO

 =

YES<= /p>

YES<= /p>

 =

YES*

YES*

JWE

enc

A128CBC

AES CBC w/ 128 bit key

YES<= /p>

 =

 =

YES =

YES =

YES =

YES<= /p>

YES<= /p>

 =

YES<= /p>

YES<= /p>

 =

YES<= /p>

YES<= /p>

JWE

enc

A256CBC

AES CBC w/ 256 bit key

YES<= /p>

 =

 =

YES =

YES =

YES =

YES<= /p>

YES<= /p>

 =

YES<= /p>

YES<= /p>

 =

YES<= /p>

YES<= /p>

JWE

enc

A128GCM

AES GCM w/ 128 bit key

NO

NO*

NO

NO

YES =

YES =

NO

NO

 =

NO*

NO

 =

YES<= /p>

YES<= /p>

JWE

enc

A256GCM

AES GCM w/ 256 bit key

NO

NO*

NO

NO

YES =

YES =

NO

NO

 =

NO*

NO

 =

YES<= /p>

YES<= /p>

JWE

kdf

CS256

Concat Key Distribution Function (K= DF)

NO

 =

 =

NO

NO

NO

NO

NO

NO

NO

NO

 =

NO

NO

JWE

kdf

CS384

Concat Key Distribution Function (K= DF)

NO

 =

 =

NO

NO

NO

NO

NO

NO

NO

NO

 =

NO

NO

JWE

kdf

CS512

Concat Key Distribution Function (K= DF)

NO

 =

 =

NO

NO

NO

NO

NO

NO

NO

NO

 =

NO

NO

YES - Support built in= to library/platform

BouncyCastle is a cry= pto lib for Java

NO - Not supported in = library/platform

Android uses BouncyCa= stle

(blank) - Unknown

PHPSecLib is a crypto= lib for PHP

* - Answer is a first im= pression but requires more research

MCrypto2 is a crypto = lib for Python

PyCrypto is a crypto = lib for Python

PHP version 5.2

PHPSecLib version 0.3.0<= o:p>

PyCrypto version 2.6

 

--_000_4E1F6AAD24975D4BA5B168042967394366741FA4TK5EX14MBXC285r_-- --_004_4E1F6AAD24975D4BA5B168042967394366741FA4TK5EX14MBXC285r_ Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="Support for JWA Crypto Algorithms.xlsx" Content-Description: Support for JWA Crypto Algorithms.xlsx Content-Disposition: attachment; filename="Support for JWA Crypto Algorithms.xlsx"; size=16361; creation-date="Thu, 19 Jul 2012 17:04:00 GMT"; modification-date="Mon, 23 Jul 2012 22:54:58 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDF3RNAiwEAAJQGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM VclqwzAQvRf6D0bXEittoZQSp4cuxzaQ9AMUa2KL2JLQTNPk7ztWFtqQBZNAe7GwpXnLDHruPc7r KplBQONsJq7TrkjA5k4bW2TiY/TauRcJkrJaVc5CJhaA4rF/edEbLTxgwtUWM1ES+QcpMS+hVpg6 D5Z3Ji7Uivg1FNKrfKoKkDfd7p3MnSWw1KEGQ/R7zzBRnxUlL3P+vFQyNlYkT8tzDVUmlPeVyRWx UDmzeouk4yYTk4N2+WfN0Cn6AEpjCUB1lfpgmDEMgYiNoZA7OQNU2I505SrlyigMS+Pxiq3vYWh2 9rta1b3zOILRkAxUoDdVs3c5r+SXC9Oxc9P0MEjb1sQWpbUydq37AH88jDIu12cW0viLwC113PwT Hbd/pIP4zoGMz9NHEmGODABpUQGe2e0S9BhzqQLoIfFtLs4u4Cf2ER2kxtwBGZfTe/47qiLoIX6O uEFwHjlFA7SfwjqymuqOZyAIZGATWrsu/4aRI7g94VYwQ5PxGvQObhn/Kf1vAAAA//8DAFBLAwQU AAYACAAAACEAtVUwI/UAAABMAgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySz07DMAzG70i8Q+T7 6m5ICKGlu0xIuyFUHsAk7h+1jaMkQPf2hAOCSmPb0fbnzz9b3u7maVQfHGIvTsO6KEGxM2J712p4 rZ9WD6BiImdpFMcajhxhV93ebF94pJSbYtf7qLKLixq6lPwjYjQdTxQL8exypZEwUcphaNGTGahl 3JTlPYa/HlAtPNXBaggHeweqPvo8+bK3NE1veC/mfWKXToxAnhM7y3blQ2YLqc/bqJpCy0mDFfOc 0xHJ+yJjA54m2lxP9P+2OHEiS4nQSODzPN+Kc0Dr64Eun2ip+L3OPOKnhOFNZPhhwcUPVF8AAAD/ /wMAUEsDBBQABgAIAAAAIQDeCf0oAgEAANQDAAAaAAgBeGwvX3JlbHMvd29ya2Jvb2sueG1sLnJl bHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8k89qwzAMxu+DvYPRfXGSbmWU Or2MQa9b9wAmUeLQxDaW9idvP5NDukDJLqEXgyT8fT/Qp/3hp+/EFwZqnVWQJSkItKWrWtso+Di9 PjyDINa20p2zqGBAgkNxf7d/w05z/ESm9SSiiiUFhtnvpKTSYK8pcR5tnNQu9JpjGRrpdXnWDco8 Tbcy/NWAYqYpjpWCcKw2IE6Dj87/a7u6bkt8ceVnj5avWMhvF85kEDmK6tAgK5haJMfJJonEIK/D 5DeGyZdgshvDZEsw2zVhyOiA1TuHmEK6rGrWXoJ5WhWGhy6GfgoMjfWS/eOa9hxPCS/uYynHd9qH nN1i8QsAAP//AwBQSwMEFAAGAAgAAAAhALPQMKBiAQAAcgIAAA8AAAB4bC93b3JrYm9vay54bWyM Uk1PwzAMvSPxH6LcWdbsAzatnYQAsQtCYmzn0LhrtDSpkoxu/x43U8sQHDjZjl+e/V6yWB4rTT7B eWVNSpPBkBIwuZXK7FL6vn66uaPEB2Gk0NZASk/g6TK7vlo01u0/rN0TJDA+pWUI9Zwxn5dQCT+w NRjsFNZVImDpdszXDoT0JUCoNOPD4ZRVQhl6Zpi7/3DYolA5PNj8UIEJZxIHWgRc35eq9jRbFErD 5qyIiLp+ERXufdSUaOHDo1QBZEonWNoGfhy4Q31/UBq7s9FwRFnWi3x1REIhDjqsUV7Hjn7xMefT FtlasVHQ+O9LbUmOW2WkbVI6vkNrT12VcKya2NoqGcqUcj6b8e7sGdSuDMg/Sm4jPbvgjw7inBiJ ifLeWlcTfKo2rlAB5m6uMHErmbQL/kLjsB6NeY/mf6JHF2jMe3S0iUUiXCkXOkev2hCXGE+mPE5n 3XfJvgAAAP//AwBQSwMEFAAGAAgAAAAhAPtipW2UBgAApxsAABMAAAB4bC90aGVtZS90aGVtZTEu eG1s7FlPb9s2FL8P2HcgdG9tJ7YbB3WK2LGbrU0bxG6HHmmZllhTokDSSX0b2uOAAcO6YZcBu+0w bCvQArt0nyZbh60D+hX2SEqyGMtL0gYb1tWHRCJ/fP/f4yN19dqDiKFDIiTlcdurXa56iMQ+H9M4 aHt3hv1LGx6SCsdjzHhM2t6cSO/a1vvvXcWbKiQRQbA+lpu47YVKJZuVivRhGMvLPCExzE24iLCC VxFUxgIfAd2IVdaq1WYlwjT2UIwjIHt7MqE+QUNN0tvKiPcYvMZK6gGfiYEmTZwVBjue1jRCzmWX CXSIWdsDPmN+NCQPlIcYlgom2l7V/LzK1tUK3kwXMbVibWFd3/zSdemC8XTN8BTBKGda69dbV3Zy +gbA1DKu1+t1e7WcngFg3wdNrSxFmvX+Rq2T0SyA7OMy7W61Ua27+AL99SWZW51Op9FKZbFEDcg+ 1pfwG9VmfXvNwRuQxTeW8PXOdrfbdPAGZPHNJXz/SqtZd/EGFDIaT5fQ2qH9fko9h0w42y2FbwB8 o5rCFyiIhjy6NIsJj9WqWIvwfS76ANBAhhWNkZonZIJ9iOIujkaCYs0AbxJcmLFDvlwa0ryQ9AVN VNv7MMGQEQt6r55//+r5U/Tq+ZPjh8+OH/50/OjR8cMfLS1n4S6Og+LCl99+9ufXH6M/nn7z8vEX 5XhZxP/6wye//Px5ORAyaCHRiy+f/PbsyYuvPv39u8cl8G2BR0X4kEZEolvkCB3wCHQzhnElJyNx vhXDEFNnBQ6Bdgnpngod4K05ZmW4DnGNd1dA8SgDXp/dd2QdhGKmaAnnG2HkAPc4Zx0uSg1wQ/Mq WHg4i4Ny5mJWxB1gfFjGu4tjx7W9WQJVMwtKx/bdkDhi7jMcKxyQmCik5/iUkBLt7lHq2HWP+oJL PlHoHkUdTEtNMqQjJ5AWi3ZpBH6Zl+kMrnZss3cXdTgr03qHHLpISAjMSoQfEuaY8TqeKRyVkRzi iBUNfhOrsEzIwVz4RVxPKvB0QBhHvTGRsmzNbQH6Fpx+A0O9KnX7HptHLlIoOi2jeRNzXkTu8Gk3 xFFShh3QOCxiP5BTCFGM9rkqg+9xN0P0O/gBxyvdfZcSx92nF4I7NHBEWgSInpmJEl9eJ9yJ38Gc TTAxVQZKulOpIxr/XdlmFOq25fCubLe9bdjEypJn90SxXoX7D5boHTyL9wlkxfIW9a5Cv6vQ3ltf oVfl8sXX5UUphiqtGxLba5vOO1rZeE8oYwM1Z+SmNL23hA1o3IdBvc4cOkl+EEtCeNSZDAwcXCCw WYMEVx9RFQ5CnEDfXvM0kUCmpAOJEi7hvGiGS2lrPPT+yp42G/ocYiuHxGqPj+3wuh7Ojhs5GSNV YM60GaN1TeCszNavpERBt9dhVtNCnZlbzYhmiqLDLVdZm9icy8HkuWowmFsTOhsE/RBYuQnHfs0a zjuYkbG2u/VR5hbjhYt0kQzxmKQ+0nov+6hmnJTFypIiWg8bDPrseIrVCtxamuwbcDuLk4rs6ivY Zd57Ey9lEbzwElA7mY4sLiYni9FR22s11hoe8nHS9iZwVIbHKAGvS91MYhbAfZOvhA37U5PZZPnC m61MMTcJanD7Ye2+pLBTBxIh1Q6WoQ0NM5WGAIs1Jyv/WgPMelEKlFSjs0mxvgHB8K9JAXZ0XUsm E+KrorMLI9p29jUtpXymiBiE4yM0YjNxgMH9OlRBnzGVcONhKoJ+ges5bW0z5RbnNOmKl2IGZ8cx S0KclludolkmW7gpSLkM5q0gHuhWKrtR7vyqmJS/IFWKYfw/U0XvJ3AFsT7WHvDhdlhgpDOl7XGh Qg5VKAmp3xfQOJjaAdECV7wwDUEFd9TmvyCH+r/NOUvDpDWcJNUBDZCgsB+pUBCyD2XJRN8pxGrp 3mVJspSQiaiCuDKxYo/IIWFDXQObem/3UAihbqpJWgYM7mT8ue9pBo0C3eQU882pZPnea3Pgn+58 bDKDUm4dNg1NZv9cxLw9WOyqdr1Znu29RUX0xKLNqmdZAcwKW0ErTfvXFOGcW62tWEsarzUy4cCL yxrDYN4QJXCRhPQf2P+o8Jn94KE31CE/gNqK4PuFJgZhA1F9yTYeSBdIOziCxskO2mDSpKxp09ZJ Wy3brC+40835njC2luws/j6nsfPmzGXn5OJFGju1sGNrO7bS1ODZkykKQ5PsIGMcY76UFT9m8dF9 cPQOfDaYMSVNMMGnKoGhhx6YPIDktxzN0q2/AAAA//8DAFBLAwQUAAYACAAAACEAQb/4YNkAAADK AQAAIwAAAHhsL3dvcmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzrJHBTsMwDEDvSPxD5DtJ uwNCaOkuCGlXGB/gpW4b0TpRbBD7e4J2odMkLpws2/Lzk73dfS2z+aQiMbGH1jZgiEPqI48e3g7P dw9gRJF7nBOThxMJ7Lrbm+0Lzah1SKaYxVQKi4dJNT86J2GiBcWmTFw7QyoLak3L6DKGdxzJbZrm 3pXfDOhWTLPvPZR9vwFzOOW6+W92GoYY6CmFj4VYr6xwiseZKhDLSOrB2nNFzqG1VRbcdY/2Pz1y iaxUXkm1HlpWRhc9d5G39hj5R9KtPtB9AwAA//8DAFBLAwQUAAYACAAAACEA++hdR2ABAAB1AgAA GAAAAHhsL3dvcmtzaGVldHMvc2hlZXQyLnhtbIySwWrDMAyG74O9g/G9cbp16xqSlEEp62Ewxra7 4yiJaWwF213bt5+SkDLopTcJSZ9//XK6PpmW/YLzGm3G51HMGViFpbZ1xr+/trMXznyQtpQtWsj4 GTxf5/d36RHd3jcAgRHB+ow3IXSJEF41YKSPsANLlQqdkYFSVwvfOZDlMGRa8RDHz8JIbflISNwt DKwqrWCD6mDAhhHioJWB9PtGd36iGXULzki3P3QzhaYjRKFbHc4DlDOjkl1t0cmipb1P84VUE3tI rvBGK4ceqxARToxCr3deiZUgUp6WmjbobWcOqoy/zrnI08GcHw1H/y9mvdcF4r4v7MqMx32ruOrd Dl5/OFZCJQ9t+MTjG+i6CXTYRbQg9f0SSXnegFfkHoGix8urGxkkYTtZw7t0tbaetVANTUvO3MiJ I4oDdv3o8omzAkNAM2UNnRfojD2WVYhhSnq5lw+T/wEAAP//AwBQSwMEFAAGAAgAAAAhAPvoXUdg AQAAdQIAABgAAAB4bC93b3Jrc2hlZXRzL3NoZWV0My54bWyMksFqwzAMhu+DvYPxvXG6desakpRB KethMMa2u+MoiWlsBdtd27efkpAy6KU3CUmff/1yuj6Zlv2C8xptxudRzBlYhaW2dca/v7azF858 kLaULVrI+Bk8X+f3d+kR3d43AIERwfqMNyF0iRBeNWCkj7ADS5UKnZGBUlcL3zmQ5TBkWvEQx8/C SG35SEjcLQysKq1gg+pgwIYR4qCVgfT7Rnd+ohl1C85Itz90M4WmI0ShWx3OA5Qzo5JdbdHJoqW9 T/OFVBN7SK7wRiuHHqsQEU6MQq93XomVIFKelpo26G1nDqqMv865yNPBnB8NR/8vZr3XBeK+L+zK jMd9q7jq3Q5efzhWQiUPbfjE4xvougl02EW0IPX9Ekl53oBX5B6BosfLqxsZJGE7WcO7dLW2nrVQ DU1LztzIiSOKA3b96PKJswJDQDNlDZ0X6Iw9llWIYUp6uZcPk/8BAAD//wMAUEsDBBQABgAIAAAA IQBPzkOd4gsAAHhIAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1srJxbc+o4Esfft2q/A8X7 QGxuSSrJ1EnMxYDBcHZmnwlxEupAnAXnXObTb8uSZavbo1Z2eeEi//RXS/q7JTD45vefh33je3I8 7dK326bXumg2krdt+rR7e7lt/vGv0W+XzcYp27w9bfbpW3Lb/JWcmr/f/fMfNz/S47fTa5JkDVB4 O902X7Ps/brdPm1fk8Pm1Erfkzc48pweD5sM3h5f2qf3Y7J5yisd9m3/4qLfPmx2b02pcH100Uif n3fbJEi3H4fkLZMix2S/ySD+0+vu/VSoHbYucofN8dvH+2/b9PAOEo+7/S77lYs2G4ftdfjylh43 j3vo90+vu9kW2vkbIn/YbY/pKX3OWiDXloHSPl+1r9qgdHfztIMeiGFvHJPn2+YX73rd8Zrtu5t8 gP7cJT9OldeNbPP4Ndkn2yx5gnlqNv5K08PX7UbEdgWTpt8uxIDvZaGYo8c0/SbEQqh2Ac2echHR 7Gab7b4nD8ke6C9+B+b5PzISeA1htHUc1ddFTKN8XuNj4yl53nzss3X6Y5LsXl4zCK7b6sJIiQG7 fvoVJKctzBQ03splt+keNOCxcdgJx8FAb37mzz92T9krBN5sPCanbLQTUs3G9uOUpYd/y2P5+Oi6 vqoLz6ouNO1dXHUGPWcN6HbePjwXGn6r0/EvOp7vrgL9zVXgWal0Oy3fu/xEINBYLgHPSmLQ6vW6 /c9o9JUGPGuNT47HQEnAs5LofzoMmMG8K/CsNDy/NRgMOt18Ziwz6oGT86rihap72er3uxd9MRu2 mtpI8OJ/7bxXOEq8KEIH32o72AIonOSVVhq0ul3PIfbCPl7pn6vW5WV/IB1ka7WwjVf65sptwAqz eKVb+m41C494pUkuHecXVhM5v/CimF/7vBZm8ko3DZzC9AtHiBfFZHZdzdyWeSrPgcEm29zdHNMf DViiQOz0vhELnnftQS9ExvOvRMaT06Sz4N+kQMh9QuaL0LltggDUP0Fe/n7X9W/a3yHXbhVyLxHo t0Z6FybyUINcmkhAESQypES3Z4qMKOKZxJgSqDsTSnRRJCFFOldmO1OKdFEoM4mIFKIHrmuqzGuQ HmIi2lJnYMosKNJDyJIiA4TEFOmgSVxRpId6vaZIR0fbBvNqB0NuMxwsrFy4Vy7reUG+lPdakB1q l/LCx0INzoDKWCPv3FOirwPLz4UHScAppOcLDVFAiT4aoqFEIFwtgogRJZC5xiwxYYmQJaYsMaME 6sucJSJJ+GIrl4/ygq2yZImYJVYssbYRhlFhIT2jUYXabRMetT+wUSmBjSoJWGq1hodSWECRPnLZ UCI2p7LEmBKolQlLhCwxZYkZJbBTWSKShPx0INbGBVtlyRIxS6xYYm0jDKdC6jqjU4WaPaVSAjtV EvBYOhUtGAFFBsjMQ4nYnEoJ5MMxS0xYImSJKUvMKIGdyhKRJCo5la2yZImYJVYssbYRhlMhd53R qULNzKke2vXd1yDlvkQu/xKBx9KraC8WUGSA7DyUiM2rlMBeZYkJS4QsMWWJmSTg45UekQ46NedU BNk5kkQlrbJVliwRs8SKJdY2wjArTOYZzSrUzLRKzFqDYLNKBM43PTUe2kcEFBmgs2IoEXjUKmj2 RpTAZmWJCUuELDFliZkkrGalIqi7kSQqmZWtsmSJmCVWLLG2EYZZYQDOaFahxmTWGgSbVSJwvmmb eWijEFBkgFSGEoGB0Cpo9kaUwGZliQlLhCwxZYmZJOBR94VkViqCuhtJopJZ2SpLlohZYsUSaxth mBW+dzqjWYUak1lrEGSzB4kYmRV/DUCRPkq+Q4nYzFoTCprgsURgNP/WJRNeJaShoLNiyhIzPpI5 j0QSqWRX2jAagiWvGmPVFau6thGGQeFbzzMaVKgx2bQGwQaVSDWb+mhXFlCkjxLuUCI2g9JQfLTZ HUvEalCJwJct2sMemuOQhoINyhIzPpI5j0QSqWRU2jAKfsmrxlh1xaqubYRhUPH18hkdmssxObSO wR5VTDWL+mjzGdQwfZRph4qx2bQmHOJTxViNWqNDnFoTDrYqj8wcopk7MJFiKvm0pnHsVwfhmAiv eOG1FTE9K64RVC9eQVL8P7769+QlB/iWTKcYH/nxvobxEPOgGCOx4i8Aapg+Sr5DxVg9WxMy2kGM a2SQ1yY8EvLIlEdmNQjy1ZxHIoVU0itfackjMdFd8ZXWVsS0q7hScEa7ygsP1RWR2pUy1K6SMVIs WuQD8QMCOLmqTA+ZaKgYq11pOD6xq2SqMqiliWrJloXDmmiQzJRHZg4tzWtkkKcjhVQTLO0lqrTk dWOiu+Irra2IaVhxweCMhpXXH+z5lTLUsJIx8ita7wPxqxUwrMGgAR4qpkwjI11SrgB46R4rxma+ iYNOqBjwQbnaoHNh6sDMHOKZOzCRYsrRWOiSMsIe2nstHZRjrVNcul2pkuo5jiZnbUVMl0JWOqdL hZy5c6VplTLUpZKBx3J+UQYKxA+kkEv7aDcxVIzNbyPFVMcTNTXmkYlCyiwV8pWmPDJTiK0Hcwcm UkwZ36KmceSjJY/ERHelS8q5w85f2xnToZCGzulQIWd+/KcOpQx1qGTgUTu0gz6YB+J3eNihaC87 VIxtfkeKsTpUNmVBJkqlzFEhrzvlkZlCbD2YOzCRYsr4FjWNE4fSfiMkJrorXVLOHXWoFK6utxXG dCiM+jkdKuS4HEqZDlpdHsRvOUGnmkM7KD8GioG+ahdfImaoGFArGfM3WyOFlMllTEomNTIozYY8 MuWRWQ2CLDHnkUghZZcWfKUlj8REd8VXWlsR04twGp7Ti0KOy5aUoV6UTNVnHZQJA/ELYpQtLxEz VIzVi0U4xYZprCqViWVSI0O8KGWqLSFkyqvMahDiRdoQQiLSgQWvu+SRmOiu+EprK2J6UXzBf8ZP QMUlhjIP0ZWbMtSLkjHyIvrsEIgfcyMv9tHqPlQMTJ/Oi/jy4Ugx1c8pHrLR2EFn4sCEirE6VnbL gswcWpo7MJFiqvmTzg0ei6WDckyUV6qk2i10Cq2tiOla8a3/GV1bXHcoXUJdSxnqWskYGZR80USZ PtoVDMVfJ8DZdtfSePBMjR10Jg5MqJjq3KETZMojM4eW5g5MpJhyqVjoknL+8FgsHZRjrVMsSytV Uu05ca2ciHrEcK1/3itQuRyzB1VMdYfcRXvHB8VUXdtFa3qgmGo+7iGdoWKsrlVMmXHGpGTioBM6 MFMHZubAzB2YyIFZODBLByZWTDmGK4daaztj+vS8V538mks4yDv3NQz1qdSp+rSH9wRKx2BQW0PF 2H1axFxkgrGOsCiZOOiEDszUgZk5MHMHJnJgFg7M0oGJFVPm6ZVDrbWdMX0qLjGcbxfgyysW1X0g 2QUoxp5PpY7hQbwLUDr2fCp17D4tYi5cOda9KEomqsSmEzowUwdm5sDMHZjIgVk4MEsHJlZMNZ/y I7+2K5s+hWk2fGr/f56g4TK/4THkn3tfQV39b7EHWhTQorAogvymPxENys2cGTdY+BNxCxrirvq+ i65a3Ys/hQuoX4mbFAWUmhZF1bgv0b45KiEwv9kV2J59oiuChijBBnqQumjfd+9rqDjTHmhRQIvm RZHRlfKnEWbccNZ+Im5B47jLyc3/vHHva6iMmxQFlFoURUbc6AP3soTIFIiPltVsbTsLlr78ICp+ e6CnYFBOgTlIYgfuqvzFl/t1Y3IHaL97X0LlIOl6RVFgUEZIHbzVt3X2S06jeRugrc19CRXtP9Ci wCgyQ4KhdB8luLMJsdIAZ6ESKkPS9YqiwKBkSPJWJfJv+ofk+JLf1OTU2KYf4sYjA/h3vS5VN1vp eNdCCETxEb97LRJd3ZEeHOnVHunDkTwHEbUBHBnU1rmCI1d1RzoXENuFONLWcnDLlPfNSxJtji+7 t1NjnzxDxy5acKId5U1X8tdZ+p6XQgp8TDO4bUrx7hXuu5PAPyvFPVgaz2maFW+gEaH7Nck+3hvp cQd3aslvpXPbfE+P2XGzy6CF693TbfMYPuXjBfeh2Sfx5pjp8fVgfHVpSecLYFsfgB609T2D7v4L AAD//wMAUEsDBBQABgAIAAAAIQCxD3nbFgcAAJ1MAAANAAAAeGwvc3R5bGVzLnhtbOwca2/bNvD7 gP0HQd9T2W7ixIHtonHioUDaFU0K7CstUTYXiTQkurE77L/vjhQl+SFbTey8xgRISOpIHu/BOx4f 3Q/zOHJ+0CRlgvfc5ruG61Dui4Dxcc/9fjs8OnOdVBIekEhw2nMXNHU/9H//rZvKRURvJpRKB5rg ac+dSDk997zUn9CYpO/ElHL4EookJhKyydhLpwklQYqV4shrNRptLyaMu7qF89iv00hMkrvZ9MgX 8ZRINmIRkwvVluvE/vmnMRcJGUWA6rx5THzTtsqsNR8zPxGpCOU7aM4TYch8uo5lx+t40FK/Gwou U8cXMy577ik0jT2c33Fxz4f4CQiYQfW76U/nB4mgpOl6/a4vIpE4EigDiKkSTmKqIQYkYqOEIVhI YhYtdHELCxQxM7iYwdCw0EM8NDb97gihNvSVjEc9d5j9YK16HS61vaXdhvp5mnY/JoxEznfOQC6p 8/kGe12jVH3E281Goz7iuzmwhUqdAZCpvc/OWAW79ytaipgpUJlFUS7wbZRtKOh3QfEkTfgQMk6W vl1MQbI5zBE4Wk/D7YAeJ2TRbJ3Ur5CKiAWIxXig9CmT8UIWR9kHxgM6p0HPbR+r1ksI10Wuoq/L Dv5io4fva9C+Gg6u9jyA4XBwuqVRxTng/EgkAVgFM9kh73VRvxvRUML4Ezae4H8ppkgNISVMof1u wMhYcBJB0jM1zH+sCdYEDEfPjWnAZjE0q6fGNVZ6CPzgXqB3hV/t3hT0gwcjJ2DFzFBWha80EIPO VvgClVrgQH9D/lrwmlOHYZRBYCdzizE+RHa2kq9Ebmi7hnRmYgpC79MoukHx/CvMJf898HUeOnwW D2P5CaYU8JDQ/pokzIFZUku5zkDPVZWOoX5WCZLlSg6ZTqPFl1k8oslQuU2qN1V6ofSxyH+M2JjH FB0RQEiBfE2EpL5UjpwycFUYnBQYQPKQGHhlimr6lkjbPH0QbZ15uJPIyKTNnMlra6KV6Kjcsiqa tYoG35dpBhmDjm4QHUF08bIcIFHkDBPN16XO+13wAzVP0SGXzEf30QcWU+31zcNqoSqhB0MvWLoD vcMhBB0bBrxEepXQexn0qpoVcgYamTkcy6qmhRwFELKlucigtD8xhhaN1EBnhRhD5qBaBlbCde4T Mr2lc6W9MH972/StClFg4+tAFAbwshBtF6xf0kjIbEZ0i4mFOkaMqtraUrtKFUE/NCZG7p9nqq9C LyfU86JXNYvk1DOzyPNQrwq9nHpPg55yjMAVKvmcSx5n7jc5GLbpuRckMNKHE+OMRZJx9IJap7g+ XAX/Q4gcHsShDK+iEavwX9DbjEwPqDNFD8qVLBw5QDmYF+5xqwU+HBTAolwFpUY6eKUqsVI6lQm7 ywJZ6qMvYI3O03IRzL2UB6VKYiYjxssg6YQE4r4EMtNpE3hAx0mZI108IinFFpBGeZgm6746IHfL Ypo6X+i9803EhKvKGNTMEDF9mYgTuHi7QiJFyGJlcbgeRNDhkE0Bi8I9nIiE/QRyo4M4ppwmyLs1 n9GRQNBvQkKUFGO7wNXCwkEGMcmWD3/PUsnCxTVJ5TVQS8Gmk4Txu1sxZHqJgZFbCAr/iWEBBACK avvsmBX/96mqaLKXEBXFAh0wMCvDuku3WvDFKrIW+ENXyoayMOSC8pDJ4xueUgCrBTsCg1YLaolp KYBRC95qQTYfvRFbQGZSZJtEnrUDWbh4q914Yg2opZXGaJRtRq2KhYnZbGGsG7DiQ3lPzP435QaU dqfXtmA27hiX90N/zRNe3VFbYaNxhTM0io02OwnWmjesFlg3wC4HYcsYlnm1FOaxy8FanRzMDXiN 4ZYtFmavMRdraWzY5eUHH6022CCkOgq1dW1rjusYQ/KmVh+lULzVBqsNVhtgK2/zydZiLW49JbtB lR1rtrbBtdpgteER2rAjmG530JfvUbzukIllNtzYsPExdZ7n5RxHsjsw6tiQPY4EhvyXIgHPG3+2 k+n/aDK1zLbMNudMrU/8lnziV7ONaN0k6ybV8nhWg2K1Kpndlb2f1svOyGc3GZCFy+fhd96U3nAa eGed9aNAO6tsWNnvrGMobc/B42UAPZPivbMtt0He9smE0j2ITXKv5cXo4z7EC+j+Qvf5182VfooH gw/FXk7p6Z+nOldZPJbyuHOVMGG4224YwbWzp1rSO881uwIvtUyj/muJh4S6B4R/4aqcxKeo1JMS +fU+uHoV0JDMInmbf+y5RfqzehgFbvllUF/ZDyFVEz23SF/j6ytNdZkPbnldpxDXg//OLGE995+r i9PO5dWwdXTWuDg7On5PT446JxeXRyfHg4vLy2Gn0WoM/oXbfvhu1zk8YvWId7HU+13wLkHz+DyN 4PWsJBtshvxNUdZzSxmNPiqDB2jrv2oQnjrvr94V6/8HAAD//wMAUEsDBBQABgAIAAAAIQDZ+92N XwMAAMIKAAAUAAAAeGwvc2hhcmVkU3RyaW5ncy54bWyMVtFu0zAUfUfiH67yBEht2o5OE2qDQpZR baytGsbgCbmpu5olTrCdjf4N38KXcd3SEV17g7f2+Jx7b+x7jz16+6Ms4I4rLSo5DvrdXgBc5tVK yJtxcPXxrHMSgDZMrlhRST4OtlwHb6Pnz0ZaG0Ct1ONgY0z9Jgx1vuEl092q5hJX1pUqmcG/6ibU teJspTecm7IIB73ecVgyIQPIq0aacXB0PAigkeJ7w5M9cjIMopEW0chEp1znStQGKxyFJhqFFt4v zbLPFBKzjEKyWvHuN03h+WROofPrLDy/TinMiptQSEPhSTYYHlPwS0rz2216o2uW4/bhPmiu7ngQ IQ+odpIdnbx2wWF/QEEslEJYJIUWvgIXviSLzJMk9cmns1ckjf/7kOd8X+pLjcRfP0nIKPXV4zmZ RRb3vw6J2l8QbrhbEeo7szh1GiFNTicd5ySjtChsI+aQNHiIcCrWa8E7E14UJZOQ1jgAXLECMsOQ RcqK4v7g5OKaotMZRWJsK5eHY+kQMWDyLnFg1PtgZL9PLn1sDzzfmo07cItmuaUB3uHE5tuEaVNw unbO7hicJzHFY7lSlVhR+EqzGyfG7WpNeYmvM7vT9CMl2inrQNbUdaUMLBtRGMBJrqAQS8XUNqwL ZqxTUeF0hrppZUDvtXyFun+qXiwLJm9fovRK3srq3jGsV7gUS33PFQgNDNZCoY+K0vqCtWAs0YDi 3xuBAJSV4vhPc6byDa1wzhQrYcpKZ8NmaMBZ9oEK7ABQLKlkzgxc8C02szZKYH5bxhke6e7Hi4vT s5dUhc6Z8fyDWNKFxDfgiW+WLxO1rU3lGNv+qz6xgobGScWz9M3qbqUzv0iyfueT6waR1WGDw30I OAGwFAZuudPFLRaOz1Msu1nXitX/EbBNfSIquk0W23DzjmXlO3PBOxeySbxDNkw7598S4a1BRBax Io+z/s01HPSJDC+BnYxu/uQyTmx97Xrc0G3WoYCnIj2WDQ+UJqNhWpRDJreeFumxVNjJh9cPDLtu Nx4a/YHU6x51e7Sa+XbfzQ+sQdd5Fxw4j2p3fpDvpsL6DKArgd+E24a7txEis67r5Hn4FG8i9y10 mFBvBn9hf1wdGo3m1a6SFmOHDW+o/5igPyzv8IT4Bo1+AwAA//8DAFBLAwQUAAYACAAAACEAeJ2M gFABAABmAgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAhJJRS8MwFIXfBf9DyXubNnOzhLaDTfYgDgQrim8xudvCmrQk0bp/b9pudUPBx9xz 8uWcS7L5l6qCTzBW1jpHSRSjADSvhdTbHD2XqzBFgXVMC1bVGnJ0AIvmxfVVxhvKawOPpm7AOAk2 8CRtKW9ytHOuoRhbvgPFbOQd2oub2ijm/NFsccP4nm0BkzieYQWOCeYY7oBhMxLRESn4iGw+TNUD BMdQgQLtLE6iBP94HRhl/7zQK2dOJd2h8Z2Occ/Zgg/i6P6ycjS2bRu1kz6Gz5/g1/XDU181lLrb FQdUZIJTboC52hRLVsF7sGB7MBk+m3c7rJh1a7/ujQSxOBRruYfg3m/aZvi36qF9h4EMIvCp6NDh pLxMlnflChUkTkgYz0KSlklKyYxO07fu8Yv7XcphoI4R/iXehmRSEkKnN5fEE6Doc1/+jOIbAAD/ /wMAUEsDBBQABgAIAAAAIQAe1kscQQcAAPQeAAAnAAAAeGwvcHJpbnRlclNldHRpbmdzL3ByaW50 ZXJTZXR0aW5nczEuYmlu7JlpUFNZFscvGFktZBEQRCEiIt1AAAGFZgTCYpAlTAg2m8ZIEghiEkPC IiSBBhSatptgK2KBDN00TFvSKCoOQhGNKDtEGBZZROiwCgGBBhEC8yKOZXXNVE1Vf+t599W5//NO 7rnvnt+rU/nwMMAfGAEsoEAXFYQDMoiCjAXF/AET0CE9DOyAFXQZAVfgAKkDoEF+ALRKNuQQQGEA 7NzjtpGsKAfkwJQKXYkE6XYQJC8P6ebs835PFjQz32f9sUnuQ7pM5SGT6QY0PoQ/iruXX+BeMAfM t0zr8193OXz84T84ip/E/r3/JyHY/T8g8Ol7n4PqDfDFH5OVrQ5egT/SJ0yos8ggBtrJi8Zgs9BU GvDE4nwDsIE4Nw+A8whw9/EBgTQqkxwj8/yJDDIzgHqeDHw88HgPHMAyqWQai8ii0mnAH4vD41y9 8ABHjqFHs9/H7K2sSAwqcKNH05m+dBJ507OxBRj/AOpZRjSVQiWTAr0AnsnebFpZUb8b0/rQ6QL9 MXJAExj+/SBCiPJ2+1sUR+mAqBMZBDWZzPygHJn5awFgrgfANKQNkH7K7XfbfryVrflGKA/cHMPi qDQSPS4mLIYRHUePs7e1JMf/12N9zIcdmMCfjcDxrVA/QbbwDID4vpmC2TO72Ab1zrm2Xl/0W64O h/X90ryDPeh+vdi5Q7mN5c17dDy6zH93uE3IY0KMn6Iks3+LK2fM2NDsiIbhuzrFdy2P1NOQbxWV PsvQ1vjmcD76Tq2gcTynebTi5FnNaYlUpTBJUhtXZVhYnThokluyV5NQUSzk+/GlfVL7EfO9qVa/ GnQtmbnn4lcPpeZxd3Tquy5b1D0g8sOPJ9yY+J6jwaeJie57O+IdKS9ikRTrNvX5oxmlxqOjduUb ioPWYvPTR+/VqJXwNAf/WrBu7viL0TvrU7958525oWU+grcX7ls+HSrdfTepJJ5dGnvBUCthfE1Y vztxf3f3LkaY5PDXPRbRxreqk3hJM/R9r6+/YKMpTzInQ7qjMRM692laSMMng8Pj7O79X7ZEzS+u o2xvlnY9uz0+GRFMH5lE1fnGFI9Y3fAQ07WQVN610aTHz4eKzlII9UR6Xq8PZ6C/8TDFDM9zyqs0 sSie2VndqlbKm35zRI+p/XDjbpNTq1gl/WV2JuG5tLZyObiLrVKufTDvoAOfrl6QMTwwnso/WoBk zqhGhF3yInK0sdc8NZicAIPV5NW32mXDfoarDYpBhnHmr60SQ+sMOiWi2ICLQam/OhSXO9ySbl1c PLbSMqc+H9rAaSiMWg9ZiML3GJdEoMSMBLmc8zjrrCXMdnvfk2I3Ma1lufurhi/LT/3Tgy+3TZCi 1W4WzO+ZC+J7RyagLZua42uCprA/bFTk1y9oJ9y3bfOObCbmZ+2M89yTG0GWc7tocqloe7OXzwye 3HDL55BBTvmu01dJat/l5z8TxUS2E2s6I7FNelXJ5IfJK4XamrYUkmbiC5XKjQrJlawGCm+f6yvE t9LmXkn7zz9iblvRe17G5D/yNm1CF+X0n0PqDT3THSleEY/+1nGlwyQ/va3R6fTXHspGyKvJ8Y5E OevGHxDZVt4u+o7IeshTk0WRWFPE90reLk4FtzGmIuU0P4ZDSuGm4ziMyEKbqjs+Hka8zCrWUip4 xRLafoik6emk+xmx5Ge/QOQfkGXP7Shwka0dTbtsfgxk3kHUdSpj5x1ToEVfNSuvteHUJ0nKGaVa YwmoHHV0xr6f3lV/tkQ36+U5n91oLeYIbKbOC57/XD7TUeO2cOJ6td1ypOTK1HcDeQlP7WY7akIX 9rQm2g2VJRSOJdrO9uSLBkqrCAvJY1se+qU+9FNkF6hVRfEZZRueSbqoiGqucQ6fNVnvoayxsnW1 vvBNlPPytpHFKc818WTuOZ1sEaoYyRUQllJLCTbmRkUEjNsaF/W0H0XVycavjaRxkQqC5bu8xcXm A6qYeClaf2T55dv2G9y8U3JemStW5QTMX04cqU+sLe1G/WgiIAW74PpMl/ZP6OKwwvH4nrjqckJF 70VP8bUWZBPnSd8htVXS54PhdjPhfSc42kPhg5kiVJ2ox1MgMltUVdaRWiyrlgdP6GriFUKmdR3T ucjHoy6XpcL2UCUpOlohdGIzNnaqUyo8o4MWZNs0WqyQBxYWcqO8KzvshiOxXZfyhE8kx3L7Gpce rZ8cxB+Soqcc7m0VFO9bMKx9k3OzauoOZyS21cDibtnavKVA4O30jwc/cYsCoGeSJGdSCPGtaAF0 JAbv8ppw2X1RVYoecBKx3h9Pim5y6r23fLSGUkSA6msehh59b4zGulmCmkl40LdocXzbwcqilIal OdVZrBbqQsgrXf10bhEhYxijJRV+rvMOKsfvW/unqEDnOeeriE6Uwvq6JTItO5ZYJWwUBGt2nPuz /VPA9cAEYAIwAZgATAAmABOACcAEYAIwAZgATAAmABOACfyvBGTfoP4FAAD//wMAUEsDBBQABgAI AAAAIQCiocrBnAEAAFwDAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAJyTQWsbMRCF74X8h0X3WGs7lGK0CsVpyKGlBjvJWdXOekW0ktBMFru/ vtpdHMttcultNO/x+DQjidtDZ4seIhrvKjaflawAp31t3L5ij7v76y+sQFKuVtY7qNgRkN3Kq09i E32ASAawSBEOK9YShRXnqFvoFM6S7JLS+NgpSse4575pjIY7r187cMQXZfmZw4HA1VBfh7dANiWu evrf0NrrgQ+fdseQgKX4GoI1WlG6pfxhdPToGyq+HTRYwXNRJLot6Ndo6ChLwfOj2GplYZ2CZaMs guDnhngANQxto0xEKXpa9aDJxwLN7zS2BSt+KYQBp2K9ikY5SliDbTqMtQ1IUT77+IItAKHgyTA1 xzL35rW5kcvRkIpL4xAwgSThEnFnyAL+bDYq0jvEy5x4ZJh4J5ztwDfP+d5IR2nxsTSR5rcaB5X4 /iJa+y4od8z2tfYx+DhuUfCTLL4b94KPYefvFMFpM5dNsW1VhDot86SfG+IhLSXaIWTdKreH+uT5 Vxje0dP0WeT8ZlYuy/REsp7g528h/wAAAP//AwBQSwMEFAAGAAgAAAAhACG8Y2EeAgAAigUAABQA AAB4bC90YWJsZXMvdGFibGUxLnhtbGyUUW/aMBDH3yftO1h+H8G0pbQCKqBDa0ULInTa65EY4smx I9u0zbffJSEZrvyYy/939t39z+OHz1ySd26s0GpCWa9PCVeJToU6TujbbvljRIl1oFKQWvEJLbml D9Pv38YO9pITpJWd0My54j6KbJLxHGxPF1zhn4M2OTj8NMfIFoZDajPOXS6jQb8/jHIQihKR4rGU KMgx+65Kil+psIWE8tULGn6Y0Bm73w4GlDjtQNqt/ogz/YE3x3tneAA3GHr8PDxh1kGVCBycP9nd hWSuDWpbIcJ1OV6Ujeh0DCenl0I6bsjl8dG0qX+h5SlXliT6pBzWUSF1puaHX9ybhSP3r3RL/Uw1 gNU13diAgZxUTfCpYYi68qnfIH3oJgRdt9Ajt4kRhUMX+Nh1CLtpsd7rz52vvwrph61+Hf/x5YOQ /LaVi3Xsy1lIjnNt+vUM70CeFzOf6YcY1lU+x9El5QKsk36b70IcbkNz1kylRovUO2oUIlhn7s2v jScPDp91vUJ5zJOV2HtQcPbsv2VKl30ZYXDwrOvxy8KUhdOY4WJXglNHd7fGLBvIY9CAVYYFlzJ2 pcRtnkMa7Ehn1e1pX3o5gnZgnd3W+K7E8cpDgpZguNHNnJROee+v9ZDaEdHFntrz1tb3flIHfYbr 56gOvvBUnHIcpcXnZimMdc2G1w9PFVuhgb6EqsfJ4VJxfCDPZKPoohcXmf4DAAD//wMAUEsBAi0A FAAGAAgAAAAhAMXdE0CLAQAAlAYAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54 bWxQSwECLQAUAAYACAAAACEAtVUwI/UAAABMAgAACwAAAAAAAAAAAAAAAADEAwAAX3JlbHMvLnJl bHNQSwECLQAUAAYACAAAACEA3gn9KAIBAADUAwAAGgAAAAAAAAAAAAAAAADqBgAAeGwvX3JlbHMv d29ya2Jvb2sueG1sLnJlbHNQSwECLQAUAAYACAAAACEAs9AwoGIBAAByAgAADwAAAAAAAAAAAAAA AAAsCQAAeGwvd29ya2Jvb2sueG1sUEsBAi0AFAAGAAgAAAAhAPtipW2UBgAApxsAABMAAAAAAAAA AAAAAAAAuwoAAHhsL3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEAQb/4YNkAAADKAQAA IwAAAAAAAAAAAAAAAACAEQAAeGwvd29ya3NoZWV0cy9fcmVscy9zaGVldDEueG1sLnJlbHNQSwEC LQAUAAYACAAAACEA++hdR2ABAAB1AgAAGAAAAAAAAAAAAAAAAACaEgAAeGwvd29ya3NoZWV0cy9z aGVldDIueG1sUEsBAi0AFAAGAAgAAAAhAPvoXUdgAQAAdQIAABgAAAAAAAAAAAAAAAAAMBQAAHhs L3dvcmtzaGVldHMvc2hlZXQzLnhtbFBLAQItABQABgAIAAAAIQBPzkOd4gsAAHhIAAAYAAAAAAAA AAAAAAAAAMYVAAB4bC93b3Jrc2hlZXRzL3NoZWV0MS54bWxQSwECLQAUAAYACAAAACEAsQ952xYH AACdTAAADQAAAAAAAAAAAAAAAADeIQAAeGwvc3R5bGVzLnhtbFBLAQItABQABgAIAAAAIQDZ+92N XwMAAMIKAAAUAAAAAAAAAAAAAAAAAB8pAAB4bC9zaGFyZWRTdHJpbmdzLnhtbFBLAQItABQABgAI AAAAIQB4nYyAUAEAAGYCAAARAAAAAAAAAAAAAAAAALAsAABkb2NQcm9wcy9jb3JlLnhtbFBLAQIt ABQABgAIAAAAIQAe1kscQQcAAPQeAAAnAAAAAAAAAAAAAAAAADcvAAB4bC9wcmludGVyU2V0dGlu Z3MvcHJpbnRlclNldHRpbmdzMS5iaW5QSwECLQAUAAYACAAAACEAoqHKwZwBAABcAwAAEAAAAAAA AAAAAAAAAAC9NgAAZG9jUHJvcHMvYXBwLnhtbFBLAQItABQABgAIAAAAIQAhvGNhHgIAAIoFAAAU AAAAAAAAAAAAAAAAAI85AAB4bC90YWJsZXMvdGFibGUxLnhtbFBLBQYAAAAADwAPAPQDAADfOwAA AAA= --_004_4E1F6AAD24975D4BA5B168042967394366741FA4TK5EX14MBXC285r_-- From ietf@augustcellars.com Mon Jul 23 22:13:39 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E7E11E811C for ; Mon, 23 Jul 2012 22:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 948IPNt22RZ2 for ; Mon, 23 Jul 2012 22:13:38 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id C649E11E810E for ; Mon, 23 Jul 2012 22:13:38 -0700 (PDT) Received: from Tobias (50-39-234-129.bvtn.or.frontiernet.net [50.39.234.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id F3ABF2CA09; Mon, 23 Jul 2012 22:13:37 -0700 (PDT) From: "Jim Schaad" To: "'Manger, James H'" , References: <005a01cd67b0$5b8e2640$12aa72c0$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F7E0FFED@WSMSG3153V.srv.dir.telstra.com> <008301cd6890$ca175b00$5e461100$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F7F01463@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F7F01463@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 23 Jul 2012 22:12:11 -0700 Message-ID: <00fd01cd695a$e37a7940$aa6f6bc0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFWdvosCN5oUN1jbpGPIyDC6pDmHAFwkqzEAXlSU0wDSNARgZf0Maag Content-Language: en-us Subject: Re: [jose] JSE/JWE algorithm factoring X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 05:13:39 -0000 > -----Original Message----- > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > Sent: Sunday, July 22, 2012 11:19 PM > To: Jim Schaad; jose@ietf.org > Subject: RE: [jose] JSE/JWE algorithm factoring >=20 > > > Wouldn't it be simpler to have a specific field to indicate the = mode? > > > Each mode defines how many dot-separated segments there are, what > > > they hold, and which other header fields indicate the algs the = mode uses. > > > If you don't recognize the mode you cannot process the message. >=20 > > I agree that having modes can be useful, but I am not sure that it = is > > going to help in this situation. The code for dealing with the = above > > is actually very simple logic > > > > if (pkAlg exists) { > > if (pkAlg is a signature algorithm) do signature processing and > > return > > else if (pkAlg is a known algorithm) { > > find the key > > process the value > > } > > Else throw an error > > } > > > > If (cwAlg exists ) { > > If unknown algorithm throw error > > If no key then find the key > > Process the value > > } > > > > If (cAlg exists) { > > If unknown alg then throw error > > If no key known then find the key > > If encryption alg then process as encryption and return > > If mac alg then process as mac and return } > > > > Throw an error >=20 >=20 > So let's say we publish JOSE v1; you implement this code; then 6 = months later > JOSE v2 adds the option to compress the data before signing it (by = allowing > "zip":"DEFLATE" in a JWS). Your code happily processes the message; = verifies > the signature; then returns DEFLATE gibberish instead of the expected > content. Yuck. > A "MUST understand everything" rule (if specified and *IMPLEMENTED > everywhere*) might save you by triggering an "unsupported field" = error, but > such a rule is wrong for lots of other reasons. > A better approach is for JOSE v2 to defines "t":"sig2". Processing is = the same > as "t":"sig" but if a "zip" field is present the content is = compressed. Your old > code looks at "t":"sig2" and immediately returns "unsupported mode". >=20 > Relying on the presence/absence and values of 3 fields (pkAlg, cwAlg, = cAlg) is > not extensible to new modes. I am not trying to make it extensible to new "modes", I am trying to get = a better way to do the current two modes that we have - signing, mac-ing = and encrypting. If we create a new Fudge mode then it needs to define = its behavior and may or may not use these fields, just like in the = current proposal. >=20 >=20 > > And now you also start getting compounded modes - want a mode that = is > > both agree-wrap-enc and zipped - then you start getting a huge = number > > of possible strings to deal with. >=20 > Not in practice. One mode string can cover lots of "sub-modes" (eg = zipped or > not), as long as the sub-modes are specified when the mode string is > defined. You only need a new mode string when you want something new > that could otherwise be misinterpreted. Instead of every field (about = the > structure, about the keys, about revocation info, about key discovery > options, metadata about the content ) needing to be "MUST understand", > only the mode string needs to be understood. This is the same as for my proposal. >=20 >=20 > We could pick mode strings corresponding to the top-level contentType = in > CMS (eg SignedData, EncryptedData, AuthenticatedData, > AuthEnvelopedData, CompressedData, ). > Or we could be a bit more specific and pick mode strings that cover = particular > key establishment techniques (eg AuthEnvelopedData.KeyTransport, > AuthEnvelopedData.KeyAgreement, AuthEnvelopedData.SymmetricKEK, > AuthEnvelopedData.Password, AuthEnvelopedData.IBE, ). I prefer the = latter > (since we are only likely to specify a subset of key establishment = techniques > at first). >=20 >=20 >=20 > > That is not to say that having some level of modes is not a good = idea. > > I would be more than willing to see the typ field become both > > mandatory and slightly more useful - i.e. encryption vs signature vs > > mac as the processing can be very different in the different cases. >=20 > -- > James Manger From bcampbell@pingidentity.com Wed Jul 25 08:17:04 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A7921F8611 for ; Wed, 25 Jul 2012 08:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.985 X-Spam-Level: X-Spam-Status: No, score=-5.985 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnwlE+0-PfeI for ; Wed, 25 Jul 2012 08:17:03 -0700 (PDT) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by ietfa.amsl.com (Postfix) with ESMTP id 0450621F84DA for ; Wed, 25 Jul 2012 08:17:01 -0700 (PDT) Received: from mail-vc0-f175.google.com ([209.85.220.175]) (using TLSv1) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKUBAN7Uv+mVGDyHHe7lD/zdXK+Bhka/6f@postini.com; Wed, 25 Jul 2012 08:17:02 PDT Received: by vcbfy27 with SMTP id fy27so673138vcb.34 for ; Wed, 25 Jul 2012 08:17:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=FgzkGJucOSYGweObakwx54OnBt7gbqZJ36CJwb7fe3A=; b=Q+RyJYpHi3ii8chYN1pM8ePoLIc/kFIFORfH1xgzfPi91SQwrEJx6+VyRr8E8eRiIt 7Qt8uacc+3WJrFLBwP2lyDI6x9kQHiF4uJY6m96UADOveAVwHrjV9lcEpbsUMX/XzsoH IqghhRhg2J1trhVAvqr8qvX9exT1G7CxNRFGMc123S/MAoYjtNwLJBL2S0bLZ0T3BlFK tsKytPqOG8BzTrSi/kLNNzKz2Jcygsi+Cof6jfn4w5oebFlXF7gU3r4qdOqlCSVuNl19 q92HtXvurgqtBvAmb9VZ9BapeEKtSO0Cemv9uvpjQYvUXps8vAp9fA+aage12KupPRbL gjug== Received: by 10.220.239.209 with SMTP id kx17mr10008410vcb.41.1343229419779; Wed, 25 Jul 2012 08:16:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.162.130 with HTTP; Wed, 25 Jul 2012 08:16:29 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F78D4ADF@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739436657A1B2@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F78D4ADF@WSMSG3153V.srv.dir.telstra.com> From: Brian Campbell Date: Wed, 25 Jul 2012 09:16:29 -0600 Message-ID: To: "Manger, James H" Content-Type: multipart/alternative; boundary=14dae9cdbefb6af49c04c5a8f8bb X-Gm-Message-State: ALoCoQlaKqrJuwKDEj24nGS5ZWiT+jd7x2nldYTqDxGV06Ab9J43RoCDAydrXlrfijufDvaKGPoi Cc: "Richard L. Barnes" , Mike Jones , "jose@ietf.org" Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 15:17:04 -0000 --14dae9cdbefb6af49c04c5a8f8bb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I won't pretend to know what the *right* thing to do is. But I do think James makes a valid point about the temporal interoperability problems that will arise if/when new parameters get introduced down the road. On Sun, Jul 8, 2012 at 6:42 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > Mike, > > >> Implementations MUST understand the entire contents of the > >> header; otherwise, the {JWS|JWE} MUST be rejected. > >> > >> We should drop this restriction. > > Mike replied: > > Since this is a security protocol, the way I see it, use of a not- > > understood parameter SHOULD break implementations if they=92re not > > prepared to handle them (or at least them cause them to reject the > > input). For example, if we hypothetically added an audience > > restriction parameter, ignoring it would be a security error. (The > > need for audience restriction is being heavily discussed in the OAuth > > WG right now, and real exploits that have occurred for the lack of it, > > so this example is real and fresh on my mind.) If not understood, a > > token containing an audience restriction MUST be rejected. > > > Consider an ecosystem with hundreds of servers and thousands of client > apps all using a protocol involving JOSE messages that has been operating > for a few years. A researcher finds a vulnerability in the protocol and > responsibly discloses it to selected servers. The fix is to add an audien= ce > restriction parameter "aud". > > What should a server do? > > If it adds the "aud" parameter immediately, every (compliant) client app > will immediately break. The outage will last until every app is updated, > which will takes weeks, months=85? Total system shutdown to fix a flaw th= at > is currently theoretical=85 heads will role. > > If a server announces that it will add the "aud" parameter in, say, 3 > months to give time for app updates then it has just disclosed a > vulnerability and given attackers a 3 month window to exploit it. Many wi= ll > clamour for an immediate fix; many will say they need longer to fix apps; > it will still break for many users in 3 months=85 heads will role. > > On the other hand, if the spec says unknown parameters MUST be ignored > then the server can immediately add the "aud" parameter, and immediately > tell client apps to start supporting it. Each app is protected as soon as > it adds support. > If actual exploits need to be stopped the server can still shutdown the > whole system, or just selected client apps, or selected users. > > > X.509 certificates are an interesting example for comparison. Certs are > security-related, just like JOSE messages. Certs allow unrecognised > additions (eg non-critical extensions). These have been very widely used = to > deploy new functionality. > > The X.509 spec (or at least its IETF profile) has one item that MUST be > understood if added: the name-constraints extension. This extension shoul= d > be really useful for security. However, because adding it in the > spec-compliant MUST-understand manner will break some clients, it has > barely been deployed for over a decade. > > > Lets drop the "MUST understand everything" requirement. > > -- > James Manger > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --14dae9cdbefb6af49c04c5a8f8bb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I won't pretend to know what the *right* thing to do is. But I do think= James makes a valid point about the temporal interoperability problems tha= t will arise if/when new parameters get introduced down the road.

On Sun, Jul 8, 2012 at 6:42 PM, Manger, James H = <James.H.Manger@team.telstra.com> wrote:
Mike,

>> =A0 =A0Implementations MUST understand the entire contents of the<= br> >> =A0 =A0header; otherwise, the {JWS|JWE} MUST be rejected.
>>
>> We should drop this restriction.

Mike replied:
> Since this is a security protocol, the way I see it, use of a not-
> understood parameter SHOULD break implementations if they=92re not
> prepared to handle them (or at least them cause them to reject the
> input). =A0For example, if we hypothetically added an audience
> restriction parameter, ignoring it would be a security error. =A0(The<= br> > need for audience restriction is being heavily discussed in the OAuth<= br> > WG right now, and real exploits that have occurred for the lack of it,=
> so this example is real and fresh on my mind.) =A0If not understood, a=
> token containing an audience restriction MUST be rejected.


Consider an ecosystem with hundreds of servers and thousands of client apps= all using a protocol involving JOSE messages that has been operating for a= few years. A researcher finds a vulnerability in the protocol and responsi= bly discloses it to selected servers. The fix is to add an audience restric= tion parameter "aud".

What should a server do?

If it adds the "aud" parameter immediately, every (compliant) cli= ent app will immediately break. The outage will last until every app is upd= ated, which will takes weeks, months=85? Total system shutdown to fix a fla= w that is currently theoretical=85 heads will role.

If a server announces that it will add the "aud" parameter in, sa= y, 3 months to give time for app updates then it has just disclosed a vulne= rability and given attackers a 3 month window to exploit it. Many will clam= our for an immediate fix; many will say they need longer to fix apps; it wi= ll still break for many users in 3 months=85 heads will role.

On the other hand, if the spec says unknown parameters MUST be ignored then= the server can immediately add the "aud" parameter, and immediat= ely tell client apps to start supporting it. Each app is protected as soon = as it adds support.
If actual exploits need to be stopped the server can still shutdown the who= le system, or just selected client apps, or selected users.


X.509 certificates are an interesting example for comparison. Certs are sec= urity-related, just like JOSE messages. Certs allow unrecognised additions = (eg non-critical extensions). These have been very widely used to deploy ne= w functionality.

The X.509 spec (or at least its IETF profile) has one item that MUST be und= erstood if added: the name-constraints extension. This extension should be = really useful for security. However, because adding it in the spec-complian= t MUST-understand manner will break some clients, it has barely been deploy= ed for over a decade.


Lets drop the "MUST understand everything" requirement.

--
James Manger
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--14dae9cdbefb6af49c04c5a8f8bb-- From Michael.Jones@microsoft.com Wed Jul 25 12:23:26 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB21421F8732 for ; Wed, 25 Jul 2012 12:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.777 X-Spam-Level: X-Spam-Status: No, score=-3.777 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eXub0p485RY for ; Wed, 25 Jul 2012 12:23:23 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id CBFCA21F8717 for ; Wed, 25 Jul 2012 12:23:21 -0700 (PDT) Received: from mail81-am1-R.bigfish.com (10.3.201.251) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Wed, 25 Jul 2012 19:23:19 +0000 Received: from mail81-am1 (localhost [127.0.0.1]) by mail81-am1-R.bigfish.com (Postfix) with ESMTP id E8D5660155 for ; Wed, 25 Jul 2012 19:23:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VS0(zzc85fhzz1202hzz8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah34h) Received-SPF: pass (mail81-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail81-am1 (localhost.localdomain [127.0.0.1]) by mail81-am1 (MessageSwitch) id 1343244196674719_2907; Wed, 25 Jul 2012 19:23:16 +0000 (UTC) Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.234]) by mail81-am1.bigfish.com (Postfix) with ESMTP id 9ACE440047 for ; Wed, 25 Jul 2012 19:23:16 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 25 Jul 2012 19:23:13 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0309.003; Wed, 25 Jul 2012 19:23:03 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Updated table of platform support for JWA Algorithms Thread-Index: Ac1qmuBm81ze+PpdQ/OOwLTf7CTxHA== Date: Wed, 25 Jul 2012 19:23:02 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366743D32@TK5EX14MBXC285.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/mixed; boundary="_004_4E1F6AAD24975D4BA5B168042967394366743D32TK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [jose] Updated table of platform support for JWA Algorithms X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 19:23:26 -0000 --_004_4E1F6AAD24975D4BA5B168042967394366743D32TK5EX14MBXC285r_ Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366743D32TK5EX14MBXC285r_" --_000_4E1F6AAD24975D4BA5B168042967394366743D32TK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As discussed at the W3C WebCrypto working group meeting today. -- Mike Usage Param Name Param Val Description .NET OSX iOS Java JCA BouncyCastle Android PHP PHPSecLib Python M2Crypto PyCrypto Ruby OpenSSL node.js JWS/JWE alg/int HS256 HMAC w/ SHA-256 hash YES YES YES YES YES YES YES YES YES YES YES YES YES YES JWS/JWE alg/int HS384 HMAC w/ SHA-384 hash YES YES YES YES YES YES YES YES YES YES YES YES YES YES JWS/JWE alg/int HS512 HMAC w/ SHA-512 hash YES YES YES YES YES YES YES YES YES YES YES YES YES YES JWS alg RS256 RSA w/ SHA-256 hash YES YES YES YES YES YES NO YES NO YES YES YES YES YES JWS alg RS384 RSA w/ SHA-384 hash YES YES YES YES YES YES NO YES NO YES YES YES YES YES JWS alg RS512 RSA w/ SHA-512 hash YES YES YES YES YES YES NO YES NO YES YES YES YES YES JWS alg ES256 ECDSA w/ P-256 curve and SHA-256 hash YES YES NO YES? YES YES NO NO NO YES NO YES YES JWS alg ES384 ECDSA w/ P-384 curve and SHA-384 hash YES YES NO YES? YES YES NO NO NO YES NO YES YES JWS alg ES512 ECDSA w/ P-521 curve and SHA-512 hash YES YES NO YES? YES YES NO NO NO YES NO YES YES JWE alg RSA1_5 RSAES-PKCS1-V1_5 YES YES YES YES YES YES YES YES NO YES YES YES YES JWE alg RSA-OAEP RSAES OAEP YES YES? YES YES YES YES NO YES NO YES YES YES YES JWE alg ECDH-ES Elliptic Curve Diffie-Hellman Ephemeral Static NO* NO? NO YES* YES* YES* NO NO NO YES? NO YES YES JWE alg A128KW AES Key Wrap w/ 128 bit key NO YES YES YES YES NO NO NO YES YES YES? YES? JWE alg A256KW AES Key Wrap w/ 256 bit key NO YES YES YES YES NO NO NO YES YES YES? YES? JWE enc A128CBC AES CBC w/ 128 bit key YES* YES YES* YES* YES* YES* YES* NO YES* YES* YES* YES* JWE enc A256CBC AES CBC w/ 256 bit key YES* YES YES* YES* YES* YES* YES* NO YES* YES* YES* YES* JWE enc A128GCM AES GCM w/ 128 bit key NO NO? NO NO YES YES NO NO NO NO? NO YES YES JWE enc A256GCM AES GCM w/ 256 bit key NO NO? NO NO YES YES NO NO NO NO? NO YES YES JWE kdf CS256 Concat Key Distribution Function (KDF) NO NO NO NO NO NO NO NO NO NO NO JWE kdf CS384 Concat Key Distribution Function (KDF) NO NO NO NO NO NO NO NO NO NO NO JWE kdf CS512 Concat Key Distribution Function (KDF) NO NO NO NO NO NO NO NO NO NO NO YES - Support built into library/platform BouncyCastle is a crypto lib for Java YES* - Supported but other non-supported code required (Concat KDF) Android uses BouncyCastle NO - Not supported in library/platform PHPSecLib is a crypto lib for PHP NO* - Not supported in the specified configuration (w/ Concat KDF) M2Crypto is a crypto lib for Python (blank) - Unknown PyCrypto is a crypto lib for Python ? - Answer is a first impression but requires more research PHP version 5.2 PHPSecLib version 0.3.0 PyCrypto version 2.6 Ruby 1.9.3 with ruby-openssl Java 7 OS X 10.6 (Snow Leopard) --_000_4E1F6AAD24975D4BA5B168042967394366743D32TK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As discussed at the W3C WebCrypto working group meet= ing today.

 

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

 

Usage

Param Name=

Param Val<= /span>

Description

.NET

OSX=

iOS=

Java JCA

BouncyCastle

Android

PHP=

PHPSecLib<= /span>

Python

M2Crypto

PyCrypto

Ruby

OpenSSL

node.js

JWS/JWE

alg/int

HS256

HMAC w/ SHA-256 hash 

YES<= /p>

YES =

YES =

YES =

YES =

YES =

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

JWS/JWE

alg/int

HS384

HMAC w/ SHA-384 hash

YES<= /p>

YES<= /p>

YES =

YES =

YES =

YES =

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

JWS/JWE

alg/int

HS512

HMAC w/ SHA-512 hash

YES<= /p>

YES =

YES =

YES =

YES =

YES =

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

JWS

alg

RS256

RSA w/ SHA-256 hash

YES<= /p>

YES =

YES =

YES =

YES =

YES =

NO

YES<= /p>

NO

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

JWS

alg

RS384

RSA w/ SHA-384 hash 

YES<= /p>

YES =

YES =

YES =

YES =

YES =

NO

YES<= /p>

NO

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

JWS

alg

RS512

RSA w/ SHA-512 hash

YES<= /p>

YES =

YES =

YES =

YES =

YES =

NO

YES<= /p>

NO

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

JWS

alg

ES256

ECDSA w/ P-256 curve and SHA-256 ha= sh

YES<= /p>

YES =

NO

YES?

YES =

YES =

NO

NO

NO

YES<= /p>

NO

 =

YES<= /p>

YES<= /p>

JWS

alg

ES384

ECDSA w/ P-384 curve and SHA-384 ha= sh 

YES<= /p>

YES =

NO

YES?

YES =

YES =

NO

NO

NO

YES<= /p>

NO

 =

YES<= /p>

YES<= /p>

JWS

alg

ES512

ECDSA w/ P-521 curve and SHA-512 ha= sh

YES<= /p>

YES =

NO

YES? <= /p>

YES =

YES =

NO

NO

NO

YES<= /p>

NO

 =

YES<= /p>

YES<= /p>

JWE

alg

RSA1_5

RSAES-PKCS1-V1_5<= /p>

YES<= /p>

YES =

YES =

YES =

YES =

YES =

YES<= /p>

YES<= /p>

NO

YES<= /p>

YES<= /p>

 =

YES<= /p>

YES<= /p>

JWE

alg

RSA-OAEP

RSAES OAEP

YES<= /p>

YES? <= /p>

YES =

YES =

YES =

YES =

NO

YES<= /p>

NO

YES<= /p>

YES<= /p>

 =

YES<= /p>

YES<= /p>

JWE

alg

ECDH-ES

Elliptic Curve Diffie-Hellman Ephem= eral Static

NO*<= /p>

NO?

NO

YES*

YES*

YES*

NO

NO

NO

YES?

NO

 =

YES<= /p>

YES<= /p>

JWE

alg

A128KW

AES Key Wrap w/ 128 bit key

NO

YES =

YES =

 =

YES =

YES =

NO

NO

NO

YES<= /p>

YES<= /p>

 =

YES? <= /p>

YES? <= /p>

JWE

alg

A256KW

AES Key Wrap w/ 256 bit key

NO

YES =

YES =

 =

YES =

YES =

NO

NO

NO

YES<= /p>

YES<= /p>

 =

YES?

YES?

JWE

enc

A128CBC

AES CBC w/ 128 bit key

YES*

YES =

 =

YES*

YES*

YES*

YES*

YES*

NO

YES*

YES*

 =

YES*

YES*

JWE

enc

A256CBC

AES CBC w/ 256 bit key

YES*

YES =

 =

YES*

YES*

YES*

YES*

YES*

NO

YES*

YES*

 =

YES*

YES*

JWE

enc

A128GCM

AES GCM w/ 128 bit key

NO

NO?

NO

NO

YES =

YES =

NO

NO

NO

NO?

NO

 =

YES<= /p>

YES<= /p>

JWE

enc

A256GCM

AES GCM w/ 256 bit key

NO

NO?

NO

NO

YES =

YES =

NO

NO

NO

NO?

NO

 =

YES<= /p>

YES<= /p>

JWE

kdf

CS256

Concat Key Distribution Function (K= DF)

NO

 =

 =

NO

NO

NO

NO

NO

NO

NO

NO

 =

NO

NO

JWE

kdf

CS384

Concat Key Distribution Function (K= DF)

NO

 =

 =

NO

NO

NO

NO

NO

NO

NO

NO

 =

NO

NO

JWE

kdf

CS512

Concat Key Distribution Function (K= DF)

NO

 =

 =

NO

NO

NO

NO

NO

NO

NO

NO

 =

NO

NO

YES - Support built in= to library/platform

BouncyCastle is a cry= pto lib for Java

YES* - Supported but oth= er non-supported code required (Concat KDF)

Android uses BouncyCa= stle

NO - Not supported in = library/platform

PHPSecLib is a crypto= lib for PHP

NO* - Not supported in= the specified configuration (w/ Concat KDF)

M2Crypto is a crypto = lib for Python

(blank) - Unknown

PyCrypto is a crypto = lib for Python

? - Answer is a first im= pression but requires more research

PHP version 5.2

PHPSecLib version 0.3.0<= o:p>

PyCrypto version 2.6

Ruby 1.9.3 with ruby-ope= nssl

Java 7=

OS X 10.6 (Snow Leopard)=

 

--_000_4E1F6AAD24975D4BA5B168042967394366743D32TK5EX14MBXC285r_-- --_004_4E1F6AAD24975D4BA5B168042967394366743D32TK5EX14MBXC285r_ Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="Support for JWA Crypto Algorithms.xlsx" Content-Description: Support for JWA Crypto Algorithms.xlsx Content-Disposition: attachment; filename="Support for JWA Crypto Algorithms.xlsx"; size=16700; creation-date="Thu, 19 Jul 2012 17:04:00 GMT"; modification-date="Wed, 25 Jul 2012 19:02:34 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDF3RNAiwEAAJQGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM VclqwzAQvRf6D0bXEittoZQSp4cuxzaQ9AMUa2KL2JLQTNPk7ztWFtqQBZNAe7GwpXnLDHruPc7r KplBQONsJq7TrkjA5k4bW2TiY/TauRcJkrJaVc5CJhaA4rF/edEbLTxgwtUWM1ES+QcpMS+hVpg6 D5Z3Ji7Uivg1FNKrfKoKkDfd7p3MnSWw1KEGQ/R7zzBRnxUlL3P+vFQyNlYkT8tzDVUmlPeVyRWx UDmzeouk4yYTk4N2+WfN0Cn6AEpjCUB1lfpgmDEMgYiNoZA7OQNU2I505SrlyigMS+Pxiq3vYWh2 9rta1b3zOILRkAxUoDdVs3c5r+SXC9Oxc9P0MEjb1sQWpbUydq37AH88jDIu12cW0viLwC113PwT Hbd/pIP4zoGMz9NHEmGODABpUQGe2e0S9BhzqQLoIfFtLs4u4Cf2ER2kxtwBGZfTe/47qiLoIX6O uEFwHjlFA7SfwjqymuqOZyAIZGATWrsu/4aRI7g94VYwQ5PxGvQObhn/Kf1vAAAA//8DAFBLAwQU AAYACAAAACEAtVUwI/UAAABMAgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySz07DMAzG70i8Q+T7 6m5ICKGlu0xIuyFUHsAk7h+1jaMkQPf2hAOCSmPb0fbnzz9b3u7maVQfHGIvTsO6KEGxM2J712p4 rZ9WD6BiImdpFMcajhxhV93ebF94pJSbYtf7qLKLixq6lPwjYjQdTxQL8exypZEwUcphaNGTGahl 3JTlPYa/HlAtPNXBaggHeweqPvo8+bK3NE1veC/mfWKXToxAnhM7y3blQ2YLqc/bqJpCy0mDFfOc 0xHJ+yJjA54m2lxP9P+2OHEiS4nQSODzPN+Kc0Dr64Eun2ip+L3OPOKnhOFNZPhhwcUPVF8AAAD/ /wMAUEsDBBQABgAIAAAAIQDeCf0oAgEAANQDAAAaAAgBeGwvX3JlbHMvd29ya2Jvb2sueG1sLnJl bHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8k89qwzAMxu+DvYPRfXGSbmWU Or2MQa9b9wAmUeLQxDaW9idvP5NDukDJLqEXgyT8fT/Qp/3hp+/EFwZqnVWQJSkItKWrWtso+Di9 PjyDINa20p2zqGBAgkNxf7d/w05z/ESm9SSiiiUFhtnvpKTSYK8pcR5tnNQu9JpjGRrpdXnWDco8 Tbcy/NWAYqYpjpWCcKw2IE6Dj87/a7u6bkt8ceVnj5avWMhvF85kEDmK6tAgK5haJMfJJonEIK/D 5DeGyZdgshvDZEsw2zVhyOiA1TuHmEK6rGrWXoJ5WhWGhy6GfgoMjfWS/eOa9hxPCS/uYynHd9qH nN1i8QsAAP//AwBQSwMEFAAGAAgAAAAhALq0cdpiAQAAcQIAAA8AAAB4bC93b3JrYm9vay54bWyM Uk1PwzAMvSPxH6LcWdruQ9u0dhICxC4IibGdQ+Ou0dKkSlK6/XvcTC1DcOBkO3559nvJan2qFPkE 66TRKY1HESWgcyOkPqT0fft0N6fEea4FV0ZDSs/g6Dq7vVm1xh4/jDkSJNAupaX39ZIxl5dQcTcy NWjsFMZW3GNpD8zVFrhwJYCvFEuiaMYqLjW9MCztfzhMUcgcHkzeVKD9hcSC4h7Xd6WsHc1WhVSw uygivK5feIV7nxQlijv/KKQHkdIplqaFHwe2qe8bqbC7GEdjyrJB5KslAgreKL9FeT07+pVMkmTW ITsrdhJa932pK8lpL7UwbUonc7T23FdxglUbWnspfIlU8XSR9GfPIA+lT+ksxlvIzq7og4E4JkSi g7q3ztQYX6qLGxSAuV1KTOxGxB3DLzTOGtCYD+jkT/T4Co35gA4usUCEK+Vc5WhVF8ISk+ksCdNZ /1uyLwAAAP//AwBQSwMEFAAGAAgAAAAhAPtipW2UBgAApxsAABMAAAB4bC90aGVtZS90aGVtZTEu eG1s7FlPb9s2FL8P2HcgdG9tJ7YbB3WK2LGbrU0bxG6HHmmZllhTokDSSX0b2uOAAcO6YZcBu+0w bCvQArt0nyZbh60D+hX2SEqyGMtL0gYb1tWHRCJ/fP/f4yN19dqDiKFDIiTlcdurXa56iMQ+H9M4 aHt3hv1LGx6SCsdjzHhM2t6cSO/a1vvvXcWbKiQRQbA+lpu47YVKJZuVivRhGMvLPCExzE24iLCC VxFUxgIfAd2IVdaq1WYlwjT2UIwjIHt7MqE+QUNN0tvKiPcYvMZK6gGfiYEmTZwVBjue1jRCzmWX CXSIWdsDPmN+NCQPlIcYlgom2l7V/LzK1tUK3kwXMbVibWFd3/zSdemC8XTN8BTBKGda69dbV3Zy +gbA1DKu1+t1e7WcngFg3wdNrSxFmvX+Rq2T0SyA7OMy7W61Ua27+AL99SWZW51Op9FKZbFEDcg+ 1pfwG9VmfXvNwRuQxTeW8PXOdrfbdPAGZPHNJXz/SqtZd/EGFDIaT5fQ2qH9fko9h0w42y2FbwB8 o5rCFyiIhjy6NIsJj9WqWIvwfS76ANBAhhWNkZonZIJ9iOIujkaCYs0AbxJcmLFDvlwa0ryQ9AVN VNv7MMGQEQt6r55//+r5U/Tq+ZPjh8+OH/50/OjR8cMfLS1n4S6Og+LCl99+9ufXH6M/nn7z8vEX 5XhZxP/6wye//Px5ORAyaCHRiy+f/PbsyYuvPv39u8cl8G2BR0X4kEZEolvkCB3wCHQzhnElJyNx vhXDEFNnBQ6Bdgnpngod4K05ZmW4DnGNd1dA8SgDXp/dd2QdhGKmaAnnG2HkAPc4Zx0uSg1wQ/Mq WHg4i4Ny5mJWxB1gfFjGu4tjx7W9WQJVMwtKx/bdkDhi7jMcKxyQmCik5/iUkBLt7lHq2HWP+oJL PlHoHkUdTEtNMqQjJ5AWi3ZpBH6Zl+kMrnZss3cXdTgr03qHHLpISAjMSoQfEuaY8TqeKRyVkRzi iBUNfhOrsEzIwVz4RVxPKvB0QBhHvTGRsmzNbQH6Fpx+A0O9KnX7HptHLlIoOi2jeRNzXkTu8Gk3 xFFShh3QOCxiP5BTCFGM9rkqg+9xN0P0O/gBxyvdfZcSx92nF4I7NHBEWgSInpmJEl9eJ9yJ38Gc TTAxVQZKulOpIxr/XdlmFOq25fCubLe9bdjEypJn90SxXoX7D5boHTyL9wlkxfIW9a5Cv6vQ3ltf oVfl8sXX5UUphiqtGxLba5vOO1rZeE8oYwM1Z+SmNL23hA1o3IdBvc4cOkl+EEtCeNSZDAwcXCCw WYMEVx9RFQ5CnEDfXvM0kUCmpAOJEi7hvGiGS2lrPPT+yp42G/ocYiuHxGqPj+3wuh7Ojhs5GSNV YM60GaN1TeCszNavpERBt9dhVtNCnZlbzYhmiqLDLVdZm9icy8HkuWowmFsTOhsE/RBYuQnHfs0a zjuYkbG2u/VR5hbjhYt0kQzxmKQ+0nov+6hmnJTFypIiWg8bDPrseIrVCtxamuwbcDuLk4rs6ivY Zd57Ey9lEbzwElA7mY4sLiYni9FR22s11hoe8nHS9iZwVIbHKAGvS91MYhbAfZOvhA37U5PZZPnC m61MMTcJanD7Ye2+pLBTBxIh1Q6WoQ0NM5WGAIs1Jyv/WgPMelEKlFSjs0mxvgHB8K9JAXZ0XUsm E+KrorMLI9p29jUtpXymiBiE4yM0YjNxgMH9OlRBnzGVcONhKoJ+ges5bW0z5RbnNOmKl2IGZ8cx S0KclludolkmW7gpSLkM5q0gHuhWKrtR7vyqmJS/IFWKYfw/U0XvJ3AFsT7WHvDhdlhgpDOl7XGh Qg5VKAmp3xfQOJjaAdECV7wwDUEFd9TmvyCH+r/NOUvDpDWcJNUBDZCgsB+pUBCyD2XJRN8pxGrp 3mVJspSQiaiCuDKxYo/IIWFDXQObem/3UAihbqpJWgYM7mT8ue9pBo0C3eQU882pZPnea3Pgn+58 bDKDUm4dNg1NZv9cxLw9WOyqdr1Znu29RUX0xKLNqmdZAcwKW0ErTfvXFOGcW62tWEsarzUy4cCL yxrDYN4QJXCRhPQf2P+o8Jn94KE31CE/gNqK4PuFJgZhA1F9yTYeSBdIOziCxskO2mDSpKxp09ZJ Wy3brC+40835njC2luws/j6nsfPmzGXn5OJFGju1sGNrO7bS1ODZkykKQ5PsIGMcY76UFT9m8dF9 cPQOfDaYMSVNMMGnKoGhhx6YPIDktxzN0q2/AAAA//8DAFBLAwQUAAYACAAAACEAQb/4YNkAAADK AQAAIwAAAHhsL3dvcmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzrJHBTsMwDEDvSPxD5DtJ uwNCaOkuCGlXGB/gpW4b0TpRbBD7e4J2odMkLpws2/Lzk73dfS2z+aQiMbGH1jZgiEPqI48e3g7P dw9gRJF7nBOThxMJ7Lrbm+0Lzah1SKaYxVQKi4dJNT86J2GiBcWmTFw7QyoLak3L6DKGdxzJbZrm 3pXfDOhWTLPvPZR9vwFzOOW6+W92GoYY6CmFj4VYr6xwiseZKhDLSOrB2nNFzqG1VRbcdY/2Pz1y iaxUXkm1HlpWRhc9d5G39hj5R9KtPtB9AwAA//8DAFBLAwQUAAYACAAAACEA++hdR2ABAAB1AgAA GAAAAHhsL3dvcmtzaGVldHMvc2hlZXQyLnhtbIySwWrDMAyG74O9g/G9cbp16xqSlEEp62Ewxra7 4yiJaWwF213bt5+SkDLopTcJSZ9//XK6PpmW/YLzGm3G51HMGViFpbZ1xr+/trMXznyQtpQtWsj4 GTxf5/d36RHd3jcAgRHB+ow3IXSJEF41YKSPsANLlQqdkYFSVwvfOZDlMGRa8RDHz8JIbflISNwt DKwqrWCD6mDAhhHioJWB9PtGd36iGXULzki3P3QzhaYjRKFbHc4DlDOjkl1t0cmipb1P84VUE3tI rvBGK4ceqxARToxCr3deiZUgUp6WmjbobWcOqoy/zrnI08GcHw1H/y9mvdcF4r4v7MqMx32ruOrd Dl5/OFZCJQ9t+MTjG+i6CXTYRbQg9f0SSXnegFfkHoGix8urGxkkYTtZw7t0tbaetVANTUvO3MiJ I4oDdv3o8omzAkNAM2UNnRfojD2WVYhhSnq5lw+T/wEAAP//AwBQSwMEFAAGAAgAAAAhAPvoXUdg AQAAdQIAABgAAAB4bC93b3Jrc2hlZXRzL3NoZWV0My54bWyMksFqwzAMhu+DvYPxvXG6desakpRB KethMMa2u+MoiWlsBdtd27efkpAy6KU3CUmff/1yuj6Zlv2C8xptxudRzBlYhaW2dca/v7azF858 kLaULVrI+Bk8X+f3d+kR3d43AIERwfqMNyF0iRBeNWCkj7ADS5UKnZGBUlcL3zmQ5TBkWvEQx8/C SG35SEjcLQysKq1gg+pgwIYR4qCVgfT7Rnd+ohl1C85Itz90M4WmI0ShWx3OA5Qzo5JdbdHJoqW9 T/OFVBN7SK7wRiuHHqsQEU6MQq93XomVIFKelpo26G1nDqqMv865yNPBnB8NR/8vZr3XBeK+L+zK jMd9q7jq3Q5efzhWQiUPbfjE4xvougl02EW0IPX9Ekl53oBX5B6BosfLqxsZJGE7WcO7dLW2nrVQ DU1LztzIiSOKA3b96PKJswJDQDNlDZ0X6Iw9llWIYUp6uZcPk/8BAAD//wMAUEsDBBQABgAIAAAA IQD4QsczXAwAAIRMAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1srJxbc+I8Eobvt2r/A8X9 B7HNKakkX01iDgZsDLOHa4Y4CTUQZ8GZw/frt2XJstTyqDW73AARj1+1Wq/bsk18++eP46H1LTud 9/nbXdvrXLVb2dsuf9q/vdy1//mPyR+jdutcbN+etof8Lbtr/8zO7T/v//632+/56ev5NcuKFii8 ne/ar0XxftPtnnev2XF77uTv2Rt885yfjtsC/jy9dM/vp2z7VG50PHT9q6tB97jdv7W5ws3JRSN/ ft7vsjDffRyzt4KLnLLDtoD4z6/793Oldty5yB23p68f73/s8uM7SHzZH/bFz1K03TrubqKXt/y0 /XKAcf/wettdpV3+Ycgf97tTfs6fiw7IdXmg5pivu9ddULq/fdrDCFjaW6fs+a79ybvZBIN29/62 TNC/9tn3s/K5VWy/fM4O2a7InmCe2q2/8vz4ebdlsV3DpMk/E5bwA29kc/Qlz78ysQg2u4Juz6UI 63a7K/bfssfsAPQnP4B5/g+PBD5DGF0Zh/q5imlSzmt6aj1lz9uPQ7HJv8+y/ctrAcH1Oj3IFEvY zdPPMDvvYKag804pu8sPoAGvreOeOQ4Svf1Rvn/fPxWv8Omq0+t5vauB32+3dh/nIj/+W3zDwpJb +mJLeBdbjjr9fm8wGtq3g4GWPcJ71aPfCQL/KvBYj1+yczHZs2FYe4cRlirwLlR6Qcf3ys4dJaCz UgLehcSwHoCjxkBowLvU8K6uA5YDR4mhkIB3ITHoDIfDoFeKWCbgWmwI72LDUWc0Ggx5EiwbeuBX PunwQW7qMneetAt8+F8H7FXOYR+ECJiuSpst8Mo7Xm0eGL1ti8onXm2Ua8csVf7waoNcK0a19VrZ wlN94bRXeZUd2Ac5N05+8OBQwacVPlSb2rNTWcirPTTsDAYOO39lBL82AtQd6SG797u8CJUFLtwW 2/vbU/69BccfEDu/b9nRzLthw2HlLAg6kEWebVniflHfoDwxmU9M564NArD9GYrut/vg+rb7DQrp TiAPHIFxS6Q30JFHE+kHOhKayJVOjE2i5+vIxEQ8nZiaBNKYmUQw1EWiBgSNeN6AjHSVBUdYCakT pyPLBqSP0hI39NTTZRITGaFgViYyRIlJTSTo6x2tTaSHcrcxkdoJXTCvdDCUNM3BzMqVe/kxu2wo j9N9ZuzG43TlY6Z214ZXmWsU+4NJoDl95ASUP6mBBheaxKAeXblDjTkC4UoRNBUTk0B73JQkZiQR kcScJBYmgcayJImYJBKSWJFEShJrktjYCM25cEi9oHOZGtRuxTDYuSaBncsJOPpK03mojIQmMkBl ZMwRm3VJYmoSyNwzkohIYk4SC5PA1iWJmCQSkliRREoSa5LY2AjNulDcLmhdpmYvuiaBrcsJeK2t i47poYkM0C4y5ojNuiaBjDkliRlJRCQxJ4mFSWDrkkRMEglJrEgiJYk1SWxshGZdqG4XtC5T06uu h9ZDDw0IOtg/cgRea/OiohqayADtAmOO2MxrEti8JDEjiYgk5iSx4ASckcmM+GgRtTRFkL9jWiQh RVYkkZLEmiQ2NkKzL0zvBe3L1PTKa9i3AcH25QjsgXKyPFRYQxMZoPkccwRepQqaz4lJYPuSxIwk IpKYk8SCE1b7miJouDEtkpAiK5JISWJNEhsbodkXUnJB+zI1ovo2INi+HIE9UBrPQ6U1NJEBmq0x RyARUgURE5PA9iWJGUlEJDEniQUn4FWOxai+pggabkyLJKTIiiRSkliTxMZGaPaFC1wXtC9TI6pv A4LtyxGt+qLSGprIAJ3XjTlis69JYPtyApL5S9vMOAKnyBIZoWV6RPYzJ4kFHcmSRmIaScxQ0G6w okVSjvjlzR52NXVNqm5shOZYuN56QccyNaLgNiDYsRzRCi6yUmgiA+STMUdsjjUJ1M2UE1bHcgTO jH/tWLKfOUks6EiWNBLTSGKGgh1Li6Qc4bc3S8eSqhsboTmWXem+oGVLOaLKNjHYtIJR66yPimjY wAzQ6eBYMDbfNiDYuAKxOlcwWrFFo4roruY0snCIZunAxA5M0hAONrCDTCoYpejSwhsropuY3b9Q b6xB2fw/bkuw28Co8PqoHj40MB6a7kfBqKXXRwYNG5g+Op0bC8ZqYh6yihgmJpFZQ0dIJaKROY0s GhBkqyWNxAKx7ZYJLbOikVQgSgmmN9pYEd2/7C7GBf3Lb4qopcj0r8mY/uWMVoSRx0P2IwfYV1Sm j66mjQWjmhPN9kQgasgj1NW0QQa5c0YjEY3MaWQhEJv1lg0yaNixg0xCy6xoJBWIWoH5zFlmZWPV 1R3MbmZc0MH83oi6DjQdbDKmgzmjVWDkzpD92AYcrDFGBeaMOt0emsuJ0AGyXruiaj8VjKqDz/Vn gmFvUqiHOotcoLkLtBCQLaSlAxM7MIlg1JHhE9KVg04qddgP9soVsWixmpnPYTOimxmq2SXNzOT0 NbFpZpMxzcwZeJW+8PGlM/Y7MGTmPvLOWDC2GZ8IRk0WqrVTGpkJpC46Eb3RnEYWArGNYOnAxA5M 0hAOSuiKRlKB1JlYy5Z6NvERb2NndM9C/bqkZ5mcfu3B9KzJmJ7lDLzWnkXpC9kPELFnkdnGgrHN +EQwVs/yrizITKjUS72I1p3TyEIgthEsHZjYgUkawkFJX9FIKpA6E2vZUs8mrt8bO6N7Fubhkp5l clSdbWCQ1x7Zr1pBR62zgXHtgTOqr4foOvBY6LBDkzQ/PpBPBARykkHxTAVS146Zi3LkAs1doIUL tHSBYgHZdoLERWjlAqUCqhO3dtlsQ0C6hWEol7Qwk6PKbgODLPPIfl2NSmqArmCEDcwQVYmxYAgL 886sFq5irhZsMxflyAWau0ALF2jpAsUCggHJHRYv4RMXoZULlApIrcE8ldYp2RDauoXZ3Y0LnrpV 91eU/CDrPbDfvuNKbViYM1oVRqdTodBRq3AfrYjHgrHN16QhnhHqa+qgM3NgIsFY9pY5jSwcelo6 MLEDkwhGuzaDsrNy0EmlTlUE1qJFzQWqQBsrovuY3fO4oI+ruy42Hzcwho85o3o0QFe2Qvb/Kahc 943VBGfsPjbjMX1M68xEPLa+IsGoc4eGPqeRhUNPSwcmdmASwajLMZydlYNOKnVqH/OcqrkwfGxD NB/7l70jV8oRq2LBqJnpoRXvo2BUH/dQXQ8Fo9bsHjLFWDA2b00EUy/cpkbLzEEncmDmDszCgVk6 MLEDkzgwKwcmFUydw7XDVhs7o/uU3U+6XL31HW66NTCmT7mO6tO+4VOTMX3KGbtPq5irSjCVEVYt M9Fi04kcmLkDs3Bglg5M7MAkDszKgUkFo6xwHbba2Bndp+w+xwV9ym+bqKsh48qYzxl7PeWM5lO0 qgqFjr2ech2bvyZCp64FU6NlJlpsOpEDM3dgFg7M0oGJHZjEgVk5MKlg6hyuHbba2BndpzDNmk/t /zrJaPiVg+YNtK588AXUlz92ezSbQrMpqpqgvsmz3GF940yPGyz8G3EzGuLW1krodtsDe1ACg4ZK 3EZTaFLzqkmLG50RxjUERVofCkT1G0NhNEQJJ6oySb06SeWNqQdfQNfKUIym0KSWVZM2lDpRetyw 1/5G3IxGcY9Qkh58AalxG02hSSVVkxr3CC0CVzVkTAE77VertX0vEBcStH/XrpMkpkBC1UH50Tea QrNpJZrY7zjkBA/rfUyfAra+d4+bnw2w++tSeWRYR0J13EZT6KtNWkhB04kE9MifNaD8t3ZjiqFP 8dSCAMbvPrSShvMNdUoGaP4fakgOzWwKtSZ9aOyg55ztgB8itWwP0fnNQw3VIcntqqZQo/SQ4Ggv Q4K625jU6h/fAwbDLggdyPkfolXqQw1V3T+aTaHWpEfEqn+VJDIicajQIjKmTUJ1REZTGKhNekTq oQIoe45ExVcjGhmzJqE6IqMpDNQmPSK14pMRASyna1RfoOGK/IFG/Hkfx+z0Uj766Nza5R/s8UQD eEyHbBWPZPJ7N+zgC5Eb3/Thm/KobXwzgG/K5zgZ3wzhm/KIib8JvBu2LzX1M4JtRuybrtwIHp/0 vn3J4u3pZf92bh2yZwj/qgPF/8QfwFR+LvL3shUy+yUv4CFK1V+v8AyuDH5Wz57H1HrO86L6Azph up+z4uO9lZ/28NSm8rFad+33/FSctvsCerjZP921T9FTGS08k+qQpdtTIbPoQRZla02Xi7Ku/AJG 0JXPD7v/LwAAAP//AwBQSwMEFAAGAAgAAAAhAEdknpaCBwAAk1AAAA0AAAB4bC9zdHlsZXMueG1s 7Fxbb+I4FH5faf9DlPdOgOmNChgNtKxG6syOph1pX00w4G0So8RMYVb73/ccOybmksu2UGjHRSpx OLY/n4t9fHxpfZiHgfODxgnjUdutv6u5Do18PmTRuO1+v++fXLpOIkg0JAGPaNtd0MT90Pn9t1Yi FgG9m1AqHCgiStruRIjplecl/oSGJHnHpzSCX0Y8DomAZDz2kmlMyTDBTGHgNWq1cy8kLHJVCVeh X6WQkMQPs+mJz8MpEWzAAiYWsizXCf2rT+OIx2QQANR5/ZT4umyZ2Cg+ZH7MEz4S76A4j49GzKeb KJte04OSOq0Rj0Ti+HwWibYLjJGFXj1E/DHq40/AwJSq00p+Oj9IAG/qrtdp+TzgsSOAMwBMvolI SBVFjwRsEDMkG5GQBQv1uoEvJDNTupBB0/ClhzgUmk5rgFRb6orHg7bbT/8wV7UKV8ouKLcm/16m 3I8xI4HzPWKgl9T5fIe1bnCqOvDzeq1WHXi5BAq41OwBm853WRnLEfc+VGtbw3ZbjxRaAtJkQbA0 rAu0IXjRaYGBCxpHfUg46fP9YgoWFEFfhFz1FF0J9Tgmi3rjrHqGhAdsiCjGPWm3qS1lOj9If2DR kM7psO2en8rSDcBVweXUdd3EDxa6/7p65zf93s2OG9Dv9y72UCgU28tFKtUB1GnA4yEMabqnRoVS rzqtgI4EMDVm4wl+Cz5FFnMhoP/vtIaMjHlEAnj0dA79jTlhKIRRr+2GdMhmIRSr+vUN/fCQ+Mm1 QO0SX+XaJPWTGyMmMATrpqxrtNEQDaeQPoNSiRz4r9lfiV5Jaj+C0gBKhZu18Sm6U8g+g91Q9hO1 c6WGVDe7DfxIyzHq0E0uyZE1uGKGMrFugioSbGqKYNg+DYI7NMG/RkvrPgXdnY+caBb2Q/EJ+mJw YdFB0o8weKSPypJVAribl+kU8qeZ4NHM5JDpNFh8mYUDGvelXytrk2+7ss/J0h8DNo5Cip4iAJIk X2MuqC+kpy09kDwEZxkCeDwEgosMwbmJABIFPEAnOGtuFQ54pkSVfA3RNtCdzmMSinm7bJ35qFTI FXKrlhqtkH57HpxGBue9yTFIaDiqQMWkesrIPjQBZwTqN61EOr1SeadFtE7hjE0wH+cXPqgYVdOC +SifWwY8aHqmUiXw9gcIKtbiO0Z+GfCOg195vdJSgFpn9ieyvG5pCQGUbKUv1JB2p8ZQotYaqCxT Y0js1cpgQHOdx5hM7+kcujjZE3hF9pYHFMT4OoBCA44LKAw9WvQrFgmJ7UALhnjIU1ZWQe6CwVEh AYOQdrA7vc+zfjBJVaU2tcOMLnnwlrI5LDxD3OvezKrAVrm3O/EdQGPyOuulxujOerXN/RfyR/Lg LTXmsPAMjYHHbJxZwpP+u/RewV81JiYr05Klc+tg8LXtdslQ2yuOXjMWCBahq9q4wJnZOvkfnC/p wYBMehlTXKf/glOSQNeAuLMaJN7NDIJqcuizDPJ61j4534ImDufZnKvRAMccXkCITIaiBypkLTMx 4zkRMXtIw9cKAYeIWZSYr2BApdHQyMRnImCRSZJMyJA/GiQz9azDgOgNS2NVrwckoVgC8nQZw0yr zw/D37OQJs4X+uh84yGJZGZcykiB6Lp0nBnspCxAmQUQ16IqmyE9FZzcFj4kS59/wmP2E9iNXv+Y RjRGWW9MBBwBDP3GBayN4IoOaEHmtkACkaSTtL9niWCjxS1JxC1wS9Imk5hFD/e8z9REDtdrYCno T4ynIQFwVBmDo0Nl36cyo05ew1oIvlCRtq3hgjVmmLGySvQl0Yj14stiEev0OhKhOQtNzjgPiWVg 0JMGYK2gJExvraCSVpdF5dbV1FpB2h+9kbGAzATXE0s7DqTrLCtx6QNbQCUr1oOGOWZUypgNMdtH GOsGHFj8b8oNMPakbKxdbt0nYu6C+H+e8Pr69poYtSucwsiWvT3bCR5hJ/imrOAYp4TWDThyR7jS aL43N+A1hlsKRpidxlzsSGPDLscffLTWYIOQcg9h4dz2VwlCWmuw1mCtAZb+tu8zz+bi1lOyC1Tp IQM7NrjWGqw1PMMaSoLpdgV99VTTc1fQDxsyscKGo07yLEklObxuYb+a+JhdgZHbhnA1yG5HKjqA t+7tVTLivcWfbWf6C3WmVthW2HqfqfWJ35JPbN0kPOeweqeEXT58S8uHh3WT0j3y6UmGzf3wpVcM bNkEUZpnc0dwaZYtk73SPNohtfvg8TCA6knxMGHBaZC33bUY5yC26b3SF22Pu1Av4PuRrvNvzurV BVx4biZbyzEu/HqpfZXZ1UXP21cJHYZbdMIIjqm91JTeOVTvCrJUOo32rzQeHuQ5IPwPR+UEXkCn zs3pO4jg6NWQjsgsEPfLH9tu9vxZ3igEpwJTqq/sBxeyiLabPd/itUV1efgPTnndJhDXg29nFrO2 +89N96J5fdNvnFzWupcnp+/p2UnzrHt9cnba615f95u1Rq33Lxz3w9v6ruDqumfchidv7YPLJuqn V0kAd+bFaWNT8HfZu7ZrJBR8NAYPYKv/shGe3OoqbxPs/AcAAP//AwBQSwMEFAAGAAgAAAAhABXj VF3MAwAAugsAABQAAAB4bC9zaGFyZWRTdHJpbmdzLnhtbIxW23LiRhB9T1X+oUtPbKokAQ6OdwtD aWW8lC9AofV685QapAEmFiPtzMgOf5NvyZelB8yG6hmTfUNHfU43o+4z3R/+tSnhmSstKnkZdKJ2 AFzmVSHk6jJ4+HwdXgSgDZMFKyvJL4Mt18Fw8PNPfa0NIFfqy2BtTP0hjnW+5humo6rmEt8sK7Vh Bh/VKta14qzQa87Npoy77fZ5vGFCBpBXjTSXwdkFpmmk+NbwdI+8bweDvhaDvhlccZ0rURussB+b QT+28P7VNPtKITHNKCSrgkd/agrPxjMK3Txm8c3jiMKsXMVCGgqPs27vnIK/j2h+e0wfdM1yPD48 B83VMw8GGAeUO87OLn51wV6nS0EslEJYJIXmvgLnviTzzJNk5KNPpr/QNCOf4sin6DnbeZZ0/uhR SUTDaTJyPtAovRqHzgkPRmVpGySHtMHDhSuxXAoejnlZbpiEUY2NyRUrITMMo2iypNO9uH2k6GRK kQQ/txuH4+IEomD6MXVg5PtgjP6U3vuiPfBsa9buIMybxZYKfMRJyrcp06bk9N0Ne2ZwkyYUT2Sh KlFQ+EGzlaPxVCxpXOrrmGgy+kwDbfeHkDV1XSkDi0aUBnDCKijFQjG1jeuSGesglDiZIm9SGdB7 Li+Q97+s1qJk8ukdUh/kk6xeHCOZMcU2MGEb519O0c2y7I7WgX/AmYO0kjkzcMu32IHaKLForGnB NX6H3Y/W7dX1O6qENpTx/E4s6IvUN1apb6z21X9hJZXAMcKD9g3S7k04u02zTvjFM4CWh90HLzFg e8JCGHjiTosdRWFvn4qyh/KoWP0DgsehJ1TRCrLEys1CG5XvJh8vKsjGyQ5ZM72mB3JEQqslJItY 0j9/n6D1uh1CQ+fc0ShpfJ+ktr7jelzp46hDAaeU3sqGH5QmozJHIYdMbj1HQW+lwo49rAzQi5y7 6XtDfw9qR2dRm1Yz26ZqW+PIv24f0I2cy/QQ8yZXaGCQ73XQOgAtA/wOeeyG4KNZS3TyHGbTy/As EK/+CY3mGo5TUmU7OXgX/MA4vEadmARr/tCJ3kdn8CLMGhQ+h3YL09pxhJ3x/0arQTcbUmwypdCb i8zQ2WSGaLWJ1C9c7U9uKRTui2Jj9x+7aqLlG1D8WyMQgE2lOD5pzlTujKx1WlR7vSvQ7y21MmuU lpUM/7sHcGu1KjvNAloHN/ZYLu4wqDihtwhqgq55LnB5KHA1lUuxahRuDFhvCwf5hOI0g6/QaUfn 0MrwfoE7XtVMFY7Z33f3TU8P+4D7+4xc+THu3oN/AQAA//8DAFBLAwQUAAYACAAAACEAomyl2VMB AABmAgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAhJJRS8MwFIXfBf9DyXubtnOzhraDTfYgDgQrim8xudvC2jQk0W7/3rTdaoeCj7nn5Ms5 l6TzQ1V6X6CNqGWGoiBEHkhWcyG3GXopVn6CPGOp5LSsJWToCAbN8+urlCnCag1PulagrQDjOZI0 hKkM7axVBGPDdlBREziHdOKm1hW17qi3WFG2p1vAcRjOcAWWcmopboG+GojohORsQKpPXXYAzjCU UIG0BkdBhH+8FnRl/rzQKSNnJexRuU6nuGM2Z704uA9GDMamaYJm0sVw+SP8tn587qr6Qra7YoDy lDPCNFBb63xJS/jwFnQPOsWjebvDkhq7duveCOCLY74We/Ae3KZNin+rDtp16MnAPZeK9B3Oyutk eV+sUB6HUeyHMz9Oiigh8YxMk/f28Yv7bcp+UJ0i/Eu89eNpEd2RMCaTmxHxDMi73Jc/I/8GAAD/ /wMAUEsDBBQABgAIAAAAIQAe1kscQQcAAPQeAAAnAAAAeGwvcHJpbnRlclNldHRpbmdzL3ByaW50 ZXJTZXR0aW5nczEuYmlu7JlpUFNZFscvGFktZBEQRCEiIt1AAAGFZgTCYpAlTAg2m8ZIEghiEkPC IiSBBhSatptgK2KBDN00TFvSKCoOQhGNKDtEGBZZROiwCgGBBhEC8yKOZXXNVE1Vf+t599W5//NO 7rnvnt+rU/nwMMAfGAEsoEAXFYQDMoiCjAXF/AET0CE9DOyAFXQZAVfgAKkDoEF+ALRKNuQQQGEA 7NzjtpGsKAfkwJQKXYkE6XYQJC8P6ebs835PFjQz32f9sUnuQ7pM5SGT6QY0PoQ/iruXX+BeMAfM t0zr8193OXz84T84ip/E/r3/JyHY/T8g8Ol7n4PqDfDFH5OVrQ5egT/SJ0yos8ggBtrJi8Zgs9BU GvDE4nwDsIE4Nw+A8whw9/EBgTQqkxwj8/yJDDIzgHqeDHw88HgPHMAyqWQai8ii0mnAH4vD41y9 8ABHjqFHs9/H7K2sSAwqcKNH05m+dBJ507OxBRj/AOpZRjSVQiWTAr0AnsnebFpZUb8b0/rQ6QL9 MXJAExj+/SBCiPJ2+1sUR+mAqBMZBDWZzPygHJn5awFgrgfANKQNkH7K7XfbfryVrflGKA/cHMPi qDQSPS4mLIYRHUePs7e1JMf/12N9zIcdmMCfjcDxrVA/QbbwDID4vpmC2TO72Ab1zrm2Xl/0W64O h/X90ryDPeh+vdi5Q7mN5c17dDy6zH93uE3IY0KMn6Iks3+LK2fM2NDsiIbhuzrFdy2P1NOQbxWV PsvQ1vjmcD76Tq2gcTynebTi5FnNaYlUpTBJUhtXZVhYnThokluyV5NQUSzk+/GlfVL7EfO9qVa/ GnQtmbnn4lcPpeZxd3Tquy5b1D0g8sOPJ9yY+J6jwaeJie57O+IdKS9ikRTrNvX5oxmlxqOjduUb ioPWYvPTR+/VqJXwNAf/WrBu7viL0TvrU7958525oWU+grcX7ls+HSrdfTepJJ5dGnvBUCthfE1Y vztxf3f3LkaY5PDXPRbRxreqk3hJM/R9r6+/YKMpTzInQ7qjMRM692laSMMng8Pj7O79X7ZEzS+u o2xvlnY9uz0+GRFMH5lE1fnGFI9Y3fAQ07WQVN610aTHz4eKzlII9UR6Xq8PZ6C/8TDFDM9zyqs0 sSie2VndqlbKm35zRI+p/XDjbpNTq1gl/WV2JuG5tLZyObiLrVKufTDvoAOfrl6QMTwwnso/WoBk zqhGhF3yInK0sdc8NZicAIPV5NW32mXDfoarDYpBhnHmr60SQ+sMOiWi2ICLQam/OhSXO9ySbl1c PLbSMqc+H9rAaSiMWg9ZiML3GJdEoMSMBLmc8zjrrCXMdnvfk2I3Ma1lufurhi/LT/3Tgy+3TZCi 1W4WzO+ZC+J7RyagLZua42uCprA/bFTk1y9oJ9y3bfOObCbmZ+2M89yTG0GWc7tocqloe7OXzwye 3HDL55BBTvmu01dJat/l5z8TxUS2E2s6I7FNelXJ5IfJK4XamrYUkmbiC5XKjQrJlawGCm+f6yvE t9LmXkn7zz9iblvRe17G5D/yNm1CF+X0n0PqDT3THSleEY/+1nGlwyQ/va3R6fTXHspGyKvJ8Y5E OevGHxDZVt4u+o7IeshTk0WRWFPE90reLk4FtzGmIuU0P4ZDSuGm4ziMyEKbqjs+Hka8zCrWUip4 xRLafoik6emk+xmx5Ge/QOQfkGXP7Shwka0dTbtsfgxk3kHUdSpj5x1ToEVfNSuvteHUJ0nKGaVa YwmoHHV0xr6f3lV/tkQ36+U5n91oLeYIbKbOC57/XD7TUeO2cOJ6td1ypOTK1HcDeQlP7WY7akIX 9rQm2g2VJRSOJdrO9uSLBkqrCAvJY1se+qU+9FNkF6hVRfEZZRueSbqoiGqucQ6fNVnvoayxsnW1 vvBNlPPytpHFKc818WTuOZ1sEaoYyRUQllJLCTbmRkUEjNsaF/W0H0XVycavjaRxkQqC5bu8xcXm A6qYeClaf2T55dv2G9y8U3JemStW5QTMX04cqU+sLe1G/WgiIAW74PpMl/ZP6OKwwvH4nrjqckJF 70VP8bUWZBPnSd8htVXS54PhdjPhfSc42kPhg5kiVJ2ox1MgMltUVdaRWiyrlgdP6GriFUKmdR3T ucjHoy6XpcL2UCUpOlohdGIzNnaqUyo8o4MWZNs0WqyQBxYWcqO8KzvshiOxXZfyhE8kx3L7Gpce rZ8cxB+Soqcc7m0VFO9bMKx9k3OzauoOZyS21cDibtnavKVA4O30jwc/cYsCoGeSJGdSCPGtaAF0 JAbv8ppw2X1RVYoecBKx3h9Pim5y6r23fLSGUkSA6msehh59b4zGulmCmkl40LdocXzbwcqilIal OdVZrBbqQsgrXf10bhEhYxijJRV+rvMOKsfvW/unqEDnOeeriE6Uwvq6JTItO5ZYJWwUBGt2nPuz /VPA9cAEYAIwAZgATAAmABOACcAEYAIwAZgATAAmABOACfyvBGTfoP4FAAD//wMAUEsDBBQABgAI AAAAIQCiocrBnAEAAFwDAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAJyTQWsbMRCF74X8h0X3WGs7lGK0CsVpyKGlBjvJWdXOekW0ktBMFru/ vtpdHMttcultNO/x+DQjidtDZ4seIhrvKjaflawAp31t3L5ij7v76y+sQFKuVtY7qNgRkN3Kq09i E32ASAawSBEOK9YShRXnqFvoFM6S7JLS+NgpSse4575pjIY7r187cMQXZfmZw4HA1VBfh7dANiWu evrf0NrrgQ+fdseQgKX4GoI1WlG6pfxhdPToGyq+HTRYwXNRJLot6Ndo6ChLwfOj2GplYZ2CZaMs guDnhngANQxto0xEKXpa9aDJxwLN7zS2BSt+KYQBp2K9ikY5SliDbTqMtQ1IUT77+IItAKHgyTA1 xzL35rW5kcvRkIpL4xAwgSThEnFnyAL+bDYq0jvEy5x4ZJh4J5ztwDfP+d5IR2nxsTSR5rcaB5X4 /iJa+y4od8z2tfYx+DhuUfCTLL4b94KPYefvFMFpM5dNsW1VhDot86SfG+IhLSXaIWTdKreH+uT5 Vxje0dP0WeT8ZlYuy/REsp7g528h/wAAAP//AwBQSwMEFAAGAAgAAAAhAGPDUBobAgAAigUAABQA AAB4bC90YWJsZXMvdGFibGUxLnhtbGyUXW+bMBSG7yftP1i+X4hpm6ZVSJXQRWuVNlFIp9064ARP xka2acu/3wECiytfcnifc3w+Zw+fhUDvTBuuZITJaIwRk6nKuDxF+G2/+jHFyFgqMyqUZBGumcEP 8+/fZpYeBENASxPh3NryPghMmrOCmpEqmYQ/R6ULauFTnwJTakYzkzNmCxGE4/EkKCiXGPEMwmIk aQHe941T+Mq4KQWtXx2jZscIL8j9LgwxsspSYXbqI8nVB7wc3p1DAKbB9Ph5fAKvYeOIWnr+JHcX kqXSoO2FALfpOFYyxfMZraxacWGZRpfhg3mXf6xEVUiDUlVJC3k0SOup++Em92boiblPusWupxaA 7LpqbKmmBWqK4FITH3XlUr+pcKEbH3TdQ4/MpJqXFqbAxa592E2PjV5/7l39lU8/6fWb5I8rD33y 217ON4krJz459LWr1zN9p+g5XrjM2MeQIfMltC6tY2qscMt85+NgG7pYC5lpxTMn1NRHkGG4t7+2 jtzbfDLUCuQJS9f84EDe3pP/I1Pb/EsLvY0nQ41fwljXpVVOFG/XYbr7waw9DAxgs20xEyKxtYBt XtLMW5FhVHfVoXbieseBDOO2gbuSJGsH8Y4EgY3u+iRVxkZ/jYO0ExFc7Kk5b2377id5VGe4PUet 8YVlvCqglQbOzYprY7sNbw9PY1vDAH0xNcfJwlIxOJBnslMM1ouHzP8BAAD//wMAUEsBAi0AFAAG AAgAAAAhAMXdE0CLAQAAlAYAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQ SwECLQAUAAYACAAAACEAtVUwI/UAAABMAgAACwAAAAAAAAAAAAAAAADEAwAAX3JlbHMvLnJlbHNQ SwECLQAUAAYACAAAACEA3gn9KAIBAADUAwAAGgAAAAAAAAAAAAAAAADqBgAAeGwvX3JlbHMvd29y a2Jvb2sueG1sLnJlbHNQSwECLQAUAAYACAAAACEAurRx2mIBAABxAgAADwAAAAAAAAAAAAAAAAAs CQAAeGwvd29ya2Jvb2sueG1sUEsBAi0AFAAGAAgAAAAhAPtipW2UBgAApxsAABMAAAAAAAAAAAAA AAAAuwoAAHhsL3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEAQb/4YNkAAADKAQAAIwAA AAAAAAAAAAAAAACAEQAAeGwvd29ya3NoZWV0cy9fcmVscy9zaGVldDEueG1sLnJlbHNQSwECLQAU AAYACAAAACEA++hdR2ABAAB1AgAAGAAAAAAAAAAAAAAAAACaEgAAeGwvd29ya3NoZWV0cy9zaGVl dDIueG1sUEsBAi0AFAAGAAgAAAAhAPvoXUdgAQAAdQIAABgAAAAAAAAAAAAAAAAAMBQAAHhsL3dv cmtzaGVldHMvc2hlZXQzLnhtbFBLAQItABQABgAIAAAAIQD4QsczXAwAAIRMAAAYAAAAAAAAAAAA AAAAAMYVAAB4bC93b3Jrc2hlZXRzL3NoZWV0MS54bWxQSwECLQAUAAYACAAAACEAR2SeloIHAACT UAAADQAAAAAAAAAAAAAAAABYIgAAeGwvc3R5bGVzLnhtbFBLAQItABQABgAIAAAAIQAV41RdzAMA ALoLAAAUAAAAAAAAAAAAAAAAAAUqAAB4bC9zaGFyZWRTdHJpbmdzLnhtbFBLAQItABQABgAIAAAA IQCibKXZUwEAAGYCAAARAAAAAAAAAAAAAAAAAAMuAABkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQA BgAIAAAAIQAe1kscQQcAAPQeAAAnAAAAAAAAAAAAAAAAAI0wAAB4bC9wcmludGVyU2V0dGluZ3Mv cHJpbnRlclNldHRpbmdzMS5iaW5QSwECLQAUAAYACAAAACEAoqHKwZwBAABcAwAAEAAAAAAAAAAA AAAAAAATOAAAZG9jUHJvcHMvYXBwLnhtbFBLAQItABQABgAIAAAAIQBjw1AaGwIAAIoFAAAUAAAA AAAAAAAAAAAAAOU6AAB4bC90YWJsZXMvdGFibGUxLnhtbFBLBQYAAAAADwAPAPQDAAAyPQAAAAA= --_004_4E1F6AAD24975D4BA5B168042967394366743D32TK5EX14MBXC285r_-- From James.H.Manger@team.telstra.com Wed Jul 25 18:53:58 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A73C711E8091 for ; Wed, 25 Jul 2012 18:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.213 X-Spam-Level: X-Spam-Status: No, score=-1.213 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gtvl91f7R9el for ; Wed, 25 Jul 2012 18:53:57 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 7251911E8079 for ; Wed, 25 Jul 2012 18:53:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,657,1336312800"; d="scan'208,217";a="83951990" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipobvi.tcif.telstra.com.au with ESMTP; 26 Jul 2012 11:53:55 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6783"; a="77591817" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipccvi.tcif.telstra.com.au with ESMTP; 26 Jul 2012 11:53:54 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Thu, 26 Jul 2012 11:53:53 +1000 From: "Manger, James H" To: Brian Campbell Date: Thu, 26 Jul 2012 11:53:52 +1000 Thread-Topic: [jose] MUST understand ALL header fields Thread-Index: Ac1qeJCQu+xUcAwjToi7ADxOSfwxsgAUsrxQ Message-ID: <255B9BB34FB7D647A506DC292726F6E114F800BACB@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739436657A1B2@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F78D4ADF@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E114F800BACBWSMSG3153Vsrv_" MIME-Version: 1.0 Cc: "Richard L. Barnes" , Mike Jones , "jose@ietf.org" Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 01:53:58 -0000 --_000_255B9BB34FB7D647A506DC292726F6E114F800BACBWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmWxsIGFkZCBhbm90aGVyIGFyZ3VtZW50IGZvciByZW1vdmluZyB0aGUg4oCcTVVTVCB1bmRl cnN0YW5kIGV2ZXJ5dGhpbmfigJ0gcmVxdWlyZW1lbnQuDQoNCkpPU0UgY3VycmVudGx5IHVzZXMg b25lIGJ1Y2tldCAodGhlIGhlYWRlciBKU09OIG9iamVjdCkgZm9yIGRpZmZlcmVudCBjYXRlZ29y aWVzIG9mIGluZm86DQoNCjEuICAgICAgIFN0cnVjdHVyZSBvZiB0aGUgSk9TRSBtZXNzYWdlIChl ZyBpbmRpY2F0ZSB3aGV0aGVyIHRoZSAybmQgZG90LXNlcGFyYXRlZCBzZWdtZW50IGlzIHBsYWlu IHRleHQsIGFuIGVuY3J5cHRlZCBrZXksIGV0YykNCg0KMi4gICAgICAgQWxnb3JpdGhtIGRldGFp bHMgKGVnIG5hbWUsIElWLCBldGMpDQoNCjMuICAgICAgIEhpbnRzIGFib3V0IGtleXMgKGVnIFVS SSB0byBnZXQga2V5IGlmIHlvdSBkb27igJl0IGhhdmUgaXQ7IHJldm9jYXRpb24gc3RhdHVzLCBl dGMpDQoNCjQuICAgICAgIE1ldGFkYXRhIGFib3V0IHRoZSBjb250ZW50IChlZyBjb250ZW50LXR5 cGUsIGxhc3QgbW9kaWZpZWQgZGF0ZSwgZXRjKQ0KDQpFdmVuIGlmIGl0IGlzIGltcG9ydGFudCBm b3Igc2VjdXJpdHkgdGhhdCwgc2F5LCBzb21lIHN0cnVjdHVyYWwgaW5mbyBpcyBub3QgaWdub3Jl ZCB0aGF0IGRvZXNu4oCZdCBtZWFuIHRoZSBzYW1lIGltcG9ydGFuY2UgYXBwbGllcyB0byB0aGUg b3RoZXIgY2F0ZWdvcmllcyBvZiBpbmZvLg0KDQpEaWZmZXJlbnQgY2F0ZWdvcmllcyBvZiBpbmZv IHdpbGwgYmUgaGFuZGxlZCBieSBxdWl0ZSBkaWZmZXJlbnQgY29kZS4gRm9yIGluc3RhbmNlLCBh IEpPU0UgbGlicmFyeSBpcyB1bmxpa2VseSB0byBjYXJlIGF0IGFsbCBhYm91dCB0aGUgY29udGVu dCBtZXRhZGF0YTsgb25seSB0aGUgZGVjcnlwdGlvbiBjb2RlIGNhcmVzIGFib3V0IHRoZSBJVjsg ZXRjLiBUbyBlbmZvcmNlIGEg4oCcTVVTVCB1bmRlcnN0YW5kIGV2ZXJ5dGhpbmfigJ0gcmVxdWly ZW1lbnQgYWxsIHRoZXNlIGRpZmZlcmVudCBwaWVjZXMgb2YgY29kZSBmcm9tIGRpZmZlcmVudCBs YXllcnMgaW4gYSBzb2Z0d2FyZSBzdGFjayAoZWcgYXBwIHZzIGxpYnJhcnkpIHdpbGwgbmVlZCB0 byBjb29wZXJhdGUuIFRoYXQgY29vcGVyYXRpb24gd2lsbCByZXF1aXJlIG1vcmUgY29tcGxleCBB UElzIGJldHdlZW4gbGF5ZXJzIChlZyBsaWJyYXJ5IHJldHVybnMg4oCcY29udGVudOKAnSwg4oCc aGVhZGVyc+KAnSwgYW5kIOKAnGxpc3Qgb2YgaGVhZGVycyB0aGUgYXBwIE1VU1QgdW5kZXJzdGFu ZCBiZWNhdXNlIHRoZSBsaWJyYXJ5IGlnbm9yZWQgdGhlbSAoYXNzdW1pbmcgdGhleSBhcmUgY29u dGVudCBtZXRhZGF0YSnigJ0pLg0KLS0NCkphbWVzIE1hbmdlcg0KDQoNCkZyb206IGpvc2UtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEJyaWFuIENhbXBiZWxsDQpTZW50OiBUaHVyc2RheSwgMjYgSnVseSAyMDEyIDE6MTYgQU0NClRv OiBNYW5nZXIsIEphbWVzIEgNCkNjOiBSaWNoYXJkIEwuIEJhcm5lczsgTWlrZSBKb25lczsgam9z ZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtqb3NlXSBNVVNUIHVuZGVyc3RhbmQgQUxMIGhlYWRl ciBmaWVsZHMNCg0KSSB3b24ndCBwcmV0ZW5kIHRvIGtub3cgd2hhdCB0aGUgKnJpZ2h0KiB0aGlu ZyB0byBkbyBpcy4gQnV0IEkgZG8gdGhpbmsgSmFtZXMgbWFrZXMgYSB2YWxpZCBwb2ludCBhYm91 dCB0aGUgdGVtcG9yYWwgaW50ZXJvcGVyYWJpbGl0eSBwcm9ibGVtcyB0aGF0IHdpbGwgYXJpc2Ug aWYvd2hlbiBuZXcgcGFyYW1ldGVycyBnZXQgaW50cm9kdWNlZCBkb3duIHRoZSByb2FkLg0KT24g U3VuLCBKdWwgOCwgMjAxMiBhdCA2OjQyIFBNLCBNYW5nZXIsIEphbWVzIEggPEphbWVzLkguTWFu Z2VyQHRlYW0udGVsc3RyYS5jb208bWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5j b20+PiB3cm90ZToNCk1pa2UsDQoNCj4+ICAgIEltcGxlbWVudGF0aW9ucyBNVVNUIHVuZGVyc3Rh bmQgdGhlIGVudGlyZSBjb250ZW50cyBvZiB0aGUNCj4+ICAgIGhlYWRlcjsgb3RoZXJ3aXNlLCB0 aGUge0pXU3xKV0V9IE1VU1QgYmUgcmVqZWN0ZWQuDQo+Pg0KPj4gV2Ugc2hvdWxkIGRyb3AgdGhp cyByZXN0cmljdGlvbi4NCg0KTWlrZSByZXBsaWVkOg0KPiBTaW5jZSB0aGlzIGlzIGEgc2VjdXJp dHkgcHJvdG9jb2wsIHRoZSB3YXkgSSBzZWUgaXQsIHVzZSBvZiBhIG5vdC0NCj4gdW5kZXJzdG9v ZCBwYXJhbWV0ZXIgU0hPVUxEIGJyZWFrIGltcGxlbWVudGF0aW9ucyBpZiB0aGV54oCZcmUgbm90 DQo+IHByZXBhcmVkIHRvIGhhbmRsZSB0aGVtIChvciBhdCBsZWFzdCB0aGVtIGNhdXNlIHRoZW0g dG8gcmVqZWN0IHRoZQ0KPiBpbnB1dCkuICBGb3IgZXhhbXBsZSwgaWYgd2UgaHlwb3RoZXRpY2Fs bHkgYWRkZWQgYW4gYXVkaWVuY2UNCj4gcmVzdHJpY3Rpb24gcGFyYW1ldGVyLCBpZ25vcmluZyBp dCB3b3VsZCBiZSBhIHNlY3VyaXR5IGVycm9yLiAgKFRoZQ0KPiBuZWVkIGZvciBhdWRpZW5jZSBy ZXN0cmljdGlvbiBpcyBiZWluZyBoZWF2aWx5IGRpc2N1c3NlZCBpbiB0aGUgT0F1dGgNCj4gV0cg cmlnaHQgbm93LCBhbmQgcmVhbCBleHBsb2l0cyB0aGF0IGhhdmUgb2NjdXJyZWQgZm9yIHRoZSBs YWNrIG9mIGl0LA0KPiBzbyB0aGlzIGV4YW1wbGUgaXMgcmVhbCBhbmQgZnJlc2ggb24gbXkgbWlu ZC4pICBJZiBub3QgdW5kZXJzdG9vZCwgYQ0KPiB0b2tlbiBjb250YWluaW5nIGFuIGF1ZGllbmNl IHJlc3RyaWN0aW9uIE1VU1QgYmUgcmVqZWN0ZWQuDQoNCg0KQ29uc2lkZXIgYW4gZWNvc3lzdGVt IHdpdGggaHVuZHJlZHMgb2Ygc2VydmVycyBhbmQgdGhvdXNhbmRzIG9mIGNsaWVudCBhcHBzIGFs bCB1c2luZyBhIHByb3RvY29sIGludm9sdmluZyBKT1NFIG1lc3NhZ2VzIHRoYXQgaGFzIGJlZW4g b3BlcmF0aW5nIGZvciBhIGZldyB5ZWFycy4gQSByZXNlYXJjaGVyIGZpbmRzIGEgdnVsbmVyYWJp bGl0eSBpbiB0aGUgcHJvdG9jb2wgYW5kIHJlc3BvbnNpYmx5IGRpc2Nsb3NlcyBpdCB0byBzZWxl Y3RlZCBzZXJ2ZXJzLiBUaGUgZml4IGlzIHRvIGFkZCBhbiBhdWRpZW5jZSByZXN0cmljdGlvbiBw YXJhbWV0ZXIgImF1ZCIuDQoNCldoYXQgc2hvdWxkIGEgc2VydmVyIGRvPw0KDQpJZiBpdCBhZGRz IHRoZSAiYXVkIiBwYXJhbWV0ZXIgaW1tZWRpYXRlbHksIGV2ZXJ5IChjb21wbGlhbnQpIGNsaWVu dCBhcHAgd2lsbCBpbW1lZGlhdGVseSBicmVhay4gVGhlIG91dGFnZSB3aWxsIGxhc3QgdW50aWwg ZXZlcnkgYXBwIGlzIHVwZGF0ZWQsIHdoaWNoIHdpbGwgdGFrZXMgd2Vla3MsIG1vbnRoc+KApj8g VG90YWwgc3lzdGVtIHNodXRkb3duIHRvIGZpeCBhIGZsYXcgdGhhdCBpcyBjdXJyZW50bHkgdGhl b3JldGljYWzigKYgaGVhZHMgd2lsbCByb2xlLg0KDQpJZiBhIHNlcnZlciBhbm5vdW5jZXMgdGhh dCBpdCB3aWxsIGFkZCB0aGUgImF1ZCIgcGFyYW1ldGVyIGluLCBzYXksIDMgbW9udGhzIHRvIGdp dmUgdGltZSBmb3IgYXBwIHVwZGF0ZXMgdGhlbiBpdCBoYXMganVzdCBkaXNjbG9zZWQgYSB2dWxu ZXJhYmlsaXR5IGFuZCBnaXZlbiBhdHRhY2tlcnMgYSAzIG1vbnRoIHdpbmRvdyB0byBleHBsb2l0 IGl0LiBNYW55IHdpbGwgY2xhbW91ciBmb3IgYW4gaW1tZWRpYXRlIGZpeDsgbWFueSB3aWxsIHNh eSB0aGV5IG5lZWQgbG9uZ2VyIHRvIGZpeCBhcHBzOyBpdCB3aWxsIHN0aWxsIGJyZWFrIGZvciBt YW55IHVzZXJzIGluIDMgbW9udGhz4oCmIGhlYWRzIHdpbGwgcm9sZS4NCg0KT24gdGhlIG90aGVy IGhhbmQsIGlmIHRoZSBzcGVjIHNheXMgdW5rbm93biBwYXJhbWV0ZXJzIE1VU1QgYmUgaWdub3Jl ZCB0aGVuIHRoZSBzZXJ2ZXIgY2FuIGltbWVkaWF0ZWx5IGFkZCB0aGUgImF1ZCIgcGFyYW1ldGVy LCBhbmQgaW1tZWRpYXRlbHkgdGVsbCBjbGllbnQgYXBwcyB0byBzdGFydCBzdXBwb3J0aW5nIGl0 LiBFYWNoIGFwcCBpcyBwcm90ZWN0ZWQgYXMgc29vbiBhcyBpdCBhZGRzIHN1cHBvcnQuDQpJZiBh Y3R1YWwgZXhwbG9pdHMgbmVlZCB0byBiZSBzdG9wcGVkIHRoZSBzZXJ2ZXIgY2FuIHN0aWxsIHNo dXRkb3duIHRoZSB3aG9sZSBzeXN0ZW0sIG9yIGp1c3Qgc2VsZWN0ZWQgY2xpZW50IGFwcHMsIG9y IHNlbGVjdGVkIHVzZXJzLg0KDQoNClguNTA5IGNlcnRpZmljYXRlcyBhcmUgYW4gaW50ZXJlc3Rp bmcgZXhhbXBsZSBmb3IgY29tcGFyaXNvbi4gQ2VydHMgYXJlIHNlY3VyaXR5LXJlbGF0ZWQsIGp1 c3QgbGlrZSBKT1NFIG1lc3NhZ2VzLiBDZXJ0cyBhbGxvdyB1bnJlY29nbmlzZWQgYWRkaXRpb25z IChlZyBub24tY3JpdGljYWwgZXh0ZW5zaW9ucykuIFRoZXNlIGhhdmUgYmVlbiB2ZXJ5IHdpZGVs eSB1c2VkIHRvIGRlcGxveSBuZXcgZnVuY3Rpb25hbGl0eS4NCg0KVGhlIFguNTA5IHNwZWMgKG9y IGF0IGxlYXN0IGl0cyBJRVRGIHByb2ZpbGUpIGhhcyBvbmUgaXRlbSB0aGF0IE1VU1QgYmUgdW5k ZXJzdG9vZCBpZiBhZGRlZDogdGhlIG5hbWUtY29uc3RyYWludHMgZXh0ZW5zaW9uLiBUaGlzIGV4 dGVuc2lvbiBzaG91bGQgYmUgcmVhbGx5IHVzZWZ1bCBmb3Igc2VjdXJpdHkuIEhvd2V2ZXIsIGJl Y2F1c2UgYWRkaW5nIGl0IGluIHRoZSBzcGVjLWNvbXBsaWFudCBNVVNULXVuZGVyc3RhbmQgbWFu bmVyIHdpbGwgYnJlYWsgc29tZSBjbGllbnRzLCBpdCBoYXMgYmFyZWx5IGJlZW4gZGVwbG95ZWQg Zm9yIG92ZXIgYSBkZWNhZGUuDQoNCg0KTGV0cyBkcm9wIHRoZSAiTVVTVCB1bmRlcnN0YW5kIGV2 ZXJ5dGhpbmciIHJlcXVpcmVtZW50Lg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kam9zZSBtYWlsaW5nIGxpc3QNCmpv c2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2pvc2UNCg0K --_000_255B9BB34FB7D647A506DC292726F6E114F800BACBWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPjxoZWFkPjxtZXRhIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQv aHRtbDsgY2hhcnNldD11dGYtOCI+PG1ldGEgbmFtZT1HZW5lcmF0b3IgY29udGVudD0iTWljcm9z b2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPjxzdHlsZT48IS0tDQovKiBGb250IERlZmlu aXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBh bm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpD YWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8q IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1z b0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0 eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0 b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE4OTA0NTcz ODE7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNDYw NzgyNTc2IDIwMTkxNjQzMSAyMDE5MTY0NDEgMjAxOTE2NDQzIDIwMTkxNjQzMSAyMDE5MTY0NDEg MjAxOTE2NDQzIDIwMTkxNjQzMSAyMDE5MTY0NDEgMjAxOTE2NDQzO30NCkBsaXN0IGwwOmxldmVs MQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9 DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tQVUgbGlu az1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5J4oCZbGwgYWRkIGFub3RoZXIgYXJndW1lbnQg Zm9yIHJlbW92aW5nIHRoZSDigJxNVVNUIHVuZGVyc3RhbmQgZXZlcnl0aGluZ+KAnSByZXF1aXJl bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkpPU0UgY3VycmVudGx5IHVzZXMgb25lIGJ1Y2tldCAo dGhlIGhlYWRlciBKU09OIG9iamVjdCkgZm9yIGRpZmZlcmVudCBjYXRlZ29yaWVzIG9mIGluZm86 PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3Rl eHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEnPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9y ZSc+MS48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlN0cnVjdHVyZSBvZiB0aGUgSk9TRSBtZXNzYWdlIChl ZyBpbmRpY2F0ZSB3aGV0aGVyIHRoZSAyPHN1cD5uZDwvc3VwPiBkb3Qtc2VwYXJhdGVkIHNlZ21l bnQgaXMgcGxhaW4gdGV4dCwgYW4gZW5jcnlwdGVkIGtleSwgZXRjKTxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotMTguMHB0 O21zby1saXN0OmwwIGxldmVsMSBsZm8xJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjIuPHNwYW4gc3R5bGU9 J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5BbGdvcml0aG0gZGV0YWlscyAoZWcgbmFtZSwgSVYsIGV0Yyk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LTE4 LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4zLjxzcGFuIHN0 eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+SGludHMgYWJvdXQga2V5cyAoZWcgVVJJIHRvIGdldCBrZXkgaWYgeW91IGRv buKAmXQgaGF2ZSBpdDsgcmV2b2NhdGlvbiBzdGF0dXMsIGV0Yyk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LTE4LjBwdDtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz40LjxzcGFuIHN0eWxlPSdm b250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+TWV0YWRhdGEgYWJvdXQgdGhlIGNvbnRlbnQgKGVnIGNvbnRlbnQtdHlwZSwgbGFzdCBt b2RpZmllZCBkYXRlLCBldGMpPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5FdmVuIGlmIGl0IGlzIGltcG9y dGFudCBmb3Igc2VjdXJpdHkgdGhhdCwgc2F5LCBzb21lIHN0cnVjdHVyYWwgaW5mbyBpcyBub3Qg aWdub3JlZCB0aGF0IGRvZXNu4oCZdCBtZWFuIHRoZSBzYW1lIGltcG9ydGFuY2UgYXBwbGllcyB0 byB0aGUgb3RoZXIgY2F0ZWdvcmllcyBvZiBpbmZvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+RGlmZmVy ZW50IGNhdGVnb3JpZXMgb2YgaW5mbyB3aWxsIGJlIGhhbmRsZWQgYnkgcXVpdGUgZGlmZmVyZW50 IGNvZGUuIEZvciBpbnN0YW5jZSwgYSBKT1NFIGxpYnJhcnkgaXMgdW5saWtlbHkgdG8gY2FyZSBh dCBhbGwgYWJvdXQgdGhlIGNvbnRlbnQgbWV0YWRhdGE7IG9ubHkgdGhlIGRlY3J5cHRpb24gY29k ZSBjYXJlcyBhYm91dCB0aGUgSVY7IGV0Yy4gVG8gZW5mb3JjZSBhIOKAnE1VU1QgdW5kZXJzdGFu ZCBldmVyeXRoaW5n4oCdIHJlcXVpcmVtZW50IGFsbCB0aGVzZSBkaWZmZXJlbnQgcGllY2VzIG9m IGNvZGUgZnJvbSBkaWZmZXJlbnQgbGF5ZXJzIGluIGEgc29mdHdhcmUgc3RhY2sgKGVnIGFwcCB2 cyBsaWJyYXJ5KSB3aWxsIG5lZWQgdG8gY29vcGVyYXRlLiBUaGF0IGNvb3BlcmF0aW9uIHdpbGwg cmVxdWlyZSBtb3JlIGNvbXBsZXggQVBJcyBiZXR3ZWVuIGxheWVycyAoZWcgbGlicmFyeSByZXR1 cm5zIOKAnGNvbnRlbnTigJ0sIOKAnGhlYWRlcnPigJ0sIGFuZCDigJxsaXN0IG9mIGhlYWRlcnMg dGhlIGFwcCBNVVNUIHVuZGVyc3RhbmQgYmVjYXVzZSB0aGUgbGlicmFyeSBpZ25vcmVkIHRoZW0g KGFzc3VtaW5nIHRoZXkgYXJlIGNvbnRlbnQgbWV0YWRhdGEp4oCdKS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4t LTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gam9zZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 am9zZS1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPkJyaWFuIENhbXBiZWxs PGJyPjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgMjYgSnVseSAyMDEyIDE6MTYgQU08YnI+PGI+VG86 PC9iPiBNYW5nZXIsIEphbWVzIEg8YnI+PGI+Q2M6PC9iPiBSaWNoYXJkIEwuIEJhcm5lczsgTWlr ZSBKb25lczsgam9zZUBpZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtqb3NlXSBNVVNU IHVuZGVyc3RhbmQgQUxMIGhlYWRlciBmaWVsZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPkkgd29uJ3QgcHJldGVuZCB0byBr bm93IHdoYXQgdGhlICpyaWdodCogdGhpbmcgdG8gZG8gaXMuIEJ1dCBJIGRvIHRoaW5rIEphbWVz IG1ha2VzIGEgdmFsaWQgcG9pbnQgYWJvdXQgdGhlIHRlbXBvcmFsIGludGVyb3BlcmFiaWxpdHkg cHJvYmxlbXMgdGhhdCB3aWxsIGFyaXNlIGlmL3doZW4gbmV3IHBhcmFtZXRlcnMgZ2V0IGludHJv ZHVjZWQgZG93biB0aGUgcm9hZC48bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD5PbiBTdW4sIEp1bCA4LCAyMDEyIGF0IDY6NDIgUE0sIE1hbmdlciwgSmFtZXMgSCAmbHQ7PGEg aHJlZj0ibWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20iIHRhcmdldD0iX2Js YW5rIj5KYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPk1pa2UsPGJyPjxicj4mZ3Q7Jmd0OyAmbmJzcDsg Jm5ic3A7SW1wbGVtZW50YXRpb25zIE1VU1QgdW5kZXJzdGFuZCB0aGUgZW50aXJlIGNvbnRlbnRz IG9mIHRoZTxicj4mZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7aGVhZGVyOyBvdGhlcndpc2UsIHRoZSB7 SldTfEpXRX0gTVVTVCBiZSByZWplY3RlZC48YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgV2Ugc2hv dWxkIGRyb3AgdGhpcyByZXN0cmljdGlvbi48YnI+PGJyPk1pa2UgcmVwbGllZDo8YnI+Jmd0OyBT aW5jZSB0aGlzIGlzIGEgc2VjdXJpdHkgcHJvdG9jb2wsIHRoZSB3YXkgSSBzZWUgaXQsIHVzZSBv ZiBhIG5vdC08YnI+Jmd0OyB1bmRlcnN0b29kIHBhcmFtZXRlciBTSE9VTEQgYnJlYWsgaW1wbGVt ZW50YXRpb25zIGlmIHRoZXnigJlyZSBub3Q8YnI+Jmd0OyBwcmVwYXJlZCB0byBoYW5kbGUgdGhl bSAob3IgYXQgbGVhc3QgdGhlbSBjYXVzZSB0aGVtIHRvIHJlamVjdCB0aGU8YnI+Jmd0OyBpbnB1 dCkuICZuYnNwO0ZvciBleGFtcGxlLCBpZiB3ZSBoeXBvdGhldGljYWxseSBhZGRlZCBhbiBhdWRp ZW5jZTxicj4mZ3Q7IHJlc3RyaWN0aW9uIHBhcmFtZXRlciwgaWdub3JpbmcgaXQgd291bGQgYmUg YSBzZWN1cml0eSBlcnJvci4gJm5ic3A7KFRoZTxicj4mZ3Q7IG5lZWQgZm9yIGF1ZGllbmNlIHJl c3RyaWN0aW9uIGlzIGJlaW5nIGhlYXZpbHkgZGlzY3Vzc2VkIGluIHRoZSBPQXV0aDxicj4mZ3Q7 IFdHIHJpZ2h0IG5vdywgYW5kIHJlYWwgZXhwbG9pdHMgdGhhdCBoYXZlIG9jY3VycmVkIGZvciB0 aGUgbGFjayBvZiBpdCw8YnI+Jmd0OyBzbyB0aGlzIGV4YW1wbGUgaXMgcmVhbCBhbmQgZnJlc2gg b24gbXkgbWluZC4pICZuYnNwO0lmIG5vdCB1bmRlcnN0b29kLCBhPGJyPiZndDsgdG9rZW4gY29u dGFpbmluZyBhbiBhdWRpZW5jZSByZXN0cmljdGlvbiBNVVNUIGJlIHJlamVjdGVkLjxicj48YnI+ PGJyPkNvbnNpZGVyIGFuIGVjb3N5c3RlbSB3aXRoIGh1bmRyZWRzIG9mIHNlcnZlcnMgYW5kIHRo b3VzYW5kcyBvZiBjbGllbnQgYXBwcyBhbGwgdXNpbmcgYSBwcm90b2NvbCBpbnZvbHZpbmcgSk9T RSBtZXNzYWdlcyB0aGF0IGhhcyBiZWVuIG9wZXJhdGluZyBmb3IgYSBmZXcgeWVhcnMuIEEgcmVz ZWFyY2hlciBmaW5kcyBhIHZ1bG5lcmFiaWxpdHkgaW4gdGhlIHByb3RvY29sIGFuZCByZXNwb25z aWJseSBkaXNjbG9zZXMgaXQgdG8gc2VsZWN0ZWQgc2VydmVycy4gVGhlIGZpeCBpcyB0byBhZGQg YW4gYXVkaWVuY2UgcmVzdHJpY3Rpb24gcGFyYW1ldGVyICZxdW90O2F1ZCZxdW90Oy48YnI+PGJy PldoYXQgc2hvdWxkIGEgc2VydmVyIGRvPzxicj48YnI+SWYgaXQgYWRkcyB0aGUgJnF1b3Q7YXVk JnF1b3Q7IHBhcmFtZXRlciBpbW1lZGlhdGVseSwgZXZlcnkgKGNvbXBsaWFudCkgY2xpZW50IGFw cCB3aWxsIGltbWVkaWF0ZWx5IGJyZWFrLiBUaGUgb3V0YWdlIHdpbGwgbGFzdCB1bnRpbCBldmVy eSBhcHAgaXMgdXBkYXRlZCwgd2hpY2ggd2lsbCB0YWtlcyB3ZWVrcywgbW9udGhz4oCmPyBUb3Rh bCBzeXN0ZW0gc2h1dGRvd24gdG8gZml4IGEgZmxhdyB0aGF0IGlzIGN1cnJlbnRseSB0aGVvcmV0 aWNhbOKApiBoZWFkcyB3aWxsIHJvbGUuPGJyPjxicj5JZiBhIHNlcnZlciBhbm5vdW5jZXMgdGhh dCBpdCB3aWxsIGFkZCB0aGUgJnF1b3Q7YXVkJnF1b3Q7IHBhcmFtZXRlciBpbiwgc2F5LCAzIG1v bnRocyB0byBnaXZlIHRpbWUgZm9yIGFwcCB1cGRhdGVzIHRoZW4gaXQgaGFzIGp1c3QgZGlzY2xv c2VkIGEgdnVsbmVyYWJpbGl0eSBhbmQgZ2l2ZW4gYXR0YWNrZXJzIGEgMyBtb250aCB3aW5kb3cg dG8gZXhwbG9pdCBpdC4gTWFueSB3aWxsIGNsYW1vdXIgZm9yIGFuIGltbWVkaWF0ZSBmaXg7IG1h bnkgd2lsbCBzYXkgdGhleSBuZWVkIGxvbmdlciB0byBmaXggYXBwczsgaXQgd2lsbCBzdGlsbCBi cmVhayBmb3IgbWFueSB1c2VycyBpbiAzIG1vbnRoc+KApiBoZWFkcyB3aWxsIHJvbGUuPGJyPjxi cj5PbiB0aGUgb3RoZXIgaGFuZCwgaWYgdGhlIHNwZWMgc2F5cyB1bmtub3duIHBhcmFtZXRlcnMg TVVTVCBiZSBpZ25vcmVkIHRoZW4gdGhlIHNlcnZlciBjYW4gaW1tZWRpYXRlbHkgYWRkIHRoZSAm cXVvdDthdWQmcXVvdDsgcGFyYW1ldGVyLCBhbmQgaW1tZWRpYXRlbHkgdGVsbCBjbGllbnQgYXBw cyB0byBzdGFydCBzdXBwb3J0aW5nIGl0LiBFYWNoIGFwcCBpcyBwcm90ZWN0ZWQgYXMgc29vbiBh cyBpdCBhZGRzIHN1cHBvcnQuPGJyPklmIGFjdHVhbCBleHBsb2l0cyBuZWVkIHRvIGJlIHN0b3Bw ZWQgdGhlIHNlcnZlciBjYW4gc3RpbGwgc2h1dGRvd24gdGhlIHdob2xlIHN5c3RlbSwgb3IganVz dCBzZWxlY3RlZCBjbGllbnQgYXBwcywgb3Igc2VsZWN0ZWQgdXNlcnMuPGJyPjxicj48YnI+WC41 MDkgY2VydGlmaWNhdGVzIGFyZSBhbiBpbnRlcmVzdGluZyBleGFtcGxlIGZvciBjb21wYXJpc29u LiBDZXJ0cyBhcmUgc2VjdXJpdHktcmVsYXRlZCwganVzdCBsaWtlIEpPU0UgbWVzc2FnZXMuIENl cnRzIGFsbG93IHVucmVjb2duaXNlZCBhZGRpdGlvbnMgKGVnIG5vbi1jcml0aWNhbCBleHRlbnNp b25zKS4gVGhlc2UgaGF2ZSBiZWVuIHZlcnkgd2lkZWx5IHVzZWQgdG8gZGVwbG95IG5ldyBmdW5j dGlvbmFsaXR5Ljxicj48YnI+VGhlIFguNTA5IHNwZWMgKG9yIGF0IGxlYXN0IGl0cyBJRVRGIHBy b2ZpbGUpIGhhcyBvbmUgaXRlbSB0aGF0IE1VU1QgYmUgdW5kZXJzdG9vZCBpZiBhZGRlZDogdGhl IG5hbWUtY29uc3RyYWludHMgZXh0ZW5zaW9uLiBUaGlzIGV4dGVuc2lvbiBzaG91bGQgYmUgcmVh bGx5IHVzZWZ1bCBmb3Igc2VjdXJpdHkuIEhvd2V2ZXIsIGJlY2F1c2UgYWRkaW5nIGl0IGluIHRo ZSBzcGVjLWNvbXBsaWFudCBNVVNULXVuZGVyc3RhbmQgbWFubmVyIHdpbGwgYnJlYWsgc29tZSBj bGllbnRzLCBpdCBoYXMgYmFyZWx5IGJlZW4gZGVwbG95ZWQgZm9yIG92ZXIgYSBkZWNhZGUuPGJy Pjxicj48YnI+TGV0cyBkcm9wIHRoZSAmcXVvdDtNVVNUIHVuZGVyc3RhbmQgZXZlcnl0aGluZyZx dW90OyByZXF1aXJlbWVudC48YnI+PGJyPi0tPGJyPkphbWVzIE1hbmdlcjxicj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5qb3NlIG1haWxpbmcgbGlz dDxicj48YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwvYT48YnI+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlPC9h PjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_255B9BB34FB7D647A506DC292726F6E114F800BACBWSMSG3153Vsrv_-- From breno@google.com Wed Jul 25 19:01:11 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8389C21F86B5 for ; Wed, 25 Jul 2012 19:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rF7jyHOhfbdC for ; Wed, 25 Jul 2012 19:01:08 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE4C21F86B4 for ; Wed, 25 Jul 2012 19:01:08 -0700 (PDT) Received: by yhq56 with SMTP id 56so1569405yhq.31 for ; Wed, 25 Jul 2012 19:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=XJQKbrlHtwcMDmyXDyZPUysuHbhxZ3LSGLaJ9OexOx4=; b=pKNaDz7gdEFlNKyU/GFXqMJjxo0TGCB0ranYz7ioUozn0SvS6xAXJ4/nE1Uax9j2X4 5QpNJoThevEv7o4X1GFDGeBy3/3xlddCKYP6HEWZSuPM2JyRrNPAvmTlEwcGYb3lGHOV XY2RXse6aAvvg7uEhzTK5ExgqvsrJmhUbthGXH6ffpF7uoqfr8rk/WJrrjpl6uuIZ40a HZ+4bgZKB1wdvnO2lqeFJIrWBLs00wMRE8/udeGyD8dtSHetYq8poEoHhVphgzzQb+E5 t+wvfp6Ax3NuTa+GcoVO9UYLa40XJXLGQi3zSengJAVZDjQSkKWhIaWf6bxhQ8CKTKap NUWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=XJQKbrlHtwcMDmyXDyZPUysuHbhxZ3LSGLaJ9OexOx4=; b=Aizavpl/BsI2UuMrc//slhwoQPGJ7CbM9qYxYehTaVs1xT33c9A3nmQ5fU2bf5cu0p IymT5GliIWYzFYyNP57xbtqwpgZ06QYLMez5cmfhkpIMgQ/9edu4D0ycHrcApTK8eM1C rkYb5E49/f+YCtS0S+dMnBR7r/pJBVu84OwSoA69i/vVqM3ni49O5UjdGPsseFo99e2b sAYksMpHKzZj2jHLGoDHeEr3HGOyV9DRQuTG/6VTVPV15ivzlXTj44hHbCMZdMA1YxH3 REJvtBPZlkBJQgA/CK482+NArgf2RaxRszTRE3nDAr8gAjz6H7CveIe5YR7l0t8wzQnt w3fQ== Received: by 10.42.38.200 with SMTP id d8mr22037072ice.19.1343268067300; Wed, 25 Jul 2012 19:01:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.38.200 with SMTP id d8mr22037056ice.19.1343268066993; Wed, 25 Jul 2012 19:01:06 -0700 (PDT) Received: by 10.231.17.194 with HTTP; Wed, 25 Jul 2012 19:01:06 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F800BACB@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739436657A1B2@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F78D4ADF@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F800BACB@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 25 Jul 2012 19:01:06 -0700 Message-ID: From: Breno de Medeiros To: "Manger, James H" Content-Type: multipart/alternative; boundary=20cf30223dcff8a71004c5b1f737 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnytdJ0yY9+hiarIpKuCCSQjLdIndyMlYdAf3w+SWfLxOyFROrXhgqgAUD6QZ5Suu0/2gN+a9CyjHzUc73EIovwlO3qsSNpCugnmoDa6jjpZS6oTRkITeqaMtEzexzFEGE6xBc+graNf+4m50uViYIgeb7m43ZeXgzF/cz4FZZxsU1PF0E= Cc: "Richard L. Barnes" , Mike Jones , Brian Campbell , "jose@ietf.org" Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 02:01:11 -0000 --20cf30223dcff8a71004c5b1f737 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Jul 25, 2012 at 6:53 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > I=92ll add another argument for removing the =93MUST understand everythin= g=94 > requirement. > The requirement of understanding everything is only about the layer that performs signature validation, clearly. The header is supposed to be metadata for validation only. Putting non-validation metadata in the header is a bad idea. They payload is arbitrary -- apps can customize it at will to specify app-level metadata semantics there. > **** > > ** ** > > JOSE currently uses one bucket (the header JSON object) for different > categories of info:**** > > **1. **Structure of the JOSE message (eg indicate whether the 2nddo= t-separated segment is plain text, an encrypted key, etc) > **** > > **2. **Algorithm details (eg name, IV, etc)**** > > **3. **Hints about keys (eg URI to get key if you don=92t have it; > revocation status, etc)**** > > **4. **Metadata about the content (eg content-type, last modified > date, etc)**** > > ** ** > > Even if it is important for security that, say, some structural info is > not ignored that doesn=92t mean the same importance applies to the other > categories of info.**** > > ** ** > > Different categories of info will be handled by quite different code. For > instance, a JOSE library is unlikely to care at all about the content > metadata; only the decryption code cares about the IV; etc. To enforce a > =93MUST understand everything=94 requirement all these different pieces o= f code > from different layers in a software stack (eg app vs library) will need t= o > cooperate. That cooperation will require more complex APIs between layers > (eg library returns =93content=94, =93headers=94, and =93list of headers = the app MUST > understand because the library ignored them (assuming they are content > metadata)=94).**** > > **** > > --**** > > James Manger**** > > ** ** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Brian Campbell > *Sent:* Thursday, 26 July 2012 1:16 AM > > *To:* Manger, James H > *Cc:* Richard L. Barnes; Mike Jones; jose@ietf.org > *Subject:* Re: [jose] MUST understand ALL header fields**** > > ** ** > > I won't pretend to know what the *right* thing to do is. But I do think > James makes a valid point about the temporal interoperability problems th= at > will arise if/when new parameters get introduced down the road.**** > > On Sun, Jul 8, 2012 at 6:42 PM, Manger, James H < > James.H.Manger@team.telstra.com> wrote:**** > > Mike, > > >> Implementations MUST understand the entire contents of the > >> header; otherwise, the {JWS|JWE} MUST be rejected. > >> > >> We should drop this restriction. > > Mike replied: > > Since this is a security protocol, the way I see it, use of a not- > > understood parameter SHOULD break implementations if they=92re not > > prepared to handle them (or at least them cause them to reject the > > input). For example, if we hypothetically added an audience > > restriction parameter, ignoring it would be a security error. (The > > need for audience restriction is being heavily discussed in the OAuth > > WG right now, and real exploits that have occurred for the lack of it, > > so this example is real and fresh on my mind.) If not understood, a > > token containing an audience restriction MUST be rejected. > > > Consider an ecosystem with hundreds of servers and thousands of client > apps all using a protocol involving JOSE messages that has been operating > for a few years. A researcher finds a vulnerability in the protocol and > responsibly discloses it to selected servers. The fix is to add an audien= ce > restriction parameter "aud". > > What should a server do? > > If it adds the "aud" parameter immediately, every (compliant) client app > will immediately break. The outage will last until every app is updated, > which will takes weeks, months=85? Total system shutdown to fix a flaw th= at > is currently theoretical=85 heads will role. > > If a server announces that it will add the "aud" parameter in, say, 3 > months to give time for app updates then it has just disclosed a > vulnerability and given attackers a 3 month window to exploit it. Many wi= ll > clamour for an immediate fix; many will say they need longer to fix apps; > it will still break for many users in 3 months=85 heads will role. > > On the other hand, if the spec says unknown parameters MUST be ignored > then the server can immediately add the "aud" parameter, and immediately > tell client apps to start supporting it. Each app is protected as soon as > it adds support. > If actual exploits need to be stopped the server can still shutdown the > whole system, or just selected client apps, or selected users. > > > X.509 certificates are an interesting example for comparison. Certs are > security-related, just like JOSE messages. Certs allow unrecognised > additions (eg non-critical extensions). These have been very widely used = to > deploy new functionality. > > The X.509 spec (or at least its IETF profile) has one item that MUST be > understood if added: the name-constraints extension. This extension shoul= d > be really useful for security. However, because adding it in the > spec-compliant MUST-understand manner will break some clients, it has > barely been deployed for over a decade. > > > Lets drop the "MUST understand everything" requirement. > > -- > James Manger > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --=20 --Breno --20cf30223dcff8a71004c5b1f737 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


On Wed, J= ul 25, 2012 at 6:53 PM, Manger, James H <James.H.Manger@team= .telstra.com> wrote:

I=92ll add an= other argument for removing the =93MUST understand everything=94 requiremen= t.


The requirement of understandi= ng everything is only about the layer that performs signature validation, c= learly.

The header is supposed to be metadata for = validation only. Putting non-validation metadata in the header is a bad ide= a. They payload is arbitrary -- apps can customize it at will to specify ap= p-level metadata semantics there.
=A0

=A0<= /p>

JOSE currently uses on= e bucket (the header JSON object) for different categories of info:<= u>

1.=A0=A0=A0=A0=A0=A0 Structure of the JOSE message (eg indicate whether = the 2nd dot-separated segment is plain text, an encrypted key, e= tc)

2.=A0=A0=A0=A0=A0=A0 Algorithm details (eg name, IV, etc)<= /span>

3.=A0=A0=A0=A0=A0=A0 Hints about keys (eg URI to get key if you don=92t = have it; revocation status, etc)

4.=A0=A0=A0=A0=A0=A0 Metadata about the content (eg content-type, last m= odified date, etc)

=A0<= /p>

Even if it is importan= t for security that, say, some structural info is not ignored that doesn=92= t mean the same importance applies to the other categories of info.<= u>

=A0<= /p>

Different categories o= f info will be handled by quite different code. For instance, a JOSE librar= y is unlikely to care at all about the content metadata; only the decryptio= n code cares about the IV; etc. To enforce a =93MUST understand everything= =94 requirement all these different pieces of code from different layers in= a software stack (eg app vs library) will need to cooperate. That cooperat= ion will require more complex APIs between layers (eg library returns =93co= ntent=94, =93headers=94, and =93list of headers the app MUST understand bec= ause the library ignored them (assuming they are content metadata)=94).<= /u>

--<= /p>

James Manger

=A0=

=A0<= /p>

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Beha= lf Of Brian Campbell
Sent: Thursday, 26 July 2012 1:16 AM

To: Manger, James H
Cc: Richard L. Barnes; Mike Jones; jose@ietf.org
Subject: Re: [jose] MUST understand ALL header fields=

=A0=

I won't p= retend to know what the *right* thing to do is. But I do think James makes = a valid point about the temporal interoperability problems that will arise = if/when new parameters get introduced down the road.

On Sun, Jul 8, 2012 at 6:42 PM, Manger, James H= <J= ames.H.Manger@team.telstra.com> wrote:

Mike,

>> =A0 =A0Implementations MUST understand the entire con= tents of the
>> =A0 =A0header; otherwise, the {JWS|JWE} MUST be re= jected.
>>
>> We should drop this restriction.

Mik= e replied:
> Since this is a security protocol, the way I see it, use of a not-
= > understood parameter SHOULD break implementations if they=92re not
= > prepared to handle them (or at least them cause them to reject the
> input). =A0For example, if we hypothetically added an audience
>= restriction parameter, ignoring it would be a security error. =A0(The
&= gt; need for audience restriction is being heavily discussed in the OAuth > WG right now, and real exploits that have occurred for the lack of it,=
> so this example is real and fresh on my mind.) =A0If not understoo= d, a
> token containing an audience restriction MUST be rejected.


Consider an ecosystem with hundreds of servers and thousands of cli= ent apps all using a protocol involving JOSE messages that has been operati= ng for a few years. A researcher finds a vulnerability in the protocol and = responsibly discloses it to selected servers. The fix is to add an audience= restriction parameter "aud".

What should a server do?

If it adds the "aud" paramete= r immediately, every (compliant) client app will immediately break. The out= age will last until every app is updated, which will takes weeks, months=85= ? Total system shutdown to fix a flaw that is currently theoretical=85 head= s will role.

If a server announces that it will add the "aud" parameter in= , say, 3 months to give time for app updates then it has just disclosed a v= ulnerability and given attackers a 3 month window to exploit it. Many will = clamour for an immediate fix; many will say they need longer to fix apps; i= t will still break for many users in 3 months=85 heads will role.

On the other hand, if the spec says unknown parameters MUST be ignored = then the server can immediately add the "aud" parameter, and imme= diately tell client apps to start supporting it. Each app is protected as s= oon as it adds support.
If actual exploits need to be stopped the server can still shutdown the who= le system, or just selected client apps, or selected users.


X.50= 9 certificates are an interesting example for comparison. Certs are securit= y-related, just like JOSE messages. Certs allow unrecognised additions (eg = non-critical extensions). These have been very widely used to deploy new fu= nctionality.

The X.509 spec (or at least its IETF profile) has one item that MUST be= understood if added: the name-constraints extension. This extension should= be really useful for security. However, because adding it in the spec-comp= liant MUST-understand manner will break some clients, it has barely been de= ployed for over a decade.


Lets drop the "MUST understand everything" requirement.
--
James Manger
_______________________________________________=
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

=A0


____= ___________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose




--
--Breno<= br>
--20cf30223dcff8a71004c5b1f737-- From James.H.Manger@team.telstra.com Wed Jul 25 19:11:43 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DF811E8096 for ; Wed, 25 Jul 2012 19:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.209 X-Spam-Level: X-Spam-Status: No, score=-1.209 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pu0t19jbIsof for ; Wed, 25 Jul 2012 19:11:42 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 3309411E807F for ; Wed, 25 Jul 2012 19:11:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,657,1336312800"; d="scan'208";a="83955601" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 26 Jul 2012 12:11:42 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6783"; a="77105488" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcbvi.tcif.telstra.com.au with ESMTP; 26 Jul 2012 12:11:41 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Thu, 26 Jul 2012 12:11:40 +1000 From: "Manger, James H" To: Breno de Medeiros Date: Thu, 26 Jul 2012 12:11:37 +1000 Thread-Topic: [jose] MUST understand ALL header fields Thread-Index: Ac1q0pmvUlXTZdSGR8Oq0ZOT6KkT7wAADNxA Message-ID: <255B9BB34FB7D647A506DC292726F6E114F800BB51@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739436657A1B2@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F78D4ADF@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F800BACB@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 02:11:43 -0000 Pj4gSeKAmWxsIGFkZCBhbm90aGVyIGFyZ3VtZW50IGZvciByZW1vdmluZyB0aGUg4oCcTVVTVCB1 bmRlcnN0YW5kIGV2ZXJ5dGhpbmfigJ0gcmVxdWlyZW1lbnQuDQoNCj4gVGhlIHJlcXVpcmVtZW50 IG9mIHVuZGVyc3RhbmRpbmcgZXZlcnl0aGluZyBpcyBvbmx5IGFib3V0IHRoZSBsYXllciB0aGF0 IHBlcmZvcm1zIHNpZ25hdHVyZSB2YWxpZGF0aW9uLCBjbGVhcmx5Lg0KPg0KPiBUaGUgaGVhZGVy IGlzIHN1cHBvc2VkIHRvIGJlIG1ldGFkYXRhIGZvciB2YWxpZGF0aW9uIG9ubHkuIFB1dHRpbmcg bm9uLXZhbGlkYXRpb24gbWV0YWRhdGEgaW4gdGhlIGhlYWRlciBpcyBhIGJhZCBpZGVhLiBUaGV5 IHBheWxvYWQgaXMgYXJiaXRyYXJ5IC0tIGFwcHMgY2FuIGN1c3RvbWl6ZSBpdCBhdCB3aWxsIHRv IHNwZWNpZnkgYXBwLWxldmVsIG1ldGFkYXRhIHNlbWFudGljcyB0aGVyZS4NCg0KDQpTbyBhcmUg eW91IHN1Z2dlc3Rpbmcgd2UgZGlzYWxsb3cgbWV0YWRhdGEgYWJvdXQgdGhlIGNvbnRlbnQgKGNh dGVnb3J5IDQgaW4gbXkgbGlzdCkgZnJvbSB0aGUgaGVhZGVyPyBGb3IgaW5zdGFuY2UsIHdlIHNo b3VsZCBkcm9wIHRoZSAidHlwIiBwYXJhbWV0ZXIgKGp1c3Qga2VlcGluZyBhbiBpbmRpY2F0aW9u IG9mIHdoZXRoZXIgdGhlcmUgaXMgYW5vdGhlciBsYXllciBvZiBKT1NFIHByb2Nlc3NpbmcgaW5z aWRlLCBvciBwZXJoYXBzIG5vdCBldmVuIHRoYXQpPw0KDQoNCj4+IEpPU0UgY3VycmVudGx5IHVz ZXMgb25lIGJ1Y2tldCAodGhlIGhlYWRlciBKU09OIG9iamVjdCkgZm9yIGRpZmZlcmVudCBjYXRl Z29yaWVzIG9mIGluZm86DQo+PiAxLsKgwqDCoMKgwqDCoCBTdHJ1Y3R1cmUgb2YgdGhlIEpPU0Ug bWVzc2FnZSAoZWcgaW5kaWNhdGUgd2hldGhlciB0aGUgMm5kIGRvdC1zZXBhcmF0ZWQgc2VnbWVu dCBpcyBwbGFpbiB0ZXh0LCBhbiBlbmNyeXB0ZWQga2V5LCBldGMpDQo+PiAyLsKgwqDCoMKgwqDC oCBBbGdvcml0aG0gZGV0YWlscyAoZWcgbmFtZSwgSVYsIGV0YykNCj4+IDMuwqDCoMKgwqDCoMKg IEhpbnRzIGFib3V0IGtleXMgKGVnIFVSSSB0byBnZXQga2V5IGlmIHlvdSBkb27igJl0IGhhdmUg aXQ7IHJldm9jYXRpb24gc3RhdHVzLCBldGMpDQo+PiA0LsKgwqDCoMKgwqDCoCBNZXRhZGF0YSBh Ym91dCB0aGUgY29udGVudCAoZWcgY29udGVudC10eXBlLCBsYXN0IG1vZGlmaWVkIGRhdGUsIGV0 YykNCj4+DQo+PiBFdmVuIGlmIGl0IGlzIGltcG9ydGFudCBmb3Igc2VjdXJpdHkgdGhhdCwgc2F5 LCBzb21lIHN0cnVjdHVyYWwgaW5mbyBpcyBub3QgaWdub3JlZCB0aGF0IGRvZXNu4oCZdCBtZWFu IHRoZSBzYW1lIGltcG9ydGFuY2UgYXBwbGllcyB0byB0aGUgb3RoZXIgY2F0ZWdvcmllcyBvZiBp bmZvLg0KPj4NCj4+IERpZmZlcmVudCBjYXRlZ29yaWVzIG9mIGluZm8gd2lsbCBiZSBoYW5kbGVk IGJ5IHF1aXRlIGRpZmZlcmVudCBjb2RlLiBGb3IgaW5zdGFuY2UsIGEgSk9TRSBsaWJyYXJ5IGlz IHVubGlrZWx5IHRvIGNhcmUgYXQgYWxsIGFib3V0IHRoZSBjb250ZW50IG1ldGFkYXRhOyBvbmx5 IHRoZSBkZWNyeXB0aW9uIGNvZGUgY2FyZXMgYWJvdXQgdGhlIElWOyBldGMuIFRvIGVuZm9yY2Ug YSDigJxNVVNUIHVuZGVyc3RhbmQgZXZlcnl0aGluZ+KAnSByZXF1aXJlbWVudCBhbGwgdGhlc2Ug ZGlmZmVyZW50IHBpZWNlcyBvZiBjb2RlIGZyb20gZGlmZmVyZW50IGxheWVycyBpbiBhIHNvZnR3 YXJlIHN0YWNrIChlZyBhcHAgdnMgbGlicmFyeSkgd2lsbCBuZWVkIHRvIGNvb3BlcmF0ZS4gVGhh dCBjb29wZXJhdGlvbiB3aWxsIHJlcXVpcmUgbW9yZSBjb21wbGV4IEFQSXMgYmV0d2VlbiBsYXll cnMgKGVnIGxpYnJhcnkgcmV0dXJucyDigJxjb250ZW504oCdLCDigJxoZWFkZXJz4oCdLCBhbmQg 4oCcbGlzdCBvZiBoZWFkZXJzIHRoZSBhcHAgTVVTVCB1bmRlcnN0YW5kIGJlY2F1c2UgdGhlIGxp YnJhcnkgaWdub3JlZCB0aGVtIChhc3N1bWluZyB0aGV5IGFyZSBjb250ZW50IG1ldGFkYXRhKeKA nSkuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From breno@google.com Wed Jul 25 19:17:53 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0193B21F863C for ; Wed, 25 Jul 2012 19:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAZIF-9N5jHu for ; Wed, 25 Jul 2012 19:17:52 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C802421F860F for ; Wed, 25 Jul 2012 19:17:51 -0700 (PDT) Received: by yenq13 with SMTP id q13so1585755yen.31 for ; Wed, 25 Jul 2012 19:17:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=g5yiX4bX4OrSjuPkRIcpyE6g05Q+ADHbovr0FLMbKUc=; b=KaXeLWnXceUTGvT8ltjELTBXxbfKVg/bSwCnR4fBlZVndF5LXcInlhMmI+UA3mBS7z WxhbmzkIz8vjJBjbn/3Il1j4Tbr1Zc0UdIqRzCE0Qyw95fq6cIHBuLBv8WYxoWkRTSyw pXrQVpoE+PJjc5iVZtYlIDnJHrFhWqyEHxchSwGLHXlzaRY8gs2fv8Y7zYqDjawDx81U fleZlWLOSETxB3iwED2R2ypsfGPXCp7Q6pTKVn8CEkk7SQlTW5Scs4O934eesiBHinw0 1FAFnGY0p3A5pfFwkNkv2IDFmZhyAppRV42LeD0kpVaVKAT96VN/2Na2Z6TE4sJJFobG xouA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=g5yiX4bX4OrSjuPkRIcpyE6g05Q+ADHbovr0FLMbKUc=; b=QVv4/+d/Uj3JxZzmJ1VoEFeMHQhuzixi9JPSvmPWbStrxq9HDK1WCMmr0MLeUAeteM bPmS+CuoqjH8L7I1C0m/cKVcu9e9RTII1hWfK83EHKvaFgS+oyzV8bjGLJq1qdFwksgv sCzl+DVZgUbregt+GXcWlu8VabTeUlYmuBaMHfB0GDYUrgQkP1JGfSqjQbfmk0g7h3d2 CpPqRnq4wwGhpNbRp79F3w8ZLSGHV0/ACTNESME1nXIxIsdaCy45EKCAxaQPX8rfiGML l21Uiac7VzkC45XYJl6BvOn2uyV/MPRge6mL2btqyJoXky407nl1rDxx23DwswRLEEtk Q+vg== Received: by 10.50.161.131 with SMTP id xs3mr379416igb.46.1343269070906; Wed, 25 Jul 2012 19:17:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.161.131 with SMTP id xs3mr379409igb.46.1343269070725; Wed, 25 Jul 2012 19:17:50 -0700 (PDT) Received: by 10.231.17.194 with HTTP; Wed, 25 Jul 2012 19:17:50 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F800BB51@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739436657A1B2@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F78D4ADF@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F800BACB@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F800BB51@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 25 Jul 2012 19:17:50 -0700 Message-ID: From: Breno de Medeiros To: "Manger, James H" Content-Type: multipart/alternative; boundary=14dae9340defcc631504c5b23323 X-System-Of-Record: true X-Gm-Message-State: ALoCoQm4svNOUlCTwQJTBCVnJKQ+npQvdRoIrXXB/8m08alYBr+jP2ribhdB9wo779U6AJp4x3a4YAkLb3FUTOYyBz9HjBXhRoup3DuFCfD9TjPcA0v284NRGURf+mxjZCsenF3eK9AOlPgjjsssCmBKbNu6HQiAx+thufh2lAfacbCOcNvBdMA= Cc: "jose@ietf.org" Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 02:17:53 -0000 --14dae9340defcc631504c5b23323 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Jul 25, 2012 at 7:11 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > >> I=92ll add another argument for removing the =93MUST understand everyt= hing=94 > requirement. > > > The requirement of understanding everything is only about the layer tha= t > performs signature validation, clearly. > > > > The header is supposed to be metadata for validation only. Putting > non-validation metadata in the header is a bad idea. They payload is > arbitrary -- apps can customize it at will to specify app-level metadata > semantics there. > > > So are you suggesting we disallow metadata about the content (category 4 > in my list) from the header? For instance, we should drop the "typ" > parameter (just keeping an indication of whether there is another layer o= f > JOSE processing inside, or perhaps not even that)? > I am suggesting that any metadata without security implications should not be in the header, and if it is in the header, then the validator must fail because it has implications for security that it doesn't understand. And yes, metadata about the contents does not belong in the JWT header. > > > >> JOSE currently uses one bucket (the header JSON object) for different > categories of info: > >> 1. Structure of the JOSE message (eg indicate whether the 2nd > dot-separated segment is plain text, an encrypted key, etc) > >> 2. Algorithm details (eg name, IV, etc) > >> 3. Hints about keys (eg URI to get key if you don=92t have it; > revocation status, etc) > >> 4. Metadata about the content (eg content-type, last modified > date, etc) > >> > >> Even if it is important for security that, say, some structural info i= s > not ignored that doesn=92t mean the same importance applies to the other > categories of info. > >> > >> Different categories of info will be handled by quite different code. > For instance, a JOSE library is unlikely to care at all about the content > metadata; only the decryption code cares about the IV; etc. To enforce a > =93MUST understand everything=94 requirement all these different pieces o= f code > from different layers in a software stack (eg app vs library) will need t= o > cooperate. That cooperation will require more complex APIs between layers > (eg library returns =93content=94, =93headers=94, and =93list of headers = the app MUST > understand because the library ignored them (assuming they are content > metadata)=94). > > -- > James Manger > --=20 --Breno --14dae9340defcc631504c5b23323 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


On Wed, J= ul 25, 2012 at 7:11 PM, Manger, James H <James.H.Manger@team= .telstra.com> wrote:
>> I=92ll add anothe= r argument for removing the =93MUST understand everything=94 requirement.
> The requirement of understanding everything is only about the layer th= at performs signature validation, clearly.
>
> The header is supposed to be metadata for validation only. Putting non= -validation metadata in the header is a bad idea. They payload is arbitrary= -- apps can customize it at will to specify app-level metadata semantics t= here.


So are you suggesting we disallow metadata about the content (categor= y 4 in my list) from the header? For instance, we should drop the "typ= " parameter (just keeping an indication of whether there is another la= yer of JOSE processing inside, or perhaps not even that)?

I am suggesting that any metadata without = security implications should not be in the header, and if it is in the head= er, then the validator must fail because it has implications for security t= hat it doesn't understand.

And yes, metadata about the contents does not belong in= the JWT header.
=A0


>> JOSE currently uses one bucket (the header JSON object) for differ= ent categories of info:
>> 1.=A0=A0=A0=A0=A0=A0 Structure of the JOSE message (eg indicate wh= ether the 2nd dot-separated segment is plain text, an encrypted key, etc) >> 2.=A0=A0=A0=A0=A0=A0 Algorithm details (eg name, IV, etc)
>> 3.=A0=A0=A0=A0=A0=A0 Hints about keys (eg URI to get key if you do= n=92t have it; revocation status, etc)
>> 4.=A0=A0=A0=A0=A0=A0 Metadata about the content (eg content-type, = last modified date, etc)
>>
>> Even if it is important for security that, say, some structural in= fo is not ignored that doesn=92t mean the same importance applies to the ot= her categories of info.
>>
>> Different categories of info will be handled by quite different co= de. For instance, a JOSE library is unlikely to care at all about the conte= nt metadata; only the decryption code cares about the IV; etc. To enforce a= =93MUST understand everything=94 requirement all these different pieces of= code from different layers in a software stack (eg app vs library) will ne= ed to cooperate. That cooperation will require more complex APIs between la= yers (eg library returns =93content=94, =93headers=94, and =93list of heade= rs the app MUST understand because the library ignored them (assuming they = are content metadata)=94).

--
James Manger



--
= --Breno
--14dae9340defcc631504c5b23323-- From James.H.Manger@team.telstra.com Wed Jul 25 19:38:55 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C2C11E808C for ; Wed, 25 Jul 2012 19:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.204 X-Spam-Level: X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[AWL=-0.303, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngiHAzeS0CHC for ; Wed, 25 Jul 2012 19:38:55 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 8976911E807F for ; Wed, 25 Jul 2012 19:38:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,657,1336312800"; d="scan'208";a="86030678" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 26 Jul 2012 12:38:53 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6783"; a="93903966" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcavi.tcif.telstra.com.au with ESMTP; 26 Jul 2012 12:38:52 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Thu, 26 Jul 2012 12:38:51 +1000 From: "Manger, James H" To: "breno@google.com" Date: Thu, 26 Jul 2012 12:38:51 +1000 Thread-Topic: [jose] MUST understand ALL header fields Thread-Index: Ac1q18qgXbO77rI9RMO3M7+9hy3N8w== Message-ID: <82F6AE16-F7D7-4733-863B-DE0776D84809@team.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 02:38:55 -0000 SG93IGFib3V0IHN0YXBsaW5nIGFuIE9DU1AgcmVzcG9uc2UgdG8gYSBKT1NFIG1lc3NhZ2U/DQoN CldoeSBzaG91bGQgdGhhdCBiZSAiTVVTVCB1bmRlcnN0YW5kIj8NCg0KLS0NCkphbWVzIE1hbmdl cg0K From breno@google.com Wed Jul 25 20:12:01 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A11211E8099 for ; Wed, 25 Jul 2012 20:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+G739RwYRIg for ; Wed, 25 Jul 2012 20:12:00 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7B18211E807F for ; Wed, 25 Jul 2012 20:12:00 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1622471ghb.31 for ; Wed, 25 Jul 2012 20:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=rig3XXTSN8GrpP+WfWZ5bckCKjIju/YdAr9RRjbZkpE=; b=acJ4ijmL7YBXt9fMexw42NmMqwly2kX53zYCWTsRm2ZvfbxAulzZ4nAF8UTf2/Wq7h +CyPPhjRt14pad4/65A5xX7D5rfN9PsFcMbhHyJ7b9K8h5OoP56/YCTjSFV4jOWOUCtL SzOVCyiWQIhjaIN1RN+/+SURwaXew33K+9CiJfvFw9IgU4khvOGlDg0Ruq0IH5vFfv5/ EnV6lDuXqukRNpxqy2hfuPzF2nHYDrVlZPTJTOrCrcz6cDtnFqVoej/uqTZseLbT2+2m nvlWdQ5vtg9t+SXfX0U8E+fJFTna+AV8il4LJ76mhtohWdIiA11jyM1BhGjln+7CSw8E ppIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=rig3XXTSN8GrpP+WfWZ5bckCKjIju/YdAr9RRjbZkpE=; b=E5sq5/ZszzAtHPMafZtznMcwkTuAmtLvkztkwD946+q0RuXSLmUZQf/o6X7gafR5wy 5h7x9nJYlnPzgc5EjffJ8JEZwLLh5RLK4KPw8jT1ba7UTL2ZJiLJCCRS+EpkIgHeauVG nfB3JXp3kCqq0aCrtBNVLn11uhnmfIm9jFYnQJOc4lSlOkJE6FuKtMM00DVUx73drMeq wmqFRc/d+UJAYAt9UfsIDNq6fCiFme3RuZTeFI/ap81S+jLMA7lj6oxm0+zLjxTgUrPw q7duGHysXSGbsewQtnaNoOOTWvmvzyaQoTBvY+8CuNUssbhFQng/HR0RH5Th2SdiZhwV D6cw== Received: by 10.50.222.162 with SMTP id qn2mr465084igc.46.1343272319631; Wed, 25 Jul 2012 20:11:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.222.162 with SMTP id qn2mr465079igc.46.1343272319546; Wed, 25 Jul 2012 20:11:59 -0700 (PDT) Received: by 10.231.17.194 with HTTP; Wed, 25 Jul 2012 20:11:59 -0700 (PDT) In-Reply-To: <82F6AE16-F7D7-4733-863B-DE0776D84809@team.telstra.com> References: <82F6AE16-F7D7-4733-863B-DE0776D84809@team.telstra.com> Date: Wed, 25 Jul 2012 20:11:59 -0700 Message-ID: From: Breno de Medeiros To: "Manger, James H" Content-Type: multipart/alternative; boundary=14dae9340fbf7175cc04c5b2f507 X-System-Of-Record: true X-Gm-Message-State: ALoCoQm7IQtOBgj/nHIaEPWm1t3P7KmK0S562XIkHKdiMYvAFpzWE7nG7B7jyP05mliJnJy88LzkBf3bWoeoJ2J5fA8L2eSn6+g2AlV7L8Xz4TZH9UDwzNm4e3+8z+pIby9ouQFkGRelh+PgVSbrdBJQQrbuON9/TjiE512go7QO29hzMs4hmy0= Cc: "jose@ietf.org" Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 03:12:01 -0000 --14dae9340fbf7175cc04c5b2f507 Content-Type: text/plain; charset=ISO-8859-1 That's a more compelling use case -- it's security-specific but only adds to the security validation context. There may be a case to define optional entries in the JWT header. However declaring that any header you don't understand could be optional is a far worse balance on the extensibility versus simplicity spectrum (where simplicity here is a stand-in for security, interoperability, etc.) So I am not convinced that losing the ability to declare OCSP bindings in JWTs justifies dropping the MUST language. If there is rough consensus that defining optional security fields in the header is prudent from the viewpoint of future spec extensibility then we should devise some simple way to declare a JWT header field optional and exempt _only_those_ from the MUST fail when not understanding clause. Changing the default behavior even to SHOULD appears to me to sacrifice too much on the altar of extensibility. On Wed, Jul 25, 2012 at 7:38 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > How about stapling an OCSP response to a JOSE message? > > Why should that be "MUST understand"? > > -- > James Manger > -- --Breno --14dae9340fbf7175cc04c5b2f507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's a more compelling use case -- it's security-specific but onl= y adds to the security validation context.

There may be = a case to define optional entries in the JWT header. However declaring that= any header you don't understand could be optional is a far worse balan= ce on the extensibility versus simplicity spectrum (where simplicity here i= s a stand-in for security, interoperability, etc.) So I am not convinced th= at losing the ability to declare OCSP bindings in JWTs justifies dropping t= he MUST language. If there is rough consensus that defining optional securi= ty fields in the header is prudent from the viewpoint of future spec extens= ibility then we should devise some simple way to declare a JWT header field= optional and exempt _only_those_ from the MUST fail when not understanding= clause. Changing the default behavior even to SHOULD appears to me to sacr= ifice too much on the altar of extensibility.=A0


On Wed, Jul 2= 5, 2012 at 7:38 PM, Manger, James H <James.H.Manger@team.tel= stra.com> wrote:
How about stapling an OCSP response to a JOS= E message?

Why should that be "MUST understand"?

--
James Manger



--
--Breno
--14dae9340fbf7175cc04c5b2f507-- From James.H.Manger@team.telstra.com Wed Jul 25 22:28:39 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31ADD21F85F7 for ; Wed, 25 Jul 2012 22:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24PoywtXFLb7 for ; Wed, 25 Jul 2012 22:28:38 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 50D0421F85EF for ; Wed, 25 Jul 2012 22:28:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,658,1336312800"; d="scan'208,217";a="86061247" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipocvi.tcif.telstra.com.au with ESMTP; 26 Jul 2012 15:28:36 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6783"; a="77631055" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipccvi.tcif.telstra.com.au with ESMTP; 26 Jul 2012 15:28:34 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Thu, 26 Jul 2012 15:28:34 +1000 From: "Manger, James H" To: Breno de Medeiros , "jose@ietf.org" Date: Thu, 26 Jul 2012 15:28:33 +1000 Thread-Topic: [jose] MUST understand ALL header fields Thread-Index: Ac1q3G2owjmc16vcTsifAjOhU/rV9AABr2hQ Message-ID: <255B9BB34FB7D647A506DC292726F6E114F8073950@WSMSG3153V.srv.dir.telstra.com> References: <82F6AE16-F7D7-4733-863B-DE0776D84809@team.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E114F8073950WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 05:28:39 -0000 --_000_255B9BB34FB7D647A506DC292726F6E114F8073950WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QnJlbm8sDQoNCj4+IEhvdyBhYm91dCBzdGFwbGluZyBhbiBPQ1NQIHJlc3BvbnNlIHRvIGEgSk9T RSBtZXNzYWdlPw0KPiBUaGF0J3MgYSBtb3JlIGNvbXBlbGxpbmcgdXNlIGNhc2UgLS0gaXQncyBz ZWN1cml0eS1zcGVjaWZpYyBidXQgb25seSBhZGRzIHRvIHRoZSBzZWN1cml0eSB2YWxpZGF0aW9u IGNvbnRleHQuDQoNCg0KSG93IGFib3V0IHRoZSBzaWduaW5nIHRpbWU/DQoNCkhvdyBhYm91dCBz b21lIEROUyByZWNvcmRzIHdpdGggREFORSBhbmQgRE5TU0VDIGluZm8gZ2l2aW5nIGV2aWRlbmNl IHRoYXQgdGhlIHB1YmxpYyBrZXkgaXMgYXNzb2NpYXRlZCB3aXRoIGEgZG9tYWluPw0KDQpIb3cg YWJvdXQgYSBibG9iIG9mIGRhdGEgcmVsYXRlZCB0byBTb3ZlcmVpZ24gS2V5cywgb3IgUGVyc3Bl Y3RpdmVzLCBvciBDb252ZXJnZW5jZSwgb3Igc29tZSBvdGhlciBwcm9wb3NhbCB0byBib2xzdGVy IFBLST8NCg0KSG93IGFib3V0IGEgZG9tYWluX3BhcmFtZXRlcl9zZWVkIHNvIHlvdSBjYW4gdmVy aWZ5IHRoYXQgdGhlIGNvbW1vbiBkb21haW4gcGFyYW1ldGVycyAoZWcgcCAmIHEgaW4gRFNBKSB3 ZXJlIG5vdCBjaG9zZW4gdG8gaGF2ZSBzcGVjaWFsIHByb3BlcnRpZXM/DQoNCkhvdyBhYm91dCBk YXRhIHRvIGFsbG93IHlvdSB0byB2YWxpZGF0ZSBhIHB1YmxpYyBrZXkgKGVnIGNvLWZhY3RvciBm b3IgRUM/IFNvbWV0aGluZyBjb21wbGljYXRlZCBmb3IgUlNBPyk/DQoNCkhvdyBhYm91dCBhIHRp bWVzdGFtcCBmcm9tIGEgdGltZXN0YW1wIHNlcnZpY2U/DQoNCg0KSeKAmW0gbm90IHN1cmUgd2hp Y2gsIHdoZXJlLCBvciB3aGVuIGFuIGl0ZW0gbGlrZSB0aGUgb25lcyBtZW50aW9uZWQgYWJvdmUg d2lsbCBiZSBuZWVkZWQuIEkgYW0gY29uZmlkZW50IHRoYXQgc29tZW9uZSB3aWxsIG5lZWQgc29t ZSBpdGVtcyBsaWtlIHRoZXNlLiBXaGVuIHRoYXQgaGFwcGVucyB0aGV5IHNob3VsZCBoYXZlIGEg Y2hvaWNlIGFib3V0IHdoZXRoZXIgaW5jbHVkaW5nIHRoZSBpdGVtIG5lZWRzIHRvIGJyZWFrIGlu dGVyb3Agd2l0aCBhbGwgZXhpc3RpbmcgcmVjZWl2ZXJzLiBBIG1vZGUgZmllbGQgdGhhdCBNVVNU IGJlIHVuZGVyc3Rvb2QgKGVnIOKAnHTigJ064oCdc2ln4oCdKSBjb3VwbGVkIHdpdGggTVVTVCBp Z25vcmVkIGFueSB1bnJlY29nbml6ZWQgcGFyYW1ldGVycyBrZWVwcyBvdXIgZnV0dXJlIGNob2lj ZXMgb3Blbi4NCg0KDQo+IEhvd2V2ZXIgZGVjbGFyaW5nIHRoYXQgYW55IGhlYWRlciB5b3UgZG9u J3QgdW5kZXJzdGFuZCBjb3VsZCBiZSBvcHRpb25hbCBpcyBhIGZhciB3b3JzZSBiYWxhbmNlIG9u IHRoZSBleHRlbnNpYmlsaXR5IHZlcnN1cyBzaW1wbGljaXR5IHNwZWN0cnVtICh3aGVyZSBzaW1w bGljaXR5IGhlcmUgaXMgYSBzdGFuZC1pbiBmb3Igc2VjdXJpdHksIGludGVyb3BlcmFiaWxpdHks IGV0Yy4pDQoNCknigJltIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB0aGlzIOKAnHNpbXBsaWNpdHni gJ0gYXJndW1lbnQuIElnbm9yaW5nIHVucmVjb2duaXplZCBmaWVsZHMgaXMgdGhlIHNpbXBsZXN0 IGltcGxlbWVudGF0aW9uIGNob2ljZS4gSXMgeW91ciBpZGVhIHRoYXQgaWYgeW91IHRpZ2h0bHkg Y29uc3RyYWluIGV4dGVuc2liaWxpdHkgKGJ5IG1ha2luZyB0aGVtIE1VU1QgdW5kZXJzdGFuZCkg dGhlbiBtZXNzYWdlcyB3aWxsIG5vdCBhY2N1bXVsYXRlIGFzIG1hbnkg4oCcZW5oYW5jZW1lbnRz 4oCdIG9mIGR1YmlvdXMgdmFsdWUuIFRoYXQgaXMsIG92ZXIgdGltZSBhIE1VU1QgaWdub3JlIHJ1 bGUgYWxsb3dzIG1lc3NhZ2VzIHRvIGdldCBtb3JlIGNvbXBsZXggKGFuZCBoZW5jZSBsZXNzIHNl Y3VyZS9pbnRlcm9wZXJhYmxlKS4gRG8geW91IHdhbnQg4oCcTVVTVCB1bmRlcnN0YW5k4oCdIHRv IHN0cm9uZ2x5IGRpc2NvdXJhZ2UgcGVvcGxlIG1pc3VzaW5nIHRoZSBoZWFkZXIgdG8gY2Fycnkg Y29udGVudCBtZXRhZGF0YSwgZm9yIGluc3RhbmNlPw0KDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0K RnJvbTogQnJlbm8gZGUgTWVkZWlyb3MgW21haWx0bzpicmVub0Bnb29nbGUuY29tXQ0KU2VudDog VGh1cnNkYXksIDI2IEp1bHkgMjAxMiAxOjEyIFBNDQpUbzogTWFuZ2VyLCBKYW1lcyBIDQpDYzog am9zZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtqb3NlXSBNVVNUIHVuZGVyc3RhbmQgQUxMIGhl YWRlciBmaWVsZHMNCg0KVGhhdCdzIGEgbW9yZSBjb21wZWxsaW5nIHVzZSBjYXNlIC0tIGl0J3Mg c2VjdXJpdHktc3BlY2lmaWMgYnV0IG9ubHkgYWRkcyB0byB0aGUgc2VjdXJpdHkgdmFsaWRhdGlv biBjb250ZXh0Lg0KDQpUaGVyZSBtYXkgYmUgYSBjYXNlIHRvIGRlZmluZSBvcHRpb25hbCBlbnRy aWVzIGluIHRoZSBKV1QgaGVhZGVyLiBIb3dldmVyIGRlY2xhcmluZyB0aGF0IGFueSBoZWFkZXIg eW91IGRvbid0IHVuZGVyc3RhbmQgY291bGQgYmUgb3B0aW9uYWwgaXMgYSBmYXIgd29yc2UgYmFs YW5jZSBvbiB0aGUgZXh0ZW5zaWJpbGl0eSB2ZXJzdXMgc2ltcGxpY2l0eSBzcGVjdHJ1bSAod2hl cmUgc2ltcGxpY2l0eSBoZXJlIGlzIGEgc3RhbmQtaW4gZm9yIHNlY3VyaXR5LCBpbnRlcm9wZXJh YmlsaXR5LCBldGMuKSBTbyBJIGFtIG5vdCBjb252aW5jZWQgdGhhdCBsb3NpbmcgdGhlIGFiaWxp dHkgdG8gZGVjbGFyZSBPQ1NQIGJpbmRpbmdzIGluIEpXVHMganVzdGlmaWVzIGRyb3BwaW5nIHRo ZSBNVVNUIGxhbmd1YWdlLiBJZiB0aGVyZSBpcyByb3VnaCBjb25zZW5zdXMgdGhhdCBkZWZpbmlu ZyBvcHRpb25hbCBzZWN1cml0eSBmaWVsZHMgaW4gdGhlIGhlYWRlciBpcyBwcnVkZW50IGZyb20g dGhlIHZpZXdwb2ludCBvZiBmdXR1cmUgc3BlYyBleHRlbnNpYmlsaXR5IHRoZW4gd2Ugc2hvdWxk IGRldmlzZSBzb21lIHNpbXBsZSB3YXkgdG8gZGVjbGFyZSBhIEpXVCBoZWFkZXIgZmllbGQgb3B0 aW9uYWwgYW5kIGV4ZW1wdCBfb25seV90aG9zZV8gZnJvbSB0aGUgTVVTVCBmYWlsIHdoZW4gbm90 IHVuZGVyc3RhbmRpbmcgY2xhdXNlLiBDaGFuZ2luZyB0aGUgZGVmYXVsdCBiZWhhdmlvciBldmVu IHRvIFNIT1VMRCBhcHBlYXJzIHRvIG1lIHRvIHNhY3JpZmljZSB0b28gbXVjaCBvbiB0aGUgYWx0 YXIgb2YgZXh0ZW5zaWJpbGl0eS4NCg0KT24gV2VkLCBKdWwgMjUsIDIwMTIgYXQgNzozOCBQTSwg TWFuZ2VyLCBKYW1lcyBIIDxKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPG1haWx0bzpK YW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPj4gd3JvdGU6DQpIb3cgYWJvdXQgc3RhcGxp bmcgYW4gT0NTUCByZXNwb25zZSB0byBhIEpPU0UgbWVzc2FnZT8NCg0KV2h5IHNob3VsZCB0aGF0 IGJlICJNVVNUIHVuZGVyc3RhbmQiPw0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCg0KDQotLQ0KLS1C cmVubw0K --_000_255B9BB34FB7D647A506DC292726F6E114F8073950WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPjxoZWFkPjxtZXRhIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQv aHRtbDsgY2hhcnNldD11dGYtOCI+PG1ldGEgbmFtZT1HZW5lcmF0b3IgY29udGVudD0iTWljcm9z b2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPjxzdHlsZT48IS0tDQovKiBGb250IERlZmlu aXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBh bm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpD YWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8q IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tQVUgbGlu az1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5CcmVubyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZn dDsmZ3Q7IEhvdyBhYm91dCBzdGFwbGluZyBhbiBPQ1NQIHJlc3BvbnNlIHRvIGEgSk9TRSBtZXNz YWdlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz4mZ3Q7IFRoYXQncyBhIG1vcmUgY29tcGVsbGluZyB1c2UgY2FzZSAtLSBpdCdz IHNlY3VyaXR5LXNwZWNpZmljIGJ1dCBvbmx5IGFkZHMgdG8gdGhlIHNlY3VyaXR5IHZhbGlkYXRp b24gY29udGV4dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Ib3cgYWJvdXQgdGhl IHNpZ25pbmcgdGltZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkhvdyBhYm91dCBzb21lIEROUyByZWNv cmRzIHdpdGggREFORSBhbmQgRE5TU0VDIGluZm8gZ2l2aW5nIGV2aWRlbmNlIHRoYXQgdGhlIHB1 YmxpYyBrZXkgaXMgYXNzb2NpYXRlZCB3aXRoIGEgZG9tYWluPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ SG93IGFib3V0IGEgYmxvYiBvZiBkYXRhIHJlbGF0ZWQgdG8gU292ZXJlaWduIEtleXMsIG9yIFBl cnNwZWN0aXZlcywgb3IgQ29udmVyZ2VuY2UsIG9yIHNvbWUgb3RoZXIgcHJvcG9zYWwgdG8gYm9s c3RlciBQS0k/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Ib3cgYWJvdXQgYSBkb21haW5fcGFyYW1ldGVy X3NlZWQgc28geW91IGNhbiB2ZXJpZnkgdGhhdCB0aGUgY29tbW9uIGRvbWFpbiBwYXJhbWV0ZXJz IChlZyBwICZhbXA7IHEgaW4gRFNBKSB3ZXJlIG5vdCBjaG9zZW4gdG8gaGF2ZSBzcGVjaWFsIHBy b3BlcnRpZXM/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Ib3cgYWJvdXQgZGF0YSB0byBhbGxvdyB5b3Ug dG8gdmFsaWRhdGUgYSBwdWJsaWMga2V5IChlZyBjby1mYWN0b3IgZm9yIEVDPyBTb21ldGhpbmcg Y29tcGxpY2F0ZWQgZm9yIFJTQT8pPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SG93IGFib3V0IGEgdGlt ZXN0YW1wIGZyb20gYSB0aW1lc3RhbXAgc2VydmljZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5J4oCZbSBub3Qgc3VyZSB3aGljaCwgd2hlcmUsIG9yIHdoZW4gYW4gaXRlbSBsaWtl IHRoZSBvbmVzIG1lbnRpb25lZCBhYm92ZSB3aWxsIGJlIG5lZWRlZC4gSSBhbSBjb25maWRlbnQg dGhhdCBzb21lb25lIHdpbGwgbmVlZCBzb21lIGl0ZW1zIGxpa2UgdGhlc2UuIFdoZW4gdGhhdCBo YXBwZW5zIHRoZXkgc2hvdWxkIGhhdmUgYSBjaG9pY2UgYWJvdXQgd2hldGhlciBpbmNsdWRpbmcg dGhlIGl0ZW0gbmVlZHMgdG8gYnJlYWsgaW50ZXJvcCB3aXRoIGFsbCBleGlzdGluZyByZWNlaXZl cnMuIEEgbW9kZSBmaWVsZCB0aGF0IE1VU1QgYmUgdW5kZXJzdG9vZCAoZWcg4oCcdOKAnTrigJ1z aWfigJ0pIGNvdXBsZWQgd2l0aCBNVVNUIGlnbm9yZWQgYW55IHVucmVjb2duaXplZCBwYXJhbWV0 ZXJzIGtlZXBzIG91ciBmdXR1cmUgY2hvaWNlcyBvcGVuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4mZ3Q7IEhvd2V2ZXIg ZGVjbGFyaW5nIHRoYXQgYW55IGhlYWRlciB5b3UgZG9uJ3QgdW5kZXJzdGFuZCBjb3VsZCBiZSBv cHRpb25hbCBpcyBhIGZhciB3b3JzZSBiYWxhbmNlIG9uIHRoZSBleHRlbnNpYmlsaXR5IHZlcnN1 cyBzaW1wbGljaXR5IHNwZWN0cnVtICh3aGVyZSBzaW1wbGljaXR5IGhlcmUgaXMgYSBzdGFuZC1p biBmb3Igc2VjdXJpdHksIGludGVyb3BlcmFiaWxpdHksIGV0Yy4pPHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPknigJltIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB0aGlz IOKAnHNpbXBsaWNpdHnigJ0gYXJndW1lbnQuIElnbm9yaW5nIHVucmVjb2duaXplZCBmaWVsZHMg aXMgdGhlIHNpbXBsZXN0IGltcGxlbWVudGF0aW9uIGNob2ljZS4gSXMgeW91ciBpZGVhIHRoYXQg aWYgeW91IHRpZ2h0bHkgY29uc3RyYWluIGV4dGVuc2liaWxpdHkgKGJ5IG1ha2luZyB0aGVtIE1V U1QgdW5kZXJzdGFuZCkgdGhlbiBtZXNzYWdlcyB3aWxsIG5vdCBhY2N1bXVsYXRlIGFzIG1hbnkg 4oCcZW5oYW5jZW1lbnRz4oCdIG9mIGR1YmlvdXMgdmFsdWUuIFRoYXQgaXMsIG92ZXIgdGltZSBh IE1VU1QgaWdub3JlIHJ1bGUgYWxsb3dzIG1lc3NhZ2VzIHRvIGdldCBtb3JlIGNvbXBsZXggKGFu ZCBoZW5jZSBsZXNzIHNlY3VyZS9pbnRlcm9wZXJhYmxlKS4gRG8geW91IHdhbnQg4oCcTVVTVCB1 bmRlcnN0YW5k4oCdIHRvIHN0cm9uZ2x5IGRpc2NvdXJhZ2UgcGVvcGxlIG1pc3VzaW5nIHRoZSBo ZWFkZXIgdG8gY2FycnkgY29udGVudCBtZXRhZGF0YSwgZm9yIGluc3RhbmNlPzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi0tPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2PjxkaXYgc3R5 bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiIn PkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IEJyZW5vIGRlIE1lZGVpcm9zIFtt YWlsdG86YnJlbm9AZ29vZ2xlLmNvbV0gPGJyPjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgMjYgSnVs eSAyMDEyIDE6MTIgUE08YnI+PGI+VG86PC9iPiBNYW5nZXIsIEphbWVzIEg8YnI+PGI+Q2M6PC9i PiBqb3NlQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW2pvc2VdIE1VU1QgdW5kZXJz dGFuZCBBTEwgaGVhZGVyIGZpZWxkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PlRoYXQncyBhIG1vcmUgY29tcGVsbGluZyB1c2UgY2FzZSAtLSBpdCdzIHNlY3VyaXR5LXNwZWNp ZmljIGJ1dCBvbmx5IGFkZHMgdG8gdGhlIHNlY3VyaXR5IHZhbGlkYXRpb24gY29udGV4dC48bzpw PjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UaGVyZSBtYXkgYmUgYSBjYXNlIHRvIGRlZmlu ZSBvcHRpb25hbCBlbnRyaWVzIGluIHRoZSBKV1QgaGVhZGVyLiBIb3dldmVyIGRlY2xhcmluZyB0 aGF0IGFueSBoZWFkZXIgeW91IGRvbid0IHVuZGVyc3RhbmQgY291bGQgYmUgb3B0aW9uYWwgaXMg YSBmYXIgd29yc2UgYmFsYW5jZSBvbiB0aGUgZXh0ZW5zaWJpbGl0eSB2ZXJzdXMgc2ltcGxpY2l0 eSBzcGVjdHJ1bSAod2hlcmUgc2ltcGxpY2l0eSBoZXJlIGlzIGEgc3RhbmQtaW4gZm9yIHNlY3Vy aXR5LCBpbnRlcm9wZXJhYmlsaXR5LCBldGMuKSBTbyBJIGFtIG5vdCBjb252aW5jZWQgdGhhdCBs b3NpbmcgdGhlIGFiaWxpdHkgdG8gZGVjbGFyZSBPQ1NQIGJpbmRpbmdzIGluIEpXVHMganVzdGlm aWVzIGRyb3BwaW5nIHRoZSBNVVNUIGxhbmd1YWdlLiBJZiB0aGVyZSBpcyByb3VnaCBjb25zZW5z dXMgdGhhdCBkZWZpbmluZyBvcHRpb25hbCBzZWN1cml0eSBmaWVsZHMgaW4gdGhlIGhlYWRlciBp cyBwcnVkZW50IGZyb20gdGhlIHZpZXdwb2ludCBvZiBmdXR1cmUgc3BlYyBleHRlbnNpYmlsaXR5 IHRoZW4gd2Ugc2hvdWxkIGRldmlzZSBzb21lIHNpbXBsZSB3YXkgdG8gZGVjbGFyZSBhIEpXVCBo ZWFkZXIgZmllbGQgb3B0aW9uYWwgYW5kIGV4ZW1wdCBfb25seV90aG9zZV8gZnJvbSB0aGUgTVVT VCBmYWlsIHdoZW4gbm90IHVuZGVyc3RhbmRpbmcgY2xhdXNlLiBDaGFuZ2luZyB0aGUgZGVmYXVs dCBiZWhhdmlvciBldmVuIHRvIFNIT1VMRCBhcHBlYXJzIHRvIG1lIHRvIHNhY3JpZmljZSB0b28g bXVjaCBvbiB0aGUgYWx0YXIgb2YgZXh0ZW5zaWJpbGl0eS4mbmJzcDs8bzpwPjwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQn PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9uIFdlZCwgSnVs IDI1LCAyMDEyIGF0IDc6MzggUE0sIE1hbmdlciwgSmFtZXMgSCAmbHQ7PGEgaHJlZj0ibWFpbHRv OkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20iIHRhcmdldD0iX2JsYW5rIj5KYW1lcy5I Lk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPkhvdyBhYm91dCBzdGFwbGluZyBhbiBPQ1NQIHJlc3BvbnNlIHRvIGEg Sk9TRSBtZXNzYWdlPzxicj48YnI+V2h5IHNob3VsZCB0aGF0IGJlICZxdW90O01VU1QgdW5kZXJz dGFuZCZxdW90Oz88YnI+PGJyPi0tPGJyPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48YnI+PGJyIGNsZWFyPWFsbD48bzpwPjwvbzpwPjwvcD48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1N c29Ob3JtYWw+LS0gPGJyPi0tQnJlbm88bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48 L2JvZHk+PC9odG1sPg== --_000_255B9BB34FB7D647A506DC292726F6E114F8073950WSMSG3153Vsrv_-- From breno@google.com Thu Jul 26 09:16:55 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E262921F8628 for ; Thu, 26 Jul 2012 09:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmUyCBnDENzO for ; Thu, 26 Jul 2012 09:16:53 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 775A121F85BB for ; Thu, 26 Jul 2012 09:16:53 -0700 (PDT) Received: by yenq13 with SMTP id q13so2370761yen.31 for ; Thu, 26 Jul 2012 09:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=oxswbCSXTKNX34N7XxyAbrJ57tj4eZEo3uDM8ho0xhY=; b=cZKQMtc3cJR4taf/NrqDXDuCpkByUu+vt3oewGr652Dcr40aGE7unjoXu04VjA4A+p zZozYusREu+F/3MQQO6iSJ9NdFJnqeYMTXAMxYaUatSaIOfp3ShbAKLyOHgvStVgrSTH PSuZY5cEmXZ7BarIx1NVtyfIVBYuHXW8IuikZdIkCZOEEWISTQjcWilozJAKDYjEO9/T n/c1DV2FHpUveYjMtWyw8fdYI5rNMM0yPriNE2ExJmaILzTKDbklMGqlvR9+l+12gQtJ 0EUTBwk1VD8j3EwRcG9GaXjOEJm2BXbx2ioZJlVYUfLm5DE9WGGxvYLZhWLxwTLPqPf7 IBLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=oxswbCSXTKNX34N7XxyAbrJ57tj4eZEo3uDM8ho0xhY=; b=iGRcUhujmsNMJDfUzyJtILxtk+rCPVq7eEMovSJyuUGfT4BNAmWnqV3pGH8qJxEMRb YqM/DAMZmBhTZ02rEtJstZfnzZ+nklW4hgG7VTEmRqRXwV51zYdz0Y7/cbz8KSB1G7KS 5GJVd3mz6qn2VKeJKW7MGDFY7cDb0B/CIH3ZSmPAzXq2A+3ijTtvscOGRypRj1Sq/hoW Cq2LGT9eU7tlT2qqm3NOBSRaBnC3uOmoQph64xKq7u1n8J1NPougyYIAU0lGJ1WSlBZf ClckJrDqfdgIfyCM84+20TWYuq/IMhvEiGkoBN0Pmf77sozE/EHixcJNuPrYwjj8f2U8 iN+w== Received: by 10.50.106.166 with SMTP id gv6mr2154064igb.46.1343319412572; Thu, 26 Jul 2012 09:16:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.106.166 with SMTP id gv6mr2154058igb.46.1343319412458; Thu, 26 Jul 2012 09:16:52 -0700 (PDT) Received: by 10.231.17.194 with HTTP; Thu, 26 Jul 2012 09:16:52 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F8073950@WSMSG3153V.srv.dir.telstra.com> References: <82F6AE16-F7D7-4733-863B-DE0776D84809@team.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F8073950@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 26 Jul 2012 09:16:52 -0700 Message-ID: From: Breno de Medeiros To: "Manger, James H" Content-Type: multipart/alternative; boundary=e89a8f23535b66469604c5bdec89 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlJ22GYmzxk2876zs0DC2dGDiEeoHQtd67EqJM180mr0HLttrrLgSptF1HsdxP45aQeID6lwL6hDRh/LqxuqLdETie+mQ4UH2uWAUdpLLP/cnz7AXuhjlhsFRkhCgP76Bc8Rc2SrWPgpQF7C11QjLlQwMkEF8TRxnE4aXgCGajRQblXyb4= Cc: "jose@ietf.org" Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 16:16:55 -0000 --e89a8f23535b66469604c5bdec89 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Jul 25, 2012 at 10:28 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > Breno,**** > > ** ** > > >> How about stapling an OCSP response to a JOSE message?**** > > > That's a more compelling use case -- it's security-specific but only > adds to the security validation context.**** > > ** ** > > ** ** > > How about the signing time?**** > > ** ** > > How about some DNS records with DANE and DNSSEC info giving evidence that > the public key is associated with a domain?**** > > ** ** > > How about a blob of data related to Sovereign Keys, or Perspectives, or > Convergence, or some other proposal to bolster PKI?**** > > ** ** > > How about a domain_parameter_seed so you can verify that the common domai= n > parameters (eg p & q in DSA) were not chosen to have special properties?*= * > ** > > ** ** > > How about data to allow you to validate a public key (eg co-factor for EC= ? > Something complicated for RSA?)?**** > > ** ** > > How about a timestamp from a timestamp service?**** > > ** ** > > ** ** > > I=92m not sure which, where, or when an item like the ones mentioned abov= e > will be needed. I am confident that someone will need some items like > these. When that happens they should have a choice about whether includin= g > the item needs to break interop with all existing receivers. A mode field > that MUST be understood (eg =93t=94:=94sig=94) coupled with MUST ignored = any > unrecognized parameters keeps our future choices open. > That's not good enough for a security spec. If fields are added and not all MUST be understood, then we need explicit syntax about what fields are to be ignored when not understood. E.g., in X509 certificates, extensions (while optional) have the ability to declare themselves critical, so that implementations that don't understand that extension MUST reject the certificate as invalid. > **** > > ** ** > > ** ** > > > However declaring that any header you don't understand could be optiona= l > is a far worse balance on the extensibility versus simplicity spectrum > (where simplicity here is a stand-in for security, interoperability, etc.= ) > **** > > ** ** > > I=92m not sure I understand this =93simplicity=94 argument. Ignoring > unrecognized fields is the simplest implementation choice. Is your idea > that if you tightly constrain extensibility (by making them MUST > understand) then messages will not accumulate as many =93enhancements=94 = of > dubious value. That is, over time a MUST ignore rule allows messages to g= et > more complex (and hence less secure/interoperable). Do you want =93MUST > understand=94 to strongly discourage people misusing the header to carry > content metadata, for instance? > Inevitably, a field will be added that shouldn't be ignored because it modifies the meaning of some other widely understood header entry, followed by usual antics and general perplexity. > **** > > ** ** > > ** ** > > --**** > > James Manger**** > > ** ** > > *From:* Breno de Medeiros [mailto:breno@google.com] > *Sent:* Thursday, 26 July 2012 1:12 PM > *To:* Manger, James H > *Cc:* jose@ietf.org > > *Subject:* Re: [jose] MUST understand ALL header fields**** > > ** ** > > That's a more compelling use case -- it's security-specific but only adds > to the security validation context.**** > > ** ** > > There may be a case to define optional entries in the JWT header. However > declaring that any header you don't understand could be optional is a far > worse balance on the extensibility versus simplicity spectrum (where > simplicity here is a stand-in for security, interoperability, etc.) So I = am > not convinced that losing the ability to declare OCSP bindings in JWTs > justifies dropping the MUST language. If there is rough consensus that > defining optional security fields in the header is prudent from the > viewpoint of future spec extensibility then we should devise some simple > way to declare a JWT header field optional and exempt _only_those_ from t= he > MUST fail when not understanding clause. Changing the default behavior ev= en > to SHOULD appears to me to sacrifice too much on the altar of > extensibility. **** > > ** ** > > On Wed, Jul 25, 2012 at 7:38 PM, Manger, James H < > James.H.Manger@team.telstra.com> wrote:**** > > How about stapling an OCSP response to a JOSE message? > > Why should that be "MUST understand"? > > -- > James Manger**** > > > > **** > > ** ** > > -- > --Breno**** > --=20 --Breno --e89a8f23535b66469604c5bdec89 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


On Wed, J= ul 25, 2012 at 10:28 PM, Manger, James H <James.H.Manger@tea= m.telstra.com> wrote:

Breno,=

= =A0

>= > How about stapling an OCSP response to a JOSE message?

> That's a m= ore compelling use case -- it's security-specific but only adds to the = security validation context.

=A0<= /p>

=A0

How about the signing tim= e?

How about some DNS record= s with DANE and DNSSEC info giving evidence that the public key is associat= ed with a domain?

=A0<= /p>

How about a blob of da= ta related to Sovereign Keys, or Perspectives, or Convergence, or some othe= r proposal to bolster PKI?

=A0<= /p>

How about a domain_par= ameter_seed so you can verify that the common domain parameters (eg p &= q in DSA) were not chosen to have special properties?=

=A0<= /p>

How about data to allo= w you to validate a public key (eg co-factor for EC? Something complicated = for RSA?)?

=A0<= /p>

How about a timestamp = from a timestamp service?

=A0<= /p>

=A0

I=92m not sure which, whe= re, or when an item like the ones mentioned above will be needed. I am conf= ident that someone will need some items like these. When that happens they = should have a choice about whether including the item needs to break intero= p with all existing receivers. A mode field that MUST be understood (eg =93= t=94:=94sig=94) coupled with MUST ignored any unrecognized parameters keeps= our future choices open.


That's not good enough for= a security spec. If fields are added and not all MUST be understood, then = we need explicit syntax about what fields are to be ignored when not unders= tood. E.g., in X509 certificates, extensions (while optional) have the abil= ity to declare themselves critical, so that implementations that don't = understand that extension MUST reject the certificate as invalid.
=A0

= =A0

<= /u>=A0

> However declaring that any header you don't= understand could be optional is a far worse balance on the extensibility v= ersus simplicity spectrum (where simplicity here is a stand-in for security= , interoperability, etc.)

=A0<= /p>

I=92m not sure I= understand this =93simplicity=94 argument. Ignoring unrecognized fields is= the simplest implementation choice. Is your idea that if you tightly const= rain extensibility (by making them MUST understand) then messages will not = accumulate as many =93enhancements=94 of dubious value. That is, over time = a MUST ignore rule allows messages to get more complex (and hence less secu= re/interoperable). Do you want =93MUST understand=94 to strongly discourage= people misusing the header to carry content metadata, for instance?=


Inevitably, a field will be ad= ded that shouldn't be ignored because it modifies the meaning of some o= ther widely understood header entry, followed by usual antics and general p= erplexity.
=A0

=A0<= /p>

=A0

--

James Manger<= /u>

=A0<= /p>

From: Breno de Medeiros [mailto:breno@google.com]
Sent: Thursday, 26 July 2012 1:12 PM
To: Manger, James HCc: jose@ietf.o= rg


Subject: Re: [jose] MUST unde= rstand ALL header fields

=A0

That's a more compelling use case -- it's security-speci= fic but only adds to the security validation context.

=A0

There may be a case to define optional entries in the JWT header. H= owever declaring that any header you don't understand could be optional= is a far worse balance on the extensibility versus simplicity spectrum (wh= ere simplicity here is a stand-in for security, interoperability, etc.) So = I am not convinced that losing the ability to declare OCSP bindings in JWTs= justifies dropping the MUST language. If there is rough consensus that def= ining optional security fields in the header is prudent from the viewpoint = of future spec extensibility then we should devise some simple way to decla= re a JWT header field optional and exempt _only_those_ from the MUST fail w= hen not understanding clause. Changing the default behavior even to SHOULD = appears to me to sacrifice too much on the altar of extensibility.=A0

=A0=

On Wed, Jul 25, 2012 at 7:38 PM, Man= ger, James H <James.H.Manger@team.telstra.com> wrote:

How about stapling an OCSP response to a JOSE messag= e?

Why should that be "MUST understand"?

--
Jame= s Manger



=A0

--
--Breno




-- --Breno
--e89a8f23535b66469604c5bdec89-- From breno@google.com Thu Jul 26 10:35:30 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C5C21F8601 for ; Thu, 26 Jul 2012 10:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sopVJb2Ewifr for ; Thu, 26 Jul 2012 10:35:29 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B933B21F85A3 for ; Thu, 26 Jul 2012 10:35:28 -0700 (PDT) Received: by yhq56 with SMTP id 56so2462101yhq.31 for ; Thu, 26 Jul 2012 10:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=m1nE8Kc/ezfYr2KTF/rQlHYQdWN9EhWLM/hsfuSnrXY=; b=d+RIVqkMXxWv0aQmkYMMu+ZFfbiug75mwOe6hOa3dcerROivg01e0lX7o1e+1Rngcx PO5Lgu0u64lkbM2ga11OJzv/9EgkIK8SoefwUkEt5YvCqbc3NcLfHzAp2OVguow26L01 XqfmdVzIYWIp/R6WAFhxZp+EW16Zo1xrnRAGl2/m3+d4+qaLllQCaO09igMoT3+HvO7R hpKPdNiXe6Kx9m7NiW32YJbez/+N704/j/i8US8h9ZkZ+pKpTUDlBbfy+vPS0hdqBTIL QmuJj3VXQNCmA4ZQQAUs+cmy6BsBjkzDn5EEL5y3cUJ3tvxhG/KMtfh2LTtnfk4kjpl+ HibA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=m1nE8Kc/ezfYr2KTF/rQlHYQdWN9EhWLM/hsfuSnrXY=; b=AKYQuOC/isSDOCZKIXi93B9/oHcmZyC3/lbjGxiaSsG1p2GUEccL1pdh16U/U9u9J+ cOALNguLiYSP0yb/eVqQ97x9Ssa+jhsCMPrFPp751A+PVmfhe2X7jnTe1ItHnHKrDdsS ubFGesq6TaUgxUHkNh5sgTMV6W6KZmIV/mVwcF1PReqzlX6GVq2oPl40w/DeYlwmks/5 vdCdIBRdqdFzeyjRRmxvcdWnlXwQZdwuCveoqJFki2hghT5TRbgYBJolvR05PzXwvaJW zR0bo1+1vGcItsGgd4APP2U60Tj04jA+ZDCeiaXKMqc0GE+8TmLw6fps/2Sh4hl/GbKJ edNw== Received: by 10.50.222.162 with SMTP id qn2mr2377945igc.46.1343324127087; Thu, 26 Jul 2012 10:35:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.222.162 with SMTP id qn2mr2377933igc.46.1343324126905; Thu, 26 Jul 2012 10:35:26 -0700 (PDT) Received: by 10.231.17.194 with HTTP; Thu, 26 Jul 2012 10:35:26 -0700 (PDT) In-Reply-To: References: <82F6AE16-F7D7-4733-863B-DE0776D84809@team.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F8073950@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 26 Jul 2012 10:35:26 -0700 Message-ID: From: Breno de Medeiros To: "Manger, James H" Content-Type: multipart/alternative; boundary=14dae9340fbf67056804c5bf05c6 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlyAzH9lvQqlSaVMRmlMjPg2T1tF3DEryESHULOwt+RSq8Q6p7QHYttDMVOuB5HB/hWLY7B32V9IOgOUH0UHfTrpBcrI7zzlN+s0qd0XuOXSHm/c9BqvpLR1P9Itv6Qc1j3jFXgXHohN2TeGNsmyELJSUxGJRebk176PsCA2WpwtCIl/P4= Cc: "jose@ietf.org" Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 17:35:30 -0000 --14dae9340fbf67056804c5bf05c6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Put it another way: If we want the JWT security header to be extensible we need to define an explicit extension mechanism. It is NOT sufficient to say MUST ignore non-understood fields in the header. This will make it impossible to write secure implementations of validation libraries in practice. An extension mechanism would define: - How to bundle fields of an extension as a single object. - How to indicate that this object is an extension, and whether the extension is critical (can't be safely ignored) or not. You can't get extensibility cheaply in a security spec. A choice is needed whether to support extensibility explicitly (at the expense of significant increase of spec complexity, since a lot will have to be spelled out right now) or not. Giving up clear security semantics to get cheap extensibility is not an acceptable 3rd option. On Thu, Jul 26, 2012 at 9:16 AM, Breno de Medeiros wrote= : > > > > On Wed, Jul 25, 2012 at 10:28 PM, Manger, James H < > James.H.Manger@team.telstra.com> wrote: > >> Breno,**** >> >> ** ** >> >> >> How about stapling an OCSP response to a JOSE message?**** >> >> > That's a more compelling use case -- it's security-specific but only >> adds to the security validation context.**** >> >> ** ** >> >> ** ** >> >> How about the signing time?**** >> >> ** ** >> >> How about some DNS records with DANE and DNSSEC info giving evidence tha= t >> the public key is associated with a domain?**** >> >> ** ** >> >> How about a blob of data related to Sovereign Keys, or Perspectives, or >> Convergence, or some other proposal to bolster PKI?**** >> >> ** ** >> >> How about a domain_parameter_seed so you can verify that the common >> domain parameters (eg p & q in DSA) were not chosen to have special >> properties?**** >> >> ** ** >> >> How about data to allow you to validate a public key (eg co-factor for >> EC? Something complicated for RSA?)?**** >> >> ** ** >> >> How about a timestamp from a timestamp service?**** >> >> ** ** >> >> ** ** >> >> I=92m not sure which, where, or when an item like the ones mentioned abo= ve >> will be needed. I am confident that someone will need some items like >> these. When that happens they should have a choice about whether includi= ng >> the item needs to break interop with all existing receivers. A mode fiel= d >> that MUST be understood (eg =93t=94:=94sig=94) coupled with MUST ignored= any >> unrecognized parameters keeps our future choices open. >> > > That's not good enough for a security spec. If fields are added and not > all MUST be understood, then we need explicit syntax about what fields ar= e > to be ignored when not understood. E.g., in X509 certificates, extensions > (while optional) have the ability to declare themselves critical, so that > implementations that don't understand that extension MUST reject the > certificate as invalid. > > >> **** >> >> ** ** >> >> ** ** >> >> > However declaring that any header you don't understand could be >> optional is a far worse balance on the extensibility versus simplicity >> spectrum (where simplicity here is a stand-in for security, >> interoperability, etc.)**** >> >> ** ** >> >> I=92m not sure I understand this =93simplicity=94 argument. Ignoring >> unrecognized fields is the simplest implementation choice. Is your idea >> that if you tightly constrain extensibility (by making them MUST >> understand) then messages will not accumulate as many =93enhancements=94= of >> dubious value. That is, over time a MUST ignore rule allows messages to = get >> more complex (and hence less secure/interoperable). Do you want =93MUST >> understand=94 to strongly discourage people misusing the header to carry >> content metadata, for instance? >> > > Inevitably, a field will be added that shouldn't be ignored because it > modifies the meaning of some other widely understood header entry, follow= ed > by usual antics and general perplexity. > > >> **** >> >> ** ** >> >> ** ** >> >> --**** >> >> James Manger**** >> >> ** ** >> >> *From:* Breno de Medeiros [mailto:breno@google.com] >> *Sent:* Thursday, 26 July 2012 1:12 PM >> *To:* Manger, James H >> *Cc:* jose@ietf.org >> >> *Subject:* Re: [jose] MUST understand ALL header fields**** >> >> ** ** >> >> That's a more compelling use case -- it's security-specific but only add= s >> to the security validation context.**** >> >> ** ** >> >> There may be a case to define optional entries in the JWT header. Howeve= r >> declaring that any header you don't understand could be optional is a fa= r >> worse balance on the extensibility versus simplicity spectrum (where >> simplicity here is a stand-in for security, interoperability, etc.) So I= am >> not convinced that losing the ability to declare OCSP bindings in JWTs >> justifies dropping the MUST language. If there is rough consensus that >> defining optional security fields in the header is prudent from the >> viewpoint of future spec extensibility then we should devise some simple >> way to declare a JWT header field optional and exempt _only_those_ from = the >> MUST fail when not understanding clause. Changing the default behavior e= ven >> to SHOULD appears to me to sacrifice too much on the altar of >> extensibility. **** >> >> ** ** >> >> On Wed, Jul 25, 2012 at 7:38 PM, Manger, James H < >> James.H.Manger@team.telstra.com> wrote:**** >> >> How about stapling an OCSP response to a JOSE message? >> >> Why should that be "MUST understand"? >> >> -- >> James Manger**** >> >> >> >> **** >> >> ** ** >> >> -- >> --Breno**** >> > > > > -- > --Breno > --=20 --Breno --14dae9340fbf67056804c5bf05c6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Put it another way: If we want the JWT security header to be extensible we = need to define an explicit extension mechanism. It is NOT sufficient to say= MUST ignore non-understood fields in the header. This will make it impossi= ble to write secure implementations of validation libraries in practice.
An extension mechanism would define:

- How to bundle fields of an extension as a single object.
- Ho= w to indicate that this object is an extension, and whether the extension i= s critical (can't be safely ignored) or not.

You can't get extensibility cheaply in a security s= pec. A choice is needed whether to support extensibility explicitly (at the= expense of significant increase of spec complexity, since a lot will have = to be spelled out right now) or not. Giving up clear security semantics to = get cheap extensibility is not an acceptable 3rd option.



On Thu, Jul 26, 2012 at 9:16 AM, Breno de Medeiros <= breno@google.com&= gt; wrote:



On Wed, Jul 25, 2012 at 10:28 PM, M= anger, James H <James.H.Manger@team.telstra.com> wrote:

Breno,=

=A0

>> How abou= t stapling an OCSP response to a JOSE message?

> That's a m= ore compelling use case -- it's security-specific but only adds to the = security validation context.

=A0<= /p>

=A0

How about the signing tim= e?

How about some DNS record= s with DANE and DNSSEC info giving evidence that the public key is associat= ed with a domain?

=A0<= /p>

How about a blob of da= ta related to Sovereign Keys, or Perspectives, or Convergence, or some othe= r proposal to bolster PKI?

=A0<= /p>

How about a domain_par= ameter_seed so you can verify that the common domain parameters (eg p &= q in DSA) were not chosen to have special properties?=

=A0<= /p>

How about data to allo= w you to validate a public key (eg co-factor for EC? Something complicated = for RSA?)?

=A0<= /p>

How about a timestamp = from a timestamp service?

=A0<= /p>

=A0

I=92m not sure which, whe= re, or when an item like the ones mentioned above will be needed. I am conf= ident that someone will need some items like these. When that happens they = should have a choice about whether including the item needs to break intero= p with all existing receivers. A mode field that MUST be understood (eg =93= t=94:=94sig=94) coupled with MUST ignored any unrecognized parameters keeps= our future choices open.


That's not good enou= gh for a security spec. If fields are added and not all MUST be understood,= then we need explicit syntax about what fields are to be ignored when not = understood. E.g., in X509 certificates, extensions (while optional) have th= e ability to declare themselves critical, so that implementations that don&= #39;t understand that extension MUST reject the certificate as invalid.
=A0

=A0

=A0=

> However declaring that any header you don't= understand could be optional is a far worse balance on the extensibility v= ersus simplicity spectrum (where simplicity here is a stand-in for security= , interoperability, etc.)

=A0<= /p>

I=92m not sure I= understand this =93simplicity=94 argument. Ignoring unrecognized fields is= the simplest implementation choice. Is your idea that if you tightly const= rain extensibility (by making them MUST understand) then messages will not = accumulate as many =93enhancements=94 of dubious value. That is, over time = a MUST ignore rule allows messages to get more complex (and hence less secu= re/interoperable). Do you want =93MUST understand=94 to strongly discourage= people misusing the header to carry content metadata, for instance?=


Inevitably, a field will= be added that shouldn't be ignored because it modifies the meaning of = some other widely understood header entry, followed by usual antics and gen= eral perplexity.
=A0

=A0<= /p>

=A0

--

James Manger<= /u>

=A0<= /p>

From: Breno de Medeiros [mailto:breno@google.com]
Sent: Thursday, 26 July 2012 1:12 PM
To: Manger, James HCc: jose@ietf.o= rg


Subject: Re: [jose] MUST understand ALL he= ader fields

=A0

That's a more compelling use case -- it's security-speci= fic but only adds to the security validation context.

=A0

There may be a case to define optional entries in the JWT header. H= owever declaring that any header you don't understand could be optional= is a far worse balance on the extensibility versus simplicity spectrum (wh= ere simplicity here is a stand-in for security, interoperability, etc.) So = I am not convinced that losing the ability to declare OCSP bindings in JWTs= justifies dropping the MUST language. If there is rough consensus that def= ining optional security fields in the header is prudent from the viewpoint = of future spec extensibility then we should devise some simple way to decla= re a JWT header field optional and exempt _only_those_ from the MUST fail w= hen not understanding clause. Changing the default behavior even to SHOULD = appears to me to sacrifice too much on the altar of extensibility.=A0

=A0=

On Wed, Jul 25, 2012 at 7:38 PM, Man= ger, James H <James.H.Manger@team.telstra.com> wrote:

How about stapling an OCSP response to a JOSE messag= e?

Why should that be "MUST understand"?

--
Jame= s Manger



=A0

--
--Breno




--
--Breno



--
--Breno
--14dae9340fbf67056804c5bf05c6-- From Michael.Jones@microsoft.com Thu Jul 26 10:39:42 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D475821F8629 for ; Thu, 26 Jul 2012 10:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.274 X-Spam-Level: X-Spam-Status: No, score=-5.274 tagged_above=-999 required=5 tests=[AWL=1.324, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuN7+EdJ0-bY for ; Thu, 26 Jul 2012 10:39:39 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 036B721F8601 for ; Thu, 26 Jul 2012 10:39:38 -0700 (PDT) Received: from mail96-tx2-R.bigfish.com (10.9.14.238) by TX2EHSOBE015.bigfish.com (10.9.40.35) with Microsoft SMTP Server id 14.1.225.23; Thu, 26 Jul 2012 17:39:38 +0000 Received: from mail96-tx2 (localhost [127.0.0.1]) by mail96-tx2-R.bigfish.com (Postfix) with ESMTP id 6C9DC401C1; Thu, 26 Jul 2012 17:39:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VS-23(zz98dI9371Ic85fh1432Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail96-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail96-tx2 (localhost.localdomain [127.0.0.1]) by mail96-tx2 (MessageSwitch) id 1343324376399716_20016; Thu, 26 Jul 2012 17:39:36 +0000 (UTC) Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.247]) by mail96-tx2.bigfish.com (Postfix) with ESMTP id 5E63D260047; Thu, 26 Jul 2012 17:39:36 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 26 Jul 2012 17:39:35 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0309.003; Thu, 26 Jul 2012 17:38:43 +0000 From: Mike Jones To: Breno de Medeiros , "Manger, James H" Thread-Topic: [jose] MUST understand ALL header fields Thread-Index: Ac1q18qgDo+RPNtVSUCtA/itrmlQRAABKC6AAATFAIAAFqRnAAACvnEAAAANS0A= Date: Thu, 26 Jul 2012 17:38:42 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943667450D2@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <82F6AE16-F7D7-4733-863B-DE0776D84809@team.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F8073950@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943667450D2TK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 17:39:43 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943667450D2TK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with this analysis. If there's an explicit way defined to indicate= which additional header parameters may be ignored, that would be OK. Allo= wing ignore-by-default would be a recipe for disaster. -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Bre= no de Medeiros Sent: Thursday, July 26, 2012 10:35 AM To: Manger, James H Cc: jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields Put it another way: If we want the JWT security header to be extensible we = need to define an explicit extension mechanism. It is NOT sufficient to say= MUST ignore non-understood fields in the header. This will make it impossi= ble to write secure implementations of validation libraries in practice. An extension mechanism would define: - How to bundle fields of an extension as a single object. - How to indicate that this object is an extension, and whether the extensi= on is critical (can't be safely ignored) or not. You can't get extensibility cheaply in a security spec. A choice is needed = whether to support extensibility explicitly (at the expense of significant = increase of spec complexity, since a lot will have to be spelled out right = now) or not. Giving up clear security semantics to get cheap extensibility = is not an acceptable 3rd option. On Thu, Jul 26, 2012 at 9:16 AM, Breno de Medeiros > wrote: On Wed, Jul 25, 2012 at 10:28 PM, Manger, James H > wrote: Breno, >> How about stapling an OCSP response to a JOSE message? > That's a more compelling use case -- it's security-specific but only adds= to the security validation context. How about the signing time? How about some DNS records with DANE and DNSSEC info giving evidence that t= he public key is associated with a domain? How about a blob of data related to Sovereign Keys, or Perspectives, or Con= vergence, or some other proposal to bolster PKI? How about a domain_parameter_seed so you can verify that the common domain = parameters (eg p & q in DSA) were not chosen to have special properties? How about data to allow you to validate a public key (eg co-factor for EC? = Something complicated for RSA?)? How about a timestamp from a timestamp service? I'm not sure which, where, or when an item like the ones mentioned above wi= ll be needed. I am confident that someone will need some items like these. = When that happens they should have a choice about whether including the ite= m needs to break interop with all existing receivers. A mode field that MUS= T be understood (eg "t":"sig") coupled with MUST ignored any unrecognized p= arameters keeps our future choices open. That's not good enough for a security spec. If fields are added and not all= MUST be understood, then we need explicit syntax about what fields are to = be ignored when not understood. E.g., in X509 certificates, extensions (whi= le optional) have the ability to declare themselves critical, so that imple= mentations that don't understand that extension MUST reject the certificate= as invalid. > However declaring that any header you don't understand could be optional = is a far worse balance on the extensibility versus simplicity spectrum (whe= re simplicity here is a stand-in for security, interoperability, etc.) I'm not sure I understand this "simplicity" argument. Ignoring unrecognized= fields is the simplest implementation choice. Is your idea that if you tig= htly constrain extensibility (by making them MUST understand) then messages= will not accumulate as many "enhancements" of dubious value. That is, over= time a MUST ignore rule allows messages to get more complex (and hence les= s secure/interoperable). Do you want "MUST understand" to strongly discoura= ge people misusing the header to carry content metadata, for instance? Inevitably, a field will be added that shouldn't be ignored because it modi= fies the meaning of some other widely understood header entry, followed by = usual antics and general perplexity. -- James Manger From: Breno de Medeiros [mailto:breno@google.com] Sent: Thursday, 26 July 2012 1:12 PM To: Manger, James H Cc: jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields That's a more compelling use case -- it's security-specific but only adds t= o the security validation context. There may be a case to define optional entries in the JWT header. However d= eclaring that any header you don't understand could be optional is a far wo= rse balance on the extensibility versus simplicity spectrum (where simplici= ty here is a stand-in for security, interoperability, etc.) So I am not con= vinced that losing the ability to declare OCSP bindings in JWTs justifies d= ropping the MUST language. If there is rough consensus that defining option= al security fields in the header is prudent from the viewpoint of future sp= ec extensibility then we should devise some simple way to declare a JWT hea= der field optional and exempt _only_those_ from the MUST fail when not unde= rstanding clause. Changing the default behavior even to SHOULD appears to m= e to sacrifice too much on the altar of extensibility. On Wed, Jul 25, 2012 at 7:38 PM, Manger, James H > wrote: How about stapling an OCSP response to a JOSE message? Why should that be "MUST understand"? -- James Manger -- --Breno -- --Breno -- --Breno --_000_4E1F6AAD24975D4BA5B1680429673943667450D2TK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with this analysi= s.  If there’s an explicit way defined to indicate which additio= nal header parameters may be ignored, that would be OK.  Allowing igno= re-by-default would be a recipe for disaster.

 <= /p>

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

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Breno de Medeiros
Sent: Thursday, July 26, 2012 10:35 AM
To: Manger, James H
Cc: jose@ietf.org
Subject: Re: [jose] MUST understand ALL header fields

 

Put it another way: If we want the JWT security head= er to be extensible we need to define an explicit extension mechanism. It i= s NOT sufficient to say MUST ignore non-understood fields in the header. Th= is will make it impossible to write secure implementations of validation libraries in practice.

 

An extension mechanism would define:

 

- How to bundle fields of an extension as a single o= bject.

- How to indicate that this object is an extension, = and whether the extension is critical (can't be safely ignored) or not.

 

You can't get extensibility cheaply in a security sp= ec. A choice is needed whether to support extensibility explicitly (at the = expense of significant increase of spec complexity, since a lot will have t= o be spelled out right now) or not. Giving up clear security semantics to get cheap extensibility is not an ac= ceptable 3rd option.

 

 

On Thu, Jul 26, 2012 at 9:16 AM, Breno de Medeiros &= lt;breno@google.com> wrote:

 

 

On Wed, Jul 25, 2012 at 10:28 PM, Manger, James H &l= t;Jame= s.H.Manger@team.telstra.com> wrote:

Breno,

 

>> How about stapl= ing an OCSP response to a JOSE message?

> That's a more compe= lling use case -- it's security-specific but only adds to the security validation context.

 

 

How about the signing ti= me?

 

How about some DNS recor= ds with DANE and DNSSEC info giving evidence that the public key is associated with a domain?

 

How about a blob of data= related to Sovereign Keys, or Perspectives, or Convergence, or some other proposal to bolster PKI?

 

How about a domain_param= eter_seed so you can verify that the common domain parameters (eg p & q in DSA) were not chosen to have special properties?

 

How about data to allow = you to validate a public key (eg co-factor for EC? Something complicated for RSA?)?

 

How about a timestamp fr= om a timestamp service?

 

 

I’m not sure which= , where, or when an item like the ones mentioned above will be needed. I am confident that someone will need some items like these. When that hap= pens they should have a choice about whether including the item needs to br= eak interop with all existing receivers. A mode field that MUST be understo= od (eg “t”:”sig”) coupled with MUST ignored any unrecognized parameters keeps our future choices open.<= span lang=3D"EN-AU">

 

That's not good enough for a security spec. If field= s are added and not all MUST be understood, then we need explicit syntax ab= out what fields are to be ignored when not understood. E.g., in X509 certif= icates, extensions (while optional) have the ability to declare themselves critical, so that implementations t= hat don't understand that extension MUST reject the certificate as invalid.=

 

 

 

> However declaring that any header you do= n't understand could be optional is a far worse balance on the extensibilit= y versus simplicity spectrum (where simplicity here is a stand-in for security, interoperability, etc.)=

 

I’m not sure I und= erstand this “simplicity” argument. Ignoring unrecognized field= s is the simplest implementation choice. Is your idea that if you tightly const= rain extensibility (by making them MUST understand) then messages will not = accumulate as many “enhancements” of dubious value. That is, ov= er time a MUST ignore rule allows messages to get more complex (and hence less secure/interoperable). Do you want “= ;MUST understand” to strongly discourage people misusing the header t= o carry content metadata, for instance?

 

Inevitably, a field will be added that shouldn't be = ignored because it modifies the meaning of some other widely understood hea= der entry, followed by usual antics and general perplexity.

 

 

 

--

James Manger

 

From: Breno de Medeiros [mai= lto:breno@google.com<= /a>]
Sent: Thursday, 26 July 2012 1:12 PM
To: Manger, James H
Cc: jose@ietf.org=


Subject: Re: [jose] MUST understand ALL header fields

 

That's a more compelling use case -- it's sec= urity-specific but only adds to the security validation context.=

 

There may be a case to define optional entrie= s in the JWT header. However declaring that any header you don't understand= could be optional is a far worse balance on the extensibility versus simplicity spectrum (where simplicity here is = a stand-in for security, interoperability, etc.) So I am not convinced that= losing the ability to declare OCSP bindings in JWTs justifies dropping the= MUST language. If there is rough consensus that defining optional security fields in the header is prudent = from the viewpoint of future spec extensibility then we should devise some = simple way to declare a JWT header field optional and exempt _only_those_ f= rom the MUST fail when not understanding clause. Changing the default behavior even to SHOULD appears to me to sacr= ifice too much on the altar of extensibility. 

 

On Wed, Jul 25, 2012 at 7:38 PM, Manger, Jame= s H <James.H.Manger@team.telstra.com> wrote:

How about stapling an OCSP response to a JOSE= message?

Why should that be "MUST understand"?

--
James Manger



 

--
--Breno



 

--
--Breno



 

--
--Breno

--_000_4E1F6AAD24975D4BA5B1680429673943667450D2TK5EX14MBXC285r_-- From James.H.Manger@team.telstra.com Thu Jul 26 20:44:48 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE89621F85D8 for ; Thu, 26 Jul 2012 20:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kp3AEs8Etg86 for ; Thu, 26 Jul 2012 20:44:48 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 02FE721F85D0 for ; Thu, 26 Jul 2012 20:44:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,664,1336312800"; d="scan'208";a="82850646" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipocni.tcif.telstra.com.au with ESMTP; 27 Jul 2012 13:44:46 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6784"; a="73169710" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcdni.tcif.telstra.com.au with ESMTP; 27 Jul 2012 13:44:46 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Fri, 27 Jul 2012 13:44:45 +1000 From: "Manger, James H" To: Breno de Medeiros , "jose@ietf.org" Date: Fri, 27 Jul 2012 13:44:44 +1000 Thread-Topic: [jose] MUST understand ALL header fields Thread-Index: Ac1rVQ3bCmokH9nTQreN4QHFu2FdtAAQttfw Message-ID: <255B9BB34FB7D647A506DC292726F6E114F80F4DD0@WSMSG3153V.srv.dir.telstra.com> References: <82F6AE16-F7D7-4733-863B-DE0776D84809@team.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F8073950@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 03:44:49 -0000 QnJlbm8sDQoNCj4gSW5ldml0YWJseSwgYSBmaWVsZCB3aWxsIGJlIGFkZGVkIHRoYXQgc2hvdWxk bid0IGJlIGlnbm9yZWQgYmVjYXVzZSBpdCBtb2RpZmllcyB0aGUgbWVhbmluZyBvZiBzb21lIG90 aGVyIHdpZGVseSB1bmRlcnN0b29kIGhlYWRlciBlbnRyeSwgZm9sbG93ZWQgYnkgdXN1YWwgYW50 aWNzIGFuZCBnZW5lcmFsIHBlcnBsZXhpdHkuDQoNCklzIHRoZXJlIGEgZ29vZCBleGFtcGxlIG9m IHdoZXJlIHRoaXMgaGFzIG9jY3VycmVkPyBUaGF0IG1pZ2h0IGhlbHAgdXMgcmVhY2ggYSBjb21t b24gdW5kZXJzdGFuZGluZy4NCg0KDQo+IEFuIGV4dGVuc2lvbiBtZWNoYW5pc20gd291bGQgZGVm aW5lOg0KPg0KPiAtIEhvdyB0byBidW5kbGUgZmllbGRzIG9mIGFuIGV4dGVuc2lvbiBhcyBhIHNp bmdsZSBvYmplY3QuDQo+IC0gSG93IHRvIGluZGljYXRlIHRoYXQgdGhpcyBvYmplY3QgaXMgYW4g ZXh0ZW5zaW9uLCBhbmQgd2hldGhlciB0aGUgZXh0ZW5zaW9uIGlzIGNyaXRpY2FsIChjYW4ndCBi ZSBzYWZlbHkgaWdub3JlZCkgb3Igbm90Lg0KDQpJZiB3ZSBzdXBwb3J0IGV4dGVuc2liaWxpdHkg d2l0aCBwZXItZXh0ZW5zaW9uIGNyaXRpY2FsaXR5IGZsYWdzLCB3b3VsZG4ndCBpdCBiZSBhbG1v c3QgYXMgaW5ldml0YWJsZSB0aGF0IGFuIGV4dGVuc2lvbiB3aWxsIGJlIGFkZGVkIHRoYXQgc2hv dWxkbid0IGJlIGlnbm9yZWQgYnV0IGlzIG1hcmtlZCBub24tY3JpdGljYWwgdG8gbm90IGJyZWFr IGludGVyb3A/IE9yIGRvIHlvdSB0aGluayBwZW9wbGUgd2lsbCAiZG8gdGhlIHJpZ2h0IHRoaW5n IChub3QgdGhlIGVhc3kgdGhpbmcpIiB3aXRoIGNyaXRpY2FsaXR5IGZsYWdzPw0KDQpQLlMuIElm IHRoZSA3IGhlYWRlciBwYXJhbWV0ZXJzIHRoYXQgYXJlIGRlZmluZWQgaW4gSldTIChkcmFmdCAw NCkgYnV0IG5ldmVyIHVzZWQgaW4gaXRzIGV4YW1wbGVzIHdlcmUgYWxsIGRlZmluZWQgYXMgImV4 dGVuc2lvbnMiLCB3b3VsZCBhbnkgYmUgY3JpdGljYWw/IGprdT8gandrPyB4NXU/IHg1dD8geDVj PyBraWQ/IGN0eT8gSSBkb3VidCBpdC4NCg0KDQo+IEl0IGlzIE5PVCBzdWZmaWNpZW50IHRvIHNh eSBNVVNUIGlnbm9yZSBub24tdW5kZXJzdG9vZCBmaWVsZHMgaW4gdGhlIGhlYWRlci4gVGhpcyB3 aWxsIG1ha2UgaXQgaW1wb3NzaWJsZSB0byB3cml0ZSBzZWN1cmUgaW1wbGVtZW50YXRpb25zIG9m IHZhbGlkYXRpb24gbGlicmFyaWVzIGluIHByYWN0aWNlLg0KDQpDTVMgW1JGQzU2NTJdIGFuZCBp dHMgQUVBRCBtb2RlIFtSRkM1MDgzXSBib3RoIGhhdmUgYXV0aEF0dHJzIGZpZWxkcyB0aGF0IGNh biBob2xkIGFyYml0cmFyeSBhdHRyaWJ1dGVzLiBJIHNlZSBubyBtZW50aW9uIGluIHRob3NlIHNw ZWNzIG9mIGEgIk1VU1QgdW5kZXJzdGFuZCIgcnVsZSBmb3IgYXR0cmlidXRlcyBpbiB0aG9zZSBm aWVsZHMuIEkgaGF2ZW4ndCBoZWFyZCB0aGF0IHRoYXQgaGFzIG1hZGUgaXQgaW1wb3NzaWJsZSB0 byB3cml0ZSBzZWN1cmUgaW1wbGVtZW50YXRpb25zIG9mIHZhbGlkYXRpb24gbGlicmFyaWVzLg0K DQpJcyBpdCBPSyBmb3IgQ01TIGJlY2F1c2UgdGhlcmUgYXJlIGRlZGljYXRlZCBmaWVsZHMgZm9y IHRoZSBwcmltYXJ5IGl0ZW1zIChlZyBzaWduYXR1cmVBbGdvcml0aG0pLCBzZXBhcmF0ZSBmcm9t IHRoZSBhdXRoQXR0cnMgYnVja2V0PyBJIGRvbid0IHRoaW5rIHRoYXQgY2FuIGJlIHRoZSBkaWZm ZXJlbmNlLg0KDQpMb3RzIG9mIENNUyBhdHRyaWJ1dGVzIGhhdmUgYmVlbiBkZWZpbmVkIGJ5IGRp ZmZlcmVudCBwYXJ0aWVzLiBGb3IgaW5zdGFuY2UsIENNUyBBZHZhbmNlZCBFbGVjdHJvbmljIFNp Z25hdHVyZXMgKENBZEVTKSBbUkZDNTEyNl0gZGVmaW5lcyBvciBtZW50aW9ucyBkb3plbnMgKHNp Z25lci1sb2NhdGlvbiwgY29udGVudC1oaW50cywgc2lnbmluZy1jZXJ0aWZpY2F0ZSwgY29tbWl0 bWVudC10eXBlLCDigKYpLiBTb21lIE1VU1QgYmUgcHJlc2VudCBpbiBhIENBZEVTIG1lc3NhZ2Us IG90aGVycyBhcmUgT1BUSU9OQUwuIEZyb20gYSBxdWljayBnbGFuY2UgSSBkaWRuJ3Qgc2VlIGEg c3RhdGVtZW50IGFib3V0IHdoaWNoIE1VU1QgYmUgdW5kZXJzdG9vZC4NCg0KDQotLQ0KSmFtZXMg TWFuZ2VyDQo= From ietf@augustcellars.com Thu Jul 26 21:37:24 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F3111E80A3 for ; Thu, 26 Jul 2012 21:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.526 X-Spam-Level: X-Spam-Status: No, score=-3.526 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bowx1teUa+MV for ; Thu, 26 Jul 2012 21:37:20 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id F0DBE11E8073 for ; Thu, 26 Jul 2012 21:37:19 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id CEE7E2CA02; Thu, 26 Jul 2012 21:37:17 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , "'Breno de Medeiros'" , "'Manger, James H'" References: <82F6AE16-F7D7-4733-863B-DE0776D84809@team.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F8073950@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943667450D2@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943667450D2@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Thu, 26 Jul 2012 21:35:49 -0700 Message-ID: <022e01cd6bb1$4e98e9c0$ebcabd40$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_022F_01CD6B76.A23F41E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJiWfhm9ifvIrHdrYH/+rlKaFz2cwIo0LhCAcFXkmECkyfjMAKuSqqTAYQsPXOVvS/6oA== Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 04:37:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_022F_01CD6B76.A23F41E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't know if it is a good idea, but James has already given you a simple way of tagging fields that cannot be ignored - just append a '!' character. I guess you could just as easily append a '?' to those that could be ignored. That being said, I don't know that having optional mandatoriness is a good or a bad thing. Jim From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Thursday, July 26, 2012 10:39 AM To: Breno de Medeiros; Manger, James H Cc: jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields I agree with this analysis. If there's an explicit way defined to indicate which additional header parameters may be ignored, that would be OK. Allowing ignore-by-default would be a recipe for disaster. -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Breno de Medeiros Sent: Thursday, July 26, 2012 10:35 AM To: Manger, James H Cc: jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields Put it another way: If we want the JWT security header to be extensible we need to define an explicit extension mechanism. It is NOT sufficient to say MUST ignore non-understood fields in the header. This will make it impossible to write secure implementations of validation libraries in practice. An extension mechanism would define: - How to bundle fields of an extension as a single object. - How to indicate that this object is an extension, and whether the extension is critical (can't be safely ignored) or not. You can't get extensibility cheaply in a security spec. A choice is needed whether to support extensibility explicitly (at the expense of significant increase of spec complexity, since a lot will have to be spelled out right now) or not. Giving up clear security semantics to get cheap extensibility is not an acceptable 3rd option. On Thu, Jul 26, 2012 at 9:16 AM, Breno de Medeiros wrote: On Wed, Jul 25, 2012 at 10:28 PM, Manger, James H wrote: Breno, >> How about stapling an OCSP response to a JOSE message? > That's a more compelling use case -- it's security-specific but only adds to the security validation context. How about the signing time? How about some DNS records with DANE and DNSSEC info giving evidence that the public key is associated with a domain? How about a blob of data related to Sovereign Keys, or Perspectives, or Convergence, or some other proposal to bolster PKI? How about a domain_parameter_seed so you can verify that the common domain parameters (eg p & q in DSA) were not chosen to have special properties? How about data to allow you to validate a public key (eg co-factor for EC? Something complicated for RSA?)? How about a timestamp from a timestamp service? I'm not sure which, where, or when an item like the ones mentioned above will be needed. I am confident that someone will need some items like these. When that happens they should have a choice about whether including the item needs to break interop with all existing receivers. A mode field that MUST be understood (eg "t":"sig") coupled with MUST ignored any unrecognized parameters keeps our future choices open. That's not good enough for a security spec. If fields are added and not all MUST be understood, then we need explicit syntax about what fields are to be ignored when not understood. E.g., in X509 certificates, extensions (while optional) have the ability to declare themselves critical, so that implementations that don't understand that extension MUST reject the certificate as invalid. > However declaring that any header you don't understand could be optional is a far worse balance on the extensibility versus simplicity spectrum (where simplicity here is a stand-in for security, interoperability, etc.) I'm not sure I understand this "simplicity" argument. Ignoring unrecognized fields is the simplest implementation choice. Is your idea that if you tightly constrain extensibility (by making them MUST understand) then messages will not accumulate as many "enhancements" of dubious value. That is, over time a MUST ignore rule allows messages to get more complex (and hence less secure/interoperable). Do you want "MUST understand" to strongly discourage people misusing the header to carry content metadata, for instance? Inevitably, a field will be added that shouldn't be ignored because it modifies the meaning of some other widely understood header entry, followed by usual antics and general perplexity. -- James Manger From: Breno de Medeiros [mailto:breno@google.com] Sent: Thursday, 26 July 2012 1:12 PM To: Manger, James H Cc: jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields That's a more compelling use case -- it's security-specific but only adds to the security validation context. There may be a case to define optional entries in the JWT header. However declaring that any header you don't understand could be optional is a far worse balance on the extensibility versus simplicity spectrum (where simplicity here is a stand-in for security, interoperability, etc.) So I am not convinced that losing the ability to declare OCSP bindings in JWTs justifies dropping the MUST language. If there is rough consensus that defining optional security fields in the header is prudent from the viewpoint of future spec extensibility then we should devise some simple way to declare a JWT header field optional and exempt _only_those_ from the MUST fail when not understanding clause. Changing the default behavior even to SHOULD appears to me to sacrifice too much on the altar of extensibility. On Wed, Jul 25, 2012 at 7:38 PM, Manger, James H wrote: How about stapling an OCSP response to a JOSE message? Why should that be "MUST understand"? -- James Manger -- --Breno -- --Breno -- --Breno ------=_NextPart_000_022F_01CD6B76.A23F41E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<personal>

 

I don’t know if it is a good idea, but James has already given = you a simple way of tagging fields that cannot be ignored – just = append a ‘!’ character.  I guess you could just as = easily append a ‘?’ to those that could be = ignored.

 

That being said, I don’t know that having optional = mandatoriness is a good or a bad thing.

 

Jim

 

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Mike Jones
Sent: Thursday, July 26, 2012 10:39 = AM
To: Breno de Medeiros; Manger, James H
Cc: = jose@ietf.org
Subject: Re: [jose] MUST understand ALL header = fields

 

I agree with this analysis.  If there’s an explicit way = defined to indicate which additional header parameters may be ignored, = that would be OK.  Allowing ignore-by-default would be a recipe for = disaster.

 

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

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.= org] On Behalf Of Breno de Medeiros
Sent: Thursday, = July 26, 2012 10:35 AM
To: Manger, James H
Cc: jose@ietf.org
Subject: Re: = [jose] MUST understand ALL header fields

 

Put it = another way: If we want the JWT security header to be extensible we need = to define an explicit extension mechanism. It is NOT sufficient to say = MUST ignore non-understood fields in the header. This will make it = impossible to write secure implementations of validation libraries in = practice.

 

An extension mechanism would = define:

 

- = How to bundle fields of an extension as a single = object.

- How to indicate = that this object is an extension, and whether the extension is critical = (can't be safely ignored) or not.

 

You can't get extensibility cheaply in a security = spec. A choice is needed whether to support extensibility explicitly (at = the expense of significant increase of spec complexity, since a lot will = have to be spelled out right now) or not. Giving up clear security = semantics to get cheap extensibility is not an acceptable 3rd = option.

 

 

On Thu, Jul 26, 2012 at 9:16 AM, Breno de Medeiros = <breno@google.com> wrote:

 

 

On Wed, Jul 25, 2012 at 10:28 PM, Manger, James H = <James.H.Manger@team.telstra.com> = wrote:

Breno,

 

>> How about stapling an OCSP response to a JOSE = message?

> That's a more compelling use case -- it's security-specific but = only adds to the security validation context.

 

 

How about the signing time?

 

How about some DNS records with DANE and DNSSEC info giving evidence = that the public key is associated with a domain?

 

How about a blob of data related to Sovereign Keys, or Perspectives, = or Convergence, or some other proposal to bolster PKI?

 

How about a domain_parameter_seed so you can verify that the common = domain parameters (eg p & q in DSA) were not chosen to have special = properties?

 

How about data to allow you to validate a public key (eg co-factor = for EC? Something complicated for RSA?)?

 

How about a timestamp from a timestamp service?

 

 

I’m not sure which, where, or when an item like the ones = mentioned above will be needed. I am confident that someone will need = some items like these. When that happens they should have a choice about = whether including the item needs to break interop with all existing = receivers. A mode field that MUST be understood (eg = “t”:”sig”) coupled with MUST ignored any = unrecognized parameters keeps our future choices open.

 

That's not good enough for a security spec. If fields = are added and not all MUST be understood, then we need explicit syntax = about what fields are to be ignored when not understood. E.g., in X509 = certificates, extensions (while optional) have the ability to declare = themselves critical, so that implementations that don't understand that = extension MUST reject the certificate as = invalid.

 

 

 

> However declaring that any header you don't understand = could be optional is a far worse balance on the extensibility versus = simplicity spectrum (where simplicity here is a stand-in for security, = interoperability, etc.)

 

I’m not sure I understand this “simplicity” = argument. Ignoring unrecognized fields is the simplest implementation = choice. Is your idea that if you tightly constrain extensibility (by = making them MUST understand) then messages will not accumulate as many = “enhancements” of dubious value. That is, over time a MUST = ignore rule allows messages to get more complex (and hence less = secure/interoperable). Do you want “MUST understand” to = strongly discourage people misusing the header to carry content = metadata, for instance?

 

Inevitably, a field will be added that shouldn't be = ignored because it modifies the meaning of some other widely understood = header entry, followed by usual antics and general = perplexity.

 

 

 

--

James Manger

 

From:= = Breno de Medeiros [mailto:breno@google.com]
Sent: Thursday, 26 = July 2012 1:12 PM
To: Manger, James H
Cc: jose@ietf.org


Subject: Re: [jose] MUST understand ALL header = fields

 

That's a more compelling use case -- it's security-specific = but only adds to the security validation = context.

 

There may be a case to define optional entries in the JWT = header. However declaring that any header you don't understand could be = optional is a far worse balance on the extensibility versus simplicity = spectrum (where simplicity here is a stand-in for security, = interoperability, etc.) So I am not convinced that losing the ability to = declare OCSP bindings in JWTs justifies dropping the MUST language. If = there is rough consensus that defining optional security fields in the = header is prudent from the viewpoint of future spec extensibility then = we should devise some simple way to declare a JWT header field optional = and exempt _only_those_ from the MUST fail when not understanding = clause. Changing the default behavior even to SHOULD appears to me to = sacrifice too much on the altar of = extensibility. 

 

On Wed, Jul 25, 2012 at 7:38 PM, Manger, James H <James.H.Manger@team.telstra.com> = wrote:

How about stapling an OCSP response to a JOSE = message?

Why should that be "MUST = understand"?

--
James = Manger



 

-- =
--Breno



 

--
--Breno



 

-- =
--Breno

------=_NextPart_000_022F_01CD6B76.A23F41E0-- From ietf@augustcellars.com Thu Jul 26 21:43:14 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B9921F851B for ; Thu, 26 Jul 2012 21:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.529 X-Spam-Level: X-Spam-Status: No, score=-3.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VecoBAhP2wYT for ; Thu, 26 Jul 2012 21:43:14 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id E12CD21F8518 for ; Thu, 26 Jul 2012 21:43:13 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 92D172CA20; Thu, 26 Jul 2012 21:43:13 -0700 (PDT) From: "Jim Schaad" To: "'Manger, James H'" , "'Breno de Medeiros'" , References: <82F6AE16-F7D7-4733-863B-DE0776D84809@team.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F8073950@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F80F4DD0@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F80F4DD0@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 26 Jul 2012 21:41:45 -0700 Message-ID: <023301cd6bb2$22220ce0$666626a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJiWfhm9ifvIrHdrYH/+rlKaFz2cwIo0LhCAcFXkmECkyfjMAKuSqqTAUvDaGyVvvSYQA== Content-Language: en-us Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 04:43:14 -0000 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of > Manger, James H > Sent: Thursday, July 26, 2012 8:45 PM > To: Breno de Medeiros; jose@ietf.org > Subject: Re: [jose] MUST understand ALL header fields >=20 > Breno, >=20 > > Inevitably, a field will be added that shouldn't be ignored because = it > modifies the meaning of some other widely understood header entry, > followed by usual antics and general perplexity. >=20 > Is there a good example of where this has occurred? That might help us > reach a common understanding. >=20 >=20 > > An extension mechanism would define: > > > > - How to bundle fields of an extension as a single object. > > - How to indicate that this object is an extension, and whether the > extension is critical (can't be safely ignored) or not. >=20 > If we support extensibility with per-extension criticality flags, = wouldn't it be > almost as inevitable that an extension will be added that shouldn't be > ignored but is marked non-critical to not break interop? Or do you = think > people will "do the right thing (not the easy thing)" with criticality = flags? Anyone who believes this to be a true statement is more than welcome to = read the current firestorm about name constraints on the PKIX mailing = list. They were defined and said to be critical when the first draft = (RFC2459) came out in 1999 and people are saying that they need to make = it non-critical because too many people did not implement it. The JOSE = documents are better in that there are not as many "extensions" defined. = But the history is still there. Jim >=20 > P.S. If the 7 header parameters that are defined in JWS (draft 04) but = never > used in its examples were all defined as "extensions", would any be = critical? > jku? jwk? x5u? x5t? x5c? kid? cty? I doubt it. >=20 >=20 > > It is NOT sufficient to say MUST ignore non-understood fields in the > header. This will make it impossible to write secure implementations = of > validation libraries in practice. >=20 > CMS [RFC5652] and its AEAD mode [RFC5083] both have authAttrs fields = that > can hold arbitrary attributes. I see no mention in those specs of a = "MUST > understand" rule for attributes in those fields. I haven't heard that = that has > made it impossible to write secure implementations of validation = libraries. >=20 > Is it OK for CMS because there are dedicated fields for the primary = items (eg > signatureAlgorithm), separate from the authAttrs bucket? I don't think = that > can be the difference. >=20 > Lots of CMS attributes have been defined by different parties. For = instance, > CMS Advanced Electronic Signatures (CAdES) [RFC5126] defines or = mentions > dozens (signer-location, content-hints, signing-certificate, = commitment-type, > =EF=BF=BD). Some MUST be present in a CAdES message, others are = OPTIONAL. From > a quick glance I didn't see a statement about which MUST be = understood. >=20 >=20 > -- > James Manger > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From James.H.Manger@team.telstra.com Fri Jul 27 00:20:30 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D092221F8568 for ; Fri, 27 Jul 2012 00:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.181 X-Spam-Level: X-Spam-Status: No, score=-1.181 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZPerHqkZeSJ for ; Fri, 27 Jul 2012 00:20:30 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id DEA7A21F8566 for ; Fri, 27 Jul 2012 00:20:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,666,1336312800"; d="scan'208";a="84164331" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 27 Jul 2012 17:20:27 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6784"; a="94613981" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcavi.tcif.telstra.com.au with ESMTP; 27 Jul 2012 17:20:25 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Fri, 27 Jul 2012 17:20:24 +1000 From: "Manger, James H" To: "jose@ietf.org" Date: Fri, 27 Jul 2012 17:20:23 +1000 Thread-Topic: [jose] MUST understand ALL header fields: "!" field Thread-Index: Ac1rVQ3bCmokH9nTQreN4QHFu2FdtAAQttfwAASU9PA= Message-ID: <255B9BB34FB7D647A506DC292726F6E114F80F539E@WSMSG3153V.srv.dir.telstra.com> References: <82F6AE16-F7D7-4733-863B-DE0776D84809@team.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F8073950@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F80F4DD0@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F80F4DD0@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] MUST understand ALL header fields: "!" field X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 07:20:31 -0000 UHJvcG9zYWw6DQoNCkRlZmluZSBhIGhlYWRlciBmaWVsZCBuYW1lZCAiISIuDQpJdHMgdmFsdWUg aXMgYSBzdHJpbmcuDQpBIHNlbmRlciBNVVNUIGluY2x1ZGUgYSAiISIgZmllbGQgaW4gZXZlcnkg Sk9TRSBtZXNzYWdlLg0KQSByZWNlaXZlciBNVVNUIHJlamVjdCBhIEpPU0UgbWVzc2FnZSBpZiB0 aGUgdmFsdWUgb2YgdGhlICIhIiBmaWVsZCBpcyBub3QgcmVjb2duaXplZC4NClRoZSB2YWx1ZSBv ZiB0aGUgIiEiIGZpZWxkIGRlZmluZXMgdGhlIG1lYW5pbmcgb2YgdGhlIG1lc3NhZ2UsIGluY2x1 ZGluZyB3aGljaCBvdGhlciBmaWVsZHMgTVVTVCBiZSB1bmRlcnN0b29kIHRvIGNvcnJlY3RseSBp bnRlcnByZXQgdGhlIG1lc3NhZ2UgaW4gYSBmYWlsLXNhZmUgbWFubmVyLiBBbnkgb3RoZXIgZmll bGRzIHRoYXQgdGhlIHJlY2VpdmVyIGRvZXMgbm90IHJlY29nbml6ZSBNVVNUIGJlIGlnbm9yZWQu DQpJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IHJlY2VpdmVycyBsb2cgdGhlIG5hbWUgb2YgYW4gdW5y ZWNvZ25pemVkIGZpZWxkIHRoZSBmaXJzdCB0aW1lIHRoZXkgc2VlIGl0IGFzIGl0IGlzIGxpa2Vs eSB0byBwcm92aWRlIGEgaGludCBhcyB0byBob3cgdGhlIHJlY2VpdmVyIGNvdWxkIGJlIGltcHJv dmVkIChpbmNsdWRpbmcgYmVpbmcgbWFkZSBtb3JlIHNlY3VyZSkuDQoNCkJ5IG1ha2luZyB0aGUg IiEiIGZpZWxkIGRlZmluZSB0aGUgbWVhbmluZyBvZiB0aGUgbWVzc2FnZSwgdGhlIG9idmlvdXMg JiBlYXN5IGltcGxlbWVudGF0aW9uIGNob2ljZSBmb3IgYSByZWNlaXZlciBpcyB0byBzd2l0Y2gg dG8gYXBwcm9wcmlhdGUgaGFuZGxpbmcgY29kZSBiYXNlZCBvbiB0aGUgIiEiIHZhbHVlLiBJbXBs ZW1lbnRpbmcgdGhlICJNVVNUIHVuZGVyc3RhbmQiIHJ1bGUgZm9yIHRoZSAiISIgdmFsdWUgb2Nj dXJzIG5hdHVyYWxseSBhcyBwYXJ0IG9mIHN1Y2ggc3dpdGNoaW5nLiBDb25zZXF1ZW50bHksIHNl bmRlcnMgY2FuIGJlIGNvbmZpZGVudCB0aGF0IHRoaXMgIk1VU1QgdW5kZXJzdGFuZCIgcnVsZSB3 aWxsIGJlIGVuZm9yY2VkIGJ5IGxlZ2l0aW1hdGUgcmVjZWl2ZXJzLg0KW0luIGNvbnRyYXN0LCBh biBhbHRlcm5hdGl2ZSBydWxlIHRvIHJlamVjdCBtZXNzYWdlcyB3aXRoIGFueSB1bnJlY29nbml6 ZWQgZmllbGRzIHJlcXVpcmVzIHJlY2VpdmVycyB0byB3cml0ZSBleHRyYSBjb2RlIHRvIGZpbHRl ciBvdXQgYWxsIGtub3duIGZpZWxkcyBhbmQgc2VlIHdoYXQgcmVtYWlucy4gVGhhdCBleHRyYSBj b2RlIG9mZmVycyBubyBleHRyYSBmdW5jdGlvbmFsaXR5IHRvIHRoZSByZWNlaXZlcjsgaXQgaXMg bm90IG5lZWRlZCBmb3IgdGhlIHJlY2VpdmVyIHRvIHByb2Nlc3MgYSBtZXNzYWdlLiBDb25zZXF1 ZW50bHksIHNlbmRlcnMgY2FuIGhhdmUgbGl0dGxlIGNvbmZpZGVuY2UgdGhhdCBzdWNoIGEgIk1V U1QgdW5kZXJzdGFuZCIgcnVsZSB3aWxsIGJlIGNvbnNpc3RlbnRseSBlbmZvcmNlZC5dDQoNCk9u IGRlZmluaW5nIGEgbmV3IGZvcm0gb2YgSk9TRSBtZXNzYWdlLCBhIG5ldyB2YWx1ZSBmb3IgdGhl ICIhIiBmaWVsZCBNVVNUIGJlIGNob3NlbiBpZiB0aGUgbWVzc2FnZSBjb3VsZCBiZSBtaXNpbnRl cnByZXRlZCBpZiBpdCB1c2VkIGFuIGV4aXN0aW5nICIhIiB2YWx1ZS4NCg0KDQooRXhhbXBsZSkg aW5pdGlhbCB2YWx1ZXMgZm9yIHRoZSAiISIgZmllbGQ6DQoNCiIhIjoic2lnIiA9IHRoZSBKT1NF IG1lc3NhZ2UgY29udGFpbnMgYSBkaWdpdGFsIHNpZ25hdHVyZSBvdmVyIHRoZSBjb250ZW50IHVz aW5nIGFuIGFzeW1tZXRyaWMgYWxnb3JpdGhtLiBUaGUgImFsZyIgZmllbGQgTVVTVCBiZSB1bmRl cnN0b29kLiAuLi4NCg0KIiEiOiJlbmMiID0gdGhlIEpPU0UgbWVzc2FnZSB1c2VzIGEga25vd24g c3ltbWV0cmljIGtleSB3aXRoIGFuIEFFQUQgYWxnb3JpdGhtIHRvIGVuY3J5cHQgdGhlIGNvbnRl bnQuIFRoZSBjb250ZW50IG1heSBmaXJzdCBiZSBjb21wcmVzc2VkLiBUaGUgImVuYyIgYW5kICJ6 aXAiIGZpZWxkcyBNVVNUIGJlIHVuZGVyc3Rvb2QuIC4uLg0KDQoiISI6ImVudiIgPSB0aGUgSk9T RSBtZXNzYWdlIGNvbnRhaW5zIGNvbnRlbnRzIGVuY3J5cHRlZCB3aXRoIGFuIEFFQUQgYWxnb3Jp dGhtIHVzaW5nIGEgcmFuZG9tbHktY2hvc2VuIHBlci1tZXNzYWdlIGtleSB0aGF0IGlzIGNvbnZl eWVkIHRvIHRoZSByZWNlaXZlciB1c2luZyBhbiBhc3ltbWV0cmljIGtleSB0cmFuc3BvcnQgYWxn b3JpdGhtLCBvciBhbiBhc3ltbWV0cmljIGtleSBhZ3JlZW1lbnQgYWxnb3JpdGhtIGNvbWJpbmVk IHdpdGggYSBzeW1tZXRyaWMga2V5IHdyYXBwaW5nIGFsZ29yaXRobS4gVGhlIGNvbnRlbnQgbWF5 IGZpcnN0IGJlIGNvbXByZXNzZWQuIFRoZSAiZW5jIiwgInRycCIsICJhZ3IiLCAid3JwIiwgYW5k ICJ6aXAiIGZpZWxkcyBNVVNUIGJlIHVuZGVyc3Rvb2QuIC4uLg0KDQpMYXRlcg0KDQoiISI6ImVu djIiID0gYXMgcGVyICJlbnYiIGJ1dCBzdXBwb3J0aW5nIGlkZW50aXR5LWJhc2VkIGVuY3J5cHRp b24gKElCRSkgb3IgYSBzeW1tZXRyaWMgbWFzdGVyIGtleSBvciBlcGhlbWVyYWwgcHVibGljIGtl eXMgZm9yIGtleSBleGNoYW5nZS4gVGhlICJpYmUiLi4uIGZpZWxkcyBNVVNUIGJlIHVuZGVyc3Rv b2QsIGluIGFkZGl0aW9uIHRvIHRoZSBmaWVsZHMgbGlzdGVkIGZvciAiZW52Ii4NCg0KDQotLQ0K SmFtZXMgTWFuZ2VyDQoNCg0K From James.H.Manger@team.telstra.com Fri Jul 27 00:31:31 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE8021F85C7 for ; Fri, 27 Jul 2012 00:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DO29LDGI8Jbu for ; Fri, 27 Jul 2012 00:31:31 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id D130521F85C3 for ; Fri, 27 Jul 2012 00:31:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,666,1336312800"; d="scan'208";a="86240809" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 27 Jul 2012 17:31:30 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6784"; a="94618365" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcavi.tcif.telstra.com.au with ESMTP; 27 Jul 2012 17:31:29 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Fri, 27 Jul 2012 17:31:28 +1000 From: "Manger, James H" To: Jim Schaad , "jose@ietf.org" Date: Fri, 27 Jul 2012 17:31:27 +1000 Thread-Topic: [jose] MUST understand ALL header fields Thread-Index: AQJiWfhm9ifvIrHdrYH/+rlKaFz2cwIo0LhCAcFXkmECkyfjMAKuSqqTAUvDaGyVvvSYQIAALSGA Message-ID: <255B9BB34FB7D647A506DC292726F6E114F80F53B8@WSMSG3153V.srv.dir.telstra.com> References: <82F6AE16-F7D7-4733-863B-DE0776D84809@team.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F8073950@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F80F4DD0@WSMSG3153V.srv.dir.telstra.com> <023301cd6bb2$22220ce0$666626a0$@augustcellars.com> In-Reply-To: <023301cd6bb2$22220ce0$666626a0$@augustcellars.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 07:31:31 -0000 PiA+ID4gQW4gZXh0ZW5zaW9uIG1lY2hhbmlzbSB3b3VsZCBkZWZpbmU6DQo+ID4gPg0KPiA+ID4g LSBIb3cgdG8gYnVuZGxlIGZpZWxkcyBvZiBhbiBleHRlbnNpb24gYXMgYSBzaW5nbGUgb2JqZWN0 Lg0KPiA+ID4gLSBIb3cgdG8gaW5kaWNhdGUgdGhhdCB0aGlzIG9iamVjdCBpcyBhbiBleHRlbnNp b24sIGFuZCB3aGV0aGVyIHRoZQ0KPiA+IGV4dGVuc2lvbiBpcyBjcml0aWNhbCAoY2FuJ3QgYmUg c2FmZWx5IGlnbm9yZWQpIG9yIG5vdC4NCg0KPiA+IElmIHdlIHN1cHBvcnQgZXh0ZW5zaWJpbGl0 eSB3aXRoIHBlci1leHRlbnNpb24gY3JpdGljYWxpdHkgZmxhZ3MsDQo+ID4gd291bGRuJ3QgaXQg YmUgYWxtb3N0IGFzIGluZXZpdGFibGUgdGhhdCBhbiBleHRlbnNpb24gd2lsbCBiZSBhZGRlZA0K PiA+IHRoYXQgc2hvdWxkbid0IGJlIGlnbm9yZWQgYnV0IGlzIG1hcmtlZCBub24tY3JpdGljYWwg dG8gbm90IGJyZWFrDQo+ID4gaW50ZXJvcD8gT3IgZG8geW91IHRoaW5rIHBlb3BsZSB3aWxsICJk byB0aGUgcmlnaHQgdGhpbmcgKG5vdCB0aGUNCj4gPiBlYXN5IHRoaW5nKSIgd2l0aCBjcml0aWNh bGl0eSBmbGFncz8NCg0KPiBBbnlvbmUgd2hvIGJlbGlldmVzIHRoaXMgdG8gYmUgYSB0cnVlIHN0 YXRlbWVudCBpcyBtb3JlIHRoYW4gd2VsY29tZSB0bw0KPiByZWFkIHRoZSBjdXJyZW50IGZpcmVz dG9ybSBhYm91dCBuYW1lIGNvbnN0cmFpbnRzIG9uIHRoZSBQS0lYIG1haWxpbmcNCj4gbGlzdC4g IFRoZXkgd2VyZSBkZWZpbmVkIGFuZCBzYWlkIHRvIGJlIGNyaXRpY2FsIHdoZW4gdGhlIGZpcnN0 IGRyYWZ0DQo+IChSRkMyNDU5KSBjYW1lIG91dCBpbiAxOTk5IGFuZCBwZW9wbGUgYXJlIHNheWlu ZyB0aGF0IHRoZXkgbmVlZCB0byBtYWtlDQo+IGl0IG5vbi1jcml0aWNhbCBiZWNhdXNlIHRvbyBt YW55IHBlb3BsZSBkaWQgbm90IGltcGxlbWVudCBpdC4gIFRoZSBKT1NFDQo+IGRvY3VtZW50cyBh cmUgYmV0dGVyIGluIHRoYXQgdGhlcmUgYXJlIG5vdCBhcyBtYW55ICJleHRlbnNpb25zIg0KPiBk ZWZpbmVkLiAgQnV0IHRoZSBoaXN0b3J5IGlzIHN0aWxsIHRoZXJlLg0KDQoNCkppbSwNCg0KV2hh dCBpcyB5b3UgY29uY2x1c2lvbiBmb3IgSk9TReKAmXMgIk1VU1QgdW5kZXJzdGFuZCBldmVyeXRo aW5nIiBydWxlDQpmcm9tIHRoZSBjcml0aWNhbCBuYW1lIGNvbnN0cmFpbnRzIGZpcmVzdG9ybT8N Cg0KTXkgY29uY2x1c2lvbiBpcyB0aGF0IHRoZSBjcml0aWNhbGl0eSBvZiBuYW1lIGNvbnN0cmFp bnRzIGhhcw0KcHJldmVudGVkIGl0cyB3aWRlc2NhbGUgZGVwbG95bWVudCBmb3IgYSBkZWNhZGUg LS0gc28gaW50ZXJuZXQNCnNlY3VyaXR5IGhhcyBzdWZmZXJlZC4gQSAiTVVTVCB1bmRlcnN0YW5k IGV2ZXJ5dGhpbmciIHJ1bGUgaW4NCkpPU0Ugd2lsbCBzaW1pbGFybHkgZnJlZXplIGl0cyBmdW5j dGlvbmFsaXR5LCBwcmV2ZW50aW5nDQpzZWN1cml0eSBpbXByb3ZlbWVudHMuDQoNCi0tDQpKYW1l cyBNYW5nZXINCg== From Axel.Nennker@telekom.de Fri Jul 27 01:29:46 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F91C21F8493 for ; Fri, 27 Jul 2012 01:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3YD+K-gG3fb for ; Fri, 27 Jul 2012 01:29:42 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3644821F84A2 for ; Fri, 27 Jul 2012 01:29:40 -0700 (PDT) Received: from he111527.emea1.cds.t-internal.com ([10.125.90.86]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 27 Jul 2012 10:29:37 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.25]) by HE111527.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a56::7cd:5a56]) with mapi; Fri, 27 Jul 2012 10:29:37 +0200 From: To: , , Date: Fri, 27 Jul 2012 10:29:34 +0200 Thread-Topic: [jose] MUST understand ALL header fields Thread-Index: Ac1q18qgDo+RPNtVSUCtA/itrmlQRAABKC6AAATFAIAAFqRnAAACvnEAAAANS0AAHrzKsA== Message-ID: References: <82F6AE16-F7D7-4733-863B-DE0776D84809@team.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F8073950@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943667450D2@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943667450D2@TK5EX14MBXC285.redmond.corp.microsoft.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF402517D8E7D4AHE111541eme_" MIME-Version: 1.0 Cc: jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 08:29:46 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF402517D8E7D4AHE111541eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Breno's analysis and support to ditch extensibility. Instead t= he JWA must specify which alg/enc/int algorithm needs what mandatory parame= ters. JWTs with a header with unknown parameters must be rejected. If somebody needs to new algorithms or new extra parameters they should wri= te a new draft. With all the interoperability issues that this implies... If later somebody finds that one alg/enc/int from this spec is not secure e= nough then the implementations need to decide whether they can take the ris= k to continue to support it or pull it. My hope is that our current set of = specified algs/encs/ints is broad enough that a secure alternative exists i= f this ever happens. The cost for extensibility is too high and there is a real danger that this= WG gets stuck like the OAUTH-WG for years. Let's specify something that is useful now. Axel From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik= e Jones Sent: Thursday, July 26, 2012 7:39 PM To: Breno de Medeiros; Manger, James H Cc: jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields I agree with this analysis. If there's an explicit way defined to indicate= which additional header parameters may be ignored, that would be OK. Allo= wing ignore-by-default would be a recipe for disaster. -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Bre= no de Medeiros Sent: Thursday, July 26, 2012 10:35 AM To: Manger, James H Cc: jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields Put it another way: If we want the JWT security header to be extensible we = need to define an explicit extension mechanism. It is NOT sufficient to say= MUST ignore non-understood fields in the header. This will make it impossi= ble to write secure implementations of validation libraries in practice. An extension mechanism would define: - How to bundle fields of an extension as a single object. - How to indicate that this object is an extension, and whether the extensi= on is critical (can't be safely ignored) or not. You can't get extensibility cheaply in a security spec. A choice is needed = whether to support extensibility explicitly (at the expense of significant = increase of spec complexity, since a lot will have to be spelled out right = now) or not. Giving up clear security semantics to get cheap extensibility = is not an acceptable 3rd option. On Thu, Jul 26, 2012 at 9:16 AM, Breno de Medeiros > wrote: On Wed, Jul 25, 2012 at 10:28 PM, Manger, James H > wrote: Breno, >> How about stapling an OCSP response to a JOSE message? > That's a more compelling use case -- it's security-specific but only adds= to the security validation context. How about the signing time? How about some DNS records with DANE and DNSSEC info giving evidence that t= he public key is associated with a domain? How about a blob of data related to Sovereign Keys, or Perspectives, or Con= vergence, or some other proposal to bolster PKI? How about a domain_parameter_seed so you can verify that the common domain = parameters (eg p & q in DSA) were not chosen to have special properties? How about data to allow you to validate a public key (eg co-factor for EC? = Something complicated for RSA?)? How about a timestamp from a timestamp service? I'm not sure which, where, or when an item like the ones mentioned above wi= ll be needed. I am confident that someone will need some items like these. = When that happens they should have a choice about whether including the ite= m needs to break interop with all existing receivers. A mode field that MUS= T be understood (eg "t":"sig") coupled with MUST ignored any unrecognized p= arameters keeps our future choices open. That's not good enough for a security spec. If fields are added and not all= MUST be understood, then we need explicit syntax about what fields are to = be ignored when not understood. E.g., in X509 certificates, extensions (whi= le optional) have the ability to declare themselves critical, so that imple= mentations that don't understand that extension MUST reject the certificate= as invalid. > However declaring that any header you don't understand could be optional = is a far worse balance on the extensibility versus simplicity spectrum (whe= re simplicity here is a stand-in for security, interoperability, etc.) I'm not sure I understand this "simplicity" argument. Ignoring unrecognized= fields is the simplest implementation choice. Is your idea that if you tig= htly constrain extensibility (by making them MUST understand) then messages= will not accumulate as many "enhancements" of dubious value. That is, over= time a MUST ignore rule allows messages to get more complex (and hence les= s secure/interoperable). Do you want "MUST understand" to strongly discoura= ge people misusing the header to carry content metadata, for instance? Inevitably, a field will be added that shouldn't be ignored because it modi= fies the meaning of some other widely understood header entry, followed by = usual antics and general perplexity. -- James Manger From: Breno de Medeiros [mailto:breno@google.com] Sent: Thursday, 26 July 2012 1:12 PM To: Manger, James H Cc: jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields That's a more compelling use case -- it's security-specific but only adds t= o the security validation context. There may be a case to define optional entries in the JWT header. However d= eclaring that any header you don't understand could be optional is a far wo= rse balance on the extensibility versus simplicity spectrum (where simplici= ty here is a stand-in for security, interoperability, etc.) So I am not con= vinced that losing the ability to declare OCSP bindings in JWTs justifies d= ropping the MUST language. If there is rough consensus that defining option= al security fields in the header is prudent from the viewpoint of future sp= ec extensibility then we should devise some simple way to declare a JWT hea= der field optional and exempt _only_those_ from the MUST fail when not unde= rstanding clause. Changing the default behavior even to SHOULD appears to m= e to sacrifice too much on the altar of extensibility. On Wed, Jul 25, 2012 at 7:38 PM, Manger, James H > wrote: How about stapling an OCSP response to a JOSE message? Why should that be "MUST understand"? -- James Manger -- --Breno -- --Breno -- --Breno --_000_CE8995AB5D178F44A2154F5C9A97CAF402517D8E7D4AHE111541eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree w= ith Breno’s analysis and support to ditch extensibility. Instead the = JWA must specify which alg/enc/int algorithm needs what mandatory parameter= s.

JWTs with a header wit= h unknown parameters must be rejected.

 

If s= omebody needs to new algorithms or new extra parameters they should write a= new draft. With all the interoperability issues that this implies…

If later somebody finds tha= t one alg/enc/int from this spec is not secure enough then the implementati= ons need to decide whether they can take the risk to continue to support it= or pull it. My hope is that our current set of specified algs/encs/ints is= broad enough that a secure alternative exists if this ever happens.

 

The cost for extensibility is too high and there is= a real danger that this WG gets stuck like the OAUTH-WG for years.

 

Let’s specify something that is useful now.

 

=

Axel

=  

 <= /o:p>

 

From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Mike Jones
Sent: Thursday, July= 26, 2012 7:39 PM
To: Breno de Medeiros; Manger, James H
Cc= : jose@ietf.org
Subject: Re: [jose] MUST understand ALL heade= r fields

 <= /o:p>

I agree with this analysis.  If t= here’s an explicit way defined to indicate which additional header pa= rameters may be ignored, that would be OK.  Allowing ignore-by-default= would be a recipe for disaster.

=  

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

 

<= b>From:<= /span> jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Breno de Medeiros
Sent: Thursday, July 26, 2012 10:35 AM
T= o: Manger, James H
Cc: jose@ietf.org
Subject: Re: [= jose] MUST understand ALL header fields

 

Put it another way: If we = want the JWT security header to be extensible we need to define an explicit= extension mechanism. It is NOT sufficient to say MUST ignore non-understoo= d fields in the header. This will make it impossible to write secure implem= entations of validation libraries in practice.

 

An extens= ion mechanism would define:

<= o:p> 

- How to bundle fields = of an extension as a single object.

- How to indicate that this object is an extension, and whether the = extension is critical (can't be safely ignored) or not.

 

You can't get extensibility cheaply in a security spec. A choice is ne= eded whether to support extensibility explicitly (at the expense of signifi= cant increase of spec complexity, since a lot will have to be spelled out r= ight now) or not. Giving up clear security semantics to get cheap extensibi= lity is not an acceptable 3rd option.

 

 

On Thu, Ju= l 26, 2012 at 9:16 AM, Breno de Medeiros <breno@google.com> wrote:

 

 

On W= ed, Jul 25, 2012 at 10:28 PM, Manger, James H <James.H.Manger@team.telstra.com= > wrote:

Breno,

 

>> How about stapling an OCSP response to a JOSE message?

> That's a more compelling use case -- it's security-specific but on= ly adds to the security validation context.<= /o:p>

 =

 

How about the signin= g time?

 

How about some DNS records with DANE and DNSSEC info giving ev= idence that the public key is associated with a domain?

 

How about a bl= ob of data related to Sovereign Keys, or Perspectives, or Convergence, or s= ome other proposal to bolster PKI?

 

How about a domain_parameter_seed s= o you can verify that the common domain parameters (eg p & q in DSA) we= re not chosen to have special properties?

 

How about data to allow you = to validate a public key (eg co-factor for EC? Something complicated for RS= A?)?

 

How about a timestamp from a timestamp service?

 

 

I= 217;m not sure which, where, or when an item like the ones mentioned above = will be needed. I am confident that someone will need some items like these= . When that happens they should have a choice about whether including the i= tem needs to break interop with all existing receivers. A mode field that M= UST be understood (eg “t”:”sig”) coupled with MUST = ignored any unrecognized parameters keeps our future choices open.

 

That's not goo= d enough for a security spec. If fields are added and not all MUST be under= stood, then we need explicit syntax about what fields are to be ignored whe= n not understood. E.g., in X509 certificates, extensions (while optional) h= ave the ability to declare themselves critical, so that implementations tha= t don't understand that extension MUST reject the certificate as invalid.

 

 

 

> H= owever declaring that any header you don't understand could be optional is = a far worse balance on the extensibility versus simplicity spectrum (where = simplicity here is a stand-in for security, interoperability, etc.)

 

I’m not sure I u= nderstand this “simplicity” argument. Ignoring unrecognized fie= lds is the simplest implementation choice. Is your idea that if you tightly= constrain extensibility (by making them MUST understand) then messages wil= l not accumulate as many “enhancements” of dubious value. That = is, over time a MUST ignore rule allows messages to get more complex (and h= ence less secure/interoperable). Do you want “MUST understand” = to strongly discourage people misusing the header to carry content metadata= , for instance?

=

 

Inevitably, a field will be added that shouldn't be = ignored because it modifies the meaning of some other widely understood hea= der entry, followed by usual antics and general perplexity.

<= /div>

 

 

 

--

James Manger

 

<= b>From:<= /span> Breno de Medeiros [mailto:breno@google.com]
Sent: Thursday, 26 July 2012 1:12 = PM
To: Manger, James H
Cc: jose@ietf.org


Subject: Re: [jose] MUST understand ALL header fields

=

 

<= span lang=3DEN-AU>That's a more compelling use case -- it's security-specif= ic but only adds to the security validation context.

<= div>

 

<= div>

There may be a case to define optional entrie= s in the JWT header. However declaring that any header you don't understand= could be optional is a far worse balance on the extensibility versus simpl= icity spectrum (where simplicity here is a stand-in for security, interoper= ability, etc.) So I am not convinced that losing the ability to declare OCS= P bindings in JWTs justifies dropping the MUST language. If there is rough = consensus that defining optional security fields in the header is prudent f= rom the viewpoint of future spec extensibility then we should devise some s= imple way to declare a JWT header field optional and exempt _only_those_ fr= om the MUST fail when not understanding clause. Changing the default behavi= or even to SHOULD appears to me to sacrifice too much on the altar of exten= sibility. 

 =

On Wed, Jul 25, 2012 a= t 7:38 PM, Manger, James H <James.H.Manger@team.telstra.com> wrote:

How about stapling an OCSP resp= onse to a JOSE message?

Why should that be "MUST understand&quo= t;?

--
James Manger



 

-- --Breno



 

--
--Breno



 

--
--Bren= o

= --_000_CE8995AB5D178F44A2154F5C9A97CAF402517D8E7D4AHE111541eme_-- From Michael.Jones@microsoft.com Fri Jul 27 09:19:55 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A0721F87BA for ; Fri, 27 Jul 2012 09:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.784 X-Spam-Level: X-Spam-Status: No, score=-3.784 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RDdLQ1awH0Z for ; Fri, 27 Jul 2012 09:19:54 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDE521F87A5 for ; Fri, 27 Jul 2012 09:19:54 -0700 (PDT) Received: from mail140-va3-R.bigfish.com (10.7.14.236) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.23; Fri, 27 Jul 2012 16:19:53 +0000 Received: from mail140-va3 (localhost [127.0.0.1]) by mail140-va3-R.bigfish.com (Postfix) with ESMTP id 176F11403AD; Fri, 27 Jul 2012 16:19:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VS-26(zz9371I542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail140-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail140-va3 (localhost.localdomain [127.0.0.1]) by mail140-va3 (MessageSwitch) id 1343405990951216_5894; Fri, 27 Jul 2012 16:19:50 +0000 (UTC) Received: from VA3EHSMHS007.bigfish.com (unknown [10.7.14.250]) by mail140-va3.bigfish.com (Postfix) with ESMTP id E03E440079; Fri, 27 Jul 2012 16:19:50 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS007.bigfish.com (10.7.99.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 27 Jul 2012 16:19:50 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0298.005; Fri, 27 Jul 2012 16:19:42 +0000 From: Mike Jones To: "Manger, James H" , "jose@ietf.org" Thread-Topic: [jose] MUST understand ALL header fields: "!" field Thread-Index: AQHNa8hSr0OT5DKQmEKxueJwdLnoaZc9Sn7w Date: Fri, 27 Jul 2012 16:19:41 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943667463B4@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <82F6AE16-F7D7-4733-863B-DE0776D84809@team.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F8073950@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F80F4DD0@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F80F539E@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F80F539E@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] MUST understand ALL header fields: "!" field X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 16:19:55 -0000 The problem I have with this proposal is that it imposes a burden in the no= rmal case, where no extensions are used. Should the working group decide t= o allow ANY not-understood fields (and only if), I would make this counter-= proposal: Define an "ext" (extras) header field, the value of which is an array of th= e extra fields in the header that may be ignored. It would be illegal to i= nclude any of the specification-defined fields in this array. So for examp= le, a header could then legally contain: {"alg":"ES256", "ext":["notes"], "notes":"This signature need not be checked when the moon is full" } This counter-proposal would impose a space burden on implementations only w= hen extra that need not be understood are actually used. Again, my personal preference would be to have no such mechanism, for exact= ly the reasons that Breno and Axel have stated. But should the working gro= up decide to have one, we could use my counter-proposal above. -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Man= ger, James H Sent: Friday, July 27, 2012 12:20 AM To: jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields: "!" field Proposal: Define a header field named "!". Its value is a string. A sender MUST include a "!" field in every JOSE message. A receiver MUST reject a JOSE message if the value of the "!" field is not = recognized. The value of the "!" field defines the meaning of the message, including wh= ich other fields MUST be understood to correctly interpret the message in a= fail-safe manner. Any other fields that the receiver does not recognize MU= ST be ignored. It is RECOMMENDED that receivers log the name of an unrecognized field the = first time they see it as it is likely to provide a hint as to how the rece= iver could be improved (including being made more secure). By making the "!" field define the meaning of the message, the obvious & ea= sy implementation choice for a receiver is to switch to appropriate handlin= g code based on the "!" value. Implementing the "MUST understand" rule for = the "!" value occurs naturally as part of such switching. Consequently, sen= ders can be confident that this "MUST understand" rule will be enforced by = legitimate receivers. [In contrast, an alternative rule to reject messages with any unrecognized = fields requires receivers to write extra code to filter out all known field= s and see what remains. That extra code offers no extra functionality to th= e receiver; it is not needed for the receiver to process a message. Consequ= ently, senders can have little confidence that such a "MUST understand" rul= e will be consistently enforced.] On defining a new form of JOSE message, a new value for the "!" field MUST = be chosen if the message could be misinterpreted if it used an existing "!"= value. (Example) initial values for the "!" field: "!":"sig" =3D the JOSE message contains a digital signature over the conten= t using an asymmetric algorithm. The "alg" field MUST be understood. ... "!":"enc" =3D the JOSE message uses a known symmetric key with an AEAD algo= rithm to encrypt the content. The content may first be compressed. The "enc= " and "zip" fields MUST be understood. ... "!":"env" =3D the JOSE message contains contents encrypted with an AEAD alg= orithm using a randomly-chosen per-message key that is conveyed to the rece= iver using an asymmetric key transport algorithm, or an asymmetric key agre= ement algorithm combined with a symmetric key wrapping algorithm. The conte= nt may first be compressed. The "enc", "trp", "agr", "wrp", and "zip" field= s MUST be understood. ... Later "!":"env2" =3D as per "env" but supporting identity-based encryption (IBE) = or a symmetric master key or ephemeral public keys for key exchange. The "i= be"... fields MUST be understood, in addition to the fields listed for "env= ". -- James Manger _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From tonynad@microsoft.com Fri Jul 27 13:49:47 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6B011E808A for ; Fri, 27 Jul 2012 13:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.681 X-Spam-Level: X-Spam-Status: No, score=-0.681 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2jFzfCyVrjd for ; Fri, 27 Jul 2012 13:49:43 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id EAEF311E809B for ; Fri, 27 Jul 2012 13:49:42 -0700 (PDT) Received: from mail49-ch1-R.bigfish.com (10.43.68.226) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.23; Fri, 27 Jul 2012 20:49:42 +0000 Received: from mail49-ch1 (localhost [127.0.0.1]) by mail49-ch1-R.bigfish.com (Postfix) with ESMTP id 1B7722C0492 for ; Fri, 27 Jul 2012 20:49:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VS-20(zz98dI9371Ic85fh1432Izz1202h1082kzz1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah107ah) Received-SPF: pass (mail49-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail49-ch1 (localhost.localdomain [127.0.0.1]) by mail49-ch1 (MessageSwitch) id 1343422180175882_9629; Fri, 27 Jul 2012 20:49:40 +0000 (UTC) Received: from CH1EHSMHS020.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.234]) by mail49-ch1.bigfish.com (Postfix) with ESMTP id 1F5F7E0044 for ; Fri, 27 Jul 2012 20:49:40 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS020.bigfish.com (10.43.70.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 27 Jul 2012 20:49:39 +0000 Received: from db3outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.2.298.5; Fri, 27 Jul 2012 20:49:36 +0000 Received: from mail89-db3-R.bigfish.com (10.3.81.231) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.23; Fri, 27 Jul 2012 20:49:25 +0000 Received: from mail89-db3 (localhost [127.0.0.1]) by mail89-db3-R.bigfish.com (Postfix) with ESMTP id E867E1201AA for ; Fri, 27 Jul 2012 20:49:24 +0000 (UTC) Received: from mail89-db3 (localhost.localdomain [127.0.0.1]) by mail89-db3 (MessageSwitch) id 134342216248479_15617; Fri, 27 Jul 2012 20:49:22 +0000 (UTC) Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.240]) by mail89-db3.bigfish.com (Postfix) with ESMTP id 093B8E00C4; Fri, 27 Jul 2012 20:49:22 +0000 (UTC) Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 27 Jul 2012 20:49:21 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.12.232]) by BL2PRD0310HT004.namprd03.prod.outlook.com ([10.255.97.39]) with mapi id 14.16.0175.005; Fri, 27 Jul 2012 20:49:18 +0000 From: Anthony Nadalin To: "Axel.Nennker@telekom.de" , Mike Jones , "breno@google.com" , "James.H.Manger@team.telstra.com" Thread-Topic: [jose] MUST understand ALL header fields Thread-Index: Ac1q18qgDo+RPNtVSUCtA/itrmlQRAABKC6AAATFAIAAFqRnAAACvnEAAAANS0AAHrzKsAAaOkrg Date: Fri, 27 Jul 2012 20:49:17 +0000 Message-ID: References: <82F6AE16-F7D7-4733-863B-DE0776D84809@team.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F8073950@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943667450D2@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.57] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E75551F4B7BL2PRD0310MB362_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT004.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GOOGLE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TELEKOM.DE$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TEAM.TELSTRA.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC104.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 20:49:47 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E75551F4B7BL2PRD0310MB362_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So not sure this is at all possible for all the permutations that there mig= ht be for all the parameters that one could specify for ECC From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Axe= l.Nennker@telekom.de Sent: Friday, July 27, 2012 1:30 AM To: Mike Jones; breno@google.com; James.H.Manger@team.telstra.com Cc: jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields I agree with Breno's analysis and support to ditch extensibility. Instead t= he JWA must specify which alg/enc/int algorithm needs what mandatory parame= ters. JWTs with a header with unknown parameters must be rejected. If somebody needs to new algorithms or new extra parameters they should wri= te a new draft. With all the interoperability issues that this implies... If later somebody finds that one alg/enc/int from this spec is not secure e= nough then the implementations need to decide whether they can take the ris= k to continue to support it or pull it. My hope is that our current set of = specified algs/encs/ints is broad enough that a secure alternative exists i= f this ever happens. The cost for extensibility is too high and there is a real danger that this= WG gets stuck like the OAUTH-WG for years. Let's specify something that is useful now. Axel From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Mike Jone= s Sent: Thursday, July 26, 2012 7:39 PM To: Breno de Medeiros; Manger, James H Cc: jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields I agree with this analysis. If there's an explicit way defined to indicate= which additional header parameters may be ignored, that would be OK. Allo= wing ignore-by-default would be a recipe for disaster. -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Breno de = Medeiros Sent: Thursday, July 26, 2012 10:35 AM To: Manger, James H Cc: jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields Put it another way: If we want the JWT security header to be extensible we = need to define an explicit extension mechanism. It is NOT sufficient to say= MUST ignore non-understood fields in the header. This will make it impossi= ble to write secure implementations of validation libraries in practice. An extension mechanism would define: - How to bundle fields of an extension as a single object. - How to indicate that this object is an extension, and whether the extensi= on is critical (can't be safely ignored) or not. You can't get extensibility cheaply in a security spec. A choice is needed = whether to support extensibility explicitly (at the expense of significant = increase of spec complexity, since a lot will have to be spelled out right = now) or not. Giving up clear security semantics to get cheap extensibility = is not an acceptable 3rd option. On Thu, Jul 26, 2012 at 9:16 AM, Breno de Medeiros > wrote: On Wed, Jul 25, 2012 at 10:28 PM, Manger, James H > wrote: Breno, >> How about stapling an OCSP response to a JOSE message? > That's a more compelling use case -- it's security-specific but only adds= to the security validation context. How about the signing time? How about some DNS records with DANE and DNSSEC info giving evidence that t= he public key is associated with a domain? How about a blob of data related to Sovereign Keys, or Perspectives, or Con= vergence, or some other proposal to bolster PKI? How about a domain_parameter_seed so you can verify that the common domain = parameters (eg p & q in DSA) were not chosen to have special properties? How about data to allow you to validate a public key (eg co-factor for EC? = Something complicated for RSA?)? How about a timestamp from a timestamp service? I'm not sure which, where, or when an item like the ones mentioned above wi= ll be needed. I am confident that someone will need some items like these. = When that happens they should have a choice about whether including the ite= m needs to break interop with all existing receivers. A mode field that MUS= T be understood (eg "t":"sig") coupled with MUST ignored any unrecognized p= arameters keeps our future choices open. That's not good enough for a security spec. If fields are added and not all= MUST be understood, then we need explicit syntax about what fields are to = be ignored when not understood. E.g., in X509 certificates, extensions (whi= le optional) have the ability to declare themselves critical, so that imple= mentations that don't understand that extension MUST reject the certificate= as invalid. > However declaring that any header you don't understand could be optional = is a far worse balance on the extensibility versus simplicity spectrum (whe= re simplicity here is a stand-in for security, interoperability, etc.) I'm not sure I understand this "simplicity" argument. Ignoring unrecognized= fields is the simplest implementation choice. Is your idea that if you tig= htly constrain extensibility (by making them MUST understand) then messages= will not accumulate as many "enhancements" of dubious value. That is, over= time a MUST ignore rule allows messages to get more complex (and hence les= s secure/interoperable). Do you want "MUST understand" to strongly discoura= ge people misusing the header to carry content metadata, for instance? Inevitably, a field will be added that shouldn't be ignored because it modi= fies the meaning of some other widely understood header entry, followed by = usual antics and general perplexity. -- James Manger From: Breno de Medeiros [mailto:breno@google.com] Sent: Thursday, 26 July 2012 1:12 PM To: Manger, James H Cc: jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields That's a more compelling use case -- it's security-specific but only adds t= o the security validation context. There may be a case to define optional entries in the JWT header. However d= eclaring that any header you don't understand could be optional is a far wo= rse balance on the extensibility versus simplicity spectrum (where simplici= ty here is a stand-in for security, interoperability, etc.) So I am not con= vinced that losing the ability to declare OCSP bindings in JWTs justifies d= ropping the MUST language. If there is rough consensus that defining option= al security fields in the header is prudent from the viewpoint of future sp= ec extensibility then we should devise some simple way to declare a JWT hea= der field optional and exempt _only_those_ from the MUST fail when not unde= rstanding clause. Changing the default behavior even to SHOULD appears to m= e to sacrifice too much on the altar of extensibility. On Wed, Jul 25, 2012 at 7:38 PM, Manger, James H > wrote: How about stapling an OCSP response to a JOSE message? Why should that be "MUST understand"? -- James Manger -- --Breno -- --Breno -- --Breno --_000_B26C1EF377CB694EAB6BDDC8E624B6E75551F4B7BL2PRD0310MB362_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So not sure this is at al= l possible for all the permutations that there might be for all the paramet= ers that one could specify for ECC

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Axel.Nennker@telekom.de
Sent: Friday, July 27, 2012 1:30 AM
To: Mike Jones; breno@google.com; James.H.Manger@team.telstra.com Cc: jose@ietf.org
Subject: Re: [jose] MUST understand ALL header fields

 

I agree with Breno’= s analysis and support to ditch extensibility. Instead the JWA must specify= which alg/enc/int algorithm needs what mandatory parameters.

JWTs with a header with u= nknown parameters must be rejected.

 <= /p>

If somebody needs to new = algorithms or new extra parameters they should write a new draft. With all = the interoperability issues that this implies…

If later somebody finds t= hat one alg/enc/int from this spec is not secure enough then the implementa= tions need to decide whether they can take the risk to continue to support it or pull it. My hope is that our current set of specified alg= s/encs/ints is broad enough that a secure alternative exists if this ever h= appens.

 <= /p>

The cost for extensibilit= y is too high and there is a real danger that this WG gets stuck like the O= AUTH-WG for years.

 <= /p>

Let’s specify somet= hing that is useful now.

 <= /p>

Axel

 <= /p>

 <= /p>

 <= /p>

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Thursday, July 26, 2012 7:39 PM
To: Breno de Medeiros; Manger, James H
Cc: jose@ietf.org
Subject: Re: [jose] MUST understand ALL header fields

 

I agree with this analysi= s.  If there’s an explicit way defined to indicate which additio= nal header parameters may be ignored, that would be OK.  Allowing igno= re-by-default would be a recipe for disaster.

 <= /p>

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

 <= /p>

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Breno de Medeiros Sent: Thursday, July 26, 2012 10:35 AM
To: Manger, James H
Cc: jose@ietf.org
Subject: Re: [jose] MUST understand ALL header fields

 

Put it another way: If we want the JWT security head= er to be extensible we need to define an explicit extension mechanism. It i= s NOT sufficient to say MUST ignore non-understood fields in the header. Th= is will make it impossible to write secure implementations of validation libraries in practice.

 

An extension mechanism would define:

 

- How to bundle fields of an extension as a single o= bject.

- How to indicate that this object is an extension, = and whether the extension is critical (can't be safely ignored) or not.

 

You can't get extensibility cheaply in a security sp= ec. A choice is needed whether to support extensibility explicitly (at the = expense of significant increase of spec complexity, since a lot will have t= o be spelled out right now) or not. Giving up clear security semantics to get cheap extensibility is not an ac= ceptable 3rd option.

 

 

On Thu, Jul 26, 2012 at 9:16 AM, Breno de Medeiros &= lt;breno@google.com> wrote:

 

 

On Wed, Jul 25, 2012 at 10:28 PM, Manger, James H &l= t;Jame= s.H.Manger@team.telstra.com> wrote:

Breno,

 

>> How about stapl= ing an OCSP response to a JOSE message?

> That's a more compe= lling use case -- it's security-specific but only adds to the security validation context.

 

 

How about the signing ti= me?

 

How about some DNS recor= ds with DANE and DNSSEC info giving evidence that the public key is associated with a domain?

 

How about a blob of data= related to Sovereign Keys, or Perspectives, or Convergence, or some other proposal to bolster PKI?

 

How about a domain_param= eter_seed so you can verify that the common domain parameters (eg p & q in DSA) were not chosen to have special properties?

 

How about data to allow = you to validate a public key (eg co-factor for EC? Something complicated for RSA?)?

 

How about a timestamp fr= om a timestamp service?

 

 

I’m not sure which= , where, or when an item like the ones mentioned above will be needed. I am confident that someone will need some items like these. When that hap= pens they should have a choice about whether including the item needs to br= eak interop with all existing receivers. A mode field that MUST be understo= od (eg “t”:”sig”) coupled with MUST ignored any unrecognized parameters keeps our future choices open.<= span lang=3D"EN-AU">

 

That's not good enough for a security spec. If field= s are added and not all MUST be understood, then we need explicit syntax ab= out what fields are to be ignored when not understood. E.g., in X509 certif= icates, extensions (while optional) have the ability to declare themselves critical, so that implementations t= hat don't understand that extension MUST reject the certificate as invalid.=

 

 

 

> However declaring that any header you do= n't understand could be optional is a far worse balance on the extensibilit= y versus simplicity spectrum (where simplicity here is a stand-in for security, interoperability, etc.)=

 

I’m not sure I und= erstand this “simplicity” argument. Ignoring unrecognized field= s is the simplest implementation choice. Is your idea that if you tightly const= rain extensibility (by making them MUST understand) then messages will not = accumulate as many “enhancements” of dubious value. That is, ov= er time a MUST ignore rule allows messages to get more complex (and hence less secure/interoperable). Do you want “= ;MUST understand” to strongly discourage people misusing the header t= o carry content metadata, for instance?

 

Inevitably, a field will be added that shouldn't be = ignored because it modifies the meaning of some other widely understood hea= der entry, followed by usual antics and general perplexity.

 

 

 

--

James Manger

 

From: Breno de Medeiros [mai= lto:breno@google.com<= /a>]
Sent: Thursday, 26 July 2012 1:12 PM
To: Manger, James H
Cc: jose@ietf.org=


Subject: Re: [jose] MUST understand ALL header fields

 

That's a more compelling use case -- it's sec= urity-specific but only adds to the security validation context.=

 

There may be a case to define optional entrie= s in the JWT header. However declaring that any header you don't understand= could be optional is a far worse balance on the extensibility versus simplicity spectrum (where simplicity here is = a stand-in for security, interoperability, etc.) So I am not convinced that= losing the ability to declare OCSP bindings in JWTs justifies dropping the= MUST language. If there is rough consensus that defining optional security fields in the header is prudent = from the viewpoint of future spec extensibility then we should devise some = simple way to declare a JWT header field optional and exempt _only_those_ f= rom the MUST fail when not understanding clause. Changing the default behavior even to SHOULD appears to me to sacr= ifice too much on the altar of extensibility. 

 

On Wed, Jul 25, 2012 at 7:38 PM, Manger, Jame= s H <James.H.Manger@team.telstra.com> wrote:

How about stapling an OCSP response to a JOSE= message?

Why should that be "MUST understand"?

--
James Manger



 

--
--Breno



 

--
--Breno



 

--
--Breno

--_000_B26C1EF377CB694EAB6BDDC8E624B6E75551F4B7BL2PRD0310MB362_-- From breno@google.com Fri Jul 27 13:55:37 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14B111E809B for ; Fri, 27 Jul 2012 13:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.642 X-Spam-Level: X-Spam-Status: No, score=-102.642 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDBV0kulKuAG for ; Fri, 27 Jul 2012 13:55:35 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4755411E808A for ; Fri, 27 Jul 2012 13:55:35 -0700 (PDT) Received: by yhq56 with SMTP id 56so3968676yhq.31 for ; Fri, 27 Jul 2012 13:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=L+P7QdbR8fblqmAuyynB8w/MA9EVUHlwQHcQf5f0L/4=; b=GJhZ9hSPJm73Xf/9J2JBDuyM/QMtE3/dthpMkVo8n+xDvLxGAX/mPjJz6pT3M9LrBl 0l3o64h1JWJwtWa+QZ/xURetifGATdWsJo0tEMQ7nDsiCxfjiFq+TmkeQG1nU/8+PFBw 4mGuOYkJWh20BtJAkOODRVt3eQXL1XhumG7wlaeE6/z2XJ1hDdBU3K1xY6hiMTBMiUaU 7UzypIM38ZH4hZEbLALl8xsNRo4v838ihOni0MwOal0ju5sj8YDLROCDDjTSKdROeXjD gtQgRs7bDuNBT56eZBkNIIiXLGcqKlS+uvtg7Jghzi8A7BXgcRsvIgzSohN474OyT6S9 /OKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=L+P7QdbR8fblqmAuyynB8w/MA9EVUHlwQHcQf5f0L/4=; b=n2TNFTcQG/32VNnJtblshhEcrMfhJYFrWR9o3Byc6OdzyXRpgdg3B1VVFCmt79DoKz Is/5wbgIFH57zS1W9IVxGYJfQic1QJVJOXYh8vvhUpjDy4JaqAk4SrrA6248KbBhKX0z HwQGoU5CKdgM9bG8HXagIPfYjSNtigB7MNli8DnvBG8pjQYtYHShRX4RAZiV2BCJi1i2 1ke7B1+Zb95vBgCKlFsIZ3IimmG/XwyaME6LGB+hdxLnmraELLTBxquBeDP5IoIJbzdI JC0EGLabActakPkrqq2f3XtoDaehGNQssZzABoknn4X4kJIQMHFYDeK2ZytIUQlnWDv6 cZsA== Received: by 10.50.236.4 with SMTP id uq4mr1970477igc.18.1343422534107; Fri, 27 Jul 2012 13:55:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.236.4 with SMTP id uq4mr1970458igc.18.1343422533854; Fri, 27 Jul 2012 13:55:33 -0700 (PDT) Received: by 10.231.17.194 with HTTP; Fri, 27 Jul 2012 13:55:33 -0700 (PDT) In-Reply-To: <023301cd6bb2$22220ce0$666626a0$@augustcellars.com> References: <82F6AE16-F7D7-4733-863B-DE0776D84809@team.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F8073950@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F80F4DD0@WSMSG3153V.srv.dir.telstra.com> <023301cd6bb2$22220ce0$666626a0$@augustcellars.com> Date: Fri, 27 Jul 2012 13:55:33 -0700 Message-ID: From: Breno de Medeiros To: Jim Schaad Content-Type: multipart/alternative; boundary=14dae9340e0fe9e63204c5d5ee83 X-System-Of-Record: true X-Gm-Message-State: ALoCoQknzbOkez/PemJJdeoKzEl84SNnDMQoEcT+NTn88mhGz7flX6fk/bZ23nybAZiYY/AVeFkaliT/FSzTUPyOrVMfy0A0l8dbbmkGfX1OU4H27mygtqJy+FmsZt9UjJF0yCJZC+//QhE220Yq6VtI9X3PeRc4aDSgNvyPU/ZnZfziCXBD194= Cc: "Manger, James H" , jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 20:55:37 -0000 --14dae9340e0fe9e63204c5d5ee83 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If they were truly non-critical and marked as critical then there was a decision process that arrived at the incorrect conclusion. There are several examples of critical extensions that if ignored will cause the processing of a certificate to lead to wide security problems. An example is name constraints. On Thu, Jul 26, 2012 at 9:41 PM, Jim Schaad wrote: > > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > > Manger, James H > > Sent: Thursday, July 26, 2012 8:45 PM > > To: Breno de Medeiros; jose@ietf.org > > Subject: Re: [jose] MUST understand ALL header fields > > > > Breno, > > > > > Inevitably, a field will be added that shouldn't be ignored because i= t > > modifies the meaning of some other widely understood header entry, > > followed by usual antics and general perplexity. > > > > Is there a good example of where this has occurred? That might help us > > reach a common understanding. > > > > > > > An extension mechanism would define: > > > > > > - How to bundle fields of an extension as a single object. > > > - How to indicate that this object is an extension, and whether the > > extension is critical (can't be safely ignored) or not. > > > > If we support extensibility with per-extension criticality flags, > wouldn't it be > > almost as inevitable that an extension will be added that shouldn't be > > ignored but is marked non-critical to not break interop? Or do you thin= k > > people will "do the right thing (not the easy thing)" with criticality > flags? > > Anyone who believes this to be a true statement is more than welcome to > read the current firestorm about name constraints on the PKIX mailing lis= t. > They were defined and said to be critical when the first draft (RFC2459) > came out in 1999 and people are saying that they need to make it > non-critical because too many people did not implement it. The JOSE > documents are better in that there are not as many "extensions" defined. > But the history is still there. > > Jim > > > > > P.S. If the 7 header parameters that are defined in JWS (draft 04) but > never > > used in its examples were all defined as "extensions", would any be > critical? > > jku? jwk? x5u? x5t? x5c? kid? cty? I doubt it. > > > > > > > It is NOT sufficient to say MUST ignore non-understood fields in the > > header. This will make it impossible to write secure implementations of > > validation libraries in practice. > > > > CMS [RFC5652] and its AEAD mode [RFC5083] both have authAttrs fields th= at > > can hold arbitrary attributes. I see no mention in those specs of a "MU= ST > > understand" rule for attributes in those fields. I haven't heard that > that has > > made it impossible to write secure implementations of validation > libraries. > > > > Is it OK for CMS because there are dedicated fields for the primary > items (eg > > signatureAlgorithm), separate from the authAttrs bucket? I don't think > that > > can be the difference. > > > > Lots of CMS attributes have been defined by different parties. For > instance, > > CMS Advanced Electronic Signatures (CAdES) [RFC5126] defines or mention= s > > dozens (signer-location, content-hints, signing-certificate, > commitment-type, > > =EF=BF=BD). Some MUST be present in a CAdES message, others are OPTIONA= L. From > > a quick glance I didn't see a statement about which MUST be understood. > > > > > > -- > > James Manger > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > --=20 --Breno --14dae9340e0fe9e63204c5d5ee83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If they were truly non-critical and marked as critical then there was a dec= ision process that arrived at the incorrect conclusion. There are several e= xamples of critical extensions that if ignored will cause the processing of= a certificate to lead to wide security problems. An example is name constr= aints.=C2=A0


On Thu, Jul 26, 2012 at 9:41 PM, Jim Sch= aad <ietf@augustcellars.com> wrote:
<personal>

> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> Manger, James H
> Sent: Thursday, July 26, 2012 8:45 PM
> To: Breno de Medeiros; jose@ietf.org<= /a>
> Subject: Re: [jose] MUST understand ALL header fields
>
> Breno,
>
> > Inevitably, a field will be added that shouldn't be ignored b= ecause it
> modifies the meaning of some other widely understood header entry,
> followed by usual antics and general perplexity.
>
> Is there a good example of where this has occurred? That might help us=
> reach a common understanding.
>
>
> > An extension mechanism would define:
> >
> > - How to bundle fields of an extension as a single object.
> > - How to indicate that this object is an extension, and whether t= he
> extension is critical (can't be safely ignored) or not.
>
> If we support extensibility with per-extension criticality flags, woul= dn't it be
> almost as inevitable that an extension will be added that shouldn'= t be
> ignored but is marked non-critical to not break interop? Or do you thi= nk
> people will "do the right thing (not the easy thing)" with c= riticality flags?

Anyone who believes this to be a true statement is more than welcome = to read the current firestorm about name constraints on the PKIX mailing li= st. =C2=A0They were defined and said to be critical when the first draft (R= FC2459) came out in 1999 and people are saying that they need to make it no= n-critical because too many people did not implement it. =C2=A0The JOSE doc= uments are better in that there are not as many "extensions" defi= ned. =C2=A0But the history is still there.

Jim

>
> P.S. If the 7 header parameters that are defined in JWS (draft 04) but= never
> used in its examples were all defined as "extensions", would= any be critical?
> jku? jwk? x5u? x5t? x5c? kid? cty? I doubt it.
>
>
> > It is NOT sufficient to say MUST ignore non-understood fields in = the
> header. This will make it impossible to write secure implementations o= f
> validation libraries in practice.
>
> CMS [RFC5652] and its AEAD mode [RFC5083] both have authAttrs fields t= hat
> can hold arbitrary attributes. I see no mention in those specs of a &q= uot;MUST
> understand" rule for attributes in those fields. I haven't he= ard that that has
> made it impossible to write secure implementations of validation libra= ries.
>
> Is it OK for CMS because there are dedicated fields for the primary it= ems (eg
> signatureAlgorithm), separate from the authAttrs bucket? I don't t= hink that
> can be the difference.
>
> Lots of CMS attributes have been defined by different parties. For ins= tance,
> CMS Advanced Electronic Signatures (CAdES) [RFC5126] defines or mentio= ns
> dozens (signer-location, content-hints, signing-certificate, commitmen= t-type,
> =EF=BF=BD). Some MUST be present in a CAdES message, others are OPTION= AL. From
> a quick glance I didn't see a statement about which MUST be unders= tood.
>
>
> --
> James Manger
> ________________________= _______________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose




--
= --Breno
--14dae9340e0fe9e63204c5d5ee83-- From Michael.Jones@microsoft.com Fri Jul 27 13:57:46 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3698011E809B for ; Fri, 27 Jul 2012 13:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.781 X-Spam-Level: X-Spam-Status: No, score=-3.781 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUvBIBsnfYrY for ; Fri, 27 Jul 2012 13:57:39 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 74AF911E808A for ; Fri, 27 Jul 2012 13:57:39 -0700 (PDT) Received: from mail123-va3-R.bigfish.com (10.7.14.238) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.23; Fri, 27 Jul 2012 20:57:38 +0000 Received: from mail123-va3 (localhost [127.0.0.1]) by mail123-va3-R.bigfish.com (Postfix) with ESMTP id 7C234360479; Fri, 27 Jul 2012 20:57:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VS-23(zz98dI9371Ic85fh1432Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail123-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail123-va3 (localhost.localdomain [127.0.0.1]) by mail123-va3 (MessageSwitch) id 1343422656363933_18096; Fri, 27 Jul 2012 20:57:36 +0000 (UTC) Received: from VA3EHSMHS020.bigfish.com (unknown [10.7.14.248]) by mail123-va3.bigfish.com (Postfix) with ESMTP id 552671A00E6; Fri, 27 Jul 2012 20:57:36 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS020.bigfish.com (10.7.99.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 27 Jul 2012 20:57:34 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0298.005; Fri, 27 Jul 2012 20:57:32 +0000 From: Mike Jones To: Anthony Nadalin , "Axel.Nennker@telekom.de" , "breno@google.com" , "James.H.Manger@team.telstra.com" Thread-Topic: [jose] MUST understand ALL header fields Thread-Index: Ac1q18qgDo+RPNtVSUCtA/itrmlQRAABKC6AAATFAIAAFqRnAAACvnEAAAANS0AAHrzKsAAaOkrgAAApcjA= Date: Fri, 27 Jul 2012 20:57:31 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366746D1A@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <82F6AE16-F7D7-4733-863B-DE0776D84809@team.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F8073950@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943667450D2@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366746D1ATK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 20:57:46 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366746D1ATK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I just spoke with Tony, and a clarifying point is worth making. He's sayin= g that there will have to be additional header parameters at some point for= some use cases. He's using additional ECC modes as an example that might = require them. He's not saying that those header parameters, if present, do= not have to be understood. Put another way, he's saying that extensions are inevitable and having no e= xtensibility model is not an option. Fortunately, we already have the JSON= Web Signature and Encryption Header Parameters Registry http://tools.ietf.= org/html/draft-ietf-jose-json-web-signature-04#section-7.1.1 that provides = just such an extensibility point. -- Mike From: Anthony Nadalin Sent: Friday, July 27, 2012 1:49 PM To: Axel.Nennker@telekom.de; Mike Jones; breno@google.com; James.H.Manger@t= eam.telstra.com Cc: jose@ietf.org Subject: RE: [jose] MUST understand ALL header fields So not sure this is at all possible for all the permutations that there mig= ht be for all the parameters that one could specify for ECC From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Axel.Nenn= ker@telekom.de Sent: Friday, July 27, 2012 1:30 AM To: Mike Jones; breno@google.com; James.H.Manger@t= eam.telstra.com Cc: jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields I agree with Breno's analysis and support to ditch extensibility. Instead t= he JWA must specify which alg/enc/int algorithm needs what mandatory parame= ters. JWTs with a header with unknown parameters must be rejected. If somebody needs to new algorithms or new extra parameters they should wri= te a new draft. With all the interoperability issues that this implies... If later somebody finds that one alg/enc/int from this spec is not secure e= nough then the implementations need to decide whether they can take the ris= k to continue to support it or pull it. My hope is that our current set of = specified algs/encs/ints is broad enough that a secure alternative exists i= f this ever happens. The cost for extensibility is too high and there is a real danger that this= WG gets stuck like the OAUTH-WG for years. Let's specify something that is useful now. Axel From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Mike Jone= s Sent: Thursday, July 26, 2012 7:39 PM To: Breno de Medeiros; Manger, James H Cc: jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields I agree with this analysis. If there's an explicit way defined to indicate= which additional header parameters may be ignored, that would be OK. Allo= wing ignore-by-default would be a recipe for disaster. -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Breno de = Medeiros Sent: Thursday, July 26, 2012 10:35 AM To: Manger, James H Cc: jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields Put it another way: If we want the JWT security header to be extensible we = need to define an explicit extension mechanism. It is NOT sufficient to say= MUST ignore non-understood fields in the header. This will make it impossi= ble to write secure implementations of validation libraries in practice. An extension mechanism would define: - How to bundle fields of an extension as a single object. - How to indicate that this object is an extension, and whether the extensi= on is critical (can't be safely ignored) or not. You can't get extensibility cheaply in a security spec. A choice is needed = whether to support extensibility explicitly (at the expense of significant = increase of spec complexity, since a lot will have to be spelled out right = now) or not. Giving up clear security semantics to get cheap extensibility = is not an acceptable 3rd option. On Thu, Jul 26, 2012 at 9:16 AM, Breno de Medeiros > wrote: On Wed, Jul 25, 2012 at 10:28 PM, Manger, James H > wrote: Breno, >> How about stapling an OCSP response to a JOSE message? > That's a more compelling use case -- it's security-specific but only adds= to the security validation context. How about the signing time? How about some DNS records with DANE and DNSSEC info giving evidence that t= he public key is associated with a domain? How about a blob of data related to Sovereign Keys, or Perspectives, or Con= vergence, or some other proposal to bolster PKI? How about a domain_parameter_seed so you can verify that the common domain = parameters (eg p & q in DSA) were not chosen to have special properties? How about data to allow you to validate a public key (eg co-factor for EC? = Something complicated for RSA?)? How about a timestamp from a timestamp service? I'm not sure which, where, or when an item like the ones mentioned above wi= ll be needed. I am confident that someone will need some items like these. = When that happens they should have a choice about whether including the ite= m needs to break interop with all existing receivers. A mode field that MUS= T be understood (eg "t":"sig") coupled with MUST ignored any unrecognized p= arameters keeps our future choices open. That's not good enough for a security spec. If fields are added and not all= MUST be understood, then we need explicit syntax about what fields are to = be ignored when not understood. E.g., in X509 certificates, extensions (whi= le optional) have the ability to declare themselves critical, so that imple= mentations that don't understand that extension MUST reject the certificate= as invalid. > However declaring that any header you don't understand could be optional = is a far worse balance on the extensibility versus simplicity spectrum (whe= re simplicity here is a stand-in for security, interoperability, etc.) I'm not sure I understand this "simplicity" argument. Ignoring unrecognized= fields is the simplest implementation choice. Is your idea that if you tig= htly constrain extensibility (by making them MUST understand) then messages= will not accumulate as many "enhancements" of dubious value. That is, over= time a MUST ignore rule allows messages to get more complex (and hence les= s secure/interoperable). Do you want "MUST understand" to strongly discoura= ge people misusing the header to carry content metadata, for instance? Inevitably, a field will be added that shouldn't be ignored because it modi= fies the meaning of some other widely understood header entry, followed by = usual antics and general perplexity. -- James Manger From: Breno de Medeiros [mailto:breno@google.com] Sent: Thursday, 26 July 2012 1:12 PM To: Manger, James H Cc: jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields That's a more compelling use case -- it's security-specific but only adds t= o the security validation context. There may be a case to define optional entries in the JWT header. However d= eclaring that any header you don't understand could be optional is a far wo= rse balance on the extensibility versus simplicity spectrum (where simplici= ty here is a stand-in for security, interoperability, etc.) So I am not con= vinced that losing the ability to declare OCSP bindings in JWTs justifies d= ropping the MUST language. If there is rough consensus that defining option= al security fields in the header is prudent from the viewpoint of future sp= ec extensibility then we should devise some simple way to declare a JWT hea= der field optional and exempt _only_those_ from the MUST fail when not unde= rstanding clause. Changing the default behavior even to SHOULD appears to m= e to sacrifice too much on the altar of extensibility. On Wed, Jul 25, 2012 at 7:38 PM, Manger, James H > wrote: How about stapling an OCSP response to a JOSE message? Why should that be "MUST understand"? -- James Manger -- --Breno -- --Breno -- --Breno --_000_4E1F6AAD24975D4BA5B168042967394366746D1ATK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I just spoke with Tony, a= nd a clarifying point is worth making.  He’s saying that there w= ill have to be additional header parameters at some point for some use cases.  He’s using additional ECC modes as an example that = might require them.  He’s not saying that those header parameter= s, if present, do not have to be understood.

 <= /p>

Put another way, he’= ;s saying that extensions are inevitable and having no extensibility model = is not an option.  Fortunately, we already have the JSON Web Signature and Encryption Header Parameters Registry http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-04#section-7.= 1.1 that provides just such an extensibility point.

 <= /p>

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

 <= /p>

From: Anthony = Nadalin
Sent: Friday, July 27, 2012 1:49 PM
To: Axel.Nennker@telekom.de; Mike Jones; breno@google.com; James.H.M= anger@team.telstra.com
Cc: jose@ietf.org
Subject: RE: [jose] MUST understand ALL header fields

 

So not sure this is at al= l possible for all the permutations that there might be for all the paramet= ers that one could specify for ECC

 <= /p>

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Axel.Nennker@telekom.de
Sent: Friday, July 27, 2012 1:30 AM
To: Mike Jones; breno@google.com= ; James.H.Manger@team.telstra.com
Cc: jose@ietf.org
Subject: Re: [jose] MUST understand ALL header fields

 

I agree with Breno’= s analysis and support to ditch extensibility. Instead the JWA must specify= which alg/enc/int algorithm needs what mandatory parameters.

JWTs with a header with u= nknown parameters must be rejected.

 <= /p>

If somebody needs to new = algorithms or new extra parameters they should write a new draft. With all = the interoperability issues that this implies…

If later somebody finds t= hat one alg/enc/int from this spec is not secure enough then the implementa= tions need to decide whether they can take the risk to continue to support it or pull it. My hope is that our current set of specified alg= s/encs/ints is broad enough that a secure alternative exists if this ever h= appens.

 <= /p>

The cost for extensibilit= y is too high and there is a real danger that this WG gets stuck like the O= AUTH-WG for years.

 <= /p>

Let’s specify somet= hing that is useful now.

 <= /p>

Axel

 <= /p>

 <= /p>

 <= /p>

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Thursday, July 26, 2012 7:39 PM
To: Breno de Medeiros; Manger, James H
Cc: jose@ietf.org
Subject: Re: [jose] MUST understand ALL header fields

 

I agree with this analysi= s.  If there’s an explicit way defined to indicate which additio= nal header parameters may be ignored, that would be OK.  Allowing igno= re-by-default would be a recipe for disaster.

 <= /p>

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

 <= /p>

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Breno de Medeiros Sent: Thursday, July 26, 2012 10:35 AM
To: Manger, James H
Cc: jose@ietf.org
Subject: Re: [jose] MUST understand ALL header fields

 

Put it another way: If we want the JWT security head= er to be extensible we need to define an explicit extension mechanism. It i= s NOT sufficient to say MUST ignore non-understood fields in the header. Th= is will make it impossible to write secure implementations of validation libraries in practice.

 

An extension mechanism would define:

 

- How to bundle fields of an extension as a single o= bject.

- How to indicate that this object is an extension, = and whether the extension is critical (can't be safely ignored) or not.

 

You can't get extensibility cheaply in a security sp= ec. A choice is needed whether to support extensibility explicitly (at the = expense of significant increase of spec complexity, since a lot will have t= o be spelled out right now) or not. Giving up clear security semantics to get cheap extensibility is not an ac= ceptable 3rd option.

 

 

On Thu, Jul 26, 2012 at 9:16 AM, Breno de Medeiros &= lt;breno@google.com> wrote:

 

 

On Wed, Jul 25, 2012 at 10:28 PM, Manger, James H &l= t;Jame= s.H.Manger@team.telstra.com> wrote:

Breno,

 

>> How about stapl= ing an OCSP response to a JOSE message?

> That's a more compe= lling use case -- it's security-specific but only adds to the security validation context.

 

 

How about the signing ti= me?

 

How about some DNS recor= ds with DANE and DNSSEC info giving evidence that the public key is associated with a domain?

 

How about a blob of data= related to Sovereign Keys, or Perspectives, or Convergence, or some other proposal to bolster PKI?

 

How about a domain_param= eter_seed so you can verify that the common domain parameters (eg p & q in DSA) were not chosen to have special properties?

 

How about data to allow = you to validate a public key (eg co-factor for EC? Something complicated for RSA?)?

 

How about a timestamp fr= om a timestamp service?

 

 

I’m not sure which= , where, or when an item like the ones mentioned above will be needed. I am confident that someone will need some items like these. When that hap= pens they should have a choice about whether including the item needs to br= eak interop with all existing receivers. A mode field that MUST be understo= od (eg “t”:”sig”) coupled with MUST ignored any unrecognized parameters keeps our future choices open.<= span lang=3D"EN-AU">

 

That's not good enough for a security spec. If field= s are added and not all MUST be understood, then we need explicit syntax ab= out what fields are to be ignored when not understood. E.g., in X509 certif= icates, extensions (while optional) have the ability to declare themselves critical, so that implementations t= hat don't understand that extension MUST reject the certificate as invalid.=

 

 

 

> However declaring that any header you do= n't understand could be optional is a far worse balance on the extensibilit= y versus simplicity spectrum (where simplicity here is a stand-in for security, interoperability, etc.)=

 

I’m not sure I und= erstand this “simplicity” argument. Ignoring unrecognized field= s is the simplest implementation choice. Is your idea that if you tightly const= rain extensibility (by making them MUST understand) then messages will not = accumulate as many “enhancements” of dubious value. That is, ov= er time a MUST ignore rule allows messages to get more complex (and hence less secure/interoperable). Do you want “= ;MUST understand” to strongly discourage people misusing the header t= o carry content metadata, for instance?

 

Inevitably, a field will be added that shouldn't be = ignored because it modifies the meaning of some other widely understood hea= der entry, followed by usual antics and general perplexity.

 

 

 

--

James Manger

 

From: Breno de Medeiros [mai= lto:breno@google.com<= /a>]
Sent: Thursday, 26 July 2012 1:12 PM
To: Manger, James H
Cc: jose@ietf.org=


Subject: Re: [jose] MUST understand ALL header fields

 

That's a more compelling use case -- it's sec= urity-specific but only adds to the security validation context.=

 

There may be a case to define optional entrie= s in the JWT header. However declaring that any header you don't understand= could be optional is a far worse balance on the extensibility versus simplicity spectrum (where simplicity here is = a stand-in for security, interoperability, etc.) So I am not convinced that= losing the ability to declare OCSP bindings in JWTs justifies dropping the= MUST language. If there is rough consensus that defining optional security fields in the header is prudent = from the viewpoint of future spec extensibility then we should devise some = simple way to declare a JWT header field optional and exempt _only_those_ f= rom the MUST fail when not understanding clause. Changing the default behavior even to SHOULD appears to me to sacr= ifice too much on the altar of extensibility. 

 

On Wed, Jul 25, 2012 at 7:38 PM, Manger, Jame= s H <James.H.Manger@team.telstra.com> wrote:

How about stapling an OCSP response to a JOSE= message?

Why should that be "MUST understand"?

--
James Manger



 

--
--Breno



 

--
--Breno



 

--
--Breno

--_000_4E1F6AAD24975D4BA5B168042967394366746D1ATK5EX14MBXC285r_-- From ve7jtb@ve7jtb.com Fri Jul 27 14:02:57 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B005911E809A for ; Fri, 27 Jul 2012 14:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCGlKMoCT2J8 for ; Fri, 27 Jul 2012 14:02:56 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6498211E808A for ; Fri, 27 Jul 2012 14:02:56 -0700 (PDT) Received: by ggnc4 with SMTP id c4so3968519ggn.31 for ; Fri, 27 Jul 2012 14:02:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=U1vaKWwbMWY43WFteJsQZqxB1CuLVDLaTdTqMeIIZn4=; b=ZBcLhHEON1cCH5ga25FQLkQY9PAMbUmjkb98osejq6ZIcK+9JKMV550CVMxsMCY+xL a52xXndL/ZweKiMxX+HJpLqzowQf/RbrFkoY0QMA9m8vQ1uR8wblJ3p7gVuOJ2rMjVGu BvKIjsI9FSqdnVStWxilG8h6VSChFveuZeJA+oYUB1nP2fFutAJ7ptVr1V6shbSmRsEo xWfOiRQ4y19cvMSitfDDmc5qr8QYhmSTMfGahweh+zj3M2ue55f+bjpi68keth6lQnf3 xlOOe+tDarHCOvaGOC5cRBRmVNnTN9rDGuI+JTHyISK+2AOPADGvLol6O2rU8hD/WFyq M0vw== Received: by 10.66.79.195 with SMTP id l3mr8157938pax.33.1343422975179; Fri, 27 Jul 2012 14:02:55 -0700 (PDT) Received: from [172.20.10.4] (out-bc-183.wireless.telus.com. [209.121.225.183]) by mx.google.com with ESMTPS id oo6sm2568001pbc.22.2012.07.27.14.02.53 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Jul 2012 14:02:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: multipart/alternative; boundary="Apple-Mail=_ED38962B-9FEF-49E3-A123-B4BEC977B99B" From: John Bradley In-Reply-To: Date: Fri, 27 Jul 2012 14:02:51 -0700 Message-Id: <2D8BDD5A-BB6A-4B2D-BBB0-07621C0287D2@ve7jtb.com> References: <82F6AE16-F7D7-4733-863B-DE0776D84809@team.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F8073950@WSMSG3153V.srv.dir.telstra.com> To: Breno de Medeiros X-Mailer: Apple Mail (2.1280) X-Gm-Message-State: ALoCoQlATSzYfHk6bgpzsXYN9eMqYYWyo18iK97nIvrD7+/SL0/FeO1wekjWpgqEkfwK7VUy0Gxc Cc: "Manger, James H" , "jose@ietf.org" Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 21:02:57 -0000 --Apple-Mail=_ED38962B-9FEF-49E3-A123-B4BEC977B99B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I agree ignore by default is going to cause too many problems down the = road.=20 I am not against having a way to indicate non critical as long as the = default is critical put in x.509 terminology. John B. On 2012-07-26, at 10:35 AM, Breno de Medeiros wrote: > Put it another way: If we want the JWT security header to be = extensible we need to define an explicit extension mechanism. It is NOT = sufficient to say MUST ignore non-understood fields in the header. This = will make it impossible to write secure implementations of validation = libraries in practice. >=20 > An extension mechanism would define: >=20 > - How to bundle fields of an extension as a single object. > - How to indicate that this object is an extension, and whether the = extension is critical (can't be safely ignored) or not. >=20 > You can't get extensibility cheaply in a security spec. A choice is = needed whether to support extensibility explicitly (at the expense of = significant increase of spec complexity, since a lot will have to be = spelled out right now) or not. Giving up clear security semantics to get = cheap extensibility is not an acceptable 3rd option. >=20 >=20 >=20 > On Thu, Jul 26, 2012 at 9:16 AM, Breno de Medeiros = wrote: >=20 >=20 >=20 > On Wed, Jul 25, 2012 at 10:28 PM, Manger, James H = wrote: > Breno, >=20 > =20 >=20 > >> How about stapling an OCSP response to a JOSE message? >=20 > > That's a more compelling use case -- it's security-specific but only = adds to the security validation context. >=20 > =20 >=20 > =20 >=20 > How about the signing time? >=20 > =20 >=20 > How about some DNS records with DANE and DNSSEC info giving evidence = that the public key is associated with a domain? >=20 > =20 >=20 > How about a blob of data related to Sovereign Keys, or Perspectives, = or Convergence, or some other proposal to bolster PKI? >=20 > =20 >=20 > How about a domain_parameter_seed so you can verify that the common = domain parameters (eg p & q in DSA) were not chosen to have special = properties? >=20 > =20 >=20 > How about data to allow you to validate a public key (eg co-factor for = EC? Something complicated for RSA?)? >=20 > =20 >=20 > How about a timestamp from a timestamp service? >=20 > =20 >=20 > =20 >=20 > I=92m not sure which, where, or when an item like the ones mentioned = above will be needed. I am confident that someone will need some items = like these. When that happens they should have a choice about whether = including the item needs to break interop with all existing receivers. A = mode field that MUST be understood (eg =93t=94:=94sig=94) coupled with = MUST ignored any unrecognized parameters keeps our future choices open. >=20 >=20 > That's not good enough for a security spec. If fields are added and = not all MUST be understood, then we need explicit syntax about what = fields are to be ignored when not understood. E.g., in X509 = certificates, extensions (while optional) have the ability to declare = themselves critical, so that implementations that don't understand that = extension MUST reject the certificate as invalid. > =20 >=20 > =20 >=20 > =20 >=20 > > However declaring that any header you don't understand could be = optional is a far worse balance on the extensibility versus simplicity = spectrum (where simplicity here is a stand-in for security, = interoperability, etc.) >=20 > =20 >=20 > I=92m not sure I understand this =93simplicity=94 argument. Ignoring = unrecognized fields is the simplest implementation choice. Is your idea = that if you tightly constrain extensibility (by making them MUST = understand) then messages will not accumulate as many =93enhancements=94 = of dubious value. That is, over time a MUST ignore rule allows messages = to get more complex (and hence less secure/interoperable). Do you want = =93MUST understand=94 to strongly discourage people misusing the header = to carry content metadata, for instance? >=20 >=20 > Inevitably, a field will be added that shouldn't be ignored because it = modifies the meaning of some other widely understood header entry, = followed by usual antics and general perplexity. > =20 >=20 > =20 >=20 > =20 >=20 > -- >=20 > James Manger >=20 > =20 >=20 > From: Breno de Medeiros [mailto:breno@google.com]=20 > Sent: Thursday, 26 July 2012 1:12 PM > To: Manger, James H > Cc: jose@ietf.org >=20 >=20 > Subject: Re: [jose] MUST understand ALL header fields >=20 > =20 >=20 > That's a more compelling use case -- it's security-specific but only = adds to the security validation context. >=20 > =20 >=20 > There may be a case to define optional entries in the JWT header. = However declaring that any header you don't understand could be optional = is a far worse balance on the extensibility versus simplicity spectrum = (where simplicity here is a stand-in for security, interoperability, = etc.) So I am not convinced that losing the ability to declare OCSP = bindings in JWTs justifies dropping the MUST language. If there is rough = consensus that defining optional security fields in the header is = prudent from the viewpoint of future spec extensibility then we should = devise some simple way to declare a JWT header field optional and exempt = _only_those_ from the MUST fail when not understanding clause. Changing = the default behavior even to SHOULD appears to me to sacrifice too much = on the altar of extensibility.=20 >=20 > =20 >=20 > On Wed, Jul 25, 2012 at 7:38 PM, Manger, James H = wrote: >=20 > How about stapling an OCSP response to a JOSE message? >=20 > Why should that be "MUST understand"? >=20 > -- > James Manger >=20 >=20 >=20 >=20 > =20 >=20 > --=20 > --Breno >=20 >=20 >=20 >=20 > --=20 > --Breno >=20 >=20 >=20 > --=20 > --Breno > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_ED38962B-9FEF-49E3-A123-B4BEC977B99B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = agree ignore by default is going to cause too many problems down the = road. 

I am not against having a way to indicate = non critical as long as the default is critical put in x.509 = terminology.

John B.
On = 2012-07-26, at 10:35 AM, Breno de Medeiros wrote:

Put it = another way: If we want the JWT security header to be extensible we need = to define an explicit extension mechanism. It is NOT sufficient to say = MUST ignore non-understood fields in the header. This will make it = impossible to write secure implementations of validation libraries in = practice.

An extension mechanism would = define:

- How to bundle fields of an extension = as a single object.
- How to indicate that this object is an = extension, and whether the extension is critical (can't be safely = ignored) or not.

You can't get extensibility cheaply in a security = spec. A choice is needed whether to support extensibility explicitly (at = the expense of significant increase of spec complexity, since a lot will = have to be spelled out right now) or not. Giving up clear security = semantics to get cheap extensibility is not an acceptable 3rd = option.



On Thu, Jul 26, 2012 at 9:16 AM, Breno de Medeiros = <breno@google.com> wrote:



On Wed, Jul 25, 2012 at 10:28 PM, Manger, James H <James.H.Manger@team.telstra.com> = wrote:

Breno,

 

>> How about stapling an OCSP response to a = JOSE message?

> That's a more compelling use case -- it's = security-specific but only adds to the security validation = context.

 

 

How about the signing = time?

 

How about some DNS records with DANE and DNSSEC = info giving evidence that the public key is associated with a = domain?

 

How about a blob of data related to Sovereign = Keys, or Perspectives, or Convergence, or some other proposal to bolster = PKI?

 

How about a domain_parameter_seed so you can = verify that the common domain parameters (eg p & q in DSA) were not = chosen to have special properties?

 

How about data to allow you to validate a public = key (eg co-factor for EC? Something complicated for = RSA?)?

 

How about a timestamp from a timestamp = service?

 

 

I=92m not sure which, where, or when an item like = the ones mentioned above will be needed. I am confident that someone = will need some items like these. When that happens they should have a = choice about whether including the item needs to break interop with all = existing receivers. A mode field that MUST be understood (eg =93t=94:=94si= g=94) coupled with MUST ignored any unrecognized parameters keeps our = future choices open.


That's not good = enough for a security spec. If fields are added and not all MUST be = understood, then we need explicit syntax about what fields are to be = ignored when not understood. E.g., in X509 certificates, extensions = (while optional) have the ability to declare themselves critical, so = that implementations that don't understand that extension MUST reject = the certificate as invalid.
 

 

 

> However declaring that any header you don't = understand could be optional is a far worse balance on the extensibility = versus simplicity spectrum (where simplicity here is a stand-in for = security, interoperability, etc.)

 

I=92m not sure I understand this =93simplicity=94 = argument. Ignoring unrecognized fields is the simplest implementation = choice. Is your idea that if you tightly constrain extensibility (by = making them MUST understand) then messages will not accumulate as many = =93enhancements=94 of dubious value. That is, over time a MUST ignore = rule allows messages to get more complex (and hence less = secure/interoperable). Do you want =93MUST understand=94 to strongly = discourage people misusing the header to carry content metadata, for = instance?


Inevitably, a field = will be added that shouldn't be ignored because it modifies the meaning = of some other widely understood header entry, followed by usual antics = and general perplexity.
 

 

 

--

James Manger

 

From: Breno de Medeiros [mailto:breno@google.com]
Sent: Thursday, 26 July 2012 1:12 PM
To: Manger, James = H
Cc: jose@ietf.org


Subject: = Re: [jose] MUST understand ALL header fields

 

That's = a more compelling use case -- it's security-specific but only adds to = the security validation context.

 

There may be a case to define optional entries in = the JWT header. However declaring that any header you don't understand = could be optional is a far worse balance on the extensibility versus = simplicity spectrum (where simplicity here is a stand-in for security, = interoperability, etc.) So I am not convinced that losing the ability to = declare OCSP bindings in JWTs justifies dropping the MUST language. If = there is rough consensus that defining optional security fields in the = header is prudent from the viewpoint of future spec extensibility then = we should devise some simple way to declare a JWT header field optional = and exempt _only_those_ from the MUST fail when not understanding = clause. Changing the default behavior even to SHOULD appears to me to = sacrifice too much on the altar of = extensibility. 

 

On Wed, Jul 25, 2012 at 7:38 PM, Manger, James H = <James.H.Manger@team.telstra.com> = wrote:

How about stapling an = OCSP response to a JOSE message?

Why should that be "MUST = understand"?

--
James Manger



 

-- =
--Breno




--
--Breno



-- =
--Breno
_______________________________________________
jose mailing = list
jose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jose

= --Apple-Mail=_ED38962B-9FEF-49E3-A123-B4BEC977B99B-- From breno@google.com Fri Jul 27 14:03:43 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E348B11E808A for ; Fri, 27 Jul 2012 14:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.666 X-Spam-Level: X-Spam-Status: No, score=-102.666 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fA13joYvkNs7 for ; Fri, 27 Jul 2012 14:03:42 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id BF48211E809A for ; Fri, 27 Jul 2012 14:03:41 -0700 (PDT) Received: by ggnc4 with SMTP id c4so3969130ggn.31 for ; Fri, 27 Jul 2012 14:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=6uo0UR5JirLunN6DS7Q4KWfi/y19TE5XU1l2oH4yuQA=; b=FnEkeZWIpAbSFmzVrfy/UbYiAWs2aiR1KT5hys4Zf8DgRSwUiEorETS2ZWT8vHpBbU zEgET0P2QejzlIhpowCmJ6zyDyxBCJlHPujlJA6x+jm5fgVk7p3QxW4unEsDEe7s37Rd by8kts4fjDYSldz9PV8FR/X+9MjeYVu3L+zTMfs/2IEtNKy1vHJatvmOnikafPLTHz4y y+sQ9nuowcu2TEsJynkvs6wo1jTiV/4EoqzxCmFKKsPYT0TX1vEogzzVTZjCPsjUToiM qKqdGr9M3PtghnzCKypKj9SmQFNcSQPRg4sUbhuTYW/ibtLylGKXI1/udObUPNjK4d6f 7ZhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=6uo0UR5JirLunN6DS7Q4KWfi/y19TE5XU1l2oH4yuQA=; b=NCEpL8DF1uXS4U4+GCtQ4R8nm27c+nUlxAjBZZ8HwyBsKLGsHARCHgnC3vJK/gkgY4 s2kD0x1sjEpJRIwCPwnJpPX+9QK6FNhaRetaGdCnCe3/naw5j2I2F+KpZVBkVHTwUpF5 cIozS78SXOMfS6jGpZdoLeePYAigRPDUeTc6HOa5sziRjVDCPNUCeCkoLx98PYWpvVkx NmijZQgqYIpTTv+YcJrkBf5ZiaJIdPhQkw8BwBfsbQsN4LE87PPeZBa462Lx2sqmdG6b ligds0yVKiyjnHlEoKEr9Drrr1zoVqRktji15Pp4EhB9qYOE23HPklWFhG2+rMH2Og0j SqgA== Received: by 10.50.106.166 with SMTP id gv6mr3199151igb.46.1343423018224; Fri, 27 Jul 2012 14:03:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.106.166 with SMTP id gv6mr3199138igb.46.1343423017968; Fri, 27 Jul 2012 14:03:37 -0700 (PDT) Received: by 10.231.17.194 with HTTP; Fri, 27 Jul 2012 14:03:37 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366746D1A@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <82F6AE16-F7D7-4733-863B-DE0776D84809@team.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F8073950@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943667450D2@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394366746D1A@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Fri, 27 Jul 2012 14:03:37 -0700 Message-ID: From: Breno de Medeiros To: Mike Jones Content-Type: multipart/alternative; boundary=e89a8f23535bc4e37f04c5d60b43 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlIMfPwCMVAuQ6iszWyZoeIDpTFqOe1jUggpvSEK5mquUfTqOT52I+bgdSQz+tv30kSFo9Ia/othDDOyx+UFN/sgnOC4Jb227WGl8zVj8JXPUik7/FnBMNVjYjB7QE5qnL+4SwN7nHs9oC5snsBpp7u1l/tvHglh//VQydJgjELu6ha+5Y= Cc: Anthony Nadalin , "James.H.Manger@team.telstra.com" , "jose@ietf.org" , "Axel.Nennker@telekom.de" Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 21:03:44 -0000 --e89a8f23535bc4e37f04c5d60b43 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Good point. Yes, the current language already allows for extensibility, though not as general as others have advocated here. On Fri, Jul 27, 2012 at 1:57 PM, Mike Jones wr= ote: > I just spoke with Tony, and a clarifying point is worth making. He=92s > saying that there will have to be additional header parameters at some > point for some use cases. He=92s using additional ECC modes as an exampl= e > that might require them. He=92s not saying that those header parameters,= if > present, do not have to be understood.**** > > ** ** > > Put another way, he=92s saying that extensions are inevitable and having = no > extensibility model is not an option. Fortunately, we already have the > JSON Web Signature and Encryption Header Parameters Registry > http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-04#section-= 7.1.1that provides just such an extensibility point. > **** > > ** ** > > -- Mike**= * > * > > ** ** > > *From:* Anthony Nadalin > *Sent:* Friday, July 27, 2012 1:49 PM > *To:* Axel.Nennker@telekom.de; Mike Jones; breno@google.com; > James.H.Manger@team.telstra.com > *Cc:* jose@ietf.org > *Subject:* RE: [jose] MUST understand ALL header fields**** > > ** ** > > So not sure this is at all possible for all the permutations that there > might be for all the parameters that one could specify for ECC**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Axel.Nennker@telekom.de > *Sent:* Friday, July 27, 2012 1:30 AM > *To:* Mike Jones; breno@google.com; James.H.Manger@team.telstra.com > *Cc:* jose@ietf.org > *Subject:* Re: [jose] MUST understand ALL header fields**** > > ** ** > > I agree with Breno=92s analysis and support to ditch extensibility. Inste= ad > the JWA must specify which alg/enc/int algorithm needs what mandatory > parameters. **** > > JWTs with a header with unknown parameters must be rejected.**** > > ** ** > > If somebody needs to new algorithms or new extra parameters they should > write a new draft. With all the interoperability issues that this implies= =85 > **** > > If later somebody finds that one alg/enc/int from this spec is not secure > enough then the implementations need to decide whether they can take the > risk to continue to support it or pull it. My hope is that our current se= t > of specified algs/encs/ints is broad enough that a secure alternative > exists if this ever happens.**** > > ** ** > > The cost for extensibility is too high and there is a real danger that > this WG gets stuck like the OAUTH-WG for years.**** > > ** ** > > Let=92s specify something that is useful now.**** > > ** ** > > Axel**** > > ** ** > > ** ** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Mike Jones > *Sent:* Thursday, July 26, 2012 7:39 PM > *To:* Breno de Medeiros; Manger, James H > *Cc:* jose@ietf.org > *Subject:* Re: [jose] MUST understand ALL header fields**** > > ** ** > > I agree with this analysis. If there=92s an explicit way defined to > indicate which additional header parameters may be ignored, that would be > OK. Allowing ignore-by-default would be a recipe for disaster.**** > > ** ** > > -- Mike**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Breno de Medeiros > *Sent:* Thursday, July 26, 2012 10:35 AM > *To:* Manger, James H > *Cc:* jose@ietf.org > *Subject:* Re: [jose] MUST understand ALL header fields**** > > ** ** > > Put it another way: If we want the JWT security header to be extensible w= e > need to define an explicit extension mechanism. It is NOT sufficient to s= ay > MUST ignore non-understood fields in the header. This will make it > impossible to write secure implementations of validation libraries in > practice.**** > > ** ** > > An extension mechanism would define:**** > > ** ** > > - How to bundle fields of an extension as a single object.**** > > - How to indicate that this object is an extension, and whether the > extension is critical (can't be safely ignored) or not.**** > > ** ** > > You can't get extensibility cheaply in a security spec. A choice is neede= d > whether to support extensibility explicitly (at the expense of significan= t > increase of spec complexity, since a lot will have to be spelled out righ= t > now) or not. Giving up clear security semantics to get cheap extensibilit= y > is not an acceptable 3rd option.**** > > ** ** > > ** ** > > On Thu, Jul 26, 2012 at 9:16 AM, Breno de Medeiros > wrote:**** > > ** ** > > ** ** > > On Wed, Jul 25, 2012 at 10:28 PM, Manger, James H < > James.H.Manger@team.telstra.com> wrote:**** > > Breno,**** > > **** > > >> How about stapling an OCSP response to a JOSE message?**** > > > That's a more compelling use case -- it's security-specific but only > adds to the security validation context.**** > > **** > > **** > > How about the signing time?**** > > **** > > How about some DNS records with DANE and DNSSEC info giving evidence that > the public key is associated with a domain?**** > > **** > > How about a blob of data related to Sovereign Keys, or Perspectives, or > Convergence, or some other proposal to bolster PKI?**** > > **** > > How about a domain_parameter_seed so you can verify that the common domai= n > parameters (eg p & q in DSA) were not chosen to have special properties?*= * > ** > > **** > > How about data to allow you to validate a public key (eg co-factor for EC= ? > Something complicated for RSA?)?**** > > **** > > How about a timestamp from a timestamp service?**** > > **** > > **** > > I=92m not sure which, where, or when an item like the ones mentioned abov= e > will be needed. I am confident that someone will need some items like > these. When that happens they should have a choice about whether includin= g > the item needs to break interop with all existing receivers. A mode field > that MUST be understood (eg =93t=94:=94sig=94) coupled with MUST ignored = any > unrecognized parameters keeps our future choices open.**** > > ** ** > > That's not good enough for a security spec. If fields are added and not > all MUST be understood, then we need explicit syntax about what fields ar= e > to be ignored when not understood. E.g., in X509 certificates, extensions > (while optional) have the ability to declare themselves critical, so that > implementations that don't understand that extension MUST reject the > certificate as invalid.**** > > **** > > **** > > **** > > > However declaring that any header you don't understand could be optiona= l > is a far worse balance on the extensibility versus simplicity spectrum > (where simplicity here is a stand-in for security, interoperability, etc.= ) > **** > > **** > > I=92m not sure I understand this =93simplicity=94 argument. Ignoring > unrecognized fields is the simplest implementation choice. Is your idea > that if you tightly constrain extensibility (by making them MUST > understand) then messages will not accumulate as many =93enhancements=94 = of > dubious value. That is, over time a MUST ignore rule allows messages to g= et > more complex (and hence less secure/interoperable). Do you want =93MUST > understand=94 to strongly discourage people misusing the header to carry > content metadata, for instance?**** > > ** ** > > Inevitably, a field will be added that shouldn't be ignored because it > modifies the meaning of some other widely understood header entry, follow= ed > by usual antics and general perplexity.**** > > **** > > **** > > **** > > --**** > > James Manger**** > > **** > > *From:* Breno de Medeiros [mailto:breno@google.com] > *Sent:* Thursday, 26 July 2012 1:12 PM > *To:* Manger, James H > *Cc:* jose@ietf.org**** > > > *Subject:* Re: [jose] MUST understand ALL header fields**** > > **** > > That's a more compelling use case -- it's security-specific but only adds > to the security validation context.**** > > **** > > There may be a case to define optional entries in the JWT header. However > declaring that any header you don't understand could be optional is a far > worse balance on the extensibility versus simplicity spectrum (where > simplicity here is a stand-in for security, interoperability, etc.) So I = am > not convinced that losing the ability to declare OCSP bindings in JWTs > justifies dropping the MUST language. If there is rough consensus that > defining optional security fields in the header is prudent from the > viewpoint of future spec extensibility then we should devise some simple > way to declare a JWT header field optional and exempt _only_those_ from t= he > MUST fail when not understanding clause. Changing the default behavior ev= en > to SHOULD appears to me to sacrifice too much on the altar of > extensibility. **** > > **** > > On Wed, Jul 25, 2012 at 7:38 PM, Manger, James H < > James.H.Manger@team.telstra.com> wrote:**** > > How about stapling an OCSP response to a JOSE message? > > Why should that be "MUST understand"? > > -- > James Manger**** > > > > **** > > **** > > -- > --Breno**** > > > > **** > > ** ** > > -- > --Breno**** > > > > **** > > ** ** > > -- > --Breno**** > --=20 --Breno --e89a8f23535bc4e37f04c5d60b43 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Good point. Yes, the current language already allows for extensibility, tho= ugh not as general as others have advocated here. --e89a8f23535bc4e37f04c5d60b43-- From ve7jtb@ve7jtb.com Fri Jul 27 14:13:31 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0266721F85AA for ; Fri, 27 Jul 2012 14:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tme1rCaR83kY for ; Fri, 27 Jul 2012 14:13:29 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3AE21F85A8 for ; Fri, 27 Jul 2012 14:13:29 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so5687688pbc.31 for ; Fri, 27 Jul 2012 14:13:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=SWqzNk81kbZHBtOXWitTpj8y52Mr5uuaWaGxNs2EqZ0=; b=VrAAA0DUSjhW43uhEq7m7yk7KTXw1qwcbpBSC24J+zMpjDwlEverfaqwUWRzSDr71h SehkLsiJ+ZifFh62Os0Qe9aJyXvd7bwdAmhAnWk+FVohcVThBvvowesgy030QnBD4kHe gCDDiklSQUwXNUQ3HT0wo1TaqkkM4yJ5KsVaJZm3oOH1IWnrIy0AOX4C4ypI5IevWNTw LEo5kWRy2t3nMlrU3iye7BhOiS1Ah3TaZbDUYiynNM5M/zAFU1aLVQLEVO2ZnzyYW5ge rFMz25HZjSUWkknSeAS0X1OU7L1ttwjsm5wnu2wBrbfVVBeYA4WJihZcBxzSMAP8ZBnX P2Xw== Received: by 10.68.201.135 with SMTP id ka7mr17303057pbc.15.1343423608790; Fri, 27 Jul 2012 14:13:28 -0700 (PDT) Received: from [172.20.10.4] (out-bc-183.wireless.telus.com. [209.121.225.183]) by mx.google.com with ESMTPS id ru4sm2571472pbc.66.2012.07.27.14.13.26 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Jul 2012 14:13:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: multipart/alternative; boundary="Apple-Mail=_8A30F84D-FAE5-49DB-8557-6B69E4438864" From: John Bradley In-Reply-To: Date: Fri, 27 Jul 2012 14:13:25 -0700 Message-Id: <328075DE-1290-415A-AFA1-29E54FFB803B@ve7jtb.com> References: <82F6AE16-F7D7-4733-863B-DE0776D84809@team.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F8073950@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943667450D2@TK5EX14MBXC285.redmond.corp.microsoft.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.1280) X-Gm-Message-State: ALoCoQlNVcEJF7WBoWVPeoDbk0avoptSQM8ZnUDsL1I0ultN9kcWWy052Y6g8xN0PPi0usugwtGm Cc: "breno@google.com" , Mike Jones , "James.H.Manger@team.telstra.com" , "jose@ietf.org" , "Axel.Nennker@telekom.de" Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 21:13:31 -0000 --Apple-Mail=_8A30F84D-FAE5-49DB-8557-6B69E4438864 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I don't know that the two ECC algorithms in JWA should support all = possible ECC permutations. If some new exotic combination needs to be supported a new algorithm = name is added to JWA and both sides need to support it. Only understanding some of the ECC parameters could cause significant = security failures. John B. On 2012-07-27, at 1:49 PM, Anthony Nadalin wrote: > So not sure this is at all possible for all the permutations that = there might be for all the parameters that one could specify for ECC > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Axel.Nennker@telekom.de > Sent: Friday, July 27, 2012 1:30 AM > To: Mike Jones; breno@google.com; James.H.Manger@team.telstra.com > Cc: jose@ietf.org > Subject: Re: [jose] MUST understand ALL header fields > =20 > I agree with Breno=92s analysis and support to ditch extensibility. = Instead the JWA must specify which alg/enc/int algorithm needs what = mandatory parameters. > JWTs with a header with unknown parameters must be rejected. > =20 > If somebody needs to new algorithms or new extra parameters they = should write a new draft. With all the interoperability issues that this = implies=85 > If later somebody finds that one alg/enc/int from this spec is not = secure enough then the implementations need to decide whether they can = take the risk to continue to support it or pull it. My hope is that our = current set of specified algs/encs/ints is broad enough that a secure = alternative exists if this ever happens. > =20 > The cost for extensibility is too high and there is a real danger that = this WG gets stuck like the OAUTH-WG for years. > =20 > Let=92s specify something that is useful now. > =20 > Axel > =20 > =20 > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Mike Jones > Sent: Thursday, July 26, 2012 7:39 PM > To: Breno de Medeiros; Manger, James H > Cc: jose@ietf.org > Subject: Re: [jose] MUST understand ALL header fields > =20 > I agree with this analysis. If there=92s an explicit way defined to = indicate which additional header parameters may be ignored, that would = be OK. Allowing ignore-by-default would be a recipe for disaster. > =20 > -- Mike > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Breno de Medeiros > Sent: Thursday, July 26, 2012 10:35 AM > To: Manger, James H > Cc: jose@ietf.org > Subject: Re: [jose] MUST understand ALL header fields > =20 > Put it another way: If we want the JWT security header to be = extensible we need to define an explicit extension mechanism. It is NOT = sufficient to say MUST ignore non-understood fields in the header. This = will make it impossible to write secure implementations of validation = libraries in practice. > =20 > An extension mechanism would define: > =20 > - How to bundle fields of an extension as a single object. > - How to indicate that this object is an extension, and whether the = extension is critical (can't be safely ignored) or not. > =20 > You can't get extensibility cheaply in a security spec. A choice is = needed whether to support extensibility explicitly (at the expense of = significant increase of spec complexity, since a lot will have to be = spelled out right now) or not. Giving up clear security semantics to get = cheap extensibility is not an acceptable 3rd option. > =20 > =20 >=20 > On Thu, Jul 26, 2012 at 9:16 AM, Breno de Medeiros = wrote: > =20 > =20 >=20 > On Wed, Jul 25, 2012 at 10:28 PM, Manger, James H = wrote: > Breno, > =20 > >> How about stapling an OCSP response to a JOSE message? > > That's a more compelling use case -- it's security-specific but only = adds to the security validation context. > =20 > =20 > How about the signing time? > =20 > How about some DNS records with DANE and DNSSEC info giving evidence = that the public key is associated with a domain? > =20 > How about a blob of data related to Sovereign Keys, or Perspectives, = or Convergence, or some other proposal to bolster PKI? > =20 > How about a domain_parameter_seed so you can verify that the common = domain parameters (eg p & q in DSA) were not chosen to have special = properties? > =20 > How about data to allow you to validate a public key (eg co-factor for = EC? Something complicated for RSA?)? > =20 > How about a timestamp from a timestamp service? > =20 > =20 > I=92m not sure which, where, or when an item like the ones mentioned = above will be needed. I am confident that someone will need some items = like these. When that happens they should have a choice about whether = including the item needs to break interop with all existing receivers. A = mode field that MUST be understood (eg =93t=94:=94sig=94) coupled with = MUST ignored any unrecognized parameters keeps our future choices open. > =20 > That's not good enough for a security spec. If fields are added and = not all MUST be understood, then we need explicit syntax about what = fields are to be ignored when not understood. E.g., in X509 = certificates, extensions (while optional) have the ability to declare = themselves critical, so that implementations that don't understand that = extension MUST reject the certificate as invalid. > =20 > =20 > =20 > > However declaring that any header you don't understand could be = optional is a far worse balance on the extensibility versus simplicity = spectrum (where simplicity here is a stand-in for security, = interoperability, etc.) > =20 > I=92m not sure I understand this =93simplicity=94 argument. Ignoring = unrecognized fields is the simplest implementation choice. Is your idea = that if you tightly constrain extensibility (by making them MUST = understand) then messages will not accumulate as many =93enhancements=94 = of dubious value. That is, over time a MUST ignore rule allows messages = to get more complex (and hence less secure/interoperable). Do you want = =93MUST understand=94 to strongly discourage people misusing the header = to carry content metadata, for instance? > =20 > Inevitably, a field will be added that shouldn't be ignored because it = modifies the meaning of some other widely understood header entry, = followed by usual antics and general perplexity. > =20 > =20 > =20 > -- > James Manger > =20 > From: Breno de Medeiros [mailto:breno@google.com]=20 > Sent: Thursday, 26 July 2012 1:12 PM > To: Manger, James H > Cc: jose@ietf.org >=20 > Subject: Re: [jose] MUST understand ALL header fields > =20 > That's a more compelling use case -- it's security-specific but only = adds to the security validation context. > =20 > There may be a case to define optional entries in the JWT header. = However declaring that any header you don't understand could be optional = is a far worse balance on the extensibility versus simplicity spectrum = (where simplicity here is a stand-in for security, interoperability, = etc.) So I am not convinced that losing the ability to declare OCSP = bindings in JWTs justifies dropping the MUST language. If there is rough = consensus that defining optional security fields in the header is = prudent from the viewpoint of future spec extensibility then we should = devise some simple way to declare a JWT header field optional and exempt = _only_those_ from the MUST fail when not understanding clause. Changing = the default behavior even to SHOULD appears to me to sacrifice too much = on the altar of extensibility.=20 > =20 >=20 > On Wed, Jul 25, 2012 at 7:38 PM, Manger, James H = wrote: > How about stapling an OCSP response to a JOSE message? >=20 > Why should that be "MUST understand"? >=20 > -- > James Manger >=20 >=20 > =20 > --=20 > --Breno >=20 >=20 > =20 > --=20 > --Breno >=20 >=20 > =20 > --=20 > --Breno > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_8A30F84D-FAE5-49DB-8557-6B69E4438864 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I don't know that the two ECC algorithms in JWA = should support all possible ECC permutations.

If some = new exotic combination needs to be supported a new algorithm name is = added to JWA and both sides need to support = it.

Only understanding some of the ECC = parameters could cause significant security = failures.

John B.

On = 2012-07-27, at 1:49 PM, Anthony Nadalin wrote:

So not sure this is at all possible for all the = permutations that there might be for all the parameters that one could = specify for ECC
 
 jose-bounces@ietf.org [mailto:jose-bounces@ietf.org= ] On Behalf Of  Friday, July 27, 2012 1:30 = AM
To: Mike = Jones; breno@google.com;  jose@ietf.org
Subject: Re: [jose] MUST understand = ALL header fields
 
I agree with Breno=92s analysis and support to ditch = extensibility. Instead the JWA must specify which alg/enc/int algorithm = needs what mandatory parameters.
JWTs with a header with unknown = parameters must be rejected.
If somebody needs to new algorithms or new extra = parameters they should write a new draft. With all the interoperability = issues that this implies=85
If later somebody finds that one = alg/enc/int from this spec is not secure enough then the implementations = need to decide whether they can take the risk to continue to support it = or pull it. My hope is that our current set of specified algs/encs/ints = is broad enough that a secure alternative exists if this ever = happens.
 
The cost for extensibility is too = high and there is a real danger that this WG gets stuck like the = OAUTH-WG for years.
 
Let=92s specify something that is = useful now.
 
Axel
 
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike = Jones
Sent: Thursday, July 26, 2012 = 7:39 PM
To: Breno de Medeiros; Manger, = James H
Cc: jose@ietf.org
Subject: Re: [jose] MUST understand = ALL header fields
 
I agree with this analysis.  If there=92s an = explicit way defined to indicate which additional header parameters may = be ignored, that would be OK.  Allowing ignore-by-default would be = a recipe for disaster.
 
 
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Breno de = Medeiros
Sent: Thursday, July 26, 2012 = 10:35 AM
To: Manger, James = H
Cc: jose@ietf.org
Subject: Re: [jose] MUST understand = ALL header fields
Put it another way: If we want the JWT = security header to be extensible we need to define an explicit extension = mechanism. It is NOT sufficient to say MUST ignore non-understood fields = in the header. This will make it impossible to write secure = implementations of validation libraries in = practice.
An extension = mechanism would define:
 
- How to bundle = fields of an extension as a single = object.
- How to indicate = that this object is an extension, and whether the extension is critical = (can't be safely ignored) or not.
 
You can't get = extensibility cheaply in a security spec. A choice is needed whether to = support extensibility explicitly (at the expense of significant increase = of spec complexity, since a lot will have to be spelled out right now) = or not. Giving up clear security semantics to get cheap extensibility is = not an acceptable 3rd option.
 

 

On Thu, Jul 26, 2012 = at 9:16 AM, Breno de Medeiros < 

 

 
That's a more compelling use case -- = it's security-specific but only adds to the security validation = context.
 
There may be a case to define optional = entries in the JWT header. However declaring that any header you don't = understand could be optional is a far worse balance on the extensibility = versus simplicity spectrum (where simplicity here is a stand-in for = security, interoperability, etc.) So I am not convinced that losing the = ability to declare OCSP bindings in JWTs justifies dropping the MUST = language. If there is rough consensus that defining optional security = fields in the header is prudent from the viewpoint of future spec = extensibility then we should devise some simple way to declare a JWT = header field optional and exempt _only_those_ from the MUST fail when = not understanding clause. Changing the default behavior even to SHOULD = appears to me to sacrifice too much on the altar of = extensibility. 




<= /div>


On Fri, Jul 27, 2012 at 1:57 PM, Mike J= ones <Michael.Jones@microsoft.com> wrote:

I just spoke with Tony, a= nd a clarifying point is worth making.=A0 He=92s saying that there will hav= e to be additional header parameters at some point for some use cases.=A0 He=92s using additional ECC modes as an example that might r= equire them.=A0 He=92s not saying that those header parameters, if present,= do not have to be understood.

=A0<= /p>

Put another way, he=92s s= aying that extensions are inevitable and having no extensibility model is n= ot an option.=A0 Fortunately, we already have the JSON Web Signature and Encryption Header Parameters Registry http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-04#section-7.= 1.1 that provides just such an extensibility point.

=A0<= /p>

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

=A0<= /p>

From: Anthony = Nadalin
Sent: Friday, July 27, 2012 1:49 PM
To: Axe= l.Nennker@telekom.de; Mike Jones; breno@google.com; James.H.Manger@team.telstra.com
Cc: jose@ietf.org=
Subject: RE: [jose] MUST understand ALL header fields<= /span>

=A0

So not sure this is at al= l possible for all the permutations that there might be for all the paramet= ers that one could specify for ECC

=A0<= /p>

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Axel.Nennker@telekom.de
Sent: Friday, July 27, 2012 1:30 AM
To: Mike Jones; breno@google.com; James.H.Manger@team.telstra.com
Cc: jose@ietf.org=
Subject: Re: [jose] MUST understand ALL header fields<= /span>

=A0

I agree with Breno=92s an= alysis and support to ditch extensibility. Instead the JWA must specify whi= ch alg/enc/int algorithm needs what mandatory parameters.

JWTs with a header with u= nknown parameters must be rejected.

=A0<= /p>

If somebody needs to new = algorithms or new extra parameters they should write a new draft. With all = the interoperability issues that this implies=85

If later somebody finds t= hat one alg/enc/int from this spec is not secure enough then the implementa= tions need to decide whether they can take the risk to continue to support it or pull it. My hope is that our current set of specified alg= s/encs/ints is broad enough that a secure alternative exists if this ever h= appens.

=A0<= /p>

The cost for extensibilit= y is too high and there is a real danger that this WG gets stuck like the O= AUTH-WG for years.

=A0<= /p>

Let=92s specify something= that is useful now.

=A0<= /p>

Axel=

=A0<= /p>

=A0<= /p>

=A0<= /p>

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Thursday, July 26, 2012 7:39 PM
To: Breno de Medeiros; Manger, James H
Cc: jose@ietf.org=
Subject: Re: [jose] MUST understand ALL header fields<= /span>

=A0

I agree with this analysi= s.=A0 If there=92s an explicit way defined to indicate which additional hea= der parameters may be ignored, that would be OK.=A0 Allowing ignore-by-defa= ult would be a recipe for disaster.

=A0<= /p>

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

=A0<= /p>

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Breno de Medeiros Sent: Thursday, July 26, 2012 10:35 AM
To: Manger, James H
Cc: jose@ietf.org=
Subject: Re: [jose] MUST understand ALL header fields<= /span>

=A0

Put it another way: If we want the JWT security head= er to be extensible we need to define an explicit extension mechanism. It i= s NOT sufficient to say MUST ignore non-understood fields in the header. Th= is will make it impossible to write secure implementations of validation libraries in practice.<= /p>

=A0

An extension mechanism would define:

=A0

- How to bundle fields of an extension as a single o= bject.

- How to indicate that this object is an extension, = and whether the extension is critical (can't be safely ignored) or not.=

=A0

You can't get extensibility cheaply in a securit= y spec. A choice is needed whether to support extensibility explicitly (at = the expense of significant increase of spec complexity, since a lot will ha= ve to be spelled out right now) or not. Giving up clear security semantics to get cheap extensibility is not an ac= ceptable 3rd option.

=A0

=A0

On Thu, Jul 26, 2012 at 9:16 AM, Breno de Medeiros &= lt;breno@google.com> wrote:

=A0

=A0

On Wed, Jul 25, 2012 at 10:28 PM, Manger, James H &l= t;Jame= s.H.Manger@team.telstra.com> wrote:

Breno,

=A0=

>> H= ow about stapling an OCSP response to a JOSE message?

> That&= #39;s a more compelling use case -- it's security-specific but only add= s to the security validation context.

=A0=

=A0=

How about = the signing time?

=A0=

How about = some DNS records with DANE and DNSSEC info giving evidence that the public key is associated with a domain?=

=A0=

How about = a blob of data related to Sovereign Keys, or Perspectives, or Convergence, or some other proposal to bolster PKI?<= u>

=A0=

How about = a domain_parameter_seed so you can verify that the common domain parameters (eg p & q in DSA) were not chosen to have special properties?

=A0=

How about = data to allow you to validate a public key (eg co-factor for EC? Something complicated for RSA?)?

=A0=

How about = a timestamp from a timestamp service?=

=A0=

=A0=

I=92m not = sure which, where, or when an item like the ones mentioned above will be ne= eded. I am confident that someone will need some items like these. When that hap= pens they should have a choice about whether including the item needs to br= eak interop with all existing receivers. A mode field that MUST be understo= od (eg =93t=94:=94sig=94) coupled with MUST ignored any unrecognized parameters keeps our future choices open.<= span lang=3D"EN-AU">

=A0

That's not good enough for a security spec. If f= ields are added and not all MUST be understood, then we need explicit synta= x about what fields are to be ignored when not understood. E.g., in X509 ce= rtificates, extensions (while optional) have the ability to declare themselves critical, so that implementations t= hat don't understand that extension MUST reject the certificate as inva= lid.

=A0

=A0=

=A0=

> However declaring that any= header you don't understand could be optional is a far worse balance o= n the extensibility versus simplicity spectrum (where simplicity here is a stand-in for security, interoperability, etc.)

=A0=

I=92m not = sure I understand this =93simplicity=94 argument. Ignoring unrecognized fie= lds is the simplest implementation choice. Is your idea that if you tightly const= rain extensibility (by making them MUST understand) then messages will not = accumulate as many =93enhancements=94 of dubious value. That is, over time = a MUST ignore rule allows messages to get more complex (and hence less secure/interoperable). Do you want =93MUS= T understand=94 to strongly discourage people misusing the header to carry = content metadata, for instance?

=A0

Inevitably, a field will be added that shouldn't= be ignored because it modifies the meaning of some other widely understood= header entry, followed by usual antics and general perplexity.

=A0

=A0=

=A0=

--<= span lang=3D"EN-AU">

James Mang= er

=A0=

From: Breno de= Medeiros [mailto:bre= no@google.com]
Sent: Thursday, 26 July 2012 1:12 PM
To: Manger, James H
Cc: jose@ietf.org=


Subject: Re: [jose] MUST understand ALL header fields<= /span>

=A0

That's a more compelling us= e case -- it's security-specific but only adds to the security validati= on context.

=A0

There may be a case to define o= ptional entries in the JWT header. However declaring that any header you do= n't understand could be optional is a far worse balance on the extensibility versus simplicity spectrum (where simplicity here is = a stand-in for security, interoperability, etc.) So I am not convinced that= losing the ability to declare OCSP bindings in JWTs justifies dropping the= MUST language. If there is rough consensus that defining optional security fields in the header is prudent = from the viewpoint of future spec extensibility then we should devise some = simple way to declare a JWT header field optional and exempt _only_those_ f= rom the MUST fail when not understanding clause. Changing the default behavior even to SHOULD appears to me to sacr= ifice too much on the altar of extensibility.=A0

= =A0

On Wed, Jul 25, 2012 at 7:38 PM= , Manger, James H <James.H.Manger@team.telstra.com> wrote:

How about stapling an OCSP resp= onse to a JOSE message?

Why should that be "MUST understand"?

--
James Manger



=A0

--
--Breno



=A0

--
--Breno



=A0

--
--Breno




--
--Breno
_______________________________________________
jose = mailing list
jose@ietf.org
To: "'Breno de Medeiros'" References: <82F6AE16-F7D7-4733-863B-DE0776D84809@team.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F8073950@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F80F4DD0@WSMSG3153V.srv.dir.telstra.com> <023301cd6bb2$22220ce0$666626a0$@augustcellars.com> In-Reply-To: Date: Fri, 27 Jul 2012 14:12:08 -0700 Message-ID: <02ad01cd6c3c$7bbec5b0$733c5110$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02AE_01CD6C01.CF63E550" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJiWfhm9ifvIrHdrYH/+rlKaFz2cwIo0LhCAcFXkmECkyfjMAKuSqqTAUvDaGwBsqY1lgEaXe/BlamhpxA= Content-Language: en-us Cc: "'Manger, James H'" , jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 21:13:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02AE_01CD6C01.CF63E550 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I don=E2=80=99t disagree with that, however they were not widely = implemented and used, so they cannot be easily rolled out today without = having a large number of implementations roll over and play dead. This = is what James is talking about when he is saying that we need to have = the ability to roll out new items in a non-critical manner. =20 Jim =20 =20 From: Breno de Medeiros [mailto:breno@google.com]=20 Sent: Friday, July 27, 2012 1:56 PM To: Jim Schaad Cc: Manger, James H; jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields =20 If they were truly non-critical and marked as critical then there was a = decision process that arrived at the incorrect conclusion. There are = several examples of critical extensions that if ignored will cause the = processing of a certificate to lead to wide security problems. An = example is name constraints.=20 =20 On Thu, Jul 26, 2012 at 9:41 PM, Jim Schaad = wrote: > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of > Manger, James H > Sent: Thursday, July 26, 2012 8:45 PM > To: Breno de Medeiros; jose@ietf.org > Subject: Re: [jose] MUST understand ALL header fields > > Breno, > > > Inevitably, a field will be added that shouldn't be ignored because = it > modifies the meaning of some other widely understood header entry, > followed by usual antics and general perplexity. > > Is there a good example of where this has occurred? That might help us > reach a common understanding. > > > > An extension mechanism would define: > > > > - How to bundle fields of an extension as a single object. > > - How to indicate that this object is an extension, and whether the > extension is critical (can't be safely ignored) or not. > > If we support extensibility with per-extension criticality flags, = wouldn't it be > almost as inevitable that an extension will be added that shouldn't be > ignored but is marked non-critical to not break interop? Or do you = think > people will "do the right thing (not the easy thing)" with criticality = flags? Anyone who believes this to be a true statement is more than welcome to = read the current firestorm about name constraints on the PKIX mailing = list. They were defined and said to be critical when the first draft = (RFC2459) came out in 1999 and people are saying that they need to make = it non-critical because too many people did not implement it. The JOSE = documents are better in that there are not as many "extensions" defined. = But the history is still there. Jim > > P.S. If the 7 header parameters that are defined in JWS (draft 04) but = never > used in its examples were all defined as "extensions", would any be = critical? > jku? jwk? x5u? x5t? x5c? kid? cty? I doubt it. > > > > It is NOT sufficient to say MUST ignore non-understood fields in the > header. This will make it impossible to write secure implementations = of > validation libraries in practice. > > CMS [RFC5652] and its AEAD mode [RFC5083] both have authAttrs fields = that > can hold arbitrary attributes. I see no mention in those specs of a = "MUST > understand" rule for attributes in those fields. I haven't heard that = that has > made it impossible to write secure implementations of validation = libraries. > > Is it OK for CMS because there are dedicated fields for the primary = items (eg > signatureAlgorithm), separate from the authAttrs bucket? I don't think = that > can be the difference. > > Lots of CMS attributes have been defined by different parties. For = instance, > CMS Advanced Electronic Signatures (CAdES) [RFC5126] defines or = mentions > dozens (signer-location, content-hints, signing-certificate, = commitment-type, > =EF=BF=BD). Some MUST be present in a CAdES message, others are = OPTIONAL. From > a quick glance I didn't see a statement about which MUST be = understood. > > > -- > James Manger > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose =20 --=20 --Breno ------=_NextPart_000_02AE_01CD6C01.CF63E550 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I don=E2=80=99t disagree with that, however they were not widely = implemented and used, so they cannot be easily rolled out today without = having a large number of implementations roll over and play dead.=C2=A0 = This is what James is talking about when he is saying that we need to = have the ability to roll out new items in a non-critical = manner.

 

Jim

 

 

From:= = Breno de Medeiros [mailto:breno@google.com]
Sent: Friday, = July 27, 2012 1:56 PM
To: Jim Schaad
Cc: Manger, = James H; jose@ietf.org
Subject: Re: [jose] MUST understand ALL = header fields

 

If they were = truly non-critical and marked as critical then there was a decision = process that arrived at the incorrect conclusion. There are several = examples of critical extensions that if ignored will cause the = processing of a certificate to lead to wide security problems. An = example is name constraints. 

 

On Thu, Jul 26, 2012 at 9:41 PM, Jim Schaad <ietf@augustcellars.com> wrote:

<personal>


> -----Original Message-----
> From: jose-bounces@ietf.org = [mailto:jose-bounces@ietf.org] On = Behalf Of

> Manger, = James H
> Sent: Thursday, July 26, 2012 8:45 PM
> To: Breno = de Medeiros; jose@ietf.org
> = Subject: Re: [jose] MUST understand ALL header = fields
>

> Breno,
>
> > = Inevitably, a field will be added that shouldn't be ignored because = it
> modifies the meaning of some other widely understood header = entry,
> followed by usual antics and general = perplexity.
>
> Is there a good example of where this has = occurred? That might help us
> reach a common = understanding.
>
>
> > An extension mechanism would = define:
> >
> > - How to bundle fields of an extension = as a single object.
> > - How to indicate that this object is = an extension, and whether the
> extension is critical (can't be = safely ignored) or not.
>
> If we support extensibility with = per-extension criticality flags, wouldn't it be
> almost as = inevitable that an extension will be added that shouldn't be
> = ignored but is marked non-critical to not break interop? Or do you = think
> people will "do the right thing (not the easy = thing)" with criticality flags?

Anyone who believes this to be a true statement is = more than welcome to read the current firestorm about name constraints = on the PKIX mailing list.  They were defined and said to be = critical when the first draft (RFC2459) came out in 1999 and people are = saying that they need to make it non-critical because too many people = did not implement it.  The JOSE documents are better in that there = are not as many "extensions" defined.  But the history is = still there.

Jim


>
> P.S. If the 7 header parameters that = are defined in JWS (draft 04) but never
> used in its examples = were all defined as "extensions", would any be = critical?
> jku? jwk? x5u? x5t? x5c? kid? cty? I doubt = it.
>
>
> > It is NOT sufficient to say MUST ignore = non-understood fields in the
> header. This will make it = impossible to write secure implementations of
> validation = libraries in practice.
>
> CMS [RFC5652] and its AEAD mode = [RFC5083] both have authAttrs fields that
> can hold arbitrary = attributes. I see no mention in those specs of a "MUST
> = understand" rule for attributes in those fields. I haven't heard = that that has
> made it impossible to write secure implementations = of validation libraries.
>
> Is it OK for CMS because there = are dedicated fields for the primary items (eg
> = signatureAlgorithm), separate from the authAttrs bucket? I don't think = that
> can be the difference.
>
> Lots of CMS = attributes have been defined by different parties. For instance,
> = CMS Advanced Electronic Signatures (CAdES) [RFC5126] defines or = mentions
> dozens (signer-location, content-hints, = signing-certificate, commitment-type,
> =EF=BF=BD). Some MUST = be present in a CAdES message, others are OPTIONAL. From
> a quick = glance I didn't see a statement about which MUST be = understood.
>
>
> --
> James = Manger

> = _______________________________________________
> jose mailing = list
> jose@ietf.org
> = https://www.ietf.org/mailman/listinfo/jose



 

-- =
--Breno

------=_NextPart_000_02AE_01CD6C01.CF63E550-- From Axel.Nennker@telekom.de Fri Jul 27 14:53:12 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB7921F85F8 for ; Fri, 27 Jul 2012 14:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tW0x+7WR4Dcu for ; Fri, 27 Jul 2012 14:53:08 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id B829B21F85F7 for ; Fri, 27 Jul 2012 14:53:06 -0700 (PDT) Received: from he101250.emea1.cds.t-internal.com ([10.125.92.153]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 27 Jul 2012 23:53:03 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.25]) by HE101250.emea1.cds.t-internal.com ([fe80::e439:4046:12e2:e37%15]) with mapi; Fri, 27 Jul 2012 23:53:03 +0200 From: To: , , , Date: Fri, 27 Jul 2012 23:52:59 +0200 Thread-Topic: [jose] MUST understand ALL header fields Thread-Index: Ac1q18qgDo+RPNtVSUCtA/itrmlQRAABKC6AAATFAIAAFqRnAAACvnEAAAANS0AAHrzKsAAaOkrgAAJDJjA= Message-ID: References: <82F6AE16-F7D7-4733-863B-DE0776D84809@team.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F8073950@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943667450D2@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF402517D8E81BAHE111541eme_" MIME-Version: 1.0 Cc: jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 21:53:13 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF402517D8E81BAHE111541eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have something for ECC that seems to "work" for those who have a use cas= e for ECC. New parameters "that one COULD specify" are not in the current draft. From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ant= hony Nadalin Sent: Friday, July 27, 2012 10:49 PM To: Nennker, Axel; Mike Jones; breno@google.com; James.H.Manger@team.telstr= a.com Cc: jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields So not sure this is at all possible for all the permutations that there mig= ht be for all the parameters that one could specify for ECC From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Axe= l.Nennker@telekom.de Sent: Friday, July 27, 2012 1:30 AM To: Mike Jones; breno@google.com; James.H.Manger@team.telstra.com Cc: jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields I agree with Breno's analysis and support to ditch extensibility. Instead t= he JWA must specify which alg/enc/int algorithm needs what mandatory parame= ters. JWTs with a header with unknown parameters must be rejected. If somebody needs to new algorithms or new extra parameters they should wri= te a new draft. With all the interoperability issues that this implies... If later somebody finds that one alg/enc/int from this spec is not secure e= nough then the implementations need to decide whether they can take the ris= k to continue to support it or pull it. My hope is that our current set of = specified algs/encs/ints is broad enough that a secure alternative exists i= f this ever happens. The cost for extensibility is too high and there is a real danger that this= WG gets stuck like the OAUTH-WG for years. Let's specify something that is useful now. Axel From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Mike Jone= s Sent: Thursday, July 26, 2012 7:39 PM To: Breno de Medeiros; Manger, James H Cc: jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields I agree with this analysis. If there's an explicit way defined to indicate= which additional header parameters may be ignored, that would be OK. Allo= wing ignore-by-default would be a recipe for disaster. -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Breno de = Medeiros Sent: Thursday, July 26, 2012 10:35 AM To: Manger, James H Cc: jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields Put it another way: If we want the JWT security header to be extensible we = need to define an explicit extension mechanism. It is NOT sufficient to say= MUST ignore non-understood fields in the header. This will make it impossi= ble to write secure implementations of validation libraries in practice. An extension mechanism would define: - How to bundle fields of an extension as a single object. - How to indicate that this object is an extension, and whether the extensi= on is critical (can't be safely ignored) or not. You can't get extensibility cheaply in a security spec. A choice is needed = whether to support extensibility explicitly (at the expense of significant = increase of spec complexity, since a lot will have to be spelled out right = now) or not. Giving up clear security semantics to get cheap extensibility = is not an acceptable 3rd option. On Thu, Jul 26, 2012 at 9:16 AM, Breno de Medeiros > wrote: On Wed, Jul 25, 2012 at 10:28 PM, Manger, James H > wrote: Breno, >> How about stapling an OCSP response to a JOSE message? > That's a more compelling use case -- it's security-specific but only adds= to the security validation context. How about the signing time? How about some DNS records with DANE and DNSSEC info giving evidence that t= he public key is associated with a domain? How about a blob of data related to Sovereign Keys, or Perspectives, or Con= vergence, or some other proposal to bolster PKI? How about a domain_parameter_seed so you can verify that the common domain = parameters (eg p & q in DSA) were not chosen to have special properties? How about data to allow you to validate a public key (eg co-factor for EC? = Something complicated for RSA?)? How about a timestamp from a timestamp service? I'm not sure which, where, or when an item like the ones mentioned above wi= ll be needed. I am confident that someone will need some items like these. = When that happens they should have a choice about whether including the ite= m needs to break interop with all existing receivers. A mode field that MUS= T be understood (eg "t":"sig") coupled with MUST ignored any unrecognized p= arameters keeps our future choices open. That's not good enough for a security spec. If fields are added and not all= MUST be understood, then we need explicit syntax about what fields are to = be ignored when not understood. E.g., in X509 certificates, extensions (whi= le optional) have the ability to declare themselves critical, so that imple= mentations that don't understand that extension MUST reject the certificate= as invalid. > However declaring that any header you don't understand could be optional = is a far worse balance on the extensibility versus simplicity spectrum (whe= re simplicity here is a stand-in for security, interoperability, etc.) I'm not sure I understand this "simplicity" argument. Ignoring unrecognized= fields is the simplest implementation choice. Is your idea that if you tig= htly constrain extensibility (by making them MUST understand) then messages= will not accumulate as many "enhancements" of dubious value. That is, over= time a MUST ignore rule allows messages to get more complex (and hence les= s secure/interoperable). Do you want "MUST understand" to strongly discoura= ge people misusing the header to carry content metadata, for instance? Inevitably, a field will be added that shouldn't be ignored because it modi= fies the meaning of some other widely understood header entry, followed by = usual antics and general perplexity. -- James Manger From: Breno de Medeiros [mailto:breno@google.com] Sent: Thursday, 26 July 2012 1:12 PM To: Manger, James H Cc: jose@ietf.org Subject: Re: [jose] MUST understand ALL header fields That's a more compelling use case -- it's security-specific but only adds t= o the security validation context. There may be a case to define optional entries in the JWT header. However d= eclaring that any header you don't understand could be optional is a far wo= rse balance on the extensibility versus simplicity spectrum (where simplici= ty here is a stand-in for security, interoperability, etc.) So I am not con= vinced that losing the ability to declare OCSP bindings in JWTs justifies d= ropping the MUST language. If there is rough consensus that defining option= al security fields in the header is prudent from the viewpoint of future sp= ec extensibility then we should devise some simple way to declare a JWT hea= der field optional and exempt _only_those_ from the MUST fail when not unde= rstanding clause. Changing the default behavior even to SHOULD appears to m= e to sacrifice too much on the altar of extensibility. On Wed, Jul 25, 2012 at 7:38 PM, Manger, James H > wrote: How about stapling an OCSP response to a JOSE message? Why should that be "MUST understand"? -- James Manger -- --Breno -- --Breno -- --Breno --_000_CE8995AB5D178F44A2154F5C9A97CAF402517D8E81BAHE111541eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have s= omething for ECC that seems to “work” for those who have a use = case for ECC.

New paramet= ers “that one COULD specify” are not in the current draft.=

 

From: jose-bounces@ietf.org [mailto:jose-bou= nces@ietf.org] On Behalf Of Anthony Nadalin
Sent: Friday, = July 27, 2012 10:49 PM
To: Nennker, Axel; Mike Jones; breno@googl= e.com; James.H.Manger@team.telstra.com
Cc: jose@ietf.org
Su= bject: Re: [jose] MUST understand ALL header fields

 

So not sure this is at all possible for all the permutations that = there might be for all the parameters that one could specify for ECC

 

From: jose-bounces@ietf.org [mailto:jose-bounc= es@ietf.org] On Behalf Of Axel.Nennker@telekom.de
Sent: Fr= iday, July 27, 2012 1:30 AM
To: Mike Jones; breno@google.com; Jam= es.H.Manger@team.telstra.com
Cc: jose@ietf.org
Subject:= Re: [jose] MUST understand ALL header fields

 

I= agree with Breno’s analysis and support to ditch extensibility. Inst= ead the JWA must specify which alg/enc/int algorithm needs what mandatory p= arameters.

JWTs with a he= ader with unknown parameters must be rejected.

 

If somebody needs to new algorithms or new extra parameters they should w= rite a new draft. With all the interoperability issues that this implies= 230;

If later somebody fin= ds that one alg/enc/int from this spec is not secure enough then the implem= entations need to decide whether they can take the risk to continue to supp= ort it or pull it. My hope is that our current set of specified algs/encs/i= nts is broad enough that a secure alternative exists if this ever happens.<= o:p>

 

The cost for extensibility is too high and th= ere is a real danger that this WG gets stuck like the OAUTH-WG for years.

 

Let’s specify something that is useful n= ow.

 

Axel

 

 

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jone= s
Sent: Thursday, July 26, 2012 7:39 PM
To: Breno de Me= deiros; Manger, James H
Cc: jose= @ietf.org
Subject: Re: [jose] MUST understand ALL header fiel= ds

 <= /p>

I agree with this analysis.  If there&#= 8217;s an explicit way defined to indicate which additional header paramete= rs may be ignored, that would be OK.  Allowing ignore-by-default would= be a recipe for disaster.

 

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

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] = On Behalf Of Breno de Medeiros
Sent: Thursday, July 26, 20= 12 10:35 AM
To: Manger, James H
Cc: jose@ietf.org
Subject: Re: [jose] MUST understa= nd ALL header fields

 <= /o:p>

Put it another way: If we want the JWT securi= ty header to be extensible we need to define an explicit extension mechanis= m. It is NOT sufficient to say MUST ignore non-understood fields in the hea= der. This will make it impossible to write secure implementations of valida= tion libraries in practice.

&n= bsp;

An extension mechanism would = define:

 

=

- How to bundle fields of an extension as a= single object.

- How to indi= cate that this object is an extension, and whether the extension is critica= l (can't be safely ignored) or not.

 

You can't get e= xtensibility cheaply in a security spec. A choice is needed whether to supp= ort extensibility explicitly (at the expense of significant increase of spe= c complexity, since a lot will have to be spelled out right now) or not. Gi= ving up clear security semantics to get cheap extensibility is not an accep= table 3rd option.

 =

 

On Thu, Jul 26, 2012 at 9:16 A= M, Breno de Medeiros <breno@google.com> wrote:

 

<= o:p> 

On Wed, Jul 25, 2012 at = 10:28 PM, Manger, James H <James.H.Manger@team.telstra.com> wrote:=

Breno,

 

>> Ho= w about stapling an OCSP response to a JOSE message?

> That's a mor= e compelling use case -- it's security-specific but only adds to the securi= ty validation context.

 

 

How about the signing time?

 <= span lang=3DEN-AU>

How abou= t some DNS records with DANE and DNSSEC info giving evidence that the publi= c key is associated with a domain?

 

How about a blob of data related to= Sovereign Keys, or Perspectives, or Convergence, or some other proposal to= bolster PKI?

 

<= span lang=3DEN-AU style=3D'font-size:11.0pt;font-family:"Calibri","sans-ser= if";color:#1F497D'>How about a domain_parameter_seed so you can verify that= the common domain parameters (eg p & q in DSA) were not chosen to have= special properties?

=  

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>How about data to allow you to validate a public = key (eg co-factor for EC? Something complicated for RSA?)?

 

How about a= timestamp from a timestamp service?

 

 <= o:p>

I’m not sure which, w= here, or when an item like the ones mentioned above will be needed. I am co= nfident that someone will need some items like these. When that happens the= y should have a choice about whether including the item needs to break inte= rop with all existing receivers. A mode field that MUST be understood (eg &= #8220;t”:”sig”) coupled with MUST ignored any unrecognize= d parameters keeps our future choices open.<= /o:p>

 

=

That's not good enough for a security= spec. If fields are added and not all MUST be understood, then we need exp= licit syntax about what fields are to be ignored when not understood. E.g.,= in X509 certificates, extensions (while optional) have the ability to decl= are themselves critical, so that implementations that don't understand that= extension MUST reject the certificate as invalid.

 

 

 

> However declaring that a= ny header you don't understand could be optional is a far worse balance on = the extensibility versus simplicity spectrum (where simplicity here is a st= and-in for security, interoperability, etc.)

<= span lang=3DEN-AU style=3D'font-size:11.0pt;font-family:"Calibri","sans-ser= if";color:#1F497D'> 

I’m not sure I understand this “= simplicity” argument. Ignoring unrecognized fields is the simplest im= plementation choice. Is your idea that if you tightly constrain extensibili= ty (by making them MUST understand) then messages will not accumulate as ma= ny “enhancements” of dubious value. That is, over time a MUST i= gnore rule allows messages to get more complex (and hence less secure/inter= operable). Do you want “MUST understand” to strongly discourage= people misusing the header to carry content metadata, for instance?=

 

Inevitably, a field will be added that shouldn't be ignored because it mod= ifies the meaning of some other widely understood header entry, followed by= usual antics and general perplexity.

 

<= span lang=3DEN-AU style=3D'font-size:11.0pt;font-family:"Calibri","sans-ser= if";color:#1F497D'> 

 =

--

James Manger

 

From: Breno de Medeiros = [mailto:breno@google.= com]
Sent: Thursday, 26 July 2012 1:12 PM
To: Mang= er, James H
Cc: jose@ietf.org


Subject: Re: [jose] MUST un= derstand ALL header fields

<= span lang=3DEN-AU> 

Tha= t's a more compelling use case -- it's security-specific but only adds to t= he security validation context.

=  

There may be a case to define optional entries in the JWT header. = However declaring that any header you don't understand could be optional is= a far worse balance on the extensibility versus simplicity spectrum (where= simplicity here is a stand-in for security, interoperability, etc.) So I a= m not convinced that losing the ability to declare OCSP bindings in JWTs ju= stifies dropping the MUST language. If there is rough consensus that defini= ng optional security fields in the header is prudent from the viewpoint of = future spec extensibility then we should devise some simple way to declare = a JWT header field optional and exempt _only_those_ from the MUST fail when= not understanding clause. Changing the default behavior even to SHOULD app= ears to me to sacrifice too much on the altar of extensibility. <= /o:p>

 

=

On Wed, Jul 25, 2012 at 7:38 PM, Manger, Jam= es H <James.H.Manger@team.telstra.com> wrote:

How about stapling an OCSP response to a JOSE message= ?

Why should that be "MUST understand"?

--
James= Manger



 

--
--Breno



 = ;

--
--Breno



&nbs= p;

--
--Breno

<= /div>= --_000_CE8995AB5D178F44A2154F5C9A97CAF402517D8E81BAHE111541eme_-- From Michael.Jones@microsoft.com Fri Jul 27 15:44:37 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F4111E80FA for ; Fri, 27 Jul 2012 15:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.279 X-Spam-Level: X-Spam-Status: No, score=-5.279 tagged_above=-999 required=5 tests=[AWL=1.319, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Jxsxeu28w94 for ; Fri, 27 Jul 2012 15:44:35 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id EFC9C11E80F9 for ; Fri, 27 Jul 2012 15:44:34 -0700 (PDT) Received: from mail84-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Fri, 27 Jul 2012 22:44:34 +0000 Received: from mail84-tx2 (localhost [127.0.0.1]) by mail84-tx2-R.bigfish.com (Postfix) with ESMTP id 78F6360298 for ; Fri, 27 Jul 2012 22:44:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VS-27(zz9371Ic85fhzz1202hzz1033IL8275bh30d1K8275dh5eeeKz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail84-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail84-tx2 (localhost.localdomain [127.0.0.1]) by mail84-tx2 (MessageSwitch) id 1343429072720535_25175; Fri, 27 Jul 2012 22:44:32 +0000 (UTC) Received: from TX2EHSMHS044.bigfish.com (unknown [10.9.14.249]) by mail84-tx2.bigfish.com (Postfix) with ESMTP id AC0914A005D for ; Fri, 27 Jul 2012 22:44:32 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS044.bigfish.com (10.9.99.144) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 27 Jul 2012 22:44:32 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0298.005; Fri, 27 Jul 2012 22:44:16 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Open Issue: Multiple uses of the Concat KDF with the same secret Thread-Index: Ac1sSVg3XDxeO3/+RGyaLSQ7LkqbVg== Date: Fri, 27 Jul 2012 22:44:15 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943667470AA@TK5EX14MBXC285.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943667470AATK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [jose] Open Issue: Multiple uses of the Concat KDF with the same secret X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 22:44:37 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943667470AATK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In conversations during this week's W3C WebCrypto F2F, Vijay Bharadwaj poin= ted out that using the same input secret to the Concat KDF twice, as we cur= rently do in JWA 4.12 http://tools.ietf.org/html/draft-ietf-jose-json-web-a= lgorithms-04#page-16, is prohibited. Rather than using two different label= s with the same secret as TLS does (in our case "Encryption" and "Integrity= "), we're supposed to generate enough key bits for both keys in one operati= on. I'll add this to the set of Open Issues for us to discuss next week. Looki= ng forward to seeing many of you then! -- Mike P.S. BTW, the W3C WebCrypto WG wants to closely coordinate with JOSE, in p= art, to ensure that the WebCrypto output - a set of JavaScript crypto APIs = - will be a great way to build JOSE implementations. From: Vijay Bharadwaj Sent: Tuesday, July 24, 2012 8:52 PM To: Mike Jones Subject: Key derivation and FIPS The restriction I was talking about is in Section 5.8 of SP 800-56A: An Approved key derivation function (KDF) shall be used to derive secret ke= ying material from a shared secret. The output from a KDF shall only be use= d for secret keying material, such as a symmetric key used for data encrypt= ion or message integrity, a secret initialization vector, or a master key t= hat will be used to generate other keys (possibly using a different process= ). Non- secret keying material (such as a non-secret initialization vector)= shall not be generated using the shared secret. Each call to the KDF requires a freshly computed shared secret, and this sh= ared secret shall be zeroized immediately following its use. The derived se= cret keying material shall be computed in its entirety before outputting an= y portion of it. In schemes using only static keys, the freshly computed sh= ared secret may be the same as the previous shared secret. In these cases, = the initiator supplied nonce (NonceU, see Section 6.3) used in the scheme w= ill vary so the same keying material is not regenerated. The derived secret keying material may be parsed into one or more keys or o= ther secret cryptographic keying material (for example, secret initializati= on vectors). If Key Confirmation (KC) or implementation validation testing = are to be performed as specified in Section 8 or Section 5.2.3, respectivel= y, then the MAC key shall be formed from the first bits of the KDF output a= nd zeroized after its use (i.e., the MAC key shall not be used for purposes= other than key confirmation or implementation validation testing). So as you can see, NIST pretty clearly advocates for the "generate a bunch = of bits and chop them up" approach. The first part is implemented in CNG by= causing BCryptDeriveKey to wipe the supplied shared secret. --_000_4E1F6AAD24975D4BA5B1680429673943667470AATK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In conversations durin= g this week’s W3C WebCrypto F2F, Vijay Bharadwaj pointed out that usi= ng the same input secret to the Concat KDF twice, as we currently do in JWA= 4.12 http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-04#page-16, is prohibited.  Rather than using two different labels with the sa= me secret as TLS does (in our case “Encryption” and “Inte= grity”), we’re supposed to generate enough key bits for both keys in one operation.

 

I’ll add this to= the set of Open Issues for us to discuss next week.  Looking forward = to seeing many of you then!

 

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

 

P.S.  BTW, the W3= C WebCrypto WG wants to closely coordinate with JOSE, in part, to ensure th= at the WebCrypto output – a set of JavaScript crypto APIs – wil= l be a great way to build JOSE implementations.

 

From: Vijay Bh= aradwaj
Sent: Tuesday, July 24, 2012 8:52 PM
To: Mike Jones
Subject: Key derivation and FIPS

 

The restriction I was talking about is in Section 5.= 8 of SP 800-56A:

 

An Approved key derivatio= n function (KDF) shall be used to derive secret keying material from a shar= ed secret. The output from a KDF shall only be used for secret keying mater= ial, such as a symmetric key used for data encryption or message integrity, a secret initialization vector, or a= master key that will be used to generate other keys (possibly using a diff= erent process). Non- secret keying material (such as a non-secret initializ= ation vector) shall not be generated using the shared secret.

 

Each call to the KDF requires a freshly compu= ted shared secret, and this shared secret shall be zeroized immediately fol= lowing its use. The derived secret keying material shall be computed in its entirety before outputting any portion o= f it. In schemes using only static keys, the freshly computed shared= secret may be the same as the previous shared secret. In these cases, the = initiator supplied nonce (NonceU, see Section 6.3) used in the scheme will vary so the same keying material = is not regenerated.

 

The derived secret keying material may be par= sed into one or more keys or other secret cryptographic keying material (fo= r example, secret initialization vectors). If Key Confirmation (KC) or implementation validation testing are to be pe= rformed as specified in Section 8 or Section 5.2.3, respectively, then the = MAC key shall be formed from the first bits of the KDF output and zeroized = after its use (i.e., the MAC key shall not be used for purposes other than key confirmation or implementati= on validation testing).

 

So as you can see, NIST pretty clearly advocates for= the “generate a bunch of bits and chop them up” approach. The = first part is implemented in CNG by causing BCryptDeriveKey to wipe the sup= plied shared secret.

--_000_4E1F6AAD24975D4BA5B1680429673943667470AATK5EX14MBXC285r_-- From Michael.Jones@microsoft.com Fri Jul 27 15:49:33 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F66411E80F4 for ; Fri, 27 Jul 2012 15:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.79 X-Spam-Level: X-Spam-Status: No, score=-3.79 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HCKEPUIyXaF for ; Fri, 27 Jul 2012 15:49:32 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 03DA511E8098 for ; Fri, 27 Jul 2012 15:49:31 -0700 (PDT) Received: from mail40-am1-R.bigfish.com (10.3.201.246) by AM1EHSOBE008.bigfish.com (10.3.204.28) with Microsoft SMTP Server id 14.1.225.23; Fri, 27 Jul 2012 22:49:30 +0000 Received: from mail40-am1 (localhost [127.0.0.1]) by mail40-am1-R.bigfish.com (Postfix) with ESMTP id 147581E02AA for ; Fri, 27 Jul 2012 22:49:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VS-20(zzc85fhzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail40-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail40-am1 (localhost.localdomain [127.0.0.1]) by mail40-am1 (MessageSwitch) id 1343429369689619_30410; Fri, 27 Jul 2012 22:49:29 +0000 (UTC) Received: from AM1EHSMHS018.bigfish.com (unknown [10.3.201.244]) by mail40-am1.bigfish.com (Postfix) with ESMTP id A62821C007D for ; Fri, 27 Jul 2012 22:49:29 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS018.bigfish.com (10.3.207.156) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 27 Jul 2012 22:49:29 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0309.003; Fri, 27 Jul 2012 22:49:27 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Open Issue: Representing the JWE IV as a dot-separated element Thread-Index: Ac1sShLZvlTbc+2LTtW27U8yfEpgwg== Date: Fri, 27 Jul 2012 22:49:26 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943667470E7@TK5EX14MBXC285.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943667470E7TK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [jose] Open Issue: Representing the JWE IV as a dot-separated element X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 22:49:33 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943667470E7TK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All the JWE block encryption algorithms we're using require an Initializati= on Vector. I'd originally put the IV in the JWE header because I thought i= t would be optional, but in practice, it's not. As a result, we're always = double base64url encoding required content. I did an investigation and we could save 15 characters in the GCM example a= t http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-04#section= -3.1 and 17 characters in the CBC example at http://tools.ietf.org/html/dra= ft-ietf-jose-json-web-encryption-04#section-3.2 if we were to represent the= IV as another dot-separated element rather than putting it in the header a= nd double base64url encoding it. Since size matters a lot in some use cases, we should consider whether to d= o this. I'll add it to the open issues list for us to discuss in Vancouver. -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943667470E7TK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All the JWE block encryption algorithms we’re = using require an Initialization Vector.  I’d originally put the = IV in the JWE header because I thought it would be optional, but in practic= e, it’s not.  As a result, we’re always double base64url encoding required content.

 

I did an investigation and we could save 15 characte= rs in the GCM example at http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-04#section-3= .1 and 17 characters in the CBC example at http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-04#section-3= .2 if we were to represent the IV as another dot-separated element rath= er than putting it in the header and double base64url encoding it.

 

Since size matters a lot in some use cases, we shoul= d consider whether to do this.

 

I’ll add it to the open issues list for us to = discuss in Vancouver.

 

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943667470E7TK5EX14MBXC285r_-- From Michael.Jones@microsoft.com Fri Jul 27 17:09:49 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D46011E8104 for ; Fri, 27 Jul 2012 17:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=-1.555, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock9=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLXG3D6pdLFN for ; Fri, 27 Jul 2012 17:09:47 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC1911E80BA for ; Fri, 27 Jul 2012 17:09:47 -0700 (PDT) Received: from mail160-ch1-R.bigfish.com (10.43.68.228) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.23; Sat, 28 Jul 2012 00:09:47 +0000 Received: from mail160-ch1 (localhost [127.0.0.1]) by mail160-ch1-R.bigfish.com (Postfix) with ESMTP id 3AC52360224 for ; Sat, 28 Jul 2012 00:09:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VS-1(zz9371Ic85fhzz1202hzz8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail160-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail160-ch1 (localhost.localdomain [127.0.0.1]) by mail160-ch1 (MessageSwitch) id 1343434185283779_446; Sat, 28 Jul 2012 00:09:45 +0000 (UTC) Received: from CH1EHSMHS037.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.234]) by mail160-ch1.bigfish.com (Postfix) with ESMTP id 43419420046 for ; Sat, 28 Jul 2012 00:09:45 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS037.bigfish.com (10.43.69.246) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 28 Jul 2012 00:09:45 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0309.003; Sat, 28 Jul 2012 00:09:44 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Blind JWE RSA-OAEP/AES-GSM decryption test Thread-Index: Ac1sVPMHyYZd3jpIRt6YGPI0CIWp4AAAEG9A Date: Sat, 28 Jul 2012 00:09:43 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366747460@TK5EX14MBXC285.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366747460TK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [jose] FW: Blind JWE RSA-OAEP/AES-GSM decryption test X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 00:09:49 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366747460TK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In case any of you want to give it a try... From: Mike Jones Sent: Friday, July 27, 2012 5:07 PM To: openid-connect-interop@googlegroups.com Subject: Blind JWE RSA-OAEP/AES-GSM decryption test Now that I've finally found the bug in my GCM code, let's try this again...= Can you decrypt the following JWE and tell me the plaintext value? eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6Il9fNzlfUHY2LWZqMzl2WDA= ifQ.LX4rQictZUJSYrVH3-TmCeH08qlpMrbFpKhEBVyAFX6h4V3Xt6omuTyMmkeiMIR6gbkn9ww= 4A0xDRnRu2GuM-v30Ri6OHx04fP1l1osYRngALuzMplcreyFCErm5asXTghweg_oI2y6ffhgR8P= 0ONWSlv0Bg-y58nAiNMi9Z51P42sx1f2JknAhG_oJ2u4Dy-6xY3tWCS4hXolMt5NMZm1dUN56RK= vGlp-nspa9mYONfV-CITnjA3zMVWGdpTF4SXNq0fK5gWM3CgxJEtuW1gk69q9k_zOAEqCph_urn= x0T7_6ZaBa90nV3TvX0cC5bq75alEqGWkqJLwTMsEnAg-A.ykqmBHvu8Yhqf5jafmUKcgDY8kZ0= vw._3cYrFHM7X640lLd_QoUKw BEGIN RSA KEY PARAMETERS Exponent [1, 0, 1] Modulus [152, 66, 27, 221, 242, 12, 205, 109, 3, 3, 73, 191, 7, 43, 214, 144, 254, 253, 173, 139, 211, 33, 139, 34, 95, 176, 106, 246, 5, 176, 94, 78, 150, 102, 87, 240, 113, 118, 40, 137, 1, 245, 201, 181, 133, 9, 175, 161, 119, 134, 19, 81, 38, 21, 100, 25, 214, 68, 37, 66, 189, 149, 75, 143, 148, 24, 249, 69, 38, 236, 119, 81, 118, 149, 244, 115, 242, 43, 3, 90, 107, 238, 42, 3, 9, 90, 173, 192, 72, 175, 165, 17, 77, 92, 175, 8, 22, 252, 201, 168, 30, 109, 167, 12, 23, 56, 114, 122, 217, 30, 241, 127, 233, 130, 119, 100, 190, 121, 77, 95, 106, 107, 109, 19, 5, 103, 110, 0, 208, 248, 166, 68, 213, 22, 203, 25, 50, 35, 207, 165, 188, 185, 62, 103, 164, 45, 172, 183, 49, 132, 72, 72, 159, 223, 180, 22, 157, 253, 197, 185, 77, 67, 236, 72, 99, 14, 155, 255, 100, 159, 208, 199, 50, 4, 232, 132, 147, 61, 84, 150, 56, 13, 109, 17, 6, 247, 76, 172, 122, 185, 142, 120, 207, 117, 90, 94, 96, 161, 216, 2, 221, 17, 89, 107, 229, 214, 154, 97, 2, 17, 14, 222, 116, 61, 249, 198, 194, 55, 187, 13, 243, 34, 151, 65, 197, 17, 145, 225, 124, 238, 155, 235, 84, 192, 107, 107, 118, 185, 67, 196= , 4, 75, 15, 89, 140, 30, 169, 51, 94, 160, 20, 98, 153, 156, 216, 51] D (private key exponent) [107, 210, 84, 253, 165, 77, 95, 164, 21, 0, 29, 23, 68, 50, 205, 45, 189, 5, 84, 2, 178, 175, 12, 98, 121, 52, 235, 105, 241, 185, 101, 239, 109, 30, 104, 164, 3, 21, 83, 187, 66, 66, 22, 103, 143, 32, 190, 217, 47, 85, 41, 20, 204, 77, 85, 167, 222, 78, 63, 188, 181, 152, 165, 251, 181, 58, 194, 59, 48, 71, 64, 111, 213, 244, 119, 58, 44, 130, 61, 75, 169, 38, 237, 101, 93, 24, 115, 246, 185, 2, 121, 120, 121, 58, 107, 80, 229, 70, 122, 95, 173, 188, 165, 17, 48, 216, 110, 105, 132, 156, 31, 21, 31, 253, 158, 35, 31, 167, 179, 29, 32, 181, 150, 118, 99, 219, 76, 207, 251, 137, 174, 83, 77, 177, 19, 244, 49, 154, 248, 255, 112, 107, 231, 233, 96, 24, 96, 218, 77, 28, 47, 208, 75, 221, 69, 210, 226, 175, 61, 65, 106, 13, 8, 127, 96, 188, 205, 210, 251, 101, 176, 46, 22, 245, 249, 13, 174, 22, 109, 117, 255, 141, 126, 39, 90, 231, 44, 51, 49, 54, 95, 99, 149, 61, 238, 4, 17, 48, 239, 76, 198, 16, 193, 252, 160, 213, 155, 98, 51, 21, 155, 203, 163, 238, 112, 23, 29, 231, 76, 141, 93, 115, 91, 83, 103, 66, 110, 227, 188, 231, 105, 78, 23, 172, 126, 196, 130, 181, 226, 214= , 178, 46, 56, 1, 181, 180, 154, 182, 80, 186, 154, 158, 79, 15, 177, 65] Good luck! -- Mike --_000_4E1F6AAD24975D4BA5B168042967394366747460TK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In case any of you wan= t to give it a try…

 

From: Mike Jon= es
Sent: Friday, July 27, 2012 5:07 PM
To: openid-connect-interop@googlegroups.com
Subject: Blind JWE RSA-OAEP/AES-GSM decryption test

 

Now that I’ve finally found the bug in my GCM = code, let’s try this again…  Can you decrypt the following= JWE and tell me the plaintext value?

 

eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00iLCJpdiI6= Il9fNzlfUHY2LWZqMzl2WDAifQ.LX4rQictZUJSYrVH3-TmCeH08qlpMrbFpKhEBVyAFX6h4V3X= t6omuTyMmkeiMIR6gbkn9ww4A0xDRnRu2GuM-v30Ri6OHx04fP1l1osYRngALuzMplcreyFCErm= 5asXTghweg_oI2y6ffhgR8P0ONWSlv0Bg-y58nAiNMi9Z51P42sx1f2JknAhG_oJ2u4Dy-6xY3t= WCS4hXolMt5NMZm1dUN56RKvGlp-nspa9mYONfV-CITnjA3zMVWGdpTF4SXNq0fK5gWM3CgxJEt= uW1gk69q9k_zOAEqCph_urnx0T7_6ZaBa90nV3TvX0cC5bq75alEqGWkqJLwTMsEnAg-A.ykqmB= Hvu8Yhqf5jafmUKcgDY8kZ0vw._3cYrFHM7X640lLd_QoUKw

 

BEGIN RSA KEY PARAMETERS

Exponent

[1, 0, 1]

Modulus

[152, 66, 27, 221, 242, 12, 205, 109, 3, 3, 73, 191,= 7, 43, 214, 144,

254, 253, 173, 139, 211, 33, 139, 34, 95, 176, 106, = 246, 5, 176, 94, 78,

150, 102, 87, 240, 113, 118, 40, 137, 1, 245, 201, 1= 81, 133, 9, 175, 161,

119, 134, 19, 81, 38, 21, 100, 25, 214, 68, 37, 66, = 189, 149, 75, 143,

148, 24, 249, 69, 38, 236, 119, 81, 118, 149, 244, 1= 15, 242, 43, 3, 90,

107, 238, 42, 3, 9, 90, 173, 192, 72, 175, 165, 17, = 77, 92, 175, 8,

22, 252, 201, 168, 30, 109, 167, 12, 23, 56, 114, 12= 2, 217, 30, 241, 127,

233, 130, 119, 100, 190, 121, 77, 95, 106, 107, 109,= 19, 5, 103, 110, 0,

208, 248, 166, 68, 213, 22, 203, 25, 50, 35, 207, 16= 5, 188, 185, 62, 103,

164, 45, 172, 183, 49, 132, 72, 72, 159, 223, 180, 2= 2, 157, 253, 197, 185,

77, 67, 236, 72, 99, 14, 155, 255, 100, 159, 208, 19= 9, 50, 4, 232, 132,

147, 61, 84, 150, 56, 13, 109, 17, 6, 247, 76, 172, = 122, 185, 142, 120,

207, 117, 90, 94, 96, 161, 216, 2, 221, 17, 89, 107,= 229, 214, 154, 97,

2, 17, 14, 222, 116, 61, 249, 198, 194, 55, 187, 13,= 243, 34, 151, 65,

197, 17, 145, 225, 124, 238, 155, 235, 84, 192, 107,= 107, 118, 185, 67, 196,

4, 75, 15, 89, 140, 30, 169, 51, 94, 160, 20, 98, 15= 3, 156, 216, 51]

D (private key exponent)

[107, 210, 84, 253, 165, 77, 95, 164, 21, 0, 29, 23,= 68, 50, 205, 45,

189, 5, 84, 2, 178, 175, 12, 98, 121, 52, 235, 105, = 241, 185, 101, 239,

109, 30, 104, 164, 3, 21, 83, 187, 66, 66, 22, 103, = 143, 32, 190, 217,

47, 85, 41, 20, 204, 77, 85, 167, 222, 78, 63, 188, = 181, 152, 165, 251,

181, 58, 194, 59, 48, 71, 64, 111, 213, 244, 119, 58= , 44, 130, 61, 75,

169, 38, 237, 101, 93, 24, 115, 246, 185, 2, 121, 12= 0, 121, 58, 107, 80,

229, 70, 122, 95, 173, 188, 165, 17, 48, 216, 110, 1= 05, 132, 156, 31, 21,

31, 253, 158, 35, 31, 167, 179, 29, 32, 181, 150, 11= 8, 99, 219, 76, 207,

251, 137, 174, 83, 77, 177, 19, 244, 49, 154, 248, 2= 55, 112, 107, 231, 233,

96, 24, 96, 218, 77, 28, 47, 208, 75, 221, 69, 210, = 226, 175, 61, 65,

106, 13, 8, 127, 96, 188, 205, 210, 251, 101, 176, 4= 6, 22, 245, 249, 13,

174, 22, 109, 117, 255, 141, 126, 39, 90, 231, 44, 5= 1, 49, 54, 95, 99,

149, 61, 238, 4, 17, 48, 239, 76, 198, 16, 193, 252,= 160, 213, 155, 98,

51, 21, 155, 203, 163, 238, 112, 23, 29, 231, 76, 14= 1, 93, 115, 91, 83,

103, 66, 110, 227, 188, 231, 105, 78, 23, 172, 126, = 196, 130, 181, 226, 214,

178, 46, 56, 1, 181, 180, 154, 182, 80, 186, 154, 15= 8, 79, 15, 177, 65]

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     Good luck!

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

 

--_000_4E1F6AAD24975D4BA5B168042967394366747460TK5EX14MBXC285r_-- From ietf@augustcellars.com Fri Jul 27 17:55:33 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC34021F84A0 for ; Fri, 27 Jul 2012 17:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVLtjEEMg+Ox for ; Fri, 27 Jul 2012 17:55:33 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 5D14621F849D for ; Fri, 27 Jul 2012 17:55:33 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 0C16138F0C; Fri, 27 Jul 2012 17:55:32 -0700 (PDT) From: "Jim Schaad" To: "'Manger, James H'" , References: <82F6AE16-F7D7-4733-863B-DE0776D84809@team.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F8073950@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F80F4DD0@WSMSG3153V.srv.dir.telstra.com> <023301cd6bb2$22220ce0$666626a0$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F80F53B8@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F80F53B8@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 27 Jul 2012 17:54:08 -0700 Message-ID: <02dd01cd6c5b$7eebaa90$7cc2ffb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJiWfhm9ifvIrHdrYH/+rlKaFz2cwIo0LhCAcFXkmECkyfjMAKuSqqTAUvDaGwBsqY1lgIE+V3mlaKJe4A= Content-Language: en-us Subject: Re: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 00:55:34 -0000 > -----Original Message----- > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > Sent: Friday, July 27, 2012 12:31 AM > To: Jim Schaad; jose@ietf.org > Subject: RE: [jose] MUST understand ALL header fields >=20 > > > > An extension mechanism would define: > > > > > > > > - How to bundle fields of an extension as a single object. > > > > - How to indicate that this object is an extension, and whether > > > > the > > > extension is critical (can't be safely ignored) or not. >=20 > > > If we support extensibility with per-extension criticality flags, > > > wouldn't it be almost as inevitable that an extension will be = added > > > that shouldn't be ignored but is marked non-critical to not break > > > interop? Or do you think people will "do the right thing (not the > > > easy thing)" with criticality flags? >=20 > > Anyone who believes this to be a true statement is more than welcome > > to read the current firestorm about name constraints on the PKIX > > mailing list. They were defined and said to be critical when the > > first draft > > (RFC2459) came out in 1999 and people are saying that they need to > > make it non-critical because too many people did not implement it. > > The JOSE documents are better in that there are not as many = "extensions" > > defined. But the history is still there. >=20 >=20 > Jim, >=20 > What is you conclusion for JOSE s "MUST understand everything" rule = from > the critical name constraints firestorm? >=20 > My conclusion is that the criticality of name constraints has = prevented its > widescale deployment for a decade -- so internet security has = suffered. A > "MUST understand everything" rule in JOSE will similarly freeze its > functionality, preventing security improvements. My conclusion on the name constraints issues is that it was correctly = defined as being critical by the specification; however nobody = understood why they would ever need it so it was never implemented. = This means that nobody today can roll out using the name criticality = functionality that should have been there from the start. My personal opinion on the "MUST understand everything" rule is that we = are looking at the wrong place for making this statement. The correct = statement is really that a library implementing the JW* documents needs = to return a set of fields that it either 1) used in processing the = document or 2) would have used in processing the document and it is up = to the application (i.e. JWT) to decide if any given field is either = mandatory, optional or required to be present. This punts the problem from the process library which would not know how = to deal with application specific items (i.e. the application would need = to pass in a complete list of everything under the sun that it could = possible permit being there) and moves it to where it makes sense - the = application. This is the basic position that is espoused by the CMS documents. We = can validate a signature and will use some items, but the rest are left = up to the interpretation of the application for both what they mean and = if they need to be there or need to be absent. The default being that = one ignores what one does not care about for most applications but not = all. Jim >=20 > -- > James Manger From ietf@augustcellars.com Fri Jul 27 17:57:05 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8766721F84A5 for ; Fri, 27 Jul 2012 17:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.537 X-Spam-Level: X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HI1xwtxSMWbs for ; Fri, 27 Jul 2012 17:57:03 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 41E2621F84A0 for ; Fri, 27 Jul 2012 17:57:03 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 8174E2CA43; Fri, 27 Jul 2012 17:57:02 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , References: <4E1F6AAD24975D4BA5B1680429673943667470AA@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943667470AA@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Fri, 27 Jul 2012 17:55:35 -0700 Message-ID: <02de01cd6c5b$b4522b00$1cf68100$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02DF_01CD6C21.07F63930" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGt0mXdUrcIDZhiTmfodFU0hlBe2Jd9EoLw Content-Language: en-us Subject: Re: [jose] Open Issue: Multiple uses of the Concat KDF with the same secret X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 00:57:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02DF_01CD6C21.07F63930 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Where did he get this idea? This is very common practice in many protocols Jim From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Friday, July 27, 2012 3:44 PM To: jose@ietf.org Subject: [jose] Open Issue: Multiple uses of the Concat KDF with the same secret In conversations during this week's W3C WebCrypto F2F, Vijay Bharadwaj pointed out that using the same input secret to the Concat KDF twice, as we currently do in JWA 4.12 http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-04#page-16, is prohibited. Rather than using two different labels with the same secret as TLS does (in our case "Encryption" and "Integrity"), we're supposed to generate enough key bits for both keys in one operation. I'll add this to the set of Open Issues for us to discuss next week. Looking forward to seeing many of you then! -- Mike P.S. BTW, the W3C WebCrypto WG wants to closely coordinate with JOSE, in part, to ensure that the WebCrypto output - a set of JavaScript crypto APIs - will be a great way to build JOSE implementations. From: Vijay Bharadwaj Sent: Tuesday, July 24, 2012 8:52 PM To: Mike Jones Subject: Key derivation and FIPS The restriction I was talking about is in Section 5.8 of SP 800-56A : An Approved key derivation function (KDF) shall be used to derive secret keying material from a shared secret. The output from a KDF shall only be used for secret keying material, such as a symmetric key used for data encryption or message integrity, a secret initialization vector, or a master key that will be used to generate other keys (possibly using a different process). Non- secret keying material (such as a non-secret initialization vector) shall not be generated using the shared secret. Each call to the KDF requires a freshly computed shared secret, and this shared secret shall be zeroized immediately following its use. The derived secret keying material shall be computed in its entirety before outputting any portion of it. In schemes using only static keys, the freshly computed shared secret may be the same as the previous shared secret. In these cases, the initiator supplied nonce (NonceU, see Section 6.3) used in the scheme will vary so the same keying material is not regenerated. The derived secret keying material may be parsed into one or more keys or other secret cryptographic keying material (for example, secret initialization vectors). If Key Confirmation (KC) or implementation validation testing are to be performed as specified in Section 8 or Section 5.2.3, respectively, then the MAC key shall be formed from the first bits of the KDF output and zeroized after its use (i.e., the MAC key shall not be used for purposes other than key confirmation or implementation validation testing). So as you can see, NIST pretty clearly advocates for the "generate a bunch of bits and chop them up" approach. The first part is implemented in CNG by causing BCryptDeriveKey to wipe the supplied shared secret. ------=_NextPart_000_02DF_01CD6C21.07F63930 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Where did he get this idea?  This is very = common practice in many protocols

 

Jim

 

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Mike Jones
Sent: Friday, July 27, 2012 3:44 = PM
To: jose@ietf.org
Subject: [jose] Open Issue: = Multiple uses of the Concat KDF with the same = secret

 

In conversations during this week’s W3C = WebCrypto F2F, Vijay Bharadwaj pointed out that using the same input = secret to the Concat KDF twice, as we currently do in JWA 4.12 http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-= 04#page-16, is prohibited.  Rather than using two different = labels with the same secret as TLS does (in our case = “Encryption” and “Integrity”), we’re = supposed to generate enough key bits for both keys in one = operation.

 

I’ll add this to = the set of Open Issues for us to discuss next week.  Looking = forward to seeing many of you then!

 

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

 

P.S.  BTW, the W3C = WebCrypto WG wants to closely coordinate with JOSE, in part, to ensure = that the WebCrypto output – a set of JavaScript crypto APIs = – will be a great way to build JOSE = implementations.

 

From:= = Vijay Bharadwaj
Sent: Tuesday, July 24, 2012 8:52 = PM
To: Mike Jones
Subject: Key derivation and = FIPS

 

The = restriction I was talking about is in Section 5.8 of SP 800-56A:

 

An Approved key derivation function (KDF) = shall be used to derive secret keying material from a shared secret. The = output from a KDF shall only be used for secret keying material, such as = a symmetric key used for data encryption or message integrity, a secret = initialization vector, or a master key that will be used to generate = other keys (possibly using a different process). Non- secret keying = material (such as a non-secret initialization vector) shall not be = generated using the shared secret.

 

Each call to the KDF = requires a freshly computed shared secret, and this shared secret shall = be zeroized immediately following its use. The derived secret keying = material shall be computed in its entirety before outputting any portion = of it. In schemes using only static keys, the freshly computed = shared secret may be the same as the previous shared secret. In these = cases, the initiator supplied nonce (NonceU, see Section 6.3) used in = the scheme will vary so the same keying material is not regenerated. =

 

The derived secret = keying material may be parsed into one or more keys or other secret = cryptographic keying material (for example, secret initialization = vectors). If Key Confirmation (KC) or implementation validation = testing are to be performed as specified in Section 8 or Section 5.2.3, = respectively, then the MAC key shall be formed from the first bits of = the KDF output and zeroized after its use (i.e., the MAC key shall not = be used for purposes other than key confirmation or implementation = validation testing).

 

So as you = can see, NIST pretty clearly advocates for the “generate a bunch = of bits and chop them up” approach. The first part is implemented = in CNG by causing BCryptDeriveKey to wipe the supplied shared = secret.

------=_NextPart_000_02DF_01CD6C21.07F63930-- From Michael.Jones@microsoft.com Fri Jul 27 18:01:56 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DB911E8108 for ; Fri, 27 Jul 2012 18:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.276 X-Spam-Level: X-Spam-Status: No, score=-6.276 tagged_above=-999 required=5 tests=[AWL=2.322, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzdILeIiJ1cX for ; Fri, 27 Jul 2012 18:01:53 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 25A5011E8086 for ; Fri, 27 Jul 2012 18:01:53 -0700 (PDT) Received: from mail225-va3-R.bigfish.com (10.7.14.235) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Sat, 28 Jul 2012 01:01:52 +0000 Received: from mail225-va3 (localhost [127.0.0.1]) by mail225-va3-R.bigfish.com (Postfix) with ESMTP id 907E05C0441; Sat, 28 Jul 2012 01:01:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VS-27(zz9371Ic85fhzz1202hzz1033IL8275bh30d1K8275dh5eeeKz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail225-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail225-va3 (localhost.localdomain [127.0.0.1]) by mail225-va3 (MessageSwitch) id 1343437310583220_3822; Sat, 28 Jul 2012 01:01:50 +0000 (UTC) Received: from VA3EHSMHS009.bigfish.com (unknown [10.7.14.247]) by mail225-va3.bigfish.com (Postfix) with ESMTP id 82EC0880046; Sat, 28 Jul 2012 01:01:50 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS009.bigfish.com (10.7.99.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 28 Jul 2012 01:01:50 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0309.003; Sat, 28 Jul 2012 01:01:49 +0000 From: Mike Jones To: Jim Schaad , "jose@ietf.org" Thread-Topic: [jose] Open Issue: Multiple uses of the Concat KDF with the same secret Thread-Index: Ac1sXJBAY8r+9ELFR5Gc9g+BmG1LbQ== Date: Sat, 28 Jul 2012 01:01:47 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366747536@TK5EX14MBXC285.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366747536TK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] Open Issue: Multiple uses of the Concat KDF with the same secret X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 01:01:56 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366747536TK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable He's quoting from the NIST spec in which Concat is defined below. I realiz= e that our usage is common practice and I suspect there's no actual problem= with it, but given it violates the letter of the spec in which Concat is d= efined, I felt that I needed to at least bring the issue to the attention o= f the working group so that we can make an informed decision. -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Friday, July 27, 2012 5:56 PM To: Mike Jones; jose@ietf.org Subject: RE: [jose] Open Issue: Multiple uses of the Concat KDF with the sa= me secret Where did he get this idea? This is very common practice in many protocols Jim From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Mike Jone= s Sent: Friday, July 27, 2012 3:44 PM To: jose@ietf.org Subject: [jose] Open Issue: Multiple uses of the Concat KDF with the same s= ecret In conversations during this week's W3C WebCrypto F2F, Vijay Bharadwaj poin= ted out that using the same input secret to the Concat KDF twice, as we cur= rently do in JWA 4.12 http://tools.ietf.org/html/draft-ietf-jose-json-web-a= lgorithms-04#page-16, is prohibited. Rather than using two different label= s with the same secret as TLS does (in our case "Encryption" and "Integrity= "), we're supposed to generate enough key bits for both keys in one operati= on. I'll add this to the set of Open Issues for us to discuss next week. Looki= ng forward to seeing many of you then! -- Mike P.S. BTW, the W3C WebCrypto WG wants to closely coordinate with JOSE, in p= art, to ensure that the WebCrypto output - a set of JavaScript crypto APIs = - will be a great way to build JOSE implementations. From: Vijay Bharadwaj Sent: Tuesday, July 24, 2012 8:52 PM To: Mike Jones Subject: Key derivation and FIPS The restriction I was talking about is in Section 5.8 of SP 800-56A: An Approved key derivation function (KDF) shall be used to derive secret ke= ying material from a shared secret. The output from a KDF shall only be use= d for secret keying material, such as a symmetric key used for data encrypt= ion or message integrity, a secret initialization vector, or a master key t= hat will be used to generate other keys (possibly using a different process= ). Non- secret keying material (such as a non-secret initialization vector)= shall not be generated using the shared secret. Each call to the KDF requires a freshly computed shared secret, and this sh= ared secret shall be zeroized immediately following its use. The derived se= cret keying material shall be computed in its entirety before outputting an= y portion of it. In schemes using only static keys, the freshly computed sh= ared secret may be the same as the previous shared secret. In these cases, = the initiator supplied nonce (NonceU, see Section 6.3) used in the scheme w= ill vary so the same keying material is not regenerated. The derived secret keying material may be parsed into one or more keys or o= ther secret cryptographic keying material (for example, secret initializati= on vectors). If Key Confirmation (KC) or implementation validation testing = are to be performed as specified in Section 8 or Section 5.2.3, respectivel= y, then the MAC key shall be formed from the first bits of the KDF output a= nd zeroized after its use (i.e., the MAC key shall not be used for purposes= other than key confirmation or implementation validation testing). So as you can see, NIST pretty clearly advocates for the "generate a bunch = of bits and chop them up" approach. The first part is implemented in CNG by= causing BCryptDeriveKey to wipe the supplied shared secret. --_000_4E1F6AAD24975D4BA5B168042967394366747536TK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

He’s quoting fro= m the NIST spec in which Concat is defined below.  I realize that our = usage is common practice and I suspect there’s no actual problem with= it, but given it violates the letter of the spec in which Concat is defined, I felt that I needed to at least bring the issue = to the attention of the working group so that we can make an informed decis= ion.

 

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

 

From: Jim Scha= ad [mailto:ietf@augustcellars.com]
Sent: Friday, July 27, 2012 5:56 PM
To: Mike Jones; jose@ietf.org
Subject: RE: [jose] Open Issue: Multiple uses of the Concat KDF with= the same secret

 

Where did he get this = idea?  This is very common practice in many protocols

 

Jim<= /p>

 

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, July 27, 2012 3:44 PM
To: jose@ietf.org
Subject: [jose] Open Issue: Multiple uses of the Concat KDF with the= same secret

 

In conversations durin= g this week’s W3C WebCrypto F2F, Vijay Bharadwaj pointed out that usi= ng the same input secret to the Concat KDF twice, as we currently do in JWA= 4.12 http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-04#page-16, is prohibited.  Rather than using two different labels with the sa= me secret as TLS does (in our case “Encryption” and “Inte= grity”), we’re supposed to generate enough key bits for both keys in one operation.

 

I’ll add this to= the set of Open Issues for us to discuss next week.  Looking forward = to seeing many of you then!

 

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

 

P.S.  BTW, the W3= C WebCrypto WG wants to closely coordinate with JOSE, in part, to ensure th= at the WebCrypto output – a set of JavaScript crypto APIs – wil= l be a great way to build JOSE implementations.

 

From: Vijay Bh= aradwaj
Sent: Tuesday, July 24, 2012 8:52 PM
To: Mike Jones
Subject: Key derivation and FIPS

 

The restriction I was talking about is in Section 5.= 8 of SP 800-56A:

 

An Approved key derivatio= n function (KDF) shall be used to derive secret keying material from a shar= ed secret. The output from a KDF shall only be used for secret keying mater= ial, such as a symmetric key used for data encryption or message integrity, a secret initialization vector, or a= master key that will be used to generate other keys (possibly using a diff= erent process). Non- secret keying material (such as a non-secret initializ= ation vector) shall not be generated using the shared secret.

 

Each call to the KDF requires a freshly compu= ted shared secret, and this shared secret shall be zeroized immediately fol= lowing its use. The derived secret keying material shall be computed in its entirety before outputting any portion o= f it. In schemes using only static keys, the freshly computed shared= secret may be the same as the previous shared secret. In these cases, the = initiator supplied nonce (NonceU, see Section 6.3) used in the scheme will vary so the same keying material = is not regenerated.

 

The derived secret keying material may be par= sed into one or more keys or other secret cryptographic keying material (fo= r example, secret initialization vectors). If Key Confirmation (KC) or implementation validation testing are to be pe= rformed as specified in Section 8 or Section 5.2.3, respectively, then the = MAC key shall be formed from the first bits of the KDF output and zeroized = after its use (i.e., the MAC key shall not be used for purposes other than key confirmation or implementati= on validation testing).

 

So as you can see, NIST pretty clearly advocates for= the “generate a bunch of bits and chop them up” approach. The = first part is implemented in CNG by causing BCryptDeriveKey to wipe the sup= plied shared secret.

--_000_4E1F6AAD24975D4BA5B168042967394366747536TK5EX14MBXC285r_-- From ietf@augustcellars.com Fri Jul 27 18:14:41 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D2B11E8117 for ; Fri, 27 Jul 2012 18:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.24 X-Spam-Level: X-Spam-Status: No, score=-4.24 tagged_above=-999 required=5 tests=[AWL=0.758, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcvHd4ckqYkb for ; Fri, 27 Jul 2012 18:14:38 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id A398B11E80D1 for ; Fri, 27 Jul 2012 18:14:38 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 2F52438F0F; Fri, 27 Jul 2012 18:14:37 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , References: <4E1F6AAD24975D4BA5B168042967394366747536@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366747536@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Fri, 27 Jul 2012 18:13:12 -0700 Message-ID: <02e901cd6c5e$28ded430$7a9c7c90$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02EA_01CD6C23.7C82BB50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCCnnt9CXc9rokVK4VZx5cdYe0JMJnTftFQ Content-Language: en-us Subject: Re: [jose] Open Issue: Multiple uses of the Concat KDF with the same secret X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 01:14:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02EA_01CD6C23.7C82BB50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I believe that he is in error unless you are doing something that I don't understand. My understanding of the current specification is you do the following KA_Secret = EC(my private, their public, other data) CMK = KDF1(KA_Secret) CEK = KDF2(CMK, string) CIK = KDF2(CMK, string) This clearly does not violate what is said in the document. It states that KDF1 must always have a new set of input not KDF2. Jim From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, July 27, 2012 6:02 PM To: Jim Schaad; jose@ietf.org Subject: RE: [jose] Open Issue: Multiple uses of the Concat KDF with the same secret He's quoting from the NIST spec in which Concat is defined below. I realize that our usage is common practice and I suspect there's no actual problem with it, but given it violates the letter of the spec in which Concat is defined, I felt that I needed to at least bring the issue to the attention of the working group so that we can make an informed decision. -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Friday, July 27, 2012 5:56 PM To: Mike Jones; jose@ietf.org Subject: RE: [jose] Open Issue: Multiple uses of the Concat KDF with the same secret Where did he get this idea? This is very common practice in many protocols Jim From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Friday, July 27, 2012 3:44 PM To: jose@ietf.org Subject: [jose] Open Issue: Multiple uses of the Concat KDF with the same secret In conversations during this week's W3C WebCrypto F2F, Vijay Bharadwaj pointed out that using the same input secret to the Concat KDF twice, as we currently do in JWA 4.12 http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-04#page-16, is prohibited. Rather than using two different labels with the same secret as TLS does (in our case "Encryption" and "Integrity"), we're supposed to generate enough key bits for both keys in one operation. I'll add this to the set of Open Issues for us to discuss next week. Looking forward to seeing many of you then! -- Mike P.S. BTW, the W3C WebCrypto WG wants to closely coordinate with JOSE, in part, to ensure that the WebCrypto output - a set of JavaScript crypto APIs - will be a great way to build JOSE implementations. From: Vijay Bharadwaj Sent: Tuesday, July 24, 2012 8:52 PM To: Mike Jones Subject: Key derivation and FIPS The restriction I was talking about is in Section 5.8 of SP 800-56A : An Approved key derivation function (KDF) shall be used to derive secret keying material from a shared secret. The output from a KDF shall only be used for secret keying material, such as a symmetric key used for data encryption or message integrity, a secret initialization vector, or a master key that will be used to generate other keys (possibly using a different process). Non- secret keying material (such as a non-secret initialization vector) shall not be generated using the shared secret. Each call to the KDF requires a freshly computed shared secret, and this shared secret shall be zeroized immediately following its use. The derived secret keying material shall be computed in its entirety before outputting any portion of it. In schemes using only static keys, the freshly computed shared secret may be the same as the previous shared secret. In these cases, the initiator supplied nonce (NonceU, see Section 6.3) used in the scheme will vary so the same keying material is not regenerated. The derived secret keying material may be parsed into one or more keys or other secret cryptographic keying material (for example, secret initialization vectors). If Key Confirmation (KC) or implementation validation testing are to be performed as specified in Section 8 or Section 5.2.3, respectively, then the MAC key shall be formed from the first bits of the KDF output and zeroized after its use (i.e., the MAC key shall not be used for purposes other than key confirmation or implementation validation testing). So as you can see, NIST pretty clearly advocates for the "generate a bunch of bits and chop them up" approach. The first part is implemented in CNG by causing BCryptDeriveKey to wipe the supplied shared secret. ------=_NextPart_000_02EA_01CD6C23.7C82BB50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I believe that he is in error unless you are = doing something that I don’t understand.  My understanding of = the current specification is you do the = following

 

KA_Secret =3D EC(my = private, their public, other data)

CMK =3D = KDF1(KA_Secret)

CEK =3D KDF2(CMK, = string)

CIK =3D KDF2(CMK, = string)

 

This clearly does not = violate what is said in the document.  It states that KDF1 must = always have a new set of input not KDF2.

 

Jim

 

 

From:= = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Friday, = July 27, 2012 6:02 PM
To: Jim Schaad; = jose@ietf.org
Subject: RE: [jose] Open Issue: Multiple uses of = the Concat KDF with the same secret

 

He’s quoting from the NIST spec in which = Concat is defined below.  I realize that our usage is common = practice and I suspect there’s no actual problem with it, but = given it violates the letter of the spec in which Concat is defined, I = felt that I needed to at least bring the issue to the attention of the = working group so that we can make an informed = decision.

 

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

 

From:= = Jim Schaad [mailto:ietf@augustcellar= s.com]
Sent: Friday, July 27, 2012 5:56 PM
To: = Mike Jones; jose@ietf.org
Subject: RE: = [jose] Open Issue: Multiple uses of the Concat KDF with the same = secret

 

Where did he get this idea?  This is very = common practice in many protocols

 

Jim

 

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.= org] On Behalf Of Mike Jones
Sent: Friday, July 27, = 2012 3:44 PM
To: jose@ietf.org
Subject: = [jose] Open Issue: Multiple uses of the Concat KDF with the same = secret

 

In conversations during this week’s W3C = WebCrypto F2F, Vijay Bharadwaj pointed out that using the same input = secret to the Concat KDF twice, as we currently do in JWA 4.12 http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-= 04#page-16, is prohibited.  Rather than using two different = labels with the same secret as TLS does (in our case = “Encryption” and “Integrity”), we’re = supposed to generate enough key bits for both keys in one = operation.

 

I’ll add this to = the set of Open Issues for us to discuss next week.  Looking = forward to seeing many of you then!

 

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

 

P.S.  BTW, the W3C = WebCrypto WG wants to closely coordinate with JOSE, in part, to ensure = that the WebCrypto output – a set of JavaScript crypto APIs = – will be a great way to build JOSE = implementations.

 

From:= = Vijay Bharadwaj
Sent: Tuesday, July 24, 2012 8:52 = PM
To: Mike Jones
Subject: Key derivation and = FIPS

 

The = restriction I was talking about is in Section 5.8 of SP 800-56A:

 

An Approved key derivation function (KDF) = shall be used to derive secret keying material from a shared secret. The = output from a KDF shall only be used for secret keying material, such as = a symmetric key used for data encryption or message integrity, a secret = initialization vector, or a master key that will be used to generate = other keys (possibly using a different process). Non- secret keying = material (such as a non-secret initialization vector) shall not be = generated using the shared secret.

 

Each call to the KDF = requires a freshly computed shared secret, and this shared secret shall = be zeroized immediately following its use. The derived secret keying = material shall be computed in its entirety before outputting any portion = of it. In schemes using only static keys, the freshly computed = shared secret may be the same as the previous shared secret. In these = cases, the initiator supplied nonce (NonceU, see Section 6.3) used in = the scheme will vary so the same keying material is not regenerated. =

 

The derived secret = keying material may be parsed into one or more keys or other secret = cryptographic keying material (for example, secret initialization = vectors). If Key Confirmation (KC) or implementation validation = testing are to be performed as specified in Section 8 or Section 5.2.3, = respectively, then the MAC key shall be formed from the first bits of = the KDF output and zeroized after its use (i.e., the MAC key shall not = be used for purposes other than key confirmation or implementation = validation testing).

 

So as you = can see, NIST pretty clearly advocates for the “generate a bunch = of bits and chop them up” approach. The first part is implemented = in CNG by causing BCryptDeriveKey to wipe the supplied shared = secret.

------=_NextPart_000_02EA_01CD6C23.7C82BB50-- From Michael.Jones@microsoft.com Fri Jul 27 20:02:09 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3D911E8137 for ; Fri, 27 Jul 2012 20:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.794 X-Spam-Level: X-Spam-Status: No, score=-3.794 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CejmL7s8x62 for ; Fri, 27 Jul 2012 20:02:07 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 276F311E8132 for ; Fri, 27 Jul 2012 20:01:59 -0700 (PDT) Received: from mail227-ch1-R.bigfish.com (10.43.68.230) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.23; Sat, 28 Jul 2012 03:01:58 +0000 Received: from mail227-ch1 (localhost [127.0.0.1]) by mail227-ch1-R.bigfish.com (Postfix) with ESMTP id C108CBC007F for ; Sat, 28 Jul 2012 03:01:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VS0(zzc85fhzz1202hzz8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah34h) Received-SPF: pass (mail227-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail227-ch1 (localhost.localdomain [127.0.0.1]) by mail227-ch1 (MessageSwitch) id 1343444514649218_26417; Sat, 28 Jul 2012 03:01:54 +0000 (UTC) Received: from CH1EHSMHS018.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.254]) by mail227-ch1.bigfish.com (Postfix) with ESMTP id 9A2DF19C0045 for ; Sat, 28 Jul 2012 03:01:54 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS018.bigfish.com (10.43.70.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 28 Jul 2012 03:01:53 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0298.005; Sat, 28 Jul 2012 03:01:51 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Updated JWA algorithm support table Thread-Index: Ac1sbUqRoEGxbbpCSPS+1W0sPnhKKg== Date: Sat, 28 Jul 2012 03:01:50 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436674A117@TK5EX14MBXC285.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/mixed; boundary="_004_4E1F6AAD24975D4BA5B16804296739436674A117TK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [jose] Updated JWA algorithm support table X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 03:02:09 -0000 --_004_4E1F6AAD24975D4BA5B16804296739436674A117TK5EX14MBXC285r_ Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436674A117TK5EX14MBXC285r_" --_000_4E1F6AAD24975D4BA5B16804296739436674A117TK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New columns added for NSS and Windows native crypto, plus more data for OS = X and Ruby. Thanks to Nov Matake, Christopher Kula, Wan-Teh Chang, Ryan Sl= eevi, Vijay Bharadwaj, and Brian LaMacchia for the additional data. -- Mike Usage Param Name Param Val Description .NET Windows native OS X iOS Java JCA BouncyCastle Android PHP PHPSecLib Python M2Crypto PyCrypto Ruby OpenSSL node.js NSS JWS/JWE alg/int HS256 HMAC w/ SHA-256 hash YES XP SP2 YES YES YES YES YES YES YES YES YES YES YES YES YES YES JWS/JWE alg/int HS384 HMAC w/ SHA-384 hash YES XP SP2 YES YES YES YES YES YES YES YES YES YES YES YES YES YES JWS/JWE alg/int HS512 HMAC w/ SHA-512 hash YES XP SP2 YES YES YES YES YES YES YES YES YES YES YES YES YES YES JWS alg RS256 RSA w/ SHA-256 hash YES XP SP2 YES YES YES YES YES NO YES NO YES YES YES YES YES YES JWS alg RS384 RSA w/ SHA-384 hash YES XP SP2 YES YES YES YES YES NO YES NO YES YES YES YES YES YES JWS alg RS512 RSA w/ SHA-512 hash YES XP SP2 YES YES YES YES YES NO YES NO YES YES YES YES YES YES JWS alg ES256 ECDSA w/ P-256 curve and SHA-256 hash YES Vista 10.6 NO YES? YES YES NO NO NO YES NO YES VARIES VARIES? VARIES JWS alg ES384 ECDSA w/ P-384 curve and SHA-384 hash YES Vista 10.6 NO YES? YES YES NO NO NO YES NO YES VARIES VARIES? VARIES JWS alg ES512 ECDSA w/ P-521 curve and SHA-512 hash YES Vista 10.6 NO YES? YES YES NO NO NO YES NO YES VARIES VARIES? VARIES JWE alg RSA1_5 RSAES-PKCS1-V1_5 YES XP SP2 YES YES YES YES YES YES YES NO YES YES YES YES YES JWE alg RSA-OAEP RSAES OAEP YES XP SP2 YES? YES YES YES YES NO YES NO YES YES YES YES NO JWE alg ECDH-ES Elliptic Curve Diffie-Hellman Ephemeral Static NO* Vista NO? NO YES* YES* YES* NO NO NO YES? NO VARIES? VARIES? NO? JWE alg A128KW AES Key Wrap w/ 128 bit key NO Win7 YES YES YES YES NO NO NO YES YES YES? YES? NO JWE alg A256KW AES Key Wrap w/ 256 bit key NO Win7 YES YES YES YES NO NO NO YES YES YES? YES? NO JWE enc A128CBC AES CBC w/ 128 bit key YES* XP SP2 YES YES* YES* YES* YES* YES* NO YES* YES* YES* YES* YES* JWE enc A256CBC AES CBC w/ 256 bit key YES* XP SP2 YES YES* YES* YES* YES* YES* NO YES* YES* YES* YES* YES* JWE enc A128GCM AES GCM w/ 128 bit key Codeplex Vista SP1 NO? NO NO YES YES NO NO NO NO? NO YES YES NO JWE enc A256GCM AES GCM w/ 256 bit key Codeplex Vista SP1 NO? NO NO YES YES NO NO NO NO? NO YES YES NO JWE kdf CS256 Concat Key Derivation Function (KDF) NO Win7 NO NO NO NO NO NO NO NO NO NO NO JWE kdf CS384 Concat Key Derivation Function (KDF) NO Win7 NO NO NO NO NO NO NO NO NO NO NO JWE kdf CS512 Concat Key Derivation Function (KDF) NO Win7 NO NO NO NO NO NO NO NO NO NO NO YES - Support built into library/platform BouncyCastle is a crypto lib for Java Release - Support included in this release of software and later Android uses BouncyCastle YES* - Supported but other non-supported code required (Concat KDF) PHPSecLib is a crypto lib for PHP VARIES - In sources but often distributed w/ support compiled out M2Crypto is a crypto lib for Python NO - Not supported in library/platform PyCrypto is a crypto lib for Python NO* - Not supported in the specified configuration (w/ Concat KDF) NSS is the crypto lib used by Firefox (blank) - Unknown ? - Answer is a first impression but requires more research PHP version 5.2 PHPSecLib version 0.3.0 PyCrypto version 2.6 Ruby 1.9.3 with ruby-openssl Java 7 OS X 10.6 (Snow Leopard) --_000_4E1F6AAD24975D4BA5B16804296739436674A117TK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

New columns added for NSS and Windows native crypto,= plus more data for OS X and Ruby.  Thanks to Nov Matake, Christopher = Kula, Wan-Teh Chang, Ryan Sleevi, Vijay Bharadwaj, and Brian LaMacchia for = the additional data.

 

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

 

Usage

Param Name=

Param Val<= /span>

Description

.NET

Windows native

OS X

iOS=

Java JCA

BouncyCastle

Android

PHP=

PHPSecLib<= /span>

Python

M2Crypto

PyCrypto

Ruby

OpenSSL

node.js

NSS=

JWS/JWE

alg/int

HS256

HMAC w/ SHA-256 hash 

YES<= /p>

XP SP2

YES =

YES =

YES =

YES =

YES =

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

JWS/JWE

alg/int

HS384

HMAC w/ SHA-384 hash

YES<= /p>

XP SP2

YES<= /p>

YES =

YES =

YES =

YES =

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

JWS/JWE

alg/int

HS512

HMAC w/ SHA-512 hash

YES<= /p>

XP SP2

YES =

YES =

YES =

YES =

YES =

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

JWS

alg

RS256

RSA w/ SHA-256 hash

YES<= /p>

XP SP2

YES =

YES =

YES =

YES =

YES =

NO

YES<= /p>

NO

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

JWS

alg

RS384

RSA w/ SHA-384 hash 

YES<= /p>

XP SP2

YES =

YES =

YES =

YES =

YES =

NO

YES<= /p>

NO

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

JWS

alg

RS512

RSA w/ SHA-512 hash

YES<= /p>

XP SP2

YES =

YES =

YES =

YES =

YES =

NO

YES<= /p>

NO

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

YES<= /p>

JWS

alg

ES256

ECDSA w/ P-256 curve and SHA-256 ha= sh

YES<= /p>

Vista

10.6=

NO

YES?

YES =

YES =

NO

NO

NO

YES<= /p>

NO

YES<= /p>

VARIES

VARIES?

VARIES

JWS

alg

ES384

ECDSA w/ P-384 curve and SHA-384 ha= sh 

YES<= /p>

Vista

10.6=

NO

YES?

YES =

YES =

NO

NO

NO

YES<= /p>

NO

YES<= /p>

VARIES

VARIES?

VARIES

JWS

alg

ES512

ECDSA w/ P-521 curve and SHA-512 ha= sh

YES<= /p>

Vista

10.6=

NO

YES? <= /p>

YES =

YES =

NO

NO

NO

YES<= /p>

NO

YES<= /p>

VARIES

VARIES?

VARIES

JWE

alg

RSA1_5

RSAES-PKCS1-V1_5<= /p>

YES<= /p>

XP SP2

YES =

YES =

YES =

YES =

YES =

YES<= /p>

YES<= /p>

NO

YES<= /p>

YES<= /p>

 =

YES<= /p>

YES<= /p>

YES<= /p>

JWE

alg

RSA-OAEP

RSAES OAEP

YES<= /p>

XP SP2

YES? <= /p>

YES =

YES =

YES =

YES =

NO

YES<= /p>

NO

YES<= /p>

YES<= /p>

 =

YES<= /p>

YES<= /p>

NO

JWE

alg

ECDH-ES

Elliptic Curve Diffie-Hellman Ephem= eral Static

NO*<= /p>

Vista

NO?

NO

YES*

YES*

YES*

NO

NO

NO

YES?

NO

 =

VARIES?

VARIES?

NO?

JWE

alg

A128KW

AES Key Wrap w/ 128 bit key

NO

Win7=

YES =

YES =

 =

YES =

YES =

NO

NO

NO

YES<= /p>

YES<= /p>

 =

YES? <= /p>

YES? <= /p>

NO

JWE

alg

A256KW

AES Key Wrap w/ 256 bit key

NO

Win7=

YES =

YES =

 =

YES =

YES =

NO

NO

NO

YES<= /p>

YES<= /p>

 =

YES?

YES?

NO

JWE

enc

A128CBC

AES CBC w/ 128 bit key

YES*

XP SP2

YES =

 =

YES*

YES*

YES*

YES*

YES*

NO

YES*

YES*

 =

YES*

YES*

YES*

JWE

enc

A256CBC

AES CBC w/ 256 bit key

YES*

XP SP2

YES =

 =

YES*

YES*

YES*

YES*

YES*

NO

YES*

YES*

 =

YES*

YES*

YES*

JWE

enc

A128GCM

AES GCM w/ 128 bit key

Codeplex

Vista SP1

NO?

NO

NO

YES =

YES =

NO

NO

NO

NO?

NO

 =

YES<= /p>

YES<= /p>

NO

JWE

enc

A256GCM

AES GCM w/ 256 bit key

Codeplex

Vista SP1

NO?

NO

NO

YES =

YES =

NO

NO

NO

NO?

NO

 =

YES<= /p>

YES<= /p>

NO

JWE

kdf

CS256

Concat Key Derivation Function (KDF= )

NO

Win7=

 =

 =

NO

NO

NO

NO

NO

NO

NO

NO

 =

NO

NO

NO

JWE

kdf

CS384

Concat Key Derivation Function (KDF= )

NO

Win7=

 =

 =

NO

NO

NO

NO

NO

NO

NO

NO

 =

NO

NO

NO

JWE

kdf

CS512

Concat Key Derivation Function (KDF= )

NO

Win7=

 =

 =

NO

NO

NO

NO

NO

NO

NO

NO

 =

NO

NO

NO

YES - Support built in= to library/platform

BouncyCastle is a cry= pto lib for Java

Release<= span style=3D"color:#006100"> - Support included in this release of softwar= e and later

Android uses BouncyCa= stle

YES* - Supported but oth= er non-supported code required (Concat KDF)

PHPSecLib is a crypto= lib for PHP

VARIES - In sources bu= t often distributed w/ support compiled out

M2Crypto is a crypto = lib for Python

NO - Not supported in = library/platform

PyCrypto is a crypto = lib for Python

NO* - Not supported in= the specified configuration (w/ Concat KDF)

NSS is the crypto lib= used by Firefox

(blank) - Unknown

? - Answer is a first im= pression but requires more research

PHP version 5.2

PHPSecLib version 0.3.0<= o:p>

PyCrypto version 2.6

Ruby 1.9.3 with ruby-ope= nssl

Java 7=

OS X 10.6 (Snow Leopard)=

 

--_000_4E1F6AAD24975D4BA5B16804296739436674A117TK5EX14MBXC285r_-- --_004_4E1F6AAD24975D4BA5B16804296739436674A117TK5EX14MBXC285r_ Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="Support for JWA Crypto Algorithms.xlsx" Content-Description: Support for JWA Crypto Algorithms.xlsx Content-Disposition: attachment; filename="Support for JWA Crypto Algorithms.xlsx"; size=18750; creation-date="Thu, 19 Jul 2012 17:04:00 GMT"; modification-date="Sat, 28 Jul 2012 02:24:02 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDF3RNAiwEAAJQGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM VclqwzAQvRf6D0bXEittoZQSp4cuxzaQ9AMUa2KL2JLQTNPk7ztWFtqQBZNAe7GwpXnLDHruPc7r KplBQONsJq7TrkjA5k4bW2TiY/TauRcJkrJaVc5CJhaA4rF/edEbLTxgwtUWM1ES+QcpMS+hVpg6 D5Z3Ji7Uivg1FNKrfKoKkDfd7p3MnSWw1KEGQ/R7zzBRnxUlL3P+vFQyNlYkT8tzDVUmlPeVyRWx UDmzeouk4yYTk4N2+WfN0Cn6AEpjCUB1lfpgmDEMgYiNoZA7OQNU2I505SrlyigMS+Pxiq3vYWh2 9rta1b3zOILRkAxUoDdVs3c5r+SXC9Oxc9P0MEjb1sQWpbUydq37AH88jDIu12cW0viLwC113PwT Hbd/pIP4zoGMz9NHEmGODABpUQGe2e0S9BhzqQLoIfFtLs4u4Cf2ER2kxtwBGZfTe/47qiLoIX6O uEFwHjlFA7SfwjqymuqOZyAIZGATWrsu/4aRI7g94VYwQ5PxGvQObhn/Kf1vAAAA//8DAFBLAwQU AAYACAAAACEAtVUwI/UAAABMAgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySz07DMAzG70i8Q+T7 6m5ICKGlu0xIuyFUHsAk7h+1jaMkQPf2hAOCSmPb0fbnzz9b3u7maVQfHGIvTsO6KEGxM2J712p4 rZ9WD6BiImdpFMcajhxhV93ebF94pJSbYtf7qLKLixq6lPwjYjQdTxQL8exypZEwUcphaNGTGahl 3JTlPYa/HlAtPNXBaggHeweqPvo8+bK3NE1veC/mfWKXToxAnhM7y3blQ2YLqc/bqJpCy0mDFfOc 0xHJ+yJjA54m2lxP9P+2OHEiS4nQSODzPN+Kc0Dr64Eun2ip+L3OPOKnhOFNZPhhwcUPVF8AAAD/ /wMAUEsDBBQABgAIAAAAIQDeCf0oAgEAANQDAAAaAAgBeGwvX3JlbHMvd29ya2Jvb2sueG1sLnJl bHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8k89qwzAMxu+DvYPRfXGSbmWU Or2MQa9b9wAmUeLQxDaW9idvP5NDukDJLqEXgyT8fT/Qp/3hp+/EFwZqnVWQJSkItKWrWtso+Di9 PjyDINa20p2zqGBAgkNxf7d/w05z/ESm9SSiiiUFhtnvpKTSYK8pcR5tnNQu9JpjGRrpdXnWDco8 Tbcy/NWAYqYpjpWCcKw2IE6Dj87/a7u6bkt8ceVnj5avWMhvF85kEDmK6tAgK5haJMfJJonEIK/D 5DeGyZdgshvDZEsw2zVhyOiA1TuHmEK6rGrWXoJ5WhWGhy6GfgoMjfWS/eOa9hxPCS/uYynHd9qH nN1i8QsAAP//AwBQSwMEFAAGAAgAAAAhALq0cdpiAQAAcQIAAA8AAAB4bC93b3JrYm9vay54bWyM Uk1PwzAMvSPxH6LcWdruQ9u0dhICxC4IibGdQ+Ou0dKkSlK6/XvcTC1DcOBkO3559nvJan2qFPkE 66TRKY1HESWgcyOkPqT0fft0N6fEea4FV0ZDSs/g6Dq7vVm1xh4/jDkSJNAupaX39ZIxl5dQcTcy NWjsFMZW3GNpD8zVFrhwJYCvFEuiaMYqLjW9MCztfzhMUcgcHkzeVKD9hcSC4h7Xd6WsHc1WhVSw uygivK5feIV7nxQlijv/KKQHkdIplqaFHwe2qe8bqbC7GEdjyrJB5KslAgreKL9FeT07+pVMkmTW ITsrdhJa932pK8lpL7UwbUonc7T23FdxglUbWnspfIlU8XSR9GfPIA+lT+ksxlvIzq7og4E4JkSi g7q3ztQYX6qLGxSAuV1KTOxGxB3DLzTOGtCYD+jkT/T4Co35gA4usUCEK+Vc5WhVF8ISk+ksCdNZ /1uyLwAAAP//AwBQSwMEFAAGAAgAAAAhAPtipW2UBgAApxsAABMAAAB4bC90aGVtZS90aGVtZTEu eG1s7FlPb9s2FL8P2HcgdG9tJ7YbB3WK2LGbrU0bxG6HHmmZllhTokDSSX0b2uOAAcO6YZcBu+0w bCvQArt0nyZbh60D+hX2SEqyGMtL0gYb1tWHRCJ/fP/f4yN19dqDiKFDIiTlcdurXa56iMQ+H9M4 aHt3hv1LGx6SCsdjzHhM2t6cSO/a1vvvXcWbKiQRQbA+lpu47YVKJZuVivRhGMvLPCExzE24iLCC VxFUxgIfAd2IVdaq1WYlwjT2UIwjIHt7MqE+QUNN0tvKiPcYvMZK6gGfiYEmTZwVBjue1jRCzmWX CXSIWdsDPmN+NCQPlIcYlgom2l7V/LzK1tUK3kwXMbVibWFd3/zSdemC8XTN8BTBKGda69dbV3Zy +gbA1DKu1+t1e7WcngFg3wdNrSxFmvX+Rq2T0SyA7OMy7W61Ua27+AL99SWZW51Op9FKZbFEDcg+ 1pfwG9VmfXvNwRuQxTeW8PXOdrfbdPAGZPHNJXz/SqtZd/EGFDIaT5fQ2qH9fko9h0w42y2FbwB8 o5rCFyiIhjy6NIsJj9WqWIvwfS76ANBAhhWNkZonZIJ9iOIujkaCYs0AbxJcmLFDvlwa0ryQ9AVN VNv7MMGQEQt6r55//+r5U/Tq+ZPjh8+OH/50/OjR8cMfLS1n4S6Og+LCl99+9ufXH6M/nn7z8vEX 5XhZxP/6wye//Px5ORAyaCHRiy+f/PbsyYuvPv39u8cl8G2BR0X4kEZEolvkCB3wCHQzhnElJyNx vhXDEFNnBQ6Bdgnpngod4K05ZmW4DnGNd1dA8SgDXp/dd2QdhGKmaAnnG2HkAPc4Zx0uSg1wQ/Mq WHg4i4Ny5mJWxB1gfFjGu4tjx7W9WQJVMwtKx/bdkDhi7jMcKxyQmCik5/iUkBLt7lHq2HWP+oJL PlHoHkUdTEtNMqQjJ5AWi3ZpBH6Zl+kMrnZss3cXdTgr03qHHLpISAjMSoQfEuaY8TqeKRyVkRzi iBUNfhOrsEzIwVz4RVxPKvB0QBhHvTGRsmzNbQH6Fpx+A0O9KnX7HptHLlIoOi2jeRNzXkTu8Gk3 xFFShh3QOCxiP5BTCFGM9rkqg+9xN0P0O/gBxyvdfZcSx92nF4I7NHBEWgSInpmJEl9eJ9yJ38Gc TTAxVQZKulOpIxr/XdlmFOq25fCubLe9bdjEypJn90SxXoX7D5boHTyL9wlkxfIW9a5Cv6vQ3ltf oVfl8sXX5UUphiqtGxLba5vOO1rZeE8oYwM1Z+SmNL23hA1o3IdBvc4cOkl+EEtCeNSZDAwcXCCw WYMEVx9RFQ5CnEDfXvM0kUCmpAOJEi7hvGiGS2lrPPT+yp42G/ocYiuHxGqPj+3wuh7Ojhs5GSNV YM60GaN1TeCszNavpERBt9dhVtNCnZlbzYhmiqLDLVdZm9icy8HkuWowmFsTOhsE/RBYuQnHfs0a zjuYkbG2u/VR5hbjhYt0kQzxmKQ+0nov+6hmnJTFypIiWg8bDPrseIrVCtxamuwbcDuLk4rs6ivY Zd57Ey9lEbzwElA7mY4sLiYni9FR22s11hoe8nHS9iZwVIbHKAGvS91MYhbAfZOvhA37U5PZZPnC m61MMTcJanD7Ye2+pLBTBxIh1Q6WoQ0NM5WGAIs1Jyv/WgPMelEKlFSjs0mxvgHB8K9JAXZ0XUsm E+KrorMLI9p29jUtpXymiBiE4yM0YjNxgMH9OlRBnzGVcONhKoJ+ges5bW0z5RbnNOmKl2IGZ8cx S0KclludolkmW7gpSLkM5q0gHuhWKrtR7vyqmJS/IFWKYfw/U0XvJ3AFsT7WHvDhdlhgpDOl7XGh Qg5VKAmp3xfQOJjaAdECV7wwDUEFd9TmvyCH+r/NOUvDpDWcJNUBDZCgsB+pUBCyD2XJRN8pxGrp 3mVJspSQiaiCuDKxYo/IIWFDXQObem/3UAihbqpJWgYM7mT8ue9pBo0C3eQU882pZPnea3Pgn+58 bDKDUm4dNg1NZv9cxLw9WOyqdr1Znu29RUX0xKLNqmdZAcwKW0ErTfvXFOGcW62tWEsarzUy4cCL yxrDYN4QJXCRhPQf2P+o8Jn94KE31CE/gNqK4PuFJgZhA1F9yTYeSBdIOziCxskO2mDSpKxp09ZJ Wy3brC+40835njC2luws/j6nsfPmzGXn5OJFGju1sGNrO7bS1ODZkykKQ5PsIGMcY76UFT9m8dF9 cPQOfDaYMSVNMMGnKoGhhx6YPIDktxzN0q2/AAAA//8DAFBLAwQUAAYACAAAACEAQb/4YNkAAADK AQAAIwAAAHhsL3dvcmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzrJHBTsMwDEDvSPxD5DtJ uwNCaOkuCGlXGB/gpW4b0TpRbBD7e4J2odMkLpws2/Lzk73dfS2z+aQiMbGH1jZgiEPqI48e3g7P dw9gRJF7nBOThxMJ7Lrbm+0Lzah1SKaYxVQKi4dJNT86J2GiBcWmTFw7QyoLak3L6DKGdxzJbZrm 3pXfDOhWTLPvPZR9vwFzOOW6+W92GoYY6CmFj4VYr6xwiseZKhDLSOrB2nNFzqG1VRbcdY/2Pz1y iaxUXkm1HlpWRhc9d5G39hj5R9KtPtB9AwAA//8DAFBLAwQUAAYACAAAACEA++hdR2ABAAB1AgAA GAAAAHhsL3dvcmtzaGVldHMvc2hlZXQyLnhtbIySwWrDMAyG74O9g/G9cbp16xqSlEEp62Ewxra7 4yiJaWwF213bt5+SkDLopTcJSZ9//XK6PpmW/YLzGm3G51HMGViFpbZ1xr+/trMXznyQtpQtWsj4 GTxf5/d36RHd3jcAgRHB+ow3IXSJEF41YKSPsANLlQqdkYFSVwvfOZDlMGRa8RDHz8JIbflISNwt DKwqrWCD6mDAhhHioJWB9PtGd36iGXULzki3P3QzhaYjRKFbHc4DlDOjkl1t0cmipb1P84VUE3tI rvBGK4ceqxARToxCr3deiZUgUp6WmjbobWcOqoy/zrnI08GcHw1H/y9mvdcF4r4v7MqMx32ruOrd Dl5/OFZCJQ9t+MTjG+i6CXTYRbQg9f0SSXnegFfkHoGix8urGxkkYTtZw7t0tbaetVANTUvO3MiJ I4oDdv3o8omzAkNAM2UNnRfojD2WVYhhSnq5lw+T/wEAAP//AwBQSwMEFAAGAAgAAAAhAPvoXUdg AQAAdQIAABgAAAB4bC93b3Jrc2hlZXRzL3NoZWV0My54bWyMksFqwzAMhu+DvYPxvXG6desakpRB KethMMa2u+MoiWlsBdtd27efkpAy6KU3CUmff/1yuj6Zlv2C8xptxudRzBlYhaW2dca/v7azF858 kLaULVrI+Bk8X+f3d+kR3d43AIERwfqMNyF0iRBeNWCkj7ADS5UKnZGBUlcL3zmQ5TBkWvEQx8/C SG35SEjcLQysKq1gg+pgwIYR4qCVgfT7Rnd+ohl1C85Itz90M4WmI0ShWx3OA5Qzo5JdbdHJoqW9 T/OFVBN7SK7wRiuHHqsQEU6MQq93XomVIFKelpo26G1nDqqMv865yNPBnB8NR/8vZr3XBeK+L+zK jMd9q7jq3Q5efzhWQiUPbfjE4xvougl02EW0IPX9Ekl53oBX5B6BosfLqxsZJGE7WcO7dLW2nrVQ DU1LztzIiSOKA3b96PKJswJDQDNlDZ0X6Iw9llWIYUp6uZcPk/8BAAD//wMAUEsDBBQABgAIAAAA IQBwba3KEQ4AAP9VAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1srJxbc+o4Esfft2q/A8X7 AOZO6uRMDRgOd8xld585xEmogTgLnNt8+m1Zsix1O2pNLS/gyD+1Wq3+S7JN/On3n+dT6Xt8uR6T t8dyUKmVS/HbIXk6vr08lv+1G/3WLZeut/3b0/6UvMWP5V/xtfz753/+49OP5PLn9TWObyWw8HZ9 LL/ebu8P1er18Bqf99dK8h6/wZnn5HLe3+DPy0v1+n6J909ppfOpWq/V2tXz/vhWlhYeLj42kufn 4yEOk8O3c/x2k0Yu8Wl/A/+vr8f3a2btfPAxd95f/vz2/tshOb+Dia/H0/H2KzVaLp0PD5OXt+Sy /3qCfv8MmvtDZjv9g5g/Hw+X5Jo83ypgriodpX3uVXtVsPT509MReiDCXrrEz4/lP4KHXaNbrn7+ lAbo38f4x9U4Lt32X7fxKT7c4icYp3LpryQ5bw974VsPBk3/uRQBP8lCMUZfk+RPYWwC1WrQ7DU1 IprdH27H7/EgPgH9R70B4/xf6QkcgxtV7Yd5nPk0Ssc1upSe4uf9t9Ntk/wYx8eX1xs416w0IVIi YA9Pv8L4eoCRgsYrqdlDcgIb8Fk6H0XGQaD3P9PvH8en2+tjuVvpdDqNZqPTKpcO36635PwfeSIQ XumKdVURvnXFVqvZ7jL1oJ9pg/Ct6gVBpR5w1aBHaTX4VtWa9UqzGTRr7brbUTib1oRv7ahXD9uq Inyrir1KUOulgbnefomRD+CcI0YdZQG+lYW2tuCoBpJPPYbvrJqzmQDyL60gDnQf+ZgGevDhQNfL uuhwMMgGXxyoih3ds6/x9TY6ikR0e51lQpCnAvTY1WyWBEGeBR2/JAiyLBAHyuNepd3m00cMsQxu ngfdSrfb7rA5G2TjLw5Uo20/dQVZDogDPTQ++gp6mb9wkNUUa4hPwtazTBIHqjL47hiTepZD4iCr 4RVYMeOlgRUHqiZMXbqP7jSqynksnSPD/W3/+dMl+VGCJQzcuL7vxYIYPIheiBmx0ahooepZ8oMp EqY4YeYPYQcmw3IJ6l9h3v7+udH9VP0Oc/FBIX2JQJg10mzZyIAircBGQorUbGJIiSYyMqJID1n5 UoCgDo0pgtqZUKLRtr2dFiAoKrMCpGNbmUtETGg6uA0bWRQgTdSjZUFLyMyKIl3UpYgiHRTdNUUa TdvfDUWaqKEtReq2kR0luj2NVEEDWggwNVtCEIrIpCx3D2lBumNoCX0U7hgyOQhrj2X41MOButen BBr2gSRg7tY2UP/DAgJl4FAi4K42glJnRIkeMvKFIihxxiwxYYkpS8xYYk4J1N0FSyxZYsUSEUus WWLDEluW2LkIK/1hUblj+gtrsI4YWYfTnxI4/SUB+w+dubly0zUnpEQb6X8oEVf6U4KkP0VQUo0p gQQyYYkpS8xYYk4J5OmCJZYssWKJiCXWLLFhiS1L7FyElf4wy94x/YU19+xPCZz+koBPnf4BWkRD irTRaj2UiCv/KUHynyIou8csMWGJKUvMWGJOCZz/LLFkiRVLRCyxZokNS2xZYucirPyHafaO+S+s 2dN/gLYU/QIEzd0DicBnrgCU3iFF2mihGUrEpQBKEAVQBCuAJSYsMWWJGUvMJQEXoTpodbRrXFAj SCRL3siKNRKxxJolNiyxZYmdi7A0ADlyRw0Ia/YaQDRQgGANSARkrIczQAkeUqSN1pKhROBTW0Ej PqIE0QBFsAZYYsISU5aYscRcEk4NUCMoIkveyIo1ErHEmiU2LLFliZ2LsDQAQbujBoQ1Zh0oQLAG JAIy1tkboAQPKdJGs95QIhAIbQWN+IgSRAMUwRpgiQlLTFlixhJzScCn7i5ZB6gRFJElb2TFGolY Ys0SG5bYssTORVgagJuYd9SAsMasAwUI1oBErHUAJXhIkRZKzqFEXBqgRA+58kUi4ka7Tq0eSpyx ZCDiGsHZN5EI3J/QSAdd308lYrqLOjRjiTnvyYJHljyyoq6goES8kTVrZCMJ8dRCxy2ooc31VkJm bIMaGsYdY8hSBLR2R0UIa8yqUIAg/wcSsVYFlB0hRVooxYYSMVMMjdqIEkQREnErQjJORUgEblno kSWKoM6gPs9YYs57suCRJY+sqCsothFvZM0a2UiCUYSEzNhSRTCGLEWIJy13lERqjlklihgsCsVY 6wRK+bCAaaM7S0PFuHRRgBBhKMatDAU5paEYc0broklvWuAQFgePzD28WXgwSw9mVeAOVoiHmTVv ZqMQRiSKMqNMVcKZsmUinr+Zj5dh4v8/nqqJX2CgpaOOUrdfwAREJtKOuXjUUTqFyo7JtNDtp6Fi nDKRTZkIuaooMIMyd8wjEx6Z8siMR+YFCErbBY8sFeKS/Yo3E/HIWiHy51zixwobvtKWR3ZOxJYB SOqeMhDm7NWCyoAyVAaSMVeLOpJKKH6yBG2ZTAsxQ8WYOY4SYlSAUBlQl/EkPy6wg6Qy4ZEpj8x4 ZK4QVwYvCsyg0Cw9zKx4MxGPrBVST3+YKIUgQ+4YuS1vd6eQDwJhK0E8kbvjgiAf8Jn7OqoEylAl SMac7Otosg/F7+5ACRaD7sUOFWNGIkDjPVKMGXO6caI+d9FCNy5oi1xkK0Z86YuKJnJo6gPNfKC5 gszuY5cWHszSg1kpxuwZvlyKPOystR3xa10pChp8sg3a6mp5YAm0K4CMYbSFATPsPYUhzHFLBGWo MCQDnzp/6vjmq/h5KRJGC92cGirGlRkjxVjCQAL7UsCg+X/MIxOF5BPhlK8045G5Qly9XHgwSw9m VeAOEnbEI2uF5JHY6JJ8xPEqvPVgdor5IBZ27sOces/cF+bsG0x0UaAMzX3JwGee+yjEofh9NM59 xAwV80Ek0jlnpBh37su2TIbkPotMVEv5bnha0DayO+ORuUJcvVx4MEsPZlXgDgp6xCNrheSR2OiS fMTxmrL1YHaK+SAWdu7DcN4z94U5bt4vYNCAD8TP+MGONe+TG0mSMfXRQWvDUNkRC6EWEd6AjBQE 5jRDLw5kYyaDfB4rM/lcNvFpfeoDzXyguQ+08IGWCvoggdIpY+VjKPKB1grKA7fxqbbNIDMB8Nju MuiDBLC1AP29pxaEOW4dKGBQXg3Ev6OgOb6BNuNhAdMheyBph9GChMw8p1qgDPJ5rPzJ57aJKnG2 PvWBZj7Q3Ada+EBLBUGf9eyALypWPoYiH2itoDxwG59q2wxya8GdALYWxPO5O14o00eCdE9UwKC8 Gohb+WhdaJA7p5IxQ9FC+/ihsmOlOVpfRkUMuij/ohi4jaGTw7jCSifKsWJcCTTxYKYF/qDwzHhk 7tHSwoNZejArxbiiE3nYWWs7+TWyHGNz/NAObKsqOZCdu21bD+Lp3B31QB8IUj0UMGjAB+KJCl4b 0O3RsIBpkX2StGMGq0f0UMAQPVCfqR4k49YDz0xVv0yfUXhmPDJXiMubhQez9GBWijH3Ijg6kYed tbaT64GODdEDi+zcbVt6EP+reUc9pOaY6wbFmNFroBwdKMac+5t4r6QY89qiixJnqBhXVowUY+Zf D60zXxSTb23HpGTi0dbUg5l5MHMPZuHBLD2YlQcTeTBrxeQx3HjU2nowOzdj57t4jnq/+b/u8SS5 gKH5Tp8kN5EmQmXH1ATNd2nHne+Sced71q9sZhrrXmQlE1Xiamvqwcw8mLkHs/Bglh7MyoOJPJi1 YoxLAI9aWw9m52bsfBdP5u6Y7/JBn7kTJPudumTc87tkzFxukfldMu75XTKuHBwpf9z5Lu3kc9NY 1cpLJqrE1dbUg5l5MHMPZuHBLD2YlQcTeTBrxeQR23jU2nowOzdj57t4iGTmu/vf6wUN2xXzfQdN tO/u1xUkX8QjHu0NaFFIi6aqSPy+Q19VdnLrtt8gBctvcEvc85LvADFeHODuj7ACFU3N9ND9o754 cY+Esql8QItCWjTNivJAzPIio4to8zQHKGtpYRwv88rZ6ZVxOjKO18bxRh7b0YNIWdFzR0nQMOqg eT0uXXQF1K8rKJ++B7QopEULVWSPem7d9hsmE8tvMS5Q9jdHXViB/pgzU1BD02lfnBZU+rKt9I7G gBaFWVHPGDJZETqUDdNSUVYfu+hCZZVDWb0IirLjtXG8ydC2Pr01Tu/ksR05cePAX+fyNoMQpB7x Zj4maTT6EJk0QHm2DmhRSItWqsiKRgfdzdpkkNnFdCjsbomLO/9uyUtBq1tdpL5+XUFmt0hRSKlI FVnd6qEbDpsMMruV5o7VrQa+ynTqM6UhU0GB+WjhbuVQllEDWhRaRbZLYofrHemG3A+LXyhpl7r5 VC4TKIdyl3S9rCik1CYrMoIIRVDD9ljsUUyPxWQBZX9rshg1hJV0bck82lpFdpOwidNNgnjcwyZg NGxtNCn0GxrKmh/QotAqsj0Si3EWBNYjAcsg6VFro1sE/YaGco9IUWhRtkfmys16pNZeM4/a6EKv 39BQ7hEpCi3K9shcDVmP5DpnZXaHjJqGco9IUdgwi2yPxBLiPWpqvTFj1CGjpqHcI1IUNswi2yNz /WBjBLBOoG4+BUqL8o2R8m1o5/jykr5b8lo6JN/E+x878BIzXareeVlvPoj9InhOzrThTDoNkDNd OJMuGORMD86kcy4+02g8CCkVtNOowZla0Zl6B6yly3RVm4M3V77vX+LF/vJyfLuWTvEzdKxWgeBe 5Lsv0+Nb8p6WQqp+TW7wAsvsr1d4/WkM22bxKszSc5Lcsj/AMWF3G9++vZeSyxFemJm+0fSx/J5c bpf98QYtPByfHsuXyVM6IcLrQE9xtL/cdHwDiK8uzen0KqSqT0APqvrVrZ//BwAA//8DAFBLAwQU AAYACAAAACEA1ohQeh4IAAD2WwAADQAAAHhsL3N0eWxlcy54bWzsXO1v2jgY/37S/Q9RvncBBm2p gGnQ5jSp601rJ91XAwZ8TWIuMSvsdP/7PbbjxLyEZLyFdt6kLQl++fl5tx/brQ9z37O+4zAiNGjb 1XcV28LBgA5JMG7b357ci2vbihgKhsijAW7bCxzZHzq//9aK2MLDjxOMmQVNBFHbnjA2vXGcaDDB Pore0SkO4JcRDX3E4DUcO9E0xGgY8Uq+59QqlUvHRySwZQs3/qBIIz4Kn2fTiwH1p4iRPvEIW4i2 bMsf3HwaBzREfQ+gzqt1NFBti5e15n0yCGlER+wdNOfQ0YgM8DrKptN0oKVOa0QDFlkDOgsY0ApI JVq9eQ7oS+Dy3+BrXKzTin5Y35EHX6q202kNqEdDiwFpAJn4EiAfyxI95JF+SHixEfKJt5Cfa/yD oGZczicwNv7R4UAknE6rz0tt6Csc99u2G//htYp1uNT2lnYr4s9p2v0YEuRZ3wICgomtz4+81zVK FQd+Wa1UigPP58AWKjV7QKbLQ3ZGMth9DNHaNLBj9JM1pliEgYKn5Nhl41DiIUQyAlklnpfYjWtu IeBDpwX2i+EwcOHFip+fFlOwDwGYWi4zjiyXU3ocokW11iheIaIeGXIU456wSgmZuUrzZvrxDyQY 4jketu3LumhdA1wUXEZft03+9zR99S7v3N7dgQfgur2rIzQKzfYOjvSu28xuVMgYyGifhkMIAzTv pr51Wh4eMRCLkIwn/H9Gp1xIKGPgNDutIUFjGiAPHh3ZynJNiB8gVGjbPh6SmQ9yJ33hmtQ5vJud e4HeBb7CvYnSOw+GTSBuUUNZ1RNtIArO1vIplELFgf6K/IXKS04dh1EKQC5z0zHuIjtbyaeRG9re UTqXeohls1vjf4U+an2oIefUSAdcsEIeW9dB/SxjcxBrY5R0LB24Uuozg1OQLiVLQGyMwbYPsOc9 ciP81ygx8A2wXvORFcx812efwMfDdIZPK9QjBCXxo7Tp8gUYkVWpDvXjSvCoV7LQdOotHmZ+H4eu mA6K3sTXrnA76ftHj4wDH/MJFgASRb6ElOEBExNUEZ5kIWikCOCxDARXKYJLHQG8bKEBnzqmw92H As20f4ByTAo4ukxJCdOE631lJ+my5qNcMeNiulk2k9qS1hodxXw7S2pqaYPvdZrBi4IjG5Rsqsas dAEEn8nL35QYq/elzjstpKSaL7UwMuDrAgMQciyn8/NRtlpp8GDoKUtz4B0PEHSsGHCO9NLgnQe9 suxiwkAlM8djWZZhTCCAkC1ZYwXpcGIMLSqpgc5SMYaXo2oZBFW29RKi6ROeg5EVlsDZpm9ZQIGN rwMoDOC8gILzU6xf0kh42Qx0S5ABdfLa2lJ7i3uWSEAhhB4cTu6ztD8ZvFK1crxLCRTZj4X71c7i RmIIgRv/zCDc/BLiEZmfwr9nhWwJJMB8ZNucRRVwG1ItypXRLHhnokKaRK7G/MtGZVnDD2diStDh rIAikRgVUCyP2T1RzJwFL5GYcuFpEgOPaSyUwNs6y80yGCAGUt6ObzCyIECuuGwIAO3QEMRUFya3 2jrK0ipKMhO2eIa1bXfRUIHgoe6MeIwEfF5bu+JLiavF/6A0KQ+GVi8vEoer5R/wjIXIU10At/Uq 15u6eOCLLkkNLnMpKCFra32AC1QdgCPSikPWG8aQzv6BKsN5uqpUq8PEHz5AckmkqPsylS0qEe05 YiF5jtPaEgGFXFMQ6Z8gYMfBUKtEZ8wjgV4kmqAhfdGKzOSzSqDx2bYwtPJzH0WYt8CHkOQ24+6z 0/NPxMeR9YBfrK/UR4GozPc4xEBUXyr/DDYuL7WXpt5WMgfriTeZ1tuUeEPJmsKEhuQHkJuvKoxx gIV0rC00WAwI+pUy2DTBt3qAFKTTInjhSOJlqL9nESOjxT2K2D1QS5SNJiEJnp+oS+RSFd/IAXtE /uRJI14AKCoNmaXSQd+moqJ6vYU9EvyDzCZtXEFdIYaeDypUPme9dbX5vPX21fJqtV1RFoacUp4r hSQAPAgFEP8YJq1S8QyZZExV9i4EY6oKmR4tdVaovNGC2Gm8EYeNZoyq1UXjrOMNH0vp5pL9QCGt VJ5dd+yFKqZxgAkDWCGKGQO4uwHUNhSvbaLauMlX38L6c9OV1e17K1qs5isxjHRXn2OM4BkawSIz FhMM7xEMmzDgzAPhQr7paGHAa9StLR7moAtjxtP8amtjRhuyT4AYbTDacP75EuMbTN5EHO3ZutKz S97E+AbjG8ShMpNFfKW5dOMbjG84jm/IyambbQ7Lh7b33eZQ7pKJYTacuRaHWgvx4U0zW63LJWen zJamlQsa9mX/m0oQmDSZ2IDHU3ZmY9+26xpWJ6iFLK0yRqfeK2DCGxPe8JOMZsuuvFXmp5aejGaH v87+7HKZ/WpWME2YZIxpIVU5rzApPm0SnwniLFw+WZJ7IdWGnSq5ddZ3LeZW2TAly62jKL3pRMmr sSunPVf1thPm2omiTXIv5UUp8SHECxYCzjT9vO6u5BW3/ARaqZtfxX24Quj32/wKBsPetrAFZ0RP NaW3yrKuwEsp0/CwYgS5KsChU8bveBZ3miVncWFGNMQjNPPYU/Jj206fP4v7J+FIblzqC/lOmWii bafP9/ySy6o4eQvnJe8jWHyF/61ZSNr2v3fdq+btnVu7uK50ry/q73Hjotno3l406r3u7a3brNQq vf/g4Cy/EPsGLofe48JpcTE2XAtVrd9EHlxLHcaDjcE/pt/atvYi4XNlcAC2/FcMwhH7kcWF3Z3/ AQAA//8DAFBLAwQUAAYACAAAACEAgy/oZb8EAAB4DgAAFAAAAHhsL3NoYXJlZFN0cmluZ3MueG1s vFfdkto2FL7vTN/hjK82nQFjNrvdZsA7xAsh+wMMTnbTq46wBahrS44kQ+jT9Fn6ZD3CkDiSl+aq N8z48/nT4XyfjnvXX/IMNlQqJnjfC9odDyhPRMr4qu99/DBqXXmgNOEpyQSnfW9HlXcd/vxTTykN 6MtV31trXbzxfZWsaU5UWxSU45ulkDnR+ChXviokJalaU6rzzO92Opd+Thj3IBEl133v9TmmKTn7 XNKoQoLOuRf2FAt7OryhKpGs0Fhiz9dhzzdw9YpNYxviIqXtP5UNz8YzG7p9iv3bp6ENk2zlM65t eBx3Ly5t8Pehnd805Y0qSILNwlMrKjfUC9EObN9xfH712gUvgq4NYqE2hEXa0LypwHlTknnckGTY 5D6Z/mKnGTZFHDZFbOjtPB4Ef1zYIRFtTQdD5w8aRjfjltPhcJhlZhoSiEpsLtyw5ZLR1phmWU44 DAscQypJBrEmaGUnGwTdq7snG51MbWSAf7drh+RwDDFg9DZyYPRvgtH6XfTQZN0Az3Z67U79vFzs 7ABvkTfJLiJKZ9R+d0s2BG6jgY0PeCoFS234oyIrJ8ZzurTtoqaJaU+GH2xDM/0tiMuiEFLDomSZ BmSYgIwtJJE7v8iINnphO06m6DcRGlTlS1P0+0+vs0VG+PMrdP3In7nYOqoxI5LkMCG5c8opalcc 39t14AEcHqCgxDS5ZwvbOGoiSNREkKqOR5LZIZAQ2LImSuzftGZ3URy0HhuoZPxwjmDrAw4aLJiG Z+oMS80Kp/SU1R3dwZMkxQ8ErJueiIqkjgcm3KxlrJI9h/GCgXg82CNrotZ2Q2pOKJqWk0GM0z9/ n3C76AaWG2rg3s12Gj8MIlNfvR43dN3qWMCpSC9lwz/UTmaHqZkcM7n11IxeSoUTe7zq4aLt3DJf B/qrUad93u7Y1cx2kdwVSN7D1gDdtnMtHm1e9GUKCCRVHBQBQPJDs9bVdQ2a3Iy4OXmO3Gz0aFgF DkoIpaIK6intyIY5qOo/QIeD1QkmGBmHoP1b+xy2TK9B4nPLbE9KOYqwl/Bf7WpQl65tbDK1oRdX kmtnJ7lG0RxwtaWy6tySSdzzWG42GbMionhrkPRzyRCAXEiKT4oSmTiUNZqJ0Q6qj8ptXIVeY2gu eOubouO2aaLsY6ZwFgmeEA13N6NX7tFMxIl9H2BMUAVNGK4BKa6UfMlWpcS7H+s9QyKfiDiN4RME nfYlnMV4U8A9FQWRqZP5oVsNvV3REW+es8bL+1gNCusNlWxT1TnC27squPHgsbMAPjGeiq0Cjv4b 5x77NIN45jD8keEqbx9hD6J1YL/ADM7ATeLYHNV0vMZeZA3+vTsY4VQsxZfvA8mwJ2f4w3xc2v+C DcnwOyPw8CkRGdJerhZ9bzTCb4Kg0zGwHAmuK7uImA2BGXRJcpbtKrhrgP3nBq2AnHEhDejvU+lw TjNK1KEtpoJDEf9XAc2U+0YHXGOSrEyrfUavsaWyqhjEEpRY6i1BaplbETcjKquO4iFqnz5mar/v tA7NONtYhPQqMmr9Kzp8HMzf7/ey9xwzljJBQu8putSUQ4qjIhk+Y4lIoQNbkVx5wTLEROl8IFUB 7fQVWpMkH78cw38BAAD//wMAUEsDBBQABgAIAAAAIQBgQQnkUQEAAGYCAAARAAgBZG9jUHJvcHMv Y29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEklFLwzAUhd8F/0PJ e5s201lC28EmexAHghPFt5jcbWVNGpJot39v2m61Q8HH3HPy5ZxLstlBVsEXGFvWKkdJFKMAFK9F qbY5elkvwxQF1jElWFUryNERLJoV11cZ15TXBp5MrcG4EmzgScpSrnO0c05TjC3fgWQ28g7lxU1t JHP+aLZYM75nW8AkjqdYgmOCOYZbYKgHIjohBR+Q+tNUHUBwDBVIUM7iJErwj9eBkfbPC50ycsrS HbXvdIo7Zgvei4P7YMvB2DRN1Ey6GD5/gt9Wj89d1bBU7a44oCITnHIDzNWmWLAKPoI524PJ8Gje 7rBi1q38ujcliPmxWJV7CB78pm2Gf6se2nXoySACn4r2Hc7K62Rxv16igsQJCeNpSNJ1klIypbfp e/v4xf02ZT+Qpwj/Eu9aYkwouaExGRHPgKLLffkzim8AAAD//wMAUEsDBBQABgAIAAAAIQDcWXjt 3AsAALQbAAAnAAAAeGwvcHJpbnRlclNldHRpbmdzL3ByaW50ZXJTZXR0aW5nczEuYmlu7Fd5NNTr G3+tpWsva0mKso+d6DbJdCUma5Yxdt80GPsuxrWEEJUllFHWLINCssSPe8kIRdMokSVZsmXf4ved ln/6655z//id8zs+73ne53ne932e830/Z545z4sFWGAAjMBFIAO0gD5sGQB5eM0LQMAR+MMiAxSB HFAAqrDlCH4FHSNgfg/6BI13AD0doANT+9z3OsKaA5jDPj08M8CeHpzNBx4QnPffg+5HCkZY08Py 0/81s4GRjumI3K+r/97n/5aC8wRtAECT72gCyQw/7V/1zw0UHyfA6jKAK1q0r/8OGm+/Qn5UkYEJ XtyB92jyM/7Xc7v+/zcDv/4ymuDrGqNNLtBuzQnKgfm3mnIHAeAIMAPucH25wHUMATe42mg1fAQo AxVYlGHLABjDUXqQnSPOzemcoxMEgIGdE2SMC4LgVR8fyOubbwQ54dzdAED5erhCAT/URXcTX7y9 KwSMIG93V18f2gkVObkAWBw9cLSv+WdA8QEgf9HInHYvVtj+p9jA867vhetgnoUTDqEDe45oHjjE SotGG2v9QdO9LLQZAOnvCjDQfa+rk3IA/lejxdCBcaUfmz8UAnHJzcEd7+EFeXtDjjIoOx87BAJ4 WnBuB7KMK2np/m3J5nrIjCur//F+DQK6gqHznafsU93RodaKuenHA/vyqntF8eiRd7z8hoICbaXH NKpH+xLQayyEKN6HD4owTGlEU+fJD1USuMwPx7kNUDrnJDQr78cUchee5+Tae/8IKsz9sl9IMOGG 6ru6TEpvZvDmYP9c54tM1cfWqk9cJ11lZWzOZH9KzezPsFR/dz1kTZ44cV7kiW+lgMiWSuGQD1OR 5HzoyOFWDJ5dVvNS6RbmUwtZ2OqG5IOrfE/8pXZkF/3DEPluEblr7X2lqhrIyKmDZGIdMyXiOiQv kXoyd3VwOJhDasdAoOhruO7sRdwii1soau2sMCXpCx6PENdeFhrLTL2/QVqgcyOY5L/tkknEefP4 nxQTv5opfaA1qGF1L2LM95z5GCrmGeT3oeHa0ox5rLPwWuD1hUq/4sd1v5cZuykaChmEXl8XliTE mi0a35vKulQ4+GalM36DNUC8Yy2hWsjp+Zza2gfJHYnZTe0xwoutRqiK7b2XTmZHzaY9cX6mZA4i Ezmyi+YnHQQrZ3hNPXISC8Qt6KrbVUvDVYjSs/ENNX5CnklOT63WGU4FFS/oe27iyQiH7dtkZGcI sw8pZAUbsWbVxCFQkS5vg63YTz+iz/moopeP+lW2bq4GQZoWqfN8fXn2TR2PriFbf0KwI3n4aLnl 0vYe/tET05uJGPvAF0UcOjOK7JbLXMWhunsIZYyUOR9DoZUH0i5XKghIUiN6059Vj2sgVMqP7N28 8oQ36cuBv4fV8Z9Kup7J41YmUrqt7ebt0wxUl1+Js/UyMk2MFmrjwjCvVFAOQ5svMfqGyUEKqR1J 9D6fw2Lvi9jq1d1gt+vgU0oTvNdaSfGxOHZcXC9T/GyrStWqWL3vtRSiYyhKndSSSzHRTTDSbrqk RbEME4mv5Y2au5ZXddPtzCazLb7gM1NdeJFees4frZSXggqzvdpZkTuKoblbsoNBSHnU1Wp9BWtK cPD6IDGh5mWX1A7vE751iprkVo+pv0zRGNnd9nT2VtAn6sbo5mcdl/dx22v1CAkCTrkoLWUHsRid vHqp+ckGRWqdasFPx5Q1jpw/et+GsLPcP1soGbozjWQXHvBxORF0RuK2/VC9+xrXwSHmrFkR54gL bR4VPQycpsdQxhw3KDZxLmJ/JaMlc7v3kpDSovtEh2vjgq7IsRXVluQczdCyyfYsjKoo9RiaiiwJ QllrlKK5yvVetBaYP47ykJ3Jmcc+oJvwzGOgogP8hJd71DhnsuugHFN7BhOH4L/EzG4ru8ZN6B4t XuW8YqLuIeYsG+40nkrKb7BfdKpIS9Pw8NWMI17zZdPC9J8zdZ1R6bpWYtnnuwRtxFUJt7Bj0SzB iNUlng3pmf/c9+eqJuQwmGmIVh2spvz2NAHDXew9oZIBxYakPDtPiBogSh3fOB8e8jdeQ3ihNvq0 9pyWNR8nz+BQE9SRJ4IojMnK647bscdqcHtcGuexlJcuYfdDRuVIMWJLeUmXzff3m5grPVxr7mNj K/QfIVc3IsKj5PND12Jt6UkxUboVciR1FqRXhMtp6WnliZtQtSSdWcNY1VT+aphMHXYIc8amIHDe KiEuhuQ7VBvl1iogkJ2KC3mj3yFDjzBMg67+NmktGU20dS3uHXk09mava/X7qcduTgcnXRyb9WNk 9y/xV82/FkWpJZzscVAdODF8okM6w9Ra5Vl5C7Vo+lHsXKi6TrQ00jPkOrFPkqtL/GKuUIzwZsmi eLzULeiD4dmCSdazc6ph+OcLxd2Ayns3kRJwmPhBVUTW8eohq3jzm+aM/pmHuOxvt41DEg2a1KZn fiNXsbeZ04Ku+TyfEv3dyBGd1RZdPMF3tMyqvMyXHSvMFC4SKxb0kMCr4DLPbyHQoINPooZOfGlJ DZEnsT0/1ZPzEK2W/siXPrkX8fA3pxWmoSKvIWeeuaTDZq+H25uPys95rnuIjSdW5G7dXLiF5M3/ mFgRCZvJyC6ddmEH3KI22XNbTVWMEJ/XKSzRtj76IHnrpic+Mo+D/pXcxscThHp1MYIj1rV//y0J I+uFNm5s+3jSlPxbLcZhLvHocQMc+WQyC1///rHpQ5gUL/a8tpQABcPU7vufPcQa98S0B4exVIiT e4PD7LHtgZgX1xvFywIxhheyeB8vKJFdslSQYvpxFoGCY8r6lkm3CuRlNZC9akTDj+r6lnduFUiQ NkSxTzt7yR5ibVGTXxm1rye31JSfEpPVSyz2fTfixcXn9lfKXWprSX3qQgbVr+BjlbPNK9FNsq91 MOGCdUdND1T5xd/+bbfL6pD9h+XDK6MZF56z1GTdrnfADm6yjwauZ7NgdUsDHpD/LLYgaYxxJAdq XosUPykcJKJjTWd+x1nR33GeyrL4cTmEWkEkYgie1O41jahigzWGiMss8wLYRMaNhltH2XpywyDV Zp2mviWfrfG5Ragef3zYOqi8cmDiLdP91WyImf/0gzhIaUDxiF3LWHuiJ0Gfny+dUkMfX5ckJ3uq bolrdDtVjuRnOprF4fzKUyuJHBMZf7dnuetIeoSmjAy3oxuxCmPD6oy7jbSsyPLrdn7foSkTe/mt 2LvpTLuq6HCMQkKH6ECLpkx6K9Tz6WZ2qt6ogkX3K5qeUozX4H19C4dVaqkZpR1QduRfvWCgq6FE jQhRVdJtIO511jn9CaFdxlxVGYcm8dQ7hCfPnFCUYce9vT749Y023crUZT1tLYxKjg1H0sURtckW 9blmaQfFeEvunp4/fRN03Ve0RgNm790pUB01TrtW2fd5NCi6/uJkpqdZuohM5lgVvUuJkP7BWybu +TddzmLudgukHCnXT7rhUF2h9KhoH26Ss1E9ViFAIPICRUSmi+ry9Wh/epugpudOP5cVa70S57ug 6RlvYVRHg9isVSN1Cd3bsB6M5rgza1VNXcqeDLUMQnOkzyZyl03a9TZYLmasZM4m2pdNWuYH+39W RqfPWmVSl3Int9fmM0Jta5GC9fnH8jc9Ol3UnWs5vtbnO+RvyvW4qLvVcug05JvprQ6XUn2afYQl g9En0Kt2T6hL+ZOnTZYz2DNmW6zLJll6Q65MKQupDERTshrxLOdrOklDq8L9fhuv2xmMx0NEbZoU rarUu1TN8yrDbbYb6vqk74grba8jD4ce2ygJGLJpFJT8fM/szBeRFWQ3auz2Mksxu+29Yy9rM80u oRAHrjxMUX2tvEDNm+d50ebN00lpntOdeSpYZiu7bf9VubivkMS4v3eHjn4HBgBK41r6aGV6wA33 sQHAAZ5dgew3GwLwsxPggT1wBqywTQMbOAB3eO57p/b9aO5gResyD4BD8ItWCY6Ug0UFtuXht6ws 3BHLwUMR8MJD/tue2o+ZtqsGv3j54Mwep0NpTfMudhnYZWCXgV0GdhnYZWCXgV0GdhnYZWCXgf8J A/8FAAD//wMAUEsDBBQABgAIAAAAIQCiocrBnAEAAFwDAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCi BAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJyTQWsbMRCF74X8h0X3WGs7lGK0CsVp yKGlBjvJWdXOekW0ktBMFru/vtpdHMttcultNO/x+DQjidtDZ4seIhrvKjaflawAp31t3L5ij7v7 6y+sQFKuVtY7qNgRkN3Kq09iE32ASAawSBEOK9YShRXnqFvoFM6S7JLS+NgpSse4575pjIY7r187 cMQXZfmZw4HA1VBfh7dANiWuevrf0NrrgQ+fdseQgKX4GoI1WlG6pfxhdPToGyq+HTRYwXNRJLot 6Ndo6ChLwfOj2GplYZ2CZaMsguDnhngANQxto0xEKXpa9aDJxwLN7zS2BSt+KYQBp2K9ikY5SliD bTqMtQ1IUT77+IItAKHgyTA1xzL35rW5kcvRkIpL4xAwgSThEnFnyAL+bDYq0jvEy5x4ZJh4J5zt wDfP+d5IR2nxsTSR5rcaB5X4/iJa+y4od8z2tfYx+DhuUfCTLL4b94KPYefvFMFpM5dNsW1VhDot 86SfG+IhLSXaIWTdKreH+uT5Vxje0dP0WeT8ZlYuy/REsp7g528h/wAAAP//AwBQSwMEFAAGAAgA AAAhADYCE9FAAgAAHwYAABQAAAB4bC90YWJsZXMvdGFibGUxLnhtbHRU23LaMBB970z/QaP3YuQ0 5DJABkhpkyHAxKTtq7AFVkeWPJKA+O+zvhZR9VGrc/bsro52+PCeCXRk2nAlR5j0+hgxGauEy/0I v23mX24xMpbKhAol2QgXzOCH8edPQ0u3giFgSzPCqbX5fRCYOGUZNT2VMwk3O6UzauGo94HJNaOJ SRmzmQjCfn8QZJRLjHgCshhJmkH2TZkUTgk3uaDF0glqthvhCbnfhCFGVlkqzKs6Rak6QeVQdwoC TEPo8X33BFnDK0hELW2PkLeDTJUGbHtT5iuV3Wgfj4f0YNWcC8s0OpcPxnX/MyUOmTQoVgdpQbGk VJnqC7e5N0P3zCmJ3GE3U0WAaupprKmmGSqH4LJufSxo9pz1kwqXdOMjfW1Jj8zEmucWXODSBj7a dUvrLb9tXPy1Dw9zaYr7xWWiTgZOlh8v2oJiyueaMSEiWwiww3elEl++QZtuFaHfrv6VD3/T4vkq cuGhD37Xwp/pkaLn2cTlEB+HdKOcghfiYkaNFRcN9n1E+F/1u01kohVPHC2vP0j3XdY/1g7cawzS TQvgEYsXfOuQvMYgf01Y2PTCFF5PkG7IL+FMF7lVjorXF6Rrfl14OP8aYkq9fiCd+V8P28LR9fqB dAZewaaKooVD8XoCvmrzTlIlrPfHOJRyZbnW/V+l3U9YRq4VK3MEZ8vDNKuk+gtPcqca/WpHVsEX lvBDBtoGduCca2PrtVNtwzK2ABNehMqNaeGnM9jaDbNGdNGzQsYfAAAA//8DAFBLAQItABQABgAI AAAAIQDF3RNAiwEAAJQGAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsB Ai0AFAAGAAgAAAAhALVVMCP1AAAATAIAAAsAAAAAAAAAAAAAAAAAxAMAAF9yZWxzLy5yZWxzUEsB Ai0AFAAGAAgAAAAhAN4J/SgCAQAA1AMAABoAAAAAAAAAAAAAAAAA6gYAAHhsL19yZWxzL3dvcmti b29rLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhALq0cdpiAQAAcQIAAA8AAAAAAAAAAAAAAAAALAkA AHhsL3dvcmtib29rLnhtbFBLAQItABQABgAIAAAAIQD7YqVtlAYAAKcbAAATAAAAAAAAAAAAAAAA ALsKAAB4bC90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAEG/+GDZAAAAygEAACMAAAAA AAAAAAAAAAAAgBEAAHhsL3dvcmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzUEsBAi0AFAAG AAgAAAAhAPvoXUdgAQAAdQIAABgAAAAAAAAAAAAAAAAAmhIAAHhsL3dvcmtzaGVldHMvc2hlZXQy LnhtbFBLAQItABQABgAIAAAAIQD76F1HYAEAAHUCAAAYAAAAAAAAAAAAAAAAADAUAAB4bC93b3Jr c2hlZXRzL3NoZWV0My54bWxQSwECLQAUAAYACAAAACEAcG2tyhEOAAD/VQAAGAAAAAAAAAAAAAAA AADGFQAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1sUEsBAi0AFAAGAAgAAAAhANaIUHoeCAAA9lsA AA0AAAAAAAAAAAAAAAAADSQAAHhsL3N0eWxlcy54bWxQSwECLQAUAAYACAAAACEAgy/oZb8EAAB4 DgAAFAAAAAAAAAAAAAAAAABWLAAAeGwvc2hhcmVkU3RyaW5ncy54bWxQSwECLQAUAAYACAAAACEA YEEJ5FEBAABmAgAAEQAAAAAAAAAAAAAAAABHMQAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYA CAAAACEA3Fl47dwLAAC0GwAAJwAAAAAAAAAAAAAAAADPMwAAeGwvcHJpbnRlclNldHRpbmdzL3By aW50ZXJTZXR0aW5nczEuYmluUEsBAi0AFAAGAAgAAAAhAKKhysGcAQAAXAMAABAAAAAAAAAAAAAA AAAA8D8AAGRvY1Byb3BzL2FwcC54bWxQSwECLQAUAAYACAAAACEANgIT0UACAAAfBgAAFAAAAAAA AAAAAAAAAADCQgAAeGwvdGFibGVzL3RhYmxlMS54bWxQSwUGAAAAAA8ADwD0AwAANEUAAAAA --_004_4E1F6AAD24975D4BA5B16804296739436674A117TK5EX14MBXC285r_-- From mamille2@cisco.com Sun Jul 29 12:54:33 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467BD21F8650 for ; Sun, 29 Jul 2012 12:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fndXStyswhGO for ; Sun, 29 Jul 2012 12:54:32 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8E55421F864A for ; Sun, 29 Jul 2012 12:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=4537; q=dns/txt; s=iport; t=1343591672; x=1344801272; h=from:to:cc:subject:date:message-id:mime-version; bh=hOXkWFKukO195M6gXhUAKL8bP5/wqKVWk2NI/CV928U=; b=jrZRwH5RmG7v6uGkpOumhEFnBk/gr2w830eySM+6R/pj/V0Xnq04TCKN SIHd2nbPV3B06uDK6RrQdY4I3qVg1HJrFUqSI9GvZD+gpa4F13ijy5Opq zkQLP/g0sX4/1bGZbhhbCZBt4wIeQXSVcElSSS2vm9LrqBLT7HAeONWBd 8=; X-Files: smime.p7s, PGP.sig : 2214, 535 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAA2UFVCtJXG//2dsb2JhbABFhS+0L4EHgiUCEgFmEgEWHxswJwQOBQ4Uh2sLmXKfI48KgkhgA45XgSGFUY4ngWaCXw X-IronPort-AV: E=Sophos;i="4.77,675,1336348800"; d="sig'?p7s'?scan'208";a="106421653" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 29 Jul 2012 19:54:32 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6TJsWwl002730 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 29 Jul 2012 19:54:32 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.93]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0298.004; Sun, 29 Jul 2012 14:54:31 -0500 From: "Matt Miller (mamille2)" To: Jim Schaad Thread-Topic: IETF84 Slides for JOSE + XMPP Thread-Index: AQHNbcP3so74YoZ2xUCJQLyG1CAnYA== Date: Sun, 29 Jul 2012 19:54:30 +0000 Message-ID: <3D0BF3F3-970D-4A62-AF61-67CD5D4C7935@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 1.3.3 x-originating-ip: [10.21.118.8] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19070.006 x-tm-as-result: No--23.207600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-6-212250154" MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: [jose] IETF84 Slides for JOSE + XMPP X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 19:54:33 -0000 --Apple-Mail-6-212250154 Content-Type: multipart/signed; boundary=Apple-Mail-5-212250142; protocol="application/pkcs7-signature"; micalg=sha1 --Apple-Mail-5-212250142 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii [once more, from the subscribed account] Here are my slides for JOSE + XMPP: < http://outer-planes.net/ietf/ietf84-josewg-xmpp.pdf > - m&m Matt Miller - Cisco Systems, Inc. --Apple-Mail-5-212250142 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcyOTE5NTQz MFowIwYJKoZIhvcNAQkEMRYEFFF7kzeVoyLwG5l6fSedYURyumX5MIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQAO3k83tbQoUcB0M3BGZZVdUo4oon091/qnh5YQGj0icU6qQj16E/q+Xu7h aqeAdAmKvaEOzXKJhEZFZBKevkaAWk07IRCfYA403X4DyHS+6hyYiJ4N6X35Soc6p2C6v0KSTDZD ukEByJONo2p2FL7wMgmStHyB9yz4gq+gV/ZIANqoLoAurTarjvRFavBBoUSoO2hfEZ4PKmgWDYFr Rlo6WzulcbGC3+z5ik67a887NJHH4sGiFbFWrgI9hxrePWge1IvAfxkQ3okxvZ15/Cq7gBL5J3ZI 0FXI5bVVcPnDgsQ5qjCGSfhb3np0t3psidrBgXBr40SrQ8+gXmpDIgdxAAAAAAAA --Apple-Mail-5-212250142-- --Apple-Mail-6-212250154 Content-Type: application/pgp-signature; x-mac-type=70674453; name="PGP.sig" Content-Description: This is a digitally signed message part Content-Disposition: inline; filename="PGP.sig" Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJQFZT2AAoJEJq6Ou0cgrSPhhoH/A8FJo01M09RyMs0th5HGHKi ntgLKeMG9Ow3n4OLzq07q72d/XbDO1y2/9uqyuiq36BBk8Rrct5jgQ995F5lxIYL zR0zwLXCj6wail2rPsFO1AJC09HJMnRzRLCtChhpDAVGoh7KvtkXvbNvSwr7CFbz X5Iy8TWW1P/+BG1BId+wMyHRAS65duZaI/MHwTNke+3tqHAaKQstRQnF+2WX8OSm A8UeIG6zbIDofv9wB4EegIloMgsisukDo8WYCpzhcB2e5CgROOBXwdy0hBxdLFPf nrnNILrbv1lNWbNWNwomIcmiA9nHB0i1+VGuytSYPHHTIZjT+1pM+KTpsVa+gv0= =j0vY -----END PGP SIGNATURE----- --Apple-Mail-6-212250154-- From James.H.Manger@team.telstra.com Sun Jul 29 18:49:40 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2D211E80F6 for ; Sun, 29 Jul 2012 18:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.172 X-Spam-Level: X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbnptjNkALKS for ; Sun, 29 Jul 2012 18:49:39 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id C022311E80E6 for ; Sun, 29 Jul 2012 18:49:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,676,1336312800"; d="scan'208,217";a="84342263" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 30 Jul 2012 11:49:34 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6787"; a="78222982" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipccvi.tcif.telstra.com.au with ESMTP; 30 Jul 2012 11:49:33 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Mon, 30 Jul 2012 11:49:33 +1000 From: "Manger, James H" To: "jose@ietf.org" Date: Mon, 30 Jul 2012 11:49:32 +1000 Thread-Topic: [jose] Open Issue: Representing the JWE IV as a dot-separated element Thread-Index: Ac1sShLZvlTbc+2LTtW27U8yfEpgwgBqe/uAAABfDFA= Message-ID: <255B9BB34FB7D647A506DC292726F6E114F97B728F@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E114F97B728FWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [jose] Open Issue: Representing the JWE IV as a dot-separated element X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 01:49:40 -0000 --_000_255B9BB34FB7D647A506DC292726F6E114F97B728FWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFrZSB0aGUgSVYgYSBwcmVmaXggb2YgdGhlIGNpcGhlcnRleHQgYW5kIHlvdSBzYXZlIGFub3Ro ZXIgY291cGxlIG9mIGJ5dGVzLiBQbHVzIHRoZSBJViBsZW5ndGggd291bGQgbm8gbG9uZ2VyIGJl IGRlZmluZWQgdHdpY2UgKGZpcnN0bHkgYnkgdGhlIGFsZyBkZWZpbml0aW9uOyBzZWNvbmRseSBi eSB0aGUgbGVuZ3RoIG9mIHRoZSBJViBmaWVsZCBpbiB0aGUgbWVzc2FnZSksIHdoaWNoIGF2b2lk cyBhIHBvdGVudGlhbCBpbmNvbnNpc3RlbmN5Lg0KDQpXaGlsZSB3ZSBhcmUgZG9pbmcgdGhhdCwg bWF5IGFzIHdlbGwgbWFrZSB0aGUgQUVBRCBhdXRoZW50aWNhdGlvbiB0YWcgYSBzdWZmaXggb2Yg dGhlIGNpcGhlcnRleHQuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0KRnJvbTogam9zZS1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWlr ZSBKb25lcw0KU2VudDogU2F0dXJkYXksIDI4IEp1bHkgMjAxMiA4OjQ5IEFNDQpUbzogam9zZUBp ZXRmLm9yZw0KU3ViamVjdDogW2pvc2VdIE9wZW4gSXNzdWU6IFJlcHJlc2VudGluZyB0aGUgSldF IElWIGFzIGEgZG90LXNlcGFyYXRlZCBlbGVtZW50DQoNCkFsbCB0aGUgSldFIGJsb2NrIGVuY3J5 cHRpb24gYWxnb3JpdGhtcyB3ZeKAmXJlIHVzaW5nIHJlcXVpcmUgYW4gSW5pdGlhbGl6YXRpb24g VmVjdG9yLiAgSeKAmWQgb3JpZ2luYWxseSBwdXQgdGhlIElWIGluIHRoZSBKV0UgaGVhZGVyIGJl Y2F1c2UgSSB0aG91Z2h0IGl0IHdvdWxkIGJlIG9wdGlvbmFsLCBidXQgaW4gcHJhY3RpY2UsIGl0 4oCZcyBub3QuICBBcyBhIHJlc3VsdCwgd2XigJlyZSBhbHdheXMgZG91YmxlIGJhc2U2NHVybCBl bmNvZGluZyByZXF1aXJlZCBjb250ZW50Lg0KDQpJIGRpZCBhbiBpbnZlc3RpZ2F0aW9uIGFuZCB3 ZSBjb3VsZCBzYXZlIDE1IGNoYXJhY3RlcnMgaW4gdGhlIEdDTSBleGFtcGxlIGF0IGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1lbmNyeXB0aW9uLTA0 I3NlY3Rpb24tMy4xIGFuZCAxNyBjaGFyYWN0ZXJzIGluIHRoZSBDQkMgZXhhbXBsZSBhdCBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItZW5jcnlwdGlv bi0wNCNzZWN0aW9uLTMuMiBpZiB3ZSB3ZXJlIHRvIHJlcHJlc2VudCB0aGUgSVYgYXMgYW5vdGhl ciBkb3Qtc2VwYXJhdGVkIGVsZW1lbnQgcmF0aGVyIHRoYW4gcHV0dGluZyBpdCBpbiB0aGUgaGVh ZGVyIGFuZCBkb3VibGUgYmFzZTY0dXJsIGVuY29kaW5nIGl0Lg0KDQpTaW5jZSBzaXplIG1hdHRl cnMgYSBsb3QgaW4gc29tZSB1c2UgY2FzZXMsIHdlIHNob3VsZCBjb25zaWRlciB3aGV0aGVyIHRv IGRvIHRoaXMuDQoNCknigJlsbCBhZGQgaXQgdG8gdGhlIG9wZW4gaXNzdWVzIGxpc3QgZm9yIHVz IHRvIGRpc2N1c3MgaW4gVmFuY291dmVyLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQo= --_000_255B9BB34FB7D647A506DC292726F6E114F97B728FWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4t QVUgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPk1ha2UgdGhlIElWIGEgcHJl Zml4IG9mIHRoZSBjaXBoZXJ0ZXh0IGFuZCB5b3Ugc2F2ZSBhbm90aGVyIGNvdXBsZSBvZiBieXRl cy4gUGx1cyB0aGUgSVYgbGVuZ3RoIHdvdWxkIG5vIGxvbmdlciBiZSBkZWZpbmVkIHR3aWNlIChm aXJzdGx5IGJ5IHRoZSBhbGcgZGVmaW5pdGlvbjsgc2Vjb25kbHkgYnkgdGhlIGxlbmd0aCBvZiB0 aGUgSVYgZmllbGQgaW4gdGhlIG1lc3NhZ2UpLCB3aGljaCBhdm9pZHMgYSBwb3RlbnRpYWwgaW5j b25zaXN0ZW5jeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5XaGlsZSB3ZSBhcmUgZG9p bmcgdGhhdCwgbWF5IGFzIHdlbGwgbWFrZSB0aGUgQUVBRCBhdXRoZW50aWNhdGlvbiB0YWcgYSBz dWZmaXggb2YgdGhlIGNpcGhlcnRleHQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdE Jz4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOiMxRjQ5N0QnPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0n Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gam9zZS1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPk1pa2UgSm9u ZXM8YnI+PGI+U2VudDo8L2I+IFNhdHVyZGF5LCAyOCBKdWx5IDIwMTIgODo0OSBBTTxicj48Yj5U bzo8L2I+IGpvc2VAaWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFtqb3NlXSBPcGVuIElzc3Vl OiBSZXByZXNlbnRpbmcgdGhlIEpXRSBJViBhcyBhIGRvdC1zZXBhcmF0ZWQgZWxlbWVudDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJz cDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+QWxsIHRoZSBK V0UgYmxvY2sgZW5jcnlwdGlvbiBhbGdvcml0aG1zIHdl4oCZcmUgdXNpbmcgcmVxdWlyZSBhbiBJ bml0aWFsaXphdGlvbiBWZWN0b3IuJm5ic3A7IEnigJlkIG9yaWdpbmFsbHkgcHV0IHRoZSBJViBp biB0aGUgSldFIGhlYWRlciBiZWNhdXNlIEkgdGhvdWdodCBpdCB3b3VsZCBiZSBvcHRpb25hbCwg YnV0IGluIHByYWN0aWNlLCBpdOKAmXMgbm90LiZuYnNwOyBBcyBhIHJlc3VsdCwgd2XigJlyZSBh bHdheXMgZG91YmxlIGJhc2U2NHVybCBlbmNvZGluZyByZXF1aXJlZCBjb250ZW50LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+ SSBkaWQgYW4gaW52ZXN0aWdhdGlvbiBhbmQgd2UgY291bGQgc2F2ZSAxNSBjaGFyYWN0ZXJzIGlu IHRoZSBHQ00gZXhhbXBsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWpvc2UtanNvbi13ZWItZW5jcnlwdGlvbi0wNCNzZWN0aW9uLTMuMSI+aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWVuY3J5cHRpb24t MDQjc2VjdGlvbi0zLjE8L2E+IGFuZCAxNyBjaGFyYWN0ZXJzIGluIHRoZSBDQkMgZXhhbXBsZSBh dCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNv bi13ZWItZW5jcnlwdGlvbi0wNCNzZWN0aW9uLTMuMiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWVuY3J5cHRpb24tMDQjc2VjdGlvbi0zLjI8L2E+ IGlmIHdlIHdlcmUgdG8gcmVwcmVzZW50IHRoZSBJViBhcyBhbm90aGVyIGRvdC1zZXBhcmF0ZWQg ZWxlbWVudCByYXRoZXIgdGhhbiBwdXR0aW5nIGl0IGluIHRoZSBoZWFkZXIgYW5kIGRvdWJsZSBi YXNlNjR1cmwgZW5jb2RpbmcgaXQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz5TaW5jZSBzaXplIG1hdHRlcnMgYSBsb3QgaW4g c29tZSB1c2UgY2FzZXMsIHdlIHNob3VsZCBjb25zaWRlciB3aGV0aGVyIHRvIGRvIHRoaXMuPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1F Ti1VUz5J4oCZbGwgYWRkIGl0IHRvIHRoZSBvcGVuIGlzc3VlcyBsaXN0IGZvciB1cyB0byBkaXNj dXNzIGluIFZhbmNvdXZlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Jv ZHk+PC9odG1sPg== --_000_255B9BB34FB7D647A506DC292726F6E114F97B728FWSMSG3153Vsrv_-- From Anil.Saldhana@redhat.com Mon Jul 30 09:30:35 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1904C11E809A for ; Mon, 30 Jul 2012 09:30:35 -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=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klAnbNgRzHRy for ; Mon, 30 Jul 2012 09:30:34 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 88EC321F860B for ; Mon, 30 Jul 2012 09:30:34 -0700 (PDT) Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q6UGUXKa001748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 30 Jul 2012 12:30:33 -0400 Received: from [10.3.237.3] (vpn-237-3.phx2.redhat.com [10.3.237.3]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q6UGUWgE004493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Jul 2012 12:30:32 -0400 Message-ID: <5016B6A7.30202@redhat.com> Date: Mon, 30 Jul 2012 11:30:31 -0500 From: Anil Saldhana User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: jose@ietf.org References: <4E1F6AAD24975D4BA5B16804296739436674A117@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436674A117@TK5EX14MBXC285.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------080507080304060707030506" X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 Subject: Re: [jose] Updated JWA algorithm support table X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 16:30:35 -0000 This is a multi-part message in MIME format. --------------080507080304060707030506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mike, regarding the Java JCA support, there is a open request (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6996769). Ideally someone should show this list to the Java JDK/JRE vendors (Oracle,IBM,OpenJDK) to get a list of algorithms supported. Regards, Anil On 07/27/2012 10:01 PM, Mike Jones wrote: > > New columns added for NSS and Windows native crypto, plus more data > for OS X and Ruby. Thanks to Nov Matake, Christopher Kula, Wan-Teh > Chang, Ryan Sleevi, Vijay Bharadwaj, and Brian LaMacchia for the > additional data. > > -- Mike > > *Usage* > > > > *Param Name* > > > > *Param Val* > > > > *Description* > > > > *.NET* > > > > *Windows native* > > > > *OS X* > > > > *iOS* > > > > *Java JCA* > > > > *BouncyCastle* > > > > *Android* > > > > *PHP* > > > > *PHPSecLib* > > > > *Python* > > > > *M2Crypto* > > > > *PyCrypto* > > > > *Ruby* > > > > *OpenSSL* > > > > *node.js* > > > > *NSS* > > JWS/JWE > > > > alg/int > > > > HS256 > > > > HMAC w/ SHA-256 hash > > > > YES > > > > XP SP2 > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > JWS/JWE > > > > alg/int > > > > HS384 > > > > HMAC w/ SHA-384 hash > > > > YES > > > > XP SP2 > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > JWS/JWE > > > > alg/int > > > > HS512 > > > > HMAC w/ SHA-512 hash > > > > YES > > > > XP SP2 > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > JWS > > > > alg > > > > RS256 > > > > RSA w/ SHA-256 hash > > > > YES > > > > XP SP2 > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > NO > > > > YES > > > > NO > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > JWS > > > > alg > > > > RS384 > > > > RSA w/ SHA-384 hash > > > > YES > > > > XP SP2 > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > NO > > > > YES > > > > NO > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > JWS > > > > alg > > > > RS512 > > > > RSA w/ SHA-512 hash > > > > YES > > > > XP SP2 > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > NO > > > > YES > > > > NO > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > JWS > > > > alg > > > > ES256 > > > > ECDSA w/ P-256 curve and SHA-256 hash > > > > YES > > > > Vista > > > > 10.6 > > > > NO > > > > YES? > > > > YES > > > > YES > > > > NO > > > > NO > > > > NO > > > > YES > > > > NO > > > > YES > > > > VARIES > > > > VARIES? > > > > VARIES > > JWS > > > > alg > > > > ES384 > > > > ECDSA w/ P-384 curve and SHA-384 hash > > > > YES > > > > Vista > > > > 10.6 > > > > NO > > > > YES? > > > > YES > > > > YES > > > > NO > > > > NO > > > > NO > > > > YES > > > > NO > > > > YES > > > > VARIES > > > > VARIES? > > > > VARIES > > JWS > > > > alg > > > > ES512 > > > > ECDSA w/ P-521 curve and SHA-512 hash > > > > YES > > > > Vista > > > > 10.6 > > > > NO > > > > YES? > > > > YES > > > > YES > > > > NO > > > > NO > > > > NO > > > > YES > > > > NO > > > > YES > > > > VARIES > > > > VARIES? > > > > VARIES > > JWE > > > > alg > > > > RSA1_5 > > > > RSAES-PKCS1-V1_5 > > > > YES > > > > XP SP2 > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > YES > > > > NO > > > > YES > > > > YES > > > > > > YES > > > > YES > > > > YES > > JWE > > > > alg > > > > RSA-OAEP > > > > RSAES OAEP > > > > YES > > > > XP SP2 > > > > YES? > > > > YES > > > > YES > > > > YES > > > > YES > > > > NO > > > > YES > > > > NO > > > > YES > > > > YES > > > > > > YES > > > > YES > > > > NO > > JWE > > > > alg > > > > ECDH-ES > > > > Elliptic Curve Diffie-Hellman Ephemeral Static > > > > NO* > > > > Vista > > > > NO? > > > > NO > > > > YES* > > > > YES* > > > > YES* > > > > NO > > > > NO > > > > NO > > > > YES? > > > > NO > > > > > > VARIES? > > > > VARIES? > > > > NO? > > JWE > > > > alg > > > > A128KW > > > > AES Key Wrap w/ 128 bit key > > > > NO > > > > Win7 > > > > YES > > > > YES > > > > > > YES > > > > YES > > > > NO > > > > NO > > > > NO > > > > YES > > > > YES > > > > > > YES? > > > > YES? > > > > NO > > JWE > > > > alg > > > > A256KW > > > > AES Key Wrap w/ 256 bit key > > > > NO > > > > Win7 > > > > YES > > > > YES > > > > > > YES > > > > YES > > > > NO > > > > NO > > > > NO > > > > YES > > > > YES > > > > > > YES? > > > > YES? > > > > NO > > JWE > > > > enc > > > > A128CBC > > > > AES CBC w/ 128 bit key > > > > YES* > > > > XP SP2 > > > > YES > > > > > > YES* > > > > YES* > > > > YES* > > > > YES* > > > > YES* > > > > NO > > > > YES* > > > > YES* > > > > > > YES* > > > > YES* > > > > YES* > > JWE > > > > enc > > > > A256CBC > > > > AES CBC w/ 256 bit key > > > > YES* > > > > XP SP2 > > > > YES > > > > > > YES* > > > > YES* > > > > YES* > > > > YES* > > > > YES* > > > > NO > > > > YES* > > > > YES* > > > > > > YES* > > > > YES* > > > > YES* > > JWE > > > > enc > > > > A128GCM > > > > AES GCM w/ 128 bit key > > > > Codeplex > > > > Vista SP1 > > > > NO? > > > > NO > > > > NO > > > > YES > > > > YES > > > > NO > > > > NO > > > > NO > > > > NO? > > > > NO > > > > > > YES > > > > YES > > > > NO > > JWE > > > > enc > > > > A256GCM > > > > AES GCM w/ 256 bit key > > > > Codeplex > > > > Vista SP1 > > > > NO? > > > > NO > > > > NO > > > > YES > > > > YES > > > > NO > > > > NO > > > > NO > > > > NO? > > > > NO > > > > > > YES > > > > YES > > > > NO > > JWE > > > > kdf > > > > CS256 > > > > Concat Key Derivation Function (KDF) > > > > NO > > > > Win7 > > > > > > > > NO > > > > NO > > > > NO > > > > NO > > > > NO > > > > NO > > > > NO > > > > NO > > > > > > NO > > > > NO > > > > NO > > JWE > > > > kdf > > > > CS384 > > > > Concat Key Derivation Function (KDF) > > > > NO > > > > Win7 > > > > > > > > NO > > > > NO > > > > NO > > > > NO > > > > NO > > > > NO > > > > NO > > > > NO > > > > > > NO > > > > NO > > > > NO > > JWE > > > > kdf > > > > CS512 > > > > Concat Key Derivation Function (KDF) > > > > NO > > > > Win7 > > > > > > > > NO > > > > NO > > > > NO > > > > NO > > > > NO > > > > NO > > > > NO > > > > NO > > > > > > NO > > > > NO > > > > NO > > > > > > > > > > > > > > > > > > > > > > > YES - Support built into library/platform > > > > > > > > > /BouncyCastle is a crypto lib for Java/ > > > > > > > > > > /Release/- Support included in this release of software and later > > > > > > > > > > /Android uses BouncyCastle/ > > > > > > > > > > YES* - Supported but other non-supported code required (Concat KDF) > > > > > > > > > > > > /PHPSecLib is a crypto lib for PHP/ > > > > > > > VARIES - In sources but often distributed w/ support compiled out > > > > > > > > > > > > > /M2Crypto is a crypto lib for Python/ > > > > > > NO - Not supported in library/platform > > > > > > > > > > > > > > /PyCrypto is a crypto lib for Python/ > > > > > NO* - Not supported in the specified configuration (w/ Concat KDF) > > > > > > > > > > > > > > > /NSS is the crypto lib used by Firefox/ > > > > (blank) - Unknown > > > > > > > > > > > > > > > > > > > ? - Answer is a first impression but requires more research > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > PHP version 5.2 > > > > > > > > > > > > > > > > > > > PHPSecLib version 0.3.0 > > > > > > > > > > > > > > > > > > > > PyCrypto version 2.6 > > > > > > > > > > > > > > > > > > > > Ruby 1.9.3 with ruby-openssl > > > > > > > > > > > > > > > > > > > > Java 7 > > > > > > > > > > > > > > > > > > > > > > OS X 10.6 (Snow Leopard) > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --------------080507080304060707030506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Mike,
  regarding the Java JCA support, there is a open request (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6996769).  Ideally someone should show this list to the Java JDK/JRE vendors (Oracle,IBM,OpenJDK) to get a list of algorithms supported.

Regards,
Anil

On 07/27/2012 10:01 PM, Mike Jones wrote:

New columns added for NSS and Windows native crypto, plus more data for OS X and Ruby.  Thanks to Nov Matake, Christopher Kula, Wan-Teh Chang, Ryan Sleevi, Vijay Bharadwaj, and Brian LaMacchia for the additional data.

 

                                                            -- Mike

 

Usage

Param Name

Param Val

Description

.NET

Windows native

OS X

iOS

Java JCA

BouncyCastle

Android

PHP

PHPSecLib

Python

M2Crypto

PyCrypto

Ruby

OpenSSL

node.js

NSS

JWS/JWE

alg/int

HS256

HMAC w/ SHA-256 hash 

YES

XP SP2

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

JWS/JWE

alg/int

HS384

HMAC w/ SHA-384 hash

YES

XP SP2

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

JWS/JWE

alg/int

HS512

HMAC w/ SHA-512 hash

YES

XP SP2

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

JWS

alg

RS256

RSA w/ SHA-256 hash

YES

XP SP2

YES

YES

YES

YES

YES

NO

YES

NO

YES

YES

YES

YES

YES

YES

JWS

alg

RS384

RSA w/ SHA-384 hash 

YES

XP SP2

YES

YES

YES

YES

YES

NO

YES

NO

YES

YES

YES

YES

YES

YES

JWS

alg

RS512

RSA w/ SHA-512 hash

YES

XP SP2

YES

YES

YES

YES

YES

NO

YES

NO

YES

YES

YES

YES

YES

YES

JWS

alg

ES256

ECDSA w/ P-256 curve and SHA-256 hash

YES

Vista

10.6

NO

YES?

YES

YES

NO

NO

NO

YES

NO

YES

VARIES

VARIES?

VARIES

JWS

alg

ES384

ECDSA w/ P-384 curve and SHA-384 hash 

YES

Vista

10.6

NO

YES?

YES

YES

NO

NO

NO

YES

NO

YES

VARIES

VARIES?

VARIES

JWS

alg

ES512

ECDSA w/ P-521 curve and SHA-512 hash

YES

Vista

10.6

NO

YES?

YES

YES

NO

NO

NO

YES

NO

YES

VARIES

VARIES?

VARIES

JWE

alg

RSA1_5

RSAES-PKCS1-V1_5

YES

XP SP2

YES

YES

YES

YES

YES

YES

YES

NO

YES

YES

 

YES

YES

YES

JWE

alg

RSA-OAEP

RSAES OAEP

YES

XP SP2

YES?

YES

YES

YES

YES

NO

YES

NO

YES

YES

 

YES

YES

NO

JWE

alg

ECDH-ES

Elliptic Curve Diffie-Hellman Ephemeral Static

NO*

Vista

NO?

NO

YES*

YES*

YES*

NO

NO

NO

YES?

NO

 

VARIES?

VARIES?

NO?

JWE

alg

A128KW

AES Key Wrap w/ 128 bit key

NO

Win7

YES

YES

 

YES

YES

NO

NO

NO

YES

YES

 

YES?

YES?

NO

JWE

alg

A256KW

AES Key Wrap w/ 256 bit key

NO

Win7

YES

YES

 

YES

YES

NO

NO

NO

YES

YES

 

YES?

YES?

NO

JWE

enc

A128CBC

AES CBC w/ 128 bit key

YES*

XP SP2

YES

 

YES*

YES*

YES*

YES*

YES*

NO

YES*

YES*

 

YES*

YES*

YES*

JWE

enc

A256CBC

AES CBC w/ 256 bit key

YES*

XP SP2

YES

 

YES*

YES*

YES*

YES*

YES*

NO

YES*

YES*

 

YES*

YES*

YES*

JWE

enc

A128GCM

AES GCM w/ 128 bit key

Codeplex

Vista SP1

NO?

NO

NO

YES

YES

NO

NO

NO

NO?

NO

 

YES

YES

NO

JWE

enc

A256GCM

AES GCM w/ 256 bit key

Codeplex

Vista SP1

NO?

NO

NO

YES

YES

NO

NO

NO

NO?

NO

 

YES

YES

NO

JWE

kdf

CS256

Concat Key Derivation Function (KDF)

NO

Win7

 

 

NO

NO

NO

NO

NO

NO

NO

NO

 

NO

NO

NO

JWE

kdf

CS384

Concat Key Derivation Function (KDF)

NO

Win7

 

 

NO

NO

NO

NO

NO

NO

NO

NO

 

NO

NO

NO

JWE

kdf

CS512

Concat Key Derivation Function (KDF)

NO

Win7

 

 

NO

NO

NO

NO

NO

NO

NO

NO

 

NO

NO

NO




















YES - Support built into library/platform




BouncyCastle is a crypto lib for Java






Release - Support included in this release of software and later





Android uses BouncyCastle






YES* - Supported but other non-supported code required (Concat KDF)







PHPSecLib is a crypto lib for PHP



VARIES - In sources but often distributed w/ support compiled out








M2Crypto is a crypto lib for Python


NO - Not supported in library/platform









PyCrypto is a crypto lib for Python

NO* - Not supported in the specified configuration (w/ Concat KDF)










NSS is the crypto lib used by Firefox

(blank) - Unknown















? - Answer is a first impression but requires more research



































PHP version 5.2















PHPSecLib version 0.3.0
















PyCrypto version 2.6
















Ruby 1.9.3 with ruby-openssl
















Java 7


















OS X 10.6 (Snow Leopard)
















 



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

--------------080507080304060707030506-- From internet-drafts@ietf.org Mon Jul 30 22:50:21 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1566011E80AD; Mon, 30 Jul 2012 22:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqnDJODU-pqn; Mon, 30 Jul 2012 22:50:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7302E11E80E2; Mon, 30 Jul 2012 22:50:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120731055020.22928.46131.idtracker@ietfa.amsl.com> Date: Mon, 30 Jul 2012 22:50:20 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-signature-05.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 05:50:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Signature (JWS) Author(s) : Michael B. Jones John Bradley Nat Sakimura Filename : draft-ietf-jose-json-web-signature-05.txt Pages : 41 Date : 2012-07-30 Abstract: JSON Web Signature (JWS) is a means of representing content secured with digital signatures or Message Authentication Codes (MACs) using JavaScript Object Notation (JSON) data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-signature-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 30 22:53:06 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AABC11E80E2; Mon, 30 Jul 2012 22:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id au7CucLNowMi; Mon, 30 Jul 2012 22:53:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A1711E80EE; Mon, 30 Jul 2012 22:53:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120731055305.32184.33293.idtracker@ietfa.amsl.com> Date: Mon, 30 Jul 2012 22:53:05 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-05.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 05:53:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Encryption (JWE) Author(s) : Michael B. Jones Eric Rescorla Joe Hildebrand Filename : draft-ietf-jose-json-web-encryption-05.txt Pages : 46 Date : 2012-07-30 Abstract: JSON Web Encryption (JWE) is a means of representing encrypted content using JavaScript Object Notation (JSON) data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. Related digital signature and MAC capabilities are described in the separate JSON Web Signature (JWS) specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 30 22:56:32 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198DD21F84F5; Mon, 30 Jul 2012 22:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgfHYU0ZzO2z; Mon, 30 Jul 2012 22:56:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8966821F8517; Mon, 30 Jul 2012 22:56:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120731055631.2237.20638.idtracker@ietfa.amsl.com> Date: Mon, 30 Jul 2012 22:56:31 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-key-05.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 05:56:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Key (JWK) Author(s) : Michael B. Jones Filename : draft-ietf-jose-json-web-key-05.txt Pages : 12 Date : 2012-07-30 Abstract: A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a public key. This specification also defines a JSON Web Key Set (JWK Set) JSON data structure for representing a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-key-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-key-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 30 22:59:20 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC6411E80D7; Mon, 30 Jul 2012 22:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbx18AohuFdQ; Mon, 30 Jul 2012 22:59:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D92B11E80E2; Mon, 30 Jul 2012 22:59:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120731055919.5400.628.idtracker@ietfa.amsl.com> Date: Mon, 30 Jul 2012 22:59:19 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-05.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 05:59:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : JSON Web Algorithms (JWA) Author(s) : Michael B. Jones Filename : draft-ietf-jose-json-web-algorithms-05.txt Pages : 43 Date : 2012-07-30 Abstract: The JSON Web Algorithms (JWA) specification enumerates cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-algorithms-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Michael.Jones@microsoft.com Mon Jul 30 23:45:08 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E64B11E80B8 for ; Mon, 30 Jul 2012 23:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+GIPDNGm-2L for ; Mon, 30 Jul 2012 23:45:07 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id C20ED11E80A3 for ; Mon, 30 Jul 2012 23:45:06 -0700 (PDT) Received: from mail93-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.23; Tue, 31 Jul 2012 06:45:06 +0000 Received: from mail93-ch1 (localhost [127.0.0.1]) by mail93-ch1-R.bigfish.com (Postfix) with ESMTP id 3B159420443 for ; Tue, 31 Jul 2012 06:45:06 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VS-19(zzc89bhc857hzz1202hzz1033IL8275eh8275bh8275dha1495iz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail93-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail93-ch1 (localhost.localdomain [127.0.0.1]) by mail93-ch1 (MessageSwitch) id 1343717103698963_31856; Tue, 31 Jul 2012 06:45:03 +0000 (UTC) Received: from CH1EHSMHS013.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.240]) by mail93-ch1.bigfish.com (Postfix) with ESMTP id 9F451180048 for ; Tue, 31 Jul 2012 06:45:03 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS013.bigfish.com (10.43.70.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 31 Jul 2012 06:45:01 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.222]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0309.003; Tue, 31 Jul 2012 06:44:59 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: IETF 84 versions of JOSE and JWT specifications Thread-Index: Ac1u5+qgapYDZwctTP6FwzT7YY/2IQ== Date: Tue, 31 Jul 2012 06:44:58 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436674D14F@TK5EX14MBXC285.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436674D14FTK5EX14MBXC285r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [jose] IETF 84 versions of JOSE and JWT specifications X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 06:45:08 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436674D14FTK5EX14MBXC285r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmXZlIG1hZGUgYSBtaW5vciByZWxlYXNlIG9mIHRoZSBKU09OIFdFQiB7U2lnbmF0dXJlLEVu Y3J5cHRpb24sS2V5LEFsZ29yaXRobXMsVG9rZW59IChKV1MsIEpXRSwgSldLLCBKV0EsIEpXVCkg c3BlY2lmaWNhdGlvbnMgdG8gc3VwcG9ydCB0aGUgd29ya2luZyBncm91cCBkaXNjdXNzaW9ucyBh dCBJRVRGIDg0IGluIFZhbmNvdXZlciwgQkM8aHR0cDovL3d3dy5pZXRmLm9yZy9tZWV0aW5nLzg0 L2luZGV4Lmh0bWw+LiAgVGhpcyByZWxlYXNlIGluY29ycG9yYXRlcyB3b3JraW5nIGdyb3VwIGZl ZWRiYWNrIHNpbmNlIHRoZSBtaW5vciByZWxlYXNlIG9uIEp1bHkgMTZ0aDxodHRwOi8vc2VsZi1p c3N1ZWQuaW5mby8/cD03OTE+IGFuZCB1cGRhdGVzIHRoZSBsaXN0cyBvZiBvcGVuIGlzc3VlcyBp biB0aGUgSldFIGFuZCBKV0Egc3BlY2lmaWNhdGlvbnMuDQoNClRoZSBzcGVjaWZpY2F0aW9ucyBh cmUgYXZhaWxhYmxlIGF0Og0KDQrCtyAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLXNpZ25hdHVyZS0wNQ0KDQrCtyAgICAgICAgaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWVuY3J5cHRpb24t MDUNCg0KwrcgICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9z ZS1qc29uLXdlYi1rZXktMDUNCg0KwrcgICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zLTA1DQoNCsK3ICAgICAgICBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTAz DQoNClRoZSBkb2N1bWVudCBoaXN0b3J5IGVudHJpZXMgKGFsc28gaW4gdGhlIHNwZWNpZmljYXRp b25zKSBhcmUgYXMgZm9sbG93czoNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1qb3NlLWpzb24td2ViLXNpZ25hdHVyZS0wNQ0KDQogICogICBBZGRlZCBzdGF0ZW1lbnQg dGhhdCAiU3RyaW5nT3JVUkkgdmFsdWVzIGFyZSBjb21wYXJlZCBhcyBjYXNlLXNlbnNpdGl2ZSBz dHJpbmdzIHdpdGggbm8gdHJhbnNmb3JtYXRpb25zIG9yIGNhbm9uaWNhbGl6YXRpb25zIGFwcGxp ZWQiLg0KICAqICAgSW5kZW50ZWQgYXJ0d29yayBlbGVtZW50cyB0byBiZXR0ZXIgZGlzdGluZ3Vp c2ggdGhlbSBmcm9tIHRoZSBib2R5IHRleHQuDQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1lbmNyeXB0aW9uLTA1DQoNCiAgKiAgIFN1cHBvcnQg Ym90aCBkaXJlY3QgZW5jcnlwdGlvbiB1c2luZyBhIHNoYXJlZCBvciBhZ3JlZWQgdXBvbiBzeW1t ZXRyaWMga2V5LCBhbmQgdGhlIHVzZSBvZiBhIHNoYXJlZCBvciBhZ3JlZWQgdXBvbiBzeW1tZXRy aWMga2V5IHRvIGtleSB3cmFwIHRoZSBDTUsuDQogICogICBBZGRlZCBzdGF0ZW1lbnQgdGhhdCAi U3RyaW5nT3JVUkkgdmFsdWVzIGFyZSBjb21wYXJlZCBhcyBjYXNlLXNlbnNpdGl2ZSBzdHJpbmdz IHdpdGggbm8gdHJhbnNmb3JtYXRpb25zIG9yIGNhbm9uaWNhbGl6YXRpb25zIGFwcGxpZWQiLg0K ICAqICAgVXBkYXRlZCBvcGVuIGlzc3Vlcy4NCiAgKiAgIEluZGVudGVkIGFydHdvcmsgZWxlbWVu dHMgdG8gYmV0dGVyIGRpc3Rpbmd1aXNoIHRoZW0gZnJvbSB0aGUgYm9keSB0ZXh0Lg0KDQpodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIta2V5LTA1DQoN CiAgKiAgIEluZGVudGVkIGFydHdvcmsgZWxlbWVudHMgdG8gYmV0dGVyIGRpc3Rpbmd1aXNoIHRo ZW0gZnJvbSB0aGUgYm9keSB0ZXh0Lg0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcy0wNQ0KDQogICogICBTdXBwb3J0IGJvdGgg ZGlyZWN0IGVuY3J5cHRpb24gdXNpbmcgYSBzaGFyZWQgb3IgYWdyZWVkIHVwb24gc3ltbWV0cmlj IGtleSwgYW5kIHRoZSB1c2Ugb2YgYSBzaGFyZWQgb3IgYWdyZWVkIHVwb24gc3ltbWV0cmljIGtl eSB0byBrZXkgd3JhcCB0aGUgQ01LLiBTcGVjaWZpY2FsbHksIGFkZGVkIHRoZSBhbGcgdmFsdWVz IGRpciwgRUNESC1FUytBMTI4S1csIGFuZCBFQ0RILUVTK0EyNTZLVyB0byBmaW5pc2ggZmlsbGlu ZyBpbiB0aGlzIHNldCBvZiBjYXBhYmlsaXRpZXMuDQogICogICBVcGRhdGVkIG9wZW4gaXNzdWVz Lg0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWpzb24td2Vi LXRva2VuLTAzDQoNCiAgKiAgIEFkZGVkIHN0YXRlbWVudCB0aGF0ICJTdHJpbmdPclVSSSB2YWx1 ZXMgYXJlIGNvbXBhcmVkIGFzIGNhc2Utc2Vuc2l0aXZlIHN0cmluZ3Mgd2l0aCBubyB0cmFuc2Zv cm1hdGlvbnMgb3IgY2Fub25pY2FsaXphdGlvbnMgYXBwbGllZCIuDQogICogICBJbmRlbnRlZCBh cnR3b3JrIGVsZW1lbnRzIHRvIGJldHRlciBkaXN0aW5ndWlzaCB0aGVtIGZyb20gdGhlIGJvZHkg dGV4dC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgLS0gTWlrZQ0KDQoNCg== --_000_4E1F6AAD24975D4BA5B16804296739436674D14FTK5EX14MBXC285r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9z ZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 IjsNCgljb2xvcjojMDAzMzY2O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFn cmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1h cmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJ bWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxT dHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjMyOTI2MjE5NDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTc4NDI3MDkz ODt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6ODgyOTg3NDY3 Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo3NjgzNTcw NjAgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz dCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVs Nw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6OTQwODM2MzA5Ow0K CW1zby1saXN0LXRlbXBsYXRlLWlkczotODcxNDA2ODY7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci Ow0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwyOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVs Nw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwzDQoJe21zby1saXN0LWlkOjEwNDE5MDY0ODA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi04NDAyMzcwODg7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwz OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0DQoJe21zby1saXN0LWlk OjE0MTY4NTQ4OTY7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjIyMTI1OTE3MDt9DQpAbGlzdCBs NDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsMg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 fQ0KQGxpc3QgbDQ6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDQ6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDUNCgl7bXNvLWxpc3QtaWQ6MTQyMDk3OTM5NDsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6ODgwMDYxMDQ0O30NCkBsaXN0IGw1OmxldmVsMQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28t YmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsNTpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsNTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs NTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNTpsZXZlbDcNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsNTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNg0K CXttc28tbGlzdC1pZDoxNTQ2NTk5MTgyOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotMjA0NDQyODYzMCA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2 NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpA bGlzdCBsNjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsNjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGw2OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw2OmxldmVsNA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDY6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDY6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDY6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsNjpsZXZlbDkNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNw0K CXttc28tbGlzdC1pZDoxODAzMjMxNjEwOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMzY3MTQ0 MTg7fQ0KQGxpc3QgbDc6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNzpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iO30NCkBsaXN0IGw3OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGw3OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw3OmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw3OmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGw3OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGw3OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw3OmxldmVsOQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw4DQoJe21zby1saXN0LWlkOjE4NTU0MTc2 MTQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMzczMjExMjQ7fQ0KQGxpc3QgbDg6bGV2ZWwx DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsODpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0 IGw4OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw4OmxldmVsNA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw4OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGw4OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw4 OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw4OmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw4OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0 LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGw5DQoJe21zby1saXN0LWlkOjE4Nzk2NTkxNjY7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOjE2ODU3MTg4MDQ7fQ0KQGxpc3QgbDk6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Oi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsOTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGw5OmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGw5OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGw5OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw5OmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw5OmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGw5OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGw5OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMA0KCXttc28t bGlzdC1pZDoxOTA5NzI1Njc3Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTQ3OTY3MTQzMDt9 DQpAbGlzdCBsMTA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTA6bGV2ZWwy DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIjt9DQpAbGlzdCBsMTA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDEwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMDpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTA6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDEwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwxMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDExDQoJe21zby1saXN0LWlkOjIw NDc5NDc5MzU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0zMzIxMjEzNjg7fQ0KQGxpc3QgbDEx OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDExOmxldmVsMg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 fQ0KQGxpc3QgbDExOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMTps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTE6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDExOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoz LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwxMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTE6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDExOmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdp bi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5J4oCZdmUgbWFkZSBhIG1pbm9yIHJlbGVhc2Ugb2YgdGhlIEpTT04gV0VCIHtT aWduYXR1cmUsRW5jcnlwdGlvbixLZXksQWxnb3JpdGhtcyxUb2tlbn0gKEpXUywgSldFLCBKV0ss IEpXQSwgSldUKSBzcGVjaWZpY2F0aW9ucyB0byBzdXBwb3J0IHRoZSB3b3JraW5nIGdyb3VwIGRp c2N1c3Npb25zIGF0DQo8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21lZXRpbmcvODQvaW5k ZXguaHRtbCI+SUVURiA4NCBpbiBWYW5jb3V2ZXIsIEJDPC9hPi4mbmJzcDsgVGhpcyByZWxlYXNl IGluY29ycG9yYXRlcyB3b3JraW5nIGdyb3VwIGZlZWRiYWNrIHNpbmNlIHRoZQ0KPGEgaHJlZj0i aHR0cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9NzkxIj5taW5vciByZWxlYXNlIG9uIEp1bHkgMTY8 c3VwPnRoPC9zdXA+PC9hPiBhbmQgdXBkYXRlcyB0aGUgbGlzdHMgb2Ygb3BlbiBpc3N1ZXMgaW4g dGhlIEpXRSBhbmQgSldBIHNwZWNpZmljYXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGUgc3BlY2lmaWNhdGlvbnMgYXJlIGF2YWlsYWJsZSBhdDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0 Omw2IGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpz b24td2ViLXNpZ25hdHVyZS0wNSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1qb3NlLWpzb24td2ViLXNpZ25hdHVyZS0wNTwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omw2 IGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24t d2ViLWVuY3J5cHRpb24tMDUiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt am9zZS1qc29uLXdlYi1lbmNyeXB0aW9uLTA1PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDYg bGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13 ZWIta2V5LTA1Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNv bi13ZWIta2V5LTA1PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDYgbGV2ZWwxIGxmbzEiPjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcy0w NSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFs Z29yaXRobXMtMDU8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsNiBsZXZlbDEgbGZvMSI+PCFb aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMDMiPmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4t MDM8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBkb2N1bWVudCBoaXN0b3J5IGVudHJp ZXMgKGFsc28gaW4gdGhlIHNwZWNpZmljYXRpb25zKSBhcmUgYXMgZm9sbG93czo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1qb3NlLWpzb24td2ViLXNpZ25hdHVyZS0wNSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLXNpZ25hdHVyZS0wNTwvYT48bzpwPjwvbzpwPjwv cD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbGlzdDpsOCBsZXZlbDEgbGZvOSI+PHNw YW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkFkZGVkIHN0YXRlbWVudCB0aGF0ICZxdW90O1N0cmluZ09yVVJJ IHZhbHVlcyBhcmUgY29tcGFyZWQgYXMgY2FzZS1zZW5zaXRpdmUgc3RyaW5ncyB3aXRoIG5vIHRy YW5zZm9ybWF0aW9ucyBvciBjYW5vbmljYWxpemF0aW9ucyBhcHBsaWVkJnF1b3Q7Lg0KPG86cD48 L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNr O21zby1saXN0Omw4IGxldmVsMSBsZm85Ij48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SW5kZW50ZWQg YXJ0d29yayBlbGVtZW50cyB0byBiZXR0ZXIgZGlzdGluZ3Vpc2ggdGhlbSBmcm9tIHRoZSBib2R5 IHRleHQuPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItZW5jcnlwdGlv bi0wNSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2Vi LWVuY3J5cHRpb24tMDU8L2E+PG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6 MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6Ymxh Y2s7bXNvLWxpc3Q6bDcgbGV2ZWwxIGxmbzEwIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U3VwcG9y dCBib3RoIGRpcmVjdCBlbmNyeXB0aW9uIHVzaW5nIGEgc2hhcmVkIG9yIGFncmVlZCB1cG9uIHN5 bW1ldHJpYyBrZXksIGFuZCB0aGUgdXNlIG9mIGEgc2hhcmVkIG9yIGFncmVlZCB1cG9uIHN5bW1l dHJpYyBrZXkgdG8NCiBrZXkgd3JhcCB0aGUgQ01LLiA8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLWxpc3Q6bDcgbGV2ZWwx IGxmbzEwIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QWRkZWQgc3RhdGVtZW50IHRoYXQgJnF1b3Q7 U3RyaW5nT3JVUkkgdmFsdWVzIGFyZSBjb21wYXJlZCBhcyBjYXNlLXNlbnNpdGl2ZSBzdHJpbmdz IHdpdGggbm8gdHJhbnNmb3JtYXRpb25zIG9yIGNhbm9uaWNhbGl6YXRpb25zIGFwcGxpZWQmcXVv dDsuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i Y29sb3I6YmxhY2s7bXNvLWxpc3Q6bDcgbGV2ZWwxIGxmbzEwIj48c3BhbiBsYW5nPSJFTiIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+VXBkYXRlZCBvcGVuIGlzc3Vlcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbGlzdDpsNyBsZXZlbDEgbGZvMTAi PjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JbmRlbnRlZCBhcnR3b3JrIGVsZW1lbnRzIHRvIGJldHRl ciBkaXN0aW5ndWlzaCB0aGVtIGZyb20gdGhlIGJvZHkgdGV4dC48bzpwPjwvbzpwPjwvc3Bhbj48 L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtam9zZS1qc29uLXdlYi1rZXktMDUiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1rZXktMDU8L2E+PG86cD48L286cD48L3A+DQo8dWwg c3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLWxpc3Q6bDUgbGV2ZWwxIGxmbzEyIj48c3BhbiBsYW5n PSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+SW5kZW50ZWQgYXJ0d29yayBlbGVtZW50cyB0byBiZXR0ZXIgZGlzdGluZ3Vp c2ggdGhlbSBmcm9tIHRoZSBib2R5IHRleHQuPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpv c2UtanNvbi13ZWItYWxnb3JpdGhtcy0wNSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXMtMDU8L2E+PG86cD48L286cD48L3A+DQo8 dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLWxpc3Q6bDExIGxldmVsMSBsZm8xMSI+PHNwYW4g bGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPlN1cHBvcnQgYm90aCBkaXJlY3QgZW5jcnlwdGlvbiB1c2luZyBhIHNo YXJlZCBvciBhZ3JlZWQgdXBvbiBzeW1tZXRyaWMga2V5LCBhbmQgdGhlIHVzZSBvZiBhIHNoYXJl ZCBvciBhZ3JlZWQgdXBvbiBzeW1tZXRyaWMga2V5IHRvDQoga2V5IHdyYXAgdGhlIENNSy4gU3Bl Y2lmaWNhbGx5LCBhZGRlZCB0aGUgPC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzAwMzM2NiI+YWxnPC9zcGFuPjxz cGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdmFsdWVzDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMDAzMzY2Ij5kaXI8 L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiwNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMwMDMzNjYiPkVD REgtRVMmIzQzO0ExMjhLVzwvc3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LCBhbmQNCjwvc3Bh bj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOiMwMDMzNjYiPkVDREgtRVMmIzQzO0EyNTZLVzwvc3Bhbj48c3BhbiBsYW5nPSJF TiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IHRvIGZpbmlzaCBmaWxsaW5nIGluIHRoaXMgc2V0IG9mIGNhcGFiaWxpdGllcy4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xv cjpibGFjazttc28tbGlzdDpsMTEgbGV2ZWwxIGxmbzExIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ VXBkYXRlZCBvcGVuIGlzc3Vlcy48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtanNv bi13ZWItdG9rZW4tMDMiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1 dGgtanNvbi13ZWItdG9rZW4tMDM8L2E+PG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdp bi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29s b3I6YmxhY2s7bXNvLWxpc3Q6bDUgbGV2ZWwxIGxmbzEyIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ QWRkZWQgc3RhdGVtZW50IHRoYXQgJnF1b3Q7U3RyaW5nT3JVUkkgdmFsdWVzIGFyZSBjb21wYXJl ZCBhcyBjYXNlLXNlbnNpdGl2ZSBzdHJpbmdzIHdpdGggbm8gdHJhbnNmb3JtYXRpb25zIG9yIGNh bm9uaWNhbGl6YXRpb25zIGFwcGxpZWQmcXVvdDsuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLWxpc3Q6bDUgbGV2ZWwx IGxmbzEyIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SW5kZW50ZWQgYXJ0d29yayBlbGVtZW50cyB0 byBiZXR0ZXIgZGlzdGluZ3Vpc2ggdGhlbSBmcm9tIHRoZSBib2R5IHRleHQuPG86cD48L286cD48 L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_4E1F6AAD24975D4BA5B16804296739436674D14FTK5EX14MBXC285r_--