From Michael.Jones@microsoft.com Thu Nov 1 04:38: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 F106721F84C9 for ; Thu, 1 Nov 2012 04:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKNc0uyXL1Vl for ; Thu, 1 Nov 2012 04:38:33 -0700 (PDT) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.29]) by ietfa.amsl.com (Postfix) with ESMTP id 22B2E21F84BE for ; Thu, 1 Nov 2012 04:38:32 -0700 (PDT) Received: from BL2FFO11FD008.protection.gbl (10.173.161.203) by BL2FFO11HUB032.protection.gbl (10.173.161.56) with Microsoft SMTP Server (TLS) id 15.0.545.8; Thu, 1 Nov 2012 11:38:29 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD008.mail.protection.outlook.com (10.173.161.4) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Thu, 1 Nov 2012 11:38:28 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.15]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Thu, 1 Nov 2012 11:38:10 +0000 From: Mike Jones To: Axel Nennker , "jose@ietf.org" Thread-Topic: [jose] jwk Thread-Index: AQHNsiF/w0zq/rO+/0GqJ4iKlhRQdpfI5BAggAAQvQCAB5mvgIAAbyUAgAPWBDA= Date: Thu, 1 Nov 2012 11:38:09 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436688578C@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436687BCEB@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943668828D9@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.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436688578CTK5EX14MBXC285r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51444002)(377454001)(479174001)(4396001)(54316001)(16406001)(550184003)(47976001)(5343655001)(44976002)(5343635001)(47446002)(46102001)(47736001)(15202345001)(31966008)(49866001)(53806001)(51856001)(74502001)(33656001)(512954001)(74662001)(50986001)(54356001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0652EA5565 Subject: Re: [jose] jwk 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, 01 Nov 2012 11:38:36 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436688578CTK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sitting next to Eric Rescorla and Richard Barnes at the WebCrypto F2F, they= just provided additional useful information on your question, Axel. Speci= fically, they pointed out that a standard ASN.1 representation of bare keys= is the DER encoding of the RFC 5280 SubjectPublicKeyInfo element (which co= ntains an algorithm and a key representation) - often referred to as SPKI. = Just to be clear, this is not a certificate (containing no signature, subj= ect, etc.). So a fair question is whether JOSE also wants to support SPKI public keys, = rather than just X.509 certificates and JWK keys. I hear you saying "yes",= Axel, and I think Nat was saying "yes" as well. Discussions last week at = the F2F OpenID Connect working meeting also makes me think that some others= would also answer this "yes". If we want to do this, would people suggest that we do this with a new head= er parameter containing a SPKI key value? Also, would we always pass SPKI = keys by value, or do people believe that it's also important to pass them b= y reference (just like we have both x5c and x5u parameters)? -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Axe= l Nennker Sent: Monday, October 29, 2012 4:56 PM To: Mike Jones Cc: jose@ietf.org Subject: Re: [jose] jwk Encoding public keys as self-signed certs: That is a hack. Not that I am op= posed to hacks but this is too much. 2012/10/29 Mike Jones > "x5c" helps because you can represent a bare key as a self-signed cert in P= EM format in the "x5c" parameter. The JOSE specs already support PEM-encod= ed keys. -- Mike From: Axel Nennker [mailto:ignisvulpis@gmail.com] Sent: Wednesday, October 24, 2012 2:14 PM To: Mike Jones Cc: jose@ietf.org Subject: Re: jwk In the case where I generate the keypair on the fly I do not have an URL to= put in x5u. And a cert in not a public key. I want bare keys. I don't know how x5u and x5c help here. I have the problem that I don't know how to convert (exp,mod) into a pubkey= on one platform (Firefox). I think that PEM is easier. I think the same might be true an other platforms too. Another reason I think that PEM is better is that there are command line to= ols to produce PEM-encoded keys while I don't know any tool to produce (exp= , mod). --Axel 2012/10/24 Mike Jones > To be clear, JWS and JWE already support the use of PEM encoded keys throug= h the "x5c" and "x5u" parameters. Therefore, I don't see any need to also = add X.509-based key formats to JWK itself. -- Mike From: Axel Nennker [mailto:ignisvulpis@gmail.com] Sent: Wednesday, October 24, 2012 12:55 PM To: jose@ietf.org Cc: Mike Jones Subject: jwk I think that having more choices other than (xpo, mod) is useful. I believe that it is easier for me to implement keys in Firefox if I have P= EM encoded keys. So the format could be: user_jwk : {"pub": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4OTqe0p1tgE= oOVtDzjQI yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ3h9ecj4p5E355umCThN/1doBc/tq18VGl= NtyDNxCh45Z1zGYJKwZxaVaWQXlB2gfgnko1D+Zw9KIlipQHtnhJw/qREEIp4YOgaGcSZBCcQQ4= DYCOjfTTbKUXSTlrlOgflfgTiyhUFuiKWkoeivwASigL76PtYNYc n+dlYKYB/vSQ2CY7FtaDcr= 22EdqUDVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk KX9Ek68zDzelOaJxs2tbkkwbqSLQfREz= Q/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB" } // PEM encoded public key without linebreaks A more general format would be: jwk: { "-----BEGIN PUBLIC KEY-----": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBC= gKCAQEA4OTqe0p1tgEoOVtDzjQI yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ3h9ecj4p5E355um= CThN/1doBc/tq18VGlNtyDNxCh45Z1zGYJKwZxaVaWQXlB2gfgnko1D+Zw9KIlipQHtnhJw/qRE= EIp4YOgaGcSZBCcQQ4DYCOjfTTbKUXSTlrlOgflfgTiyhUFuiKWkoeivwASigL76PtYNYc n+dl= YKYB/vSQ2CY7FtaDcr22EdqUDVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk KX9Ek68zDzelOa= Jxs2tbkkwbqSLQfREzQ/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB" } This general format could be used for private keys too. What do you think? Axel ps: Don't know whether I can post from this email address.... Mike, would y= ou lease post it if it does appear in your inbox but not on the list. Thank= s. --_000_4E1F6AAD24975D4BA5B16804296739436688578CTK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sitting next to Eric Resc= orla and Richard Barnes at the WebCrypto F2F, they just provided additional= useful information on your question, Axel.  Specifically, they pointed out that a standard ASN.1 representation of bare keys is the = DER encoding of the RFC 5280 SubjectPublicKeyInfo element (which contains a= n algorithm and a key representation) – often referred to as SPKI.&nb= sp; Just to be clear, this is not a certificate (containing no signature, subject, etc.).

 <= /p>

So a fair question is whe= ther JOSE also wants to support SPKI public keys, rather than just X.509 ce= rtificates and JWK keys.  I hear you saying “yes”, Axel, and I think Nat was saying “yes” as well.  Discussions la= st week at the F2F OpenID Connect working meeting also makes me think that = some others would also answer this “yes”.

 <= /p>

If we want to do this, wo= uld people suggest that we do this with a new header parameter containing a= SPKI key value?  Also, would we always pass SPKI keys by value, or do people believe that it’s also important to pass them by= reference (just like we have both x5c and x5u parameters)?

 <= /p>

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

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Axel Nennker
Sent: Monday, October 29, 2012 4:56 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: Re: [jose] jwk

 

Encoding public keys = as self-signed certs: That is a hack. Not that I am opposed to hacks but th= is is too much.

2012/10/29 Mike Jones <Michael.Jones@microsoft.com><= o:p>

“x5c” helps because you can= represent a bare key as a self-signed cert in PEM format in the “x5c= ” parameter.  The JOSE specs already support PEM-encoded keys.

 

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

 

From: Axel Nennker [mailto:<= a href=3D"mailto:ignisvulpis@gmail.com" target=3D"_blank">ignisvulpis@gmail= .com]
Sent: Wednesday, October 24, 2012 2:14 PM
To: Mike Jones
Cc: jose@ietf.org=
Subject: Re: jwk

 

In the case where I generate the keypair on the fly I do not have an URL= to put in x5u. And a cert in not a public key. I want bare keys.
I don't know how x5u and x5c help here.

I have the problem that I don't know how to convert (exp,mod) into a pubkey= on one platform (Firefox). I think that PEM is easier.
I think the same might be true an other platforms too.

Another reason I think that PEM is better is that there are command line to= ols to produce PEM-encoded keys while I don't know any tool to produce (exp= , mod).

--Axel

2012/10/24 Mike Jones <Michael.Jones@microsoft.com>

To be clear, JWS and JWE already support the use of PEM encoded keys thr= ough the "x5c" and "x5u" parameters.  Therefore, I= don't see any need to also add X.509-based key formats to JWK itself.=

 

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

 

From: Axel Nennker [mailto:<= a href=3D"mailto:ignisvulpis@gmail.com" target=3D"_blank">ignisvulpis@gmail= .com]
Sent: Wednesday, October 24, 2012 12:55 PM
To: jose@ietf.org=
Cc: Mike Jones
Subject: jwk

 


I think that having more choices other than (xpo, mod) is useful.
I believe that it is easier for me to implement keys in Firefox if I have P= EM encoded keys.

So the format could be:

user_jwk : {"pub": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC= AQEA4OTqe0p1tgEoOVtDzjQI yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ3h9ecj4p5E355umCTh= N/1doBc/tq18VGlNtyDNxCh45Z1zGYJKwZxaVaWQXlB2gfgnko1D+Zw9KIlipQHtnhJw/qR= EEIp4YOgaGcSZBCcQQ4DYCOjfTTbKUXSTlrlOgflfgTiyhUFuiKWkoeivwASigL76PtYNYc n+dlYKYB/vSQ2CY7FtaDcr22EdqUDVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk K= X9Ek68zDzelOaJxs2tbkkwbqSLQfREzQ/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB&qu= ot; }
// PEM encoded public key without linebreaks

A more general format would be:

jwk: { "-----BEGIN PUBLIC KEY-----": "MIIBIjANBgkqhkiG9w0BAQ= EFAAOCAQ8AMIIBCgKCAQEA4OTqe0p1tgEoOVtDzjQI yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ= 3h9ecj4p5E355umCThN/1doBc/tq18VGlNtyDNxCh45Z1zGYJKwZxaVaWQXlB2gfgnko1D+= Zw9KIlipQHtnhJw/qREEIp4YOgaGcSZBCcQQ4DYCOjfTTbKUXSTlrlOgflfgTiyhUFuiKWkoeiv= wASigL76PtYNYc n+dlYKYB/vSQ2CY7FtaDcr22EdqUDVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk K= X9Ek68zDzelOaJxs2tbkkwbqSLQfREzQ/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB&qu= ot;
}

This general format could be used for private keys too.

What do you think?

Axel

ps: Don't know whether I can post from this email address.... Mike, would y= ou lease post it if it does appear in your inbox but not on the list. Thank= s.

 

 

--_000_4E1F6AAD24975D4BA5B16804296739436688578CTK5EX14MBXC285r_-- From Axel.Nennker@telekom.de Thu Nov 1 05:41: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 0DDA621F8C1A for ; Thu, 1 Nov 2012 05:41:28 -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=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dn2qQh3pCe4C for ; Thu, 1 Nov 2012 05:41:25 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 21DB221F8C28 for ; Thu, 1 Nov 2012 05:41:23 -0700 (PDT) Received: from he113415.emea1.cds.t-internal.com ([10.125.65.81]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 01 Nov 2012 13:41:21 +0100 Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.94]) by HE113415.emea1.cds.t-internal.com ([2002:7cd:4151::7cd:4151]) with mapi; Thu, 1 Nov 2012 13:41:21 +0100 From: To: , , Date: Thu, 1 Nov 2012 13:41:20 +0100 Thread-Topic: [jose] jwk Thread-Index: AQHNsiF/w0zq/rO+/0GqJ4iKlhRQdpfI5BAggAAQvQCAB5mvgIAAbyUAgAPWBDCAACHEIA== Message-ID: References: <4E1F6AAD24975D4BA5B16804296739436687BCEB@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943668828D9@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436688578C@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436688578C@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_CE8995AB5D178F44A2154F5C9A97CAF4025219A6572EHE111541eme_" MIME-Version: 1.0 Subject: Re: [jose] jwk 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, 01 Nov 2012 12:41:28 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF4025219A6572EHE111541eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think that the example public keys that I used in my email (Oct 24) are e= xactly that. Base64-encoded-subjectpublickeyinfo From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik= e Jones Sent: Thursday, November 01, 2012 12:38 PM To: Axel Nennker; jose@ietf.org Subject: Re: [jose] jwk Sitting next to Eric Rescorla and Richard Barnes at the WebCrypto F2F, they= just provided additional useful information on your question, Axel. Speci= fically, they pointed out that a standard ASN.1 representation of bare keys= is the DER encoding of the RFC 5280 SubjectPublicKeyInfo element (which co= ntains an algorithm and a key representation) - often referred to as SPKI. = Just to be clear, this is not a certificate (containing no signature, subj= ect, etc.). So a fair question is whether JOSE also wants to support SPKI public keys, = rather than just X.509 certificates and JWK keys. I hear you saying "yes",= Axel, and I think Nat was saying "yes" as well. Discussions last week at = the F2F OpenID Connect working meeting also makes me think that some others= would also answer this "yes". If we want to do this, would people suggest that we do this with a new head= er parameter containing a SPKI key value? Also, would we always pass SPKI = keys by value, or do people believe that it's also important to pass them b= y reference (just like we have both x5c and x5u parameters)? -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Axe= l Nennker Sent: Monday, October 29, 2012 4:56 PM To: Mike Jones Cc: jose@ietf.org Subject: Re: [jose] jwk Encoding public keys as self-signed certs: That is a hack. Not that I am op= posed to hacks but this is too much. 2012/10/29 Mike Jones > "x5c" helps because you can represent a bare key as a self-signed cert in P= EM format in the "x5c" parameter. The JOSE specs already support PEM-encod= ed keys. -- Mike From: Axel Nennker [mailto:ignisvulpis@gmail.com] Sent: Wednesday, October 24, 2012 2:14 PM To: Mike Jones Cc: jose@ietf.org Subject: Re: jwk In the case where I generate the keypair on the fly I do not have an URL to= put in x5u. And a cert in not a public key. I want bare keys. I don't know how x5u and x5c help here. I have the problem that I don't know how to convert (exp,mod) into a pubkey= on one platform (Firefox). I think that PEM is easier. I think the same might be true an other platforms too. Another reason I think that PEM is better is that there are command line to= ols to produce PEM-encoded keys while I don't know any tool to produce (exp= , mod). --Axel 2012/10/24 Mike Jones > To be clear, JWS and JWE already support the use of PEM encoded keys throug= h the "x5c" and "x5u" parameters. Therefore, I don't see any need to also = add X.509-based key formats to JWK itself. -- Mike From: Axel Nennker [mailto:ignisvulpis@gmail.com] Sent: Wednesday, October 24, 2012 12:55 PM To: jose@ietf.org Cc: Mike Jones Subject: jwk I think that having more choices other than (xpo, mod) is useful. I believe that it is easier for me to implement keys in Firefox if I have P= EM encoded keys. So the format could be: user_jwk : {"pub": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4OTqe0p1tgE= oOVtDzjQI yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ3h9ecj4p5E355umCThN/1doBc/tq18VGl= NtyDNxCh45Z1zGYJKwZxaVaWQXlB2gfgnko1D+Zw9KIlipQHtnhJw/qREEIp4YOgaGcSZBCcQQ4= DYCOjfTTbKUXSTlrlOgflfgTiyhUFuiKWkoeivwASigL76PtYNYc n+dlYKYB/vSQ2CY7FtaDcr= 22EdqUDVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk KX9Ek68zDzelOaJxs2tbkkwbqSLQfREz= Q/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB" } // PEM encoded public key without linebreaks A more general format would be: jwk: { "-----BEGIN PUBLIC KEY-----": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBC= gKCAQEA4OTqe0p1tgEoOVtDzjQI yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ3h9ecj4p5E355um= CThN/1doBc/tq18VGlNtyDNxCh45Z1zGYJKwZxaVaWQXlB2gfgnko1D+Zw9KIlipQHtnhJw/qRE= EIp4YOgaGcSZBCcQQ4DYCOjfTTbKUXSTlrlOgflfgTiyhUFuiKWkoeivwASigL76PtYNYc n+dl= YKYB/vSQ2CY7FtaDcr22EdqUDVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk KX9Ek68zDzelOa= Jxs2tbkkwbqSLQfREzQ/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB" } This general format could be used for private keys too. What do you think? Axel ps: Don't know whether I can post from this email address.... Mike, would y= ou lease post it if it does appear in your inbox but not on the list. Thank= s. --_000_CE8995AB5D178F44A2154F5C9A97CAF4025219A6572EHE111541eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think t= hat the example public keys that I used in my email (Oct 24) are exactly th= at. Base64-encoded-subjectpublickeyinfo

 

Fro= m: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Mike Jones
Sent: Thursday, November 01, 2012 12:38 PM
T= o: Axel Nennker; jose@ietf.org
Subject: Re: [jose] jwk

 

Sitting next to Eric Rescorla and Richard Barnes at t= he WebCrypto F2F, they just provided additional useful information on your = question, Axel.  Specifically, they pointed out that a standard ASN.1 = representation of bare keys is the DER encoding of the RFC 5280 SubjectPubl= icKeyInfo element (which contains an algorithm and a key representation) &#= 8211; often referred to as SPKI.  Just to be clear, this is not a cert= ificate (containing no signature, subject, etc.).

 

So a fair question is whether JOSE also wants to support SPKI public k= eys, rather than just X.509 certificates and JWK keys.  I hear you say= ing “yes”, Axel, and I think Nat was saying “yes” a= s well.  Discussions last week at the F2F OpenID Connect working meeti= ng also makes me think that some others would also answer this “yes&#= 8221;.

 

If we want to do this, would people su= ggest that we do this with a new header parameter containing a SPKI key val= ue?  Also, would we always pass SPKI keys by value, or do people belie= ve that it’s also important to pass them by reference (just like we h= ave both x5c and x5u parameters)?

 

  = ;            &n= bsp;            = ;            &n= bsp;            = ;        -- Mike

 

= From:= jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Axel Nennker
Sent: Monday, October 29, 2012 4:56 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: Re: [jose] jwk=

 

Encoding public keys as self-signe= d certs: That is a hack. Not that I am opposed to hacks but this is too muc= h.

2012/10/29 Mike Jones <Michael.Jones@mi= crosoft.com>

“x5c”= helps because you can represent a bare key as a self-signed cert in PEM fo= rmat in the “x5c” parameter.  The JOSE specs already suppo= rt PEM-encoded keys.

 <= /o:p>

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

 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>From: Axel Nennker [mailto:ignisvulpis@gmail.com]
Sent: Wednesday, Octob= er 24, 2012 2:14 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: Re:= jwk

 

In the cas= e where I generate the keypair on the fly I do not have an URL to put in x5= u. And a cert in not a public key. I want bare keys.
I don't know how x5= u and x5c help here.

I have the problem that I don't know how to con= vert (exp,mod) into a pubkey on one platform (Firefox). I think that PEM is= easier.
I think the same might be true an other platforms too.

A= nother reason I think that PEM is better is that there are command line too= ls to produce PEM-encoded keys while I don't know any tool to produce (exp,= mod).

--Axel

2012/10/24 Mike Jones <Michael.Jone= s@microsoft.com>

To be clear, JWS and JWE= already support the use of PEM encoded keys through the "x5c" an= d "x5u" parameters.  Therefore, I don't see any need to also= add X.509-based key formats to JWK itself.

 

           = ;            &n= bsp;            = ;            &n= bsp;           -- Mike

 

From: Axel Nennk= er [mailto:ignis= vulpis@gmail.com]
Sent: Wednesday, October 24, 2012 12:55 PM=
To: jose@ietf= .org
Cc: Mike Jones
Subject: jwk<= /p>

 


I think that having mor= e choices other than (xpo, mod) is useful.
I believe that it is easier f= or me to implement keys in Firefox if I have PEM encoded keys.

So th= e format could be:

user_jwk : {"pub": "MIIBIjANBgkqhk= iG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4OTqe0p1tgEoOVtDzjQI yP1Ipo8ivqTIeH4yH9kLzI4f= CKx6ggZJ3h9ecj4p5E355umCThN/1doBc/tq18VGlNtyDNxCh45Z1zGYJKwZxaVaWQXlB2gfgnk= o1D+Zw9KIlipQHtnhJw/qREEIp4YOgaGcSZBCcQQ4DYCOjfTTbKUXSTlrlOgflfgTiyhUFuiKWk= oeivwASigL76PtYNYc n+dlYKYB/vSQ2CY7FtaDcr22EdqUDVPLNg1+K1rsvHvllP7iTnXA5Igx= T5JELdrk KX9Ek68zDzelOaJxs2tbkkwbqSLQfREzQ/yGAIOW9rZVqlaVBEBzUYzREmeybVq3 g= wIDAQAB" }
// PEM encoded public key without linebreaks

A m= ore general format would be:

jwk: { "-----BEGIN PUBLIC KEY-----= ": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4OTqe0p1tgEoOVtDz= jQI yP1Ipo8ivqTIeH4yH9kLzI4fCKx6ggZJ3h9ecj4p5E355umCThN/1doBc/tq18VGlNtyDNx= Ch45Z1zGYJKwZxaVaWQXlB2gfgnko1D+Zw9KIlipQHtnhJw/qREEIp4YOgaGcSZBCcQQ4DYCOjf= TTbKUXSTlrlOgflfgTiyhUFuiKWkoeivwASigL76PtYNYc n+dlYKYB/vSQ2CY7FtaDcr22EdqU= DVPLNg1+K1rsvHvllP7iTnXA5IgxT5JELdrk KX9Ek68zDzelOaJxs2tbkkwbqSLQfREzQ/yGAI= OW9rZVqlaVBEBzUYzREmeybVq3 gwIDAQAB"
}

This general format c= ould be used for private keys too.

What do you think?

Axel
ps: Don't know whether I can post from this email address.... Mike, wo= uld you lease post it if it does appear in your inbox but not on the list. = Thanks.

 

 

= --_000_CE8995AB5D178F44A2154F5C9A97CAF4025219A6572EHE111541eme_-- From dick.hardt@gmail.com Fri Nov 2 08:21: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 A131911E80A3 for ; Fri, 2 Nov 2012 08:21:47 -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.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGB7dd13F2G0 for ; Fri, 2 Nov 2012 08:21:47 -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 2D5C411E8099 for ; Fri, 2 Nov 2012 08:21:47 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so2540996pbb.31 for ; Fri, 02 Nov 2012 08:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer; bh=qK3UzxnlucdV5Iph4kSrc0adO1Tz9+Nslwn8lAsPSVg=; b=zyNCh/dAlNXawqtjUNu1tjtp0O7+97JL6CJ0utN5So03IDin0c3jtt2wHJx+X48nQd RAdyMokcg8vasGOS9bVcl+v1bcNvvRXVklYnAYVxO7nMTI2i3L6rMriDrs9vNgPUZzll HACgs1OZwHbQCnuBC7NLNYS1iq7LXeMfswhLk+9wJxWI+8Hc92n8z3uSghKpoqqKHpx6 uo7aj5Ci6RzRRsq0IW3IzBsf1Iuos0HBdx27uTQJSWmzv55jyWeXskJZK55ATmj7Dlsm EDDAvYe3oPX5NonW/ucFU69g1x4QVMIrfDu8HUqs116ZlDs6IbJYgLVsACUYv4Gcudeu LWXA== Received: by 10.68.219.163 with SMTP id pp3mr7181403pbc.13.1351869706997; Fri, 02 Nov 2012 08:21:46 -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 e9sm5871460paz.28.2012.11.02.08.21.45 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Nov 2012 08:21:46 -0700 (PDT) From: Dick Hardt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4ACFC778-31A9-4C79-9F4E-7C01719F51AD@gmail.com> Date: Fri, 2 Nov 2012 08:21:44 -0700 To: "jose@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [jose] encrypting AND signing a token 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, 02 Nov 2012 15:21:47 -0000 I am trying to figure out how to implement JWT/JWS/JWE to solve a real = world problem. 1) Bob sends a token to Charlie via Alice. (Alice gets token from Bob = and then Alice gives token to Charlie)=20 2) Alice must be prevented from reading the token. (token needs to be = encrypted) 3) Bob and Charlie can share a symmetric key. I can solve this with JWE. Now let's add another condition. 4) Charlie wants non-repuditation that Bob created the token.=20 5) Bob has a private key and a public key I don't see how to do this using JWE. It seems I have to sign the same = token I had previously with JWS. This seems inefficient since I should = be able to replace the JWE integrity computation done with the symmetric = key with the private key -- but the "alg" parameter is the same in both = encrypting and signing.=20 Now let's expand this to replacing the symmetric key with a = public/private key pair for encryption. Bob encrypts with Charlies = public key and signs with Bob's private key (we also need to make sure = we are not doing naive encryption and signing here, would be a really = useful to specify what needs to be done there). Now we need to have = parameters for both public/private key pairs in the header. Am I missing something here? Seems like we can do this if we change the header parameters to specify = if they ("alg", "kid", et.c) are for token signing, payload encryption = or content key encryption. -- Dick From Michael.Jones@microsoft.com Fri Nov 2 08:47: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 5B74111E8099 for ; Fri, 2 Nov 2012 08:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPsJhIoAmvTr for ; Fri, 2 Nov 2012 08:47:05 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.27]) by ietfa.amsl.com (Postfix) with ESMTP id BF33F1F0C42 for ; Fri, 2 Nov 2012 08:47:04 -0700 (PDT) Received: from BL2FFO11FD006.protection.gbl (10.173.161.204) by BL2FFO11HUB035.protection.gbl (10.173.161.115) with Microsoft SMTP Server (TLS) id 15.0.545.8; Fri, 2 Nov 2012 15:47:02 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD006.mail.protection.outlook.com (10.173.161.2) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Fri, 2 Nov 2012 15:47:01 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.15]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Fri, 2 Nov 2012 15:46:29 +0000 From: Mike Jones To: Dick Hardt , "jose@ietf.org" Thread-Topic: [jose] encrypting AND signing a token Thread-Index: AQHNuQ3ME+O2ePBNwUCi7ftO2XMizpfWrXtw Date: Fri, 2 Nov 2012 15:46:28 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366887325@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4ACFC778-31A9-4C79-9F4E-7C01719F51AD@gmail.com> In-Reply-To: <4ACFC778-31A9-4C79-9F4E-7C01719F51AD@gmail.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464001)(479174001)(377454001)(46102001)(31966008)(47776002)(47446002)(44976002)(49866001)(74502001)(54356001)(4396001)(74662001)(51856001)(53806001)(33656001)(47976001)(47736001)(76482001)(5343655001)(50466001)(16406001)(50986001)(48376001)(54316001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 06530126A4 Subject: Re: [jose] encrypting AND signing a token 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, 02 Nov 2012 15:47:06 -0000 The way you put it brings one straightforward solution to mind. Solve 1-3 = with a JWE. Solve 4-5 by signing the JWE as a JWS payload. Done. I do understand that the 4/3 space blowup-of double base64url encoding the = JWE motivates your earlier proposal about nested signing. (See Dick's 10/2= 9/12 message "[jose] signing an existing JWT".) I also understand that if = you could do integrity with the asymmetric signature then the integrity pro= vided by the JWE itself may be redundant. I don't have a specific proposal= on how to do that. -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Dic= k Hardt Sent: Friday, November 02, 2012 8:22 AM To: jose@ietf.org Subject: [jose] encrypting AND signing a token I am trying to figure out how to implement JWT/JWS/JWE to solve a real worl= d problem. 1) Bob sends a token to Charlie via Alice. (Alice gets token from Bob and t= hen Alice gives token to Charlie)=20 2) Alice must be prevented from reading the token. (token needs to be encry= pted) 3) Bob and Charlie can share a symmetric key. I can solve this with JWE. Now let's add another condition. 4) Charlie wants non-repuditation that Bob created the token.=20 5) Bob has a private key and a public key I don't see how to do this using JWE. It seems I have to sign the same toke= n I had previously with JWS. This seems inefficient since I should be able = to replace the JWE integrity computation done with the symmetric key with t= he private key -- but the "alg" parameter is the same in both encrypting an= d signing.=20 Now let's expand this to replacing the symmetric key with a public/private = key pair for encryption. Bob encrypts with Charlies public key and signs wi= th Bob's private key (we also need to make sure we are not doing naive encr= yption and signing here, would be a really useful to specify what needs to = be done there). Now we need to have parameters for both public/private key = pairs in the header. Am I missing something here? Seems like we can do this if we change the header parameters to specify if = they ("alg", "kid", et.c) are for token signing, payload encryption or cont= ent key encryption. -- Dick _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From dick.hardt@gmail.com Fri Nov 2 09:30: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 6A33E11E809C for ; Fri, 2 Nov 2012 09:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFnJ+AIJiY7M for ; Fri, 2 Nov 2012 09:30:02 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id CF9D811E809A for ; Fri, 2 Nov 2012 09:30:02 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so2582585pad.31 for ; Fri, 02 Nov 2012 09:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=G8nJWtfbzg4/PhUea6OimvEbQEFsBJuYstqYVgvJQ5g=; b=KroVWxKuEq1zMPCR+meOMN2fcJYoQ/0r7kL/D+Lee3lWkKqsdDLFAdU2T1BbLetEAL 3VD2S16q+Jn3+kbXtJnU/Imqe0465RjDHBlFvmVFP4AK3zei61yMhYhmLz/lDB0nkdhq 5121V5es6IBsSI4pKm4ph4FnSOD1rE9vvcIfHp75LYWPOFRamklETmWnydkkx5bunvZp Ck/1uldqOdZdrfvUeEItyuRrbRXctTt3jzYmDMYU+J2jOJk10tw4trQIPWC1ezrvi7oq 0tR2oEwRW970mrtQgUop982jucDNRWOAGb28v2o3yVmUCy0DFlvMkdPmODw+egLOeXKB qqPQ== Received: by 10.66.78.4 with SMTP id x4mr6659004paw.60.1351873802450; Fri, 02 Nov 2012 09:30:02 -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 hs1sm5984064pbc.33.2012.11.02.09.29.54 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Nov 2012 09:29:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366887325@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Fri, 2 Nov 2012 09:29:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4ACFC778-31A9-4C79-9F4E-7C01719F51AD@gmail.com> <4E1F6AAD24975D4BA5B168042967394366887325@TK5EX14MBXC285.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1499) Cc: jose@ietf.org Subject: Re: [jose] encrypting AND signing a token 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, 02 Nov 2012 16:30:03 -0000 Not only is my original token increasing in size by 4/3, I am also = adding another header, payload and signature. One of the objectives of JWT was to enabled compact tokens. It would = seem that we should be able to support both signing and encryption of = the same token. All the encryption use cases I can think of involving asymmetric keys = would also require signing with the senders private key.=20 My suggestion is to be explicit in what the algorithm etc. is used for: Rather than "alg" and "enc", we have: "algs" - algorithm for token signing "algk" - algorithm for content management key encryption "alge" - algorithm for payload encryption Similiarly, "kids" - key id for signing "kidk" - key id for content managment key encryption We could probably make these three or even two letter codes if you want = to save a couple bytes. -- Dick On Nov 2, 2012, at 8:46 AM, Mike Jones = wrote: > The way you put it brings one straightforward solution to mind. Solve = 1-3 with a JWE. Solve 4-5 by signing the JWE as a JWS payload. Done. >=20 > I do understand that the 4/3 space blowup-of double base64url encoding = the JWE motivates your earlier proposal about nested signing. (See = Dick's 10/29/12 message "[jose] signing an existing JWT".) I also = understand that if you could do integrity with the asymmetric signature = then the integrity provided by the JWE itself may be redundant. I don't = have a specific proposal on how to do that. >=20 > -- Mike >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Dick Hardt > Sent: Friday, November 02, 2012 8:22 AM > To: jose@ietf.org > Subject: [jose] encrypting AND signing a token >=20 > I am trying to figure out how to implement JWT/JWS/JWE to solve a real = world problem. >=20 > 1) Bob sends a token to Charlie via Alice. (Alice gets token from Bob = and then Alice gives token to Charlie)=20 > 2) Alice must be prevented from reading the token. (token needs to be = encrypted) > 3) Bob and Charlie can share a symmetric key. >=20 > I can solve this with JWE. >=20 > Now let's add another condition. >=20 > 4) Charlie wants non-repuditation that Bob created the token.=20 > 5) Bob has a private key and a public key >=20 > I don't see how to do this using JWE. It seems I have to sign the same = token I had previously with JWS. This seems inefficient since I should = be able to replace the JWE integrity computation done with the symmetric = key with the private key -- but the "alg" parameter is the same in both = encrypting and signing.=20 >=20 > Now let's expand this to replacing the symmetric key with a = public/private key pair for encryption. Bob encrypts with Charlies = public key and signs with Bob's private key (we also need to make sure = we are not doing naive encryption and signing here, would be a really = useful to specify what needs to be done there). Now we need to have = parameters for both public/private key pairs in the header. >=20 > Am I missing something here? >=20 > Seems like we can do this if we change the header parameters to = specify if they ("alg", "kid", et.c) are for token signing, payload = encryption or content key encryption. >=20 > -- Dick >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From turners@ieca.com Sun Nov 4 06:09: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 CA70221F8632 for ; Sun, 4 Nov 2012 06:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.936 X-Spam-Level: X-Spam-Status: No, score=-101.936 tagged_above=-999 required=5 tests=[AWL=-0.663, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srNmJOkyv6De for ; Sun, 4 Nov 2012 06:09:56 -0800 (PST) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.93.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3355721F85FD for ; Sun, 4 Nov 2012 06:09:49 -0800 (PST) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id B2793613601AD; Sun, 4 Nov 2012 08:09:48 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway02.websitewelcome.com (Postfix) with ESMTP id A7D1E6136018D for ; Sun, 4 Nov 2012 08:09:48 -0600 (CST) Received: from [130.129.19.104] (port=49857 helo=dhcp-1368.meeting.ietf.org) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TV0tY-0000Do-Gg for jose@ietf.org; Sun, 04 Nov 2012 08:09:48 -0600 Message-ID: <50955510.7030000@ieca.com> Date: Sat, 03 Nov 2012 13:32:00 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "jose@ietf.org" References: <4E1F6AAD24975D4BA5B168042967394366853BB5@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114FDD5151B@WSMSG3153V.srv.dir.telstra.com> <8AC56264-8B09-48BA-802F-6B30577419E9@bbn.com> In-Reply-To: <8AC56264-8B09-48BA-802F-6B30577419E9@bbn.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: (dhcp-1368.meeting.ietf.org) [130.129.19.104]:49857 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [jose] xpo 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, 04 Nov 2012 14:09:57 -0000 +1 On 10/16/12 7:15 PM, Richard Barnes wrote: > +1 > > On Oct 16, 2012, at 6:55 PM, Manger, James H wrote: > >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-06 >>> • Changed the name of the JWK RSA exponent parameter from exp to xpo so as to allow the potential use of the name exp for a future extension that might define an expiration parameter for keys. (The exp name is already used for this purpose in the JWT specification.) >> >> "n" and "e" would be better than "mod" and "xpo". >> "n" and "e" are very widely used for the RSA modulus and public exponent. >> >> s^e = m mod n >> >> -- >> 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 > From sakimura@gmail.com Sun Nov 4 06:14: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 0315821F86AF for ; Sun, 4 Nov 2012 06:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.754 X-Spam-Level: X-Spam-Status: No, score=0.754 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFtIylrQ9rT6 for ; Sun, 4 Nov 2012 06:14:54 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5793A21F86AB for ; Sun, 4 Nov 2012 06:14:54 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id k13so2212759eaa.31 for ; Sun, 04 Nov 2012 06:14:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:mime-version:in-reply-to:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=o/+E5XgIbTEZuRqbvIcNvAs4sF9jIx/JX65eVNmoUzs=; b=Nvrt9sS8aV3LlDqn7yiHBe09HjzoK44KlFMnlXHduX/7MIUmf3pmXkrrgpD/rprb3/ MmetAo6lvapCr522W1Uspq3FBeQebnqE9LGVtm+JiIr35cpB2AMRuDImP1IUgDSGNvsv /9mfsnh+q9AbC7vQo8zLBauzCwBmv5cN8XXHjXCNfTlOxeOl0gQ4IoWED7npnTcBgufv zuPPN1ny2HKRZlHV3rI5Vk3JoL09CrFTdHodhx+CPqBy3o8zW24se4o/JvDdX7Pc4Ny3 jClCm9yjpZXyTYU3jGNoieWDsPgYDSxTpJgll/XoeHHFsVFc8LKcvf+11F8WYsoM2us6 xoQA== Received: by 10.14.172.195 with SMTP id t43mr26900091eel.17.1352038493582; Sun, 04 Nov 2012 06:14:53 -0800 (PST) References: <4E1F6AAD24975D4BA5B168042967394366853BB5@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114FDD5151B@WSMSG3153V.srv.dir.telstra.com> <8AC56264-8B09-48BA-802F-6B30577419E9@bbn.com> <50955510.7030000@ieca.com> From: Nat Sakimura Mime-Version: 1.0 (1.0) In-Reply-To: <50955510.7030000@ieca.com> Date: Sun, 4 Nov 2012 09:14:53 -0500 Message-ID: <-7585918764096795770@unknownmsgid> To: Sean Turner Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: base64 Cc: "jose@ietf.org" Subject: Re: [jose] xpo 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, 04 Nov 2012 14:14:55 -0000 KzEKCk5vdiA0LCAyMDEyIDk6MTAbJEIhIhsoQlNlYW4gVHVybmVyIDx0dXJuZXJzQGllY2EuY29t PiAbJEIkTiVhJUMlOyE8JTgbKEI6Cgo+ICsxCj4KPiBPbiAxMC8xNi8xMiA3OjE1IFBNLCBSaWNo YXJkIEJhcm5lcyB3cm90ZToKPj4gKzEKPj4KPj4gT24gT2N0IDE2LCAyMDEyLCBhdCA2OjU1IFBN LCBNYW5nZXIsIEphbWVzIEggd3JvdGU6Cj4+Cj4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS0wNgo+Pj4+ICogQ2hhbmdlZCB0aGUgbmFt ZSBvZiB0aGUgSldLIFJTQSBleHBvbmVudCBwYXJhbWV0ZXIgZnJvbSBleHAgdG8geHBvIHNvIGFz IHRvIGFsbG93IHRoZSBwb3RlbnRpYWwgdXNlIG9mIHRoZSBuYW1lIGV4cCBmb3IgYSBmdXR1cmUg ZXh0ZW5zaW9uIHRoYXQgbWlnaHQgZGVmaW5lIGFuIGV4cGlyYXRpb24gcGFyYW1ldGVyIGZvciBr ZXlzLiAoVGhlIGV4cCBuYW1lIGlzIGFscmVhZHkgdXNlZCBmb3IgdGhpcyBwdXJwb3NlIGluIHRo ZSBKV1Qgc3BlY2lmaWNhdGlvbi4pCj4+Pgo+Pj4gIm4iIGFuZCAiZSIgd291bGQgYmUgYmV0dGVy IHRoYW4gIm1vZCIgYW5kICJ4cG8iLgo+Pj4gIm4iIGFuZCAiZSIgYXJlIHZlcnkgd2lkZWx5IHVz ZWQgZm9yIHRoZSBSU0EgbW9kdWx1cyBhbmQgcHVibGljIGV4cG9uZW50Lgo+Pj4KPj4+IHNeZSA9 IG0gbW9kIG4KPj4+Cj4+PiAtLQo+Pj4gSmFtZXMgTWFuZ2VyCj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4gam9zZSBtYWlsaW5nIGxpc3QKPj4+ IGpvc2VAaWV0Zi5vcmcKPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v am9zZQo+Pgo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xwo+PiBqb3NlIG1haWxpbmcgbGlzdAo+PiBqb3NlQGlldGYub3JnCj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCj4gam9zZSBtYWlsaW5nIGxpc3QKPiBqb3NlQGlldGYub3Jn Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlCg== From ietf@augustcellars.com Sun Nov 4 10:24: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 E122121F8721 for ; Sun, 4 Nov 2012 10:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQDA-4ode3Sl for ; Sun, 4 Nov 2012 10:24:19 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0A10F21F86A0 for ; Sun, 4 Nov 2012 10:24:19 -0800 (PST) Received: from Philemon (dhcp-469b.meeting.ietf.org [130.129.70.155]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 54DEB2CA07; Sun, 4 Nov 2012 10:24:18 -0800 (PST) From: "Jim Schaad" To: "'Dick Hardt'" , "'Mike Jones'" References: <4ACFC778-31A9-4C79-9F4E-7C01719F51AD@gmail.com> <4E1F6AAD24975D4BA5B168042967394366887325@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: Date: Sun, 4 Nov 2012 13:24:09 -0500 Message-ID: <000b01cdbab9$967ef070$c37cd150$@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: AQJk3UBi+7c9NJolq0gv1z0r2pGfkgJRTlTwAoSEM22WhQko4A== Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] encrypting AND signing a token 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, 04 Nov 2012 18:24:20 -0000 I would note that the original PKCS#7 specifications had a mode that provided a similar sign and encrypt as a single operation mode. When the PKCS#7 specifications where adopted by the IETF as part of the CMS work, this mode was discussed and very deliberately dropped because of numerous security problems that had been found. These included (but are not limited to) the fact that it was signed or who signed it was sometimes a security leak. Also there were attacks where the signed and encrypted mode could be converted to just an encrypted mode. I would think that there would be a need for a very detailed security analysis that we are not prepared to do in order to support a signed and encrypted mode. Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Dick Hardt > Sent: Friday, November 02, 2012 12:30 PM > To: Mike Jones > Cc: jose@ietf.org > Subject: Re: [jose] encrypting AND signing a token > > Not only is my original token increasing in size by 4/3, I am also adding > another header, payload and signature. > > One of the objectives of JWT was to enabled compact tokens. It would seem > that we should be able to support both signing and encryption of the same > token. > > All the encryption use cases I can think of involving asymmetric keys would > also require signing with the senders private key. > > My suggestion is to be explicit in what the algorithm etc. is used for: > > Rather than "alg" and "enc", we have: > > "algs" - algorithm for token signing > "algk" - algorithm for content management key encryption "alge" - algorithm > for payload encryption > > Similiarly, > > "kids" - key id for signing > "kidk" - key id for content managment key encryption > > We could probably make these three or even two letter codes if you want to > save a couple bytes. > > -- Dick > > On Nov 2, 2012, at 8:46 AM, Mike Jones > wrote: > > > The way you put it brings one straightforward solution to mind. Solve 1-3 > with a JWE. Solve 4-5 by signing the JWE as a JWS payload. Done. > > > > I do understand that the 4/3 space blowup-of double base64url encoding > the JWE motivates your earlier proposal about nested signing. (See Dick's > 10/29/12 message "[jose] signing an existing JWT".) I also understand that if > you could do integrity with the asymmetric signature then the integrity > provided by the JWE itself may be redundant. I don't have a specific proposal > on how to do that. > > > > -- Mike > > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > > Of Dick Hardt > > Sent: Friday, November 02, 2012 8:22 AM > > To: jose@ietf.org > > Subject: [jose] encrypting AND signing a token > > > > I am trying to figure out how to implement JWT/JWS/JWE to solve a real > world problem. > > > > 1) Bob sends a token to Charlie via Alice. (Alice gets token from Bob > > and then Alice gives token to Charlie) > > 2) Alice must be prevented from reading the token. (token needs to be > > encrypted) > > 3) Bob and Charlie can share a symmetric key. > > > > I can solve this with JWE. > > > > Now let's add another condition. > > > > 4) Charlie wants non-repuditation that Bob created the token. > > 5) Bob has a private key and a public key > > > > I don't see how to do this using JWE. It seems I have to sign the same token > I had previously with JWS. This seems inefficient since I should be able to > replace the JWE integrity computation done with the symmetric key with the > private key -- but the "alg" parameter is the same in both encrypting and > signing. > > > > Now let's expand this to replacing the symmetric key with a public/private > key pair for encryption. Bob encrypts with Charlies public key and signs with > Bob's private key (we also need to make sure we are not doing naive > encryption and signing here, would be a really useful to specify what needs > to be done there). Now we need to have parameters for both public/private > key pairs in the header. > > > > Am I missing something here? > > > > Seems like we can do this if we change the header parameters to specify if > they ("alg", "kid", et.c) are for token signing, payload encryption or content > key encryption. > > > > -- Dick > > > > > > _______________________________________________ > > 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 dick.hardt@gmail.com Sun Nov 4 11: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 98B4D21F8785 for ; Sun, 4 Nov 2012 11:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.742 X-Spam-Level: X-Spam-Status: No, score=-4.742 tagged_above=-999 required=5 tests=[AWL=0.857, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkIofT8bFWBq for ; Sun, 4 Nov 2012 11:55:59 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id DD78821F8800 for ; Sun, 4 Nov 2012 11:55:59 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so3432016pbb.31 for ; Sun, 04 Nov 2012 11:55:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=sxl5Bp1aM4URFC5RfYOJf0WrH8WhJeUaAAYkNERujq8=; b=ywvvPtxk4/Uytr/z10oLs960fRhddedIGUohMAzFWBXVCBJaFnC76LkK9OomcWGJ6D Rof80jRnHec5rAPFA6sd6xZ+YlaBvYE8elY1cVB9ozzO76cib6bvghUiT+ka4cbJ76Zj MW2Ne1HbvVQTZhCAHLM3rOY5yYOZD31qEiOnhW6auJ9UWnkNSCFxXRMe+hauvTlB6rY3 ZN1fIkrWdD+hXBzIHATDajhV4yovMvQYhmV48CSnSxKt3a0aGGw58rbDNb6knQYEgY95 TKjhgeY1MyYpJ3W5JeDEoRrW1h/eH/6IKAbU8N9k8GyjVre0kYyjI7vcpZ6KJseMB4i/ yt1Q== Received: by 10.68.143.201 with SMTP id sg9mr24923371pbb.32.1352058959649; Sun, 04 Nov 2012 11:55:59 -0800 (PST) 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 hc4sm9295223pbc.30.2012.11.04.11.55.56 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 04 Nov 2012 11:55:58 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <000b01cdbab9$967ef070$c37cd150$@augustcellars.com> Date: Sun, 4 Nov 2012 11:55:54 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <210E03E3-FD49-449A-8953-571ECA9E5FBE@gmail.com> References: <4ACFC778-31A9-4C79-9F4E-7C01719F51AD@gmail.com> <4E1F6AAD24975D4BA5B168042967394366887325@TK5EX14MBXC285.redmond.corp.microsoft.com> <000b01cdbab9$967ef070$c37cd150$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1499) Cc: 'Mike Jones' , jose@ietf.org, 'Dick Hardt' Subject: Re: [jose] encrypting AND signing a token 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, 04 Nov 2012 19:56:00 -0000 Thanks Jim. An interesting historical reference.=20 In my use case, who signed or who the token is for is not a secret. The = payload needs to be kept a secret. Does no one sign and encrypt SAML tokens? Is this not a common use case? If it does need to be solved, it would seem to me that a standards body = would be the place to have lots of eyes look at how to sign and encrypt = a token so that people do not do naive sign and encrypt. Q: does anyone else need to sign and encrypt? -- Dick On Nov 4, 2012, at 10:24 AM, "Jim Schaad" = wrote: > >=20 > I would note that the original PKCS#7 specifications had a mode that > provided a similar sign and encrypt as a single operation mode. When = the > PKCS#7 specifications where adopted by the IETF as part of the CMS = work, > this mode was discussed and very deliberately dropped because of = numerous > security problems that had been found. These included (but are not = limited > to) the fact that it was signed or who signed it was sometimes a = security > leak. Also there were attacks where the signed and encrypted mode = could be > converted to just an encrypted mode. >=20 > I would think that there would be a need for a very detailed security > analysis that we are not prepared to do in order to support a signed = and > encrypted mode. >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of >> Dick Hardt >> Sent: Friday, November 02, 2012 12:30 PM >> To: Mike Jones >> Cc: jose@ietf.org >> Subject: Re: [jose] encrypting AND signing a token >>=20 >> Not only is my original token increasing in size by 4/3, I am also = adding >> another header, payload and signature. >>=20 >> One of the objectives of JWT was to enabled compact tokens. It would = seem >> that we should be able to support both signing and encryption of the = same >> token. >>=20 >> All the encryption use cases I can think of involving asymmetric keys > would >> also require signing with the senders private key. >>=20 >> My suggestion is to be explicit in what the algorithm etc. is used = for: >>=20 >> Rather than "alg" and "enc", we have: >>=20 >> "algs" - algorithm for token signing >> "algk" - algorithm for content management key encryption "alge" - > algorithm >> for payload encryption >>=20 >> Similiarly, >>=20 >> "kids" - key id for signing >> "kidk" - key id for content managment key encryption >>=20 >> We could probably make these three or even two letter codes if you = want to >> save a couple bytes. >>=20 >> -- Dick >>=20 >> On Nov 2, 2012, at 8:46 AM, Mike Jones >> wrote: >>=20 >>> The way you put it brings one straightforward solution to mind. = Solve > 1-3 >> with a JWE. Solve 4-5 by signing the JWE as a JWS payload. Done. >>>=20 >>> I do understand that the 4/3 space blowup-of double base64url = encoding >> the JWE motivates your earlier proposal about nested signing. (See = Dick's >> 10/29/12 message "[jose] signing an existing JWT".) I also = understand > that if >> you could do integrity with the asymmetric signature then the = integrity >> provided by the JWE itself may be redundant. I don't have a specific > proposal >> on how to do that. >>>=20 >>> -- Mike >>>=20 >>> -----Original Message----- >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf >>> Of Dick Hardt >>> Sent: Friday, November 02, 2012 8:22 AM >>> To: jose@ietf.org >>> Subject: [jose] encrypting AND signing a token >>>=20 >>> I am trying to figure out how to implement JWT/JWS/JWE to solve a = real >> world problem. >>>=20 >>> 1) Bob sends a token to Charlie via Alice. (Alice gets token from = Bob >>> and then Alice gives token to Charlie) >>> 2) Alice must be prevented from reading the token. (token needs to = be >>> encrypted) >>> 3) Bob and Charlie can share a symmetric key. >>>=20 >>> I can solve this with JWE. >>>=20 >>> Now let's add another condition. >>>=20 >>> 4) Charlie wants non-repuditation that Bob created the token. >>> 5) Bob has a private key and a public key >>>=20 >>> I don't see how to do this using JWE. It seems I have to sign the = same > token >> I had previously with JWS. This seems inefficient since I should be = able > to >> replace the JWE integrity computation done with the symmetric key = with the >> private key -- but the "alg" parameter is the same in both encrypting = and >> signing. >>>=20 >>> Now let's expand this to replacing the symmetric key with a > public/private >> key pair for encryption. Bob encrypts with Charlies public key and = signs > with >> Bob's private key (we also need to make sure we are not doing naive >> encryption and signing here, would be a really useful to specify what > needs >> to be done there). Now we need to have parameters for both = public/private >> key pairs in the header. >>>=20 >>> Am I missing something here? >>>=20 >>> Seems like we can do this if we change the header parameters to = specify > if >> they ("alg", "kid", et.c) are for token signing, payload encryption = or > content >> key encryption. >>>=20 >>> -- Dick >>>=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 From ietf@augustcellars.com Sun Nov 4 12:51: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 88E1E21F88A1 for ; Sun, 4 Nov 2012 12:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niAkP5a2GGSr for ; Sun, 4 Nov 2012 12:51:56 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 9341221F8813 for ; Sun, 4 Nov 2012 12:51:53 -0800 (PST) Received: from Philemon (dhcp-469b.meeting.ietf.org [130.129.70.155]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id E06622C9BC; Sun, 4 Nov 2012 12:51:52 -0800 (PST) From: "Jim Schaad" To: "'Dick Hardt'" References: <4ACFC778-31A9-4C79-9F4E-7C01719F51AD@gmail.com> <4E1F6AAD24975D4BA5B168042967394366887325@TK5EX14MBXC285.redmond.corp.microsoft.com> <000b01cdbab9$967ef070$c37cd150$@augustcellars.com> <210E03E3-FD49-449A-8953-571ECA9E5FBE@gmail.com> In-Reply-To: <210E03E3-FD49-449A-8953-571ECA9E5FBE@gmail.com> Date: Sun, 4 Nov 2012 15:51:45 -0500 Message-ID: <001101cdbace$34906500$9db12f00$@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: AQJk3UBi+7c9NJolq0gv1z0r2pGfkgJRTlTwAoSEM20BgKfcgQFj4EGHlm4O9uA= Content-Language: en-us Cc: 'Mike Jones' , jose@ietf.org Subject: Re: [jose] encrypting AND signing a token 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, 04 Nov 2012 20:51:58 -0000 > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Sunday, November 04, 2012 2:56 PM > To: Jim Schaad > Cc: 'Dick Hardt'; 'Mike Jones'; jose@ietf.org > Subject: Re: [jose] encrypting AND signing a token > > Thanks Jim. An interesting historical reference. > > In my use case, who signed or who the token is for is not a secret. The > payload needs to be kept a secret. > > Does no one sign and encrypt SAML tokens? > Is this not a common use case? Everything I have seen does this as independent operations. Jim > > If it does need to be solved, it would seem to me that a standards body > would be the place to have lots of eyes look at how to sign and encrypt a > token so that people do not do naive sign and encrypt. > > Q: does anyone else need to sign and encrypt? > > -- Dick > > On Nov 4, 2012, at 10:24 AM, "Jim Schaad" wrote: > > > > > > > I would note that the original PKCS#7 specifications had a mode that > > provided a similar sign and encrypt as a single operation mode. When > > the > > PKCS#7 specifications where adopted by the IETF as part of the CMS > > work, this mode was discussed and very deliberately dropped because of > > numerous security problems that had been found. These included (but > > are not limited > > to) the fact that it was signed or who signed it was sometimes a > > security leak. Also there were attacks where the signed and encrypted > > mode could be converted to just an encrypted mode. > > > > I would think that there would be a need for a very detailed security > > analysis that we are not prepared to do in order to support a signed > > and encrypted mode. > > > > Jim > > > > > >> -----Original Message----- > >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > >> Of Dick Hardt > >> Sent: Friday, November 02, 2012 12:30 PM > >> To: Mike Jones > >> Cc: jose@ietf.org > >> Subject: Re: [jose] encrypting AND signing a token > >> > >> Not only is my original token increasing in size by 4/3, I am also > >> adding another header, payload and signature. > >> > >> One of the objectives of JWT was to enabled compact tokens. It would > >> seem that we should be able to support both signing and encryption of > >> the same token. > >> > >> All the encryption use cases I can think of involving asymmetric keys > > would > >> also require signing with the senders private key. > >> > >> My suggestion is to be explicit in what the algorithm etc. is used for: > >> > >> Rather than "alg" and "enc", we have: > >> > >> "algs" - algorithm for token signing > >> "algk" - algorithm for content management key encryption "alge" - > > algorithm > >> for payload encryption > >> > >> Similiarly, > >> > >> "kids" - key id for signing > >> "kidk" - key id for content managment key encryption > >> > >> We could probably make these three or even two letter codes if you > >> want to save a couple bytes. > >> > >> -- Dick > >> > >> On Nov 2, 2012, at 8:46 AM, Mike Jones > >> wrote: > >> > >>> The way you put it brings one straightforward solution to mind. > >>> Solve > > 1-3 > >> with a JWE. Solve 4-5 by signing the JWE as a JWS payload. Done. > >>> > >>> I do understand that the 4/3 space blowup-of double base64url > >>> encoding > >> the JWE motivates your earlier proposal about nested signing. (See > >> Dick's > >> 10/29/12 message "[jose] signing an existing JWT".) I also > >> understand > > that if > >> you could do integrity with the asymmetric signature then the > >> integrity provided by the JWE itself may be redundant. I don't have > >> a specific > > proposal > >> on how to do that. > >>> > >>> -- Mike > >>> > >>> -----Original Message----- > >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > >>> Of Dick Hardt > >>> Sent: Friday, November 02, 2012 8:22 AM > >>> To: jose@ietf.org > >>> Subject: [jose] encrypting AND signing a token > >>> > >>> I am trying to figure out how to implement JWT/JWS/JWE to solve a > >>> real > >> world problem. > >>> > >>> 1) Bob sends a token to Charlie via Alice. (Alice gets token from > >>> Bob and then Alice gives token to Charlie) > >>> 2) Alice must be prevented from reading the token. (token needs to > >>> be > >>> encrypted) > >>> 3) Bob and Charlie can share a symmetric key. > >>> > >>> I can solve this with JWE. > >>> > >>> Now let's add another condition. > >>> > >>> 4) Charlie wants non-repuditation that Bob created the token. > >>> 5) Bob has a private key and a public key > >>> > >>> I don't see how to do this using JWE. It seems I have to sign the > >>> same > > token > >> I had previously with JWS. This seems inefficient since I should be > >> able > > to > >> replace the JWE integrity computation done with the symmetric key > >> with the private key -- but the "alg" parameter is the same in both > >> encrypting and signing. > >>> > >>> Now let's expand this to replacing the symmetric key with a > > public/private > >> key pair for encryption. Bob encrypts with Charlies public key and > >> signs > > with > >> Bob's private key (we also need to make sure we are not doing naive > >> encryption and signing here, would be a really useful to specify what > > needs > >> to be done there). Now we need to have parameters for both > >> public/private key pairs in the header. > >>> > >>> Am I missing something here? > >>> > >>> Seems like we can do this if we change the header parameters to > >>> specify > > if > >> they ("alg", "kid", et.c) are for token signing, payload encryption > >> or > > content > >> key encryption. > >>> > >>> -- Dick > >>> > >>> > >>> _______________________________________________ > >>> 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 mike.scott@certivox.com Sun Nov 4 13:27: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 1413621F8613 for ; Sun, 4 Nov 2012 13:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKXdk5niCPS2 for ; Sun, 4 Nov 2012 13:27:02 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDDE21F84F3 for ; Sun, 4 Nov 2012 13:27:01 -0800 (PST) Received: from mail160-co1-R.bigfish.com (10.243.78.254) by CO1EHSOBE002.bigfish.com (10.243.66.65) with Microsoft SMTP Server id 14.1.225.23; Sun, 4 Nov 2012 21:27:01 +0000 Received: from mail160-co1 (localhost [127.0.0.1]) by mail160-co1-R.bigfish.com (Postfix) with ESMTP id 2270280023C for ; Sun, 4 Nov 2012 21:27:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.248.133; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0310HT002.eurprd03.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: PS-29(zzbb2dI98dI9371I542M1432Izz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz31h2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h) Received-SPF: softfail (mail160-co1: transitioning domain of certivox.com does not designate 157.56.248.133 as permitted sender) client-ip=157.56.248.133; envelope-from=mike.scott@certivox.com; helo=AMXPRD0310HT002.eurprd03.prod.outlook.com ; .outlook.com ; Received: from mail160-co1 (localhost.localdomain [127.0.0.1]) by mail160-co1 (MessageSwitch) id 1352064417873774_8804; Sun, 4 Nov 2012 21:26:57 +0000 (UTC) Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.234]) by mail160-co1.bigfish.com (Postfix) with ESMTP id D374FA0004A for ; Sun, 4 Nov 2012 21:26:57 +0000 (UTC) Received: from AMXPRD0310HT002.eurprd03.prod.outlook.com (157.56.248.133) by CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 4 Nov 2012 21:26:57 +0000 Received: from AMXPRD0310MB353.eurprd03.prod.outlook.com ([169.254.4.218]) by AMXPRD0310HT002.eurprd03.prod.outlook.com ([10.255.55.37]) with mapi id 14.16.0233.002; Sun, 4 Nov 2012 21:26:55 +0000 From: Mike Scott To: "jose@ietf.org" Thread-Topic: [jose] encrypting AND signing a token Thread-Index: AQHNuQ3KoFNZ2fysZU+2R3+vnzYsspfWsFUAgAAMIoCAA0SWgIAAGaMAgAAPmoCAAAkkIA== Date: Sun, 4 Nov 2012 21:26:55 +0000 Message-ID: <0C8F9A45306BD9499EAD612A10CFF8942BE45035@AMXPRD0310MB353.eurprd03.prod.outlook.com> References: <4ACFC778-31A9-4C79-9F4E-7C01719F51AD@gmail.com> <4E1F6AAD24975D4BA5B168042967394366887325@TK5EX14MBXC285.redmond.corp.microsoft.com> <000b01cdbab9$967ef070$c37cd150$@augustcellars.com> <210E03E3-FD49-449A-8953-571ECA9E5FBE@gmail.com>, <001101cdbace$34906500$9db12f00$@augustcellars.com> In-Reply-To: <001101cdbace$34906500$9db12f00$@augustcellars.com> Accept-Language: en-IE, en-US Content-Language: en-IE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.78.106.228] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: certivox.com Subject: Re: [jose] encrypting AND signing a token 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, 04 Nov 2012 21:27:03 -0000 Signcryption? http://www.signcryption.org/standards/ Mike Scott ________________________________________ From: jose-bounces@ietf.org [jose-bounces@ietf.org] on behalf of Jim Schaad= [ietf@augustcellars.com] Sent: 04 November 2012 20:51 To: 'Dick Hardt' Cc: 'Mike Jones'; jose@ietf.org Subject: Re: [jose] encrypting AND signing a token > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Sunday, November 04, 2012 2:56 PM > To: Jim Schaad > Cc: 'Dick Hardt'; 'Mike Jones'; jose@ietf.org > Subject: Re: [jose] encrypting AND signing a token > > Thanks Jim. An interesting historical reference. > > In my use case, who signed or who the token is for is not a secret. The > payload needs to be kept a secret. > > Does no one sign and encrypt SAML tokens? > Is this not a common use case? Everything I have seen does this as independent operations. Jim > > If it does need to be solved, it would seem to me that a standards body > would be the place to have lots of eyes look at how to sign and encrypt a > token so that people do not do naive sign and encrypt. > > Q: does anyone else need to sign and encrypt? > > -- Dick > > On Nov 4, 2012, at 10:24 AM, "Jim Schaad" wrote: > > > > > > > I would note that the original PKCS#7 specifications had a mode that > > provided a similar sign and encrypt as a single operation mode. When > > the > > PKCS#7 specifications where adopted by the IETF as part of the CMS > > work, this mode was discussed and very deliberately dropped because of > > numerous security problems that had been found. These included (but > > are not limited > > to) the fact that it was signed or who signed it was sometimes a > > security leak. Also there were attacks where the signed and encrypted > > mode could be converted to just an encrypted mode. > > > > I would think that there would be a need for a very detailed security > > analysis that we are not prepared to do in order to support a signed > > and encrypted mode. > > > > Jim > > > > > >> -----Original Message----- > >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > >> Of Dick Hardt > >> Sent: Friday, November 02, 2012 12:30 PM > >> To: Mike Jones > >> Cc: jose@ietf.org > >> Subject: Re: [jose] encrypting AND signing a token > >> > >> Not only is my original token increasing in size by 4/3, I am also > >> adding another header, payload and signature. > >> > >> One of the objectives of JWT was to enabled compact tokens. It would > >> seem that we should be able to support both signing and encryption of > >> the same token. > >> > >> All the encryption use cases I can think of involving asymmetric keys > > would > >> also require signing with the senders private key. > >> > >> My suggestion is to be explicit in what the algorithm etc. is used for= : > >> > >> Rather than "alg" and "enc", we have: > >> > >> "algs" - algorithm for token signing > >> "algk" - algorithm for content management key encryption "alge" - > > algorithm > >> for payload encryption > >> > >> Similiarly, > >> > >> "kids" - key id for signing > >> "kidk" - key id for content managment key encryption > >> > >> We could probably make these three or even two letter codes if you > >> want to save a couple bytes. > >> > >> -- Dick > >> > >> On Nov 2, 2012, at 8:46 AM, Mike Jones > >> wrote: > >> > >>> The way you put it brings one straightforward solution to mind. > >>> Solve > > 1-3 > >> with a JWE. Solve 4-5 by signing the JWE as a JWS payload. Done. > >>> > >>> I do understand that the 4/3 space blowup-of double base64url > >>> encoding > >> the JWE motivates your earlier proposal about nested signing. (See > >> Dick's > >> 10/29/12 message "[jose] signing an existing JWT".) I also > >> understand > > that if > >> you could do integrity with the asymmetric signature then the > >> integrity provided by the JWE itself may be redundant. I don't have > >> a specific > > proposal > >> on how to do that. > >>> > >>> -- Mike > >>> > >>> -----Original Message----- > >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > >>> Of Dick Hardt > >>> Sent: Friday, November 02, 2012 8:22 AM > >>> To: jose@ietf.org > >>> Subject: [jose] encrypting AND signing a token > >>> > >>> I am trying to figure out how to implement JWT/JWS/JWE to solve a > >>> real > >> world problem. > >>> > >>> 1) Bob sends a token to Charlie via Alice. (Alice gets token from > >>> Bob and then Alice gives token to Charlie) > >>> 2) Alice must be prevented from reading the token. (token needs to > >>> be > >>> encrypted) > >>> 3) Bob and Charlie can share a symmetric key. > >>> > >>> I can solve this with JWE. > >>> > >>> Now let's add another condition. > >>> > >>> 4) Charlie wants non-repuditation that Bob created the token. > >>> 5) Bob has a private key and a public key > >>> > >>> I don't see how to do this using JWE. It seems I have to sign the > >>> same > > token > >> I had previously with JWS. This seems inefficient since I should be > >> able > > to > >> replace the JWE integrity computation done with the symmetric key > >> with the private key -- but the "alg" parameter is the same in both > >> encrypting and signing. > >>> > >>> Now let's expand this to replacing the symmetric key with a > > public/private > >> key pair for encryption. Bob encrypts with Charlies public key and > >> signs > > with > >> Bob's private key (we also need to make sure we are not doing naive > >> encryption and signing here, would be a really useful to specify what > > needs > >> to be done there). Now we need to have parameters for both > >> public/private key pairs in the header. > >>> > >>> Am I missing something here? > >>> > >>> Seems like we can do this if we change the header parameters to > >>> specify > > if > >> they ("alg", "kid", et.c) are for token signing, payload encryption > >> or > > content > >> key encryption. > >>> > >>> -- Dick > >>> > >>> > >>> _______________________________________________ > >>> 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 > > _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From Axel.Nennker@telekom.de Mon Nov 5 06:57: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 5950F21F8790 for ; Mon, 5 Nov 2012 06:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+HcZ-zvQpON for ; Mon, 5 Nov 2012 06:57:42 -0800 (PST) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id B34A221F8510 for ; Mon, 5 Nov 2012 06:57:41 -0800 (PST) Received: from he111296.emea1.cds.t-internal.com ([10.125.90.14]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 05 Nov 2012 15:57:37 +0100 Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.94]) by HE111296.EMEA1.CDS.T-INTERNAL.COM ([fe80::19ac:3fb4:a382:6df4%16]) with mapi; Mon, 5 Nov 2012 15:57:37 +0100 From: To: Date: Mon, 5 Nov 2012 15:57:36 +0100 Thread-Topic: [jose] encrypting AND signing a token Thread-Index: Ac26xmxqDubGBLgNRG+LFrzxrrO9JQAnrZdA Message-ID: References: <4ACFC778-31A9-4C79-9F4E-7C01719F51AD@gmail.com> <4E1F6AAD24975D4BA5B168042967394366887325@TK5EX14MBXC285.redmond.corp.microsoft.com> <000b01cdbab9$967ef070$c37cd150$@augustcellars.com> <210E03E3-FD49-449A-8953-571ECA9E5FBE@gmail.com> In-Reply-To: <210E03E3-FD49-449A-8953-571ECA9E5FBE@gmail.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 Cc: Michael.Jones@microsoft.com, jose@ietf.org Subject: Re: [jose] encrypting AND signing a token 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, 05 Nov 2012 14:57:43 -0000 A OpenID Connect self-issued token is a signed and then encrypted id_token = using JWS then JWE. Because the audience is part of the id_token the re-encryption issue is not= valid in this case. The signed-and-encrypted JWT is then transported to the RP as a URL fragmen= t. I have not hit any url length limits on Android but saving some bytes throu= gh a combined signend-and-encrypted-format would be good. -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Dic= k Hardt Sent: Sunday, November 04, 2012 8:56 PM To: Jim Schaad Cc: 'Mike Jones'; jose@ietf.org; 'Dick Hardt' Subject: Re: [jose] encrypting AND signing a token Thanks Jim. An interesting historical reference.=20 In my use case, who signed or who the token is for is not a secret. The pay= load needs to be kept a secret. Does no one sign and encrypt SAML tokens? Is this not a common use case? If it does need to be solved, it would seem to me that a standards body wou= ld be the place to have lots of eyes look at how to sign and encrypt a toke= n so that people do not do naive sign and encrypt. Q: does anyone else need to sign and encrypt? -- Dick On Nov 4, 2012, at 10:24 AM, "Jim Schaad" wrote: > >=20 > I would note that the original PKCS#7 specifications had a mode that=20 > provided a similar sign and encrypt as a single operation mode. When=20 > the > PKCS#7 specifications where adopted by the IETF as part of the CMS=20 > work, this mode was discussed and very deliberately dropped because of=20 > numerous security problems that had been found. These included (but=20 > are not limited > to) the fact that it was signed or who signed it was sometimes a=20 > security leak. Also there were attacks where the signed and encrypted=20 > mode could be converted to just an encrypted mode. >=20 > I would think that there would be a need for a very detailed security=20 > analysis that we are not prepared to do in order to support a signed=20 > and encrypted mode. >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20 >> Of Dick Hardt >> Sent: Friday, November 02, 2012 12:30 PM >> To: Mike Jones >> Cc: jose@ietf.org >> Subject: Re: [jose] encrypting AND signing a token >>=20 >> Not only is my original token increasing in size by 4/3, I am also=20 >> adding another header, payload and signature. >>=20 >> One of the objectives of JWT was to enabled compact tokens. It would=20 >> seem that we should be able to support both signing and encryption of=20 >> the same token. >>=20 >> All the encryption use cases I can think of involving asymmetric keys > would >> also require signing with the senders private key. >>=20 >> My suggestion is to be explicit in what the algorithm etc. is used for: >>=20 >> Rather than "alg" and "enc", we have: >>=20 >> "algs" - algorithm for token signing >> "algk" - algorithm for content management key encryption "alge" - > algorithm >> for payload encryption >>=20 >> Similiarly, >>=20 >> "kids" - key id for signing >> "kidk" - key id for content managment key encryption >>=20 >> We could probably make these three or even two letter codes if you=20 >> want to save a couple bytes. >>=20 >> -- Dick >>=20 >> On Nov 2, 2012, at 8:46 AM, Mike Jones >> wrote: >>=20 >>> The way you put it brings one straightforward solution to mind. =20 >>> Solve > 1-3 >> with a JWE. Solve 4-5 by signing the JWE as a JWS payload. Done. >>>=20 >>> I do understand that the 4/3 space blowup-of double base64url=20 >>> encoding >> the JWE motivates your earlier proposal about nested signing. (See=20 >> Dick's >> 10/29/12 message "[jose] signing an existing JWT".) I also=20 >> understand > that if >> you could do integrity with the asymmetric signature then the=20 >> integrity provided by the JWE itself may be redundant. I don't have=20 >> a specific > proposal >> on how to do that. >>>=20 >>> -- Mike >>>=20 >>> -----Original Message----- >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20 >>> Of Dick Hardt >>> Sent: Friday, November 02, 2012 8:22 AM >>> To: jose@ietf.org >>> Subject: [jose] encrypting AND signing a token >>>=20 >>> I am trying to figure out how to implement JWT/JWS/JWE to solve a=20 >>> real >> world problem. >>>=20 >>> 1) Bob sends a token to Charlie via Alice. (Alice gets token from=20 >>> Bob and then Alice gives token to Charlie) >>> 2) Alice must be prevented from reading the token. (token needs to=20 >>> be >>> encrypted) >>> 3) Bob and Charlie can share a symmetric key. >>>=20 >>> I can solve this with JWE. >>>=20 >>> Now let's add another condition. >>>=20 >>> 4) Charlie wants non-repuditation that Bob created the token. >>> 5) Bob has a private key and a public key >>>=20 >>> I don't see how to do this using JWE. It seems I have to sign the=20 >>> same > token >> I had previously with JWS. This seems inefficient since I should be=20 >> able > to >> replace the JWE integrity computation done with the symmetric key=20 >> with the private key -- but the "alg" parameter is the same in both=20 >> encrypting and signing. >>>=20 >>> Now let's expand this to replacing the symmetric key with a > public/private >> key pair for encryption. Bob encrypts with Charlies public key and=20 >> signs > with >> Bob's private key (we also need to make sure we are not doing naive=20 >> encryption and signing here, would be a really useful to specify what > needs >> to be done there). Now we need to have parameters for both=20 >> public/private key pairs in the header. >>>=20 >>> Am I missing something here? >>>=20 >>> Seems like we can do this if we change the header parameters to=20 >>> specify > if >> they ("alg", "kid", et.c) are for token signing, payload encryption=20 >> or > content >> key encryption. >>>=20 >>> -- Dick >>>=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 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From dick.hardt@gmail.com Mon Nov 5 11:47: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 97C3721F8989 for ; Mon, 5 Nov 2012 11:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rC8Lh6fpu38R for ; Mon, 5 Nov 2012 11:47:29 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8972721F8811 for ; Mon, 5 Nov 2012 11:47:29 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so4149935pbb.31 for ; Mon, 05 Nov 2012 11:47:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=T7/YUeE/LfWZ7EEFcYwYhpcc/Awfme7mfZKRe+GjAUY=; b=LaPdK0wp38eXnnWFZ3G/O0ToKBX77Wef2f6ZPzR7mYOUO7qeL5WXMb18C8kiF4cCP3 iuaCs+C2UmiYWuLShbaCGus7OW5lDG2lwVWxrzHXtLm12FB+02fX2Tdgu6oPB3JeDXuk Ce8UZMKfSV3N/0D6R5qT4aAlFRsmrGukIH5mYDmfhC7hi/1ESJI2yPW9oNcjw4qX1a0L UlTOv6SqVnH+TSpjzFf9l1UWUhy9H/ixOQyVEC477LbcoINXyBrsrhElbkTsKBmqLu8N YjbFS+FAMTGcjcGbPV1ZH8SbmJZdqgneX/EsHVkgk4BiCjx/zrPxzJ0ZSlPIeNgfGnAN dEkw== Received: by 10.66.73.34 with SMTP id i2mr31292667pav.28.1352144849254; Mon, 05 Nov 2012 11:47:29 -0800 (PST) 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 e9sm11091025paz.28.2012.11.05.11.47.24 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Nov 2012 11:47:25 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: Date: Mon, 5 Nov 2012 11:47:23 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4ACFC778-31A9-4C79-9F4E-7C01719F51AD@gmail.com> <4E1F6AAD24975D4BA5B168042967394366887325@TK5EX14MBXC285.redmond.corp.microsoft.com> <000b01cdbab9$967ef070$c37cd150$@augustcellars.com> <210E03E3-FD49-449A-8953-571ECA9E5FBE@gmail.com> To: X-Mailer: Apple Mail (2.1499) Cc: Michael.Jones@microsoft.com, jose@ietf.org, dick.hardt@gmail.com Subject: Re: [jose] encrypting AND signing a token 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, 05 Nov 2012 19:47:30 -0000 Thanks Axel. Nice to know the implementation I am working on is not the = only one. Do you know what algorithm is being used for signing and encrypting in = deployments?=20 The implementation I am working on passes the token using a custom = scheme in iOS and Android. I am concerned about the token size, but = don't know the limits. -- Dick On Nov 5, 2012, at 6:57 AM, wrote: > A OpenID Connect self-issued token is a signed and then encrypted = id_token using JWS then JWE. > Because the audience is part of the id_token the re-encryption issue = is not valid in this case. > The signed-and-encrypted JWT is then transported to the RP as a URL = fragment. >=20 > I have not hit any url length limits on Android but saving some bytes = through a combined signend-and-encrypted-format would be good. >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Dick Hardt > Sent: Sunday, November 04, 2012 8:56 PM > To: Jim Schaad > Cc: 'Mike Jones'; jose@ietf.org; 'Dick Hardt' > Subject: Re: [jose] encrypting AND signing a token >=20 > Thanks Jim. An interesting historical reference.=20 >=20 > In my use case, who signed or who the token is for is not a secret. = The payload needs to be kept a secret. >=20 > Does no one sign and encrypt SAML tokens? > Is this not a common use case? >=20 > If it does need to be solved, it would seem to me that a standards = body would be the place to have lots of eyes look at how to sign and = encrypt a token so that people do not do naive sign and encrypt. >=20 > Q: does anyone else need to sign and encrypt? >=20 > -- Dick >=20 > On Nov 4, 2012, at 10:24 AM, "Jim Schaad" = wrote: >=20 >> >>=20 >> I would note that the original PKCS#7 specifications had a mode that=20= >> provided a similar sign and encrypt as a single operation mode. When=20= >> the >> PKCS#7 specifications where adopted by the IETF as part of the CMS=20 >> work, this mode was discussed and very deliberately dropped because = of=20 >> numerous security problems that had been found. These included (but=20= >> are not limited >> to) the fact that it was signed or who signed it was sometimes a=20 >> security leak. Also there were attacks where the signed and = encrypted=20 >> mode could be converted to just an encrypted mode. >>=20 >> I would think that there would be a need for a very detailed security=20= >> analysis that we are not prepared to do in order to support a signed=20= >> and encrypted mode. >>=20 >> Jim >>=20 >>=20 >>> -----Original Message----- >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20= >>> Of Dick Hardt >>> Sent: Friday, November 02, 2012 12:30 PM >>> To: Mike Jones >>> Cc: jose@ietf.org >>> Subject: Re: [jose] encrypting AND signing a token >>>=20 >>> Not only is my original token increasing in size by 4/3, I am also=20= >>> adding another header, payload and signature. >>>=20 >>> One of the objectives of JWT was to enabled compact tokens. It would=20= >>> seem that we should be able to support both signing and encryption = of=20 >>> the same token. >>>=20 >>> All the encryption use cases I can think of involving asymmetric = keys >> would >>> also require signing with the senders private key. >>>=20 >>> My suggestion is to be explicit in what the algorithm etc. is used = for: >>>=20 >>> Rather than "alg" and "enc", we have: >>>=20 >>> "algs" - algorithm for token signing >>> "algk" - algorithm for content management key encryption "alge" - >> algorithm >>> for payload encryption >>>=20 >>> Similiarly, >>>=20 >>> "kids" - key id for signing >>> "kidk" - key id for content managment key encryption >>>=20 >>> We could probably make these three or even two letter codes if you=20= >>> want to save a couple bytes. >>>=20 >>> -- Dick >>>=20 >>> On Nov 2, 2012, at 8:46 AM, Mike Jones >>> wrote: >>>=20 >>>> The way you put it brings one straightforward solution to mind. =20 >>>> Solve >> 1-3 >>> with a JWE. Solve 4-5 by signing the JWE as a JWS payload. Done. >>>>=20 >>>> I do understand that the 4/3 space blowup-of double base64url=20 >>>> encoding >>> the JWE motivates your earlier proposal about nested signing. (See=20= >>> Dick's >>> 10/29/12 message "[jose] signing an existing JWT".) I also=20 >>> understand >> that if >>> you could do integrity with the asymmetric signature then the=20 >>> integrity provided by the JWE itself may be redundant. I don't have=20= >>> a specific >> proposal >>> on how to do that. >>>>=20 >>>> -- Mike >>>>=20 >>>> -----Original Message----- >>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf=20 >>>> Of Dick Hardt >>>> Sent: Friday, November 02, 2012 8:22 AM >>>> To: jose@ietf.org >>>> Subject: [jose] encrypting AND signing a token >>>>=20 >>>> I am trying to figure out how to implement JWT/JWS/JWE to solve a=20= >>>> real >>> world problem. >>>>=20 >>>> 1) Bob sends a token to Charlie via Alice. (Alice gets token from=20= >>>> Bob and then Alice gives token to Charlie) >>>> 2) Alice must be prevented from reading the token. (token needs to=20= >>>> be >>>> encrypted) >>>> 3) Bob and Charlie can share a symmetric key. >>>>=20 >>>> I can solve this with JWE. >>>>=20 >>>> Now let's add another condition. >>>>=20 >>>> 4) Charlie wants non-repuditation that Bob created the token. >>>> 5) Bob has a private key and a public key >>>>=20 >>>> I don't see how to do this using JWE. It seems I have to sign the=20= >>>> same >> token >>> I had previously with JWS. This seems inefficient since I should be=20= >>> able >> to >>> replace the JWE integrity computation done with the symmetric key=20 >>> with the private key -- but the "alg" parameter is the same in both=20= >>> encrypting and signing. >>>>=20 >>>> Now let's expand this to replacing the symmetric key with a >> public/private >>> key pair for encryption. Bob encrypts with Charlies public key and=20= >>> signs >> with >>> Bob's private key (we also need to make sure we are not doing naive=20= >>> encryption and signing here, would be a really useful to specify = what >> needs >>> to be done there). Now we need to have parameters for both=20 >>> public/private key pairs in the header. >>>>=20 >>>> Am I missing something here? >>>>=20 >>>> Seems like we can do this if we change the header parameters to=20 >>>> specify >> if >>> they ("alg", "kid", et.c) are for token signing, payload encryption=20= >>> or >> content >>> key encryption. >>>>=20 >>>> -- Dick >>>>=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 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From mamille2@cisco.com Mon Nov 5 12:50: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 69D7F21F84DF for ; Mon, 5 Nov 2012 12:50:15 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6fMcdZvBf2b for ; Mon, 5 Nov 2012 12:50:15 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 9665321F84D8 for ; Mon, 5 Nov 2012 12:50:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4977; q=dns/txt; s=iport; t=1352148614; x=1353358214; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RCrYF2sOw2h7AwsOsCQFBmXlXsZYe+OBhJOeDkSKj50=; b=Ok6MN/2rvGUUyHW7xbIJpcC2kGvGuWfgm4VEE8Ogr5VW5m5TDDdUVgQd zIK+/NZI0rdHxIEI1sKc6aZTvdZeHVYTA5cXimiGlmxiqp5Ox0/LH3Ldp cCenUZEhwxpKat5og5i+NiNT9zQP5iEQV8+wlWeTnT9ZAn/dRJge0l+13 E=; X-Files: smime.p7s : 2214 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHAlmFCtJV2d/2dsb2JhbABEhhe9HYEIgh4BAQEEAQEBDwEOAUwLEAIBCBgKBRoDAgIfBgslAgQOBQgGFIdWAw8LmnCNIwGJDA2JVIsZaIUmNWEDjnuBIYQKgnGKF4MmgWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,716,1344211200"; d="p7s'?scan'208";a="139013327" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 05 Nov 2012 20:50:14 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA5KoENj019087 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 20:50:14 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.240]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 14:50:13 -0600 From: "Matt Miller (mamille2)" To: Nat Sakimura Thread-Topic: [jose] xpo Thread-Index: AQHNq/RPuX3uWp0OAUq3qpfMosC+IZfYzisAgAFsBoCAAgDJgA== Date: Mon, 5 Nov 2012 20:50:13 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B168042967394366853BB5@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114FDD5151B@WSMSG3153V.srv.dir.telstra.com> <8AC56264-8B09-48BA-802F-6B30577419E9@bbn.com> <50955510.7030000@ieca.com> <-7585918764096795770@unknownmsgid> In-Reply-To: <-7585918764096795770@unknownmsgid> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.64.248] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19340.004 x-tm-as-result: No--33.862600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail=_D6A6051E-181F-4A28-9889-F3DEC29DB001"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Sean Turner , "jose@ietf.org" Subject: Re: [jose] xpo 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, 05 Nov 2012 20:50:15 -0000 --Apple-Mail=_D6A6051E-181F-4A28-9889-F3DEC29DB001 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-2022-jp +1 - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On Nov 4, 2012, at 9:14 AM, Nat Sakimura wrote: > +1 >=20 > Nov 4, 2012 9:10=1B$B!"=1B(BSean Turner = =1B$B$N%a%C%;!<%8=1B(B: >=20 >> +1 >>=20 >> On 10/16/12 7:15 PM, Richard Barnes wrote: >>> +1 >>>=20 >>> On Oct 16, 2012, at 6:55 PM, Manger, James H wrote: >>>=20 >>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-06 >>>>> * Changed the name of the JWK RSA exponent parameter from exp to = xpo so as to allow the potential use of the name exp for a future = extension that might define an expiration parameter for keys. (The exp = name is already used for this purpose in the JWT specification.) >>>>=20 >>>> "n" and "e" would be better than "mod" and "xpo". >>>> "n" and "e" are very widely used for the RSA modulus and public = exponent. >>>>=20 >>>> s^e =3D m mod n >>>>=20 >>>> -- >>>> James Manger >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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 --Apple-Mail=_D6A6051E-181F-4A28-9889-F3DEC29DB001 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 ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTEwNTIwNTAx M1owIwYJKoZIhvcNAQkEMRYEFGhYzVDWU8L48zyBaalVPpbP6z19MIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQApVy86Tv+BX+T1dBQH6utrk9Qr/2Q2wV3gv1xY6u32rYPshdvEw5sAOtTI rcEVh7Whx45z6VOCJ9qs0P9RxbcTLjfd8EK+ob+imR3gyp2mWORsVLYKbo7awzWgRjna8F/6zk+w 2QFsOL8/V1XaG7kaVCDbNxGmB+z6mCxRO/skhijrgnJSz74ZP4JhToRnA2cSvbI80b0r11Y2wtES Us1qfVoeb+3YX83XekSlDSL0Jx3/7ts10dRm9jxMYt/8T7pazccmLzeu+rB+K+z4wz4xJUTmWP+i 7yiGOCe34jb88JYHodx3Qy8mLgecTbPDxaxFABdVRo2nT71S1Tw2k7zPAAAAAAAA --Apple-Mail=_D6A6051E-181F-4A28-9889-F3DEC29DB001-- From Axel.Nennker@telekom.de Mon Nov 5 13:11: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 1E91C21F8665 for ; Mon, 5 Nov 2012 13:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQdwLL1ETrp4 for ; Mon, 5 Nov 2012 13:11:15 -0800 (PST) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 71CC621F85FC for ; Mon, 5 Nov 2012 13:11:14 -0800 (PST) Received: from he111527.emea1.cds.t-internal.com ([10.125.90.86]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 05 Nov 2012 22:10:59 +0100 Received: from HE113559.emea1.cds.t-internal.com (10.125.65.101) by HE111527.EMEA1.CDS.T-INTERNAL.COM (10.125.90.86) with Microsoft SMTP Server (TLS) id 8.3.245.1; Mon, 5 Nov 2012 22:10:59 +0100 Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.94]) by HE113559.emea1.cds.t-internal.com ([2002:7cd:4165::7cd:4165]) with mapi; Mon, 5 Nov 2012 22:10:58 +0100 From: To: Date: Mon, 5 Nov 2012 22:10:57 +0100 Thread-Topic: [jose] encrypting AND signing a token Thread-Index: Ac27jmjkLQCkg5PAR9ycNDpKpaJfOQACNvXg Message-ID: References: <4ACFC778-31A9-4C79-9F4E-7C01719F51AD@gmail.com> <4E1F6AAD24975D4BA5B168042967394366887325@TK5EX14MBXC285.redmond.corp.microsoft.com> <000b01cdbab9$967ef070$c37cd150$@augustcellars.com> <210E03E3-FD49-449A-8953-571ECA9E5FBE@gmail.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: jose@ietf.org Subject: Re: [jose] encrypting AND signing a token 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, 05 Nov 2012 21:11:19 -0000 I am using an RP that uses an openid-url scheme to let the Android App kno= w the openid connect object. openid://?response_type=3Did_token&client_id=3Dhttps://gabunomi.net/seminar= /callback.html&request=3Dheader.payload.signatur&state=3D50982a45f0ec1&nonc= e=3D50982a45f12ab The id_token is returned to the RP in a fragment. https://server/callback.html#id_token=3Dsigned-then-encrypted-id_token I did not test the size limits but it worked for an id_token with claims em= ail, display name and picture url. Inside is a user_jwk with a public key. = The corresponding private key is used to sign the id_token. It is unique pe= r RP. The algs used are RSA1_5 and A256CBC+HS256. I don't know whether I can name the RP's url here. Maybe its owner wants to= do that. The RP is currently moving to another domain. I guess it is publi= c after the move. Axel -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Dic= k Hardt Sent: Monday, November 05, 2012 8:47 PM To: Nennker, Axel Cc: Michael.Jones@microsoft.com; jose@ietf.org; dick.hardt@gmail.com Subject: Re: [jose] encrypting AND signing a token Thanks Axel. Nice to know the implementation I am working on is not the onl= y one. Do you know what algorithm is being used for signing and encrypting in depl= oyments?=20 The implementation I am working on passes the token using a custom scheme i= n iOS and Android. I am concerned about the token size, but don't know the = limits. -- Dick On Nov 5, 2012, at 6:57 AM, wrote: > A OpenID Connect self-issued token is a signed and then encrypted id_toke= n using JWS then JWE. > Because the audience is part of the id_token the re-encryption issue is n= ot valid in this case. > The signed-and-encrypted JWT is then transported to the RP as a URL fragm= ent. >=20 > I have not hit any url length limits on Android but saving some bytes thr= ough a combined signend-and-encrypted-format would be good. >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20 > Of Dick Hardt > Sent: Sunday, November 04, 2012 8:56 PM > To: Jim Schaad > Cc: 'Mike Jones'; jose@ietf.org; 'Dick Hardt' > Subject: Re: [jose] encrypting AND signing a token >=20 > Thanks Jim. An interesting historical reference.=20 >=20 > In my use case, who signed or who the token is for is not a secret. The p= ayload needs to be kept a secret. >=20 > Does no one sign and encrypt SAML tokens? > Is this not a common use case? >=20 > If it does need to be solved, it would seem to me that a standards body w= ould be the place to have lots of eyes look at how to sign and encrypt a to= ken so that people do not do naive sign and encrypt. >=20 > Q: does anyone else need to sign and encrypt? >=20 > -- Dick >=20 > On Nov 4, 2012, at 10:24 AM, "Jim Schaad" wrote: >=20 >> >>=20 >> I would note that the original PKCS#7 specifications had a mode that=20 >> provided a similar sign and encrypt as a single operation mode. When=20 >> the >> PKCS#7 specifications where adopted by the IETF as part of the CMS=20 >> work, this mode was discussed and very deliberately dropped because=20 >> of numerous security problems that had been found. These included=20 >> (but are not limited >> to) the fact that it was signed or who signed it was sometimes a=20 >> security leak. Also there were attacks where the signed and=20 >> encrypted mode could be converted to just an encrypted mode. >>=20 >> I would think that there would be a need for a very detailed security=20 >> analysis that we are not prepared to do in order to support a signed=20 >> and encrypted mode. >>=20 >> Jim >>=20 >>=20 >>> -----Original Message----- >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20 >>> Of Dick Hardt >>> Sent: Friday, November 02, 2012 12:30 PM >>> To: Mike Jones >>> Cc: jose@ietf.org >>> Subject: Re: [jose] encrypting AND signing a token >>>=20 >>> Not only is my original token increasing in size by 4/3, I am also=20 >>> adding another header, payload and signature. >>>=20 >>> One of the objectives of JWT was to enabled compact tokens. It would=20 >>> seem that we should be able to support both signing and encryption=20 >>> of the same token. >>>=20 >>> All the encryption use cases I can think of involving asymmetric=20 >>> keys >> would >>> also require signing with the senders private key. >>>=20 >>> My suggestion is to be explicit in what the algorithm etc. is used for: >>>=20 >>> Rather than "alg" and "enc", we have: >>>=20 >>> "algs" - algorithm for token signing "algk" - algorithm for content=20 >>> management key encryption "alge" - >> algorithm >>> for payload encryption >>>=20 >>> Similiarly, >>>=20 >>> "kids" - key id for signing >>> "kidk" - key id for content managment key encryption >>>=20 >>> We could probably make these three or even two letter codes if you=20 >>> want to save a couple bytes. >>>=20 >>> -- Dick >>>=20 >>> On Nov 2, 2012, at 8:46 AM, Mike Jones >>> wrote: >>>=20 >>>> The way you put it brings one straightforward solution to mind. =20 >>>> Solve >> 1-3 >>> with a JWE. Solve 4-5 by signing the JWE as a JWS payload. Done. >>>>=20 >>>> I do understand that the 4/3 space blowup-of double base64url=20 >>>> encoding >>> the JWE motivates your earlier proposal about nested signing. (See=20 >>> Dick's >>> 10/29/12 message "[jose] signing an existing JWT".) I also=20 >>> understand >> that if >>> you could do integrity with the asymmetric signature then the=20 >>> integrity provided by the JWE itself may be redundant. I don't have=20 >>> a specific >> proposal >>> on how to do that. >>>>=20 >>>> -- Mike >>>>=20 >>>> -----Original Message----- >>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On=20 >>>> Behalf Of Dick Hardt >>>> Sent: Friday, November 02, 2012 8:22 AM >>>> To: jose@ietf.org >>>> Subject: [jose] encrypting AND signing a token >>>>=20 >>>> I am trying to figure out how to implement JWT/JWS/JWE to solve a=20 >>>> real >>> world problem. >>>>=20 >>>> 1) Bob sends a token to Charlie via Alice. (Alice gets token from=20 >>>> Bob and then Alice gives token to Charlie) >>>> 2) Alice must be prevented from reading the token. (token needs to=20 >>>> be >>>> encrypted) >>>> 3) Bob and Charlie can share a symmetric key. >>>>=20 >>>> I can solve this with JWE. >>>>=20 >>>> Now let's add another condition. >>>>=20 >>>> 4) Charlie wants non-repuditation that Bob created the token. >>>> 5) Bob has a private key and a public key >>>>=20 >>>> I don't see how to do this using JWE. It seems I have to sign the=20 >>>> same >> token >>> I had previously with JWS. This seems inefficient since I should be=20 >>> able >> to >>> replace the JWE integrity computation done with the symmetric key=20 >>> with the private key -- but the "alg" parameter is the same in both=20 >>> encrypting and signing. >>>>=20 >>>> Now let's expand this to replacing the symmetric key with a >> public/private >>> key pair for encryption. Bob encrypts with Charlies public key and=20 >>> signs >> with >>> Bob's private key (we also need to make sure we are not doing naive=20 >>> encryption and signing here, would be a really useful to specify=20 >>> what >> needs >>> to be done there). Now we need to have parameters for both=20 >>> public/private key pairs in the header. >>>>=20 >>>> Am I missing something here? >>>>=20 >>>> Seems like we can do this if we change the header parameters to=20 >>>> specify >> if >>> they ("alg", "kid", et.c) are for token signing, payload encryption=20 >>> or >> content >>> key encryption. >>>>=20 >>>> -- Dick >>>>=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 > _______________________________________________ > 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 dick.hardt@gmail.com Mon Nov 5 13:55: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 5A8D221F84DD for ; Mon, 5 Nov 2012 13:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.529 X-Spam-Level: X-Spam-Status: No, score=-4.529 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8IYRS-X2SsC for ; Mon, 5 Nov 2012 13:55:14 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7468121F8461 for ; Mon, 5 Nov 2012 13:55:14 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so4231107pad.31 for ; Mon, 05 Nov 2012 13:55:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=BkSB+giv9Meh3d7ImhxnBbABu/V+CL0PV1/WjzZOats=; b=TtTzi6HmuHO+KDsrmEQtVGbrQ5yCUqocjjs77VszC7sJSC1gnC1xesO0kHobIKNcil P5fGBn4b7YbKco3ImyLJqjIytnL7YFonZtC8G9Vc+/J30VtZ6QGy8QSlNa8voO2ITAXR wK7NB14XGCSRDq0bzW0WN3Nsa8vsop+C2ut0yOt9b5w65wE9XLDNjLUTjn1bcQ2u4DdE kiW92JzEaswc4YOUN7ARziv0DYIcnajLU+7NsstcjRQc+wYLWW1IFNAEW9nSL/yQXfMy +OTPIEWIdGHxElmaNDXzvwj6Q8eMkxyQAL6xOlr6Yg5rZqpmLM2m8eG0+TIjVYwzsfqi 6SCw== Received: by 10.68.230.10 with SMTP id su10mr33858582pbc.47.1352152514242; Mon, 05 Nov 2012 13:55:14 -0800 (PST) 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 ak10sm10266591pbd.24.2012.11.05.13.55.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Nov 2012 13:55:08 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FE01A44B@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 5 Nov 2012 13:55:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121017012429.cc40c4f3d92d2001859047cd8cabb9ab.c59acbdefa.wbe@email07.europe.secureserver.net> <255B9BB34FB7D647A506DC292726F6E114FDEC39C2@WSMSG3153V.srv.dir.telstra.com> <6BA7F1B5-5F4D-4626-B18E-9D31E68FCE21@bbn.com> <4E1F6AAD24975D4BA5B168042967394366877D28@TK5EX14MBXC285.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114FE01A44B@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1499) Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] xpo 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, 05 Nov 2012 21:55:15 -0000 Seems strange to insist on a flat structure when the reason for choosing = JSON was that we got a richer structure than name value pairs. Having this be an object with its own attributes makes it clear that a = number of parameters all belong together and is easier to move them = around together in implementations. Also, I would REALLY like to see the parameters have single purpose = across JWE and JWS. It makes debugging an implementation much easier. = One does not have to have other context to know what a parameter means. = Speaking from experience here. :) -- Dick On Oct 23, 2012, at 4:47 PM, "Manger, James H" = wrote: > Mike is right that with only a handful or so parameters we could = muddle through with a flat structure. The fact that we have already had = a clash ("exp") is annoying, and not a good sign about the flat = structure, but we could muddle through anyway. A parameter registry is = supposed to help. >=20 > But there are already other problems... > JWK [section 4. "JSON Web Key (JWK) Format"; section 6.1.1. = "Registration Template"] says parameters should be registered; says = different kinds of key can use the same parameter name for kind-specific = parameters; and establishes a registry that assumes parameter names are = unambiguous. Those three points cannot all work together. >=20 > For instance, an elliptic curve key can use "y" for the x-coordinate = of a point; while a=20 > DSA key could use "y" for the public key (an integer). What goes in = the registry? >=20 > The "exp" clash theoretically isn=92t a clash anyway, since the JWK = parameter registry is *separate* from the JWE/JWS header parameter = registry. Of course we don't want different names for the same sort of = metadata in JWS & JWK -- that would be annoying. This suggests we have = arranged the registries incorrectly. >=20 > You can also see this issue in JWE & JWS. They share a common = registry: "JSON Web Signature and Encryption header Parameters Registry" = [JWS section 7.1]. JWS puts "kid" in this registry, pointing to JWS = section 4.1.7. where it is defined as an identifier for the originator's = key. JWE puts the same name "kid" in the same registry, but points it to = JWE section 4.1.10. where it is defined as an identifier for the = recipient's key. Ugh? What will go in the registry? What happens when an = originator and recipient key are both involved? >=20 >=20 > Perhaps this mess can be sorted out by putting more care into which = registries are defined and what details go into them. Perhaps a = parameter registry that is common for JWE/JWS/JWK, but allows names to = be registered that (instead of pointing to one definition for the = parameter) mark that parameter as dependant on the value of, say, the = "alg" value in the same context? >=20 > Actually, this sounds more complex than just using some structure in = the messages. >=20 > -- > James Manger >=20 >=20 >=20 >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of >> Mike Jones >> Sent: Tuesday, 23 October 2012 7:33 PM >> To: jose@ietf.org >> Subject: Re: [jose] xpo >>=20 >> Scoping would make sense if we anticipated there being many many key >> parameters in the future, such that future naming conflicts were >> likely. In practice, there are all of eight key parameters defined = at >> present ("alg", "crv", "x", "y", "mod", "xpo", "use", and "kid"). = I've >> heard discussions of maybe one or two more that people might = anticipate >> adding in the future (expiration time is the only one I can remember >> off the top of my head). So at least within the next few years, the >> number might reach a dozen or so. And we already have a registry >> defined that would avoid parameter conflicts. >>=20 >> Adding structure to avoid potential conflicts among at most a dozen = or >> so parameter names seems like significant overkill. In the spirit of >> keeping simple things simple, in practice, I'm sure that a flat >> structure will continue to work out just fine. >>=20 >> Cheers, >> -- Mike >>=20 >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of >> Richard Barnes >> Sent: Monday, October 22, 2012 1:52 PM >> To: Manger, James H >> Cc: bcampbell@pingidentity.com; sakimura@gmail.com; jose@ietf.org; >> Axel.Nennker@telekom.de; vladimir@nimbusds.com >> Subject: Re: [jose] xpo >>=20 >>=20 >> On Oct 19, 2012, at 3:18 AM, Manger, James H wrote: >>=20 >>> "exp" wouldn't clash if we used some JSON structure in a JWK. For >> instance, separate the maths fields of the public key (n, e, ...) = from >> the administrative parts (key-id, certificate, usage...). Instead, = JWK >> goes for a flat bucket for all a key's info. Hence, we have potential >> problems with clashes of names from quite separate domains. We should >> fix the structure, instead of tinkering with the name. >>=20 >> Yes. This. >>=20 >> Most of this WG's problems arise from using flat buckets. Flat = buckets >> don't hold water :) >>=20 >> --Richard >>=20 >>=20 >>=20 >>=20 >>=20 >>>=20 >>> -- >>> James Manger >>>=20 >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf >> Of Axel.Nennker@telekom.de >>> Sent: Friday, 19 October 2012 5:50 PM >>> To: jose@ietf.org >>> Cc: bcampbell@pingidentity.com; sakimura@gmail.com; >> vladimir@nimbusds.com >>> Subject: Re: [jose] xpo >>>=20 >>> I don't know why the exp in jwk needs to be changed. =46rom a = developer >> POW there is no need. You always know which "exp" is the right one. >>> I would reverse the change from exp to xpo. Developers don't need it >> and many did not update their implementation to incorporate the exp- >>> xpo transition. >>>=20 >>> Actually I don't care (much) how the parameters are named. Although = I >> would like to stick to the 3-letter scheme I am OK with the n,e >> proposal. >>> But please stop making breaking changes (especially renaming >> parameters which leads only to more work and no gain). >>>=20 >>> Case1: harm is already done -> stick with xpo and don't change = AGAIN. >>> Case2: Most implementation haven't changed yet -> revert to exp >>> Case3: xpo is just stupid -> n,e is better -> another change -> Oh = no >> -> revert to exp >>>=20 >>> Again: I suggest to revert to exp and make the implementers happy. >>>=20 >>> Axel >>>=20 >>> Cc'ing Nat because I don't want to give away his developer's emails >> without asking. >>>=20 >>>=20 >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf >> Of Brian Campbell >>>=20 >>> +1 (if a parameter name change is going to happen anyway) >>>=20 >>> On Wed, Oct 17, 2012 at 2:24 AM, Vladimir Dzhuvinov / NimbusDS >> wrote: >>> +1 >>>=20 >>> -------- Original Message -------- >>> From: Richard Barnes >>>=20 >>> +1 >>>=20 >>> On Oct 16, 2012, at 6:55 PM, Manger, James H wrote: >>>=20 >>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-06 >>>>> * Changed the name of the JWK RSA exponent parameter from exp to >> xpo so as to allow the potential use of the name exp for a future >> extension that might define an expiration parameter for keys. (The = exp >> name is already used for this purpose in the JWT specification.) >>>>=20 >>>> "n" and "e" would be better than "mod" and "xpo". >>>> "n" and "e" are very widely used for the RSA modulus and public >> exponent. >>>>=20 >>>> s^e =3D m mod n >>>>=20 >>>> -- >>>> James Manger > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From odonoghue@isoc.org Mon Nov 5 15:47: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 3C8BF11E80AD for ; Mon, 5 Nov 2012 15:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.097 X-Spam-Level: X-Spam-Status: No, score=-104.097 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnfi3au2lEyl for ; Mon, 5 Nov 2012 15:47:57 -0800 (PST) Received: from smtp156.dfw.emailsrvr.com (smtp156.dfw.emailsrvr.com [67.192.241.156]) by ietfa.amsl.com (Postfix) with ESMTP id 841B911E80A3 for ; Mon, 5 Nov 2012 15:47:57 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp15.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 2D45D3007DF for ; Mon, 5 Nov 2012 18:47:57 -0500 (EST) X-Virus-Scanned: OK Received: by smtp15.relay.dfw1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id DE94D3007DE for ; Mon, 5 Nov 2012 18:47:56 -0500 (EST) Message-ID: <5098502C.4030507@isoc.org> Date: Mon, 05 Nov 2012 18:47:56 -0500 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: jose@ietf.org References: <20121101121722.29094.73706.idtracker@ietfa.amsl.com> In-Reply-To: <20121101121722.29094.73706.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121101121722.29094.73706.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------070509030106090102010202" Subject: [jose] Fwd: CORRECTION: Help the NomCom X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 23:47:58 -0000 This is a multi-part message in MIME format. --------------070509030106090102010202 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Folks, Just a reminder, nomcom feedback requested by 11 Nov 2012. See Matt's message below. Karen -------- Original Message -------- Subject: CORRECTION: Help the NomCom Date: Thu, 01 Nov 2012 05:17:22 -0700 From: NomCom Chair To: Working Group Chairs I sent a message several hours ago requesting that you help and make your working group aware that the NomCom is looking for input from the community. This message had a minor error. The NomCom needs to receive community input by November 11, 2012. The full text of the corrected message is below --------------------------------------------------- The IETF Nominations Committee (NomCom) continues to seek input from the IETF Community. The NomCom would greatly appreciate any help you could provide in making members of your working group aware of ways in which they can provide valuable feedback to the NomCom. In order to ensure that your input is received in time to be useful, the NomCom needs to receive community feedback on or before Sunday, November 11. The final list of candidates (as per RFC 5680) that the NomCom is considering for open positions can be found at: https://www.ietf.org/group/nomcom/2012/input/ The NomCom will be holding office hours during IETF 85, Monday- Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes comments on specific individuals, as well as general feedback related to any of the positions that NomCom is considering. Note: A list of leadership positions that the NomCom is considering can be found at: https://www.ietf.org/group/nomcom/2012/ If the NomCom office hours are inconvenient for you or if you cannot attend IETF 85, the NomCom is happy to take community input via email to nomcom12 at ietf.org. Additionally, the NomCom is happy to arrange a meeting outside of office hours, just send us email and we can set something up. Comments on specific candidates can also be provided to the NomCom via the web feedback tool: https://www.ietf.org/group/nomcom/2012/input/ Thank you for your help, - Matt Lepinski nomcom-chair at ietf.org --------------070509030106090102010202 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Folks,

Just a reminder, nomcom feedback requested by 11 Nov 2012. See Matt's message below.

Karen

-------- Original Message --------
Subject: CORRECTION: Help the NomCom
Date: Thu, 01 Nov 2012 05:17:22 -0700
From: NomCom Chair <nomcom-chair@ietf.org>
To: Working Group Chairs <wgchairs@ietf.org> 


I sent a message several hours ago requesting that you help and make 
your working group aware that the NomCom is looking for input from the 
community. This message had a minor error. The NomCom needs to 
receive community input by November 11, 2012. 

The full text of the corrected message is below
---------------------------------------------------

The IETF Nominations Committee (NomCom) continues to seek input from
the IETF Community. The NomCom would greatly appreciate any help you
could provide in making members of your working group aware of ways in
which they can provide valuable feedback to the NomCom.

In order to ensure that your input is received in time to be useful, the 
NomCom needs to receive community feedback on or before Sunday, November 11.

The final list of candidates (as per RFC 5680) that the NomCom is 
considering for open positions can be found at: 
https://www.ietf.org/group/nomcom/2012/input/

The NomCom will be holding office hours during IETF 85, Monday-
Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes 
comments on specific individuals, as well as general feedback related to 
any of the positions that NomCom is considering.

Note: A list of leadership positions that the NomCom is considering can be 
found at: https://www.ietf.org/group/nomcom/2012/

If the NomCom office hours are inconvenient for you or if you cannot 
attend IETF 85, the NomCom is happy to take community input via email 
to nomcom12 at ietf.org. Additionally, the NomCom is happy to arrange a 
meeting outside of office hours, just send us email and we can set 
something up.

Comments on specific candidates can also be provided to the NomCom
via the web feedback tool: 
https://www.ietf.org/group/nomcom/2012/input/

Thank you for your help,
- Matt Lepinski
  nomcom-chair at ietf.org



--------------070509030106090102010202-- From Axel.Nennker@telekom.de Tue Nov 6 07:02: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 E269E21F898F for ; Tue, 6 Nov 2012 07:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcF2Use5L+gG for ; Tue, 6 Nov 2012 07:02:06 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id D2CAA21F8A46 for ; Tue, 6 Nov 2012 07:02:05 -0800 (PST) Received: from he111296.emea1.cds.t-internal.com ([10.125.90.14]) by tcmail21.telekom.de with ESMTP; 05 Nov 2012 15:31:41 +0100 Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.94]) by HE111296.EMEA1.CDS.T-INTERNAL.COM ([fe80::19ac:3fb4:a382:6df4%16]) with mapi; Mon, 5 Nov 2012 15:31:41 +0100 From: To: Date: Mon, 5 Nov 2012 15:31:40 +0100 Thread-Topic: [jose] encrypting AND signing a token Thread-Index: AQHNuQ3KoFNZ2fysZU+2R3+vnzYsspfWsFUAgAAMIoCAA0SWgIAAGaMAgAAPmoCAAAkkIIAA14lg Message-ID: References: <4ACFC778-31A9-4C79-9F4E-7C01719F51AD@gmail.com> <4E1F6AAD24975D4BA5B168042967394366887325@TK5EX14MBXC285.redmond.corp.microsoft.com> <000b01cdbab9$967ef070$c37cd150$@augustcellars.com> <210E03E3-FD49-449A-8953-571ECA9E5FBE@gmail.com>, <001101cdbace$34906500$9db12f00$@augustcellars.com> <0C8F9A45306BD9499EAD612A10CFF8942BE45035@AMXPRD0310MB353.eurprd03.prod.outlook.com> In-Reply-To: <0C8F9A45306BD9499EAD612A10CFF8942BE45035@AMXPRD0310MB353.eurprd03.prod.outlook.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] encrypting AND signing a token 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, 06 Nov 2012 15:02:13 -0000 I think that it is NOT necessary to have ONE crypto op for signing and simu= ltaneous encryption.=20 I think we should define ONE signed and encrypted JWT. As was stated in previous emails: This is a very common use case. If this paper is true http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.= html then we have these options: 1) naming repair 2) sign/encrypt/sign 3) encrypt/sign/encrypt The naming repair is difficult with JWT because we don't handle sender and = recipient names. The other two seem to cost a lot. I guess that in Dick's use case the naming repair will work and I think we = should add senderID and recipientID to JWT and make it then mandatory for s= ign&encrypt. -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik= e Scott Sent: Sunday, November 04, 2012 10:27 PM To: jose@ietf.org Subject: Re: [jose] encrypting AND signing a token Signcryption? http://www.signcryption.org/standards/ Mike Scott ________________________________________ From: jose-bounces@ietf.org [jose-bounces@ietf.org] on behalf of Jim Schaad= [ietf@augustcellars.com] Sent: 04 November 2012 20:51 To: 'Dick Hardt' Cc: 'Mike Jones'; jose@ietf.org Subject: Re: [jose] encrypting AND signing a token > -----Original Message----- > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Sunday, November 04, 2012 2:56 PM > To: Jim Schaad > Cc: 'Dick Hardt'; 'Mike Jones'; jose@ietf.org > Subject: Re: [jose] encrypting AND signing a token > > Thanks Jim. An interesting historical reference. > > In my use case, who signed or who the token is for is not a secret. The > payload needs to be kept a secret. > > Does no one sign and encrypt SAML tokens? > Is this not a common use case? Everything I have seen does this as independent operations. Jim > > If it does need to be solved, it would seem to me that a standards body > would be the place to have lots of eyes look at how to sign and encrypt a > token so that people do not do naive sign and encrypt. > > Q: does anyone else need to sign and encrypt? > > -- Dick > > On Nov 4, 2012, at 10:24 AM, "Jim Schaad" wrote: > > > > > > > I would note that the original PKCS#7 specifications had a mode that > > provided a similar sign and encrypt as a single operation mode. When > > the > > PKCS#7 specifications where adopted by the IETF as part of the CMS > > work, this mode was discussed and very deliberately dropped because of > > numerous security problems that had been found. These included (but > > are not limited > > to) the fact that it was signed or who signed it was sometimes a > > security leak. Also there were attacks where the signed and encrypted > > mode could be converted to just an encrypted mode. > > > > I would think that there would be a need for a very detailed security > > analysis that we are not prepared to do in order to support a signed > > and encrypted mode. > > > > Jim > > > > > >> -----Original Message----- > >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > >> Of Dick Hardt > >> Sent: Friday, November 02, 2012 12:30 PM > >> To: Mike Jones > >> Cc: jose@ietf.org > >> Subject: Re: [jose] encrypting AND signing a token > >> > >> Not only is my original token increasing in size by 4/3, I am also > >> adding another header, payload and signature. > >> > >> One of the objectives of JWT was to enabled compact tokens. It would > >> seem that we should be able to support both signing and encryption of > >> the same token. > >> > >> All the encryption use cases I can think of involving asymmetric keys > > would > >> also require signing with the senders private key. > >> > >> My suggestion is to be explicit in what the algorithm etc. is used for= : > >> > >> Rather than "alg" and "enc", we have: > >> > >> "algs" - algorithm for token signing > >> "algk" - algorithm for content management key encryption "alge" - > > algorithm > >> for payload encryption > >> > >> Similiarly, > >> > >> "kids" - key id for signing > >> "kidk" - key id for content managment key encryption > >> > >> We could probably make these three or even two letter codes if you > >> want to save a couple bytes. > >> > >> -- Dick > >> > >> On Nov 2, 2012, at 8:46 AM, Mike Jones > >> wrote: > >> > >>> The way you put it brings one straightforward solution to mind. > >>> Solve > > 1-3 > >> with a JWE. Solve 4-5 by signing the JWE as a JWS payload. Done. > >>> > >>> I do understand that the 4/3 space blowup-of double base64url > >>> encoding > >> the JWE motivates your earlier proposal about nested signing. (See > >> Dick's > >> 10/29/12 message "[jose] signing an existing JWT".) I also > >> understand > > that if > >> you could do integrity with the asymmetric signature then the > >> integrity provided by the JWE itself may be redundant. I don't have > >> a specific > > proposal > >> on how to do that. > >>> > >>> -- Mike > >>> > >>> -----Original Message----- > >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > >>> Of Dick Hardt > >>> Sent: Friday, November 02, 2012 8:22 AM > >>> To: jose@ietf.org > >>> Subject: [jose] encrypting AND signing a token > >>> > >>> I am trying to figure out how to implement JWT/JWS/JWE to solve a > >>> real > >> world problem. > >>> > >>> 1) Bob sends a token to Charlie via Alice. (Alice gets token from > >>> Bob and then Alice gives token to Charlie) > >>> 2) Alice must be prevented from reading the token. (token needs to > >>> be > >>> encrypted) > >>> 3) Bob and Charlie can share a symmetric key. > >>> > >>> I can solve this with JWE. > >>> > >>> Now let's add another condition. > >>> > >>> 4) Charlie wants non-repuditation that Bob created the token. > >>> 5) Bob has a private key and a public key > >>> > >>> I don't see how to do this using JWE. It seems I have to sign the > >>> same > > token > >> I had previously with JWS. This seems inefficient since I should be > >> able > > to > >> replace the JWE integrity computation done with the symmetric key > >> with the private key -- but the "alg" parameter is the same in both > >> encrypting and signing. > >>> > >>> Now let's expand this to replacing the symmetric key with a > > public/private > >> key pair for encryption. Bob encrypts with Charlies public key and > >> signs > > with > >> Bob's private key (we also need to make sure we are not doing naive > >> encryption and signing here, would be a really useful to specify what > > needs > >> to be done there). Now we need to have parameters for both > >> public/private key pairs in the header. > >>> > >>> Am I missing something here? > >>> > >>> Seems like we can do this if we change the header parameters to > >>> specify > > if > >> they ("alg", "kid", et.c) are for token signing, payload encryption > >> or > > content > >> key encryption. > >>> > >>> -- Dick > >>> > >>> > >>> _______________________________________________ > >>> 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 > > _______________________________________________ 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 ve7jtb@ve7jtb.com Tue Nov 6 07:37: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 4256C21F89D4 for ; Tue, 6 Nov 2012 07:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qv4tkYApN8xw for ; Tue, 6 Nov 2012 07:37:52 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6421621F89D3 for ; Tue, 6 Nov 2012 07:37:52 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so440361pad.31 for ; Tue, 06 Nov 2012 07:37:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=vTSUgwLqw1/NCOBgLXZpRmlwvDIJONUTa0JFJDmxQSE=; b=XC4phkZDGcBa/nH2dfPgw4fDlOiSdscjy+83GxO/IJxD2g6dySh4uE/cY2m5tFpP6R 3r2nSVygB+JLpdncdmZHCUu8NJ57JCN2Z7AyZlJjFerwb2iDQ2vLTx0mhs18KNTLyt1W FpIwziaO/6DFXRN3TjF0AGf77guCrOEK2YXLT5HUC7ZjAMEkEbFaTmdjGMz+8ByfWcjF iIwMD1j6l0UcmklAu3StnM+sbu57O8dQDEEWm1b7Sco5yrEhPbZeRxu1Irva1k9AHmW9 a+AvsDTw3+eFqiSIujl71HlsyF6K6uHg4bSMHvgnj1E/h6KzMOZSdj5wVpVyc1Zg+s7s RllQ== Received: by 10.68.234.100 with SMTP id ud4mr4362408pbc.82.1352216272172; Tue, 06 Nov 2012 07:37:52 -0800 (PST) Received: from dhcp-5445.meeting.ietf.org (dhcp-5445.meeting.ietf.org. [130.129.84.69]) by mx.google.com with ESMTPS id n6sm12628915pav.18.2012.11.06.07.37.49 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Nov 2012 07:37:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <210E03E3-FD49-449A-8953-571ECA9E5FBE@gmail.com> Date: Tue, 6 Nov 2012 10:37:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1C292375-A9C4-440A-870A-79A85D085B9A@ve7jtb.com> References: <4ACFC778-31A9-4C79-9F4E-7C01719F51AD@gmail.com> <4E1F6AAD24975D4BA5B168042967394366887325@TK5EX14MBXC285.redmond.corp.microsoft.com> <000b01cdbab9$967ef070$c37cd150$@augustcellars.com> <210E03E3-FD49-449A-8953-571ECA9E5FBE@gmail.com> To: Dick Hardt X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkgb7FWOV8PnkF8RrsQQCFWFeidn50gpMIagAFwkljr5RxTmvZ36MZKPU8EWF2YffQgyzFg Cc: Jim Schaad , 'Mike Jones' , jose@ietf.org Subject: Re: [jose] encrypting AND signing a token 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, 06 Nov 2012 15:37:53 -0000 SAML performs this as separate operations. Now in some cases the assertion is signed then encrypted and then the = message signed to deal with the AESCBC padding oracle attack. There is non technical issue around the use of qualified signatures in = cases where non repudiation is required. Signing a encrypted object has different connotations than signing a = unencrypted one. =20 I don't know what the status of a combined operation would be. It is = probably not relevant to your use case. At IETF #83 I presented including ECDH-SS as an encryption option as it = provides sender verification. I think that would answer your use case, depending on how you feel about = EC. The work group rejected adding that algorithm at the time on the grounds = that it is not used in places where it is supported. ECDH-ES is defined and is considered more secure than ECDH-SS mostly = because it is harder to get wrong. I am not recommending revisiting the issue, but it would be a way to = address the composite use case. Despite being a Canadian I am not shilling for certicom. Just saying. John B. On 2012-11-04, at 2:55 PM, Dick Hardt wrote: > Thanks Jim. An interesting historical reference.=20 >=20 > In my use case, who signed or who the token is for is not a secret. = The payload needs to be kept a secret. >=20 > Does no one sign and encrypt SAML tokens? > Is this not a common use case? >=20 > If it does need to be solved, it would seem to me that a standards = body would be the place to have lots of eyes look at how to sign and = encrypt a token so that people do not do naive sign and encrypt. >=20 > Q: does anyone else need to sign and encrypt? >=20 > -- Dick >=20 > On Nov 4, 2012, at 10:24 AM, "Jim Schaad" = wrote: >=20 >> >>=20 >> I would note that the original PKCS#7 specifications had a mode that >> provided a similar sign and encrypt as a single operation mode. When = the >> PKCS#7 specifications where adopted by the IETF as part of the CMS = work, >> this mode was discussed and very deliberately dropped because of = numerous >> security problems that had been found. These included (but are not = limited >> to) the fact that it was signed or who signed it was sometimes a = security >> leak. Also there were attacks where the signed and encrypted mode = could be >> converted to just an encrypted mode. >>=20 >> I would think that there would be a need for a very detailed security >> analysis that we are not prepared to do in order to support a signed = and >> encrypted mode. >>=20 >> Jim >>=20 >>=20 >>> -----Original Message----- >>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of >>> Dick Hardt >>> Sent: Friday, November 02, 2012 12:30 PM >>> To: Mike Jones >>> Cc: jose@ietf.org >>> Subject: Re: [jose] encrypting AND signing a token >>>=20 >>> Not only is my original token increasing in size by 4/3, I am also = adding >>> another header, payload and signature. >>>=20 >>> One of the objectives of JWT was to enabled compact tokens. It would = seem >>> that we should be able to support both signing and encryption of the = same >>> token. >>>=20 >>> All the encryption use cases I can think of involving asymmetric = keys >> would >>> also require signing with the senders private key. >>>=20 >>> My suggestion is to be explicit in what the algorithm etc. is used = for: >>>=20 >>> Rather than "alg" and "enc", we have: >>>=20 >>> "algs" - algorithm for token signing >>> "algk" - algorithm for content management key encryption "alge" - >> algorithm >>> for payload encryption >>>=20 >>> Similiarly, >>>=20 >>> "kids" - key id for signing >>> "kidk" - key id for content managment key encryption >>>=20 >>> We could probably make these three or even two letter codes if you = want to >>> save a couple bytes. >>>=20 >>> -- Dick >>>=20 >>> On Nov 2, 2012, at 8:46 AM, Mike Jones >>> wrote: >>>=20 >>>> The way you put it brings one straightforward solution to mind. = Solve >> 1-3 >>> with a JWE. Solve 4-5 by signing the JWE as a JWS payload. Done. >>>>=20 >>>> I do understand that the 4/3 space blowup-of double base64url = encoding >>> the JWE motivates your earlier proposal about nested signing. (See = Dick's >>> 10/29/12 message "[jose] signing an existing JWT".) I also = understand >> that if >>> you could do integrity with the asymmetric signature then the = integrity >>> provided by the JWE itself may be redundant. I don't have a = specific >> proposal >>> on how to do that. >>>>=20 >>>> -- Mike >>>>=20 >>>> -----Original Message----- >>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf >>>> Of Dick Hardt >>>> Sent: Friday, November 02, 2012 8:22 AM >>>> To: jose@ietf.org >>>> Subject: [jose] encrypting AND signing a token >>>>=20 >>>> I am trying to figure out how to implement JWT/JWS/JWE to solve a = real >>> world problem. >>>>=20 >>>> 1) Bob sends a token to Charlie via Alice. (Alice gets token from = Bob >>>> and then Alice gives token to Charlie) >>>> 2) Alice must be prevented from reading the token. (token needs to = be >>>> encrypted) >>>> 3) Bob and Charlie can share a symmetric key. >>>>=20 >>>> I can solve this with JWE. >>>>=20 >>>> Now let's add another condition. >>>>=20 >>>> 4) Charlie wants non-repuditation that Bob created the token. >>>> 5) Bob has a private key and a public key >>>>=20 >>>> I don't see how to do this using JWE. It seems I have to sign the = same >> token >>> I had previously with JWS. This seems inefficient since I should be = able >> to >>> replace the JWE integrity computation done with the symmetric key = with the >>> private key -- but the "alg" parameter is the same in both = encrypting and >>> signing. >>>>=20 >>>> Now let's expand this to replacing the symmetric key with a >> public/private >>> key pair for encryption. Bob encrypts with Charlies public key and = signs >> with >>> Bob's private key (we also need to make sure we are not doing naive >>> encryption and signing here, would be a really useful to specify = what >> needs >>> to be done there). Now we need to have parameters for both = public/private >>> key pairs in the header. >>>>=20 >>>> Am I missing something here? >>>>=20 >>>> Seems like we can do this if we change the header parameters to = specify >> if >>> they ("alg", "kid", et.c) are for token signing, payload encryption = or >> content >>> key encryption. >>>>=20 >>>> -- Dick >>>>=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 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From ve7jtb@ve7jtb.com Tue Nov 6 07:50: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 5AA9221F89AE for ; Tue, 6 Nov 2012 07:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RthWBrFrJIvf for ; Tue, 6 Nov 2012 07:50:33 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5054C21F89A1 for ; Tue, 6 Nov 2012 07:50:33 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so508565pbb.31 for ; Tue, 06 Nov 2012 07:50:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=dFo2hIWAoweCOgWPJs12bpq7QXJBTmU/TggprqKZK+g=; b=kP5bVVIVSWLQX63yTJnjUl913i6nEo1KubYJYZ0ffQcaXfnySuCEPSELHjTWQ9TrXF L0SgbfbSkoZqSH82ANTWTW7p++uYN5m7m8xPPUd4aHnzskz0m4n4sArECGYhBz4Xqasp 5fvB0FEEKIsn9jomLW742Us98krCVxpVaU7vChhGl9nGb4ThQqa24DpjSR/1gwf9k224 8Qk4zdc0JP0ss+S8TFhrrmy/wHl9aj6R7qbgz94kh28lO8WBFb3bUcs0MX+DQ4z4FGbE gBu+kTerWEVwmJB5yIK6anzGhgNWAUKOAZWXus9gVJQvXD/+QKauVrFTX7l0teEgOdF0 WnyA== Received: by 10.68.227.162 with SMTP id sb2mr4755274pbc.4.1352217033063; Tue, 06 Nov 2012 07:50:33 -0800 (PST) Received: from dhcp-5445.meeting.ietf.org (dhcp-5445.meeting.ietf.org. [130.129.84.69]) by mx.google.com with ESMTPS id uk9sm12516161pbc.63.2012.11.06.07.50.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Nov 2012 07:50:32 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <1C292375-A9C4-440A-870A-79A85D085B9A@ve7jtb.com> Date: Tue, 6 Nov 2012 10:50:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <796B4958-C30C-4242-BFC7-CCB7416A9CBD@ve7jtb.com> References: <4ACFC778-31A9-4C79-9F4E-7C01719F51AD@gmail.com> <4E1F6AAD24975D4BA5B168042967394366887325@TK5EX14MBXC285.redmond.corp.microsoft.com> <000b01cdbab9$967ef070$c37cd150$@augustcellars.com> <210E03E3-FD49-449A-8953-571ECA9E5FBE@gmail.com> <1C292375-A9C4-440A-870A-79A85D085B9A@ve7jtb.com> To: Dick Hardt X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkl9k+9DMLRN8RbQYLW6/blwNUy9ffnA8LE1t/hNz62Q7vXvuVrhnuVLStp36MCzc4wFZYw Cc: Jim Schaad , 'Mike Jones' , jose@ietf.org Subject: Re: [jose] encrypting AND signing a token 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, 06 Nov 2012 15:50:34 -0000 I should also note that with symmetric keys, the alg option of A128KW = with an enc of A128CBC+HS256 effectively gives you signing and = encryption in a single JWE. That doesn't solve the asymmetric signing case, but may work for some = people . John B. On 2012-11-06, at 10:37 AM, John Bradley wrote: > SAML performs this as separate operations. >=20 > Now in some cases the assertion is signed then encrypted and then the = message signed to deal with the AESCBC padding oracle attack. >=20 > There is non technical issue around the use of qualified signatures in = cases where non repudiation is required. > Signing a encrypted object has different connotations than signing a = unencrypted one. =20 >=20 > I don't know what the status of a combined operation would be. It is = probably not relevant to your use case. >=20 > At IETF #83 I presented including ECDH-SS as an encryption option as = it provides sender verification. > I think that would answer your use case, depending on how you feel = about EC. >=20 > The work group rejected adding that algorithm at the time on the = grounds that it is not used in places where it is supported. > ECDH-ES is defined and is considered more secure than ECDH-SS mostly = because it is harder to get wrong. >=20 > I am not recommending revisiting the issue, but it would be a way to = address the composite use case. >=20 > Despite being a Canadian I am not shilling for certicom. Just saying. >=20 > John B. > On 2012-11-04, at 2:55 PM, Dick Hardt wrote: >=20 >> Thanks Jim. An interesting historical reference.=20 >>=20 >> In my use case, who signed or who the token is for is not a secret. = The payload needs to be kept a secret. >>=20 >> Does no one sign and encrypt SAML tokens? >> Is this not a common use case? >>=20 >> If it does need to be solved, it would seem to me that a standards = body would be the place to have lots of eyes look at how to sign and = encrypt a token so that people do not do naive sign and encrypt. >>=20 >> Q: does anyone else need to sign and encrypt? >>=20 >> -- Dick >>=20 >> On Nov 4, 2012, at 10:24 AM, "Jim Schaad" = wrote: >>=20 >>> >>>=20 >>> I would note that the original PKCS#7 specifications had a mode that >>> provided a similar sign and encrypt as a single operation mode. = When the >>> PKCS#7 specifications where adopted by the IETF as part of the CMS = work, >>> this mode was discussed and very deliberately dropped because of = numerous >>> security problems that had been found. These included (but are not = limited >>> to) the fact that it was signed or who signed it was sometimes a = security >>> leak. Also there were attacks where the signed and encrypted mode = could be >>> converted to just an encrypted mode. >>>=20 >>> I would think that there would be a need for a very detailed = security >>> analysis that we are not prepared to do in order to support a signed = and >>> encrypted mode. >>>=20 >>> Jim >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf Of >>>> Dick Hardt >>>> Sent: Friday, November 02, 2012 12:30 PM >>>> To: Mike Jones >>>> Cc: jose@ietf.org >>>> Subject: Re: [jose] encrypting AND signing a token >>>>=20 >>>> Not only is my original token increasing in size by 4/3, I am also = adding >>>> another header, payload and signature. >>>>=20 >>>> One of the objectives of JWT was to enabled compact tokens. It = would seem >>>> that we should be able to support both signing and encryption of = the same >>>> token. >>>>=20 >>>> All the encryption use cases I can think of involving asymmetric = keys >>> would >>>> also require signing with the senders private key. >>>>=20 >>>> My suggestion is to be explicit in what the algorithm etc. is used = for: >>>>=20 >>>> Rather than "alg" and "enc", we have: >>>>=20 >>>> "algs" - algorithm for token signing >>>> "algk" - algorithm for content management key encryption "alge" - >>> algorithm >>>> for payload encryption >>>>=20 >>>> Similiarly, >>>>=20 >>>> "kids" - key id for signing >>>> "kidk" - key id for content managment key encryption >>>>=20 >>>> We could probably make these three or even two letter codes if you = want to >>>> save a couple bytes. >>>>=20 >>>> -- Dick >>>>=20 >>>> On Nov 2, 2012, at 8:46 AM, Mike Jones = >>>> wrote: >>>>=20 >>>>> The way you put it brings one straightforward solution to mind. = Solve >>> 1-3 >>>> with a JWE. Solve 4-5 by signing the JWE as a JWS payload. Done. >>>>>=20 >>>>> I do understand that the 4/3 space blowup-of double base64url = encoding >>>> the JWE motivates your earlier proposal about nested signing. (See = Dick's >>>> 10/29/12 message "[jose] signing an existing JWT".) I also = understand >>> that if >>>> you could do integrity with the asymmetric signature then the = integrity >>>> provided by the JWE itself may be redundant. I don't have a = specific >>> proposal >>>> on how to do that. >>>>>=20 >>>>> -- Mike >>>>>=20 >>>>> -----Original Message----- >>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf >>>>> Of Dick Hardt >>>>> Sent: Friday, November 02, 2012 8:22 AM >>>>> To: jose@ietf.org >>>>> Subject: [jose] encrypting AND signing a token >>>>>=20 >>>>> I am trying to figure out how to implement JWT/JWS/JWE to solve a = real >>>> world problem. >>>>>=20 >>>>> 1) Bob sends a token to Charlie via Alice. (Alice gets token from = Bob >>>>> and then Alice gives token to Charlie) >>>>> 2) Alice must be prevented from reading the token. (token needs to = be >>>>> encrypted) >>>>> 3) Bob and Charlie can share a symmetric key. >>>>>=20 >>>>> I can solve this with JWE. >>>>>=20 >>>>> Now let's add another condition. >>>>>=20 >>>>> 4) Charlie wants non-repuditation that Bob created the token. >>>>> 5) Bob has a private key and a public key >>>>>=20 >>>>> I don't see how to do this using JWE. It seems I have to sign the = same >>> token >>>> I had previously with JWS. This seems inefficient since I should be = able >>> to >>>> replace the JWE integrity computation done with the symmetric key = with the >>>> private key -- but the "alg" parameter is the same in both = encrypting and >>>> signing. >>>>>=20 >>>>> Now let's expand this to replacing the symmetric key with a >>> public/private >>>> key pair for encryption. Bob encrypts with Charlies public key and = signs >>> with >>>> Bob's private key (we also need to make sure we are not doing naive >>>> encryption and signing here, would be a really useful to specify = what >>> needs >>>> to be done there). Now we need to have parameters for both = public/private >>>> key pairs in the header. >>>>>=20 >>>>> Am I missing something here? >>>>>=20 >>>>> Seems like we can do this if we change the header parameters to = specify >>> if >>>> they ("alg", "kid", et.c) are for token signing, payload encryption = or >>> content >>>> key encryption. >>>>>=20 >>>>> -- Dick >>>>>=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 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 From ietf@augustcellars.com Tue Nov 6 07:54: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 8922721F89A0 for ; Tue, 6 Nov 2012 07:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pe1QP3-L+-ll for ; Tue, 6 Nov 2012 07:54:35 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA4421F8508 for ; Tue, 6 Nov 2012 07:54:35 -0800 (PST) Received: from Philemon (dhcp-120b.meeting.ietf.org [130.129.18.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 8456F38F0E; Tue, 6 Nov 2012 07:54:34 -0800 (PST) From: "Jim Schaad" To: "'John Bradley'" , "'Dick Hardt'" References: <4ACFC778-31A9-4C79-9F4E-7C01719F51AD@gmail.com> <4E1F6AAD24975D4BA5B168042967394366887325@TK5EX14MBXC285.redmond.corp.microsoft.com> <000b01cdbab9$967ef070$c37cd150$@augustcellars.com> <210E03E3-FD49-449A-8953-571ECA9E5FBE@gmail.com> <1C292375-A9C4-440A-870A-79A85D085B9A@ve7jtb.com> <796B4958-C30C-4242-BFC7-CCB7416A9CBD@ve7jtb.com> In-Reply-To: <796B4958-C30C-4242-BFC7-CCB7416A9CBD@ve7jtb.com> Date: Tue, 6 Nov 2012 10:54:26 -0500 Message-ID: <01dd01cdbc37$00ce5dc0$026b1940$@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: AQJk3UBi+7c9NJolq0gv1z0r2pGfkgJRTlTwAoSEM20BgKfcgQFj4EGHAYSMcdcCQA7pApZSu4sg Content-Language: en-us Cc: 'Mike Jones' , jose@ietf.org Subject: Re: [jose] encrypting AND signing a token 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, 06 Nov 2012 15:54:36 -0000 Only if you have a really loose definition of signing - it gives you an integrity check but not origination which is usually implied by the term signing Jim > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com] > Sent: Tuesday, November 06, 2012 10:50 AM > To: Dick Hardt > Cc: Jim Schaad; 'Mike Jones'; jose@ietf.org > Subject: Re: [jose] encrypting AND signing a token > > I should also note that with symmetric keys, the alg option of A128KW with > an enc of A128CBC+HS256 effectively gives you signing and encryption in a > single JWE. > > That doesn't solve the asymmetric signing case, but may work for some > people . > > John B. > On 2012-11-06, at 10:37 AM, John Bradley wrote: > > > SAML performs this as separate operations. > > > > Now in some cases the assertion is signed then encrypted and then the > message signed to deal with the AESCBC padding oracle attack. > > > > There is non technical issue around the use of qualified signatures in cases > where non repudiation is required. > > Signing a encrypted object has different connotations than signing a > unencrypted one. > > > > I don't know what the status of a combined operation would be. It is > probably not relevant to your use case. > > > > At IETF #83 I presented including ECDH-SS as an encryption option as it > provides sender verification. > > I think that would answer your use case, depending on how you feel about > EC. > > > > The work group rejected adding that algorithm at the time on the grounds > that it is not used in places where it is supported. > > ECDH-ES is defined and is considered more secure than ECDH-SS mostly > because it is harder to get wrong. > > > > I am not recommending revisiting the issue, but it would be a way to > address the composite use case. > > > > Despite being a Canadian I am not shilling for certicom. Just saying. > > > > John B. > > On 2012-11-04, at 2:55 PM, Dick Hardt wrote: > > > >> Thanks Jim. An interesting historical reference. > >> > >> In my use case, who signed or who the token is for is not a secret. The > payload needs to be kept a secret. > >> > >> Does no one sign and encrypt SAML tokens? > >> Is this not a common use case? > >> > >> If it does need to be solved, it would seem to me that a standards body > would be the place to have lots of eyes look at how to sign and encrypt a > token so that people do not do naive sign and encrypt. > >> > >> Q: does anyone else need to sign and encrypt? > >> > >> -- Dick > >> > >> On Nov 4, 2012, at 10:24 AM, "Jim Schaad" > wrote: > >> > >>> > >>> > >>> I would note that the original PKCS#7 specifications had a mode that > >>> provided a similar sign and encrypt as a single operation mode. > >>> When the > >>> PKCS#7 specifications where adopted by the IETF as part of the CMS > >>> work, this mode was discussed and very deliberately dropped because > >>> of numerous security problems that had been found. These included > >>> (but are not limited > >>> to) the fact that it was signed or who signed it was sometimes a > >>> security leak. Also there were attacks where the signed and > >>> encrypted mode could be converted to just an encrypted mode. > >>> > >>> I would think that there would be a need for a very detailed > >>> security analysis that we are not prepared to do in order to support > >>> a signed and encrypted mode. > >>> > >>> Jim > >>> > >>> > >>>> -----Original Message----- > >>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On > >>>> Behalf Of Dick Hardt > >>>> Sent: Friday, November 02, 2012 12:30 PM > >>>> To: Mike Jones > >>>> Cc: jose@ietf.org > >>>> Subject: Re: [jose] encrypting AND signing a token > >>>> > >>>> Not only is my original token increasing in size by 4/3, I am also > >>>> adding another header, payload and signature. > >>>> > >>>> One of the objectives of JWT was to enabled compact tokens. It > >>>> would seem that we should be able to support both signing and > >>>> encryption of the same token. > >>>> > >>>> All the encryption use cases I can think of involving asymmetric > >>>> keys > >>> would > >>>> also require signing with the senders private key. > >>>> > >>>> My suggestion is to be explicit in what the algorithm etc. is used for: > >>>> > >>>> Rather than "alg" and "enc", we have: > >>>> > >>>> "algs" - algorithm for token signing "algk" - algorithm for content > >>>> management key encryption "alge" - > >>> algorithm > >>>> for payload encryption > >>>> > >>>> Similiarly, > >>>> > >>>> "kids" - key id for signing > >>>> "kidk" - key id for content managment key encryption > >>>> > >>>> We could probably make these three or even two letter codes if you > >>>> want to save a couple bytes. > >>>> > >>>> -- Dick > >>>> > >>>> On Nov 2, 2012, at 8:46 AM, Mike Jones > >>>> > >>>> wrote: > >>>> > >>>>> The way you put it brings one straightforward solution to mind. > >>>>> Solve > >>> 1-3 > >>>> with a JWE. Solve 4-5 by signing the JWE as a JWS payload. Done. > >>>>> > >>>>> I do understand that the 4/3 space blowup-of double base64url > >>>>> encoding > >>>> the JWE motivates your earlier proposal about nested signing. (See > >>>> Dick's > >>>> 10/29/12 message "[jose] signing an existing JWT".) I also > >>>> understand > >>> that if > >>>> you could do integrity with the asymmetric signature then the > >>>> integrity provided by the JWE itself may be redundant. I don't > >>>> have a specific > >>> proposal > >>>> on how to do that. > >>>>> > >>>>> -- Mike > >>>>> > >>>>> -----Original Message----- > >>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On > >>>>> Behalf Of Dick Hardt > >>>>> Sent: Friday, November 02, 2012 8:22 AM > >>>>> To: jose@ietf.org > >>>>> Subject: [jose] encrypting AND signing a token > >>>>> > >>>>> I am trying to figure out how to implement JWT/JWS/JWE to solve a > >>>>> real > >>>> world problem. > >>>>> > >>>>> 1) Bob sends a token to Charlie via Alice. (Alice gets token from > >>>>> Bob and then Alice gives token to Charlie) > >>>>> 2) Alice must be prevented from reading the token. (token needs to > >>>>> be > >>>>> encrypted) > >>>>> 3) Bob and Charlie can share a symmetric key. > >>>>> > >>>>> I can solve this with JWE. > >>>>> > >>>>> Now let's add another condition. > >>>>> > >>>>> 4) Charlie wants non-repuditation that Bob created the token. > >>>>> 5) Bob has a private key and a public key > >>>>> > >>>>> I don't see how to do this using JWE. It seems I have to sign the > >>>>> same > >>> token > >>>> I had previously with JWS. This seems inefficient since I should be > >>>> able > >>> to > >>>> replace the JWE integrity computation done with the symmetric key > >>>> with the private key -- but the "alg" parameter is the same in both > >>>> encrypting and signing. > >>>>> > >>>>> Now let's expand this to replacing the symmetric key with a > >>> public/private > >>>> key pair for encryption. Bob encrypts with Charlies public key and > >>>> signs > >>> with > >>>> Bob's private key (we also need to make sure we are not doing naive > >>>> encryption and signing here, would be a really useful to specify > >>>> what > >>> needs > >>>> to be done there). Now we need to have parameters for both > >>>> public/private key pairs in the header. > >>>>> > >>>>> Am I missing something here? > >>>>> > >>>>> Seems like we can do this if we change the header parameters to > >>>>> specify > >>> if > >>>> they ("alg", "kid", et.c) are for token signing, payload encryption > >>>> or > >>> content > >>>> key encryption. > >>>>> > >>>>> -- Dick > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>> > >> > >> _______________________________________________ > >> jose mailing list > >> jose@ietf.org > >> https://www.ietf.org/mailman/listinfo/jose > > From rbarnes@bbn.com Tue Nov 6 08:11: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 91C3A21F8A4F for ; Tue, 6 Nov 2012 08:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.599 X-Spam-Level: X-Spam-Status: No, score=-108.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EM0gz+ATsfnR for ; Tue, 6 Nov 2012 08:11:51 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFFF21F8A52 for ; Tue, 6 Nov 2012 08:11:51 -0800 (PST) Received: from [128.89.254.139] (port=60933) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TVljS-00033w-9I; Tue, 06 Nov 2012 11:10:30 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Richard L. Barnes" In-Reply-To: <01dd01cdbc37$00ce5dc0$026b1940$@augustcellars.com> Date: Tue, 6 Nov 2012 11:10:26 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <4ACFC778-31A9-4C79-9F4E-7C01719F51AD@gmail.com> <4E1F6AAD24975D4BA5B168042967394366887325@TK5EX14MBXC285.redmond.corp.microsoft.com> <000b01cdbab9$967ef070$c37cd150$@augustcellars.com> <210E03E3-FD49-449A-8953-571ECA9E5FBE@gmail.com> <1C292375-A9C4-440A-870A-79A85D085B9A@ve7jtb.com> <796B4958-C30C-4242-BFC7-CCB7416A9CBD@ve7jtb.com> <01dd01cdbc37$00ce5dc0$026b1940$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1499) Cc: 'John Bradley' , 'Mike Jones' , jose@ietf.org, 'Dick Hardt' Subject: Re: [jose] encrypting AND signing a token 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, 06 Nov 2012 16:11:55 -0000 +1 Can we please stop confusing signing and MAC? On Nov 6, 2012, at 10:54 AM, Jim Schaad wrote: > > > Only if you have a really loose definition of signing - it gives you an > integrity check but not origination which is usually implied by the term > signing > > Jim > > >> -----Original Message----- >> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >> Sent: Tuesday, November 06, 2012 10:50 AM >> To: Dick Hardt >> Cc: Jim Schaad; 'Mike Jones'; jose@ietf.org >> Subject: Re: [jose] encrypting AND signing a token >> >> I should also note that with symmetric keys, the alg option of A128KW with >> an enc of A128CBC+HS256 effectively gives you signing and encryption in a >> single JWE. >> >> That doesn't solve the asymmetric signing case, but may work for some >> people . >> >> John B. >> On 2012-11-06, at 10:37 AM, John Bradley wrote: >> >>> SAML performs this as separate operations. >>> >>> Now in some cases the assertion is signed then encrypted and then the >> message signed to deal with the AESCBC padding oracle attack. >>> >>> There is non technical issue around the use of qualified signatures in > cases >> where non repudiation is required. >>> Signing a encrypted object has different connotations than signing a >> unencrypted one. >>> >>> I don't know what the status of a combined operation would be. It is >> probably not relevant to your use case. >>> >>> At IETF #83 I presented including ECDH-SS as an encryption option as it >> provides sender verification. >>> I think that would answer your use case, depending on how you feel about >> EC. >>> >>> The work group rejected adding that algorithm at the time on the grounds >> that it is not used in places where it is supported. >>> ECDH-ES is defined and is considered more secure than ECDH-SS mostly >> because it is harder to get wrong. >>> >>> I am not recommending revisiting the issue, but it would be a way to >> address the composite use case. >>> >>> Despite being a Canadian I am not shilling for certicom. Just saying. >>> >>> John B. >>> On 2012-11-04, at 2:55 PM, Dick Hardt wrote: >>> >>>> Thanks Jim. An interesting historical reference. >>>> >>>> In my use case, who signed or who the token is for is not a secret. The >> payload needs to be kept a secret. >>>> >>>> Does no one sign and encrypt SAML tokens? >>>> Is this not a common use case? >>>> >>>> If it does need to be solved, it would seem to me that a standards body >> would be the place to have lots of eyes look at how to sign and encrypt a >> token so that people do not do naive sign and encrypt. >>>> >>>> Q: does anyone else need to sign and encrypt? >>>> >>>> -- Dick >>>> >>>> On Nov 4, 2012, at 10:24 AM, "Jim Schaad" >> wrote: >>>> >>>>> >>>>> >>>>> I would note that the original PKCS#7 specifications had a mode that >>>>> provided a similar sign and encrypt as a single operation mode. >>>>> When the >>>>> PKCS#7 specifications where adopted by the IETF as part of the CMS >>>>> work, this mode was discussed and very deliberately dropped because >>>>> of numerous security problems that had been found. These included >>>>> (but are not limited >>>>> to) the fact that it was signed or who signed it was sometimes a >>>>> security leak. Also there were attacks where the signed and >>>>> encrypted mode could be converted to just an encrypted mode. >>>>> >>>>> I would think that there would be a need for a very detailed >>>>> security analysis that we are not prepared to do in order to support >>>>> a signed and encrypted mode. >>>>> >>>>> Jim >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On >>>>>> Behalf Of Dick Hardt >>>>>> Sent: Friday, November 02, 2012 12:30 PM >>>>>> To: Mike Jones >>>>>> Cc: jose@ietf.org >>>>>> Subject: Re: [jose] encrypting AND signing a token >>>>>> >>>>>> Not only is my original token increasing in size by 4/3, I am also >>>>>> adding another header, payload and signature. >>>>>> >>>>>> One of the objectives of JWT was to enabled compact tokens. It >>>>>> would seem that we should be able to support both signing and >>>>>> encryption of the same token. >>>>>> >>>>>> All the encryption use cases I can think of involving asymmetric >>>>>> keys >>>>> would >>>>>> also require signing with the senders private key. >>>>>> >>>>>> My suggestion is to be explicit in what the algorithm etc. is used > for: >>>>>> >>>>>> Rather than "alg" and "enc", we have: >>>>>> >>>>>> "algs" - algorithm for token signing "algk" - algorithm for content >>>>>> management key encryption "alge" - >>>>> algorithm >>>>>> for payload encryption >>>>>> >>>>>> Similiarly, >>>>>> >>>>>> "kids" - key id for signing >>>>>> "kidk" - key id for content managment key encryption >>>>>> >>>>>> We could probably make these three or even two letter codes if you >>>>>> want to save a couple bytes. >>>>>> >>>>>> -- Dick >>>>>> >>>>>> On Nov 2, 2012, at 8:46 AM, Mike Jones >>>>>> >>>>>> wrote: >>>>>> >>>>>>> The way you put it brings one straightforward solution to mind. >>>>>>> Solve >>>>> 1-3 >>>>>> with a JWE. Solve 4-5 by signing the JWE as a JWS payload. Done. >>>>>>> >>>>>>> I do understand that the 4/3 space blowup-of double base64url >>>>>>> encoding >>>>>> the JWE motivates your earlier proposal about nested signing. (See >>>>>> Dick's >>>>>> 10/29/12 message "[jose] signing an existing JWT".) I also >>>>>> understand >>>>> that if >>>>>> you could do integrity with the asymmetric signature then the >>>>>> integrity provided by the JWE itself may be redundant. I don't >>>>>> have a specific >>>>> proposal >>>>>> on how to do that. >>>>>>> >>>>>>> -- Mike >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On >>>>>>> Behalf Of Dick Hardt >>>>>>> Sent: Friday, November 02, 2012 8:22 AM >>>>>>> To: jose@ietf.org >>>>>>> Subject: [jose] encrypting AND signing a token >>>>>>> >>>>>>> I am trying to figure out how to implement JWT/JWS/JWE to solve a >>>>>>> real >>>>>> world problem. >>>>>>> >>>>>>> 1) Bob sends a token to Charlie via Alice. (Alice gets token from >>>>>>> Bob and then Alice gives token to Charlie) >>>>>>> 2) Alice must be prevented from reading the token. (token needs to >>>>>>> be >>>>>>> encrypted) >>>>>>> 3) Bob and Charlie can share a symmetric key. >>>>>>> >>>>>>> I can solve this with JWE. >>>>>>> >>>>>>> Now let's add another condition. >>>>>>> >>>>>>> 4) Charlie wants non-repuditation that Bob created the token. >>>>>>> 5) Bob has a private key and a public key >>>>>>> >>>>>>> I don't see how to do this using JWE. It seems I have to sign the >>>>>>> same >>>>> token >>>>>> I had previously with JWS. This seems inefficient since I should be >>>>>> able >>>>> to >>>>>> replace the JWE integrity computation done with the symmetric key >>>>>> with the private key -- but the "alg" parameter is the same in both >>>>>> encrypting and signing. >>>>>>> >>>>>>> Now let's expand this to replacing the symmetric key with a >>>>> public/private >>>>>> key pair for encryption. Bob encrypts with Charlies public key and >>>>>> signs >>>>> with >>>>>> Bob's private key (we also need to make sure we are not doing naive >>>>>> encryption and signing here, would be a really useful to specify >>>>>> what >>>>> needs >>>>>> to be done there). Now we need to have parameters for both >>>>>> public/private key pairs in the header. >>>>>>> >>>>>>> Am I missing something here? >>>>>>> >>>>>>> Seems like we can do this if we change the header parameters to >>>>>>> specify >>>>> if >>>>>> they ("alg", "kid", et.c) are for token signing, payload encryption >>>>>> or >>>>> content >>>>>> key encryption. >>>>>>> >>>>>>> -- Dick >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>> >>>> _______________________________________________ >>>> 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 ve7jtb@ve7jtb.com Tue Nov 6 08:58: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 2387E21F85C0 for ; Tue, 6 Nov 2012 08:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCisDcq+neZz for ; Tue, 6 Nov 2012 08:58:56 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C82821F85BF for ; Tue, 6 Nov 2012 08:58:56 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so553757pbb.31 for ; Tue, 06 Nov 2012 08:58:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=MRhk90BTXmA1Q3k0JHK+DvznRGC0kTw8CATzn8D4FtM=; b=Fb5wWtV3md7LbPytCcHsJwyyT8IDJ1sP8bU19/fAX4PSpIj4PdaRx5srTNUTmSaVNB Qx3Pje8JvtoNEl7uchwGnX8E+7mON3k7Uzd1xRvEzZT4wO+DG325ozXZgoZDreP2Zuoz xT2zUzxUfLdRPozVgAHCV3WWCFetfu3cojeM0lkcilE0Zs+uVihxNm3f1X5hJVEHJ336 RLaEDCCG8cX6/rMobf/rG+wq65FtqnL5WA0fYj3Hk6c9FVDXfPmCMVpg7CNTrb862PHZ 4DpACjiFGbOkfwYFG5if+/bfQnJRhnl1Eg2mDMZmolIQ7pEZ524SVpOjxFDGbf+CCYOR jLgQ== Received: by 10.66.72.136 with SMTP id d8mr4400654pav.4.1352221135872; Tue, 06 Nov 2012 08:58:55 -0800 (PST) Received: from dhcp-47c5.meeting.ietf.org (dhcp-47c5.meeting.ietf.org. [130.129.71.197]) by mx.google.com with ESMTPS id v9sm12729154paz.6.2012.11.06.08.58.53 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Nov 2012 08:58:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <01dd01cdbc37$00ce5dc0$026b1940$@augustcellars.com> Date: Tue, 6 Nov 2012 11:58:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8A51F18A-9598-43EA-95DE-DB79029C305B@ve7jtb.com> References: <4ACFC778-31A9-4C79-9F4E-7C01719F51AD@gmail.com> <4E1F6AAD24975D4BA5B168042967394366887325@TK5EX14MBXC285.redmond.corp.microsoft.com> <000b01cdbab9$967ef070$c37cd150$@augustcellars.com> <210E03E3-FD49-449A-8953-571ECA9E5FBE@gmail.com> <1C292375-A9C4-440A-870A-79A85D085B9A@ve7jtb.com> <796B4958-C30C-4242-BFC7-CCB7416A9CBD@ve7jtb.com> <01dd01cdbc37$00ce5dc0$026b1940$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQm0VA6FftVWFyfkyhY94ghg5HXF9ZXmB/R/JxR1rCLHnllK5/9Jn7nLJkQ0wTUpuAPztPhU Cc: 'Mike Jones' , jose@ietf.org, 'Dick Hardt' Subject: Re: [jose] encrypting AND signing a token 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, 06 Nov 2012 16:58:57 -0000 I take your point, but there are a number of cases where people are = creating security tokens using a pre-shared key. Given that a JWE using KeyWrap & Encryption with integrity and a JWS = using HS256 provide the same level of verification of the sender. They are equivalent , though nether of them are signatures. If HS256 is good for you then perhaps A256KW + A128CBC+HS256 might be = good if you need to add encryption based on the same key. John On 2012-11-06, at 10:54 AM, "Jim Schaad" wrote: > >=20 > Only if you have a really loose definition of signing - it gives you = an > integrity check but not origination which is usually implied by the = term > signing >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >> Sent: Tuesday, November 06, 2012 10:50 AM >> To: Dick Hardt >> Cc: Jim Schaad; 'Mike Jones'; jose@ietf.org >> Subject: Re: [jose] encrypting AND signing a token >>=20 >> I should also note that with symmetric keys, the alg option of A128KW = with >> an enc of A128CBC+HS256 effectively gives you signing and encryption = in a >> single JWE. >>=20 >> That doesn't solve the asymmetric signing case, but may work for some >> people . >>=20 >> John B. >> On 2012-11-06, at 10:37 AM, John Bradley wrote: >>=20 >>> SAML performs this as separate operations. >>>=20 >>> Now in some cases the assertion is signed then encrypted and then = the >> message signed to deal with the AESCBC padding oracle attack. >>>=20 >>> There is non technical issue around the use of qualified signatures = in > cases >> where non repudiation is required. >>> Signing a encrypted object has different connotations than signing a >> unencrypted one. >>>=20 >>> I don't know what the status of a combined operation would be. It = is >> probably not relevant to your use case. >>>=20 >>> At IETF #83 I presented including ECDH-SS as an encryption option as = it >> provides sender verification. >>> I think that would answer your use case, depending on how you feel = about >> EC. >>>=20 >>> The work group rejected adding that algorithm at the time on the = grounds >> that it is not used in places where it is supported. >>> ECDH-ES is defined and is considered more secure than ECDH-SS mostly >> because it is harder to get wrong. >>>=20 >>> I am not recommending revisiting the issue, but it would be a way to >> address the composite use case. >>>=20 >>> Despite being a Canadian I am not shilling for certicom. Just = saying. >>>=20 >>> John B. >>> On 2012-11-04, at 2:55 PM, Dick Hardt wrote: >>>=20 >>>> Thanks Jim. An interesting historical reference. >>>>=20 >>>> In my use case, who signed or who the token is for is not a secret. = The >> payload needs to be kept a secret. >>>>=20 >>>> Does no one sign and encrypt SAML tokens? >>>> Is this not a common use case? >>>>=20 >>>> If it does need to be solved, it would seem to me that a standards = body >> would be the place to have lots of eyes look at how to sign and = encrypt a >> token so that people do not do naive sign and encrypt. >>>>=20 >>>> Q: does anyone else need to sign and encrypt? >>>>=20 >>>> -- Dick >>>>=20 >>>> On Nov 4, 2012, at 10:24 AM, "Jim Schaad" >> wrote: >>>>=20 >>>>> >>>>>=20 >>>>> I would note that the original PKCS#7 specifications had a mode = that >>>>> provided a similar sign and encrypt as a single operation mode. >>>>> When the >>>>> PKCS#7 specifications where adopted by the IETF as part of the CMS >>>>> work, this mode was discussed and very deliberately dropped = because >>>>> of numerous security problems that had been found. These included >>>>> (but are not limited >>>>> to) the fact that it was signed or who signed it was sometimes a >>>>> security leak. Also there were attacks where the signed and >>>>> encrypted mode could be converted to just an encrypted mode. >>>>>=20 >>>>> I would think that there would be a need for a very detailed >>>>> security analysis that we are not prepared to do in order to = support >>>>> a signed and encrypted mode. >>>>>=20 >>>>> Jim >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On >>>>>> Behalf Of Dick Hardt >>>>>> Sent: Friday, November 02, 2012 12:30 PM >>>>>> To: Mike Jones >>>>>> Cc: jose@ietf.org >>>>>> Subject: Re: [jose] encrypting AND signing a token >>>>>>=20 >>>>>> Not only is my original token increasing in size by 4/3, I am = also >>>>>> adding another header, payload and signature. >>>>>>=20 >>>>>> One of the objectives of JWT was to enabled compact tokens. It >>>>>> would seem that we should be able to support both signing and >>>>>> encryption of the same token. >>>>>>=20 >>>>>> All the encryption use cases I can think of involving asymmetric >>>>>> keys >>>>> would >>>>>> also require signing with the senders private key. >>>>>>=20 >>>>>> My suggestion is to be explicit in what the algorithm etc. is = used > for: >>>>>>=20 >>>>>> Rather than "alg" and "enc", we have: >>>>>>=20 >>>>>> "algs" - algorithm for token signing "algk" - algorithm for = content >>>>>> management key encryption "alge" - >>>>> algorithm >>>>>> for payload encryption >>>>>>=20 >>>>>> Similiarly, >>>>>>=20 >>>>>> "kids" - key id for signing >>>>>> "kidk" - key id for content managment key encryption >>>>>>=20 >>>>>> We could probably make these three or even two letter codes if = you >>>>>> want to save a couple bytes. >>>>>>=20 >>>>>> -- Dick >>>>>>=20 >>>>>> On Nov 2, 2012, at 8:46 AM, Mike Jones >>>>>> >>>>>> wrote: >>>>>>=20 >>>>>>> The way you put it brings one straightforward solution to mind. >>>>>>> Solve >>>>> 1-3 >>>>>> with a JWE. Solve 4-5 by signing the JWE as a JWS payload. = Done. >>>>>>>=20 >>>>>>> I do understand that the 4/3 space blowup-of double base64url >>>>>>> encoding >>>>>> the JWE motivates your earlier proposal about nested signing. = (See >>>>>> Dick's >>>>>> 10/29/12 message "[jose] signing an existing JWT".) I also >>>>>> understand >>>>> that if >>>>>> you could do integrity with the asymmetric signature then the >>>>>> integrity provided by the JWE itself may be redundant. I don't >>>>>> have a specific >>>>> proposal >>>>>> on how to do that. >>>>>>>=20 >>>>>>> -- Mike >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On >>>>>>> Behalf Of Dick Hardt >>>>>>> Sent: Friday, November 02, 2012 8:22 AM >>>>>>> To: jose@ietf.org >>>>>>> Subject: [jose] encrypting AND signing a token >>>>>>>=20 >>>>>>> I am trying to figure out how to implement JWT/JWS/JWE to solve = a >>>>>>> real >>>>>> world problem. >>>>>>>=20 >>>>>>> 1) Bob sends a token to Charlie via Alice. (Alice gets token = from >>>>>>> Bob and then Alice gives token to Charlie) >>>>>>> 2) Alice must be prevented from reading the token. (token needs = to >>>>>>> be >>>>>>> encrypted) >>>>>>> 3) Bob and Charlie can share a symmetric key. >>>>>>>=20 >>>>>>> I can solve this with JWE. >>>>>>>=20 >>>>>>> Now let's add another condition. >>>>>>>=20 >>>>>>> 4) Charlie wants non-repuditation that Bob created the token. >>>>>>> 5) Bob has a private key and a public key >>>>>>>=20 >>>>>>> I don't see how to do this using JWE. It seems I have to sign = the >>>>>>> same >>>>> token >>>>>> I had previously with JWS. This seems inefficient since I should = be >>>>>> able >>>>> to >>>>>> replace the JWE integrity computation done with the symmetric key >>>>>> with the private key -- but the "alg" parameter is the same in = both >>>>>> encrypting and signing. >>>>>>>=20 >>>>>>> Now let's expand this to replacing the symmetric key with a >>>>> public/private >>>>>> key pair for encryption. Bob encrypts with Charlies public key = and >>>>>> signs >>>>> with >>>>>> Bob's private key (we also need to make sure we are not doing = naive >>>>>> encryption and signing here, would be a really useful to specify >>>>>> what >>>>> needs >>>>>> to be done there). Now we need to have parameters for both >>>>>> public/private key pairs in the header. >>>>>>>=20 >>>>>>> Am I missing something here? >>>>>>>=20 >>>>>>> Seems like we can do this if we change the header parameters to >>>>>>> specify >>>>> if >>>>>> they ("alg", "kid", et.c) are for token signing, payload = encryption >>>>>> or >>>>> content >>>>>> key encryption. >>>>>>>=20 >>>>>>> -- Dick >>>>>>>=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 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >=20 From ve7jtb@ve7jtb.com Tue Nov 6 08:59: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 2EAA121F8606 for ; Tue, 6 Nov 2012 08:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFD10-pz-yqS for ; Tue, 6 Nov 2012 08:59:33 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1778121F85BF for ; Tue, 6 Nov 2012 08:59:33 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so492031pad.31 for ; Tue, 06 Nov 2012 08:59:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=YcHCUdYpbijvCCT1GWHWcTHRyGrbKJxKck9BPlHWJUI=; b=dUuafS3ZrQC8HULhuFo0YAjbJ7Z5aenbVsVAj/tKf4RWNHGZ33aC8sD4nABJWGDaF6 RA45/MPeA3UkqTY3WI+VBrnZfNh82Cl5nkMbxxDZ8Suvk1tzx5uP/8Hi1s2IcHGUQraP uazXfycLoYIKjIkKrTRgbdVvVX2ghSaFQKiCxFv4ODteHHlZuqkWCCfgrQ6cOE8C3uBW tcF5w0MlIEbLeAs0IJ4p8pAcx0/w0QcAfeE9B6ZHwMkxxjj/wrnjtxUKCUA1OJGCnovJ kkhpubxhGhQf680uoSkXg467y/Kr14HB1vZfwZq1t/+zjdL9e9tTZWb3ZBJiBHXsDw2W 2UuA== Received: by 10.68.238.199 with SMTP id vm7mr4958937pbc.105.1352221170896; Tue, 06 Nov 2012 08:59:30 -0800 (PST) Received: from dhcp-47c5.meeting.ietf.org (dhcp-47c5.meeting.ietf.org. [130.129.71.197]) by mx.google.com with ESMTPS id v9sm12729154paz.6.2012.11.06.08.59.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Nov 2012 08:59:30 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Tue, 6 Nov 2012 11:59:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9B7901C0-1312-4D58-91A5-9BFE19B4E928@ve7jtb.com> References: <4ACFC778-31A9-4C79-9F4E-7C01719F51AD@gmail.com> <4E1F6AAD24975D4BA5B168042967394366887325@TK5EX14MBXC285.redmond.corp.microsoft.com> <000b01cdbab9$967ef070$c37cd150$@augustcellars.com> <210E03E3-FD49-449A-8953-571ECA9E5FBE@gmail.com> <1C292375-A9C4-440A-870A-79A85D085B9A@ve7jtb.com> <796B4958-C30C-4242-BFC7-CCB7416A9CBD@ve7jtb.com> <01dd01cdbc37$00ce5dc0$026b1940$@augustcellars.com> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlZ3WBUcLW87RVpjkspy9ATbNRYRcfFi6a6mru2OAsS4pcRfamGUqXwrX9jGei8UKczRA9n Cc: Jim Schaad , 'Mike Jones' , jose@ietf.org, 'Dick Hardt' Subject: Re: [jose] encrypting AND signing a token 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, 06 Nov 2012 16:59:34 -0000 Probably not:) On 2012-11-06, at 11:10 AM, "Richard L. Barnes" wrote: > +1 >=20 > Can we please stop confusing signing and MAC? >=20 >=20 >=20 > On Nov 6, 2012, at 10:54 AM, Jim Schaad = wrote: >=20 >> >>=20 >> Only if you have a really loose definition of signing - it gives you = an >> integrity check but not origination which is usually implied by the = term >> signing >>=20 >> Jim >>=20 >>=20 >>> -----Original Message----- >>> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >>> Sent: Tuesday, November 06, 2012 10:50 AM >>> To: Dick Hardt >>> Cc: Jim Schaad; 'Mike Jones'; jose@ietf.org >>> Subject: Re: [jose] encrypting AND signing a token >>>=20 >>> I should also note that with symmetric keys, the alg option of = A128KW with >>> an enc of A128CBC+HS256 effectively gives you signing and encryption = in a >>> single JWE. >>>=20 >>> That doesn't solve the asymmetric signing case, but may work for = some >>> people . >>>=20 >>> John B. >>> On 2012-11-06, at 10:37 AM, John Bradley wrote: >>>=20 >>>> SAML performs this as separate operations. >>>>=20 >>>> Now in some cases the assertion is signed then encrypted and then = the >>> message signed to deal with the AESCBC padding oracle attack. >>>>=20 >>>> There is non technical issue around the use of qualified signatures = in >> cases >>> where non repudiation is required. >>>> Signing a encrypted object has different connotations than signing = a >>> unencrypted one. >>>>=20 >>>> I don't know what the status of a combined operation would be. It = is >>> probably not relevant to your use case. >>>>=20 >>>> At IETF #83 I presented including ECDH-SS as an encryption option = as it >>> provides sender verification. >>>> I think that would answer your use case, depending on how you feel = about >>> EC. >>>>=20 >>>> The work group rejected adding that algorithm at the time on the = grounds >>> that it is not used in places where it is supported. >>>> ECDH-ES is defined and is considered more secure than ECDH-SS = mostly >>> because it is harder to get wrong. >>>>=20 >>>> I am not recommending revisiting the issue, but it would be a way = to >>> address the composite use case. >>>>=20 >>>> Despite being a Canadian I am not shilling for certicom. Just = saying. >>>>=20 >>>> John B. >>>> On 2012-11-04, at 2:55 PM, Dick Hardt wrote: >>>>=20 >>>>> Thanks Jim. An interesting historical reference. >>>>>=20 >>>>> In my use case, who signed or who the token is for is not a = secret. The >>> payload needs to be kept a secret. >>>>>=20 >>>>> Does no one sign and encrypt SAML tokens? >>>>> Is this not a common use case? >>>>>=20 >>>>> If it does need to be solved, it would seem to me that a standards = body >>> would be the place to have lots of eyes look at how to sign and = encrypt a >>> token so that people do not do naive sign and encrypt. >>>>>=20 >>>>> Q: does anyone else need to sign and encrypt? >>>>>=20 >>>>> -- Dick >>>>>=20 >>>>> On Nov 4, 2012, at 10:24 AM, "Jim Schaad" >>> wrote: >>>>>=20 >>>>>> >>>>>>=20 >>>>>> I would note that the original PKCS#7 specifications had a mode = that >>>>>> provided a similar sign and encrypt as a single operation mode. >>>>>> When the >>>>>> PKCS#7 specifications where adopted by the IETF as part of the = CMS >>>>>> work, this mode was discussed and very deliberately dropped = because >>>>>> of numerous security problems that had been found. These = included >>>>>> (but are not limited >>>>>> to) the fact that it was signed or who signed it was sometimes a >>>>>> security leak. Also there were attacks where the signed and >>>>>> encrypted mode could be converted to just an encrypted mode. >>>>>>=20 >>>>>> I would think that there would be a need for a very detailed >>>>>> security analysis that we are not prepared to do in order to = support >>>>>> a signed and encrypted mode. >>>>>>=20 >>>>>> Jim >>>>>>=20 >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On >>>>>>> Behalf Of Dick Hardt >>>>>>> Sent: Friday, November 02, 2012 12:30 PM >>>>>>> To: Mike Jones >>>>>>> Cc: jose@ietf.org >>>>>>> Subject: Re: [jose] encrypting AND signing a token >>>>>>>=20 >>>>>>> Not only is my original token increasing in size by 4/3, I am = also >>>>>>> adding another header, payload and signature. >>>>>>>=20 >>>>>>> One of the objectives of JWT was to enabled compact tokens. It >>>>>>> would seem that we should be able to support both signing and >>>>>>> encryption of the same token. >>>>>>>=20 >>>>>>> All the encryption use cases I can think of involving asymmetric >>>>>>> keys >>>>>> would >>>>>>> also require signing with the senders private key. >>>>>>>=20 >>>>>>> My suggestion is to be explicit in what the algorithm etc. is = used >> for: >>>>>>>=20 >>>>>>> Rather than "alg" and "enc", we have: >>>>>>>=20 >>>>>>> "algs" - algorithm for token signing "algk" - algorithm for = content >>>>>>> management key encryption "alge" - >>>>>> algorithm >>>>>>> for payload encryption >>>>>>>=20 >>>>>>> Similiarly, >>>>>>>=20 >>>>>>> "kids" - key id for signing >>>>>>> "kidk" - key id for content managment key encryption >>>>>>>=20 >>>>>>> We could probably make these three or even two letter codes if = you >>>>>>> want to save a couple bytes. >>>>>>>=20 >>>>>>> -- Dick >>>>>>>=20 >>>>>>> On Nov 2, 2012, at 8:46 AM, Mike Jones >>>>>>> >>>>>>> wrote: >>>>>>>=20 >>>>>>>> The way you put it brings one straightforward solution to mind. >>>>>>>> Solve >>>>>> 1-3 >>>>>>> with a JWE. Solve 4-5 by signing the JWE as a JWS payload. = Done. >>>>>>>>=20 >>>>>>>> I do understand that the 4/3 space blowup-of double base64url >>>>>>>> encoding >>>>>>> the JWE motivates your earlier proposal about nested signing. = (See >>>>>>> Dick's >>>>>>> 10/29/12 message "[jose] signing an existing JWT".) I also >>>>>>> understand >>>>>> that if >>>>>>> you could do integrity with the asymmetric signature then the >>>>>>> integrity provided by the JWE itself may be redundant. I don't >>>>>>> have a specific >>>>>> proposal >>>>>>> on how to do that. >>>>>>>>=20 >>>>>>>> -- Mike >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On >>>>>>>> Behalf Of Dick Hardt >>>>>>>> Sent: Friday, November 02, 2012 8:22 AM >>>>>>>> To: jose@ietf.org >>>>>>>> Subject: [jose] encrypting AND signing a token >>>>>>>>=20 >>>>>>>> I am trying to figure out how to implement JWT/JWS/JWE to solve = a >>>>>>>> real >>>>>>> world problem. >>>>>>>>=20 >>>>>>>> 1) Bob sends a token to Charlie via Alice. (Alice gets token = from >>>>>>>> Bob and then Alice gives token to Charlie) >>>>>>>> 2) Alice must be prevented from reading the token. (token needs = to >>>>>>>> be >>>>>>>> encrypted) >>>>>>>> 3) Bob and Charlie can share a symmetric key. >>>>>>>>=20 >>>>>>>> I can solve this with JWE. >>>>>>>>=20 >>>>>>>> Now let's add another condition. >>>>>>>>=20 >>>>>>>> 4) Charlie wants non-repuditation that Bob created the token. >>>>>>>> 5) Bob has a private key and a public key >>>>>>>>=20 >>>>>>>> I don't see how to do this using JWE. It seems I have to sign = the >>>>>>>> same >>>>>> token >>>>>>> I had previously with JWS. This seems inefficient since I should = be >>>>>>> able >>>>>> to >>>>>>> replace the JWE integrity computation done with the symmetric = key >>>>>>> with the private key -- but the "alg" parameter is the same in = both >>>>>>> encrypting and signing. >>>>>>>>=20 >>>>>>>> Now let's expand this to replacing the symmetric key with a >>>>>> public/private >>>>>>> key pair for encryption. Bob encrypts with Charlies public key = and >>>>>>> signs >>>>>> with >>>>>>> Bob's private key (we also need to make sure we are not doing = naive >>>>>>> encryption and signing here, would be a really useful to specify >>>>>>> what >>>>>> needs >>>>>>> to be done there). Now we need to have parameters for both >>>>>>> public/private key pairs in the header. >>>>>>>>=20 >>>>>>>> Am I missing something here? >>>>>>>>=20 >>>>>>>> Seems like we can do this if we change the header parameters to >>>>>>>> specify >>>>>> if >>>>>>> they ("alg", "kid", et.c) are for token signing, payload = encryption >>>>>>> or >>>>>> content >>>>>>> key encryption. >>>>>>>>=20 >>>>>>>> -- Dick >>>>>>>>=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 >>>>> _______________________________________________ >>>>> 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 >=20 From dick.hardt@gmail.com Tue Nov 6 09:14: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 E6E1521F8522 for ; Tue, 6 Nov 2012 09:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3w9dtAFIYqT for ; Tue, 6 Nov 2012 09:14:23 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 95EA821F88A3 for ; Tue, 6 Nov 2012 09:14:22 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so469902eek.31 for ; Tue, 06 Nov 2012 09:14:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type; bh=HERORWSWbV1Ylzr1Q4rwU07p2W4Sx2BBRUL8tC0U1ZY=; b=QNHamZ9DhB6SEC5Esmbgru00gnP0ssvlj285zcsAeHt8wL+m/KDHIEUfGrJ0rxa6Fp 9UxLKnhG9ltTiiQ9TxDivzY40pgFeMQa2Ey1aNaGV/o3MIOA2BbPzt3/wWjNcT9AMQO/ eB7orYNC27r4szZyjczEtj5ENcoAgUH1+wm9Mhm5hvdEh++dJuoqG6tT8RGYJhQcN+Tt BVdY3ZqHQI49TlLlo5RQttLRm9TdxnndL1qFJskhNHcfvAZ+RyCQfdz2qZY91TRiYCWd wA+sKBhAJtCfbFdgHWlxCGMfj7JJzNdW8TbzFSjiZ1o+tsMTlviKwlnqjdxbEa7p2i/7 fwpw== Received: by 10.14.225.71 with SMTP id y47mr5730224eep.0.1352222061424; Tue, 06 Nov 2012 09:14:21 -0800 (PST) References: <4ACFC778-31A9-4C79-9F4E-7C01719F51AD@gmail.com> <4E1F6AAD24975D4BA5B168042967394366887325@TK5EX14MBXC285.redmond.corp.microsoft.com> <000b01cdbab9$967ef070$c37cd150$@augustcellars.com> <210E03E3-FD49-449A-8953-571ECA9E5FBE@gmail.com> <1C292375-A9C4-440A-870A-79A85D085B9A@ve7jtb.com> <796B4958-C30C-4242-BFC7-CCB7416A9CBD@ve7jtb.com> <01dd01cdbc37$00ce5dc0$026b1940$@augustcellars.com> <8A51F18A-9598-43EA-95DE-DB79029C305B@ve7jtb.com> From: Dick Hardt In-Reply-To: <8A51F18A-9598-43EA-95DE-DB79029C305B@ve7jtb.com> Mime-Version: 1.0 (1.0) Date: Tue, 6 Nov 2012 09:19:25 -0800 Message-ID: <8933406288859862861@unknownmsgid> To: John Bradley Content-Type: text/plain; charset=ISO-8859-1 Cc: Jim Schaad , Mike Jones , "jose@ietf.org" Subject: Re: [jose] encrypting AND signing a token 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, 06 Nov 2012 17:14:24 -0000 John, do you have any comments on the original post? Telling me I can do what I already described is not useful. -- Dick On 2012-11-06, at 8:58 AM, John Bradley wrote: > I take your point, but there are a number of cases where people are creating security tokens using a pre-shared key. > > Given that a JWE using KeyWrap & Encryption with integrity and a JWS using HS256 provide the same level of verification of the sender. > They are equivalent , though nether of them are signatures. > > If HS256 is good for you then perhaps A256KW + A128CBC+HS256 might be good if you need to add encryption based on the same key. > > John > On 2012-11-06, at 10:54 AM, "Jim Schaad" wrote: > >> >> >> Only if you have a really loose definition of signing - it gives you an >> integrity check but not origination which is usually implied by the term >> signing >> >> Jim >> >> >>> -----Original Message----- >>> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >>> Sent: Tuesday, November 06, 2012 10:50 AM >>> To: Dick Hardt >>> Cc: Jim Schaad; 'Mike Jones'; jose@ietf.org >>> Subject: Re: [jose] encrypting AND signing a token >>> >>> I should also note that with symmetric keys, the alg option of A128KW with >>> an enc of A128CBC+HS256 effectively gives you signing and encryption in a >>> single JWE. >>> >>> That doesn't solve the asymmetric signing case, but may work for some >>> people . >>> >>> John B. >>> On 2012-11-06, at 10:37 AM, John Bradley wrote: >>> >>>> SAML performs this as separate operations. >>>> >>>> Now in some cases the assertion is signed then encrypted and then the >>> message signed to deal with the AESCBC padding oracle attack. >>>> >>>> There is non technical issue around the use of qualified signatures in >> cases >>> where non repudiation is required. >>>> Signing a encrypted object has different connotations than signing a >>> unencrypted one. >>>> >>>> I don't know what the status of a combined operation would be. It is >>> probably not relevant to your use case. >>>> >>>> At IETF #83 I presented including ECDH-SS as an encryption option as it >>> provides sender verification. >>>> I think that would answer your use case, depending on how you feel about >>> EC. >>>> >>>> The work group rejected adding that algorithm at the time on the grounds >>> that it is not used in places where it is supported. >>>> ECDH-ES is defined and is considered more secure than ECDH-SS mostly >>> because it is harder to get wrong. >>>> >>>> I am not recommending revisiting the issue, but it would be a way to >>> address the composite use case. >>>> >>>> Despite being a Canadian I am not shilling for certicom. Just saying. >>>> >>>> John B. >>>> On 2012-11-04, at 2:55 PM, Dick Hardt wrote: >>>> >>>>> Thanks Jim. An interesting historical reference. >>>>> >>>>> In my use case, who signed or who the token is for is not a secret. The >>> payload needs to be kept a secret. >>>>> >>>>> Does no one sign and encrypt SAML tokens? >>>>> Is this not a common use case? >>>>> >>>>> If it does need to be solved, it would seem to me that a standards body >>> would be the place to have lots of eyes look at how to sign and encrypt a >>> token so that people do not do naive sign and encrypt. >>>>> >>>>> Q: does anyone else need to sign and encrypt? >>>>> >>>>> -- Dick >>>>> >>>>> On Nov 4, 2012, at 10:24 AM, "Jim Schaad" >>> wrote: >>>>> >>>>>> >>>>>> >>>>>> I would note that the original PKCS#7 specifications had a mode that >>>>>> provided a similar sign and encrypt as a single operation mode. >>>>>> When the >>>>>> PKCS#7 specifications where adopted by the IETF as part of the CMS >>>>>> work, this mode was discussed and very deliberately dropped because >>>>>> of numerous security problems that had been found. These included >>>>>> (but are not limited >>>>>> to) the fact that it was signed or who signed it was sometimes a >>>>>> security leak. Also there were attacks where the signed and >>>>>> encrypted mode could be converted to just an encrypted mode. >>>>>> >>>>>> I would think that there would be a need for a very detailed >>>>>> security analysis that we are not prepared to do in order to support >>>>>> a signed and encrypted mode. >>>>>> >>>>>> Jim >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On >>>>>>> Behalf Of Dick Hardt >>>>>>> Sent: Friday, November 02, 2012 12:30 PM >>>>>>> To: Mike Jones >>>>>>> Cc: jose@ietf.org >>>>>>> Subject: Re: [jose] encrypting AND signing a token >>>>>>> >>>>>>> Not only is my original token increasing in size by 4/3, I am also >>>>>>> adding another header, payload and signature. >>>>>>> >>>>>>> One of the objectives of JWT was to enabled compact tokens. It >>>>>>> would seem that we should be able to support both signing and >>>>>>> encryption of the same token. >>>>>>> >>>>>>> All the encryption use cases I can think of involving asymmetric >>>>>>> keys >>>>>> would >>>>>>> also require signing with the senders private key. >>>>>>> >>>>>>> My suggestion is to be explicit in what the algorithm etc. is used >> for: >>>>>>> >>>>>>> Rather than "alg" and "enc", we have: >>>>>>> >>>>>>> "algs" - algorithm for token signing "algk" - algorithm for content >>>>>>> management key encryption "alge" - >>>>>> algorithm >>>>>>> for payload encryption >>>>>>> >>>>>>> Similiarly, >>>>>>> >>>>>>> "kids" - key id for signing >>>>>>> "kidk" - key id for content managment key encryption >>>>>>> >>>>>>> We could probably make these three or even two letter codes if you >>>>>>> want to save a couple bytes. >>>>>>> >>>>>>> -- Dick >>>>>>> >>>>>>> On Nov 2, 2012, at 8:46 AM, Mike Jones >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>>> The way you put it brings one straightforward solution to mind. >>>>>>>> Solve >>>>>> 1-3 >>>>>>> with a JWE. Solve 4-5 by signing the JWE as a JWS payload. Done. >>>>>>>> >>>>>>>> I do understand that the 4/3 space blowup-of double base64url >>>>>>>> encoding >>>>>>> the JWE motivates your earlier proposal about nested signing. (See >>>>>>> Dick's >>>>>>> 10/29/12 message "[jose] signing an existing JWT".) I also >>>>>>> understand >>>>>> that if >>>>>>> you could do integrity with the asymmetric signature then the >>>>>>> integrity provided by the JWE itself may be redundant. I don't >>>>>>> have a specific >>>>>> proposal >>>>>>> on how to do that. >>>>>>>> >>>>>>>> -- Mike >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On >>>>>>>> Behalf Of Dick Hardt >>>>>>>> Sent: Friday, November 02, 2012 8:22 AM >>>>>>>> To: jose@ietf.org >>>>>>>> Subject: [jose] encrypting AND signing a token >>>>>>>> >>>>>>>> I am trying to figure out how to implement JWT/JWS/JWE to solve a >>>>>>>> real >>>>>>> world problem. >>>>>>>> >>>>>>>> 1) Bob sends a token to Charlie via Alice. (Alice gets token from >>>>>>>> Bob and then Alice gives token to Charlie) >>>>>>>> 2) Alice must be prevented from reading the token. (token needs to >>>>>>>> be >>>>>>>> encrypted) >>>>>>>> 3) Bob and Charlie can share a symmetric key. >>>>>>>> >>>>>>>> I can solve this with JWE. >>>>>>>> >>>>>>>> Now let's add another condition. >>>>>>>> >>>>>>>> 4) Charlie wants non-repuditation that Bob created the token. >>>>>>>> 5) Bob has a private key and a public key >>>>>>>> >>>>>>>> I don't see how to do this using JWE. It seems I have to sign the >>>>>>>> same >>>>>> token >>>>>>> I had previously with JWS. This seems inefficient since I should be >>>>>>> able >>>>>> to >>>>>>> replace the JWE integrity computation done with the symmetric key >>>>>>> with the private key -- but the "alg" parameter is the same in both >>>>>>> encrypting and signing. >>>>>>>> >>>>>>>> Now let's expand this to replacing the symmetric key with a >>>>>> public/private >>>>>>> key pair for encryption. Bob encrypts with Charlies public key and >>>>>>> signs >>>>>> with >>>>>>> Bob's private key (we also need to make sure we are not doing naive >>>>>>> encryption and signing here, would be a really useful to specify >>>>>>> what >>>>>> needs >>>>>>> to be done there). Now we need to have parameters for both >>>>>>> public/private key pairs in the header. >>>>>>>> >>>>>>>> Am I missing something here? >>>>>>>> >>>>>>>> Seems like we can do this if we change the header parameters to >>>>>>>> specify >>>>>> if >>>>>>> they ("alg", "kid", et.c) are for token signing, payload encryption >>>>>>> or >>>>>> content >>>>>>> key encryption. >>>>>>>> >>>>>>>> -- Dick >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>> >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>> >> > From dick.hardt@gmail.com Tue Nov 6 09:15: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 AD3DF21F8BD2 for ; Tue, 6 Nov 2012 09:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsCk4A4jjd8I for ; Tue, 6 Nov 2012 09:15:31 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 326A721F8B17 for ; Tue, 6 Nov 2012 09:15:31 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id k13so315567eaa.31 for ; Tue, 06 Nov 2012 09:15:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type; bh=1qLfjUxxctIdAt/2hodMYOqFFpqaIZTRnuY8T0eDqIY=; b=pREt+VjqBlgaJJAzMmaUilN+Odk0YZPc954dConXrLdI5WzQu3FeBtTnW241WqT63n ARIwAdYQ7IY0p7Gt6Y8xvUqjBVW1TIvyRhiPjcV/E5q0aSkGfrjcom8FkjIZEKwVVFY/ OTuUlbg1L+dQnZ59b9f3ThJ8MNkfF6FVgPdEPkk5me2gJczpP+d9VaAPXGSJHfTs06aP Me49TOMKPzrscWe9W65I6DJHuVl/kHNi2j0ezJUirTO8ladeTmP4a8V0v5BsQUXh2QIT 6KXfZasOtbbilQtkeb/tnUWdYdg3P9Mtux5lP15MjuViY7+3BDgTNKz9UTVDn32GyaNN ZfqQ== Received: by 10.14.194.72 with SMTP id l48mr5661286een.9.1352222130357; Tue, 06 Nov 2012 09:15:30 -0800 (PST) References: <4ACFC778-31A9-4C79-9F4E-7C01719F51AD@gmail.com> <4E1F6AAD24975D4BA5B168042967394366887325@TK5EX14MBXC285.redmond.corp.microsoft.com> <000b01cdbab9$967ef070$c37cd150$@augustcellars.com> <210E03E3-FD49-449A-8953-571ECA9E5FBE@gmail.com> <1C292375-A9C4-440A-870A-79A85D085B9A@ve7jtb.com> <796B4958-C30C-4242-BFC7-CCB7416A9CBD@ve7jtb.com> <01dd01cdbc37$00ce5dc0$026b1940$@augustcellars.com> <9B7901C0-1312-4D58-91A5-9BFE19B4E928@ve7jtb.com> From: Dick Hardt In-Reply-To: <9B7901C0-1312-4D58-91A5-9BFE19B4E928@ve7jtb.com> Mime-Version: 1.0 (1.0) Date: Tue, 6 Nov 2012 09:20:34 -0800 Message-ID: <-1067801465777863407@unknownmsgid> To: John Bradley Content-Type: text/plain; charset=ISO-8859-1 Cc: "Richard L. Barnes" , Jim Schaad , Mike Jones , "jose@ietf.org" Subject: Re: [jose] encrypting AND signing a token 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, 06 Nov 2012 17:15:32 -0000 "we" can. John can't. :-) -- Dick On 2012-11-06, at 8:59 AM, John Bradley wrote: > Probably not:) > > On 2012-11-06, at 11:10 AM, "Richard L. Barnes" wrote: > >> +1 >> >> Can we please stop confusing signing and MAC? >> >> >> >> On Nov 6, 2012, at 10:54 AM, Jim Schaad wrote: >> >>> >>> >>> Only if you have a really loose definition of signing - it gives you an >>> integrity check but not origination which is usually implied by the term >>> signing >>> >>> Jim >>> >>> >>>> -----Original Message----- >>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >>>> Sent: Tuesday, November 06, 2012 10:50 AM >>>> To: Dick Hardt >>>> Cc: Jim Schaad; 'Mike Jones'; jose@ietf.org >>>> Subject: Re: [jose] encrypting AND signing a token >>>> >>>> I should also note that with symmetric keys, the alg option of A128KW with >>>> an enc of A128CBC+HS256 effectively gives you signing and encryption in a >>>> single JWE. >>>> >>>> That doesn't solve the asymmetric signing case, but may work for some >>>> people . >>>> >>>> John B. >>>> On 2012-11-06, at 10:37 AM, John Bradley wrote: >>>> >>>>> SAML performs this as separate operations. >>>>> >>>>> Now in some cases the assertion is signed then encrypted and then the >>>> message signed to deal with the AESCBC padding oracle attack. >>>>> >>>>> There is non technical issue around the use of qualified signatures in >>> cases >>>> where non repudiation is required. >>>>> Signing a encrypted object has different connotations than signing a >>>> unencrypted one. >>>>> >>>>> I don't know what the status of a combined operation would be. It is >>>> probably not relevant to your use case. >>>>> >>>>> At IETF #83 I presented including ECDH-SS as an encryption option as it >>>> provides sender verification. >>>>> I think that would answer your use case, depending on how you feel about >>>> EC. >>>>> >>>>> The work group rejected adding that algorithm at the time on the grounds >>>> that it is not used in places where it is supported. >>>>> ECDH-ES is defined and is considered more secure than ECDH-SS mostly >>>> because it is harder to get wrong. >>>>> >>>>> I am not recommending revisiting the issue, but it would be a way to >>>> address the composite use case. >>>>> >>>>> Despite being a Canadian I am not shilling for certicom. Just saying. >>>>> >>>>> John B. >>>>> On 2012-11-04, at 2:55 PM, Dick Hardt wrote: >>>>> >>>>>> Thanks Jim. An interesting historical reference. >>>>>> >>>>>> In my use case, who signed or who the token is for is not a secret. The >>>> payload needs to be kept a secret. >>>>>> >>>>>> Does no one sign and encrypt SAML tokens? >>>>>> Is this not a common use case? >>>>>> >>>>>> If it does need to be solved, it would seem to me that a standards body >>>> would be the place to have lots of eyes look at how to sign and encrypt a >>>> token so that people do not do naive sign and encrypt. >>>>>> >>>>>> Q: does anyone else need to sign and encrypt? >>>>>> >>>>>> -- Dick >>>>>> >>>>>> On Nov 4, 2012, at 10:24 AM, "Jim Schaad" >>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> I would note that the original PKCS#7 specifications had a mode that >>>>>>> provided a similar sign and encrypt as a single operation mode. >>>>>>> When the >>>>>>> PKCS#7 specifications where adopted by the IETF as part of the CMS >>>>>>> work, this mode was discussed and very deliberately dropped because >>>>>>> of numerous security problems that had been found. These included >>>>>>> (but are not limited >>>>>>> to) the fact that it was signed or who signed it was sometimes a >>>>>>> security leak. Also there were attacks where the signed and >>>>>>> encrypted mode could be converted to just an encrypted mode. >>>>>>> >>>>>>> I would think that there would be a need for a very detailed >>>>>>> security analysis that we are not prepared to do in order to support >>>>>>> a signed and encrypted mode. >>>>>>> >>>>>>> Jim >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On >>>>>>>> Behalf Of Dick Hardt >>>>>>>> Sent: Friday, November 02, 2012 12:30 PM >>>>>>>> To: Mike Jones >>>>>>>> Cc: jose@ietf.org >>>>>>>> Subject: Re: [jose] encrypting AND signing a token >>>>>>>> >>>>>>>> Not only is my original token increasing in size by 4/3, I am also >>>>>>>> adding another header, payload and signature. >>>>>>>> >>>>>>>> One of the objectives of JWT was to enabled compact tokens. It >>>>>>>> would seem that we should be able to support both signing and >>>>>>>> encryption of the same token. >>>>>>>> >>>>>>>> All the encryption use cases I can think of involving asymmetric >>>>>>>> keys >>>>>>> would >>>>>>>> also require signing with the senders private key. >>>>>>>> >>>>>>>> My suggestion is to be explicit in what the algorithm etc. is used >>> for: >>>>>>>> >>>>>>>> Rather than "alg" and "enc", we have: >>>>>>>> >>>>>>>> "algs" - algorithm for token signing "algk" - algorithm for content >>>>>>>> management key encryption "alge" - >>>>>>> algorithm >>>>>>>> for payload encryption >>>>>>>> >>>>>>>> Similiarly, >>>>>>>> >>>>>>>> "kids" - key id for signing >>>>>>>> "kidk" - key id for content managment key encryption >>>>>>>> >>>>>>>> We could probably make these three or even two letter codes if you >>>>>>>> want to save a couple bytes. >>>>>>>> >>>>>>>> -- Dick >>>>>>>> >>>>>>>> On Nov 2, 2012, at 8:46 AM, Mike Jones >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> The way you put it brings one straightforward solution to mind. >>>>>>>>> Solve >>>>>>> 1-3 >>>>>>>> with a JWE. Solve 4-5 by signing the JWE as a JWS payload. Done. >>>>>>>>> >>>>>>>>> I do understand that the 4/3 space blowup-of double base64url >>>>>>>>> encoding >>>>>>>> the JWE motivates your earlier proposal about nested signing. (See >>>>>>>> Dick's >>>>>>>> 10/29/12 message "[jose] signing an existing JWT".) I also >>>>>>>> understand >>>>>>> that if >>>>>>>> you could do integrity with the asymmetric signature then the >>>>>>>> integrity provided by the JWE itself may be redundant. I don't >>>>>>>> have a specific >>>>>>> proposal >>>>>>>> on how to do that. >>>>>>>>> >>>>>>>>> -- Mike >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On >>>>>>>>> Behalf Of Dick Hardt >>>>>>>>> Sent: Friday, November 02, 2012 8:22 AM >>>>>>>>> To: jose@ietf.org >>>>>>>>> Subject: [jose] encrypting AND signing a token >>>>>>>>> >>>>>>>>> I am trying to figure out how to implement JWT/JWS/JWE to solve a >>>>>>>>> real >>>>>>>> world problem. >>>>>>>>> >>>>>>>>> 1) Bob sends a token to Charlie via Alice. (Alice gets token from >>>>>>>>> Bob and then Alice gives token to Charlie) >>>>>>>>> 2) Alice must be prevented from reading the token. (token needs to >>>>>>>>> be >>>>>>>>> encrypted) >>>>>>>>> 3) Bob and Charlie can share a symmetric key. >>>>>>>>> >>>>>>>>> I can solve this with JWE. >>>>>>>>> >>>>>>>>> Now let's add another condition. >>>>>>>>> >>>>>>>>> 4) Charlie wants non-repuditation that Bob created the token. >>>>>>>>> 5) Bob has a private key and a public key >>>>>>>>> >>>>>>>>> I don't see how to do this using JWE. It seems I have to sign the >>>>>>>>> same >>>>>>> token >>>>>>>> I had previously with JWS. This seems inefficient since I should be >>>>>>>> able >>>>>>> to >>>>>>>> replace the JWE integrity computation done with the symmetric key >>>>>>>> with the private key -- but the "alg" parameter is the same in both >>>>>>>> encrypting and signing. >>>>>>>>> >>>>>>>>> Now let's expand this to replacing the symmetric key with a >>>>>>> public/private >>>>>>>> key pair for encryption. Bob encrypts with Charlies public key and >>>>>>>> signs >>>>>>> with >>>>>>>> Bob's private key (we also need to make sure we are not doing naive >>>>>>>> encryption and signing here, would be a really useful to specify >>>>>>>> what >>>>>>> needs >>>>>>>> to be done there). Now we need to have parameters for both >>>>>>>> public/private key pairs in the header. >>>>>>>>> >>>>>>>>> Am I missing something here? >>>>>>>>> >>>>>>>>> Seems like we can do this if we change the header parameters to >>>>>>>>> specify >>>>>>> if >>>>>>>> they ("alg", "kid", et.c) are for token signing, payload encryption >>>>>>>> or >>>>>>> content >>>>>>>> key encryption. >>>>>>>>> >>>>>>>>> -- Dick >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 internet-drafts@ietf.org Wed Nov 7 01:32: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 BC2A121F881C; Wed, 7 Nov 2012 01:32:34 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHBeMyNO3MP2; Wed, 7 Nov 2012 01:32:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5872021F8831; Wed, 7 Nov 2012 01:32:34 -0800 (PST) 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.35 Message-ID: <20121107093234.16962.83129.idtracker@ietfa.amsl.com> Date: Wed, 07 Nov 2012 01:32:34 -0800 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-signature-07.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: Wed, 07 Nov 2012 09:32:34 -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-07.txt Pages : 40 Date : 2012-11-07 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-signature-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Nov 7 01:34: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 2111821F875C; Wed, 7 Nov 2012 01:34:42 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 696w8m7USGal; Wed, 7 Nov 2012 01:34:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533E521F8B35; Wed, 7 Nov 2012 01:34:41 -0800 (PST) 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.35 Message-ID: <20121107093441.26081.45621.idtracker@ietfa.amsl.com> Date: Wed, 07 Nov 2012 01:34:41 -0800 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-07.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: Wed, 07 Nov 2012 09:34:42 -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-07.txt Pages : 50 Date : 2012-11-07 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-encryption-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Nov 7 01:37: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 E0E7A21F8B4D; Wed, 7 Nov 2012 01:37:05 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-rTtAp8lYat; Wed, 7 Nov 2012 01:37:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4432921F8B4F; Wed, 7 Nov 2012 01:37:05 -0800 (PST) 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.35 Message-ID: <20121107093705.15170.80600.idtracker@ietfa.amsl.com> Date: Wed, 07 Nov 2012 01:37:05 -0800 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-key-07.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: Wed, 07 Nov 2012 09:37: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 Key (JWK) Author(s) : Michael B. Jones Filename : draft-ietf-jose-json-web-key-07.txt Pages : 12 Date : 2012-11-07 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-key-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Nov 7 01:39: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 6517C21F8B6C; Wed, 7 Nov 2012 01:39:20 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNMiezwIB0Um; Wed, 7 Nov 2012 01:39:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2C121F8B65; Wed, 7 Nov 2012 01:39:19 -0800 (PST) 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.35 Message-ID: <20121107093919.1898.99918.idtracker@ietfa.amsl.com> Date: Wed, 07 Nov 2012 01:39:19 -0800 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-07.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: Wed, 07 Nov 2012 09:39:20 -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-07.txt Pages : 41 Date : 2012-11-07 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jose-json-web-algorithms-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From michael_b_jones@hotmail.com Wed Nov 7 02:06: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 B227C21F8BD5 for ; Wed, 7 Nov 2012 02:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSjgsihqhvQw for ; Wed, 7 Nov 2012 02:06:27 -0800 (PST) Received: from bay0-omc1-s26.bay0.hotmail.com (bay0-omc1-s26.bay0.hotmail.com [65.54.190.37]) by ietfa.amsl.com (Postfix) with ESMTP id D222C21F8B4C for ; Wed, 7 Nov 2012 02:06:20 -0800 (PST) Received: from BAY171-W88 ([65.54.190.59]) by bay0-omc1-s26.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Nov 2012 02:06:20 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_d5efff7f-026a-4d55-b00e-9140964e86fa_" X-Originating-IP: [130.129.71.146] From: Michael Jones To: Date: Wed, 7 Nov 2012 02:06:19 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 07 Nov 2012 10:06:20.0005 (UTC) FILETIME=[889FF950:01CDBCCF] Subject: [jose] JOSE and JWT specs updated for IETF 85 working group meetings 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, 07 Nov 2012 10:06:30 -0000 --_d5efff7f-026a-4d55-b00e-9140964e86fa_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I=92ve made a small set of updates to the JSON Object Signing and Encryption (JOSE) and JSON Web Token (JWT) specs in preparation for the= JOSE and OAuth working group meetings at IETF 85. These updates incorporate resolutions to issues that have been discussed by the working groups since publication of the previous drafts. =20 Normative changes to the working group specs were to add length fields for PartyUInfo and PartyVInfo values for key derivation calculations and to change the JWK field identifiers for RSA keys from (mod= =2C xpo) to (n=2C e). Fields for representing the RSA private key values neede= d for Chinese Remainder Theorem (CRT) calculations were added to the JSON Pri= vate Key specification. =20 The updated specs are available at: =B7 =20 http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-07 =B7 =20 http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-07 =B7 =20 http://tools.ietf.org/html/draft-ietf-jose-json-web-key-07 =B7 =20 http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-07 =B7 =20 http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-05 =B7 =20 http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-03 =B7 =20 http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization-03 =B7 =20 http://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization-03 =B7 =20 http://tools.ietf.org/html/draft-jones-jose-json-private-key-01 =20 HTML formatted versions are available at: =B7 =20 http://self-issued.info/docs/draft-ietf-jose-json-web-signature-07.html =B7 =20 http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-07.html =B7 =20 http://self-issued.info/docs/draft-ietf-jose-json-web-key-07.html =B7 =20 http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-07.html =B7 =20 http://self-issued.info/docs/draft-ietf-oauth-json-web-token-05.html =B7 =20 http://self-issued.info/docs/draft-ietf-oauth-jwt-bearer-03.html =B7 =20 http://self-issued.info/docs/draft-jones-jose-jws-json-serialization-03.htm= l =B7 =20 http://self-issued.info/docs/draft-jones-jose-jwe-json-serialization-03.htm= l =B7 =20 http://self-issued.info/docs/draft-jones-jose-json-private-key-01.html =20 See the history entries in the specs for detailed change descriptions. =20 =20 =20 -- Mike =20 = --_d5efff7f-026a-4d55-b00e-9140964e86fa_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I=92ve made a small set of updates to the JSON Obje= ct Signing and Encryption (JOSE) and JSON Web Token (JWT) specs in preparation for the= JOSE and OAuth= working group meetings at IETF 85. =3B These updates incorporate resolutions to issues that have been discussed by the working groups since publication of the previous drafts.

 =3B

Normative changes to the working group specs = were to add length fields for PartyUInfo and PartyVInfo values for key derivation calculations and to change the JWK field identifiers for RSA keys from (mod= =2C xpo) to (n=2C e). =3B Fields for representing the RSA private key value= s needed for Chinese Remainder Theorem (CRT) calculations were added to the JSON Pri= vate Key specification.

 =3B

The updated specs are available at:

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B = http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-07=

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-07

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http:/= /tools.ietf.org/html/draft-ietf-jose-json-web-key-07<= /p>

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-07

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B htt= p://tools.ietf.org/html/draft-ietf-oauth-json-web-token-05<= /o:p>

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http://= tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-03

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization-03<= /font>

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization-03<= /font>

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B h= ttp://tools.ietf.org/html/draft-jones-jose-json-private-key-01

 =3B

HTML formatted versions are available at:

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http://self-issued.info/docs/draft-ietf-jose-json-web-signature-07.h= tml

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-07= .html

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http://self-issued.info/docs/draft-ietf-jose-json-web-key-07.html

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-07= .html

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http://self-issued.info/docs/draft-ietf-oauth-json-web-token-05.html

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B = http://self-issued.info/docs/draft-ietf-oauth-jwt-bearer-03.html=

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http://self-issued.info/docs/draft-jones-jose-jws-json-seriali= zation-03.html

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http://self-issued.info/docs/draft-jones-jose-jwe-json-seriali= zation-03.html

=B7 =3B =3B =3B =3B =3B =3B&= nbsp=3B http://self-issued.info/docs/draft-jones-jose-json-private-key-01.htm= l

 =3B

See the history entries in the specs for deta= iled change descriptions.

 =3B

 =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B -- Mike

 =3B

= --_d5efff7f-026a-4d55-b00e-9140964e86fa_-- From djc.ochtman@gmail.com Wed Nov 7 04:14: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 4E23D21F88A4 for ; Wed, 7 Nov 2012 04:14:26 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLS1Nqm3lCkG for ; Wed, 7 Nov 2012 04:14:25 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 54B9521F8898 for ; Wed, 7 Nov 2012 04:14:25 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id t11so1023925qaa.10 for ; Wed, 07 Nov 2012 04:14:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=x/xp/nxuoSkXbc56CK5wDM9cjXmUB+K/ZXYgqrMTz2E=; b=rTYUexKLmpgWrvFV4o5dkaHo85WPslEybMAvsIsx27B3Q5jf6yB13Ajong9O+wvnfB wkJw/OKhpnUd6eKv4LOcsJyPT+WBXmJXWH+PI5iVyKeX7UcLNuwiczxYkKMqvE92QvY/ LX24kQbkeVG7FlYABYbLrpRJhNKODTkEfGDmAXdgCiJruXLLhp3djnD1mbnFXtYyGAxT D0hVj7ONMhypUzGbZM0IVvwJlaR1TtOl6w6VYYf4Fw6/xBHvBuKgjy9q6hY5htypWo5l HvXorOh6nnkGISGty3c+Zxl/MxTjgsnL3cszQGk1t5D8RSriKwxXlXKQClYWF8YL/12M Q2Ew== Received: by 10.49.28.231 with SMTP id e7mr7514272qeh.49.1352290464654; Wed, 07 Nov 2012 04:14:24 -0800 (PST) MIME-Version: 1.0 Sender: djc.ochtman@gmail.com Received: by 10.49.97.195 with HTTP; Wed, 7 Nov 2012 04:14:04 -0800 (PST) In-Reply-To: References: From: Dirkjan Ochtman Date: Wed, 7 Nov 2012 13:14:04 +0100 X-Google-Sender-Auth: YgULEjeduPeDBIv2wd1BKu7319Q Message-ID: To: Michael Jones Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: jose@ietf.org Subject: Re: [jose] JOSE and JWT specs updated for IETF 85 working group meetings 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, 07 Nov 2012 12:14:26 -0000 On Wed, Nov 7, 2012 at 11:06 AM, Michael Jones wrote: > I=E2=80=99ve made a small set of updates to the JSON Object Signing and E= ncryption > (JOSE) and JSON Web Token (JWT) specs in preparation for the JOSE and OAu= th > working group meetings at IETF 85. These updates incorporate resolutions= to > issues that have been discussed by the working groups since publication o= f > the previous drafts. How can I get someone to respond to my suggestions? Emailing to the list twice (Oct 20 and Oct 30) hasn't helped so far. Is there a bug tracker? Cheers, Dirkjan From James.H.Manger@team.telstra.com Wed Nov 7 06:00: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 D374721F8B62 for ; Wed, 7 Nov 2012 06:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.485 X-Spam-Level: X-Spam-Status: No, score=-0.485 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDLzvKxM5T31 for ; Wed, 7 Nov 2012 06:00:23 -0800 (PST) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 19C1021F8B64 for ; Wed, 7 Nov 2012 06:00:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,730,1344175200"; d="scan'208";a="100450200" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipocni.tcif.telstra.com.au with ESMTP; 08 Nov 2012 01:00:21 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6888"; a="92015542" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcdni.tcif.telstra.com.au with ESMTP; 08 Nov 2012 01:00:21 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Thu, 8 Nov 2012 01:00:20 +1100 From: "Manger, James H" To: "dirkjan@ochtman.nl" , "michael_b_jones@hotmail.com" Date: Thu, 8 Nov 2012 01:00:19 +1100 Thread-Topic: [jose] JOSE and JWT specs updated for IETF 85 working group meetings Thread-Index: Ac284XJAgiiEhjpUQaSHn/30wFYCDgADsa4K Message-ID: 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] JOSE and JWT specs updated for IETF 85 working group meetings 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, 07 Nov 2012 14:00:23 -0000 RGlya2phbiwNClNlZSBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvam9zZS9j dXJyZW50L21zZzAwNjIwLmh0bWwNCmFuZCB0aGUgcmVzdCBvZiB0aGF0IHRocmVhZCBmb3IgY29t cHJlc3Npb24gaW4gSldTLg0KDQpBbmQgd2Ugc2hvdWxkIHVzZSB0aGUgaXNzdWVzIHRyYWNrZXIg YXQgaHR0cDovL3Rvb2xzLmlldGYub3JnL2VnL2pvc2UvdHJhYy9yZXBvcnQvMS4NCi0tDQpKYW1l cyBNYW5nZXINCg0KLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLQ0KRnJvbTogIkRpcmtqYW4gT2No dG1hbiIgPGRpcmtqYW5Ab2NodG1hbi5ubD4NCkRhdGU6IFdlZCwgTm92IDcsIDIwMTIgMTE6MTQg cG0NClN1YmplY3Q6IFtqb3NlXSBKT1NFIGFuZCBKV1Qgc3BlY3MgdXBkYXRlZCBmb3IgSUVURiA4 NSB3b3JraW5nIGdyb3VwIG1lZXRpbmdzDQpUbzogIk1pY2hhZWwgSm9uZXMiIDxtaWNoYWVsX2Jf am9uZXNAaG90bWFpbC5jb20+DQpDYzogImpvc2VAaWV0Zi5vcmciIDxqb3NlQGlldGYub3JnPg0K DQpPbiBXZWQsIE5vdiA3LCAyMDEyIGF0IDExOjA2IEFNLCBNaWNoYWVsIEpvbmVzDQo8bWljaGFl bF9iX2pvbmVzQGhvdG1haWwuY29tPiB3cm90ZToNCj4gSeKAmXZlIG1hZGUgYSBzbWFsbCBzZXQg b2YgdXBkYXRlcyB0byB0aGUgSlNPTiBPYmplY3QgU2lnbmluZyBhbmQgRW5jcnlwdGlvbg0KPiAo Sk9TRSkgYW5kIEpTT04gV2ViIFRva2VuIChKV1QpIHNwZWNzIGluIHByZXBhcmF0aW9uIGZvciB0 aGUgSk9TRSBhbmQgT0F1dGgNCj4gd29ya2luZyBncm91cCBtZWV0aW5ncyBhdCBJRVRGIDg1LiAg VGhlc2UgdXBkYXRlcyBpbmNvcnBvcmF0ZSByZXNvbHV0aW9ucyB0bw0KPiBpc3N1ZXMgdGhhdCBo YXZlIGJlZW4gZGlzY3Vzc2VkIGJ5IHRoZSB3b3JraW5nIGdyb3VwcyBzaW5jZSBwdWJsaWNhdGlv biBvZg0KPiB0aGUgcHJldmlvdXMgZHJhZnRzLg0KDQpIb3cgY2FuIEkgZ2V0IHNvbWVvbmUgdG8g cmVzcG9uZCB0byBteSBzdWdnZXN0aW9ucz8gRW1haWxpbmcgdG8gdGhlDQpsaXN0IHR3aWNlIChP Y3QgMjAgYW5kIE9jdCAzMCkgaGFzbid0IGhlbHBlZCBzbyBmYXIuIElzIHRoZXJlIGEgYnVnDQp0 cmFja2VyPw0KDQpDaGVlcnMsDQoNCkRpcmtqYW4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpqb3NlIG1haWxpbmcgbGlzdA0Kam9zZUBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlDQo= From djc.ochtman@gmail.com Wed Nov 7 06:08: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 DEB1321F8799 for ; Wed, 7 Nov 2012 06:08:14 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnLKdfgbsjdN for ; Wed, 7 Nov 2012 06:08:14 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6D921F8742 for ; Wed, 7 Nov 2012 06:08:13 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id t11so1094058qaa.10 for ; Wed, 07 Nov 2012 06:08:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=JPFzvCkM6CKlkXs52+iLOj5SYJ2epgJO0HEC9ura5VU=; b=IxFwfNsvuAmDkmFGP4+oPbkVO8pnm9W+jywQ7UKD9H0fsQoJl7Jtgo6qD1KQRpuL3b OwYJ7OJ9N6NDyJsLX5drVGHkZyiwgWJZZlJoXJ9YJijb13cwTZdIKfrFeUEHEPq6x7pm Qemi4ZcZMf8G5fvBUlnTgk69RYYPc4czZmEOyPrFtF9qzhsw0ZukQwIJm14TBTydnWDh 5dCABLGLKjgjtB32IVcziPSgCuERpCwBc9CuTvqd9ff7rnq4pXyVz4lHeLSf03uyQTQM SFysSJjegd0CP7294/LnvBF4FpzGiyUsDb0ZjVgwde6i+ot15hkdE/+nBOmRhnMSupsg jEQQ== Received: by 10.224.59.197 with SMTP id m5mr7048371qah.4.1352297293521; Wed, 07 Nov 2012 06:08:13 -0800 (PST) MIME-Version: 1.0 Sender: djc.ochtman@gmail.com Received: by 10.49.97.195 with HTTP; Wed, 7 Nov 2012 06:07:53 -0800 (PST) In-Reply-To: References: From: Dirkjan Ochtman Date: Wed, 7 Nov 2012 15:07:53 +0100 X-Google-Sender-Auth: 05UVVr0iONkVrylpaMZu_ZvSBeg Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=UTF-8 Cc: "michael_b_jones@hotmail.com" , "jose@ietf.org" Subject: Re: [jose] JOSE and JWT specs updated for IETF 85 working group meetings 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, 07 Nov 2012 14:08:15 -0000 On Wed, Nov 7, 2012 at 3:00 PM, Manger, James H wrote: > Dirkjan, > See http://www.ietf.org/mail-archive/web/jose/current/msg00620.html > and the rest of that thread for compression in JWS. > > And we should use the issues tracker at http://tools.ietf.org/eg/jose/trac/report/1. Thanks for the response, the mailing list thread on compression makes some sense. Would it make sense to report a bug on clarifying the signing operation (i.e. PKCS1 vs. "pure" RSA signing), or is that something that should be discussed here first? Cheers, Dirkjan From dick.hardt@gmail.com Wed Nov 7 12:26: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 382D721F8BF9 for ; Wed, 7 Nov 2012 12:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYxKEK-2RG3O for ; Wed, 7 Nov 2012 12:26:12 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD5221F8C03 for ; Wed, 7 Nov 2012 12:26:11 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so1488769pad.31 for ; Wed, 07 Nov 2012 12:26:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=Vanh3BeZU/Dcxu4TsflWcaXSQ1RIpVhKGk4AE+8E9vU=; b=PTTLYSbfVm8LTPJVStCpat7sYLt5OT+lS5LK/wJO+ixVMV5LzmBmSQi5cboN6dE2UR w4QjnUHExGLZ2WsJTVndy9k/aF5FQ/zYtuceG3hcC5WDtEWzILB021PF2Wr5DIK+E7AK UPRDfj97QEZfDxOUv+ID/i7bdIoiIsNhYGwCo0TAqAgXa+o7UiSzcnpgKzYFu1+cSld7 TzbLc76H7lTgSYC5ph1UxHYhGl4Ns4FNwKgBPkG15sCjkAu96JwUweTIOMlH6ZWelPdp BCEBjKzYgaymKcUnRvX/bHFG+raJ5FK4KPW3V2+aC+eu+xY8aY8mK+/EkLTWVmvOBxTh DYJg== Received: by 10.68.225.34 with SMTP id rh2mr2314946pbc.78.1352319970894; Wed, 07 Nov 2012 12:26:10 -0800 (PST) Received: from [192.168.64.235] ([207.239.114.206]) by mx.google.com with ESMTPS id ok3sm14624389pbb.11.2012.11.07.12.25.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 12:26:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <20121107093441.26081.45621.idtracker@ietfa.amsl.com> Date: Wed, 7 Nov 2012 12:23:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <19F1B8FA-6655-4933-A58C-70B12BE025C3@gmail.com> References: <20121107093441.26081.45621.idtracker@ietfa.amsl.com> To: "jose@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: [jose] proposal: put encryption header parameters into a separate object 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, 07 Nov 2012 20:26:14 -0000 To enable encrypting and then signing of the same token, we need to = specify the encrypting and signing algorithms separately. Since we are using JSON, how about if we create an encryption object to = contain all the parameters defined in JWE so that there is no overlap in = the JWS namespace. "enc":=20 { "alg" , "enc" , "zip" } From James.H.Manger@team.telstra.com Wed Nov 7 14:40: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 12D4421F84DF for ; Wed, 7 Nov 2012 14:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.554 X-Spam-Level: X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaplPmpXdVi6 for ; Wed, 7 Nov 2012 14:40:46 -0800 (PST) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 4650221F84CF for ; Wed, 7 Nov 2012 14:40:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,734,1344175200"; d="scan'208";a="100248725" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 08 Nov 2012 09:40:45 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6889"; a="46301254" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcani.tcif.telstra.com.au with ESMTP; 08 Nov 2012 09:40:44 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Thu, 8 Nov 2012 09:40:44 +1100 From: "Manger, James H" To: Dirkjan Ochtman Date: Thu, 8 Nov 2012 09:40:43 +1100 Thread-Topic: [jose] JOSE and JWT specs updated for IETF 85 working group meetings Thread-Index: Ac288Vj99Gynv15ZRVSA+YSAHjCdngAREnXw Message-ID: <255B9BB34FB7D647A506DC292726F6E115001D5339@WSMSG3153V.srv.dir.telstra.com> References: 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] JOSE and JWT specs updated for IETF 85 working group meetings 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, 07 Nov 2012 22:40:47 -0000 PiBXb3VsZCBpdCBtYWtlIHNlbnNlIHRvIHJlcG9ydCBhIGJ1ZyBvbiBjbGFyaWZ5aW5nIHRoZSBz aWduaW5nIG9wZXJhdGlvbg0KPiAoaS5lLiBQS0NTMSB2cy4gInB1cmUiIFJTQSBzaWduaW5nKSwg b3IgaXMgdGhhdCBzb21ldGhpbmcgdGhhdCBzaG91bGQNCj4gYmUgZGlzY3Vzc2VkIGhlcmUgZmly c3Q/DQoNCkF2b2lkaW5nIGRldmVsb3BlciBjb25mdXNpb24gaXMgZ2VuZXJhbGx5IGEgZ29vZCBy ZWFzb24gZm9yIGNsYXJpZmljYXRpb25zLCB0aG91Z2ggSSBkb3VidCByZXBvcnRpbmcgYSBidWcg b24gdGhpcyBzcGVjaWZpYyBwb2ludCBtYWtlcyBzZW5zZS4gVHJ5aW5nICJwdXJlIiBSU0Egc2ln bmluZyB3YXMgbmV2ZXIgYSBnb29kIGNob2ljZSBhcyBubyBvbmUgZG9lcyB0aGF0IChhbmQgc2hv dWxkbid0IGRvIGl0KS4NCg0KVGhlIG9yZ2FuaXNhdGlvbiBiZXR3ZWVuIEpXUy9KV0UvSldBL0pX Sy8uLi4gaXMgbm90IGdyZWF0LiBGaXhpbmcgdGhhdCBtaWdodCBoZWxwIGlmIGl0IHB1dHMgZGV0 YWlsZWQgZXhhbXBsZXMgY2xvc2VyIHRvIHRoZSBkZWZpbml0aW9uIG9mIHRoZSBhbGdvcml0aG1z IHRoZXkgdXNlLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From James.H.Manger@team.telstra.com Wed Nov 7 17:19: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 0935E21F8B06 for ; Wed, 7 Nov 2012 17:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[AWL=0.297, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RV8uOYjeNCB6 for ; Wed, 7 Nov 2012 17:19:04 -0800 (PST) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 25A5C21F8A55 for ; Wed, 7 Nov 2012 17:19:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,735,1344175200"; d="scan'208,217";a="100551389" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipocni.tcif.telstra.com.au with ESMTP; 08 Nov 2012 12:19:01 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6889"; a="97724433" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcbni.tcif.telstra.com.au with ESMTP; 08 Nov 2012 12:19:01 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Thu, 8 Nov 2012 12:19:00 +1100 From: "Manger, James H" To: "jose@ietf.org" Date: Thu, 8 Nov 2012 12:18:58 +1100 Thread-Topic: NIST Concat KDF Thread-Index: Ac22LuWgSDJoAVpDQL23HP4i5KxmTwACPfUAAcDFM+A= Message-ID: <255B9BB34FB7D647A506DC292726F6E115001D5886@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B168042967394366880D09@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436688123A@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436688296F@TK5EX14MBXC285.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114FFB9FC5D@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FFB9FC5D@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_255B9BB34FB7D647A506DC292726F6E115001D5886WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [jose] NIST Concat KDF 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, 08 Nov 2012 01:19:05 -0000 --_000_255B9BB34FB7D647A506DC292726F6E115001D5886WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sk9TRSBpcyBpbmNoaW5nIGNsb3NlciB0byBwcm9wZXJseSB1c2luZyBOSVNUIDgwMC01NkEgQ29u Y2F0IGtleSBkZXJpdmF0aW9uIGZ1bmN0aW9uIChLREYpLCBidXQgdGhlcmUgaXMgc3RpbGwgYSBz aXplYWJsZSBnYXAuDQoNClRoZSBsYXRlc3QgY2hhbmdlcyAoZHJhZnQtaWV0Zi1qb3NlLWpzb24t d2ViLWFsZ29yaXRobXMtMDcpIGFkZCBsZW5ndGggcHJlZml4ZXMgdG8gUGFydHlVSW5mbyBhbmQg UGFydHlWSW5mby4NCkhvd2V2ZXIsIHRoZSBBbGdvcml0aG1JRCBmaWVsZCBkb2VzbuKAmXQgaGF2 ZSBhIGxlbmd0aCBwcmVmaXg7IG5vciBkb2VzIFN1cHBQdWJJbmZvIG9yIFN1cHBQcml2SW5mby4N ClRoZSByZW1haW5pbmcgYW1iaWd1aXR5IGluIHRoZSBLREYgaW5wdXQgaXMgbGVzcyBwcmFjdGlj YWwgdG8gZXhwbG9pdCB0aGFuIHRoZSDigJxKb0JldGhBbm5l4oCdIGV4YW1wbGUgdGhhdCB3YXMg cHJldmlvdXNseSBwb3NzaWJsZSwgYnV0IHRoZW9yZXRpY2FsIGFtYmlndWl0eSByZW1haW5zLiBD YW7igJl0IHRoZSBzcGVjIGp1c3QgZG8gd2hhdCBOSVNUIDgwMC01NkEgc2F5cyBpZiBpdCByZWFs bHkgd2FudHMgdG8gdXNlIGl0Pw0KDQpEZWZpbmluZyDigJxhcHXigJ0gYW5kIOKAnGFwduKAnSB0 byBob2xkIFBhcnR5VUluZm8gYW5kIFBhcnR5VkluZm8gdmFsdWVzIGlzIG9ubHkgcHJldGVuZGlu ZyB0byBzdXBwb3J0IE5JU1QgODAwLTU2QS4gTklTVCA4MDAtNTZBIHNheXMgdGhleSBuZWVkIHRv IGJlIG1hbmRhdG9yeSAobm9uLW51bGwpIGFuZCB0aGV5IG5lZWQgdG8gYmUgZXhwbGljaXRseSBj aGVja2VkIGJ5IHRoZSByZWNpcGllbnQg4oCUIG5vdCBvcHRpb25hbCBhbmQgYmxpbmRseSBjb3Bp ZWQgZnJvbSBhcHUvYXB2IGZpZWxkcyB0byB0aGUgS0RGIGlucHV0Lg0KDQpUaGUgQWxnb3JpdGht SUQgZmllbGQgaXMgc3BlY2lmaWVkIGFzIGluZGljYXRpbmcg4oCcaG93IHRoZSBkZXJpdmVkIGtl eWluZyBtYXRlcmlhbCB3aWxsIGJlIHBhcnNlZCBhbmQgZm9yIHdoaWNoIGFsZ29yaXRobShzKSB0 aGUgZGVyaXZlZCBzZWNyZXQga2V5aW5nIG1hdGVyaWFsIHdpbGwgYmUgdXNlZOKAnS4gSk9TRSB2 aW9sYXRlcyB0aGlzLiBUaGUgc2FtZSBBbGdvcml0aG1JRCB2YWx1ZSAoZWcg4oCcPDAwMDAwMTAw PkExMjhDQkMrSFMyNTbigJ0pIGlzIHNvbWV0aW1lcyB1c2VkIHRvIGRlcml2ZSBhIDEyOC1iaXQg QUVTIGtleSwgYW5kIGF0IG90aGVyIHRpbWVzIHVzZWQgdG8gZGVyaXZlIGEgMjU2LWJpdCBITUFD IGtleS4gVGhlIEpPU0UgbWV0aG9kIGlzIGFsbW9zdCBjZXJ0YWlubHkg4oCcc2FmZeKAnSBhcyBp dCB1c2VzIGRpZmZlcmVudCBTdXBwUHViSW5mbyB2YWx1ZXMgKOKAnEVuY3J5cHRpb27igJ0gYW5k IOKAnEludGVncml0eeKAnSkgaW4gdGhlc2UgY2FzZXMg4oCUIGJ1dCBpdCBpcyBub3QgTklTVCA4 MDAtNTZBIENvbmNhdC4gQSBOSVNUIDgwMC01NkEgQ29uY2F0IGFwcHJvYWNoIHdvdWxkIHJ1biB0 aGUgS0RGIG9uY2UgYW5kIGdldCBvdXQgYSAzODQtYml0IHNlY3JldCB0aGF0IGlzIHNwbGl0IGlu dG8gdGhlIHJlcXVpcmVkIDEyOC1iaXQgYW5kIDI1Ni1iaXQga2V5cy4NCg0KLS0NCkphbWVzIE1h bmdlcg0KDQpGcm9tOiBqb3NlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpqb3NlLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYW5nZXIsIEphbWVzIEgNClNlbnQ6IFdlZG5lc2RheSwg MzEgT2N0b2JlciAyMDEyIDEyOjEzIEFNDQpUbzogam9zZUBpZXRmLm9yZw0KU3ViamVjdDogW2pv c2VdIE5JU1QgQ29uY2F0IEtERg0KDQpKT1NFIHN0aWxsIGRvZXNu4oCZdCB1c2UgdGhlIE5JU1Qg ODAwLTU2QSBDb25jYXQgS2V5IERGIGFzIHRoYXQgc3BlY2lmaWNhdGlvbiByZXF1aXJlcy4NCg0K SldBIGFsbG93cyBQYXJ0eVVJbmZvIGFuZC9vciBQYXJ0eVZJbmZvIHRvIGJlIGVtcHR5IChpZiBh cHUvYXB2L2VwdS9lcHYgYXJlIGFic2VudCkuIFRoYXQgZG9lc27igJl0IGNvbXBseSB3aXRoIDgw MC01NkEgdGhhdCBzYXlzIOKAnGF0IGEgbWluaW11bSwgUGFydHlVSW5mbyBzaGFsbCBpbmNsdWRl IElEdSwgdGhlIGlkZW50aXR5IG9mIHBhcnR5IFXigJ0uIDgwMC01NkEgYWxzbyBzYXlzIOKAnGl0 IGlzIHJlcXVpcmVkIHRoYXQgaWRlbnRpZmllciBmb3IgYm90aCBwYXJ0aWVzIHRvIGEga2V5IGFn cmVlbWVudCB0cmFuc2FjdGlvbiBiZSBpbmNsdWRlZCBpbiB0aGUgT3RoZXJJbmZvIHRoYXQgaXMg aW5wdXQgdG8gdGhlIGtleSBkZXJpdmF0aW9uIGZ1bmN0aW9u4oCdLg0KDQo4MDAtNTZBIHJlcXVp cmVzIHRoYXQgdGhlIGNvbmNhdGVuYXRpb24gQWxnb3JpdGhtSUQgfHwgUGFydHlVSW5mbyB8fCBQ YXJ0eVZJbmZvIGJlIHVuYW1iaWd1b3VzLiBJdCBhbGxvd3MgdHdvIHdheXMgdG8gYWNoaWV2ZSB0 aGlzOiBwcmUtZGVmaW5lIGZpeGVkIHNpemVzIGZvciBjb21wb25lbnRzOyBvciBwcmVmaXggZWFj aCBjb21wb25lbnQgd2l0aCBpdHMgbGVuZ3RoLiBKV0EgZG9lcyBuZWl0aGVyIG9mIHRoZXNlLg0K DQpDb25zaWRlciB0d28gSk9TRSBtZXNzYWdlcyAoaWdub3Jpbmcgc29tZSBpcnJlbGV2YW50IGJh c2U2NHVybCBlbmNvZGluZyk6DQogIHsgLi4uLCAiYXB1IjoiSm9CZXRoIiwgImFwdiI6IkFubmUi IH0gYW5kDQogIHsgLi4uLCAiYXB1IjoiSm8iLCAiYXB2IjoiQmV0aEFubmUiIH0NCkpXQSBpbXBs aWVzIGJvdGggdXNlIHRoZSBzdHJpbmcgIkpvQmV0aEFubmUiIGluIHRoZSBLREYgZGVzcGl0ZSB0 aGUgbWVzc2FnZXMgYmVpbmcgYmV0d2VlbiBkaWZmZXJlbnQgcGFydGllcywgd2hpY2ggZGVmZWF0 cyB0aGlzIHBhcnQgb2YgdGhlIENvbmNhdCBLREYgZGVzaWduLg0KDQpKV0EgZXhwbGljaXRseSBw dXRzIHRoZSBrZXkgbGVuZ3RoIGFuZCAiYWxnIiB2YWx1ZSBpbnRvIHRoZSBBbGdvcml0aG1JRCBm aWVsZCB0aGF0IHRoZSBLREYgdXNlcy4gSG93ZXZlciwgdGhlICJhbGciIHZhbHVlIGFsb25lIG11 c3QgaW1wbHkgb25lIHNwZWNpZmljIGtleSBsZW5ndGggZm9yIHRoZSByZXN0IG9mIHRoZSBKT1NF IHByb2Nlc3NpbmcgdG8gd29yayBzbyBpbmNsdWRpbmcgdGhlIGtleSBsZW5ndGggZXhwbGljaXRs eSBpcyByZWR1bmRhbnQuDQoNCjgwMC01NkEgaXMgZGVzaWduZWQgdG8gZGVyaXZlIGludGVncml0 eSBhbmQgZW5jcnlwdGlvbiBrZXlzIHRvZ2V0aGVyLiBGb3IgaW5zdGFuY2UsIGl0IHNheXMg4oCc QWxnb3JpdGhtSUQgbWlnaHQgaW5kaWNhdGUgdGhhdCBiaXRzIDEtODAgYXJlIHRvIGJlIHVzZWQg YXMgYW4gODAtYml0IEhNQUMga2V5IGFuZCB0aGF0IGJpdHMgODEtMjA4IGFyZSB0byBiZSB1c2Vk IGFzIGEgMTI4LWJpdCBBRVMga2V54oCdLiBKV0EgZG9lcyBub3QgZG8gdGhpcy4gSldBIHJ1bnMg dGhlIEtERiB0d2ljZSB0byBkZXJpdmUgaW50ZWdyaXR5IGFuZCBlbmNyeXB0aW9uIGtleXMgc2Vw YXJhdGVseS4NCg0KSWYgd2Ugd2FudCB0byB1c2UgTklTVCA4MDAtNTZBIENvbmNhdCBLREYgdGhl biBKV0EvSldFIG5lZWRzIGxvdHMgb2YgZml4ZXMuDQpJZiB3ZSB3YW50IGEgc2ltcGxlciBLREYg dGhlbiBKV0Egc2hvdWxkbuKAmXQgcHJldGVuZCBpdCBpcyB0aGUgTklTVCA4MDAtNTZBIENvbmNh dCBLREYuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== --_000_255B9BB34FB7D647A506DC292726F6E115001D5886WSMSG3153Vsrv_ 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 Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJv ZHkgbGFuZz1FTi1BVSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rp b24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkpPU0UgaXMgaW5j aGluZyBjbG9zZXIgdG8gcHJvcGVybHkgdXNpbmcgTklTVCA4MDAtNTZBIENvbmNhdCBrZXkgZGVy aXZhdGlvbiBmdW5jdGlvbiAoS0RGKSwgYnV0IHRoZXJlIGlzIHN0aWxsIGEgc2l6ZWFibGUgZ2Fw LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlIGxhdGVzdCBjaGFuZ2VzIChkcmFmdC1pZXRmLWpvc2Ut anNvbi13ZWItYWxnb3JpdGhtcy0wNykgYWRkIGxlbmd0aCBwcmVmaXhlcyB0byBQYXJ0eVVJbmZv IGFuZCBQYXJ0eVZJbmZvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Ib3dldmVyLCB0aGUgQWxnb3JpdGhtSUQgZmllbGQgZG9l c27igJl0IGhhdmUgYSBsZW5ndGggcHJlZml4OyBub3IgZG9lcyBTdXBwUHViSW5mbyBvciBTdXBw UHJpdkluZm8uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPlRoZSByZW1haW5pbmcgYW1iaWd1aXR5IGluIHRoZSBLREYgaW5wdXQg aXMgbGVzcyBwcmFjdGljYWwgdG8gZXhwbG9pdCB0aGFuIHRoZSDigJxKb0JldGhBbm5l4oCdIGV4 YW1wbGUgdGhhdCB3YXMgcHJldmlvdXNseSBwb3NzaWJsZSwgYnV0IHRoZW9yZXRpY2FsIGFtYmln dWl0eSByZW1haW5zLiBDYW7igJl0IHRoZSBzcGVjIGp1c3QgZG8gd2hhdCBOSVNUIDgwMC01NkEg c2F5cyBpZiBpdCByZWFsbHkgd2FudHMgdG8gdXNlIGl0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+RGVm aW5pbmcg4oCcYXB14oCdIGFuZCDigJxhcHbigJ0gdG8gaG9sZCBQYXJ0eVVJbmZvIGFuZCBQYXJ0 eVZJbmZvIHZhbHVlcyBpcyBvbmx5IHByZXRlbmRpbmcgdG8gc3VwcG9ydCBOSVNUIDgwMC01NkEu IE5JU1QgODAwLTU2QSBzYXlzIHRoZXkgbmVlZCB0byBiZSBtYW5kYXRvcnkgKG5vbi1udWxsKSBh bmQgdGhleSBuZWVkIHRvIGJlIGV4cGxpY2l0bHkgY2hlY2tlZCBieSB0aGUgcmVjaXBpZW50IOKA lCBub3Qgb3B0aW9uYWwgYW5kIGJsaW5kbHkgY29waWVkIGZyb20gYXB1L2FwdiBmaWVsZHMgdG8g dGhlIEtERiBpbnB1dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBBbGdvcml0aG1JRCBmaWVsZCBp cyBzcGVjaWZpZWQgYXMgaW5kaWNhdGluZyDigJxob3cgdGhlIGRlcml2ZWQga2V5aW5nIG1hdGVy aWFsIHdpbGwgYmUgcGFyc2VkIGFuZCBmb3Igd2hpY2ggYWxnb3JpdGhtKHMpIHRoZSBkZXJpdmVk IHNlY3JldCBrZXlpbmcgbWF0ZXJpYWwgd2lsbCBiZSB1c2Vk4oCdLiBKT1NFIHZpb2xhdGVzIHRo aXMuIFRoZSBzYW1lIEFsZ29yaXRobUlEIHZhbHVlIChlZyDigJwmbHQ7MDAwMDAxMDAmZ3Q7QTEy OENCQytIUzI1NuKAnSkgaXMgc29tZXRpbWVzIHVzZWQgdG8gZGVyaXZlIGEgMTI4LWJpdCBBRVMg a2V5LCBhbmQgYXQgb3RoZXIgdGltZXMgdXNlZCB0byBkZXJpdmUgYSAyNTYtYml0IEhNQUMga2V5 LiBUaGUgSk9TRSBtZXRob2QgaXMgYWxtb3N0IGNlcnRhaW5seSDigJxzYWZl4oCdIGFzIGl0IHVz ZXMgZGlmZmVyZW50IFN1cHBQdWJJbmZvIHZhbHVlcyAo4oCcRW5jcnlwdGlvbuKAnSBhbmQg4oCc SW50ZWdyaXR54oCdKSBpbiB0aGVzZSBjYXNlcyDigJQgYnV0IGl0IGlzIG5vdCBOSVNUIDgwMC01 NkEgQ29uY2F0LiBBIE5JU1QgODAwLTU2QSBDb25jYXQgYXBwcm9hY2ggd291bGQgcnVuIHRoZSBL REYgb25jZSBhbmQgZ2V0IG91dCBhIDM4NC1iaXQgc2VjcmV0IHRoYXQgaXMgc3BsaXQgaW50byB0 aGUgcmVxdWlyZWQgMTI4LWJpdCBhbmQgMjU2LWJpdCBrZXlzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiInPiBqb3NlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpq b3NlLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+TWFuZ2VyLCBKYW1lcyBI PGJyPjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIDMxIE9jdG9iZXIgMjAxMiAxMjoxMyBBTTxicj48 Yj5Ubzo8L2I+IGpvc2VAaWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFtqb3NlXSBOSVNUIENv bmNhdCBLREY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPkpPU0Ugc3RpbGwgZG9lc27igJl0IHVzZSB0aGUgTklTVCA4MDAtNTZBIENvbmNh dCBLZXkgREYgYXMgdGhhdCBzcGVjaWZpY2F0aW9uIHJlcXVpcmVzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+SldBIGFsbG93cyBQYXJ0eVVJbmZvIGFuZC9vciBQYXJ0eVZJbmZvIHRvIGJlIGVtcHR5IChp ZiBhcHUvYXB2L2VwdS9lcHYgYXJlIGFic2VudCkuIFRoYXQgZG9lc27igJl0IGNvbXBseSB3aXRo IDgwMC01NkEgdGhhdCBzYXlzIOKAnGF0IGEgbWluaW11bSwgUGFydHlVSW5mbyBzaGFsbCBpbmNs dWRlIElEdSwgdGhlIGlkZW50aXR5IG9mIHBhcnR5IFXigJ0uIDgwMC01NkEgYWxzbyBzYXlzIOKA nGl0IGlzIHJlcXVpcmVkIHRoYXQgaWRlbnRpZmllciBmb3IgYm90aCBwYXJ0aWVzIHRvIGEga2V5 IGFncmVlbWVudCB0cmFuc2FjdGlvbiBiZSBpbmNsdWRlZCBpbiB0aGUgT3RoZXJJbmZvIHRoYXQg aXMgaW5wdXQgdG8gdGhlIGtleSBkZXJpdmF0aW9uIGZ1bmN0aW9u4oCdLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+ODAwLTU2QSByZXF1aXJlcyB0aGF0IHRoZSBjb25jYXRlbmF0aW9uIEFsZ29yaXRobUlE IHx8IFBhcnR5VUluZm8gfHwgUGFydHlWSW5mbyBiZSB1bmFtYmlndW91cy4gSXQgYWxsb3dzIHR3 byB3YXlzIHRvIGFjaGlldmUgdGhpczogcHJlLWRlZmluZSBmaXhlZCBzaXplcyBmb3IgY29tcG9u ZW50czsgb3IgcHJlZml4IGVhY2ggY29tcG9uZW50IHdpdGggaXRzIGxlbmd0aC4gSldBIGRvZXMg bmVpdGhlciBvZiB0aGVzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkNvbnNpZGVyIHR3byBKT1NFIG1l c3NhZ2VzIChpZ25vcmluZyBzb21lIGlycmVsZXZhbnQgYmFzZTY0dXJsIGVuY29kaW5nKTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+Jm5ic3A7IHsgLi4uLCAmcXVvdDthcHUmcXVvdDs6JnF1b3Q7Sm9CZXRoJnF1b3Q7LCAmcXVv dDthcHYmcXVvdDs6JnF1b3Q7QW5uZSZxdW90OyB9IGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDsgeyAuLi4sICZx dW90O2FwdSZxdW90OzomcXVvdDtKbyZxdW90OywgJnF1b3Q7YXB2JnF1b3Q7OiZxdW90O0JldGhB bm5lJnF1b3Q7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+SldBIGltcGxpZXMgYm90aCB1c2UgdGhlIHN0cmluZyAmcXVvdDtK b0JldGhBbm5lJnF1b3Q7IGluIHRoZSBLREYgZGVzcGl0ZSB0aGUgbWVzc2FnZXMgYmVpbmcgYmV0 d2VlbiBkaWZmZXJlbnQgcGFydGllcywgd2hpY2ggZGVmZWF0cyB0aGlzIHBhcnQgb2YgdGhlIENv bmNhdCBLREYgZGVzaWduLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SldBIGV4cGxpY2l0bHkgcHV0cyB0 aGUga2V5IGxlbmd0aCBhbmQgJnF1b3Q7YWxnJnF1b3Q7IHZhbHVlIGludG8gdGhlIEFsZ29yaXRo bUlEIGZpZWxkIHRoYXQgdGhlIEtERiB1c2VzLiBIb3dldmVyLCB0aGUgJnF1b3Q7YWxnJnF1b3Q7 IHZhbHVlIGFsb25lIG11c3QgaW1wbHkgb25lIHNwZWNpZmljIGtleSBsZW5ndGggZm9yIHRoZSBy ZXN0IG9mIHRoZSBKT1NFIHByb2Nlc3NpbmcgdG8gd29yayBzbyBpbmNsdWRpbmcgdGhlIGtleSBs ZW5ndGggZXhwbGljaXRseSBpcyByZWR1bmRhbnQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz44MDAtNTZB IGlzIGRlc2lnbmVkIHRvIGRlcml2ZSBpbnRlZ3JpdHkgYW5kIGVuY3J5cHRpb24ga2V5cyB0b2dl dGhlci4gRm9yIGluc3RhbmNlLCBpdCBzYXlzIOKAnEFsZ29yaXRobUlEIG1pZ2h0IGluZGljYXRl IHRoYXQgYml0cyAxLTgwIGFyZSB0byBiZSB1c2VkIGFzIGFuIDgwLWJpdCBITUFDIGtleSBhbmQg dGhhdCBiaXRzIDgxLTIwOCBhcmUgdG8gYmUgdXNlZCBhcyBhIDEyOC1iaXQgQUVTIGtleeKAnS4g SldBIGRvZXMgbm90IGRvIHRoaXMuIEpXQSBydW5zIHRoZSBLREYgdHdpY2UgdG8gZGVyaXZlIGlu dGVncml0eSBhbmQgZW5jcnlwdGlvbiBrZXlzIHNlcGFyYXRlbHkuPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5JZiB3ZSB3YW50IHRvIHVzZSBOSVNUIDgwMC01NkEgQ29uY2F0IEtERiB0aGVuIEpXQS9KV0Ug bmVlZHMgbG90cyBvZiBmaXhlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SWYgd2Ugd2FudCBhIHNpbXBsZXIgS0RGIHRoZW4g SldBIHNob3VsZG7igJl0IHByZXRlbmQgaXQgaXMgdGhlIE5JU1QgODAwLTU2QSBDb25jYXQgS0RG LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_255B9BB34FB7D647A506DC292726F6E115001D5886WSMSG3153Vsrv_-- From jhildebr@cisco.com Wed Nov 7 08:10: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 CBF9321F8C23 for ; Wed, 7 Nov 2012 08:10:35 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ltmyyUxu3u1 for ; Wed, 7 Nov 2012 08:10:35 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 645B021F8C54 for ; Wed, 7 Nov 2012 08:10:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=509; q=dns/txt; s=iport; t=1352304633; x=1353514233; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=QR4IgUGXFb9JqS5LogmEGFmNo/3D/MJ7Z/hiJj4xjqo=; b=dW2g2GnULd58jc03Sbv1dp51IyslaqJAKg1Y78CRJtCTj3Cd8HKd0aMM 8hBHgdGxRfZK5fS7T0/Jphw1rUMyhzPbt/idPvr0wQA4PLHFvRAwjcYkp dsxOvkBYQnt6Kw+KG/H69xn8Nq1//tzCjMOOAu2jCrNLh+KZNyHDijGHV Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskIAHqHmlCtJV2b/2dsb2JhbABEw2CBAQeCIAEEEgEnUQEaEBRCFxAEGxqHaJsPgSugJZFzYQOkVIFrgm+BZDU X-IronPort-AV: E=Sophos;i="4.80,730,1344211200"; d="scan'208";a="139780628" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 07 Nov 2012 16:10:29 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA7GAT1H013339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 7 Nov 2012 16:10:29 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.252]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 10:10:29 -0600 From: "Joe Hildebrand (jhildebr)" To: "jose@ietf.org" Thread-Topic: Whiteboard discussion Thread-Index: AQHNvQJnTeRLN31T7keUlOoq8Mm1ow== Date: Wed, 7 Nov 2012 16:10:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.21.68.57] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19346.005 x-tm-as-result: No--24.074500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 08 Nov 2012 07:25:01 -0800 Subject: [jose] Whiteboard discussion 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, 07 Nov 2012 16:10:36 -0000 If you're interested in participating in the high-level architecture discussion we just talked about in the room, and you're in Atlanta this week, please send me a message off-list. This activity is not intended to be secret in any way, we are just going to try to put together an email to the list that combines all of the different ideas that we heard in the room as a coherent world view, so the group can form an opinion about precisely how many documents we're writing. --=20 Joe Hildebrand From rbarnes@bbn.com Thu Nov 8 22:56: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 81BA721F8B83 for ; Thu, 8 Nov 2012 22:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.849 X-Spam-Level: X-Spam-Status: No, score=-106.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jS7tjeDXaJ4W for ; Thu, 8 Nov 2012 22:56:41 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id B3A0C21F8B80 for ; Thu, 8 Nov 2012 22:56:41 -0800 (PST) Received: from [128.89.253.120] (port=57398) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TWiW5-000MDS-Q3; Fri, 09 Nov 2012 01:56:37 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Richard L. Barnes" In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115001D5886@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 9 Nov 2012 01:56:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B168042967394366880D09@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436688123A@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436688296F@TK5EX14MBXC285.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114FFB9FC5D@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E115001D5886@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1499) Cc: "jose@ietf.org" Subject: Re: [jose] NIST Concat KDF 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, 09 Nov 2012 06:56:42 -0000 If implementing Concat is this much work, why not just use longer keys? On Nov 7, 2012, at 8:18 PM, "Manger, James H" = wrote: > JOSE is inching closer to properly using NIST 800-56A Concat key = derivation function (KDF), but there is still a sizeable gap. > =20 > The latest changes (draft-ietf-jose-json-web-algorithms-07) add length = prefixes to PartyUInfo and PartyVInfo. > However, the AlgorithmID field doesn=92t have a length prefix; nor = does SuppPubInfo or SuppPrivInfo. > The remaining ambiguity in the KDF input is less practical to exploit = than the =93JoBethAnne=94 example that was previously possible, but = theoretical ambiguity remains. Can=92t the spec just do what NIST = 800-56A says if it really wants to use it? > =20 > Defining =93apu=94 and =93apv=94 to hold PartyUInfo and PartyVInfo = values is only pretending to support NIST 800-56A. NIST 800-56A says = they need to be mandatory (non-null) and they need to be explicitly = checked by the recipient =97 not optional and blindly copied from = apu/apv fields to the KDF input. > =20 > The AlgorithmID field is specified as indicating =93how the derived = keying material will be parsed and for which algorithm(s) the derived = secret keying material will be used=94. JOSE violates this. The same = AlgorithmID value (eg =93<00000100>A128CBC+HS256=94) is sometimes used = to derive a 128-bit AES key, and at other times used to derive a 256-bit = HMAC key. The JOSE method is almost certainly =93safe=94 as it uses = different SuppPubInfo values (=93Encryption=94 and =93Integrity=94) in = these cases =97 but it is not NIST 800-56A Concat. A NIST 800-56A Concat = approach would run the KDF once and get out a 384-bit secret that is = split into the required 128-bit and 256-bit keys. > =20 > -- > James Manger > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Manger, James H > Sent: Wednesday, 31 October 2012 12:13 AM > To: jose@ietf.org > Subject: [jose] NIST Concat KDF > =20 > JOSE still doesn=92t use the NIST 800-56A Concat Key DF as that = specification requires. > =20 > JWA allows PartyUInfo and/or PartyVInfo to be empty (if = apu/apv/epu/epv are absent). That doesn=92t comply with 800-56A that = says =93at a minimum, PartyUInfo shall include IDu, the identity of = party U=94. 800-56A also says =93it is required that identifier for both = parties to a key agreement transaction be included in the OtherInfo that = is input to the key derivation function=94. > =20 > 800-56A requires that the concatenation AlgorithmID || PartyUInfo || = PartyVInfo be unambiguous. It allows two ways to achieve this: = pre-define fixed sizes for components; or prefix each component with its = length. JWA does neither of these. > =20 > Consider two JOSE messages (ignoring some irrelevant base64url = encoding): > { ..., "apu":"JoBeth", "apv":"Anne" } and > { ..., "apu":"Jo", "apv":"BethAnne" } > JWA implies both use the string "JoBethAnne" in the KDF despite the = messages being between different parties, which defeats this part of the = Concat KDF design. > =20 > JWA explicitly puts the key length and "alg" value into the = AlgorithmID field that the KDF uses. However, the "alg" value alone must = imply one specific key length for the rest of the JOSE processing to = work so including the key length explicitly is redundant. > =20 > 800-56A is designed to derive integrity and encryption keys together. = For instance, it says =93AlgorithmID might indicate that bits 1-80 are = to be used as an 80-bit HMAC key and that bits 81-208 are to be used as = a 128-bit AES key=94. JWA does not do this. JWA runs the KDF twice to = derive integrity and encryption keys separately. > =20 > If we want to use NIST 800-56A Concat KDF then JWA/JWE needs lots of = fixes. > If we want a simpler KDF then JWA shouldn=92t pretend it is the NIST = 800-56A Concat KDF. > =20 > -- > James Manger > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From rbarnes@bbn.com Thu Nov 8 22:58: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 AA57921F8536 for ; Thu, 8 Nov 2012 22:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.799 X-Spam-Level: X-Spam-Status: No, score=-106.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBX4lyICrASc for ; Thu, 8 Nov 2012 22:58:39 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 02F4921F853F for ; Thu, 8 Nov 2012 22:58:39 -0800 (PST) Received: from [128.89.253.120] (port=57408) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TWiY2-0001ux-FB; Fri, 09 Nov 2012 01:58:38 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Richard L. Barnes" In-Reply-To: <19F1B8FA-6655-4933-A58C-70B12BE025C3@gmail.com> Date: Fri, 9 Nov 2012 01:58:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3F30DDAB-F245-459F-90B9-91DCFED11A3A@bbn.com> References: <20121107093441.26081.45621.idtracker@ietfa.amsl.com> <19F1B8FA-6655-4933-A58C-70B12BE025C3@gmail.com> To: Dick Hardt X-Mailer: Apple Mail (2.1499) Cc: "jose@ietf.org" Subject: Re: [jose] proposal: put encryption header parameters into a separate object 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, 09 Nov 2012 06:58:39 -0000 Hey Dick, To make sure I understand your use case correctly: You want to convey an = encrypted object, as well as a signature over the plaintext (without = having to encrypt the signature value). Does that sound accurate? It seems like there are three types of information you want in the = object: (1) cipher text, (2) encryption parameters, and (3) signature = value/parameters. So why not encapsulate it like that? To propose a = JSON syntax: { "enc": { /* encryption parameters */ }, "sig": { /* signature parameters + value */ }, "val": "/* ciphertext */" } Obviously:=20 -- JWE/JWS could be the special cases where only one of "enc" or "sig" = is present -- This cleanly supports multiple signatures via multiple "sig" values = (e.g., in an array) -- This cleanly supports multiple recipients via multiple "enc" values = (e.g., in an array) -- You could leave one of "enc" or "sig" parameters as flat lists (as in = JWS/JWE), but it seems cleaner to have them parallel -- For a compact serialization, you would want certain fields to be not = double-base64'ed. We can figure that out later :) This seems like kind of an appealing line of reasoning to me. I would = be glad to do some work on figuring out the details. --Richard On Nov 7, 2012, at 3:23 PM, Dick Hardt wrote: > To enable encrypting and then signing of the same token, we need to = specify the encrypting and signing algorithms separately. >=20 > Since we are using JSON, how about if we create an encryption object = to contain all the parameters defined in JWE so that there is no overlap = in the JWS namespace. >=20 > "enc":=20 > { "alg" > , "enc" > , "zip" > } >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From bobwyman@gmail.com Fri Nov 9 08:29: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 BFE2C21F8646 for ; Fri, 9 Nov 2012 08:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lOBZwXMqD1H for ; Fri, 9 Nov 2012 08:29:09 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E02721F8680 for ; Fri, 9 Nov 2012 08:29:08 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id k13so3452636lbo.31 for ; Fri, 09 Nov 2012 08:29:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=pgYhax5KVvOKbS7ABD0+OxQUQ8t4Z3jD8q8Wc1tZwnc=; b=tMyPJjmYT3eoAHRsbiBzk21Z6EFazmM58Wj/6lInRRdirBnmkHARDiwkInJ7IqWFP+ XafEAlB/XdnS9pYntWmblu/6tl4BgJHP5Km54RQBSWFDygTOe48YRgpQOkZtby/n5LvE 80Q6MlEde1VzZqaovNIhD4KzBnjdeNmvW92I7229KZRzDWhL3o80PfG11kVa03jj0AHu QSg6rfGJbZJAa4EzbC1Tnl3j4Ee5dVJQucYSy5JiRGBPuH0TZiEA5Eb1dYvjiHrcNkWN m5EZbAPfHnWHGPhLLnGQ3+PRBFB2RTKcVn/SH9EFtkI2BXpntwQr0HbCfudcpvc6yzBg jtCg== MIME-Version: 1.0 Received: by 10.152.104.50 with SMTP id gb18mr11320003lab.9.1352478547120; Fri, 09 Nov 2012 08:29:07 -0800 (PST) Sender: bobwyman@gmail.com Received: by 10.114.37.227 with HTTP; Fri, 9 Nov 2012 08:29:07 -0800 (PST) In-Reply-To: <3F30DDAB-F245-459F-90B9-91DCFED11A3A@bbn.com> References: <20121107093441.26081.45621.idtracker@ietfa.amsl.com> <19F1B8FA-6655-4933-A58C-70B12BE025C3@gmail.com> <3F30DDAB-F245-459F-90B9-91DCFED11A3A@bbn.com> Date: Fri, 9 Nov 2012 11:29:07 -0500 X-Google-Sender-Auth: tFvzHj2CPdJdz7Yt_f0VBe5EAss Message-ID: From: Bob Wyman To: "Richard L. Barnes" Content-Type: multipart/alternative; boundary=f46d04083df75e12e104ce1273b5 Cc: "jose@ietf.org" , Dick Hardt Subject: Re: [jose] proposal: put encryption header parameters into a separate object 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, 09 Nov 2012 16:29:09 -0000 --f46d04083df75e12e104ce1273b5 Content-Type: text/plain; charset=ISO-8859-1 The "val" element in Barnes' proposal would need some parameters (typ, cty, etc.) as well as the content in val: { "enc": { /* encryption parameters */ }, "sig": { /* signature parameters + value */ }, "val": *{*/** content parameters +* plaintext */*}* } On Fri, Nov 9, 2012 at 1:58 AM, Richard L. Barnes wrote: > Hey Dick, > > To make sure I understand your use case correctly: You want to convey an > encrypted object, as well as a signature over the plaintext (without having > to encrypt the signature value). Does that sound accurate? > > It seems like there are three types of information you want in the object: > (1) cipher text, (2) encryption parameters, and (3) signature > value/parameters. So why not encapsulate it like that? To propose a JSON > syntax: > > { > "enc": { /* encryption parameters */ }, > "sig": { /* signature parameters + value */ }, > "val": "/* ciphertext */" > } > > Obviously: > -- JWE/JWS could be the special cases where only one of "enc" or "sig" is > present > -- This cleanly supports multiple signatures via multiple "sig" values > (e.g., in an array) > -- This cleanly supports multiple recipients via multiple "enc" values > (e.g., in an array) > -- You could leave one of "enc" or "sig" parameters as flat lists (as in > JWS/JWE), but it seems cleaner to have them parallel > -- For a compact serialization, you would want certain fields to be not > double-base64'ed. We can figure that out later :) > > This seems like kind of an appealing line of reasoning to me. I would be > glad to do some work on figuring out the details. > > --Richard > > > > > On Nov 7, 2012, at 3:23 PM, Dick Hardt wrote: > > > To enable encrypting and then signing of the same token, we need to > specify the encrypting and signing algorithms separately. > > > > Since we are using JSON, how about if we create an encryption object to > contain all the parameters defined in JWE so that there is no overlap in > the JWS namespace. > > > > "enc": > > { "alg" > > , "enc" > > , "zip" > > } > > > > _______________________________________________ > > 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 > --f46d04083df75e12e104ce1273b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The "val" element in Barnes= ' proposal would need some parameters (typ, cty, etc.) as well as the c= ontent in val:

{
=A0 "enc": { /* encryption pa= rameters */ },
=A0 "sig&q= uot;: { /* signature parameters + value */ },
=A0 "val": {/* content parameters += =A0plaintext */}
}



On Fri, N= ov 9, 2012 at 1:58 AM, Richard L. Barnes <rbarnes@bbn.com> wro= te:
Hey Dick,

To make sure I understand your use case correctly: You want to convey an en= crypted object, as well as a signature over the plaintext (without having t= o encrypt the signature value). =A0Does that sound accurate?

It seems like there are three types of information you want in the object: = (1) cipher text, (2) encryption parameters, and (3) signature value/paramet= ers. =A0So why not encapsulate it like that? =A0To propose a JSON syntax:
{
=A0 "enc": { /* encryption parameters */ },
=A0 "sig": { /* signature parameters + value */ },
=A0 "val": "/* ciphertext */"
}

Obviously:
-- JWE/JWS could be the special cases where only one of "enc" or = "sig" is present
-- This cleanly supports multiple signatures via multiple "sig" v= alues (e.g., in an array)
-- This cleanly supports multiple recipients via multiple "enc" v= alues (e.g., in an array)
-- You could leave one of "enc" or "sig" parameters as = flat lists (as in JWS/JWE), but it seems cleaner to have them parallel
-- For a compact serialization, you would want certain fields to be not dou= ble-base64'ed. =A0We can figure that out later :)

This seems like kind of an appealing line of reasoning to me. =A0I would be= glad to do some work on figuring out the details.

--Richard




On Nov 7, 2012, at 3:23 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

> To enable encrypting and then signing of the same token, we need to sp= ecify the encrypting and signing algorithms separately.
>
> Since we are using JSON, how about if we create an encryption object t= o contain all the parameters defined in JWE so that there is no overlap in = the JWS namespace.
>
> "enc":
> =A0 =A0 =A0 { =A0"alg"
> =A0 =A0 =A0 , =A0"enc"
> =A0 =A0 =A0 , =A0"zip"
> =A0 =A0 =A0 }
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose

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

--f46d04083df75e12e104ce1273b5-- From ietf@meetecho.com Fri Nov 9 09:07: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 0AD8A21F877B for ; Fri, 9 Nov 2012 09:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naWhrorWqi-Q for ; Fri, 9 Nov 2012 09:07:40 -0800 (PST) Received: from smtpdg9.aruba.it (smtpdg9.aruba.it [62.149.158.239]) by ietfa.amsl.com (Postfix) with ESMTP id 32CCA21F8759 for ; Fri, 9 Nov 2012 09:07:34 -0800 (PST) Received: from [130.129.19.11] ([130.129.19.11]) by smtpcmd03.ad.aruba.it with bizsmtp id MV7Y1k00A0ELJoa01V7YWA; Fri, 09 Nov 2012 18:07:33 +0100 Message-ID: <509D3852.3020502@meetecho.com> Date: Fri, 09 Nov 2012 18:07:30 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "jose@ietf.org" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [jose] Meetecho session recording 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, 09 Nov 2012 17:07:41 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of this WG session at IETF-85 is available. You can watch it by accessing the following URL: http://www.meetecho.com/ietf85/recordings For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From michael_b_jones@hotmail.com Fri Nov 9 10:06: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 043F921F8506 for ; Fri, 9 Nov 2012 10:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5dVFVhDz92i for ; Fri, 9 Nov 2012 10:06:22 -0800 (PST) Received: from bay0-omc1-s23.bay0.hotmail.com (bay0-omc1-s23.bay0.hotmail.com [65.54.190.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5E321F84B1 for ; Fri, 9 Nov 2012 10:06:22 -0800 (PST) Received: from BAY171-W32 ([65.54.190.61]) by bay0-omc1-s23.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Nov 2012 10:06:22 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_cbe74add-56f7-4f15-97c9-4e15d77cddaf_" X-Originating-IP: [107.17.123.153] From: Michael Jones To: Date: Fri, 9 Nov 2012 10:06:22 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 09 Nov 2012 18:06:22.0387 (UTC) FILETIME=[ED023030:01CDBEA4] Subject: [jose] Choice for WG: Use a KDF with AES CBC or use a longer 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, 09 Nov 2012 18:06:23 -0000 --_cbe74add-56f7-4f15-97c9-4e15d77cddaf_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Some working group members=2C including Axel=2C James=2C Matt=2C and Richard have expressed dissatisfaction with the use of the Concat KDF to generate the CEK and CIK when AES CBC is the block encryption algorithm. R= easons stated are implementation complexity and possible issues with following the letter of the law of the NIST spec. = Axel and Richard had both written suggesting an alternative =96 let the CMK be simply the concatenation of the CEK and the = CIK values. This is the same approach used in draft-mcgrew-aead-aes-cbc-hmac-sha2. =20 I and others had argued against this for size reasons. For A128CBC+HS256 this would increase the CMK size from 256 bits to 384 bits and for A256CBC+HS512 this would increase the CMK size from 512 bits to 768 bits. In the first case= =2C after base64url encoding=2C one would expect the extra 128 bits to require about an extra 21 bytes in the J= WE. The interesting fact though=2C is that when an RSA algorithm is used to encrypt the CMK=2C the output size is same as the = RSA key size =96 in our case=2C a minimum of 2048 bits.=20 Thus=2C for any combination of =93alg=94:=94RSA1_5=94 or =93RSA-OAEP=94 and= =93enc=94:=94A128CBC+HS256=94 or =93A256CBC+HS512=94 there is no actual size difference in the JWE. (However when =93alg=94:=94A128KW=94 or =93A256KW=94 are used=2C there would be a si= ze increase of about 21 or 43 bytes=2C respectively.) =20 So I=92d like to explicitly ask the working group. Do you want us to: =20 (1) Use the concatenation of random CEK and CIK values as the CMK for AES CBC=2C resulting in a longer CMK? (2) Continue to use a KDF to generate the CEK and CIK from a shorter CMK? =20 Thanks all=2C -- Mike =20 P.S. A KDF will still be required for ECDH-ES key agreement.=20 I=92ll address James=92 concerns about our use of Concat in a separate note= . = --_cbe74add-56f7-4f15-97c9-4e15d77cddaf_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Some working group members=2C including Axel= =2C James=2C Matt=2C and Richard have expressed dissatisfaction with the use of the Concat KDF to generate the CEK and CIK when AES CBC is the block encryption algorithm. =3B Reasons stated are implem= entation complexity and possible issues with following the letter of the law of the NIST spec.<= span style=3D"mso-spacerun: yes=3B"> =3B Axel and Richard had bo= th written suggesting an alternative =96 let the CMK be simply the concatenation of the CEK and the = CIK values. =3B This is the sam= e approach used in draft-mcgrew-aead-aes-cbc-hmac-sha2.

 =3B

I and others had argued against this for siz= e reasons. =3B For A128CBC+HS= 256 this would increase the CMK size from 256 bits to 384 bits and for A256CBC+HS512 this would increase the CMK size from 512 bits to 768 bits. =3B In the first case=2C after base64url encodi= ng=2C one would expect the extra 128 bits to require about an extra 21 bytes in the J= WE. =3B The interesting fac= t though=2C is that when an RSA algorithm is used to encrypt the CMK=2C the output size is same as the = RSA key size =96 in our case=2C a minimum of 2048 bits. =3B Thus=2C for any combination of =93alg=94:=94RSA1_5=94 or =93RSA-OAEP= =94 and =93enc=94:=94A128CBC+HS256=94 or =93A256CBC+HS512=94 there is= no actual size difference in the JWE. = =3B (However when =93alg=94:=94A128KW=94 or =93A256KW=94 are used=2C there would be a si= ze increase of about 21 or 43 bytes=2C respectively.)

 =3B

So I=92d like to explicitly ask the working = group. =3B Do you want us t= o:

 =3B

(1) Use the concatenation of random CEK and = CIK values as the CMK for AES CBC=2C resulting in a longer CMK?<= /p>

(2) Continue to use a KDF to generate the CE= K and CIK from a shorter CMK?

 =3B

 =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B Thanks all=2C<= o:p>

 =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B -- Mike

 =3B

P.S.&nb= sp=3B A KDF will still be required for ECDH-ES key agreement. =3B I=92ll address James=92 concerns about our use of Concat in a separa= te note.

= --_cbe74add-56f7-4f15-97c9-4e15d77cddaf_-- From ignisvulpis@gmail.com Fri Nov 9 10:48: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 9C40B21F84EB for ; Fri, 9 Nov 2012 10:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCV4cg-L+Oqj for ; Fri, 9 Nov 2012 10:48:33 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 76FEC21F84E6 for ; Fri, 9 Nov 2012 10:48:33 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr13so1920630wgb.13 for ; Fri, 09 Nov 2012 10:48:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oTpx/AuWX0N/2Zy4tvrQvTLC76IzOtW4N5GU1xY1qxk=; b=ikw5VX8zIrshjMA8Yd/3pXOR2ZRXM1jiM8fRpxQIwgUM4YLkrCCa03tWGnhvgRTgUz tEU+dXMcPsH6/IvhXgldYYowjhFauNcXY3U+kLIWGh1QrdQqWJWUK3eGfAXHJtBoPVSH AaZCKMoQVgLQoE16MJ95BEFR3JUK3Nv7vcsLbje90+P8zPWnjesZMw4HyLMLeECGOufI mhH71rErg3Ef7a6uClV0tK85BPa3VYNMxwq7VX8yq81T1BrpW8IaHFoE23MDX3kMKTGK VXSnIdLpYPLxcwNlr76r34eNjeiAkIxzqi5mHc1oCypXDzXEdTmKwxmDmnJ6SO7XHBOl OhBA== MIME-Version: 1.0 Received: by 10.180.87.74 with SMTP id v10mr4096993wiz.21.1352486912663; Fri, 09 Nov 2012 10:48:32 -0800 (PST) Received: by 10.216.54.130 with HTTP; Fri, 9 Nov 2012 10:48:32 -0800 (PST) In-Reply-To: References: Date: Fri, 9 Nov 2012 19:48:32 +0100 Message-ID: From: Axel Nennker To: Michael Jones Content-Type: multipart/alternative; boundary=f46d0444032efe224604ce1465de Cc: "jose@ietf.org" Subject: Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer 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, 09 Nov 2012 18:48:34 -0000 --f46d0444032efe224604ce1465de Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable My suggestion did not change the CMK size. I think it can stay as is. I think that the concat-kdf is hard to implement in Firefox/NSS in Javascript if more than one iteration is needed. For the examples in the spec there is no iteration and so there is no problem. There is a problem when NIST compliance is really required because CEK and CIK should be computed in one go. I could live with a NIST-like concat-KDF. I think openid connect even does not need the optional sender/receiver-ids. Most important is the randomness of the CMK. I don't understand the choices you provided. I think the CMK can stay a defined. // cmk size matters. more bytes give better cik and cek. // cmk size does not change encodedEncryptedKeySegment if alg =3D RSA1_5 or RSA-OAEP cmk =3D generateRandomKey(size, enc); // cik and cek have as many bytes as required by enc (cik,cek) =3D some-kdf(cmk, otherInfoInput); Axel 2012/11/9 Michael Jones > Some working group members, including Axel, James, Matt, and Richard > have expressed dissatisfaction with the use of the Concat KDF to generate > the CEK and CIK when AES CBC is the block encryption algorithm. Reasons > stated are implementation complexity and possible issues with following t= he > letter of the law of the NIST spec. Axel and Richard had both written > suggesting an alternative =96 let the CMK be simply the concatenation of = the > CEK and the CIK values. This is the same approach used in > draft-mcgrew-aead-aes-cbc-hmac-sha2.****** > > ** ** > > I and others had argued against this for size reasons. For A128CBC+HS256 > this would increase the CMK size from 256 bits to 384 bits and for > A256CBC+HS512 this would increase the CMK size from 512 bits to 768 bits. > In the first case, after base64url encoding, one would expect the extra > 128 bits to require about an extra 21 bytes in the JWE. The interesting > fact though, is that when an RSA algorithm is used to encrypt the CMK, th= e > output size is same as the RSA key size =96 in our case, a minimum of 204= 8 > bits. Thus, for any combination of =93alg=94:=94RSA1_5=94 or =93RSA-OAEP= =94 and > =93enc=94:=94A128CBC+HS256=94 or =93A256CBC+HS512=94 *there is no actual = size > difference in the JWE*. (However when =93alg=94:=94A128KW=94 or =93A256K= W=94 are > used, there would be a size increase of about 21 or 43 bytes, respectivel= y.) > **** > > ** ** > > So I=92d like to explicitly ask the working group. Do you want us to:***= * > > ** ** > > (1) Use the concatenation of random CEK and CIK values as the CMK for AES > CBC, resulting in a longer CMK?**** > > (2) Continue to use a KDF to generate the CEK and CIK from a shorter CMK?= * > *** > > ** ** > > Thanks all,**= * > * > > -- Mike**** > > ** ** > > P.S. A KDF will still be required for ECDH-ES key agreement. I=92ll > address James=92 concerns about our use of Concat in a separate note.**** > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --f46d0444032efe224604ce1465de Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable My suggestion did not change the CMK size. I think it can stay as is.
I = think that the concat-kdf is hard to=A0 implement in Firefox/NSS in Javascr= ipt if more than one iteration is needed. For the examples in the spec ther= e is no iteration and so there=A0 is no problem.
There is a problem when NIST compliance is really required because CEK and = CIK should be computed in one go.
I could live with a NIST-like concat-K= DF. I think openid connect even does not need the=A0 optional sender/receiv= er-ids.
Most important is the randomness of the CMK.

I don't understand = the choices you provided. I think the CMK can stay a defined.

// cmk= size matters. more bytes give better cik and cek.
// cmk size does not= change encodedEncryptedKeySegment if alg =3D RSA1_5 or RSA-OAEP
cmk =3D generateRandomKey(size, enc);
// cik and cek have as many byte= s as required by enc
(cik,cek) =3D some-kdf(cmk, otherInfoInput);
Axel



= 2012/11/9 Michael Jones <michael_b_jones@hotmail.com>

Some working group members, including Axel, James, Matt, and Richard have expressed dissatisfaction with the use of the Concat KDF to generate the CEK and CIK when AES CBC is the block encryption algorithm.=A0 Reasons stated are implementation complexity and possible issues with following the letter of the law of the NIST spec.<= span>=A0 Axel and Richard had both written suggesting an alternative =96 let the CMK be simply the concatenation of the CEK and the = CIK values.=A0 This is the same approach used in draft-mcgrew-aead-aes-cbc-hmac-sha2.<= /p>

=A0

I and others had argued against this for size reasons.=A0 For A128CBC+HS256 this would increase the CMK size from 256 bits to 384 bits and for A256CBC+HS512 this would increase the CMK size from 512 bits to 768 bits.=A0 In t= he first case, after base64url encoding, one would expect the extra 128 bits to require about an extra 21 bytes in the J= WE.=A0 The interesting fact though, is that when an RSA algorithm is used to encrypt the CMK, the output size is same as the RS= A key size =96 in our case, a minimum of 2048 bits.=A0 Thus, for any combination of =93alg=94:=94RSA1_5=94 or =93RSA-OAEP= =94 and =93enc=94:=94A128CBC+HS256=94 or =93A256CBC+HS512=94 there is no actual size difference in the JWE.=A0 (However when =93alg=94:=94A128KW=94 or =93A256KW=94 are used, there would be a size= increase of about 21 or 43 bytes, respectively.)

=A0

So I=92d like to explicitly ask the working group.=A0 Do y= ou want us to:

=A0

(1) Use the concatenation of random CEK and CIK values as the CMK for AES CBC, resulting in a longer CMK?=

(2) Continue to use a KDF to generate the CEK and CIK from a shorter CMK?

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

=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.S.=A0 A KDF will still be required for ECDH-ES key agreement.=A0 I=92ll address James=92 concerns about our use of Concat in a separa= te note.


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


--f46d0444032efe224604ce1465de-- From michael_b_jones@hotmail.com Fri Nov 9 10:55: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 057E621F8447 for ; Fri, 9 Nov 2012 10:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmlq70sKZABz for ; Fri, 9 Nov 2012 10:55:46 -0800 (PST) Received: from bay0-omc4-s9.bay0.hotmail.com (bay0-omc4-s9.bay0.hotmail.com [65.54.190.211]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA8321F8445 for ; Fri, 9 Nov 2012 10:55:46 -0800 (PST) Received: from BAY171-W106 ([65.54.190.200]) by bay0-omc4-s9.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Nov 2012 10:55:45 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_0cad2995-e29e-49af-9ff1-3769a7f3d1a0_" X-Originating-IP: [107.17.123.153] From: Michael Jones To: Date: Fri, 9 Nov 2012 10:55:45 -0800 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 09 Nov 2012 18:55:45.0850 (UTC) FILETIME=[D35EC1A0:01CDBEAB] Cc: jose@ietf.org Subject: Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer 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, 09 Nov 2012 18:55:47 -0000 --_0cad2995-e29e-49af-9ff1-3769a7f3d1a0_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable So it sounds to me like you're in favor of (2) Continue to use a KDF to gen= erate the CEK and CIK from a shorter CMK. = --Mike Date: Fri=2C 9 Nov 2012 19:48:32 +0100 From: ignisvulpis@gmail.com To: michael_b_jones@hotmail.com CC: jose@ietf.org Subject: Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer k= ey My suggestion did not change the CMK size. I think it can stay as is. I think that the concat-kdf is hard to implement in Firefox/NSS in Javascr= ipt if more than one iteration is needed. For the examples in the spec ther= e is no iteration and so there is no problem. There is a problem when NIST compliance is really required because CEK and = CIK should be computed in one go. I could live with a NIST-like concat-KDF. I think openid connect even does = not need the optional sender/receiver-ids. Most important is the randomness of the CMK. I don't understand the choices you provided. I think the CMK can stay a def= ined. // cmk size matters. more bytes give better cik and cek.=20 // cmk size does not change encodedEncryptedKeySegment if alg =3D RSA1_5 or= RSA-OAEP cmk =3D generateRandomKey(size=2C enc)=3B=20 // cik and cek have as many bytes as required by enc (cik=2Ccek) =3D some-kdf(cmk=2C otherInfoInput)=3B Axel 2012/11/9 Michael Jones Some working group members=2C including Axel=2C James=2C Matt=2C and Richard have expressed dissatisfaction with the use of the Concat KDF to generate the CEK and CIK when AES CBC is the block encryption algorithm. R= easons stated are implementation complexity and possible issues with following the letter of the law of the NIST spec. = Axel and Richard had both written suggesting an alternative =96 let the CMK be simply the concatenation of the CEK and the = CIK values. This is the same approach used in draft-mcgrew-aead-aes-cbc-hmac-sha2. =20 I and others had argued against this for size reasons. For A128CBC+HS256 this would increase the CMK size from 256 bits to 384 bits and for A256CBC+HS512 this would increase the CMK size from 512 bits to 768 bits. In the first case= =2C after base64url encoding=2C one would expect the extra 128 bits to require about an extra 21 bytes in the J= WE. The interesting fact though=2C is that when an RSA algorithm is used to encrypt the CMK=2C the output size is same as the = RSA key size =96 in our case=2C a minimum of 2048 bits.=20 Thus=2C for any combination of =93alg=94:=94RSA1_5=94 or =93RSA-OAEP=94 and= =93enc=94:=94A128CBC+HS256=94 or =93A256CBC+HS512=94 there is no actual size difference in the JWE. (However when =93alg=94:=94A128KW=94 or =93A256KW=94 are used=2C there would be a si= ze increase of about 21 or 43 bytes=2C respectively.) =20 So I=92d like to explicitly ask the working group. Do you want us to: =20 (1) Use the concatenation of random CEK and CIK values as the CMK for AES CBC=2C resulting in a longer CMK? (2) Continue to use a KDF to generate the CEK and CIK from a shorter CMK? =20 Thanks all=2C -- Mike =20 P.S. A KDF will still be required for ECDH-ES key agreement.=20 I=92ll address James=92 concerns about our use of Concat in a separate note= . =20 _______________________________________________ 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 = --_0cad2995-e29e-49af-9ff1-3769a7f3d1a0_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
So it sounds =3Bto me like you're in favor of (2) Continue to use a KDF to generate the CEK and CIK from a shorter CMK.
 =3B
 =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B --Mike
 =3B<= BR>
Date:= Fri=2C 9 Nov 2012 19:48:32 +0100
From: ignisvulpis@gmail.com
To: mic= hael_b_jones@hotmail.com
CC: jose@ietf.org
Subject: Re: [jose] Choice= for WG: Use a KDF with AES CBC or use a longer key

My suggestion di= d not change the CMK size. I think it can stay as is.
I think that the c= oncat-kdf is hard to =3B implement in Firefox/NSS in Javascript if more= than one iteration is needed. For the examples in the spec there is no ite= ration and so there =3B is no problem.
There is a problem when NIST compliance is really required because CEK and = CIK should be computed in one go.
I could live with a NIST-like concat-K= DF. I think openid connect even does not need the =3B optional sender/r= eceiver-ids.
Most important is the randomness of the CMK.

I don't understand the = choices you provided. I think the CMK can stay a defined.

// cmk siz= e matters. more bytes give better cik and cek.
// cmk size does not cha= nge encodedEncryptedKeySegment if alg =3D RSA1_5 or RSA-OAEP
cmk =3D generateRandomKey(size=2C enc)=3B
// cik and cek have as many = bytes as required by enc
(cik=2Ccek) =3D some-kdf(cmk=2C otherInfoInput)= =3B

Axel



2012/11/9 Michael Jones <=3Bmichael_b_jones@hotmail.com>=3B
Some working group members= =2C including Axel=2C James=2C Matt=2C and Richard have expressed dissatisfaction with the use of the Concat KDF to generate the CEK and CIK when AES CBC is the block encryption algorithm. =3B Reasons stated are implementation complexity and possible issues with following the letter of the law of the NIST spec.<= span> =3B Axel and Richard had both written suggesting an alternative =96 let the CMK be simply the concatenation of the CEK and the = CIK values. =3B This is the same approach used in draft-mcgrew-aead-aes-cbc-hmac-sha2.<= BR>  =3B
<= font size=3D"3" face=3D"Times New Roman"> I and others had argued agai= nst this for size reasons. =3B For A128CBC+HS256 this would increase the CMK size from 256 bits to 384 bits and for A256CBC+HS512 this would increase the CMK size from 512 bits to 768 bits. =3B In the first case=2C after base64url encoding=2C one would expect the extra 128 bits to require about an extra 21 bytes in the J= WE. =3B The interesting fact though=2C is that when an RSA algorithm is used to encrypt the CMK=2C the output size is same as the = RSA key size =96 in our case=2C a minimum of 2048 bits. =3B Thus=2C for any combination of =93alg=94:=94RSA1_5=94 or =93RSA-OAEP= =94 and =93enc=94:=94A128CBC+HS256=94 or =93A256CBC+HS512=94 there is no actual size difference in the JWE. =3B (However when =93alg=94:=94A128KW=94 or =93A256KW=94 are used=2C there would be a si= ze increase of about 21 or 43 bytes=2C respectively.)
 =3B
<= font size=3D"3" face=3D"Times New Roman"> So I=92d like to explicitly = ask the working group. =3B Do you want us to:
 =3B
<= font size=3D"3" face=3D"Times New Roman"> (1) Use the concatenation of= random CEK and CIK values as the CMK for AES CBC=2C resulting in a longer CMK?
(2) Continue to use a KDF to= generate the CEK and CIK from a shorter CMK?
 =3B
<= font size=3D"3" face=3D"Times New Roman">  =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B Thanks all=2C
 =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B -- Mike
 =3B
<= font size=3D"3" face=3D"Times New Roman"> P.S. =3B A = KDF will still be required for ECDH-ES key agreement. =3B I=92ll address James=92 concerns about our use of Concat in a separa= te note.

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



_______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose
= --_0cad2995-e29e-49af-9ff1-3769a7f3d1a0_-- From watsonm@netflix.com Fri Nov 9 13:13: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 C25E621F87E5 for ; Fri, 9 Nov 2012 13:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.265 X-Spam-Level: X-Spam-Status: No, score=-10.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehH8GKEDrdkU for ; Fri, 9 Nov 2012 13:13:09 -0800 (PST) Received: from exout104.netflix.com (exout102.netflix.com [69.53.237.163]) by ietfa.amsl.com (Postfix) with ESMTP id 294B521F875A for ; Fri, 9 Nov 2012 13:13:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=s1024;d=netflix.com; h=from:to:subject:date:message-id:references:content-type:mime-version; bh=cRUETfamrUB8NH7Tx3dtO7dQUaI=; b=TVJqDRNVB92kroePcdAKpRlpI8Ia4TziYQaCsk4Jlgkknb/wqogyzgyyF5NVFw4ttHGwBEZ5 ddatE8dumt/9oLgxRq1DS39gOeERMXCUWJEelBIdP2pbmLkSFwmsv80bhAhqNdvJpc6v9G0I e2L8YWLzDgWw22fyH5BWHrT7+ss= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;d=netflix.com; h=from:to:subject:date:message-id:references:content-type:mime-version; b=gEepk/BtRqI5lVncBtvgaC/BXF3/OMT4cdK42ua3iSVD12HrBnrC1zy78Qcfq9aR9CkMsIfD v5Lq3MAHDDkUdqKM8+bpLZOneLus9ApX//mFtw9Uf0+kPuu3+RepmyRie0UTPfOOJf3cz0vI t6PNXz+edQSyit+s4upsPN5osgU= Received: from EXFE103.corp.netflix.com (10.64.32.103) by exout104.netflix.com (10.64.240.74) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 7 Nov 2012 13:45:21 -0800 Received: from EXMB106.corp.netflix.com ([169.254.6.135]) by exfe103.corp.netflix.com ([10.64.32.103]) with mapi id 14.02.0283.003; Wed, 7 Nov 2012 13:45:28 -0800 From: Mark Watson To: "jose@ietf.org" Thread-Topic: RESEND: JSON Web Key support for private and symmetric keys Thread-Index: AQHNu4w1mKMK4AWfQEKkA5HPNCBJqA== Date: Wed, 7 Nov 2012 21:45:28 +0000 Message-ID: <26E00E85-A8B9-4E5C-87AC-F2087D7E7C58@netflix.com> References: <2D8B50D1-6135-4D3F-B288-8B690F5B9ACA@netflix.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.25.40] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [jose] Fwd: RESEND: JSON Web Key support for private and symmetric keys 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, 09 Nov 2012 21:13:09 -0000 > All, I was hoping to get this to you before your meeting, but get repeate= d delivery failures. One more try ... >=20 > Begin forwarded message: >=20 >> From: Mark Watson >> Subject: JSON Web Key support for private and symmetric keys >> Date: November 5, 2012 11:31:53 AM PST >> To: >>=20 >> All, >>=20 >> First let me introduce myself. I work for Netflix and have been working = on standardization of various components that we need for support of our se= rvice in pure HTML/Javascript. Specifically, the HTML Encrypted Media Exten= sions [1], Media Source Extension [1] and the WebCrypto API [3] in W3C (the= latter to provide us the ability to implement a secure application protoco= l in Javascript). >>=20 >> At last week's W3C meeting in Lyon, two requirements came up that we bel= ieve could be met very well by the extension of JWK to support private and = symmetric keys: >>=20 >> (1) Key wrap/unwrap in the WebCrypto API >>=20 >> The WebCrypto API can manage keys below the API boundary, avoiding the s= haring of keying material with the Javascript environment. This has advanta= ge in certain security models where the JS is less trusted than the UA. >>=20 >> We are working on the specification of key import/export functions inclu= ding import/export of wrapped keys. Both these functions require an explici= t binary representation of the key material to be defined. In the latter ca= se it is required that not only the key itself is protected by the wrapping= operation, but also attributes associated with the key, most importantly t= he "exportable" attribute which determines whether the key can later be exp= orted back to the JS layer. >>=20 >> JWK seems attractive for this purpose since it is straightforward to def= ine additional attributes to be carried with the key. The entire JWK JSON s= tructure would then be wrapped using the key wrapping algorithm (for exampl= e AES Key Wrap). >>=20 >> WebCrypto supports public/private key pairs and symmetric keys. Hence JW= K would need to be extended to support private and symmetric keys to be use= d for this purpose. >>=20 >> (2) Provision of keys to the HTML Encrypted Media Extensions "clear key"= keysystem=20 >>=20 >> The Encrypted Media Extensions provide an API for a script to interact w= ith a "Content Decryption Module" within the UA that provides key exchange = and content decryption capabilities. It is expected that the well-known DRM= vendors will provide "Content Decryption Modules" that are integrated into= browsers and/or that platform APIs for such modules will be available for = browsers to integrate with (e.g. in the case that the capability is present= within the OS on a given platform.) >>=20 >> Additionally, the W3C group itself will define a simple "clearkey" Conte= nt Decryption Module in which the key is passed, in the clear, directly fro= m the JS to the UA. This keysystem has application in certain specific secu= rity models (for example if the user is also the owner of the content) and = for testing. >>=20 >> The keying material is passed to the CDM in the form of an opaque keysys= tem-specific byte array, which for clearkey must specify one or more (symme= tric, likely AES) keys and associated Key Ids. Again, JWK seems an excellen= t simple candidate for this purpose, if it supported symmetric keys. >>=20 >>=20 >> I understand that the JWK specification can be extended by registering t= he necessary additional attributes with IANA on a "Specification Required" = basis. However, it was generally agreed in last week's W3C meetings that it= would be better if this work was done in the IETF JOSE group. >>=20 >> Therefore, the upshot of this email is to ask if there is support in the= IETF JOSE group for adding private and symmetric keys to JWK ? >>=20 >> I understand there is a draft for private keys already existing. I would= be more than happy to propose a draft for symmetric keys if there is inter= est in progressing that here. >>=20 >> Finally, just to avoid any confusion, I should say that whilst the above= approaches had general support in last week's W3C meeting, this is not a f= ormal communication from the W3C (W3C groups tend not to send formal "liais= ons"). >>=20 >> Best regards, >>=20 >> Mark Watson >> Netflix >>=20 >> [1] http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encryp= ted-media.html >> [2] http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-sou= rce.html >> [3] http://www.w3.org/2012/webcrypto/WebCryptoAPI/ >=20 From watsonm@netflix.com Fri Nov 9 13:19: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 3F16921F86D0 for ; Fri, 9 Nov 2012 13:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.265 X-Spam-Level: X-Spam-Status: No, score=-10.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnxy2pd+rx+O for ; Fri, 9 Nov 2012 13:19:43 -0800 (PST) Received: from exout103.netflix.com (exout101.netflix.com [69.53.237.162]) by ietfa.amsl.com (Postfix) with ESMTP id 9B07621F86CE for ; Fri, 9 Nov 2012 13:19:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=s2048;d=netflix.com; h=from:to:subject:date:message-id:content-type:mime-version; bh=5k9eM9UpwGt/bRzNNqz83qxW9UM=; b=dN8DZBqKx489iI+A0HlDBCyPxNEYJ82XeBPsI0f08EqN/1k9tCAlAh+qaFSiW371qSXw1vts Tg7A+dhuttMbTjZlLF6Trh55uqvV32mCWZSmxtOI0bgN+lWon9WTPStxV1g/I//0LqpN4nXW N364gPRGSo6xlnZkRSooOZYZxSl5sUc7FiNcRIFIOWOHiV8K+Lga6VcOa0IR7rt55dE5Elu2 3nAKlWPWCBbfN7OloIAaCUAeh53sNIeE5ymnZeA7IEhiLpYo7bydrTGEKRpEfaD1iE9GWf1m wVhRUp0SgpOjHaz8w0h4h+lfzx7e+2sGKKtbIH/rxs3WEUqaePlcbg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048;d=netflix.com; h=from:to:subject:date:message-id:content-type:mime-version; b=AfSZv+HyqTZ92dAOxj2WzYbBrIAcBJQujFHnHcZ+XVTuGRhqi4GHk76nChf/4kG2LBkbaGH8 q1HX7CajtDTg8yT71Fhpl1+dD2ancrCDy8qCG1zi6SKWKor8YWPi+RIXgwsNaTaEMOM4NzHg ghFqOJxEohiVAaDIWdxjMId7/3UEAl3xj7tYJn2+SilhiktfZAL3aGwwFz81wRMWPdYkvS0U BCe5NOkip774B2zY9m/H1CqfV6nP5qBGrwa1j1HseeRyxmM3eAaoFwJaLTHjhGECvRGlI27n Da9Y7xDNkJ0WcTA/6OXdspA3zcHmVrjJKoZFv0PbCN9vaNqz9uHP0A== Received: from EXFE101.corp.netflix.com (10.64.32.161) by exout103.netflix.com (10.64.240.73) with Microsoft SMTP Server (TLS) id 14.2.298.4; Thu, 8 Nov 2012 13:17:25 -0800 Received: from EXMB106.corp.netflix.com ([169.254.6.135]) by exfe101.corp.netflix.com ([10.64.32.161]) with mapi id 14.02.0283.003; Thu, 8 Nov 2012 13:17:23 -0800 From: Mark Watson To: "jose@ietf.org" Thread-Topic: JSON Web Key support of private and symmetric keys Thread-Index: AQHNvfZxrHCAF4SnVEyTBV5l1FgV6Q== Date: Thu, 8 Nov 2012 21:17:22 +0000 Message-ID: <23AEA030-D4B7-4F12-A2AA-9F7571C2A09A@netflix.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.26.153] Content-Type: text/plain; charset="us-ascii" Content-ID: <0219AC00EDEEF349AB6FB9211B7A844B@netflix.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [jose] JSON Web Key support of private and symmetric keys 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, 09 Nov 2012 21:19:44 -0000 > All, >=20 > First let me introduce myself. I work for Netflix and have been working o= n standardization of various components that we need for support of our ser= vice in pure HTML/Javascript. Specifically, the HTML Encrypted Media Extens= ions [1], Media Source Extension [1] and the WebCrypto API [3] in W3C (the = latter to provide us the ability to implement a secure application protocol= in Javascript). >=20 > At last week's W3C meeting in Lyon, two requirements came up that we beli= eve could be met very well by the extension of JWK to support private and s= ymmetric keys: >=20 > (1) Key wrap/unwrap in the WebCrypto API >=20 > The WebCrypto API can manage keys below the API boundary, avoiding the sh= aring of keying material with the Javascript environment. This has advantag= e in certain security models where the JS is less trusted than the UA. >=20 > We are working on the specification of key import/export functions includ= ing import/export of wrapped keys. Both these functions require an explicit= binary representation of the key material to be defined. In the latter cas= e it is required that not only the key itself is protected by the wrapping = operation, but also attributes associated with the key, most importantly th= e "exportable" attribute which determines whether the key can later be expo= rted back to the JS layer. >=20 > JWK seems attractive for this purpose since it is straightforward to defi= ne additional attributes to be carried with the key. The entire JWK JSON st= ructure would then be wrapped using the key wrapping algorithm (for example= AES Key Wrap). >=20 > WebCrypto supports public/private key pairs and symmetric keys. Hence JWK= would need to be extended to support private and symmetric keys to be used= for this purpose. >=20 > (2) Provision of keys to the HTML Encrypted Media Extensions "clear key" = keysystem=20 >=20 > The Encrypted Media Extensions provide an API for a script to interact wi= th a "Content Decryption Module" within the UA that provides key exchange a= nd content decryption capabilities. It is expected that the well-known DRM = vendors will provide "Content Decryption Modules" that are integrated into = browsers and/or that platform APIs for such modules will be available for b= rowsers to integrate with (e.g. in the case that the capability is present = within the OS on a given platform.) >=20 > Additionally, the W3C group itself will define a simple "clearkey" Conten= t Decryption Module in which the key is passed, in the clear, directly from= the JS to the UA. This keysystem has application in certain specific secur= ity models (for example if the user is also the owner of the content) and f= or testing. >=20 > The keying material is passed to the CDM in the form of an opaque keysyst= em-specific byte array, which for clearkey must specify one or more (symmet= ric, likely AES) keys and associated Key Ids. Again, JWK seems an excellent= simple candidate for this purpose, if it supported symmetric keys. >=20 >=20 > I understand that the JWK specification can be extended by registering th= e necessary additional attributes with IANA on a "Specification Required" b= asis. However, it was generally agreed in last week's W3C meetings that it = would be better if this work was done in the IETF JOSE group. >=20 > Therefore, the upshot of this email is to ask if there is support in the = IETF JOSE group for adding private and symmetric keys to JWK ? >=20 > I understand there is a draft for private keys already existing. I would = be more than happy to propose a draft for symmetric keys if there is intere= st in progressing that here. >=20 > Finally, just to avoid any confusion, I should say that whilst the above = approaches had general support in last week's W3C meeting, this is not a fo= rmal communication from the W3C (W3C groups tend not to send formal "liaiso= ns"). >=20 > Best regards, >=20 > Mark Watson > Netflix >=20 > [1] http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypt= ed-media.html > [2] http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-sour= ce.html > [3] http://www.w3.org/2012/webcrypto/WebCryptoAPI/ From michael_b_jones@hotmail.com Sat Nov 10 16:39: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 443E321F84BF for ; Sat, 10 Nov 2012 16:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eGi5tuysbwR for ; Sat, 10 Nov 2012 16:39:53 -0800 (PST) Received: from bay0-omc1-s13.bay0.hotmail.com (bay0-omc1-s13.bay0.hotmail.com [65.54.190.24]) by ietfa.amsl.com (Postfix) with ESMTP id D685D21F84B7 for ; Sat, 10 Nov 2012 16:39:53 -0800 (PST) Received: from BAY171-W38 ([65.54.190.59]) by bay0-omc1-s13.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 10 Nov 2012 16:39:53 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_931d3626-a896-43cc-a701-9e6581664b43_" X-Originating-IP: [50.47.91.23] From: Michael Jones To: , Date: Sat, 10 Nov 2012 16:39:53 -0800 Importance: Normal In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115001D5886@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B168042967394366880D09@TK5EX14MBXC285.redmond.corp.microsoft.com>, , <4E1F6AAD24975D4BA5B16804296739436688123A@TK5EX14MBXC285.redmond.corp.microsoft.com>, , , <4E1F6AAD24975D4BA5B16804296739436688296F@TK5EX14MBXC285.redmond.corp.microsoft.com>, , <255B9BB34FB7D647A506DC292726F6E114FFB9FC5D@WSMSG3153V.srv.dir.telstra.com>, <255B9BB34FB7D647A506DC292726F6E115001D5886@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 X-OriginalArrivalTime: 11 Nov 2012 00:39:53.0363 (UTC) FILETIME=[10A8F630:01CDBFA5] Subject: Re: [jose] NIST Concat KDF 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, 11 Nov 2012 00:39:55 -0000 --_931d3626-a896-43cc-a701-9e6581664b43_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi James=2C I appreciate that you are reading and providing detailed feedba= ck on the text of the drafts. As I=92m sure you saw=2C many of the changes= made between the -06 and -07 drafts were to address comments that you had = made. I=92ll try to address the details of your comments below in this not= e. By adding the length prefix to the PartyUInfo and PartyVInfo values=2C I= fail to see how the JoBethAnne ambiguity could remain possible. I address= ed that per your earlier note in the -07 drafts by adding the length prefix= . You wrote that the AlgorithmID doesn=92t have a length prefix. That=92s = true. The Concat definition allows fields to not contain a length prefix w= hen they are fixed length=2C as AlgorithmID is in this case. Likewise=2C t= here=92s no need for a length prefix for SuppPubInfo or SuppPrivInfo=2C as = they are also fixed length (0) in our use for key agreement. Similarly=2C = the use of SuppPrivInfo by A128CBC+HS256 and A256CBC+HS512 effectively make= s them fixed length strings=2C as only two values are possible=2C =93Encryp= tion=94 and =93Integrity=94=2C with no confusion possible between them. Wh= at=92s more=2C they occur at the end of the concatenation. You wrote =93Can= =92t the spec just do what NIST 800-56A says if it really wants to use it?= =94. I suspect that underlying this comment is the actual difference you h= ave with the specs=92 use of Concat. It=92s not a goal of JWA to make it p= ossible to use every feature of Concat. (Concat isn=92t an end unto itself= .) Hence the spec not needing to use SuppPrivInfo=2C etc. The actual goal= is generating two high-quality keys from the CMK. I believe that this goa= l has already been attained. As for whether we use Concat twice to generate= two keys with different inputs and then discard the random value or whethe= r we use Concat once to generate a long enough output to chop it into two k= eys=2C that seems like a distinction without a difference. I reviewed this= decision with Jim Schaad a while back=2C among others=2C and they concurre= d. The precedent for this is the TLS PRF KDF [RFC5246]=2C which generates = keys in this manner. Unless there=92s an actual security argument that thi= s (widely used) practice is demonstrably unsafe=2C there doesn=92t seem to = be a reason to change. As for requiring PartyUInfo and PartyVInfo values fo= r key agreement=2C the actual need for these parameters is context-dependen= t. I=92m perfectly fine putting a statement in our specs that NIST=92s spe= cification for the KDF requires these values to be present and checked=2C i= f that would make you happier. That way=2C per my earlier conversation wit= h Jim about this topic=2C applications of JWE can choose to use the KDF in = a fully NIST-compliant fashion=2C if appropriate. But for the same reasons= that the TLS PRF KDF doesn=92t need these parameters=2C in practice they= =92re not needed in some JWA contexts either. I=92m trying to have us not l= ose sight of the fact that a core goal of the JOSE specs is to create specs= that are simple enough that they will actually be implemented and used. A= nd yes=2C of course they need to be secure. I believe we=92re already ther= e with the current specs. Whereas=2C for instance=2C adding optional SuppP= rivInfo parameters just because NIST says that you *can* use them would see= m to be adding implementation complexity with no actual security benefit. B= est wishes=2C -- Mike From: James.H.Manger@team.telstra.com To: jose@ietf.org Date: Thu=2C 8 Nov 2012 12:18:58 +1100 Subject: Re: [jose] NIST Concat KDF JOSE is inching closer to properly using NIST 800-56A Concat key derivation= function (KDF)=2C but there is still a sizeable gap. The latest changes (d= raft-ietf-jose-json-web-algorithms-07) add length prefixes to PartyUInfo an= d PartyVInfo.However=2C the AlgorithmID field doesn=92t have a length prefi= x=3B nor does SuppPubInfo or SuppPrivInfo.The remaining ambiguity in the KD= F input is less practical to exploit than the =93JoBethAnne=94 example that= was previously possible=2C but theoretical ambiguity remains. Can=92t the = spec just do what NIST 800-56A says if it really wants to use it? Defining = =93apu=94 and =93apv=94 to hold PartyUInfo and PartyVInfo values is only pr= etending to support NIST 800-56A. NIST 800-56A says they need to be mandato= ry (non-null) and they need to be explicitly checked by the recipient =97 n= ot optional and blindly copied from apu/apv fields to the KDF input. The Al= gorithmID field is specified as indicating =93how the derived keying materi= al will be parsed and for which algorithm(s) the derived secret keying mate= rial will be used=94. JOSE violates this. The same AlgorithmID value (eg = =93<00000100>A128CBC+HS256=94) is sometimes used to derive a 128-bit AES ke= y=2C and at other times used to derive a 256-bit HMAC key. The JOSE method = is almost certainly =93safe=94 as it uses different SuppPubInfo values (=93= Encryption=94 and =93Integrity=94) in these cases =97 but it is not NIST 80= 0-56A Concat. A NIST 800-56A Concat approach would run the KDF once and get= out a 384-bit secret that is split into the required 128-bit and 256-bit k= eys. --James Manger From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.o= rg] On Behalf Of Manger=2C James H Sent: Wednesday=2C 31 October 2012 12:13 AM To: jose@ietf.org Subject: [jose] NIST Concat KDF JOSE still doesn=92t use the NIST 800-56A C= oncat Key DF as that specification requires. JWA allows PartyUInfo and/or P= artyVInfo to be empty (if apu/apv/epu/epv are absent). That doesn=92t compl= y with 800-56A that says =93at a minimum=2C PartyUInfo shall include IDu=2C= the identity of party U=94. 800-56A also says =93it is required that ident= ifier for both parties to a key agreement transaction be included in the Ot= herInfo that is input to the key derivation function=94. 800-56A requires t= hat the concatenation AlgorithmID || PartyUInfo || PartyVInfo be unambiguou= s. It allows two ways to achieve this: pre-define fixed sizes for component= s=3B or prefix each component with its length. JWA does neither of these. C= onsider two JOSE messages (ignoring some irrelevant base64url encoding): {= ...=2C "apu":"JoBeth"=2C "apv":"Anne" } and { ...=2C "apu":"Jo"=2C "apv":= "BethAnne" }JWA implies both use the string "JoBethAnne" in the KDF despite= the messages being between different parties=2C which defeats this part of= the Concat KDF design. JWA explicitly puts the key length and "alg" value = into the AlgorithmID field that the KDF uses. However=2C the "alg" value al= one must imply one specific key length for the rest of the JOSE processing = to work so including the key length explicitly is redundant. 800-56A is des= igned to derive integrity and encryption keys together. For instance=2C it = says =93AlgorithmID might indicate that bits 1-80 are to be used as an 80-b= it HMAC key and that bits 81-208 are to be used as a 128-bit AES key=94. JW= A does not do this. JWA runs the KDF twice to derive integrity and encrypti= on keys separately. If we want to use NIST 800-56A Concat KDF then JWA/JWE = needs lots of fixes.If we want a simpler KDF then JWA shouldn=92t pretend i= t is the NIST 800-56A Concat KDF. --James Manger _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose = --_931d3626-a896-43cc-a701-9e6581664b43_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi James=2C
 =3B
I appreciate that you are reading and providing = detailed feedback on the text of the drafts. =3B As I=92m sure you saw= =2C many of the changes made between the -06 and -07 drafts were to address= comments that you had made. =3B I=92ll try to address the details of y= our comments below in this note.
 =3B
By adding the length prefix= to the PartyUInfo and PartyVInfo values=2C I fail to see how the JoBethAnn= e ambiguity could remain possible. =3B I addressed that per your earlie= r note in the -07 drafts by adding the length prefix.
 =3B
You wr= ote that the AlgorithmID doesn=92t have a length prefix. =3B That=92s t= rue. =3B The Concat definition allows fields to not contain a length pr= efix when they are fixed length=2C as AlgorithmID is in this case. =3B = Likewise=2C there=92s no need for a length prefix for SuppPubInfo or SuppPr= ivInfo=2C as they are also fixed length (0) in our use for key agreement.&n= bsp=3B Similarly=2C the use of SuppPrivInfo by A128CBC+HS256 and A256CBC+HS= 512 effectively makes them fixed length strings=2C as only two values are p= ossible=2C =93Encryption=94 and =93Integrity=94=2C with no confusion possib= le between them. =3B What=92s more=2C =3Bthey occur at the end of t= he concatenation.
 =3B
You wrote =93Can=92t the spec just do what= NIST 800-56A says if it really wants to use it?=94. =3B I suspect that= underlying this comment is the actual difference you have with the specs= =92 use of Concat. =3B It=92s not a goal of JWA to make it possible to = use every feature of Concat. =3B (Concat isn=92t an end unto itself.)&n= bsp=3B Hence the spec not needing to use SuppPrivInfo=2C etc. =3B The a= ctual goal is generating two high-quality keys from the CMK. =3B I beli= eve that this goal has already been attained.
 =3B
As for whether= we use Concat twice to generate two keys with different inputs and then di= scard the random value or whether we use Concat once to generate a long eno= ugh output to chop it into two keys=2C that seems like a distinction withou= t a difference. =3B I reviewed this decision with Jim Schaad a while ba= ck=2C among others=2C and they concurred. =3B The precedent for this is= the TLS PRF KDF [RFC5246]=2C which generates keys in this manner. =3B = Unless there=92s an actual security argument that this (widely used) practi= ce is demonstrably unsafe=2C there doesn=92t seem to be a reason to change.=
 =3B
As for requiring PartyUInfo and PartyVInfo values for key a= greement=2C the actual need for these parameters is context-dependent. = =3B I=92m perfectly fine putting a statement in our specs =3Bthat NIST= =92s specification for the KDF requires these values to be present and chec= ked=2C if that would make you happier. =3B That way=2C per my earlier c= onversation with Jim about this topic=2C applications of JWE can choose to = use the KDF in a fully NIST-compliant fashion=2C if appropriate. =3B Bu= t for the same reasons that the TLS PRF KDF doesn=92t need these parameters= =2C in practice they=92re not needed in some JWA contexts either.
 = =3B
I=92m trying to have us not lose sight of the fact that a core goal = of the JOSE specs is to create specs that are simple enough that they will = actually be implemented and used. =3B And yes=2C of course they need to= be secure. =3B I believe we=92re already there with the current specs.=  =3B Whereas=2C for instance=2C adding optional SuppPrivInfo parameters= just because NIST says that you *can* use them would seem to be adding imp= lementation complexity with no actual security benefit.
 =3B
Best= wishes=2C
-- Mike
 =3B
<= /div>
From: James.H.Manger@team.telstra.com
To: j= ose@ietf.org
Date: Thu=2C 8 Nov 2012 12:18:58 +1100
Subject: Re: [jos= e] NIST Concat KDF

JOSE is inching closer to properly using NIST 800-= 56A Concat key derivation function (KDF)=2C but there is still a sizeable g= ap.

&n= bsp=3B

= The latest changes (draft-ietf-jose-json-web-algorithms-07) add length pref= ixes to PartyUInfo and PartyVInfo.

However=2C the AlgorithmID field doesn=92t have= a length prefix=3B nor does SuppPubInfo or SuppPrivInfo.

The remaining ambiguity = in the KDF input is less practical to exploit than the =93JoBethAnne=94 exa= mple that was previously possible=2C but theoretical ambiguity remains. Can= =92t the spec just do what NIST 800-56A says if it really wants to use it?<= /span>

 = =3B

De= fining =93apu=94 and =93apv=94 to hold PartyUInfo and PartyVInfo values is = only pretending to support NIST 800-56A. NIST 800-56A says they need to be = mandatory (non-null) and they need to be explicitly checked by the recipien= t =97 not optional and blindly copied from apu/apv fields to the KDF input.=

 = =3B

Th= e AlgorithmID field is specified as indicating =93how the derived keying ma= terial will be parsed and for which algorithm(s) the derived secret keying = material will be used=94. JOSE violates this. The same AlgorithmID value (e= g =93<=3B00000100>=3BA128CBC+HS256=94) is sometimes used to derive a 12= 8-bit AES key=2C and at other times used to derive a 256-bit HMAC key. The = JOSE method is almost certainly =93safe=94 as it uses different SuppPubInfo= values (=93Encryption=94 and =93Integrity=94) in these cases =97 but it is= not NIST 800-56A Concat. A NIST 800-56A Concat approach would run the KDF = once and get out a 384-bit secret that is split into the required 128-bit a= nd 256-bit keys.

 =3B

--

James Manger

 =3B

From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Manger=2C James H
Sent: Wednesd= ay=2C 31 October 2012 12:13 AM
To: jose@ietf.org
Subject: [jose] NIST Concat KDF

&= nbsp=3B

JOSE s= till doesn=92t use the NIST 800-56A Concat Key DF as that specification req= uires.

=  =3B

JWA allows PartyUInfo and/or PartyVInfo to be empty (if apu/apv/epu/ep= v are absent). That doesn=92t comply with 800-56A that says =93at a minimum= =2C PartyUInfo shall include IDu=2C the identity of party U=94. 800-56A als= o says =93it is required that identifier for both parties to a key agreemen= t transaction be included in the OtherInfo that is input to the key derivat= ion function=94.

 =3B

800-56A requires that the concatenation AlgorithmID || PartyUIn= fo || PartyVInfo be unambiguous. It allows two ways to achieve this: pre-de= fine fixed sizes for components=3B or prefix each component with its length= . JWA does neither of these.

 =3B

Consider two JOSE messages (ignoring some irrelev= ant base64url encoding):

 =3B { ...=2C "apu":"JoBeth"=2C "apv":"Anne" } and

 =3B = { ...=2C "apu":"Jo"=2C "apv":"BethAnne" }

JWA implies both use the string "JoBethA= nne" in the KDF despite the messages being between different parties=2C whi= ch defeats this part of the Concat KDF design.

 =3B

JWA explicitly puts the key lengt= h and "alg" value into the AlgorithmID field that the KDF uses. However=2C = the "alg" value alone must imply one specific key length for the rest of th= e JOSE processing to work so including the key length explicitly is redunda= nt.

&n= bsp=3B

= 800-56A is designed to derive integrity and encryption keys together. For i= nstance=2C it says =93AlgorithmID might indicate that bits 1-80 are to be u= sed as an 80-bit HMAC key and that bits 81-208 are to be used as a 128-bit = AES key=94. JWA does not do this. JWA runs the KDF twice to derive integrit= y and encryption keys separately.

 =3B

If we want to use NIST 800-56A Concat KDF then= JWA/JWE needs lots of fixes.

If we want a simpler KDF then JWA shouldn=92t prete= nd it is the NIST 800-56A Concat KDF.

<= span style=3D'color: rgb(31=2C 73=2C 125)=3B font-family: "Calibri"=2C"sans= -serif"=3B font-size: 11pt=3B'> =3B

--

James Manger


_______= ________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose
= --_931d3626-a896-43cc-a701-9e6581664b43_-- From James.H.Manger@team.telstra.com Sun Nov 11 14:23: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 C4F3221F84CD for ; Sun, 11 Nov 2012 14:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.641 X-Spam-Level: X-Spam-Status: No, score=-0.641 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yIN2KfsW0X7 for ; Sun, 11 Nov 2012 14:23:59 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7FF21F84B1 for ; Sun, 11 Nov 2012 14:23:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,759,1344175200"; d="scan'208";a="102771061" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipobvi.tcif.telstra.com.au with ESMTP; 12 Nov 2012 09:23:39 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6893"; a="98255838" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipccvi.tcif.telstra.com.au with ESMTP; 12 Nov 2012 09:23:39 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Mon, 12 Nov 2012 09:23:38 +1100 From: "Manger, James H" To: Michael Jones , "jose@ietf.org" Date: Mon, 12 Nov 2012 09:23:37 +1100 Thread-Topic: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key Thread-Index: Ac2+pPHgsjSnsnodRg+O2DPcJWDdJABteA1g Message-ID: <255B9BB34FB7D647A506DC292726F6E11500331CA9@WSMSG3153V.srv.dir.telstra.com> References: 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] Choice for WG: Use a KDF with AES CBC or use a longer 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: Sun, 11 Nov 2012 22:23:59 -0000 PiBTbyBJ4oCZZCBsaWtlIHRvIGV4cGxpY2l0bHkgYXNrIHRoZSB3b3JraW5nIGdyb3VwLiAgRG8g eW91IHdhbnQgdXMgdG86DQo+DQo+ICgxKSBVc2UgdGhlIGNvbmNhdGVuYXRpb24gb2YgcmFuZG9t IENFSyBhbmQgQ0lLIHZhbHVlcyBhcyB0aGUgQ01LIGZvciBBRVMgQ0JDLCByZXN1bHRpbmcgaW4g YSBsb25nZXIgQ01LPw0KPiAoMikgQ29udGludWUgdG8gdXNlIGEgS0RGIHRvIGdlbmVyYXRlIHRo ZSBDRUsgYW5kIENJSyBmcm9tIGEgc2hvcnRlciBDTUs/DQoNCg0KMS4gVXNlIGRyYWZ0LW1jZ3Jl dy1hZWFkLWFlcy1jYmMtaG1hYy1zaGEyDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From James.H.Manger@team.telstra.com Sun Nov 11 15:45: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 DDE3A21F851B for ; Sun, 11 Nov 2012 15:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.67 X-Spam-Level: X-Spam-Status: No, score=-0.67 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XA2x-7R+N7rp for ; Sun, 11 Nov 2012 15:45:36 -0800 (PST) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id BC2AA21F8518 for ; Sun, 11 Nov 2012 15:45:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,759,1344175200"; d="scan'208";a="100761198" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 12 Nov 2012 10:45:33 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6893"; a="46794207" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcani.tcif.telstra.com.au with ESMTP; 12 Nov 2012 10:45:33 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Mon, 12 Nov 2012 10:45:33 +1100 From: "Manger, James H" To: Michael Jones , "jose@ietf.org" Date: Mon, 12 Nov 2012 10:45:32 +1100 Thread-Topic: [jose] NIST Concat KDF Thread-Index: Ac2/pRTcOReJZixRTNCHjFolIPrt5gAtjmfA Message-ID: <255B9BB34FB7D647A506DC292726F6E11500331F3B@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B168042967394366880D09@TK5EX14MBXC285.redmond.corp.microsoft.com>, , <4E1F6AAD24975D4BA5B16804296739436688123A@TK5EX14MBXC285.redmond.corp.microsoft.com>, , , <4E1F6AAD24975D4BA5B16804296739436688296F@TK5EX14MBXC285.redmond.corp.microsoft.com>, , <255B9BB34FB7D647A506DC292726F6E114FFB9FC5D@WSMSG3153V.srv.dir.telstra.com>, <255B9BB34FB7D647A506DC292726F6E115001D5886@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] NIST Concat KDF 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, 11 Nov 2012 23:45:37 -0000 TWlrZSwNCg0KPiBCeSBhZGRpbmcgdGhlIGxlbmd0aCBwcmVmaXggdG8gdGhlIFBhcnR5VUluZm8g YW5kIFBhcnR5VkluZm8gdmFsdWVzLCBJIGZhaWwgdG8gc2VlIGhvdyB0aGUgSm9CZXRoQW5uZSBh bWJpZ3VpdHkgY291bGQgcmVtYWluIHBvc3NpYmxlLiAgSSBhZGRyZXNzZWQgdGhhdCBwZXIgeW91 ciBlYXJsaWVyIG5vdGUgaW4gdGhlIC0wNyBkcmFmdHMgYnkgYWRkaW5nIHRoZSBsZW5ndGggcHJl Zml4Lg0KDQpUaGUgSm9CZXRoL0FubmUgdnMgSm8vQmV0aEFubmUgYW1iaWd1aXR5IGlzIHNvbHZl ZC4gQW4gQWxnb3JpdGhtSUQvUGFydHlVSW5mbyBhbWJpZ3VpdHkgcmVtYWlucy4gSXQgZmVlbHMg bW9yZSB0aGVvcmV0aWNhbCwgYnV0IGl0IHNpbXBseSBkb2VzIG5vdCBuZWVkIHRvIGV4aXN0LiBU aGUgZm9sbG93aW5nIDIgSk9TRSBtZXNzYWdlcyBwcm9kdWNlIHRoZSBzYW1lIEtERiBpbnB1dC4g VGhleSBzaG91bGRuJ3QuIEl0IGlzIHRoZSBzb3J0IG9mIHNpdHVhdGlvbiBOSVNUIENvbmNhdCBL REYgaXMgc3BlY2lmaWNhbGx5IGRlc2lnbmVkIHRvIGF2b2lkLg0KDQogIHsiYWxnIjoiQTEyOENC QytIUzI1Nlx1MDAwMFx1MDAwMFx1MDAwMFx1MDAwN1giLCAiZXB1IjoiSm8iLCAiZXB2IjoiQmV0 aEFubmUifQ0KDQogIHsiYWxnIjoiQTEyOENCQytIUzI1NiIsICJlcHUiOiJYXHUwMDAwXHUwMDAw XHUwMDAwXHUwMDAySm8iLCAiZXB2IjoiQmV0aEFubmUifSAgDQoNCg0KPiBZb3Ugd3JvdGUgdGhh dCB0aGUgQWxnb3JpdGhtSUQgZG9lc27igJl0IGhhdmUgYSBsZW5ndGggcHJlZml4LiAgVGhhdOKA mXMgdHJ1ZS4gIFRoZSBDb25jYXQgZGVmaW5pdGlvbiBhbGxvd3MgZmllbGRzIHRvIG5vdCBjb250 YWluIGEgbGVuZ3RoIHByZWZpeCB3aGVuIHRoZXkgYXJlIGZpeGVkIGxlbmd0aCwgYXMgQWxnb3Jp dGhtSUQgaXMgaW4gdGhpcyBjYXNlLg0KDQpBbGdvcml0aG1JRCBpbmNsdWRlcyB0aGUgdmFsdWUg b2YgdGhlICJlbmMiIGZpZWxkLCB3aGljaCBpcyBoYXJkbHkgZml4ZWQgbGVuZ3RoLg0KDQoNCg0K PiBZb3Ugd3JvdGUg4oCcQ2Fu4oCZdCB0aGUgc3BlYyBqdXN0IGRvIHdoYXQgTklTVCA4MDAtNTZB IHNheXMgaWYgaXQgcmVhbGx5IHdhbnRzIHRvIHVzZSBpdD/igJ0uICBJIHN1c3BlY3QgdGhhdCB1 bmRlcmx5aW5nIHRoaXMgY29tbWVudCBpcyB0aGUgYWN0dWFsIGRpZmZlcmVuY2UgeW91IGhhdmUg d2l0aCB0aGUgc3BlY3PigJkgdXNlIG9mIENvbmNhdC4gIEl04oCZcyBub3QgYSBnb2FsIG9mIEpX QSB0byBtYWtlIGl0IHBvc3NpYmxlIHRvIHVzZSBldmVyeSBmZWF0dXJlIG9mIENvbmNhdC4gKENv bmNhdCBpc27igJl0IGFuIGVuZCB1bnRvIGl0c2VsZi4pICBIZW5jZSB0aGUgc3BlYyBub3QgbmVl ZGluZyB0byB1c2UgU3VwcFByaXZJbmZvLCBldGMuDQoNCkkgaGF2ZSBubyBkZXNpcmUgdG8gdXNl IFN1cHBQcml2SW5mby4gSSBhbSBjb21wbGV0ZWx5IGZpbmUgd2l0aCBKT1NFIHNheWluZyBpdCBt dXN0IGJlIG9taXR0ZWQuIEkgZG9uJ3QgcmVhbGx5IGV2ZW4gd2FudCB0byB1c2UgUGFydHlVSW5m byBhbmQgUGFydHlWSW5mby4gTklTVCA4MDAtNTZBIENvbmNhdCBLREYsIGhvd2V2ZXIsIGlzIGRl c2lnbmVkIHRvIGVuc3VyZSB0aGUgc2FtZSBrZXkgY2Fubm90IGJlIGRlcml2ZWQgaWYgdGhlIGFs Z29yaXRobSwgdGhlIGlkIG9mIGVpdGhlciBwYXJ0eSwgb3IgYW55IG90aGVyIGltcG9ydGFudCBk ZXRhaWwgb2YgdGhlIGNvbnRleHQgaXMgZGlmZmVyZW50LiBJZiBKT1NFIHNheXMgaXQgdXNlcyBD b25jYXQgaXQgbmVlZHMgdG8gZGVsaXZlciB0aGVzZSBwcm9wZXJ0aWVzLiBJZiBKT1NFIGRvZXMg bm90IG5lZWQgdGhlc2UgcHJvcGVydGllcyB0aGVuIGl0IHNob3VsZG4ndCBmYWxzZWx5IGltcGx5 IGl0IGFjaGlldmVzIHRoZW0gYnkgc2F5aW5nIGl0IHVzZXMgQ29uY2F0Lg0KDQoNCj4gVGhlIGFj dHVhbCBnb2FsIGlzIGdlbmVyYXRpbmcgdHdvIGhpZ2gtcXVhbGl0eSBrZXlzIGZyb20gdGhlIENN Sy4NCg0KR3JlYXQuIFRoZW4gZHJvcCB0aGUgYXB1L2Fwdi9lcHUvZXB2IHN0dWZmIGFuZCBkb24n dCBjYWxsIGl0IE5JU1QgQ29uY2F0Lg0KDQoNCj4gQXMgZm9yIHdoZXRoZXIgd2UgdXNlIENvbmNh dCB0d2ljZSB0byBnZW5lcmF0ZSB0d28ga2V5cyB3aXRoIGRpZmZlcmVudCBpbnB1dHMgYW5kIHRo ZW4gZGlzY2FyZCB0aGUgcmFuZG9tIHZhbHVlIG9yIHdoZXRoZXIgd2UgdXNlIENvbmNhdCBvbmNl IHRvIGdlbmVyYXRlIGEgbG9uZyBlbm91Z2ggb3V0cHV0IHRvIGNob3AgaXQgaW50byB0d28ga2V5 cywgdGhhdCBzZWVtcyBsaWtlIGEgZGlzdGluY3Rpb24gd2l0aG91dCBhIGRpZmZlcmVuY2UuDQoN Ckl0IHByb2JhYmx5IGlzIGEgZGlzdGluY3Rpb24gd2l0aG91dCBhIGRpZmZlcmVuY2UuIFNvIHdo eSBkbyB5b3UgYm90aGVyIG1ha2luZyB0aGUgZGlzdGluY3Rpb24gZnJvbSB0aGUgTklTVCBDb25j YXQgS0RGIHRoYXQgSk9TRSBzYXlzIGl0IHVzZXM/IFRoYXQganVzdCB1bm5lY2Vzc2FyaWx5IHJh aXNlcyBhIHNoYWRvdyBvZiBkb3VidC4NCg0KDQo+IEkgcmV2aWV3ZWQgdGhpcyBkZWNpc2lvbiB3 aXRoIEppbSBTY2hhYWQgYSB3aGlsZSBiYWNrLCBhbW9uZyBvdGhlcnMsIGFuZCB0aGV5IGNvbmN1 cnJlZC4gIFRoZSBwcmVjZWRlbnQgZm9yIHRoaXMgaXMgdGhlIFRMUyBQUkYgS0RGIFtSRkM1MjQ2 XSwgd2hpY2ggZ2VuZXJhdGVzIGtleXMgaW4gdGhpcyBtYW5uZXIuDQoNClRoZW4gdXNlIHRoZSBU TFMgMS4yIFBSRiwgaW5zdGVhZCBvZiBOSVNUIENvbmNhdC4NCg0KDQo+IFVubGVzcyB0aGVyZeKA mXMgYW4gYWN0dWFsIHNlY3VyaXR5IGFyZ3VtZW50IHRoYXQgdGhpcyAod2lkZWx5IHVzZWQpIHBy YWN0aWNlIGlzIGRlbW9uc3RyYWJseSB1bnNhZmUsIHRoZXJlIGRvZXNu4oCZdCBzZWVtIHRvIGJl IGEgcmVhc29uIHRvIGNoYW5nZS4NCg0KSk9TRSBzYXlzIGl0IHVzZXMgTklTVCBDb25jYXQ7IGl0 IGRlbW9uc3RyYWJseSBkb2Vzbid0IG1lZXRzIENvbmNhdOKAmXMgc2VjdXJpdHkgZGVzaWduIChl ZyBKT1NFIGNhbiBkZXJpdmUgdGhlIHNhbWUga2V5IGZvciBkaWZmIHVzZXIgaWRzIGFzIEpPU0Ug Y2FuIG9taXQgdGhlIGlkcyBmcm9tIHRoZSBjYWxjdWxhdGlvbik7IHNvIHRoZXJlIGlzIGEgcmVh c29uIHRvIGNoYW5nZS4NCg0KDQo+IEnigJltIHRyeWluZyB0byBoYXZlIHVzIG5vdCBsb3NlIHNp Z2h0IG9mIHRoZSBmYWN0IHRoYXQgYSBjb3JlIGdvYWwgb2YgdGhlIEpPU0Ugc3BlY3MgaXMgdG8g Y3JlYXRlIHNwZWNzIHRoYXQgYXJlIHNpbXBsZSBlbm91Z2ggdGhhdCB0aGV5IHdpbGwgYWN0dWFs bHkgYmUgaW1wbGVtZW50ZWQgYW5kIHVzZWQuDQoNClNvdW5kcyBsaWtlIGEgZ29vZCByZWFzb24g bm90IHRvIHBpY2sgTklTVCBDb25jYXQsIHdoaWNoIGNob29zZXMgbW9yZSBjb21wbGV4aXR5IGZv ciBzZWN1cml0eSBpbiBzb21lIGNvcm5lciBjYXNlcy4NCg0KLS0NCkphbWVzIE1hbmdlcg0K From ve7jtb@ve7jtb.com Sun Nov 11 16:27: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 1933421F84DA for ; Sun, 11 Nov 2012 16:27:28 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsmgAaV+zRY1 for ; Sun, 11 Nov 2012 16:27:27 -0800 (PST) Received: from mail-yh0-f44.google.com (mail-yh0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9304021F84D8 for ; Sun, 11 Nov 2012 16:27:27 -0800 (PST) Received: by mail-yh0-f44.google.com with SMTP id 56so1150919yhq.31 for ; Sun, 11 Nov 2012 16:27:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=cN+i9twGhQT8d7Tv+xqCjnU13rjSh9vThMyFbpBygsw=; b=Umx+cPBKHXb5c84kiM5dIo9kL5QMRqOYnl00QFerLcHx33sgTVRYJ1ufoy8s57c2FQ xU5mZBnBgbqimuiedOryBj1i/iRNSUNzlrag6YI6vT0hnTbCeteCe7wNlb06tHy5a0iF zWBJNBAisMCgnYsCkJrkR7Wst4vm5QSt5tpK8T3MNjhjTFDnip2m4vY1XmsTFlj8IztD dat/jPQ8xCnR8hM0QmqUpFQqUbftrAK93Kmy0Mh197RgNfNiMCT0TBB08rzQaaD7ZMDt HVjpB33eEULPGcy4EZxWbl+ilgDaId5xTwKHjpojh8XBKMph1QrCxoGWU1iXtncUAYPJ yYTA== Received: by 10.236.128.141 with SMTP id f13mr18222524yhi.52.1352680047181; Sun, 11 Nov 2012 16:27:27 -0800 (PST) Received: from [192.168.1.211] (190-20-39-87.baf.movistar.cl. [190.20.39.87]) by mx.google.com with ESMTPS id n20sm4682655anl.19.2012.11.11.16.27.23 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Nov 2012 16:27:26 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11500331CA9@WSMSG3153V.srv.dir.telstra.com> Date: Sun, 11 Nov 2012 21:27:16 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8D4A85A2-07DD-4E34-89D9-1640F5ED9BEA@ve7jtb.com> References: <255B9BB34FB7D647A506DC292726F6E11500331CA9@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnT3cib58HFEam7HRvDagTOW0pmX96FyfN+r7sDSCgiQFSfAqIUaTM7fm7XxgFXogCiclSU Cc: Michael Jones , "jose@ietf.org" Subject: Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer 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: Mon, 12 Nov 2012 00:27:28 -0000 I think that is largely the effect of making the proposed change. The = remaining question if we do it is if we want to take a dependency on = draft-mcgrew-aead-aes-cbc-hmac-sha2 or incorporate it. If it is a ID taking a dependency on it is problematic proceduraly. I am personally in favour of sending the concatenation of the two values = rather than use a KDF. I think it will reduce interoperability issues. What we call it needs to be determined. John B. On 2012-11-11, at 7:23 PM, "Manger, James H" = wrote: >> So I=92d like to explicitly ask the working group. Do you want us = to: >>=20 >> (1) Use the concatenation of random CEK and CIK values as the CMK for = AES CBC, resulting in a longer CMK? >> (2) Continue to use a KDF to generate the CEK and CIK from a shorter = CMK? >=20 >=20 > 1. Use draft-mcgrew-aead-aes-cbc-hmac-sha2 >=20 > -- > James Manger > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From James.H.Manger@team.telstra.com Sun Nov 11 17:21: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 B2AA021F84DF for ; Sun, 11 Nov 2012 17:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgu1MDhgUKL2 for ; Sun, 11 Nov 2012 17:21:11 -0800 (PST) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 008C521F84D8 for ; Sun, 11 Nov 2012 17:21:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,759,1344175200"; d="scan'208";a="108347642" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipoani.tcif.telstra.com.au with ESMTP; 12 Nov 2012 12:21:10 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6893"; a="92635935" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcdni.tcif.telstra.com.au with ESMTP; 12 Nov 2012 12:21:10 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Mon, 12 Nov 2012 12:21:09 +1100 From: "Manger, James H" To: John Bradley , "jose@ietf.org" Date: Mon, 12 Nov 2012 12:21:08 +1100 Thread-Topic: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key Thread-Index: Ac3AbIAIee/c0fapQuSCPcpknJsJHwABGWdA Message-ID: <255B9BB34FB7D647A506DC292726F6E11500332235@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11500331CA9@WSMSG3153V.srv.dir.telstra.com> <8D4A85A2-07DD-4E34-89D9-1640F5ED9BEA@ve7jtb.com> In-Reply-To: <8D4A85A2-07DD-4E34-89D9-1640F5ED9BEA@ve7jtb.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] Choice for WG: Use a KDF with AES CBC or use a longer 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: Mon, 12 Nov 2012 01:21:12 -0000 PiA+IDEuIFVzZSBkcmFmdC1tY2dyZXctYWVhZC1hZXMtY2JjLWhtYWMtc2hhMg0KDQo+IEkgdGhp bmsgdGhhdCBpcyBsYXJnZWx5IHRoZSBlZmZlY3Qgb2YgbWFraW5nIHRoZSBwcm9wb3NlZCBjaGFu Z2UuICBUaGUNCj4gcmVtYWluaW5nIHF1ZXN0aW9uIGlmIHdlIGRvIGl0IGlzIGlmIHdlIHdhbnQg dG8gdGFrZSBhIGRlcGVuZGVuY3kgb24NCj4gZHJhZnQtbWNncmV3LWFlYWQtYWVzLWNiYy1obWFj LXNoYTIgb3IgaW5jb3Jwb3JhdGUgaXQuDQo+IA0KPiBJZiBpdCBpcyBhIElEIHRha2luZyBhIGRl cGVuZGVuY3kgb24gaXQgaXMgcHJvYmxlbWF0aWMgcHJvY2VkdXJhbHkuDQoNCldoYXQgaXMgdGhl IHByb2NlZHVyYWwgcHJvYmxlbT8gSXMgdGhpcyBhIHRpbWluZyB0aGluZyAtLSB5b3UgZG9uJ3Qg d2FudCBhIEpPU0UgZHJhZnQgdG8gaGF2ZSB0byB3YWl0IGZvciB0aGUgZHJhZnQtbWNncmV3LWFl YWQtYWVzLWNiYy1obWFjLXNoYTIgZHJhZnQ/DQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From michael_b_jones@hotmail.com Sun Nov 11 17:30: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 7DBD321F852C for ; Sun, 11 Nov 2012 17:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zplj0xMmDBcJ for ; Sun, 11 Nov 2012 17:30:58 -0800 (PST) Received: from bay0-omc1-s17.bay0.hotmail.com (bay0-omc1-s17.bay0.hotmail.com [65.54.190.28]) by ietfa.amsl.com (Postfix) with ESMTP id CC6F621F8522 for ; Sun, 11 Nov 2012 17:30:58 -0800 (PST) Received: from BAY171-W136 ([65.54.190.59]) by bay0-omc1-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Nov 2012 17:30:55 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_5c2bb073-a2f9-49e0-9b03-3cb3efadc5e3_" X-Originating-IP: [50.47.91.23] From: Michael Jones To: , Date: Sun, 11 Nov 2012 17:30:54 -0800 Importance: Normal In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11500331CA9@WSMSG3153V.srv.dir.telstra.com> References: , <255B9BB34FB7D647A506DC292726F6E11500331CA9@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Nov 2012 01:30:55.0273 (UTC) FILETIME=[5C1D1990:01CDC075] Subject: Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer 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: Mon, 12 Nov 2012 01:30:59 -0000 --_5c2bb073-a2f9-49e0-9b03-3cb3efadc5e3_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Using draft-mcgrew-aead-aes-cbc-hmac-sha2 is not the same thing as (1). Fo= r instance=2C as was discussed after David's presentation at IETF 84=2C dra= ft-mcgrew-aead-aes-cbc-hmac-sha2 does not follow the pattern of AEAD algori= thms such as AES GCM=2C which have two inputs (plaintext=2C "additional aut= henticated data")=2C and two outputs (ciphertext=2C "authentication tag"). = Instead=2C it adds a step combining the ciphertext and "authentication tag= " outputs. If you read the draft=2C implementation of draft-mcgrew-aead-aes= -cbc-hmac-sha2 has a lot more steps than what we have for A128CBC+HS256 and= A256CBC+HS512. It requires generating and adding specific padding bytes. = It prefixes the ciphertext with the IV. It includes the length of the "ad= ditional authenticated data" in the MAC calculation. It combines the two o= utputs into one. For decryption=2C likewise=2C the two outputs must be spl= it apart=2C the IV must be split apart=2C etc. All of these are steps that = implementations could get wrong=2C resulting in interoperability problems. = By keeping all the parameters separate=2C our current A128CBC+HS256 and A2= 56CBC+HS512 algorithms eliminate those steps. I'm sorry for the apparent co= nfusion between (1) and draft-mcgrew-aead-aes-cbc-hmac-sha2. While they bo= th explicitly represent the CMK and CEK=2C and use the same underlying cryp= to operations=2C the details differ in ways that are likely to matter to im= plementers. If there was a version of draft-mcgrew-aead-aes-cbc-hmac-sha2 = that kept all the inputs and outputs separate=2C I agree that it would be a= reasonable candidate for JOSE to consider. But unlike AES GCM=2C that's n= ot what it does. -- Mike > From: James.H.Manger@team.telstra.com > To: michael_b_jones@hotmail.com=3B jose@ietf.org > Date: Mon=2C 12 Nov 2012 09:23:37 +1100 > Subject: RE: [jose] Choice for WG: Use a KDF with AES CBC or use a longer= key >=20 > > So I=92d like to explicitly ask the working group. Do you want us to: > > > > (1) Use the concatenation of random CEK and CIK values as the CMK for A= ES CBC=2C resulting in a longer CMK? > > (2) Continue to use a KDF to generate the CEK and CIK from a shorter CM= K? >=20 >=20 > 1. Use draft-mcgrew-aead-aes-cbc-hmac-sha2 >=20 > -- > James Manger = --_5c2bb073-a2f9-49e0-9b03-3cb3efadc5e3_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Using draft-mcgrew-aead-aes-cbc-hmac-sha2 is not the same thing as (1).&nbs= p=3B For instance=2C as was discussed after David's presentation at IETF 84= =2C draft-mcgrew-aead-aes-cbc-hmac-sha2 does not follow the pattern of AEAD= algorithms such as AES GCM=2C which have two inputs (plaintext=2C "additio= nal authenticated data")=2C and two outputs (ciphertext=2C "authentication = tag"). =3B Instead=2C it adds a step combining the ciphertext and "auth= entication tag" outputs.
 =3B
If you read the draft=2C implementa= tion of draft-mcgrew-aead-aes-cbc-hmac-sha2 has a lot more steps than what = we have for A128CBC+HS256 and A256CBC+HS512. =3B It requires generating= and adding specific padding bytes. =3B It prefixes the ciphertext with= the IV. =3B It includes the length of the "additional authenticated da= ta" in the MAC calculation. =3B It combines the two outputs into one.&n= bsp=3B For decryption=2C likewise=2C the two outputs must be split apart=2C= the IV must be split apart=2C etc.
 =3B
All of these are steps t= hat implementations could get wrong=2C resulting in interoperability proble= ms. =3B By keeping all the parameters separate=2C our current A128CBC+H= S256 and A256CBC+HS512 algorithms eliminate those steps.
 =3B
I'm= sorry for the apparent confusion between (1) and draft-mcgrew-aead-aes-cbc= -hmac-sha2. =3B While they both explicitly represent the CMK and CEK=2C= and use the same underlying crypto operations=2C the details differ in way= s that are likely to matter to implementers. =3B If there was a version= of draft-mcgrew-aead-aes-cbc-hmac-sha2 that kept all the inputs and output= s separate=2C I agree that it would be a reasonable candidate for JOSE to c= onsider. =3B But unlike AES GCM=2C that's not what it does.
 =3B=
-- Mike
 =3B
>= =3B From: James.H.Manger@team.telstra.com
>=3B To: michael_b_jones@hot= mail.com=3B jose@ietf.org
>=3B Date: Mon=2C 12 Nov 2012 09:23:37 +1100=
>=3B Subject: RE: [jose] Choice for WG: Use a KDF with AES CBC or use= a longer key
>=3B
>=3B >=3B So I=92d like to explicitly ask t= he working group. Do you want us to:
>=3B >=3B
>=3B >=3B (1)= Use the concatenation of random CEK and CIK values as the CMK for AES CBC= =2C resulting in a longer CMK?
>=3B >=3B (2) Continue to use a KDF t= o generate the CEK and CIK from a shorter CMK?
>=3B
>=3B
>= =3B 1. Use draft-mcgrew-aead-aes-cbc-hmac-sha2
>=3B
>=3B --
&= gt=3B James Manger
= --_5c2bb073-a2f9-49e0-9b03-3cb3efadc5e3_-- From rbarnes@bbn.com Sun Nov 11 17:36: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 14A9321F84BF for ; Sun, 11 Nov 2012 17:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.766 X-Spam-Level: X-Spam-Status: No, score=-106.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPfxOvwsLCEN for ; Sun, 11 Nov 2012 17:36:49 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3AADF21F84BE for ; Sun, 11 Nov 2012 17:36:49 -0800 (PST) Received: from [128.89.254.119] (port=60996) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TXixD-000Mk8-Cr; Sun, 11 Nov 2012 20:36:47 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Richard L. Barnes" In-Reply-To: <26E00E85-A8B9-4E5C-87AC-F2087D7E7C58@netflix.com> Date: Sun, 11 Nov 2012 20:36:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D8B50D1-6135-4D3F-B288-8B690F5B9ACA@netflix.com> <26E00E85-A8B9-4E5C-87AC-F2087D7E7C58@netflix.com> To: Mark Watson X-Mailer: Apple Mail (2.1499) Cc: "jose@ietf.org" Subject: Re: [jose] RESEND: JSON Web Key support for private and symmetric keys 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, 12 Nov 2012 01:36:50 -0000 Hey Mark, Do you mind if I incorporate these in the JOSE use cases document? --Richard On Nov 7, 2012, at 4:45 PM, Mark Watson wrote: >> All, I was hoping to get this to you before your meeting, but get = repeated delivery failures. One more try ... >>=20 >> Begin forwarded message: >>=20 >>> From: Mark Watson >>> Subject: JSON Web Key support for private and symmetric keys >>> Date: November 5, 2012 11:31:53 AM PST >>> To: >>>=20 >>> All, >>>=20 >>> First let me introduce myself. I work for Netflix and have been = working on standardization of various components that we need for = support of our service in pure HTML/Javascript. Specifically, the HTML = Encrypted Media Extensions [1], Media Source Extension [1] and the = WebCrypto API [3] in W3C (the latter to provide us the ability to = implement a secure application protocol in Javascript). >>>=20 >>> At last week's W3C meeting in Lyon, two requirements came up that we = believe could be met very well by the extension of JWK to support = private and symmetric keys: >>>=20 >>> (1) Key wrap/unwrap in the WebCrypto API >>>=20 >>> The WebCrypto API can manage keys below the API boundary, avoiding = the sharing of keying material with the Javascript environment. This has = advantage in certain security models where the JS is less trusted than = the UA. >>>=20 >>> We are working on the specification of key import/export functions = including import/export of wrapped keys. Both these functions require an = explicit binary representation of the key material to be defined. In the = latter case it is required that not only the key itself is protected by = the wrapping operation, but also attributes associated with the key, = most importantly the "exportable" attribute which determines whether the = key can later be exported back to the JS layer. >>>=20 >>> JWK seems attractive for this purpose since it is straightforward to = define additional attributes to be carried with the key. The entire JWK = JSON structure would then be wrapped using the key wrapping algorithm = (for example AES Key Wrap). >>>=20 >>> WebCrypto supports public/private key pairs and symmetric keys. = Hence JWK would need to be extended to support private and symmetric = keys to be used for this purpose. >>>=20 >>> (2) Provision of keys to the HTML Encrypted Media Extensions "clear = key" keysystem=20 >>>=20 >>> The Encrypted Media Extensions provide an API for a script to = interact with a "Content Decryption Module" within the UA that provides = key exchange and content decryption capabilities. It is expected that = the well-known DRM vendors will provide "Content Decryption Modules" = that are integrated into browsers and/or that platform APIs for such = modules will be available for browsers to integrate with (e.g. in the = case that the capability is present within the OS on a given platform.) >>>=20 >>> Additionally, the W3C group itself will define a simple "clearkey" = Content Decryption Module in which the key is passed, in the clear, = directly from the JS to the UA. This keysystem has application in = certain specific security models (for example if the user is also the = owner of the content) and for testing. >>>=20 >>> The keying material is passed to the CDM in the form of an opaque = keysystem-specific byte array, which for clearkey must specify one or = more (symmetric, likely AES) keys and associated Key Ids. Again, JWK = seems an excellent simple candidate for this purpose, if it supported = symmetric keys. >>>=20 >>>=20 >>> I understand that the JWK specification can be extended by = registering the necessary additional attributes with IANA on a = "Specification Required" basis. However, it was generally agreed in last = week's W3C meetings that it would be better if this work was done in the = IETF JOSE group. >>>=20 >>> Therefore, the upshot of this email is to ask if there is support in = the IETF JOSE group for adding private and symmetric keys to JWK ? >>>=20 >>> I understand there is a draft for private keys already existing. I = would be more than happy to propose a draft for symmetric keys if there = is interest in progressing that here. >>>=20 >>> Finally, just to avoid any confusion, I should say that whilst the = above approaches had general support in last week's W3C meeting, this is = not a formal communication from the W3C (W3C groups tend not to send = formal "liaisons"). >>>=20 >>> Best regards, >>>=20 >>> Mark Watson >>> Netflix >>>=20 >>> [1] = http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-me= dia.html >>> [2] = http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.ht= ml >>> [3] http://www.w3.org/2012/webcrypto/WebCryptoAPI/ >>=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From ve7jtb@ve7jtb.com Sun Nov 11 17:54: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 ABB8F21F84C4 for ; Sun, 11 Nov 2012 17:54:13 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BR5shopZwOhA for ; Sun, 11 Nov 2012 17:54:12 -0800 (PST) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A3E3521F84B3 for ; Sun, 11 Nov 2012 17:54:12 -0800 (PST) Received: by mail-gg0-f172.google.com with SMTP id i4so1154757ggn.31 for ; Sun, 11 Nov 2012 17:54:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=6bEaFTIO9OnRum2ysgjYo+oBnH11KFJ7jnpBftCqDsM=; b=cnpEAnBBwhjFdcCI5yXJJ1XQXYpe1cfxq5+snPwMz18ozzjML+MbrOXTTVpdflk9JV vkC2qUnR285ePcncLM+u8hJbX/dCDo0bAZDbR2sdFXgVDLKcmuEcFTTZQzczGBBYsLU9 WR266jpKuly6UM8KlZS8UlQg62Alu+wvJow2BdUbdRJ0/p0TKXq/3cEQ22u6PwGTvDhU H8OUSV5s/8pZ+ezEb+omB7QVEwNCdg/OT2jQt5vLvVKVryLsvgf13NkIFOMBhAKF7RUL 6m8DzpbzqJmfmdtgpPHi3dpSWfKtRzN0pfUqbTb5RgG/JImXr9gV0eEuZ3jXfWPTGLX7 lUCA== Received: by 10.236.52.198 with SMTP id e46mr17930693yhc.57.1352685252033; Sun, 11 Nov 2012 17:54:12 -0800 (PST) Received: from [192.168.1.211] (190-20-39-87.baf.movistar.cl. [190.20.39.87]) by mx.google.com with ESMTPS id t14sm4852036anl.17.2012.11.11.17.54.08 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Nov 2012 17:54:11 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_431A62DE-0493-43B8-BDC8-4D2F43D3E425" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Sun, 11 Nov 2012 22:54:00 -0300 Message-Id: <95B94292-42F7-4C57-B6FD-B509373F9E98@ve7jtb.com> References: , <255B9BB34FB7D647A506DC292726F6E11500331CA9@WSMSG3153V.srv.dir.telstra.com> To: Michael Jones X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQl/Q0a50/Jp/HTykTk6LOb2c/kTa/9DHF7O6Dez80NAyAaGuWS0re6fnktIVYYqCUpz5gHn Cc: james.h.manger@team.telstra.com, jose@ietf.org Subject: Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer 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: Mon, 12 Nov 2012 01:54:13 -0000 --Apple-Mail=_431A62DE-0493-43B8-BDC8-4D2F43D3E425 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Sorry I was only thinking of the KDF issue not the other differences. = You far correct there are still non trivia differences between the two. The two are closer but not the same. =20 I caught the flue on my way home from IETF and probably need to get off = the cold medication before answering email. John On 2012-11-11, at 10:30 PM, Michael Jones = wrote: > Using draft-mcgrew-aead-aes-cbc-hmac-sha2 is not the same thing as = (1). For instance, as was discussed after David's presentation at IETF = 84, draft-mcgrew-aead-aes-cbc-hmac-sha2 does not follow the pattern of = AEAD algorithms such as AES GCM, which have two inputs (plaintext, = "additional authenticated data"), and two outputs (ciphertext, = "authentication tag"). Instead, it adds a step combining the ciphertext = and "authentication tag" outputs. > =20 > If you read the draft, implementation of = draft-mcgrew-aead-aes-cbc-hmac-sha2 has a lot more steps than what we = have for A128CBC+HS256 and A256CBC+HS512. It requires generating and = adding specific padding bytes. It prefixes the ciphertext with the IV. = It includes the length of the "additional authenticated data" in the MAC = calculation. It combines the two outputs into one. For decryption, = likewise, the two outputs must be split apart, the IV must be split = apart, etc. > =20 > All of these are steps that implementations could get wrong, resulting = in interoperability problems. By keeping all the parameters separate, = our current A128CBC+HS256 and A256CBC+HS512 algorithms eliminate those = steps. > =20 > I'm sorry for the apparent confusion between (1) and = draft-mcgrew-aead-aes-cbc-hmac-sha2. While they both explicitly = represent the CMK and CEK, and use the same underlying crypto = operations, the details differ in ways that are likely to matter to = implementers. If there was a version of = draft-mcgrew-aead-aes-cbc-hmac-sha2 that kept all the inputs and outputs = separate, I agree that it would be a reasonable candidate for JOSE to = consider. But unlike AES GCM, that's not what it does. > =20 > -- Mike > =20 > > From: James.H.Manger@team.telstra.com > > To: michael_b_jones@hotmail.com; jose@ietf.org > > Date: Mon, 12 Nov 2012 09:23:37 +1100 > > Subject: RE: [jose] Choice for WG: Use a KDF with AES CBC or use a = longer key > >=20 > > > So I=92d like to explicitly ask the working group. Do you want us = to: > > > > > > (1) Use the concatenation of random CEK and CIK values as the CMK = for AES CBC, resulting in a longer CMK? > > > (2) Continue to use a KDF to generate the CEK and CIK from a = shorter CMK? > >=20 > >=20 > > 1. Use draft-mcgrew-aead-aes-cbc-hmac-sha2 > >=20 > > -- > > James Manger > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_431A62DE-0493-43B8-BDC8-4D2F43D3E425 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Sorry I was only thinking of = the KDF issue not the other differences.   You far correct there = are still non trivia differences between the two.

The = two are closer but not the same.  

I = caught the flue on my way home from IETF and probably need to get off = the cold medication before answering = email.

John
On 2012-11-11, at = 10:30 PM, Michael Jones <michael_b_jones@hotmail.com> wrote:

Using draft-mcgrew-aead-aes-cbc-hmac-sha2 is not the same = thing as (1).  For instance, as was discussed after David's = presentation at IETF 84, draft-mcgrew-aead-aes-cbc-hmac-sha2 does not = follow the pattern of AEAD algorithms such as AES GCM, which have two = inputs (plaintext, "additional authenticated data"), and two outputs = (ciphertext, "authentication tag").  Instead, it adds a step = combining the ciphertext and "authentication tag" = outputs.
 
If you read the draft, implementation of = draft-mcgrew-aead-aes-cbc-hmac-sha2 has a lot more steps than what we = have for A128CBC+HS256 and A256CBC+HS512.  It requires generating = and adding specific padding bytes.  It prefixes the ciphertext with = the IV.  It includes the length of the "additional authenticated = data" in the MAC calculation.  It combines the two outputs into = one.  For decryption, likewise, the two outputs must be split = apart, the IV must be split apart, etc.
 
All of these are = steps that implementations could get wrong, resulting in = interoperability problems.  By keeping all the parameters separate, = our current A128CBC+HS256 and A256CBC+HS512 algorithms eliminate those = steps.
 
I'm sorry for the apparent confusion between (1) and = draft-mcgrew-aead-aes-cbc-hmac-sha2.  While they both explicitly = represent the CMK and CEK, and use the same underlying crypto = operations, the details differ in ways that are likely to matter to = implementers.  If there was a version of = draft-mcgrew-aead-aes-cbc-hmac-sha2 that kept all the inputs and outputs = separate, I agree that it would be a reasonable candidate for JOSE to = consider.  But unlike AES GCM, that's not what it = does.
 
-- Mike
 
> From: James.H.Manger@team.telstr= a.com
> To: michael_b_jones@hotmail.com; jose@ietf.org
> Date: Mon, 12 = Nov 2012 09:23:37 +1100
> Subject: RE: [jose] Choice for WG: Use a = KDF with AES CBC or use a longer key
> 
> > So I=92d like = to explicitly ask the working group. Do you want us to:
> = >
> > (1) Use the concatenation of random CEK and CIK values = as the CMK for AES CBC, resulting in a longer CMK?
> > (2) = Continue to use a KDF to generate the CEK and CIK from a shorter = CMK?
> 
> 
> 1. Use = draft-mcgrew-aead-aes-cbc-hmac-sha2
> 
> --
> James = Manger
_______________________________________________
j= ose mailing list
jose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jose

= --Apple-Mail=_431A62DE-0493-43B8-BDC8-4D2F43D3E425-- From ve7jtb@ve7jtb.com Sun Nov 11 17:58: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 20BEC21F8438 for ; Sun, 11 Nov 2012 17:58:48 -0800 (PST) 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.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmudsHCNBHsZ for ; Sun, 11 Nov 2012 17:58:47 -0800 (PST) Received: from mail-ye0-f172.google.com (mail-ye0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFE521F8436 for ; Sun, 11 Nov 2012 17:58:47 -0800 (PST) Received: by mail-ye0-f172.google.com with SMTP id l13so1117992yen.31 for ; Sun, 11 Nov 2012 17:58:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=2BtvxZv3rqGJuqs2hBqpkUeYmrAlf5JhH5swwmnjCVw=; b=MJNGN0+Y+UcsWzXDU6GAohqGE/NIxqgoSs1b21Yn/ugASoSq/q0jMTMXz4Og9SeIvj NJfeXAHPtdkacp/f+pdfptyYpqRv0BTy9+U5pQmGvwlbmF9zVjrzd1reKdKFWVefY1Gv FiuBkjaNjBEoqnAfccscoICC7R9/NSvbEUA49w044lgqMN/kuaS5Ffd1YG1QVpnq03iQ 3RuNHayC3eunttwsd+V2vOc+q4qC0S1CQKv7Z6IOmgP4xjupGkfEjorzmQY/Hc2JWxkZ cIlrDmpiowchwYxgqAgItjP31bDNZ2HV3RW7RIg1Q1DbIF1knYXZ0El1d6dkaJkXcjvj AGoA== Received: by 10.236.138.10 with SMTP id z10mr17861070yhi.39.1352685527120; Sun, 11 Nov 2012 17:58:47 -0800 (PST) Received: from [192.168.1.211] (190-20-39-87.baf.movistar.cl. [190.20.39.87]) by mx.google.com with ESMTPS id g2sm5505292yhj.9.2012.11.11.17.58.42 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Nov 2012 17:58:46 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11500332235@WSMSG3153V.srv.dir.telstra.com> Date: Sun, 11 Nov 2012 22:58:34 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1FF2D51B-9EE4-46E9-A9A8-CDD856B0A9F9@ve7jtb.com> References: <255B9BB34FB7D647A506DC292726F6E11500331CA9@WSMSG3153V.srv.dir.telstra.com> <8D4A85A2-07DD-4E34-89D9-1640F5ED9BEA@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E11500332235@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlM/sOvUg5rYZlWlL/wnP8O1MplkAPpiFq4QurKXz0nNfUeW3UreuHIoJAgV/57Lr0izcc2 Cc: "jose@ietf.org" Subject: Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer 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: Mon, 12 Nov 2012 01:58:48 -0000 Yes without draft-mcgrew-aead-aes-cbc-hmac-sha2 having a clear path to = RFC I would not want to have a dependency on it. Mike correctly points out that there are other outstanding differences = between the two as well. John On 2012-11-11, at 10:21 PM, "Manger, James H" = wrote: >>> 1. Use draft-mcgrew-aead-aes-cbc-hmac-sha2 >=20 >> I think that is largely the effect of making the proposed change. = The >> remaining question if we do it is if we want to take a dependency on >> draft-mcgrew-aead-aes-cbc-hmac-sha2 or incorporate it. >>=20 >> If it is a ID taking a dependency on it is problematic proceduraly. >=20 > What is the procedural problem? Is this a timing thing -- you don't = want a JOSE draft to have to wait for the = draft-mcgrew-aead-aes-cbc-hmac-sha2 draft? >=20 > -- > James Manger From watsonm@netflix.com Sun Nov 11 18:53: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 0568B21F8430 for ; Sun, 11 Nov 2012 18:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.213 X-Spam-Level: X-Spam-Status: No, score=-9.213 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8H0OlaChYmI for ; Sun, 11 Nov 2012 18:53:36 -0800 (PST) Received: from exout103.netflix.com (unknown [69.53.237.162]) by ietfa.amsl.com (Postfix) with ESMTP id 1D46B21F842E for ; Sun, 11 Nov 2012 18:53:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=s2048;d=netflix.com; h=from:to:cc:subject:date:message-id:references:in-reply-to :content-type:mime-version; bh=St2JjkDOsQ8RuoFDkLXlOIsWgNw=; b=oL966n7W+O5zzq9EAnkNF+k9BGtxBiHIjgrHeldnE7a0PsCJU8ObdiPz0pgOG6qetkEk5IHQ OxvYKNTjQJAgPl6TzyLlqdmZZOnAqF5qzdHkkf6tBJJvTOLDxoL+w4gBZ11ts3rN84wWUSgd wILlvp3cYCmhG52zrRxtYVwB9Xdq5QFX7CLZi/mwWPk1fw5cn3TZrxa1gEKMOl6tsahR+3Az Axj4QyD2XQI7ROWg2Z40sXf9ydMS9tId1Y53rmljGHjXepKp//QcM6+XR2ARv7m8dlQqRy5P RIn/flPA3v4ByGcomRhdBR3OdbcZRv31FVnW+ektFJXQ6xwVFa73Bg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048;d=netflix.com; h=from:to:cc:subject:date:message-id:references:in-reply-to :content-type:mime-version; b=UHHFu/LWY3oQNZXpk1V24etRkmilK5AaNkl+IguapuPfDIEnreCrW+W9jIaD1cXQ2q9ACC1N la51bMWFIb+cic2s3NrV2MdMuio6Dt/8St+7EZhsynsyLln67Ax2ORX0LIZ64VYRIUnL5Os+ q21MWp6vL2FuJCVssVvqHrT+yM6Uc5CMd6K1ntQVPviMYNAS65FTdQ12Y10em1t42epojrOn Slgzqty4It0VKQP26Ks+/DjusThn9+7XBKYkaYDh/Q/4n/e5hEdXWpOmqdNDQwyq5IUIRDL1 faICvzl3eczi06wuxbk7TEWUiojkbYrG5pHVevaqwjfXilcjrjbRQA== Received: from EXFE104.corp.netflix.com (10.64.32.104) by exout103.netflix.com (10.64.240.73) with Microsoft SMTP Server (TLS) id 14.2.298.4; Sun, 11 Nov 2012 18:53:38 -0800 Received: from EXMB106.corp.netflix.com ([169.254.6.135]) by exfe104.corp.netflix.com ([10.64.32.104]) with mapi id 14.02.0283.003; Sun, 11 Nov 2012 18:53:35 -0800 From: Mark Watson To: "Richard L. Barnes" Thread-Topic: [jose] RESEND: JSON Web Key support for private and symmetric keys Thread-Index: AQHNu4w1mKMK4AWfQEKkA5HPNCBJqJfl+2GAgAAVdYA= Date: Mon, 12 Nov 2012 02:53:35 +0000 Message-ID: <455B6BE1-A9DC-4225-B7F8-BA5DDC1611F4@netflix.com> References: <2D8B50D1-6135-4D3F-B288-8B690F5B9ACA@netflix.com> <26E00E85-A8B9-4E5C-87AC-F2087D7E7C58@netflix.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.32.82] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1384A0FA90041F478FE05AA7EF845BEF@netflix.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] RESEND: JSON Web Key support for private and symmetric keys 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, 12 Nov 2012 02:53:37 -0000 On Nov 11, 2012, at 5:36 PM, Richard L. Barnes wrote: > Hey Mark, >=20 > Do you mind if I incorporate these in the JOSE use cases document? > Please go ahead! =85Mark >=20 > --Richard >=20 >=20 >=20 > On Nov 7, 2012, at 4:45 PM, Mark Watson wrote: >=20 >>> All, I was hoping to get this to you before your meeting, but get repea= ted delivery failures. One more try ... >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: Mark Watson >>>> Subject: JSON Web Key support for private and symmetric keys >>>> Date: November 5, 2012 11:31:53 AM PST >>>> To: >>>>=20 >>>> All, >>>>=20 >>>> First let me introduce myself. I work for Netflix and have been workin= g on standardization of various components that we need for support of our = service in pure HTML/Javascript. Specifically, the HTML Encrypted Media Ext= ensions [1], Media Source Extension [1] and the WebCrypto API [3] in W3C (t= he latter to provide us the ability to implement a secure application proto= col in Javascript). >>>>=20 >>>> At last week's W3C meeting in Lyon, two requirements came up that we b= elieve could be met very well by the extension of JWK to support private an= d symmetric keys: >>>>=20 >>>> (1) Key wrap/unwrap in the WebCrypto API >>>>=20 >>>> The WebCrypto API can manage keys below the API boundary, avoiding the= sharing of keying material with the Javascript environment. This has advan= tage in certain security models where the JS is less trusted than the UA. >>>>=20 >>>> We are working on the specification of key import/export functions inc= luding import/export of wrapped keys. Both these functions require an expli= cit binary representation of the key material to be defined. In the latter = case it is required that not only the key itself is protected by the wrappi= ng operation, but also attributes associated with the key, most importantly= the "exportable" attribute which determines whether the key can later be e= xported back to the JS layer. >>>>=20 >>>> JWK seems attractive for this purpose since it is straightforward to d= efine additional attributes to be carried with the key. The entire JWK JSON= structure would then be wrapped using the key wrapping algorithm (for exam= ple AES Key Wrap). >>>>=20 >>>> WebCrypto supports public/private key pairs and symmetric keys. Hence = JWK would need to be extended to support private and symmetric keys to be u= sed for this purpose. >>>>=20 >>>> (2) Provision of keys to the HTML Encrypted Media Extensions "clear ke= y" keysystem=20 >>>>=20 >>>> The Encrypted Media Extensions provide an API for a script to interact= with a "Content Decryption Module" within the UA that provides key exchang= e and content decryption capabilities. It is expected that the well-known D= RM vendors will provide "Content Decryption Modules" that are integrated in= to browsers and/or that platform APIs for such modules will be available fo= r browsers to integrate with (e.g. in the case that the capability is prese= nt within the OS on a given platform.) >>>>=20 >>>> Additionally, the W3C group itself will define a simple "clearkey" Con= tent Decryption Module in which the key is passed, in the clear, directly f= rom the JS to the UA. This keysystem has application in certain specific se= curity models (for example if the user is also the owner of the content) an= d for testing. >>>>=20 >>>> The keying material is passed to the CDM in the form of an opaque keys= ystem-specific byte array, which for clearkey must specify one or more (sym= metric, likely AES) keys and associated Key Ids. Again, JWK seems an excell= ent simple candidate for this purpose, if it supported symmetric keys. >>>>=20 >>>>=20 >>>> I understand that the JWK specification can be extended by registering= the necessary additional attributes with IANA on a "Specification Required= " basis. However, it was generally agreed in last week's W3C meetings that = it would be better if this work was done in the IETF JOSE group. >>>>=20 >>>> Therefore, the upshot of this email is to ask if there is support in t= he IETF JOSE group for adding private and symmetric keys to JWK ? >>>>=20 >>>> I understand there is a draft for private keys already existing. I wou= ld be more than happy to propose a draft for symmetric keys if there is int= erest in progressing that here. >>>>=20 >>>> Finally, just to avoid any confusion, I should say that whilst the abo= ve approaches had general support in last week's W3C meeting, this is not a= formal communication from the W3C (W3C groups tend not to send formal "lia= isons"). >>>>=20 >>>> Best regards, >>>>=20 >>>> Mark Watson >>>> Netflix >>>>=20 >>>> [1] http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encr= ypted-media.html >>>> [2] http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-s= ource.html >>>> [3] http://www.w3.org/2012/webcrypto/WebCryptoAPI/ >>>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 >=20 From James.H.Manger@team.telstra.com Sun Nov 11 19:06: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 406D221F84BE for ; Sun, 11 Nov 2012 19:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[AWL=0.189, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+b6Ebl80vJC for ; Sun, 11 Nov 2012 19:06:52 -0800 (PST) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 33EA521F84B8 for ; Sun, 11 Nov 2012 19:06:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,759,1344175200"; d="scan'208,217";a="100802125" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 12 Nov 2012 14:06:47 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6893"; a="98989579" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipccni.tcif.telstra.com.au with ESMTP; 12 Nov 2012 14:06:47 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Mon, 12 Nov 2012 14:06:47 +1100 From: "Manger, James H" To: Michael Jones , "jose@ietf.org" Date: Mon, 12 Nov 2012 14:06:46 +1100 Thread-Topic: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key Thread-Index: Ac3AdV46GFasBAvrSXeE1Q74185+xQAA53Hg Message-ID: <255B9BB34FB7D647A506DC292726F6E1150045CB9F@WSMSG3153V.srv.dir.telstra.com> References: , <255B9BB34FB7D647A506DC292726F6E11500331CA9@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_255B9BB34FB7D647A506DC292726F6E1150045CB9FWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer 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: Mon, 12 Nov 2012 03:06:53 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1150045CB9FWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBVc2luZyBkcmFmdC1tY2dyZXctYWVhZC1hZXMtY2JjLWhtYWMtc2hhMiBpcyBub3QgdGhlIHNh bWUgdGhpbmcgYXMgKDEpLg0KDQpUaGVuIGNoYW5nZSBteSB2b3RlIHRvOg0KDQooMWIpIFVzZSBk cmFmdC1tY2dyZXctYWVhZC1hZXMtY2JjLWhtYWMtc2hhMg0KDQpJIGtub3cgZHJhZnQtbWNncmV3 LWFlYWQtYWVzLWNiYy1obWFjLXNoYTIgaXMgbm90IHF1aXRlIHRoZSBzYW1lIGFzIEExMjhDQkMr SFMyNTYtd2l0aG91dC1hLUtERi4gVGhlcmUgYXJlIGEgaGFuZGZ1bCBvZiDigJxkaXN0aW5jdGlv bnMtd2l0aG91dC1hLWRpZmZlcmVuY2XigJ0gYW5kIHNvbWUgZGlmZmVyZW5jZXMgdGhhdCBhcmUg c3VidGxlIGJ1dCBpbXBvcnRhbnQgd2hlcmUgZHJhZnQtbWNncmV3IGlzIGJldHRlci4NCg0KPiBJ dCByZXF1aXJlcyBnZW5lcmF0aW5nIGFuZCBhZGRpbmcgc3BlY2lmaWMgcGFkZGluZyBieXRlcy4N Cg0KVGhleSBib3RoIGFkZCBpZGVudGljYWwgcGFkZGluZy4gZHJhZnQtbWNncmV3IHNwZWxscyBp dCBvdXQ7IEExMjhDQkMrSFMyNTYganVzdCByZWZlcnMgdG8gUEtDUyAjNSBwYWRkaW5nICh3aXRo b3V0IG11Y2ggb2YgYSByZWZlcmVuY2UpLg0KDQo+IEl0IHByZWZpeGVzIHRoZSBjaXBoZXJ0ZXh0 IHdpdGggdGhlIElWLg0KDQpHb29kIGRlc2lnbi4gQnV0IGlmIEpPU0UgaW5zaXN0cyBvbiBzZXBh cmF0ZSBCNjQtZW5jb2RlZCBmaWVsZHMgaXQgaXMgdHJpdmlhbCB0byBjb252ZXJ0Lg0KDQo+IEl0 IGluY2x1ZGVzIHRoZSBsZW5ndGggb2YgdGhlICJhZGRpdGlvbmFsIGF1dGhlbnRpY2F0ZWQgZGF0 YSIgaW4gdGhlIE1BQyBjYWxjdWxhdGlvbi4NCg0KR3JlYXQgZGVzaWduLiBBMTI4Q0JDK0hTMjU2 LCBpbiBjb250cmFzdCwgcmVsaWVzIG9uIGFuIGV4dHJhIEI2NC1lbmNvZGluZyBzdGVwIHRvIHNh ZmVseSBkaXN0aW5ndWlzaCDigJxhZGRpdGlvbmFsIGRhdGHigJ0gYW5kIOKAnGNpcGhlcnRleHTi gJ0uIEExMjhDQkMrSFMyNTYgaGFzIHRvIE1BQyB1cCB0byAzMyUgbW9yZSBieXRlcyB0aGFuIGRy YWZ0LW1jZ3JldyAod2hlbiB0aGUgcGxhaW50ZXh0IHNpemUgZG9taW5hdGVzKS4NCg0KV2hpbGUg Z2VuZXJhbC1wdXJwb3NlIGNyeXB0byBsaWJyYXJpZXMgb25seSBpbXBsZW1lbnQgdGhlIEFFUyAm IEhNQUMgY29tcG9uZW50cyBidXQgbm90IHRoZSBBRUFEIGNvbWJpbmF0aW9uIChhbmQgQTEyOENC QytIUzI1NiBpcyBvbmx5IGFwcGxpZWQgdG8gc21hbGwgbWVzc2FnZXMpLCBpdCBkb2VzbuKAmXQg bWF0dGVyIG11Y2guIEhvd2V2ZXIsIG9uY2UgY3J5cHRvIGxpYnJhcmllcyBvZmZlciBBRUFEIEFQ SXMgaXQgZG9lcy4gQTEyOENCQytIUzI1NiByZXF1aXJlcyB0aGUg4oCcaW5zaWRl4oCdIG9mIHRo ZSBjcnlwdG8gQVBJIHRvIGhhdmUgdGhlIHJhdyBhbmQgQjY0IGRhdGEgYnV0IG9ubHkgb25lIGZv cm0gd2lsbCBiZSBwYXNzZWQgYWNyb3NzIHRoZSBBUEkuIFRoYXQgbG9ja3MgaW4gZHVwbGljYXRl ZCBlZmZvcnQgYW5kIG92ZXJoZWFkIHNvIG11Y2ggc28gdGhhdCBJIGV4cGVjdCBnZW5lcmFsIHB1 cnBvc2UgY3J5cHRvIGxpYnJhcmllcyB3aWxsIHN1cHBvcnQgZHJhZnQtbWNncmV3IGJ1dCBub3Qg QTEyOENCQytIUzI1Ni4NCg0KPiBJdCBjb21iaW5lcyB0aGUgdHdvIG91dHB1dHMgaW50byBvbmUu DQoNCkFnYWluIGdvb2QgZGVzaWduLCBidXQgdHJpdmlhbCB0byBzZXBhcmF0ZSBpZiBkZXNpcmVk Lg0KDQoNCkJvdGggSldBIGFuZCBkcmFmdC1tY2dyZXcgcmVmZXIgdG8gUkZDIDUxMTYg4oCcQW4g SW50ZXJmYWNlIGFuZCBBbGdvcml0aG1zIGZvciBBdXRoZW50aWNhdGVkIEVuY3J5cHRpb27igJ0u IEpPU0Ugc2hvdWxkIGZvbGxvdyB0aGUgcGF0dGVybiBzcGVjaWZpZWQgaW4gdGhhdCBSRkMsIHdo aWNoIGRyYWZ0LW1jZ3JldyBkb2VzLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCkZyb206IE1pY2hh ZWwgSm9uZXMgW21haWx0bzptaWNoYWVsX2Jfam9uZXNAaG90bWFpbC5jb21dDQpTZW50OiBNb25k YXksIDEyIE5vdmVtYmVyIDIwMTIgMTI6MzEgUE0NClRvOiBNYW5nZXIsIEphbWVzIEg7IGpvc2VA aWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbam9zZV0gQ2hvaWNlIGZvciBXRzogVXNlIGEgS0RGIHdp dGggQUVTIENCQyBvciB1c2UgYSBsb25nZXIga2V5DQoNClVzaW5nIGRyYWZ0LW1jZ3Jldy1hZWFk LWFlcy1jYmMtaG1hYy1zaGEyIGlzIG5vdCB0aGUgc2FtZSB0aGluZyBhcyAoMSkuICBGb3IgaW5z dGFuY2UsIGFzIHdhcyBkaXNjdXNzZWQgYWZ0ZXIgRGF2aWQncyBwcmVzZW50YXRpb24gYXQgSUVU RiA4NCwgZHJhZnQtbWNncmV3LWFlYWQtYWVzLWNiYy1obWFjLXNoYTIgZG9lcyBub3QgZm9sbG93 IHRoZSBwYXR0ZXJuIG9mIEFFQUQgYWxnb3JpdGhtcyBzdWNoIGFzIEFFUyBHQ00sIHdoaWNoIGhh dmUgdHdvIGlucHV0cyAocGxhaW50ZXh0LCAiYWRkaXRpb25hbCBhdXRoZW50aWNhdGVkIGRhdGEi KSwgYW5kIHR3byBvdXRwdXRzIChjaXBoZXJ0ZXh0LCAiYXV0aGVudGljYXRpb24gdGFnIikuICBJ bnN0ZWFkLCBpdCBhZGRzIGEgc3RlcCBjb21iaW5pbmcgdGhlIGNpcGhlcnRleHQgYW5kICJhdXRo ZW50aWNhdGlvbiB0YWciIG91dHB1dHMuDQoNCklmIHlvdSByZWFkIHRoZSBkcmFmdCwgaW1wbGVt ZW50YXRpb24gb2YgZHJhZnQtbWNncmV3LWFlYWQtYWVzLWNiYy1obWFjLXNoYTIgaGFzIGEgbG90 IG1vcmUgc3RlcHMgdGhhbiB3aGF0IHdlIGhhdmUgZm9yIEExMjhDQkMrSFMyNTYgYW5kIEEyNTZD QkMrSFM1MTIuICBJdCByZXF1aXJlcyBnZW5lcmF0aW5nIGFuZCBhZGRpbmcgc3BlY2lmaWMgcGFk ZGluZyBieXRlcy4gIEl0IHByZWZpeGVzIHRoZSBjaXBoZXJ0ZXh0IHdpdGggdGhlIElWLiAgSXQg aW5jbHVkZXMgdGhlIGxlbmd0aCBvZiB0aGUgImFkZGl0aW9uYWwgYXV0aGVudGljYXRlZCBkYXRh IiBpbiB0aGUgTUFDIGNhbGN1bGF0aW9uLiAgSXQgY29tYmluZXMgdGhlIHR3byBvdXRwdXRzIGlu dG8gb25lLiAgRm9yIGRlY3J5cHRpb24sIGxpa2V3aXNlLCB0aGUgdHdvIG91dHB1dHMgbXVzdCBi ZSBzcGxpdCBhcGFydCwgdGhlIElWIG11c3QgYmUgc3BsaXQgYXBhcnQsIGV0Yy4NCg0KQWxsIG9m IHRoZXNlIGFyZSBzdGVwcyB0aGF0IGltcGxlbWVudGF0aW9ucyBjb3VsZCBnZXQgd3JvbmcsIHJl c3VsdGluZyBpbiBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zLiAgQnkga2VlcGluZyBhbGwgdGhl IHBhcmFtZXRlcnMgc2VwYXJhdGUsIG91ciBjdXJyZW50IEExMjhDQkMrSFMyNTYgYW5kIEEyNTZD QkMrSFM1MTIgYWxnb3JpdGhtcyBlbGltaW5hdGUgdGhvc2Ugc3RlcHMuDQoNCkknbSBzb3JyeSBm b3IgdGhlIGFwcGFyZW50IGNvbmZ1c2lvbiBiZXR3ZWVuICgxKSBhbmQgZHJhZnQtbWNncmV3LWFl YWQtYWVzLWNiYy1obWFjLXNoYTIuICBXaGlsZSB0aGV5IGJvdGggZXhwbGljaXRseSByZXByZXNl bnQgdGhlIENNSyBhbmQgQ0VLLCBhbmQgdXNlIHRoZSBzYW1lIHVuZGVybHlpbmcgY3J5cHRvIG9w ZXJhdGlvbnMsIHRoZSBkZXRhaWxzIGRpZmZlciBpbiB3YXlzIHRoYXQgYXJlIGxpa2VseSB0byBt YXR0ZXIgdG8gaW1wbGVtZW50ZXJzLiAgSWYgdGhlcmUgd2FzIGEgdmVyc2lvbiBvZiBkcmFmdC1t Y2dyZXctYWVhZC1hZXMtY2JjLWhtYWMtc2hhMiB0aGF0IGtlcHQgYWxsIHRoZSBpbnB1dHMgYW5k IG91dHB1dHMgc2VwYXJhdGUsIEkgYWdyZWUgdGhhdCBpdCB3b3VsZCBiZSBhIHJlYXNvbmFibGUg Y2FuZGlkYXRlIGZvciBKT1NFIHRvIGNvbnNpZGVyLiAgQnV0IHVubGlrZSBBRVMgR0NNLCB0aGF0 J3Mgbm90IHdoYXQgaXQgZG9lcy4NCg0KLS0gTWlrZQ0KDQo+IEZyb206IEphbWVzLkguTWFuZ2Vy QHRlYW0udGVsc3RyYS5jb208bWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20+ DQo+IFRvOiBtaWNoYWVsX2Jfam9uZXNAaG90bWFpbC5jb208bWFpbHRvOm1pY2hhZWxfYl9qb25l c0Bob3RtYWlsLmNvbT47IGpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQo+IERh dGU6IE1vbiwgMTIgTm92IDIwMTIgMDk6MjM6MzcgKzExMDANCj4gU3ViamVjdDogUkU6IFtqb3Nl XSBDaG9pY2UgZm9yIFdHOiBVc2UgYSBLREYgd2l0aCBBRVMgQ0JDIG9yIHVzZSBhIGxvbmdlciBr ZXkNCj4NCj4gPiBTbyBJ4oCZZCBsaWtlIHRvIGV4cGxpY2l0bHkgYXNrIHRoZSB3b3JraW5nIGdy b3VwLiBEbyB5b3Ugd2FudCB1cyB0bzoNCj4gPg0KPiA+ICgxKSBVc2UgdGhlIGNvbmNhdGVuYXRp b24gb2YgcmFuZG9tIENFSyBhbmQgQ0lLIHZhbHVlcyBhcyB0aGUgQ01LIGZvciBBRVMgQ0JDLCBy ZXN1bHRpbmcgaW4gYSBsb25nZXIgQ01LPw0KPiA+ICgyKSBDb250aW51ZSB0byB1c2UgYSBLREYg dG8gZ2VuZXJhdGUgdGhlIENFSyBhbmQgQ0lLIGZyb20gYSBzaG9ydGVyIENNSz8NCj4NCj4NCj4g MS4gVXNlIGRyYWZ0LW1jZ3Jldy1hZWFkLWFlcy1jYmMtaG1hYy1zaGEyDQo+DQo+IC0tDQo+IEph bWVzIE1hbmdlcg0K --_000_255B9BB34FB7D647A506DC292726F6E1150045CB9FWSMSG3153Vsrv_ 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 Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpw Lk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVO LUFVIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIic+Jmd0OyBVc2luZyBkcmFmdC1tY2dyZXctYWVhZC1hZXMtY2Jj LWhtYWMtc2hhMiBpcyBub3QgdGhlIHNhbWUgdGhpbmcgYXMgKDEpLiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlbiBjaGFuZ2UgbXkgdm90 ZSB0bzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPigxYikgVXNlIGRyYWZ0LW1jZ3Jldy1hZWFkLWFlcy1j YmMtaG1hYy1zaGEyPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JIGtub3cgZHJhZnQ8L3NwYW4+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz4tbWNncmV3LWFlYWQtYWVzLWNiYy1obWFjLXNoYTIgaXMgbm90IHF1 aXRlIHRoZSA8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5zYW1lIGFzIDwvc3Bhbj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPkExMjhDQkMrSFMyNTYtd2l0aG91dC1hLUtERi4gVGhlcmUgYXJl IGEgaGFuZGZ1bCBvZiDigJxkaXN0aW5jdGlvbnMtd2l0aG91dC1hLWRpZmZlcmVuY2XigJ0gYW5k IHNvbWUgZGlmZmVyZW5jZXMgdGhhdCBhcmUgc3VidGxlIGJ1dCBpbXBvcnRhbnQgd2hlcmUgPC9z cGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ZHJhZnQtbWNncmV3IGlzIGJldHRlci48L3NwYW4+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZndDsgPC9zcGFuPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIic+SXQgcmVxdWlyZXMgZ2VuZXJhdGluZyBhbmQgYWRkaW5nIHNwZWNpZmljIHBhZGRpbmcg Ynl0ZXMuPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5U aGV5IGJvdGggYWRkIGlkZW50aWNhbCBwYWRkaW5nLiBkcmFmdC1tY2dyZXcgc3BlbGxzIGl0IG91 dDsgPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QTEyOENCQytIUzI1NiBqdXN0IHJlZmVy cyB0byBQS0NTICM1IHBhZGRpbmcgKHdpdGhvdXQgbXVjaCBvZiBhIHJlZmVyZW5jZSkuPC9zcGFu PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4mZ3Q7IEl0IHByZWZpeGVzIHRoZSBjaXBoZXJ0 ZXh0IHdpdGggdGhlIElWLjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+R29vZCBkZXNpZ24uIEJ1dCBpZiBKT1NFIGluc2lzdHMgb24gc2VwYXJhdGUgQjY0 LWVuY29kZWQgZmllbGRzIGl0IGlzIHRyaXZpYWwgdG8gY29udmVydC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiZndDsgSXQgaW5j bHVkZXMgdGhlIGxlbmd0aCBvZiB0aGUgJnF1b3Q7YWRkaXRpb25hbCBhdXRoZW50aWNhdGVkIGRh dGEmcXVvdDsgaW4gdGhlIE1BQyBjYWxjdWxhdGlvbi48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkdyZWF0IGRlc2lnbi4gPC9zcGFuPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+QTEyOENCQytIUzI1NiwgaW4gY29udHJhc3QsIHJlbGllcyBvbiBhbiBleHRy YSBCNjQtZW5jb2Rpbmcgc3RlcCB0byBzYWZlbHkgZGlzdGluZ3Vpc2gg4oCcYWRkaXRpb25hbCBk YXRh4oCdIGFuZCDigJxjaXBoZXJ0ZXh04oCdLiBBMTI4Q0JDK0hTMjU2IGhhcyB0byBNQUMgdXAg dG8gMzMlIG1vcmUgYnl0ZXMgdGhhbiBkcmFmdC1tY2dyZXcgKHdoZW4gdGhlIHBsYWludGV4dCBz aXplIGRvbWluYXRlcykuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5XaGlsZSBnZW5lcmFsLXB1cnBvc2Ug Y3J5cHRvIGxpYnJhcmllcyBvbmx5IGltcGxlbWVudCB0aGUgQUVTICZhbXA7IEhNQUMgY29tcG9u ZW50cyBidXQgbm90IHRoZSBBRUFEIGNvbWJpbmF0aW9uIChhbmQgQTEyOENCQytIUzI1NiBpcyBv bmx5IGFwcGxpZWQgdG8gc21hbGwgbWVzc2FnZXMpLCBpdCBkb2VzbuKAmXQgbWF0dGVyIG11Y2gu IEhvd2V2ZXIsIG9uY2UgY3J5cHRvIGxpYnJhcmllcyBvZmZlciBBRUFEIEFQSXMgaXQgZG9lcy4g QTEyOENCQytIUzI1NiByZXF1aXJlcyB0aGUg4oCcaW5zaWRl4oCdIG9mIHRoZSBjcnlwdG8gQVBJ IHRvIGhhdmUgdGhlIHJhdyBhbmQgQjY0IGRhdGEgYnV0IG9ubHkgb25lIGZvcm0gd2lsbCBiZSBw YXNzZWQgYWNyb3NzIHRoZSBBUEkuIFRoYXQgbG9ja3MgaW4gZHVwbGljYXRlZCBlZmZvcnQgYW5k IG92ZXJoZWFkIHNvIG11Y2ggc28gdGhhdCBJIGV4cGVjdCBnZW5lcmFsIHB1cnBvc2UgY3J5cHRv IGxpYnJhcmllcyB3aWxsIHN1cHBvcnQgZHJhZnQtbWNncmV3IGJ1dCBub3QgQTEyOENCQytIUzI1 Ni48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiInPiZndDsgSXQgY29tYmluZXMgdGhlIHR3byBvdXRwdXRzIGludG8gb25lLjwvc3Bhbj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QWdhaW4gZ29vZCBkZXNp Z24sIGJ1dCB0cml2aWFsIHRvIHNlcGFyYXRlIGlmIGRlc2lyZWQuPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+Qm90aCBKV0EgYW5kIGRyYWZ0PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+LW1jZ3JldyByZWZlciB0byBSRkMgNTExNiDigJxBbiBJbnRlcmZhY2UgYW5kIEFsZ29y aXRobXMgZm9yIEF1dGhlbnRpY2F0ZWQgRW5jcnlwdGlvbuKAnS4gSk9TRSBzaG91bGQgZm9sbG93 IHRoZSBwYXR0ZXJuIHNwZWNpZmllZCBpbiB0aGF0IFJGQywgd2hpY2ggPC9zcGFuPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+ZHJhZnQ8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4tbWNncmV3 IGRvZXMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi0tPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkphbWVzIE1hbmdlcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0 Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IE1pY2hh ZWwgSm9uZXMgW21haWx0bzptaWNoYWVsX2Jfam9uZXNAaG90bWFpbC5jb21dIDxicj48Yj5TZW50 OjwvYj4gTW9uZGF5LCAxMiBOb3ZlbWJlciAyMDEyIDEyOjMxIFBNPGJyPjxiPlRvOjwvYj4gTWFu Z2VyLCBKYW1lcyBIOyBqb3NlQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSRTogW2pvc2Vd IENob2ljZSBmb3IgV0c6IFVzZSBhIEtERiB3aXRoIEFFUyBDQkMgb3IgdXNlIGEgbG9uZ2VyIGtl eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Vc2luZyBk cmFmdC1tY2dyZXctYWVhZC1hZXMtY2JjLWhtYWMtc2hhMiBpcyBub3QgdGhlIHNhbWUgdGhpbmcg YXMgKDEpLiZuYnNwOyBGb3IgaW5zdGFuY2UsIGFzIHdhcyBkaXNjdXNzZWQgYWZ0ZXIgRGF2aWQn cyBwcmVzZW50YXRpb24gYXQgSUVURiA4NCwgZHJhZnQtbWNncmV3LWFlYWQtYWVzLWNiYy1obWFj LXNoYTIgZG9lcyBub3QgZm9sbG93IHRoZSBwYXR0ZXJuIG9mIEFFQUQgYWxnb3JpdGhtcyBzdWNo IGFzIEFFUyBHQ00sIHdoaWNoIGhhdmUgdHdvIGlucHV0cyAocGxhaW50ZXh0LCAmcXVvdDthZGRp dGlvbmFsIGF1dGhlbnRpY2F0ZWQgZGF0YSZxdW90OyksIGFuZCB0d28gb3V0cHV0cyAoY2lwaGVy dGV4dCwgJnF1b3Q7YXV0aGVudGljYXRpb24gdGFnJnF1b3Q7KS4mbmJzcDsgSW5zdGVhZCwgaXQg YWRkcyBhIHN0ZXAgY29tYmluaW5nIHRoZSBjaXBoZXJ0ZXh0IGFuZCAmcXVvdDthdXRoZW50aWNh dGlvbiB0YWcmcXVvdDsgb3V0cHV0cy48YnI+Jm5ic3A7PGJyPklmIHlvdSByZWFkIHRoZSBkcmFm dCwgaW1wbGVtZW50YXRpb24gb2YgZHJhZnQtbWNncmV3LWFlYWQtYWVzLWNiYy1obWFjLXNoYTIg aGFzIGEgbG90IG1vcmUgc3RlcHMgdGhhbiB3aGF0IHdlIGhhdmUgZm9yIEExMjhDQkMrSFMyNTYg YW5kIEEyNTZDQkMrSFM1MTIuJm5ic3A7IEl0IHJlcXVpcmVzIGdlbmVyYXRpbmcgYW5kIGFkZGlu ZyBzcGVjaWZpYyBwYWRkaW5nIGJ5dGVzLiZuYnNwOyBJdCBwcmVmaXhlcyB0aGUgY2lwaGVydGV4 dCB3aXRoIHRoZSBJVi4mbmJzcDsgSXQgaW5jbHVkZXMgdGhlIGxlbmd0aCBvZiB0aGUgJnF1b3Q7 YWRkaXRpb25hbCBhdXRoZW50aWNhdGVkIGRhdGEmcXVvdDsgaW4gdGhlIE1BQyBjYWxjdWxhdGlv bi4mbmJzcDsgSXQgY29tYmluZXMgdGhlIHR3byBvdXRwdXRzIGludG8gb25lLiZuYnNwOyBGb3Ig ZGVjcnlwdGlvbiwgbGlrZXdpc2UsIHRoZSB0d28gb3V0cHV0cyBtdXN0IGJlIHNwbGl0IGFwYXJ0 LCB0aGUgSVYgbXVzdCBiZSBzcGxpdCBhcGFydCwgZXRjLjxicj4mbmJzcDs8YnI+QWxsIG9mIHRo ZXNlIGFyZSBzdGVwcyB0aGF0IGltcGxlbWVudGF0aW9ucyBjb3VsZCBnZXQgd3JvbmcsIHJlc3Vs dGluZyBpbiBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zLiZuYnNwOyBCeSBrZWVwaW5nIGFsbCB0 aGUgcGFyYW1ldGVycyBzZXBhcmF0ZSwgb3VyIGN1cnJlbnQgQTEyOENCQytIUzI1NiBhbmQgQTI1 NkNCQytIUzUxMiBhbGdvcml0aG1zIGVsaW1pbmF0ZSB0aG9zZSBzdGVwcy48YnI+Jm5ic3A7PGJy PkknbSBzb3JyeSBmb3IgdGhlIGFwcGFyZW50IGNvbmZ1c2lvbiBiZXR3ZWVuICgxKSBhbmQgZHJh ZnQtbWNncmV3LWFlYWQtYWVzLWNiYy1obWFjLXNoYTIuJm5ic3A7IFdoaWxlIHRoZXkgYm90aCBl eHBsaWNpdGx5IHJlcHJlc2VudCB0aGUgQ01LIGFuZCBDRUssIGFuZCB1c2UgdGhlIHNhbWUgdW5k ZXJseWluZyBjcnlwdG8gb3BlcmF0aW9ucywgdGhlIGRldGFpbHMgZGlmZmVyIGluIHdheXMgdGhh dCBhcmUgbGlrZWx5IHRvIG1hdHRlciB0byBpbXBsZW1lbnRlcnMuJm5ic3A7IElmIHRoZXJlIHdh cyBhIHZlcnNpb24gb2YgZHJhZnQtbWNncmV3LWFlYWQtYWVzLWNiYy1obWFjLXNoYTIgdGhhdCBr ZXB0IGFsbCB0aGUgaW5wdXRzIGFuZCBvdXRwdXRzIHNlcGFyYXRlLCBJIGFncmVlIHRoYXQgaXQg d291bGQgYmUgYSByZWFzb25hYmxlIGNhbmRpZGF0ZSBmb3IgSk9TRSB0byBjb25zaWRlci4mbmJz cDsgQnV0IHVubGlrZSBBRVMgR0NNLCB0aGF0J3Mgbm90IHdoYXQgaXQgZG9lcy48YnI+Jm5ic3A7 PGJyPi0tIE1pa2U8YnI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIic+Jmd0OyBGcm9tOiA8YSBocmVmPSJtYWlsdG86SmFtZXMuSC5NYW5n ZXJAdGVhbS50ZWxzdHJhLmNvbSI+SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbTwvYT48 YnI+Jmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOm1pY2hhZWxfYl9qb25lc0Bob3RtYWlsLmNvbSI+ bWljaGFlbF9iX2pvbmVzQGhvdG1haWwuY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmpvc2VAaWV0 Zi5vcmciPmpvc2VAaWV0Zi5vcmc8L2E+PGJyPiZndDsgRGF0ZTogTW9uLCAxMiBOb3YgMjAxMiAw OToyMzozNyArMTEwMDxicj4mZ3Q7IFN1YmplY3Q6IFJFOiBbam9zZV0gQ2hvaWNlIGZvciBXRzog VXNlIGEgS0RGIHdpdGggQUVTIENCQyBvciB1c2UgYSBsb25nZXIga2V5PGJyPiZndDsgPGJyPiZn dDsgJmd0OyBTbyBJ4oCZZCBsaWtlIHRvIGV4cGxpY2l0bHkgYXNrIHRoZSB3b3JraW5nIGdyb3Vw LiBEbyB5b3Ugd2FudCB1cyB0bzo8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAoMSkgVXNlIHRo ZSBjb25jYXRlbmF0aW9uIG9mIHJhbmRvbSBDRUsgYW5kIENJSyB2YWx1ZXMgYXMgdGhlIENNSyBm b3IgQUVTIENCQywgcmVzdWx0aW5nIGluIGEgbG9uZ2VyIENNSz88YnI+Jmd0OyAmZ3Q7ICgyKSBD b250aW51ZSB0byB1c2UgYSBLREYgdG8gZ2VuZXJhdGUgdGhlIENFSyBhbmQgQ0lLIGZyb20gYSBz aG9ydGVyIENNSz88YnI+Jmd0OyA8YnI+Jmd0OyA8YnI+Jmd0OyAxLiBVc2UgZHJhZnQtbWNncmV3 LWFlYWQtYWVzLWNiYy1obWFjLXNoYTI8YnI+Jmd0OyA8YnI+Jmd0OyAtLTxicj4mZ3Q7IEphbWVz IE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jv ZHk+PC9odG1sPg== --_000_255B9BB34FB7D647A506DC292726F6E1150045CB9FWSMSG3153Vsrv_-- From michael_b_jones@hotmail.com Sun Nov 11 19:15: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 3694621F8462 for ; Sun, 11 Nov 2012 19:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuZmQiYPUyGY for ; Sun, 11 Nov 2012 19:15:18 -0800 (PST) Received: from bay0-omc1-s18.bay0.hotmail.com (bay0-omc1-s18.bay0.hotmail.com [65.54.190.29]) by ietfa.amsl.com (Postfix) with ESMTP id 2F06821F8448 for ; Sun, 11 Nov 2012 19:15:18 -0800 (PST) Received: from BAY171-W60 ([65.54.190.59]) by bay0-omc1-s18.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Nov 2012 19:15:17 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_e8e2c224-9c83-4fda-b1e1-baad963323fe_" X-Originating-IP: [50.47.91.23] From: Michael Jones To: , Date: Sun, 11 Nov 2012 19:15:17 -0800 Importance: Normal In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150045CB9F@WSMSG3153V.srv.dir.telstra.com> References: , , <255B9BB34FB7D647A506DC292726F6E11500331CA9@WSMSG3153V.srv.dir.telstra.com>, , <255B9BB34FB7D647A506DC292726F6E1150045CB9F@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Nov 2012 03:15:17.0719 (UTC) FILETIME=[F0D28670:01CDC083] Subject: Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer 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: Mon, 12 Nov 2012 03:15:19 -0000 --_e8e2c224-9c83-4fda-b1e1-baad963323fe_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I'm not sure why you're saying that combing fields with distinct meanings i= s good design. It just means extra=2C unnecessary steps. The pattern used= by AES GCM=2C which keeps fields with distinct meanings separate=2C seems = more general and cleaner to me. I think this may be one of those points whe= re we may just have to agree to disagree=2C because it doesn't seem that th= at either of us is convincing the other. =3B-) Cheers=2C-- Mike From: James.H.Manger@team.telstra.com To: michael_b_jones@hotmail.com=3B jose@ietf.org Date: Mon=2C 12 Nov 2012 14:06:46 +1100 Subject: Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer k= ey > Using draft-mcgrew-aead-aes-cbc-hmac-sha2 is not the same thing as (1). = Then change my vote to: (1b) Use draft-mcgrew-aead-aes-cbc-hmac-sha2 I know= draft-mcgrew-aead-aes-cbc-hmac-sha2 is not quite the same as A128CBC+HS256= -without-a-KDF. There are a handful of =93distinctions-without-a-difference= =94 and some differences that are subtle but important where draft-mcgrew i= s better. > It requires generating and adding specific padding bytes. They = both add identical padding. draft-mcgrew spells it out=3B A128CBC+HS256 jus= t refers to PKCS #5 padding (without much of a reference). > It prefixes th= e ciphertext with the IV. Good design. But if JOSE insists on separate B64-= encoded fields it is trivial to convert. > It includes the length of the "a= dditional authenticated data" in the MAC calculation. Great design. A128CBC= +HS256=2C in contrast=2C relies on an extra B64-encoding step to safely dis= tinguish =93additional data=94 and =93ciphertext=94. A128CBC+HS256 has to M= AC up to 33% more bytes than draft-mcgrew (when the plaintext size dominate= s). While general-purpose crypto libraries only implement the AES & HMAC co= mponents but not the AEAD combination (and A128CBC+HS256 is only applied to= small messages)=2C it doesn=92t matter much. However=2C once crypto librar= ies offer AEAD APIs it does. A128CBC+HS256 requires the =93inside=94 of the= crypto API to have the raw and B64 data but only one form will be passed a= cross the API. That locks in duplicated effort and overhead so much so that= I expect general purpose crypto libraries will support draft-mcgrew but no= t A128CBC+HS256. > It combines the two outputs into one. Again good design= =2C but trivial to separate if desired. Both JWA and draft-mcgrew refer to= RFC 5116 =93An Interface and Algorithms for Authenticated Encryption=94. J= OSE should follow the pattern specified in that RFC=2C which draft-mcgrew d= oes. --James Manger From: Michael Jones [mailto:michael_b_jones@hotmail.com= ]=20 Sent: Monday=2C 12 November 2012 12:31 PM To: Manger=2C James H=3B jose@ietf.org Subject: RE: [jose] Choice for WG: Use a KDF with AES CBC or use a longer k= ey Using draft-mcgrew-aead-aes-cbc-hmac-sha2 is not the same thing as (1). = For instance=2C as was discussed after David's presentation at IETF 84=2C = draft-mcgrew-aead-aes-cbc-hmac-sha2 does not follow the pattern of AEAD alg= orithms such as AES GCM=2C which have two inputs (plaintext=2C "additional = authenticated data")=2C and two outputs (ciphertext=2C "authentication tag"= ). Instead=2C it adds a step combining the ciphertext and "authentication = tag" outputs. =20 If you read the draft=2C implementation of draft-mcgrew-aead-aes-cbc-hmac-s= ha2 has a lot more steps than what we have for A128CBC+HS256 and A256CBC+HS= 512. It requires generating and adding specific padding bytes. It prefixe= s the ciphertext with the IV. It includes the length of the "additional au= thenticated data" in the MAC calculation. It combines the two outputs into= one. For decryption=2C likewise=2C the two outputs must be split apart=2C= the IV must be split apart=2C etc. =20 All of these are steps that implementations could get wrong=2C resulting in= interoperability problems. By keeping all the parameters separate=2C our = current A128CBC+HS256 and A256CBC+HS512 algorithms eliminate those steps. =20 I'm sorry for the apparent confusion between (1) and draft-mcgrew-aead-aes-= cbc-hmac-sha2. While they both explicitly represent the CMK and CEK=2C and= use the same underlying crypto operations=2C the details differ in ways th= at are likely to matter to implementers. If there was a version of draft-m= cgrew-aead-aes-cbc-hmac-sha2 that kept all the inputs and outputs separate= =2C I agree that it would be a reasonable candidate for JOSE to consider. = But unlike AES GCM=2C that's not what it does. =20 -- Mike > From: James.H.Manger@team.telstra.com > To: michael_b_jones@hotmail.com=3B jose@ietf.org > Date: Mon=2C 12 Nov 2012 09:23:37 +1100 > Subject: RE: [jose] Choice for WG: Use a KDF with AES CBC or use a longer= key >=20 > > So I=92d like to explicitly ask the working group. Do you want us to: > > > > (1) Use the concatenation of random CEK and CIK values as the CMK for A= ES CBC=2C resulting in a longer CMK? > > (2) Continue to use a KDF to generate the CEK and CIK from a shorter CM= K? >=20 >=20 > 1. Use draft-mcgrew-aead-aes-cbc-hmac-sha2 >=20 > -- > James Manger _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose = --_e8e2c224-9c83-4fda-b1e1-baad963323fe_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I'm not sure why you're saying that combing fields with distinct meanings i= s good design. =3B It just means extra=2C unnecessary steps. =3B Th= e pattern used by AES =3BGCM=2C which keeps fields with distinct meanin= gs =3Bseparate=2C seems more general and cleaner to me.
 =3B
= I think this may be one of those points where we may just have to agree to = disagree=2C because it doesn't seem that that either of us is convincing th= e other. =3B-)

Cheers=2C
-- Mike =3B
From: James.H.Manger@team.tel= stra.com
To: michael_b_jones@hotmail.com=3B jose@ietf.org
Date: Mon= =2C 12 Nov 2012 14:06:46 +1100
Subject: Re: [jose] Choice for WG: Use a = KDF with AES CBC or use a longer key

>=3B = Using draft-mcgrew-aead-aes-cbc-hmac-sha2 is not the same thing as (1).&nbs= p=3B

 =3B

Then change my vote to:

=

 =3B

(1b) Use draft-= mcgrew-aead-aes-cbc-hmac-sha2

 =3B

I know draft-mcgrew-aead-aes-cbc-hmac-sha2 is not quite the same as A128CBC+HS= 256-without-a-KDF. There are a handful of =93distinctions-without-a-differe= nce=94 and some differences that are subtle but important where draft-mcgrew is better.

 =3B

>=3B It requires generating and adding specific padding= bytes.

 =3B

They both add identical padding. = draft-mcgrew spells it out=3B A128CB= C+HS256 just refers to PKCS #5 padding (without much of a reference).

 =3B

>= =3B It prefixes the ciphertext with the IV.

 =3B

Good design. But if JOSE insists on separate B64-encoded fields it is = trivial to convert.

 =3B

>=3B It include= s the length of the "additional authenticated data" in the MAC calculation.=

 =3B

Great design. A128CBC+HS256=2C in contrast=2C relies on an extra B64-encodin= g step to safely distinguish =93additional data=94 and =93ciphertext=94. A1= 28CBC+HS256 has to MAC up to 33% more bytes than draft-mcgrew (when the pla= intext size dominates).

 =3B

While general-purpose crypto libraries only implement = the AES &=3B HMAC components but not the AEAD combination (and A128CBC+H= S256 is only applied to small messages)=2C it doesn=92t matter much. Howeve= r=2C once crypto libraries offer AEAD APIs it does. A128CBC+HS256 requires = the =93inside=94 of the crypto API to have the raw and B64 data but only on= e form will be passed across the API. That locks in duplicated effort and o= verhead so much so that I expect general purpose crypto libraries will supp= ort draft-mcgrew but not A128CBC+HS256.

 =3B

>=3B It combines the two outputs into one.

 =3B

Again good design=2C but trivial to separate if desired.

 =3B<= /p>

 =3B

Both JWA a= nd draft-mcgrew refer to RFC 5116 = =93An Interface and Algorithms for Authenticated Encryption=94. JOSE should= follow the pattern specified in that RFC=2C which draft-mcgrew does.

 =3B<= /span>

--=

James = Manger

 =3B

From:<= span style=3D'font-family: "Tahoma"=2C"sans-serif"=3B font-size: 10pt=3B' l= ang=3D"EN-US"> Michael Jones [mailto:michael_b_jones@hotmail.com]
Se= nt: Monday=2C 12 November 2012 12:31 PM
To: Manger=2C James H= =3B jose@ietf.org
Subject: RE: [jose] Choice for WG: Use a KDF wi= th AES CBC or use a longer key

 =3B

Using draft-mcgrew-aead-aes-= cbc-hmac-sha2 is not the same thing as (1). =3B For instance=2C as was = discussed after David's presentation at IETF 84=2C draft-mcgrew-aead-aes-cb= c-hmac-sha2 does not follow the pattern of AEAD algorithms such as AES GCM= =2C which have two inputs (plaintext=2C "additional authenticated data")=2C= and two outputs (ciphertext=2C "authentication tag"). =3B Instead=2C i= t adds a step combining the ciphertext and "authentication tag" outputs. =3B
If you read the draft=2C implementation of draft-mcgrew-aead-a= es-cbc-hmac-sha2 has a lot more steps than what we have for A128CBC+HS256 a= nd A256CBC+HS512. =3B It requires generating and adding specific paddin= g bytes. =3B It prefixes the ciphertext with the IV. =3B It include= s the length of the "additional authenticated data" in the MAC calculation.=  =3B It combines the two outputs into one. =3B For decryption=2C li= kewise=2C the two outputs must be split apart=2C the IV must be split apart= =2C etc.
 =3B
All of these are steps that implementations could g= et wrong=2C resulting in interoperability problems. =3B By keeping all = the parameters separate=2C our current A128CBC+HS256 and A256CBC+HS512 algo= rithms eliminate those steps.
 =3B
I'm sorry for the apparent con= fusion between (1) and draft-mcgrew-aead-aes-cbc-hmac-sha2. =3B While t= hey both explicitly represent the CMK and CEK=2C and use the same underlyin= g crypto operations=2C the details differ in ways that are likely to matter= to implementers. =3B If there was a version of draft-mcgrew-aead-aes-c= bc-hmac-sha2 that kept all the inputs and outputs separate=2C I agree that = it would be a reasonable candidate for JOSE to consider. =3B But unlike= AES GCM=2C that's not what it does.
 =3B
-- Mike
 =3B

>=3B From: James.H.Manger@team.telstra.com
>=3B T= o: michael_b_jones@hotmail.c= om=3B jose@ietf.org
>=3B Date= : Mon=2C 12 Nov 2012 09:23:37 +1100
>=3B Subject: RE: [jose] Choice fo= r WG: Use a KDF with AES CBC or use a longer key
>=3B
>=3B >= =3B So I=92d like to explicitly ask the working group. Do you want us to:>=3B >=3B
>=3B >=3B (1) Use the concatenation of random CEK an= d CIK values as the CMK for AES CBC=2C resulting in a longer CMK?
>=3B= >=3B (2) Continue to use a KDF to generate the CEK and CIK from a shorte= r CMK?
>=3B
>=3B
>=3B 1. Use draft-mcgrew-aead-aes-cbc-hma= c-sha2
>=3B
>=3B --
>=3B James Manger


_______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose
= --_e8e2c224-9c83-4fda-b1e1-baad963323fe_-- From michael_b_jones@hotmail.com Sun Nov 11 19:51:54 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 4396021F84A0 for ; Sun, 11 Nov 2012 19:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31YyKJT8IcX7 for ; Sun, 11 Nov 2012 19:51:53 -0800 (PST) Received: from bay0-omc1-s27.bay0.hotmail.com (bay0-omc1-s27.bay0.hotmail.com [65.54.190.38]) by ietfa.amsl.com (Postfix) with ESMTP id 3456521F849C for ; Sun, 11 Nov 2012 19:51:53 -0800 (PST) Received: from BAY171-W79 ([65.54.190.60]) by bay0-omc1-s27.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Nov 2012 19:51:51 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_922cd14d-f2ef-4b88-a50b-d9b786287de5_" X-Originating-IP: [50.47.91.23] From: Michael Jones To: , Date: Sun, 11 Nov 2012 19:51:51 -0800 Importance: Normal In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11500331F3B@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B168042967394366880D09@TK5EX14MBXC285.redmond.corp.microsoft.com>, , , , <4E1F6AAD24975D4BA5B16804296739436688123A@TK5EX14MBXC285.redmond.corp.microsoft.com>, , , , , , <4E1F6AAD24975D4BA5B16804296739436688296F@TK5EX14MBXC285.redmond.corp.microsoft.com>, , , , <255B9BB34FB7D647A506DC292726F6E114FFB9FC5D@WSMSG3153V.srv.dir.telstra.com>, , <255B9BB34FB7D647A506DC292726F6E115001D5886@WSMSG3153V.srv.dir.telstra.com>, , <255B9BB34FB7D647A506DC292726F6E11500331F3B@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Nov 2012 03:51:51.0845 (UTC) FILETIME=[0C9F9550:01CDC089] Subject: Re: [jose] NIST Concat KDF 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, 12 Nov 2012 03:51:54 -0000 --_922cd14d-f2ef-4b88-a50b-d9b786287de5_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable As background=2C the NIST Concat KDF was chosen over the TLS 1.2 PRF becaus= e it was already specified for use with key agreement in XML ENC=2C whereas= the TLS PRF is a one-off. It was thought that=2C particularly for key agr= eement=2C libraries were more likely to support key agreement using Concat = than a custom KDF=2C making JWE implementations easier. The authors also d= ecided that it made sense to use the same KDF both for key agreement and to= derive CEK and CIK values from a CMK value=2C to make life easier for impl= ementers. Hence=2C the use of Concat for both use cases. You wrote that "i= t demonstrably doesn't meets Concat=92s security design (e.g. JOSE can deri= ve the same key for diff user ids as JOSE can omit the ids from the calcula= tion)". It's true that JOSE could derive the same key for different users= =2C but only if the two users use the same CMK value=2C which the spec requ= ires to be randomly generated for each interaction. If an implementation i= s repeatedly generating THE SAME 256 or 512 bit random numbers=2C I suspect= it has bigger problems than the ones we're talking about. I'll also point= out that draft-mcgrew-aead-aes-cbc-hmac-sha2 puts all its eggs in the bask= et of the random number generator=2C and you seem to be in favor of that. = By using Concat without PartyUInfo and PartyVInfo fields=2C we'd be no wors= e off than mcgrew. As for me=2C I'd be perfectly happy to change the drafts= to say something like "a KDF based upon the Concat KDF" (or to not mention= Concat at all)=2C drop the PartyUInfo and PartyVInfo parameters and be don= e with it. The TLS PRF doesn't use them and it seems to be fine. It doesn= 't sound you like them either. Might that be a resolution to this whole lo= ng discussion? My only worry is that we might get push-back from the secur= ity community as a result. Feedback from others would be appreciated. Than= ks=2C-- Mike P.S. The AlgorithmID/PartyUInfo ambiguity you describe is not= possible because the only two "enc" values that use Concat in this way are= "A128CBC+HS256" and "A256CBC+HS512". It truly is fixed length. The behav= ior of other "enc" values are beyond the scope of this particular discussio= n. > From: James.H.Manger@team.telstra.com > To: michael_b_jones@hotmail.com=3B jose@ietf.org > Date: Mon=2C 12 Nov 2012 10:45:32 +1100 > Subject: Re: [jose] NIST Concat KDF >=20 > Mike=2C >=20 > > By adding the length prefix to the PartyUInfo and PartyVInfo values=2C = I fail to see how the JoBethAnne ambiguity could remain possible. I addres= sed that per your earlier note in the -07 drafts by adding the length prefi= x. >=20 > The JoBeth/Anne vs Jo/BethAnne ambiguity is solved. An AlgorithmID/PartyU= Info ambiguity remains. It feels more theoretical=2C but it simply does not= need to exist. The following 2 JOSE messages produce the same KDF input. T= hey shouldn't. It is the sort of situation NIST Concat KDF is specifically = designed to avoid. >=20 > {"alg":"A128CBC+HS256\u0000\u0000\u0000\u0007X"=2C "epu":"Jo"=2C "epv":= "BethAnne"} >=20 > {"alg":"A128CBC+HS256"=2C "epu":"X\u0000\u0000\u0000\u0002Jo"=2C "epv":= "BethAnne"} =20 >=20 >=20 > > You wrote that the AlgorithmID doesn=92t have a length prefix. That=92= s true. The Concat definition allows fields to not contain a length prefix= when they are fixed length=2C as AlgorithmID is in this case. >=20 > AlgorithmID includes the value of the "enc" field=2C which is hardly fixe= d length. >=20 >=20 >=20 > > You wrote =93Can=92t the spec just do what NIST 800-56A says if it real= ly wants to use it?=94. I suspect that underlying this comment is the actu= al difference you have with the specs=92 use of Concat. It=92s not a goal = of JWA to make it possible to use every feature of Concat. (Concat isn=92t = an end unto itself.) Hence the spec not needing to use SuppPrivInfo=2C etc= . >=20 > I have no desire to use SuppPrivInfo. I am completely fine with JOSE sayi= ng it must be omitted. I don't really even want to use PartyUInfo and Party= VInfo. NIST 800-56A Concat KDF=2C however=2C is designed to ensure the same= key cannot be derived if the algorithm=2C the id of either party=2C or any= other important detail of the context is different. If JOSE says it uses C= oncat it needs to deliver these properties. If JOSE does not need these pro= perties then it shouldn't falsely imply it achieves them by saying it uses = Concat. >=20 >=20 > > The actual goal is generating two high-quality keys from the CMK. >=20 > Great. Then drop the apu/apv/epu/epv stuff and don't call it NIST Concat. >=20 >=20 > > As for whether we use Concat twice to generate two keys with different = inputs and then discard the random value or whether we use Concat once to g= enerate a long enough output to chop it into two keys=2C that seems like a = distinction without a difference. >=20 > It probably is a distinction without a difference. So why do you bother m= aking the distinction from the NIST Concat KDF that JOSE says it uses? That= just unnecessarily raises a shadow of doubt. >=20 >=20 > > I reviewed this decision with Jim Schaad a while back=2C among others= =2C and they concurred. The precedent for this is the TLS PRF KDF [RFC5246= ]=2C which generates keys in this manner. >=20 > Then use the TLS 1.2 PRF=2C instead of NIST Concat. >=20 >=20 > > Unless there=92s an actual security argument that this (widely used) pr= actice is demonstrably unsafe=2C there doesn=92t seem to be a reason to cha= nge. >=20 > JOSE says it uses NIST Concat=3B it demonstrably doesn't meets Concat=92s= security design (eg JOSE can derive the same key for diff user ids as JOSE= can omit the ids from the calculation)=3B so there is a reason to change. >=20 >=20 > > I=92m trying to have us not lose sight of the fact that a core goal of = the JOSE specs is to create specs that are simple enough that they will act= ually be implemented and used. >=20 > Sounds like a good reason not to pick NIST Concat=2C which chooses more c= omplexity for security in some corner cases. >=20 > -- > James Manger > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose = --_922cd14d-f2ef-4b88-a50b-d9b786287de5_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
As background=2C the NIST Concat KDF was chosen over the TLS 1.2 PRF becaus= e it was already specified for use with key agreement in XML ENC=2C whereas= the TLS PRF is a one-off. =3B It was thought that=2C particularly for = key agreement=2C libraries were more likely to support key agreement using = Concat than a custom KDF=2C making JWE implementations easier. =3B The = authors also decided that it made sense to use the same KDF both for key ag= reement and to derive CEK and CIK values from a CMK value=2C to make life e= asier for implementers. =3B Hence=2C the use of Concat for both use cas= es.
 =3B
You wrote that "it demonstrably doesn't meets Concat=92s= security design (e.g. JOSE can derive the same key for diff user ids as JO= SE can omit the ids from the calculation)". =3B It's true that JOSE cou= ld derive the same key for different users=2C but =3Bonly if the two us= ers use the same CMK value=2C which the spec requires to be randomly genera= ted for each interaction. =3B If an implementation is repeatedly genera= ting THE SAME 256 or 512 bit random numbers=2C I suspect it has bigger prob= lems than the ones we're talking about. =3B I'll also point out that dr= aft-mcgrew-aead-aes-cbc-hmac-sha2 puts all its eggs in the basket of the ra= ndom number generator=2C and you seem to be in favor of that. =3B By us= ing Concat without PartyUInfo and PartyVInfo fields=2C we'd be no worse off= than mcgrew.
 =3B
As for me=2C I'd be perfectly happy to change = the drafts to say something like "a KDF based upon the Concat KDF" (or to n= ot mention Concat at all)=2C drop the PartyUInfo and PartyVInfo parameters = and be done with it. =3B The TLS PRF doesn't use them and it seems to b= e fine. =3B It doesn't sound you like them either. =3B Might that b= e a resolution to this whole long discussion? =3B My only worry is that= we might get push-back from the security community as a result. =3B Fe= edback from others would be appreciated.
 =3B
Thanks=2C
-- Mik= e
 =3B
P.S. =3B The AlgorithmID/PartyUInfo ambiguity you desc= ribe =3Bis not possible because the only two "enc" values that use Conc= at in this way are "A128CBC+HS256" and "A256CBC+HS512". =3B It truly is= fixed length. =3B The behavior of other "enc" values are beyond the sc= ope of this particular discussion.

>=3B From: James.H.Manger@team.telstra.com
>=3B To: michae= l_b_jones@hotmail.com=3B jose@ietf.org
>=3B Date: Mon=2C 12 Nov 2012 1= 0:45:32 +1100
>=3B Subject: Re: [jose] NIST Concat KDF
>=3B
&= gt=3B Mike=2C
>=3B
>=3B >=3B By adding the length prefix to th= e PartyUInfo and PartyVInfo values=2C I fail to see how the JoBethAnne ambi= guity could remain possible. I addressed that per your earlier note in the= -07 drafts by adding the length prefix.
>=3B
>=3B The JoBeth/An= ne vs Jo/BethAnne ambiguity is solved. An AlgorithmID/PartyUInfo ambiguity = remains. It feels more theoretical=2C but it simply does not need to exist.= The following 2 JOSE messages produce the same KDF input. They shouldn't. = It is the sort of situation NIST Concat KDF is specifically designed to avo= id.
>=3B
>=3B {"alg":"A128CBC+HS256\u0000\u0000\u0000\u0007X"= =2C "epu":"Jo"=2C "epv":"BethAnne"}
>=3B
>=3B {"alg":"A128CBC+= HS256"=2C "epu":"X\u0000\u0000\u0000\u0002Jo"=2C "epv":"BethAnne"}
>= =3B
>=3B
>=3B >=3B You wrote that the AlgorithmID doesn=92t h= ave a length prefix. That=92s true. The Concat definition allows fields t= o not contain a length prefix when they are fixed length=2C as AlgorithmID = is in this case.
>=3B
>=3B AlgorithmID includes the value of the= "enc" field=2C which is hardly fixed length.
>=3B
>=3B
>= =3B
>=3B >=3B You wrote =93Can=92t the spec just do what NIST 800-5= 6A says if it really wants to use it?=94. I suspect that underlying this c= omment is the actual difference you have with the specs=92 use of Concat. = It=92s not a goal of JWA to make it possible to use every feature of Concat= . (Concat isn=92t an end unto itself.) Hence the spec not needing to use S= uppPrivInfo=2C etc.
>=3B
>=3B I have no desire to use SuppPrivIn= fo. I am completely fine with JOSE saying it must be omitted. I don't reall= y even want to use PartyUInfo and PartyVInfo. NIST 800-56A Concat KDF=2C ho= wever=2C is designed to ensure the same key cannot be derived if the algori= thm=2C the id of either party=2C or any other important detail of the conte= xt is different. If JOSE says it uses Concat it needs to deliver these prop= erties. If JOSE does not need these properties then it shouldn't falsely im= ply it achieves them by saying it uses Concat.
>=3B
>=3B
>= =3B >=3B The actual goal is generating two high-quality keys from the CMK= .
>=3B
>=3B Great. Then drop the apu/apv/epu/epv stuff and don't= call it NIST Concat.
>=3B
>=3B
>=3B >=3B As for whether= we use Concat twice to generate two keys with different inputs and then di= scard the random value or whether we use Concat once to generate a long eno= ugh output to chop it into two keys=2C that seems like a distinction withou= t a difference.
>=3B
>=3B It probably is a distinction without a= difference. So why do you bother making the distinction from the NIST Conc= at KDF that JOSE says it uses? That just unnecessarily raises a shadow of d= oubt.
>=3B
>=3B
>=3B >=3B I reviewed this decision with = Jim Schaad a while back=2C among others=2C and they concurred. The precede= nt for this is the TLS PRF KDF [RFC5246]=2C which generates keys in this ma= nner.
>=3B
>=3B Then use the TLS 1.2 PRF=2C instead of NIST Conc= at.
>=3B
>=3B
>=3B >=3B Unless there=92s an actual secur= ity argument that this (widely used) practice is demonstrably unsafe=2C the= re doesn=92t seem to be a reason to change.
>=3B
>=3B JOSE says = it uses NIST Concat=3B it demonstrably doesn't meets Concat=92s security de= sign (eg JOSE can derive the same key for diff user ids as JOSE can omit th= e ids from the calculation)=3B so there is a reason to change.
>=3B >=3B
>=3B >=3B I=92m trying to have us not lose sight of the fa= ct that a core goal of the JOSE specs is to create specs that are simple en= ough that they will actually be implemented and used.
>=3B
>=3B = Sounds like a good reason not to pick NIST Concat=2C which chooses more com= plexity for security in some corner cases.
>=3B
>=3B --
>= =3B James Manger
>=3B _______________________________________________<= br>>=3B jose mailing list
>=3B jose@ietf.org
>=3B https://www.i= etf.org/mailman/listinfo/jose
= --_922cd14d-f2ef-4b88-a50b-d9b786287de5_-- From stephen.farrell@cs.tcd.ie Mon Nov 12 05:14: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 8C1E721F859D for ; Mon, 12 Nov 2012 05:14:09 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPA1o7g9YgcN for ; Mon, 12 Nov 2012 05:14:05 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B061C21F859E for ; Mon, 12 Nov 2012 05:14:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 06A0EBE4D; Mon, 12 Nov 2012 13:13:41 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kq-01WIwoYIE; Mon, 12 Nov 2012 13:13:39 +0000 (GMT) Received: from [10.87.48.10] (unknown [86.41.57.92]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E490EBE47; Mon, 12 Nov 2012 13:13:38 +0000 (GMT) Message-ID: <50A0F602.7080709@cs.tcd.ie> Date: Mon, 12 Nov 2012 13:13:38 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Michael Jones References: , , <255B9BB34FB7D647A506DC292726F6E11500331CA9@WSMSG3153V.srv.dir.telstra.com>, , <255B9BB34FB7D647A506DC292726F6E1150045CB9F@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: james.h.manger@team.telstra.com, jose@ietf.org Subject: Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer 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: Mon, 12 Nov 2012 13:14:09 -0000 FWIW, I'd say asking David and/or CFRG about stuff like this ought be useful. Features that are a "don't care" from the jose WG/protocol perspective might well be important either for security reasons or because of re-use in other protocols. S. On 11/12/2012 03:15 AM, Michael Jones wrote: > > I'm not sure why you're saying that combing fields with distinct meanings is good design. It just means extra, unnecessary steps. The pattern used by AES GCM, which keeps fields with distinct meanings separate, seems more general and cleaner to me. I think this may be one of those points where we may just have to agree to disagree, because it doesn't seem that that either of us is convincing the other. ;-) > Cheers,-- Mike From: James.H.Manger@team.telstra.com > To: michael_b_jones@hotmail.com; jose@ietf.org > Date: Mon, 12 Nov 2012 14:06:46 +1100 > Subject: Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key > >> Using draft-mcgrew-aead-aes-cbc-hmac-sha2 is not the same thing as (1). Then change my vote to: (1b) Use draft-mcgrew-aead-aes-cbc-hmac-sha2 I know draft-mcgrew-aead-aes-cbc-hmac-sha2 is not quite the same as A128CBC+HS256-without-a-KDF. There are a handful of “distinctions-without-a-difference” and some differences that are subtle but important where draft-mcgrew is better. > It requires generating and adding specific padding bytes. They both add identical padding. draft-mcgrew spells it out; A128CBC+HS256 just refers to PKCS #5 padding (without much of a reference). > It prefixes the ciphertext with the IV. Good design. But if JOSE insists on separate B64-encoded fields it is trivial to convert. > It includes the length of the "additional authenticated data" in the MAC calculation. Great design. A128CBC+HS256, in contrast, relies on an extra B64-encoding step to safely distinguish “additional data” and “ciphertext”. A128CBC+HS256 has to MAC up to 33% more bytes than dra ft-mcgrew (when the plaintext size dominates). While general-purpose crypto libraries only implement the AES & HMAC components but not the AEAD combination (and A128CBC+HS256 is only applied to small messages), it doesn’t matter much. However, once crypto libraries offer AEAD APIs it does. A128CBC+HS256 requires the “inside” of the crypto API to have the raw and B64 data but only one form will be passed across the API. That locks in duplicated effort and overhead so much so that I expect general purpose crypto libraries will support draft-mcgrew but not A128CBC+HS256. > It combines the two outputs into one. Again good design, but trivial to separate if desired. Both JWA and draft-mcgrew refer to RFC 5116 “An Interface and Algorithms for Authenticated Encryption”. JOSE should follow the pattern specified in that RFC, which draft-mcgrew does. --James Manger From: Michael Jones [mailto:michael_b_jones@hotmail.com] > Sent: Monday, 12 November 2012 12:31 PM > To: Manger, James H; jose@ietf.org > Subject: RE: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key Using draft-mcgrew-aead-aes-cbc-hmac-sha2 is not the same thing as (1). For instance, as was discussed after David's presentation at IETF 84, draft-mcgrew-aead-aes-cbc-hmac-sha2 does not follow the pattern of AEAD algorithms such as AES GCM, which have two inputs (plaintext, "additional authenticated data"), and two outputs (ciphertext, "authentication tag"). Instead, it adds a step combining the ciphertext and "authentication tag" outputs. > > If you read the draft, implementation of draft-mcgrew-aead-aes-cbc-hmac-sha2 has a lot more steps than what we have for A128CBC+HS256 and A256CBC+HS512. It requires generating and adding specific padding bytes. It prefixes the ciphertext with the IV. It includes the length of the "additional authenticated data" in the MAC calculation. It combines the two outputs into one. For decryption, likewise, the two outputs must be split apart, the IV must be split apart, etc. > > All of these are steps that implementations could get wrong, resulting in interoperability problems. By keeping all the parameters separate, our current A128CBC+HS256 and A256CBC+HS512 algorithms eliminate those steps. > > I'm sorry for the apparent confusion between (1) and draft-mcgrew-aead-aes-cbc-hmac-sha2. While they both explicitly represent the CMK and CEK, and use the same underlying crypto operations, the details differ in ways that are likely to matter to implementers. If there was a version of draft-mcgrew-aead-aes-cbc-hmac-sha2 that kept all the inputs and outputs separate, I agree that it would be a reasonable candidate for JOSE to consider. But unlike AES GCM, that's not what it does. > > -- Mike > > From: James.H.Manger@team.telstra.com >> To: michael_b_jones@hotmail.com; jose@ietf.org >> Date: Mon, 12 Nov 2012 09:23:37 +1100 >> Subject: RE: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key >> >>> So I’d like to explicitly ask the working group. Do you want us to: >>> >>> (1) Use the concatenation of random CEK and CIK values as the CMK for AES CBC, resulting in a longer CMK? >>> (2) Continue to use a KDF to generate the CEK and CIK from a shorter CMK? >> >> >> 1. Use draft-mcgrew-aead-aes-cbc-hmac-sha2 >> >> -- >> 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 > From mcgrew@cisco.com Mon Nov 12 08:44: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 A4FD821F86D0 for ; Mon, 12 Nov 2012 08:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZEwrVhD3jJB for ; Mon, 12 Nov 2012 08:44:41 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B4F0A21F86DC for ; Mon, 12 Nov 2012 08:43:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10789; q=dns/txt; s=iport; t=1352738607; x=1353948207; h=from:to:cc:subject:date:message-id:mime-version; bh=XzeLjQt1rOcPN6T03lPvTprHl2FAY281Z7UuIveotfo=; b=LwML1aD45ZauJ3TL18qcTmBHCqJFyrA5NhwnwPMK9fa9MvkJfTZ5wc0F abKPbhmkmcgGBFkHdgmiHZLWOIT/fZWfLqYoJYCA7MN2ukc/9LuQfj43s uG5kxSKmjoZGleMo9I0ZZkjTNxtSneWykby9NL6auMJ9IBAlNJ9xXCIyy w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioJAIImoVCtJV2a/2dsb2JhbABEgkmuaZAqgX2BAQeCHgEBAQMBEgFmBQ0BGQMBAgtWHQoEDg0TB4dWAwkGC5oOlggDGolEjBWFaWEDlxiNPIFrgm+CGQ X-IronPort-AV: E=McAfee;i="5400,1158,6893"; a="141342082" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 12 Nov 2012 16:43:23 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qACGhNgq002323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Nov 2012 16:43:23 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 10:43:22 -0600 From: "David McGrew (mcgrew)" To: "michael_b_jones@hotmail.com" Thread-Topic: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key Thread-Index: AQHNwPTTk66PENi2xEKklkO+owUlFw== Date: Mon, 12 Nov 2012 16:43:21 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F50A90C@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.228] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19356.005 x-tm-as-result: No--40.455300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_747787E65E3FBD4E93F0EB2F14DB556B0F50A90Cxmbrcdx04ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 12 Nov 2012 09:55:56 -0800 Cc: "jose@ietf.org" Subject: [jose] Choice for WG: Use a KDF with AES CBC or use a longer 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: Mon, 12 Nov 2012 16:44:47 -0000 --_000_747787E65E3FBD4E93F0EB2F14DB556B0F50A90Cxmbrcdx04ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Mike, Please see inline. From: Michael Jones To: , Date: Sun, 11 Nov 2012 17:30:54 -0800 In-reply-to: <255B9BB34FB7D647A506DC292726F6E11500331CA9 at WSMSG3153V.srv.= dir.telstra.com> References: , <255B9BB34FB7= D647A506DC292726F6E11500331CA9 at WSMSG3153V.srv.dir.telstra.com> List-id: Javascript Object Signing and Encryption Using draft-mcgrew-aead-aes-cbc-hmac-sha2 is not the same thing as (1). For= instance, as was discussed after David's presentation at IETF 84, draft-mc= grew-aead-aes-cbc-hmac-sha2 does not follow the pattern of AEAD algorithms = such as AES GCM, which have two inputs (plaintext, "additional authenticate= d data"), and two outputs (ciphertext, "authentication tag"). Instead, it a= dds a step combining the ciphertext and "authentication tag" outputs. draft-mcgrew-aead-aes-cbc-hmac-sha2 does use exactly the same interface as = AES-GCM, RFC 5116, and the other AEAD algorithms that make use of that inte= rface. To make this more clear, I can make the following addition. Section 2.1 st= arts out as "We briefly recall the encryption interface defined in Section = 2 of [RFC5116]." I will add "which is used by all of the algorithms defi= ned in this note". If you read the draft, implementation of draft-mcgrew-aead-aes-cbc-hmac-sha= 2 has a lot more steps than what we have for A128CBC+HS256 and A256CBC+HS51= 2. It requires generating and adding specific padding bytes. It prefixes th= e ciphertext with the IV. It includes the length of the "additional authent= icated data" in the MAC calculation. It combines the two outputs into one. = For decryption, likewise, the two outputs must be split apart, the IV must = be split apart, etc. All of these are steps that implementations could get wrong, resulting in i= nteroperability problems. By keeping all the parameters separate, our curre= nt A128CBC+HS256 and A256CBC+HS512 algorithms eliminate those steps. draft-mcgrew-aead-aes-cbc-hmac-sha2 has all of the required steps for authe= nticated encryption, and does not have any extraneous steps. Things like = plaintext padding need to be specified, and it is critical to have the leng= th of the associated data included in the MAC input (see Section 6, third p= aragraph, of draft-mcgrew). The fact that implementations might get these details wrong is why they bel= ong in the crypto algorithm, and not in the JOSE implementation. Conside= r, for instance, that with the AEAD approach these details would get test c= overage from the AEAD test cases; otherwise, there are details that would g= o untested. I'm sorry for the apparent confusion between (1) and draft-mcgrew-aead-aes-= cbc-hmac-sha2. While they both explicitly represent the CMK and CEK, and us= e the same underlying crypto operations, the details differ in ways that ar= e likely to matter to implementers. When JOSE met at IETF84, the consensus of the room was to use AEAD and draf= t-mcgrew-aead-aes-cbc-hmac-sha2, and omit unauthenticated encryption. Tha= t's what JOSE should do, as it is the technically best solution. I will a= sk Kevin Igoe to move draft-mcgrew forward to RFC. If there was a version of draft-mcgrew-aead-aes-cbc-hmac-sha2 that kept al= l the inputs and outputs separate, I agree that it would be a reasonable ca= ndidate for JOSE to consider. But unlike AES GCM, that's not what it does. draft-mcgrew-aead-aes-cbc-hmac-sha2 uses the same interface as does AEAD_AE= S_128_GCM; see Section 5.1 of RFC 5116. David -- Mike > From: James.H.Manger at team.telstra.com > To: michael_b_jones at hotmail.com; jose at ietf.org > Date: Mon, 12 Nov 2012 09:23:37 +1100 > Subject: RE: [jose] Choice for WG: Use a KDF with AES CBC or use a longer= key > > > So I=92d like to explicitly ask the working group. Do you want us to: > > > > (1) Use the concatenation of random CEK and CIK values as the CMK for A= ES CBC, resulting in a longer CMK? > > (2) Continue to use a KDF to generate the CEK and CIK from a shorter CM= K? > > > 1. Use draft-mcgrew-aead-aes-cbc-hmac-sha2 > > -- > James Manger --_000_747787E65E3FBD4E93F0EB2F14DB556B0F50A90Cxmbrcdx04ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Mike,

Please see <DAM> inline.

From: Michael Jones <michael_b_jones at hotmail.com>
To: <james.h.manger at team.telstra.com>, <jose at ietf.org&g= t;
Date: Sun, 11 Nov 2012 17:30:54 -0800
In-reply-to: <255B9BB34FB7D647A506DC292726F6E11500331CA9 at WSMSG31= 53V.srv.dir.telstra.com>
References: <BAY171-W32DD53461B3DF4235F053DB7680 at phx.gbl>, &l= t;255B9BB34FB7D647A506DC292726F6E11500331CA9 at WSMSG3153V.srv.dir.telstra.= com>
List-id: Javascript Object Signing and Encryption <jose.ietf.org>= ;

Using draft-mcgrew-aead-aes-cbc-hmac-sha2 is not the same thing as (1)= . For instance, as was discussed after David's presentation at IETF 84, dra= ft-mcgrew-aead-aes-cbc-hmac-sha2 does not follow the pattern of AEAD algori= thms such as AES GCM, which have two inputs (plaintext, "additional authenticated data"), and two= outputs (ciphertext, "authentication tag"). Instead, it adds a s= tep combining the ciphertext and "authentication tag" outputs.

<DAM>
draft-mcgrew-aead-aes-cbc-hmac-sha2 does use exactly the same interfac= e as AES-GCM, RFC 5116, and the other AEAD algorithms that make use of that= interface.
To make this more clear, I can make the following addition.  Sect= ion 2.1 starts out as "We briefly recall the encryption interface defi= ned in Section 2 of  [RFC5116]."   I will add "whi= ch is used by all of the algorithms defined in this note".
</DAM>

If you read the draft, implementation of draft-mcgrew-aead-aes-cbc-hma= c-sha2 has a lot more steps than what we have for A128CBC+HS256 and A25= 6CBC+HS512. It requires generating and adding specific padding bytes. I= t prefixes the ciphertext with the IV. It includes the length of the "additional authenticated data" in th= e MAC calculation. It combines the two outputs into one. For decryption, li= kewise, the two outputs must be split apart, the IV must be split apart, et= c.

All of these are steps that implementations could get wrong, resulting= in interoperability problems. By keeping all the parameters separate, our = current A128CBC+HS256 and A256CBC+HS512 algorithms eliminate those = steps.

<DAM>
draft-mcgrew-aead-aes-cbc-hmac-sha2 has all of the required steps= for authenticated encryption, and does not have any extraneous steps. &nbs= p; Things like plaintext padding need to be specified, and it is critical t= o have the length of the associated data included in the MAC input (see Section 6, third paragraph, of draft-mcgrew).  =  

The fact that implementations might get these details wrong is why the= y belong in the crypto algorithm, and not in the JOSE implementation.  = ;  Consider, for instance, that with the AEAD approach these details w= ould get test coverage from the AEAD test cases; otherwise, there are details that would go untested.

</DAM>

I'm sorry for the apparent confusion between (1) and draft-mcgrew-aead= -aes-cbc-hmac-sha2. While they both explicitly represent the CMK and CEK, a= nd use the same underlying crypto operations, the details differ in ways th= at are likely to matter to implementers.

<DAM>
When JOSE met at IETF84, the consensus of the room was to use AEAD and=  draft-mcgrew-aead-aes-cbc-hmac-sha2, and omit unauthenticated encrypt= ion.   That's what JOSE should do, as it is the technically best solut= ion.   I will ask Kevin Igoe to move draft-mcgrew forward to RFC.  

</DAM>

 If there was a version of draft-mcgrew-aead-aes-cbc-hmac-sha2 th= at kept all the inputs and outputs separate, I agree that it would be a rea= sonable candidate for JOSE to consider. But unlike AES GCM, that's not what= it does.

<DAM>
draft-mcgrew-aead-aes-cbc-hmac-sha2 uses the same interface as does AE= AD_AES_128_GCM; see Section 5.1 of RFC 5116.  

David
</DAM>

-- Mike

> From: James.H.Manger at team.telstra.com
> To: michael_b_jones at hotmail.com; jose at ietf.org
> Date: Mon, 12 Nov 2012 09:23:37 +1100
> Subject: RE: [jose] Choice for WG: Use a KDF with AES CBC or use = a longer key
>
> > So I=92d like to explicitly ask the working group. Do you wa= nt us to:
> >
> > (1) Use the concatenation of random CEK and CIK values as th= e CMK for AES CBC, resulting in a longer CMK?
> > (2) Continue to use a KDF to generate the CEK and CIK from a= shorter CMK?
>
>
> 1. Use draft-mcgrew-aead-aes-cbc-hmac-sha2
>
> --
> James Manger


--_000_747787E65E3FBD4E93F0EB2F14DB556B0F50A90Cxmbrcdx04ciscoc_-- From mcgrew@cisco.com Mon Nov 12 10:20: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 9CCFC21F8674 for ; Mon, 12 Nov 2012 10:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTLJlcUxbMEd for ; Mon, 12 Nov 2012 10:20:58 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF3921F8609 for ; Mon, 12 Nov 2012 10:20:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4396; q=dns/txt; s=iport; t=1352744458; x=1353954058; h=from:to:cc:subject:date:message-id:mime-version; bh=4X7UHtJe3TJVIAY1M3sG63OuFd+Me+j/hqUClsItXCM=; b=YRPAEFw0+0W3NUlhrIm8U7OlfhuqA913KhTEDsXEnatjMvjzhErayJQp nXS5u2AEenfKoJQJ6KPoNxjNWqOrs38U7V8lTShlN3Xb1dSh8cwnuwq1b Md8YToLcUg3lr7P5OIYFoom7d1fOachVBpMRa3OEY5FSp6A/DfUCwY0xx Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAFAJs9oVCtJV2Z/2dsb2JhbABEgkmvHIkFAYhvgQiCIAEEEgFmEgEMHlYnBAENDQEZh2gLmWWffJF+YQOXGI08gWuCb4IZ X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="141162395" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 12 Nov 2012 18:20:58 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qACIKwqX022002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Nov 2012 18:20:58 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 12:20:57 -0600 From: "David McGrew (mcgrew)" To: "cfrg@irtf.org" , "jose@ietf.org" Thread-Topic: Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 Thread-Index: AQHNwQJ1KPZ1PBWsRUecOePTOEDiwQ== Date: Mon, 12 Nov 2012 18:20:57 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F50A96C@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.228] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19356.005 x-tm-as-result: No--30.318000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_747787E65E3FBD4E93F0EB2F14DB556B0F50A96Cxmbrcdx04ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 12 Nov 2012 10:42:18 -0800 Cc: "Paterson, Kenny" Subject: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 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, 12 Nov 2012 18:20:59 -0000 --_000_747787E65E3FBD4E93F0EB2F14DB556B0F50A96Cxmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, There is a new version of "Authenticated Encryption with AES-CBC and HMAC-S= HA", and I would appreciate your review. It is online at = The diff between the current and the previous version is available at This draft has been proposed for use in the JOSE WG , where its adoption would allow the working group to omit = "raw" unauthenticated encryption, e.g. AES-CBC, and only include authentica= ted encryption. Thus I am asking for your help in making John Foley generated test cases that correspond to the current version of t= he draft, but I didn't include these in the draft because I did not yet get= confirmation from a second independent implementation. With hope, there = will not be any need for any normative changes, and I will include these af= ter I get confirmation. Thanks, David --_000_747787E65E3FBD4E93F0EB2F14DB556B0F50A96Cxmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

There is a new version of "Authenticated Encryption with AES-CBC and HMAC-SHA"= ;, and I would appreciate your review.   It is online at &= lt;https://datatracker.ietf.org/doc/draft-mcgre= w-aead-aes-cbc-hmac-sha2/?include_text=3D1>   The diff between the current and the previous version is available a= t <http://www.ietf.org/rfcdiff?url2=3Ddraft-mcgrew-aead-a= es-cbc-hmac-sha2-01>


John Foley generated test cases that correspond to the current version of t= he draft, but I didn't include these in the draft because I did not yet get= confirmation from a second independent implementation.   With hope, t= here will not be any need for any normative changes, and I will include these after I get confirmation.  

Thanks,

David
--_000_747787E65E3FBD4E93F0EB2F14DB556B0F50A96Cxmbrcdx04ciscoc_-- From michael_b_jones@hotmail.com Mon Nov 12 12:09: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 085CC21F86B8 for ; Mon, 12 Nov 2012 12:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7cXkM2kVFCE for ; Mon, 12 Nov 2012 12:09:42 -0800 (PST) Received: from bay0-omc1-s11.bay0.hotmail.com (bay0-omc1-s11.bay0.hotmail.com [65.54.190.22]) by ietfa.amsl.com (Postfix) with ESMTP id D251B21F8686 for ; Mon, 12 Nov 2012 12:09:42 -0800 (PST) Received: from BAY171-W7 ([65.54.190.60]) by bay0-omc1-s11.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Nov 2012 12:09:42 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_9fd6521c-0bb5-4a4d-a637-40576353e969_" X-Originating-IP: [50.47.91.23] From: Michael Jones To: Date: Mon, 12 Nov 2012 12:09:41 -0800 Importance: Normal In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F50A90C@xmb-rcd-x04.cisco.com> References: <747787E65E3FBD4E93F0EB2F14DB556B0F50A90C@xmb-rcd-x04.cisco.com> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Nov 2012 20:09:42.0589 (UTC) FILETIME=[A71CA6D0:01CDC111] Cc: jose@ietf.org Subject: Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer 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: Mon, 12 Nov 2012 20:09:44 -0000 --_9fd6521c-0bb5-4a4d-a637-40576353e969_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I believe that you're slightly misstating the consensus below. Yes=2C ther= e was consensus that we should move to only authenticated encryption algori= thms. The drafts have already done this. There was not consensus to spedi= fically use the algorithms in draft-mcgrew-aead-aes-cbc-hmac-sha2. If ther= e was=2C they would already be in the drafts=2C as the drafts have been upd= ated to incorporate all consensus decisions since then. There *was* an info= rmal agreement that=2C should someone want to=2C they could add the algorit= hms in draft-mcgrew-aead-aes-cbc-hmac-sha2 to the JWA algorithms registry= =2C and then people could also use them=2C should they so desire. It's a p= otentially subtle=2C but important distinction. Best wishes=2C-- Mike From:= mcgrew@cisco.com To: michael_b_jones@hotmail.com Date: Mon=2C 12 Nov 2012 16:43:21 +0000 CC: jose@ietf.org Subject: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key Hi Mike=2C Please see inline. From: Michael Jones To: =2C Date: Sun=2C 11 Nov 2012 17:30:54 -0800 In-reply-to: <255B9BB34FB7D647A506DC292726F6E11500331CA9 at WSMSG3153V.srv.= dir.telstra.com> References: =2C <255B9BB34F= B7D647A506DC292726F6E11500331CA9 at WSMSG3153V.srv.dir.telstra.com> List-id: Javascript Object Signing and Encryption Using draft-mcgrew-aead-aes-cbc-hmac-sha2 is not the same thing as (1). For= instance=2C as was discussed after David's presentation at IETF 84=2C draf= t-mcgrew-aead-aes-cbc-hmac-sha2 does not follow the pattern of AEAD algorit= hms such as AES GCM=2C which have two inputs (plaintext=2C "additional authenticated data")=2C and two outpu= ts (ciphertext=2C "authentication tag"). Instead=2C it adds a step combinin= g the ciphertext and "authentication tag" outputs. draft-mcgrew-aead-aes-cbc-hmac-sha2 does use exactly the same interface as = AES-GCM=2C RFC 5116=2C and the other AEAD algorithms that make use of that = interface. To make this more clear=2C I can make the following addition. Section 2.1 = starts out as "We briefly recall the encryption interface defined in Sectio= n 2 of [RFC5116]." I will add "which is used by all of the algorithms de= fined in this note". If you read the draft=2C implementation of draft-mcgrew-aead-aes-cbc-hmac-s= ha2 has a lot more steps than what we have for A128CBC+HS256 and A256CBC+HS= 512. It requires generating and adding specific padding bytes. It prefixes = the ciphertext with the IV. It includes the length of the "additional authenticated data" in the MAC calc= ulation. It combines the two outputs into one. For decryption=2C likewise= =2C the two outputs must be split apart=2C the IV must be split apart=2C et= c. All of these are steps that implementations could get wrong=2C resulting in= interoperability problems. By keeping all the parameters separate=2C our c= urrent A128CBC+HS256 and A256CBC+HS512 algorithms eliminate those steps. draft-mcgrew-aead-aes-cbc-hmac-sha2 has all of the required steps for authe= nticated encryption=2C and does not have any extraneous steps. Things lik= e plaintext padding need to be specified=2C and it is critical to have the = length of the associated data included in the MAC input (see Section 6=2C third paragraph=2C of draft-mcgrew). = =20 The fact that implementations might get these details wrong is why they bel= ong in the crypto algorithm=2C and not in the JOSE implementation. Consi= der=2C for instance=2C that with the AEAD approach these details would get = test coverage from the AEAD test cases=3B otherwise=2C there are details that would go untested. I'm sorry for the apparent confusion between (1) and draft-mcgrew-aead-aes-= cbc-hmac-sha2. While they both explicitly represent the CMK and CEK=2C and = use the same underlying crypto operations=2C the details differ in ways tha= t are likely to matter to implementers. When JOSE met at IETF84=2C the consensus of the room was to use AEAD and dr= aft-mcgrew-aead-aes-cbc-hmac-sha2=2C and omit unauthenticated encryption. = That's what JOSE should do=2C as it is the technically best solution. I = will ask Kevin Igoe to move draft-mcgrew forward to RFC. =20 If there was a version of draft-mcgrew-aead-aes-cbc-hmac-sha2 that kept al= l the inputs and outputs separate=2C I agree that it would be a reasonable = candidate for JOSE to consider. But unlike AES GCM=2C that's not what it do= es. draft-mcgrew-aead-aes-cbc-hmac-sha2 uses the same interface as does AEAD_AE= S_128_GCM=3B see Section 5.1 of RFC 5116. =20 David -- Mike > From: James.H.Manger at team.telstra.com > To: michael_b_jones at hotmail.com=3B jose at ietf.org > Date: Mon=2C 12 Nov 2012 09:23:37 +1100 > Subject: RE: [jose] Choice for WG: Use a KDF with AES CBC or use a longer= key >=20 > > So I=92d like to explicitly ask the working group. Do you want us to: > > > > (1) Use the concatenation of random CEK and CIK values as the CMK for A= ES CBC=2C resulting in a longer CMK? > > (2) Continue to use a KDF to generate the CEK and CIK from a shorter CM= K? >=20 >=20 > 1. Use draft-mcgrew-aead-aes-cbc-hmac-sha2 >=20 > -- > James Manger _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose = --_9fd6521c-0bb5-4a4d-a637-40576353e969_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I believe that you're slightly misstating the consensus below. =3B Yes= =2C there was consensus that we should move to only authenticated encryptio= n algorithms. =3B The drafts have already done this. =3B There was = not consensus to spedifically use the algorithms in draft-mcgrew-aead-aes-c= bc-hmac-sha2. =3B If there was=2C they would already be in the drafts= =2C as the drafts have been updated to incorporate all consensus decisions = since then.
 =3B
There =3B*was* an informal agreement that=2C= should someone =3Bwant to=2C they could add the algorithms in draft-mc= grew-aead-aes-cbc-hmac-sha2 to the JWA algorithms registry=2C and =3Bth= en people could also use them=2C should they so desire. =3B It's = =3Ba potentially subtle=2C but important distinction.
 =3B
Best w= ishes=2C
-- Mike =3B
<= hr id=3D"stopSpelling">From: mcgrew@cisco.com
To: michael_b_jones@hotmai= l.com
Date: Mon=2C 12 Nov 2012 16:43:21 +0000
CC: jose@ietf.org
Su= bject: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key
Hi Mike=2C

Please see <=3BDAM>=3B inline.

From: Michael Jones <=3Bmichael_b_jones at hotmail.com>=3B
To: <=3Bjames.h.manger at team.telstra.com>=3B=2C <=3Bjose at ie= tf.org>=3B
Date: Sun=2C 11 Nov 2012 17:30:54 -0800
In-reply-to: <=3B255B9BB34FB7D647A506DC292726F6E11500331CA9 at WSMSG= 3153V.srv.dir.telstra.com>=3B
References: <=3BBAY171-W32DD53461B3DF4235F053DB7680 at phx.gbl>=3B= =2C <=3B255B9BB34FB7D647A506DC292726F6E11500331CA9 at WSMSG3153V.srv.dir.= telstra.com>=3B
List-id: Javascript Object Signing and Encryption <=3Bjose.ietf.org&= gt=3B

Using draft-mcgrew-aead-aes-cbc-hmac-sha2 is not the same thing as (1)= . For instance=2C as was discussed after David's presentation at IETF 84=2C= draft-mcgrew-aead-aes-cbc-hmac-sha2 does not follow the pattern of AEAD al= gorithms such as AES GCM=2C which have two inputs (plaintext=2C "additional authenticated data")=2C and two outpu= ts (ciphertext=2C "authentication tag"). Instead=2C it adds a step combinin= g the ciphertext and "authentication tag" outputs.

<=3BDAM>=3B
draft-mcgrew-aead-aes-cbc-hmac-sha2 does use exactly the same interfac= e as AES-GCM=2C RFC 5116=2C and the other AEAD algorithms that make use of = that interface.
To make this more clear=2C I can make the following addition.  =3B= Section 2.1 starts out as "We briefly recall the encryption interface defin= ed in Section 2 of =3B =3B[RFC5116]."  =3B I will add "which is= used by all of the algorithms defined in this note".
<=3B/DAM>=3B

If you read the draft=2C implementation of draft-mcgrew-aead-aes-cbc-h= mac-sha2 has a lot more steps than what we have for A128CBC+HS256 and A256C= BC+HS512. It requires generating and adding specific padding bytes. It pref= ixes the ciphertext with the IV. It includes the length of the "additional authenticated data" in the MAC calc= ulation. It combines the two outputs into one. For decryption=2C likewise= =2C the two outputs must be split apart=2C the IV must be split apart=2C et= c.

All of these are steps that implementations could get wrong=2C resulti= ng in interoperability problems. By keeping all the parameters separate=2C = our current A128CBC+HS256 and A256CBC+HS512 algorithms eliminate those step= s.

<=3BDAM>=3B
draft-mcgrew-aead-aes-cbc-hmac-sha2 =3Bhas all of the required ste= ps for authenticated encryption=2C and does not have any extraneous steps. =  =3B Things like plaintext padding need to be specified=2C and it is cr= itical to have the length of the associated data included in the MAC input (see Section 6=2C third paragraph=2C of draft-mcgrew). &n= bsp=3B  =3B

The fact that implementations might get these details wrong is why the= y belong in the crypto algorithm=2C and not in the JOSE implementation. &nb= sp=3B  =3BConsider=2C for instance=2C that with the AEAD approach these= details would get test coverage from the AEAD test cases=3B otherwise=2C there are details that would go untested.

<=3B/DAM>=3B

I'm sorry for the apparent confusion between (1) and draft-mcgrew-aead= -aes-cbc-hmac-sha2. While they both explicitly represent the CMK and CEK=2C= and use the same underlying crypto operations=2C the details differ in way= s that are likely to matter to implementers.

<=3BDAM>=3B
When JOSE met at IETF84=2C the consensus of the room was to use AEAD a= nd =3Bdraft-mcgrew-aead-aes-cbc-hmac-sha2=2C and omit unauthenticated e= ncryption.  =3B That's what JOSE should do=2C as it is the technically = best solution.  =3B I will ask Kevin Igoe to move draft-mcgrew forward to RFC.  =3B

<=3B/DAM>=3B

 =3BIf there was a version of draft-mcgrew-aead-aes-cbc-hmac-sha2 = that kept all the inputs and outputs separate=2C I agree that it would be a= reasonable candidate for JOSE to consider. But unlike AES GCM=2C that's no= t what it does.

<=3BDAM>=3B
draft-mcgrew-aead-aes-cbc-hmac-sha2 uses the same interface as does AE= AD_AES_128_GCM=3B see Section 5.1 of RFC 5116.  =3B

David
<=3B/DAM>=3B

-- Mike

>=3B From: James.H.Manger at team.telstra.com
>=3B To: michael_b_jones at hotmail.com=3B jose at ietf.org
>=3B Date: Mon=2C 12 Nov 2012 09:23:37 +1100
>=3B Subject: RE: [jose] Choice for WG: Use a KDF with AES CBC or us= e a longer key
>=3B
>=3B >=3B So I=92d like to explicitly ask the working group. Do yo= u want us to:
>=3B >=3B
>=3B >=3B (1) Use the concatenation of random CEK and CIK values a= s the CMK for AES CBC=2C resulting in a longer CMK?
>=3B >=3B (2) Continue to use a KDF to generate the CEK and CIK fr= om a shorter CMK?
>=3B
>=3B
>=3B 1. Use draft-mcgrew-aead-aes-cbc-hmac-sha2
>=3B
>=3B --
>=3B James Manger



_______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose
= --_9fd6521c-0bb5-4a4d-a637-40576353e969_-- From michael_b_jones@hotmail.com Mon Nov 12 12:25: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 A782121F859D for ; Mon, 12 Nov 2012 12:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYgAtO5m33Gm for ; Mon, 12 Nov 2012 12:25:05 -0800 (PST) Received: from bay0-omc1-s2.bay0.hotmail.com (bay0-omc1-s2.bay0.hotmail.com [65.54.190.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA6C21F8462 for ; Mon, 12 Nov 2012 12:25:05 -0800 (PST) Received: from BAY171-W133 ([65.54.190.60]) by bay0-omc1-s2.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Nov 2012 12:25:04 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_e8f7860d-ce2d-4929-9424-1c73cd8e9749_" X-Originating-IP: [50.47.91.23] From: Michael Jones To: , , Date: Mon, 12 Nov 2012 12:25:04 -0800 Importance: Normal In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F50A96C@xmb-rcd-x04.cisco.com> References: <747787E65E3FBD4E93F0EB2F14DB556B0F50A96C@xmb-rcd-x04.cisco.com> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Nov 2012 20:25:04.0774 (UTC) FILETIME=[CCC6EA60:01CDC113] Subject: Re: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 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, 12 Nov 2012 20:25:06 -0000 --_e8f7860d-ce2d-4929-9424-1c73cd8e9749_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable OK=2C I admit that the way I phrased my request may not be exactly in line with the way the =93AEAD=94 terminology is used.=20 I can correct that. That=92s syntax.=20 I was using =93AEAD=94 as a shorthand for the working group=92s decision to use only authenticated encryption algorithms =96 not to mean the particular combined representation of those parameters apparently specified in the AEA= D draft. I will correct the terminology usage in the next revision of the JOSE specifications. The semantic point remains that it=92s cleaner and more flexible to have the Key=2C the Plaintext=2C IV=2C and =93additional authenticated data=94 p= arameters all be separate inputs and the Ciphertext and =93authentication tag=94 all be s= eparate outputs. In JOSE=92s particular use case=2C that would be a significantly better match and easier for implementers to u= se. JOSE already has a way of combining the inputs and outputs that=92s inherent to its representation=2C and it doesn=92t match the one you=92ve specified. GCM=2C CTR=2C and the current JOSE-specified algorithms are a great fit for this=2C as they can directly = use that representation. The AEAD pattern you cite requires disassembly of the components of the AEAD-specific representation to be able to use the combinations already present in the JO= SE representations and then reassembly at decryption time. That=92s just more= work for implementers=2C and it=92s not semantically necessary work. Are you open to specifying versions of your algorithms that don=92t require a particular combination method for the parameters=2C but instead leave the= combination up to the use case? I=92m fine with you also specifying a specific combination method as an optional feature of the specification. But it shouldn=92t be part of the algorithm definition=2C just like it isn=92t for GCM. Best wishes=2C -- Mike From: David McGrew (mcgrew) [mailto:mcgrew@cisco.com]=20 Sent: Monday=2C November 12=2C 2012 11:43 AM To: Mike Jones=3B cfrg@irtf.org=3B jose@ietf.org Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA=2C version 01 Hi Mike=2C From: Mike Jones Date: Monday=2C November 12=2C 2012 1:55 PM To: Cisco Employee =2C "cfrg@irtf.org" =2C "jose@ietf.org" Subject: RE: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA=2C version 01 As background=2C if there was a version of this spec that did not assume that the parameters would be concatenated together in a specific way=2C but left them as independent inputs and outputs=2C as AES GCM and AE= S CTR do=2C it would be a better match for JOSE=92s use case. I believe that what you are referring to is the inclusion of the authentication tag in the authenticated ciphertext. This is not just a property of draft-mcgrew-aead-aes-cbc-hmac-sha2=3B it is a feature of all 19 of the AEA= D algorithms that have been defined so far. For comparison=2C draft-mcgrew-aead-aes-cbc-hmac-sha2 says=20 =20 The AEAD Ciphertext consists of the string S=2C with the string T =20 appended to it. This Ciphertext is returned as the output of the =20 AEAD encryption operation. Where S is the ciphertext and T is the authentication tag. RFC 5116 says =20 =20 "The AEAD_AES_128_GCM ciphertext is formed by appending the authentication tag provided as an output to the GCM encryption operation to the ciphertext that is output by that=20 operation." David =20 -- Mike From: mcgrew@cisco.com To: cfrg@irtf.org=3B jose@ietf.org Date: Mon=2C 12 Nov 2012 18:20:57 +0000 CC: Kenny.Paterson@rhul.ac.uk Subject: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA=2C versi= on 01 Hi=2C There is a new version of "Authenticated Encryption with AES-CBC and HMAC-S= HA"=2C and I would appreciate your review. It is online at = =20 The diff between the current and the previous version is available at This draft has been proposed for use in the JOSE WG =2C where its adoption would allow the working group to omi= t "raw" unauthenticated encryption=2C e.g. AES-CBC=2C and only include authenticated encryption. Thus I am asking for your help in maki= ng=20 John Foley generated test cases that correspond to the current version of t= he draft=2C but I didn't include these in the draft because I did not yet g= et confirmation from a second independent implementation. With hope=2C th= ere will not be any need for any normative changes=2C and I will include these after I get confirmation. =20 Thanks=2C David _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose = --_e8f7860d-ce2d-4929-9424-1c73cd8e9749_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

OK=2C I admit that the w= ay I phrased my request may not be exactly in line with the way the =93AEAD=94 terminology is used. =3B I can correct that. That=92s syntax. =3B I was using =93AEAD=94 as a shorthand for the working group=92s deci= sion to use only authenticated encryption algorithms =96 not to mean the particular combined representation of those parameters apparently specified in the AEA= D draft. =3B I will correct t= he terminology usage in the next revision of the JOSE specifications.


The semantic point remai= ns that it=92s cleaner and more flexible to have the Key=2C the Plaintext=2C IV=2C and =93additional authenticated data=94 p= arameters all be separate inputs and the Ciphertext and =93authentication tag=94 all be s= eparate outputs. =3B In JOSE=92s pa= rticular use case=2C that would be a significantly better match and easier for implementers to u= se.


JOSE already has a way o= f combining the inputs and outputs that=92s inherent to its representation=2C and it doesn=92t match the one you=92ve specified. =3B GCM=2C CTR= =2C and the current JOSE-specified algorithms are a great fit for this=2C as they can directly = use that representation. =3B Th= e AEAD pattern you cite requires disassembly of the components of the AEAD-specific representation to be able to use the combinations already present in the JO= SE representations and then reassembly at decryption time. =3B That=92s just more work for implementers= =2C and it=92s not semantically necessary work.


Are you open to specifyi= ng versions of your algorithms that don=92t require a particular combination method for the parameters=2C but instead leave the= combination up to the use case? =3B I= =92m fine with you also specifying a specific combination method as an optional feature of the specification.  =3BBut it s= houldn=92t be part of the algorithm definition=2C just like it isn=92t for GCM.


 =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B Best wishes=2C

 =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B -- Mike



From: David McGrew (mcgrew) [mailto:mcgrew@cisco.com= ]
Sent: Monday=2C November 12=2C 2012 11:43 AM
To: Mike Jones=3B cfrg@irtf.org=3B jose@ietf.org
Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-S= HA=2C version 01


Hi Mike=2C<= /p>

From: Mike Jones <=3BMichael.J= ones@microsoft.com>=3B
Date: Monday=2C November 12=2C 2012 1:55 PM
To: Cisco Employee <=3Bmcgrew@cisco.com>=3B=2C "cfrg@irtf.org" <=3Bcfr= g@irtf.org>=3B=2C "jose@ietf.org" <=3Bjose@ietf.org>=3B
Subject: RE: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-S= HA=2C version 01


As background=2C if there was a version of this spe= c that did not assume that the parameters would be concatenated together in a specific way=2C but left them as independent inputs and outputs=2C as AES GCM and AE= S CTR do=2C it would be a better match for JOSE=92s use case.

I believ= e that what you are referring to is the inclusion of the authentication tag in the authenticated ciphertext.  =3B This is not just a property of draft-mcgrew-aead-aes-cbc-hmac-sha2=3B it is a feature of all 19 of the AEA= D algorithms that have been defined so far.  =3B For comparison=2C =3Bdraft-mcgrew-aead-aes-cbc-hmac-sha2 says =3B<= /o:p>


 =3B  =3B =  =3B  =3BThe AEAD Ciphertext consists of the string S=2C with the string T

 =3B  =3B &n= bsp=3B  =3Bappended to it.  =3BThis Ciphertext is returned as the output o= f the

 =3B &nbs= p=3B  =3B  =3BAEAD encryption operation.

 =3B

Where S is the ciphertext and T is the authentication tag.  =3B =3BRFC 5116 says


 =3B  =3B =  =3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B &nb= sp=3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B"The AEAD_AES_128_GCM ciphertex= t is formed by

 =3B =  =3Bappending the authentication tag provided as an output to the GCM

 =3B  =3Bencryption operation to the ciphertext that is output by that

 =3B  =3Boperation."


David


 =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B -- Mike


From: mcgrew@cisco.com
To: cfrg@irtf.org=3B jose@ietf.org
Date: Mo= n=2C 12 Nov 2012 18:20:57 +0000
CC: Kenny.Paterson@rhul.ac.uk
Subject= : [jose] Authenticated Encryption with AES-CBC and HMAC-SHA=2C version 01
Hi=2C
There is a new version of "Authenticated Encryption with AES-CBC and HMAC-SHA"=2C a= nd =3BI would appreciate your review.  =3B It is online at &= lt=3Bhttps://datatracker.ietf.= org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2/?include_text=3D1>=3B&nbs= p=3B  =3BThe diff between the current and the previous version is available= at <=3Bhttp://www.ietf.org/rfcdiff?url2= =3Ddraft-mcgrew-aead-aes-cbc-hmac-sha2-01>=3B
This draft has been proposed for use in the JOSE WG <=3Bhttp://datatracker.iet= f.org/wg/jose/>=3B =3B=2C where its adoption would allow the work= ing group to omit "raw" unauthenticated encryption=2C e.g. AES-CBC=2C and o= nly include authenticated encryption.  =3B Thus I am asking for your help = in making =3B
John Foley generated test cases that correspond to the current version of t= he draft=2C but I didn't include these in the draft because I did not yet g= et confirmation from a second independent implementation.  =3B With hop= e=2C there will not be any need for any normative changes=2C and I will include these after I get confirmation.  =3B
Thanks=2C
David

_______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose
= --_e8f7860d-ce2d-4929-9424-1c73cd8e9749_-- From mcgrew@cisco.com Mon Nov 12 11:42: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 674EB21F8751 for ; Mon, 12 Nov 2012 11:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6EV7gwLqZvp for ; Mon, 12 Nov 2012 11:42:38 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0E58C21F85C0 for ; Mon, 12 Nov 2012 11:42:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14309; q=dns/txt; s=iport; t=1352749358; x=1353958958; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=ufHUlhNVBUCu4Iq/mwoHq+dzKkXjb4UwLuBIU06fEwA=; b=c5mTZ9uhhrVnbxxCirEoSoR4I6BkaqzqJBHO4LWS95pfmeuwmHk5npTB duyu7gJwHorvkaGe+zqvEAUuDOnbIn3SgyoBS9I7qRdd0NVWRq+HOmfix QC45Qxl1LXfvksEdkJhDjx1ZqYNTBhS6oGPDZToO079UvbTX2xI2Gorxu A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIFAD1QoVCtJXG+/2dsb2JhbABEgkmvHIkFAYhvgQiCHgEBAQQSARpeAQgOAwMBAQELHTkUCQgCBAESCAEZh2gLmVWgA4wVhWlhA5cYjTyBa4Jvghk X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="138404565" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 12 Nov 2012 19:42:37 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qACJgbCu017622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Nov 2012 19:42:37 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 13:42:36 -0600 From: "David McGrew (mcgrew)" To: Mike Jones , "cfrg@irtf.org" , "jose@ietf.org" Thread-Topic: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 Thread-Index: AQHNwQ3d4t8orcyRa0OnKgA6UvxDXw== Date: Mon, 12 Nov 2012 19:42:36 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F50AA95@xmb-rcd-x04.cisco.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943668B026C@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.228] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19356.005 x-tm-as-result: No--38.562600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_747787E65E3FBD4E93F0EB2F14DB556B0F50AA95xmbrcdx04ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 12 Nov 2012 12:51:09 -0800 Subject: Re: [jose] [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 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, 12 Nov 2012 19:42:39 -0000 --_000_747787E65E3FBD4E93F0EB2F14DB556B0F50AA95xmbrcdx04ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Mike, From: Mike Jones > Date: Monday, November 12, 2012 1:55 PM To: Cisco Employee >, "cfrg@irtf.= org" >, "jose@iet= f.org" > Subject: RE: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, ver= sion 01 As background, if there was a version of this spec that did not assume that= the parameters would be concatenated together in a specific way, but left = them as independent inputs and outputs, as AES GCM and AES CTR do, it would= be a better match for JOSE=92s use case. I believe that what you are referring to is the inclusion of the authentica= tion tag in the authenticated ciphertext. This is not just a property of = draft-mcgrew-aead-aes-cbc-hmac-sha2; it is a feature of all 19 of the AEAD = algorithms that have been defined so far. For comparison, draft-mcgrew-ae= ad-aes-cbc-hmac-sha2 says The AEAD Ciphertext consists of the string S, with the string T appended to it. This Ciphertext is returned as the output of the AEAD encryption operation. Where S is the ciphertext and T is the authentication tag. RFC 5116 says "The AEAD_AES_128_GCM ciphertext is fo= rmed by appending the authentication tag provided as an output to the GCM encryption operation to the ciphertext that is output by that operation." David -- Mike From: cfrg-bounces@irtf.org [mailto:cfrg-boun= ces@irtf.org] On Behalf Of David McGrew (mcgrew) Sent: Monday, November 12, 2012 10:21 AM To: cfrg@irtf.org; jose@ietf.org Subject: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version= 01 Hi, There is a new version of "Authenticated Encryption with AES-CBC and HMAC-S= HA", and I would appreciate your review. It is online at The diff between the current and the previous version is av= ailable at This draft has been proposed for use in the JOSE WG , where its adopti= on would allow the working group to omit "raw" unauthenticated encryption, = e.g. AES-CBC, and only include authenticated encryption. Thus I am asking= for your help in making John Foley generated test cases that correspond to the current version of t= he draft, but I didn't include these in the draft because I did not yet get= confirmation from a second independent implementation. With hope, there = will not be any need for any normative changes, and I will include these af= ter I get confirmation. Thanks, David --_000_747787E65E3FBD4E93F0EB2F14DB556B0F50AA95xmbrcdx04ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Mike,

From: Mike Jones <Michael.Jones@microsoft.com>
Date: Monday, November 12, 2012 1:5= 5 PM
To: Cisco Employee <mcgrew@cisco.com>, "cfrg@irtf.org" <= cfrg@irtf.org>, "jose@ietf.org= " <jose@ietf.org>
Subject: RE: [Cfrg] Authenticated E= ncryption with AES-CBC and HMAC-SHA, version 01

As background, if there was a vers= ion of this spec that did not assume that the parameters would be concatena= ted together in a specific way, but left them as independent inputs and outputs, as AES GCM and AES CTR do, it= would be a better match for JOSE=92s use case.

I believe that what you are referring to is the inclusion of the authe= ntication tag in the authenticated ciphertext.   This is not just a pr= operty of draft-mcgrew-aead-aes-cbc-hmac-sha2; it is a feature of all 19 of= the AEAD algorithms that have been defined so far.   For comparison, draft-mcgrew-aead-aes-cbc-hmac-sha2 sa= ys 

       The AEAD Ciphertext consists of the string = S, with the string T
       appended to it.  This Ciphertext is re= turned as the output of the
       AEAD encryption operation.

Where S is the ciphertext and T is the authentication tag.   = ;RFC 5116 says

                    =                  "The AEA= D_AES_128_GCM ciphertext is formed by
   appending the authentication tag provided as an output to= the GCM
   encryption operation to the ciphertext that is output by = that
   operation."

David

 

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

 

From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of David McGrew (mcgrew)
Sent: Monday, November 12, 2012 10:21 AM
To: cfrg@irtf.org; jose@ietf.org
Subject: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, = version 01

 

Hi,

 

There is a new version of "Authenticated Encryption with AES-CBC and HMAC-SHA", and https://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hma= c-sha2/?include_text=3D1>   The diff between the current and the previous version is available a= t <http://www.ietf.org/rfcdiff?url2=3Ddraft-mcgrew-aead-ae= s-cbc-hmac-sha2-01>

 

This draft has been proposed for use in the= JOSE WG <http://dat= atracker.ietf.org/wg/jose/> , where its adoption would allow the working group to omit "raw" unauthentic= ated encryption, e.g. AES-CBC, and only include authenticated encryption. &= nbsp; Thus I am asking for your help in making 

 

John Foley generated test cases that corres= pond to the current version of the draft, but I didn't include these in the= draft because I did not yet get confirmation from a second independent implementation.   With hope, there will not= be any need for any normative changes, and I will include these after I ge= t confirmation.  

 

Thanks,

 

David

 --_000_747787E65E3FBD4E93F0EB2F14DB556B0F50AA95xmbrcdx04ciscoc_-- From michael_b_jones@hotmail.com Mon Nov 12 17:36: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 2D51B21F87CF for ; Mon, 12 Nov 2012 17:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzGhY1q5ORx3 for ; Mon, 12 Nov 2012 17:36:50 -0800 (PST) Received: from col0-omc4-s3.col0.hotmail.com (col0-omc4-s3.col0.hotmail.com [65.55.34.205]) by ietfa.amsl.com (Postfix) with ESMTP id 533BF21F8788 for ; Mon, 12 Nov 2012 17:36:50 -0800 (PST) Received: from COL401-EAS436 ([65.55.34.199]) by col0-omc4-s3.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Nov 2012 17:36:49 -0800 X-Originating-IP: [32.173.214.130] X-EIP: [RksFGqcBip46A6Ga1yMGpVuM3wAb7cN8] X-Originating-Email: [michael_b_jones@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_c18d8d59-6f64-4747-8f62-240c572c3402_" MIME-Version: 1.0 From: Michael Jones Date: Mon, 12 Nov 2012 17:36:33 -0800 To: "David McGrew (mcgrew)" , "cfrg@irtf.org" , "jose@ietf.org" X-OriginalArrivalTime: 13 Nov 2012 01:36:49.0811 (UTC) FILETIME=[59D90E30:01CDC13F] Cc: "Paterson, Kenny" Subject: Re: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 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, 13 Nov 2012 01:36:52 -0000 --_c18d8d59-6f64-4747-8f62-240c572c3402_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Believe me=2C if there were out of the box AEAD algorithm implementations a= vailable in most crypto libraries=2C I'd be eager to use them. As it is th= ough=2C all we can count on really being there are AES CBC and SHA-2. The J= WE algs are intended to be as easy to securely and interoperably implement = with those building blocks as possible. Remember that implementers will be building these algorithms from those par= ts themselves. A key JOSE goal is making that prospect both approachable an= d attractive. That's my primary motivation in all of these (very useful) d= iscussions. I'm sure that's a goal we all share. Cheers=2C -- Mike Sent from my Windows Phone ________________________________ From: David McGrew (mcgrew) Sent: 11/12/2012 3:20 PM To: Michael Jones=3B cfrg@irtf.org=3B jose@ietf.org Cc: Paterson=2C Kenny Subject: Re: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA=2C v= ersion 01 From: Michael Jones > Date: Monday=2C November 12=2C 2012 3:25 PM To: Cisco Employee >=2C "cfrg@irt= f.org" >=2C "jose= @ietf.org" > Subject: RE: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA=2C v= ersion 01 OK=2C I admit that the way I phrased my request may not be exactly in line = with the way the =E2=80=9CAEAD=E2=80=9D terminology is used. I can correct= that. That=E2=80=99s syntax. I was using =E2=80=9CAEAD=E2=80=9D as a shor= thand for the working group=E2=80=99s decision to use only authenticated en= cryption algorithms =E2=80=93 not to mean the particular combined represent= ation of those parameters apparently specified in the AEAD draft. I will c= orrect the terminology usage in the next revision of the JOSE specification= s. The semantic point remains that it=E2=80=99s cleaner and more flexible to h= ave the Key=2C the Plaintext=2C IV=2C and =E2=80=9Cadditional authenticated= data=E2=80=9D parameters all be separate inputs and the Ciphertext and =E2= =80=9Cauthentication tag=E2=80=9D all be separate outputs. In JOSE=E2=80=99= s particular use case=2C that would be a significantly better match and eas= ier for implementers to use. JOSE already has a way of combining the inputs and outputs that=E2=80=99s i= nherent to its representation=2C and it doesn=E2=80=99t match the one you= =E2=80=99ve specified. GCM=2C CTR=2C and the current JOSE-specified algori= thms are a great fit for this=2C as they can directly use that representati= on. The AEAD pattern you cite requires disassembly of the components of th= e AEAD-specific representation to be able to use the combinations already p= resent in the JOSE representations and then reassembly at decryption time. = That=E2=80=99s just more work for implementers=2C and it=E2=80=99s not sem= antically necessary work. One could just as easily argue that the unnecessary work comes from the fac= t that draft-ietf-jose-json-web-algorithms-07 defines its own AEAD algorith= ms=2C which do not use the RFC 5116 interface. The draft confusingly refe= rences that RFC after it defines AEAD=2C but then does something different.= If the plan is really going to be for the JOSE WG to define its own AEAD= algorithms that are incompatible (which I hope is not the case)=2C the dif= ferences and motivation deserve to be documented. The motivation for 5116 incorporating the authentication data into the ciph= ertext was to simplify the interface and move more of the crypto details un= der the crypto interface. These are still valid motivations=2C though at = this point the most important reason to use the interface is to avoid gratu= itous incompatibility. Other protocols have not had any trouble in using t= he 5116 interface=3B See RFC 5288 (TLSv1.2) Section 6.2.3.3=2C RFC 5647 (SS= H GCM)=2C or draft-ietf-avtcore-srtp-aes-gcm=2C for instance. Are you open to specifying versions of your algorithms that don=E2=80=99t r= equire a particular combination method for the parameters=2C but instead le= ave the combination up to the use case? I=E2=80=99m fine with you also spe= cifying a specific combination method as an optional feature of the specifi= cation. But it shouldn=E2=80=99t be part of the algorithm definition=2C ju= st like it isn=E2=80=99t for GCM. I am not dogmatically opposed to other interfaces=2C but the best solution = here is for JOSE to actually use the 5116 interface=2C like this: X.Y. Authenticated Encryption This section defines the specifics of encrypting the JWE Plaintext Using the Authenticated Encryption with Associated Data (AEAD) as defined in RFC 5116. The authenticated encryption operation has four inputs=2C as follows: The secret key is the CMK. The associated data is the bytes of the ASCII representation of the co= ncatenation of the Encoded JWE Header=2C a period ('.') character=2C the Encoded JWE Encrypted Key=2C a second period character ('.')=2C and the Encoded JW= E Initialization Vector=2C per Section 5 of the JWE specification. The plaintext =2C which contains the data to be encrypted and authenticated. A nonce N=2C with a length of either 0 or 96 bits. If the length is zero=2C the nonce is omitted. Otherwise=2C the nonce is as described in Section 3 of RFC 5116. There is a single output=2C the Ciphertext. The "enc" header parameter values are set as follows: "enc" Algorithm ----------------------------------------------------------------------- "A128GCM" AEAD_AES_128_GCM "A256GCM" AEAD_AES_256_GCM "A128CHS" AEAD_AES_128_CBC_HMAC_SHA_256 "A256CHS" AEAD_AES_256_CBC_HMAC_SHA_512 "A128SIV" AEAD_AES_SIV_CMAC_256 "A256SIV" AEAD_AES_SIV_CMAC_384 See for the references corresponding to these symbolic names. If we want to make actual progress on crypto interfaces=2C the thing that w= ould be worth doing is defining a simpler interface that moves the nonce de= tails into the ciphertext (and thus away from the user). Moving the authe= ntication data out of the ciphertext would be movement in the wrong directi= on=2C in my opinion. David Best wishes=2C -- Mike From: David McGrew (mcgrew) [mailto:mcgrew@cisco.com] Sent: Monday=2C November 12=2C 2012 11:43 AM To: Mike Jones=3B cfrg@irtf.org=3B jose@ietf.org Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA=2C v= ersion 01 Hi Mike=2C From: Mike Jones > Date: Monday=2C November 12=2C 2012 1:55 PM To: Cisco Employee >=2C "cfrg@irt= f.org" >=2C "jose= @ietf.org" > Subject: RE: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA=2C v= ersion 01 As background=2C if there was a version of this spec that did not assume th= at the parameters would be concatenated together in a specific way=2C but l= eft them as independent inputs and outputs=2C as AES GCM and AES CTR do=2C = it would be a better match for JOSE=E2=80=99s use case. I believe that what you are referring to is the inclusion of the authentica= tion tag in the authenticated ciphertext. This is not just a property of = draft-mcgrew-aead-aes-cbc-hmac-sha2=3B it is a feature of all 19 of the AEA= D algorithms that have been defined so far. For comparison=2C draft-mcgre= w-aead-aes-cbc-hmac-sha2 says The AEAD Ciphertext consists of the string S=2C with the string T appended to it. This Ciphertext is returned as the output of the AEAD encryption operation. Where S is the ciphertext and T is the authentication tag. RFC 5116 says "The AEAD_AES_128_GCM ciphertext is fo= rmed by appending the authentication tag provided as an output to the GCM encryption operation to the ciphertext that is output by that operation." David -- Mike ________________________________ From: mcgrew@cisco.com To: cfrg@irtf.org=3B jose@ietf.org Date: Mon=2C 12 Nov 2012 18:20:57 +0000 CC: Kenny.Paterson@rhul.ac.uk Subject: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA=2C versi= on 01 Hi=2C There is a new version of "Authenticated Encryption with AES-CBC and HMAC-S= HA"=2C and I would appreciate your review. It is online at <= https://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2/?inclu= de_text=3D1%3e> The diff between the current and the previous version is = available at This draft has been proposed for use in the JOSE WG =2C where its adop= tion would allow the working group to omit "raw" unauthenticated encryption= =2C e.g. AES-CBC=2C and only include authenticated encryption. Thus I am = asking for your help in making John Foley generated test cases that correspond to the current version of t= he draft=2C but I didn't include these in the draft because I did not yet g= et confirmation from a second independent implementation. With hope=2C th= ere will not be any need for any normative changes=2C and I will include th= ese after I get confirmation. Thanks=2C David _______________________________________________ jose mailing list jose@ietf= .org https://www.ietf.org/mailman/listinfo/jose --_c18d8d59-6f64-4747-8f62-240c572c3402_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Beli= eve me=2C if there were out of the box AEAD algorithm implementations avail= able in most crypto libraries=2C I'd be eager to use them. =3B As it is= though=2C all we can count on really being there are AES CBC and SHA-2. The JWE algs are intended to be as easy to securely and= interoperably implement with those building blocks as possible.

Remember that implementers will be building these algorithms from those par= ts themselves. A key JOSE goal is making that prospect both approachable an= d attractive. =3B That's my primary motivation in all of these (very us= eful) discussions. =3B I'm sure that's a goal we all share.

Cheers=2C
-- Mike

Sent from my Windows Phone
From: David McGrew (mcgrew)
Sent: 11/12/2012 3:20 PM
To: Michael Jones=3B cfrg@irtf.org=3B jose@ietf.org
Cc: Paterson=2C Kenny
Subject: Re: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA=2C versi= on 01



From: Michael Jones <=3Bmichael_b_jones@hotmail.com>= =3B
Date: Monday=2C November 12=2C 2012= 3:25 PM
To: Cisco Employee <=3Bmcgrew@cisco.com>=3B=2C "=3Bcfrg@irtf.org"=3B <=3Bcfrg@irtf.org>=3B=2C "=3Bjose@ietf.org"=3B <=3Bjose@ietf.org>=3B
Subject: RE: [jose] Authenticated E= ncryption with AES-CBC and HMAC-SHA=2C version 01


O= K=2C I admit that the way I phrased my request may not be exactly in line w= ith the way the =E2=80=9CAEAD=E2=80=9D terminology is used. =3B I can correct that. That=E2=80=99s syntax. =3B = I was using =E2=80=9CAEAD=E2=80=9D as a shorthand for the working gr= oup=E2=80=99s decision to use only authenticated encryption algorithms =E2= =80=93 not to mean the particular combined representation of those paramete= rs apparently specified in the AEAD draft. =3B I will correc= t the terminology usage in the next revision of the JOSE specifications.


T= he semantic point remains that it=E2=80=99s cleaner and more flexible to ha= ve the Key=2C the Plaintext=2C IV=2C and =E2=80=9Cadditional authenticated data=E2=80=9D parameters all be separate inputs and the Ciphertext and =E2= =80=9Cauthentication tag=E2=80=9D all be separate outputs.=  =3BIn JOSE=E2=80=99s particular use case=2C that would be a sig= nificantly better match and easier for implementers to use.



J= OSE already has a way of combining the inputs and outputs that=E2=80=99s in= herent to its representation=2C and it doesn=E2=80=99t match the one you=E2=80=99ve specified. =3B GCM=2C CTR=2C an= d the current JOSE-specified algorithms are a great fit for this=2C as they= can directly use that representation. =3B The AEAD pattern you cite requires disassembly of the components of = the AEAD-specific representation to be able to use the combinations already= present in the JOSE representations and then reassembly at decryption time= . =3B That=E2=80=99s just more work for implementers=2C and it=E2=80=99s n= ot semantically necessary work.

One could just as easily argue that =3Bthe unnecessary w= ork comes from the fact that =3Bdraft-ietf-jose-json-web-algorithms-07 = defines its own AEAD algorithms=2C which do not use the RFC 5116 interface.  =3B The draft confusingly references that RFC after i= t defines AEAD=2C but then does something different.  =3B If the plan i= s really going to be for the JOSE WG to define its own AEAD algorithms that= are incompatible (which I hope is not the case)=2C the differences and motivation deserve to be documented.  =3B

The motivation for 5116 incorporating the authentication dat= a into the ciphertext was to simplify the interface and move more of the cr= ypto details under the crypto interface.  =3B These are still valid motivations=2C though at this point the most important rea= son to use the interface is to avoid gratuitous incompatibility.  =3BOt= her protocols have not had any trouble in using the 5116 interface=3B See R= FC 5288 (TLSv1.2) Section 6.2.3.3=2C RFC 5647 (SSH GCM)=2C or =3Bdraft-ietf-avtcore-srtp-aes-gcm=2C for instance. &n= bsp=3B


A= re you open to specifying versions of your algorithms that don=E2=80=99t re= quire a particular combination method for the parameters=2C but instead leave the combination up to the use case?&nbs= p=3B I=E2=80=99m fine with you also specifying a specific combinatio= n method as an optional feature of the specification.  =3BBut it shouldn=E2=80=99t be part of the alg= orithm definition=2C just like it isn=E2=80=99t for GCM.

I am not dogmatically opposed to other interfaces=2C but the= best solution here is for JOSE to actually use the 5116 interface=2C like = this:

X.Y. = Authenticated Encryption

 = =3B  =3BThis section defines the specifics of encrypting the JWE Plaint= ext
 = =3B  =3BUsing the Authenticated Encryption with Associated Data (AEAD)<= /font>
 = =3B  =3Bas defined in RFC 5116.  =3B =3BThe= authenticated encryption operation =3B
 =3B  =3Bhas four inputs=2C as follows:

 =3B  =3B  =3BThe secret key is the CMK.

 =3B  =3B  =3BThe associated data is the bytes of the= ASCII representation of the concatenation of
 =3B  =3B  =3Bthe Encoded JWE Header=2C a period ('.') cha= racter=2C the Encoded JWE
 =3B  =3B  =3BEncrypted Key=2C a second period character (= '.')=2C and the Encoded JWE
 =3B  =3B  =3BInitialization Vector=2C per Section 5 of th= e JWE specification.
 =3B  =3B  =3B The plaintext =2C which contains the data t= o be encrypted and
 =3B  =3B  =3B authenticated.

 =3B  =3B  =3B A nonce N=2C with a length of either 0= or 96 bits.  =3B If the length
 = =3B  =3B  =3B is zero=2C the nonce is omitted.  =3BOtherwise=2C= the nonce
 = =3B  =3B  =3B is as described in Section 3 of RFC 5116.  =3B&nb= sp=3B

 =3B  =3BThere is a single output=2C the Ciphertext.  =3B<= /div>

 =3B  =3BThe "=3Benc"=3B header =3B= parameter values are set as follows:

 =3B  =3B "=3Benc"=3B  =3B  =3B  =3B &n= bsp=3B  =3B  =3B  =3B  =3B  =3BAlgorithm  =3B  = =3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B=  =3B  =3B =3B
 = =3B  =3B --------------------------------------------------------------= ---------
 =3B  =3B =3B"=3BA128GCM"=3B  =3B=  =3B =3BAEAD_AES_128_GCM  =3B  =3B  =3B  =3B  = =3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B=  =3B  =3B  =3B  =3B
 =3B  =3B "=3BA256GCM"=3B  =3B  =3B AEAD_AE= S_256_GCM  =3B  =3B  =3B  =3B  =3B  =3B  =3B &n= bsp=3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B  = =3B  =3B =3B
 =3B  =3B  =3B"=3BA128CHS"=3B  =3B  =3B=  =3BAEAD_AES_128_CBC_HMAC_SHA_256  =3B  =3B
 =3B  =3B  =3B"=3BA25= 6CHS"=3B  =3B  =3B  =3BAEAD_AES_256_CBC_HMAC_SHA_512  = =3B
 =3B  =3B  =3B "=3BA128SIV"=3B  =3B  =3B &= nbsp=3BAEAD_AES_SIV_CMAC_256
 =3B  =3B  =3B "=3BA256SIV"=3B  =3B  =3B &= nbsp=3BAEAD_AES_SIV_CMAC_384

 = =3B  =3B  =3Breferences corresponding to =3Bthese sym= bolic names.  =3B

If we= want to make actual progress on crypto interfaces=2C the thing that would = be worth doing is defining a simpler interface that moves the nonce details= into the ciphertext (and thus away from the user).  =3B Moving the authentication data out of the ciphertext w= ould be movement in the wrong direction=2C in my opinion.  =3B =3B<= /font>

David


<= span style=3D""> =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B Best wishes=2C

<= span style=3D""> =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B -- Mike



From: David McGrew (mcgre= w) [mailto:mcgrew@cisco.com]
Sent: Monday=2C November 12=2C 2012 11:43 AM
To: Mike Jones=3B cfrg@irtf.org= =3B jose@ietf.org
Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-S= HA=2C version 01


Hi Mike=2C


From: Mike Jones <=3BMichael.Jones@microsoft.com>=3B
Date: Monday=2C November 12=2C 2012 1:55 PM
To: Cisco Employee <=3Bmcgrew@cisco.com>=3B=2C "=3Bcfrg@irtf.org"= =3B <=3Bcfrg@irt= f.org>=3B=2C "=3Bjose@ietf= .org"=3B <=3Bjose@ietf.org>=3B
Subject: RE: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-S= HA=2C version 01


A= s background=2C if there was a version of this spec that did not assume tha= t the parameters would be concatenated together in a specific way=2C but left them as independent inputs and outputs=2C as AE= S GCM and AES CTR do=2C it would be a better match for JOSE=E2=80=99s use c= ase.

 =3B

I believe th= at what you are referring to is the inclusion of the authentication tag in = the authenticated ciphertext.  =3B This is not just a property of draft-mcgrew-aead-aes-cbc-hmac-sha2=3B it is a feature = of all 19 of the AEAD algorithms that have been defined so far.  =3B Fo= r comparison=2C =3Bdraft-mcgrew-aead-aes-cbc-hmac-sha2 says =3B


 =3B &nb= sp=3B  =3B  =3BThe AEAD Ciphertext consists of the string S=2C with= the string T

 =3B &nb= sp=3B  =3B  =3Bappended to it.  =3BThis Ciphertext is returned = as the output of the

 =3B &nb= sp=3B  =3B  =3BAEAD encryption operation.

 =3B

Where S is t= he ciphertext and T is the authentication tag.  =3B =3BRFC 5116 say= s


 =3B &nb= sp=3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B  = =3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B  =3B=  =3B"=3BThe AEAD_AES_128_GCM ciphertext is formed by

 =3B &nb= sp=3Bappending the authentication tag provided as an output to the GCM

 =3B &nb= sp=3Bencryption operation to the ciphertext that is output by that

 =3B &nb= sp=3Boperation."=3B


David=


&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B -- Mike


From: mcgrew@cisco.com
To: cfrg@irtf.org=3B jose@ietf.org
Date: Mon=2C 12 Nov 2012 18:20:57 +=3B0000
CC: Kenny.Paterson@rhul.ac.uk<= /a>
Subject: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA=2C versi= on 01

Hi=2C
This draft has been proposed for use in the JOSE WG <=3Bhttp://= datatracker.ietf.org/wg/jose/>=3B =3B=2C where its adoption would allow the working group to omit "=3Braw"=3B unauthenticated = encryption=2C e.g. AES-CBC=2C and only include authenticated encryption. &n= bsp=3B Thus I am asking for your help in making =3B
John Foley generated test cases that correspond to the curre= nt version of the draft=2C but I didn't include these in the draft because = I did not yet get confirmation from a second independent implementation.  =3B With hope=2C there will not be any need for any n= ormative changes=2C and I will include these after I get confirmation. &nbs= p=3B
Thanks=2C
David

_______________________________________________ jose mailing list jose@ietf.org ht= tps://www.ietf.org/mailman/listinfo/jose
--_c18d8d59-6f64-4747-8f62-240c572c3402_-- From rbarnes@bbn.com Mon Nov 12 18:43: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 4DA7521F8841 for ; Mon, 12 Nov 2012 18:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.742 X-Spam-Level: X-Spam-Status: No, score=-106.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ir9qpMKy-Uf8 for ; Mon, 12 Nov 2012 18:43:32 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3B55021F8830 for ; Mon, 12 Nov 2012 18:43:32 -0800 (PST) Received: from [128.89.253.114] (port=61800) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TY6TJ-000Oex-NC; Mon, 12 Nov 2012 21:43:29 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Richard L. Barnes" In-Reply-To: Date: Mon, 12 Nov 2012 21:43:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <747787E65E3FBD4E93F0EB2F14DB556B0F50A90C@xmb-rcd-x04.cisco.com> To: Michael Jones X-Mailer: Apple Mail (2.1499) Cc: mcgrew@cisco.com, jose@ietf.org Subject: Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer 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: Tue, 13 Nov 2012 02:43:33 -0000 Unfortunately, the minutes from that session don't appear very clear on = the point [1]. As I recall, people were OK with going AEAD-only = precisely because it would be so easy to do with = draft-mcgrew-aead-aes-cbc-hmac-sha2. Since it seems like a bad idea to = have people going around inventing their own AEAD algorithms (as David = notes below), it would make sense to at least RECOMMEND that the McGrew = draft be the way people build AEAD algorithms from non-AEAD primitives, = when no AEAD algorithms are available natively. =20 [1] On Nov 12, 2012, at 3:09 PM, Michael Jones = wrote: > I believe that you're slightly misstating the consensus below. Yes, = there was consensus that we should move to only authenticated encryption = algorithms. The drafts have already done this. There was not consensus = to spedifically use the algorithms in = draft-mcgrew-aead-aes-cbc-hmac-sha2. If there was, they would already = be in the drafts, as the drafts have been updated to incorporate all = consensus decisions since then. > =20 > There *was* an informal agreement that, should someone want to, they = could add the algorithms in draft-mcgrew-aead-aes-cbc-hmac-sha2 to the = JWA algorithms registry, and then people could also use them, should = they so desire. It's a potentially subtle, but important distinction. > =20 > Best wishes, > -- Mike=20 > From: mcgrew@cisco.com > To: michael_b_jones@hotmail.com > Date: Mon, 12 Nov 2012 16:43:21 +0000 > CC: jose@ietf.org > Subject: [jose] Choice for WG: Use a KDF with AES CBC or use a longer = key >=20 > Hi Mike, >=20 > Please see inline. >=20 > From: Michael Jones > To: , > Date: Sun, 11 Nov 2012 17:30:54 -0800 > In-reply-to: <255B9BB34FB7D647A506DC292726F6E11500331CA9 at = WSMSG3153V.srv.dir.telstra.com> > References: , = <255B9BB34FB7D647A506DC292726F6E11500331CA9 at = WSMSG3153V.srv.dir.telstra.com> > List-id: Javascript Object Signing and Encryption >=20 > Using draft-mcgrew-aead-aes-cbc-hmac-sha2 is not the same thing as = (1). For instance, as was discussed after David's presentation at IETF = 84, draft-mcgrew-aead-aes-cbc-hmac-sha2 does not follow the pattern of = AEAD algorithms such as AES GCM, which have two inputs (plaintext, = "additional authenticated data"), and two outputs (ciphertext, = "authentication tag"). Instead, it adds a step combining the ciphertext = and "authentication tag" outputs. >=20 > > draft-mcgrew-aead-aes-cbc-hmac-sha2 does use exactly the same = interface as AES-GCM, RFC 5116, and the other AEAD algorithms that make = use of that interface. > To make this more clear, I can make the following addition. Section = 2.1 starts out as "We briefly recall the encryption interface defined in = Section 2 of [RFC5116]." I will add "which is used by all of the = algorithms defined in this note". > >=20 > If you read the draft, implementation of = draft-mcgrew-aead-aes-cbc-hmac-sha2 has a lot more steps than what we = have for A128CBC+HS256 and A256CBC+HS512. It requires generating and = adding specific padding bytes. It prefixes the ciphertext with the IV. = It includes the length of the "additional authenticated data" in the MAC = calculation. It combines the two outputs into one. For decryption, = likewise, the two outputs must be split apart, the IV must be split = apart, etc. >=20 > All of these are steps that implementations could get wrong, resulting = in interoperability problems. By keeping all the parameters separate, = our current A128CBC+HS256 and A256CBC+HS512 algorithms eliminate those = steps. >=20 > > draft-mcgrew-aead-aes-cbc-hmac-sha2 has all of the required steps for = authenticated encryption, and does not have any extraneous steps. = Things like plaintext padding need to be specified, and it is critical = to have the length of the associated data included in the MAC input (see = Section 6, third paragraph, of draft-mcgrew). =20 >=20 > The fact that implementations might get these details wrong is why = they belong in the crypto algorithm, and not in the JOSE implementation. = Consider, for instance, that with the AEAD approach these details = would get test coverage from the AEAD test cases; otherwise, there are = details that would go untested. >=20 > >=20 > I'm sorry for the apparent confusion between (1) and = draft-mcgrew-aead-aes-cbc-hmac-sha2. While they both explicitly = represent the CMK and CEK, and use the same underlying crypto = operations, the details differ in ways that are likely to matter to = implementers. >=20 > > When JOSE met at IETF84, the consensus of the room was to use AEAD and = draft-mcgrew-aead-aes-cbc-hmac-sha2, and omit unauthenticated = encryption. That's what JOSE should do, as it is the technically best = solution. I will ask Kevin Igoe to move draft-mcgrew forward to RFC. =20= >=20 > >=20 > If there was a version of draft-mcgrew-aead-aes-cbc-hmac-sha2 that = kept all the inputs and outputs separate, I agree that it would be a = reasonable candidate for JOSE to consider. But unlike AES GCM, that's = not what it does. >=20 > > draft-mcgrew-aead-aes-cbc-hmac-sha2 uses the same interface as does = AEAD_AES_128_GCM; see Section 5.1 of RFC 5116. =20 >=20 > David > >=20 > -- Mike >=20 > > From: James.H.Manger at team.telstra.com > > To: michael_b_jones at hotmail.com; jose at ietf.org > > Date: Mon, 12 Nov 2012 09:23:37 +1100 > > Subject: RE: [jose] Choice for WG: Use a KDF with AES CBC or use a = longer key > > > > > So I=92d like to explicitly ask the working group. Do you want us = to: > > > > > > (1) Use the concatenation of random CEK and CIK values as the CMK = for AES CBC, resulting in a longer CMK? > > > (2) Continue to use a KDF to generate the CEK and CIK from a = shorter CMK? > > > > > > 1. Use draft-mcgrew-aead-aes-cbc-hmac-sha2 > > > > -- > > James Manger >=20 >=20 >=20 > _______________________________________________ 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 rbarnes@bbn.com Mon Nov 12 19:02: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 C70CE21F884D for ; Mon, 12 Nov 2012 19:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.724 X-Spam-Level: X-Spam-Status: No, score=-106.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIVHhO-zToSB for ; Mon, 12 Nov 2012 19:02:48 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C3D0A21F8847 for ; Mon, 12 Nov 2012 19:02:47 -0800 (PST) Received: from [128.89.253.114] (port=61935) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TY6lu-000Ohy-C1; Mon, 12 Nov 2012 22:02:42 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Richard L. Barnes" In-Reply-To: Date: Mon, 12 Nov 2012 22:02:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B168042967394366880D09@TK5EX14MBXC285.redmond.corp.microsoft.com>, , , , <4E1F6AAD24975D4BA5B16804296739436688123A@TK5EX14MBXC285.redmond.corp.microsoft.com>, , , , , , <4E1F6AAD24975D4BA5B16804296739436688296F@TK5EX14MBXC285.redmond.corp.microsoft.com>, , , , <255B9BB34FB7D647A506DC292726F6E114FFB9FC5D@WSMSG3153V.srv.dir.telstra.com>, , <255B9BB34FB7D647A506DC292726F6E115001D5886@WSMSG3153V.srv.dir.telstra.com>, , <255B9BB34FB7D647A506DC292726F6E11500331F3B@WSMSG3153V.srv.dir.telstra.com> To: Michael Jones X-Mailer: Apple Mail (2.1499) Cc: james.h.manger@team.telstra.com, jose@ietf.org Subject: Re: [jose] NIST Concat KDF 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, 13 Nov 2012 03:02:49 -0000 This argument does not seem terribly convincing. You seem to be missing = the importance of re-using things that have been used before in this = context. On the one hand, we invent something new "based on Concat", something = which would has not been evaluated and approved for use in any context = where that is important. =20 On the other hand, the TLS PRF is very broadly used and trivial to = implement. While I don't know he chapter and verse, it seems likely = that someone has considered the implications of trying to get a TLS = stack approved for use in, say, a Suite B environment. Unless you really want to do the hard work of demonstrating the strength = of this new KDF, let's just stick with something we all know. I would = be fine with the TLS PRF, or with just using longer keys (McGrew-style). = Concat would also be OK, if we did it properly; that just seems to be a = bad fit with the JOSE operational model. (BTW: Using the TLS PRF would be a concrete use case for a nonce = parameter.) --Richard =20 On Nov 11, 2012, at 10:51 PM, Michael Jones = wrote: > As background, the NIST Concat KDF was chosen over the TLS 1.2 PRF = because it was already specified for use with key agreement in XML ENC, = whereas the TLS PRF is a one-off. It was thought that, particularly for = key agreement, libraries were more likely to support key agreement using = Concat than a custom KDF, making JWE implementations easier. The = authors also decided that it made sense to use the same KDF both for key = agreement and to derive CEK and CIK values from a CMK value, to make = life easier for implementers. Hence, the use of Concat for both use = cases. > =20 > You wrote that "it demonstrably doesn't meets Concat=92s security = design (e.g. JOSE can derive the same key for diff user ids as JOSE can = omit the ids from the calculation)". It's true that JOSE could derive = the same key for different users, but only if the two users use the same = CMK value, which the spec requires to be randomly generated for each = interaction. If an implementation is repeatedly generating THE SAME 256 = or 512 bit random numbers, I suspect it has bigger problems than the = ones we're talking about. I'll also point out that = draft-mcgrew-aead-aes-cbc-hmac-sha2 puts all its eggs in the basket of = the random number generator, and you seem to be in favor of that. By = using Concat without PartyUInfo and PartyVInfo fields, we'd be no worse = off than mcgrew. > =20 > As for me, I'd be perfectly happy to change the drafts to say = something like "a KDF based upon the Concat KDF" (or to not mention = Concat at all), drop the PartyUInfo and PartyVInfo parameters and be = done with it. The TLS PRF doesn't use them and it seems to be fine. It = doesn't sound you like them either. Might that be a resolution to this = whole long discussion? My only worry is that we might get push-back = from the security community as a result. Feedback from others would be = appreciated. > =20 > Thanks, > -- Mike > =20 > P.S. The AlgorithmID/PartyUInfo ambiguity you describe is not = possible because the only two "enc" values that use Concat in this way = are "A128CBC+HS256" and "A256CBC+HS512". It truly is fixed length. The = behavior of other "enc" values are beyond the scope of this particular = discussion. >=20 > > From: James.H.Manger@team.telstra.com > > To: michael_b_jones@hotmail.com; jose@ietf.org > > Date: Mon, 12 Nov 2012 10:45:32 +1100 > > Subject: Re: [jose] NIST Concat KDF > >=20 > > Mike, > >=20 > > > By adding the length prefix to the PartyUInfo and PartyVInfo = values, I fail to see how the JoBethAnne ambiguity could remain = possible. I addressed that per your earlier note in the -07 drafts by = adding the length prefix. > >=20 > > The JoBeth/Anne vs Jo/BethAnne ambiguity is solved. An = AlgorithmID/PartyUInfo ambiguity remains. It feels more theoretical, but = it simply does not need to exist. The following 2 JOSE messages produce = the same KDF input. They shouldn't. It is the sort of situation NIST = Concat KDF is specifically designed to avoid. > >=20 > > {"alg":"A128CBC+HS256\u0000\u0000\u0000\u0007X", "epu":"Jo", = "epv":"BethAnne"} > >=20 > > {"alg":"A128CBC+HS256", "epu":"X\u0000\u0000\u0000\u0002Jo", = "epv":"BethAnne"}=20 > >=20 > >=20 > > > You wrote that the AlgorithmID doesn=92t have a length prefix. = That=92s true. The Concat definition allows fields to not contain a = length prefix when they are fixed length, as AlgorithmID is in this = case. > >=20 > > AlgorithmID includes the value of the "enc" field, which is hardly = fixed length. > >=20 > >=20 > >=20 > > > You wrote =93Can=92t the spec just do what NIST 800-56A says if it = really wants to use it?=94. I suspect that underlying this comment is = the actual difference you have with the specs=92 use of Concat. It=92s = not a goal of JWA to make it possible to use every feature of Concat. = (Concat isn=92t an end unto itself.) Hence the spec not needing to use = SuppPrivInfo, etc. > >=20 > > I have no desire to use SuppPrivInfo. I am completely fine with JOSE = saying it must be omitted. I don't really even want to use PartyUInfo = and PartyVInfo. NIST 800-56A Concat KDF, however, is designed to ensure = the same key cannot be derived if the algorithm, the id of either party, = or any other important detail of the context is different. If JOSE says = it uses Concat it needs to deliver these properties. If JOSE does not = need these properties then it shouldn't falsely imply it achieves them = by saying it uses Concat. > >=20 > >=20 > > > The actual goal is generating two high-quality keys from the CMK. > >=20 > > Great. Then drop the apu/apv/epu/epv stuff and don't call it NIST = Concat. > >=20 > >=20 > > > As for whether we use Concat twice to generate two keys with = different inputs and then discard the random value or whether we use = Concat once to generate a long enough output to chop it into two keys, = that seems like a distinction without a difference. > >=20 > > It probably is a distinction without a difference. So why do you = bother making the distinction from the NIST Concat KDF that JOSE says it = uses? That just unnecessarily raises a shadow of doubt. > >=20 > >=20 > > > I reviewed this decision with Jim Schaad a while back, among = others, and they concurred. The precedent for this is the TLS PRF KDF = [RFC5246], which generates keys in this manner. > >=20 > > Then use the TLS 1.2 PRF, instead of NIST Concat. > >=20 > >=20 > > > Unless there=92s an actual security argument that this (widely = used) practice is demonstrably unsafe, there doesn=92t seem to be a = reason to change. > >=20 > > JOSE says it uses NIST Concat; it demonstrably doesn't meets = Concat=92s security design (eg JOSE can derive the same key for diff = user ids as JOSE can omit the ids from the calculation); so there is a = reason to change. > >=20 > >=20 > > > I=92m trying to have us not lose sight of the fact that a core = goal of the JOSE specs is to create specs that are simple enough that = they will actually be implemented and used. > >=20 > > Sounds like a good reason not to pick NIST Concat, which chooses = more complexity for security in some corner cases. > >=20 > > -- > > 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 From dharkins@lounge.org Mon Nov 12 12:21: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 DAAF021F868D for ; Mon, 12 Nov 2012 12:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXhn+txaP9ta for ; Mon, 12 Nov 2012 12:21:14 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAC621F8674 for ; Mon, 12 Nov 2012 12:21:14 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 0F22B1022400A; Mon, 12 Nov 2012 12:21:13 -0800 (PST) Received: from 50.84.73.44 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 12 Nov 2012 12:21:13 -0800 (PST) Message-ID: <3bfc8545d5829d56d26ceafba6d8d1f3.squirrel@www.trepanning.net> In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F50AA95@xmb-rcd-x04.cisco.com> References: <747787E65E3FBD4E93F0EB2F14DB556B0F50AA95@xmb-rcd-x04.cisco.com> Date: Mon, 12 Nov 2012 12:21:13 -0800 (PST) From: "Dan Harkins" To: "David McGrew (mcgrew)" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Mon, 12 Nov 2012 22:26:20 -0800 Cc: Mike Jones , "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [jose] [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 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, 12 Nov 2012 20:21:15 -0000 Hi Mike, > From: Mike Jones > > > Date: Monday, November 12, 2012 1:55 PM > To: Cisco Employee >, > "cfrg@irtf.org" > >, > "jose@ietf.org" > > > Subject: RE: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, > version 01 > > As background, if there was a version of this spec that did not assume > that the parameters would be concatenated together in a specific way, but > left them as independent inputs and outputs, as AES GCM and AES CTR do, it > would be a better match for JOSE’s use case. I encourage you to look into SIV mode, an AEAD scheme found in RFC 5297. SIV was defined by Rogaway and Shrimpton (in a paper found in the RFC) and is provably secure. It takes a vector of input as additional authenticated data which will be authenticated, and a plaintext which will be authenticated and encrypted. It does not assume that the parameters are concatenated together, it's just a vector of separate inputs. Additionally, SIV mode does not require a random IV/nonce. It works just fine if you have one, and it won't collapse if it is repeated (as GCM does) or is predictable (as CBC-HMAC does), and it works if you don't have, or want to have, one. In that fashion it is more robust than other AEAD schemes. The downside is that it's slower than GCM but is probably faster than CBC-HMAC with SHA2. regards, Dan. From mcgrew@cisco.com Mon Nov 12 15:19: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 C5B7821F85D5 for ; Mon, 12 Nov 2012 15:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.538 X-Spam-Level: X-Spam-Status: No, score=-110.538 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKILapiTUL45 for ; Mon, 12 Nov 2012 15:19:51 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C5ADA21F847D for ; Mon, 12 Nov 2012 15:19:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35742; q=dns/txt; s=iport; t=1352762391; x=1353971991; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=0K7E90smBCTodgctihD4gQHc+cggu6Vd04ItE62eki8=; b=hYU8nuTiy5vHcMhhz8GdbhSw1gFUl7RtJWqLgIPV0N04fzFBDgEkJK1J bxi4RIx0EWNrrwqAn3P4ekswxtvq43yAKhLdtS6g23BMHQlmqJhfE3HQn dzZbpZjkxHlCRpUWV2ThTQtbYmB/ZYMzvW9i66MolWAmHXWr9y/4ACk7B g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIFAGeCoVCtJXG+/2dsb2JhbABEgkmuajOJBQGId4EIgh4BAQEEAQEBDwEaQQsSAQgRAwEBAQsWAQYuCxQJCAIEAQ0FCAESB4dWAw8LmXqgDIssaYNugXthA5QognCKFoMmgWuCYg2CGQ X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="141473985" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 12 Nov 2012 23:19:50 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qACNJnrx010934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Nov 2012 23:19:49 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 17:19:49 -0600 From: "David McGrew (mcgrew)" To: Michael Jones , "cfrg@irtf.org" , "jose@ietf.org" Thread-Topic: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 Thread-Index: AQHNwQJ1KPZ1PBWsRUecOePTOEDiwZfnCigA///dCgA= Date: Mon, 12 Nov 2012 23:19:48 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F50ABF8@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.228] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19356.005 x-tm-as-result: No--30.170200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_747787E65E3FBD4E93F0EB2F14DB556B0F50ABF8xmbrcdx04ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 12 Nov 2012 22:26:20 -0800 Cc: "Paterson, Kenny" Subject: Re: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 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, 12 Nov 2012 23:19:52 -0000 --_000_747787E65E3FBD4E93F0EB2F14DB556B0F50ABF8xmbrcdx04ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Michael Jones > Date: Monday, November 12, 2012 3:25 PM To: Cisco Employee >, "cfrg@irtf.= org" >, "jose@iet= f.org" > Subject: RE: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, ver= sion 01 OK, I admit that the way I phrased my request may not be exactly in line wi= th the way the =93AEAD=94 terminology is used. I can correct that. That=92= s syntax. I was using =93AEAD=94 as a shorthand for the working group=92s = decision to use only authenticated encryption algorithms =96 not to mean th= e particular combined representation of those parameters apparently specifi= ed in the AEAD draft. I will correct the terminology usage in the next rev= ision of the JOSE specifications. The semantic point remains that it=92s cleaner and more flexible to have th= e Key, the Plaintext, IV, and =93additional authenticated data=94 parameter= s all be separate inputs and the Ciphertext and =93authentication tag=94 al= l be separate outputs. In JOSE=92s particular use case, that would be a sig= nificantly better match and easier for implementers to use. JOSE already has a way of combining the inputs and outputs that=92s inheren= t to its representation, and it doesn=92t match the one you=92ve specified.= GCM, CTR, and the current JOSE-specified algorithms are a great fit for t= his, as they can directly use that representation. The AEAD pattern you ci= te requires disassembly of the components of the AEAD-specific representati= on to be able to use the combinations already present in the JOSE represent= ations and then reassembly at decryption time. That=92s just more work for= implementers, and it=92s not semantically necessary work. One could just as easily argue that the unnecessary work comes from the fac= t that draft-ietf-jose-json-web-algorithms-07 defines its own AEAD algorith= ms, which do not use the RFC 5116 interface. The draft confusingly refere= nces that RFC after it defines AEAD, but then does something different. I= f the plan is really going to be for the JOSE WG to define its own AEAD alg= orithms that are incompatible (which I hope is not the case), the differenc= es and motivation deserve to be documented. The motivation for 5116 incorporating the authentication data into the ciph= ertext was to simplify the interface and move more of the crypto details un= der the crypto interface. These are still valid motivations, though at th= is point the most important reason to use the interface is to avoid gratuit= ous incompatibility. Other protocols have not had any trouble in using the= 5116 interface; See RFC 5288 (TLSv1.2) Section 6.2.3.3, RFC 5647 (SSH GCM)= , or draft-ietf-avtcore-srtp-aes-gcm, for instance. Are you open to specifying versions of your algorithms that don=92t require= a particular combination method for the parameters, but instead leave the = combination up to the use case? I=92m fine with you also specifying a spec= ific combination method as an optional feature of the specification. But i= t shouldn=92t be part of the algorithm definition, just like it isn=92t for= GCM. I am not dogmatically opposed to other interfaces, but the best solution he= re is for JOSE to actually use the 5116 interface, like this: X.Y. Authenticated Encryption This section defines the specifics of encrypting the JWE Plaintext Using the Authenticated Encryption with Associated Data (AEAD) as defined in RFC 5116. The authenticated encryption operation has four inputs, as follows: The secret key is the CMK. The associated data is the bytes of the ASCII representation of the co= ncatenation of the Encoded JWE Header, a period ('.') character, the Encoded JWE Encrypted Key, a second period character ('.'), and the Encoded JWE Initialization Vector, per Section 5 of the JWE specification. The plaintext , which contains the data to be encrypted and authenticated. A nonce N, with a length of either 0 or 96 bits. If the length is zero, the nonce is omitted. Otherwise, the nonce is as described in Section 3 of RFC 5116. There is a single output, the Ciphertext. The "enc" header parameter values are set as follows: "enc" Algorithm ----------------------------------------------------------------------- "A128GCM" AEAD_AES_128_GCM "A256GCM" AEAD_AES_256_GCM "A128CHS" AEAD_AES_128_CBC_HMAC_SHA_256 "A256CHS" AEAD_AES_256_CBC_HMAC_SHA_512 "A128SIV" AEAD_AES_SIV_CMAC_256 "A256SIV" AEAD_AES_SIV_CMAC_384 See for the references corresponding to these symbolic names. If we want to make actual progress on crypto interfaces, the thing that wou= ld be worth doing is defining a simpler interface that moves the nonce deta= ils into the ciphertext (and thus away from the user). Moving the authent= ication data out of the ciphertext would be movement in the wrong direction= , in my opinion. David Best wishes, -- Mike From: David McGrew (mcgrew) [mailto:mcgrew@cisco.com] Sent: Monday, November 12, 2012 11:43 AM To: Mike Jones; cfrg@irtf.org; jose@ietf.org Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, ver= sion 01 Hi Mike, From: Mike Jones > Date: Monday, November 12, 2012 1:55 PM To: Cisco Employee >, "cfrg@irtf.= org" >, "jose@iet= f.org" > Subject: RE: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, ver= sion 01 As background, if there was a version of this spec that did not assume that= the parameters would be concatenated together in a specific way, but left = them as independent inputs and outputs, as AES GCM and AES CTR do, it would= be a better match for JOSE=92s use case. I believe that what you are referring to is the inclusion of the authentica= tion tag in the authenticated ciphertext. This is not just a property of = draft-mcgrew-aead-aes-cbc-hmac-sha2; it is a feature of all 19 of the AEAD = algorithms that have been defined so far. For comparison, draft-mcgrew-ae= ad-aes-cbc-hmac-sha2 says The AEAD Ciphertext consists of the string S, with the string T appended to it. This Ciphertext is returned as the output of the AEAD encryption operation. Where S is the ciphertext and T is the authentication tag. RFC 5116 says "The AEAD_AES_128_GCM ciphertext is fo= rmed by appending the authentication tag provided as an output to the GCM encryption operation to the ciphertext that is output by that operation." David -- Mike ________________________________ From: mcgrew@cisco.com To: cfrg@irtf.org; jose@ietf.org Date: Mon, 12 Nov 2012 18:20:57 +0000 CC: Kenny.Paterson@rhul.ac.uk Subject: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version= 01 Hi, There is a new version of "Authenticated Encryption with AES-CBC and HMAC-S= HA", and I would appreciate your review. It is online at The diff between the current and the previous version is av= ailable at This draft has been proposed for use in the JOSE WG , where its adopti= on would allow the working group to omit "raw" unauthenticated encryption, = e.g. AES-CBC, and only include authenticated encryption. Thus I am asking= for your help in making John Foley generated test cases that correspond to the current version of t= he draft, but I didn't include these in the draft because I did not yet get= confirmation from a second independent implementation. With hope, there = will not be any need for any normative changes, and I will include these af= ter I get confirmation. Thanks, David _______________________________________________ jose mailing list jose@ietf= .org https://www.ietf.org/mailman/listinfo/jose --_000_747787E65E3FBD4E93F0EB2F14DB556B0F50ABF8xmbrcdx04ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7261A6CFF5A1E0429F29B0D910A05A09@cisco.com> Content-Transfer-Encoding: quoted-printable


From: Michael Jones <michael_b_jones@hotmail.com>
Date: Monday, November 12, 2012 3:2= 5 PM
To: Cisco Employee <mcgrew@cisco.com>, "cfrg@irtf.org" <= cfrg@irtf.org>, "jose@ietf.org= " <jose@ietf.org>
Subject: RE: [jose] Authenticated E= ncryption with AES-CBC and HMAC-SHA, version 01


OK,= I admit that the way I phrased my request may not be exactly in line with = the way the =93AEAD=94 terminology is used.  I can correct that. That=92s syntax.  I was using =93AEAD=94 as a shorthand for the working group=92s decision to= use only authenticated encryption algorithms =96 not to mean the particula= r combined representation of those parameters apparently specified in the A= EAD draft.  I will correct the terminology usage in the next revision of the JOS= E specifications.


The= semantic point remains that it=92s cleaner and more flexible to have the K= ey, the Plaintext, IV, and =93additional authenticated data=94 parameters all be separate inputs and the Ciphertext and =93authen= tication tag=94 all be separate outputs.=  In JOSE=92s particular use case, that would be a significantly= better match and easier for implementers to use.



JOS= E already has a way of combining the inputs and outputs that=92s inherent t= o its representation, and it doesn=92t match the one you=92ve specified.  GCM, CTR, and the current JOSE-specified algorithms are a great fit for t= his, as they can directly use that representation.  The AEAD pattern you cite requires disassembly of the components of = the AEAD-specific representation to be able to use the combinations already= present in the JOSE representations and then reassembly at decryption time= .  That=92s just more work for implementers, and it=92s not semanticall= y necessary work.

One could just as easily argue that the unnecessary work comes from th= e fact that draft-ietf-jose-json-web-algorithms-07 defines its own AEA= D algorithms, which do not use the RFC 5116 interface.   The draft con= fusingly references that RFC after it defines AEAD, but then does something different.   If the plan is really going to b= e for the JOSE WG to define its own AEAD algorithms that are incompatible (= which I hope is not the case), the differences and motivation deserve to be= documented.  

The motivation for 5116 incorporating the authentication data into the ciph= ertext was to simplify the interface and move more of the crypto details un= der the crypto interface.   These are still valid motivations, though = at this point the most important reason to use the interface is to avoid gratuitous incompatibility.  Other p= rotocols have not had any trouble in using the 5116 interface; See RFC 5288= (TLSv1.2) Section 6.2.3.3, RFC 5647 (SSH GCM), or draft-ietf-avtcore-= srtp-aes-gcm, for instance.  


Are= you open to specifying versions of your algorithms that don=92t require a = particular combination method for the parameters, but instead leave the combination up to the use case?  I=92m fine with you also specifying a specific combination method as= an optional feature of the specification.  But it shouldn=92t be part = of the algorithm definition, just like it isn=92t for GCM.

I am not dogmatically opposed to other interfaces, but the best solution he= re is for JOSE to actually use the 5116 interface, like this:

X.Y. Auth= enticated Encryption

  &n= bsp;This section defines the specifics of encrypting the JWE Plaintext
  &n= bsp;Using the Authenticated Encryption with Associated Data (AEAD)
  &n= bsp;as defined in RFC 5116.   The authenticated encryption operation 
   has four inputs, as follows:

     The secret key is the CMK.

     The associated data is the bytes of the ASCII= representation of the concatenation of
     the Encoded JWE Header, a period ('.') character, = the Encoded JWE
     Encrypted Key, a second period character ('.'), an= d the Encoded JWE
     Initialization Vector, per Section 5 of the JWE sp= ecification.
      The plaintext , which contains the data to be enc= rypted and
      authenticated.

      A nonce N, with a length of either 0 or 96 b= its.   If the length
  &n= bsp;   is zero, the nonce is omitted.  Otherwise, the nonce
  &n= bsp;   is as described in Section 3 of RFC 5116.   

   There is a single output, the Ciphertext.  

   The "enc" header  parameter v= alues are set as follows:

    "enc"           &n= bsp;      Algorithm            = ;             
  &n= bsp; ----------------------------------------------------------------------= -
    "A128GCM"     = ;AEAD_AES_128_GCM                 &= nbsp;                
    "A256GCM"     AEAD_AES_256_GCM &n= bsp;                     =             
     "A128CHS"      AEAD_AE= S_128_CBC_HMAC_SHA_256    
     "A256CHS&= quot;      AEAD_AES_256_CBC_HMAC_SHA_512  
      "A128SIV"      AEAD_AES_= SIV_CMAC_256
      "A256SIV"      AEAD_AES_= SIV_CMAC_384

  &n= bsp;  references corresponding to these symbolic names.=  

If we wan= t to make actual progress on crypto interfaces, the thing that would be wor= th doing is defining a simpler interface that moves the nonce details into = the ciphertext (and thus away from the user).   Moving the authentication data out of the ciphertext would b= e movement in the wrong direction, in my opinion.   

David


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

       &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;  -- Mike



From: David McGrew (mcg= rew) [mailto:mcgrew@cisco.com]
Sent: Monday, November 12, 2012 11:43 AM
To: Mike Jones; cfrg@irtf.org; = jose@ietf.org
Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-S= HA, version 01


Hi Mike,


From: Mike Jones <Michael.Jones@microsoft.com&= gt;
Date: Monday, November 12, 2012 1:55 PM
To: Cisco Employee <mcgrew@cisco.com>, "cfrg@irtf.org" <cfrg@irtf.org>, "jose@ietf.o= rg" <jose@ietf.org>
Subject: RE: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-S= HA, version 01


As = background, if there was a version of this spec that did not assume that th= e parameters would be concatenated together in a specific way, but left them as independent inputs and outputs, as AES= GCM and AES CTR do, it would be a better match for JOSE=92s use case.

 

I believe th= at what you are referring to is the inclusion of the authentication tag in = the authenticated ciphertext.   This is not just a property of draft-mcgrew-aead-aes-cbc-hmac-sha2; it is a featur= e of all 19 of the AEAD algorithms that have been defined so far.   Fo= r comparison, draft-mcgrew-aead-aes-cbc-hmac-sha2 says 


   = ;    The AEAD Ciphertext consists of the string S, with the strin= g T

   = ;    appended to it.  This Ciphertext is returned as the out= put of the

   = ;    AEAD encryption operation.

 

Where S is t= he ciphertext and T is the authentication tag.   RFC 5116 says


   = ;                     &nb= sp;            "The AEAD_AES_128_GCM cip= hertext is formed by

   = ;appending the authentication tag provided as an output to the GCM

   = ;encryption operation to the ciphertext that is output by that

   = ;operation."


David


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


From: mcgrew@cisco.com
To: cfrg@irtf.org; jose@ietf.org
Date: Mon, 12 Nov 2012 18:20:57 +0000
CC: Kenny.Paterson@rhul.ac.uk<= /a>
Subject: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version= 01

Hi,
This draft has been proposed for use in the JOSE WG <http://datatracker.ietf.= org/wg/jose/> , where its adoption would allow the working grou= p to omit "raw" unauthenticated encryption, e.g. AES-CBC, and only include authenticated encryption.   Thus I am askin= g for your help in making 
John Foley generated test cases that correspond to the current version of t= he draft, but I didn't include these in the draft because I did not yet get= confirmation from a second independent implementation.   With hope, t= here will not be any need for any normative changes, and I will include these after I get confirmation.  
Thanks,
David

_______________________________________________ jose mailing list jose@ietf.org ht= tps://www.ietf.org/mailman/listinfo/jose
 --_000_747787E65E3FBD4E93F0EB2F14DB556B0F50ABF8xmbrcdx04ciscoc_-- From mcgrew@cisco.com Mon Nov 12 15:39: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 8440321F8786 for ; Mon, 12 Nov 2012 15:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.556 X-Spam-Level: X-Spam-Status: No, score=-110.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnD-Y5pXAwGq for ; Mon, 12 Nov 2012 15:39:35 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 983F221F8674 for ; Mon, 12 Nov 2012 15:39:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2468; q=dns/txt; s=iport; t=1352763575; x=1353973175; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=CfhQMd/wi5U9Z3cUDSDgdUCOlZv597bwG8WrdKDjZ5k=; b=RShkj5zpEIguV6Gn6a3VlEY4f/bSR7ey/HTqWfU6xcB2wi25fyK+yNX7 kxBE/Oxg095o51+vnFj3NuFR9AVTMUjsqFFN0/x3fAvV8rejdJmTWRg1d PE2kxLsBBGkTLIi9BBnKpVJPYfUkF1Pt+k3sLqQVZWaGEzkMyEXrbeTzU 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAG+HoVCtJV2c/2dsb2JhbABEw2OBCIIeAQEBAwESAQVhEgEIDgMDAQILHTkUCQgCBA4FCBqHYgaaBKANjBWDboF7YQOIJZwvgWuCYg2CGQ X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="141455826" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 12 Nov 2012 23:39:35 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qACNdY8V000976 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Nov 2012 23:39:35 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 17:39:34 -0600 From: "David McGrew (mcgrew)" To: Dan Harkins Thread-Topic: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 Thread-Index: AQHNwRNEN8doFmnIpEGgEt2l6seQrpfm7JkA Date: Mon, 12 Nov 2012 23:39:33 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F50AC3E@xmb-rcd-x04.cisco.com> In-Reply-To: <3bfc8545d5829d56d26ceafba6d8d1f3.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.228] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19356.005 x-tm-as-result: No--40.253500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 12 Nov 2012 22:26:20 -0800 Cc: Mike Jones , "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [jose] [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 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, 12 Nov 2012 23:39:36 -0000 On 11/12/12 3:21 PM, "Dan Harkins" wrote: > > Hi Mike, > >> From: Mike Jones >> > >> Date: Monday, November 12, 2012 1:55 PM >> To: Cisco Employee >, >> "cfrg@irtf.org" >> >, >> "jose@ietf.org" >> > >> Subject: RE: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, >> version 01 >> >> As background, if there was a version of this spec that did not assume >> that the parameters would be concatenated together in a specific way, >>but >> left them as independent inputs and outputs, as AES GCM and AES CTR do, >>it >> would be a better match for JOSE=B9s use case. > > I encourage you to look into SIV mode, an AEAD scheme found in >RFC 5297. SIV was defined by Rogaway and Shrimpton (in a paper >found in the RFC) and is provably secure. > > It takes a vector of input as additional authenticated data which will >be authenticated, and a plaintext which will be authenticated and >encrypted. It does not assume that the parameters are concatenated >together, it's just a vector of separate inputs. > > Additionally, SIV mode does not require a random IV/nonce. It works >just fine if you have one, and it won't collapse if it is repeated (as GCM >does) or is predictable (as CBC-HMAC does), and it works if you don't >have, or want to have, one. In that fashion it is more robust than other >AEAD schemes. The downside is that it's slower than GCM but is probably >faster than CBC-HMAC with SHA2. AES-SIV is in several ways technically superior to AES-CBC-HMAC-SHA. However, the motivation to use the latter algorithm is its widespread availability, as I understand it. Mike and some other folks did a survey of what crypto that is available. (Perhaps someone can send a reference, it is a good survey.) Despite SIV's flexibility, it doesn't address Mike's complaint, because it does not have an authentication tag that is separate from the ciphertext. Instead, it has the synthetic IV (which acts like an auth tag) combined with the ciphertext. As an aside, if SIV is used for JOSE, it can use the RFC 5116 interface (see Sections 6.1-6.3 of the SIV RFC) and essentially would need to do so. =20 David > > regards, > > Dan. > > > From dharkins@lounge.org Mon Nov 12 16:06: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 5A59021F8782 for ; Mon, 12 Nov 2012 16:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74z-4so2nBct for ; Mon, 12 Nov 2012 16:06:44 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id BFEF421F875C for ; Mon, 12 Nov 2012 16:06:44 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 42DAB1022400A; Mon, 12 Nov 2012 16:06:44 -0800 (PST) Received: from 50.84.73.44 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 12 Nov 2012 16:06:44 -0800 (PST) Message-ID: <20a4747903e232548d778f1f1d171868.squirrel@www.trepanning.net> In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F50AC3E@xmb-rcd-x04.cisco.com> References: <747787E65E3FBD4E93F0EB2F14DB556B0F50AC3E@xmb-rcd-x04.cisco.com> Date: Mon, 12 Nov 2012 16:06:44 -0800 (PST) From: "Dan Harkins" To: "David McGrew (mcgrew)" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Mon, 12 Nov 2012 22:26:20 -0800 Cc: Mike Jones , "cfrg@irtf.org" , Dan Harkins , "jose@ietf.org" Subject: Re: [jose] [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 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, 13 Nov 2012 00:06:45 -0000 Hi David, On Mon, November 12, 2012 3:39 pm, David McGrew (mcgrew) wrote: > > > On 11/12/12 3:21 PM, "Dan Harkins" wrote: > >> >> Hi Mike, >> >>> From: Mike Jones >>> > >>> Date: Monday, November 12, 2012 1:55 PM >>> To: Cisco Employee >, >>> "cfrg@irtf.org" >>> >, >>> "jose@ietf.org" >>> > >>> Subject: RE: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, >>> version 01 >>> >>> As background, if there was a version of this spec that did not assume >>> that the parameters would be concatenated together in a specific way, >>>but >>> left them as independent inputs and outputs, as AES GCM and AES CTR do, >>>it >>> would be a better match for JOSE¹s use case. >> >> I encourage you to look into SIV mode, an AEAD scheme found in >>RFC 5297. SIV was defined by Rogaway and Shrimpton (in a paper >>found in the RFC) and is provably secure. >> >> It takes a vector of input as additional authenticated data which will >>be authenticated, and a plaintext which will be authenticated and >>encrypted. It does not assume that the parameters are concatenated >>together, it's just a vector of separate inputs. >> >> Additionally, SIV mode does not require a random IV/nonce. It works >>just fine if you have one, and it won't collapse if it is repeated (as >> GCM >>does) or is predictable (as CBC-HMAC does), and it works if you don't >>have, or want to have, one. In that fashion it is more robust than other >>AEAD schemes. The downside is that it's slower than GCM but is probably >>faster than CBC-HMAC with SHA2. > > AES-SIV is in several ways technically superior to AES-CBC-HMAC-SHA. > However, the motivation to use the latter algorithm is its widespread > availability, as I understand it. Mike and some other folks did a survey > of what crypto that is available. (Perhaps someone can send a reference, > it is a good survey.) Well, there is no widespread availability of AES-CBC-HMAC-SHA either. There may be availability of AES-CBC and HMAC-SHA separately but then there is, probably, availability of AES-CTR and AES-CMAC too and that is all SIV is, a provably secure construction of those two primitives. > Despite SIV's flexibility, it doesn't address Mike's complaint, because it > does not have an authentication tag that is separate from the ciphertext. > Instead, it has the synthetic IV (which acts like an auth tag) combined > with the ciphertext. Ahh, I missed that. But I think that is probably a trivial complaint of any 5116 AEAD scheme. It should be straightforward to extract the specific sub-string from the bitstring returned by any of the appropriate schemes if he wants to copy the IV/MAC/tag/whatever into a field that is separate from the encrypted plaintext. > As an aside, if SIV is used for JOSE, it can use the RFC 5116 interface > (see Sections 6.1-6.3 of the SIV RFC) and essentially would need to do so. Good point! Regards, Dan. > David > >> >> regards, >> >> Dan. >> >> >> > > From dharkins@lounge.org Mon Nov 12 18:58: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 2C6F921F8856 for ; Mon, 12 Nov 2012 18:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VROQ7vEY9Z93 for ; Mon, 12 Nov 2012 18:58:12 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id A4A8121F8847 for ; Mon, 12 Nov 2012 18:58:12 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 14D301022400A; Mon, 12 Nov 2012 18:58:12 -0800 (PST) Received: from 50.84.73.44 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 12 Nov 2012 18:58:12 -0800 (PST) Message-ID: In-Reply-To: References: Date: Mon, 12 Nov 2012 18:58:12 -0800 (PST) From: "Dan Harkins" To: "Peter Gutmann" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Mon, 12 Nov 2012 22:26:20 -0800 Cc: mcgrew@cisco.com, cfrg@irtf.org, dharkins@lounge.org, jose@ietf.org Subject: Re: [jose] [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 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, 13 Nov 2012 02:58:13 -0000 On Mon, November 12, 2012 5:43 pm, Peter Gutmann wrote: > Dan Harkins writes: > >>The downside is that it's slower than GCM but is probably faster than >> CBC- >>HMAC with SHA2. > > A much bigger downside is that it requires two passes over the data, > making it > unusable with any streaming implementation. This limits its applicability > to > protocols with very short PDUs. That is exactly why it's slower than GCM. But the alternative that's being discussed for JOSE does 2 passes of the data anyway, one with HMAC-SHA256 and another with AES-CBC, so it sounds a little hard to believe that 2 passes is a limitation for the application at hand. Dan. From James.H.Manger@team.telstra.com Mon Nov 12 22:33: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 1AE9021F88E6 for ; Mon, 12 Nov 2012 22:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.727 X-Spam-Level: X-Spam-Status: No, score=-0.727 tagged_above=-999 required=5 tests=[AWL=0.173, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMENQ+Ta9QiJ for ; Mon, 12 Nov 2012 22:33:48 -0800 (PST) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id C96F621F88E4 for ; Mon, 12 Nov 2012 22:33:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.80,765,1344175200"; d="scan'208,217";a="101285960" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipocni.tcif.telstra.com.au with ESMTP; 13 Nov 2012 17:33:32 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="92856483" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcdni.tcif.telstra.com.au with ESMTP; 13 Nov 2012 17:33:32 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Tue, 13 Nov 2012 17:33:31 +1100 From: "Manger, James H" To: "David McGrew (mcgrew)" , "cfrg@irtf.org" , "jose@ietf.org" Date: Tue, 13 Nov 2012 17:33:30 +1100 Thread-Topic: [Cfrg] [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 Thread-Index: AQHNwQJ1KPZ1PBWsRUecOePTOEDiwZfnCigA///dCgCAAFxuQA== Message-ID: <255B9BB34FB7D647A506DC292726F6E115004FD4BA@WSMSG3153V.srv.dir.telstra.com> References: <747787E65E3FBD4E93F0EB2F14DB556B0F50ABF8@xmb-rcd-x04.cisco.com> In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F50ABF8@xmb-rcd-x04.cisco.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_255B9BB34FB7D647A506DC292726F6E115004FD4BAWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [jose] [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 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, 13 Nov 2012 06:33:49 -0000 --_000_255B9BB34FB7D647A506DC292726F6E115004FD4BAWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEwDQoNClRoaXMgaXMgbXVjaCBjbGVhcmVyLCBhbmQgbXVjaCBtb3JlIHN1aXRhYmxlIGZvciBz ZXBhcmF0aW5nIHdoYXQgZ29lcyBpbiBhIEpPU0UgbGlicmFyeSB2cyB3aGF0IGdvZXMgaW4gYSBn ZW5lcmFsLXB1cnBvc2UgY3J5cHRvIGxpYnJhcnkuIEV2ZW4gaWYgYSBKT1NFIGxpYnJhcnkgbmVl ZHMgdG8gaW1wbGVtZW50IHBhcnRzIG9mIHRoZSBjcnlwdG8gdG9kYXkgYmVjYXVzZSBuYXRpdmUg QUVBRCBzdXBwb3J0IGlzIG5vdCB5ZXQgcHJlc2VudCwgdGhpcyBzb2x1dGlvbiBtYWtlcyBpdCBt dWNoIG1vcmUgbGlrZWx5IEpPU0Ugd2lsbCBiZSBjb21wYXRpYmxlIHdpdGggbmF0aXZlIEFFQUQg YXMgaXQgYmVjb21lcyBhdmFpbGFibGUuIEkgdGhpbmsgaXQgaXMgdW5saWtlbHkgdGhhdCBuYXRp dmUgQUVBRCBzdXBwb3J0IChvbmNlIGF2YWlsYWJsZSkgd291bGQgc3VwcG9ydCBib3RoIEpPU0Ug YW5kIGRyYWZ0LW1jZ3JldyB2YXJpYW50cyBvZiBBRUFELWZyb20tQUVTLUNCQy1ITUFDLiBUaGUg ZHJhZnQtbWNncmV3IHZhcmlhbnQgaGFzIGEgYmV0dGVyIGNoYW5jZSBvZiBiZWluZyBpbXBsZW1l bnRlZCBiZWNhdXNlIGl0IGRvZXNu4oCZdCBpbXBvc2UgYSAzMyUgcGVyZm9ybWFuY2UgcGVuYWx0 eSBmb3IgdGhlIE1BQ2luZyBwYXJ0LCBhbmQgdGhlIG90aGVyIGRpZmZlcmVuY2VzIGFyZSB0cml2 aWFsLg0KDQpUaGUgZmFjdCB0aGF0IHNvbWUgZXhpc3RpbmcgQUVBRCBhbGdvcml0aG1zIChTSVYg W1JGQyA1Mjk3XSkgZG9u4oCZdCBwcm9kdWNlIGEgc2VwYXJhdGUgYXV0aGVudGljYXRpb24gdGFn IGlzIGEgY2xlYXIgaW5kaWNhdGlvbiB0aGF0IGEgc2luZ2xlIGNpcGhlcnRleHQgb3V0cHV0IGlz IGEgYmV0dGVyIGdlbmVyYWwgbW9kZWwgZm9yIEFFQUQgaW4gSk9TRSB0aGFuIHNlcGFyYXRlIGNp cGhlcnRleHQgYW5kIGludGVncml0eSB2YWx1ZXMgYXMgaW4gSldFIHRvZGF5Lg0KDQpFZGl0b3Jp YWxzOg0K4oCcSldFIEluaXRpYWxpemF0aW9uIFZlY3RvcuKAnSBzaG91bGQgYmUgcmVuYW1lZCDi gJxKV0UgTm9uY2XigJ0uDQpUaGUgbm9uY2UgcGFyYWdyYXBoIG5lZWRu4oCZdCBoYXJkd2lyZSAy IGxlbmd0aHMgKDAgYW5kIDk2IGJpdHMpIOKAkyBsZWF2ZSBpdCB0byBlYWNoIGFsZyB0byBzcGVj aWZ5Lg0KVGhlIHRhYmxlIGNhbiBpbmNsdWRlIGtleSBhbmQgbm9uY2Ugc2l6ZXMuDQogICAgImVu YyIgICAgICAgICAgICAgICAga2V5IHNpemUgICAgbm9uY2Ugc2l6ZSAgQWxnb3JpdGhtDQogICAg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCiAgICAiQTEyOEdDTSIgICAxNiBieXRlcyAgICAxMiBieXRlcyAgICAg QUVBRF9BRVNfMTI4X0dDTQ0KICAgICJBMjU2R0NNIiAgIDMyIGJ5dGVzICAgIDEyIGJ5dGVzICAg ICBBRUFEX0FFU18yNTZfR0NNDQogICAgICJBMTI4Q0hTIiAgICAgNDggYnl0ZXMgICAgIDAgYnl0 ZXMgICAgICBBRUFEX0FFU18xMjhfQ0JDX0hNQUNfU0hBXzI1Ng0KICAgICAiQTI1NkNIUyIgICAg IDY0IGJ5dGVzICAgICAwIGJ5dGVzICAgICAgQUVBRF9BRVNfMjU2X0NCQ19ITUFDX1NIQV81MTIN Cg0KLS0NCkphbWVzIE1hbmdlcg0KDQpGcm9tOiBjZnJnLWJvdW5jZXNAaXJ0Zi5vcmcgW21haWx0 bzpjZnJnLWJvdW5jZXNAaXJ0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXZpZCBNY0dyZXcgKG1jZ3Jl dykNClNlbnQ6IFR1ZXNkYXksIDEzIE5vdmVtYmVyIDIwMTIgMTA6MjAgQU0NClRvOiBNaWNoYWVs IEpvbmVzOyBjZnJnQGlydGYub3JnOyBqb3NlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0Nmcmdd IFtqb3NlXSBBdXRoZW50aWNhdGVkIEVuY3J5cHRpb24gd2l0aCBBRVMtQ0JDIGFuZCBITUFDLVNI QSwgdmVyc2lvbiAwMQ0KDQrigKYNCkkgYW0gbm90IGRvZ21hdGljYWxseSBvcHBvc2VkIHRvIG90 aGVyIGludGVyZmFjZXMsIGJ1dCB0aGUgYmVzdCBzb2x1dGlvbiBoZXJlIGlzIGZvciBKT1NFIHRv IGFjdHVhbGx5IHVzZSB0aGUgNTExNiBpbnRlcmZhY2UsIGxpa2UgdGhpczoNCg0KWC5ZLiBBdXRo ZW50aWNhdGVkIEVuY3J5cHRpb24NCg0KICAgVGhpcyBzZWN0aW9uIGRlZmluZXMgdGhlIHNwZWNp ZmljcyBvZiBlbmNyeXB0aW5nIHRoZSBKV0UgUGxhaW50ZXh0DQogICBVc2luZyB0aGUgQXV0aGVu dGljYXRlZCBFbmNyeXB0aW9uIHdpdGggQXNzb2NpYXRlZCBEYXRhIChBRUFEKQ0KICAgYXMgZGVm aW5lZCBpbiBSRkMgNTExNi4gICBUaGUgYXV0aGVudGljYXRlZCBlbmNyeXB0aW9uIG9wZXJhdGlv bg0KICAgaGFzIGZvdXIgaW5wdXRzLCBhcyBmb2xsb3dzOg0KDQogICAgIFRoZSBzZWNyZXQga2V5 IGlzIHRoZSBDTUsuDQoNCiAgICAgVGhlIGFzc29jaWF0ZWQgZGF0YSBpcyB0aGUgYnl0ZXMgb2Yg dGhlIEFTQ0lJIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBjb25jYXRlbmF0aW9uIG9mDQogICAgIHRo ZSBFbmNvZGVkIEpXRSBIZWFkZXIsIGEgcGVyaW9kICgnLicpIGNoYXJhY3RlciwgdGhlIEVuY29k ZWQgSldFDQogICAgIEVuY3J5cHRlZCBLZXksIGEgc2Vjb25kIHBlcmlvZCBjaGFyYWN0ZXIgKCcu JyksIGFuZCB0aGUgRW5jb2RlZCBKV0UNCiAgICAgSW5pdGlhbGl6YXRpb24gVmVjdG9yLCBwZXIg U2VjdGlvbiA1IG9mIHRoZSBKV0Ugc3BlY2lmaWNhdGlvbi4NCg0KICAgICAgVGhlIHBsYWludGV4 dCAsIHdoaWNoIGNvbnRhaW5zIHRoZSBkYXRhIHRvIGJlIGVuY3J5cHRlZCBhbmQNCiAgICAgIGF1 dGhlbnRpY2F0ZWQuDQoNCiAgICAgIEEgbm9uY2UgTiwgd2l0aCBhIGxlbmd0aCBvZiBlaXRoZXIg MCBvciA5NiBiaXRzLiAgIElmIHRoZSBsZW5ndGgNCiAgICAgIGlzIHplcm8sIHRoZSBub25jZSBp cyBvbWl0dGVkLiAgT3RoZXJ3aXNlLCB0aGUgbm9uY2UNCiAgICAgIGlzIGFzIGRlc2NyaWJlZCBp biBTZWN0aW9uIDMgb2YgUkZDIDUxMTYuDQoNCiAgIFRoZXJlIGlzIGEgc2luZ2xlIG91dHB1dCwg dGhlIENpcGhlcnRleHQuDQoNCiAgIFRoZSAiZW5jIiBoZWFkZXIgIHBhcmFtZXRlciB2YWx1ZXMg YXJlIHNldCBhcyBmb2xsb3dzOg0KDQogICAgImVuYyIgICAgICAgICAgICAgICAgICBBbGdvcml0 aG0NCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgICJBMTI4R0NNIiAgICAgQUVBRF9BRVNfMTI4X0dD TQ0KICAgICJBMjU2R0NNIiAgICAgQUVBRF9BRVNfMjU2X0dDTQ0KICAgICAiQTEyOENIUyIgICAg ICBBRUFEX0FFU18xMjhfQ0JDX0hNQUNfU0hBXzI1Ng0KICAgICAiQTI1NkNIUyIgICAgICBBRUFE X0FFU18yNTZfQ0JDX0hNQUNfU0hBXzUxMg0KICAgICAgIkExMjhTSVYiICAgICAgQUVBRF9BRVNf U0lWX0NNQUNfMjU2DQogICAgICAiQTI1NlNJViIgICAgICBBRUFEX0FFU19TSVZfQ01BQ18zODQN Cg0KICAgICAgU2VlIDxodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2FlYWQtcGFyYW1l dGVycy9hZWFkLXBhcmFtZXRlcnMueG1sPjxodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRz L2FlYWQtcGFyYW1ldGVycy9hZWFkLXBhcmFtZXRlcnMueG1sJTNlPiBmb3IgdGhlDQogICAgIHJl ZmVyZW5jZXMgY29ycmVzcG9uZGluZyB0byB0aGVzZSBzeW1ib2xpYyBuYW1lcy4NCg== --_000_255B9BB34FB7D647A506DC292726F6E115004FD4BAWSMSG3153Vsrv_ 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 Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpw Lk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJ e21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5lY3hhcHBsZS1zdHlsZS1z cGFuDQoJe21zby1zdHlsZS1uYW1lOmVjeGFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5CYWxsb29u VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48 Ym9keSBsYW5nPUVOLUFVIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2Vj dGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+KzEwPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5UaGlzIGlzIG11Y2ggY2xlYXJlciwgYW5kIG11Y2ggbW9yZSBzdWl0YWJs ZSBmb3Igc2VwYXJhdGluZyB3aGF0IGdvZXMgaW4gYSBKT1NFIGxpYnJhcnkgdnMgd2hhdCBnb2Vz IGluIGEgZ2VuZXJhbC1wdXJwb3NlIGNyeXB0byBsaWJyYXJ5LiBFdmVuIGlmIGEgSk9TRSBsaWJy YXJ5IG5lZWRzIHRvIGltcGxlbWVudCBwYXJ0cyBvZiB0aGUgY3J5cHRvIHRvZGF5IGJlY2F1c2Ug bmF0aXZlIEFFQUQgc3VwcG9ydCBpcyBub3QgeWV0IHByZXNlbnQsIHRoaXMgc29sdXRpb24gbWFr ZXMgaXQgbXVjaCBtb3JlIGxpa2VseSBKT1NFIHdpbGwgYmUgY29tcGF0aWJsZSB3aXRoIG5hdGl2 ZSBBRUFEIGFzIGl0IGJlY29tZXMgYXZhaWxhYmxlLiBJIHRoaW5rIGl0IGlzIHVubGlrZWx5IHRo YXQgbmF0aXZlIEFFQUQgc3VwcG9ydCAob25jZSBhdmFpbGFibGUpIHdvdWxkIHN1cHBvcnQgYm90 aCBKT1NFIGFuZCBkcmFmdC1tY2dyZXcgdmFyaWFudHMgb2YgQUVBRC1mcm9tLUFFUy1DQkMtSE1B Qy4gVGhlIGRyYWZ0LW1jZ3JldyB2YXJpYW50IGhhcyBhIGJldHRlciBjaGFuY2Ugb2YgYmVpbmcg aW1wbGVtZW50ZWQgYmVjYXVzZSBpdCBkb2VzbuKAmXQgaW1wb3NlIGEgMzMlIHBlcmZvcm1hbmNl IHBlbmFsdHkgZm9yIHRoZSBNQUNpbmcgcGFydCwgYW5kIHRoZSBvdGhlciBkaWZmZXJlbmNlcyBh cmUgdHJpdmlhbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBmYWN0IHRoYXQgc29tZSBleGlzdGlu ZyBBRUFEIGFsZ29yaXRobXMgKFNJViBbUkZDIDUyOTddKSBkb27igJl0IHByb2R1Y2UgYSBzZXBh cmF0ZSBhdXRoZW50aWNhdGlvbiB0YWcgaXMgYSBjbGVhciBpbmRpY2F0aW9uIHRoYXQgYSBzaW5n bGUgY2lwaGVydGV4dCBvdXRwdXQgaXMgYSBiZXR0ZXIgZ2VuZXJhbCBtb2RlbCBmb3IgQUVBRCBp biBKT1NFIHRoYW4gc2VwYXJhdGUgY2lwaGVydGV4dCBhbmQgaW50ZWdyaXR5IHZhbHVlcyBhcyBp biBKV0UgdG9kYXkuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5FZGl0b3JpYWxzOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz7igJxKV0Ug SW5pdGlhbGl6YXRpb24gVmVjdG9y4oCdIHNob3VsZCBiZSByZW5hbWVkIOKAnEpXRSBOb25jZeKA nS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+VGhlIG5vbmNlIHBhcmFncmFwaCBuZWVkbuKAmXQgaGFyZHdpcmUgMiBsZW5ndGhz ICgwIGFuZCA5NiBiaXRzKSDigJMgbGVhdmUgaXQgdG8gZWFjaCBhbGcgdG8gc3BlY2lmeS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+VGhlIHRhYmxlIGNhbiBpbmNsdWRlIGtleSBhbmQgbm9uY2Ugc2l6ZXMuPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPsKgwqDC oCAmcXVvdDtlbmMmcXVvdDvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAga2V5IHNpemXC oCDCoMKgbm9uY2Ugc2l6ZcKgIEFsZ29yaXRobcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+wqDCoMKgwqAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz7C oMKgwqAgJnF1b3Q7QTEyOEdDTSZxdW90O8KgwqAgMTYgYnl0ZXPCoCDCoMKgMTIgYnl0ZXPCoMKg wqDCoCBBRUFEX0FFU18xMjhfR0NNwqDCoMKgwqAgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz7CoMKgwqDCoCZxdW90O0EyNTZH Q00mcXVvdDvCoMKgIDMyIGJ5dGVzwqDCoMKgIDEyIGJ5dGVzwqAgwqDCoMKgQUVBRF9BRVNfMjU2 X0dDTcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz7CoMKgwqDCoMKgJnF1b3Q7QTEyOENIUyZxdW90O8KgwqDC oMKgIDQ4IGJ5dGVzwqDCoMKgwqAgMCBieXRlc8KgwqDCoMKgIMKgQUVBRF9BRVNfMTI4X0NCQ19I TUFDX1NIQV8yNTbCoMKgwqAgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPsKgwqDCoMKgwqAmcXVvdDtBMjU2Q0hTJnF1b3Q7wqDC oMKgwqAgNjQgYnl0ZXPCoMKgwqDCoCAwIGJ5dGVzwqDCoMKgwqAgwqBBRUFEX0FFU18yNTZfQ0JD X0hNQUNfU0hBXzUxMsKgIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4tLTxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5KYW1lcyBN YW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9 J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9y bWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiInPiBjZnJnLWJvdW5jZXNAaXJ0Zi5vcmcgW21haWx0bzpjZnJnLWJvdW5jZXNAaXJ0Zi5vcmdd IDxiPk9uIEJlaGFsZiBPZiA8L2I+RGF2aWQgTWNHcmV3IChtY2dyZXcpPGJyPjxiPlNlbnQ6PC9i PiBUdWVzZGF5LCAxMyBOb3ZlbWJlciAyMDEyIDEwOjIwIEFNPGJyPjxiPlRvOjwvYj4gTWljaGFl bCBKb25lczsgY2ZyZ0BpcnRmLm9yZzsgam9zZUBpZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4g UmU6IFtDZnJnXSBbam9zZV0gQXV0aGVudGljYXRlZCBFbmNyeXB0aW9uIHdpdGggQUVTLUNCQyBh bmQgSE1BQy1TSEEsIHZlcnNpb24gMDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+4oCmPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymxh Y2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOmJsYWNrJz5JIGFtIG5vdCBkb2dtYXRpY2FsbHkgb3Bwb3NlZCB0byBvdGhl ciBpbnRlcmZhY2VzLCBidXQgdGhlIGJlc3Qgc29sdXRpb24gaGVyZSBpcyBmb3IgSk9TRSB0byBh Y3R1YWxseSB1c2UgdGhlIDUxMTYgaW50ZXJmYWNlLCBsaWtlIHRoaXM6PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2sn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5Y LlkuIEF1dGhlbnRpY2F0ZWQgRW5jcnlwdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIic+Jm5ic3A7ICZuYnNwO1RoaXMgc2VjdGlvbiBkZWZpbmVzIHRoZSBzcGVjaWZpY3Mg b2YgZW5jcnlwdGluZyB0aGUgSldFIFBsYWludGV4dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7ICZuYnNwO1VzaW5nIHRoZSBBdXRoZW50aWNhdGVkIEVu Y3J5cHRpb24gd2l0aCBBc3NvY2lhdGVkIERhdGEgKEFFQUQpPC9zcGFuPjxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7YXMgZGVmaW5lZCBpbiBSRkMgNTEx Ni4gJm5ic3A7PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj4mbmJzcDtUaGUgYXV0aGVudGlj YXRlZCBlbmNyeXB0aW9uIG9wZXJhdGlvbiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUt c3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5i c3A7ICZuYnNwO2hhcyBmb3VyIGlucHV0cywgYXMgZm9sbG93czo8L3NwYW4+PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgc2Vj cmV0IGtleSBpcyB0aGUgQ01LLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7ICZuYnNwO1RoZSBhc3NvY2lhdGVk IGRhdGEgaXMgdGhlIGJ5dGVzIG9mIHRoZSBBU0NJSSByZXByZXNlbnRhdGlvbiBvZiB0aGUgY29u Y2F0ZW5hdGlvbiBvZjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiInPiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIic+Jm5ic3A7ICZuYnNwOyAmbmJzcDt0aGUgRW5jb2RlZCBKV0UgSGVhZGVyLCBhIHBlcmlv ZCAoJy4nKSBjaGFyYWN0ZXIsIHRoZSBFbmNvZGVkIEpXRTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7ICZuYnNwOyAmbmJzcDtFbmNyeXB0ZWQgS2V5LCBh IHNlY29uZCBwZXJpb2QgY2hhcmFjdGVyICgnLicpLCBhbmQgdGhlIEVuY29kZWQgSldFPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7ICZuYnNw O0luaXRpYWxpemF0aW9uIFZlY3RvciwgcGVyIFNlY3Rpb24gNSBvZiB0aGUgSldFIHNwZWNpZmlj YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPiZuYnNwOyAm bmJzcDsgJm5ic3A7IFRoZSBwbGFpbnRleHQgLCB3aGljaCBjb250YWlucyB0aGUgZGF0YSB0byBi ZSBlbmNyeXB0ZWQgYW5kPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Jz4mbmJzcDsgJm5ic3A7ICZuYnNwOyBhdXRoZW50aWNhdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPjxzcGFuIHN0 eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7ICZu YnNwOyBBIG5vbmNlIE4sIHdpdGggYSBsZW5ndGggb2YgZWl0aGVyIDAgb3IgOTYgYml0cy4gJm5i c3A7IElmIHRoZSBsZW5ndGg8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7ICZuYnNwOyBpcyB6ZXJvLCB0aGUgbm9uY2UgaXMgb21p dHRlZC4gJm5ic3A7T3RoZXJ3aXNlLCB0aGUgbm9uY2U8L3NwYW4+PG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiInPiZuYnNwOyAmbmJzcDsgJm5ic3A7IGlzIGFzIGRlc2NyaWJlZCBp biBTZWN0aW9uIDMgb2YgUkZDIDUxMTYuICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7VGhlcmUgaXMgYSBzaW5nbGUgb3V0cHV0LCB0aGUgQ2lw aGVydGV4dC4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7ICZuYnNwO1RoZSAmcXVvdDtlbmMm cXVvdDsgaGVhZGVyJm5ic3A7IHBhcmFtZXRlciB2YWx1ZXMgYXJlIHNldCBhcyBmb2xsb3dzOjwv c3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g Y2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIic+Jm5ic3A7ICZuYnNwOyAmcXVvdDtlbmMmcXVvdDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtBbGdvcml0 aG0gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiInPiZuYnNwOyAmbmJzcDsmbmJzcDsmcXVvdDtBMTI4R0NNJnF1b3Q7ICZu YnNwOyAmbmJzcDsmbmJzcDtBRUFEX0FFU18xMjhfR0NNICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGNsYXNzPWFwcGxl LXN0eWxlLXNwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiInPiZuYnNwOyAmbmJzcDsgJnF1b3Q7QTI1NkdDTSZxdW90OyAmbmJzcDsgJm5ic3A7IEFFQURf QUVTXzI1Nl9HQ00gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj48c3Bh biBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7ICZuYnNw OyAmbmJzcDsmcXVvdDtBMTI4Q0hTJnF1b3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QUVBRF9BRVNf MTI4X0NCQ19ITUFDX1NIQV8yNTYgJm5ic3A7ICZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286 cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBjbGFz cz1hcHBsZS1zdHlsZS1zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiJz4mbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O0EyNTZDSFMmcXVvdDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtBRUFEX0FFU18yNTZfQ0JDX0hNQUNfU0hBXzUxMiAmbmJzcDs8L3NwYW4+ PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZxdW90O0ExMjhTSVYmcXVvdDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtBRUFEX0FFU19T SVZfQ01BQ18yNTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O0EyNTZTSVYmcXVvdDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtBRUFEX0FFU19TSVZfQ01BQ18zODQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiInPiZuYnNwOyAmbmJzcDsgJm5ic3A7IFNlZSAmbHQ7PGEgaHJlZj0iaHR0cDovL3d3 dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9hZWFkLXBhcmFtZXRlcnMvYWVhZC1wYXJhbWV0ZXJzLnht bCUzZSI+aHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9hZWFkLXBhcmFtZXRlcnMvYWVh ZC1wYXJhbWV0ZXJzLnhtbCZndDs8L2E+Jm5ic3A7Zm9yIHRoZSZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7ICZuYnNwOyAmbmJzcDtyZWZlcmVu Y2VzIGNvcnJlc3BvbmRpbmcgdG88c3BhbiBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPiZuYnNwO3Ro ZXNlIHN5bWJvbGljIG5hbWVzLiAmbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_255B9BB34FB7D647A506DC292726F6E115004FD4BAWSMSG3153Vsrv_-- From dick.hardt@gmail.com Tue Nov 13 08:08: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 6697D21F8717 for ; Tue, 13 Nov 2012 08:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.863 X-Spam-Level: X-Spam-Status: No, score=-3.863 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pIRbvXYntE4 for ; Tue, 13 Nov 2012 08:08:10 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 018B421F8744 for ; Tue, 13 Nov 2012 08:08:08 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so3359772dan.31 for ; Tue, 13 Nov 2012 08:08:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=OTZjRrjmZMZ4d0lwDYJgDhyjiSxzYpuOlIYhxrqmwWA=; b=B+TwU0PHGSMmrLKzVb3s5VZZr4dO5TcEyxEbvc3pg+z+Q31P/AejHoZyUItX3IQy18 P709rY07qTcQbXp5YvzyliZBdlRnwsixxGm8hLtGUJGutUJqRm2V4/JofWEgc6TiTIs3 brhHtdkaOGb/GaUiuS4FLQNM2Hv0xRVThwh5gbbHN6h6BG++eQS/4rxlcyiQAfM8pVxg je42QJplbnpdFCXSsTlrROrNhNKNNZjwt/ue2Qd4ee4ZeQ/I5YjLsCP+mQj6Ffs2CCC9 Om6FQhTlDKCM2n4OeXpOBThXGUdytUoAYpUXB7jKmzWsIWS3xeVQ7ytjiDP2T7tW/CzL SPGg== Received: by 10.69.1.8 with SMTP id bc8mr69797699pbd.9.1352822886655; Tue, 13 Nov 2012 08:08:06 -0800 (PST) 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 nt5sm3950878pbb.59.2012.11.13.08.08.04 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Nov 2012 08:08:05 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_86CFA2AF-9948-4D61-9618-BCF33E8E6595" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: Date: Tue, 13 Nov 2012 08:08:02 -0800 Message-Id: <1AB706FC-13B1-4462-ACB6-1980E70744C4@gmail.com> References: <20121107093441.26081.45621.idtracker@ietfa.amsl.com> <19F1B8FA-6655-4933-A58C-70B12BE025C3@gmail.com> <3F30DDAB-F245-459F-90B9-91DCFED11A3A@bbn.com> To: Bob Wyman X-Mailer: Apple Mail (2.1499) Cc: "Richard L. Barnes" , "jose@ietf.org" , Dick Hardt Subject: Re: [jose] proposal: put encryption header parameters into a separate object 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, 13 Nov 2012 16:08:14 -0000 --Apple-Mail=_86CFA2AF-9948-4D61-9618-BCF33E8E6595 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Bob / Richard Including the signature value and the ciphertext in the JSON would = needlessly enlarge the resulting token as it was base64url encoded. Having the header use a hierarchical structure seems to make it easier = to support multiple keys, which is needed if you want to sign and = encrypt a message -- which seems to be a common use case! -- Dick On Nov 9, 2012, at 8:29 AM, Bob Wyman wrote: > The "val" element in Barnes' proposal would need some parameters (typ, = cty, etc.) as well as the content in val: >=20 > { > "enc": { /* encryption parameters */ }, > "sig": { /* signature parameters + value */ }, > "val": {/* content parameters + plaintext */} > } >=20 >=20 >=20 > On Fri, Nov 9, 2012 at 1:58 AM, Richard L. Barnes = wrote: > Hey Dick, >=20 > To make sure I understand your use case correctly: You want to convey = an encrypted object, as well as a signature over the plaintext (without = having to encrypt the signature value). Does that sound accurate? >=20 > It seems like there are three types of information you want in the = object: (1) cipher text, (2) encryption parameters, and (3) signature = value/parameters. So why not encapsulate it like that? To propose a = JSON syntax: >=20 > { > "enc": { /* encryption parameters */ }, > "sig": { /* signature parameters + value */ }, > "val": "/* ciphertext */" > } >=20 > Obviously: > -- JWE/JWS could be the special cases where only one of "enc" or "sig" = is present > -- This cleanly supports multiple signatures via multiple "sig" values = (e.g., in an array) > -- This cleanly supports multiple recipients via multiple "enc" values = (e.g., in an array) > -- You could leave one of "enc" or "sig" parameters as flat lists (as = in JWS/JWE), but it seems cleaner to have them parallel > -- For a compact serialization, you would want certain fields to be = not double-base64'ed. We can figure that out later :) >=20 > This seems like kind of an appealing line of reasoning to me. I would = be glad to do some work on figuring out the details. >=20 > --Richard >=20 >=20 >=20 >=20 > On Nov 7, 2012, at 3:23 PM, Dick Hardt wrote: >=20 > > To enable encrypting and then signing of the same token, we need to = specify the encrypting and signing algorithms separately. > > > > Since we are using JSON, how about if we create an encryption object = to contain all the parameters defined in JWE so that there is no overlap = in the JWS namespace. > > > > "enc": > > { "alg" > > , "enc" > > , "zip" > > } > > > > _______________________________________________ > > 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 --Apple-Mail=_86CFA2AF-9948-4D61-9618-BCF33E8E6595 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 bob@wyman.us> wrote:

The "val" element in Barnes' proposal would = need some parameters (typ, cty, etc.) as well as the content in = val:

{
  "enc": { /* = encryption parameters */ },
  = "sig": { /* signature parameters + value */ },
  "val": = {/* content parameters + plaintext = */}
}



On Fri, Nov = 9, 2012 at 1:58 AM, Richard L. Barnes <rbarnes@bbn.com> wrote:
Hey Dick,

To make sure I understand your use case correctly: You want to convey an = encrypted object, as well as a signature over the plaintext (without = having to encrypt the signature value).  Does that sound = accurate?

It seems like there are three types of information you want in the = object: (1) cipher text, (2) encryption parameters, and (3) signature = value/parameters.  So why not encapsulate it like that?  To = propose a JSON syntax:

{
  "enc": { /* encryption parameters */ },
  "sig": { /* signature parameters + value */ },
  "val": "/* ciphertext */"
}

Obviously:
-- JWE/JWS could be the special cases where only one of "enc" or "sig" = is present
-- This cleanly supports multiple signatures via multiple "sig" values = (e.g., in an array)
-- This cleanly supports multiple recipients via multiple "enc" values = (e.g., in an array)
-- You could leave one of "enc" or "sig" parameters as flat lists (as in = JWS/JWE), but it seems cleaner to have them parallel
-- For a compact serialization, you would want certain fields to be not = double-base64'ed.  We can figure that out later :)

This seems like kind of an appealing line of reasoning to me.  I = would be glad to do some work on figuring out the details.

--Richard




On Nov 7, 2012, at 3:23 PM, Dick Hardt <dick.hardt@gmail.com> = wrote:

> To enable encrypting and then signing of the same token, we need to = specify the encrypting and signing algorithms separately.
>
> Since we are using JSON, how about if we create an encryption = object to contain all the parameters defined in JWE so that there is no = overlap in the JWS namespace.
>
> "enc":
>       {  "alg"
>       ,  "enc"
>       ,  "zip"
>       }
>
> _______________________________________________
> 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


= --Apple-Mail=_86CFA2AF-9948-4D61-9618-BCF33E8E6595-- From dick.hardt@gmail.com Tue Nov 13 08:10: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 496FD21F876A for ; Tue, 13 Nov 2012 08:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.845 X-Spam-Level: X-Spam-Status: No, score=-3.845 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icMi95A4sNtX for ; Tue, 13 Nov 2012 08:10:02 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id AA8E221F8766 for ; Tue, 13 Nov 2012 08:10:01 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so1837345pbc.31 for ; Tue, 13 Nov 2012 08:09:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ef5ZI12U/ZNmlJOHbBxmnnbraPPVqOD5a7hSi86DdC4=; b=1BZdY20Wra9VhPgja+8i8yCwqaxrzG5LvBtzwTF9lDAEsqdY1GpIeW2l5PPVoN31Ke 6lcibjkHsHol8dq73Eew+ZsT/7s8LiHUjzQ+2IIZM98+Zsx2xfSnFDay1lbD27WgByPK KGn1PzBO552kc8ZSZqz3WVyEkeNxbkNXjfcBenrxzwx/WRh/wtZ9kzdJdxmWN7Ge6slg xcI5b5oRG6JpLYHUdl7oJQkvxTUqQBmmlxo5lbcgeQ6QS9FLPibTSAzBBHASY0E/zwrc 25TrRxU0ENMIMeqVEkiwtr/3hc83AQ4tbXHpxaYGlpNDtqZSXw0LTZdW+FpGi0ZR2PbG OlPA== Received: by 10.68.143.106 with SMTP id sd10mr47229993pbb.62.1352822999219; Tue, 13 Nov 2012 08:09:59 -0800 (PST) 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 c1sm6305003pav.23.2012.11.13.08.09.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Nov 2012 08:09:53 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: Date: Tue, 13 Nov 2012 08:08:28 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Joe Hildebrand (jhildebr) X-Mailer: Apple Mail (2.1499) Cc: "jose@ietf.org" Subject: Re: [jose] Whiteboard discussion 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, 13 Nov 2012 16:10:03 -0000 Was there an output from this discussion?=20 On Nov 7, 2012, at 8:10 AM, Joe Hildebrand (jhildebr) = wrote: > If you're interested in participating in the high-level architecture > discussion we just talked about in the room, and you're in Atlanta = this > week, please send me a message off-list. >=20 > This activity is not intended to be secret in any way, we are just = going > to try to put together an email to the list that combines all of the > different ideas that we heard in the room as a coherent world view, so = the > group can form an opinion about precisely how many documents we're = writing. >=20 > --=20 > Joe Hildebrand >=20 >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From mcgrew@cisco.com Tue Nov 13 08:31:54 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 70B1421F8774 for ; Tue, 13 Nov 2012 08:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oU-4+GjtK1BL for ; Tue, 13 Nov 2012 08:31:50 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 98C4621F8718 for ; Tue, 13 Nov 2012 08:31:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24252; q=dns/txt; s=iport; t=1352824307; x=1354033907; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=HOAweE7u4s4DT3cNeIP4WIBrnrr2Mu0ih4Y27BymVsQ=; b=SAlY6fATgy5x/j+5hkwRef4P2kReUdlaGw2bxlKz27hbyBE+ifdpZqDf Mu56PFy9X4iZAM0U2XA4pEwyYsf1fUc5F4RGzJRfKMIb3S/GmwyL5jM2Z 23nkftno7kQWIsuPEWYoxGHwe3cWcbPB3hB0GJ7YI/h2Xrmka4kWxUPlH k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIt0olCtJV2d/2dsb2JhbABEgknBJIEIgh4BAQEEEgEaXgEIEQMBAQELFgc5FAkIAgQBEggBEgeHVgMPC5oXj2WGTx2JRIwqhXNhA6RUgWuCb4IZ X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="141958792" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 13 Nov 2012 16:31:44 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qADGVhuM030265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Nov 2012 16:31:44 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Tue, 13 Nov 2012 10:31:43 -0600 From: "David McGrew (mcgrew)" To: "Manger, James H" , "cfrg@irtf.org" , "jose@ietf.org" Thread-Topic: [Cfrg] [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 Thread-Index: AQHNwQJ1KPZ1PBWsRUecOePTOEDiwZfnCigA///dCgCAAFxuQIAAw+YA Date: Tue, 13 Nov 2012 16:31:42 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F50AFD6@xmb-rcd-x04.cisco.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E115004FD4BA@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.228] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19360.002 x-tm-as-result: No--32.424200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_747787E65E3FBD4E93F0EB2F14DB556B0F50AFD6xmbrcdx04ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 13 Nov 2012 14:23:36 -0800 Subject: Re: [jose] [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 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, 13 Nov 2012 16:31:54 -0000 --_000_747787E65E3FBD4E93F0EB2F14DB556B0F50AFD6xmbrcdx04ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi James, From: , James H > Date: Tuesday, November 13, 2012 1:33 AM To: Cisco Employee >, "cfrg@irtf.= org" >, "jose@iet= f.org" > Subject: RE: [Cfrg] [jose] Authenticated Encryption with AES-CBC and HMAC-S= HA, version 01 +10 This is much clearer, and much more suitable for separating what goes in a = JOSE library vs what goes in a general-purpose crypto library. Even if a JO= SE library needs to implement parts of the crypto today because native AEAD= support is not yet present, this solution makes it much more likely JOSE w= ill be compatible with native AEAD as it becomes available. I think it is u= nlikely that native AEAD support (once available) would support both JOSE a= nd draft-mcgrew variants of AEAD-from-AES-CBC-HMAC. The draft-mcgrew varian= t has a better chance of being implemented because it doesn=92t impose a 33= % performance penalty for the MACing part, and the other differences are tr= ivial. The fact that some existing AEAD algorithms (SIV [RFC 5297]) don=92t produc= e a separate authentication tag is a clear indication that a single ciphert= ext output is a better general model for AEAD in JOSE than separate ciphert= ext and integrity values as in JWE today. Editorials: =93JWE Initialization Vector=94 should be renamed =93JWE Nonce=94. The nonce paragraph needn=92t hardwire 2 lengths (0 and 96 bits) =96 leave = it to each alg to specify. The table can include key and nonce sizes. "enc" key size nonce size Algorithm ----------------------------------------------------------------------- "A128GCM" 16 bytes 12 bytes AEAD_AES_128_GCM "A256GCM" 32 bytes 12 bytes AEAD_AES_256_GCM "A128CHS" 48 bytes 0 bytes AEAD_AES_128_CBC_HMAC_SHA_256 "A256CHS" 64 bytes 0 bytes AEAD_AES_256_CBC_HMAC_SHA_512 Thanks for the good suggestions (agreed on all of them) and support. Regards, David -- James Manger From: cfrg-bounces@irtf.org [mailto:cfrg-boun= ces@irtf.org] On Behalf Of David McGrew (mcgrew) Sent: Tuesday, 13 November 2012 10:20 AM To: Michael Jones; cfrg@irtf.org; jose@ietf.org Subject: Re: [Cfrg] [jose] Authenticated Encryption with AES-CBC and HMAC-S= HA, version 01 =85 I am not dogmatically opposed to other interfaces, but the best solution he= re is for JOSE to actually use the 5116 interface, like this: X.Y. Authenticated Encryption This section defines the specifics of encrypting the JWE Plaintext Using the Authenticated Encryption with Associated Data (AEAD) as defined in RFC 5116. The authenticated encryption operation has four inputs, as follows: The secret key is the CMK. The associated data is the bytes of the ASCII representation of the co= ncatenation of the Encoded JWE Header, a period ('.') character, the Encoded JWE Encrypted Key, a second period character ('.'), and the Encoded JWE Initialization Vector, per Section 5 of the JWE specification. The plaintext , which contains the data to be encrypted and authenticated. A nonce N, with a length of either 0 or 96 bits. If the length is zero, the nonce is omitted. Otherwise, the nonce is as described in Section 3 of RFC 5116. There is a single output, the Ciphertext. The "enc" header parameter values are set as follows: "enc" Algorithm ----------------------------------------------------------------------- "A128GCM" AEAD_AES_128_GCM "A256GCM" AEAD_AES_256_GCM "A128CHS" AEAD_AES_128_CBC_HMAC_SHA_256 "A256CHS" AEAD_AES_256_CBC_HMAC_SHA_512 "A128SIV" AEAD_AES_SIV_CMAC_256 "A256SIV" AEAD_AES_SIV_CMAC_384 See for the references corresponding to these symbolic names. --_000_747787E65E3FBD4E93F0EB2F14DB556B0F50AFD6xmbrcdx04ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <94533B1A0135D84F9C9FB7FEBA90D1A7@cisco.com> Content-Transfer-Encoding: quoted-printable
Hi James,

From: <Manger>, James H <<= a href=3D"mailto:James.H.Manger@team.telstra.com">James.H.Manger@team.telst= ra.com>
Date: Tuesday, November 13, 2012 1:= 33 AM
To: Cisco Employee <mcgrew@cisco.com>, "cfrg@irtf.org" <= cfrg@irtf.org>, "jose@ietf.org= " <jose@ietf.org>
Subject: RE: [Cfrg] [jose] Authenti= cated Encryption with AES-CBC and HMAC-SHA, version 01

+10

 

This is much clearer, and much mor= e suitable for separating what goes in a JOSE library vs what goes in a gen= eral-purpose crypto library. Even if a JOSE library needs to implement parts of the crypto today because native= AEAD support is not yet present, this solution makes it much more likely J= OSE will be compatible with native AEAD as it becomes available. I think it= is unlikely that native AEAD support (once available) would support both JOSE and draft-mcgrew variants of AEAD= -from-AES-CBC-HMAC. The draft-mcgrew variant has a better chance of being i= mplemented because it doesn=92t impose a 33% performance penalty for the MA= Cing part, and the other differences are trivial.

 

The fact that some existing AEAD a= lgorithms (SIV [RFC 5297]) don=92t produce a separate authentication tag is= a clear indication that a single ciphertext output is a better general model for AEAD in JOSE than separate ciphertext= and integrity values as in JWE today.

 

Editorials:

=93JWE Initialization Vector=94 sh= ould be renamed =93JWE Nonce=94.

The nonce paragraph needn=92t hard= wire 2 lengths (0 and 96 bits) =96 leave it to each alg to specify.

The table can include key and nonc= e sizes.

    "enc"=             &nb= sp;   key size    nonce size  Algorithm =             &nb= sp;          

    ----------= -------------------------------------------------------------

    "A128GCM&q= uot;   16 bytes    12 bytes    = ; AEAD_AES_128_GCM          &n= bsp;            = ;           

    "A256= GCM"   32 bytes    12 bytes    = ; AEAD_AES_256_GCM        &nbs= p;            &= nbsp;           &nbs= p;

     &quo= t;A128CHS"     48 bytes     0 = bytes      AEAD_AES_128_CBC_HMAC_SHA_256 &nbs= p; 

     &quo= t;A256CHS"     64 bytes     0 = bytes      AEAD_AES_256_CBC_HMAC_SHA_512 

Thanks for the good suggestions (agreed on all of them) and support.

Regards,

David

 

--

James Manger

 

From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of David McGrew (mcgrew)
Sent: Tuesday, 13 November 2012 10:20 AM
To: Michael Jones; cfrg@irtf.org; jose@ietf.org
Subject: Re: [Cfrg] [jose] Authenticated Encryption with AES-CBC and= HMAC-SHA, version 01

 

=85

I am not dogmatically opposed to other inte= rfaces, but the best solution here is for JOSE to actually use the 5116 int= erface, like this:

 

X= .Y. Authenticated Encryption

 

&= nbsp;  This section defines the specifics of encrypting the JWE Plaint= ext

&= nbsp;  Using the Authenticated Encryption with Associated Data (AEAD)<= /span>

&= nbsp;  as defined in RFC 5116.  =  The authenticated encryption operation =

   has four inputs, as follows:

<= o:p> 

&= nbsp;    The secret key is the CMK.

<= o:p> 

     The associated data is = the bytes of the ASCII representation of the concatenation of=

&= nbsp;    the Encoded JWE Header, a period ('.') character, the En= coded JWE

&= nbsp;    Encrypted Key, a second period character ('.'), and the = Encoded JWE

&= nbsp;    Initialization Vector, per Section 5 of the JWE specific= ation.

<= o:p> 

&= nbsp;     The plaintext , which contains the data to be encrypted= and

&= nbsp;     authenticated.

<= o:p> 

      A nonce N, with a leng= th of either 0 or 96 bits.   If the length

&= nbsp;     is zero, the nonce is omitted.  Otherwise, the non= ce

&= nbsp;     is as described in Section 3 of RFC 5116.   <= o:p>

<= o:p> 

&= nbsp;  There is a single output, the Ciphertext.  

<= o:p> 

   The "enc" header&nbs= p; parameter values are set as follows:

 

    "enc"    =              Algorithm     &n= bsp;                   

&= nbsp;   --------------------------------------------------------------= ---------

    "A128GCM" &nbs= p;   AEAD_AES_128_GCM             &= nbsp;                    =

    "A256GCM"   &n= bsp; AEAD_AES_256_GCM               &nbs= p;                   

     "A128CHS" &nb= sp;    AEAD_AES_128_CBC_HMAC_SHA_256    <= o:p>

     "A256CHS" &nb= sp;    AEAD_AES_256_CBC_HMAC_SHA_512  

&= nbsp;     "A128SIV"      AEAD_AES_SIV_CM= AC_256

&= nbsp;     "A256SIV"      AEAD_AES_SIV_CM= AC_384

 

&= nbsp;    references corresponding to these symbolic names.  

 --_000_747787E65E3FBD4E93F0EB2F14DB556B0F50AFD6xmbrcdx04ciscoc_-- From Michael.Jones@microsoft.com Tue Nov 13 14:46: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 0F3DE21F878B for ; Tue, 13 Nov 2012 14:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id he6Z58bClcaB for ; Tue, 13 Nov 2012 14:46:16 -0800 (PST) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.30]) by ietfa.amsl.com (Postfix) with ESMTP id 65B1321F866B for ; Tue, 13 Nov 2012 14:46:16 -0800 (PST) Received: from BL2FFO11FD008.protection.gbl (10.173.161.201) by BL2FFO11HUB024.protection.gbl (10.173.161.48) with Microsoft SMTP Server (TLS) id 15.0.556.9; Mon, 12 Nov 2012 18:56:07 +0000 Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD008.mail.protection.outlook.com (10.173.161.4) with Microsoft SMTP Server (TLS) id 15.0.556.9 via Frontend Transport; Mon, 12 Nov 2012 18:56:07 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.11]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0318.003; Mon, 12 Nov 2012 18:55:18 +0000 From: Mike Jones To: "David McGrew (mcgrew)" , "cfrg@irtf.org" , "jose@ietf.org" Thread-Topic: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 Thread-Index: AQHNwQJ1KPZ1PBWsRUecOePTOEDiwZfmjABA Date: Mon, 12 Nov 2012 18:55:17 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943668B026C@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <747787E65E3FBD4E93F0EB2F14DB556B0F50A96C@xmb-rcd-x04.cisco.com> In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F50A96C@xmb-rcd-x04.cisco.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_4E1F6AAD24975D4BA5B1680429673943668B026CTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(164054002)(377454001)(46102001)(16406001)(5343635001)(5343655001)(31966008)(512954001)(54316001)(54356001)(53806001)(51856001)(47976001)(15202345001)(33656001)(4396001)(47446002)(49866001)(50986001)(76482001)(44976002)(47736001)(74502001)(74662001)(55846005); DIR:OUT; SFP:; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0663390E1B Subject: Re: [jose] [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 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, 13 Nov 2012 22:46:18 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943668B026CTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As background, if there was a version of this spec that did not assume that= the parameters would be concatenated together in a specific way, but left = them as independent inputs and outputs, as AES GCM and AES CTR do, it would= be a better match for JOSE's use case. -- Mike From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Dav= id McGrew (mcgrew) Sent: Monday, November 12, 2012 10:21 AM To: cfrg@irtf.org; jose@ietf.org Subject: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version= 01 Hi, There is a new version of "Authenticated Encryption with AES-CBC and HMAC-S= HA", and I would appreciate your review. It is online at The diff between the current and the previous version is av= ailable at This draft has been proposed for use in the JOSE WG , where its adopti= on would allow the working group to omit "raw" unauthenticated encryption, = e.g. AES-CBC, and only include authenticated encryption. Thus I am asking= for your help in making John Foley generated test cases that correspond to the current version of t= he draft, but I didn't include these in the draft because I did not yet get= confirmation from a second independent implementation. With hope, there = will not be any need for any normative changes, and I will include these af= ter I get confirmation. Thanks, David --_000_4E1F6AAD24975D4BA5B1680429673943668B026CTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As background, if there w= as a version of this spec that did not assume that the parameters would be = concatenated together in a specific way, but left them as independent inputs and outputs, as AES GCM and AES CTR do, it would be a b= etter match for JOSE’s use case.

 <= /p>

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

 <= /p>

From: cfrg-bou= nces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of David McGrew (mcgrew)
Sent: Monday, November 12, 2012 10:21 AM
To: cfrg@irtf.org; jose@ietf.org
Subject: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, = version 01

 

Hi,

 

There is a new version of &= quot;Authe= nticated Encryption with AES-CBC and HMAC-SHA", and I would appreciate your review.   It is online at <https://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-= cbc-hmac-sha2/?include_text=3D1>   The diff between the current and the previous version is available a= t <http://www.ietf.org/rfcdiff?url2=3Ddraft-mcgrew-aead-ae= s-cbc-hmac-sha2-01>

 

This draft has been propose= d for use in the JOSE WG <http://datatracker.ietf.org/wg/jose/> , where its adoptio= n would allow the working group to omit "raw" unauthenticated encr= yption, e.g. AES-CBC, and only include authenticated encryption.   Thu= s I am asking for your help in making 

 

John Foley generated test c= ases that correspond to the current version of the draft, but I didn't incl= ude these in the draft because I did not yet get confirmation from a second independent implementation.   With hope, there will not= be any need for any normative changes, and I will include these after I ge= t confirmation.  

 

Thanks,

 

David

--_000_4E1F6AAD24975D4BA5B1680429673943668B026CTK5EX14MBXC283r_-- From michael_b_jones@hotmail.com Tue Nov 13 15:33: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 41DB321F8691; Tue, 13 Nov 2012 15:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntI5ZIMOsIXx; Tue, 13 Nov 2012 15:33:26 -0800 (PST) Received: from bay0-omc1-s25.bay0.hotmail.com (bay0-omc1-s25.bay0.hotmail.com [65.54.190.36]) by ietfa.amsl.com (Postfix) with ESMTP id D57B521F868F; Tue, 13 Nov 2012 15:33:26 -0800 (PST) Received: from BAY171-W47 ([65.54.190.60]) by bay0-omc1-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Nov 2012 15:33:26 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_2df8537d-c1b1-4a26-b683-96413d67d4ed_" X-Originating-IP: [174.7.255.77] From: Michael Jones To: , , Date: Tue, 13 Nov 2012 15:33:26 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 13 Nov 2012 23:33:26.0611 (UTC) FILETIME=[479C2230:01CDC1F7] Cc: Mike Jones , cfrg@irtf.org Subject: [jose] Vacationing this week & e-mail address 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, 13 Nov 2012 23:33:27 -0000 --_2df8537d-c1b1-4a26-b683-96413d67d4ed_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all=2C I wanted to let you know that I'm vacationing this week=2C and so= mostly won't be participating in discussions. I'll respond next week. Als= o=2C at present I=92m using the e-mail address michael_b_jones@hotmail.com to send e-mail to IETF mailing lists because currently I=92m unable to send= e-mail to any IETF lists using my normal e-mail address Michael.Jones@microsoft.com.=20 When corresponding with me individually=2C it would be better to use the Microsoft address=2C as the message is likely to be seen more quickly. Have= a good week=2C everyone! -- Mike=20 = --_2df8537d-c1b1-4a26-b683-96413d67d4ed_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi all=2C
 =3B
I wanted to let you know that I'm vacationing this= week=2C and so mostly won't be participating in discussions. =3B I'll = respond next week.
&nbs= p=3B

Also=2C at present I=92m using the e-ma= il address michael_b_jones@hotmail.com to send e-mail to IETF mailing lists because currently I=92m unable to send= e-mail to any IETF lists using my normal e-mail address Michael.Jones@microsoft.com. =3B When corresponding with me individually=2C it would be better to use the Microsoft address=2C as the message is likely to be seen more quickly.

 =3B
Have a good week=2C everyone!
 =3B
-- Mike
 =3B


= --_2df8537d-c1b1-4a26-b683-96413d67d4ed_-- From Michael.Jones@microsoft.com Tue Nov 13 16:14:38 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 0D55F21F84B9 for ; Tue, 13 Nov 2012 16:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNDkVx13Ibnu for ; Tue, 13 Nov 2012 16:14:37 -0800 (PST) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.30]) by ietfa.amsl.com (Postfix) with ESMTP id B692E21F8477 for ; Tue, 13 Nov 2012 16:14:35 -0800 (PST) Received: from BL2FFO11FD004.protection.gbl (10.173.161.202) by BL2FFO11HUB034.protection.gbl (10.173.161.114) with Microsoft SMTP Server (TLS) id 15.0.556.9; Mon, 12 Nov 2012 01:29:19 +0000 Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD004.mail.protection.outlook.com (10.173.160.104) with Microsoft SMTP Server (TLS) id 15.0.556.9 via Frontend Transport; Mon, 12 Nov 2012 01:29:19 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.11]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0318.003; Mon, 12 Nov 2012 01:28:44 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key Thread-Index: AQHNvqT3EpFpmMO25kO23VChuPByMJflORmAgAAdecA= Date: Mon, 12 Nov 2012 01:28:44 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943668AF1FF@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <255B9BB34FB7D647A506DC292726F6E11500331CA9@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11500331CA9@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.36] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(51704002)(13464001)(33656001)(46102001)(74502001)(53806001)(49866001)(4396001)(47976001)(16406001)(23676001)(47736001)(31966008)(50466001)(44976002)(5343655001)(47776002)(54316001)(47446002)(50986001)(74662001)(51856001)(54356001)(76482001)(148743001)(55846005)(217873001); DIR:OUT; SFP:; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0663390E1B Subject: Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer 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: Wed, 14 Nov 2012 00:14:38 -0000 VXNpbmcgZHJhZnQtbWNncmV3LWFlYWQtYWVzLWNiYy1obWFjLXNoYTIgaXMgbm90IHRoZSBzYW1l IHRoaW5nIGFzICgxKS4gIEZvciBpbnN0YW5jZSwgYXMgd2FzIGRpc2N1c3NlZCBhZnRlciBEYXZp ZCdzIHByZXNlbnRhdGlvbiBhdCBJRVRGIDg0LCBkcmFmdC1tY2dyZXctYWVhZC1hZXMtY2JjLWht YWMtc2hhMiBkb2VzIG5vdCBmb2xsb3cgdGhlIHBhdHRlcm4gb2YgQUVBRCBhbGdvcml0aG1zIHN1 Y2ggYXMgQUVTIEdDTSwgd2hpY2ggaGF2ZSB0d28gaW5wdXRzIChwbGFpbnRleHQsICJhZGRpdGlv bmFsIGF1dGhlbnRpY2F0ZWQgZGF0YSIpLCBhbmQgdHdvIG91dHB1dHMgKGNpcGhlcnRleHQsICJh dXRoZW50aWNhdGlvbiB0YWciKS4gIEluc3RlYWQsIGl0IGFkZHMgYSBzdGVwIGNvbWJpbmluZyB0 aGUgY2lwaGVydGV4dCBhbmQgImF1dGhlbnRpY2F0aW9uIHRhZyIgb3V0cHV0cy4NCg0KSWYgeW91 IHJlYWQgdGhlIGRyYWZ0LCBpbXBsZW1lbnRhdGlvbiBvZiBkcmFmdC1tY2dyZXctYWVhZC1hZXMt Y2JjLWhtYWMtc2hhMiBoYXMgYSBsb3QgbW9yZSBzdGVwcyB0aGFuIHdoYXQgd2UgaGF2ZSBmb3Ig QTEyOENCQytIUzI1NiBhbmQgQTI1NkNCQytIUzUxMi4gIEl0IHJlcXVpcmVzIGdlbmVyYXRpbmcg YW5kIGFkZGluZyBzcGVjaWZpYyBwYWRkaW5nIGJ5dGVzLiAgSXQgcHJlZml4ZXMgdGhlIGNpcGhl cnRleHQgd2l0aCB0aGUgSVYuICBJdCBpbmNsdWRlcyB0aGUgbGVuZ3RoIG9mIHRoZSAiYWRkaXRp b25hbCBhdXRoZW50aWNhdGVkIGRhdGEiIGluIHRoZSBNQUMgY2FsY3VsYXRpb24uICBJdCBjb21i aW5lcyB0aGUgdHdvIG91dHB1dHMgaW50byBvbmUuICBGb3IgZGVjcnlwdGlvbiwgbGlrZXdpc2Us IHRoZSB0d28gb3V0cHV0cyBtdXN0IGJlIHNwbGl0IGFwYXJ0LCB0aGUgSVYgbXVzdCBiZSBzcGxp dCBhcGFydCwgZXRjLg0KDQpBbGwgb2YgdGhlc2UgYXJlIHN0ZXBzIHRoYXQgaW1wbGVtZW50YXRp b25zIGNvdWxkIGdldCB3cm9uZywgcmVzdWx0aW5nIGluIGludGVyb3BlcmFiaWxpdHkgcHJvYmxl bXMuICBCeSBrZWVwaW5nIGFsbCB0aGUgcGFyYW1ldGVycyBzZXBhcmF0ZSwgb3VyIGN1cnJlbnQg QTEyOENCQytIUzI1NiBhbmQgQTI1NkNCQytIUzUxMiBhbGdvcml0aG1zIGVsaW1pbmF0ZSB0aG9z ZSBzdGVwcy4NCg0KSSdtIHNvcnJ5IGZvciB0aGUgYXBwYXJlbnQgY29uZnVzaW9uIGJldHdlZW4g KDEpIGFuZCBkcmFmdC1tY2dyZXctYWVhZC1hZXMtY2JjLWhtYWMtc2hhMi4gIFdoaWxlIHRoZXkg Ym90aCBleHBsaWNpdGx5IHJlcHJlc2VudCB0aGUgQ01LIGFuZCBDRUssIGFuZCB1c2UgdGhlIHNh bWUgdW5kZXJseWluZyBjcnlwdG8gb3BlcmF0aW9ucywgdGhlIGRldGFpbHMgZGlmZmVyIGluIHdh eXMgdGhhdCBhcmUgbGlrZWx5IHRvIG1hdHRlciB0byBpbXBsZW1lbnRlcnMuICBJZiB0aGVyZSB3 YXMgYSB2ZXJzaW9uIG9mIGRyYWZ0LW1jZ3Jldy1hZWFkLWFlcy1jYmMtaG1hYy1zaGEyIHRoYXQg a2VwdCBhbGwgdGhlIGlucHV0cyBhbmQgb3V0cHV0cyBzZXBhcmF0ZSwgSSBhZ3JlZSB0aGF0IGl0 IHdvdWxkIGJlIGEgcmVhc29uYWJsZSBjYW5kaWRhdGUgZm9yIEpPU0UgdG8gY29uc2lkZXIuICBC dXQgdW5saWtlIEFFUyBHQ00sIHRoYXQncyBub3Qgd2hhdCBpdCBkb2VzLg0KDQoJCQkJLS0gTWlr ZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogam9zZS1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFuZ2VyLCBK YW1lcyBIDQpTZW50OiBTdW5kYXksIE5vdmVtYmVyIDExLCAyMDEyIDI6MjQgUE0NClRvOiBNaWNo YWVsIEpvbmVzOyBqb3NlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2pvc2VdIENob2ljZSBmb3Ig V0c6IFVzZSBhIEtERiB3aXRoIEFFUyBDQkMgb3IgdXNlIGEgbG9uZ2VyIGtleQ0KDQo+IFNvIEni gJlkIGxpa2UgdG8gZXhwbGljaXRseSBhc2sgdGhlIHdvcmtpbmcgZ3JvdXAuICBEbyB5b3Ugd2Fu dCB1cyB0bzoNCj4NCj4gKDEpIFVzZSB0aGUgY29uY2F0ZW5hdGlvbiBvZiByYW5kb20gQ0VLIGFu ZCBDSUsgdmFsdWVzIGFzIHRoZSBDTUsgZm9yIEFFUyBDQkMsIHJlc3VsdGluZyBpbiBhIGxvbmdl ciBDTUs/DQo+ICgyKSBDb250aW51ZSB0byB1c2UgYSBLREYgdG8gZ2VuZXJhdGUgdGhlIENFSyBh bmQgQ0lLIGZyb20gYSBzaG9ydGVyIENNSz8NCg0KDQoxLiBVc2UgZHJhZnQtbWNncmV3LWFlYWQt YWVzLWNiYy1obWFjLXNoYTINCg0KLS0NCkphbWVzIE1hbmdlcg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmpvc2UgbWFpbGluZyBsaXN0DQpqb3NlQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UNCg== From ignisvulpis@gmail.com Wed Nov 14 08:40: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 4093A21F8554 for ; Wed, 14 Nov 2012 08:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.848 X-Spam-Level: X-Spam-Status: No, score=-3.848 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GxZm06NKOnl for ; Wed, 14 Nov 2012 08:40:30 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 747D321F852C for ; Wed, 14 Nov 2012 08:40:30 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id u46so240103wey.31 for ; Wed, 14 Nov 2012 08:40:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vdWzKE5XpKAG2deTwtdnhMEYRHu7wADxqIJk/SAA57U=; b=PLHZ9EHtgSK2BFSEiwElqu3di1Z1v4avVboSiBfsO1mSKQZLZ+qKi1sQHYqZnoAh5t 3tmD5wUXzutgTfw1Z+FDTkBvY8HMZcwNTNcYkk6CABxdt/tTCFSjEcWotReO0R1ZFp58 KLEPFmYAXu0PYpzBvdLLkLL+bayVoFEtQ7z6kyB8VDcbDwV1ZwIb9L8EP6Eyt0HrPrgO TOQj8TFRR0OpCAB254fMIolYNOZpO6YUPIfaFCQzWWws5AyZsWf+dFXTzcwWFehfDa9x abUT7B0+6Tu2VFCuwkrnJ1FIuh3qKyp1zjpCkkWnbGF5CVizq8FrlQrsXU+xWDsMrzv6 SHog== MIME-Version: 1.0 Received: by 10.216.53.197 with SMTP id g47mr1356237wec.110.1352911229618; Wed, 14 Nov 2012 08:40:29 -0800 (PST) Received: by 10.216.54.130 with HTTP; Wed, 14 Nov 2012 08:40:29 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Nov 2012 17:40:29 +0100 Message-ID: From: Axel Nennker To: Dick Hardt Content-Type: multipart/alternative; boundary=0016e6dee767410c3104ce7731f7 Cc: "jose@ietf.org" , Joe Hildebrand Subject: Re: [jose] Whiteboard discussion 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, 14 Nov 2012 16:40:31 -0000 --0016e6dee767410c3104ce7731f7 Content-Type: text/plain; charset=ISO-8859-1 The suspense is killing me too. I am not a fan of off-list discussions. Axel 2012/11/13 Dick Hardt > Was there an output from this discussion? > > On Nov 7, 2012, at 8:10 AM, Joe Hildebrand (jhildebr) > wrote: > > > If you're interested in participating in the high-level architecture > > discussion we just talked about in the room, and you're in Atlanta this > > week, please send me a message off-list. > > > > This activity is not intended to be secret in any way, we are just going > > to try to put together an email to the list that combines all of the > > different ideas that we heard in the room as a coherent world view, so > the > > group can form an opinion about precisely how many documents we're > writing. > > > > -- > > Joe Hildebrand > > > > > > > > _______________________________________________ > > 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 > --0016e6dee767410c3104ce7731f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The suspense is killing me too. I am not a fan of off-list discussions.=A0 =
Axel


2= 012/11/13 Dick Hardt <dick.hardt@gmail.com>
Was there an output from this discussion?

On Nov 7, 2012, at 8:10 AM, Joe Hildebrand (jhildebr) <jhildebr@cisco.com> wrote:

> If you're interested in participating in the high-level architectu= re
> discussion we just talked about in the room, and you're in Atlanta= this
> week, please send me a message off-list.
>
> This activity is not intended to be secret in any way, we are just goi= ng
> to try to put together an email to the list that combines all of the > different ideas that we heard in the room as a coherent world view, so= the
> group can form an opinion about precisely how many documents we're= writing.
>
> --
> Joe Hildebrand
>
>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose

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

--0016e6dee767410c3104ce7731f7-- From jhildebr@cisco.com Wed Nov 14 09:06: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 C1A1721F8689 for ; Wed, 14 Nov 2012 09:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.948 X-Spam-Level: X-Spam-Status: No, score=-10.948 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIvy2A-3l+u9 for ; Wed, 14 Nov 2012 09:06:00 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 024BD21F85C4 for ; Wed, 14 Nov 2012 09:05:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4333; q=dns/txt; s=iport; t=1352912760; x=1354122360; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UBkxJG1siH5XTPbOIKwAMPoJ8UaxUxj2zyJ+dioUTxU=; b=dvLGXSQSftB/pG49M49v8WgwP0N2S8W8I6Rs6hs8zpRN1tZGjgcjB61Z eMV6pbsbI4wxfp8pgkHyHHeBexC7jPnmeypQCB8C21T7eFJZlK352jXQH /CNCTxCI9VxNqD4ExmGAdz02BjGS9SDD1vFujd/y3MIbV6KwXzd3UCQl7 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFLOo1CtJXHA/2dsb2JhbABEwz6BCIIeAQEBAwEBAQEPAVsLBQsCAQgECgQtByEGCxQDDgIEDgUih1YDCQYLmyaWOg2JUASLRGmFS2EDlCeBVYsygyaBa4JvgVsJFwM X-IronPort-AV: E=McAfee;i="5400,1158,6895"; a="142362282" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 14 Nov 2012 17:05:59 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qAEH5xx4006248 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Nov 2012 17:05:59 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Wed, 14 Nov 2012 11:05:59 -0600 From: "Joe Hildebrand (jhildebr)" To: Axel Nennker Thread-Topic: [jose] Whiteboard discussion Thread-Index: AQHNvQJnTeRLN31T7keUlOoq8Mm1o5foXMwAgAGbR4D//6KKrA== Date: Wed, 14 Nov 2012 17:05:58 +0000 Message-ID: <8CD9CB1E-0055-49A8-937A-6B7D4B4F4AE7@cisco.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19364.000 x-tm-as-result: No--32.207100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_8CD9CB1E005549A8937A6B7D4B4F4AE7ciscocom_" MIME-Version: 1.0 Cc: "jose@ietf.org" , Dick Hardt Subject: Re: [jose] Whiteboard discussion 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, 14 Nov 2012 17:06:00 -0000 --_000_8CD9CB1E005549A8937A6B7D4B4F4AE7ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry, haven't had a chance to write it up. Hope to tonight. There is not an extensive off-list discussion going on, just a personal ban= dwidth issue. Mobile/terse. DYAC. On Nov 14, 2012, at 9:40 AM, "Axel Nennker" > wrote: The suspense is killing me too. I am not a fan of off-list discussions. Axel 2012/11/13 Dick Hardt > Was there an output from this discussion? On Nov 7, 2012, at 8:10 AM, Joe Hildebrand (jhildebr) > wrote: > If you're interested in participating in the high-level architecture > discussion we just talked about in the room, and you're in Atlanta this > week, please send me a message off-list. > > This activity is not intended to be secret in any way, we are just going > to try to put together an email to the list that combines all of the > different ideas that we heard in the room as a coherent world view, so th= e > group can form an opinion about precisely how many documents we're writin= g. > > -- > Joe Hildebrand > > > > _______________________________________________ > 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 --_000_8CD9CB1E005549A8937A6B7D4B4F4AE7ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Sorry, haven't had a chance to write it up. Hope to tonight. 

There is not an extensive off-list discussion going on, just a persona= l bandwidth issue. 

Mobile/terse. DYAC. 

On Nov 14, 2012, at 9:40 AM, "Axel Nennker" <ignisvulpis@gmail.com> wrote:

The suspense is killing me too. I am not a fan of off-list discussions= . 
Axel


2012/11/13 Dick Hardt <dick.hardt@gmail.com<= /a>>
Was there an output from this discussion?

On Nov 7, 2012, at 8:10 AM, Joe Hildebrand (jhildebr) <jhildebr@cisco.com> wrote:

> If you're interested in participating in the high-level architecture > discussion we just talked about in the room, and you're in Atlanta thi= s
> week, please send me a message off-list.
>
> This activity is not intended to be secret in any way, we are just goi= ng
> to try to put together an email to the list that combines all of the > different ideas that we heard in the room as a coherent world view, so= the
> group can form an opinion about precisely how many documents we're wri= ting.
>
> --
> Joe Hildebrand
>
>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose

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

--_000_8CD9CB1E005549A8937A6B7D4B4F4AE7ciscocom_-- From ve7jtb@ve7jtb.com Wed Nov 14 09:17: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 8032521F8792 for ; Wed, 14 Nov 2012 09:17:50 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GB-834DsEn0 for ; Wed, 14 Nov 2012 09:17:49 -0800 (PST) Received: from mail-ye0-f172.google.com (mail-ye0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id ECC5B21F8791 for ; Wed, 14 Nov 2012 09:17:48 -0800 (PST) Received: by mail-ye0-f172.google.com with SMTP id l13so143333yen.31 for ; Wed, 14 Nov 2012 09:17:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=xkDI+WI21tf/CNjMsPYY4n5L62FmqCyr/jyi+0m5Exg=; b=NpeZ2RZ3fgc66/McnMT9FjjkLy7d5NHQxdql4oy70TjQ47Ptf7yJr70dt24kbCdPAg Zy+A9vfpNiuaKBST1qKnSUD8V2+33IdqovKSujqPKGqyHBaj51a+nXxpaxcqXcftHW9S ZXTNqhOnzZgBAmPOM513frpBgvHuX2z3+/ofVfe/FRL/gzzwfCGEO8Pl4EzjHvVUfX3K vjBQW9/hadYsy1p0OMBiEBe6qASWZwSqlTka3eMiQYICUTxb6N3r0+zaS+EBkWDQaN0q CAjvMg9Nm9gBJ89pMNpaSBYmxF9nBB8OPXyy726QrIDVP+0wThKJKUdFyc3rub35Lwxj 67pQ== Received: by 10.236.142.139 with SMTP id i11mr26659193yhj.24.1352913468388; Wed, 14 Nov 2012 09:17:48 -0800 (PST) Received: from [192.168.1.211] (190-20-23-204.baf.movistar.cl. [190.20.23.204]) by mx.google.com with ESMTPS id u21sm13361526yhl.6.2012.11.14.09.17.45 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Nov 2012 09:17:47 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_41B51CDE-83B6-4F4D-A085-4E5D451DC172" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Wed, 14 Nov 2012 14:17:39 -0300 Message-Id: References: To: Axel Nennker X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkn9yjnZpuJ72gG2upGTGt/3tbTyyKD5ENd62SdPG/41Jd/kn0p2EGOAbdz93OjRiDhqlsO Cc: Joe Hildebrand , "jose@ietf.org" , Dick Hardt Subject: Re: [jose] Whiteboard discussion 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, 14 Nov 2012 17:17:50 -0000 --Apple-Mail=_41B51CDE-83B6-4F4D-A085-4E5D451DC172 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Yes, Joe was going to post the summery to the list. Mike and I fell sick with the flue over the weekend so I hope the same = fate hasn't befallen Joe. Richard is also going to write up a alternate proposal and circulate = that as well. Basically we discussed: 1 Extending JWK with formats for symmetric and private keys. 2 Adding a Password Based encryption algorithm to JWA. =20 3 Using JWE as the container for protected key info (JWE wrapped JWK). There was discussion on how to best arrange the new material in the = specs and not have the addition slow progress. It looked like this would meet the needs of the Web Crypto folks and = Matt's need for key transport. Richard, has what I characterize as an optimization, in mind. I don't = intend to explain it as I don't understand it enough to do it justice. He is going to write it up. I have some photos of whiteboards, but those are probably not = decipherable by non attendees. No big secret. Joe and Jim will get the results and some recommended = divvying up of the work out shortly I expect. John B. On 2012-11-14, at 1:40 PM, Axel Nennker wrote: > The suspense is killing me too. I am not a fan of off-list = discussions. =20 > Axel >=20 >=20 > 2012/11/13 Dick Hardt > Was there an output from this discussion? >=20 > On Nov 7, 2012, at 8:10 AM, Joe Hildebrand (jhildebr) = wrote: >=20 > > If you're interested in participating in the high-level architecture > > discussion we just talked about in the room, and you're in Atlanta = this > > week, please send me a message off-list. > > > > This activity is not intended to be secret in any way, we are just = going > > to try to put together an email to the list that combines all of the > > different ideas that we heard in the room as a coherent world view, = so the > > group can form an opinion about precisely how many documents we're = writing. > > > > -- > > Joe Hildebrand > > > > > > > > _______________________________________________ > > 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 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_41B51CDE-83B6-4F4D-A085-4E5D451DC172 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Yes, = Joe was going to post the summery to the list.

Mike = and I fell sick with the flue over the weekend so I hope the same fate = hasn't befallen Joe.

Richard is also going to = write up a alternate proposal and circulate that as = well.

Basically we = discussed:

1 Extending JWK with formats for = symmetric and private keys.

2 Adding a Password = Based encryption algorithm to JWA.  

3 = Using JWE as the container for protected key info (JWE wrapped = JWK).

There was discussion on how to best = arrange the new material in the specs and not have the addition slow = progress.

It looked like this would meet the = needs of the Web Crypto folks and  Matt's need for key = transport.

Richard, has what I characterize as = an optimization, in mind.   I don't intend to explain it as I don't = understand it enough to do it justice.
He is going to write it = up.

I have some photos of whiteboards, but = those are probably not decipherable by non = attendees.

No big secret.  Joe and Jim = will get the results and some recommended divvying up of the work out = shortly I expect.


John = B.


On 2012-11-14, at 1:40 PM, = Axel Nennker <ignisvulpis@gmail.com> = wrote:

The suspense is killing me too. I am not a fan of off-list = discussions. 
Axel


2012/11/13 Dick Hardt <dick.hardt@gmail.com>
Was there an output = from this discussion?

On Nov 7, 2012, at 8:10 AM, Joe Hildebrand (jhildebr) <jhildebr@cisco.com> wrote:

> If you're interested in participating in the high-level = architecture
> discussion we just talked about in the room, and you're in Atlanta = this
> week, please send me a message off-list.
>
> This activity is not intended to be secret in any way, we are just = going
> to try to put together an email to the list that combines all of = the
> different ideas that we heard in the room as a coherent world view, = so the
> group can form an opinion about precisely how many documents we're = writing.
>
> --
> Joe Hildebrand
>
>
>
> _______________________________________________
> 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

_______________________________________________
jose mailing = list
jose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jose

= --Apple-Mail=_41B51CDE-83B6-4F4D-A085-4E5D451DC172-- From mamille2@cisco.com Thu Nov 15 10:25: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 806BC21F845E for ; Thu, 15 Nov 2012 10:25:09 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtQ+yYl3S+3s for ; Thu, 15 Nov 2012 10:25:08 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C894121F8428 for ; Thu, 15 Nov 2012 10:25:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6376; q=dns/txt; s=iport; t=1353003906; x=1354213506; h=from:to:subject:date:message-id:mime-version; bh=T2uU5ftQoUFJ5U/fTHsbmLwYNhu7KTqAFMB0UPQ3hnQ=; b=d61ILSJhAeVv2YNSggaiwRWul0GwC3KE3m3k/OwkbdMKJD60R7ymb5UZ ZZQIWDHOdgJrtuNhEClrQaY1tmpEaHxAHX5MdrI8e2vpA9tZJ06b5P2Il VKntzjhjPlmXcrQ4iT/kvArb/hqOkSpcEP6keUO5o+gBkv7PvifHZKMo1 I=; X-Files: smime.p7s : 2214 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsJABgzpVCtJV2a/2dsb2JhbABEwj6BAQeCIAEEEgF4ASoOGDAnBBMIBhSHawubToEroAiPOIJEYQOOe4EhlDiBa4JvgVskGg X-IronPort-AV: E=McAfee;i="5400,1158,6897"; a="142854784" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 15 Nov 2012 18:25:04 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAFIP4ON030156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 15 Nov 2012 18:25:04 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.240]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 12:25:04 -0600 From: "Matt Miller (mamille2)" To: "jose@ietf.org" Thread-Topic: Whiteboard Discussion MInutes Thread-Index: AQHNw16Hmd7Xf4G7rk2GDVnD14/Byg== Date: Thu, 15 Nov 2012 18:25:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.149.163] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19368.001 x-tm-as-result: No--28.965100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail=_6712D70F-CB07-41C6-AB50-84B09CBB3CA5"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [jose] Whiteboard Discussion MInutes 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, 15 Nov 2012 18:25:09 -0000 --Apple-Mail=_6712D70F-CB07-41C6-AB50-84B09CBB3CA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [ I urge the original participants to correct any omissions or glaring = mistakes ] Participants =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * Richard Barnes * John Bradley * Joe Hildebrand * Michael Jones * Matt Miller * Jim Schaad "What's a JOSE" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We started with a discussion of what the areas of concerns for JOSE are = (established or otherwise): * public key * private key * symmetric key * sign * encrypt * MAC * wrapped keys * passphrase-based wrapping * algorithms * extensibility * common attributes * serialization/syntax Regarding Keys =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D There was also discussion on whether wrapped keys were their own = top-level object, or an application of JWE. With this discussion, there = was rough consensus that keys (including symmetric keys) should have the = ability to include additional information (e.g. "expires" ). For top-level, this is approximately as presented in the WG: { "typ":"transport", "alg":RSA-OEAP", "jwk":{ ... }, "val":base64url(pk-encrypt(jku, symmetric key value)) } For JWE application, the key would have a JWK representation: { "typ":"AES", "key":base64url(symmetric key value) } Which is then serialized to UTF-8 and used as the plaintext into JWE. Given this, there was very rough consensus that we pursue the "wrapped = keys as JWE application" path, although it was suggested Richard provide = a more concrete example of the top-level model. Regarding Encrypted Private Keys =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D There was discussion and consensus on adding support for PBKDF2 to = derive a symmetric key from a password. The details are to be worked = out as part of the wrapped key document. Regarding Organization =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D There was discussion on the organization of items, and whether the = current documentation is sufficient. While there was no consensus on = what the best layout is, there was also no consensus on changing = anything. Work Items =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D There was rough consensus on the following outputs, assuming no = objections from the rest of the WG: * A document extending "RSA" and "EC" with the private key factors, plus = a new JWK for symmetric keys. Tentatively to be done by Mike Jones, = starting with draft-jones-jose-json-private-key * A document that applies JWE to protecting keys (as JWK objects), and = defines an algorithm that uses PBKDF2 for passphrase-based protection. = Tentatively to be done by Matt Miller. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. PS: If you are interested in the cryptic notes, the images are = temporarily available at < http://outer-planes.net/ietf/ietf85-josewg/ = >.= --Apple-Mail=_6712D70F-CB07-41C6-AB50-84B09CBB3CA5 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 ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTExNTE4MjUw M1owIwYJKoZIhvcNAQkEMRYEFFKMoSbo9N9tjZh4nodtMtJ5dgHpMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQCxPyESYFVntB/xKw+nja2wAvILwD0tTWYCZ9eswF74g7GqKt2m8PsOUHud l3hWaSEPGnhWOxnTRK7Bc9fCSyN2xJjAnykdxDVpPj5p/vI5+ugrqkTBqvRZgk14MFFj4P3AiBHk IOkp3vgnPMmfwY/eMfHJxEfieg4s1VYHG9jaHZv7+UrPUC4JnMfM3Sfj79p5tTV32rK/kYTUM7oh J+NUEum3OjxMt4hEgCx1zbu2ao9Jq8+DGumEWrbL2AkxgcIUPOHmj1C40m3tADG+gOOKMt/YMy7V 14EwdGUr/gHD2ftG804y72qiSzYCALLBqKWwrblNmxCB6gsW8VZCraAuAAAAAAAA --Apple-Mail=_6712D70F-CB07-41C6-AB50-84B09CBB3CA5-- From Michael.Jones@microsoft.com Thu Nov 15 12:46: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 0AE2621F8C42 for ; Thu, 15 Nov 2012 12:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRe3AWkYvIzI for ; Thu, 15 Nov 2012 12:46:22 -0800 (PST) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.30]) by ietfa.amsl.com (Postfix) with ESMTP id 27E2D21F8BC3 for ; Thu, 15 Nov 2012 12:46:21 -0800 (PST) Received: from BY2FFO11FD003.protection.gbl (10.1.15.204) by BY2FFO11HUB025.protection.gbl (10.1.14.111) with Microsoft SMTP Server (TLS) id 15.0.556.9; Thu, 15 Nov 2012 20:46:19 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD003.mail.protection.outlook.com (10.1.14.125) with Microsoft SMTP Server (TLS) id 15.0.556.9 via Frontend Transport; Thu, 15 Nov 2012 20:46:19 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.146]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Thu, 15 Nov 2012 20:46:06 +0000 From: Mike Jones To: "Matt Miller (mamille2)" , "jose@ietf.org" Thread-Topic: Whiteboard Discussion Minutes Thread-Index: Ac3DcjoE4OfAWA4iTayYn2cBOFtQEQ== Date: Thu, 15 Nov 2012 20:46:05 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943668D0123@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.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(13464001)(54316002)(76482001)(4396001)(46406002)(49866001)(5343645001)(47736001)(74662001)(53806001)(16406001)(47976001)(31966008)(33656001)(51856001)(54356001)(50986001)(5343655001)(56776001)(74502001)(46102001)(47776002)(56816001)(44976002)(50466001)(15202345001)(5343635001)(23726001)(551544001)(47446002)(55846005); DIR:OUT; SFP:; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0666E15D35 Subject: Re: [jose] Whiteboard Discussion Minutes 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, 15 Nov 2012 20:46:23 -0000 That's close to my recollection as well. I'll summarize the primary conclu= sions in a different way to hopefully make them even clearer to people who = weren't there: (1) We will define JWK extensions to represent private and symmetric keys (2) We will recommend protection of private and symmetric keys by encrypti= ng their JWK representations in a JWE (3) We will define an additional JWA "alg" value for generation of a symme= tric key from a password (thus enabling password-based key protection schem= es) The two deliverables we agreed to were: (A) The JWK extension document defining (1), which Mike will produce (B) A key protection application document specifying (2) and (3), which Ma= tt will produce Note that (B) will use the JWA registry to register (3), rather than adding= (3) to the JWA doc itself. -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mat= t Miller (mamille2) Sent: Thursday, November 15, 2012 10:25 AM To: jose@ietf.org Subject: [jose] Whiteboard Discussion MInutes [ I urge the original participants to correct any omissions or glaring mist= akes ] Participants =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * Richard Barnes * John Bradley * Joe Hildebrand * Michael Jones * Matt Miller * Jim Schaad "What's a JOSE" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We started with a discussion of what the areas of concerns for JOSE are (es= tablished or otherwise): * public key * private key * symmetric key * sign * encrypt * MAC * wrapped keys * passphrase-based wrapping * algorithms * extensibility * common attributes * serialization/syntax Regarding Keys =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D There was also discussion on whether wrapped keys were their own top-level = object, or an application of JWE. With this discussion, there was rough co= nsensus that keys (including symmetric keys) should have the ability to inc= lude additional information (e.g. "expires" ). For top-level, this is approximately as presented in the WG: { "typ":"transport", "alg":RSA-OEAP", "jwk":{ ... }, "val":base64url(pk-encrypt(jku, symmetric key value)) } For JWE application, the key would have a JWK representation: { "typ":"AES", "key":base64url(symmetric key value) } Which is then serialized to UTF-8 and used as the plaintext into JWE. Given this, there was very rough consensus that we pursue the "wrapped keys= as JWE application" path, although it was suggested Richard provide a more= concrete example of the top-level model. Regarding Encrypted Private Keys =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D There was discussion and consensus on adding support for PBKDF2 to derive a= symmetric key from a password. The details are to be worked out as part o= f the wrapped key document. Regarding Organization =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D There was discussion on the organization of items, and whether the current = documentation is sufficient. While there was no consensus on what the best= layout is, there was also no consensus on changing anything. Work Items =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D There was rough consensus on the following outputs, assuming no objections = from the rest of the WG: * A document extending "RSA" and "EC" with the private key factors, plus a = new JWK for symmetric keys. Tentatively to be done by Mike Jones, starting= with draft-jones-jose-json-private-key * A document that applies JWE to protecting keys (as JWK objects), and defi= nes an algorithm that uses PBKDF2 for passphrase-based protection. Tentati= vely to be done by Matt Miller. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. PS: If you are interested in the cryptic notes, the images are temporarily = available at < http://outer-planes.net/ietf/ietf85-josewg/ >. From ve7jtb@ve7jtb.com Thu Nov 15 15:09: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 F256621F84E4 for ; Thu, 15 Nov 2012 15:09:54 -0800 (PST) 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.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WAoY+Fx3-tB for ; Thu, 15 Nov 2012 15:09:54 -0800 (PST) Received: from mail-ye0-f172.google.com (mail-ye0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id DD82121F84E3 for ; Thu, 15 Nov 2012 15:09:53 -0800 (PST) Received: by mail-ye0-f172.google.com with SMTP id l13so451315yen.31 for ; Thu, 15 Nov 2012 15:09:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=TqGyS23fD4MNhgLeZC1oHKpa+yVOK6vmfJfBaNNHWo8=; b=i+MlHjX+Ex1dU6oPG/RhaK3odfao2ho1tU0z8xuDeQnA2I1g+AKSHGocIFc0z8SkwN aBeAJasJE60h04cxkCym6Mbk2zM+K054kztzeaCyQNPMiqxvCZMZDdIkv0BrsyCFsoOK U9eO1FogesK0Fugq+hF0siuQZelfOtccCj7PG1lxOSc/yCDPQw58LAYEkGC7jPNBuxio FvnHbJxvEod8ln67jdEsOBXVnFRCUjUpMZoPkVeFGYwEIjn8bdUJS5YO/8U48zh2P+8F zXlXWyQ97sAE6oUyc2phS6xgTgTK44tXvWY/+EpZeg5pURGAtWqXU0UEH8G2+VEqysR+ 7E7Q== Received: by 10.236.186.105 with SMTP id v69mr2524922yhm.128.1353020993443; Thu, 15 Nov 2012 15:09:53 -0800 (PST) Received: from [192.168.1.211] (190-20-31-131.baf.movistar.cl. [190.20.31.131]) by mx.google.com with ESMTPS id p17sm15521476anh.12.2012.11.15.15.09.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Nov 2012 15:09:52 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943668D0123@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Thu, 15 Nov 2012 20:09:43 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <84D2F337-8A87-4FD3-BE3D-2942DD9EB39C@ve7jtb.com> References: <4E1F6AAD24975D4BA5B1680429673943668D0123@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlJ0cpfocMXYW4AictzNA2QvxtZ1XCUYa6iRg6CliUnZycZnXK6txmZue3QkbJg6CpLYQTp Cc: "jose@ietf.org" , "Matt Miller \(mamille2\)" Subject: Re: [jose] Whiteboard Discussion Minutes 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, 15 Nov 2012 23:09:55 -0000 Yes that is consistent with the conclusion I attempted to summarize to = the list. John B. On 2012-11-15, at 5:46 PM, Mike Jones = wrote: > That's close to my recollection as well. I'll summarize the primary = conclusions in a different way to hopefully make them even clearer to = people who weren't there: >=20 > (1) We will define JWK extensions to represent private and symmetric = keys > (2) We will recommend protection of private and symmetric keys by = encrypting their JWK representations in a JWE > (3) We will define an additional JWA "alg" value for generation of a = symmetric key from a password (thus enabling password-based key = protection schemes) >=20 > The two deliverables we agreed to were: > (A) The JWK extension document defining (1), which Mike will produce > (B) A key protection application document specifying (2) and (3), = which Matt will produce >=20 > Note that (B) will use the JWA registry to register (3), rather than = adding (3) to the JWA doc itself. >=20 > -- Mike >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Matt Miller (mamille2) > Sent: Thursday, November 15, 2012 10:25 AM > To: jose@ietf.org > Subject: [jose] Whiteboard Discussion MInutes >=20 > [ I urge the original participants to correct any omissions or glaring = mistakes ] >=20 > Participants > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > * Richard Barnes > * John Bradley > * Joe Hildebrand > * Michael Jones > * Matt Miller > * Jim Schaad >=20 > "What's a JOSE" > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > We started with a discussion of what the areas of concerns for JOSE = are (established or otherwise): >=20 > * public key > * private key > * symmetric key > * sign > * encrypt > * MAC > * wrapped keys > * passphrase-based wrapping > * algorithms > * extensibility > * common attributes > * serialization/syntax >=20 > Regarding Keys > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > There was also discussion on whether wrapped keys were their own = top-level object, or an application of JWE. With this discussion, there = was rough consensus that keys (including symmetric keys) should have the = ability to include additional information (e.g. "expires" ). >=20 > For top-level, this is approximately as presented in the WG: > { > "typ":"transport", > "alg":RSA-OEAP", > "jwk":{ ... }, > "val":base64url(pk-encrypt(jku, symmetric key value)) } >=20 > For JWE application, the key would have a JWK representation: > { > "typ":"AES", > "key":base64url(symmetric key value) > } >=20 > Which is then serialized to UTF-8 and used as the plaintext into JWE. >=20 > Given this, there was very rough consensus that we pursue the "wrapped = keys as JWE application" path, although it was suggested Richard provide = a more concrete example of the top-level model. >=20 > Regarding Encrypted Private Keys > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >=20 > There was discussion and consensus on adding support for PBKDF2 to = derive a symmetric key from a password. The details are to be worked = out as part of the wrapped key document. >=20 > Regarding Organization > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > There was discussion on the organization of items, and whether the = current documentation is sufficient. While there was no consensus on = what the best layout is, there was also no consensus on changing = anything. >=20 > Work Items > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > There was rough consensus on the following outputs, assuming no = objections from the rest of the WG: >=20 > * A document extending "RSA" and "EC" with the private key factors, = plus a new JWK for symmetric keys. Tentatively to be done by Mike = Jones, starting with draft-jones-jose-json-private-key > * A document that applies JWE to protecting keys (as JWK objects), and = defines an algorithm that uses PBKDF2 for passphrase-based protection. = Tentatively to be done by Matt Miller. >=20 >=20 > - m&m >=20 > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. >=20 > PS: If you are interested in the cryptic notes, the images are = temporarily available at < http://outer-planes.net/ietf/ietf85-josewg/ = >. > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From housley@vigilsec.com Sun Nov 18 04:45: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 9468A21F84B9 for ; Sun, 18 Nov 2012 04:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbDl66AV35LC for ; Sun, 18 Nov 2012 04:45:40 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 71A8E21F847B for ; Sun, 18 Nov 2012 04:45:39 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 85BFA9A4006; Sun, 18 Nov 2012 07:45:44 -0500 (EST) 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 TjBKGZGNrKKm; Sun, 18 Nov 2012 07:45:33 -0500 (EST) Received: from [5.5.33.15] (vpn.snozzages.com [204.194.22.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id AAA919A4002; Sun, 18 Nov 2012 07:45:37 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-91--874108683 From: Russ Housley In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943668B026C@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Sun, 18 Nov 2012 07:45:29 -0500 Message-Id: References: <747787E65E3FBD4E93F0EB2F14DB556B0F50A96C@xmb-rcd-x04.cisco.com> <4E1F6AAD24975D4BA5B1680429673943668B026C@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1085) Cc: IRTF CFRG , jose@ietf.org Subject: Re: [jose] [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 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, 18 Nov 2012 12:45:40 -0000 --Apple-Mail-91--874108683 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Have you looked at the algorithm in RFC 6476? While the discussion is = CMS-specific, the algorithm could be used with another syntax. Russ On Nov 12, 2012, at 1:55 PM, Mike Jones wrote: > As background, if there was a version of this spec that did not assume = that the parameters would be concatenated together in a specific way, = but left them as independent inputs and outputs, as AES GCM and AES CTR = do, it would be a better match for JOSE=92s use case. > =20 > -- Mike > =20 > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf = Of David McGrew (mcgrew) > Sent: Monday, November 12, 2012 10:21 AM > To: cfrg@irtf.org; jose@ietf.org > Subject: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, = version 01 > =20 > Hi, > =20 > There is a new version of "Authenticated Encryption with AES-CBC and = HMAC-SHA", and I would appreciate your review. It is online at = The diff between the current and the previous version = is available at = > =20 > This draft has been proposed for use in the JOSE WG = , where its adoption would allow = the working group to omit "raw" unauthenticated encryption, e.g. = AES-CBC, and only include authenticated encryption. Thus I am asking = for your help in making=20 > =20 > John Foley generated test cases that correspond to the current version = of the draft, but I didn't include these in the draft because I did not = yet get confirmation from a second independent implementation. With = hope, there will not be any need for any normative changes, and I will = include these after I get confirmation. =20 > =20 > Thanks, > =20 > David > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail-91--874108683 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Have = you looked at the algorithm in RFC 6476?  While the discussion is = CMS-specific, the algorithm could be used with another = syntax.

Russ


On = Nov 12, 2012, at 1:55 PM, Mike Jones wrote:

As = background, if there was a version of this spec that did not assume that = the parameters would be concatenated together in a specific way, but = left them as independent inputs and outputs, as AES GCM and AES CTR do, = it would be a better match for JOSE=92s use = case.
From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org= ] On Behalf Of David McGrew = (mcgrew)
Sent: Monday, November 12, 2012 = 10:21 AM
To: cfrg@irtf.org; jose@ietf.org
Subject: [Cfrg] Authenticated = Encryption with AES-CBC and HMAC-SHA, version = 01
There is a new version of "Authenticated = Encryption with AES-CBC and HMAC-SHA", and I would appreciate your review.   It is online at <https://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2/?in= clude_text=3D1>   The diff between the current and the = previous version is available at < 
_______________________________= ________________
Cfrg mailing list
, "jose@ietf.org" Subject: Re: [jose] [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01 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, 20 Nov 2012 01:48:58 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943668D8EE3TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the pointer, Russ. This is a useful point of reference in sever= al regards. -- Mike From: Russ Housley [mailto:housley@vigilsec.com] Sent: Sunday, November 18, 2012 4:45 AM To: Mike Jones Cc: IRTF CFRG; jose@ietf.org Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, ver= sion 01 Have you looked at the algorithm in RFC 6476? While the discussion is CMS-= specific, the algorithm could be used with another syntax. Russ On Nov 12, 2012, at 1:55 PM, Mike Jones wrote: As background, if there was a version of this spec that did not assume that= the parameters would be concatenated together in a specific way, but left = them as independent inputs and outputs, as AES GCM and AES CTR do, it would= be a better match for JOSE's use case. -- Mike From: cfrg-bounces@irtf.org [mailto:cfrg-boun= ces@irtf.org] On Behalf Of David McGrew (mcgrew) Sent: Monday, November 12, 2012 10:21 AM To: cfrg@irtf.org; jose@ietf.org Subject: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version= 01 Hi, There is a new version of "Authenticated Encryption with AES-CBC and HMAC-S= HA", and I would appreciate your review. It is online at The diff between the current and the previous version is av= ailable at This draft has been proposed for use in the JOSE WG , where its adopti= on would allow the working group to omit "raw" unauthenticated encryption, = e.g. AES-CBC, and only include authenticated encryption. Thus I am asking= for your help in making John Foley generated test cases that correspond to the current version of t= he draft, but I didn't include these in the draft because I did not yet get= confirmation from a second independent implementation. With hope, there = will not be any need for any normative changes, and I will include these af= ter I get confirmation. Thanks, David _______________________________________________ Cfrg mailing list Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg --_000_4E1F6AAD24975D4BA5B1680429673943668D8EE3TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the pointer, R= uss.  This is a useful point of reference in several regards.

 <= /p>

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

 <= /p>

From: Russ Hou= sley [mailto:housley@vigilsec.com]
Sent: Sunday, November 18, 2012 4:45 AM
To: Mike Jones
Cc: IRTF CFRG; jose@ietf.org
Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-S= HA, version 01

 

Have you looked at the algorithm in RFC 6476?  = While the discussion is CMS-specific, the algorithm could be used with anot= her syntax.

 

Russ

 

 

On Nov 12, 2012, at 1:55 PM, Mike Jones wrote:<= /o:p>



As background, if there w= as a version of this spec that did not assume that the parameters would be = concatenated together in a specific way, but left them as independent inputs and outputs, as AES GCM and AES CTR do, it would be a b= etter match for JOSE’s use case.

 <= /p>

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

 <= /p>

From: cfrg-bounces@irtf.org [mailt= o:cfrg-bounces@irtf.org] On Behalf Of David McGr= ew (mcgrew)
Sent: Monday, Nove= mber 12, 2012 10:21 AM
To: cfrg@irtf.org;=  jose@ietf.org
Subject: [Cfrg] Au= thenticated Encryption with AES-CBC and HMAC-SHA, version 01

 

Hi,

 

There is a new version of &= quot;Authe= nticated Encryption with AES-CBC and HMAC-SHA", and I would appreciate your review.   It is online at <https://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-= cbc-hmac-sha2/?include_text=3D1>   The diff between the current and the previous version is available a= t <http://www.ietf.org/rfcdiff?url2=3Ddraft-mcgrew-aead-ae= s-cbc-hmac-sha2-01>

 

This draft has been propose= d for use in the JOSE WG <http://datatracker.ietf.org/wg/jose/> , where its adoptio= n would allow the working group to omit "raw" unauthenticated encr= yption, e.g. AES-CBC, and only include authenticated encryption.   Thu= s I am asking for your help in making 

 

John Foley generated test c= ases that correspond to the current version of the draft, but I didn't incl= ude these in the draft because I did not yet get confirmation from a second independent implementation.   With hope, there will not= be any need for any normative changes, and I will include these after I ge= t confirmation.  

 

Thanks,

 

David

_____________________________________= __________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.org/m= ailman/listinfo/cfrg

 

--_000_4E1F6AAD24975D4BA5B1680429673943668D8EE3TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Tue Nov 20 09:02: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 66FB721F84BA for ; Tue, 20 Nov 2012 09:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeJFeiYIhVYp for ; Tue, 20 Nov 2012 09:02:19 -0800 (PST) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.27]) by ietfa.amsl.com (Postfix) with ESMTP id E7D3721F849F for ; Tue, 20 Nov 2012 09:02:18 -0800 (PST) Received: from BY2FFO11FD005.protection.gbl (10.1.15.201) by BY2FFO11HUB022.protection.gbl (10.1.14.109) with Microsoft SMTP Server (TLS) id 15.0.556.9; Tue, 20 Nov 2012 17:02:04 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD005.mail.protection.outlook.com (10.1.14.126) with Microsoft SMTP Server (TLS) id 15.0.556.9 via Frontend Transport; Tue, 20 Nov 2012 17:02:04 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.146]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Tue, 20 Nov 2012 17:01:37 +0000 From: Mike Jones To: Karen O'Donoghue , Jim Schaad Thread-Topic: Minutes from IETF 85 JOSE meeting Thread-Index: Ac3HQLKow2Xy2wbbTiSaaRXEJwXb1A== Date: Tue, 20 Nov 2012 17:01:35 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943668D9DB7@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.33] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943668D9DB7TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(164054002)(76482001)(56776001)(44976002)(74662001)(47446002)(74502001)(31966008)(54356001)(33656001)(15202345001)(53806001)(5343635001)(5343655001)(50986001)(16406001)(47976001)(56816002)(4396001)(512954001)(49866001)(54316002)(47736001)(51856001)(46102001)(55846005); DIR:OUT; SFP:; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0671F32598 Cc: "jose@ietf.org" Subject: [jose] Minutes from IETF 85 JOSE meeting 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, 20 Nov 2012 17:02:19 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943668D9DB7TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Have these been posted? I know someone took minutes, but I haven't seen th= em. Thanks, -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943668D9DB7TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Have these been posted?  I know someone took mi= nutes, but I haven’t seen them.

 

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

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943668D9DB7TK5EX14MBXC283r_-- From odonoghue@isoc.org Tue Nov 20 15:32: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 4754621F877B for ; Tue, 20 Nov 2012 15:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.9 X-Spam-Level: X-Spam-Status: No, score=-102.9 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dv3n5C32KrT for ; Tue, 20 Nov 2012 15:32:27 -0800 (PST) Received: from smtp176.iad.emailsrvr.com (smtp176.iad.emailsrvr.com [207.97.245.176]) by ietfa.amsl.com (Postfix) with ESMTP id B455F21F8767 for ; Tue, 20 Nov 2012 15:32:27 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp27.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 2F1511182DD; Tue, 20 Nov 2012 18:32:27 -0500 (EST) X-Virus-Scanned: OK Received: by smtp27.relay.iad1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 8A49B1182D9; Tue, 20 Nov 2012 18:32:26 -0500 (EST) References: <4E1F6AAD24975D4BA5B1680429673943668D9DB7@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943668D9DB7@TK5EX14MBXC283.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-8385C1C4-CA2B-4F79-828B-C37F75BD3E7F Message-Id: <1805F054-2CDD-47AE-B0B9-857FA949BDA5@isoc.org> X-Mailer: iPhone Mail (9B206) From: Karen O'Donoghue Date: Tue, 20 Nov 2012 23:32:19 +0000 To: Mike Jones Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] Minutes from IETF 85 JOSE meeting 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, 20 Nov 2012 23:32:28 -0000 --Apple-Mail-8385C1C4-CA2B-4F79-828B-C37F75BD3E7F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I'm on vacation out of the country until 26 November. I'll check into it whe= n I return.=20 Karen Sent from my iPhone On Nov 20, 2012, at 5:01 PM, Mike Jones wrote:= > Have these been posted? I know someone took minutes, but I haven=E2=80=99= t seen them. > =20 > Thanks, > -- Mike > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail-8385C1C4-CA2B-4F79-828B-C37F75BD3E7F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I'm on vacation out of the= country until 26 November. I'll check into it when I return. 

Karen

Sent from my iPhone

On Nov 20, 2= 012, at 5:01 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

=

Have these been posted?  I know someone took min= utes, but I haven=E2=80=99t seen them.

 

         = ;            &nb= sp;            &= nbsp;            = ;             Th= anks,

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

 

____________________= ___________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman= /listinfo/jose
= --Apple-Mail-8385C1C4-CA2B-4F79-828B-C37F75BD3E7F-- From hannes.tschofenig@gmx.net Mon Nov 26 03:07: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 10F7F21F8542 for ; Mon, 26 Nov 2012 03:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8Ay0SsnzEK8 for ; Mon, 26 Nov 2012 03:07:28 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 24BEF21F84FA for ; Mon, 26 Nov 2012 03:07:27 -0800 (PST) Received: (qmail invoked by alias); 26 Nov 2012 11:07:25 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.114]) [88.115.216.191] by mail.gmx.net (mp030) with SMTP; 26 Nov 2012 12:07:25 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/e0NtT8PHesBXZaf2ksCjd6f/AYYe1mOu5HY7/Bs gqCc+zf3YzrGV4 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Nov 2012 13:07:23 +0200 Message-Id: To: jose@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: Hannes Tschofenig Subject: [jose] Extensibility (was "Criticality") 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, 26 Nov 2012 11:07:29 -0000 Hi all,=20 doing my shepherd writeup of some of the OAuth WG documents I was = wondering how the extensibility story for these JSON-based documents = should look like given a statement like this: "Implementations MUST = understand the entire contents of the header; otherwise, the JWS MUST be = rejected." Absent a "feature discovery" mechanism I am curious whether any = extension is actually possible.=20 (Funny enough then all individual parameters then say "This header = parameter is OPTIONAL.")=20 Since this type of extensibility feature does not seem to a be a new = concept I am curious how it has been handled (successfully) in other = specifications.=20 Ciao Hannes PS: I remember that this has been discussed during the meeting but I do = not know what the outcome of the discussion was. The meeting minutes do = not seem to be available yet. =20= From Hannes.Tschofenig@gmx.net Mon Nov 26 03:11: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 9503121F8449 for ; Mon, 26 Nov 2012 03:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBfMXOJgVrSb for ; Mon, 26 Nov 2012 03:11:11 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 5690B21F8448 for ; Mon, 26 Nov 2012 03:11:11 -0800 (PST) Received: (qmail invoked by alias); 26 Nov 2012 11:11:10 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.114]) [88.115.216.191] by mail.gmx.net (mp019) with SMTP; 26 Nov 2012 12:11:10 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19he49IBc1hn3zoXkeEY7fb9xeEb3dxc6oQgJXRGf ZU6WEDyE7W/Cbw Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Hannes Tschofenig Date: Mon, 26 Nov 2012 13:11:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2F1412B7-4585-4372-9B2F-FA852DA759A8@gmx.net> References: <0DC3825F-D600-4239-8283-FB7E2CAC4514@gmx.net> To: jose@ietf.org X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: Hannes Tschofenig Subject: [jose] Namespace 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, 26 Nov 2012 11:11:12 -0000 Hi all,=20 I posted a review of the JWT document to the OAuth mailing list but one = specific issue is probably more relevant for JOSE than for OAuth. The namespace concept form the JOSE header parameters has been copied to = the "body" for the OAuth JWT spec: Begin forwarded message: > - Namespace >=20 > The document defines a couple of claims. Quite naturally one wants to = provide extension points since others will quite likely come up with new = claims in the near future. The obvious approach would be to use an IANA = registry to maintain uniqueness of the labels but without using a = namespace declaration concept like XML does.=20 >=20 > For some reason that does not seem to be enough to use IANA alone: the = document introduces three types of claims, namely Reserved Claim Names, = Public Claim Names, and Private Claim Names >=20 > No mechanism is stated how these claims can be differentiated but = essentially everything is allowed. Section 2 ("Terminology") says that = the claims that are not registered through IANA may be Domain Names, = Object Identifiers (OIDs), UUIDs, etc.=20 >=20 > Later in Section 4.2 it is said that public claims could be a URI, = which is again different to what is said in Section 2.=20 >=20 > Furthermore, Private Claims (as defined in Section 4.3) do not seem to = have the requirement for uniqueness anymore even though Section 4 says = that claim names in a JWT have to be unique.=20 >=20 > The danger is obviously that two parties define claim names that have = different semantic. This will lead to confusion. When claims with the = same names are added to a JWT then, per specification, the receiver will = have to fail.=20 >=20 > Do we really need to support claims where uniqueness cannot be = guaranteed? > Can we decide on a few namespace concepts rather than leaving the list = open-ended? What are the JOSE guys going to do about this issue? >=20 > Btw, is it allowed to use JavaScript reserved keywords as claim names? >=20 In a summary, has someone looked at the way how the header parameters = are reserved? Does this make sense to you? Ciao Hannes From Hannes.Tschofenig@gmx.net Mon Nov 26 03:15:54 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 BB11E21F8588 for ; Mon, 26 Nov 2012 03:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYAk4m9NzQIQ for ; Mon, 26 Nov 2012 03:15:54 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id C140B21F857E for ; Mon, 26 Nov 2012 03:15:53 -0800 (PST) Received: (qmail invoked by alias); 26 Nov 2012 11:15:52 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.114]) [88.115.216.191] by mail.gmx.net (mp032) with SMTP; 26 Nov 2012 12:15:52 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/j8asPZ6zjKZMiYztuJVptF0nRI5VCpvD7XVdJSR YyD4wWi3NU9QV9 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Hannes Tschofenig Date: Mon, 26 Nov 2012 13:15:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4354D3B0-62A3-45A2-ABDB-9A006C6C7263@gmx.net> References: <0DC3825F-D600-4239-8283-FB7E2CAC4514@gmx.net> To: jose@ietf.org X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: Hannes Tschofenig Subject: [jose] Key Identifier 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, 26 Nov 2012 11:15:54 -0000 Hi all,=20 In Appendix A.1 of the JWS document there is an example with an HMAC = SHA-256 keyed message digest. I would have assumed that the header contains the key id so that the = receipient can actually verify it. Ciao Hannes From Michael.Jones@microsoft.com Tue Nov 27 22:01: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 F1CA921F8788 for ; Tue, 27 Nov 2012 22:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYaTbL-2bl37 for ; Tue, 27 Nov 2012 22:01:21 -0800 (PST) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id 93EC621F8763 for ; Tue, 27 Nov 2012 22:01:20 -0800 (PST) Received: from mail102-db3-R.bigfish.com (10.3.81.234) by DB3EHSOBE009.bigfish.com (10.3.84.29) with Microsoft SMTP Server id 14.1.225.23; Wed, 28 Nov 2012 06:01:19 +0000 Received: from mail102-db3 (localhost [127.0.0.1]) by mail102-db3-R.bigfish.com (Postfix) with ESMTP id 6979120107; Wed, 28 Nov 2012 06:01:19 +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: -23 X-BigFish: VS-23(zz9371I542M14ffIzz1de0h1202h1d1ah1d2ahzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h15d0l1155h) Received-SPF: pass (mail102-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 mail102-db3 (localhost.localdomain [127.0.0.1]) by mail102-db3 (MessageSwitch) id 1354082477654498_12767; Wed, 28 Nov 2012 06:01:17 +0000 (UTC) Received: from DB3EHSMHS015.bigfish.com (unknown [10.3.81.244]) by mail102-db3.bigfish.com (Postfix) with ESMTP id 9CD3642005B; Wed, 28 Nov 2012 06:01:17 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS015.bigfish.com (10.3.87.115) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 28 Nov 2012 06:01:17 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.240]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Wed, 28 Nov 2012 06:01:03 +0000 From: Mike Jones To: Hannes Tschofenig , "jose@ietf.org" Thread-Topic: [jose] Key Identifier Thread-Index: AQHNy8d0ku6cn6XRzEmtwuiZq1B1wJf+w3/Q Date: Wed, 28 Nov 2012 06:01:02 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366905D5D@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <0DC3825F-D600-4239-8283-FB7E2CAC4514@gmx.net> <4354D3B0-62A3-45A2-ABDB-9A006C6C7263@gmx.net> In-Reply-To: <4354D3B0-62A3-45A2-ABDB-9A006C6C7263@gmx.net> 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] Key Identifier 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, 28 Nov 2012 06:01:22 -0000 It may contain the key ID, or like many things OAuth, it may know which key= to use by other means. For instance, it may be supplied via dynamic regis= tration. -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Han= nes Tschofenig Sent: Monday, November 26, 2012 3:16 AM To: jose@ietf.org Cc: Hannes Tschofenig Subject: [jose] Key Identifier Hi all,=20 In Appendix A.1 of the JWS document there is an example with an HMAC SHA-25= 6 keyed message digest. I would have assumed that the header contains the key id so that the receip= ient can actually verify it. Ciao Hannes _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From hannes.tschofenig@nsn.com Tue Nov 27 23:00: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 F118521F85A1 for ; Tue, 27 Nov 2012 23:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OLL30hmCzQ1 for ; Tue, 27 Nov 2012 23:00:21 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA9B21F859D for ; Tue, 27 Nov 2012 23:00:20 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id qAS70ENp031759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Nov 2012 08:00:16 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id qAS70EIJ014594; Wed, 28 Nov 2012 08:00:14 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Nov 2012 08:00:14 +0100 Received: from 10.144.246.139 ([10.144.246.139]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) with Microsoft Exchange Server HTTP-DAV ; Wed, 28 Nov 2012 07:00:13 +0000 User-Agent: Microsoft-Entourage/12.35.0.121009 Date: Wed, 28 Nov 2012 09:00:12 +0200 From: Hannes Tschofenig To: Mike Jones , Hannes Tschofenig , "jose@ietf.org" Message-ID: Thread-Topic: [jose] Key Identifier Thread-Index: AQHNy8d0ku6cn6XRzEmtwuiZq1B1wJf+w3/QgAAQ9/8= In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366905D5D@TK5EX14MBXC283.redmond.corp.microsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Nov 2012 07:00:14.0162 (UTC) FILETIME=[03F04B20:01CDCD36] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1635 X-purgate-ID: 151667::1354086016-000010BC-D38D53DB/0-0/0-0 Subject: Re: [jose] Key Identifier 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, 28 Nov 2012 07:00:22 -0000 Hi Mike, Thanks for the response. If you indeed think that all header parameters can be configured out of band (or guessed) then it would be good to state that assumption in the example. For real-world practicability purposes I would assume that the key identifier is present (regardless whether the keying material is statically or dynamically provisioned). Somehow the right key has to be selected and you want to make it robust (particularly when keys can be cached and multiple keys may be used at the same time, for example, for key roll-over). Ciao Hannes On 11/28/12 8:01 AM, "Mike Jones" wrote: > It may contain the key ID, or like many things OAuth, it may know which key to > use by other means. For instance, it may be supplied via dynamic > registration. > > -- Mike > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Hannes > Tschofenig > Sent: Monday, November 26, 2012 3:16 AM > To: jose@ietf.org > Cc: Hannes Tschofenig > Subject: [jose] Key Identifier > > Hi all, > > In Appendix A.1 of the JWS document there is an example with an HMAC SHA-256 > keyed message digest. > > I would have assumed that the header contains the key id so that the > receipient can actually verify it. > > Ciao > Hannes > > _______________________________________________ > 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 odonoghue@isoc.org Fri Nov 30 07:56: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 E28BA21F86A8 for ; Fri, 30 Nov 2012 07:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.11 X-Spam-Level: X-Spam-Status: No, score=-102.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnTBiExOoZTG for ; Fri, 30 Nov 2012 07:56:51 -0800 (PST) Received: from smtp116.iad.emailsrvr.com (smtp116.iad.emailsrvr.com [207.97.245.116]) by ietfa.amsl.com (Postfix) with ESMTP id AC18F21F8665 for ; Fri, 30 Nov 2012 07:56:50 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp41.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id E3C1B290D07 for ; Fri, 30 Nov 2012 10:56:49 -0500 (EST) X-Virus-Scanned: OK Received: by smtp41.relay.iad1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 6C8CC2909D0 for ; Fri, 30 Nov 2012 10:56:49 -0500 (EST) Message-ID: <50B8D740.6000205@isoc.org> Date: Fri, 30 Nov 2012 10:56:48 -0500 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: jose@ietf.org References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: multipart/mixed; boundary="------------060605050700090501070700" Subject: [jose] rough notes from ietf85 jose meeting X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 15:56:53 -0000 This is a multi-part message in MIME format. --------------060605050700090501070700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks, Here are some raw notes from the jose meeting. Special thanks to Carl Wallace for these. They have not yet been turned into minutes. That will hopefully be done shortly. Any corrections to these notes are welcome in anticipation of minutes. Regards, Karen --------------060605050700090501070700 Content-Type: text/plain; charset=UTF-8; x-mac-type="54455854"; x-mac-creator="522A6368"; name="jose minutes.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="jose minutes.txt" JOSE WG - IETF 85 Agenda ======================== Wednesday, 7 November 2012, 900-1130 EDT (1400 - 1630 UTC) ****************************************************************************************** JWA, JWE, JWK, JWS Document Updates ****************************************************************************************** John Bradley presented slides (http://www.ietf.org/proceedings/85/slides/slides-85-jose-4.pdf). No questions or comments. ****************************************************************************************** JWS, JWE, JWA, JWK Way forward ****************************************************************************************** Nat Sakimura presented slides (http://www.ietf.org/proceedings/85/slides/slides-85-jose-1.pptx). Richard Barnes: One might observe that requiring all fields to be critical and requiring a nonce invites abuse. Process-wise, should revisit these after some other discussions. ********Algorithm issue******** Jim Schaad: Heard interesting presentation during KITTEN, they were discussing requirements for supporting Suite B in Kerberos. Though shalt not SHA1 anything. Even though there are no known issues with HMAC-SHA1, it is not permitted by a Suite B version of the system, this may or may not cause changes here. This is potentially a good time to ask W3C to implement the specs. John Bradley: Same point, for Suite B if OAEP w/ SHA1 were made mandatory then folks would get into scenario where could not be Suite B and JOSE compliant. Having it available for use but omitted in government implementations should be fine. The debate is still open. Probably not going to see the world agree on an OAEP variant. Joe Hillenbrand: One thing discussed early on was to select small number of things to increase interoperability. Not suggesting things be nailed down to one, but if we are going to pick one mandatory to implement make it Suite B compatible. Richard: Thought we were not going to have mandatory to implement algs. The alg definitions in the web crypto spec allow for separate specification of params to OAEP. That spec is not finalized but that is current state. Stefan Santesson: Really really bad for protocol to specify mandatory to implement algs. Joe: Having users define their own MTI makes sense but guidance can be provided to help make choices. Mike Jones: Background info about how the specs currently handle the status of whether some things are required, optional or deprecated. Illustrious AD Sean suggested that practice be followed where a field is added to the registry for algorithms and explicitly give designated experts to change status over time as crypto landscape changes. There will be initial values, but fully expected that some new algs will be added, downgraded, etc. Not in an inflexible situations. Additionally, always part of JOSE to create interoperable specs. Which is why the question keeps coming up about PKCS1.5. Should OAEP be supported at all, use default in RFC 3347 or do something else. Studies of existing libraries indicate that this is the only feasible choice today. Would like to see this issue put to bed. Richard: If MTI question is to be pursued, should it be run to ground now or flagged as issue. Karen O'Donoghue: Flag as an issue. Stefan: Secdir may define a document with IETF wide algorithm statements. Would be a good approach even if not fitting the timeframe for this group. Sean Turner: Suite B does not define RSA for signature stuff, so perhaps we should just let it be. Karen: Any objections? No. Will take to list for closure. On to criticality of fields. ********Criticality issue******** Richard: If we do not allow non-critical fields we invite folks to stuff things into critical fields that don't really fit. There are some syntactic ways to support non-critical fields. NC fields is a good idea. Jim: Question about bullet 2 on criticality slide. Can you tell me why mandating applications to decide which fields are critical would not provide same security levels. John: the receiver must understand what it is being sent. Sender may have a different understanding than receiver. Jim: Application should define in a specification to address understanding mismatch. Lets it live outside of the core spec. John: It may be possible to leave to all things that use the JOSE specs but thinks this would lead to interop issues. Hannes Tschofenig: If you think about the usage of these, different apps have very different semantics and require specs anyway. So there is no additional security problem with leaving decision to apps. For example, S/MIME defines different CMS fields than other apps. John: Agrees with Richard that if multiple things are using these specs, all may need a way to indicate non-critical elements. We will wind up with interop issues otherwise. Can't assume isolation between apps, for example SAML tokens. Hannes: Richard: We will encode it all in DER:-) Some of the suggestions on the list have been to make two buckets instead of one (critical and non-critical instead of just critical). Mike: A number of syntaxes have been proposed. For example, include a list of fields that may be allowed to be not understood. John: Mike is saying, that no one is expressing the opinion that all fields are non-critical. Everyone agrees that at least some fields should be critical but no one is saying all should be critical. Though there may be some folks who hold this opinion (i.e. all critical). Mike: List traffic indicated there were people who held this view. Simplicity is one reason. Code can simply look at each field, ask do I understand it, fail if not. Alternative is inventing a mechanism for per field behavior. Joe: We've had good success with forward compatibility. If you've updated one side but not the other, its tough to know what to send if sending something new breaks the other side. Mike said from the floor that this argues not to send it. However, this inhibits future change. If we think we won't need different params in the future fine, but that's probably not the case. John: Disagrees with Mike since other protocols will need to include different information into the headers for different reasons, including encrypted body. Saying everything in headers must be understood is going to far. Sean: Conservative in sending, liberal in receiving. Are we sure we have everything we'll need identified? Jim: It is just as simple to pass in a list of headers that the application understands to make applications responsible instead of libraries. Matt Miller: Should not make everything mandatory. In XMPP, we include a rough timestamp. It works for XMPP but won't work for most cases. Thus some headers need to be non-critical. Need not be in the protocol, could be app specified. Mike: Not philosophically opposed to having a list of fields that indicate fields to ignore. To Jim's point about apps defining such, the current spec is completely agnostic to that. As long as app understands, spec allows it to be used. Karen: Before we spend more time, if there is a small group that could work with Mike to make the change could a solution be reached? Perhaps with Richard and John. Mike: Perfectly willing to write up something. Stefan: Is there a thought that the header fields might be expanded in the future. Karen: Uncomfortable precluding expansion. So we've decided all fields are non critical and will figure out right text offline. ********Nonce issue******** Jim: I have proposed a means for putting a timestamp parameter in. Got a number of comments "but do you have a concrete reason for needing this parameter"? If you don't, there is no reason to include a time of signing parameter. Without a use case, acceptance was thin. Not sure what should be done with the proposal. Hannes: There a couple of different aspects. Does not matter if defined now or later. Apps will define new stuff anyway. Where should you put it - header or body? Also does not matter since it needs to be signed. Gets to question how much stuff into base specs and how much into applications. Should not be too religious as it does not matter at the end of the day. John: Since we will resolve the criticality issue, this is less important. Need to determine if multiple folks will need it. Joe: Seems reasonable that more than one app will want protection against replay. Mike: Not disagreeing. Restating some comments from the list, folks who have implemented this at Google and elsewhere, if you don't have an expiration with a nonce then you are implying infinite storage. Jim: The proposal had no nonce and was strictly a time. However, given resolution to previous item then this is less important at this time. Karen: Will take this issue up later. It will not impact WGLC decision. Three issues coming in. WGLC will be discussed at the end. ****************************************************************************************** JOSE Use Case Document ****************************************************************************************** Richard Barnes presented slides (http://www.ietf.org/proceedings/85/slides/slides-85-jose-2.pdf). Jim: Would support adopting this as a WG item. Matt: I also think this would be a good document to adopt. Karen: Any objections. None. Will be adopted. Sean: Procedural point. Will need to re-charter since charter limits the number of docs. Should be easy to address. ****************************************************************************************** Serialization Documents ****************************************************************************************** Mike Jones presented slides (http://www.ietf.org/proceedings/85/slides/slides-85-jose-3.pptx). Richard/Mike: Matt: Re: XMPP, know who is being sent to but not which end point is receiving. Mike: Fair point. May want to distribute cipher text before knowing which key. Matt: In XMPP, this always occurs. Sean: Recharter or stick this stuff into existing docs? Recharter should be easy. Jim: Prefer us to recharter or include in docs? Sean: Publish docs. John: If the right structure is to have as separate doc, we should not let charter issue get in the way. Karen: For purpose of today, consensus is to adopt as separate docs. Will worry about charter later. Richard: Aside from process points, current docs are not a good starting point. ****************************************************************************************** Wrapped Keys ****************************************************************************************** Matt Miller presented slides (http://www.ietf.org/proceedings/85/slides/slides-85-jose-7.pdf). Richard: This is a great idea. We have JWE with key mgmt mech and makes sense to use it. Proposal 2 is the right way to go. Proposal 1 is riddled with issues. All sorts of questions about which algs to use. Much cleaner to use Proposal 2. Jim: You mentioned integrity. Are you doing two separate integrity checks on original msg and key exchange? Matt: Yes. John: My understanding is that the initial message is JWE but recipient does not have decryption key yet. Recipient can ask for the key. Backwards to what usually happens. Mike: Is there concrete syntax for proposal 2? Matt: Yes, previous two slides. Strawman syntax at present. Mike: Different thing from JWK. Jim: Procedure question. How will strawman get incorporated into one or more docs? Matt: Will prepare a draft or work with Mike to see if changes can be made directly to JWK. Mike: Gut reaction is to see individual draft first. Short draft is fine. Matt: OK. Jim: Anyone else to scream and yell? No. A draft will be prepared for group review. ****************************************************************************************** SPI ****************************************************************************************** Richard Barnes presented slides (http://www.ietf.org/proceedings/85/slides/slides-85-jose-6.pdf). John: I don't hate it. Observes that in Open ID connect pre-negotiation occurs. Would not want to remove the ability to specify params in each message. For typical case, the two parties will have negotiated out of band and this will save a pile of octets. Joe: Likes the idea. Did you mean random for spi name? Or something like a UUID? Or something like a hash. John: Probably protocol dependent. Richard: No randomness requirements. Probably some uniqueness requirements, within some scope. John: Will need to determine if sender is identified separately or if uniqueness is global, but this can be sorted out. Matt: This will be application dependent. Richard: Proposes this go in as text to JWS and JWE. Will provide text to Mike. Karen: Anyone against this? No. Are folks comfortable with Richard and Mike working to modify the base docs? John: Would prefer to see a short draft before mucking with base docs. Richard: Probably not a draft, but an email. ****************************************************************************************** Key Requets from W3C ****************************************************************************************** Mike Jones presented slides (http://www.ietf.org/proceedings/85/slides/slides-85-jose-5.pptx) John: As I recall, initial hesitation was with public keys risk of disclosure is small, but with private keys we are taking on large expansion in responsibility. Somewhat hesitant but this is going to be done anyway so we should best grapple with it. Potential for getting it wrong is dire. Justin ?: Add support for it. Add another use case: configuration of bare keys in apps. Would like to use JSON based formats for storing raw keys and not have to do and create a certificate. Ryan Sleevi: If the WG does not adopt this, then the Wc3 work will pursue it since use cases demand such. JOSE seems to be the consistent place to do this work. If JOSE rejects, then WebCrypto group will standardize. Joe: Have always wanted this. Overjoyed to have use cases for this. Thinks the WG is good place to do the work. Enthusiastically supports. Matt: Earlier presentation was argument for wrapped sym key, as others have said private key piece would be useful. Thinks security issues can be addressed and not made worse. Jim: Has not read the draft, puzzled what it is that is required for symmetric key usage? Do you want algs as well since key is just a base64 string. Mike: Yes. Would identify the algorithm and key blob. Analogous to X.509 SubjectPublicKeyInfo. Richard: A couple of desires: 1) wrapped key format for import/export; 2) keys that have attributes attached. Mike: Already have key ID. Could define more. Jim: Clarifying if attributed private key is desired. Are you proposing that we accept as a work item, protection mechanisms. Mike: No request so far. Joe: I am making that request. Necessary to have complete suite. John: Violently opposed to doing the work without protection mechanisms. Sean: Procedurally, nice that it went this route instead of through liaison process. John: Not making comparisons to previous attempts by IETF to define alternatives to X.509. Karen: Will address under rechartering discussion. ****************************************************************************************** Private Key Formats ****************************************************************************************** Mike Jones presented slides (http://www.ietf.org/proceedings/85/slides/slides-85-jose-8.pptx). Richard: Should merge this with the stuff Matt talked about earlier. May make sense to address in JWK. Matt: Need to write drafts first and see what they look like. Multiple docs may make things more readable. Joe: Have you defined a protection mechanism yet? Mike: No John: Agree that Matt is pushing private keys around and needs protection. Wrapped symmetric key more specifically, Lots of overlap with this. Joe: Start with an email to the list describing the overall architecture. Here are the pieces, how they fit, etc. Let's see it at least in high level form then decide how to best allocate to documents. Mike: Three layers: public key, key representations for private and symmetric keys, key protection mechanisms. ****************************************************************************************** Re-chartering questions ****************************************************************************************** Sean: The milestones are separate from charter so just send an email with new dates. Karen: Back to WGLC questions. One open issue on criticality of headers: Richard, John and Mike will address. Private key work and SPI work effect core docs. Jim: Richard, would you like to have mandatory to implement (MTI) algorithm argument now? Richard: Sure. The broad outline is whether these specs should require a given set of algs. A similar arg went through WC3 web crypto group. They decided against. Argument in favor is interoperability. Counter view is placing alg requirements makes it hard for apps to make sure certain algorithms are available. For example, multi-platform browsers that use OS crypto. Jim: Make clear, IESG will complain if there is not a mandatory to implement alg. May be able to get away with pushing to application. Richard: Yes. CMS and PKIX do not have required algs. This is not DNSSEC which is a global infrastructure. In this case, the communications are between two parties who can figure out what they want to do. Mike: Every draft for last two years has had some set of MTI algs. Having a small core helps. Request is that if we are changing, there should be a consensus call. Change is a fairly big deal. Re: Web crypto decision, their use case is different. In our case, a small set of algs is proposed to promote interop. They are defining general purpose low level mechanism. Russ Housley: Interop is the whole point with MTI. However, algs will change over time. Do not put this in base spec. We have made that mistake before, don't repeat. Reason PKIX does not have MTI alg is that certs are used in many apps. Each app defines MTI achieving separation of MTI from syntax. Barry Leiba: Would rather see MTI in registrations of these things. Appreciates that apps should define. Given reuse of apps, there is concern about not stating something. (from floor) use case? No use case, just thinking ahead. Mike: The spec initializes a set of use, don't use, etc in a registry. Russ: Please don't confuse a registry with MTI. Richard: Re: cross-app usage, for interop there are often specs to iron out details anyway. Just another detail in those. Joe: Fine with punting to apps. For example, for XMPP these are MTI, etc. Karen: So, hearing generally agreement to move out of base spec except from Mike. AD has asked to do a hum then will take it to a list. Hum indicates remove from base spec wins. Will bring up on the list. There are four open issues. Another rev of docs will be required before WGLC. How long will it take to rev drafts? Richard and Matt? Richard: SPI should be quick. By end of year. Matt: For draft of wrapped keys. Similar time frame. Integrating with others is a different discussion. Mike: Private key, wrapped key, etc. is much bigger chunk of work. Would like JWK go to WGLC sooner. Jim: Does current JWK define anything about field criticality? Mike: Follows other docs. Jim: So we need a rev for that too. Richard: Matt's private key bits should just be shuffling stuff between docs. Should not be large effort. Karen: I though W3C work would take longer. Jim: Opposed to including private keys with a doc describing protection. Sean: Would like to see this work taken on. Karen: A few issues to incorporate. Aim is to issue WGLC in early 2013. Mike: Assuming we make decisions on these issued before WGLC, chairs should assume a consensus call will be held on the list. Jim: I assume you preference would be to update JWA and JWK specs to include private keys? Mike: I would prefer to go forward with public key docs as is and write a new draft that would update and add fields to JWK structure but in a separate draft for private, sym and wrapped keys. Richard: I think I would split todos into piles: 1) things that go into a JWE; 2) things like private keys, sym keys and attributes. Push wrapped keys into JWK. Provide feedback to W3C as well. Mike: I have a different model of what JWK is for vs Richard. JWK is just a key representation. If you want to wrap it, that's a different object that uses JWK. It's not a part of the key but a container. Would write container separately. Richard: JWK defines how to send keys on the wire. Joe: Would be nice to have one short email with architecture. Too early to say how docs will be split. Leave that out of new charter. Karen: Who is going to write architecture email. Joe: Mike nodded in a way that indicated he may do that. Mike: OK, if I get some input on best practices for wrapped keys. Joe: Let's find a white board this week, then send notes from that board to the list. Karen: Strongly agree. Joe: I will fill the whiteboard. Karen: Next thing is use cases doc. Charter will be updated. Ditto serialization draft, which will be incorporated somehow. Charter will be updated for this as well. Final is W3C work will be documented in email generated by the white board team. Anything else? Jim: Joe, do you want volunteers? Joe: Sending note to the list right now. Matt: One thing that has come up on the list is key derivation stuff. Some disalignment with NIST 800-56a. PBKDF2 as defined says a password is an octet string. Mike: Primary thing in specs, is to address legitimate concerns about use of concat KDF. Initially no length prefix. So there was ambiguity. With length prefix, ambiguity is gone. What is it possible for everyone to easily implement? With concat, it's a string concat and a hash. Everyone can do that. At least 6 implementations. Richard: Are we actually saving anything. Are we sending more info to identify KDF than if we just sent key, since KDF is intended to allow use of shorter keys. Mike: You do need KDF for ECDH anyway. Anything with key agreement will have KDF already. Matt: In that case, implementing PBKDF is not much more difficult. Mike: Iterations are just more work. Jim: Iterations can be set to 1. Matt: Looking at things that do PBKDF and concat KDF, it's not hard to implement PBKDF. ?: Is subject KDFs or password based KDFs? Jim: KDFs ?: Don't we have a real KDF? Why not use that? Lots of work going on about improving PBKDFs. Not sure marrying to PBKDF2 is wise. Matt: Not saying we only implement PBKDF2, saying for things we register don't see why not PBKDF2. Mike: Given decision to specify AEAD, there's nothing to say you could not define another alg, say CBC with a different KDF. Various iterations with ADs etc to make sure use of concat is clean. Same issues would come up for any other KDF. Similar sets of inputs. Not any simpler to use different KDF. Matt: Richard: Our need to have this discussion is a consequence of alg IDs. If alg ID included this things then this would not be an issue. May want to figure out how to separate this out to be more configurable. Mike: That's a closed issue. Karen: Issuer tracker will be used going forward. Read the docs now and get comments out now to spare work during WGLC. Kevin Igoe: There is a draft that does composite AEAD . May want to look at that. Mike: WG did have a presentation last time. Discussion was that it is an alg that could be added should it mature. Kevin: Why not just steal their params? Mike: There was a length expansion there that we don't need. Richard: Please post to the list how using a longer key compares to using a KDF. --------------060605050700090501070700--