From ve7jtb@ve7jtb.com Wed May 2 16:32: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 BB82A21E8054 for ; Wed, 2 May 2012 16:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWtPU+4VRjji for ; Wed, 2 May 2012 16:32:13 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1695021E8042 for ; Wed, 2 May 2012 16:32:13 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so1734984pbc.31 for ; Wed, 02 May 2012 16:32:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:subject:date:message-id:to:mime-version:x-mailer :x-gm-message-state; bh=UKyZPsQLstr70yA89TtJMpSgePDNYoujSX2Q2p/g9ck=; b=NAL6eP91luAh/ay2PnHb9du7fCVy2O8MpADqMBRCiOHELeady9OLvwtEJxfNcUQAQE +bJyEIvkhuA6K+OPTJo6ipTkxNkNw2h6OiuFx0tDlRVpAud+3GQvzsIzlFL02fHi58nR kp085B4VtAi0rDpqHwnY11/t2H6Y/41agsGs6Xz5RLQ+TjXsSXkx21qqFPWBed4CulVK SPlTTmass1DW0RlytZRGrY1K9qTzsWkpq8969Llabos3UP4Gq0BDv/JWNijzdtL3PJaQ d04r/4b1wRVat0z3Re3n3uQAJGQPZIlNvpAXgBJKpGO/ee+p7fq2vfpJG6aCIxjfz9nK mh6g== Received: by 10.68.237.33 with SMTP id uz1mr1779409pbc.55.1336001532804; Wed, 02 May 2012 16:32:12 -0700 (PDT) Received: from [10.2.4.153] ([64.9.249.121]) by mx.google.com with ESMTPS id oj3sm443346pbb.20.2012.05.02.16.32.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 May 2012 16:32:11 -0700 (PDT) From: John Bradley Content-Type: multipart/alternative; boundary="Apple-Mail=_D1230595-A9E1-4365-B88E-2F25B51B5B2A" Date: Wed, 2 May 2012 16:32:09 -0700 Message-Id: <50612135-0071-424E-B223-ACBD1606F685@ve7jtb.com> To: jose@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkni6+OU0gYxBRwuETou5E12iHV367CSyZEQlw7qByGPzTXjMfZES02YdkK9o3HXPGTXEUD Subject: [jose] AES-CBC padding 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, 02 May 2012 23:32:13 -0000 --Apple-Mail=_D1230595-A9E1-4365-B88E-2F25B51B5B2A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii JWE is not making a specific padding recommendation for CBC. There are several options including PKCS#5 and the variant used by = xmlenc. The other option is to use one of the new CBC modes AES-CBC-CS1. = http://csrc.nist.gov/publications/nistpubs/800-38a/addendum-to-nist_sp800-= 38A.pdf I suspect the best thing for interoperability is to use PKCS#5 like CMS. The new modes are more secure, but will be an interoperability problem. Thoughts? John B.= --Apple-Mail=_D1230595-A9E1-4365-B88E-2F25B51B5B2A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii JWE = is not making a specific padding recommendation for = CBC.

There are several options including PKCS#5 and = the variant used by xmlenc.

The other option is = to use one of the new CBC modes AES-CBC-CS1.

I suspect the best thing = for interoperability is to use PKCS#5 like = CMS.

The new modes are more secure, but will be = an interoperability = problem.

Thoughts?

John = B.
= --Apple-Mail=_D1230595-A9E1-4365-B88E-2F25B51B5B2A-- From ietf@augustcellars.com Wed May 2 17:24:07 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A06F11E80B1 for ; Wed, 2 May 2012 17:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoGWbHmgjUOu for ; Wed, 2 May 2012 17:24:05 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 5641711E808D for ; Wed, 2 May 2012 17:24:05 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id CBF322CA16; Wed, 2 May 2012 17:24:04 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" References: <01f401cd181e$ab37d1a0$01a774e0$@augustcellars.com> <4E1F6AAD24975D4BA5B168042967394366499F0B@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366499F0B@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Wed, 2 May 2012 17:23:03 -0700 Message-ID: <022c01cd28c2$e807e390$b817aab0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_022D_01CD2888.3BB121E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHa69L8BLxmfdrmGGpoJWfhMWxd3AJCjJM+lomXgJA= Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] Comments on draft-ietf-jose-json-web-key-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: Thu, 03 May 2012 00:24:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_022D_01CD2888.3BB121E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, April 25, 2012 9:22 PM To: Jim Schaad Cc: jose@ietf.org Subject: RE: [jose] Comments on draft-ietf-jose-json-web-key-01 Thanks for the detailed comments, as always, Jim. Replies inline. -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Wednesday, April 11, 2012 1:07 PM To: Mike Jones Cc: jose@ietf.org Subject: [jose] Comments on draft-ietf-jose-json-web-key-01 11. Should the text that is in the signature and encryption dealing with adding fields (urls vs simple names) be included in this section as well? Are you thinking of the text about the three classes of names: reserved, private, and public? With the possibility of a registry? What do people in the working group think? I think the chances of this object being extended are small, especially since we only define one member. But then, it's incredibly hard to predict how a standard will be used, if successful. I'd be more prone to think that extension made sense if the spec defined more than one member. Yes that was what I was thinking of. If we are going to say don't add things willy-nilly then we should probably have text saying how to add things safely. 12. Should there be an IANA registry for the member names of a container object. Per 11, I don't think so. I think this case is better handled by the standard JSON "you can add fields if you understand them" logic. Cost of a registry is low if we think that the IETF is going to want to add things then we should setup the registry now. JWK Key Object Format: 18. Should the text dealing with adding members be present (copied from JWS)? Is it just the key and not the entire key set that is to be ignored? Again, are you thinking the reserved/private/public treatment? With a registry? Or maybe just a registry? I didn't find "ignore" in the draft, so I'm not sure what the second sentence in your remarks is referring to. The text for Key Object says that if additional members are present they MUST be understood - hence if not understood the Key Object MUST NOT be used. The question is does this propagate up to the Key Container? Open Issues: 19. I think that a section on adding key families would be reasonable. Yes, probably in JWA. I think this would be better here - specifically requirements on what must be added to put something into the alg registry. Jim Thanks again, -- Mike ------=_NextPart_000_022D_01CD2888.3BB121E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From:= = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: = Wednesday, April 25, 2012 9:22 PM
To: Jim Schaad
Cc: = jose@ietf.org
Subject: RE: [jose] Comments on = draft-ietf-jose-json-web-key-01

 

Thanks for the detailed comments, as always, = Jim.  Replies inline…

 

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.= org] On Behalf Of Jim Schaad
Sent: Wednesday, April 11, 2012 1:07 = PM
To: Mike Jones
Cc: jose@ietf.org
Subject: [jose] = Comments on draft-ietf-jose-json-web-key-01

 

<no hat>

 

11.  Should the = text that is in the signature and encryption dealing with adding fields = (urls vs simple names) be included in this section as = well?

 

Are you thinking of the = text about the three classes of names:  reserved, private, and = public?  With the possibility of a registry?  What do people = in the working group think?  I think the chances of this object = being extended are small, especially since we only define one = member.  But then, it’s incredibly hard to predict how a = standard will be used, if successful.  I’d be more prone to = think that extension made sense if the spec defined more than one = member.

 

Yes that was what I was = thinking of.   If we are going to say don’t add things = willy-nilly then we should probably have text saying how to add things = safely.

 

12.  Should there = be an IANA registry for the member names of a container = object.

 

Per 11, I don’t = think so.  I think this case is better handled by the standard JSON = “you can add fields if you understand them” = logic.

 

Cost of a registry is low if we think that the = IETF is going to want to add things then we should  setup the = registry now.

 

JWK Key Object = Format:

 

18.  Should the text dealing with adding = members be present (copied from JWS)?  Is it just the key and not = the entire key set that is to be ignored?

 

Again, are you thinking = the reserved/private/public treatment?  With a registry?  Or = maybe just a registry?  I didn’t find “ignore” in = the draft, so I’m not sure what the second sentence in your = remarks is referring to.

 

The text for Key Object = says that if additional members are present they MUST be understood = – hence if not understood the Key Object MUST NOT be used.  = The question is does this propagate up to the Key = Container?

 

Open = Issues:

 

19.  I think that a section on adding = key families would be reasonable.

 

Yes, probably in = JWA.

 

I think this would be = better here – specifically requirements on what must be added to = put something into the alg registry.

 

 

Jim

 

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

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

 

------=_NextPart_000_022D_01CD2888.3BB121E0-- From phoyer@actividentity.com Thu May 3 07:06: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 F209621F848F for ; Thu, 3 May 2012 07:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0K+bdnZaxV7 for ; Thu, 3 May 2012 07:06:17 -0700 (PDT) Received: from na3sys009aog129.obsmtp.com (na3sys009aog129.obsmtp.com [74.125.149.142]) by ietfa.amsl.com (Postfix) with SMTP id 78CE021F8476 for ; Thu, 3 May 2012 07:06:10 -0700 (PDT) Received: from frhub1.activcard.fr ([92.103.229.143]) by na3sys009aob129.postini.com ([74.125.148.12]) with SMTP ID DSNKT6KQ0f0CzZ/pCvfu5JKcv6+jjiCb/zaI@postini.com; Thu, 03 May 2012 07:06:16 PDT Received: from sur-corp-ex-02.corp.ad.activcard.com (sur-corp-ex-02.corp.ad.activcard.com [192.168.33.40]) by frhub1.activcard.fr (Postfix) with ESMTP id 3C5E4183956; Thu, 3 May 2012 16:06:09 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD2935.D3FD716F" Date: Thu, 3 May 2012 16:05:42 +0200 Message-ID: <5BFE9E473DBFC24CA87F18F29B3F0AC40D5E6CF6@sur-corp-ex-02.corp.ad.activcard.com> In-Reply-To: <50612135-0071-424E-B223-ACBD1606F685@ve7jtb.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [jose] AES-CBC padding Thread-Index: Ac0ou8s2QjQ6hWsfRrCZC6JLKOXJygAeTj+g References: <50612135-0071-424E-B223-ACBD1606F685@ve7jtb.com> From: "Philip Hoyer" To: "John Bradley" , Subject: Re: [jose] AES-CBC padding 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, 03 May 2012 14:06:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD2935.D3FD716F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable John, This is what we did in RFC6030 around the area of padding: =20 For AEC-CBC we used PKCS#5 padding=20 " Figure 6 shows an example that illustrates the encryption of the content of the element using AES-128-CBC and PKCS #5 Padding. The plaintext value of is '3132333435363738393031323334353637383930'. The name of the pre- shared secret is "Pre-shared-key", as set in the element (which is a child element of the element). The value of the encryption key used is '12345678901234567890123456789012'. =20 The IV for the MAC key is '11223344556677889900112233445566', and the IV for the HOTP key is '000102030405060708090a0b0c0d0e0f'. =20 As AES-128-CBC does not provide integrity checks, a keyed MAC is applied to the encrypted value using a MAC key and a MAC algorithm as declared in the element (in our example, "http://www.w3.org/2000/09/xmldsig#hmac-sha1" is used as the algorithm and the value of the MAC key is randomly generated, in our case '1122334455667788990011223344556677889900', and encrypted with the above encryption key). The result of the keyed-MAC computation is placed in the child element of . =20 " =20 and then: =20 " For systems implementing PSKC, it is RECOMMENDED to support AES-128-CBC (with the URI of http://www.w3.org/2001/04/xmlenc#aes128-cbc) and KW-AES128 (with the URI of http://www.w3.org/2001/04/xmlenc#kw-aes128). Please note that KW-AES128 requires that the key to be protected must be a multiple of 8 bytes in length. Hence, if keys of a different length have to be protected, then the usage of the key-wrap algorithm with padding, as described in [RFC5649 ] is RECOMMENDED.=20 =20 " =20 Philip =20 From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of John Bradley Sent: 03 May 2012 00:32 To: jose@ietf.org Subject: [jose] AES-CBC padding =20 JWE is not making a specific padding recommendation for CBC. =20 There are several options including PKCS#5 and the variant used by xmlenc. =20 The other option is to use one of the new CBC modes AES-CBC-CS1. http://csrc.nist.gov/publications/nistpubs/800-38a/addendum-to-nist_sp80 0-38A.pdf =20 =20 I suspect the best thing for interoperability is to use PKCS#5 like CMS. =20 The new modes are more secure, but will be an interoperability problem. =20 Thoughts? =20 John B. ------_=_NextPart_001_01CD2935.D3FD716F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

John,

This is what we did in RFC6030 around the area of = padding:

 

For AEC—CBC we used PKCS#5 padding

Figure 6 shows an example that =
illustrates the encryption of the
   =
content of the <Secret> element using AES-128-CBC and PKCS =
#5
   Padding.  The plaintext =
value of <Secret> is
   =
'3132333435363738393031323334353637383930'.  The name of the =
pre-
   shared secret is =
"Pre-shared-key", as set in the <KeyName> =
element
   (which is a child element of =
the <EncryptionKey> element).  The =
value
   of the encryption key used is =
'12345678901234567890123456789012'.
 
   The IV for the MAC key is =
'11223344556677889900112233445566', and =
the
   IV for the HOTP key is =
'000102030405060708090a0b0c0d0e0f'.
 
   As AES-128-CBC does not provide integrity =
checks, a keyed MAC is
   applied to the =
encrypted value using a MAC key and a MAC algorithm =
as
   declared in the <MACMethod> =
element (in our example,
   "http://www.w3.org/20=
00/09/xmldsig#hmac-sha1" is used as =
the
   algorithm and the value of the MAC =
key is randomly generated, in our
   case =
'1122334455667788990011223344556677889900', and encrypted =
with
   the above encryption key).  =
The result of the keyed-MAC =
computation
   is placed in the =
<ValueMAC> child element of <Secret>.

 

 

and then:

 

For systems = implementing PSKC, it is RECOMMENDED to support

   AES-128-CBC (with the URI of

   http://www.w3.org/20= 01/04/xmlenc#aes128-cbc) and KW-AES128 (with = the

   URI of = http://www.w3.org/200= 1/04/xmlenc#kw-aes128).  Please note = that

   = KW-AES128 requires that the key to be protected must be a multiple = of

   8 = bytes in length.  Hence, if keys of a different length have to = be

   = protected, then the usage of the key-wrap algorithm with padding, = as

   = described in [RFC5649] is RECOMMENDED.

 

 

Philip

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = John Bradley
Sent: 03 May 2012 00:32
To: = jose@ietf.org
Subject: [jose] AES-CBC = padding

 

JWE is not = making a specific padding recommendation for CBC.

 

There are several options including PKCS#5 and the = variant used by xmlenc.

 

The other option is to use one of the new CBC modes = AES-CBC-CS1.

 

I = suspect the best thing for interoperability is to use PKCS#5 like = CMS.

 

The new modes are more secure, but will be an = interoperability problem.

 

Thoughts?

 

John B.

------_=_NextPart_001_01CD2935.D3FD716F-- From ve7jtb@ve7jtb.com Thu May 3 08:10:56 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414C121F8615 for ; Thu, 3 May 2012 08:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h11Dyvr6hNkj for ; Thu, 3 May 2012 08:10:50 -0700 (PDT) Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) by ietfa.amsl.com (Postfix) with ESMTP id 79C4121F85FF for ; Thu, 3 May 2012 08:10:50 -0700 (PDT) Received: by dadz9 with SMTP id z9so2272270dad.39 for ; Thu, 03 May 2012 08:10:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=L/fYHS79LzbGFqsqvj3FNHUUMpfc9v8UEReas2J1x6k=; b=XaDjMm1u9165UODU2bjhv+coc9lzUr1en/+rqO6LocdN/BOhJr+4TGAPrd0M9TpW08 IV7bKcPAaWeAoJlQvxhbuEtQAzw8LABRPDUt2dK3qUR3UPi2KZn1mZtEvLaVf1pA8rFu bSno4rqRtqZu2Q/bupOAMScnnudM9Wc5ZTGXhy/xr8gRC6eSsLQZIVldy8V4yuiKANhK POKVJe4pmez1xl1aE2wftjgBCCOs2zdjNwbGnFB4n8pX7W6hYkSPx/W4xJ7GRkNKk4yO RyhxgPDUsaMxOOjtnaIiJbHF6/s1vtAtecBDhRsPurpuF3DpNmcUPrWOeY1fDpfsf3U4 PwCQ== Received: by 10.68.213.162 with SMTP id nt2mr6499203pbc.31.1336057850113; Thu, 03 May 2012 08:10:50 -0700 (PDT) Received: from [10.0.246.138] ([209.118.182.66]) by mx.google.com with ESMTPS id sr5sm970900pbc.57.2012.05.03.08.10.45 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 May 2012 08:10:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_4407F509-9632-491F-A9B3-1C86A56C7D15" From: John Bradley In-Reply-To: <5BFE9E473DBFC24CA87F18F29B3F0AC40D5E6CF6@sur-corp-ex-02.corp.ad.activcard.com> Date: Thu, 3 May 2012 08:10:45 -0700 Message-Id: References: <50612135-0071-424E-B223-ACBD1606F685@ve7jtb.com> <5BFE9E473DBFC24CA87F18F29B3F0AC40D5E6CF6@sur-corp-ex-02.corp.ad.activcard.com> To: "Philip Hoyer" X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlscRYf2XJYsk5Lre51q3RjnItZumyddrEUvea9gzTzMqWvlMFT6rqFAq+s6TknAuwGSZv6 Cc: jose@ietf.org Subject: Re: [jose] AES-CBC padding 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, 03 May 2012 15:10:56 -0000 --Apple-Mail=_4407F509-9632-491F-A9B3-1C86A56C7D15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks an other good datapoint for PKCS #5. I suspect that is the most reasonable option, but wanted to solicit = other opinions before getting getting the clarification added. People building librarys need a decision shortly otherwise it will not = interop. John B. On 2012-05-03, at 7:05 AM, Philip Hoyer wrote: > John, > This is what we did in RFC6030 around the area of padding: > =20 > For AEC=97CBC we used PKCS#5 padding > =93 > Figure 6 shows an example that illustrates the encryption of the > content of the element using AES-128-CBC and PKCS #5 > Padding. The plaintext value of is > '3132333435363738393031323334353637383930'. The name of the pre- > shared secret is "Pre-shared-key", as set in the element > (which is a child element of the element). The = value > of the encryption key used is '12345678901234567890123456789012'. > =20 > The IV for the MAC key is '11223344556677889900112233445566', and = the > IV for the HOTP key is '000102030405060708090a0b0c0d0e0f'. > =20 > As AES-128-CBC does not provide integrity checks, a keyed MAC is > applied to the encrypted value using a MAC key and a MAC algorithm = as > declared in the element (in our example, > "http://www.w3.org/2000/09/xmldsig#hmac-sha1" is used as the > algorithm and the value of the MAC key is randomly generated, in = our > case '1122334455667788990011223344556677889900', and encrypted with > the above encryption key). The result of the keyed-MAC computation > is placed in the child element of . > =20 > =94 > =20 > and then: > =20 > =93 > For systems implementing PSKC, it is RECOMMENDED to support > AES-128-CBC (with the URI of > http://www.w3.org/2001/04/xmlenc#aes128-cbc) and KW-AES128 (with = the > URI of http://www.w3.org/2001/04/xmlenc#kw-aes128). Please note = that > KW-AES128 requires that the key to be protected must be a multiple = of > 8 bytes in length. Hence, if keys of a different length have to be > protected, then the usage of the key-wrap algorithm with padding, = as > described in [RFC5649] is RECOMMENDED. > =20 > =93 > =20 > Philip > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of John Bradley > Sent: 03 May 2012 00:32 > To: jose@ietf.org > Subject: [jose] AES-CBC padding > =20 > JWE is not making a specific padding recommendation for CBC. > =20 > There are several options including PKCS#5 and the variant used by = xmlenc. > =20 > The other option is to use one of the new CBC modes AES-CBC-CS1. > = http://csrc.nist.gov/publications/nistpubs/800-38a/addendum-to-nist_sp800-= 38A.pdf > =20 > I suspect the best thing for interoperability is to use PKCS#5 like = CMS. > =20 > The new modes are more secure, but will be an interoperability = problem. > =20 > Thoughts? > =20 > John B. --Apple-Mail=_4407F509-9632-491F-A9B3-1C86A56C7D15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Thanks an other good datapoint for PKCS = #5.

I suspect that is the most reasonable option, but = wanted to solicit other opinions before getting getting the = clarification added.

People building librarys = need a decision shortly otherwise it will not = interop.

John B.

On = 2012-05-03, at 7:05 AM, Philip Hoyer wrote:

This = is what we did in RFC6030 around the area of = padding:
For = AEC=97CBC we used PKCS#5 padding
=93
   content of the <Secret> element =
using AES-128-CBC and PKCS #5
   =
'3132333435363738393031323334353637383930'.  The name of the =
pre-
   shared secret is "Pre-shared-key", as set =
in the <KeyName> element
   (which is a =
child element of the <EncryptionKey> element).  The =
value
   of the encryption key used is =
'12345678901234567890123456789012'.
   The IV for the MAC key is =
'11223344556677889900112233445566', and the
   As AES-128-CBC does not =
provide integrity checks, a keyed MAC is
   declared in the =
<MACMethod> element (in our example,
   algorithm and the value of the MAC key is =
randomly generated, in our
   case =
'1122334455667788990011223344556677889900', and encrypted =
with
   the above encryption key).  The =
result of the keyed-MAC computation
and =
then:
For systems implementing PSKC, it is = RECOMMENDED to support
   = AES-128-CBC (with the URI of
   described in [RFC5649] is = RECOMMENDED.
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org= ] On Behalf Of John = Bradley
Sent: 03 May 2012 = 00:32
To: jose@ietf.org
Subject: [jose] AES-CBC = padding
JWE is not making a specific = padding recommendation for CBC.
 
There are several options including PKCS#5 and the = variant used by xmlenc.
 
The other option is to use one of the new CBC modes = AES-CBC-CS1.

<= /body>= --Apple-Mail=_4407F509-9632-491F-A9B3-1C86A56C7D15-- From Michael.Jones@microsoft.com Fri May 4 14:58: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 5D61721F84D8 for ; Fri, 4 May 2012 14:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.916 X-Spam-Level: X-Spam-Status: No, score=-3.916 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96OdSdKbzAk6 for ; Fri, 4 May 2012 14:58:20 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6E82721F84E6 for ; Fri, 4 May 2012 14:58:19 -0700 (PDT) Received: from mail57-db3-R.bigfish.com (10.3.81.236) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Fri, 4 May 2012 21:58:07 +0000 Received: from mail57-db3 (localhost [127.0.0.1]) by mail57-db3-R.bigfish.com (Postfix) with ESMTP id 5BB7830018A; Fri, 4 May 2012 21:58:07 +0000 (UTC) X-SpamScore: -38 X-BigFish: VS-38(zz9371I936eKc85fh1b0bM98dKzz1202hzz1033IL8275bh30d1K8275dh5eeeKz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail57-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail57-db3 (localhost.localdomain [127.0.0.1]) by mail57-db3 (MessageSwitch) id 1336168685782101_2449; Fri, 4 May 2012 21:58:05 +0000 (UTC) Received: from DB3EHSMHS012.bigfish.com (unknown [10.3.81.253]) by mail57-db3.bigfish.com (Postfix) with ESMTP id AE2E62A0059; Fri, 4 May 2012 21:58:05 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS012.bigfish.com (10.3.87.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 4 May 2012 21:58:03 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.230]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0298.005; Fri, 4 May 2012 21:57:57 +0000 From: Mike Jones To: John Bradley , Philip Hoyer Thread-Topic: [jose] AES-CBC padding Thread-Index: AQHNKLvR9D1CmAe3W0mCphU/RVB+CZa4Gi8AgAASLICAAgOJIA== Date: Fri, 4 May 2012 21:57:56 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943664C03C5@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <50612135-0071-424E-B223-ACBD1606F685@ve7jtb.com> <5BFE9E473DBFC24CA87F18F29B3F0AC40D5E6CF6@sur-corp-ex-02.corp.ad.activcard.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_4E1F6AAD24975D4BA5B1680429673943664C03C5TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] AES-CBC padding 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, 04 May 2012 21:58:22 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943664C03C5TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, I intend to specify the use of PKCS #5 padding for ACS-CBC in the next= JWE spec unless further discussion results in consensus for another decisi= on. My thanks to Edmund Jay and John Bradley for identifying the issue and anal= yzing potential solutions. -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Joh= n Bradley Sent: Thursday, May 03, 2012 8:11 AM To: Philip Hoyer Cc: jose@ietf.org Subject: Re: [jose] AES-CBC padding Thanks an other good datapoint for PKCS #5. I suspect that is the most reasonable option, but wanted to solicit other o= pinions before getting getting the clarification added. People building librarys need a decision shortly otherwise it will not inte= rop. John B. On 2012-05-03, at 7:05 AM, Philip Hoyer wrote: John, This is what we did in RFC6030 around the area of padding: For AEC-CBC we used PKCS#5 padding " Figure 6 shows an example that illustrates the encryption of the content of the element using AES-128-CBC and PKCS #5 Padding. The plaintext value of is '3132333435363738393031323334353637383930'. The name of the pre- shared secret is "Pre-shared-key", as set in the element (which is a child element of the element). The value of the encryption key used is '12345678901234567890123456789012'. The IV for the MAC key is '11223344556677889900112233445566', and the IV for the HOTP key is '000102030405060708090a0b0c0d0e0f'. As AES-128-CBC does not provide integrity checks, a keyed MAC is applied to the encrypted value using a MAC key and a MAC algorithm as declared in the element (in our example, "http://www.w3.org/2000/09/xmldsig#hmac-sha1" is used as the algorithm and the value of the MAC key is randomly generated, in our case '1122334455667788990011223344556677889900', and encrypted with the above encryption key). The result of the keyed-MAC computation is placed in the child element of . " and then: " For systems implementing PSKC, it is RECOMMENDED to support AES-128-CBC (with the URI of http://www.w3.org/2001/04/xmlenc#aes128-cbc) and KW-AES128 (with the URI of http://www.w3.org/2001/04/xmlenc#kw-aes128). Please note that KW-AES128 requires that the key to be protected must be a multiple of 8 bytes in length. Hence, if keys of a different length have to be protected, then the usage of the key-wrap algorithm with padding, as described in [RFC5649] is RECOMMENDE= D. " Philip From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of John Brad= ley Sent: 03 May 2012 00:32 To: jose@ietf.org Subject: [jose] AES-CBC padding JWE is not making a specific padding recommendation for CBC. There are several options including PKCS#5 and the variant used by xmlenc. The other option is to use one of the new CBC modes AES-CBC-CS1. http://csrc.nist.gov/publications/nistpubs/800-38a/addendum-to-nist_sp800-3= 8A.pdf I suspect the best thing for interoperability is to use PKCS#5 like CMS. The new modes are more secure, but will be an interoperability problem. Thoughts? John B. --_000_4E1F6AAD24975D4BA5B1680429673943664C03C5TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI, I intend to specify = the use of PKCS #5 padding for ACS-CBC in the next JWE spec unless further = discussion results in consensus for another decision.

 <= /p>

My thanks to Edmund Jay a= nd John Bradley for identifying the issue and analyzing potential solutions= .

 <= /p>

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

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of John Bradley
Sent: Thursday, May 03, 2012 8:11 AM
To: Philip Hoyer
Cc: jose@ietf.org
Subject: Re: [jose] AES-CBC padding

 

Thanks an other good datapoint for PKCS #5.

 

I suspect that is the most reasonable option, but wa= nted to solicit other opinions before getting getting the clarification add= ed.

 

People building librarys need a decision shortly oth= erwise it will not interop.

 

John B.

 

On 2012-05-03, at 7:05 AM, Philip Hoyer wrote:<= /o:p>



John,

This is wh= at we did in RFC6030 around the area of padding:

 

For AEC= 212;CBC we used PKCS#5 padding

Figure 6 shows an example that illustrates the en=
cryption of the
   content of the <Secret> elemen=
t using AES-128-CBC and PKCS #5
   Padding.  The plaintext value o=
f <Secret> is
   '31323334353637383930313233343536373=
83930'.  The name of the pre-
   shared secret is "Pre-shared-ke=
y", as set in the <KeyName> element
   (which is a child element of the <=
;EncryptionKey> element).  The value
   of the encryption key used is '12345=
678901234567890123456789012'.
 
   The IV for the MAC key is '112233445=
56677889900112233445566', and the
   IV for the HOTP key is '000102030405=
060708090a0b0c0d0e0f'.
 
   As AES-128-CBC does not provide inte=
grity checks, a keyed MAC is
   applied to the encrypted value using=
 a MAC key and a MAC algorithm as
   declared in the <MACMethod> el=
ement (in our example,
   "http://www.w3.org/2000/09/xmldsig#hmac-sha1&q=
uot; is used as the
   algorithm and the value of the MAC k=
ey is randomly generated, in our
   case '112233445566778899001122334455=
6677889900', and encrypted with
   the above encryption key).  The=
 result of the keyed-MAC computation
   is placed in the <ValueMAC> ch=
ild element of <Secret>.

 

 

and then:<= /span>

 

For systems implementing PSKC, it is RECOMM= ENDED to support

   AES-128-CBC (with the URI of

   http://www.w3.org/2001/04/xmlenc#aes128-cbc) and KW-AES128 (with the

   URI of http://www.w3.org/2001/04/xmlenc#kw-aes128).  Please note that

   KW-AES128 requires that the ke= y to be protected must be a multiple of

   8 bytes in length.  Hence= , if keys of a different length have to be=

   protected, then the usage of t= he key-wrap algorithm with padding, as

   described in [RFC5649] is RECOMMENDED.

 

 

Philip

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org]=  On Behalf Of John Bradl= ey
Sent: 03 May 2012 = 00:32
To: jose@ietf.org
Subject: [jose] AE= S-CBC padding

 

JWE is not making a specific pa= dding recommendation for CBC.

 

There are several options inclu= ding PKCS#5 and the variant used by xmlenc.

 

The other option is to use one = of the new CBC modes AES-CBC-CS1.

 

I suspect the best thing for in= teroperability is to use PKCS#5 like CMS.

 

The new modes are more secure, = but will be an interoperability problem.

 

Thoughts?

 

John B.

 

--_000_4E1F6AAD24975D4BA5B1680429673943664C03C5TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Fri May 4 15:16: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 C9F2721F84A0 for ; Fri, 4 May 2012 15:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8N-Xc+cNA92 for ; Fri, 4 May 2012 15:16:31 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 0328421F8495 for ; Fri, 4 May 2012 15:16:28 -0700 (PDT) Received: from mail36-am1-R.bigfish.com (10.3.201.240) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Fri, 4 May 2012 22:16:17 +0000 Received: from mail36-am1 (localhost [127.0.0.1]) by mail36-am1-R.bigfish.com (Postfix) with ESMTP id 14EA2603CE; Fri, 4 May 2012 22:16:17 +0000 (UTC) X-SpamScore: -20 X-BigFish: VS-20(zzc85fhzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail36-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail36-am1 (localhost.localdomain [127.0.0.1]) by mail36-am1 (MessageSwitch) id 1336169775230588_23410; Fri, 4 May 2012 22:16:15 +0000 (UTC) Received: from AM1EHSMHS014.bigfish.com (unknown [10.3.201.251]) by mail36-am1.bigfish.com (Postfix) with ESMTP id 27D544E00FF; Fri, 4 May 2012 22:16:15 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS014.bigfish.com (10.3.207.152) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 4 May 2012 22:16:14 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.230]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0298.005; Fri, 4 May 2012 22:16:21 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: AES-GCM in JWE Thread-Index: Ac0qQ4jATDK6eCTDTVycis/kEfLJeQ== Date: Fri, 4 May 2012 22:16:21 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943664C0440@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.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943664C0440TK5EX14MBXC283r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Edmund Jay Subject: [jose] AES-GCM in JWE 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, 04 May 2012 22:16:32 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943664C0440TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the current JWE spec, AES Galois Counter Mode (GCM) is treated quite differently= than other algorithms because it provides an integrated integrity check, h= owever some of the unique properties of GCM are not utilized. Having more = deeply investigated the actual GCM specification (NIST SP800-38D) and imple= mentations, I now believe that its treatment can and should be much more li= ke the other algorithms in JWE. Specifically, the current JWE spec is sile= nt on how to use these properties GCM: * GCM includes an "additional authenticated data" parameter, in addi= tion to the plaintext * GCM specifies a preferred IV length of 96 bits (12 bytes) * GCM has a separate "authentication tag" output, distinct from the = ciphertext output In the next version of the JWE spec, I plan to specify that the GCM "additi= onal authenticated data" input for GCM be the concatenation of the Encoded = JWE Header, a period ('.') character, and the Encoded JWE Encrypted Key. T= his will then include these values in the GCM integrity value calculation, = just as they are included in the separate integrity value calculation of = JWE for non-AEAD algorithms (thus securing the header and encrypted key val= ues). Likewise, in the next version of the JWE spec, I plan to specify that the G= CM "authentication tag" output be base64url encoded and used as the Encoded= JWE Integrity Value (the fourth field of the JWE), just as the separately = computed integrity value is used as the Encoded JWE Integrity Value for non= -AEAD algorithms. Finally, in the next version of the JWE spec, I plan to specify that a 96 b= it IV be used with GCM. This will make the treatment of GCM substantially more parallel to non-AEAD= algorithms and will use the "additional authenticated data" feature of GCM= to secure the encryption parameters, as I believe was its intended use. -- Mike P.S. My thanks to Edmund Jay for his deep dive into the particulars of GCM= in the course of his JWE implementation work. --_000_4E1F6AAD24975D4BA5B1680429673943664C0440TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the current JWE spec, AES Galois Counter Mode (GCM) is treated quite differently th= an other algorithms because it provides an integrated integrity check, howe= ver some of the unique properties of GCM are not utilized.  Having mor= e deeply investigated the actual GCM specification (NIST SP800-38D) and implementations, I now believe that its treatment can and should b= e much more like the other algorithms in JWE.  Specifically, the current JWE spec is silent on how to use these properties GCM:

·        GCM includes an “additional authentica= ted data” parameter, in addition to the plaintext

·        GCM specifies a preferred IV length of 96 bi= ts (12 bytes)

·        GCM has a separate “authentication tag= ” output, distinct from the ciphertext output

 

In the next version of the JWE spec, I plan to speci= fy that the GCM “additional authenticated data” input for GCM b= e the concatenation of the Encoded JWE Header, a period ('.') character, an= d the Encoded JWE Encrypted Key.  This will then include these values in the GCM integrity value calculation, just as they = are included in the separate integrity value calculation of JWE for non-AEAD algorithms (thus securi= ng the header and encrypted key values).

 

Likewise, in the next version of the JWE spec, I pla= n to specify that the GCM “authentication tag” output be base64= url encoded and used as the Encoded JWE Integrity Value (t= he fourth field of the JWE), just as the separately computed integrity valu= e is used as the Encoded JWE Integrity Value for non-AEAD algorithms.<= /o:p>

&n= bsp;

Finally= , in the next version of the JWE spec, I plan to specify that a 96 bit IV b= e used with GCM.

&n= bsp;

This wi= ll make the treatment of GCM substantially more parallel to non-AEAD algori= thms and will use the “additional authenticated data” feature o= f GCM to secure the encryption parameters, as I believe was its intended use.

&n= bsp;

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

&n= bsp;

P.S.&nb= sp; My thanks to Edmund Jay for his deep dive into the particulars of GCM i= n the course of his JWE implementation work.

&n= bsp;

--_000_4E1F6AAD24975D4BA5B1680429673943664C0440TK5EX14MBXC283r_-- From sakimura@gmail.com Fri May 4 16:01:56 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DED721F853C for ; Fri, 4 May 2012 16:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pkCTwUiLP6p for ; Fri, 4 May 2012 16:01:55 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9E83921F8539 for ; Fri, 4 May 2012 16:01:52 -0700 (PDT) Received: by bkty8 with SMTP id y8so3096802bkt.31 for ; Fri, 04 May 2012 16:01:51 -0700 (PDT) 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=O2zuxILYmVw5W/rc0yurNVhqKPof5BVHVTKEs3Rn6Gc=; b=M6y4X/sWcDzDsT+3L7DZsswI0/kxWhNL36Zsb799IZWkf3KNG/W8tCdwGL6NF7KAkY hSYe8iBLEnFedolOSuUEKwrraIKRvxYxIR2GzSJ63tn0tfsOcQnBDgRm7D3UTw/D5Ff5 bnMIQ7scidE5gU/4XiipqLqvgYKwfAb+yhorg5ksYIr37pAWYvE1COff9nN1ko7Ue0WW pHwGH82wrdlWLMN0v/PA428kJVDjfH2ChvAmgxGlvwkKoiGgLspWUqVQjKQnx0aDxHhQ BxOzPXKhDp1BPmQTQitj9jGI3Srqvom6AedBqaP+IcD2aviakk4LCX/FbET8i+IMxlum fMOA== Received: by 10.204.151.81 with SMTP id b17mr2732690bkw.52.1336172511686; Fri, 04 May 2012 16:01:51 -0700 (PDT) References: <4E1F6AAD24975D4BA5B1680429673943664C0440@TK5EX14MBXC283.redmond.corp.microsoft.com> From: Nat Sakimura In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943664C0440@TK5EX14MBXC283.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) Date: Fri, 4 May 2012 16:00:11 -0700 Message-ID: <-928519897122090382@unknownmsgid> To: Mike Jones Content-Type: multipart/alternative; boundary=0015175cabaeeaef1504bf3de7cf Cc: "jose@ietf.org" , Edmund Jay Subject: Re: [jose] AES-GCM in JWE 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, 04 May 2012 23:01:56 -0000 --0015175cabaeeaef1504bf3de7cf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1 =3Dnat via iPhone On 2012/05/04, at 15:16, Mike Jones wrote: In the current JWE spec, AES Galois Counter Mode (GCM) is treated quite differently than other algorithms because it provides an integrated integrity check, however some of the unique properties of GCM are not utilized. Having more deeply investigated the actual GCM specification (NIST SP800-38D) and implementations, I now believe that its treatment can and should be much more like the other algorithms in JWE. Specifically, the current JWE spec is silent on how to use these properties GCM: =B7 GCM includes an =93additional authenticated data=94 parameter, i= n addition to the plaintext =B7 GCM specifies a preferred IV length of 96 bits (12 bytes) =B7 GCM has a separate =93authentication tag=94 output, distinct fro= m the ciphertext output In the next version of the JWE spec, I plan to specify that the GCM =93additional authenticated data=94 input for GCM be the concatenation of t= he Encoded JWE Header, a period ('.') character, and the Encoded JWE Encrypted Key. This will then include these values in the GCM integrity value calculation, just as they are included in the separate integrity value calculationof JWE for non-AEAD algorithms (thus securing the header and encrypted key values). Likewise, in the next version of the JWE spec, I plan to specify that the GCM =93authentication tag=94 output be base64url encoded and used as the En= coded JWE Integrity Value (the fourth field of the JWE), just as the separately computed integrity value is used as the Encoded JWE Integrity Value for non-AEAD algorithms. Finally, in the next version of the JWE spec, I plan to specify that a 96 bit IV be used with GCM. This will make the treatment of GCM substantially more parallel to non-AEAD algorithms and will use the =93additional authenticated data=94 feature of = GCM to secure the encryption parameters, as I believe was its intended use. -- Mike P.S. My thanks to Edmund Jay for his deep dive into the particulars of GCM in the course of his JWE implementation work. _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --0015175cabaeeaef1504bf3de7cf Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
+1=A0

=3Dnat via i= Phone

On 2012/05/04, at 15:16, Mike Jones <Michael.Jones@microsoft.com> wrote:<= br>

In the current JWE spec, AES Galois Counter Mode (GCM) is treated quite differently th= an other algorithms because it provides an integrated integrity check, howe= ver some of the unique properties of GCM are not utilized.=A0 Having more d= eeply investigated the actual GCM specification (NIST SP800-38D) and implementations, I now believe that its treatment can and should b= e much more like the other algorithms in JWE.=A0 Specifically, the current JWE spec is silent on how to use these properties GCM:

=B7=A0=A0=A0= =A0=A0=A0=A0 GCM includes an =93additional authenticated data=94 pa= rameter, in addition to the plaintext

=B7=A0=A0=A0= =A0=A0=A0=A0 GCM specifies a preferred IV length of 96 bits (12 byt= es)

=B7=A0=A0=A0= =A0=A0=A0=A0 GCM has a separate =93authentication tag=94 output, di= stinct from the ciphertext output

=A0

In the next version of the JWE spec, I plan to speci= fy that the GCM =93additional authenticated data=94 input for GCM be the co= ncatenation of the Encoded JWE Header, a period ('.') character, an= d the Encoded JWE Encrypted Key.=A0 This will then include these values in the GCM integrity value calculation, just as they = are included in the separate integrity value calculation of JWE for non-AEAD algorithms (thus securi= ng the header and encrypted key values).

=A0

Likewise, in the next version of the JWE spec, I pla= n to specify that the GCM =93authentication tag=94 output be base64url enco= ded and used as the Encoded JWE Integrity Value (t= he fourth field of the JWE), just as the separately computed integrity valu= e is used as the Encoded JWE Integrity Value for non-AEAD algorithms.

=A0

Finally= , in the next version of the JWE spec, I plan to specify that a 96 bit IV b= e used with GCM.

=A0

This wi= ll make the treatment of GCM substantially more parallel to non-AEAD algori= thms and will use the =93additional authenticated data=94 feature of GCM to= secure the encryption parameters, as I believe was its intended use.

=A0

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

=A0

P.S.=A0= My thanks to Edmund Jay for his deep dive into the particulars of GCM in t= he course of his JWE implementation work.

=A0

___________________= ____________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mai= lman/listinfo/jose
--0015175cabaeeaef1504bf3de7cf-- From jimsch@augustcellars.com Fri May 4 20:38:02 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2DD321E8036 for ; Fri, 4 May 2012 20:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMJgLfoV9tlK for ; Fri, 4 May 2012 20:38:02 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7464721E8034 for ; Fri, 4 May 2012 20:38:02 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id D9A772CA26 for ; Fri, 4 May 2012 20:38:01 -0700 (PDT) From: "Jim Schaad" To: Date: Fri, 4 May 2012 20:36:56 -0700 Message-ID: <002301cd2a70$55c88200$01598600$@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: Ac0qX58KcGERjMN0RUKDOQ2BvA9oBg== Content-Language: en-us Subject: [jose] Signing and Encryption algorithm X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 03:38:03 -0000 I want to see if there is room for a discussion about the inputs used for signature (and encryption?) computations. The current algorithm was designed with a specific mechanism in mind. It is not clear that with the new serialization methods that have been suggested that the current steps to sign are the best. The current code computes the signature hash as HASH( BASE64( TEXT( header )) || "." || BASE64 ( body )) >From what I know and can guess, there are three reasons for doing it this way. 1. We need to make sure that nothing can move the body to the headers and vice versa 2. There is a strong desire to avoid canonicalization of the inputs and base64 is the method chosen to do this 3. We already have the base64 values - so it makes sense to use them. I would propose to change the hash computation to be HASH( TEXT( header ) || body ) 1. There are no issues with the migration of data across the concatenation operator. Since the header is required to be a well-defined JSON object, it is always possible to find the exact end of the JSON object in order to separate the header and the body fields. The only requirement would be that the creation code would need to state that there are no trailing characters following the closing curly brace. 2. We do want to avoid canonicalization; however there is no effective difference between hashing the data before or after applying the base64 data string. If one looks at what ALTO wants to do, they think that they do not need to base64 encode the body of the message. It will be transported unchanged by http(s). The only problem would be if the application were to read in and then write out the JSON data. That might change the bytes, but the same issue would be true if you base64 encoded the byte stream as you wrote it out. 3. In some cases the base64 values are not already present and would need to be created as part of the processing. Jim From sakimura@gmail.com Sat May 5 08:09: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 E8A3521F859A for ; Sat, 5 May 2012 08:09: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CdNW3nh8gJ5 for ; Sat, 5 May 2012 08:09:47 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B7E4621F8598 for ; Sat, 5 May 2012 08:09:46 -0700 (PDT) Received: by bkty8 with SMTP id y8so3416895bkt.31 for ; Sat, 05 May 2012 08:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wL2imK0sxb/l0DGEdVueNmzK3W7F0HAqvGVaqO8gPBs=; b=GlGzP94XtflzG3TUPZ2qe6QCcpAiv37BfxmAn7Qfa6qbO2uDJ3e8dWLR4NOB598hAE WHqsitC/VQLTIacBp4M6dMQXXZHjmysRFf358dOfKZtAh9tmKZSkyCwy7hzDAZKz4zg+ P0CNpor9Xq1uLD/afHwXymlEEJbdaXU/5lJ1Var49Wf3JojyQdsDpRAfSfIu4XuXYnnn tDHPqH/Pe0iZ71ygWqg51LR4WfMoI8QjbXzglQrpuq2dVEVqvxqKbRWI5KRZsZS6HRsX yEyHiZ3HO0qNH8uIOqoaSi6KWx9GW9daF6jpmkUhLQk0iNFnxhrnipAMwQPrbP16iMmV SX9Q== MIME-Version: 1.0 Received: by 10.204.154.18 with SMTP id m18mr3621280bkw.23.1336230581722; Sat, 05 May 2012 08:09:41 -0700 (PDT) Received: by 10.204.240.143 with HTTP; Sat, 5 May 2012 08:09:41 -0700 (PDT) In-Reply-To: <002301cd2a70$55c88200$01598600$@augustcellars.com> References: <002301cd2a70$55c88200$01598600$@augustcellars.com> Date: Sat, 5 May 2012 08:09:41 -0700 Message-ID: From: Nat Sakimura To: Jim Schaad Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: jose@ietf.org Subject: Re: [jose] Signing and Encryption algorithm X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 15:09:48 -0000 Hi Jim, Thanks for pointing it out. I am not as confident as you are on getting the body unchanged through all the transport and processing environment. True, it may be fine with https, but we are not just targeting that. It may go through various media including offline storage and by the time the JWE processor gets to the data, it may have gone through bunch of frameworks that may touch the whitespaces and eol chars that may end up requiring us to do the canonicalization. Instead of risking that, I would prefer staying on the safer side albeit it may incur a little more overhead. The canonicalization is the primary thing that we want to avoid. Thoughts? Nat Sakimura On Fri, May 4, 2012 at 8:36 PM, Jim Schaad wrote= : > > > I want to see if there is room for a discussion about the inputs used for > signature (and encryption?) computations. =A0The current algorithm was > designed with a specific mechanism in mind. =A0It is not clear that with = the > new serialization methods that have been suggested that the current steps= to > sign are the best. > > The current code computes the signature hash as > > HASH( BASE64( TEXT( header )) || "." || BASE64 ( body )) > > From what I know and can guess, there are three reasons for doing it this > way. > > 1. =A0We need to make sure that nothing can move the body to the headers = and > vice versa > 2. =A0There is a strong desire to avoid canonicalization of the inputs an= d > base64 is the method chosen to do this > 3. =A0We already have the base64 values - so it makes sense to use them. > > I would propose to change the hash computation to be > > HASH( TEXT( header ) || body ) > > 1. =A0There are no issues with the migration of data across the concatena= tion > operator. =A0Since the header is required to be a well-defined JSON objec= t, it > is always possible to find the exact end of the JSON object in order to > separate the header and the body fields. =A0The only requirement would be= that > the creation code would need to state that there are no trailing characte= rs > following the closing curly brace. > > 2. =A0We do want to avoid canonicalization; however there is no effective > difference between hashing the data before or after applying the base64 d= ata > string. =A0If one looks at what ALTO wants to do, they think that they do= not > need to base64 encode the body of the message. =A0It will be transported > unchanged by http(s). =A0The only problem would be if the application wer= e to > read in and then write out the JSON data. =A0That might change the bytes,= but > the same issue would be true if you base64 encoded the byte stream as you > wrote it out. > > 3. =A0In some cases the base64 values are not already present and would n= eed > to be created as part of the processing. > > Jim > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en From jimsch@augustcellars.com Sat May 5 08:45: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 3FA1121F85E7 for ; Sat, 5 May 2012 08:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VB94himExFAL for ; Sat, 5 May 2012 08:45:43 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 6B16021F85E4 for ; Sat, 5 May 2012 08:45:43 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id AFAA52CA80; Sat, 5 May 2012 08:45:42 -0700 (PDT) From: "Jim Schaad" To: "'Nat Sakimura'" References: <002301cd2a70$55c88200$01598600$@augustcellars.com> In-Reply-To: Date: Sat, 5 May 2012 08:44:41 -0700 Message-ID: <004301cd2ad5$fd061f90$f7125eb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFFrMSCGEOV2uKMrNzEk2QJWLgndwGVQmUvl72mobA= Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] Signing and Encryption algorithm X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 15:45:44 -0000 I am not suggesting that it should not be encoded as base64 for = transport if you are in a situation where it might be modified. I think that how the transport is done should be left up to the protocol using JOSE and not specified by JOSE. For the JWT serialization method, base64 will = definitely be used. Jim > -----Original Message----- > From: Nat Sakimura [mailto:sakimura@gmail.com] > Sent: Saturday, May 05, 2012 8:10 AM > To: Jim Schaad > Cc: jose@ietf.org > Subject: Re: [jose] Signing and Encryption algorithm >=20 > Hi Jim, >=20 > Thanks for pointing it out. >=20 > I am not as confident as you are on getting the body unchanged through = all > the transport and processing environment. True, it may be fine with = https, > but we are not just targeting that. It may go through various media including > offline storage and by the time the JWE processor gets to the data, it = may > have gone through bunch of frameworks that may touch the whitespaces > and eol chars that may end up requiring us to do the canonicalization. Instead > of risking that, I would prefer staying on the safer side albeit it = may incur a > little more overhead. The canonicalization is the primary thing that = we want > to avoid. >=20 > Thoughts? >=20 > Nat Sakimura >=20 > On Fri, May 4, 2012 at 8:36 PM, Jim Schaad > wrote: > > > > > > I want to see if there is room for a discussion about the inputs = used > > for signature (and encryption?) computations. =A0The current = algorithm > > was designed with a specific mechanism in mind. =A0It is not clear = that > > with the new serialization methods that have been suggested that the > > current steps to sign are the best. > > > > The current code computes the signature hash as > > > > HASH( BASE64( TEXT( header )) || "." || BASE64 ( body )) > > > > From what I know and can guess, there are three reasons for doing it > > this way. > > > > 1. =A0We need to make sure that nothing can move the body to the = headers > > and vice versa 2. =A0There is a strong desire to avoid = canonicalization > > of the inputs and > > base64 is the method chosen to do this 3. =A0We already have the = base64 > > values - so it makes sense to use them. > > > > I would propose to change the hash computation to be > > > > HASH( TEXT( header ) || body ) > > > > 1. =A0There are no issues with the migration of data across the > > concatenation operator. =A0Since the header is required to be a > > well-defined JSON object, it is always possible to find the exact = end > > of the JSON object in order to separate the header and the body > > fields. =A0The only requirement would be that the creation code = would > > need to state that there are no trailing characters following the closing curly > brace. > > > > 2. =A0We do want to avoid canonicalization; however there is no > > effective difference between hashing the data before or after = applying > > the base64 data string. =A0If one looks at what ALTO wants to do, = they > > think that they do not need to base64 encode the body of the = message. > > It will be transported unchanged by http(s). =A0The only problem = would > > be if the application were to read in and then write out the JSON > > data. =A0That might change the bytes, but the same issue would be = true > > if you base64 encoded the byte stream as you wrote it out. > > > > 3. =A0In some cases the base64 values are not already present and = would > > need to be created as part of the processing. > > > > Jim > > > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 >=20 > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en From ve7jtb@ve7jtb.com Sat May 5 11:32:56 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9742E21F85FC for ; Sat, 5 May 2012 11:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bu3KZdVTOcdc for ; Sat, 5 May 2012 11:32:55 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD2621F85FB for ; Sat, 5 May 2012 11:32:55 -0700 (PDT) Received: by yhq56 with SMTP id 56so4256982yhq.31 for ; Sat, 05 May 2012 11:32:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=BsTiM3PKEIGhh960wyrSBSL8eSORPvIB7ZF4S7vIj6Y=; b=Fbqwe4Pe1xFhoWc7De6IkAbj7TYZj5lUq1YzOSX2nZPtu8Mqhs/zDHW8B63Vyf2cU8 ZbvDdkKKm5hF8VQzCaAV6YGmJm/lZovWSOMjy7Bho4RukCBeFtzBtxLdMPocGgJDWfzC gvRV2lEq3rJzUyxd/XnsfJO5w5nJZnFratYbReSvrSgJ2gEnK6ODKejFUB5Iv4AX+/sb v52605Hc6iyF7tXmg2ch6d8YOg6IKjaxQJKuA64vqvnxVTigtHM/UP+pRcbUiMFOMXdY P0erOlgSjhDukGaYJgtrX3Y/aC0f/9eBRNTAeQwOy7rIGFELPB+jE0nmtjLEBHrHnOGp tXLQ== Received: by 10.236.124.73 with SMTP id w49mr13176916yhh.31.1336242295954; Sat, 05 May 2012 11:24:55 -0700 (PDT) Received: from [10.0.0.112] ([216.9.106.106]) by mx.google.com with ESMTPS id a30sm56660866yhe.18.2012.05.05.11.24.49 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 05 May 2012 11:24:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: John Bradley In-Reply-To: <004301cd2ad5$fd061f90$f7125eb0$@augustcellars.com> Date: Sat, 5 May 2012 11:24:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <223137E5-AC44-49C0-842F-DA33B113D420@ve7jtb.com> References: <002301cd2a70$55c88200$01598600$@augustcellars.com> <004301cd2ad5$fd061f90$f7125eb0$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkZCgDZqRgdGr/qj20x6zWsrFgP0zAGcGau+m9egcf4tdkT9QlyZ9NuUPQ+d7xq0CcanGBP Cc: 'Nat Sakimura' , jose@ietf.org Subject: Re: [jose] Signing and Encryption algorithm X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 18:32:56 -0000 Sorry I am traveling so responses may be delayed. We have talked about this in the past, and come to the conclusion that = of interoperability and simplicity of implementations calculating the = hash over the encoded values was preferred. I agree that on the face of it the hash calculated over the raw strings = should produce be repeatable if the various upper layers do the right = things. =20 =46rom an interoperability perspective having various transports = encoding and decoding the binary seems like it will cause problems in = deployments. The other downside (Though not directly a IETF concern) is that this = would be a breaking change to existing implementations of openID = Connect, BrowserID and others. I can't say I like the idea of having to do some non JSON string search = to find the end of the header. If we complicate things more than the existing practice of splitting on = periods and base64 decoding we will get pushback from implementers. I probably need to talk to more coders about this before I make a final = decision on the wisdom of this. So while not warm to the idea I will keep an open mind. John B. On 2012-05-05, at 8:44 AM, Jim Schaad wrote: > I am not suggesting that it should not be encoded as base64 for = transport if > you are in a situation where it might be modified. I think that how = the > transport is done should be left up to the protocol using JOSE and not > specified by JOSE. For the JWT serialization method, base64 will = definitely > be used. >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: Nat Sakimura [mailto:sakimura@gmail.com] >> Sent: Saturday, May 05, 2012 8:10 AM >> To: Jim Schaad >> Cc: jose@ietf.org >> Subject: Re: [jose] Signing and Encryption algorithm >>=20 >> Hi Jim, >>=20 >> Thanks for pointing it out. >>=20 >> I am not as confident as you are on getting the body unchanged = through all >> the transport and processing environment. True, it may be fine with = https, >> but we are not just targeting that. It may go through various media > including >> offline storage and by the time the JWE processor gets to the data, = it may >> have gone through bunch of frameworks that may touch the whitespaces >> and eol chars that may end up requiring us to do the = canonicalization. > Instead >> of risking that, I would prefer staying on the safer side albeit it = may > incur a >> little more overhead. The canonicalization is the primary thing that = we > want >> to avoid. >>=20 >> Thoughts? >>=20 >> Nat Sakimura >>=20 >> On Fri, May 4, 2012 at 8:36 PM, Jim Schaad >> wrote: >>> >>>=20 >>> I want to see if there is room for a discussion about the inputs = used >>> for signature (and encryption?) computations. The current algorithm >>> was designed with a specific mechanism in mind. It is not clear = that >>> with the new serialization methods that have been suggested that the >>> current steps to sign are the best. >>>=20 >>> The current code computes the signature hash as >>>=20 >>> HASH( BASE64( TEXT( header )) || "." || BASE64 ( body )) >>>=20 >>> =46rom what I know and can guess, there are three reasons for doing = it >>> this way. >>>=20 >>> 1. We need to make sure that nothing can move the body to the = headers >>> and vice versa 2. There is a strong desire to avoid = canonicalization >>> of the inputs and >>> base64 is the method chosen to do this 3. We already have the = base64 >>> values - so it makes sense to use them. >>>=20 >>> I would propose to change the hash computation to be >>>=20 >>> HASH( TEXT( header ) || body ) >>>=20 >>> 1. There are no issues with the migration of data across the >>> concatenation operator. Since the header is required to be a >>> well-defined JSON object, it is always possible to find the exact = end >>> of the JSON object in order to separate the header and the body >>> fields. The only requirement would be that the creation code would >>> need to state that there are no trailing characters following the > closing curly >> brace. >>>=20 >>> 2. We do want to avoid canonicalization; however there is no >>> effective difference between hashing the data before or after = applying >>> the base64 data string. If one looks at what ALTO wants to do, they >>> think that they do not need to base64 encode the body of the = message. >>> It will be transported unchanged by http(s). The only problem would >>> be if the application were to read in and then write out the JSON >>> data. That might change the bytes, but the same issue would be true >>> if you base64 encoded the byte stream as you wrote it out. >>>=20 >>> 3. In some cases the base64 values are not already present and = would >>> need to be created as part of the processing. >>>=20 >>> Jim >>>=20 >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >>=20 >>=20 >> -- >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From jimsch@augustcellars.com Sat May 5 12:01:07 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC42321F8552 for ; Sat, 5 May 2012 12:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHAKMYtJsjhE for ; Sat, 5 May 2012 12:01:06 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 3C07E21F849A for ; Sat, 5 May 2012 12:01:02 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 3F1682CA0A; Sat, 5 May 2012 12:00:59 -0700 (PDT) From: "Jim Schaad" To: "'John Bradley'" References: <002301cd2a70$55c88200$01598600$@augustcellars.com> <004301cd2ad5$fd061f90$f7125eb0$@augustcellars.com> <223137E5-AC44-49C0-842F-DA33B113D420@ve7jtb.com> In-Reply-To: <223137E5-AC44-49C0-842F-DA33B113D420@ve7jtb.com> Date: Sat, 5 May 2012 11:59:56 -0700 Message-ID: <004a01cd2af1$45c907e0$d15b17a0$@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: AQFFrMSCGEOV2uKMrNzEk2QJWLgndwGVQmUvAhOb1coBEF/Afpeku8Jg Content-Language: en-us Cc: 'Nat Sakimura' , jose@ietf.org Subject: Re: [jose] Signing and Encryption algorithm X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 19:01:07 -0000 > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com] > Sent: Saturday, May 05, 2012 11:25 AM > To: Jim Schaad > Cc: 'Nat Sakimura'; jose@ietf.org > Subject: Re: [jose] Signing and Encryption algorithm > > Sorry I am traveling so responses may be delayed. > > We have talked about this in the past, and come to the conclusion that of > interoperability and simplicity of implementations calculating the hash over > the encoded values was preferred. I am not sure how much this is real - it will depend on how one creates their library. There is not a lot of difference between the following pseudo codes String hdrString = hdr.ToString(); String hdrB64String = Base64(hdrString); Hash(hdrB64String); And String hdrString = hdr.ToString(); Hash(hdrString); String hdrB64String = Base64(hdrString); The question is where and when are the "to text" conversion and the base64 conversion done in the various libraries. > > I agree that on the face of it the hash calculated over the raw strings should > produce be repeatable if the various upper layers do the right things. > > From an interoperability perspective having various transports encoding and > decoding the binary seems like it will cause problems in deployments. I might have chosen a bad word here. When I say transport in this case I am not talking about http or email, I am talking about the ALTO message object or the JWT encoded object. This is an issue that the container which is using the JOSE work needs to deal with. I am not saying that this is an issue the HTTP or email needs to deal with. > > The other downside (Though not directly a IETF concern) is that this would be > a breaking change to existing implementations of openID Connect, > BrowserID and others. > > I can't say I like the idea of having to do some non JSON string search to find > the end of the header. I don't believe that I said this was ever going to be necessary. However there is a security issue which is almost surely not currently done in the libraries. When the header is parsed, the code needs to ensure that there are no unused characters at the end of the input string. If this is not the case then there is a dead zone in which the signature algorithm can be attacked. This would also apply to a body if it is a JSON encoded object. I expect that the header and the body are going to stay in distinct locations and there is no need to try and separate them in any protocol. The issue of making sure that there is no way for data to travel between the header and the body is strictly a security consideration on using the hash algorithm. One needs to make sure that you are not in the situation of having ABCDEF GHIJK ABCD EFGHIJK If you ignore the white space, these two strings generate the same hash value. However the semantics are going to be different as the characters are either part of the header or the body and that can change the meaning of things. Jim > > If we complicate things more than the existing practice of splitting on periods > and base64 decoding we will get pushback from implementers. > > I probably need to talk to more coders about this before I make a final > decision on the wisdom of this. > > So while not warm to the idea I will keep an open mind. > > John B. > > > On 2012-05-05, at 8:44 AM, Jim Schaad wrote: > > > I am not suggesting that it should not be encoded as base64 for > > transport if you are in a situation where it might be modified. I > > think that how the transport is done should be left up to the protocol > > using JOSE and not specified by JOSE. For the JWT serialization > > method, base64 will definitely be used. > > > > Jim > > > > > >> -----Original Message----- > >> From: Nat Sakimura [mailto:sakimura@gmail.com] > >> Sent: Saturday, May 05, 2012 8:10 AM > >> To: Jim Schaad > >> Cc: jose@ietf.org > >> Subject: Re: [jose] Signing and Encryption algorithm > >> > >> Hi Jim, > >> > >> Thanks for pointing it out. > >> > >> I am not as confident as you are on getting the body unchanged > >> through all the transport and processing environment. True, it may be > >> fine with https, but we are not just targeting that. It may go > >> through various media > > including > >> offline storage and by the time the JWE processor gets to the data, > >> it may have gone through bunch of frameworks that may touch the > >> whitespaces and eol chars that may end up requiring us to do the > canonicalization. > > Instead > >> of risking that, I would prefer staying on the safer side albeit it > >> may > > incur a > >> little more overhead. The canonicalization is the primary thing that > >> we > > want > >> to avoid. > >> > >> Thoughts? > >> > >> Nat Sakimura > >> > >> On Fri, May 4, 2012 at 8:36 PM, Jim Schaad > >> wrote: > >>> > >>> > >>> I want to see if there is room for a discussion about the inputs > >>> used for signature (and encryption?) computations. The current > >>> algorithm was designed with a specific mechanism in mind. It is not > >>> clear that with the new serialization methods that have been > >>> suggested that the current steps to sign are the best. > >>> > >>> The current code computes the signature hash as > >>> > >>> HASH( BASE64( TEXT( header )) || "." || BASE64 ( body )) > >>> > >>> From what I know and can guess, there are three reasons for doing it > >>> this way. > >>> > >>> 1. We need to make sure that nothing can move the body to the > >>> headers and vice versa 2. There is a strong desire to avoid > >>> canonicalization of the inputs and > >>> base64 is the method chosen to do this 3. We already have the > >>> base64 values - so it makes sense to use them. > >>> > >>> I would propose to change the hash computation to be > >>> > >>> HASH( TEXT( header ) || body ) > >>> > >>> 1. There are no issues with the migration of data across the > >>> concatenation operator. Since the header is required to be a > >>> well-defined JSON object, it is always possible to find the exact > >>> end of the JSON object in order to separate the header and the body > >>> fields. The only requirement would be that the creation code would > >>> need to state that there are no trailing characters following the > > closing curly > >> brace. > >>> > >>> 2. We do want to avoid canonicalization; however there is no > >>> effective difference between hashing the data before or after > >>> applying the base64 data string. If one looks at what ALTO wants to > >>> do, they think that they do not need to base64 encode the body of the > message. > >>> It will be transported unchanged by http(s). The only problem would > >>> be if the application were to read in and then write out the JSON > >>> data. That might change the bytes, but the same issue would be true > >>> if you base64 encoded the byte stream as you wrote it out. > >>> > >>> 3. In some cases the base64 values are not already present and > >>> would need to be created as part of the processing. > >>> > >>> Jim > >>> > >>> > >>> _______________________________________________ > >>> jose mailing list > >>> jose@ietf.org > >>> https://www.ietf.org/mailman/listinfo/jose > >> > >> > >> > >> -- > >> Nat Sakimura (=nat) > >> Chairman, OpenID Foundation > >> http://nat.sakimura.org/ > >> @_nat_en > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose From James.H.Manger@team.telstra.com Mon May 7 01:38:10 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC7621F84FF for ; Mon, 7 May 2012 01:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1ke8Me4D5vV for ; Mon, 7 May 2012 01:38:10 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id ABCB421F84CE for ; Mon, 7 May 2012 01:38:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,543,1330866000"; d="scan'208";a="72867950" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 07 May 2012 16:47:10 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6703"; a="61798667" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcdvi.tcif.telstra.com.au with ESMTP; 07 May 2012 16:47:09 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Mon, 7 May 2012 16:47:10 +1000 From: "Manger, James H" To: Jim Schaad , "jose@ietf.org" Date: Mon, 7 May 2012 16:47:08 +1000 Thread-Topic: [jose] Signing and Encryption algorithm Thread-Index: Ac0qX58KcGERjMN0RUKDOQ2BvA9oBgBugXCA Message-ID: <255B9BB34FB7D647A506DC292726F6E114F296BC71@WSMSG3153V.srv.dir.telstra.com> References: <002301cd2a70$55c88200$01598600$@augustcellars.com> In-Reply-To: <002301cd2a70$55c88200$01598600$@augustcellars.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [jose] Signing and Encryption algorithm 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, 07 May 2012 08:38:10 -0000 > The current code computes the signature hash as > > HASH( BASE64( TEXT( header )) || "." || BASE64 ( body )) > > From what I know and can guess, there are three reasons for doing it this > way. > > 1. We need to make sure that nothing can move the body to the headers an= d > vice versa > 2. There is a strong desire to avoid canonicalization of the inputs and > base64 is the method chosen to do this > 3. We already have the base64 values - so it makes sense to use them. > > I would propose to change the hash computation to be > > HASH( TEXT( header ) || body ) > > 1. There are no issues with the migration of data across the concatenati= on > operator. Since the header is required to be a well-defined JSON object,= it > is always possible to find the exact end of the JSON object in order to > separate the header and the body fields. The only requirement would be t= hat > the creation code would need to state that there are no trailing characte= rs > following the closing curly brace. I agree that it would be better to do the base64url-encoding outside of the= MAC calculation. Only issue 1 seems relevant. Requiring nothing after the closing "}" of the= header might be the answer. That should be easy enough for signers to meet= . However, it might be harder for verifiers to check (or they might "forget= " to check). I am sure many/most JSON decoders will (sensibly) ignore whitespace after t= he closing "}" -- it is allowed by the JSON spec. I wouldn't be surprised i= f some allowed C-style comments. Others might even allow arbitrary junk. Base64url-encoding the header, but not the body, might satisfy more parties= . HASH( BASE64( TEXT( header )) || "." || body ) P.S. HMAC is not the only form of MAC. I hope the spec drops the unnecessar= y restriction to "Hash-based MACs". -- James Manger From James.H.Manger@team.telstra.com Mon May 7 05:57:07 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C40F21F85CF for ; Mon, 7 May 2012 05:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.715 X-Spam-Level: X-Spam-Status: No, score=-0.715 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-eIg0OFLQpq for ; Mon, 7 May 2012 05:57:06 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8BF21F85C4 for ; Mon, 7 May 2012 05:57:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,543,1330866000"; d="scan'208";a="74929824" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 07 May 2012 22:56:59 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6703"; a="61827567" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcdvi.tcif.telstra.com.au with ESMTP; 07 May 2012 22:56:57 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Mon, 7 May 2012 22:56:58 +1000 From: "Manger, James H" To: "jimsch@augustcellars.com" , "jose@ietf.org" Date: Mon, 7 May 2012 22:56:58 +1000 Thread-Topic: [jose] Signing and Encryption algorithm Thread-Index: Ac0qX58KcGERjMN0RUKDOQ2BvA9oBgBugXCAAA3PkT4= 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [jose] Signing and Encryption algorithm 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, 07 May 2012 12:57:07 -0000 MAC( TEXT( header ) || body || LENGTH( body ) ) Including the length of the body as the last input to the MAC calculation (= or starting with the length of the header) would prevent any header/body bo= undary changes, without adding any constraints on how the header ends (eg w= ith or without a trailing new line). -- James Manger ----- Reply message ----- From: "Manger, James H" Date: Mon, May 7, 2012 6:38 pm Subject: [jose] Signing and Encryption algorithm To: "Jim Schaad" , "jose@ietf.org" > The current code computes the signature hash as > > HASH( BASE64( TEXT( header )) || "." || BASE64 ( body )) > > From what I know and can guess, there are three reasons for doing it this > way. > > 1. We need to make sure that nothing can move the body to the headers an= d > vice versa > 2. There is a strong desire to avoid canonicalization of the inputs and > base64 is the method chosen to do this > 3. We already have the base64 values - so it makes sense to use them. > > I would propose to change the hash computation to be > > HASH( TEXT( header ) || body ) > > 1. There are no issues with the migration of data across the concatenati= on > operator. Since the header is required to be a well-defined JSON object,= it > is always possible to find the exact end of the JSON object in order to > separate the header and the body fields. The only requirement would be t= hat > the creation code would need to state that there are no trailing characte= rs > following the closing curly brace. I agree that it would be better to do the base64url-encoding outside of the= MAC calculation. Only issue 1 seems relevant. Requiring nothing after the closing "}" of the= header might be the answer. That should be easy enough for signers to meet= . However, it might be harder for verifiers to check (or they might "forget= " to check). I am sure many/most JSON decoders will (sensibly) ignore whitespace after t= he closing "}" -- it is allowed by the JSON spec. I wouldn't be surprised i= f some allowed C-style comments. Others might even allow arbitrary junk. Base64url-encoding the header, but not the body, might satisfy more parties= . HASH( BASE64( TEXT( header )) || "." || body ) P.S. HMAC is not the only form of MAC. I hope the spec drops the unnecessar= y restriction to "Hash-based MACs". -- James Manger _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From ve7jtb@ve7jtb.com Mon May 7 08:07: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 E195A21F85CF for ; Mon, 7 May 2012 08:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.521 X-Spam-Level: X-Spam-Status: No, score=-3.521 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlBKaPKbXXf3 for ; Mon, 7 May 2012 08:07:34 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E87E921F85CE for ; Mon, 7 May 2012 08:07:33 -0700 (PDT) Received: by yenq13 with SMTP id q13so553245yen.31 for ; Mon, 07 May 2012 08:07:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=G3AAomjiw4fTewCfa5yJFjU5/mjZTBpm2incUe6a63c=; b=iVAkSlBi3n52RRfIahBAlvlCM6ROMFupyGpEuV0Hmk49c+dxozc2lXCSWc1FHCvEss AmbjRi/7MXLiftG2snGhIOg4BeuT8LUFM8Z2mbpoCgKALytNjXtrUmz6QPGkrG5d3LCH hhT9dsb72XZ/c48onSnbUUsLAg3fVDUNGE6ZwCEzehuZXFL1C8LnVgzoikoC+d1jOsNa UWT+mLVSzOOPkA6szb6inraaUdNU7ZC1vZKD2+Za+e8i9BAruBikb59WZ0zoKDaGwYdV yKCEmkegqj6FVaBHCn9gMSyi2aQpguSk04ySY8gbSFctWVsNxI1MaYbvMEm6Q1RcuC+8 lZyA== Received: by 10.236.136.99 with SMTP id v63mr9201886yhi.27.1336403253352; Mon, 07 May 2012 08:07:33 -0700 (PDT) Received: from [192.168.1.213] (190-20-11-19.baf.movistar.cl. [190.20.11.19]) by mx.google.com with ESMTPS id g4sm30633828yhf.12.2012.05.07.08.07.28 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 May 2012 08:07:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_992974F1-566A-4FE3-807E-1C67E458C626"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <-928519897122090382@unknownmsgid> Date: Mon, 7 May 2012 11:07:22 -0400 Message-Id: References: <4E1F6AAD24975D4BA5B1680429673943664C0440@TK5EX14MBXC283.redmond.corp.microsoft.com> <-928519897122090382@unknownmsgid> To: Nat Sakimura X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQl7zi+4oOb/XEFZnwSGDP72jBam9FAi/+25OB11hANUKR6ZwqB3WbCO0T6j1OZq+om5Qd9X Cc: Mike Jones , "jose@ietf.org" , Edmund Jay Subject: Re: [jose] AES-GCM in JWE 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, 07 May 2012 15:07:35 -0000 --Apple-Mail=_992974F1-566A-4FE3-807E-1C67E458C626 Content-Type: multipart/alternative; boundary="Apple-Mail=_ECF13515-2FA9-4703-81C7-1371E686E226" --Apple-Mail=_ECF13515-2FA9-4703-81C7-1371E686E226 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 +1 I looked at this with Mike and Edmund. Some of the changes are = necessary for interop, as GCM was underspecified. Keeping the input and = output parameters in line with there handling in CBC + HMAC makes the = spec more consistent. John B. On 2012-05-04, at 7:00 PM, Nat Sakimura wrote: > +1=20 >=20 > =3Dnat via iPhone >=20 > On 2012/05/04, at 15:16, Mike Jones = wrote: >=20 >> In the current JWE spec, AES Galois Counter Mode (GCM) is treated = quite differently than other algorithms because it provides an = integrated integrity check, however some of the unique properties of GCM = are not utilized. Having more deeply investigated the actual GCM = specification (NIST SP800-38D) and implementations, I now believe that = its treatment can and should be much more like the other algorithms in = JWE. Specifically, the current JWE spec is silent on how to use these = properties GCM: >> =B7 GCM includes an =93additional authenticated data=94 = parameter, in addition to the plaintext >> =B7 GCM specifies a preferred IV length of 96 bits (12 bytes) >> =B7 GCM has a separate =93authentication tag=94 output, = distinct from the ciphertext output >> =20 >> In the next version of the JWE spec, I plan to specify that the GCM = =93additional authenticated data=94 input for GCM be the concatenation = of the Encoded JWE Header, a period ('.') character, and the Encoded JWE = Encrypted Key. This will then include these values in the GCM integrity = value calculation, just as they are included in the separate integrity = value calculation of JWE for non-AEAD algorithms (thus securing the = header and encrypted key values). >> =20 >> Likewise, in the next version of the JWE spec, I plan to specify that = the GCM =93authentication tag=94 output be base64url encoded and used as = the Encoded JWE Integrity Value (the fourth field of the JWE), just as = the separately computed integrity value is used as the Encoded JWE = Integrity Value for non-AEAD algorithms. >> =20 >> Finally, in the next version of the JWE spec, I plan to specify that = a 96 bit IV be used with GCM. >> =20 >> This will make the treatment of GCM substantially more parallel to = non-AEAD algorithms and will use the =93additional authenticated data=94 = feature of GCM to secure the encryption parameters, as I believe was its = intended use. >> =20 >> -- Mike >> =20 >> P.S. My thanks to Edmund Jay for his deep dive into the particulars = of GCM in the course of his JWE implementation work. >> =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 --Apple-Mail=_ECF13515-2FA9-4703-81C7-1371E686E226 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
+1 

=3Dnat via = iPhone

On 2012/05/04, at 15:16, Mike Jones <Michael.Jones@microsoft.com> wrote:

In the current JWE spec, AES Galois Counter Mode (GCM) is treated quite differently = than other algorithms because it provides an integrated integrity check, = however some of the unique properties of GCM are not utilized.  = Having more deeply investigated the actual GCM specification (NIST SP800-38D) and implementations, I = now believe that its treatment can and should be much more like the = other algorithms in JWE.  Specifically, the current JWE spec is silent on how to use these properties = GCM:

=B7        GCM includes an =93additional authenticated data=94 = parameter, in addition to the plaintext

=B7        GCM specifies a preferred IV length of 96 bits (12 = bytes)

=B7        GCM has a separate =93authentication tag=94 output, = distinct from the ciphertext output

 

In the = next version of the JWE spec, I plan to specify that the GCM =93additional= authenticated data=94 input for GCM be the concatenation of the Encoded = JWE Header, a period ('.') character, and the Encoded JWE Encrypted = Key.  This will then include these values in the GCM integrity value calculation, just as = they are included in the separate integrity value calculation of JWE for non-AEAD algorithms (thus = securing the header and encrypted key values).

 

Likewise, = in the next version of the JWE spec, I plan to specify that the GCM = =93authentication tag=94 output be base64url encoded and used as the Encoded JWE Integrity Value = (the fourth field of the JWE), just as the separately computed integrity = value is used as the Encoded JWE Integrity Value for non-AEAD = algorithms.

 

Finally, in the next version of = the JWE spec, I plan to specify that a 96 bit IV be used with = GCM.

 

This will make the treatment of = GCM substantially more parallel to non-AEAD algorithms and will use the = =93additional authenticated data=94 feature of GCM to secure the = encryption parameters, as I believe was its intended use.

 

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

 

P.S.  My thanks to Edmund = Jay for his deep dive into the particulars of GCM in the course of his = JWE implementation work.

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

= --Apple-Mail=_ECF13515-2FA9-4703-81C7-1371E686E226-- --Apple-Mail=_992974F1-566A-4FE3-807E-1C67E458C626 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUw NzE1MDcyMlowIwYJKoZIhvcNAQkEMRYEFOAJsnRD3Yr+1V3uSg7Ea7IFIlfrMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AGm/Vck808nTrqa64ELHYeRhxu7dVLiDY8vjIw+JjLl+xOKYk8UKYa7MAtfwPdyBmwd35UgPrOPn BlhPM7aJP4x05qfTIiVoUo2BCMBfRF1L7DCSPoGFYMUTjUb46Zs2DLGKjUHI7bpiwOHZH3mNJkUw WVn0lGrkTk6/IsGTUTb38wdRJCicjfjgpk647bHnByiWdzwCZyI0jGM9Zj8eNljXz9BCqobqGEv4 P2bhrsXjH1fSodPlimVQEc6lWp1Sy290kh11Y48+cceYpqpaWxTHF5F+nTQLBzSSJXEa/6uX44fd qE+GFvZsrNKxQE9hYRCGx/f5TZsJChw37PXt3NIAAAAAAAA= --Apple-Mail=_992974F1-566A-4FE3-807E-1C67E458C626-- From ve7jtb@ve7jtb.com Mon May 7 08:16: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 D6C5A21F8566 for ; Mon, 7 May 2012 08:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xL7Yhrnmi3Q for ; Mon, 7 May 2012 08:16:31 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id DD5D621F8546 for ; Mon, 7 May 2012 08:16:30 -0700 (PDT) Received: by yenq13 with SMTP id q13so564424yen.31 for ; Mon, 07 May 2012 08:16:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=H9jp+mSwkvtx3aoTB65ob7gEkFcnaggkXdHr3C1ST14=; b=iuk8DTeMu18+2B7m9Zkq+Q6nUlp7sqcTvNQ/dybKlYlhDIqNmayL2tkHAQhmwMSTnK uNzQFNmeTRy+txuM6yesUglS6fqRJ0Fhx/hjEDOZKefeT5Cd0blwBFFSzN9AlmWc6/Xf gWkbGpUW7enMfupXt64mdOb4JD4fWS/+cnc7oAPHc5G8kwfedE688dGiBaB84Te8/v8B 7bjiACVKONRx0fGeZfRlDi/gsepB1kiE9oyNsWz2c4MQ/rDiZbVT7sZfEV/DQoZH4S6j PR0PNUuHdjNIiUsfG+szegPjqhrSMQ+Tifa2POem4s3XyH9a+hjvgnl7Q7kAufMd26Zl ZLSA== Received: by 10.236.125.168 with SMTP id z28mr19687061yhh.120.1336403789925; Mon, 07 May 2012 08:16:29 -0700 (PDT) Received: from [192.168.1.213] (190-20-11-19.baf.movistar.cl. [190.20.11.19]) by mx.google.com with ESMTPS id i2sm11839829anl.9.2012.05.07.08.16.26 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 May 2012 08:16:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_9B5BC2E9-B132-446C-A8CC-F6CF93A604AA"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Mon, 7 May 2012 11:16:19 -0400 Message-Id: References: To: "Manger, James H" X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmRGObLLF7nspQ/X7ve0+G2Hjm18cA7CJEjGBAdn9COpF++XY/BDj5SzywmZp6xD1+QhKJe Cc: "jose@ietf.org" , "jimsch@augustcellars.com" Subject: Re: [jose] Signing and Encryption algorithm 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, 07 May 2012 15:16:31 -0000 --Apple-Mail=_9B5BC2E9-B132-446C-A8CC-F6CF93A604AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes all true if you are in a C/C++ type environment. =20 Manipulating these signed objects easily in Scripting environments is a = concern for adoption. Google and Facebook both backed the hash over the base64 encoded parts = as the simplest for developers in those environments. I am not keen to change that without significant feedback. John B. On 2012-05-07, at 8:56 AM, Manger, James H wrote: > MAC( TEXT( header ) || body || LENGTH( body ) ) >=20 > Including the length of the body as the last input to the MAC = calculation (or starting with the length of the header) would prevent = any header/body boundary changes, without adding any constraints on how = the header ends (eg with or without a trailing new line). >=20 > -- > James Manger >=20 > ----- Reply message ----- > From: "Manger, James H" > Date: Mon, May 7, 2012 6:38 pm > Subject: [jose] Signing and Encryption algorithm > To: "Jim Schaad" , "jose@ietf.org" = >=20 >> The current code computes the signature hash as >>=20 >> HASH( BASE64( TEXT( header )) || "." || BASE64 ( body )) >>=20 >> =46rom what I know and can guess, there are three reasons for doing = it this >> way. >>=20 >> 1. We need to make sure that nothing can move the body to the = headers and >> vice versa >> 2. There is a strong desire to avoid canonicalization of the inputs = and >> base64 is the method chosen to do this >> 3. We already have the base64 values - so it makes sense to use = them. >>=20 >> I would propose to change the hash computation to be >>=20 >> HASH( TEXT( header ) || body ) >>=20 >> 1. There are no issues with the migration of data across the = concatenation >> operator. Since the header is required to be a well-defined JSON = object, it >> is always possible to find the exact end of the JSON object in order = to >> separate the header and the body fields. The only requirement would = be that >> the creation code would need to state that there are no trailing = characters >> following the closing curly brace. >=20 >=20 > I agree that it would be better to do the base64url-encoding outside = of the MAC calculation. >=20 > Only issue 1 seems relevant. Requiring nothing after the closing "}" = of the header might be the answer. That should be easy enough for = signers to meet. However, it might be harder for verifiers to check (or = they might "forget" to check). >=20 > I am sure many/most JSON decoders will (sensibly) ignore whitespace = after the closing "}" -- it is allowed by the JSON spec. I wouldn't be = surprised if some allowed C-style comments. Others might even allow = arbitrary junk. >=20 > Base64url-encoding the header, but not the body, might satisfy more = parties. >=20 > HASH( BASE64( TEXT( header )) || "." || body ) >=20 >=20 > P.S. HMAC is not the only form of MAC. I hope the spec drops the = unnecessary restriction to "Hash-based MACs". >=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 --Apple-Mail=_9B5BC2E9-B132-446C-A8CC-F6CF93A604AA Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUw NzE1MTYyMFowIwYJKoZIhvcNAQkEMRYEFELKkQEKP8lr+loC6au3CBrkuLWMMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ACXOnhPkyDhSnWA8iKWJqzUWu9PWnknkrkBGUm/X/+RrDxloz2CZSfJ14c91ErKJjLJMhqfPykry Qr/R2XgpJzMu157s6HX1rkvbV4S847gMg9VcSdfkc7SxJGEESMk5UtSppmQxhYyRXdYfBzcjUIW3 hj7tp85qWFUX2r3OUBMTd0Y/s6cmpuswrX1DN6s1Wvo3E1A0QpINB4b3PIwRAbQ28QBUjy/rQikY yW9zUxAhP+DDOz8s4J9aaSPVKj9PSaAfscPDaioJBsFDQgcgBN/iAeAQsITnspTLzrox7cXK2YwJ rAT7gC1HM89CzY44H7Wge+d2RwbUhrZO+WFNI4YAAAAAAAA= --Apple-Mail=_9B5BC2E9-B132-446C-A8CC-F6CF93A604AA-- From ietf@augustcellars.com Mon May 7 13:00: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 D595C21F86BB for ; Mon, 7 May 2012 13:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.285 X-Spam-Level: X-Spam-Status: No, score=-3.285 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gok20PN0SBVC for ; Mon, 7 May 2012 13:00:06 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id E875521F86A7 for ; Mon, 7 May 2012 13:00:05 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id A97DD38F25; Mon, 7 May 2012 13:00:04 -0700 (PDT) From: "Jim Schaad" To: "'Manger, James H'" , References: In-Reply-To: Date: Mon, 7 May 2012 12:58:57 -0700 Message-ID: <00e201cd2c8b$d88bf6a0$89a3e3e0$@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: AQMLIfVaa1DwBv3T/leN2l3I9Cwb2ZRC0cUA Content-Language: en-us Subject: Re: [jose] Signing and Encryption algorithm 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, 07 May 2012 20:00:07 -0000 I don't think doing this would get around the need to do the check that there are no trailing characters following the JSON object encoding. This would still allow for an attacker to be able to place data into the message in two places which would never be seen by the consumer of the message (the end of the header and the end of the body if JSON encoded). Specifically this would allow for a prefix attack where one would try and make the following the same HASH'( TEXT(ATTACKER HEADER) || ATTACKER DATA) = HASH'( TEXT(HEADER)) Where Hash' does not do the closing steps (such as adding the length). One would just output the internal state of the hash function at the end of processing a block of data. (One can actually use any prefix of the original header as the remainder of the original header can just be tacked onto the end of the attacker data field.) jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Manger, James H > Sent: Monday, May 07, 2012 5:57 AM > To: jimsch@augustcellars.com; jose@ietf.org > Subject: Re: [jose] Signing and Encryption algorithm > > MAC( TEXT( header ) || body || LENGTH( body ) ) > > Including the length of the body as the last input to the MAC calculation (or > starting with the length of the header) would prevent any header/body > boundary changes, without adding any constraints on how the header ends > (eg with or without a trailing new line). > > -- > James Manger > > ----- Reply message ----- > From: "Manger, James H" > Date: Mon, May 7, 2012 6:38 pm > Subject: [jose] Signing and Encryption algorithm > To: "Jim Schaad" , "jose@ietf.org" > > > > The current code computes the signature hash as > > > > HASH( BASE64( TEXT( header )) || "." || BASE64 ( body )) > > > > From what I know and can guess, there are three reasons for doing it > > this way. > > > > 1. We need to make sure that nothing can move the body to the headers > > and vice versa 2. There is a strong desire to avoid canonicalization > > of the inputs and > > base64 is the method chosen to do this 3. We already have the base64 > > values - so it makes sense to use them. > > > > I would propose to change the hash computation to be > > > > HASH( TEXT( header ) || body ) > > > > 1. There are no issues with the migration of data across the > > concatenation operator. Since the header is required to be a > > well-defined JSON object, it is always possible to find the exact end > > of the JSON object in order to separate the header and the body > > fields. The only requirement would be that the creation code would > > need to state that there are no trailing characters following the closing curly > brace. > > > I agree that it would be better to do the base64url-encoding outside of the > MAC calculation. > > Only issue 1 seems relevant. Requiring nothing after the closing "}" of the > header might be the answer. That should be easy enough for signers to > meet. However, it might be harder for verifiers to check (or they might > "forget" to check). > > I am sure many/most JSON decoders will (sensibly) ignore whitespace after > the closing "}" -- it is allowed by the JSON spec. I wouldn't be surprised if > some allowed C-style comments. Others might even allow arbitrary junk. > > Base64url-encoding the header, but not the body, might satisfy more parties. > > HASH( BASE64( TEXT( header )) || "." || body ) > > > P.S. HMAC is not the only form of MAC. I hope the spec drops the > unnecessary restriction to "Hash-based MACs". > > -- > 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 ietf@augustcellars.com Mon May 7 13:02: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 F1D9421F86E4 for ; Mon, 7 May 2012 13:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWLxs7RQ1Am3 for ; Mon, 7 May 2012 13:02:19 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 2979F21F86E2 for ; Mon, 7 May 2012 13:02:18 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 3B76A38F25; Mon, 7 May 2012 13:02:16 -0700 (PDT) From: "Jim Schaad" To: "'John Bradley'" References: In-Reply-To: Date: Mon, 7 May 2012 13:01:09 -0700 Message-ID: <00e301cd2c8c$27e1de90$77a59bb0$@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: AQMLIfVaa1DwBv3T/leN2l3I9Cwb2QHwllBzlDNPNqA= Content-Language: en-us Cc: jimsch@augustcellars.com, jose@ietf.org Subject: Re: [jose] Signing and Encryption algorithm 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, 07 May 2012 20:02:20 -0000 John, I don't follow this. I have done work in both a C/C++ environment and in a scripting environment (mostly jscript) and I don't see why the difference in environment should make any difference to this. Can you elaborate why you feel there is a difference? Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > John Bradley > Sent: Monday, May 07, 2012 8:16 AM > To: Manger, James H > Cc: jose@ietf.org; jimsch@augustcellars.com > Subject: Re: [jose] Signing and Encryption algorithm > > Yes all true if you are in a C/C++ type environment. > > Manipulating these signed objects easily in Scripting environments is a > concern for adoption. > > Google and Facebook both backed the hash over the base64 encoded parts > as the simplest for developers in those environments. > > I am not keen to change that without significant feedback. > > John B. > > > On 2012-05-07, at 8:56 AM, Manger, James H wrote: > > > MAC( TEXT( header ) || body || LENGTH( body ) ) > > > > Including the length of the body as the last input to the MAC calculation (or > starting with the length of the header) would prevent any header/body > boundary changes, without adding any constraints on how the header ends > (eg with or without a trailing new line). > > > > -- > > James Manger > > > > ----- Reply message ----- > > From: "Manger, James H" > > Date: Mon, May 7, 2012 6:38 pm > > Subject: [jose] Signing and Encryption algorithm > > To: "Jim Schaad" , "jose@ietf.org" > > > > > >> The current code computes the signature hash as > >> > >> HASH( BASE64( TEXT( header )) || "." || BASE64 ( body )) > >> > >> From what I know and can guess, there are three reasons for doing it > >> this way. > >> > >> 1. We need to make sure that nothing can move the body to the > >> headers and vice versa 2. There is a strong desire to avoid > >> canonicalization of the inputs and > >> base64 is the method chosen to do this 3. We already have the base64 > >> values - so it makes sense to use them. > >> > >> I would propose to change the hash computation to be > >> > >> HASH( TEXT( header ) || body ) > >> > >> 1. There are no issues with the migration of data across the > >> concatenation operator. Since the header is required to be a > >> well-defined JSON object, it is always possible to find the exact end > >> of the JSON object in order to separate the header and the body > >> fields. The only requirement would be that the creation code would > >> need to state that there are no trailing characters following the closing > curly brace. > > > > > > I agree that it would be better to do the base64url-encoding outside of the > MAC calculation. > > > > Only issue 1 seems relevant. Requiring nothing after the closing "}" of the > header might be the answer. That should be easy enough for signers to > meet. However, it might be harder for verifiers to check (or they might > "forget" to check). > > > > I am sure many/most JSON decoders will (sensibly) ignore whitespace after > the closing "}" -- it is allowed by the JSON spec. I wouldn't be surprised if > some allowed C-style comments. Others might even allow arbitrary junk. > > > > Base64url-encoding the header, but not the body, might satisfy more > parties. > > > > HASH( BASE64( TEXT( header )) || "." || body ) > > > > > > P.S. HMAC is not the only form of MAC. I hope the spec drops the > unnecessary restriction to "Hash-based MACs". > > > > -- > > 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 Mon May 7 16:39: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 0492021F84D5 for ; Mon, 7 May 2012 16:39:50 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sjpBL+IvNGZ for ; Mon, 7 May 2012 16:39:48 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0C93721F84D2 for ; Mon, 7 May 2012 16:39:47 -0700 (PDT) Received: by bkty8 with SMTP id y8so4998375bkt.31 for ; Mon, 07 May 2012 16:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=33rCfrXOhDgh/n/YDlZ8xYp0b2LwQnmXU//1L5q8Gvw=; b=fWn1T0z1O1L+YH55FcrLdRG+LN0TbfbbijatG2b12GqEwQP02lq23+mEwXKxDXedJJ duHtXnH6IxLlS+/yVjTRWmthsey+QRIvQ+uYbR1DRwlEtKxrMuFjrKyScdIvTqRrZ7e4 EIMDH9hFFzVWP9k3wxM2CAGuynkxXmIj8fSDBKxHcDvj8ZMciVGexlmjyLLa0ua0Llpu HHWR815reLc15jAEfyIzffWLoFN1zllj86Ug6537FDWLWZfxZ0Rs5JnOlnUmkMb07lIJ i8HO4VpACx7sInYYO1Eu+LbwZki144uWRzmw/na3wis5ryf/wTEWoiO+t2wi7J1C8L7e ywCQ== MIME-Version: 1.0 Received: by 10.204.151.81 with SMTP id b17mr6144714bkw.52.1336433987110; Mon, 07 May 2012 16:39:47 -0700 (PDT) Received: by 10.204.240.143 with HTTP; Mon, 7 May 2012 16:39:47 -0700 (PDT) In-Reply-To: <00e301cd2c8c$27e1de90$77a59bb0$@augustcellars.com> References: <00e301cd2c8c$27e1de90$77a59bb0$@augustcellars.com> Date: Tue, 8 May 2012 01:39:47 +0200 Message-ID: From: Nat Sakimura To: Jim Schaad Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: John Bradley , jose@ietf.org, jimsch@augustcellars.com Subject: Re: [jose] Signing and Encryption algorithm 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, 07 May 2012 23:39:50 -0000 I suppose what John is asking is: Suppose body was binary. Is it safe to do TEXT( header ) || body ? Or should we do pack("C*", str_split(header)) || body ? What happens if the header includes UTF-8 characters? etc. Nat On Mon, May 7, 2012 at 10:01 PM, Jim Schaad wrote: > John, > > I don't follow this. =A0I have done work in both a C/C++ environment and = in a > scripting environment (mostly jscript) and I don't see why the difference= in > environment should make any difference to this. =A0Can you elaborate why = you > feel there is a difference? > > Jim > > >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of >> John Bradley >> Sent: Monday, May 07, 2012 8:16 AM >> To: Manger, James H >> Cc: jose@ietf.org; jimsch@augustcellars.com >> Subject: Re: [jose] Signing and Encryption algorithm >> >> Yes all true if you are in a C/C++ type environment. >> >> Manipulating these signed objects easily in Scripting environments is a >> concern for adoption. >> >> Google and Facebook both backed the hash over the base64 encoded parts >> as the simplest for developers in those environments. >> >> I am not keen to change that without significant feedback. >> >> John B. >> >> >> On 2012-05-07, at 8:56 AM, Manger, James H wrote: >> >> > MAC( TEXT( header ) || body || LENGTH( body ) ) >> > >> > Including the length of the body as the last input to the MAC > calculation (or >> starting with the length of the header) would prevent any header/body >> boundary changes, without adding any constraints on how the header ends >> (eg with or without a trailing new line). >> > >> > -- >> > James Manger >> > >> > ----- Reply message ----- >> > From: "Manger, James H" >> > Date: Mon, May 7, 2012 6:38 pm >> > Subject: [jose] Signing and Encryption algorithm >> > To: "Jim Schaad" , "jose@ietf.org" >> > >> > >> >> The current code computes the signature hash as >> >> >> >> HASH( BASE64( TEXT( header )) || "." || BASE64 ( body )) >> >> >> >> From what I know and can guess, there are three reasons for doing it >> >> this way. >> >> >> >> 1. =A0We need to make sure that nothing can move the body to the >> >> headers and vice versa 2. =A0There is a strong desire to avoid >> >> canonicalization of the inputs and >> >> base64 is the method chosen to do this 3. =A0We already have the base= 64 >> >> values - so it makes sense to use them. >> >> >> >> I would propose to change the hash computation to be >> >> >> >> HASH( TEXT( header ) || body ) >> >> >> >> 1. =A0There are no issues with the migration of data across the >> >> concatenation operator. =A0Since the header is required to be a >> >> well-defined JSON object, it is always possible to find the exact end >> >> of the JSON object in order to separate the header and the body >> >> fields. =A0The only requirement would be that the creation code would >> >> need to state that there are no trailing characters following the > closing >> curly brace. >> > >> > >> > I agree that it would be better to do the base64url-encoding outside o= f > the >> MAC calculation. >> > >> > Only issue 1 seems relevant. Requiring nothing after the closing "}" o= f > the >> header might be the answer. That should be easy enough for signers to >> meet. However, it might be harder for verifiers to check (or they might >> "forget" to check). >> > >> > I am sure many/most JSON decoders will (sensibly) ignore whitespace > after >> the closing "}" -- it is allowed by the JSON spec. I wouldn't be surpris= ed > if >> some allowed C-style comments. Others might even allow arbitrary junk. >> > >> > Base64url-encoding the header, but not the body, might satisfy more >> parties. >> > >> > HASH( BASE64( TEXT( header )) || "." || body ) >> > >> > >> > P.S. HMAC is not the only form of MAC. I hope the spec drops the >> unnecessary restriction to "Hash-based MACs". >> > >> > -- >> > 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 > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en From ietf@augustcellars.com Mon May 7 17:22: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 B0C5B21F85E1 for ; Mon, 7 May 2012 17:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.564 X-Spam-Level: X-Spam-Status: No, score=-3.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofGjMvAYR474 for ; Mon, 7 May 2012 17:22:20 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id C0E2621F85DD for ; Mon, 7 May 2012 17:22:20 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 87B5C2CA13; Mon, 7 May 2012 17:22:19 -0700 (PDT) From: "Jim Schaad" To: "'Nat Sakimura'" References: <00e301cd2c8c$27e1de90$77a59bb0$@augustcellars.com> In-Reply-To: Date: Mon, 7 May 2012 17:21:07 -0700 Message-ID: <00f301cd2cb0$7b3d17c0$71b74740$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMLIfVaa1DwBv3T/leN2l3I9Cwb2QHwllBzAoc5AHgCofSlH5QKS0bQ Content-Language: en-us Cc: 'John Bradley' , jose@ietf.org Subject: Re: [jose] Signing and Encryption algorithm 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, 08 May 2012 00:22:21 -0000 > -----Original Message----- > From: Nat Sakimura [mailto:sakimura@gmail.com] > Sent: Monday, May 07, 2012 4:40 PM > To: Jim Schaad > Cc: John Bradley; jimsch@augustcellars.com; jose@ietf.org > Subject: Re: [jose] Signing and Encryption algorithm >=20 > I suppose what John is asking is: >=20 > Suppose body was binary. Hash functions only operate on arrays of bytes - so the real question is what happens if the body is a string. You need to convert it into an = array of bytes before you can hash or mac it. >=20 > Is it safe to do TEXT( header ) || body ? Completely if you assume that there is no trailing data on TEXT(header) >=20 > Or should we do pack("C*", str_split(header)) || body ? I don't understand the question. You are always going need to convert = from characters to bytes in order to hash. >=20 > What happens if the header includes UTF-8 characters? The header needs to be converted into a string and then into an array of bytes. You then base64 encode the array of bytes. If you base64 encode = the string then yes there is a potential problem about how the utf8 string = is converted into a byte array for base64 encoding. If you just pass in = the byte array then no issues. If you decode the base64 encoded strings (in = the library) to a byte array then no problem But again this is a question of how the library or other code is = written. Somebody needs to do this conversion, if you suggest that user code does = it then it will almost surely be done consistently but yes that is a = potential problem. On the other hand you have the same issue if people encode it = into base64 twice (once for the signature and once for sending it). Jim >=20 > etc. >=20 > Nat >=20 > On Mon, May 7, 2012 at 10:01 PM, Jim Schaad > wrote: > > John, > > > > I don't follow this. =A0I have done work in both a C/C++ environment = and > > in a scripting environment (mostly jscript) and I don't see why the > > difference in environment should make any difference to this. =A0Can = you > > elaborate why you feel there is a difference? > > > > Jim > > > > > >> -----Original Message----- > >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf > >> Of John Bradley > >> Sent: Monday, May 07, 2012 8:16 AM > >> To: Manger, James H > >> Cc: jose@ietf.org; jimsch@augustcellars.com > >> Subject: Re: [jose] Signing and Encryption algorithm > >> > >> Yes all true if you are in a C/C++ type environment. > >> > >> Manipulating these signed objects easily in Scripting environments = is > >> a concern for adoption. > >> > >> Google and Facebook both backed the hash over the base64 encoded > >> parts as the simplest for developers in those environments. > >> > >> I am not keen to change that without significant feedback. > >> > >> John B. > >> > >> > >> On 2012-05-07, at 8:56 AM, Manger, James H wrote: > >> > >> > MAC( TEXT( header ) || body || LENGTH( body ) ) > >> > > >> > Including the length of the body as the last input to the MAC > > calculation (or > >> starting with the length of the header) would prevent any = header/body > >> boundary changes, without adding any constraints on how the header > >> ends (eg with or without a trailing new line). > >> > > >> > -- > >> > James Manger > >> > > >> > ----- Reply message ----- > >> > From: "Manger, James H" > >> > Date: Mon, May 7, 2012 6:38 pm > >> > Subject: [jose] Signing and Encryption algorithm > >> > To: "Jim Schaad" , "jose@ietf.org" > >> > > >> > > >> >> The current code computes the signature hash as > >> >> > >> >> HASH( BASE64( TEXT( header )) || "." || BASE64 ( body )) > >> >> > >> >> From what I know and can guess, there are three reasons for = doing > >> >> it this way. > >> >> > >> >> 1. =A0We need to make sure that nothing can move the body to the > >> >> headers and vice versa 2. =A0There is a strong desire to avoid > >> >> canonicalization of the inputs and > >> >> base64 is the method chosen to do this 3. =A0We already have the > >> >> base64 values - so it makes sense to use them. > >> >> > >> >> I would propose to change the hash computation to be > >> >> > >> >> HASH( TEXT( header ) || body ) > >> >> > >> >> 1. =A0There are no issues with the migration of data across the > >> >> concatenation operator. =A0Since the header is required to be a > >> >> well-defined JSON object, it is always possible to find the = exact > >> >> end of the JSON object in order to separate the header and the > >> >> body fields. =A0The only requirement would be that the creation = code > >> >> would need to state that there are no trailing characters > >> >> following the > > closing > >> curly brace. > >> > > >> > > >> > I agree that it would be better to do the base64url-encoding > >> > outside of > > the > >> MAC calculation. > >> > > >> > Only issue 1 seems relevant. Requiring nothing after the closing > >> > "}" of > > the > >> header might be the answer. That should be easy enough for signers = to > >> meet. However, it might be harder for verifiers to check (or they > >> might "forget" to check). > >> > > >> > I am sure many/most JSON decoders will (sensibly) ignore = whitespace > > after > >> the closing "}" -- it is allowed by the JSON spec. I wouldn't be > >> surprised > > if > >> some allowed C-style comments. Others might even allow arbitrary = junk. > >> > > >> > Base64url-encoding the header, but not the body, might satisfy = more > >> parties. > >> > > >> > HASH( BASE64( TEXT( header )) || "." || body ) > >> > > >> > > >> > P.S. HMAC is not the only form of MAC. I hope the spec drops the > >> unnecessary restriction to "Hash-based MACs". > >> > > >> > -- > >> > 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 > > > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 >=20 > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en From ietf@augustcellars.com Mon May 7 17: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 07A9321F85B5 for ; Mon, 7 May 2012 17:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VR6zpjl1H8GG for ; Mon, 7 May 2012 17:27:02 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 10B1D21F84A1 for ; Mon, 7 May 2012 17:27:02 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 2315E2C9BE; Mon, 7 May 2012 17:26:56 -0700 (PDT) From: "Jim Schaad" To: "'Nat Sakimura'" References: <00e301cd2c8c$27e1de90$77a59bb0$@augustcellars.com> <00f301cd2cb0$7b3d17c0$71b74740$@augustcellars.com> In-Reply-To: <00f301cd2cb0$7b3d17c0$71b74740$@augustcellars.com> Date: Mon, 7 May 2012 17:25:45 -0700 Message-ID: <00f701cd2cb1$21f2b480$65d81d80$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMLIfVaa1DwBv3T/leN2l3I9Cwb2QHwllBzAoc5AHgCofSlHwH6HfiRk/p+5gA= Content-Language: en-us Cc: 'John Bradley' , jose@ietf.org Subject: Re: [jose] Signing and Encryption algorithm 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, 08 May 2012 00:27:03 -0000 After sending this message I realized that I messed up. The UTF8 = conversion from Unicode to bytes is a deterministic one. Thus applying to a string = to produce bytes is always going to be the same. The only problem would be = if you re-normalized the string between the applications of the utf8 = conversion function. Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of > Jim Schaad > Sent: Monday, May 07, 2012 5:21 PM > To: 'Nat Sakimura' > Cc: 'John Bradley'; jose@ietf.org > Subject: Re: [jose] Signing and Encryption algorithm >=20 >=20 >=20 > > -----Original Message----- > > From: Nat Sakimura [mailto:sakimura@gmail.com] > > Sent: Monday, May 07, 2012 4:40 PM > > To: Jim Schaad > > Cc: John Bradley; jimsch@augustcellars.com; jose@ietf.org > > Subject: Re: [jose] Signing and Encryption algorithm > > > > I suppose what John is asking is: > > > > Suppose body was binary. >=20 > Hash functions only operate on arrays of bytes - so the real question = is what > happens if the body is a string. You need to convert it into an array = of bytes > before you can hash or mac it. >=20 > > > > Is it safe to do TEXT( header ) || body ? >=20 > Completely if you assume that there is no trailing data on = TEXT(header) >=20 > > > > Or should we do pack("C*", str_split(header)) || body ? >=20 > I don't understand the question. You are always going need to convert from > characters to bytes in order to hash. >=20 > > > > What happens if the header includes UTF-8 characters? >=20 > The header needs to be converted into a string and then into an array = of > bytes. You then base64 encode the array of bytes. If you base64 = encode the > string then yes there is a potential problem about how the utf8 string = is > converted into a byte array for base64 encoding. If you just pass in = the byte > array then no issues. If you decode the base64 encoded strings (in = the > library) to a byte array then no problem >=20 > But again this is a question of how the library or other code is = written. > Somebody needs to do this conversion, if you suggest that user code = does it > then it will almost surely be done consistently but yes that is a potential > problem. On the other hand you have the same issue if people encode = it > into > base64 twice (once for the signature and once for sending it). >=20 > Jim >=20 >=20 > > > > etc. > > > > Nat > > > > On Mon, May 7, 2012 at 10:01 PM, Jim Schaad > > wrote: > > > John, > > > > > > I don't follow this. =A0I have done work in both a C/C++ = environment > > > and in a scripting environment (mostly jscript) and I don't see = why > > > the difference in environment should make any difference to this. > > > Can you elaborate why you feel there is a difference? > > > > > > Jim > > > > > > > > >> -----Original Message----- > > >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On > > >> Behalf Of John Bradley > > >> Sent: Monday, May 07, 2012 8:16 AM > > >> To: Manger, James H > > >> Cc: jose@ietf.org; jimsch@augustcellars.com > > >> Subject: Re: [jose] Signing and Encryption algorithm > > >> > > >> Yes all true if you are in a C/C++ type environment. > > >> > > >> Manipulating these signed objects easily in Scripting = environments > > >> is a concern for adoption. > > >> > > >> Google and Facebook both backed the hash over the base64 encoded > > >> parts as the simplest for developers in those environments. > > >> > > >> I am not keen to change that without significant feedback. > > >> > > >> John B. > > >> > > >> > > >> On 2012-05-07, at 8:56 AM, Manger, James H wrote: > > >> > > >> > MAC( TEXT( header ) || body || LENGTH( body ) ) > > >> > > > >> > Including the length of the body as the last input to the MAC > > > calculation (or > > >> starting with the length of the header) would prevent any > > >> header/body boundary changes, without adding any constraints on = how > > >> the header ends (eg with or without a trailing new line). > > >> > > > >> > -- > > >> > James Manger > > >> > > > >> > ----- Reply message ----- > > >> > From: "Manger, James H" > > >> > Date: Mon, May 7, 2012 6:38 pm > > >> > Subject: [jose] Signing and Encryption algorithm > > >> > To: "Jim Schaad" , "jose@ietf.org" > > >> > > > >> > > > >> >> The current code computes the signature hash as > > >> >> > > >> >> HASH( BASE64( TEXT( header )) || "." || BASE64 ( body )) > > >> >> > > >> >> From what I know and can guess, there are three reasons for > > >> >> doing it this way. > > >> >> > > >> >> 1. =A0We need to make sure that nothing can move the body to = the > > >> >> headers and vice versa 2. =A0There is a strong desire to avoid > > >> >> canonicalization of the inputs and > > >> >> base64 is the method chosen to do this 3. =A0We already have = the > > >> >> base64 values - so it makes sense to use them. > > >> >> > > >> >> I would propose to change the hash computation to be > > >> >> > > >> >> HASH( TEXT( header ) || body ) > > >> >> > > >> >> 1. =A0There are no issues with the migration of data across = the > > >> >> concatenation operator. =A0Since the header is required to be = a > > >> >> well-defined JSON object, it is always possible to find the > > >> >> exact end of the JSON object in order to separate the header = and > > >> >> the body fields. =A0The only requirement would be that the > > >> >> creation code would need to state that there are no trailing > > >> >> characters following the > > > closing > > >> curly brace. > > >> > > > >> > > > >> > I agree that it would be better to do the base64url-encoding > > >> > outside of > > > the > > >> MAC calculation. > > >> > > > >> > Only issue 1 seems relevant. Requiring nothing after the = closing > > >> > "}" of > > > the > > >> header might be the answer. That should be easy enough for = signers > > >> to meet. However, it might be harder for verifiers to check (or > > >> they might "forget" to check). > > >> > > > >> > I am sure many/most JSON decoders will (sensibly) ignore > > >> > whitespace > > > after > > >> the closing "}" -- it is allowed by the JSON spec. I wouldn't be > > >> surprised > > > if > > >> some allowed C-style comments. Others might even allow arbitrary > junk. > > >> > > > >> > Base64url-encoding the header, but not the body, might satisfy > > >> > more > > >> parties. > > >> > > > >> > HASH( BASE64( TEXT( header )) || "." || body ) > > >> > > > >> > > > >> > P.S. HMAC is not the only form of MAC. I hope the spec drops = the > > >> unnecessary restriction to "Hash-based MACs". > > >> > > > >> > -- > > >> > 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 > > > > > > > > > _______________________________________________ > > > jose mailing list > > > jose@ietf.org > > > https://www.ietf.org/mailman/listinfo/jose > > > > > > > > -- > > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > > http://nat.sakimura.org/ > > @_nat_en >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From James.H.Manger@team.telstra.com Mon May 7 20:04:24 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF6721F8443 for ; Mon, 7 May 2012 20:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.73 X-Spam-Level: X-Spam-Status: No, score=-0.73 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2lLn2yLxisG for ; Mon, 7 May 2012 20:04:24 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id C318721F85F2 for ; Mon, 7 May 2012 20:04:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,547,1330866000"; d="scan'208";a="77963882" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 08 May 2012 13:04:21 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6704"; a="62114573" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcbni.tcif.telstra.com.au with ESMTP; 08 May 2012 13:04:21 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Tue, 8 May 2012 13:04:21 +1000 From: "Manger, James H" To: Jim Schaad , "jose@ietf.org" Date: Tue, 8 May 2012 13:04:20 +1000 Thread-Topic: [jose] Signing and Encryption algorithm Thread-Index: AQMLIfVaa1DwBv3T/leN2l3I9Cwb2ZRC0cUAgABhO9A= Message-ID: <255B9BB34FB7D647A506DC292726F6E114F296C687@WSMSG3153V.srv.dir.telstra.com> References: <00e201cd2c8b$d88bf6a0$89a3e3e0$@augustcellars.com> In-Reply-To: <00e201cd2c8b$d88bf6a0$89a3e3e0$@augustcellars.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [jose] Signing and Encryption algorithm 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, 08 May 2012 03:04:24 -0000 Jim, I think there are 2 distinct concerns here: 1. The header/body boundary must not be "movable" after signing. It must no= t be possible for {h1, b1} and {h2, b2} to produce the same sequence of byt= es that are fed to the MAC algorithm. 2. If there is room for arbitrary "junk" in the signed data then an attacke= r can use that to try to find collisions. We must prevent #1. I think we will have to accept #2. We have to assume our choice of MAC algo= rithm is strong enough make finding collisions infeasible. Preventing #2 would require JSON canonicalization rules at a minimum, which= we want to avoid. Regardless of whether JSON parsers ignore junk after the= closing "}", there is still ample freedom to insert whitespace in the JSON= value that will be ignored. For instance, insert 128 spaces or tabs before= the closing "}" to give 2^128 variants of the "same" header in a search fo= r a collision. The current structure MAC(BASE64(header) || "." || BASE64(body)) prevents #= 1 because "." cannot appear in a BASE64-encoding. Might attacks still be po= ssible if some base64-decoders silently ignore non-base64 chars during deco= ding, and the order of HTML-unescaping and splitting on "." is not quite ri= ght? MAC(header_with_nothing_after_closing_} || body) prevents #1 only if JSON d= ecoders (or the apps calling them) enforce the "nothing after the closing }= " condition, which is not realistic. Enforcing "nothing other than whitespa= ce after the closing }" is more realistic, but maybe not certain enough. MAC(header || body || length(body)) prevents #1 regardless of any leniency = of base64-decoders and JSON-decoders. Jim, your "prefix attack" looks like issue #2. Is junk after "}" that is ig= nored any worse than whitespace before "}" that is ignored? -- James Manger From S.Durbha@cablelabs.com Tue May 8 08:05: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 E03DB11E8087 for ; Tue, 8 May 2012 08:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpgrMYN+sfoa for ; Tue, 8 May 2012 08:05:43 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id B37B111E807F for ; Tue, 8 May 2012 08:05:37 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q48F5DdU002184; Tue, 8 May 2012 09:05:13 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 08 May 2012 09:05:13 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 8 May 2012 09:05:13 -0600 From: Seetharama Rao Durbha To: "'Manger, James H'" , Jim Schaad , "jose@ietf.org" Date: Tue, 8 May 2012 09:05:12 -0600 Thread-Topic: [jose] Signing and Encryption algorithm Thread-Index: AQMLIfVaa1DwBv3T/leN2l3I9Cwb2ZRC0cUAgABhO9D//9dwgA== Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D05BEC135A4@srvxchg> References: <00e201cd2c8b$d88bf6a0$89a3e3e0$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F296C687@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F296C687@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [jose] Signing and Encryption algorithm 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, 08 May 2012 15:05:44 -0000 Apologize for jumping in. Isn't it true that if header cannot be reliably s= erialized (ignoring whitespace after closing }) then it doesn't matter if w= e do=20 a. MAC(BASE64(serializedHeader) || "." || BASE64(body)) OR b. MAC(serializedHeader || body) Base64(serializedHeader) is still going to be messed up if there are traili= ng whitespace after closing }. -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Man= ger, James H Sent: Monday, May 07, 2012 9:04 PM To: Jim Schaad; jose@ietf.org Subject: Re: [jose] Signing and Encryption algorithm Jim, I think there are 2 distinct concerns here: 1. The header/body boundary must not be "movable" after signing. It must no= t be possible for {h1, b1} and {h2, b2} to produce the same sequence of byt= es that are fed to the MAC algorithm. 2. If there is room for arbitrary "junk" in the signed data then an attacke= r can use that to try to find collisions. We must prevent #1. I think we will have to accept #2. We have to assume our choice of MAC algo= rithm is strong enough make finding collisions infeasible. Preventing #2 would require JSON canonicalization rules at a minimum, which= we want to avoid. Regardless of whether JSON parsers ignore junk after the= closing "}", there is still ample freedom to insert whitespace in the JSON= value that will be ignored. For instance, insert 128 spaces or tabs before= the closing "}" to give 2^128 variants of the "same" header in a search fo= r a collision. The current structure MAC(BASE64(header) || "." || BASE64(body)) prevents #= 1 because "." cannot appear in a BASE64-encoding. Might attacks still be po= ssible if some base64-decoders silently ignore non-base64 chars during deco= ding, and the order of HTML-unescaping and splitting on "." is not quite ri= ght? MAC(header_with_nothing_after_closing_} || body) prevents #1 only if JSON d= ecoders (or the apps calling them) enforce the "nothing after the closing }= " condition, which is not realistic. Enforcing "nothing other than whitespa= ce after the closing }" is more realistic, but maybe not certain enough. MAC(header || body || length(body)) prevents #1 regardless of any leniency = of base64-decoders and JSON-decoders. Jim, your "prefix attack" looks like issue #2. Is junk after "}" that is ig= nored any worse than whitespace before "}" that is ignored? -- James Manger _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Tue May 8 09:01: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 36FC811E80B1 for ; Tue, 8 May 2012 09:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.942 X-Spam-Level: X-Spam-Status: No, score=-3.942 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekUa2aIaAVYc for ; Tue, 8 May 2012 09:01:49 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id C6BBE11E80B0 for ; Tue, 8 May 2012 09:01:48 -0700 (PDT) Received: from mail116-am1-R.bigfish.com (10.3.201.230) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 8 May 2012 16:01:33 +0000 Received: from mail116-am1 (localhost [127.0.0.1]) by mail116-am1-R.bigfish.com (Postfix) with ESMTP id 66DA0203DA; Tue, 8 May 2012 16:01:33 +0000 (UTC) X-SpamScore: -26 X-BigFish: VS-26(zz9371I542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail116-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail116-am1 (localhost.localdomain [127.0.0.1]) by mail116-am1 (MessageSwitch) id 1336492891462313_13956; Tue, 8 May 2012 16:01:31 +0000 (UTC) Received: from AM1EHSMHS018.bigfish.com (unknown [10.3.201.241]) by mail116-am1.bigfish.com (Postfix) with ESMTP id 5409B2600B3; Tue, 8 May 2012 16:01:31 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS018.bigfish.com (10.3.206.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 8 May 2012 16:01:30 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.230]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0298.005; Tue, 8 May 2012 16:01:41 +0000 From: Mike Jones To: Seetharama Rao Durbha , "'Manger, James H'" , Jim Schaad , "jose@ietf.org" Thread-Topic: [jose] Signing and Encryption algorithm Thread-Index: Ac0qX58KcGERjMN0RUKDOQ2BvA9oBgBugXCAAA3PkT4ADrzLgAAO2zkAABktDQAAAbawMA== Date: Tue, 8 May 2012 16:01:40 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943664C9FF0@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <00e201cd2c8b$d88bf6a0$89a3e3e0$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F296C687@WSMSG3153V.srv.dir.telstra.com> <114DAD31379DFA438C0A2E39B3B8AF5D05BEC135A4@srvxchg> In-Reply-To: <114DAD31379DFA438C0A2E39B3B8AF5D05BEC135A4@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] Signing and Encryption algorithm 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, 08 May 2012 16:01:50 -0000 It doesn't matter to the meaning of the header whether there is trailing wh= itespace or not. The period character between the base64url encoded header= and the base64url encoded payload provides a simple way of ensuring that t= he two cannot be confused with one another. Base64url encoding the header = accurately preserves it, whether there are trailing (or leading or embedded= ) whitespace characters (including tabs, LFs, CRs, spaces), or not. -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of See= tharama Rao Durbha Sent: Tuesday, May 08, 2012 8:05 AM To: 'Manger, James H'; Jim Schaad; jose@ietf.org Subject: Re: [jose] Signing and Encryption algorithm Apologize for jumping in. Isn't it true that if header cannot be reliably s= erialized (ignoring whitespace after closing }) then it doesn't matter if w= e do=20 a. MAC(BASE64(serializedHeader) || "." || BASE64(body)) OR b. MAC(serialize= dHeader || body) Base64(serializedHeader) is still going to be messed up if there are traili= ng whitespace after closing }. -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Man= ger, James H Sent: Monday, May 07, 2012 9:04 PM To: Jim Schaad; jose@ietf.org Subject: Re: [jose] Signing and Encryption algorithm Jim, I think there are 2 distinct concerns here: 1. The header/body boundary must not be "movable" after signing. It must no= t be possible for {h1, b1} and {h2, b2} to produce the same sequence of byt= es that are fed to the MAC algorithm. 2. If there is room for arbitrary "junk" in the signed data then an attacke= r can use that to try to find collisions. We must prevent #1. I think we will have to accept #2. We have to assume our choice of MAC algo= rithm is strong enough make finding collisions infeasible. Preventing #2 would require JSON canonicalization rules at a minimum, which= we want to avoid. Regardless of whether JSON parsers ignore junk after the= closing "}", there is still ample freedom to insert whitespace in the JSON= value that will be ignored. For instance, insert 128 spaces or tabs before= the closing "}" to give 2^128 variants of the "same" header in a search fo= r a collision. The current structure MAC(BASE64(header) || "." || BASE64(body)) prevents #= 1 because "." cannot appear in a BASE64-encoding. Might attacks still be po= ssible if some base64-decoders silently ignore non-base64 chars during deco= ding, and the order of HTML-unescaping and splitting on "." is not quite ri= ght? MAC(header_with_nothing_after_closing_} || body) prevents #1 only if JSON d= ecoders (or the apps calling them) enforce the "nothing after the closing }= " condition, which is not realistic. Enforcing "nothing other than whitespa= ce after the closing }" is more realistic, but maybe not certain enough. MAC(header || body || length(body)) prevents #1 regardless of any leniency = of base64-decoders and JSON-decoders. Jim, your "prefix attack" looks like issue #2. Is junk after "}" that is ig= nored any worse than whitespace before "}" that is ignored? -- 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 S.Durbha@cablelabs.com Tue May 8 09:16: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 5E36421F85F0 for ; Tue, 8 May 2012 09:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vn91ChHdRdFb for ; Tue, 8 May 2012 09:16:25 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id BD9C021F85AA for ; Tue, 8 May 2012 09:16:25 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q48GGNWB012712; Tue, 8 May 2012 10:16:23 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 08 May 2012 10:16:23 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 8 May 2012 10:16:23 -0600 From: Seetharama Rao Durbha To: "'Mike Jones'" , "'Manger, James H'" , Jim Schaad , "jose@ietf.org" Date: Tue, 8 May 2012 10:13:57 -0600 Thread-Topic: [jose] Signing and Encryption algorithm Thread-Index: Ac0qX58KcGERjMN0RUKDOQ2BvA9oBgBugXCAAA3PkT4ADrzLgAAO2zkAABktDQAAAbawMAAAhEnQ Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D05BEC135A5@srvxchg> References: <00e201cd2c8b$d88bf6a0$89a3e3e0$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F296C687@WSMSG3153V.srv.dir.telstra.com> <114DAD31379DFA438C0A2E39B3B8AF5D05BEC135A4@srvxchg> <4E1F6AAD24975D4BA5B1680429673943664C9FF0@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943664C9FF0@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [jose] Signing and Encryption algorithm 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, 08 May 2012 16:16:26 -0000 If there was deserialization involved, I might agree with the confusion asp= ect. But since we are talking about inputs to MAC, we just need reliable se= rialization of header and body. Adding a period in between does not elimina= te inconsistencies in serialization of header or body. What I am saying is = that whoever is verifying the MAC should know whether to include or exclude= any trailing whitespace, regardless. Seetharama -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik= e Jones Sent: Tuesday, May 08, 2012 10:02 AM To: Seetharama Rao Durbha; 'Manger, James H'; Jim Schaad; jose@ietf.org Subject: Re: [jose] Signing and Encryption algorithm It doesn't matter to the meaning of the header whether there is trailing wh= itespace or not. The period character between the base64url encoded header= and the base64url encoded payload provides a simple way of ensuring that t= he two cannot be confused with one another. Base64url encoding the header = accurately preserves it, whether there are trailing (or leading or embedded= ) whitespace characters (including tabs, LFs, CRs, spaces), or not. -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of See= tharama Rao Durbha Sent: Tuesday, May 08, 2012 8:05 AM To: 'Manger, James H'; Jim Schaad; jose@ietf.org Subject: Re: [jose] Signing and Encryption algorithm Apologize for jumping in. Isn't it true that if header cannot be reliably s= erialized (ignoring whitespace after closing }) then it doesn't matter if w= e do=20 a. MAC(BASE64(serializedHeader) || "." || BASE64(body)) OR b. MAC(serialize= dHeader || body) Base64(serializedHeader) is still going to be messed up if there are traili= ng whitespace after closing }. -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Man= ger, James H Sent: Monday, May 07, 2012 9:04 PM To: Jim Schaad; jose@ietf.org Subject: Re: [jose] Signing and Encryption algorithm Jim, I think there are 2 distinct concerns here: 1. The header/body boundary must not be "movable" after signing. It must no= t be possible for {h1, b1} and {h2, b2} to produce the same sequence of byt= es that are fed to the MAC algorithm. 2. If there is room for arbitrary "junk" in the signed data then an attacke= r can use that to try to find collisions. We must prevent #1. I think we will have to accept #2. We have to assume our choice of MAC algo= rithm is strong enough make finding collisions infeasible. Preventing #2 would require JSON canonicalization rules at a minimum, which= we want to avoid. Regardless of whether JSON parsers ignore junk after the= closing "}", there is still ample freedom to insert whitespace in the JSON= value that will be ignored. For instance, insert 128 spaces or tabs before= the closing "}" to give 2^128 variants of the "same" header in a search fo= r a collision. The current structure MAC(BASE64(header) || "." || BASE64(body)) prevents #= 1 because "." cannot appear in a BASE64-encoding. Might attacks still be po= ssible if some base64-decoders silently ignore non-base64 chars during deco= ding, and the order of HTML-unescaping and splitting on "." is not quite ri= ght? MAC(header_with_nothing_after_closing_} || body) prevents #1 only if JSON d= ecoders (or the apps calling them) enforce the "nothing after the closing }= " condition, which is not realistic. Enforcing "nothing other than whitespa= ce after the closing }" is more realistic, but maybe not certain enough. MAC(header || body || length(body)) prevents #1 regardless of any leniency = of base64-decoders and JSON-decoders. Jim, your "prefix attack" looks like issue #2. Is junk after "}" that is ig= nored any worse than whitespace before "}" that is ignored? -- 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 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From ietf@augustcellars.com Tue May 8 14:54:01 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C0021F853B for ; Tue, 8 May 2012 14:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.269 X-Spam-Level: X-Spam-Status: No, score=-3.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnFsYhrYnkbP for ; Tue, 8 May 2012 14:54:00 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 57A1421F8534 for ; Tue, 8 May 2012 14:54:00 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 1CF532CA09; Tue, 8 May 2012 14:54:00 -0700 (PDT) From: "Jim Schaad" To: "'Manger, James H'" , References: <00e201cd2c8b$d88bf6a0$89a3e3e0$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F296C687@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F296C687@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 8 May 2012 14:52:52 -0700 Message-ID: <013d01cd2d64$ebac75a0$c30560e0$@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: AQMLIfVaa1DwBv3T/leN2l3I9Cwb2QHhhLV/Adla7hGUJp2AgA== Content-Language: en-us Subject: Re: [jose] Signing and Encryption algorithm 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, 08 May 2012 21:54:01 -0000 > -----Original Message----- > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > Sent: Monday, May 07, 2012 8:04 PM > To: Jim Schaad; jose@ietf.org > Subject: RE: [jose] Signing and Encryption algorithm > > Jim, > > I think there are 2 distinct concerns here: > > 1. The header/body boundary must not be "movable" after signing. It must > not be possible for {h1, b1} and {h2, b2} to produce the same sequence of > bytes that are fed to the MAC algorithm. > > 2. If there is room for arbitrary "junk" in the signed data then an attacker can > use that to try to find collisions. > > We must prevent #1. > I think we will have to accept #2. We have to assume our choice of MAC > algorithm is strong enough make finding collisions infeasible. > > Preventing #2 would require JSON canonicalization rules at a minimum, which > we want to avoid. Regardless of whether JSON parsers ignore junk after the > closing "}", there is still ample freedom to insert whitespace in the JSON > value that will be ignored. For instance, insert 128 spaces or tabs before the > closing "}" to give 2^128 variants of the "same" header in a search for a > collision. The restriction of the character set to those items which are just whitespace does provide some improved security characteristics over allowing for a complete character set to occur. The fact that some bits in the string need to be 0s (bits 6 and 7) and others are tightly related restricts the full search space in the hash algorithm attack. One of the improvements that was considered to keep SHA1 alive longer was to double hash each characters (thus "abc" becomes "aabbcc") which forces structure on the input stream and therefore increases the difficulty of finding collisions. This does imply that allowing whitespace in the string in arbitrary locations does allow for an attack space, but not a full attack space. > > > The current structure MAC(BASE64(header) || "." || BASE64(body)) > prevents #1 because "." cannot appear in a BASE64-encoding. Might attacks > still be possible if some base64-decoders silently ignore non-base64 chars > during decoding, and the order of HTML-unescaping and splitting on "." is not > quite right? There are a couple of things. First the base64 decoder would need to check that all of the input bytes are consumed - you could have a legal base64 string followed by some arbitrary bytes (not containing a ".") and then the "." character. If the base64 stopped when it got to the point it had enough characters and did not check to see if there were more then you would have an issue. (As an example it could stop when finding either a "=" or a "==") This is less of an issue because of the call for the url safe version of base64 to be used. Again the fact that only base64 characters can appear does make it more difficult to attack this section if the base64 decoder does its job and makes sure that there are no non-base64 characters present. This is an issue for whitespace since most base64 decoders allow for arbitrary amounts of whitespace to occur in the string. > > MAC(header_with_nothing_after_closing_} || body) prevents #1 only if > JSON decoders (or the apps calling them) enforce the "nothing after the > closing }" condition, which is not realistic. Enforcing "nothing other than > whitespace after the closing }" is more realistic, but maybe not certain > enough. > > MAC(header || body || length(body)) prevents #1 regardless of any > leniency of base64-decoders and JSON-decoders. But we still need to deal with MAC (header || Attack || body || length(body)) It would be possible to deal with it by including a header length as well and checking both lengths against the total message length. This would allow for total lengths to be checked and ignore the JSON/Base64 parser problems. However putting lengths in imposes additional programmer issues that need to be dealt with. Jim > > > Jim, your "prefix attack" looks like issue #2. Is junk after "}" that is ignored > any worse than whitespace before "}" that is ignored? > > -- > James Manger From internet-drafts@ietf.org Sat May 12 16:39: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 D198321F869A; Sat, 12 May 2012 16:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.457 X-Spam-Level: X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-agEtH2pBOu; Sat, 12 May 2012 16:39:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3C121F859B; Sat, 12 May 2012 16:39:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120512233953.7770.62608.idtracker@ietfa.amsl.com> Date: Sat, 12 May 2012 16:39:53 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-signature-02.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 23:39:54 -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 Encrypt= ion 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-02.txt Pages : 30 Date : 2012-05-12 JSON Web Signature (JWS) is a means of representing content secured with digital signatures or Message Authentication Codes (MACs) using JSON data structures. Cryptographic algorithms and identifiers used with this specification are enumerated in the separate JSON Web Algorithms (JWA) specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-signature-02.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-jose-json-web-signature-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature/ From internet-drafts@ietf.org Sat May 12 16:41: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 BD40E21F86B2; Sat, 12 May 2012 16:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kz9YvcRYFGoU; Sat, 12 May 2012 16:41:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE0C21F859F; Sat, 12 May 2012 16:41:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120512234138.8590.1100.idtracker@ietfa.amsl.com> Date: Sat, 12 May 2012 16:41:38 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-encryption-02.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 23:41:38 -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 Encrypt= ion 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-02.txt Pages : 24 Date : 2012-05-12 JSON Web Encryption (JWE) is a means of representing encrypted content using JSON data structures. Cryptographic algorithms and identifiers used with this specification are enumerated in the separate JSON Web Algorithms (JWA) specification. Related digital signature and MAC capabilities are described in the separate JSON Web Signature (JWS) specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-encryption-02.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-jose-json-web-encryption-02.t= xt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption/ From internet-drafts@ietf.org Sat May 12 16:43: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 9FF7921F869E; Sat, 12 May 2012 16:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDwuxh6GUbJB; Sat, 12 May 2012 16:43:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A8F21F859F; Sat, 12 May 2012 16:43:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120512234350.9160.80183.idtracker@ietfa.amsl.com> Date: Sat, 12 May 2012 16:43:50 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 23:43:50 -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 Encrypt= ion Working Group of the IETF. Title : JSON Web Key (JWK) Author(s) : Michael B. Jones Filename : draft-ietf-jose-json-web-key-02.txt Pages : 8 Date : 2012-05-12 A JSON Web Key (JWK) is a 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 used with this specification are enumerated in the separate JSON Web Algorithms (JWA) specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-key-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-jose-json-web-key-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key/ From internet-drafts@ietf.org Sat May 12 16:45: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 6445421F86C2; Sat, 12 May 2012 16:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FK+5qpbNnQIe; Sat, 12 May 2012 16:45:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3AA121F859F; Sat, 12 May 2012 16:45:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120512234538.9868.10035.idtracker@ietfa.amsl.com> Date: Sat, 12 May 2012 16:45:38 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-02.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 23:45:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encrypt= ion Working Group of the IETF. Title : JSON Web Algorithms (JWA) Author(s) : Michael B. Jones Filename : draft-ietf-jose-json-web-algorithms-02.txt Pages : 26 Date : 2012-05-12 The JSON Web Algorithms (JWA) specification enumerates cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS) and JSON Web Encryption (JWE) specifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-algorithms-02.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-jose-json-web-algorithms-02.t= xt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms/ From Michael.Jones@microsoft.com Sat May 12 17:22:59 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79A421F86C8 for ; Sat, 12 May 2012 17:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.903 X-Spam-Level: X-Spam-Status: No, score=-3.903 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1d1O3MB8hL47 for ; Sat, 12 May 2012 17:22:58 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCE721F86C7 for ; Sat, 12 May 2012 17:22:58 -0700 (PDT) Received: from mail129-va3-R.bigfish.com (10.7.14.236) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Sun, 13 May 2012 00:22:55 +0000 Received: from mail129-va3 (localhost [127.0.0.1]) by mail129-va3-R.bigfish.com (Postfix) with ESMTP id 7178A2603C5; Sun, 13 May 2012 00:22:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -37 X-BigFish: VS-37(zzbb2dI9371I146fI542M1432N98dK111aIzz1202hzz1033IL8275eh8275dha1495iz2fh2a8h668h839h944hd25h) Received-SPF: pass (mail129-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail129-va3 (localhost.localdomain [127.0.0.1]) by mail129-va3 (MessageSwitch) id 1336868573383632_2142; Sun, 13 May 2012 00:22:53 +0000 (UTC) Received: from VA3EHSMHS010.bigfish.com (unknown [10.7.14.239]) by mail129-va3.bigfish.com (Postfix) with ESMTP id 5A846160044; Sun, 13 May 2012 00:22:53 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS010.bigfish.com (10.7.99.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 13 May 2012 00:22:53 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0298.005; Sun, 13 May 2012 00:22:53 +0000 From: Mike Jones To: Yaron Sheffer Thread-Topic: [jose] Comments on the JOSE drafts Thread-Index: AQHM1bKNqrUc7ZcPqUO+Ach6FhljB5Y25GPQgAGEu4CAjbFx0A== Date: Sun, 13 May 2012 00:22:52 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943664F1966@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4F167432.1030503@gmail.com> <4E1F6AAD24975D4BA5B1680429673943663A01B0@TK5EX14MBXC284.redmond.corp.microsoft.com> <4F367753.5070809@gmail.com> In-Reply-To: <4F367753.5070809@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-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Comments on the JOSE drafts 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, 13 May 2012 00:23:00 -0000 Hi Yaron, I wanted to let you know that I've applied the changes agreed to below in t= he just-published set of new JOSE drafts. If you have time for another det= ailed read, I'd appreciate you going through the new drafts with the same a= ttention to detail that you did the -00 versions. Your comments were quite= valuable in improving the current drafts. Thanks again, -- Mike -----Original Message----- From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]=20 Sent: Saturday, February 11, 2012 6:13 AM To: Mike Jones Cc: jose@ietf.org Subject: Re: [jose] Comments on the JOSE drafts Hi Mike, please see my responses below. Apologies as this message is getting too lon= g for humans to parse... On 02/11/2012 02:05 AM, Mike Jones wrote: > Thanks for your detailed comments, Yaron. Responses inline below. > > draft-ietf-jose-json-web-key-00 > > * This is probably water under the bridge by now, but I think the=20 > applicability of bare public keys (as opposed to certificates and=20 > certificate chains) is very limited. And there is value in using the=20 > mechanisms defined here for certificate (and not just public key) roll-ov= er. > > There was an explicit working group decision to include JSON=20 > representation of bare public keys in the working group charter. That=20 > being said, if there are specific changes you'd like to see, by all=20 > means, let's discuss them. I'm OK with the web-key spec being focused on bare public keys. What's impo= rtant is what can be used in JWS, and that clearly allows certificates. How= ever note that the "jku" parameter in JWS Sec. 4.1 mentions that it's used = for "web keys" only, but then goes on to mention certificates. > > * In addition, integrity protection and encryption with symmetric keys=20 > is also extremely useful. For example, this format could be used for=20 > Kerberos-like authorization tickets. > > If you make a compelling case for a scenario that requires or would=20 > benefit from this functionality, I'm sure the working group would=20 > consider it. Recently I wrote some code that allows one server in a very dynamic cloud s= etup to issue time-limited authorization tickets to other servers, tickets = that can only be validated by the issuing server. This is much easier to do= with symmetric keys than with public keys. > > * Why mention specifically RSA and Elliptic Curve, instead of building=20 > on (a subset of) PKCS#8, which is more generic? For example, someone's=20 > bound to require modular DSA at some point. > > The goal was to be able to encode public keys for algorithms in common=20 > usage on the Internet. The more minimal, the more likely the spec is=20 > to be actually implemented, provided it actually meets the needs of=20 > the implementer's scenarios. Thus, keys for RSA and Elliptic Curve=20 > algorithms were explicitly selected. > > If you want to make the case for including other algorithm families=20 > based on a real scenario, I suspect the working group would be open to th= at. I don't... > > * "EC" is not an algorithm. You probably mean "ECDSA" (e.g. as opposed=20 > to ECDH). > > This may be more than you want to know, but in the first version of=20 > the spec=20 > , > this identifier was, in fact, "ECDSA". This was changed in the -01=20 > version with the introduction of the JWE spec and the need to=20 > represent keys used with the ECDH algorithm as well as those used with=20 > ECDSA. The "EC" identifier is explicitly there to represent a family=20 > of algorithms sharing the same key representation - not a specific algori= thm. OK. > > * The way we propose to deal with additional, unknown members=20 > precludes extensibility. One can easily think of meaningful optional memb= ers (e.g. > > key owner, key version) that do NOT need to be understood by most consume= rs. > > For a core security feature, the decision was to err on the side of=20 > security, rather than convenience of extensibility. The problem is -=20 > how would an implementation /know/ whether it's safe to ignore a=20 > parameter or not? Unless there's a way to tell outside of=20 > understanding the parameter itself, the only safe thing to do is to=20 > require rejecting not-understood parameters. There are standard ways of dealing with this issue, the so-called "critical= " flag. The semantics needs to be defined very well. But I think it's worth= the effort if you expect this format to be widely deployed. See e.g. botto= m of http://tools.ietf.org/html/rfc5996#section-2.5. > > draft-ietf-jose-json-web-signature-00 > > * Again, why mention HMAC already in the introduction, vs. the more=20 > generic "message authentication code". > > I'm open to this change. Comments from others in the WG? > > * Can the payload be binary? The Terminology should clarify it. > > Yes. The introduction already says "... independent of the type of=20 > content being secured, allowing arbitrary content to be secured", but=20 > I supposebit I could this clarification to the JWS Payload definition=20 > as well. I'll add this to my to-do list. > > * The definition of JWS Header is self-referential and confusing. > > Agreed, I'll clarify this in the next version to be more along the=20 > lines of the (hopefully clearer) JWE Header definition in the JWE spec. > > * "Computing the HMAC of the UTF-8 representation": this is a bit=20 > misleading - the representation is actually good old ASCII. > > Yes it is ASCII. Would the language "Computing the HMAC of the bytes=20 > of the ASCII representation" be better? Comments from others? Fine with me. > > * In the same paragraph, computing HMAC-256 also requires a key, which=20 > should have been mentioned. > > Agreed. I'll add this to my to-do list. (The key /is/ shown in the=20 > example in Appendix A, but it should be mentioned in 3.1 as well.) > > * When defining the jku member: RFC 6125 is very new - do we really=20 > have to make it mandatory here? > > Opinions from the working group? > > * No way is defined to name symmetric keys used for HMAC signatures. > > I suspect the right thing to do is to generalize the Key ID language=20 > to allow it to be used for symmetric keys as well as asymmetric. Any=20 > disagreement? Not from me. > > * I suggest to rename x5t to something that includes the algorithm, e.g. > > "x5t_sha1". We have already migrated from MD5 to SHA-1, there will be=20 > more coming. But the idea of using key names instead of the full key=20 > is valuable. > > Also see Jim Schaad's proposal on this x5t that I replied to earlier=20 > today. Ideas welcome... > > * Again, step #3 of the JWS validation process precludes easy=20 > extensibility. In many cases you do NOT want the signature consumer to=20 > understand all the fields. In particular when some parameters ("typ")=20 > are underspecified. > > See my comments on the typ header parameter in JWS in my note=20 > "Discussion of open issues in JOSE drafts" sent earlier today. I=20 > believe my comments on must-understand above also apply here in the=20 > general case, however. > > * IANA considerations: why not define a way for implementations to=20 > have member names that are guaranteed *not* to become reserved?=20 > Something like "x-*"? URIs are simply too long. > > I believe the sense among IETF participants at this point is that "x-" > was a well-intentioned idea that failed in practice for a number of=20 > real-world reasons. But I would certainly be open to the WG discussing=20 > this possibility. You're probably right (although I don't know why "x-" is considered to have= failed). Anyway, you can always use a URI. > > * Also, it is very important to allow for IANA extensibility of the=20 > set of supported algorithms (probably in the forthcoming JWA document). > > Yes - a registry for this purpose is already specified. > > draft-ietf-jose-json-web-encryption-00 > > * Many people are still not using authenticated-encryption algorithms. > > Such people are very likely to abuse this specification, i.e. use just=20 > encryption with no integrity protection (yes, despite the SHOULD=20 > wording at the bottom of the document). IMHO this spec must also=20 > support the more traditional usage of encryption+MAC. Integrity=20 > protection should not be left as an implementer's option. > > I believe the working group largely feels the same as you do on this=20 > point. A proposal for enabling encryption+integrity is in the works. > > * 4.2: this paragraph talks about parameter names, but also sneaks in=20 > algorithm names, which probably require a separate IANA registry and=20 > possibly separate extensibility rules. I suggest to separate them out. > > You're right that this is unnecessarily confusing, as written. In=20 > practice, separate registries for header parameters and algorithms are=20 > already specified. All add clarifying this text to my to-do list. > > * 5: in steps #5 and #6, this is not a bitstring, it's a byte string=20 > (or a "sequence of octets"). > > Agreed - I'll make this change. > > * 6: the decryption step (#6) also includes validation of the AES-GCM=20 > authentication tag, and this may fail of course. > > Agreed - I'll make this clarification. > > * 7.2: OK, the algorithm can be specified, but how do we reference the=20 > key being used, and its version number? > > Possibly with the Key ID, per my earlier comment? OK. > > * As far as I know "randomness in browsers... is easy to screw up" is=20 > actually an understatement. It is still impossible to do, at least not=20 > in a portable way. > > That's what I thought. Do you have a reference handy that=20 > authoritatively makes this point? > Nothing better than "private communication"... > =3D=3D=3D=3D > > Thanks again for the detailed read! My pleasure. Yaron > > -- Mike > From Michael.Jones@microsoft.com Sat May 12 17:23:08 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6146521F86D1 for ; Sat, 12 May 2012 17:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Tx1nTfKqkKy for ; Sat, 12 May 2012 17:23:07 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 943F721F86C7 for ; Sat, 12 May 2012 17:23:07 -0700 (PDT) Received: from mail63-ch1-R.bigfish.com (10.43.68.250) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Sun, 13 May 2012 00:23:04 +0000 Received: from mail63-ch1 (localhost [127.0.0.1]) by mail63-ch1-R.bigfish.com (Postfix) with ESMTP id BC0112A0326; Sun, 13 May 2012 00:23:04 +0000 (UTC) X-SpamScore: -41 X-BigFish: VS-41(zz9371I542M1432N98dK111aI1486Mzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail63-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail63-ch1 (localhost.localdomain [127.0.0.1]) by mail63-ch1 (MessageSwitch) id 133686858359310_2582; Sun, 13 May 2012 00:23:03 +0000 (UTC) Received: from CH1EHSMHS016.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.234]) by mail63-ch1.bigfish.com (Postfix) with ESMTP id 0A4E638007F; Sun, 13 May 2012 00:23:03 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS016.bigfish.com (10.43.70.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 13 May 2012 00:23:02 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0298.005; Sun, 13 May 2012 00:23:04 +0000 From: Mike Jones To: Matt Miller Thread-Topic: [jose] Discussion of open issues in JOSE drafts Thread-Index: AczoO0YE4vGS3UblSUWSpCkmMaMKUAChdPSAEUkAUKA= Date: Sun, 13 May 2012 00:23:03 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943664F196D@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436639FBD8@TK5EX14MBXC284.redmond.corp.microsoft.com> <666D4F23-662F-4AD7-B427-1BF91EACBB1B@cisco.com> In-Reply-To: <666D4F23-662F-4AD7-B427-1BF91EACBB1B@cisco.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-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Discussion of open issues in JOSE drafts 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, 13 May 2012 00:23:08 -0000 Hi Matt, Many of your recommendations below were incorporated in the just-published = -02 versions of the JOSE specs. I'd appreciate it if you could have a look= at the new text covering these. Thanks again for the review. -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mat= t Miller Sent: Monday, February 13, 2012 10:34 AM To: Mike Jones Cc: jose@ietf.org Subject: Re: [jose] Discussion of open issues in JOSE drafts Trimming non-considered concerns... Also, another JWE concern that was stated in Taipei and on list: * Accommodating multiple recipients On Feb 10, 2012, at 14:31, Mike Jones wrote: >=20 > From http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-00#se= ction-12: >=20 > * Consider whether to add parameters for directly including keys = in the header, either as JWK Key Objects, or X.509 cert values, or both. > As for JWS, I suspect this will be required by some use cases. Any disag= reement or discussion? >=20 I need this for my use-cases. > * Consider which of the open issues from the JWS and JWT specs al= so apply here. > Having just reviewed them, the only one that seems that it may apply is a= decision on whether to create a JSON serialization whose final representat= ion is JSON (probably in separate specifications) in addition to the curren= t compact serializations, whose representation is base64url encoded data st= ructures. One problem with the JSON serialization is the possible need for= canonicalization algorithms. (Bear in mind that not needing canonicalizat= ion is one of the major advantages of the present specs over the correspond= ing XML ones.) I don't think, however that the outcome of this decision wi= ll affect the current specs either way. >=20 I would concur on efforts to avoid canonicalization. I can see the appeal = to having a "JSON-Stringified" representation (e.g. value =3D JSON.parse(JS= ON.parse(input).field) ), but I personally have no problem sticking with ba= se64 or base64url. > * Should StringOrURI use IRIs rather than RFC 3986 URIs? > Opinions? Is this a standing IETF requirement now, or is this being hand= led on case-by-case basis as makes sense in context? >=20 If humans are involved, then i18n is a concern. I suspect, at the least, "= jku" and "x5u" will require support for internationalized values. > From http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-00#se= ction-7: >=20 >=20 > * Consider whether to define "alg":"none" here, rather than in the JWT= spec. > This would seem to make sense, as other application contexts may also wan= t this capability. Any disagreement? >=20 I would find this very useful for some of my use-cases. >=20 > * Decide whether to move the JWK algorithm family definitions "EC" and= "RSA" here. This would likely result in all the family-specific parameter = definitions also moving here ("crv", "x", "y", "mod", "exp"), leaving very = little normative text in the JWK spec itself. This seems like it would redu= ce spec readability and so was not done. > After discussion, unless the WG disagrees, I propose to delete this open = issue. >=20 I personally don't see a problem with moving them, as long as there's plent= y of (expanded) examples in the affected specs. - m&m Matt Miller - Cisco Systems, Inc. From Michael.Jones@microsoft.com Sat May 12 17:23: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 4559A21F86CE for ; Sat, 12 May 2012 17:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.394 X-Spam-Level: X-Spam-Status: No, score=-5.394 tagged_above=-999 required=5 tests=[AWL=1.205, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJPafiSlAsA7 for ; Sat, 12 May 2012 17:23:21 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id A630021F86C7 for ; Sat, 12 May 2012 17:23:21 -0700 (PDT) Received: from mail77-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id 14.1.225.23; Sun, 13 May 2012 00:23:19 +0000 Received: from mail77-tx2 (localhost [127.0.0.1]) by mail77-tx2-R.bigfish.com (Postfix) with ESMTP id F24CF4402F8; Sun, 13 May 2012 00:23:18 +0000 (UTC) X-SpamScore: -27 X-BigFish: VS-27(zz9371I542M1447Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail77-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail77-tx2 (localhost.localdomain [127.0.0.1]) by mail77-tx2 (MessageSwitch) id 1336868597174433_29957; Sun, 13 May 2012 00:23:17 +0000 (UTC) Received: from TX2EHSMHS006.bigfish.com (unknown [10.9.14.247]) by mail77-tx2.bigfish.com (Postfix) with ESMTP id 2774648004E; Sun, 13 May 2012 00:23:17 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS006.bigfish.com (10.9.99.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 13 May 2012 00:23:17 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0298.005; Sun, 13 May 2012 00:23:18 +0000 From: Mike Jones To: "Frederick.Hirsch@nokia.com" , "jose@ietf.org" Thread-Topic: [jose] JSON Web Signature, Encryption comment, signature best practices Thread-Index: AQHNAfe9cbRw9NVIkUet0eQv9oaLwZbFyAcw Date: Sun, 13 May 2012 00:23:17 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943664F197F@TK5EX14MBXC284.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] JSON Web Signature, Encryption comment, signature best practices 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, 13 May 2012 00:23:22 -0000 Hi Frederick, Done in the just-published -02 versions of the JOSE specs. Thanks for the = feedback. (More on the new drafts would also be welcome! :-) ) -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Fre= derick.Hirsch@nokia.com Sent: Wednesday, March 14, 2012 8:33 AM To: jose@ietf.org Cc: Frederick.Hirsch@nokia.com Subject: [jose] JSON Web Signature, Encryption comment, signature best prac= tices Hi You might wish to add an informative reference to XML Signature 1.1 to the= JSON web signature draft (similar to having informative reference to XML E= ncryption 1.1 in JSON encryption draft). [XMLDSIG-CORE1] D. Eastlake, J. Reagle, D. Solo, F. Hirsch, T. Roessler, K. Yiu. XML Signat= ure Syntax and Processing Version 1.1. 3 March 2011. W3C Candidate Recommen= dation. (Work in progress.) URL: http://www.w3.org/TR/2011/CR-xmldsig-core1= -20110303/ The XML Encryption 1.1 reference should be updated [XMLENC-CORE1] J. Reagle; D. Eastlake; F. Hirsch; T. Roessler. XML Encryption Syntax and P= rocessing Version 1.1. 13 March 2012. W3C Candidate Recommendation. (Work i= n progress.) URL: http://www.w3.org/TR/2012/CR-xmlenc-core1-20120313/ In addition, it might be useful to reference the XML Signature Best Practi= ces document, as similar issues may apply to JSON signing [XMLDSIG-BESTPRACTICES] Pratik Datta; Frederick Hirsch. XML Signature Best Practices. 9 August 2011= . W3C Working Draft. (Work in progress.) URL:http://www.w3.org/TR/2011/WD-x= mldsig-bestpractices-20110809/ regards, Frederick Frederick Hirsch, Nokia Chair XML Security WG _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Sat May 12 17:24: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 5C38C21F86C8 for ; Sat, 12 May 2012 17:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.411 X-Spam-Level: X-Spam-Status: No, score=-5.411 tagged_above=-999 required=5 tests=[AWL=1.187, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqUijYiDhLRd for ; Sat, 12 May 2012 17:24:11 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0133521F86CE for ; Sat, 12 May 2012 17:24:11 -0700 (PDT) Received: from mail148-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Sun, 13 May 2012 00:24:08 +0000 Received: from mail148-tx2 (localhost [127.0.0.1]) by mail148-tx2-R.bigfish.com (Postfix) with ESMTP id 5DE8EA0215; Sun, 13 May 2012 00:24:08 +0000 (UTC) X-SpamScore: -29 X-BigFish: VS-29(zz9371Ic85fh542M1418I111aI1447Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h) 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 Received-SPF: pass (mail148-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail148-tx2 (localhost.localdomain [127.0.0.1]) by mail148-tx2 (MessageSwitch) id 1336868644963462_13507; Sun, 13 May 2012 00:24:04 +0000 (UTC) Received: from TX2EHSMHS043.bigfish.com (unknown [10.9.14.235]) by mail148-tx2.bigfish.com (Postfix) with ESMTP id E7216180128; Sun, 13 May 2012 00:24:04 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS043.bigfish.com (10.9.99.143) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 13 May 2012 00:24:04 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0298.005; Sun, 13 May 2012 00:24:05 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: [jose] Comments on draft-ietf-jose-json-web-key-01 Thread-Index: Ac0YFumdEsd+H7NuSBmmwJ3ugtJ7YwLQf9TwAVp/jIAB7BrbEA== Date: Sun, 13 May 2012 00:24:04 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943664F19B8@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <01f401cd181e$ab37d1a0$01a774e0$@augustcellars.com> <4E1F6AAD24975D4BA5B168042967394366499F0B@TK5EX14MBXC284.redmond.corp.microsoft.com> <022c01cd28c2$e807e390$b817aab0$@augustcellars.com> In-Reply-To: <022c01cd28c2$e807e390$b817aab0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943664F19B8TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Comments on draft-ietf-jose-json-web-key-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, 13 May 2012 00:24:13 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943664F19B8TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, I've applied your recommendations in the just-published -02 JOSE drafts. T= hanks again for taking the time to provide the detailed critique. I believ= e the text is much improved and more usable as a result! -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Wednesday, May 02, 2012 5:23 PM To: Mike Jones Cc: jose@ietf.org Subject: RE: [jose] Comments on draft-ietf-jose-json-web-key-01 From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Wednesday, April 25, 2012 9:22 PM To: Jim Schaad Cc: jose@ietf.org Subject: RE: [jose] Comments on draft-ietf-jose-json-web-key-01 Thanks for the detailed comments, as always, Jim. Replies inline... -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Jim Schaa= d Sent: Wednesday, April 11, 2012 1:07 PM To: Mike Jones Cc: jose@ietf.org Subject: [jose] Comments on draft-ietf-jose-json-web-key-01 11. Should the text that is in the signature and encryption dealing with a= dding fields (urls vs simple names) be included in this section as well? Are you thinking of the text about the three classes of names: reserved, p= rivate, and public? With the possibility of a registry? What do people in= the working group think? I think the chances of this object being extende= d are small, especially since we only define one member. But then, it's in= credibly hard to predict how a standard will be used, if successful. I'd b= e more prone to think that extension made sense if the spec defined more th= an one member. Yes that was what I was thinking of. If we are going to say don't add thi= ngs willy-nilly then we should probably have text saying how to add things = safely. 12. Should there be an IANA registry for the member names of a container o= bject. Per 11, I don't think so. I think this case is better handled by the stand= ard JSON "you can add fields if you understand them" logic. Cost of a registry is low if we think that the IETF is going to want to add= things then we should setup the registry now. JWK Key Object Format: 18. Should the text dealing with adding members be present (copied from JW= S)? Is it just the key and not the entire key set that is to be ignored? Again, are you thinking the reserved/private/public treatment? With a regi= stry? Or maybe just a registry? I didn't find "ignore" in the draft, so I= 'm not sure what the second sentence in your remarks is referring to. The text for Key Object says that if additional members are present they MU= ST be understood - hence if not understood the Key Object MUST NOT be used.= The question is does this propagate up to the Key Container? Open Issues: 19. I think that a section on adding key families would be reasonable. Yes, probably in JWA. I think this would be better here - specifically requirements on what must = be added to put something into the alg registry. Jim Thanks again, -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943664F19B8TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim,

 

I’ve applied you= r recommendations in the just-published -02 JOSE drafts.  Thanks again= for taking the time to provide the detailed critique.  I believe the = text is much improved and more usable as a result!

 

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

 

From: Jim Scha= ad [mailto:ietf@augustcellars.com]
Sent: Wednesday, May 02, 2012 5:23 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: RE: [jose] Comments on draft-ietf-jose-json-web-key-01=

 

 

 

From: Mike Jon= es [mailto:Michael.Jon= es@microsoft.com]
Sent: Wednesday, April 25, 2012 9:22 PM
To: Jim Schaad
Cc: jose@ietf.org
Subject: RE: [jose] Comments on draft-ietf-jose-json-web-key-01=

 

Thanks for the detaile= d comments, as always, Jim.  Replies inline…

 

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Wednesday, April 11, 2012 1:07 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: [jose] Comments on draft-ietf-jose-json-web-key-01

 

<no hat>

 

11.  Should the t= ext that is in the signature and encryption dealing with adding fields (url= s vs simple names) be included in this section as well?

 

Are you thinking of th= e text about the three classes of names:  reserved, private, and publi= c?  With the possibility of a registry?  What do people in the wo= rking group think?  I think the chances of this object being extended are small, especially since we only define one member. = ; But then, it’s incredibly hard to predict how a standard will be us= ed, if successful.  I’d be more prone to think that extension ma= de sense if the spec defined more than one member.

 

Yes that was what I wa= s thinking of.   If we are going to say don’t add things wi= lly-nilly then we should probably have text saying how to add things safely= .

 

12.  Should there= be an IANA registry for the member names of a container object.=

 

Per 11, I don’t = think so.  I think this case is better handled by the standard JSON &#= 8220;you can add fields if you understand them” logic.

 

Cost of a registry is = low if we think that the IETF is going to want to add things then we should=  setup the registry now.

 

JWK Key Object Format:=

 

18.  Should the t= ext dealing with adding members be present (copied from JWS)?  Is it j= ust the key and not the entire key set that is to be ignored?

 

Again, are you thinkin= g the reserved/private/public treatment?  With a registry?  Or ma= ybe just a registry?  I didn’t find “ignore” in the = draft, so I’m not sure what the second sentence in your remarks is re= ferring to.

 

The text for Key Objec= t says that if additional members are present they MUST be understood ̵= 1; hence if not understood the Key Object MUST NOT be used.  The quest= ion is does this propagate up to the Key Container?

 

Open Issues:

 

19.  I think that= a section on adding key families would be reasonable.

 

Yes, probably in JWA.<= o:p>

 

I think this would be = better here – specifically requirements on what must be added to put = something into the alg registry.

 

 

Jim

 

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

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943664F19B8TK5EX14MBXC284r_-- From Michael.Jones@microsoft.com Sat May 12 17:24: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 E4E2A9E8008 for ; Sat, 12 May 2012 17:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.928 X-Spam-Level: X-Spam-Status: No, score=-3.928 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5eFZizH8rhl for ; Sat, 12 May 2012 17:24:23 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id D101021F86C8 for ; Sat, 12 May 2012 17:24:22 -0700 (PDT) Received: from mail4-db3-R.bigfish.com (10.3.81.252) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Sun, 13 May 2012 00:09:03 +0000 Received: from mail4-db3 (localhost [127.0.0.1]) by mail4-db3-R.bigfish.com (Postfix) with ESMTP id 3EC6D18019C for ; Sun, 13 May 2012 00:09:03 +0000 (UTC) X-SpamScore: -20 X-BigFish: VS-20(zzc85fhzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail4-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail4-db3 (localhost.localdomain [127.0.0.1]) by mail4-db3 (MessageSwitch) id 1336867741460964_13924; Sun, 13 May 2012 00:09:01 +0000 (UTC) Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.249]) by mail4-db3.bigfish.com (Postfix) with ESMTP id 6C8C660053 for ; Sun, 13 May 2012 00:09:01 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 13 May 2012 00:09:00 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0298.005; Sun, 13 May 2012 00:09:00 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Draft -02 of JSON Crypto Specs: JWS, JWE, JWK, JWA Thread-Index: Ac0wnJNnnN9jpblpRpGKmgusm4TcEg== Date: Sun, 13 May 2012 00:08:59 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943664F18ED@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943664F18EDTK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [jose] Draft -02 of JSON Crypto Specs: JWS, JWE, JWK, JWA 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, 13 May 2012 00:24:28 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943664F18EDTK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New -02 versions of the JSON Object Signing and Encryption (JOSE) specifications are now available that incorpor= ate working decisions made since the previous versions, including decisions= made at IETF 83 in Paris and in follow-up discussions on the working group= list. The drafts contain numerous clarifications, refinements, and editor= ial improvements. They are: * JSON Web Signature (JWS) - Digital signature/HMAC specification * JSON Web Encryption (JWE) - Encryption specification * JSON Web Key (JWK) - Public key specification * JSON Web Algorithms (JWA) - Algorithms and identifiers specificati= on These specifications are available at: * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-02 * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-02 * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-02 * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-02 The document history entries (also in the specifications) are as follows: http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-02: * Clarified that it is an error when a kid value is included and no mat= ching key is found. * Removed assumption that kid (key ID) can only refer to an asymmetric = key. * Clarified that JWSs with duplicate Header Parameter Names MUST be rej= ected. * Clarified the relationship between typ header parameter values and MI= ME types. * Registered application/jws MIME type and "JWS" typ header parameter v= alue. * Simplified JWK terminology to get replace the "JWK Key Object" and "J= WK Container Object" terms with simply "JSON Web Key (JWK)" and "JSON Web K= ey Set (JWK Set)" and to eliminate potential confusion between single keys = and sets of keys. As part of this change, the header parameter name for a p= ublic key value was changed from jpk (JSON Public Key) to jwk (JSON Web Key= ). * Added suggestion on defining additional header parameters such as x5t= #S256 in the future for certificate thumbprints using hash algorithms other= than SHA-1. * Specify RFC 2818 server identity validation, rather than RFC 6125 (pa= ralleling the same decision in the OAuth specs). * Generalized language to refer to Message Authentication Codes (MACs) = rather than Hash-based Message Authentication Codes (HMACs) unless in a con= text specific to HMAC algorithms. * Reformatted to give each header parameter its own section heading. http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-02: * When using AEAD algorithms (such as AES GCM), use the "additional aut= henticated data" parameter to provide integrity for the header, encrypted k= ey, and ciphertext and use the resulting "authentication tag" value as the = JWE Integrity Value. * Defined KDF output key sizes. * Generalized text to allow key agreement to be employed as an alternat= ive to key wrapping or key encryption. * Changed compression algorithm from gzip to DEFLATE. * Clarified that it is an error when a kid value is included and no mat= ching key is found. * Clarified that JWEs with duplicate Header Parameter Names MUST be rej= ected. * Clarified the relationship between typ header parameter values and MI= ME types. * Registered application/jwe MIME type and "JWE" typ header parameter v= alue. * Simplified JWK terminology to get replace the "JWK Key Object" and "J= WK Container Object" terms with simply "JSON Web Key (JWK)" and "JSON Web K= ey Set (JWK Set)" and to eliminate potential confusion between single keys = and sets of keys. As part of this change, the header parameter name for a p= ublic key value was changed from jpk (JSON Public Key) to jwk (JSON Web Key= ). * Added suggestion on defining additional header parameters such as x5t= #S256 in the future for certificate thumbprints using hash algorithms other= than SHA-1. * Specify RFC 2818 server identity validation, rather than RFC 6125 (pa= ralleling the same decision in the OAuth specs). * Generalized language to refer to Message Authentication Codes (MACs) = rather than Hash-based Message Authentication Codes (HMACs) unless in a con= text specific to HMAC algorithms. * Reformatted to give each header parameter its own section heading. http://tools.ietf.org/html/draft-ietf-jose-json-web-key-02: * Simplified JWK terminology to get replace the "JWK Key Object" and "J= WK Container Object" terms with simply "JSON Web Key (JWK)" and "JSON Web K= ey Set (JWK Set)" and to eliminate potential confusion between single keys = and sets of keys. As part of this change, the top-level member name for a s= et of keys was changed from jwk to keys. * Clarified that values with duplicate member names MUST be rejected. * Established JSON Web Key Set Parameters registry. * Explicitly listed non-goals in the introduction. * Moved algorithm-specific definitions from JWK to JWA. * Reformatted to give each member definition its own section heading. http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-02: * For AES GCM, use the "additional authenticated data" parameter to pro= vide integrity for the header, encrypted key, and ciphertext and use the re= sulting "authentication tag" value as the JWE Integrity Value. * Defined minimum required key sizes for algorithms without specified k= ey sizes. * Defined KDF output key sizes. * Specified the use of PKCS #5 padding with AES-CBC. * Generalized text to allow key agreement to be employed as an alternat= ive to key wrapping or key encryption. * Clarified that ECDH-ES is a key agreement algorithm. * Required implementation of AES-128-KW and AES-256-KW. * Removed the use of A128GCM and A256GCM for key wrapping. * Removed A512KW since it turns out that it's not a standard algorithm. * Clarified the relationship between typ header parameter values and MI= ME types. * Generalized language to refer to Message Authentication Codes (MACs) = rather than Hash-based Message Authentication Codes (HMACs) unless in a con= text specific to HMAC algorithms. * Established registries: JSON Web Signature and Encryption Header Para= meters, JSON Web Signature and Encryption Algorithms, JSON Web Signature an= d Encryption "typ" Values, JSON Web Key Parameters, and JSON Web Key Algori= thm Families. * Moved algorithm-specific definitions from JWK to JWA. * Reformatted to give each member definition its own section heading. -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943664F18EDTK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

New -02 versions of the JSON Object Signing and Encryption (JOSE) specifications are now availa= ble that incorporate working decisions made since the previous versions, in= cluding decisions made at IETF 83 in Paris and in follow-up discussions on = the working group list.  The drafts contain numerous clarifications, refinements, and editorial improvements.&= nbsp; They are:

·        JSON Web Signature (JWS) – Digital sig= nature/HMAC specification

·        JSON Web Encryption (JWE) – Encryption= specification

·        JSON Web Key (JWK) – Public key specif= ication

·        JSON Web Algorithms (JWA) – Algorithms= and identifiers specification

 

These specifications are available at:

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

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

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

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

 

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

 

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

  • Clarified that it is an error when a kid value is included and no matching key is found= .
  • Removed assumption that kid (key ID) can only refer to an asymmetric key.
  • Clarified that JWSs with duplicate Header Paramet= er Names MUST be rejected.
  • Clarified the relationship between typ header parameter values and MIME types.
  • Registered application/jws MIME type and "JW= S" typ header parameter value.
  • Simplified JWK terminology to get replace the &qu= ot;JWK Key Object" and "JWK Container Object" terms with sim= ply "JSON Web Key (JWK)" and "JSON Web Key Set (JWK Set)" and to eliminate potential confusio= n between single keys and sets of keys. As part of this change, the header = parameter name for a public key value was changed from jpk (JSON Public Key) to jwk (JSON Web Key).
  • Added suggestion on defining additional header pa= rameters such as x5t#S256 in the future for certificate thumbprints= using hash algorithms other than SHA-1.
  • Specify RFC 2818 server identity validation, rath= er than RFC 6125 (paralleling the same decision in the OAuth specs).
  • Generalized language to refer to Message Authenti= cation Codes (MACs) rather than Hash-based Message Authentication Codes (HM= ACs) unless in a context specific to HMAC algorithms.
  • Reform= atted to give each header parameter its own section heading.

 

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

  • When using AEAD algorithms (such as AES GCM), use the "additional a= uthenticated data" parameter to provide integrity for the header, encrypted key, and ciphertext and use the resulting "authentication t= ag" value as the JWE Integrity Value.
  • Defined KDF output key sizes.
  • Generalized text to allow key agreement to be emp= loyed as an alternative to key wrapping or key encryption.
  • Changed compression algorithm from gzip to DEFLAT= E.
  • Clarified that it is an error when a kid value is included and no matching key is found= .
  • Clarified that JWEs with duplicate Header Paramet= er Names MUST be rejected.
  • Clarified the relationship between typ header parameter values and MIME types.
  • Registered application/jwe MIME type and "JW= E" typ header parameter value.
  • Simplified JWK terminology to get replace the &qu= ot;JWK Key Object" and "JWK Container Object" terms with sim= ply "JSON Web Key (JWK)" and "JSON Web Key Set (JWK Set)" and to eliminate potential confusio= n between single keys and sets of keys. As part of this change, the header = parameter name for a public key value was changed from jpk (JSON Public Key) to jwk (JSON Web Key).
  • Added suggestion on defining additional header pa= rameters such as x5t#S256 in the future for certificate thumbprints= using hash algorithms other than SHA-1.
  • Specify RFC 2818 server identity validation, rath= er than RFC 6125 (paralleling the same decision in the OAuth specs).
  • Generalized language to refer to Message Authenti= cation Codes (MACs) rather than Hash-based Message Authentication Codes (HM= ACs) unless in a context specific to HMAC algorithms.
  • Reform= atted to give each header parameter its own section heading.

 

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

  • Simplified JWK terminology to get replace the "JWK Key Object"= and "JWK Container Object" terms with simply "JSON Web Key = (JWK)" and "JSON Web Key Set (JWK Set)" and to eliminate potential confusio= n between single keys and sets of keys. As part of this change, the top-lev= el member name for a set of keys was changed from jwk to keys.
  • Clarified that values with duplicate member names= MUST be rejected.
  • Established JSON Web Key Set Parameters registry.
  • Explicitly listed non-goals in the introduction.
  • Moved algorithm-specific definitions from JWK to = JWA.
  • Reformatted to give each member definition its ow= n section heading.

 

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

  • For AES GCM, use the "additional authenticated data" parameter= to provide integrity for the header, encrypted key, and ciphertext and use the resulting "authentication tag" value as the JWE Integrit= y Value.
  • Defined minimum required key sizes for a= lgorithms without specified key sizes.
  • Defined KDF output key sizes.
  • Specified the use of PKCS #5 padding with AES-CBC= .
  • Generalized text to allow key agreement to be emp= loyed as an alternative to key wrapping or key encryption.
  • Clarified that ECDH-ES is a key agreement algorit= hm.
  • Required implementation of AES-128-KW and AES-256= -KW.
  • Removed the use of A128GCM and A256GCM for key wrapping.
  • Removed A512KW since it turns out that it's not a standard= algorithm.
  • Clarified the relationship between typ header parameter values and MIME types.
  • Generalized language to refer to Message Authenti= cation Codes (MACs) rather than Hash-based Message Authentication Codes (HM= ACs) unless in a context specific to HMAC algorithms.
  • Establ= ished registries: JSON Web Signature and Encryption Header Parameters, JSON= Web Signature and Encryption Algorithms, JSON Web Signature and Encryption "typ" Values, JSON Web Key Parameters, = and JSON Web Key Algorithm Families.
  • Moved algorithm-specific definitions from JWK to = JWA.
  • Reformatted to give each member definition its ow= n section heading.

 

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943664F18EDTK5EX14MBXC284r_-- From Michael.Jones@microsoft.com Sat May 12 17:24: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 1673D9E8020 for ; Sat, 12 May 2012 17:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.423 X-Spam-Level: X-Spam-Status: No, score=-5.423 tagged_above=-999 required=5 tests=[AWL=1.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DlqXOsXgeAa for ; Sat, 12 May 2012 17:24:25 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id B26999E8007 for ; Sat, 12 May 2012 17:24:25 -0700 (PDT) Received: from mail145-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id 14.1.225.23; Sun, 13 May 2012 00:24:23 +0000 Received: from mail145-tx2 (localhost [127.0.0.1]) by mail145-tx2-R.bigfish.com (Postfix) with ESMTP id 02F843A0274; Sun, 13 May 2012 00:24:23 +0000 (UTC) X-SpamScore: -28 X-BigFish: VS-28(zz9371Ic85fh1418I111aI1486Mzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail145-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail145-tx2 (localhost.localdomain [127.0.0.1]) by mail145-tx2 (MessageSwitch) id 1336868660418680_2413; Sun, 13 May 2012 00:24:20 +0000 (UTC) Received: from TX2EHSMHS029.bigfish.com (unknown [10.9.14.240]) by mail145-tx2.bigfish.com (Postfix) with ESMTP id 57B47300131; Sun, 13 May 2012 00:24:20 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS029.bigfish.com (10.9.99.129) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 13 May 2012 00:24:20 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0298.005; Sun, 13 May 2012 00:24:21 +0000 From: Mike Jones To: Jim Schaad Thread-Topic: [jose] Comments on the -03 JSON Web Signature document Thread-Index: AcydAC1ZyMCYdH1nSHiQnx6fNbxIaRLO7MzAAFTZDoARlYxiEA== Date: Sun, 13 May 2012 00:24:20 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943664F19C4@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <017201cca118$5883ee30$098bca90$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436639FDA8@TK5EX14MBXC284.redmond.corp.microsoft.com> <01a701cce94c$37355490$a59ffdb0$@augustcellars.com> In-Reply-To: <01a701cce94c$37355490$a59ffdb0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943664F19C4TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Comments on the -03 JSON Web Signature document 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, 13 May 2012 00:24:31 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943664F19C4TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, Many of your recommendations below were incorporated in the just-published = -02 versions of the JOSE specs (and some were already incorporated into the= -01 versions). I'd appreciate it if you could have a look at the new text= covering these. Thanks again for the review. I didn't come up with better wording for the "key associated with the party= that digitally signed or MACed the content" issue for the "alg" header par= ameter, so that's still unresolved. There's an important semantic concept = (being able to validate that the right party signed the JWS!) and I recogni= ze that the current wording is perfect. I'd welcome suggestions for differ= ent proposed text by the working group. Thanks again, -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Saturday, February 11, 2012 10:05 PM To: Mike Jones Cc: jose@ietf.org Subject: RE: [jose] Comments on the -03 JSON Web Signature document None interesting things have been removed. Jim From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, February 10, 2012 2:28 PM To: Jim Schaad; draft-jones-json-web-signature@tools.ietf.org Cc: jose@ietf.org Subject: RE: [jose] Comments on the -03 JSON Web Signature document This note replies the comments from your note where the resolutions to them= were incomplete or different than you proposed. Per our e-mail exchange, = I won't clutter the discussion by replying to comments whose resolutions ar= e already incorporated into the working group drafts. 1. I have a personal problem with the fact that the draft is still named "= JSON Web Signature" rather than something like "JSON Integrity Objects". I= doubt that I am the only person who has this issue given the number of peo= ple who gave opinions during the charter discussion and the resulting chart= er description "JSON-structured integrity protection to data". This become= s a major re-write of the document internally as well. Per discussion that occurred within the WG after the Taipei meeting on the = list, for the same reasons that the WG uses the term "signature", the spec = continues to use the vernacular term "signature" as the most readable of th= e choices in the title. For instance, see http://www.ietf.org/mail-archive= /web/jose/current/msg00315.html and http://www.ietf.org/mail-archive/web/jo= se/current/msg00309.html. That being said, the terminology within the spec= s has been changed to no longer call both digital signatures and HMACs "sig= natures", and so I believe is now correct throughout. [JLS] I disagree with this, but am not going to fight this issue at this ti= me. 16. The text states that the key must be associated with the signer of the content. The current document for json keys does not have any way of associating a key with the signer. What does this requirement really mean? It's intended to mean that there must be a way to verify that the content w= as signed by the correct party, using a key controlled by that party. I'd = welcome better language for this concept (possibly lifted from another cryp= to spec?). [JLS] I have a problem with the statement both in the original text and ab= ove. If we are looking at a bare key for doing the validation, we have no = idea who the correct party is in general. The fact that the key was found= at https://example.com/Tom_Piperson does not tell me without other informa= tion who the key is associated with. Going back and re-reading the MUST st= atement I think that it could be removed entirely. I am not sure that I ev= en understand what the test should be for an interop matrix. If the algori= thm is understood by the sender and not the validator is the MUST violated?= Is processing a sender or a validator function or both? If I were to suc= cessfully forge a message, would the MUST still be true? 18. It would be useful to know if there was going to be any registry for t= he "typ" header. If not, then it would be useful to state that the values = of the "typ" header are based on agreement between the parties. It would a= lso be useful to state the expected behavior in the case the the value of t= he typ field is either unknown, does not match the expected value or is mis= sing. Are values of the "typ" field supposed to have the same type of publ= ic/private values as does algorithm? If not what happens when a collision = exists between two different applications? Per my comments on the open issues listed in the drafts, an argument can be= made for deleting this parameter from the JWS spec entirely and leaving it= s definition up to profile specs like JWT. If this isn't done, then a regi= stry could be considered for names not residing in a collision-resistant na= mespace. [JLS] If it is believe that a parameter this list is going to be "commonly"= used by many different profilers, then I believe that the core items needs= to be done the in the base specification. I would therefore not be in fav= or of punting it out to somebody else. The only exception would be if we a= re going to have a very light core and a "real" core specs. In this case t= he very light core spec could punt to the "real" core spec. Having said th= at I think that a registry would be a good idea. 23. Having done a much more detailed read. The last para in section 4.2 c= an be expanded as follows: New header parameters should be introduced sparingly, an implementation whi= ch does not understand a newly introduced parameter will fail validate of t= he JWS. However, uses which use the JWS structure but define additional se= mantics, such as the JSON Web Token usage, are expected to define additiona= l public header parameters. The first concept (must-understand of header parameters) is already in the = second sentence of the description of header parameters (in Section 4). I = could however, add the sentence "However, it is expected that some addition= al header parameters will be defined by specific profiles and specification= s using this specification" to cover the second point, if that works for yo= u. [JLS] I see no problems with re-iterating why it is a problem, but would n= ot insist on it. Telling people that it breaks is usually insufficient, t= elling them why it breaks means they have a starting place to look for prob= lems. 24. Why MUST I do the following steps (since to me this implies an order o= f operations). Is there a reason that I cannot do things in the order of 3= , 4, 5, 1, 2, 6, 7? Reordered and partially rewrote to be more logical. Please review. [JLS] Sorry, my core problem was insufficiently defined in my message. My = problem is that the order of the steps is NOT NORMATIVE. The result needs = to be the same as the steps given, but the order that I do things can be an= ything that works for me. [JLS] In step 3 is there a reason that I cannot perform canonicalization? = The current text explicitly forbids it. [JLS] Having followed and read RFC4627 - I note that a JSON object IS perm= itted to have the same member name listed twice. No restriction about if t= he values are required to be the same. [JLS] For decode - I think that step 5 should be folded into the text for s= tep 1. [JLS] I would suggest that section 5 be sub-divided - one for creation and = one for validation. [JLS] I think that I am having some problems with the fact that the validat= ion process apparently is now totally based on the alg being used and does = not have any reliance on this specification. At a minimum the text in val= idate step 6 needs to say that the input for processing is the concatenatio= n of .... 21, Section 6.1 - The last para states that there is a correspondingly long= er key and result. While the result is going to be longer, there is no req= uirement that the key be longer unless you are going to make a statement to= that effect. One could use a 512 bit key for all of the algorithms. I believe that this statement is true for the HS256, HS384, and HS512 algor= ithms, but I agree that it's not particularly enabling. I'll put describin= g the expected key sizes for all the algorithms on my to-do list. [JLS] Where did this text wander off to? Some place in JWA? --_000_4E1F6AAD24975D4BA5B1680429673943664F19C4TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim,

 

Many of your recommendations below were incorpora= ted in the just-published -02 versions of the JOSE specs (and some were alr= eady incorporated into the -01 versions).  I'd appreciate it if you co= uld have a look at the new text covering these.  Thanks again for the review.

 

I didn’t come up with better wording for th= e “key associated with the party that digitally signed or MACed the c= ontent” issue for the “alg” header parameter, so thatR= 17;s still unresolved.  There’s an important semantic concept (b= eing able to validate that the right party signed the JWS!) and I recognize that the= current wording is perfect.  I’d welcome suggestions for differ= ent proposed text by the working group.

 

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

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

 

From: Jim Scha= ad [mailto:ietf@augustcellars.com]
Sent: Saturday, February 11, 2012 10:05 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: RE: [jose] Comments on the -03 JSON Web Signature document<= o:p>

 

<NO HAT>

 

None interesting thing= s have been removed.

 

Jim<= /p>

 

 

From: Mike Jon= es [mailto:Michael.Jon= es@microsoft.com]
Sent: Friday, February 10, 2012 2:28 PM
To: Jim Schaad; draft-jones-json-web-signature@tools.ietf.org
Cc: jose@ietf.org
Subject: RE: [jose] Comments on the -03 JSON Web Signature document<= o:p>

 

This note replies the = comments from your note where the resolutions to them were incomplete or di= fferent than you proposed.  Per our e-mail exchange, I won’t clu= tter the discussion by replying to comments whose resolutions are already incorporated into the working group drafts.

 

1.  I have a personal problem with the fact = that the draft is still named "JSON Web Signature" rather than so= mething like "JSON Integrity Objects".  I doubt that I am th= e only person who has this issue given the number of people who gave opinions during the charter discussion and the resulting charter desc= ription "JSON-structured integrity protection to data".  Thi= s becomes a major re-write of the document internally as well.

 

Per discussion that oc= curred within the WG after the Taipei meeting on the list, for the same rea= sons that the WG uses the term “signature”, the spec continues = to use the vernacular term “signature” as the most readable of the choices in the title.  For instance, see http://www.ietf.org/mail-archive/web/jose/current/msg00315.html and http://www.ietf.org/mail-archive/web/jose/current/msg00309.html.  = That being said, the terminology within the specs has been changed to no lo= nger call both digital signatures and HMACs "signatures", and so = I believe is now correct throughout.

 

[JLS] I disagree with = this, but am not going to fight this issue at this time.<= /p>

 

16.  The text states that the key must be as= sociated with the signer of the

content.   The current document for jso= n keys does not have any way of

associating a key with the signer.  What doe= s this requirement really mean?

 

It’s intended to= mean that there must be a way to verify that the content was signed by the= correct party, using a key controlled by that party.  I’d welco= me better language for this concept (possibly lifted from another crypto spec?).

 

[JLS]  I have a p= roblem with the statement both in the original text and above.  If we = are looking at a bare key for doing the validation, we have no idea who the= correct party is in general.   The fact that the key was found at https://= example.com/Tom_Piperson does not tell me without other information who= the key is associated with.  Going back and re-reading the MUST state= ment I think that it could be removed entirely.  I am not sure that I even understand what the test should be for an intero= p matrix.  If the algorithm is understood by the sender and not the va= lidator is the MUST violated?  Is processing a sender or a validator f= unction or both?  If I were to successfully forge a message, would the MUST still be true? 

 

18.  It would be useful to know if there was= going to be any registry for the "typ" header.  If not, the= n it would be useful to state that the values of the "typ" header= are based on agreement between the parties.  It would also be useful to state the expected behavior in the case the the value of the typ field = is either unknown, does not match the expected value or is missing.  A= re values of the "typ" field supposed to have the same type of pu= blic/private values as does algorithm?  If not what happens when a collision exists between two different applications?

 

Per my comments on the= open issues listed in the drafts, an argument can be made for deleting thi= s parameter from the JWS spec entirely and leaving its definition up to pro= file specs like JWT.  If this isn’t done, then a registry could be considered for names not residing in a coll= ision-resistant namespace.

 

[JLS] If it is believe= that a parameter this list is going to be “commonly” used by m= any different profilers, then I believe that the core items needs to be don= e the in the base specification.  I would therefore not be in favor of punting it out to somebody else.  The only excepti= on would be if we are going to have a very light core and a “realR= 21; core specs.  In this case the very light core spec could punt to t= he “real” core spec.  Having said that I think that a registry would be a good idea.

 

23.  Having done a much more detailed read.&= nbsp; The last para in section 4.2 can be expanded as follows:

 

New header parameters should be introduced sparin= gly, an implementation which does not understand a newly introduced paramet= er will fail validate of the JWS.  However, uses which use the JWS str= ucture but define additional semantics, such as the JSON Web Token usage, are expected to define additional public= header parameters.

 

The first concept (mus= t-understand of header parameters) is already in the second sentence of the= description of header parameters (in Section 4).  I could however, ad= d the sentence “However, it is expected that some additional header parameters will be defined by specific profiles and= specifications using this specification” to cover the second point, = if that works for you.

 

[JLS]  I see no p= roblems with re-iterating why it is a problem, but would not insist on it.&= nbsp; Telling people that it  breaks is usually insufficient, telling = them why it breaks means they have a starting place to look for problems.

 

24.  Why MUST I do the following steps (sinc= e to me this implies an order of operations).  Is there a reason that = I cannot do things in the order of 3, 4, 5, 1, 2, 6, 7?

 

Reordered and partiall= y rewrote to be more logical.  Please review.

 

[JLS] Sorry, my core p= roblem was insufficiently defined in my message.  My problem is that t= he order of the steps is NOT NORMATIVE.  The result needs to be the sa= me as the steps given, but the order that I do things can be anything that works for me.

 

[JLS] In step 3 is the= re a reason that I cannot perform canonicalization?  The current text = explicitly forbids it.

 

[JLS] Having followed = and read RFC4627 – I note that a JSON  object IS permitted to ha= ve the same member name listed twice.  No restriction about if the val= ues are required to be the same.

 

[JLS] For decode ̵= 1; I think that step 5 should be folded into the text for step 1.

 

[JLS] I would suggest = that section 5 be sub-divided – one for creation and one for validati= on.

 

[JLS] I think that I a= m having some problems with the fact that the validation process apparently= is now totally based on the alg being used and does not have any reliance = on this specification.   At a minimum the text in validate step 6 needs to say that the input for processing is = the concatenation of ….

 

21, Section 6.1 - The last para states that there= is a correspondingly longer key and result.  While the result is goin= g to be longer, there is no requirement that the key be longer unless you a= re going to make a statement to that effect.  One could use a 512 bit key for all of the algorithms.

 

I believe that this st= atement is true for the HS256, HS384, and HS512 algorithms, but I agree that it= ’s not particularly enabling.  I’ll put describing the exp= ected key sizes for all the algorithms on my to-do list.<= /p>

 

[JLS] Where did this t= ext wander off to?  Some place in JWA?

 

 

--_000_4E1F6AAD24975D4BA5B1680429673943664F19C4TK5EX14MBXC284r_-- From ietf@augustcellars.com Sun May 13 09:00: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 C68D121F850F for ; Sun, 13 May 2012 09:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8l4a0Ag7io2 for ; Sun, 13 May 2012 09:00:57 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 4031B21F8505 for ; Sun, 13 May 2012 09:00:57 -0700 (PDT) Received: from Tobias (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 0EA5938EF0 for ; Sun, 13 May 2012 09:00:56 -0700 (PDT) From: "Jim Schaad" To: References: <20120512234350.9160.80183.idtracker@ietfa.amsl.com> In-Reply-To: <20120512234350.9160.80183.idtracker@ietfa.amsl.com> Date: Sun, 13 May 2012 08:59:54 -0700 Message-ID: <029c01cd3121$706fcf70$514f6e50$@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: AQKI2fceYwu2GM7CvTOI2NJ/vJnH6JVQjqsQ Content-Language: en-us Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 16:00:57 -0000 In scanning this document I came across the following statement: The member names within a JWK MUST be unique; objects with duplicate member names MUST be rejected. Given the discussion that we just had on JSON parsers - is there any reason to believe that current parsers would possibly enforce this? Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Saturday, May 12, 2012 4:44 PM > To: i-d-announce@ietf.org > Cc: jose@ietf.org > Subject: [jose] I-D Action: draft-ietf-jose-json-web-key-02.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > 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-02.txt > Pages : 8 > Date : 2012-05-12 > > A JSON Web Key (JWK) is a 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 used with this specification > are enumerated in the separate JSON Web Algorithms (JWA) > specification. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-key-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-jose-json-web-key-02.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key/ > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From juraj.somorovsky@rub.de Mon May 14 05:15: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 B001921F85B7 for ; Mon, 14 May 2012 05:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTFoEjhszs-S for ; Mon, 14 May 2012 05:15:41 -0700 (PDT) Received: from mx4.rz.ruhr-uni-bochum.de (mi.ruhr-uni-bochum.de [134.147.64.53]) by ietfa.amsl.com (Postfix) with SMTP id 98E1B21F85B1 for ; Mon, 14 May 2012 05:15:40 -0700 (PDT) X-Queued: (qmail 30762 invoked by alias); 14 May 2012 12:15:39 -0000 X-Queued: (qmail 30749 invoked from network); 14 May 2012 12:15:39 -0000 Received: from c2-3-4.rz.ruhr-uni-bochum.de (134.147.64.5) by mx4.rz.ruhr-uni-bochum.de with SMTP; 14 May 2012 12:15:39 -0000 X-Queued: (qmail 11024 invoked by uid 281); 14 May 2012 12:15:38 -0000 X-Qmailscanner: from 134.147.40.78 (7Cil8M2CiUwvt7ubziZ7yA==@134.147.40.78) by c2-3-4.rz.ruhr-uni-bochum.de (envelope-from , uid 80) with qmail-scanner-2.01 (sophie: 3.05/3.29/4.75. Clear:RC:1(134.147.40.78):. Processed in 0.048168 secs); 14 May 2012 12:15:38 -0000 Received: from jontop.nds.ruhr-uni-bochum.de (HELO ?134.147.40.78?) (7Cil8M2CiUwvt7ubziZ7yA==@134.147.40.78) by c2-3-4.rz.ruhr-uni-bochum.de with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP; 14 May 2012 12:15:38 -0000 Date: 14 May 2012 14:15:37 +0200 Message-ID: <4FB0F769.1010300@rub.de> From: "Juraj Somorovsky" To: internet-drafts@ietf.org User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 References: <20120512234538.9868.10035.idtracker@ietfa.amsl.com> In-Reply-To: <20120512234538.9868.10035.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-02.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 12:15:41 -0000 Hi, I just wanted to mention that I am still against the usage of PKCS1 v1.5 in the specification (which is vulnerable to the Bleichenbacher's attack). There are two more motivations to omit it: 1) If you have a server, which has a vulnerable RSA1_5 implementation (this is e.g. the case in NimbusJWT as described in this thread: http://www.mail-archive.com/jose@ietf.org/msg00157.html), you can use this server also to decrypt messages encrypted with RSA-OAEP. You just have to take the original message and replace the "alg" header parameter value "RSA-OAEP" with the value "RSA1_5". This way, you can force the server to act as an RSA1_5 oracle and decrypt also the message encrypted with RSA-OAEP (you just need more oracle queries). (tested with NimbusJWT) 2) The next motivation is the work by Bardou, Focard, Kawamoto, Steel, and Tsay (http://hal.inria.fr/docs/00/69/19/58/PDF/RR-7944.pdf), who improved the Bleichenbacher's attack and made it even more practical. I would thus propose to remove RSA1_5. Otherewise, also the clients' messages using RSA-OAEP will be vulnerable to the Bleichenbacher's attack. If you want to leave RSA1_5 in your standard, I would propose to explicitly include the information about the countermeasures to the Bleichenbacher's attack and a notice that RSA-OAEP should not be used with the same key as RSA1_5. Thanks Regards Juraj On 05/13/2012 01:45 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. 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-02.txt > Pages : 26 > Date : 2012-05-12 > > The JSON Web Algorithms (JWA) specification enumerates cryptographic > algorithms and identifiers to be used with the JSON Web Signature > (JWS) and JSON Web Encryption (JWE) specifications. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-algorithms-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-jose-json-web-algorithms-02.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms/ > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose -- M.Sc. Juraj Somorovsky Lehrstuhl für Netz- und Datensicherheit Ruhr Universität Bochum ----------------------------------- Universitätsstr. 150, Geb. ID 2/411 D-44780 Bochum Telefon: +49 (0) 234 / 32-26551 Fax: +49 (0) 234 / 32-14347 http://www.nds.rub.de From Michael.Jones@microsoft.com Mon May 14 12:03: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 3147F21F8763; Mon, 14 May 2012 12:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsuNHQgjwM9t; Mon, 14 May 2012 12:03:45 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 7D23F21F8764; Mon, 14 May 2012 12:03:44 -0700 (PDT) Received: from mail115-am1-R.bigfish.com (10.3.201.243) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Mon, 14 May 2012 19:03:39 +0000 Received: from mail115-am1 (localhost [127.0.0.1]) by mail115-am1-R.bigfish.com (Postfix) with ESMTP id 35C23A00D6; Mon, 14 May 2012 19:03:39 +0000 (UTC) X-SpamScore: -40 X-BigFish: VS-40(zzbb2dI9371Ic89bh1431J936eKc85dh1432N98dK4015Izz1202hzz1033IL8275bh8275dh5eeeKz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail115-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail115-am1 (localhost.localdomain [127.0.0.1]) by mail115-am1 (MessageSwitch) id 1337022217185908_32606; Mon, 14 May 2012 19:03:37 +0000 (UTC) Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.241]) by mail115-am1.bigfish.com (Postfix) with ESMTP id 28DE72E004A; Mon, 14 May 2012 19:03:37 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 14 May 2012 19:03:36 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0298.005; Mon, 14 May 2012 19:03:38 +0000 From: Mike Jones To: Juraj Somorovsky , "internet-drafts@ietf.org" Thread-Topic: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-02.txt Thread-Index: AQHNMJlZf1r9SBFoIE20Y6WprM+3MJbJNVeAgAByAN4= Date: Mon, 14 May 2012 19:03:38 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943664F601D@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <20120512234538.9868.10035.idtracker@ietfa.amsl.com>, <4FB0F769.1010300@rub.de> In-Reply-To: <4FB0F769.1010300@rub.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943664F601DTK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-02.txt X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 19:03:48 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943664F601DTK5EX14MBXC284r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'll plan on describing these countermeasures in the Security Consideration= s section. Thanks, -- Mike ________________________________ From: Juraj Somorovsky Sent: 5/14/2012 5:15 AM To: internet-drafts@ietf.org Cc: jose@ietf.org Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-algorithms-02.txt Hi, I just wanted to mention that I am still against the usage of PKCS1 v1.5 in the specification (which is vulnerable to the Bleichenbacher's attack). There are two more motivations to omit it: 1) If you have a server, which has a vulnerable RSA1_5 implementation (this is e.g. the case in NimbusJWT as described in this thread: http://www.mail-archive.com/jose@ietf.org/msg00157.html), you can use this server also to decrypt messages encrypted with RSA-OAEP. You just have to take the original message and replace the "alg" header parameter value "RSA-OAEP" with the value "RSA1_5". This way, you can force the server to act as an RSA1_5 oracle and decrypt also the message encrypted with RSA-OAEP (you just need more oracle queries). (tested with NimbusJWT) 2) The next motivation is the work by Bardou, Focard, Kawamoto, Steel, and Tsay (http://hal.inria.fr/docs/00/69/19/58/PDF/RR-7944.pdf), who improved the Bleichenbacher's attack and made it even more practical. I would thus propose to remove RSA1_5. Otherewise, also the clients' messages using RSA-OAEP will be vulnerable to the Bleichenbacher's attack. If you want to leave RSA1_5 in your standard, I would propose to explicitly include the information about the countermeasures to the Bleichenbacher's attack and a notice that RSA-OAEP should not be used with the same key as RSA1_5. Thanks Regards Juraj On 05/13/2012 01:45 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Javascript Object Signing and Encry= ption Working Group of the IETF. > > Title : JSON Web Algorithms (JWA) > Author(s) : Michael B. Jones > Filename : draft-ietf-jose-json-web-algorithms-02.txt > Pages : 26 > Date : 2012-05-12 > > The JSON Web Algorithms (JWA) specification enumerates cryptographic > algorithms and identifiers to be used with the JSON Web Signature > (JWS) and JSON Web Encryption (JWE) specifications. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-algorithms-0= 2.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-jose-json-web-algorithms-02= .txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms/ > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose -- M.Sc. Juraj Somorovsky Lehrstuhl f=FCr Netz- und Datensicherheit Ruhr Universit=E4t Bochum ----------------------------------- Universit=E4tsstr. 150, Geb. ID 2/411 D-44780 Bochum Telefon: +49 (0) 234 / 32-26551 Fax: +49 (0) 234 / 32-14347 http://www.nds.rub.de _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B1680429673943664F601DTK5EX14MBXC284r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'll plan on = describing these countermeasures in the Security Considerations section.
Thanks,
-- Mike


From: Juraj = Somorovsky
Sent: 5/14/2= 012 5:15 AM
To: intern= et-drafts@ietf.org
Cc: jose@i= etf.org
Subject: Re: [j= ose] I-D Action: draft-ietf-jose-json-web-algorithms-02.txt

Hi,

I just wanted to mention that I am still against the usage of PKCS1 v1.5 in the specification (which is vulnerable to the Bleichenbacher's
attack). There are two more motivations to omit it:

1) If you have a server, which has a vulnerable RSA1_5 implementation
(this is e.g. the case in NimbusJWT as described in this thread:
http://= www.mail-archive.com/jose@ietf.org/msg00157.html), you can use
this server also to decrypt messages encrypted with RSA-OAEP. You just
have to take the original message and replace the "alg" header pa= rameter
value "RSA-OAEP" with the value "RSA1_5". This way, you= can force the
server to act as an RSA1_5 oracle and decrypt also the message encrypted with RSA-OAEP (you just need more oracle queries).
(tested with NimbusJWT)

2) The next motivation is the work by Bardou, Focard, Kawamoto, Steel,
and Tsay (= http://hal.inria.fr/docs/00/69/19/58/PDF/RR-7944.pdf), who
improved the Bleichenbacher's attack and made it even more practical.


I would thus propose to remove RSA1_5. Otherewise, also the clients'
messages using RSA-OAEP will be vulnerable to the Bleichenbacher's attack.<= br>
If you want to leave RSA1_5 in your standard, I would propose to
explicitly include the information about the countermeasures to the
Bleichenbacher's attack and a notice that RSA-OAEP should not be used
with the same key as RSA1_5.


Thanks
Regards
Juraj

On 05/13/2012 01:45 AM, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. This draft is a work item of the Javascript Object Signing and En= cryption Working Group of the IETF.
>
>        Title    = ;       : JSON Web Algorithms (JWA)
>        Author(s)   &= nbsp;   : Michael B. Jones
>        Filename   &n= bsp;    : draft-ietf-jose-json-web-algorithms-02.txt
>        Pages    = ;       : 26
>        Date    =         : 2012-05-12
>
>    The JSON Web Algorithms (JWA) specification enumerat= es cryptographic
>    algorithms and identifiers to be used with the JSON = Web Signature
>    (JWS) and JSON Web Encryption (JWE) specifications.<= br> >
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-algorithms-02.= txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/int= ernet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-jose-json-web-algorithms-02.t= xt
>
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms/ >
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.iet= f.org/mailman/listinfo/jose

--
M.Sc. Juraj Somorovsky

Lehrstuhl f=FCr Netz- und Datensicherheit
Ruhr Universit=E4t Bochum
-----------------------------------
Universit=E4tsstr. 150, Geb. ID 2/411
D-44780 Bochum

Telefon: +49 (0) 234 / 32-26551
Fax: +49 (0) 234 / 32-14347
http://www.nds.rub.de
_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org= /mailman/listinfo/jose

--_000_4E1F6AAD24975D4BA5B1680429673943664F601DTK5EX14MBXC284r_-- From James.H.Manger@team.telstra.com Tue May 15 07:22:10 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6AB21F877F for ; Tue, 15 May 2012 07:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.752 X-Spam-Level: X-Spam-Status: No, score=-0.752 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yf2JV0Cf93D9 for ; Tue, 15 May 2012 07:22:08 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 22FAE21F877D for ; Tue, 15 May 2012 07:22:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,595,1330866000"; d="scan'208,217";a="73013736" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 16 May 2012 00:22:05 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6711"; a="63000078" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcbni.tcif.telstra.com.au with ESMTP; 16 May 2012 00:22:05 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Wed, 16 May 2012 00:22:04 +1000 From: "Manger, James H" To: Mike Jones , "jose@ietf.org" Date: Wed, 16 May 2012 00:22:02 +1000 Thread-Topic: "typ":"JWS" Thread-Index: Ac0wnJNnnN9jpblpRpGKmgusm4TcEgBvMKlg Message-ID: <255B9BB34FB7D647A506DC292726F6E114F2D6A743@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B1680429673943664F18ED@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943664F18ED@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E114F2D6A743WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: [jose] "typ":"JWS" X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 14:22:10 -0000 --_000_255B9BB34FB7D647A506DC292726F6E114F2D6A743WSMSG3153Vsrv_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-ietf-jose-json-web-signature-02 =A77.2 registers the "JWS" type value= (for the "typ" header field). Presumably this value indicates that the dat= a to be signed is itself a JSON Web Signature (JWS). That is, it is used wh= en you want multiple signatures, one wrapping another. This sounds like qui= te an unusual corner case. Yet, the 2nd sentence of the definition of the "= typ" header parameter [=A74.1.8] explicitly mentions this "JWS" type value = - almost implying it is the usual value for this parameter. Perhaps "typ":"JWS" is more useful in a JWE header when encrypting signed c= ontent (sign-then-encrypt). If this is the intention, then mentioning the "= JWS" type value when defining the "typ" header for a JWS is misleading. It = would be better to mention it where the JWE spec defines "typ". The definition of the "JWS" type value [=A77.2] doesn't actually say what t= he syntax is. It needs to explicitly say that when "typ" is "JWS" the conte= nt bytes are a JWS Compact Serialization. This is not a great syntax when there are multiple wrapped signature, nor w= hen encrypting a signature. It causes nested layers of base64url encodings.= For instance, if 3 signatures sign some message the result includes base64= (base64(base64(message). Similarly, encrypting signed content results in ba= se64(base64(message)). This hardly matches the opening sentence of the spec= that talks about a "compact format" for "space constrained environments". It is great to have a base64url-based format for when a small amount of sec= ured data is passed around, but it doesn't need to cause bloat for nested o= perations or securing larger amounts of data. -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E114F2D6A743WSMSG3153Vsrv_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

draft-ietf-jose-json-web-signature-02 =A77.2 registers the &#= 8220;JWS” type value (for the “typ” header field). Presum= ably this value indicates that the data to be signed is itself a JSON Web S= ignature (JWS). That is, it is used when you want multiple signatures, one = wrapping another. This sounds like quite an unusual corner case. Yet, the 2= nd sentence of the definition of the “typ” header pa= rameter [=A74.1.8] explicitly mentions this “JWS” type value &#= 8212; almost implying it is the usual value for this parameter.<= /span>

 

Perhaps &#= 8220;typ”:”JWS” is more useful in a JWE header when encry= pting signed content (sign-then-encrypt). If this is the intention, then me= ntioning the “JWS” type value when defining the “typ̶= 1; header for a JWS is misleading. It would be better to mention it where t= he JWE spec defines “typ”.

 

 

The definition of the “JW= S” type value [=A77.2] doesn’t actually say what the syntax is.= It needs to explicitly say that when “typ” is “JWS”= ; the content bytes are a JWS Compact Serialization.

<= p class=3DMsoNormal> <= /p>

This is not a great s= yntax when there are multiple wrapped signature, nor when encrypting a sign= ature. It causes nested layers of base64url encodings. For instance, if 3 s= ignatures sign some message the result includes base64(base64(base64(messag= e). Similarly, encrypting signed content results in base64(base64(message))= . This hardly matches the opening sentence of the spec that talks about a &= #8220;compact format” for “space constrained environments”= ;.

=  

It is great to have a base64url-based format for when a small amount of= secured data is passed around, but it doesn’t need to cause bloat fo= r nested operations or securing larger amounts of data.

 

 <= /span>

--

James Man= ger

= --_000_255B9BB34FB7D647A506DC292726F6E114F2D6A743WSMSG3153Vsrv_-- From James.H.Manger@team.telstra.com Tue May 15 07:55: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 03FF021F88CE for ; Tue, 15 May 2012 07:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.761 X-Spam-Level: X-Spam-Status: No, score=-0.761 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TC5zHsAPSLzo for ; Tue, 15 May 2012 07:55:37 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4F121F87D5 for ; Tue, 15 May 2012 07:55:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,595,1330866000"; d="scan'208,217";a="73888726" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 16 May 2012 00:55:35 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6711"; a="62648257" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipccvi.tcif.telstra.com.au with ESMTP; 16 May 2012 00:55:35 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Wed, 16 May 2012 00:55:34 +1000 From: "Manger, James H" To: "jose@ietf.org" Date: Wed, 16 May 2012 00:55:33 +1000 Thread-Topic: MUST understand ALL header fields Thread-Index: Ac0yqsdDmfmv4/UhR56cZBr83MAvbw== Message-ID: <255B9BB34FB7D647A506DC292726F6E114F2D6A745@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_255B9BB34FB7D647A506DC292726F6E114F2D6A745WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: [jose] MUST understand ALL header fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 14:55:38 -0000 --_000_255B9BB34FB7D647A506DC292726F6E114F2D6A745WSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-jose-json-web-signature-02 and draft-ietf-jose-json-web-encrypti= on-02 say: Implementations MUST understand the entire contents of the header; otherwise, the {JWS|JWE} MUST be rejected. We should drop this restriction. Firstly, most implementations will ignore it. I had a quick glance at some existing implementations (magical/jwt-python, = markrcote/jwt, jsontoken) and all appear to ignore this requirement. It cannot add any security when it is ignored. It does cause massive compat= ibility headaches for anyone wanting to define another header parameter, si= nce a new parameter will break some implementations. Secondly, a couple of parameters are defined for X.509 certs, but none for = OCSP responses, CRLs, timestamps etc. It is inevitable that a cert-based sc= heme will need these extra pieces of info. With the "MUST understand everyt= hing" rule, we have to define all the extra info that might be needed right= now. If we need to be able to break backward compatibility we should define a me= chanism explicitly for that. -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E114F2D6A745WSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

draft-ietf-jose-= json-web-signature-02 and draft-ietf-jose-json-web-encryption-02 say:<= /o:p>

 

&nb= sp;  Implementations MUST understand the entire contents of the

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

 

<= p class=3DMsoNormal>We should drop this restriction.

 

Firstly, most implem= entations will ignore it.

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

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

 

Secon= dly, a couple of parameters are defined for X.509 certs, but none for OCSP = responses, CRLs, timestamps etc. It is inevitable that a cert-based scheme = will need these extra pieces of info. With the “MUST understand every= thing” rule, we have to define all the extra info that might be neede= d right now.

 

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

 

--

James Manger

 <= /p>

= --_000_255B9BB34FB7D647A506DC292726F6E114F2D6A745WSMSG3153Vsrv_-- From Michael.Jones@microsoft.com Tue May 15 08:07:51 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9AD21F861B for ; Tue, 15 May 2012 08:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.939 X-Spam-Level: X-Spam-Status: No, score=-3.939 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgC93yYqlYSx for ; Tue, 15 May 2012 08:07:49 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 85EFA21F85A2 for ; Tue, 15 May 2012 08:07:49 -0700 (PDT) Received: from mail126-ch1-R.bigfish.com (10.43.68.233) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.23; Tue, 15 May 2012 15:07:43 +0000 Received: from mail126-ch1 (localhost [127.0.0.1]) by mail126-ch1-R.bigfish.com (Postfix) with ESMTP id 5FC6320321; Tue, 15 May 2012 15:07:43 +0000 (UTC) X-SpamScore: -21 X-BigFish: VS-21(zz9371Ic85dhzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail126-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail126-ch1 (localhost.localdomain [127.0.0.1]) by mail126-ch1 (MessageSwitch) id 1337094450910463_25781; Tue, 15 May 2012 15:07:30 +0000 (UTC) Received: from CH1EHSMHS027.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.241]) by mail126-ch1.bigfish.com (Postfix) with ESMTP id C89D52C06D4; Tue, 15 May 2012 15:07:30 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS027.bigfish.com (10.43.70.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 15 May 2012 15:07:28 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0298.005; Tue, 15 May 2012 15:07:11 +0000 From: Mike Jones To: "Manger, James H" , "jose@ietf.org" Thread-Topic: "typ":"JWS" Thread-Index: AQHNMqYfhCl4rjojOkOSeTkXESp6sZbK8sJw Date: Tue, 15 May 2012 15:07:10 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943664FA3F6@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943664F18ED@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F2D6A743@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F2D6A743@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.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943664FA3F6TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] "typ":"JWS" X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 15:07:51 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943664FA3F6TK5EX14MBXC284r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your second paragraph correctly describes the intended usage. For instance= , see http://tools.ietf.org/html/draft-jones-json-web-token-10#section-5.1 = for this usage in action. The value is registered per the working group de= cision relating "typ" values to MIME types. -- Mike From: Manger, James H [mailto:James.H.Manger@team.telstra.com] Sent: Tuesday, May 15, 2012 7:22 AM To: Mike Jones; jose@ietf.org Subject: "typ":"JWS" draft-ietf-jose-json-web-signature-02 =A77.2 registers the "JWS" type value= (for the "typ" header field). Presumably this value indicates that the dat= a to be signed is itself a JSON Web Signature (JWS). That is, it is used wh= en you want multiple signatures, one wrapping another. This sounds like qui= te an unusual corner case. Yet, the 2nd sentence of the definition of the "= typ" header parameter [=A74.1.8] explicitly mentions this "JWS" type value = - almost implying it is the usual value for this parameter. Perhaps "typ":"JWS" is more useful in a JWE header when encrypting signed c= ontent (sign-then-encrypt). If this is the intention, then mentioning the "= JWS" type value when defining the "typ" header for a JWS is misleading. It = would be better to mention it where the JWE spec defines "typ". The definition of the "JWS" type value [=A77.2] doesn't actually say what t= he syntax is. It needs to explicitly say that when "typ" is "JWS" the conte= nt bytes are a JWS Compact Serialization. This is not a great syntax when there are multiple wrapped signature, nor w= hen encrypting a signature. It causes nested layers of base64url encodings.= For instance, if 3 signatures sign some message the result includes base64= (base64(base64(message). Similarly, encrypting signed content results in ba= se64(base64(message)). This hardly matches the opening sentence of the spec= that talks about a "compact format" for "space constrained environments". It is great to have a base64url-based format for when a small amount of sec= ured data is passed around, but it doesn't need to cause bloat for nested o= perations or securing larger amounts of data. -- James Manger --_000_4E1F6AAD24975D4BA5B1680429673943664FA3F6TK5EX14MBXC284r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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

 

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

 

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

 

draft-i= etf-jose-json-web-signature-02 =A77.2 registers the “JWS” type = value (for the “typ” header field). Presumably this value indic= ates that the data to be signed is itself a JSON Web Signature (JWS). That is, it is used when you want multiple signatures, one wrapping anothe= r. This sounds like quite an unusual corner case. Yet, the 2nd s= entence of the definition of the “typ” header parameter [=A74.1= .8] explicitly mentions this “JWS” type value — almost implying it is the usual value for this parameter.

&n= bsp;

Perhaps= “typ”:”JWS” is more useful in a JWE header when en= crypting signed content (sign-then-encrypt). If this is the intention, then= mentioning the “JWS” type value when defining the “typ&#= 8221; header for a JWS is misleading. It would be better to mention it where the JWE sp= ec defines “typ”.

&n= bsp;

&n= bsp;

The def= inition of the “JWS” type value [=A77.2] doesn’t actually= say what the syntax is. It needs to explicitly say that when “typ= 221; is “JWS” the content bytes are a JWS Compact Serialization= .

&n= bsp;

This is= not a great syntax when there are multiple wrapped signature, nor when enc= rypting a signature. It causes nested layers of base64url encodings. For in= stance, if 3 signatures sign some message the result includes base64(base64(base64(message). Similarly, encrypting s= igned content results in base64(base64(message)). This hardly matches the o= pening sentence of the spec that talks about a “compact format”= for “space constrained environments”.

&n= bsp;

It is g= reat to have a base64url-based format for when a small amount of secured da= ta is passed around, but it doesn’t need to cause bloat for nested op= erations or securing larger amounts of data.

&n= bsp;

&n= bsp;

--=

James M= anger

--_000_4E1F6AAD24975D4BA5B1680429673943664FA3F6TK5EX14MBXC284r_-- From James.H.Manger@team.telstra.com Tue May 15 17:40: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 7A5EE21F8638 for ; Tue, 15 May 2012 17:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.769 X-Spam-Level: X-Spam-Status: No, score=-0.769 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqHZ-PQPmUnh for ; Tue, 15 May 2012 17:40:33 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id F141A21F8637 for ; Tue, 15 May 2012 17:40:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,599,1330866000"; d="scan'208,217";a="73071749" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 16 May 2012 10:40:22 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6712"; a="63470500" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipccni.tcif.telstra.com.au with ESMTP; 16 May 2012 10:40:23 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Wed, 16 May 2012 10:40:22 +1000 From: "Manger, James H" To: Mike Jones , "jose@ietf.org" Date: Wed, 16 May 2012 10:40:20 +1000 Thread-Topic: "typ":"JWS" Thread-Index: AQHNMqYfhCl4rjojOkOSeTkXESp6sZbK8sJwgACVPiA= Message-ID: <255B9BB34FB7D647A506DC292726F6E114F2D6AB7C@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B1680429673943664F18ED@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F2D6A743@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943664FA3F6@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943664FA3F6@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E114F2D6AB7CWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [jose] "typ":"JWS" X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 00:40:35 -0000 --_000_255B9BB34FB7D647A506DC292726F6E114F2D6AB7CWSMSG3153Vsrv_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >> draft-ietf-jose-json-web-signature-02 =A77.2 registers the "JWS" type va= lue (for the "typ" header field) >> ... >> Perhaps "typ":"JWS" is more useful in a JWE header when encrypting signe= d content (sign-then-encrypt). If this is the intention, then mentioning th= e "JWS" type value when defining the "typ" header for a JWS is misleading. = It would be better to mention it where the JWE spec defines "typ". >> ... > Your second paragraph correctly describes the intended usage. For instan= ce, see http://tools.ietf.org/html/draft-jones-json-web-token-10#section-5.= 1 for this usage in action. The value is registered per the working group = decision relating "typ" values to MIME types. Good. So let's say that. Suggested text changes: * draft-ietf-jose-json-web-signature-02, section 4.1.8 "typ" (Type) Header = Parameter: delete the 2nd sentence because signing a signature is not what = we are talking about (and JWS-JS recommends a different approach for multip= le signatures anyway). * section 7.1 Registration of application/jws MIME Media Type: add a phrase= explicitly stating the syntax (since the spec mentions two: compact, and J= WS JS) so the section says: This specification registers the "application/jws" MIME Media Type [RFC 2= 045] to identify content that uses the JWS compact serialization. * section 7.2 Registration of "JWS" Type Value: mention the intended use of= encrypting signed content by adding this sentence. The "typ" parameter can be set to "JWS" in a JSON Web Encryption [JWE] he= ader when encrypting signed content. * draft-ietf-jose-json-web-encryption-02, section 4.1.13 "typ" (Type) Heade= r Parameter, section 11.1 Registration of application/jwe MIME Media Type, = section 11.2 Registration of "JWE" type Value: make equivalent changes. -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E114F2D6AB7CWSMSG3153Vsrv_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>> draft-ietf-jose= -json-web-signature-02 =A77.2 registers the “JWS” type value (f= or the “typ” header field)

>> …

>> Perhaps “ty= p”:”JWS” is more useful in a JWE header when encrypting s= igned content (sign-then-encrypt). If this is the intention, then mentionin= g the “JWS” type value when defining the “typ” head= er for a JWS is misleading. It would be better to mention it where the JWE = spec defines “typ”.

>> = …

 

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

 

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

 

* draft-ietf-jose-json-web-s= ignature-02, section 4.1.8 “typ&= #8221; (Type) Header Parameter: delete the 2nd sentence because signing a s= ignature is not what we are talking about (and JWS-JS recommends a differen= t approach for multiple signatures anyway).

 

* section 7.1 Registration o= f application/jws MIME Media Type: add a phrase explicitly stating the synt= ax (since the spec mentions two: compact, and JWS JS) so the section says:<= o:p>

=A0= This specification registers the "application/jws" MIME Media Ty= pe [RFC 2045]

=A0 to identify content that uses the JWS compact serialization.=

 

* section 7.2 Registration of "JWS" Type Value: mention the int= ended use of encrypting signed content by adding this sentence.<= /span>

=A0 The “= ;typ” parameter can be set to “JWS” in a JSON Web Encrypt= ion [JWE] header when encrypting signed content.

 

<= p class=3DMsoNormal>* draft-ietf-jose-json-we= b-encryption-02, section 4.1.13 “typ” (Type) Header Parameter, = section 11.1 Registration of application/jwe MIME Media Type, section 11.2 = Registration of “JWE” type Value: make equivalent changes.=

&n= bsp;

--<= o:p>

Jam= es Manger

 

= --_000_255B9BB34FB7D647A506DC292726F6E114F2D6AB7CWSMSG3153Vsrv_-- From James.H.Manger@team.telstra.com Wed May 16 19:23: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 AE68121F85F6 for ; Wed, 16 May 2012 19:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBT10AvQccB3 for ; Wed, 16 May 2012 19:23:28 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id EABF621F85F4 for ; Wed, 16 May 2012 19:23:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,607,1330866000"; d="scan'208";a="76240797" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 17 May 2012 12:23:26 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6713"; a="63036599" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcdvi.tcif.telstra.com.au with ESMTP; 17 May 2012 12:23:26 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Thu, 17 May 2012 12:23:26 +1000 From: "Manger, James H" To: "jose@ietf.org" Date: Thu, 17 May 2012 12:23:25 +1000 Thread-Topic: "typ":"JWT" Thread-Index: AQHNMqYfhCl4rjojOkOSeTkXESp6sZbK8sJwgACVPiCAAaoqQA== Message-ID: <255B9BB34FB7D647A506DC292726F6E114F2E1BCE0@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B1680429673943664F18ED@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F2D6A743@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943664FA3F6@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F2D6AB7C@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F2D6AB7C@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [jose] "typ":"JWT" 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, 17 May 2012 02:23:28 -0000 The term "JWT" is used both for: 1. A JSON object listing claims, eg {"iss":"joe","exp":1300819380}; and 2. A string of base64-and-dots, eg eyJhbGciOiJub25lIn0.eyJ...lfQ. I assume "typ":"JWT" in a JWS or JWE header means the payload or plaintext = is #1. If I received content with the application/jwt media type, however, I would= probably expect #2 as this is the form that is more often passed around in= protocols. But this expectation must be wrong. These seems inconsistent. "typ":"JWT" is also not consistent with "typ":"JWS" and "typ":"JWE". Could we add a sentence to "Registration of application/jwt media type" [dr= aft-jones-json-web-token-10#section-9.3] explicitly stating the syntax bein= g identified is a JWT Claim Set. I would also add a note: Note: The syntax associated with "typ":"JWT" is a JSON object, in contrast to the syntax associated with "typ":"JWS" and "typ":"JWE" that is a string of dot-separated base64url segments. =20 Alternatively use "typ":"CLM" (for claims) instead of "typ":"JWT". -- James Manger From Michael.Jones@microsoft.com Wed May 16 19:57: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 0152821F85E4 for ; Wed, 16 May 2012 19:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.926 X-Spam-Level: X-Spam-Status: No, score=-3.926 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4CSOPjZbJTO for ; Wed, 16 May 2012 19:57:21 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id EF61721F85E3 for ; Wed, 16 May 2012 19:57:20 -0700 (PDT) Received: from mail109-ch1-R.bigfish.com (10.43.68.240) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.23; Thu, 17 May 2012 02:57:12 +0000 Received: from mail109-ch1 (localhost [127.0.0.1]) by mail109-ch1-R.bigfish.com (Postfix) with ESMTP id BA27346A9B8; Thu, 17 May 2012 02:57:12 +0000 (UTC) X-SpamScore: -27 X-BigFish: VS-27(zz9371I542M4015Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail109-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail109-ch1 (localhost.localdomain [127.0.0.1]) by mail109-ch1 (MessageSwitch) id 1337223430848225_4001; Thu, 17 May 2012 02:57:10 +0000 (UTC) Received: from CH1EHSMHS015.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.232]) by mail109-ch1.bigfish.com (Postfix) with ESMTP id C6B6044DCAF; Thu, 17 May 2012 02:57:10 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 17 May 2012 02:57:10 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0298.005; Thu, 17 May 2012 02:57:16 +0000 From: Mike Jones To: "Manger, James H" , "jose@ietf.org" Thread-Topic: "typ":"JWT" Thread-Index: AQHNM9QOJTRLoyCfUECMDgXuyQa0Z5bNSWDQ Date: Thu, 17 May 2012 02:57:16 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436650AAFC@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943664F18ED@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F2D6A743@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943664FA3F6@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F2D6AB7C@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F2E1BCE0@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F2E1BCE0@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.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] "typ":"JWT" 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, 17 May 2012 02:57:22 -0000 If JWT is ever used to refer to the bare claim set, rather than the complet= e object, that's a spec bug. If you've found any such references, can you = point me to them so I can correct them? Thanks, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Man= ger, James H Sent: Wednesday, May 16, 2012 7:23 PM To: jose@ietf.org Subject: [jose] "typ":"JWT" The term "JWT" is used both for: 1. A JSON object listing claims, eg {"iss":"joe","exp":1300819380}; and 2. = A string of base64-and-dots, eg eyJhbGciOiJub25lIn0.eyJ...lfQ. I assume "typ":"JWT" in a JWS or JWE header means the payload or plaintext = is #1. If I received content with the application/jwt media type, however, I would= probably expect #2 as this is the form that is more often passed around in= protocols. But this expectation must be wrong. These seems inconsistent. "typ":"JWT" is also not consistent with "typ":"JWS" and "typ":"JWE". Could we add a sentence to "Registration of application/jwt media type" [dr= aft-jones-json-web-token-10#section-9.3] explicitly stating the syntax bein= g identified is a JWT Claim Set. I would also add a note: Note: The syntax associated with "typ":"JWT" is a JSON object, in contrast to the syntax associated with "typ":"JWS" and "typ":"JWE" that is a string of dot-separated base64url segments. =20 Alternatively use "typ":"CLM" (for claims) instead of "typ":"JWT". -- James Manger _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From James.H.Manger@team.telstra.com Wed May 16 20:06: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 A45C111E80AD for ; Wed, 16 May 2012 20:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.804 X-Spam-Level: X-Spam-Status: No, score=-0.804 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sir63bvbA4Qt for ; Wed, 16 May 2012 20:06:44 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id ACF3E11E809C for ; Wed, 16 May 2012 20:06:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,607,1330866000"; d="scan'208";a="74215987" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipobvi.tcif.telstra.com.au with ESMTP; 17 May 2012 13:06:42 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6713"; a="62873794" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipccvi.tcif.telstra.com.au with ESMTP; 17 May 2012 13:06:43 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Thu, 17 May 2012 13:06:42 +1000 From: "Manger, James H" To: Mike Jones , "jose@ietf.org" Date: Thu, 17 May 2012 13:06:41 +1000 Thread-Topic: "typ":"JWT" Thread-Index: AQHNM9QOJTRLoyCfUECMDgXuyQa0Z5bNSWDQgAAA6iA= Message-ID: <255B9BB34FB7D647A506DC292726F6E114F2E1BDB4@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B1680429673943664F18ED@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F2D6A743@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943664FA3F6@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F2D6AB7C@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F2E1BCE0@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436650AAFC@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436650AAFC@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [jose] "typ":"JWT" 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, 17 May 2012 03:06:44 -0000 The "typ" value tells you the syntax of the payload. "typ":"JWT" means the payload is a bare claim set doesn't it? That is what = =A73.1 "Example JWT" has. This looks like "JWT" referring to a bare claim set to me. -- James Manger -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik= e Jones Sent: Thursday, 17 May 2012 12:57 PM To: Manger, James H; jose@ietf.org Subject: Re: [jose] "typ":"JWT" If JWT is ever used to refer to the bare claim set, rather than the complet= e object, that's a spec bug. If you've found any such references, can you = point me to them so I can correct them? Thanks, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Man= ger, James H Sent: Wednesday, May 16, 2012 7:23 PM To: jose@ietf.org Subject: [jose] "typ":"JWT" The term "JWT" is used both for: 1. A JSON object listing claims, eg {"iss":"joe","exp":1300819380}; and 2. = A string of base64-and-dots, eg eyJhbGciOiJub25lIn0.eyJ...lfQ. I assume "typ":"JWT" in a JWS or JWE header means the payload or plaintext = is #1. If I received content with the application/jwt media type, however, I would= probably expect #2 as this is the form that is more often passed around in= protocols. But this expectation must be wrong. These seems inconsistent. "typ":"JWT" is also not consistent with "typ":"JWS" and "typ":"JWE". Could we add a sentence to "Registration of application/jwt media type" [dr= aft-jones-json-web-token-10#section-9.3] explicitly stating the syntax bein= g identified is a JWT Claim Set. I would also add a note: Note: The syntax associated with "typ":"JWT" is a JSON object, in contrast to the syntax associated with "typ":"JWS" and "typ":"JWE" that is a string of dot-separated base64url segments. =20 Alternatively use "typ":"CLM" (for claims) instead of "typ":"JWT". -- 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 Michael.Jones@microsoft.com Wed May 16 20:16: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 3460521F86BE for ; Wed, 16 May 2012 20:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.922 X-Spam-Level: X-Spam-Status: No, score=-3.922 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiLcn+KcxxLT for ; Wed, 16 May 2012 20:16:42 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 320BC11E808F for ; Wed, 16 May 2012 20:16:42 -0700 (PDT) Received: from mail91-ch1-R.bigfish.com (10.43.68.238) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.23; Thu, 17 May 2012 03:16:30 +0000 Received: from mail91-ch1 (localhost [127.0.0.1]) by mail91-ch1-R.bigfish.com (Postfix) with ESMTP id 3D39640448; Thu, 17 May 2012 03:16:30 +0000 (UTC) X-SpamScore: -27 X-BigFish: VS-27(zz9371I542M4015Izz1202hzz1033IL8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail91-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail91-ch1 (localhost.localdomain [127.0.0.1]) by mail91-ch1 (MessageSwitch) id 1337224588916311_19493; Thu, 17 May 2012 03:16:28 +0000 (UTC) Received: from CH1EHSMHS016.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.237]) by mail91-ch1.bigfish.com (Postfix) with ESMTP id D3B591A0075; Thu, 17 May 2012 03:16:28 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS016.bigfish.com (10.43.70.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 17 May 2012 03:16:28 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0298.005; Thu, 17 May 2012 03:13:09 +0000 From: Mike Jones To: "Manger, James H" , "jose@ietf.org" Thread-Topic: "typ":"JWT" Thread-Index: AQHNM9QOJTRLoyCfUECMDgXuyQa0Z5bNSWDQgAAA6iCAAAPdcA== Date: Thu, 17 May 2012 03:13:08 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436650AF40@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943664F18ED@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F2D6A743@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B1680429673943664FA3F6@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F2D6AB7C@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E114F2E1BCE0@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436650AAFC@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F2E1BDB4@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F2E1BDB4@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.78] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] "typ":"JWT" 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, 17 May 2012 03:16:43 -0000 Fair enough. Let me think about this one... -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Man= ger, James H Sent: Wednesday, May 16, 2012 8:07 PM To: Mike Jones; jose@ietf.org Subject: Re: [jose] "typ":"JWT" The "typ" value tells you the syntax of the payload. "typ":"JWT" means the payload is a bare claim set doesn't it? That is what = =A73.1 "Example JWT" has. This looks like "JWT" referring to a bare claim set to me. -- James Manger -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik= e Jones Sent: Thursday, 17 May 2012 12:57 PM To: Manger, James H; jose@ietf.org Subject: Re: [jose] "typ":"JWT" If JWT is ever used to refer to the bare claim set, rather than the complet= e object, that's a spec bug. If you've found any such references, can you = point me to them so I can correct them? Thanks, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Man= ger, James H Sent: Wednesday, May 16, 2012 7:23 PM To: jose@ietf.org Subject: [jose] "typ":"JWT" The term "JWT" is used both for: 1. A JSON object listing claims, eg {"iss":"joe","exp":1300819380}; and 2. = A string of base64-and-dots, eg eyJhbGciOiJub25lIn0.eyJ...lfQ. I assume "typ":"JWT" in a JWS or JWE header means the payload or plaintext = is #1. If I received content with the application/jwt media type, however, I would= probably expect #2 as this is the form that is more often passed around in= protocols. But this expectation must be wrong. These seems inconsistent. "typ":"JWT" is also not consistent with "typ":"JWS" and "typ":"JWE". Could we add a sentence to "Registration of application/jwt media type" [dr= aft-jones-json-web-token-10#section-9.3] explicitly stating the syntax bein= g identified is a JWT Claim Set. I would also add a note: Note: The syntax associated with "typ":"JWT" is a JSON object, in contrast to the syntax associated with "typ":"JWS" and "typ":"JWE" that is a string of dot-separated base64url segments. =20 Alternatively use "typ":"CLM" (for claims) instead of "typ":"JWT". -- 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 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From James.H.Manger@team.telstra.com Wed May 16 21:57:10 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD9A21F8564 for ; Wed, 16 May 2012 21:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.808 X-Spam-Level: X-Spam-Status: No, score=-0.808 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtkWD+EBVAma for ; Wed, 16 May 2012 21:57:09 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 5396121F876C for ; Wed, 16 May 2012 21:57:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,607,1330866000"; d="scan'208";a="76266148" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipocvi.tcif.telstra.com.au with ESMTP; 17 May 2012 14:57:07 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6713"; a="62839914" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcbvi.tcif.telstra.com.au with ESMTP; 17 May 2012 14:57:08 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Thu, 17 May 2012 14:57:07 +1000 From: "Manger, James H" To: "jose@ietf.org" Date: Thu, 17 May 2012 14:57:06 +1000 Thread-Topic: Distinguishing signed, encrypted, and unprotected tokens Thread-Index: Ac0z6YIAkxSNdpPpSJGGHmreRKfuNA== Message-ID: <255B9BB34FB7D647A506DC292726F6E114F2E1C05D@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [jose] Distinguishing signed, encrypted, and unprotected tokens 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, 17 May 2012 04:57:10 -0000 draft-jones-json-web-token-10#section-5 suggests looking at the "alg" value= in the header to distinguish whether you have a JWE, JWS, or plain JWT. Wouldn't it be better to distinguish these cases by the number of dots: * 3 dots (4 segments) =3D> JWE * 2 dots (3 segments) =3D> JWS Then we could use 1 segment for a plaintext JWT * 0 dots (1 segment) =3D> Plaintext JWT (base64url-encoded JWT Claim Set) Benefits: 1. JWT spec doesn't need to confusingly specify the "JWT header" as though = it is a separate thing from a JWS or JWE header. Rules are specified for th= e JWT header (unique names, no duplicates, all understood or reject, JWT-sp= ecific "typ" definition) but surely these should just be the JWS or JWE hea= der rules as appropriate. 2. No need for the rather pointless "eyJhbGciOiJub25lIn0." prefix (for {"al= g":"none"}) on plaintext JWTs 3. Top-level code doesn't need to know all sig & enc algs; can leave that t= o signing & encryption libraries 4. Don't need to split, decode, parse header before passing JWT onto JWS or= JWE processing (which may well split, decode, and parse the same stuff all= over again) [eg https://github.com/NimbusDS/Nimbus-JWT/blob/master/src/com= /nimbusds/jwt/JWT.java#LC137] 5. Less risk that "none" is implemented as a proper JWS signature verificat= ion algorithm and accidentally allows unsigned code to pass security gates. -- James Manger From James.H.Manger@team.telstra.com Thu May 17 21:49: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 B274A21F8716 for ; Thu, 17 May 2012 21:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.19 X-Spam-Level: X-Spam-Status: No, score=0.19 tagged_above=-999 required=5 tests=[AWL=-0.913, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, TRACKER_ID=2.003] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWftz9S83nGc for ; Thu, 17 May 2012 21:49:25 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 03DE921F8711 for ; Thu, 17 May 2012 21:49:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,614,1330866000"; d="scan'208,217";a="74385492" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 18 May 2012 14:49:21 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6714"; a="63016538" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipcbvi.tcif.telstra.com.au with ESMTP; 18 May 2012 14:49:21 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Fri, 18 May 2012 14:49:20 +1000 From: "Manger, James H" To: "jose@ietf.org" Date: Fri, 18 May 2012 14:49:18 +1000 Thread-Topic: Is an OpenID Connect request really a JWT? Thread-Index: Ac00sZXAvnxsTepNSaaPeYnzNySn2w== Message-ID: <255B9BB34FB7D647A506DC292726F6E114F2EB077A@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_255B9BB34FB7D647A506DC292726F6E114F2EB077AWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: [jose] Is an OpenID Connect request really a JWT? 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, 18 May 2012 04:49:26 -0000 --_000_255B9BB34FB7D647A506DC292726F6E114F2EB077AWSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OpenID Connect [http://openid.net/specs/openid-connect-standard-1_0.html#re= q_param_method] says: "The request parameter is a JWT encoded OpenID Request Object... The JWT object MAY be signed or signed and encrypted via JWS and JWE" It gives the example below, which is a JWS with "typ":"JWT". The payload is= a JSON object with 8 fields (response_type, client_id, redirect_uri, scope= , state, nonce, userinfo (with lots of sub-fields), id_token (with sub-fiel= ds)). The payload has none of the 8 reserved claims from the JWT spec (exp,= nbf, iat, iss, aud, prn, jti, typ). Can we really call that a JWT? It seems implausible that the 8 fields in this example (response_type...) = are supposed to be treated as "Private Claim Names" as per the JWT spec. We have two totally separate ideas both being called "JWT". 1. JSON object carrying a bunch of claims. 2. A base64-based way to package any blob of bytes in unprotected, si= gned, or encrypted forms. Suggestion: use "JWT" for #2; pick a new name for #1 (perhaps JSON Claim Se= t); lots of changes to spec text. JWT algorithm =3D HS256 HMAC HASH Key =3D 'aaa' JSON Encoded Header =3D "{"alg":"HS256","typ":"JWT"}" JSON Encoded Payload =3D "{"response_type":"code id_token", "client_id":"s6BhdRkqt3", "redirect_uri":"https://client.example.com/cb", "scope":"openid profile", "state":"af0ifjsldkj", "nonce":"n-0S6_WzA2Mj", "userinfo":{"claims":{"name":null,"nickname":{"optional":true}, "email":null,"verified":null, "picture":{"optional":true}}}, "id_token":{"max_age":86400,"claims":{"acr":{"values":["2"]}}} JWT =3D eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJyZXNwb25zZV90eXBlIjoiY29kZ SBpZF90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiO iJodHRwczpcL1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3BlbmlkI HByb2ZpbGUiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwibm9uY2UiOiJuLTBTNl9XekEyT WoiLCJ1c2VyaW5mbyI6eyJjbGFpbXMiOnsibmFtZSI6bnVsbCwibmlja25hbWUiOnsib 3B0aW9uYWwiOnRydWV9LCJlbWFpbCI6bnVsbCwidmVyaWZpZWQiOm51bGwsInBpY3R1c mUiOnsib3B0aW9uYWwiOnRydWV9fX0sImlkX3Rva2VuIjp7Im1heF9hZ2UiOjg2NDAwL CJjbGFpbXMiOnsiYWNyIjp7InZhbHVlcyI6WyIyIl19fX19.ou2Yc1B9a5iZLqbzBxE9 5aNS0pSfRClCqM77n85ehGo -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E114F2EB077AWSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

OpenID Connect [= http://openid.net/specs/openid-connect-standard-1_0.html#req_par= am_method] says:

  “The r= equest parameter is a JWT encoded OpenID Request Object…

   The JWT object MAY be signed or signed = and encrypted via JWS and JWE”

 

It gives the example below, which is= a JWS with “typ”:”JWT”. The payload is a JSON obje= ct with 8 fields (response_type, client_id, redirect_uri, scope, state, non= ce, userinfo (with lots of sub-fields), id_token (with sub-fields)). The pa= yload has none of the 8 reserved claims from the JWT spec (exp, nbf, iat, i= ss, aud, prn, jti, typ).

 

Can we really call that a JWT?

It seems implausible that the  8 fields in this exam= ple (response_type…) are supposed to be treated as “Private Cla= im Names” as per the JWT spec.

 

We have two totally separate ideas b= oth being called “JWT”.

1.       JSON ob= ject carrying a bunch of claims.

= 2.       A base64-b= ased way to package any blob of bytes in unprotected, signed, or encrypted = forms.

 

Suggestion: use “JWT” for #2; pick a new name for #1 (= perhaps JSON Claim Set); lots of changes to spec text.

 

 <= /p>

JWT algorithm =3D HS256
HMAC HASH Key =3D=
 'aaa'
 
JSON E=
ncoded Header =3D "{"alg":"HS256","typ":=
"JWT"}"
JSON Encoded Payload =3D =
"{"response_type":"code id_token",
    "client_id":"s6BhdRkqt3"=
,
    "redirect_uri":&q=
uot;https://client.example.com/cb",
 =
   "scope":"openid profile",
    "state":"af0ifjsldkj",
    "nonce":"n-0S6_W=
zA2Mj",
    "userinfo&q=
uot;:{"claims":{"name":null,"nickname":{"=
;optional":true},
    &=
nbsp;   "email":null,"verified":null,
        "pictur=
e":{"optional":true}}},
 &nb=
sp;  "id_token":{"max_age":86400,"claims"=
;:{"acr":{"values":["2"]}}}=
 
<=
span style=3D'font-size:12.0pt;color:black'>JWT =3D eyJ0eXAiOiJKV1QiLCJhbGc=
iOiJIUzI1NiJ9.eyJyZXNwb25zZV90eXBlIjoiY29kZ
&nbs=
p;   SBpZF90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjd=
F91cmkiO
    iJodHRwczpcL1wvY2xpZ=
W50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3BlbmlkI
    HByb2ZpbGUiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwibm9uY2UiOiJu= LTBTNl9XekEyT
    WoiLCJ1c2VyaW5m=
byI6eyJjbGFpbXMiOnsibmFtZSI6bnVsbCwibmlja25hbWUiOnsib
    3B0aW9uYWwiOnRydWV9LCJlbWFpbCI6bnVsbCwidmVyaWZpZWQ=
iOm51bGwsInBpY3R1c
    mUiOnsib3B=
0aW9uYWwiOnRydWV9fX0sImlkX3Rva2VuIjp7Im1heF9hZ2UiOjg2NDAwL
    CJjbGFpbXMiOnsiYWNyIjp7InZhbHVlcyI6WyIyIl19fX=
19.ou2Yc1B9a5iZLqbzBxE9
    5aNS0=
pSfRClCqM77n85ehGo

 <= /o:p>

 

 

--

James Manger

 

= --_000_255B9BB34FB7D647A506DC292726F6E114F2EB077AWSMSG3153Vsrv_-- From vladimir@nimbusds.com Fri May 18 00:31: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 125EF21F8644 for ; Fri, 18 May 2012 00:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zik5oM5T0NFv for ; Fri, 18 May 2012 00:31:32 -0700 (PDT) Received: from n1plwbeout07-01.prod.ams1.secureserver.net (n1plsmtp07-01-02.prod.ams1.secureserver.net [188.121.52.106]) by ietfa.amsl.com (Postfix) with SMTP id 05C4721F8603 for ; Fri, 18 May 2012 00:31:31 -0700 (PDT) Received: (qmail 6853 invoked from network); 18 May 2012 07:31:30 -0000 Received: from unknown (HELO localhost) (188.121.52.245) by n1plwbeout07-01.prod.ams1.secureserver.net with SMTP; 18 May 2012 07:31:26 -0000 Received: (qmail 18939 invoked by uid 99); 18 May 2012 07:31:25 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 77.85.89.193 User-Agent: Workspace Webmail 5.6.17 Message-Id: <20120518003124.cc40c4f3d92d2001859047cd8cabb9ab.ced11553da.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: "Manger, James H" , "jose@ietf.org" Date: Fri, 18 May 2012 00:31:24 -0700 Mime-Version: 1.0 Subject: Re: [jose] Distinguishing signed, encrypted, and unprotected tokens 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, 18 May 2012 07:31:33 -0000 I suppose this recommendation is part legacy, part an effort to make=0Athin= gs future-proof.=0A=0AWhen I first started work on the Nimbus-JWT library, = that was in early=0A2012, the drafts specified three dots for plain, signed= and encrypted=0AJWTs. So there was no way to figure out the type from the = delimiter=0Acount and the "alg" value had to be inspected. =0A=0AI agree th= at "alg":"none" is superfluous and could be made optional.=0A=0A=0ACheers,= =0A=0AVladimir=0A=0A--=0AVladimir Dzhuvinov : www.NimbusDS.com : vladimir@n= imbusds.com=0A=0A=0A-------- Original Message --------=0ASubject: [jose] Di= stinguishing signed, encrypted, and unprotected=0Atokens=0AFrom: "Manger, J= ames H" =0ADate: Thu, May 17, 2012 5:57 am= =0ATo: "jose@ietf.org" =0A=0A=0Adraft-jones-json-web-token-1= 0#section-5 suggests looking at the "alg"=0Avalue in the header to distingu= ish whether you have a JWE, JWS, or plain=0AJWT.=0A=0AWouldn't it be better= to distinguish these cases by the number of dots:=0A* 3 dots (4 segments) = =3D> JWE=0A* 2 dots (3 segments) =3D> JWS=0AThen we could use 1 segment for= a plaintext JWT=0A* 0 dots (1 segment) =3D> Plaintext JWT (base64url-encod= ed JWT Claim Set)=0A=0ABenefits:=0A=0A1. JWT spec doesn't need to confusing= ly specify the "JWT header" as=0Athough it is a separate thing from a JWS o= r JWE header. Rules are=0Aspecified for the JWT header (unique names, no du= plicates, all=0Aunderstood or reject, JWT-specific "typ" definition) but su= rely these=0Ashould just be the JWS or JWE header rules as appropriate.=0A= =0A2. No need for the rather pointless "eyJhbGciOiJub25lIn0." prefix (for= =0A{"alg":"none"}) on plaintext JWTs=0A=0A3. Top-level code doesn't need to= know all sig & enc algs; can leave=0Athat to signing & encryption librarie= s=0A=0A4. Don't need to split, decode, parse header before passing JWT onto= JWS=0Aor JWE processing (which may well split, decode, and parse the same= =0Astuff all over again) [eg=0Ahttps://github.com/NimbusDS/Nimbus-JWT/blob/= master/src/com/nimbusds/jwt/JWT.java#LC137]=0A=0A5. Less risk that "none" i= s implemented as a proper JWS signature=0Averification algorithm and accide= ntally allows unsigned code to pass=0Asecurity gates.=0A=0A=0A--=0AJames Ma= nger=0A=0A_______________________________________________=0Ajose mailing li= st=0Ajose@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/jose=0A From ve7jtb@ve7jtb.com Fri May 18 04:45: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 CA00821F867A for ; Fri, 18 May 2012 04:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.533 X-Spam-Level: X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPJ-2g5T20pm for ; Fri, 18 May 2012 04:45:30 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id CBE1321F8631 for ; Fri, 18 May 2012 04:45:29 -0700 (PDT) Received: by ggnc4 with SMTP id c4so3210715ggn.31 for ; Fri, 18 May 2012 04:45:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=BfZZ8Un5BpmOZmRsaCX5g2Ybg6ntGpoPRi3F3xq1qQ0=; b=bPDIgaBt/6rScIsWAJxgtHPOsQjdp/soWf3Ey8fDwKpvJU23hld/IaTxo6To/eXvrK 6FD4noXUZBKUIQ/D/FqIbHZ3wI6fUGy3bBuHPY3SEXYufzUsEp5CMPjUeR4wphpkrDEm IvCZbz/4KyfdkKgd+9amNbi8cOLflO2jE1qUtYMFxZJj7jMzcLcjnoB5oj95xO9mEEe+ Nu73UmKITuMWKr5rVBtP9Ef4rss0ODNzKxFNzHyefme0q57GJgkqJWBFXYF7+CLnNYiO TW0u0roxF50cqmiP43BpRGsx0nq5ZrAJ0+EGQEKOCUvVira49MqXr8duMW/GpvKF/efn XCHg== Received: by 10.101.131.14 with SMTP id i14mr662678ann.44.1337341529252; Fri, 18 May 2012 04:45:29 -0700 (PDT) Received: from [192.168.1.213] (190-20-51-194.baf.movistar.cl. [190.20.51.194]) by mx.google.com with ESMTPS id j39sm16088172ani.3.2012.05.18.04.45.26 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 May 2012 04:45:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_0837D5F1-6416-4E5E-89F0-44BB718DB3C0"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F2E1C05D@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 18 May 2012 07:45:20 -0400 Message-Id: <44153647-17FA-4B02-B528-60456E1E4751@ve7jtb.com> References: <255B9BB34FB7D647A506DC292726F6E114F2E1C05D@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmX/LmN56G4+/2XxM3c9ngJjWLl+PC7y/IfhB8ja8zfcbpzigiBJG0qTTLjtR6OP+w9mMj/ Cc: "jose@ietf.org" Subject: Re: [jose] Distinguishing signed, encrypted, and unprotected tokens 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, 18 May 2012 11:45:30 -0000 --Apple-Mail=_0837D5F1-6416-4E5E-89F0-44BB718DB3C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I would be against using the number of segments to determine the type. = That has changes over time as we added integrity to encryption. I would not want to assume that some new algorithm might not need = another segment. =20 Their might also be attacks that we haven't considerd that might be = possible by altering the number of segments. I understand that it is an attractive shortcut, but I think the downside = is risky. John B. On 2012-05-17, at 12:57 AM, Manger, James H wrote: > draft-jones-json-web-token-10#section-5 suggests looking at the "alg" = value in the header to distinguish whether you have a JWE, JWS, or plain = JWT. >=20 > Wouldn't it be better to distinguish these cases by the number of = dots: > * 3 dots (4 segments) =3D> JWE > * 2 dots (3 segments) =3D> JWS > Then we could use 1 segment for a plaintext JWT > * 0 dots (1 segment) =3D> Plaintext JWT (base64url-encoded JWT Claim = Set) >=20 > Benefits: >=20 > 1. JWT spec doesn't need to confusingly specify the "JWT header" as = though it is a separate thing from a JWS or JWE header. Rules are = specified for the JWT header (unique names, no duplicates, all = understood or reject, JWT-specific "typ" definition) but surely these = should just be the JWS or JWE header rules as appropriate. >=20 > 2. No need for the rather pointless "eyJhbGciOiJub25lIn0." prefix (for = {"alg":"none"}) on plaintext JWTs >=20 > 3. Top-level code doesn't need to know all sig & enc algs; can leave = that to signing & encryption libraries >=20 > 4. Don't need to split, decode, parse header before passing JWT onto = JWS or JWE processing (which may well split, decode, and parse the same = stuff all over again) [eg = https://github.com/NimbusDS/Nimbus-JWT/blob/master/src/com/nimbusds/jwt/JW= T.java#LC137] >=20 > 5. Less risk that "none" is implemented as a proper JWS signature = verification algorithm and accidentally allows unsigned code to pass = security gates. >=20 >=20 > -- > James Manger >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_0837D5F1-6416-4E5E-89F0-44BB718DB3C0 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUx ODExNDUyMFowIwYJKoZIhvcNAQkEMRYEFO/NOMw7oFEjzDmtb3whysO7I6a4MIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB AHJwix9FWK8oM/qPnB3VXiWQfGJvCO23yF6wH7vPcdSeVfaLv83P7QTQ99QqaIr+2MzfQXeGg0Ab cIUhBwjLMQtCQIBQ1pCiG0A9v1txymwMcSQWuijhVGN8/TY1W07/IFIsEeJ+CRTUVqoHK92X26ev RbLid68cb2Jy5tkvNnP76IPBAfZDUrOx7K5sT3jtaTjslUslK5v/oYPVb4RpNcNNGS9p3V+4bMtg tcArIsqxAgpSiV5v/P3pvPmk+j/nK7+jm57GWGPZJPn2EJauPTv1ndsRWnzkB3eTRmU6fLrbpffX j98nx/7le3yWvSOR/l55GoaafOZaUKgMztWVZdIAAAAAAAA= --Apple-Mail=_0837D5F1-6416-4E5E-89F0-44BB718DB3C0-- From Michael.Jones@microsoft.com Fri May 18 09:07:04 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012DF21F874C for ; Fri, 18 May 2012 09:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[AWL=-1.302, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, TRACKER_ID=2.003] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEGrl+R8sGyd for ; Fri, 18 May 2012 09:07:02 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id BE69521F873E for ; Fri, 18 May 2012 09:07:01 -0700 (PDT) Received: from mail29-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Fri, 18 May 2012 16:06:50 +0000 Received: from mail29-va3 (localhost [127.0.0.1]) by mail29-va3-R.bigfish.com (Postfix) with ESMTP id 5453E4001C2; Fri, 18 May 2012 16:06:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VS-21(zz9371Ic85fhzz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail29-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail29-va3 (localhost.localdomain [127.0.0.1]) by mail29-va3 (MessageSwitch) id 1337357208112511_26454; Fri, 18 May 2012 16:06:48 +0000 (UTC) Received: from VA3EHSMHS014.bigfish.com (unknown [10.7.14.244]) by mail29-va3.bigfish.com (Postfix) with ESMTP id 18A873C0049; Fri, 18 May 2012 16:06:48 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS014.bigfish.com (10.7.99.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 18 May 2012 16:06:47 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0298.005; Fri, 18 May 2012 16:06:54 +0000 From: Mike Jones To: "Manger, James H" , "jose@ietf.org" Thread-Topic: Is an OpenID Connect request really a JWT? Thread-Index: Ac00sZXAvnxsTepNSaaPeYnzNySn2wACUaRA Date: Fri, 18 May 2012 16:06:53 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436650DB44@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <255B9BB34FB7D647A506DC292726F6E114F2EB077A@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F2EB077A@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.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436650DB44TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] Is an OpenID Connect request really a JWT? 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, 18 May 2012 16:07:04 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436650DB44TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Actually, I'd received similar feedback from other parties. It probably ma= kes sense to change the description of the OpenID Request Object from being= a JWT to being a JWS signed JSON object. BTW, if you would like to contribute to the OpenID Connect specs, the bette= r venue would be to join the working group and send your feedback to the Op= enID Specs AB mailing list http://lists.openid.net/mailman/listinfo/openid-= specs-ab. -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Man= ger, James H Sent: Thursday, May 17, 2012 9:49 PM To: jose@ietf.org Subject: [jose] Is an OpenID Connect request really a JWT? OpenID Connect [http://openid.net/specs/openid-connect-standard-1_0.html#re= q_param_method] says: "The request parameter is a JWT encoded OpenID Request Object... The JWT object MAY be signed or signed and encrypted via JWS and JWE" It gives the example below, which is a JWS with "typ":"JWT". The payload is= a JSON object with 8 fields (response_type, client_id, redirect_uri, scope= , state, nonce, userinfo (with lots of sub-fields), id_token (with sub-fiel= ds)). The payload has none of the 8 reserved claims from the JWT spec (exp,= nbf, iat, iss, aud, prn, jti, typ). Can we really call that a JWT? It seems implausible that the 8 fields in this example (response_type...) = are supposed to be treated as "Private Claim Names" as per the JWT spec. We have two totally separate ideas both being called "JWT". 1. JSON object carrying a bunch of claims. 2. A base64-based way to package any blob of bytes in unprotected, sig= ned, or encrypted forms. Suggestion: use "JWT" for #2; pick a new name for #1 (perhaps JSON Claim Se= t); lots of changes to spec text. JWT algorithm =3D HS256 HMAC HASH Key =3D 'aaa' JSON Encoded Header =3D "{"alg":"HS256","typ":"JWT"}" JSON Encoded Payload =3D "{"response_type":"code id_token", "client_id":"s6BhdRkqt3", "redirect_uri":"https://client.example.com/cb", "scope":"openid profile", "state":"af0ifjsldkj", "nonce":"n-0S6_WzA2Mj", "userinfo":{"claims":{"name":null,"nickname":{"optional":true}, "email":null,"verified":null, "picture":{"optional":true}}}, "id_token":{"max_age":86400,"claims":{"acr":{"values":["2"]}}} JWT =3D eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJyZXNwb25zZV90eXBlIjoiY29kZ SBpZF90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiO iJodHRwczpcL1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3BlbmlkI HByb2ZpbGUiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwibm9uY2UiOiJuLTBTNl9XekEyT WoiLCJ1c2VyaW5mbyI6eyJjbGFpbXMiOnsibmFtZSI6bnVsbCwibmlja25hbWUiOnsib 3B0aW9uYWwiOnRydWV9LCJlbWFpbCI6bnVsbCwidmVyaWZpZWQiOm51bGwsInBpY3R1c mUiOnsib3B0aW9uYWwiOnRydWV9fX0sImlkX3Rva2VuIjp7Im1heF9hZ2UiOjg2NDAwL CJjbGFpbXMiOnsiYWNyIjp7InZhbHVlcyI6WyIyIl19fX19.ou2Yc1B9a5iZLqbzBxE9 5aNS0pSfRClCqM77n85ehGo -- James Manger --_000_4E1F6AAD24975D4BA5B16804296739436650DB44TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Actually, I’d re= ceived similar feedback from other parties.  It probably makes sense to change the = description of the OpenID Request Object from being a JWT to being a JWS si= gned JSON object.

 

BTW, if you would like= to contribute to the OpenID Connect specs, the better venue would be to jo= in the working group and send your feedback to the OpenID Specs AB mailing = list http:/= /lists.openid.net/mailman/listinfo/openid-specs-ab.

 

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

 

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Manger, James H
Sent: Thursday, May 17, 2012 9:49 PM
To: jose@ietf.org
Subject: [jose] Is an OpenID Connect request really a JWT?

 

OpenID Connect [http= ://openid.net/specs/openid-connect-standard-1_0.html#req_param_method] = says:

  “The request param= eter is a JWT encoded OpenID Request Object…

   The JWT object MAY= be signed or signed and encrypted via JWS and JWE”=

 

It gives the example below, whi= ch is a JWS with “typ”:”JWT”. The payload is a JSON= object with 8 fields (response_type, client_id, redirect_uri, scope, state= , nonce, userinfo (with lots of sub-fields), id_token (with sub-fields)). The payload has none of the 8 reserved claims from the JWT s= pec (exp, nbf, iat, iss, aud, prn, jti, typ).

 

Can we really call that a JWT?<= o:p>

It seems implausible that the&n= bsp; 8 fields in this example (response_type…) are supposed to be tre= ated as “Private Claim Names” as per the JWT spec.

 

We have two totally separate id= eas both being called “JWT”.

1.  = ;    JSON object carrying a = bunch of claims.

2.  = ;    A base64-based way to p= ackage any blob of bytes in unprotected, signed, or encrypted forms.

 

Suggestion: use “JWT̶= 1; for #2; pick a new name for #1 (perhaps JSON Claim Set); lots of changes= to spec text.

 

 

JWT algorithm =3D HS256
HMAC HASH Key =3D 'aaa'
 
JSON Encoded Header =3D "{"alg":"HS2=
56","typ":"JWT"}"
JSON Encoded Payload =3D "{"response_type"=
;:"code id_token",
    "client_id":"s6BhdRkqt=
3",
    "redirect_uri":"https://client.example.com/cb"=
,
    "scope":"openid profil=
e",
    "state":"af0ifjsldkj&q=
uot;,
    "nonce":"n-0S6_WzA2Mj&=
quot;,
    "userinfo":{"claims&qu=
ot;:{"name":null,"nickname":{"optional":true}=
,
        "email&q=
uot;:null,"verified":null,
        "picture=
":{"optional":true}}},
    "id_token":{"max_age&q=
uot;:86400,"claims":{"acr":{"values":["2=
"]}}}
 
JWT =3D eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJyZXNwb25=
zZV90eXBlIjoiY29kZ
    SBpZF90b2tlbiIsImNsaWVudF9pZCI6InM2Qm=
hkUmtxdDMiLCJyZWRpcmVjdF91cmkiO
    iJodHRwczpcL1wvY2xpZW50LmV4YW1wbGUuY2=
9tXC9jYiIsInNjb3BlIjoib3BlbmlkI
    HByb2ZpbGUiLCJzdGF0ZSI6ImFmMGlmanNsZG=
tqIiwibm9uY2UiOiJuLTBTNl9XekEyT
    WoiLCJ1c2VyaW5mbyI6eyJjbGFpbXMiOnsibm=
FtZSI6bnVsbCwibmlja25hbWUiOnsib
    3B0aW9uYWwiOnRydWV9LCJlbWFpbCI6bnVsbC=
widmVyaWZpZWQiOm51bGwsInBpY3R1c
    mUiOnsib3B0aW9uYWwiOnRydWV9fX0sImlkX3=
Rva2VuIjp7Im1heF9hZ2UiOjg2NDAwL
    CJjbGFpbXMiOnsiYWNyIjp7InZhbHVlcyI6Wy=
IyIl19fX19.ou2Yc1B9a5iZLqbzBxE9
    5aNS0pSfRClCqM77n85ehGo

 

 

 

--

James Manger<= /p>

 

--_000_4E1F6AAD24975D4BA5B16804296739436650DB44TK5EX14MBXC284r_-- From ietf@augustcellars.com Sat May 19 15:34: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 8283E11E808F for ; Sat, 19 May 2012 15:34: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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T05RRQ6yFpsL for ; Sat, 19 May 2012 15:34:46 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id DE10421F844F for ; Sat, 19 May 2012 15:34:46 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 2806538EF1; Sat, 19 May 2012 15:34:46 -0700 (PDT) From: "Jim Schaad" To: "Mike Jones" Date: Sat, 19 May 2012 15:33:34 -0700 Message-ID: <020001cd360f$6da10190$48e304b0$@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: Ac0163Sed6pM9c+JR7OKMRgzzwxF3Q== Content-Language: en-us Cc: jose@ietf.org Subject: [jose] Comments on draft-ietf-jose-json-web-key-02 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 22:34:47 -0000 My apologies for introducing you to the term algorithm families. We don't use it in the same way and thus I think that you should generally remove it from the text. To me it is a very wide term and somewhat nebulous. Thus I think of all of the DH algorithms as being in a family - but that family could also include the ECDH algorithm as well as DSA depending on how one is using it. Thus for me an algorithm family is not restricted to a specific instance (or small set of instances) such a DH & DSA but could be as large as all key agreement algorithms. As such it does not really match how you are using it in much of the text. Slightly more detailed: You can define an RSA key You can define an RSA-OAEP key The second one has all of the fields of the first, however it may have additional fields defined that deal specifically with RSA-OAEP. The difference is going to be a question of restriction of usage of the key to a single algorithm vs allowing for all RSA algorithms. Here are some more comments Abstract 1. I am not a fan of the word enumerated in the last sentence. This word implies to me that the list is not expandable. I would recommend something along the lines of "An initial set of ... can be found in ..." 2. JSON needs to be expanded on first use Section 1 1. JSON needs to be expanded on first use. (Doing it on second use should be fine and clearer) 2. See enumerated comment above 3. Don't use non-goals. The wording "The goals of this document do not include ..." (Minor) 4. It is fine to tell me what documents they are used in. I don't know that we need to say what the fields are. (Minor) Section 2 1. The phrase "For the purpose of this document" should be removed unless this term is used in other ways elsewhere. Section 4 1. In para #2 - the use of "algorithm family" is incorrect. They members are going to be required for the specific key being represented not to the family - consider the case of RSA and RSA-OAEP - these are both in the same family, but the fields required are different. 2. Do you believe that all of the algorithm members are defined in the JWA document - or only for some algorithms. Text should probably say they are defined for the algorithms defined for the algorithms in JWA. 3. I don't believe that para #3 is enforceable by parsers as they have been presented to me. Please prove me wrong. 4. Let's look at the sentence "If present, they MUST be understood by implementations using them." I believe that this is an incorrect assertion. (Not to mention that it is totally uncheckable.) Consider the following situation: Implementation A creates a JWK and files it with Implementation B. A does not understand the "exist-date" property. Implementation B adds the "exist-date" property and puts it at a URL. Implementation C pulls the JWK from the URL, understand the "exist-date" property. According to the MUST, the JWK cannot be used as it is not understood by all of the implementations. The only entity that you can make the requirement on is the consumer. One assumes that the "provider" would/might understand the field or it would not be there but it could have been added in transit and thus that is not the case. 5. I find the last sentence of para #4 to be unreadable. I would start by breaking it into two sentences and potentially move the first one into the JWA document (that about parameters for keys). Section 4.1 1. Do you want to point to the JWA document or to the registry for the set of defined algorithms? 2. In para #1 I would remove the sentence starting "Specific additional..." as this is not part of the definition of the "alg" parameter and is covered in section 4.0 3. The last two sentences in para #1 can be combined together. Section 4.2 1. Presentation suggestion - if you use a bulleted list for the values it will be easier to see what the list of defined values is. 2. See point #3 in section 4.1 Section 4.3 1. Is there a requirement that the kid be unique in a JWK Set? I think that the answer should be called out in text either way. 2. Is the string case sensitive? 3. Move the sentence "When used..." to a new paragraph. (suggestion) Section 6.1 1. Please make things easy for IANA - create a table with the fields across the top and the values down the table. This will allow them to do their job without having to go through the entire document and for us to be able to easily validate that they got it correct. Section 6.2 1. Please put in a registration section for the items you are registering in Section 4 in the JWK table. You can refer to JWA for creation of the table. Appendix A 1. I am not sure why this appendix is in this document. From James.H.Manger@team.telstra.com Sun May 20 00:48:08 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10DE21F8510 for ; Sun, 20 May 2012 00:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKDkimcGEVB6 for ; Sun, 20 May 2012 00:48:08 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id AC53D21F850C for ; Sun, 20 May 2012 00:48:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,624,1330866000"; d="scan'208";a="74527552" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 20 May 2012 17:48:05 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6716"; a="63742729" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcdvi.tcif.telstra.com.au with ESMTP; 20 May 2012 17:48:04 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Sun, 20 May 2012 17:48:05 +1000 From: "Manger, James H" To: John Bradley Date: Sun, 20 May 2012 17:48:03 +1000 Thread-Topic: [jose] Distinguishing signed, encrypted, and unprotected tokens Thread-Index: Ac0068onEnUIi+WVSy+nf0GeUsQ+rwBar58Q Message-ID: <255B9BB34FB7D647A506DC292726F6E114F2F2E7DF@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114F2E1C05D@WSMSG3153V.srv.dir.telstra.com> <44153647-17FA-4B02-B528-60456E1E4751@ve7jtb.com> In-Reply-To: <44153647-17FA-4B02-B528-60456E1E4751@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] Distinguishing signed, encrypted, and unprotected tokens 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, 20 May 2012 07:48:08 -0000 First, for unprotected plaintext we still need the header to hold metadata = about the payload, like its type ("typ" header field). So I now suggest: * 3 dots (4 segments) =3D> JWE * 2 dots (3 segments) =3D> JWS * 1 dot (2 segments) =3D> unprotected payload (
.) If you don't like using the dot-count to distinguish these cases, how about= adding an explicit indication? For instance, a JWE is "E".
...; a JWS is "S".
.., and = an unprotected payload is "P".
.. Distinguishing using "alg" value is a poor choice. Consider receiving a JWT= in 2 year. After splitting on dots, base64 decoding, interpreting as UTF-8= , JSON parsing, and extracting "alg", you get the value "XY512". Uhmmm.. ob= viously a new algorithm has been defined since the initial publication of "= JWA" -- which is not too surprising, eg SHA-3 is expected soon. So you look= at the IANA web page for registered "alg" values. "XY512" is in the list. = Its usage is "alg" (not "enc" or "int"). That still means it could be a key= -wrapping alg or an asymmetric signature alg so you still cannot distinguis= h what you have. You follow the IANA reference to a spec for "XY512" and, a= t last, you know if you have a JWE or JWS. For many apps if you don't know the "alg" it doesn't really matter if it is= a JWE or JWS since you cannot decrypt or verify it so the app will just re= ject it. But for other apps (or other layers of an app or other steps in a = processing chain) it would be nice to distinguish signed/encrypted/plain at= bit more simply. -- James Manger -----Original Message----- From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 Sent: Friday, 18 May 2012 9:45 PM To: Manger, James H Cc: jose@ietf.org Subject: Re: [jose] Distinguishing signed, encrypted, and unprotected token= s I would be against using the number of segments to determine the type. Tha= t has changes over time as we added integrity to encryption. I would not want to assume that some new algorithm might not need another s= egment. =20 Their might also be attacks that we haven't considerd that might be possibl= e by altering the number of segments. I understand that it is an attractive shortcut, but I think the downside is= risky. John B. On 2012-05-17, at 12:57 AM, Manger, James H wrote: > draft-jones-json-web-token-10#section-5 suggests looking at the "alg" val= ue in the header to distinguish whether you have a JWE, JWS, or plain JWT. >=20 > Wouldn't it be better to distinguish these cases by the number of dots: > * 3 dots (4 segments) =3D> JWE > * 2 dots (3 segments) =3D> JWS > Then we could use 1 segment for a plaintext JWT > * 0 dots (1 segment) =3D> Plaintext JWT (base64url-encoded JWT Claim Set) >=20 > Benefits: >=20 > 1. JWT spec doesn't need to confusingly specify the "JWT header" as thoug= h it is a separate thing from a JWS or JWE header. Rules are specified for = the JWT header (unique names, no duplicates, all understood or reject, JWT-= specific "typ" definition) but surely these should just be the JWS or JWE h= eader rules as appropriate. >=20 > 2. No need for the rather pointless "eyJhbGciOiJub25lIn0." prefix (for {"= alg":"none"}) on plaintext JWTs >=20 > 3. Top-level code doesn't need to know all sig & enc algs; can leave that= to signing & encryption libraries >=20 > 4. Don't need to split, decode, parse header before passing JWT onto JWS = or JWE processing (which may well split, decode, and parse the same stuff a= ll over again) [eg https://github.com/NimbusDS/Nimbus-JWT/blob/master/src/c= om/nimbusds/jwt/JWT.java#LC137] >=20 > 5. Less risk that "none" is implemented as a proper JWS signature verific= ation algorithm and accidentally allows unsigned code to pass security gate= s. >=20 >=20 > -- > James Manger >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From James.H.Manger@team.telstra.com Sun May 20 01:06: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 4903C21F8598 for ; Sun, 20 May 2012 01:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.401 X-Spam-Level: * X-Spam-Status: No, score=1.401 tagged_above=-999 required=5 tests=[AWL=-2.302, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, TRACKER_ID=2.003] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTxzyWErYPzS for ; Sun, 20 May 2012 01:06:47 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id D9D5A21F8557 for ; Sun, 20 May 2012 01:06:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,625,1330866000"; d="scan'208,217";a="74528080" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 20 May 2012 18:06:46 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6716"; a="65209662" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcavi.tcif.telstra.com.au with ESMTP; 20 May 2012 18:06:46 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Sun, 20 May 2012 18:06:45 +1000 From: "Manger, James H" To: Mike Jones , "jose@ietf.org" Date: Sun, 20 May 2012 18:06:43 +1000 Thread-Topic: Is an OpenID Connect request really a JWT? Thread-Index: Ac00sZXAvnxsTepNSaaPeYnzNySn2wACUaRAAGiOcqA= Message-ID: <255B9BB34FB7D647A506DC292726F6E114F2F2E7E2@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114F2EB077A@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436650DB44@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436650DB44@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E114F2F2E7E2WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [jose] Is an OpenID Connect request really a JWT? 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, 20 May 2012 08:06:50 -0000 --_000_255B9BB34FB7D647A506DC292726F6E114F2F2E7E2WSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mike, > Actually, I'd received similar feedback from other parties. It probably = makes sense to change the description of the OpenID Request Object from bei= ng a JWT to being a JWS signed JSON object. I don't think so. The OpenID-Connect spec says the request "MAY be signed o= r signed and encrypted". It looks like the request can be a JWS, a JWE, or = unprotected. Saying it is a JWS doesn't cover the options. We do need a label for "a base64-based way to package a blob of bytes in un= protected, signed, or encrypted forms". How about keeping "JWT" for this (and not for a JSON object carrying a bunc= h of claims)? In either case "typ":"JWT" is wrong in this instance. > BTW, if you would like to contribute to the OpenID Connect specs, the bet= ter venue would be to join the working group and send your feedback to the = OpenID Specs AB mailing list http://lists.openid.net/mailman/listinfo/openi= d-specs-ab. At the moment I was focusing on the JOSE's JWx specs. OpenID Connect was ju= st a good illustration of confusion around "JWT". [P.S. Should the "signed and encrypted" option quoted above from OpenID Con= nect actually be "signed then encrypted"?] -- James Manger From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Man= ger, James H Sent: Thursday, May 17, 2012 9:49 PM To: jose@ietf.org Subject: [jose] Is an OpenID Connect request really a JWT? OpenID Connect [http://openid.net/specs/openid-connect-standard-1_0.html#re= q_param_method] says: "The request parameter is a JWT encoded OpenID Request Object... The JWT object MAY be signed or signed and encrypted via JWS and JWE" It gives the example below, which is a JWS with "typ":"JWT". The payload is= a JSON object with 8 fields (response_type, client_id, redirect_uri, scope= , state, nonce, userinfo (with lots of sub-fields), id_token (with sub-fiel= ds)). The payload has none of the 8 reserved claims from the JWT spec (exp,= nbf, iat, iss, aud, prn, jti, typ). Can we really call that a JWT? It seems implausible that the 8 fields in this example (response_type...) = are supposed to be treated as "Private Claim Names" as per the JWT spec. We have two totally separate ideas both being called "JWT". 1. JSON object carrying a bunch of claims. 2. A base64-based way to package any blob of bytes in unprotected, si= gned, or encrypted forms. Suggestion: use "JWT" for #2; pick a new name for #1 (perhaps JSON Claim Se= t); lots of changes to spec text. JWT algorithm =3D HS256 HMAC HASH Key =3D 'aaa' JSON Encoded Header =3D "{"alg":"HS256","typ":"JWT"}" JSON Encoded Payload =3D "{"response_type":"code id_token", "client_id":"s6BhdRkqt3", "redirect_uri":"https://client.example.com/cb", "scope":"openid profile", "state":"af0ifjsldkj", "nonce":"n-0S6_WzA2Mj", "userinfo":{"claims":{"name":null,"nickname":{"optional":true}, "email":null,"verified":null, "picture":{"optional":true}}}, "id_token":{"max_age":86400,"claims":{"acr":{"values":["2"]}}} JWT =3D eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJyZXNwb25zZV90eXBlIjoiY29kZ SBpZF90b2tlbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiO iJodHRwczpcL1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYiIsInNjb3BlIjoib3BlbmlkI HByb2ZpbGUiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwibm9uY2UiOiJuLTBTNl9XekEyT WoiLCJ1c2VyaW5mbyI6eyJjbGFpbXMiOnsibmFtZSI6bnVsbCwibmlja25hbWUiOnsib 3B0aW9uYWwiOnRydWV9LCJlbWFpbCI6bnVsbCwidmVyaWZpZWQiOm51bGwsInBpY3R1c mUiOnsib3B0aW9uYWwiOnRydWV9fX0sImlkX3Rva2VuIjp7Im1heF9hZ2UiOjg2NDAwL CJjbGFpbXMiOnsiYWNyIjp7InZhbHVlcyI6WyIyIl19fX19.ou2Yc1B9a5iZLqbzBxE9 5aNS0pSfRClCqM77n85ehGo -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E114F2F2E7E2WSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mike,

 

> Actually, I’d received simila= r feedback from other parties.  It probably makes sense to change the = description of the OpenID Request Object from being a JWT to being a JWS si= gned JSON object.

 = ;

I don’t think so. The OpenID-Connect spec says the request = 220;MAY be signed or signed and encrypted”. It looks like the request= can be a JWS, a JWE, or unprotected. Saying it is a JWS doesn’t cove= r the options.

 

<= span lang=3DEN-US style=3D'color:#1F497D'>We do need a label for “a base64-based way to package a blob of b= ytes in unprotected, signed, or encrypted forms”.

How about keeping R= 20;JWT” for this (and not for a JSON object carrying a bunch of claim= s)?

In either case “typ”:”JWT” is wrong in this instan= ce.

 

 

> BTW, if you would like to contribute to the O= penID Connect specs, the better venue would be to join the working group an= d send your feedback to the OpenID Specs AB mailing list http://lists.openid.net/= mailman/listinfo/openid-specs-ab.

 

At the mom= ent I was focusing on the JOSE’s JWx specs. OpenID Connect was just a= good illustration of confusion around “JWT”.

&= nbsp;

[P.S. Should the “signed and encrypted” option quote= d above from OpenID Connect actually be “signed then encrypted”= ?]

 

--

= James Manger

&nbs= p;

From:<= /b> jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Manger, James H
Sent: Thursday, May 17, 2012 9:49 PM
To:
jose@ietf.org
Subject: [jose] Is an OpenID Connect reque= st really a JWT?

 

OpenID Conn= ect [http://openid.net/specs/openid-connect-standard-1_0.html#re= q_param_method] says:

  “= The request parameter is a JWT encoded OpenID Request Object…

   The JWT object MAY be signed or si= gned and encrypted via JWS and JWE”

 

It gives the example below, whi= ch is a JWS with “typ”:”JWT”. The payload is a JSON= object with 8 fields (response_type, client_id, redirect_uri, scope, state= , nonce, userinfo (with lots of sub-fields), id_token (with sub-fields)). T= he payload has none of the 8 reserved claims from the JWT spec (exp, nbf, i= at, iss, aud, prn, jti, typ).

 = ;

Can we really call that a JWT?

It seems implausible that the  8 fields in this= example (response_type…) are supposed to be treated as “Privat= e Claim Names” as per the JWT spec.

 

We have two totally separate id= eas both being called “JWT”.

1.       JS= ON object carrying a bunch of claims.

2.       A bas= e64-based way to package any blob of bytes in unprotected, signed, or encry= pted forms.

 

Suggestion: use “JWT” for #2; pick a new name for= #1 (perhaps JSON Claim Set); lots of changes to spec text.

<= p class=3DMsoNormal> 

 

JWT algorithm =3D HS256
HMAC HASH Ke=
y =3D 'aaa'
 
JS=
ON Encoded Header =3D "{"alg":"HS256","typ&qu=
ot;:"JWT"}"
JSON Encoded Payload =
=3D "{"response_type":"code id_token",<=
/span>
    "client_id":"s6BhdRkqt3&q=
uot;,
    "redirect_uri&quo=
t;:"https://client.example.c=
om/cb",
<=
span style=3D'font-size:12.0pt;color:black'>    "scope&=
quot;:"openid profile",
  &n=
bsp; "state":"af0ifjsldkj",
=     "nonce":"n-0S6_WzA2Mj",
    "userinfo":{"claims":=
{"name":null,"nickname":{"optional":true},
        "e=
mail":null,"verified":null,
 =
;       "picture":{"optional&q=
uot;:true}}},
    "id_token&=
quot;:{"max_age":86400,"claims":{"acr":{"=
;values":["2"]}}}
 
JWT =3D eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJyZXNwb25=
zZV90eXBlIjoiY29kZ
    SBpZF90b2t=
lbiIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmVjdF91cmkiO
    iJodHRwczpcL1wvY2xpZW50LmV4YW1wbGUuY29tXC9jYi=
IsInNjb3BlIjoib3BlbmlkI
    HByb2=
ZpbGUiLCJzdGF0ZSI6ImFmMGlmanNsZGtqIiwibm9uY2UiOiJuLTBTNl9XekEyT<=
/span>
    WoiLCJ1c2VyaW5mbyI6eyJjbGFpbXMiOnsibmFtZ=
SI6bnVsbCwibmlja25hbWUiOnsib
    =
3B0aW9uYWwiOnRydWV9LCJlbWFpbCI6bnVsbCwidmVyaWZpZWQiOm51bGwsInBpY3R1c
    mUiOnsib3B0aW9uYWwiOnRydWV9fX0sImlk=
X3Rva2VuIjp7Im1heF9hZ2UiOjg2NDAwL
  &n=
bsp; CJjbGFpbXMiOnsiYWNyIjp7InZhbHVlcyI6WyIyIl19fX19.ou2Yc1B9a5iZLqbzBxE9
    5aNS0pSfRClCqM77n85ehGo

 

 

 

--

James Manger=

 

= --_000_255B9BB34FB7D647A506DC292726F6E114F2F2E7E2WSMSG3153Vsrv_-- From Michael.Jones@microsoft.com Sun May 20 09:14: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 10E4221F8613 for ; Sun, 20 May 2012 09:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYOOczlFNnys for ; Sun, 20 May 2012 09:14:43 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id AA1CB21F8615 for ; Sun, 20 May 2012 09:14:42 -0700 (PDT) Received: from mail46-db3-R.bigfish.com (10.3.81.236) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Sun, 20 May 2012 16:14:29 +0000 Received: from mail46-db3 (localhost [127.0.0.1]) by mail46-db3-R.bigfish.com (Postfix) with ESMTP id 84E1948007F; Sun, 20 May 2012 16:14:29 +0000 (UTC) X-SpamScore: -38 X-BigFish: VS-38(zz9371I936eK542M1432N98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail46-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=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail46-db3 (localhost.localdomain [127.0.0.1]) by mail46-db3 (MessageSwitch) id 1337530468133578_12104; Sun, 20 May 2012 16:14:28 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.232]) by mail46-db3.bigfish.com (Postfix) with ESMTP id 105BC140350; Sun, 20 May 2012 16:14:28 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 20 May 2012 16:14:27 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0298.005; Sun, 20 May 2012 16:14:36 +0000 From: Mike Jones To: "Manger, James H" , John Bradley Thread-Topic: [jose] Distinguishing signed, encrypted, and unprotected tokens Thread-Index: Ac0z6YIAkxSNdpPpSJGGHmreRKfuNABAjGsAAFxLuoAAEX8o8A== Date: Sun, 20 May 2012 16:14:35 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436651017C@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <255B9BB34FB7D647A506DC292726F6E114F2E1C05D@WSMSG3153V.srv.dir.telstra.com> <44153647-17FA-4B02-B528-60456E1E4751@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E114F2F2E7DF@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F2F2E7DF@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.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Distinguishing signed, encrypted, and unprotected tokens 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, 20 May 2012 16:14:44 -0000 Per http://tools.ietf.org/html/draft-jones-json-web-token-08#section-5, the= re already is an explicit indication in the header. A second method is determining whether an "enc" (encryption method) member exists. If the "enc" member exists, the JWT is a JWE; otherwise, the JWT is a JWS. Both methods will yield the same result. Use that method if you prefer, as it is algorithm independent. Adding a se= cond explicit indication would be redundant. BTW, JWT is not a JOSE spec - it has been accepted as an OAuth spec. If yo= u want to continue this thread, I suggest removing jose@ietf.org and adding= oauth@ietf.org. Best wishes, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Man= ger, James H Sent: Sunday, May 20, 2012 12:48 AM To: John Bradley Cc: jose@ietf.org Subject: Re: [jose] Distinguishing signed, encrypted, and unprotected token= s First, for unprotected plaintext we still need the header to hold metadata = about the payload, like its type ("typ" header field). So I now suggest: * 3 dots (4 segments) =3D> JWE * 2 dots (3 segments) =3D> JWS * 1 dot (2 segments) =3D> unprotected payload (
.) If you don't like using the dot-count to distinguish these cases, how about= adding an explicit indication? For instance, a JWE is "E".
...; a JWS is "S".
.., and = an unprotected payload is "P".
.. Distinguishing using "alg" value is a poor choice. Consider receiving a JWT= in 2 year. After splitting on dots, base64 decoding, interpreting as UTF-8= , JSON parsing, and extracting "alg", you get the value "XY512". Uhmmm.. ob= viously a new algorithm has been defined since the initial publication of "= JWA" -- which is not too surprising, eg SHA-3 is expected soon. So you look= at the IANA web page for registered "alg" values. "XY512" is in the list. = Its usage is "alg" (not "enc" or "int"). That still means it could be a key= -wrapping alg or an asymmetric signature alg so you still cannot distinguis= h what you have. You follow the IANA reference to a spec for "XY512" and, a= t last, you know if you have a JWE or JWS. For many apps if you don't know the "alg" it doesn't really matter if it is= a JWE or JWS since you cannot decrypt or verify it so the app will just re= ject it. But for other apps (or other layers of an app or other steps in a = processing chain) it would be nice to distinguish signed/encrypted/plain at= bit more simply. -- James Manger -----Original Message----- From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 Sent: Friday, 18 May 2012 9:45 PM To: Manger, James H Cc: jose@ietf.org Subject: Re: [jose] Distinguishing signed, encrypted, and unprotected token= s I would be against using the number of segments to determine the type. Tha= t has changes over time as we added integrity to encryption. I would not want to assume that some new algorithm might not need another s= egment. =20 Their might also be attacks that we haven't considerd that might be possibl= e by altering the number of segments. I understand that it is an attractive shortcut, but I think the downside is= risky. John B. On 2012-05-17, at 12:57 AM, Manger, James H wrote: > draft-jones-json-web-token-10#section-5 suggests looking at the "alg" val= ue in the header to distinguish whether you have a JWE, JWS, or plain JWT. >=20 > Wouldn't it be better to distinguish these cases by the number of dots: > * 3 dots (4 segments) =3D> JWE > * 2 dots (3 segments) =3D> JWS > Then we could use 1 segment for a plaintext JWT > * 0 dots (1 segment) =3D> Plaintext JWT (base64url-encoded JWT Claim Set) >=20 > Benefits: >=20 > 1. JWT spec doesn't need to confusingly specify the "JWT header" as thoug= h it is a separate thing from a JWS or JWE header. Rules are specified for = the JWT header (unique names, no duplicates, all understood or reject, JWT-= specific "typ" definition) but surely these should just be the JWS or JWE h= eader rules as appropriate. >=20 > 2. No need for the rather pointless "eyJhbGciOiJub25lIn0." prefix (for {"= alg":"none"}) on plaintext JWTs >=20 > 3. Top-level code doesn't need to know all sig & enc algs; can leave that= to signing & encryption libraries >=20 > 4. Don't need to split, decode, parse header before passing JWT onto JWS = or JWE processing (which may well split, decode, and parse the same stuff a= ll over again) [eg https://github.com/NimbusDS/Nimbus-JWT/blob/master/src/c= om/nimbusds/jwt/JWT.java#LC137] >=20 > 5. Less risk that "none" is implemented as a proper JWS signature verific= ation algorithm and accidentally allows unsigned code to pass security gate= s. >=20 >=20 > -- > James Manger >=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 ietf@augustcellars.com Sun May 20 12:13: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 DE0A121F861F for ; Sun, 20 May 2012 12:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKCDBmNl+48j for ; Sun, 20 May 2012 12:13:57 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 867CC21F84B4 for ; Sun, 20 May 2012 12:13:52 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id DE9F92C9EB; Sun, 20 May 2012 12:13:51 -0700 (PDT) From: "Jim Schaad" To: "'Manger, James H'" , "'John Bradley'" References: <255B9BB34FB7D647A506DC292726F6E114F2E1C05D@WSMSG3153V.srv.dir.telstra.com> <44153647-17FA-4B02-B528-60456E1E4751@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E114F2F2E7DF@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F2F2E7DF@WSMSG3153V.srv.dir.telstra.com> Date: Sun, 20 May 2012 12:12:36 -0700 Message-ID: <021601cd36bc$86606bf0$932143d0$@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: AQL5L75P0xQyaLeFm5IUgTTaTlNUsAKRtAsVAYmpQ/uUWj58YA== Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] Distinguishing signed, encrypted, and unprotected tokens 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, 20 May 2012 19:13:58 -0000 What happens if you are distinguishing based on the number of dots and then you move to a new encoding format that is not dot separated? Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Manger, James H > Sent: Sunday, May 20, 2012 12:48 AM > To: John Bradley > Cc: jose@ietf.org > Subject: Re: [jose] Distinguishing signed, encrypted, and unprotected tokens > > First, for unprotected plaintext we still need the header to hold metadata > about the payload, like its type ("typ" header field). So I now suggest: > * 3 dots (4 segments) => JWE > * 2 dots (3 segments) => JWS > * 1 dot (2 segments) => unprotected payload (
.) > > If you don't like using the dot-count to distinguish these cases, how about > adding an explicit indication? For instance, a JWE is > "E".
...; a JWS is > "S".
.., and an unprotected payload is > "P".
.. > > Distinguishing using "alg" value is a poor choice. Consider receiving a JWT in 2 > year. After splitting on dots, base64 decoding, interpreting as UTF-8, JSON > parsing, and extracting "alg", you get the value "XY512". Uhmmm.. obviously > a new algorithm has been defined since the initial publication of "JWA" -- > which is not too surprising, eg SHA-3 is expected soon. So you look at the > IANA web page for registered "alg" values. "XY512" is in the list. Its usage is > "alg" (not "enc" or "int"). That still means it could be a key-wrapping alg or an > asymmetric signature alg so you still cannot distinguish what you have. You > follow the IANA reference to a spec for "XY512" and, at last, you know if you > have a JWE or JWS. > > For many apps if you don't know the "alg" it doesn't really matter if it is a JWE > or JWS since you cannot decrypt or verify it so the app will just reject it. But > for other apps (or other layers of an app or other steps in a processing chain) > it would be nice to distinguish signed/encrypted/plain at bit more simply. > > -- > James Manger > > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com] > Sent: Friday, 18 May 2012 9:45 PM > To: Manger, James H > Cc: jose@ietf.org > Subject: Re: [jose] Distinguishing signed, encrypted, and unprotected tokens > > I would be against using the number of segments to determine the type. > That has changes over time as we added integrity to encryption. > > I would not want to assume that some new algorithm might not need > another segment. > > Their might also be attacks that we haven't considerd that might be possible > by altering the number of segments. > > I understand that it is an attractive shortcut, but I think the downside is risky. > > John B. > > On 2012-05-17, at 12:57 AM, Manger, James H wrote: > > > draft-jones-json-web-token-10#section-5 suggests looking at the "alg" > value in the header to distinguish whether you have a JWE, JWS, or plain > JWT. > > > > Wouldn't it be better to distinguish these cases by the number of dots: > > * 3 dots (4 segments) => JWE > > * 2 dots (3 segments) => JWS > > Then we could use 1 segment for a plaintext JWT > > * 0 dots (1 segment) => Plaintext JWT (base64url-encoded JWT Claim Set) > > > > Benefits: > > > > 1. JWT spec doesn't need to confusingly specify the "JWT header" as > though it is a separate thing from a JWS or JWE header. Rules are specified > for the JWT header (unique names, no duplicates, all understood or reject, > JWT-specific "typ" definition) but surely these should just be the JWS or JWE > header rules as appropriate. > > > > 2. No need for the rather pointless "eyJhbGciOiJub25lIn0." prefix (for > {"alg":"none"}) on plaintext JWTs > > > > 3. Top-level code doesn't need to know all sig & enc algs; can leave that to > signing & encryption libraries > > > > 4. Don't need to split, decode, parse header before passing JWT onto JWS > or JWE processing (which may well split, decode, and parse the same stuff all > over again) [eg https://github.com/NimbusDS/Nimbus- > JWT/blob/master/src/com/nimbusds/jwt/JWT.java#LC137] > > > > 5. Less risk that "none" is implemented as a proper JWS signature > verification algorithm and accidentally allows unsigned code to pass security > gates. > > > > > > -- > > 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 rbarnes@bbn.com Sun May 20 12:23: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 5BAC121F85BB for ; Sun, 20 May 2012 12:23:58 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLJ8Y+dxYwnb for ; Sun, 20 May 2012 12:23:57 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 87B9B21F845A for ; Sun, 20 May 2012 12:23:57 -0700 (PDT) Received: from [128.89.254.181] (port=53479) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SWBio-000Bxa-JR; Sun, 20 May 2012 15:23:18 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <021601cd36bc$86606bf0$932143d0$@augustcellars.com> Date: Sun, 20 May 2012 15:23:47 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <255B9BB34FB7D647A506DC292726F6E114F2E1C05D@WSMSG3153V.srv.dir.telstra.com> <44153647-17FA-4B02-B528-60456E1E4751@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E114F2F2E7DF@WSMSG3153V.srv.dir.telstra.com> <021601cd36bc$86606bf0$932143d0$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1257) Cc: 'John Bradley' , "'Manger, James H'" , jose@ietf.org Subject: Re: [jose] Distinguishing signed, encrypted, and unprotected tokens 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, 20 May 2012 19:23:58 -0000 +1 Distinguishing based on number of dots seems really fragile. On May 20, 2012, at 3:12 PM, Jim Schaad wrote: > > > What happens if you are distinguishing based on the number of dots and then > you move to a new encoding format that is not dot separated? > > Jim > > >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of >> Manger, James H >> Sent: Sunday, May 20, 2012 12:48 AM >> To: John Bradley >> Cc: jose@ietf.org >> Subject: Re: [jose] Distinguishing signed, encrypted, and unprotected > tokens >> >> First, for unprotected plaintext we still need the header to hold metadata >> about the payload, like its type ("typ" header field). So I now suggest: >> * 3 dots (4 segments) => JWE >> * 2 dots (3 segments) => JWS >> * 1 dot (2 segments) => unprotected payload (
.) >> >> If you don't like using the dot-count to distinguish these cases, how > about >> adding an explicit indication? For instance, a JWE is >> "E".
...; a JWS is >> "S".
.., and an unprotected payload is >> "P".
.. >> >> Distinguishing using "alg" value is a poor choice. Consider receiving a > JWT in 2 >> year. After splitting on dots, base64 decoding, interpreting as UTF-8, > JSON >> parsing, and extracting "alg", you get the value "XY512". Uhmmm.. > obviously >> a new algorithm has been defined since the initial publication of "JWA" -- >> which is not too surprising, eg SHA-3 is expected soon. So you look at the >> IANA web page for registered "alg" values. "XY512" is in the list. Its > usage is >> "alg" (not "enc" or "int"). That still means it could be a key-wrapping > alg or an >> asymmetric signature alg so you still cannot distinguish what you have. > You >> follow the IANA reference to a spec for "XY512" and, at last, you know if > you >> have a JWE or JWS. >> >> For many apps if you don't know the "alg" it doesn't really matter if it > is a JWE >> or JWS since you cannot decrypt or verify it so the app will just reject > it. But >> for other apps (or other layers of an app or other steps in a processing > chain) >> it would be nice to distinguish signed/encrypted/plain at bit more simply. >> >> -- >> James Manger >> >> -----Original Message----- >> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >> Sent: Friday, 18 May 2012 9:45 PM >> To: Manger, James H >> Cc: jose@ietf.org >> Subject: Re: [jose] Distinguishing signed, encrypted, and unprotected > tokens >> >> I would be against using the number of segments to determine the type. >> That has changes over time as we added integrity to encryption. >> >> I would not want to assume that some new algorithm might not need >> another segment. >> >> Their might also be attacks that we haven't considerd that might be > possible >> by altering the number of segments. >> >> I understand that it is an attractive shortcut, but I think the downside > is risky. >> >> John B. >> >> On 2012-05-17, at 12:57 AM, Manger, James H wrote: >> >>> draft-jones-json-web-token-10#section-5 suggests looking at the "alg" >> value in the header to distinguish whether you have a JWE, JWS, or plain >> JWT. >>> >>> Wouldn't it be better to distinguish these cases by the number of dots: >>> * 3 dots (4 segments) => JWE >>> * 2 dots (3 segments) => JWS >>> Then we could use 1 segment for a plaintext JWT >>> * 0 dots (1 segment) => Plaintext JWT (base64url-encoded JWT Claim Set) >>> >>> Benefits: >>> >>> 1. JWT spec doesn't need to confusingly specify the "JWT header" as >> though it is a separate thing from a JWS or JWE header. Rules are > specified >> for the JWT header (unique names, no duplicates, all understood or reject, >> JWT-specific "typ" definition) but surely these should just be the JWS or > JWE >> header rules as appropriate. >>> >>> 2. No need for the rather pointless "eyJhbGciOiJub25lIn0." prefix (for >> {"alg":"none"}) on plaintext JWTs >>> >>> 3. Top-level code doesn't need to know all sig & enc algs; can leave > that to >> signing & encryption libraries >>> >>> 4. Don't need to split, decode, parse header before passing JWT onto JWS >> or JWE processing (which may well split, decode, and parse the same stuff > all >> over again) [eg https://github.com/NimbusDS/Nimbus- >> JWT/blob/master/src/com/nimbusds/jwt/JWT.java#LC137] >>> >>> 5. Less risk that "none" is implemented as a proper JWS signature >> verification algorithm and accidentally allows unsigned code to pass > security >> gates. >>> >>> >>> -- >>> 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 > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Sun May 20 15:44: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 BFA9D21F853D for ; Sun, 20 May 2012 15:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZNv-8igbh-P for ; Sun, 20 May 2012 15:44:02 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id 3C47721F853C for ; Sun, 20 May 2012 15:44:01 -0700 (PDT) Received: from mail113-db3-R.bigfish.com (10.3.81.247) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Sun, 20 May 2012 22:43:49 +0000 Received: from mail113-db3 (localhost [127.0.0.1]) by mail113-db3-R.bigfish.com (Postfix) with ESMTP id 4CDCA600E7; Sun, 20 May 2012 22:43:49 +0000 (UTC) X-SpamScore: -38 X-BigFish: VS-38(zz9371I936eK542M1432N98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail113-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail113-db3 (localhost.localdomain [127.0.0.1]) by mail113-db3 (MessageSwitch) id 1337553827370952_14905; Sun, 20 May 2012 22:43:47 +0000 (UTC) Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.234]) by mail113-db3.bigfish.com (Postfix) with ESMTP id 5596F180045; Sun, 20 May 2012 22:43:47 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 20 May 2012 22:43:46 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0298.005; Sun, 20 May 2012 22:43:57 +0000 From: Mike Jones To: "Richard L. Barnes" , Jim Schaad Thread-Topic: [jose] Distinguishing signed, encrypted, and unprotected tokens Thread-Index: Ac0z6YIAkxSNdpPpSJGGHmreRKfuNABAjGsAAFxLuoAAF+hbAAAAY/yAAAbafnA= Date: Sun, 20 May 2012 22:43:56 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366510478@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <255B9BB34FB7D647A506DC292726F6E114F2E1C05D@WSMSG3153V.srv.dir.telstra.com> <44153647-17FA-4B02-B528-60456E1E4751@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E114F2F2E7DF@WSMSG3153V.srv.dir.telstra.com> <021601cd36bc$86606bf0$932143d0$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: 'John Bradley' , "'Manger, James H'" , "jose@ietf.org" Subject: Re: [jose] Distinguishing signed, encrypted, and unprotected tokens 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, 20 May 2012 22:44:03 -0000 Indeed, we already have a JSON format proposed in response working group in= put with no dots. See these specs: http://tools.ietf.org/html/draft-jones-json-web-signature-json-serializati= on-01 http://tools.ietf.org/html/draft-jones-json-web-encryption-json-serializat= ion-01 -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard L. Barnes Sent: Sunday, May 20, 2012 12:24 PM To: Jim Schaad Cc: 'John Bradley'; 'Manger, James H'; jose@ietf.org Subject: Re: [jose] Distinguishing signed, encrypted, and unprotected token= s +1 Distinguishing based on number of dots seems really fragile. =20 On May 20, 2012, at 3:12 PM, Jim Schaad wrote: > >=20 > What happens if you are distinguishing based on the number of dots and=20 > then you move to a new encoding format that is not dot separated? >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20 >> Of Manger, James H >> Sent: Sunday, May 20, 2012 12:48 AM >> To: John Bradley >> Cc: jose@ietf.org >> Subject: Re: [jose] Distinguishing signed, encrypted, and unprotected > tokens >>=20 >> First, for unprotected plaintext we still need the header to hold=20 >> metadata about the payload, like its type ("typ" header field). So I now= suggest: >> * 3 dots (4 segments) =3D> JWE >> * 2 dots (3 segments) =3D> JWS >> * 1 dot (2 segments) =3D> unprotected payload (
.) >>=20 >> If you don't like using the dot-count to distinguish these cases, how > about >> adding an explicit indication? For instance, a JWE is=20 >> "E".
...; a JWS is=20 >> "S".
.., and an unprotected payload is=20 >> "P".
.. >>=20 >> Distinguishing using "alg" value is a poor choice. Consider receiving=20 >> a > JWT in 2 >> year. After splitting on dots, base64 decoding, interpreting as=20 >> UTF-8, > JSON >> parsing, and extracting "alg", you get the value "XY512". Uhmmm.. > obviously >> a new algorithm has been defined since the initial publication of=20 >> "JWA" -- which is not too surprising, eg SHA-3 is expected soon. So=20 >> you look at the IANA web page for registered "alg" values. "XY512" is=20 >> in the list. Its > usage is >> "alg" (not "enc" or "int"). That still means it could be a=20 >> key-wrapping > alg or an >> asymmetric signature alg so you still cannot distinguish what you have. > You >> follow the IANA reference to a spec for "XY512" and, at last, you=20 >> know if > you >> have a JWE or JWS. >>=20 >> For many apps if you don't know the "alg" it doesn't really matter if=20 >> it > is a JWE >> or JWS since you cannot decrypt or verify it so the app will just=20 >> reject > it. But >> for other apps (or other layers of an app or other steps in a=20 >> processing > chain) >> it would be nice to distinguish signed/encrypted/plain at bit more simpl= y. >>=20 >> -- >> James Manger >>=20 >> -----Original Message----- >> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >> Sent: Friday, 18 May 2012 9:45 PM >> To: Manger, James H >> Cc: jose@ietf.org >> Subject: Re: [jose] Distinguishing signed, encrypted, and unprotected > tokens >>=20 >> I would be against using the number of segments to determine the type. >> That has changes over time as we added integrity to encryption. >>=20 >> I would not want to assume that some new algorithm might not need=20 >> another segment. >>=20 >> Their might also be attacks that we haven't considerd that might be > possible >> by altering the number of segments. >>=20 >> I understand that it is an attractive shortcut, but I think the=20 >> downside > is risky. >>=20 >> John B. >>=20 >> On 2012-05-17, at 12:57 AM, Manger, James H wrote: >>=20 >>> draft-jones-json-web-token-10#section-5 suggests looking at the "alg" >> value in the header to distinguish whether you have a JWE, JWS, or=20 >> plain JWT. >>>=20 >>> Wouldn't it be better to distinguish these cases by the number of dots: >>> * 3 dots (4 segments) =3D> JWE >>> * 2 dots (3 segments) =3D> JWS >>> Then we could use 1 segment for a plaintext JWT >>> * 0 dots (1 segment) =3D> Plaintext JWT (base64url-encoded JWT Claim=20 >>> Set) >>>=20 >>> Benefits: >>>=20 >>> 1. JWT spec doesn't need to confusingly specify the "JWT header" as >> though it is a separate thing from a JWS or JWE header. Rules are > specified >> for the JWT header (unique names, no duplicates, all understood or=20 >> reject, JWT-specific "typ" definition) but surely these should just=20 >> be the JWS or > JWE >> header rules as appropriate. >>>=20 >>> 2. No need for the rather pointless "eyJhbGciOiJub25lIn0." prefix=20 >>> (for >> {"alg":"none"}) on plaintext JWTs >>>=20 >>> 3. Top-level code doesn't need to know all sig & enc algs; can leave > that to >> signing & encryption libraries >>>=20 >>> 4. Don't need to split, decode, parse header before passing JWT onto=20 >>> JWS >> or JWE processing (which may well split, decode, and parse the same=20 >> stuff > all >> over again) [eg https://github.com/NimbusDS/Nimbus- >> JWT/blob/master/src/com/nimbusds/jwt/JWT.java#LC137] >>>=20 >>> 5. Less risk that "none" is implemented as a proper JWS signature >> verification algorithm and accidentally allows unsigned code to pass > security >> gates. >>>=20 >>>=20 >>> -- >>> James Manger >>>=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 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From James.H.Manger@team.telstra.com Sun May 20 17:43: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 A9AA721F8597 for ; Sun, 20 May 2012 17:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.25 X-Spam-Level: X-Spam-Status: No, score=0.25 tagged_above=-999 required=5 tests=[AWL=1.151, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQM4z-etRnrb for ; Sun, 20 May 2012 17:43:18 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 6700C21F8594 for ; Sun, 20 May 2012 17:43:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,627,1330866000"; d="scan'208";a="76626358" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 21 May 2012 10:43:17 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6717"; a="63847151" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcdvi.tcif.telstra.com.au with ESMTP; 21 May 2012 10:43:16 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Mon, 21 May 2012 10:43:16 +1000 From: "Manger, James H" To: Mike Jones , "Richard L. Barnes" , Jim Schaad Date: Mon, 21 May 2012 10:43:15 +1000 Thread-Topic: [jose] Distinguishing signed, encrypted, and unprotected tokens Thread-Index: Ac0z6YIAkxSNdpPpSJGGHmreRKfuNABAjGsAAFxLuoAAF+hbAAAAY/yAAAbafnAAAdL98A== Message-ID: <255B9BB34FB7D647A506DC292726F6E114F2F2EC9E@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E114F2E1C05D@WSMSG3153V.srv.dir.telstra.com> <44153647-17FA-4B02-B528-60456E1E4751@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E114F2F2E7DF@WSMSG3153V.srv.dir.telstra.com> <021601cd36bc$86606bf0$932143d0$@augustcellars.com> <4E1F6AAD24975D4BA5B168042967394366510478@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366510478@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'John Bradley' , "jose@ietf.org" Subject: Re: [jose] Distinguishing signed, encrypted, and unprotected tokens 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, 21 May 2012 00:43:19 -0000 I suggested: >>> * 3 dots (4 segments) =3D> JWE >>> * 2 dots (3 segments) =3D> JWS >>> * 1 dot (2 segments) =3D> unprotected payload (
.) Jim wrote: >> What happens if you are distinguishing based on the number of dots and=20 >> then you move to a new encoding format that is not dot separated? Hang on Jim, of course interop fails if you change syntax. Mike said: > Indeed, we already have a JSON format proposed in response working > group input with no dots. See these specs: > http://tools.ietf.org/html/draft-jones-json-web-signature-json-serializat= ion-01 > http://tools.ietf.org/html/draft-jones-json-web-encryption-json-serializa= tion-01 Neither of these 2 specs talk about having a field that can be a JWE-JS, or= a JWS-JS, or an (undefined) Plain-JS and having to distinguish them -- whi= ch is the *-JS equivalent to the dot-separated-B64 issue we are discussing. The *-JS alternatives are illustrative. JWS-JS: {"headers":[

,

...], "payload":

, "signatures":[,.= ..]} JWE-JS: {"headers":[

,

...], "encrypted_keys":[,...], "ciphertext":, "integrity_values":[,...]} The *-JS syntaxes have an *array of headers*. Are you supposed to use the "= alg" value from the first header, the last header, check all headers? Or lo= ok for an "enc" header field in the first, last, or every header? I hope th= ey are not inconsistent. A better alternative would be to leave the headers alone and look for an "e= ncrypted_keys" field. Another alternative could be changing the "headers" l= abel to "jws" or "jwe" or "header" (when unprotected). If you want to send an unprotected payload in *-JS syntax, can you omit the= "integrity_values" field, or send an empty array, or send an array with 1 = value that is an empty string? The first option sounds best, but the last o= ption is the equivalent of the "alg":"none"-fake-signature method in JWT. I really think we need -- in the JOSE specs -- to defined the packaging of = signed, encrypted, or unprotected content in a way that is trivial to disti= nguish these 3 modes. If we have another packaging syntax (eg *-JS) it also= needs to support these 3 modes and make them trivial to distinguish. This has nothing to do with a JSON object carrying a bunch of claims (for w= hich the OAuth group might be more appropriate). -- James Manger From James.H.Manger@team.telstra.com Sun May 20 19:11:56 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40A321F8474 for ; Sun, 20 May 2012 19:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.166 X-Spam-Level: X-Spam-Status: No, score=0.166 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_33=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBeHgrlGKBx0 for ; Sun, 20 May 2012 19:11:56 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 202CB21F854A for ; Sun, 20 May 2012 19:11:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,628,1330866000"; d="scan'208";a="73806484" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 21 May 2012 12:11:54 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6717"; a="12318702" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcani.tcif.telstra.com.au with ESMTP; 21 May 2012 12:11:54 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Mon, 21 May 2012 12:11:53 +1000 From: "Manger, James H" To: "jose@ietf.org" Date: Mon, 21 May 2012 12:11:52 +1000 Thread-Topic: JWK: comments on jku, kid, use, mod.. Thread-Index: Ac029xZIpX7/XO9DQSuLMbrimkwPkw== Message-ID: <255B9BB34FB7D647A506DC292726F6E114F2F2EF77@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [jose] JWK: comments on jku, kid, use, mod.. X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 02:11:57 -0000 A "jku" value is a URL pointing to a 1 or more JSON Web Keys. A "kid" value= (key id) is really needed to pick the right key from the set. Consequently= the spec should say [in JWS section 4.1.2 "jku" (JWK Set URL) Header Param= eter]: Producers MUST include a "kid" parameter when including a "jku" paramet= er. "jku" makes sense for a JWS -- the receiver uses the "jku" URL to get the p= ublic key to verify the JWS signature. I'm not sure it makes sense in a JWE= , though. The receiver needs a private key to decrypt, not the public key t= hat "jku" points to. At best, "jku" in a JWE acts as an key id -- but we ha= ve a separate "kid" field. I think we should drop the "jku" parameter from = the JWE spec. The "use" (key use) parameter [JWK 4.2] should be a JSON array of strings, = not a single string. It is nice crypto hygiene to have only 1 use for a key= . However, multiple uses are common in practise and are not so atrocious th= at we should forbid it at a syntax level. Particularly given that "other va= lues [than "sig" and "enc"] MAY be used". I would add the word "unsigned" when defining the "mod" and "exp" fields fo= r an RSA key[JWA sections 5.3.1 and 5.3.2] to explicitly avoid confusion gi= ven that other specs use signed representations (eg 2's complement) for the= se keys: It is represented as the base64url encoding of the value's *unsigned* big endian representation. I am not sure if adding "unsigned" would clarify the definitions of "x" and= "y" for elliptic curve keys since they are not always integers (depends on= the type of curve). -- James Manger From vladimir@nimbusds.com Mon May 21 02:38: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 091F021F8622 for ; Mon, 21 May 2012 02:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUVDZWwSKAoy for ; Mon, 21 May 2012 02:38:39 -0700 (PDT) Received: from n1plwbeout07-01.prod.ams1.secureserver.net (n1plsmtp07-01-02.prod.ams1.secureserver.net [188.121.52.106]) by ietfa.amsl.com (Postfix) with SMTP id F3E0F21F8623 for ; Mon, 21 May 2012 02:38:38 -0700 (PDT) Received: (qmail 9362 invoked from network); 21 May 2012 09:38:32 -0000 Received: from unknown (HELO localhost) (188.121.52.246) by n1plwbeout07-01.prod.ams1.secureserver.net with SMTP; 21 May 2012 09:38:32 -0000 Received: (qmail 25357 invoked by uid 99); 21 May 2012 09:38:32 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 79.100.184.220 User-Agent: Workspace Webmail 5.6.17 Message-Id: <20120521023831.cc40c4f3d92d2001859047cd8cabb9ab.433456133a.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: jose@ietf.org Date: Mon, 21 May 2012 02:38:31 -0700 Mime-Version: 1.0 Subject: [jose] Pleased with new -02 spec structure 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, 21 May 2012 09:38:40 -0000 I just went through the new -02 specs in order to update our Java JWT=0Alib= rary and have to say I'm very pleased with the new spec structure=0Awhere t= he algorithms have been moved entirely to the JWA doc. The whole=0Aspec sui= te reads easier now.=0A=0AThe new JWK terms are also a much better match!= =0A=0AThanks to everyone who worked on that!=0A=0AVladimir=0A=0A--=0AVladim= ir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com=0A From ietf@augustcellars.com Mon May 21 15:47: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 2D58221F85A5 for ; Mon, 21 May 2012 15:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbSAUlOXgirY for ; Mon, 21 May 2012 15:47:21 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 5294E21F859F for ; Mon, 21 May 2012 15:47:21 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id B736E38F04; Mon, 21 May 2012 15:47:20 -0700 (PDT) From: "Jim Schaad" To: "Mike Jones" Date: Mon, 21 May 2012 15:46:05 -0700 Message-ID: <026d01cd37a3$8215dc00$86419400$@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: Ac02D5hCCAHMzxPmQDC/RwzlQzAQzw== Content-Language: en-us Cc: jose@ietf.org Subject: [jose] Comments on draft-ietf-jose-json-web-algorithms-02 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 22:47:22 -0000 Here are comments this document Abstract 1. Since I called it out for JWK I will make the comment that I do not have a problem with enumerate in this document. Section 1 1. Just a comment - I am not sure why you feel the name to create a specific acronym for this document but it does not really matter. 2. Need to expand JSON if you are going to use it. 3. New paragraph for sentence starting with "Enumerating..." Separate justification from what this document does and hash. 4. Move last sentence to the end of the first paragraph Section 2 1. In general I would like to see this duplicated into this document. Readers should not have to reference another document for this purpose. Section 3.1 1. I am not overly happy with the existence of a "none" algorithm. Does it really need to exist? Section 3.2 1. You may want to reference RFC4231 as well. It contains test vectors and such for the SHA2 HMACs 2. HMAC SHA-256 is a MAC function not a hash function (para #2) 3. I have not yet read the updated JWS document, but I do worry about the fact that this document is saying that the output should be base64url encoded. If the JWS document says the same thing injudiciously then one could easily see that people might double encode the result. 4. I have a real problem with people saying that UTF-8 and ASCII are the same. They aren't and saying that they are does not make it so. 5. I find it confusing to constantly refer to the JWS specification throughout this text. For one thing it makes it harder to refer to these documents for other uses in JSON of these algorithms (such as for an encrypt and MAC algorithm). Section 3.3 1. I am not sure why there is a reference to both RFC 3447 and FIPS 186-3. RSA v1.5 is fully defined and described in 3447. 2. I would move the justification of PKCS v1.5 to security considerations and not put it here. Section 3.4 1. I am not sure that the statement on key sizes makes any sense given that a key size is implied by the group being used. 2. Given that we are using JSON as the basic structure - why not use a JSON structure rather than concatenate - just the question of size? 3. If you are doing a guide for idiots - then you need to give the array sizes for R and S for each of the algorithms 4. I have never see the R,S pair be referred to as a point before. I believe it is just an ordered pair of integers and not a point on the field. 5. The following sentence puzzles me "The ECDSA validator will then determine if the digital signature is valid, given the inputs." This sentence is just after the steps of how to do validation so saying it will then be validated does not make sense to me. Section 3.5 1. I would put the justification for plaintext JWS in JWS not here. In fact I would almost prefer a version of JWS that omitted the alg parameter to say that it has no security than what is done here. I think this entire section should be moved into JWS. Section 3.6 1. I don't see the purpose of the last paragraph in this section. It has nothing to do with algorithms. Section 4.5 1. RSA-OAEP is under specified. There are a number of parameters for OAEP that must be defined to go with it. These include the mask function and a hash function. Look at RFC 3447 for the details. Section 4.6 1. I would rephrase the last paragraph as being you must re-generate a new EPK for each key agreement done rather than saying that you cannot reuse them. The way specified might say that you can never re-use them rather than you should only rarely re-use them and in an unpredictable manner. 2. I strongly disagree with setting OtherInfo parameters to be empty. We need to define and fill in the AlgorithmId at a minimum. Note that this can be an implicit computation and does not need to be carried as extra data. At a minimum I would suggest something along the lines of JOSE-### where ### is the number of bits to get generated. 3. Same comment as above about key sizes - key sizes are specified by the curve being used. Section 4.8 1. Use of an IV is REQUIRED not RECOMMENDED Section 4.9 1. Specification of the data to be processed needs to be in JWE not in this document. It should just specify that there are the following inputs: Additional data and data to be encrypted. Interesting question of is this where the key is generated or not - I would ignore that issue. Section 4.10 1. Is this section needed? It is a duplicate of the same data in section 3.2 (or it should be) Section 4.11 1. for last paragraph see comment on 3.6 Section 6.1 1. I would move this registry to either the signature or encryption documents and not put it here. What does this document populate it with? Section 6.2 1. Make life easy for IANA and me - create a table of the values 2. Can an algorithm have more than one usage? Section 6.3 1. This registry should be in either the encryption or signature draft Section 6.4 1. This registry should be in the JWK document Section 6.5 1. Make life easy for IANA and me - create a table of the values From ietf@augustcellars.com Mon May 21 15:57: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 44F2521F85DB for ; Mon, 21 May 2012 15:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eojsFs0u3QYa for ; Mon, 21 May 2012 15:57:14 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id D498F21F858F for ; Mon, 21 May 2012 15:57:14 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 9EB482CA1C for ; Mon, 21 May 2012 15:57:14 -0700 (PDT) From: "Jim Schaad" To: Date: Mon, 21 May 2012 15:55:59 -0700 Message-ID: <026e01cd37a4$e406d670$ac148350$@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: Ac03pF2514K1eFkfQHa3/Uzt2hZsGw== Content-Language: en-us Subject: [jose] Disscussion Issue - Algorithm Parameters 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, 21 May 2012 22:57:15 -0000 An issue I would like to see some discussion on Should an algorithm be able to specific parameters rather than making them part of the algorithm name string? If so should we change the way that we are doing parameters to allow for this better? As an example of this, the RSA-OAEP algorithm needs to specify two parameters: The mask function and a hash function. We can say that these are to be encoded in the name of the algorithm (i.e. RSA-OAEP-mf1-sha256) or we can change the alg parameter to allow for the following: Either a string specifying the name of the algorithm (with defaults values in some cases) (i.e. alg: "RSA-OAEP-mf2-sha256") OR A JSON structure with the name of the algorithm and the parameters alg: { name:"RSA-OAEP", hash: "SHA-256", mgf: "mgf1" } jim From James.H.Manger@team.telstra.com Mon May 21 18:31: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 EF9F421F85DF for ; Mon, 21 May 2012 18:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.251 X-Spam-Level: X-Spam-Status: No, score=-0.251 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARsjguuxKu8v for ; Mon, 21 May 2012 18:31:49 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 23C4B21F85A1 for ; Mon, 21 May 2012 18:31:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,635,1330866000"; d="scan'208";a="73772232" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 22 May 2012 11:31:46 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6718"; a="12593212" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcani.tcif.telstra.com.au with ESMTP; 22 May 2012 11:31:45 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Tue, 22 May 2012 11:31:45 +1000 From: "Manger, James H" To: "jose@ietf.org" Date: Tue, 22 May 2012 11:31:43 +1000 Thread-Topic: [jose] Comments on draft-ietf-jose-json-web-algorithms-02 Thread-Index: Ac02D5hCCAHMzxPmQDC/RwzlQzAQzwBonveQ Message-ID: <255B9BB34FB7D647A506DC292726F6E114F2FE718A@WSMSG3153V.srv.dir.telstra.com> References: <026d01cd37a3$8215dc00$86419400$@augustcellars.com> In-Reply-To: <026d01cd37a3$8215dc00$86419400$@augustcellars.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 01:31:50 -0000 > Section 3.1 > > 1. I am not overly happy with the existence of a "none" algorithm. Does= it > really need to exist? +1 for removing "none" > Section 3.2 > 3. I have not yet read the updated JWS document, but I do worry about th= e > fact that this document is saying that the output should be base64url > encoded. If the JWS document says the same thing injudiciously then one > could easily see that people might double encode the result. The algorithms spec should map a string, eg "HS512", to the "standard model= " for that type of algorithm. The standard model for a MAC, for example, ha= s two inputs (key and data) and one output (mac), all of which are byte arr= ays. A better structure for the algorithms spec would be 8 sections for the 8 ty= pes of algorithm: asymmetric signature, MAC, asymmetric key encryption, sym= metric key wrapping, asymmetric key agreement, symmetric encryption, AEAD, = public key. Each section would describing the model for that type of algori= thm: inputs and outputs, and their types (generally byte arrays). A sub-sec= tion for each specific name would reference the algorithm's external specif= ication and add any restrictions on options or lengths. Leave it to JWE/JWS/JWT to take care of how to package it all together (eg = to support asymmetric key encryption or symmetric key wrapping or key agree= ment in a JSON structure; what to base64url encode...). > Section 4.9 [A128GCM, A256GCM] NIST 800-38D says the authentication tag for A128GCM or A256GCM can be 128,= 120, 112, 104, or 96 bits long (or 64 or 32 bits for certain applications)= -- regardless of the key size. It cannot be 256 bits. I suspect we should = just pick 128 bits. REPLACE The requested size of the "authentication tag" output MUST be the same as the key size (for instance, 128 bits for "A128GCM"). WITH The "authentication tag" MUST be 16 bytes (128 bits), regardless of the key size. > Section 6.2 [algorithm registry] > > 2. Can an algorithm have more than one usage? Each algorithm name should be assigned to 1 of the 8 algorithm type, not ju= st "alg", "enc", or "int". The JWE spec, for instance, can say its 'alg' field can hold names from the= 3 types (asymmetric key encryption, symmetric key wrap, asymmetric key agr= eement) etc. -- James Manger From James.H.Manger@team.telstra.com Mon May 21 20:25: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 0E18D21F851A for ; Mon, 21 May 2012 20:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.381 X-Spam-Level: X-Spam-Status: No, score=-0.381 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqfeE6jkVDms for ; Mon, 21 May 2012 20:25:30 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 34AD021F84FC for ; Mon, 21 May 2012 20:25:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,636,1330866000"; d="scan'208";a="79791402" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipoani.tcif.telstra.com.au with ESMTP; 22 May 2012 13:25:28 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6718"; a="12609770" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipcani.tcif.telstra.com.au with ESMTP; 22 May 2012 13:25:28 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Tue, 22 May 2012 13:25:28 +1000 From: "Manger, James H" To: Jim Schaad , "jose@ietf.org" Date: Tue, 22 May 2012 13:25:26 +1000 Thread-Topic: [jose] Disscussion Issue - Algorithm Parameters Thread-Index: Ac03pF2514K1eFkfQHa3/Uzt2hZsGwAFxX3Q Message-ID: <255B9BB34FB7D647A506DC292726F6E114F2FE746C@WSMSG3153V.srv.dir.telstra.com> References: <026e01cd37a4$e406d670$ac148350$@augustcellars.com> In-Reply-To: <026e01cd37a4$e406d670$ac148350$@augustcellars.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [jose] Disscussion Issue - Algorithm Parameters 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, 22 May 2012 03:25:31 -0000 X-List-Received-Date: Tue, 22 May 2012 03:25:31 -0000 > Should an algorithm be able to specific parameters rather than making the= m > part of the algorithm name string? If so should we change the way that w= e > are doing parameters to allow for this better? > alg: "RSA-OAEP-mf2-sha256" > OR > alg: { name:"RSA-OAEP", hash: "SHA-256", mgf: "mgf1" } Another option is: "alg": "RSA-OAEP" "mgf": "MGF1" "hash": "SHA-256" I suspect additional parameters in the header (like "mgf" and "hash" above)= was the intention. This is why the algorithms spec (in sections 3.6 and 4.= 11 for signature and encryption algorithms) says: "additional reserved head= er parameter names MAY be defined". The result is a flat structure for all sorts of parameters: about the paylo= ad ("typ"); about JWE processing ("enc", "int"); about a specific algorithm= ("mgf", "hash") etc. A flat structure will cause headaches at some point (cf trying to separate = transport and content details from HTTP's flat header structure), but it is= simpler to start with. I suggest we stick with a flat structure for JOSE. > As an example of this, the RSA-OAEP algorithm needs to specify two > parameters: The mask function and a hash function. For RSA-OAEP specifically, I suggest: * picking one hash algorithm (SHA-256) and including it in the name "RSA-OA= EP256" * hardwiring the mask-generation function (to be MGF1 with the same hash al= gorithm) (so no "mgf" parameter is needed) * hardwiring the label to be empty. The resulting spec text could be: =3D=3D=3D=3D=3D 4.5 "RSA-OAEP256" The "RSA-OAEP256" key encryption algorithm is RSA encryption with Optimal Asymmetric Encryption Padding (OAEP) using SHA-256. The algorithm is specified in PKCS#1 [RFC 3447], where it is called RSAES-OAEP-ENCRYPT. The hash function is SHA-256 [FIPS 180-4]. The mask generation function is MGF1 [RFC 3447], using SHA-256 as the hash function. The label is the empty string. =3D=3D=3D=3D=3D -- James Manger From ietf@augustcellars.com Mon May 21 20:56: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 5379221F8552 for ; Mon, 21 May 2012 20:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQEFwU3ZsZZS for ; Mon, 21 May 2012 20:56:11 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id CA1D121F854F for ; Mon, 21 May 2012 20:56:11 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 8BDF738EF1; Mon, 21 May 2012 20:56:10 -0700 (PDT) From: "Jim Schaad" To: "'Manger, James H'" , References: <026e01cd37a4$e406d670$ac148350$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F2FE746C@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F2FE746C@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 21 May 2012 20:54:51 -0700 Message-ID: <028001cd37ce$a6eaaa80$f4bfff80$@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: AQJTMkX84NM/XCcjp4/V7EN5qPKLUQJ+iFxzlbVDjeA= Content-Language: en-us Subject: Re: [jose] Disscussion Issue - Algorithm Parameters 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, 22 May 2012 03:56:12 -0000 > -----Original Message----- > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > Sent: Monday, May 21, 2012 8:25 PM > To: Jim Schaad; jose@ietf.org > Subject: RE: [jose] Disscussion Issue - Algorithm Parameters > > > Should an algorithm be able to specific parameters rather than making > > them part of the algorithm name string? If so should we change the > > way that we are doing parameters to allow for this better? > > > alg: "RSA-OAEP-mf2-sha256" > > OR > > alg: { name:"RSA-OAEP", hash: "SHA-256", mgf: "mgf1" } > > > Another option is: > "alg": "RSA-OAEP" > "mgf": "MGF1" > "hash": "SHA-256" That is an option that is doable as well. I happen to think that it might lead to problems down the road. If you have two algorithms in the header, then one must make sure that there is no possibility that the two algorithms will want to use the same field. Given that anybody can define a new algorithm, it is not possible to do an exhaustive search for collisions in the use of field names. It might be better to have them scoped already. > > I suspect additional parameters in the header (like "mgf" and "hash" above) > was the intention. This is why the algorithms spec (in sections 3.6 and 4.11 for > signature and encryption algorithms) says: "additional reserved header > parameter names MAY be defined". > The result is a flat structure for all sorts of parameters: about the payload > ("typ"); about JWE processing ("enc", "int"); about a specific algorithm > ("mgf", "hash") etc. > A flat structure will cause headaches at some point (cf trying to separate > transport and content details from HTTP's flat header structure), but it is > simpler to start with. > I suggest we stick with a flat structure for JOSE. > > > > > As an example of this, the RSA-OAEP algorithm needs to specify two > > parameters: The mask function and a hash function. > > For RSA-OAEP specifically, I suggest: > * picking one hash algorithm (SHA-256) and including it in the name "RSA- > OAEP256" > * hardwiring the mask-generation function (to be MGF1 with the same hash > algorithm) (so no "mgf" parameter is needed) > * hardwiring the label to be empty. > > The resulting spec text could be: > ===== > 4.5 "RSA-OAEP256" > > The "RSA-OAEP256" key encryption algorithm is RSA encryption with > Optimal Asymmetric Encryption Padding (OAEP) using SHA-256. > The algorithm is specified in PKCS#1 [RFC 3447], where it is > called RSAES-OAEP-ENCRYPT. > > The hash function is SHA-256 [FIPS 180-4]. > > The mask generation function is MGF1 [RFC 3447], using SHA-256 as > the hash function. > > The label is the empty string. > ===== > > -- > James Manger From Michael.Jones@microsoft.com Mon May 21 22:50:01 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB8021F846C for ; Mon, 21 May 2012 22:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InrCFmmHY4oa for ; Mon, 21 May 2012 22:49:57 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3AC21F8499 for ; Mon, 21 May 2012 22:49:56 -0700 (PDT) Received: from mail36-am1-R.bigfish.com (10.3.201.243) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Tue, 22 May 2012 05:49:41 +0000 Received: from mail36-am1 (localhost [127.0.0.1]) by mail36-am1-R.bigfish.com (Postfix) with ESMTP id 6575B480226; Tue, 22 May 2012 05:49:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -36 X-BigFish: VS-36(zz9371I1503Mc85fh542M1432Nzz1202hzz1033IL8275eh8275bh8275dha1495iz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail36-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail36-am1 (localhost.localdomain [127.0.0.1]) by mail36-am1 (MessageSwitch) id 1337665779242748_3587; Tue, 22 May 2012 05:49:39 +0000 (UTC) Received: from AM1EHSMHS012.bigfish.com (unknown [10.3.201.250]) by mail36-am1.bigfish.com (Postfix) with ESMTP id 2F946200048; Tue, 22 May 2012 05:49:39 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS012.bigfish.com (10.3.207.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 22 May 2012 05:49:38 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0298.005; Tue, 22 May 2012 05:49:49 +0000 From: Mike Jones To: Jim Schaad , "'Manger, James H'" , "jose@ietf.org" Thread-Topic: [jose] Disscussion Issue - Algorithm Parameters Thread-Index: Ac03pF2514K1eFkfQHa3/Uzt2hZsGwAFxX3QAATL9oAAAIcqMA== Date: Tue, 22 May 2012 05:49:48 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436651227A@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <026e01cd37a4$e406d670$ac148350$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F2FE746C@WSMSG3153V.srv.dir.telstra.com> <028001cd37ce$a6eaaa80$f4bfff80$@augustcellars.com> In-Reply-To: <028001cd37ce$a6eaaa80$f4bfff80$@augustcellars.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_4E1F6AAD24975D4BA5B16804296739436651227ATK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] Disscussion Issue - Algorithm Parameters 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, 22 May 2012 05:50:01 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436651227ATK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As background on the current spec design, both JSMS and the JWS family of s= pecs independently made a conscious design choice to specify a small, limit= ed set of cryptographic algorithms and algorithm combinations to simplify i= mplementations and increase interoperability. Quoting from the introductio= n to JSMS (wit= h my emphasis): Many applications require the ability to send cryptographically secured (encrypted, digitally signed, etc.) messages. While the IETF has defined a number of formats for such messages, those formats are widely viewed as being excessively complicated for the demands of Web applications, which typically only need the ability to secure simple messages. ... This document describes a new cryptographic message format, JavaScript Message Security (JSMS) intended to meet the need of the Web environment. While JSMS is modeled on existing formats -- principally CMS [RFC5652] -- it uses JavaScript Object Notation (JSON) rather than ASN.1/BER/DER, making it far easier for Web applications to handle. In the interest of simplicity, JSMS also omits as many as possible of the CMS modes (multiple signatures, password-based encryption). In parallel, the consensus decisions in the design discussions behind the J= WE design included: "we should specify a small set of composite operations that will meet t= he needs of common use cases" We're trying to make simple things simple to facilitate widespread deployme= nt of strong crypto. The alternative is XML ENC, where all parameters and = parameter combinations *can* be specified but with no guarantees that any p= articular combination, other than a mandatory-to-implement set, will actual= ly be supported or interoperable among any particular implementations. I believe that the designers of both sets of JOSE precursor specs reached t= he conclusion that simple specs with a small set of useful, widely implemen= ted, carefully chosen cryptographic primitives and combinations would be of= more practical value to developers and result in more deployment and inter= operability than a highly general spec that allows for a large combinatoria= l set of parameter combinations. If new parameter combinations are needed in practice, they can easily be sp= ecified in the JWA spec or in the registries that it defines. I hope that understanding this rationale behind the intentionally limited s= ets of algorithms specified in both JSMS and JWA will be useful to the work= ing group. Best wishes, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Monday, May 21, 2012 8:55 PM To: 'Manger, James H'; jose@ietf.org Subject: Re: [jose] Disscussion Issue - Algorithm Parameters > -----Original Message----- > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > Sent: Monday, May 21, 2012 8:25 PM > To: Jim Schaad; jose@ietf.org > Subject: RE: [jose] Disscussion Issue - Algorithm Parameters > > > Should an algorithm be able to specific parameters rather than > > making them part of the algorithm name string? If so should we > > change the way that we are doing parameters to allow for this better? > > > alg: "RSA-OAEP-mf2-sha256" > > OR > > alg: { name:"RSA-OAEP", hash: "SHA-256", mgf: "mgf1" } > > > Another option is: > "alg": "RSA-OAEP" > "mgf": "MGF1" > "hash": "SHA-256" That is an option that is doable as well. I happen to think that it might = lead to problems down the road. If you have two algorithms in the header, = then one must make sure that there is no possibility that the two algorithm= s will want to use the same field. Given that anybody can define a new algorithm, it is not possible to do an = exhaustive search for collisions in the use of field names. It might be be= tter to have them scoped already. > > I suspect additional parameters in the header (like "mgf" and "hash" above) > was the intention. This is why the algorithms spec (in sections 3.6 > and 4.11 for > signature and encryption algorithms) says: "additional reserved header > parameter names MAY be defined". > The result is a flat structure for all sorts of parameters: about the payload > ("typ"); about JWE processing ("enc", "int"); about a specific > algorithm ("mgf", "hash") etc. > A flat structure will cause headaches at some point (cf trying to > separate transport and content details from HTTP's flat header > structure), but it is > simpler to start with. > I suggest we stick with a flat structure for JOSE. > > > > > As an example of this, the RSA-OAEP algorithm needs to specify two > > parameters: The mask function and a hash function. > > For RSA-OAEP specifically, I suggest: > * picking one hash algorithm (SHA-256) and including it in the name > "RSA- OAEP256" > * hardwiring the mask-generation function (to be MGF1 with the same > hash > algorithm) (so no "mgf" parameter is needed) > * hardwiring the label to be empty. > > The resulting spec text could be: > =3D=3D=3D=3D=3D > 4.5 "RSA-OAEP256" > > The "RSA-OAEP256" key encryption algorithm is RSA encryption with > Optimal Asymmetric Encryption Padding (OAEP) using SHA-256. > The algorithm is specified in PKCS#1 [RFC 3447], where it is > called RSAES-OAEP-ENCRYPT. > > The hash function is SHA-256 [FIPS 180-4]. > > The mask generation function is MGF1 [RFC 3447], using SHA-256 as > the hash function. > > The label is the empty string. > =3D=3D=3D=3D=3D > > -- > James Manger _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B16804296739436651227ATK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As background on the current spec design, both JS= MS and the JWS family of specs independently made a conscious design choice= to specify a small, limited set of cryptographic algorithms and algorithm = combinations to simplify implementations and increase interoperability.  Quoting from the introduction to JSMS (with my emphasis):

 

   Many applications require the abilit= y to send cryptographically

   secured (encrypted, digitally signed= , etc.) messages.  While the IETF

   has defined a number of formats for = such messages, those formats are

   widely viewed as being excessivel= y complicated for the demands of Web

   applications, which typically onl= y need the ability to secure simple

   messages.  ...

 

   This document describes a new crypto= graphic message format,

   JavaScript Message Security (JSMS) i= ntended to meet the need of the

   Web environment.  While JSMS is= modeled on existing formats --

   principally CMS [RFC5652] -- it uses= JavaScript Object Notation

   (JSON) rather than ASN.1/BER/DER, ma= king it far easier for Web

   applications to handle.  In = the interest of simplicity, JSMS also

   omits as many as possible of the = CMS modes (multiple signatures,

   password-based encryption).

 

In parallel, the consensus decisions in the design discussions behind the JWE design included:

    “we should specify a small set of composite operations that will me= et the needs of common use cases

 

We’re trying to make simple things simple t= o facilitate widespread deployment of strong crypto.  The alternative = is XML ENC, where all parameters and parameter combinations *can* be= specified but with no guarantees that any particular combination, other than a mandatory-to-implement set, will actually be sup= ported or interoperable among any particular implementations.

 

I believe that the designers of both sets of JOSE= precursor specs reached the conclusion that simple specs with a small set = of useful, widely implemented, carefully chosen cryptographic primitives an= d combinations would be of more practical value to developers and result in more deployment and interoperability tha= n a highly general spec that allows for a large combinatorial set of parame= ter combinations.

 

If new parameter combinations are needed in pract= ice, they can easily be specified in the JWA spec or in the registries that= it defines.

 

I hope that understanding this rationale behind t= he intentionally limited sets of algorithms specified in both JSMS and JWA = will be useful to the working group.

 

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

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

 

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad
Sent: Monday, May 21, 2012 8:55 PM
To: 'Manger, James H'; jose@ietf.org
Subject: Re: [jose] Disscussion Issue - Algorithm Parameters

 

 

 

> -----Original Message-----

> From: Manger, James H [mailto:James.H.Mange= r@team.telstra.com]

> Sent: Monday, May 21, 2012 8:25 PM

> To: Jim Schaad; jose@ietf.org

> Subject: RE: [jose] Disscussion Issue - Algo= rithm Parameters

>

> > Should an algorithm be able to specific= parameters rather than

> > making them part of the algorithm name = string?  If so should we

> > change the way that we are doing parame= ters to allow for this better?

>

> > alg: "RSA-OAEP-mf2-sha256"

> > OR

> > alg: { name:"RSA-OAEP", hash:= "SHA-256", mgf: "mgf1" }

>

>

> Another option is:

>   "alg": "RSA-OAEP&= quot;

>   "mgf": "MGF1"= ;

>   "hash": "SHA-256&= quot;

 

That is an option that is doable as well.  I= happen to think that it might lead to problems down the road.  If you= have two algorithms in the header, then one must make sure that there is n= o possibility that the two algorithms will want to use the same field. 

 

Given that anybody can define a new algorithm, it= is not possible to do an exhaustive search for collisions in the use of fi= eld names.  It might be better to have them scoped already.=

 

 

>

> I suspect additional parameters in the heade= r (like "mgf" and "hash"

above)

> was the intention. This is why the algorithm= s spec (in sections 3.6

> and

4.11 for

> signature and encryption algorithms) says: &= quot;additional reserved header

> parameter names MAY be defined".

> The result is a flat structure for all sorts= of parameters: about the

payload

> ("typ"); about JWE processing (&qu= ot;enc", "int"); about a specific

> algorithm ("mgf", "hash"= ) etc.

> A flat structure will cause headaches at som= e point (cf trying to

> separate transport and content details from = HTTP's flat header

> structure), but it

is

> simpler to start with.

> I suggest we stick with a flat structure for= JOSE.

>

>

>

> > As an example of this, the RSA-OAEP alg= orithm needs to specify two

> > parameters:  The mask function and= a hash function.

>

> For RSA-OAEP specifically, I suggest:

> * picking one hash algorithm (SHA-256) and i= ncluding it in the name

> "RSA- OAEP256"

> * hardwiring the mask-generation function (t= o be MGF1 with the same

> hash

> algorithm) (so no "mgf" parameter = is needed)

> * hardwiring the label to be empty.

>

> The resulting spec text could be:=

> =3D=3D=3D=3D=3D

> 4.5 "RSA-OAEP256"

>

>   The "RSA-OAEP256" key = encryption algorithm is RSA encryption with

>   Optimal Asymmetric Encryption Pa= dding (OAEP) using SHA-256.

>   The algorithm is specified in PK= CS#1 [RFC 3447], where it is

>   called RSAES-OAEP-ENCRYPT.<= /o:p>

>

>   The hash function is SHA-256 [FI= PS 180-4].

>

>   The mask generation function is = MGF1 [RFC 3447], using SHA-256 as

>   the hash function.

>

>   The label is the empty string.

> =3D=3D=3D=3D=3D

>

> --

> James Manger

 

_______________________________________________

jose mailing list

jose@ietf.org

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

 

--_000_4E1F6AAD24975D4BA5B16804296739436651227ATK5EX14MBXC284r_-- From James.H.Manger@team.telstra.com Mon May 21 23:21:46 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804939E8016 for ; Mon, 21 May 2012 23:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gu0uok5mvU6A for ; Mon, 21 May 2012 23:21:46 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id B82DA9E800A for ; Mon, 21 May 2012 23:21:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,637,1330866000"; d="scan'208";a="79825067" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipoani.tcif.telstra.com.au with ESMTP; 22 May 2012 16:21:42 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6718"; a="64885219" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipccni.tcif.telstra.com.au with ESMTP; 22 May 2012 16:21:43 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Tue, 22 May 2012 16:21:42 +1000 From: "Manger, James H" To: Jim Schaad , "jose@ietf.org" Date: Tue, 22 May 2012 16:21:40 +1000 Thread-Topic: [jose] Disscussion Issue - Algorithm Parameters Thread-Index: AQJTMkX84NM/XCcjp4/V7EN5qPKLUQJ+iFxzlbVDjeCAAAr2kA== Message-ID: <255B9BB34FB7D647A506DC292726F6E114F2FE7908@WSMSG3153V.srv.dir.telstra.com> References: <026e01cd37a4$e406d670$ac148350$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F2FE746C@WSMSG3153V.srv.dir.telstra.com> <028001cd37ce$a6eaaa80$f4bfff80$@augustcellars.com> In-Reply-To: <028001cd37ce$a6eaaa80$f4bfff80$@augustcellars.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [jose] Disscussion Issue - Algorithm Parameters 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, 22 May 2012 06:21:46 -0000 >> Another option is: >> "alg": "RSA-OAEP" >> "mgf": "MGF1" >> "hash": "SHA-256" > That is an option that is doable as well. I happen to think that it migh= t > lead to problems down the road. If you have two algorithms in the header= , > then one must make sure that there is no possibility that the two algorit= hms > will want to use the same field. =20 > > Given that anybody can define a new algorithm, it is not possible to do a= n > exhaustive search for collisions in the use of field names. It might be > better to have them scoped already. That's what we have a registry for: "JSON Web Signature and Encryption Head= er Parameters Registry". If you encrypt a session key with RSA-OAEP and use HMAC for integrity, you = can theoretically use 3 different hash algorithms (in OAEP, in mask generat= ion, in HMAC). Hence, defining one "hash" header parameter would not be suf= ficient. In practice I doubt this will be a problem (in this case requiring= the 3 hash algorithms be consistent is likely to be a good restriction). The problem I see down the road is when some software wants to, for instanc= e, pass just the parameters relating directly to the plaintext onto another= module. Today, it would keep "typ" and remove "alg", "int", "jku", "kid", = "jwk", "x5u", and "x5t". Tomorrow, the task gets increasingly awkward since= new public and private parameters start appearing and software cannot auto= matically tell if they are related to the plaintext or to something else. I am still willing to support a flat structure, however, for its simplicity= . -- James Manger From Axel.Nennker@telekom.de Tue May 22 00:32: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 E5AE021F84D9 for ; Tue, 22 May 2012 00:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fb0RVTdXm06m for ; Tue, 22 May 2012 00:32:52 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8905121F84DE for ; Tue, 22 May 2012 00:32:45 -0700 (PDT) Received: from he113414.emea1.cds.t-internal.com ([10.125.65.80]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 22 May 2012 09:32:40 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.88]) by HE113414.emea1.cds.t-internal.com ([2002:7cd:4150::7cd:4150]) with mapi; Tue, 22 May 2012 09:32:39 +0200 From: To: , Date: Tue, 22 May 2012 09:32:39 +0200 Thread-Topic: [jose] Disscussion Issue - Algorithm Parameters Thread-Index: Ac03pF2514K1eFkfQHa3/Uzt2hZsGwARPfPw Message-ID: References: <026e01cd37a4$e406d670$ac148350$@augustcellars.com> In-Reply-To: <026e01cd37a4$e406d670$ac148350$@augustcellars.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] Disscussion Issue - Algorithm Parameters 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, 22 May 2012 07:32:55 -0000 I agree with the fact that all described algorithms must be fully described= to eliminate ambiguity.=20 But we have to find a balance between long and complicated and short and si= mple. With regard to RSA-OAEP I suggest to keep the name "RSA-OAEP" and describe = the default parameters in the text or table-cell. If an implementer chooses other parameters than the default then they could= use your suggested format. alg: { name:"RSA-OAEP", hash: "PSI-384", mgf: "= mgfX" } Which then leads to the requirement that servers MUST reject the whole thin= g if one of the parameters is not supported. Things are getting complicated. It is best to stay with the defaults (fully= describe them in the text but keep the name) and leave other parameters t= han default ones to extensions.=20 I have implemented an early version of the JW? Specs in Java https://code.google.com/p/openinfocard/source/browse/trunk/src/org/xmldap/j= son/WebToken.java which uses Bouncycastle http://bouncycastle.org/docs/docs1.5on/org/bouncycastle/asn1/pkcs/RSAESOAEP= params.html which use sha1 and mgf1SHA1 as default. These same defaults are specified in Table5 of http://self-issued.info/docs= /draft-jones-json-web-encryption.html "RSA using Optimal Asymmetric Encryption Padding (OAEP) RSA-OAEP http://w= ww.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p RSA/ECB/OAEPWithSHA-1AndMGF1Paddin= g" So everything in this spec (related to RSA_OAEP) looks fully specified to m= e.=20 I see no reason to make things more complicated. -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Tuesday, May 22, 2012 12:56 AM To: jose@ietf.org Subject: [jose] Disscussion Issue - Algorithm Parameters An issue I would like to see some discussion on=20 Should an algorithm be able to specific parameters rather than making them = part of the algorithm name string? If so should we change the way that we = are doing parameters to allow for this better? As an example of this, the RSA-OAEP algorithm needs to specify two parameters: The mask function and a hash function. We can say that these = are to be encoded in the name of the algorithm (i.e. RSA-OAEP-mf1-sha256) o= r we can change the alg parameter to allow for the following: Either a string specifying the name of the algorithm (with defaults values = in some cases) (i.e. alg: "RSA-OAEP-mf2-sha256") OR A JSON structure with the name of the algorithm and the parameters alg: { name:"RSA-OAEP", hash: "SHA-256", mgf: "mgf1" } jim _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From vladimir@nimbusds.com Tue May 22 01:00: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 4C1ED21F8497 for ; Tue, 22 May 2012 01:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vch16KO93XfL for ; Tue, 22 May 2012 01:00:04 -0700 (PDT) Received: from n1plwbeout07-02.prod.ams1.secureserver.net (n1plsmtp07-02-02.prod.ams1.secureserver.net [188.121.52.107]) by ietfa.amsl.com (Postfix) with SMTP id 5E76921F8459 for ; Tue, 22 May 2012 01:00:04 -0700 (PDT) Received: (qmail 25993 invoked from network); 22 May 2012 07:53:17 -0000 Received: from unknown (HELO localhost) (188.121.52.246) by n1plwbeout07-02.prod.ams1.secureserver.net with SMTP; 22 May 2012 07:53:17 -0000 Received: (qmail 10416 invoked by uid 99); 22 May 2012 07:53:10 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 79.100.190.175 User-Agent: Workspace Webmail 5.6.17 Message-Id: <20120522005309.cc40c4f3d92d2001859047cd8cabb9ab.67beb32ca3.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: jose@ietf.org Date: Tue, 22 May 2012 00:53:09 -0700 Mime-Version: 1.0 Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 08:00:05 -0000 =0A>> Section 3.1=0A>>=0A>> 1. I am not overly happy with the existence of = a "none" algorithm. Does it=0A>> really need to exist?=0A> =0A> +1 for remo= ving "none"=0A=0A+1 for deprecating none.=0A=0AThe same information can be = expressed by simply omitting "alg". This=0Amakes plain JWTs nimbler too. I = see no problem with having empty headers=0Afor plain JWTs.=0A=0AAlso, by re= moving "none", "alg" would become consistent with the rest of=0Athe paramet= ers which don't have "none" values (we don't have=0A"enc":"none", etc.). Ve= ry much like the recent change to "zip" (JWS,=0Asection 4.1.6) which no lon= ger has the (optional) "none": it's either=0A"zip":"DEF" or nothing.=0A=0AV= ladimir=0A--=0AVladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.co= m=0A From gffletch@aol.com Tue May 22 08:37: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 A600C21F85FD for ; Tue, 22 May 2012 08:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.206, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJ7nQQRxct8J for ; Tue, 22 May 2012 08:37:30 -0700 (PDT) Received: from imr-da04.mx.aol.com (imr-da04.mx.aol.com [205.188.105.146]) by ietfa.amsl.com (Postfix) with ESMTP id D211A21F85FC for ; Tue, 22 May 2012 08:37:29 -0700 (PDT) Received: from mtaout-da03.r1000.mx.aol.com (mtaout-da03.r1000.mx.aol.com [172.29.51.131]) by imr-da04.mx.aol.com (8.14.1/8.14.1) with ESMTP id q4MFalgM024605; Tue, 22 May 2012 11:36:47 -0400 Received: from palantir.office.aol.com (palantir.office.aol.com [10.181.186.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-da03.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 5F3C0E00010A; Tue, 22 May 2012 11:36:47 -0400 (EDT) Message-ID: <4FBBB28E.1080701@aol.com> Date: Tue, 22 May 2012 11:36:46 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mike Jones References: <026e01cd37a4$e406d670$ac148350$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F2FE746C@WSMSG3153V.srv.dir.telstra.com> <028001cd37ce$a6eaaa80$f4bfff80$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436651227A@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436651227A@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------000700050806050506090104" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1337701007; bh=5oMH4MH/RFXRNV5Mor5nJ8BnIhuXyRn9GE2jCB46o9I=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=bwhJrGDOVXVNhOOAF4QI12bo8eUQr1FgB5AsPoni7OmOFyTrYY+WOEaagH/vfFNSN uBbmhGIalJvBzGKZNqNAtQ+KGc7Cfh49RVqjGrCsOhEQpRan+l1FGU0m2iXX6YI2Ga /EUMXk7zzHNXUJ8PqoCC9KfgmufrF7KqZOKqh5Ew= X-AOL-SCOLL-SCORE: 1:2:489028544:93952408 X-AOL-SCOLL-URL_COUNT: 2 x-aol-sid: 3039ac1d33834fbbb28f5e02 X-AOL-IP: 10.181.186.254 Cc: Jim Schaad , "'Manger, James H'" , "jose@ietf.org" Subject: Re: [jose] Disscussion Issue - Algorithm Parameters 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, 22 May 2012 15:37:32 -0000 This is a multi-part message in MIME format. --------------000700050806050506090104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 On 5/22/12 1:49 AM, Mike Jones wrote: > > As background on the current spec design, both JSMS and the JWS family > of specs independently made a conscious design choice to specify a > small, limited set of cryptographic algorithms and algorithm > combinations to simplify implementations and increase > interoperability. Quoting from the introduction to JSMS > (with > *my emphasis*): > > Many applications require the ability to send cryptographically > > secured (encrypted, digitally signed, etc.) messages. While the IETF > > has defined a number of formats for such messages, *those formats are* > > * widely viewed as being excessively complicated for the demands of Web* > > * applications, which typically only need the ability to secure simple* > > * messages*. ... > > This document describes a new cryptographic message format, > > JavaScript Message Security (JSMS) intended to meet the need of the > > Web environment. While JSMS is modeled on existing formats -- > > principally CMS [RFC5652] -- it uses JavaScript Object Notation > > (JSON) rather than ASN.1/BER/DER, making it far easier for Web > > applications to handle. *In the interest of simplicity, JSMS also* > > * omits as many as possible of the CMS modes* (multiple signatures, > > password-based encryption). > > In parallel, the consensus decisions in the design discussions behind > the JWE design included: > > "we should specify a small set of composite operations that will > meet the needs of common use cases" > > We're trying to make simple things simple to facilitate widespread > deployment of strong crypto. The alternative is XML ENC, where all > parameters and parameter combinations **can** be specified but with no > guarantees that any particular combination, other than a > mandatory-to-implement set, will actually be supported or > interoperable among any particular implementations. > > I believe that the designers of both sets of JOSE precursor specs > reached the conclusion that simple specs with a small set of useful, > widely implemented, carefully chosen cryptographic primitives and > combinations would be of more practical value to developers and result > in more deployment and interoperability than a highly general spec > that allows for a large combinatorial set of parameter combinations. > > If new parameter combinations are needed in practice, they can easily > be specified in the JWA spec or in the registries that it defines. > > I hope that understanding this rationale behind the intentionally > limited sets of algorithms specified in both JSMS and JWA will be > useful to the working group. > > Best wishes, > > -- Mike > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > Of Jim Schaad > Sent: Monday, May 21, 2012 8:55 PM > To: 'Manger, James H'; jose@ietf.org > Subject: Re: [jose] Disscussion Issue - Algorithm Parameters > > > -----Original Message----- > > > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > > > > Sent: Monday, May 21, 2012 8:25 PM > > > To: Jim Schaad; jose@ietf.org > > > Subject: RE: [jose] Disscussion Issue - Algorithm Parameters > > > > > > > Should an algorithm be able to specific parameters rather than > > > > making them part of the algorithm name string? If so should we > > > > change the way that we are doing parameters to allow for this better? > > > > > > > alg: "RSA-OAEP-mf2-sha256" > > > > OR > > > > alg: { name:"RSA-OAEP", hash: "SHA-256", mgf: "mgf1" } > > > > > > > > > Another option is: > > > "alg": "RSA-OAEP" > > > "mgf": "MGF1" > > > "hash": "SHA-256" > > That is an option that is doable as well. I happen to think that it > might lead to problems down the road. If you have two algorithms in > the header, then one must make sure that there is no possibility that > the two algorithms will want to use the same field. > > Given that anybody can define a new algorithm, it is not possible to > do an exhaustive search for collisions in the use of field names. It > might be better to have them scoped already. > > > > > > I suspect additional parameters in the header (like "mgf" and "hash" > > above) > > > was the intention. This is why the algorithms spec (in sections 3.6 > > > and > > 4.11 for > > > signature and encryption algorithms) says: "additional reserved header > > > parameter names MAY be defined". > > > The result is a flat structure for all sorts of parameters: about the > > payload > > > ("typ"); about JWE processing ("enc", "int"); about a specific > > > algorithm ("mgf", "hash") etc. > > > A flat structure will cause headaches at some point (cf trying to > > > separate transport and content details from HTTP's flat header > > > structure), but it > > is > > > simpler to start with. > > > I suggest we stick with a flat structure for JOSE. > > > > > > > > > > > > > As an example of this, the RSA-OAEP algorithm needs to specify two > > > > parameters: The mask function and a hash function. > > > > > > For RSA-OAEP specifically, I suggest: > > > * picking one hash algorithm (SHA-256) and including it in the name > > > "RSA- OAEP256" > > > * hardwiring the mask-generation function (to be MGF1 with the same > > > hash > > > algorithm) (so no "mgf" parameter is needed) > > > * hardwiring the label to be empty. > > > > > > The resulting spec text could be: > > > ===== > > > 4.5 "RSA-OAEP256" > > > > > > The "RSA-OAEP256" key encryption algorithm is RSA encryption with > > > Optimal Asymmetric Encryption Padding (OAEP) using SHA-256. > > > The algorithm is specified in PKCS#1 [RFC 3447], where it is > > > called RSAES-OAEP-ENCRYPT. > > > > > > The hash function is SHA-256 [FIPS 180-4]. > > > > > > The mask generation function is MGF1 [RFC 3447], using SHA-256 as > > > the hash function. > > > > > > The label is the empty string. > > > ===== > > > > > > -- > > > 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 -- Chief Architect Identity Services Engineering AOL Inc. --------------000700050806050506090104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1

On 5/22/12 1:49 AM, Mike Jones wrote:

As background on the current spec design, both JSMS and the JWS family of specs independently made a conscious design choice to specify a small, limited set of cryptographic algorithms and algorithm combinations to simplify implementations and increase interoperability.  Quoting from the introduction to JSMS (with my emphasis):

 

   Many applications require the ability to send cryptographically

   secured (encrypted, digitally signed, etc.) messages.  While the IETF

   has defined a number of formats for such messages, those formats are

   widely viewed as being excessively complicated for the demands of Web

   applications, which typically only need the ability to secure simple

   messages.  ...

 

   This document describes a new cryptographic message format,

   JavaScript Message Security (JSMS) intended to meet the need of the

   Web environment.  While JSMS is modeled on existing formats --

   principally CMS [RFC5652] -- it uses JavaScript Object Notation

   (JSON) rather than ASN.1/BER/DER, making it far easier for Web

   applications to handle.  In the interest of simplicity, JSMS also

   omits as many as possible of the CMS modes (multiple signatures,

   password-based encryption).

 

In parallel, the consensus decisions in the design discussions behind the JWE design included:

    “we should specify a small set of composite operations that will meet the needs of common use cases

 

We’re trying to make simple things simple to facilitate widespread deployment of strong crypto.  The alternative is XML ENC, where all parameters and parameter combinations *can* be specified but with no guarantees that any particular combination, other than a mandatory-to-implement set, will actually be supported or interoperable among any particular implementations.

 

I believe that the designers of both sets of JOSE precursor specs reached the conclusion that simple specs with a small set of useful, widely implemented, carefully chosen cryptographic primitives and combinations would be of more practical value to developers and result in more deployment and interoperability than a highly general spec that allows for a large combinatorial set of parameter combinations.

 

If new parameter combinations are needed in practice, they can easily be specified in the JWA spec or in the registries that it defines.

 

I hope that understanding this rationale behind the intentionally limited sets of algorithms specified in both JSMS and JWA will be useful to the working group.

 

                                                            Best wishes,

                                                            -- Mike

 

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Monday, May 21, 2012 8:55 PM
To: 'Manger, James H'; jose@ietf.org
Subject: Re: [jose] Disscussion Issue - Algorithm Parameters

 

 

 

> -----Original Message-----

> From: Manger, James H [mailto:James.H.Manger@team.telstra.com]

> Sent: Monday, May 21, 2012 8:25 PM

> To: Jim Schaad; jose@ietf.org

> Subject: RE: [jose] Disscussion Issue - Algorithm Parameters

>

> > Should an algorithm be able to specific parameters rather than

> > making them part of the algorithm name string?  If so should we

> > change the way that we are doing parameters to allow for this better?

>

> > alg: "RSA-OAEP-mf2-sha256"

> > OR

> > alg: { name:"RSA-OAEP", hash: "SHA-256", mgf: "mgf1" }

>

>

> Another option is:

>   "alg": "RSA-OAEP"

>   "mgf": "MGF1"

>   "hash": "SHA-256"

 

That is an option that is doable as well.  I happen to think that it might lead to problems down the road.  If you have two algorithms in the header, then one must make sure that there is no possibility that the two algorithms will want to use the same field. 

 

Given that anybody can define a new algorithm, it is not possible to do an exhaustive search for collisions in the use of field names.  It might be better to have them scoped already.

 

 

>

> I suspect additional parameters in the header (like "mgf" and "hash"

above)

> was the intention. This is why the algorithms spec (in sections 3.6

> and

4.11 for

> signature and encryption algorithms) says: "additional reserved header

> parameter names MAY be defined".

> The result is a flat structure for all sorts of parameters: about the

payload

> ("typ"); about JWE processing ("enc", "int"); about a specific

> algorithm ("mgf", "hash") etc.

> A flat structure will cause headaches at some point (cf trying to

> separate transport and content details from HTTP's flat header

> structure), but it

is

> simpler to start with.

> I suggest we stick with a flat structure for JOSE.

>

>

>

> > As an example of this, the RSA-OAEP algorithm needs to specify two

> > parameters:  The mask function and a hash function.

>

> For RSA-OAEP specifically, I suggest:

> * picking one hash algorithm (SHA-256) and including it in the name

> "RSA- OAEP256"

> * hardwiring the mask-generation function (to be MGF1 with the same

> hash

> algorithm) (so no "mgf" parameter is needed)

> * hardwiring the label to be empty.

>

> The resulting spec text could be:

> =====

> 4.5 "RSA-OAEP256"

>

>   The "RSA-OAEP256" key encryption algorithm is RSA encryption with

>   Optimal Asymmetric Encryption Padding (OAEP) using SHA-256.

>   The algorithm is specified in PKCS#1 [RFC 3447], where it is

>   called RSAES-OAEP-ENCRYPT.

>

>   The hash function is SHA-256 [FIPS 180-4].

>

>   The mask generation function is MGF1 [RFC 3447], using SHA-256 as

>   the hash function.

>

>   The label is the empty string.

> =====

>

> --

> 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

-- 
Chief Architect              
Identity Services Engineering
AOL Inc.                     
--------------000700050806050506090104-- From Axel.Nennker@telekom.de Tue May 22 09:50:46 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3493721F84A7 for ; Tue, 22 May 2012 09:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdMtfrdxcu+m for ; Tue, 22 May 2012 09:50:42 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id C4A7221F84AF for ; Tue, 22 May 2012 09:50:41 -0700 (PDT) Received: from he111297.emea1.cds.t-internal.com ([10.125.90.15]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 22 May 2012 18:50:40 +0200 Received: from HE113558.emea1.cds.t-internal.com (10.125.65.100) by HE111297.EMEA1.CDS.T-INTERNAL.COM (10.125.90.15) with Microsoft SMTP Server (TLS) id 8.3.245.1; Tue, 22 May 2012 18:50:39 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.88]) by HE113558.emea1.cds.t-internal.com ([2002:7cd:4164::7cd:4164]) with mapi; Tue, 22 May 2012 18:50:39 +0200 From: To: , , , Date: Tue, 22 May 2012 18:50:37 +0200 Thread-Topic: [jose] Disscussion Issue - Algorithm Parameters Thread-Index: Ac03pF2514K1eFkfQHa3/Uzt2hZsGwAFxX3QAATL9oAAAIcqMAAaj1SA Message-ID: References: <026e01cd37a4$e406d670$ac148350$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F2FE746C@WSMSG3153V.srv.dir.telstra.com> <028001cd37ce$a6eaaa80$f4bfff80$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436651227A@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436651227A@TK5EX14MBXC284.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_CE8995AB5D178F44A2154F5C9A97CAF402512C54AD1EHE111541eme_" MIME-Version: 1.0 Subject: Re: [jose] Disscussion Issue - Algorithm Parameters 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, 22 May 2012 16:50:46 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF402512C54AD1EHE111541eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik= e Jones Sent: Tuesday, May 22, 2012 7:50 AM To: Jim Schaad; 'Manger, James H'; jose@ietf.org Subject: Re: [jose] Disscussion Issue - Algorithm Parameters As background on the current spec design, both JSMS and the JWS family of s= pecs independently made a conscious design choice to specify a small, limit= ed set of cryptographic algorithms and algorithm combinations to simplify i= mplementations and increase interoperability. Quoting from the introductio= n to JSMS (wit= h my emphasis): Many applications require the ability to send cryptographically secured (encrypted, digitally signed, etc.) messages. While the IETF has defined a number of formats for such messages, those formats are widely viewed as being excessively complicated for the demands of Web applications, which typically only need the ability to secure simple messages. ... This document describes a new cryptographic message format, JavaScript Message Security (JSMS) intended to meet the need of the Web environment. While JSMS is modeled on existing formats -- principally CMS [RFC5652] -- it uses JavaScript Object Notation (JSON) rather than ASN.1/BER/DER, making it far easier for Web applications to handle. In the interest of simplicity, JSMS also omits as many as possible of the CMS modes (multiple signatures, password-based encryption). In parallel, the consensus decisions in the design discussions behind the J= WE design included: "we should specify a small set of composite operations that will meet t= he needs of common use cases" We're trying to make simple things simple to facilitate widespread deployme= nt of strong crypto. The alternative is XML ENC, where all parameters and = parameter combinations *can* be specified but with no guarantees that any p= articular combination, other than a mandatory-to-implement set, will actual= ly be supported or interoperable among any particular implementations. I believe that the designers of both sets of JOSE precursor specs reached t= he conclusion that simple specs with a small set of useful, widely implemen= ted, carefully chosen cryptographic primitives and combinations would be of= more practical value to developers and result in more deployment and inter= operability than a highly general spec that allows for a large combinatoria= l set of parameter combinations. If new parameter combinations are needed in practice, they can easily be sp= ecified in the JWA spec or in the registries that it defines. I hope that understanding this rationale behind the intentionally limited s= ets of algorithms specified in both JSMS and JWA will be useful to the work= ing group. Best wishes, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Monday, May 21, 2012 8:55 PM To: 'Manger, James H'; jose@ietf.org Subject: Re: [jose] Disscussion Issue - Algorithm Parameters > -----Original Message----- > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > Sent: Monday, May 21, 2012 8:25 PM > To: Jim Schaad; jose@ietf.org > Subject: RE: [jose] Disscussion Issue - Algorithm Parameters > > > Should an algorithm be able to specific parameters rather than > > making them part of the algorithm name string? If so should we > > change the way that we are doing parameters to allow for this better? > > > alg: "RSA-OAEP-mf2-sha256" > > OR > > alg: { name:"RSA-OAEP", hash: "SHA-256", mgf: "mgf1" } > > > Another option is: > "alg": "RSA-OAEP" > "mgf": "MGF1" > "hash": "SHA-256" That is an option that is doable as well. I happen to think that it might = lead to problems down the road. If you have two algorithms in the header, = then one must make sure that there is no possibility that the two algorithm= s will want to use the same field. Given that anybody can define a new algorithm, it is not possible to do an = exhaustive search for collisions in the use of field names. It might be be= tter to have them scoped already. > > I suspect additional parameters in the header (like "mgf" and "hash" above) > was the intention. This is why the algorithms spec (in sections 3.6 > and 4.11 for > signature and encryption algorithms) says: "additional reserved header > parameter names MAY be defined". > The result is a flat structure for all sorts of parameters: about the payload > ("typ"); about JWE processing ("enc", "int"); about a specific > algorithm ("mgf", "hash") etc. > A flat structure will cause headaches at some point (cf trying to > separate transport and content details from HTTP's flat header > structure), but it is > simpler to start with. > I suggest we stick with a flat structure for JOSE. > > > > > As an example of this, the RSA-OAEP algorithm needs to specify two > > parameters: The mask function and a hash function. > > For RSA-OAEP specifically, I suggest: > * picking one hash algorithm (SHA-256) and including it in the name > "RSA- OAEP256" > * hardwiring the mask-generation function (to be MGF1 with the same > hash > algorithm) (so no "mgf" parameter is needed) > * hardwiring the label to be empty. > > The resulting spec text could be: > =3D=3D=3D=3D=3D > 4.5 "RSA-OAEP256" > > The "RSA-OAEP256" key encryption algorithm is RSA encryption with > Optimal Asymmetric Encryption Padding (OAEP) using SHA-256. > The algorithm is specified in PKCS#1 [RFC 3447], where it is > called RSAES-OAEP-ENCRYPT. > > The hash function is SHA-256 [FIPS 180-4]. > > The mask generation function is MGF1 [RFC 3447], using SHA-256 as > the hash function. > > The label is the empty string. > =3D=3D=3D=3D=3D > > -- > James Manger _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_CE8995AB5D178F44A2154F5C9A97CAF402512C54AD1EHE111541eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

Fro= m: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Mike Jones
Sent: Tuesday, May 22, 2012 7:50 AM
To: = Jim Schaad; 'Manger, James H'; jose@ietf.org
Subject: Re: [jose] = Disscussion Issue - Algorithm Parameters

<= p class=3DMsoNormal> 

As backgro= und on the current spec design, both JSMS and the JWS family of specs indep= endently made a conscious design choice to specify a small, limited set of = cryptographic algorithms and algorithm combinations to simplify implementat= ions and increase interoperability.  Quoting from the introduction to JSM= S (with my emphasis):

 

   Many applications req= uire the ability to send cryptographically

   secured (encrypted, digitally signed, etc.) messages.&nb= sp; While the IETF

   has d= efined a number of formats for such messages, those formats are

   widely viewed as being ex= cessively complicated for the demands of Web

   applications, which typically only need the abi= lity to secure simple

 &n= bsp; messages.  ...

&nb= sp;

   This document describes a= new cryptographic message format,

&n= bsp;  JavaScript Message Security (JSMS) intended to meet the need of = the

   Web environment.&nbs= p; While JSMS is modeled on existing formats --

   principally CMS [RFC5652] -- it uses JavaScript Obj= ect Notation

   (JSON) rath= er than ASN.1/BER/DER, making it far easier for Web

   applications to handle.  In the intere= st of simplicity, JSMS also

&n= bsp;  omits as many as possible of the CMS modes (multiple signatu= res,

   password-based encr= yption).

 

In parallel, the consensus decisions in the design discussions behind the JWE design= included:

    “= we should specify a small set of composite operations that will= meet the needs of common use cases

 

We’re tryin= g to make simple things simple to facilitate widespread deployment of stron= g crypto.  The alternative is XML ENC, where all parameters and parame= ter combinations *can* be specified but with no guarantees that any = particular combination, other than a mandatory-to-implement set, will actua= lly be supported or interoperable among any particular implementations.

 

I believe that the designers of both sets of JOSE precursor specs reac= hed the conclusion that simple specs with a small set of useful, widely imp= lemented, carefully chosen cryptographic primitives and combinations would = be of more practical value to developers and result in more deployment and = interoperability than a highly general spec that allows for a large combina= torial set of parameter combinations.

 

If new parameter combinations= are needed in practice, they can easily be specified in the JWA spec or in= the registries that it defines.

 

I hope that understanding this rat= ionale behind the intentionally limited sets of algorithms specified in bot= h JSMS and JWA will be useful to the working group.

 

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

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

 

-----Original Message-----
From: jose-bounces@ietf.org [mai= lto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Monday, May 21,= 2012 8:55 PM
To: 'Manger, James H'; jose@ietf.org
Subject: Re: [jose= ] Disscussion Issue - Algorithm Parameters

 

 

 

> ----= -Original Message-----

> From: Man= ger, James H [mailto:James.H.Manger@= team.telstra.com]

> Sen= t: Monday, May 21, 2012 8:25 PM

> = To: Jim Schaad; jose@ietf.org

> Subject: RE: [jose] Disscussion Issue - Algorithm Para= meters

>

> > Should an algorithm be able to specific parameter= s rather than

> > making them = part of the algorithm name string?  If so should we

> > change the way that we are doing parameters = to allow for this better?

> <= /o:p>

> > alg: "RSA-OAEP-mf2-sha256&q= uot;

> > OR

> > alg: { name:"RSA-OAEP", hash: "= SHA-256", mgf: "mgf1" }

>

>

> Another option is:

>   "alg": "RSA-OAEP"

>   "mgf": "MGF1"

>   "hash": "= ;SHA-256"

 

<= p class=3DMsoPlainText>That is an option that is doable as well.  I ha= ppen to think that it might lead to problems down the road.  If you ha= ve two algorithms in the header, then one must make sure that there is no p= ossibility that the two algorithms will want to use the same field.  <= o:p>

 

Given that anybody can define a new algorithm, it is not possible t= o do an exhaustive search for collisions in the use of field names.  I= t might be better to have them scoped already.

 

 

>

> I= suspect additional parameters in the header (like "mgf" and &quo= t;hash"

above)

> was the intention. This is why the algorithms spe= c (in sections 3.6

> and

4.11 for

> signature and encryption algorithms) says: "additional reserved= header

> parameter names MAY be = defined".

> The result is a f= lat structure for all sorts of parameters: about the

payload

> ("t= yp"); about JWE processing ("enc", "int"); about a= specific

> algorithm ("mgf&= quot;, "hash") etc.

> A = flat structure will cause headaches at some point (cf trying to =

> separate transport and content details fro= m HTTP's flat header

> structure)= , but it

is

> simpler to start with.

> I suggest we stick with a flat structure for JOSE.

<= p class=3DMsoPlainText>>

>

>

> > As an example of this, the RSA-OAEP algorithm needs to speci= fy two

> > parameters:  Th= e mask function and a hash function.

= >

> For RSA-OAEP specifically,= I suggest:

> * picking one hash a= lgorithm (SHA-256) and including it in the name

> "RSA- OAEP256"

> * hardwiring the mask-generation function (to be MGF1 with the sa= me

> hash

> algorithm) (so no "mgf" parameter is needed)=

> * hardwiring the label to be em= pty.

>

> The resulting spec text could be:

> =3D=3D=3D=3D=3D

= > 4.5 "RSA-OAEP256"

>=

>   The "RSA-OAEP= 256" key encryption algorithm is RSA encryption with

>   Optimal Asymmetric Encryption Padding= (OAEP) using SHA-256.

> &nbs= p; The algorithm is specified in PKCS#1 [RFC 3447], where it is<= /p>

>   called RSAES-OAEP-ENCRYPT.=

>

>   The hash function is SHA-256 [FIPS 180-4].

>

>&= nbsp;  The mask generation function is MGF1 [RFC 3447], using SHA-256 = as

>   the hash function= .

>

>   The label is the empty string.

> =3D=3D=3D=3D=3D

>

> --

> James Manger

=  

______________________________= _________________

jose mailing list

jose@ietf.org

http= s://www.ietf.org/mailman/listinfo/jose

 

= --_000_CE8995AB5D178F44A2154F5C9A97CAF402512C54AD1EHE111541eme_-- From ietf@augustcellars.com Tue May 22 09:55: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 6DEDF21F84BF for ; Tue, 22 May 2012 09:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHp3nZ-J6eH3 for ; Tue, 22 May 2012 09:55:09 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id A793F21F84B6 for ; Tue, 22 May 2012 09:55:09 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id EAA5A2CA25; Tue, 22 May 2012 09:55:08 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , References: <026e01cd37a4$e406d670$ac148350$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F2FE746C@WSMSG3153V.srv.dir.telstra.com> <028001cd37ce$a6eaaa80$f4bfff80$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436651227A@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436651227A@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Tue, 22 May 2012 09:53:52 -0700 Message-ID: <02aa01cd383b$78266320$68732960$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02AB_01CD3800.CBD323E0" X-Mailer: Microsoft Outlook 14.0 thread-index: AQJTMkX84NM/XCcjp4/V7EN5qPKLUQJ+iFxzAsP+20wBzAHfE5WRnd9A Content-Language: en-us Subject: Re: [jose] Disscussion Issue - Algorithm Parameters 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, 22 May 2012 16:55:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02AB_01CD3800.CBD323E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I fully understand that you wanted to keep it simple. That is why I proposed having the option - either a string or a structure. Allowing for the structure allows people who want to have the complexity have it. This would not be the normal case. Jim From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Monday, May 21, 2012 10:50 PM To: Jim Schaad; 'Manger, James H'; jose@ietf.org Subject: RE: [jose] Disscussion Issue - Algorithm Parameters As background on the current spec design, both JSMS and the JWS family of specs independently made a conscious design choice to specify a small, limited set of cryptographic algorithms and algorithm combinations to simplify implementations and increase interoperability. Quoting from the introduction to JSMS (with my emphasis): Many applications require the ability to send cryptographically secured (encrypted, digitally signed, etc.) messages. While the IETF has defined a number of formats for such messages, those formats are widely viewed as being excessively complicated for the demands of Web applications, which typically only need the ability to secure simple messages. ... This document describes a new cryptographic message format, JavaScript Message Security (JSMS) intended to meet the need of the Web environment. While JSMS is modeled on existing formats -- principally CMS [RFC5652] -- it uses JavaScript Object Notation (JSON) rather than ASN.1/BER/DER, making it far easier for Web applications to handle. In the interest of simplicity, JSMS also omits as many as possible of the CMS modes (multiple signatures, password-based encryption). In parallel, the consensus decisions in the design discussions behind the JWE design included: "we should specify a small set of composite operations that will meet the needs of common use cases" We're trying to make simple things simple to facilitate widespread deployment of strong crypto. The alternative is XML ENC, where all parameters and parameter combinations *can* be specified but with no guarantees that any particular combination, other than a mandatory-to-implement set, will actually be supported or interoperable among any particular implementations. I believe that the designers of both sets of JOSE precursor specs reached the conclusion that simple specs with a small set of useful, widely implemented, carefully chosen cryptographic primitives and combinations would be of more practical value to developers and result in more deployment and interoperability than a highly general spec that allows for a large combinatorial set of parameter combinations. If new parameter combinations are needed in practice, they can easily be specified in the JWA spec or in the registries that it defines. I hope that understanding this rationale behind the intentionally limited sets of algorithms specified in both JSMS and JWA will be useful to the working group. Best wishes, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Monday, May 21, 2012 8:55 PM To: 'Manger, James H'; jose@ietf.org Subject: Re: [jose] Disscussion Issue - Algorithm Parameters > -----Original Message----- > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > Sent: Monday, May 21, 2012 8:25 PM > To: Jim Schaad; jose@ietf.org > Subject: RE: [jose] Disscussion Issue - Algorithm Parameters > > > Should an algorithm be able to specific parameters rather than > > making them part of the algorithm name string? If so should we > > change the way that we are doing parameters to allow for this better? > > > alg: "RSA-OAEP-mf2-sha256" > > OR > > alg: { name:"RSA-OAEP", hash: "SHA-256", mgf: "mgf1" } > > > Another option is: > "alg": "RSA-OAEP" > "mgf": "MGF1" > "hash": "SHA-256" That is an option that is doable as well. I happen to think that it might lead to problems down the road. If you have two algorithms in the header, then one must make sure that there is no possibility that the two algorithms will want to use the same field. Given that anybody can define a new algorithm, it is not possible to do an exhaustive search for collisions in the use of field names. It might be better to have them scoped already. > > I suspect additional parameters in the header (like "mgf" and "hash" above) > was the intention. This is why the algorithms spec (in sections 3.6 > and 4.11 for > signature and encryption algorithms) says: "additional reserved header > parameter names MAY be defined". > The result is a flat structure for all sorts of parameters: about the payload > ("typ"); about JWE processing ("enc", "int"); about a specific > algorithm ("mgf", "hash") etc. > A flat structure will cause headaches at some point (cf trying to > separate transport and content details from HTTP's flat header > structure), but it is > simpler to start with. > I suggest we stick with a flat structure for JOSE. > > > > > As an example of this, the RSA-OAEP algorithm needs to specify two > > parameters: The mask function and a hash function. > > For RSA-OAEP specifically, I suggest: > * picking one hash algorithm (SHA-256) and including it in the name > "RSA- OAEP256" > * hardwiring the mask-generation function (to be MGF1 with the same > hash > algorithm) (so no "mgf" parameter is needed) > * hardwiring the label to be empty. > > The resulting spec text could be: > ===== > 4.5 "RSA-OAEP256" > > The "RSA-OAEP256" key encryption algorithm is RSA encryption with > Optimal Asymmetric Encryption Padding (OAEP) using SHA-256. > The algorithm is specified in PKCS#1 [RFC 3447], where it is > called RSAES-OAEP-ENCRYPT. > > The hash function is SHA-256 [FIPS 180-4]. > > The mask generation function is MGF1 [RFC 3447], using SHA-256 as > the hash function. > > The label is the empty string. > ===== > > -- > James Manger _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose ------=_NextPart_000_02AB_01CD3800.CBD323E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I fully understand that you wanted to keep it = simple.  That is why I proposed having the option – either a = string or a structure.   Allowing for the structure allows = people who want to have the complexity have it.  This would not be = the normal case.

 

Jim

 

 

From:= = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Monday, = May 21, 2012 10:50 PM
To: Jim Schaad; 'Manger, James H'; = jose@ietf.org
Subject: RE: [jose] Disscussion Issue - = Algorithm Parameters

 

As = background on the current spec design, both JSMS and the JWS family of = specs independently made a conscious design choice to specify a small, = limited set of cryptographic algorithms and algorithm combinations to = simplify implementations and increase interoperability.  Quoting = from the intr= oduction to JSMS (with my emphasis):

 

   Many applications require the ability = to send cryptographically

   secured (encrypted, digitally signed, = etc.) messages.  While the IETF

   has defined a number of formats for = such messages, those formats are

   widely viewed as being excessively = complicated for the demands of Web

   applications, which typically only = need the ability to secure simple

   messages.  = ...

 

   This document describes a new = cryptographic message format,

   JavaScript Message Security (JSMS) = intended to meet the need of the

   Web environment.  While JSMS is = modeled on existing formats --

   principally CMS [RFC5652] -- it uses = JavaScript Object Notation

   (JSON) rather than ASN.1/BER/DER, = making it far easier for Web

   applications to handle.  In = the interest of simplicity, JSMS also

   omits as many as possible of the = CMS modes (multiple signatures,

   password-based = encryption).

 

In = parallel, the consensus decisions in the design discussions behind the = JWE design included:

    “we should specify a small set of = composite operations that will meet the needs of common use = cases

 

We’re trying to make simple things simple to = facilitate widespread deployment of strong crypto.  The alternative = is XML ENC, where all parameters and parameter combinations *can* = be specified but with no guarantees that any particular combination, = other than a mandatory-to-implement set, will actually be supported or = interoperable among any particular implementations.

 

I = believe that the designers of both sets of JOSE precursor specs reached = the conclusion that simple specs with a small set of useful, widely = implemented, carefully chosen cryptographic primitives and combinations = would be of more practical value to developers and result in more = deployment and interoperability than a highly general spec that allows = for a large combinatorial set of parameter = combinations.

 

If new = parameter combinations are needed in practice, they can easily be = specified in the JWA spec or in the registries that it = defines.

 

I hope that understanding this rationale behind the = intentionally limited sets of algorithms specified in both JSMS and JWA = will be useful to the working group.

 

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

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

 

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.= org] On Behalf Of Jim Schaad
Sent: Monday, May 21, 2012 8:55 = PM
To: 'Manger, James H'; jose@ietf.org
Subject: Re: [jose] = Disscussion Issue - Algorithm Parameters

 

 

 

> = -----Original Message-----

> = From: Manger, James H [mailto:James.H.Manger@te= am.telstra.com]

> = Sent: Monday, May 21, 2012 8:25 PM

> To: Jim Schaad; jose@ietf.org<= o:p>

> Subject: RE: [jose] = Disscussion Issue - Algorithm Parameters

>

> = > Should an algorithm be able to specific parameters rather than =

> > making them part of the = algorithm name string?  If so should we

> > change the way that we are doing = parameters to allow for this better?

>

> = > alg: "RSA-OAEP-mf2-sha256"

> > OR

> > alg: { name:"RSA-OAEP", hash: = "SHA-256", mgf: "mgf1" }

>

> =

> Another option = is:

>   = "alg": "RSA-OAEP"

>   "mgf": = "MGF1"

>   = "hash": "SHA-256"

 

That = is an option that is doable as well.  I happen to think that it = might lead to problems down the road.  If you have two algorithms = in the header, then one must make sure that there is no possibility that = the two algorithms will want to use the same field.  =

 

Given that anybody can define a new algorithm, it = is not possible to do an exhaustive search for collisions in the use of = field names.  It might be better to have them scoped = already.

 

 

> =

> I suspect additional = parameters in the header (like "mgf" and = "hash"

above)

> = was the intention. This is why the algorithms spec (in sections 3.6 =

> and

4.11 for

> = signature and encryption algorithms) says: "additional reserved = header

> parameter names MAY = be defined".

> The result = is a flat structure for all sorts of parameters: about = the

payload

> ("typ"); about JWE processing = ("enc", "int"); about a specific

> algorithm ("mgf", "hash") = etc.

> A flat structure will = cause headaches at some point (cf trying to

> separate transport and content details from = HTTP's flat header

> = structure), but it

is

> = simpler to start with.

> I = suggest we stick with a flat structure for JOSE.

>

> =

>

> > As an example of this, the RSA-OAEP = algorithm needs to specify two

> > parameters:  The mask function and a = hash function.

> =

> For RSA-OAEP specifically, I = suggest:

> * picking one hash = algorithm (SHA-256) and including it in the name

> "RSA- OAEP256"

> * hardwiring the mask-generation function (to = be MGF1 with the same

> = hash

> algorithm) (so no = "mgf" parameter is needed)

> * hardwiring the label to be = empty.

>

> The resulting spec text could = be:

> = =3D=3D=3D=3D=3D

> 4.5 = "RSA-OAEP256"

> =

>   The = "RSA-OAEP256" key encryption algorithm is RSA encryption = with

>   Optimal = Asymmetric Encryption Padding (OAEP) using SHA-256.

>   The algorithm is specified in = PKCS#1 [RFC 3447], where it is

>   called = RSAES-OAEP-ENCRYPT.

> =

>   The hash = function is SHA-256 [FIPS 180-4].

>

>   The mask generation function is = MGF1 [RFC 3447], using SHA-256 as

>   the hash = function.

>

>   The label is the empty = string.

> = =3D=3D=3D=3D=3D

> =

> --

> James Manger

 

_______________________________________________=

jose mailing list

jose@ietf.org<= o:p>

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

 

------=_NextPart_000_02AB_01CD3800.CBD323E0-- From cmortimore@salesforce.com Tue May 22 09:56:02 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01EE21F85B8 for ; Tue, 22 May 2012 09:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbA4UHFp9GuY for ; Tue, 22 May 2012 09:56:01 -0700 (PDT) Received: from exprod8og112.obsmtp.com (exprod8og112.obsmtp.com [64.18.3.24]) by ietfa.amsl.com (Postfix) with SMTP id D042A21F85B5 for ; Tue, 22 May 2012 09:56:00 -0700 (PDT) Received: from exsfm-hub5.internal.salesforce.com ([204.14.239.233]) by exprod8ob112.postini.com ([64.18.7.12]) with SMTP ID DSNKT7vFIEFWoJ9sVdFm9tL0o52zPK32vHGi@postini.com; Tue, 22 May 2012 09:56:00 PDT Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.58]) by exsfm-hub5.internal.salesforce.com ([10.1.127.5]) with mapi; Tue, 22 May 2012 09:56:00 -0700 From: Chuck Mortimore To: "" Date: Tue, 22 May 2012 09:55:58 -0700 Thread-Topic: [jose] Disscussion Issue - Algorithm Parameters Thread-Index: Ac04O8LJ0uQPjMjPQbKuB16hD7zXpg== Message-ID: <5F239486-031A-47FB-A508-83ACFD76EEFD@salesforce.com> References: <026e01cd37a4$e406d670$ac148350$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F2FE746C@WSMSG3153V.srv.dir.telstra.com> <028001cd37ce$a6eaaa80$f4bfff80$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436651227A@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5F239486031A47FBA50883ACFD76EEFDsalesforcecom_" MIME-Version: 1.0 Cc: "Michael.Jones@microsoft.com" , "James.H.Manger@team.telstra.com" , "ietf@augustcellars.com" , "jose@ietf.org" Subject: Re: [jose] Disscussion Issue - Algorithm Parameters 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, 22 May 2012 16:56:02 -0000 --_000_5F239486031A47FBA50883ACFD76EEFDsalesforcecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 on editing down available options in exchange for simplicity On May 22, 2012, at 9:50 AM, > wrote: +1 From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Mike Jones Sent: Tuesday, May 22, 2012 7:50 AM To: Jim Schaad; 'Manger, James H'; jose@ietf.org Subject: Re: [jose] Disscussion Issue - Algorithm Parameters As background on the current spec design, both JSMS and the JWS family of s= pecs independently made a conscious design choice to specify a small, limit= ed set of cryptographic algorithms and algorithm combinations to simplify i= mplementations and increase interoperability. Quoting from the introductio= n to JSMS (wit= h my emphasis): Many applications require the ability to send cryptographically secured (encrypted, digitally signed, etc.) messages. While the IETF has defined a number of formats for such messages, those formats are widely viewed as being excessively complicated for the demands of Web applications, which typically only need the ability to secure simple messages. ... This document describes a new cryptographic message format, JavaScript Message Security (JSMS) intended to meet the need of the Web environment. While JSMS is modeled on existing formats -- principally CMS [RFC5652] -- it uses JavaScript Object Notation (JSON) rather than ASN.1/BER/DER, making it far easier for Web applications to handle. In the interest of simplicity, JSMS also omits as many as possible of the CMS modes (multiple signatures, password-based encryption). In parallel, the consensus decisions in the design discussions behind the J= WE design included: =93we should specify a small set of composite operations that will meet= the needs of common use cases=94 We=92re trying to make simple things simple to facilitate widespread deploy= ment of strong crypto. The alternative is XML ENC, where all parameters an= d parameter combinations *can* be specified but with no guarantees that any= particular combination, other than a mandatory-to-implement set, will actu= ally be supported or interoperable among any particular implementations. I believe that the designers of both sets of JOSE precursor specs reached t= he conclusion that simple specs with a small set of useful, widely implemen= ted, carefully chosen cryptographic primitives and combinations would be of= more practical value to developers and result in more deployment and inter= operability than a highly general spec that allows for a large combinatoria= l set of parameter combinations. If new parameter combinations are needed in practice, they can easily be sp= ecified in the JWA spec or in the registries that it defines. I hope that understanding this rationale behind the intentionally limited s= ets of algorithms specified in both JSMS and JWA will be useful to the work= ing group. Best wishes, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Jim Schaad Sent: Monday, May 21, 2012 8:55 PM To: 'Manger, James H'; jose@ietf.org Subject: Re: [jose] Disscussion Issue - Algorithm Parameters > -----Original Message----- > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > Sent: Monday, May 21, 2012 8:25 PM > To: Jim Schaad; jose@ietf.org > Subject: RE: [jose] Disscussion Issue - Algorithm Parameters > > > Should an algorithm be able to specific parameters rather than > > making them part of the algorithm name string? If so should we > > change the way that we are doing parameters to allow for this better? > > > alg: "RSA-OAEP-mf2-sha256" > > OR > > alg: { name:"RSA-OAEP", hash: "SHA-256", mgf: "mgf1" } > > > Another option is: > "alg": "RSA-OAEP" > "mgf": "MGF1" > "hash": "SHA-256" That is an option that is doable as well. I happen to think that it might = lead to problems down the road. If you have two algorithms in the header, = then one must make sure that there is no possibility that the two algorithm= s will want to use the same field. Given that anybody can define a new algorithm, it is not possible to do an = exhaustive search for collisions in the use of field names. It might be be= tter to have them scoped already. > > I suspect additional parameters in the header (like "mgf" and "hash" above) > was the intention. This is why the algorithms spec (in sections 3.6 > and 4.11 for > signature and encryption algorithms) says: "additional reserved header > parameter names MAY be defined". > The result is a flat structure for all sorts of parameters: about the payload > ("typ"); about JWE processing ("enc", "int"); about a specific > algorithm ("mgf", "hash") etc. > A flat structure will cause headaches at some point (cf trying to > separate transport and content details from HTTP's flat header > structure), but it is > simpler to start with. > I suggest we stick with a flat structure for JOSE. > > > > > As an example of this, the RSA-OAEP algorithm needs to specify two > > parameters: The mask function and a hash function. > > For RSA-OAEP specifically, I suggest: > * picking one hash algorithm (SHA-256) and including it in the name > "RSA- OAEP256" > * hardwiring the mask-generation function (to be MGF1 with the same > hash > algorithm) (so no "mgf" parameter is needed) > * hardwiring the label to be empty. > > The resulting spec text could be: > =3D=3D=3D=3D=3D > 4.5 "RSA-OAEP256" > > The "RSA-OAEP256" key encryption algorithm is RSA encryption with > Optimal Asymmetric Encryption Padding (OAEP) using SHA-256. > The algorithm is specified in PKCS#1 [RFC 3447], where it is > called RSAES-OAEP-ENCRYPT. > > The hash function is SHA-256 [FIPS 180-4]. > > The mask generation function is MGF1 [RFC 3447], using SHA-256 as > the hash function. > > The label is the empty string. > =3D=3D=3D=3D=3D > > -- > 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 --_000_5F239486031A47FBA50883ACFD76EEFDsalesforcecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Axel.Nennker@telekom.de> wrote:=
+= 1
 <= /o:p>
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Tuesday, May 22, 2012 7:50 AM
To: Jim Schaad; 'Manger, James H'; 
jose@ietf.org
Subject: Re: = [jose] Disscussion Issue - Algorithm Parameters
 
=    Many applications require the ability to send cryptographicall= y
   secured (encrypted, digitally signed, etc.) mess= ages.  While the IETF
   has defined a number of= formats for such messages, those formats are
   widely viewed as be= ing excessively complicated for the demands of Web
 = ;  applications, which typically only need the ability to secure simpl= e
   messages.  ...
<= div style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; margin-b= ottom: 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">=  
   This document describes a new cryptographic mess= age format,
   JavaScript Message Security (JSMS) int= ended to meet the need of the
   Web environment.&nbs= p; While JSMS is modeled on existing formats --
   p= rincipally CMS [RFC5652] -- it uses JavaScript Object Notation
=    (JSON) rather than ASN.1/BER/DER, making it far easier for Web=
   applications to handle.  In the interest of simplicity, JSMS also<= o:p>
   omits as many as possible of the CMS modes<= /b> (multiple signatures,=
   password-based encryption).
&nbs= p;
In parallel, the consensus decisions in the design discussions behin= d the JWE design incl= uded:
    =93we should s= pecify a small set of composite operations that will meet the needs of comm= on use cases=94
 
We=92re trying to mak= e simple things simple to facilitate widespread deployment of strong crypto= .  The alternative is XML ENC, where all parameters and parameter comb= inations *can* be specified but with no guarantees that any particul= ar combination, other than a mandatory-to-implement set, will actually be s= upported or interoperable among any particular implementations.<= /div>
 
I believe that the designers of both sets of JOSE precu= rsor specs reached the conclusion that simple specs with a small set of use= ful, widely implemented, carefully chosen cryptographic primitives and comb= inations would be of more practical value to developers and result in more = deployment and interoperability than a highly general spec that allows for = a large combinatorial set of parameter combinations.
 = ;
If new parameter combinations are needed in practice, they can eas= ily be specified in the JWA spec or in the registries that it defines.=
 
I hope that understanding this rationale behind = the intentionally limited sets of algorithms specified in both JSMS and JWA= will be useful to the working group.
 
 =             &nb= sp;            =             &nb= sp;            =          Best wishes,
&= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         -- Mike
<= o:p> 
-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.o= rg] On Behalf Of Jim Schaad
Sent: Monday, May 21, 2012 8:55 PM
To: 'M= anger, James H';  
> Sent: Mon= day, May 21, 2012 8:25 PM
> To: Jim Schaad; jose@ietf.org
> Subje= ct: RE: [jose] Disscussion Issue - Algorithm Parameters
>
> > Should an algorithm be able to specific parameters rath= er than
> > making them part of the algorithm name string= ?  If so should we
> > change the way that we are do= ing parameters to allow for this better?
>
<= div style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; margin-b= ottom: 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">> = > alg: "RSA-OAEP-mf2-sha256"
> > OR
> &= gt; alg: { name:"RSA-OAEP", hash: "SHA-256", mgf: "mgf1" }
=
>=
>
> Another option is:
> = ;  "alg": "RSA-OAEP"
>   "mgf": "MGF1"
>   "hash": "SHA-256"
 
Tha= t is an option that is doable as well.  I happen to think that it migh= t lead to problems down the road.  If you have two algorithms in the h= eader, then one must make sure that there is no possibility that the two al= gorithms will want to use the same field. 
 
Given that anybody can define a new algorithm, it is not possible to d= o an exhaustive search for collisions in the use of field names.  It m= ight be better to have them scoped already.
 
=  
>
> I suspect additional parameters in= the header (like "mgf" and "hash"
above)
> was = the intention. This is why the algorithms spec (in sections 3.6<= /div>
> and
4.11 for
> signature and encryption al= gorithms) says: "additional reserved header
> parameter name= s MAY be defined".
> The result is a flat structure for all = sorts of parameters: about the
payload
> ("typ")= ; about JWE processing ("enc", "int"); about a specific
> al= gorithm ("mgf", "hash") etc.
> A flat structure will cause h= eadaches at some point (cf trying to
> separate transport an= d content details from HTTP's flat header
> structure), but = it
is
> simpler to start with.
<= div style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; margin-b= ottom: 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">> = I suggest we stick with a flat structure for JOSE.
>
>
>
> > As an example of this, the= RSA-OAEP algorithm needs to specify two
> > parameters:&= nbsp; The mask function and a hash function.
>
&= gt; For RSA-OAEP specifically, I suggest:
> * picking one ha= sh algorithm (SHA-256) and including it in the name
> "RSA- = OAEP256"
> * hardwiring the mask-generation function (to be = MGF1 with the same
> hash
> algorithm) (so no= "mgf" parameter is needed)
> * hardwiring the label to be e= mpty.
>
> The resulting spec text could be:
> =3D=3D=3D=3D=3D
> 4.5 "RSA-OAEP256"
>
>   The "RSA-OAEP256" key encryption algo= rithm is RSA encryption with
>   Optimal Asymmetri= c Encryption Padding (OAEP) using SHA-256.
>   The= algorithm is specified in PKCS#1 [RFC 3447], where it is
<= div style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; margin-b= ottom: 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">>&= nbsp;  called RSAES-OAEP-ENCRYPT.
>
>&nb= sp;  The hash function is SHA-256 [FIPS 180-4].
><= /o:p>
>   The mask generation function is MGF1 [RFC 3447], us= ing SHA-256 as
>   the hash function.
= >
>   The label is the empty string.=
>
> --
>= ; James Manger
 
_____________________________= __________________
jose mailing list
 
______________________= _________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo= /jose

= --_000_5F239486031A47FBA50883ACFD76EEFDsalesforcecom_-- From dick.hardt@gmail.com Tue May 22 10:48: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 B65A521F8631 for ; Tue, 22 May 2012 10:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOW8AOSz3jPq for ; Tue, 22 May 2012 10:48:32 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 37BD921F8606 for ; Tue, 22 May 2012 10:48:32 -0700 (PDT) Received: by dacx6 with SMTP id x6so8770553dac.31 for ; Tue, 22 May 2012 10:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=4ie59AOdokfF0Hjp47tfP0L46BN3BXNU2qx0G5k4BhA=; b=TtG2RzwvU3+qGRxDlbNu29QwBrzCIk+rYKQ0AtAyfRdn75APzcIsDMvzqIY+olnyMX +UbduXrFm0qGgun1v46goF30o2iKnE7xMYiSpWgkazPipbXDwTgGOH69EhTfDb4qqlR0 T9R85KnusTCpE7P02PaOpxZ20TuxsThjj8PDmD+dtnJvNiuVUc1KgMffwzyWiHRGzlSL O3yah0IMaPBWrCZpuN2WHOwhI3aBUoiN4fTiX0GsIrz5PM1Vk/cvwOVUNOuiICYca6+c R5vzEdiYfoOWEA8i4vw5zr10g1WRHLh3dksznPcEhv8mykf2rUOsdL6+S7ocxw990+oS iDQw== Received: by 10.68.236.169 with SMTP id uv9mr939239pbc.64.1337708911713; Tue, 22 May 2012 10:48:31 -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 nd6sm27363557pbc.63.2012.05.22.10.48.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 May 2012 10:48:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_4CF1105B-3E31-4E2D-990D-F464614C5E23" From: Dick Hardt In-Reply-To: <5F239486-031A-47FB-A508-83ACFD76EEFD@salesforce.com> Date: Tue, 22 May 2012 10:48:28 -0700 Message-Id: <81423F8B-71B7-4F29-9425-C9CB47CA8F44@gmail.com> References: <026e01cd37a4$e406d670$ac148350$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F2FE746C@WSMSG3153V.srv.dir.telstra.com> <028001cd37ce$a6eaaa80$f4bfff80$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436651227A@TK5EX14MBXC284.redmond.corp.microsoft.com> <5F239486-031A-47FB-A508-83ACFD76EEFD@salesforce.com> To: jose@ietf.org X-Mailer: Apple Mail (2.1278) Cc: Mike Jones , James.H.Manger@team.telstra.com, ietf@augustcellars.com, Axel Nennker , Chuck Mortimore Subject: Re: [jose] Disscussion Issue - Algorithm Parameters 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, 22 May 2012 17:48:33 -0000 --Apple-Mail=_4CF1105B-3E31-4E2D-990D-F464614C5E23 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 +1 on keeping it simple per the current design of of the algorithm being = a single string I have one implementation running and deployed and another being = designed and prefer having only a few good crypto choices, but being = extensible in case others are needed by having a different string.=20 -- Dick On May 22, 2012, at 9:55 AM, Chuck Mortimore wrote: > +1 on editing down available options in exchange for simplicity >=20 >=20 > On May 22, 2012, at 9:50 AM, wrote: >=20 >> +1 >> =20 >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Mike Jones >> Sent: Tuesday, May 22, 2012 7:50 AM >> To: Jim Schaad; 'Manger, James H'; jose@ietf.org >> Subject: Re: [jose] Disscussion Issue - Algorithm Parameters >> =20 >> As background on the current spec design, both JSMS and the JWS = family of specs independently made a conscious design choice to specify = a small, limited set of cryptographic algorithms and algorithm = combinations to simplify implementations and increase interoperability. = Quoting from the introduction to JSMS (with my emphasis): >> =20 >> Many applications require the ability to send cryptographically >> secured (encrypted, digitally signed, etc.) messages. While the = IETF >> has defined a number of formats for such messages, those formats = are >> widely viewed as being excessively complicated for the demands of = Web >> applications, which typically only need the ability to secure = simple >> messages. ... >> =20 >> This document describes a new cryptographic message format, >> JavaScript Message Security (JSMS) intended to meet the need of = the >> Web environment. While JSMS is modeled on existing formats -- >> principally CMS [RFC5652] -- it uses JavaScript Object Notation >> (JSON) rather than ASN.1/BER/DER, making it far easier for Web >> applications to handle. In the interest of simplicity, JSMS also >> omits as many as possible of the CMS modes (multiple signatures, >> password-based encryption). >> =20 >> In parallel, the consensus decisions in the design discussions behind = the JWE design included: >> =93we should specify a small set of composite operations that = will meet the needs of common use cases=94 >> =20 >> We=92re trying to make simple things simple to facilitate widespread = deployment of strong crypto. The alternative is XML ENC, where all = parameters and parameter combinations *can* be specified but with no = guarantees that any particular combination, other than a = mandatory-to-implement set, will actually be supported or interoperable = among any particular implementations. >> =20 >> I believe that the designers of both sets of JOSE precursor specs = reached the conclusion that simple specs with a small set of useful, = widely implemented, carefully chosen cryptographic primitives and = combinations would be of more practical value to developers and result = in more deployment and interoperability than a highly general spec that = allows for a large combinatorial set of parameter combinations. >> =20 >> If new parameter combinations are needed in practice, they can easily = be specified in the JWA spec or in the registries that it defines. >> =20 >> I hope that understanding this rationale behind the intentionally = limited sets of algorithms specified in both JSMS and JWA will be useful = to the working group. >> =20 >> Best = wishes, >> -- Mike >> =20 >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Jim Schaad >> Sent: Monday, May 21, 2012 8:55 PM >> To: 'Manger, James H'; jose@ietf.org >> Subject: Re: [jose] Disscussion Issue - Algorithm Parameters >> =20 >> =20 >> =20 >> > -----Original Message----- >> > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] >> > Sent: Monday, May 21, 2012 8:25 PM >> > To: Jim Schaad; jose@ietf.org >> > Subject: RE: [jose] Disscussion Issue - Algorithm Parameters >> > >> > > Should an algorithm be able to specific parameters rather than >> > > making them part of the algorithm name string? If so should we >> > > change the way that we are doing parameters to allow for this = better? >> > >> > > alg: "RSA-OAEP-mf2-sha256" >> > > OR >> > > alg: { name:"RSA-OAEP", hash: "SHA-256", mgf: "mgf1" } >> > >> > >> > Another option is: >> > "alg": "RSA-OAEP" >> > "mgf": "MGF1" >> > "hash": "SHA-256" >> =20 >> That is an option that is doable as well. I happen to think that it = might lead to problems down the road. If you have two algorithms in the = header, then one must make sure that there is no possibility that the = two algorithms will want to use the same field.=20 >> =20 >> Given that anybody can define a new algorithm, it is not possible to = do an exhaustive search for collisions in the use of field names. It = might be better to have them scoped already. >> =20 >> =20 >> > >> > I suspect additional parameters in the header (like "mgf" and = "hash" >> above) >> > was the intention. This is why the algorithms spec (in sections 3.6 >> > and >> 4.11 for >> > signature and encryption algorithms) says: "additional reserved = header >> > parameter names MAY be defined". >> > The result is a flat structure for all sorts of parameters: about = the >> payload >> > ("typ"); about JWE processing ("enc", "int"); about a specific >> > algorithm ("mgf", "hash") etc. >> > A flat structure will cause headaches at some point (cf trying to >> > separate transport and content details from HTTP's flat header >> > structure), but it >> is >> > simpler to start with. >> > I suggest we stick with a flat structure for JOSE. >> > >> > >> > >> > > As an example of this, the RSA-OAEP algorithm needs to specify = two >> > > parameters: The mask function and a hash function. >> > >> > For RSA-OAEP specifically, I suggest: >> > * picking one hash algorithm (SHA-256) and including it in the name >> > "RSA- OAEP256" >> > * hardwiring the mask-generation function (to be MGF1 with the same >> > hash >> > algorithm) (so no "mgf" parameter is needed) >> > * hardwiring the label to be empty. >> > >> > The resulting spec text could be: >> > =3D=3D=3D=3D=3D >> > 4.5 "RSA-OAEP256" >> > >> > The "RSA-OAEP256" key encryption algorithm is RSA encryption with >> > Optimal Asymmetric Encryption Padding (OAEP) using SHA-256. >> > The algorithm is specified in PKCS#1 [RFC 3447], where it is >> > called RSAES-OAEP-ENCRYPT. >> > >> > The hash function is SHA-256 [FIPS 180-4]. >> > >> > The mask generation function is MGF1 [RFC 3447], using SHA-256 as >> > the hash function. >> > >> > The label is the empty string. >> > =3D=3D=3D=3D=3D >> > >> > -- >> > James Manger >> =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 --Apple-Mail=_4CF1105B-3E31-4E2D-990D-F464614C5E23 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 +1 on = keeping it simple per the current design of of the algorithm being a = single string

I have one implementation running and = deployed and another being designed and prefer having only a few good = crypto choices, but being extensible in case others are needed by having = a different string. 

-- = Dick

On May 22, 2012, at 9:55 AM, Chuck = Mortimore wrote:

+1 on editing down available options in = exchange for simplicity


On May 22, = 2012, at 9:50 AM, <Axel.Nennker@telekom.de> = wrote:

+1
 
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org= ] On Behalf Of Mike = Jones
Sent: Tuesday, May 22, 2012 7:50 = AM
To: Jim = Schaad; 'Manger, James H'; jose@ietf.org
Subject: Re: [jose] Disscussion = Issue - Algorithm Parameters
 
As background on the current = spec design, both JSMS and the JWS family of specs independently made a = conscious design choice to specify a small, limited set of cryptographic = algorithms and algorithm combinations to simplify implementations and = increase interoperability.  Quoting from the introduction to = JSMS (with my = emphasis):
 
   Many applications require the ability to send = cryptographically
   secured = (encrypted, digitally signed, etc.) messages.  While the = IETF
   has defined a number of formats for = such messages, those = formats are
   widely viewed = as being excessively complicated for the demands of = Web
   applications, which = typically only need the ability to secure = simple
   messages.  = ...
 
   This = document describes a new cryptographic message = format,
   JavaScript Message = Security (JSMS) intended to meet the need of the
   Web environment.  While JSMS is modeled = on existing formats --
   principally CMS = [RFC5652] -- it uses JavaScript Object Notation
   (JSON) rather than ASN.1/BER/DER, making it = far easier for Web
   applications to = handle.  In = the interest of simplicity, JSMS also
   omits as many as possible of the CMS = modes (multiple = signatures,
   password-based = encryption).
 
In parallel, the consensus decisions in the design discussions behind the JWE design = included:
    =93we should specify a small set of composite = operations that will meet the needs of common use = cases=94
 
We=92re trying to make simple things simple to facilitate = widespread deployment of strong crypto.  The alternative is XML = ENC, where all parameters and parameter combinations *can* be = specified but with no guarantees that any particular combination, other = than a mandatory-to-implement set, will actually be supported or = interoperable among any particular implementations.
 
I believe that the designers = of both sets of JOSE precursor specs reached the conclusion that simple = specs with a small set of useful, widely implemented, carefully chosen = cryptographic primitives and combinations would be of more practical = value to developers and result in more deployment and interoperability = than a highly general spec that allows for a large combinatorial set of = parameter combinations.
 
If new parameter combinations are needed in practice, they = can easily be specified in the JWA spec or in the registries that it = defines.
 
I hope that understanding this rationale behind the = intentionally limited sets of algorithms specified in both JSMS and JWA = will be useful to the working group.
 
 
-----Original = Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org= ] On Behalf Of Jim Schaad
Sent: Monday, May 21, 2012 8:55 PM
To: = 'Manger, James H'; jose@ietf.org
Subject: Re: [jose] Disscussion Issue = - Algorithm Parameters
 
 
 
> -----Original Message-----
<= div style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; = margin-bottom: 0.0001pt; font-size: 11pt; font-family: Calibri, = sans-serif; ">>
___________________________________________= ____
jose mailing list
jose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jose

= --Apple-Mail=_4CF1105B-3E31-4E2D-990D-F464614C5E23-- From ve7jtb@ve7jtb.com Tue May 22 10:48: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 81B4921F8606 for ; Tue, 22 May 2012 10:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4BK8jY67Mt4 for ; Tue, 22 May 2012 10:48:33 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6E67221F861B for ; Tue, 22 May 2012 10:48:33 -0700 (PDT) Received: by qabj40 with SMTP id j40so3323394qab.15 for ; Tue, 22 May 2012 10:48:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=8JlYm1cP87/xLh7Vn4OTFFs42WiFoSzW042BaicaLtk=; b=FSyp8Lt2hPsdEjhexl39EsN+n7sLLHzBkeVdy8183HXbh2Zqm6bbtNJiuWCK2iyiqy wK0dDrC2oI5fVIGWzqCYYUmbrTINGU85cg955BjGRPpvwSrPVQUk5k4B/mJviX7ANJEE Z+4VsrY3v2Mq2orJAGdad0kU8r+9RDPmAbxmmJQhQ206+3MCFPkjFZxPP67QfkdCawR9 IJNFANdeV0r/eQLrjoRBLuc7qqy/xr5MAVnLDPIf/RsCSAE28I75+KrQolljwl4XZU8n 6Puv8EsOhOqcf4QDEy/xHSaqKRpCjhnaQl3Ml0KREl8VF5SiyFdgWExsdrID5dAmByZz dbcw== Received: by 10.224.205.8 with SMTP id fo8mr477875qab.78.1337708912819; Tue, 22 May 2012 10:48:32 -0700 (PDT) Received: from [192.168.0.100] (md82436d0.tmodns.net. [208.54.36.216]) by mx.google.com with ESMTPS id ch15sm46671522qab.18.2012.05.22.10.48.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 May 2012 10:48:31 -0700 (PDT) References: <026e01cd37a4$e406d670$ac148350$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F2FE746C@WSMSG3153V.srv.dir.telstra.com> <028001cd37ce$a6eaaa80$f4bfff80$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436651227A@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436651227A@TK5EX14MBXC284.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-D57401A1-3EAA-4F84-812A-815994577EFB; protocol="application/pkcs7-signature" Message-Id: X-Mailer: iPhone Mail (9B206) From: John Bradley Date: Tue, 22 May 2012 13:48:25 -0400 To: Mike Jones X-Gm-Message-State: ALoCoQkB/ht5JigCsFGPVemrkW2wAW42cno1GzyJeOX4YzF0h2nUfwdZQFB5mmUPBmRjQM5FEu0O Cc: Jim Schaad , "Manger, James H" , "jose@ietf.org" Subject: Re: [jose] Disscussion Issue - Algorithm Parameters 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, 22 May 2012 17:48:35 -0000 --Apple-Mail-D57401A1-3EAA-4F84-812A-815994577EFB Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-3C5EB3AC-E357-49E1-9FCF-A39CF0B39075 --Apple-Mail-3C5EB3AC-E357-49E1-9FCF-A39CF0B39075 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The default set needs to be kept simple.=20 They do need all the optional parameters nails down. That should no change t= he default alg names.=20 Defining extension composite algorithms is fine with whatever names.=20 Keep the core ones simple so they work.=20 John B.=20 Sent from my iPhone On 2012-05-22, at 1:49 AM, Mike Jones wrote: > As background on the current spec design, both JSMS and the JWS family of s= pecs independently made a conscious design choice to specify a small, limite= d set of cryptographic algorithms and algorithm combinations to simplify imp= lementations and increase interoperability. Quoting from the introduction t= o JSMS (with my emphasis): > =20 > Many applications require the ability to send cryptographically > secured (encrypted, digitally signed, etc.) messages. While the IETF > has defined a number of formats for such messages, those formats are > widely viewed as being excessively complicated for the demands of Web > applications, which typically only need the ability to secure simple > messages. ... > =20 > This document describes a new cryptographic message format, > JavaScript Message Security (JSMS) intended to meet the need of the > Web environment. While JSMS is modeled on existing formats -- > principally CMS [RFC5652] -- it uses JavaScript Object Notation > (JSON) rather than ASN.1/BER/DER, making it far easier for Web > applications to handle. In the interest of simplicity, JSMS also > omits as many as possible of the CMS modes (multiple signatures, > password-based encryption). > =20 > In parallel, the consensus decisions in the design discussions behind the J= WE design included: > =E2=80=9Cwe should specify a small set of composite operations that wi= ll meet the needs of common use cases=E2=80=9D > =20 > We=E2=80=99re trying to make simple things simple to facilitate widespread= deployment of strong crypto. The alternative is XML ENC, where all paramet= ers and parameter combinations *can* be specified but with no guarantees tha= t any particular combination, other than a mandatory-to-implement set, will a= ctually be supported or interoperable among any particular implementations. > =20 > I believe that the designers of both sets of JOSE precursor specs reached t= he conclusion that simple specs with a small set of useful, widely implement= ed, carefully chosen cryptographic primitives and combinations would be of m= ore practical value to developers and result in more deployment and interope= rability than a highly general spec that allows for a large combinatorial se= t of parameter combinations. > =20 > If new parameter combinations are needed in practice, they can easily be s= pecified in the JWA spec or in the registries that it defines. > =20 > I hope that understanding this rationale behind the intentionally limited s= ets of algorithms specified in both JSMS and JWA will be useful to the worki= ng group. > =20 > Best wishes, > -- Mike > =20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ji= m Schaad > Sent: Monday, May 21, 2012 8:55 PM > To: 'Manger, James H'; jose@ietf.org > Subject: Re: [jose] Disscussion Issue - Algorithm Parameters > =20 > =20 > =20 > > -----Original Message----- > > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > > Sent: Monday, May 21, 2012 8:25 PM > > To: Jim Schaad; jose@ietf.org > > Subject: RE: [jose] Disscussion Issue - Algorithm Parameters > > > > > Should an algorithm be able to specific parameters rather than > > > making them part of the algorithm name string? If so should we > > > change the way that we are doing parameters to allow for this better? > > > > > alg: "RSA-OAEP-mf2-sha256" > > > OR > > > alg: { name:"RSA-OAEP", hash: "SHA-256", mgf: "mgf1" } > > > > > > Another option is: > > "alg": "RSA-OAEP" > > "mgf": "MGF1" > > "hash": "SHA-256" > =20 > That is an option that is doable as well. I happen to think that it might= lead to problems down the road. If you have two algorithms in the header, t= hen one must make sure that there is no possibility that the two algorithms w= ill want to use the same field.=20 > =20 > Given that anybody can define a new algorithm, it is not possible to do an= exhaustive search for collisions in the use of field names. It might be be= tter to have them scoped already. > =20 > =20 > > > > I suspect additional parameters in the header (like "mgf" and "hash" > above) > > was the intention. This is why the algorithms spec (in sections 3.6 > > and > 4.11 for > > signature and encryption algorithms) says: "additional reserved header > > parameter names MAY be defined". > > The result is a flat structure for all sorts of parameters: about the > payload > > ("typ"); about JWE processing ("enc", "int"); about a specific > > algorithm ("mgf", "hash") etc. > > A flat structure will cause headaches at some point (cf trying to > > separate transport and content details from HTTP's flat header > > structure), but it > is > > simpler to start with. > > I suggest we stick with a flat structure for JOSE. > > > > > > > > > As an example of this, the RSA-OAEP algorithm needs to specify two > > > parameters: The mask function and a hash function. > > > > For RSA-OAEP specifically, I suggest: > > * picking one hash algorithm (SHA-256) and including it in the name > > "RSA- OAEP256" > > * hardwiring the mask-generation function (to be MGF1 with the same > > hash > > algorithm) (so no "mgf" parameter is needed) > > * hardwiring the label to be empty. > > > > The resulting spec text could be: > > =3D=3D=3D=3D=3D > > 4.5 "RSA-OAEP256" > > > > The "RSA-OAEP256" key encryption algorithm is RSA encryption with > > Optimal Asymmetric Encryption Padding (OAEP) using SHA-256. > > The algorithm is specified in PKCS#1 [RFC 3447], where it is > > called RSAES-OAEP-ENCRYPT. > > > > The hash function is SHA-256 [FIPS 180-4]. > > > > The mask generation function is MGF1 [RFC 3447], using SHA-256 as > > the hash function. > > > > The label is the empty string. > > =3D=3D=3D=3D=3D > > > > -- > > James Manger > =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-3C5EB3AC-E357-49E1-9FCF-A39CF0B39075 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
The default set needs to b= e kept simple. 

They do need all the optional p= arameters nails down.  That should no change the default alg names.&nbs= p;

Defining extension composite algorithms is fine w= ith whatever names. 

Keep the core ones simple= so they work. 

John B. 

Sent from= my iPhone

On 2012-05-22, at 1:49 AM, Mike Jones <Michael.Jones@microsoft.com> wro= te:

=

As background on the current spec design, both JSM= S and the JWS family of specs independently made a conscious design choice t= o specify a small, limited set of cryptographic algorithms and algorithm com= binations to simplify implementations and increase interoperability.  Quoting from the introduction to JSMS (with my emphasis):

 

   Many applications require the ability= to send cryptographically

   secured (encrypted, digitally signed,= etc.) messages.  While the IETF

   has defined a number of formats for s= uch messages, those formats are

   widely viewed as being excessively= complicated for the demands of Web

   applications, which typically only= need the ability to secure simple

   messages.  ...=

 

   This document describes a new cryptog= raphic message format,

   JavaScript Message Security (JSMS) in= tended to meet the need of the

   Web environment.  While JSMS is m= odeled on existing formats --

   principally CMS [RFC5652] -- it uses J= avaScript Object Notation

   (JSON) rather than ASN.1/BER/DER, mak= ing it far easier for Web

   applications to handle.  In t= he interest of simplicity, JSMS also

   omits as many as possible of the C= MS modes (multiple signatures,

   password-based encryption).

 

In parallel, the consensus decisions in the design discussions behind the JWE design included:

    =E2=80=9Cwe should specify a small set of composite operations that will mee= t the needs of common use cases=E2=80=9D

 

We=E2=80=99re trying to make simple things simple t= o facilitate widespread deployment of strong crypto.  The alternative i= s XML ENC, where all parameters and parameter combinations *can* be s= pecified but with no guarantees that any particular combination, other than a mandatory-to-implement set, will actually be supp= orted or interoperable among any particular implementations.

 

I believe that the designers of both sets of JOSE p= recursor specs reached the conclusion that simple specs with a small set of u= seful, widely implemented, carefully chosen cryptographic primitives and com= binations would be of more practical value to developers and result in more deployment and interoperability than= a highly general spec that allows for a large combinatorial set of paramete= r combinations.

 

If new parameter combinations are needed in practi= ce, they can easily be specified in the JWA spec or in the registries that i= t defines.

 

I hope that understanding this rationale behind th= e intentionally limited sets of algorithms specified in both JSMS and JWA wi= ll be useful to the working group.

 

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

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

 

-----Original Message-----
From: jose-bounces@ietf.org [ma= ilto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Monday, May 21, 2012 8:55 PM
To: 'Manger, James H'; jose@ietf.org Subject: Re: [jose] Disscussion Issue - Algorithm Parameters

 

 

 

> -----Original Message-----

> From: Manger, James H [mailto:James.H.Manger= @team.telstra.com]

> Sent: Monday, May 21, 2012 8:25 PM=

> To: Jim Schaad; jose@ietf.org

> Subject: RE: [jose] Disscussion Issue - Algor= ithm Parameters

>

> > Should an algorithm be able to specific p= arameters rather than

> > making them part of the algorithm name s= tring?  If so should we

> > change the way that we are doing paramet= ers to allow for this better?

>

> > alg: "RSA-OAEP-mf2-sha256"

> > OR

> > alg: { name:"RSA-OAEP", hash: "SHA-256",= mgf: "mgf1" }

>

>

> Another option is:

>   "alg": "RSA-OAEP"

>   "mgf": "MGF1"

>   "hash": "SHA-256"

 

That is an option that is doable as well.  I h= appen to think that it might lead to problems down the road.  If you ha= ve two algorithms in the header, then one must make sure that there is no po= ssibility that the two algorithms will want to use the same field. 

 

Given that anybody can define a new algorithm, it i= s not possible to do an exhaustive search for collisions in the use of field= names.  It might be better to have them scoped already.

=

 

 

>

> I suspect additional parameters in the header= (like "mgf" and "hash"

above)

> was the intention. This is why the algorithms= spec (in sections 3.6

> and

4.11 for

> signature and encryption algorithms) says: "a= dditional reserved header

> parameter names MAY be defined".

> The result is a flat structure for all sorts o= f parameters: about the

payload

> ("typ"); about JWE processing ("enc", "int");= about a specific

> algorithm ("mgf", "hash") etc.

=

> A flat structure will cause headaches at some= point (cf trying to

> separate transport and content details from H= TTP's flat header

> structure), but it

is

> simpler to start with.

> I suggest we stick with a flat structure for J= OSE.

>

>

>

> > As an example of this, the RSA-OAEP algo= rithm needs to specify two

> > parameters:  The mask function and a= hash function.

>

> For RSA-OAEP specifically, I suggest:

> * picking one hash algorithm (SHA-256) and in= cluding it in the name

> "RSA- OAEP256"

> * hardwiring the mask-generation function (to= be MGF1 with the same

> hash

> algorithm) (so no "mgf" parameter is needed)<= o:p>

> * hardwiring the label to be empty.

>

> The resulting spec text could be:<= /p>

> =3D=3D=3D=3D=3D

> 4.5 "RSA-OAEP256"

>

>   The "RSA-OAEP256" key encryption a= lgorithm is RSA encryption with

>   Optimal Asymmetric Encryption Pad= ding (OAEP) using SHA-256.

>   The algorithm is specified in PKC= S#1 [RFC 3447], where it is

>   called RSAES-OAEP-ENCRYPT.

>

>   The hash function is SHA-256 [FIP= S 180-4].

>

>   The mask generation function is M= GF1 [RFC 3447], using SHA-256 as

>   the hash function.

=

>

>   The label is the empty string.

> =3D=3D=3D=3D=3D

>

> --

> 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
= --Apple-Mail-3C5EB3AC-E357-49E1-9FCF-A39CF0B39075-- --Apple-Mail-D57401A1-3EAA-4F84-812A-815994577EFB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVvjCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMIIHyTCCBbGgAwIBAgIBATANBgkqhkiG9w0B AQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM2WhcNMzYwOTE3MTk0NjM2WjB9MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDBiNsJvGxGfHiflXu1M5DycmLW wTYgIiRezul38kMKogZkpMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v/uqwQVlntsQGfQqedIXW eUyAN3rfOQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9ujPW3U3eCztKS5/CJi/6 tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6RtYTKqi5pquDSR3l8u/d 5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNiHzvEvqBTViVsUQn3qqvKv3b9bZvz ndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMMAv+Z6+hsTXBbKWWc3apdzK8BMewM69KN6Oqce+Zu 9ydmDBpI125C4z/eIT574Q1w+2OqqGwaVLRcJXrJosmLFqa7LH4XXgVNWG4SHQHuEhANxjJ/GP/8 9PrNbpHoNkm+Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN0nZPV/+Qt+OR0t3vwmC3 Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOzEmDyei+B26Nu/yYwl/WL 3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwIDAQABo4ICUjCCAk4wDAYDVR0T BAUwAwEB/zALBgNVHQ8EBAMCAa4wHQYDVR0OBBYEFE4L7xqkQFulF2mHMMo0aEPQQa7yMGQGA1Ud HwRdMFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMIIBXQYDVR0gBIIBVDCCAVAw ggFMBgsrBgEEAYG1NwEBATCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJt ZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3RhcnRDb20p IEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBM aW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGlj eSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZI AYb4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVlIFNTTCBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAFmyZ9GYMNPXQhV59CuzaEE44HF7fpiUF S5Eyweg78T3dRAlbB0mKKctmArexmvclmAk8jhvh3TaHK0u7aNM5Zj2gJsfyOZEdUauCe37Vzlrk 4gNXcGmXCPleWKYK34wGmkUWFjgKXlf2Ysd6AgXmvB618p70qSmD+LIU424oh0TDkBreOKk8rENN ZEXO3SipXPJzewT4F+irsfMuXGRuczE6Eri8sxHkfY+BUZo7jYn0TZNmezwD7dOaHZrzZVD1oNB1 ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3fsNrarnDy0RLrHiQi+fHLB5LEUTINFInzQpd n4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZEoalHmdkrQYuL6lwhceWD3yJZfWOQ1QOq92l gDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+PwqyvqCUqDvr0tVk+vBtfAii6w0TiYiBKGHLHVK t+V9E9e4DGTANtLJL4YSjCMJwRuCO3NJo2pXh5Tl1njFmUNj403gdy3hZZlyaQQaRwnmDwFWJPsf vw55qVguucQJAX6Vum0ABj6y6koQOdjQK/W/7HW/lwLFCRsI3FU34oH7N4RDYiDK51ZLZer+bMEk kyShNOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14xggNsMIIDaAIBATCBkzCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgIeXDAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA1MjIxNzQ4MzBaMCMGCSqGSIb3DQEJBDEWBBR0GVS+ MeReEBIJDPzLSBNWFlvu7DCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDANBgkqhkiG9w0BAQEFAASCAQAIrndVRRnrQm1HkDyP5Q9B0HL97KY0DUg5KFgU Flnvo6puX6RMpP6G3Yyvzty/Gtb3V1eB7UBQ4mixjz6RwRrvgKY8w3nKc4AkfYQgC1av4/ow2rwl sQWT/GoLqBrmT8pnpP6Rpljz2DuDrbCumsZxAKnPk9qHKb7bUM8b0UuN4kT9y5hS2IG4VRIkURCY OGXmje9cY83vAIEacmAhvtklfxvGWXjaEyruhhxM3k0vzfYB9djexa1hWr3FZw/TTt/Th15OiEwd YVuwwpLtfkZSPo1FVq8iIMEP8Dy3jQyM1KgCHXRslYMtu4Klx+NOePHxZZCq0tffr6qplvVsHg/u AAAAAAAA --Apple-Mail-D57401A1-3EAA-4F84-812A-815994577EFB-- From sakimura@gmail.com Tue May 22 10:52: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 F420321F85AA for ; Tue, 22 May 2012 10:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPe2UBhmFxTa for ; Tue, 22 May 2012 10:52:13 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B830721F85C3 for ; Tue, 22 May 2012 10:52:12 -0700 (PDT) Received: by bkty8 with SMTP id y8so6304687bkt.31 for ; Tue, 22 May 2012 10:52:11 -0700 (PDT) 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=pIuFVBOa/DbO+g9xtdm1R+TJPqGnu8Zr6UrqC7cecIc=; b=eLkIinNDav64QYwhpQe1m4UOxiAWoMKghiH70O7l+7pWYo0PBd4M+hOJUt8okXZ2EJ VFG9GxTFVR/zpTTrkjlt4OqUM3Vw+mirXMRiZ4DRP9F1ZyygAb+nUlnpYtmr/8gRAMKe 0RBz6yoBHLxexeMvVOjz8np6O89PR+KKJJXXhMmzkPAEQy/4K1YzwbAY5d3+tLJEP5MA 76OPVbg1rY2TdEcPHzWa2lJz2yng6Q2APfR9U2PmOTAejHWW309apFgbgWmRIOYb3PuL VVbVPw7sBuAHZ1HcBJ5oqfN1KlL0vN0fJ414ygFYQgHvoKNaMpEOgqYaJJze4vFwMH8+ XGyQ== Received: by 10.205.133.13 with SMTP id hw13mr10008142bkc.30.1337709131753; Tue, 22 May 2012 10:52:11 -0700 (PDT) References: <026e01cd37a4$e406d670$ac148350$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F2FE746C@WSMSG3153V.srv.dir.telstra.com> <028001cd37ce$a6eaaa80$f4bfff80$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436651227A@TK5EX14MBXC284.redmond.corp.microsoft.com> <5F239486-031A-47FB-A508-83ACFD76EEFD@salesforce.com> <81423F8B-71B7-4F29-9425-C9CB47CA8F44@gmail.com> From: Nat Sakimura In-Reply-To: <81423F8B-71B7-4F29-9425-C9CB47CA8F44@gmail.com> Mime-Version: 1.0 (1.0) Date: Wed, 23 May 2012 02:52:09 +0900 Message-ID: <-7669406502197121492@unknownmsgid> To: Dick Hardt Content-Type: multipart/alternative; boundary=000e0ce0d6729c6ac504c0a3ad54 Cc: Axel Nennker , "ietf@augustcellars.com" , Mike Jones , "jose@ietf.org" , "James.H.Manger@team.telstra.com" , Chuck Mortimore Subject: Re: [jose] Disscussion Issue - Algorithm Parameters 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, 22 May 2012 17:52:15 -0000 --000e0ce0d6729c6ac504c0a3ad54 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1 Less choice is better for the core. =3Dnat via iPhone On 2012/05/23, at 2:48, Dick Hardt wrote: +1 on keeping it simple per the current design of of the algorithm being a single string I have one implementation running and deployed and another being designed and prefer having only a few good crypto choices, but being extensible in case others are needed by having a different string. -- Dick On May 22, 2012, at 9:55 AM, Chuck Mortimore wrote: +1 on editing down available options in exchange for simplicity On May 22, 2012, at 9:50 AM, wrote: +1 *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf Of *Mike Jones *Sent:* Tuesday, May 22, 2012 7:50 AM *To:* Jim Schaad; 'Manger, James H'; jose@ietf.org *Subject:* Re: [jose] Disscussion Issue - Algorithm Parameters As background on the current spec design, both JSMS and the JWS family of specs independently made a conscious design choice to specify a small, limited set of cryptographic algorithms and algorithm combinations to simplify implementations and increase interoperability. Quoting from the introduction to JSMS (with *my emphasis*): Many applications require the ability to send cryptographically secured (encrypted, digitally signed, etc.) messages. While the IETF has defined a number of formats for such messages, *those formats are* * widely viewed as being excessively complicated for the demands of Web* * applications, which typically only need the ability to secure simple* * messages*. ... This document describes a new cryptographic message format, JavaScript Message Security (JSMS) intended to meet the need of the Web environment. While JSMS is modeled on existing formats -- principally CMS [RFC5652] -- it uses JavaScript Object Notation (JSON) rather than ASN.1/BER/DER, making it far easier for Web applications to handle. *In the interest of simplicity, JSMS also* * omits as many as possible of the CMS modes* (multiple signatures, password-based encryption). In parallel, the consensus decisions in the design discussions behind the JWE design included: =93we should specify a small set of composite operations that will meet the needs of common use cases=94 We=92re trying to make simple things simple to facilitate widespread deployment of strong crypto. The alternative is XML ENC, where all parameters and parameter combinations **can** be specified but with no guarantees that any particular combination, other than a mandatory-to-implement set, will actually be supported or interoperable among any particular implementations. I believe that the designers of both sets of JOSE precursor specs reached the conclusion that simple specs with a small set of useful, widely implemented, carefully chosen cryptographic primitives and combinations would be of more practical value to developers and result in more deployment and interoperability than a highly general spec that allows for a large combinatorial set of parameter combinations. If new parameter combinations are needed in practice, they can easily be specified in the JWA spec or in the registries that it defines. I hope that understanding this rationale behind the intentionally limited sets of algorithms specified in both JSMS and JWA will be useful to the working group. Best wishes, -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Monday, May 21, 2012 8:55 PM To: 'Manger, James H'; jose@ietf.org Subject: Re: [jose] Disscussion Issue - Algorithm Parameters > -----Original Message----- > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > Sent: Monday, May 21, 2012 8:25 PM > To: Jim Schaad; jose@ietf.org > Subject: RE: [jose] Disscussion Issue - Algorithm Parameters > > > Should an algorithm be able to specific parameters rather than > > making them part of the algorithm name string? If so should we > > change the way that we are doing parameters to allow for this better? > > > alg: "RSA-OAEP-mf2-sha256" > > OR > > alg: { name:"RSA-OAEP", hash: "SHA-256", mgf: "mgf1" } > > > Another option is: > "alg": "RSA-OAEP" > "mgf": "MGF1" > "hash": "SHA-256" That is an option that is doable as well. I happen to think that it might lead to problems down the road. If you have two algorithms in the header, then one must make sure that there is no possibility that the two algorithms will want to use the same field. Given that anybody can define a new algorithm, it is not possible to do an exhaustive search for collisions in the use of field names. It might be better to have them scoped already. > > I suspect additional parameters in the header (like "mgf" and "hash" above) > was the intention. This is why the algorithms spec (in sections 3.6 > and 4.11 for > signature and encryption algorithms) says: "additional reserved header > parameter names MAY be defined". > The result is a flat structure for all sorts of parameters: about the payload > ("typ"); about JWE processing ("enc", "int"); about a specific > algorithm ("mgf", "hash") etc. > A flat structure will cause headaches at some point (cf trying to > separate transport and content details from HTTP's flat header > structure), but it is > simpler to start with. > I suggest we stick with a flat structure for JOSE. > > > > > As an example of this, the RSA-OAEP algorithm needs to specify two > > parameters: The mask function and a hash function. > > For RSA-OAEP specifically, I suggest: > * picking one hash algorithm (SHA-256) and including it in the name > "RSA- OAEP256" > * hardwiring the mask-generation function (to be MGF1 with the same > hash > algorithm) (so no "mgf" parameter is needed) > * hardwiring the label to be empty. > > The resulting spec text could be: > =3D=3D=3D=3D=3D > 4.5 "RSA-OAEP256" > > The "RSA-OAEP256" key encryption algorithm is RSA encryption with > Optimal Asymmetric Encryption Padding (OAEP) using SHA-256. > The algorithm is specified in PKCS#1 [RFC 3447], where it is > called RSAES-OAEP-ENCRYPT. > > The hash function is SHA-256 [FIPS 180-4]. > > The mask generation function is MGF1 [RFC 3447], using SHA-256 as > the hash function. > > The label is the empty string. > =3D=3D=3D=3D=3D > > -- > 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 _______________________________________________ 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 --000e0ce0d6729c6ac504c0a3ad54 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
+1=A0

Less choice is better for the core.=A0

=3Dnat via iPhone
=

On 2012/05/23, at 2:48, Dick Hardt <dick.hardt@gmail.com> wrote:

+1 on keeping it simple= per the current design of of the algorithm being a single string

<= /div>
I have one implementation running and deployed and another being = designed and prefer having only a few good crypto choices, but being extens= ible in case others are needed by having a different string.=A0

-- Dick

On May 22, 2012, at 9:5= 5 AM, Chuck Mortimore wrote:

<= blockquote type=3D"cite">
+1 on editing down available options in exchange for simplicity
<= div>

On May 22, 2012, at 9:50 AM, <Axel.Nennker@telekom.de> wrote:

+1
=A0
From:=A0jose-bounces@ietf.org=A0[mailto:jose-bounces@ietf.org]=A0= On Behalf Of=A0M= ike Jones
Sent:=A0Tuesday, May 22= , 2012 7:50 AM
To:=A0Jim Schaad; 'Manger, James H';=A0jose@ietf.org
Subject:=A0Re: [jose] D= isscussion Issue - Algorithm Parameters
=A0
As backgr= ound on the current spec design, both JSMS and the JWS family of specs inde= pendently made a conscious design choice to specify a small, limited set of= cryptographic algorithms and algorithm combinations to simplify implementa= tions and increase interoperability.=A0 Quoting from the=A0in= troduction to JSMS=A0(with= =A0my emphasis):
=A0
=A0=A0 Many applications require the ability to send cryptographically
=A0=A0 secured (e= ncrypted, digitally signed, etc.) messages.=A0 While the IETF
=A0=A0 has defined= a number of formats for such messages,=A0those formats are
=A0=A0 widely v= iewed as being excessively complicated for the demands of Web
=A0=A0 applications, which typically only need the ability to secure sim= ple
= =A0=A0 messages.=A0 ...
=A0
=A0=A0 This document describes a new cryptographic message format,
=A0=A0 JavaScript Mes= sage Security (JSMS) intended to meet the need of the
=A0=A0 Web environ= ment.=A0 While JSMS is modeled on existing formats --
=A0=A0 principally CMS [RFC5652] -- it uses JavaScript Object Notation
=A0=A0 (JSON) rat= her than ASN.1/BER/DER, making it far easier for Web
=A0=A0 application= s to handle.=A0=A0In the in= terest of simplicity, JSMS also
=A0=A0 omits as= many as possible of the CMS modes=A0(multiple signatures,
=A0=A0 password-ba= sed encryption).
=A0
In parall= el, the consensus decisions in the=A0= design discussions behind the JWE=A0design included:
=A0=A0=A0 =93we should specify a small set of composite operations that= will meet the needs of common use cases=94
=A0
We=92re trying to make simple things simple to facilitate widespread deploy= ment of strong crypto.=A0 The alternative is XML ENC, where all parameters = and parameter combinations *can* be specified but with no guarantees= that any particular combination, other than a mandatory-to-implement set, = will actually be supported or interoperable among any particular implementa= tions.
=A0
I believe that the designers of both sets of JOSE precursor specs reached t= he conclusion that simple specs with a small set of useful, widely implemen= ted, carefully chosen cryptographic primitives and combinations would be of= more practical value to developers and result in more deployment and inter= operability than a highly general spec that allows for a large combinatoria= l set of parameter combinations.
=A0
If new parameter combinations are needed in practice, they can easily be sp= ecified in the JWA spec or in the registries that it defines.
=A0
I hope th= at understanding this rationale behind the intentionally limited sets of al= gorithms specified in both JSMS and JWA will be useful to the working group= .
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 Best wishes,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike
=A0
-----Original Message-----
From:= =A0jose-bounces@ietf.org=A0[mailto:jose-= bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Monday, May 21, 2012 8:55 PM
To: 'Manger, James H';=A0jose@ietf.org
Subject:= Re: [jose] Disscussion Issue - Algorithm Parameters
=A0
=A0
=A0
=
> -----Original Message-----
> Sent: Monday,= May 21, 2012 8:25 PM
> To: Jim Schaad;=A0jose@ietf.org
> Subject: RE: = [jose] Disscussion Issue - Algorithm Parameters
>
> >= ; Should an algorithm be able to specific parameters rather than
> > making them part of the algorithm name string?=A0 If so should we=
> > ch= ange the way that we are doing parameters to allow for this better?
>
> > alg: "RSA-OAEP-mf2-sha256"
> > OR
> > alg: { name:"RSA-OAEP", hash: "SHA-256", mgf:= "mgf1" }
>
>
> Another option is:
>=A0=A0 "alg": "RSA-OAEP"
>=A0=A0 "mgf": "MGF1"
>=A0=A0 "hash": "SHA-256&= quot;
=A0
That is an option that is doable as well.=A0 I happen to think that it migh= t lead to problems down the road.=A0 If you have two algorithms in the head= er, then one must make sure that there is no possibility that the two algor= ithms will want to use the same field.=A0
=A0
Given that anybody can define a new algorithm, it is not possible to do an = exhaustive search for collisions in the use of field names.=A0 It might be = better to have them scoped already.
=A0
=A0
=
>
> I s= uspect additional parameters in the header (like "mgf" and "= hash"
above)
> was the intention. This is why the algorithms spec (in sections 3.6
> and
4.11 for
> signature and encryption algorithms) says: "additional reserved h= eader
> pa= rameter names MAY be defined".
> The result is= a flat structure for all sorts of parameters: about the
payload
> = ("typ"); about JWE processing ("enc", "int");= about a specific
> algorithm (&q= uot;mgf", "hash") etc.
> A flat structure will cause headaches at some point (cf trying to
> separate tra= nsport and content details from HTTP's flat header
> structure), b= ut it
is
> simpl= er to start with.
> I suggest we stick with a flat structure for JOSE.
>
>
>
> > As an example of this, the RSA-OAEP algorithm needs to specify tw= o
> > p= arameters:=A0 The mask function and a hash function.
>
> For RSA-OAEP specifically, I suggest:
> * picking one hash algorithm (SHA-256) a= nd including it in the name
> "RSA- OA= EP256"
> * hardwiring the mask-generation function (to be MGF1 with the same
> hash
> algorithm) (s= o no "mgf" parameter is needed)
> * hardwiring the label to be empty.
>
> The resulting spec text could be:
> =3D=3D=3D=3D=3D
> 4.5 "RSA-OAEP256"
>
>=A0=A0 The "RSA-OAEP256" key encryption algorithm is RSA encr= yption with
&= gt;=A0=A0 Optimal Asymmetric Encryption Padding (OAEP) using SHA-256.
>=A0=A0 The alg= orithm is specified in PKCS#1 [RFC 3447], where it is
>=A0=A0 called RSAES-OAEP-ENCRYPT.
>
>=A0=A0 The hash function is SHA-256 [FIPS 180-4].
>
>=A0=A0 The mask generation function is MGF1 [RFC 3447], using SHA-256 a= s
>=A0=A0 = the hash function.
>
>=A0=A0 The label is the empty string.
> =3D=3D=3D=3D=3D
>
_______________________________________________
jose mail= ing list
jose@ietf.org
https://ww= w.ietf.org/mailman/listinfo/jose

_________________________________= ______________
jose mailing list
jos= e@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

<= div>_______________________________________________
j= ose mailing list
jose@ietf= .org
https://www.ie= tf.org/mailman/listinfo/jose
--000e0ce0d6729c6ac504c0a3ad54-- From ejay@mgi1.com Tue May 22 12:10: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 521C821F86C6 for ; Tue, 22 May 2012 12:10:33 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAshyIr1SSiI for ; Tue, 22 May 2012 12:10:31 -0700 (PDT) Received: from nm30-vm0.access.bullet.mail.sp2.yahoo.com (nm30-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.194]) by ietfa.amsl.com (Postfix) with SMTP id 8E17721F86C9 for ; Tue, 22 May 2012 12:10:31 -0700 (PDT) Received: from [98.139.44.105] by nm30.access.bullet.mail.sp2.yahoo.com with NNFMP; 22 May 2012 19:10:28 -0000 Received: from [98.139.44.86] by tm10.access.bullet.mail.sp2.yahoo.com with NNFMP; 22 May 2012 19:10:28 -0000 Received: from [127.0.0.1] by omp1023.access.mail.sp2.yahoo.com with NNFMP; 22 May 2012 19:10:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 683800.14242.bm@omp1023.access.mail.sp2.yahoo.com Received: (qmail 53567 invoked by uid 60001); 22 May 2012 19:10:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1337713828; bh=O0RT4IHdmbkG4ODwXHYpjUFp0vpJziN6+0izMnroGGk=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=me6l79bvYV+FCB2+WaanhrcNZ0S7Y7WUp1mT2SCXA99CflWitxBOLLgypus9tAKyUV5KE1Y4RkTRDTGyKHu9Hpp3NQIdZB5gHy+L7cLpR3mLc+pMlWuWACfiq5fDzu8H6rfdBHLAbNzBH9oR8qT7MoiB4a0Jk7OyIExaZUUq+3g= X-YMail-OSG: XV9y840VM1mC64MQQJJ44RCiya85dVoaW7fW788fhBlwiAV inniCHC0hFYxTuINM_.NJpDDudtbYYc34dX3gBv6JlKsAr.gauCRQpljXI.u uUfZ9OpoJLE.0JxkszMu3CFTKkHnbx5rCOebkRUN095ofHP.LEQJzBa82R._ o2XiG4sC_7LbrewxVrgB7kAieKDGH4Jb42l7nZcOta.w2VUi_li.14WifKZz Qrx4hvHpnp7Ij.Ke4v6NZTYax47wtOoHRkyVBFJw.RIZErugwR6xhV6rDpCa A8jLIk26nozzOSL9_pGULXiVWq42aWMUKBlzoFHfLiPcl1JnmL9QyxKLSfTl tuiQXYm68rBf0x0jOhGEfFQcoJ6bM1WkpLjJzW1OvoonWPObGY_trJBRZBxn yFsDfXXGhoB60XZIwJB6pTnAP3usg_T34f2ElOAVM4zB0DiNznsWeBds_y1Y H2raWrnAurtjCqtSPeQNgbZrDqvFU2pURF5xPdKsjn.v7zob0PCz9EdLo7mq XJNSOn_bWUXqnslVFPqt6c7wIwy.x1wsdlyGMaw-- Received: from [64.140.94.67] by web181309.mail.ne1.yahoo.com via HTTP; Tue, 22 May 2012 12:10:27 PDT X-RocketYMMF: edmundjay@sbcglobal.net X-Mailer: YahooMailRC/708 YahooMailWebService/0.8.118.349524 References: <026e01cd37a4$e406d670$ac148350$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F2FE746C@WSMSG3153V.srv.dir.telstra.com> <028001cd37ce$a6eaaa80$f4bfff80$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436651227A@TK5EX14MBXC284.redmond.corp.microsoft.com> Message-ID: <1337713827.53420.YahooMailRC@web181309.mail.ne1.yahoo.com> Date: Tue, 22 May 2012 12:10:27 -0700 (PDT) From: Edmund Jay To: Mike Jones , Jim Schaad , "Manger, James H" , "jose@ietf.org" In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436651227A@TK5EX14MBXC284.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-939539953-1914324992-1337713827=:53420" Subject: Re: [jose] Disscussion Issue - Algorithm Parameters 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, 22 May 2012 19:20:05 -0000 ---939539953-1914324992-1337713827=:53420 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 to keep things simple=0A=0A=0A=0A=0A________________________________=0AF= rom: Mike Jones =0ATo: Jim Schaad ; "Manger, James H" =0A; "jose= @ietf.org" =0ASent: Mon, May 21, 2012 10:50:06 PM=0ASubject:= Re: [jose] Disscussion Issue - Algorithm Parameters=0A=0A =0AAs background= on the current spec design, both JSMS and the JWS family of specs =0Aindep= endently made a conscious design choice to specify a small, limited set of = =0Acryptographic algorithms and algorithm combinations to simplify implemen= tations =0Aand increase interoperability. Quoting from the introduction t= o JSMS (with my =0Aemphasis):=0A =0A Many applications require the abilit= y to send cryptographically=0A secured (encrypted, digitally signed, etc.= ) messages. While the IETF=0A has defined a number of formats for such m= essages, those formats are=0A widely viewed as being excessively complica= ted for the demands of Web=0A applications, which typically only need the= ability to secure simple=0A messages. ...=0A =0A This document descri= bes a new cryptographic message format,=0A JavaScript Message Security (J= SMS) intended to meet the need of the=0A Web environment. While JSMS is = modeled on existing formats --=0A principally CMS [RFC5652] -- it uses Ja= vaScript Object Notation=0A (JSON) rather than ASN.1/BER/DER, making it f= ar easier for Web=0A applications to handle. In the interest of simplici= ty, JSMS also=0A omits as many as possible of the CMS modes (multiple sig= natures,=0A password-based encryption).=0A =0AIn parallel, the consensus = decisions in the design discussions behind the JWE =0Adesign included:=0A = =E2=80=9Cwe should specify a small set of composite operations that will = meet the =0Aneeds of common use cases=E2=80=9D=0A =0AWe=E2=80=99re trying t= o make simple things simple to facilitate widespread deployment of =0Astron= g crypto. The alternative is XML ENC, where all parameters and parameter = =0Acombinations *can* be specified but with no guarantees that any particul= ar =0Acombination, other than a mandatory-to-implement set, will actually = be supported =0Aor interoperable among any particular implementations.=0A = =0AI believe that the designers of both sets of JOSE precursor specs reache= d the =0Aconclusion that simple specs with a small set of useful, widely im= plemented, =0Acarefully chosen cryptographic primitives and combinations wo= uld be of more =0Apractical value to developers and result in more deploym= ent and =0Ainteroperability than a highly general spec that allows for a la= rge =0Acombinatorial set of parameter combinations.=0A =0AIf new parameter = combinations are needed in practice, they can easily be =0Aspecified in the= JWA spec or in the registries that it defines.=0A =0AI hope that understan= ding this rationale behind the intentionally limited sets =0Aof algorithms = specified in both JSMS and JWA will be useful to the working =0Agroup.=0A = =0A Best wishes,= =0A -- Mike=0A = =0A-----Original Message-----=0AFrom: jose-bounces@ietf.org [mailto:jose-bo= unces@ietf.org] On Behalf Of Jim =0ASchaad=0ASent: Monday, May 21, 2012 8:5= 5 PM=0ATo: 'Manger, James H'; jose@ietf.org=0ASubject: Re: [jose] Disscussi= on Issue - Algorithm Parameters=0A =0A =0A =0A> -----Original Message-----= =0A> From: Manger, James H [mailto:James.H.Manger@team.telstra.com]=0A> Sen= t: Monday, May 21, 2012 8:25 PM=0A> To: Jim Schaad; jose@ietf.org=0A> Subje= ct: RE: [jose] Disscussion Issue - Algorithm Parameters=0A> =0A> > Should a= n algorithm be able to specific parameters rather than =0A> > making them p= art of the algorithm name string? If so should we =0A> > change the way th= at we are doing parameters to allow for this better?=0A> =0A> > alg: "RSA-O= AEP-mf2-sha256"=0A> > OR=0A> > alg: { name:"RSA-OAEP", hash: "SHA-256", mgf= : "mgf1" }=0A> =0A> =0A> Another option is:=0A> "alg": "RSA-OAEP"=0A> "= mgf": "MGF1"=0A> "hash": "SHA-256"=0A =0AThat is an option that is doable= as well. I happen to think that it might lead =0Ato problems down the roa= d. If you have two algorithms in the header, then one =0Amust make sure th= at there is no possibility that the two algorithms will want =0Ato use the= same field. =0A=0A =0AGiven that anybody can define a new algorithm, it i= s not possible to do an =0Aexhaustive search for collisions in the use of f= ield names. It might be better =0Ato have them scoped already.=0A =0A =0A>= =0A> I suspect additional parameters in the header (like "mgf" and "hash"= =0Aabove)=0A> was the intention. This is why the algorithms spec (in sectio= ns 3.6 =0A> and=0A4.11 for=0A> signature and encryption algorithms) says: "= additional reserved header =0A> parameter names MAY be defined".=0A> The re= sult is a flat structure for all sorts of parameters: about the=0Apayload= =0A> ("typ"); about JWE processing ("enc", "int"); about a specific =0A> al= gorithm ("mgf", "hash") etc.=0A> A flat structure will cause headaches at s= ome point (cf trying to =0A> separate transport and content details from HT= TP's flat header =0A> structure), but it=0Ais=0A> simpler to start with.=0A= > I suggest we stick with a flat structure for JOSE.=0A> =0A> =0A> =0A> > A= s an example of this, the RSA-OAEP algorithm needs to specify two=0A> > par= ameters: The mask function and a hash function.=0A> =0A> For RSA-OAEP spec= ifically, I suggest:=0A> * picking one hash algorithm (SHA-256) and includi= ng it in the name =0A> "RSA- OAEP256"=0A> * hardwiring the mask-generation = function (to be MGF1 with the same =0A> hash=0A> algorithm) (so no "mgf" pa= rameter is needed)=0A> * hardwiring the label to be empty.=0A> =0A> The res= ulting spec text could be:=0A> =3D=3D=3D=3D=3D=0A> 4.5 "RSA-OAEP256"=0A> = =0A> The "RSA-OAEP256" key encryption algorithm is RSA encryption with=0A= > Optimal Asymmetric Encryption Padding (OAEP) using SHA-256.=0A> The a= lgorithm is specified in PKCS#1 [RFC 3447], where it is=0A> called RSAES-= OAEP-ENCRYPT.=0A> =0A> The hash function is SHA-256 [FIPS 180-4].=0A> =0A= > The mask generation function is MGF1 [RFC 3447], using SHA-256 as=0A> = the hash function.=0A> =0A> The label is the empty string.=0A> =3D=3D=3D= =3D=3D=0A> =0A> --=0A> James Manger=0A =0A_________________________________= ______________=0Ajose mailing list=0Ajose@ietf.org=0Ahttps://www.ietf.org/m= ailman/listinfo/jose ---939539953-1914324992-1337713827=:53420 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1 to keep things simple


From:= Mike Jones <Michael.Jones@microsoft.com>
To: Jim Schaad <ietf@augustcellars.com>;= "Manger, James H" <James.H.Manger@team.telstra.com>; "jose@ietf.org"= <jose@ietf.org>
Sent: Mon, May 21, 2012 10:50:06 PM
= =0A=0A=0A
=0A

As backgr= ound on the current spec design, both JSMS and the JWS family of specs inde= pendently made a conscious design choice to specify a small, limited set of= cryptographic algorithms and algorithm combinations to simplify implementa= tions=0A and increase interoperability.  Quoting from the =0Aintroduction to JSMS (with my emphasis):<= /p> =0A

 

=0A

&= nbsp;  Many applications require the ability to send cryptographically=

=0A

   secured (encrypted, digitall= y signed, etc.) messages.  While the IETF

=0A

   has defined a number of formats for such messages, =0A= those formats are

=0A

   wide= ly viewed as being excessively complicated for the demands of Web

= =0A

   applications, which typically = only need the ability to secure simple

=0A

   messages.  ...

=0A

=  

=0A

   This document describe= s a new cryptographic message format,

=0A

&nbs= p;  JavaScript Message Security (JSMS) intended to meet the need of th= e

=0A

   Web environment.  Whil= e JSMS is modeled on existing formats --

=0A

&= nbsp;  principally CMS [RFC5652] -- it uses JavaScript Object Notation=

=0A

   (JSON) rather than ASN.1/BER= /DER, making it far easier for Web

=0A

 &= nbsp; applications to handle.  In the interest of simplicity, JSMS = also

=0A

   omits as many as = possible of the CMS modes (multiple signatures,

=0A

   password-based encryption).

=0A

 

=0A

In parallel, the consensu= s decisions in the =0Adesign discussions behind the JWE design inc= luded:

=0A

    =E2=80=9Cwe should specify a small set of c= omposite operations that will meet the needs of common use cases=E2= =80=9D

=0A

 

=0A

We=E2=80=99re trying to make simple things simple to facilitate wides= pread deployment of strong crypto.  The alternative is XML ENC, where = all parameters and parameter combinations *can* be specified but wit= h no guarantees that any particular=0A combination, other than a mandatory-= to-implement set, will actually be supported or interoperable among any par= ticular implementations.

=0A

 

=0AI believe that the designers of both sets of JOSE p= recursor specs reached the conclusion that simple specs with a small set of= useful, widely implemented, carefully chosen cryptographic primitives and = combinations would be of more practical=0A value to developers and result i= n more deployment and interoperability than a highly general spec that allo= ws for a large combinatorial set of parameter combinations.

=0A

 

=0A

If new parameter= combinations are needed in practice, they can easily be specified in the J= WA spec or in the registries that it defines.

=0A

 

=0A

I hope that understanding this= rationale behind the intentionally limited sets of algorithms specified in= both JSMS and JWA will be useful to the working group.

=0A

 

=0A

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

=0A

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

= =0A

 

=0A

-----= Original Message-----
=0AFrom: jose-bounces@ietf.org [mailto:jose-bounce= s@ietf.org] On Behalf Of Jim Schaad
=0ASent: Monday, May 21, 2012 8:55 P= M
=0ATo: 'Manger, James H'; jose@ietf.org
=0ASubject: Re: [jose] Diss= cussion Issue - Algorithm Parameters

=0A

 = ;

=0A

 

=0A

 

=0A

> -----Original Message----- =0A

> From: Manger, James H =0A[mailto:James.H.Manger@team.= telstra.com]

=0A

> Sent: Monday,= May 21, 2012 8:25 PM

=0A

> To: Jim Schaad;= jose@ietf.org

=0A

> Subje= ct: RE: [jose] Disscussion Issue - Algorithm Parameters

=0A

>

=0A

> > Should an al= gorithm be able to specific parameters rather than=0A

=0A

> > making them part of the algorithm name string?  = If so should we=0A

=0A

> > change the wa= y that we are doing parameters to allow for this better?

=0A

>

=0A

> > alg: "RSA-O= AEP-mf2-sha256"

=0A

> > OR

=0A

> > alg: { name:"RSA-OAEP", hash: "SHA-256", mgf:= "mgf1" }

=0A

>

=0A

>

=0A

> Another option is:

= =0A

>   "alg": "RSA-OAEP"

=0A

>   "mgf": "MGF1"

=0A

>   "hash": "SHA-256"

=0A

 

=0A

That is an option that is doab= le as well.  I happen to think that it might lead to problems down the= road.  If you have two algorithms in the header, then one must make s= ure that there is no possibility that the two algorithms will want=0A to us= e the same field. 

=0A

 

=0AGiven that anybody can define a new algorithm, it i= s not possible to do an exhaustive search for collisions in the use of fiel= d names.  It might be better to have them scoped already.

=0A

 

=0A

 

= =0A

>

=0A

> I = suspect additional parameters in the header (like "mgf" and "hash"

=0A<= p class=3D"MsoPlainText">above)

=0A

> was t= he intention. This is why the algorithms spec (in sections 3.6=0A

=0A> and

=0A

4.11 for<= /p> =0A

> signature and encryption algorithms) = says: "additional reserved header=0A

=0A

> = parameter names MAY be defined".

=0A

> The = result is a flat structure for all sorts of parameters: about the

=0Apayload

=0A

> ("typ= "); about JWE processing ("enc", "int"); about a specific=0A

=0A

> algorithm ("mgf", "hash") etc.

=0A

> A flat structure will cause headaches at some point (cf t= rying to=0A

=0A

> separate transport and co= ntent details from HTTP's flat header=0A

=0A

&= gt; structure), but it

=0A

is

=0A

> simpler to start with.

=0A

> I suggest we stick with a flat structure for JOSE.

=0A

>

=0A

>

=0A

>

=0A

> > As an= example of this, the RSA-OAEP algorithm needs to specify two

=0A

> > parameters:  The mask function and a has= h function.

=0A

>

=0A

> For RSA-OAEP specifically, I suggest:

=0A

> * picking one hash algorithm (SHA-256) and including it in t= he name=0A

=0A

> "RSA- OAEP256"

=0A

> * hardwiring the mask-generation function (to be= MGF1 with the same=0A

=0A

> hash

=0A> algorithm) (so no "mgf" parameter is needed) =0A

> * hardwiring the label to be empty. =0A

>

=0A

> = The resulting spec text could be:

=0A

> =3D= =3D=3D=3D=3D

=0A

> 4.5 "RSA-OAEP256"

= =0A

>

=0A

>&nb= sp;  The "RSA-OAEP256" key encryption algorithm is RSA encryption with=

=0A

>   Optimal Asymmetric Encry= ption Padding (OAEP) using SHA-256.

=0A

>&n= bsp;  The algorithm is specified in PKCS#1 [RFC 3447], where it is

= =0A

>   called RSAES-OAEP-ENCRYPT. =0A

>

=0A

>=    The hash function is SHA-256 [FIPS 180-4].

=0A

>

=0A

>   The m= ask generation function is MGF1 [RFC 3447], using SHA-256 as

=0A

>   the hash function.

=0A

>

=0A

>   The la= bel is the empty string.

=0A

> =3D=3D=3D=3D= =3D

=0A

>

=0A

> --

=0A

> James Manger

=0A

 

=0A

________________= _______________________________

=0A

jose maili= ng list

=0A

jose@ietf.org

= =0A

https://www.ietf.org/mailman/listinfo/jose<= /a>

=0A

 

=0A
=0A=0A=0A
=0A=0A=0A=0A
---939539953-1914324992-1337713827=:53420-- From ejay@mgi1.com Tue May 22 13:18:25 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7FB21F8609 for ; Tue, 22 May 2012 13:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnNxjVbukd2R for ; Tue, 22 May 2012 13:18:24 -0700 (PDT) Received: from nm15-vm1.bullet.mail.ne1.yahoo.com (nm15-vm1.bullet.mail.ne1.yahoo.com [98.138.90.254]) by ietfa.amsl.com (Postfix) with SMTP id 5671821F84B6 for ; Tue, 22 May 2012 13:18:24 -0700 (PDT) Received: from [98.138.90.54] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 22 May 2012 20:18:18 -0000 Received: from [68.142.200.227] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 22 May 2012 20:18:17 -0000 Received: from [66.94.237.116] by t8.bullet.mud.yahoo.com with NNFMP; 22 May 2012 20:18:17 -0000 Received: from [127.0.0.1] by omp1021.access.mail.mud.yahoo.com with NNFMP; 22 May 2012 20:18:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 756598.52968.bm@omp1021.access.mail.mud.yahoo.com Received: (qmail 97144 invoked by uid 60001); 22 May 2012 20:18:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1337717897; bh=o/z8FIogbvABNeJBEVwQMTLVb5HE3qx/H/cMAHmxlJg=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=j4kYH6Pyuo/yY4iHao3ua+pWcZvmIQRonXcA+DFhVZpQh6FZSB9Jp+1EmT4uA4MPgbEbJyCJLACCDuMFCqk3+B7PcFoi+o51fuEU8zq3odIsxUmdl19fwVJdYjnKy9Yrf39QEnxTNrY3EQs53UJvlsyV54GGwb50Ca+ge45eyfw= X-YMail-OSG: .f1HTDAVM1nvInJWfRD7WDd7sUcwc.ZksSviThrHypvBdOb QEy5DA7FWwGdyfiTiceWFG_fOOsfIHtk5ZAu85XvqlAP.HaqGHvFIQFpMTEZ 7gY83pwn5rpwIhH.6gty_.9USXiKd2x7Ewlo0iIJx7O6sDWTJLN3APbCAt1_ d2PtVBOECQUv2oeL7ccJY4aFTDyHXXdkRQzUjYe3RhRQHjeC_GhrCB5pjkU2 Bpl6VP.0Qqj.ngmfsMeGZThEjeeAhQJet.KqaOq7RFe2bP_TGl6kHyLo_Lwt ro2SsGXcxEfb9f2ICfubtcwhlFUWnirvKPyKvvLNUv8iI3RX3X5X1eUcwRv6 LqYLWBU9O7oEirsg0JqRbs2DtPovU7RCq0jKD4kDxwoIHNh9y2LHDm0cyMmc qFUa_xL3ESqO.nRlC_1PjeZg6x_aZRGOm5c1XSjUrl7KQVqA63oPJRLqKDD3 VTsH_2G4gLyCHq8MXzmjkjZw3iMQpHsxG1MNJLocbGFDWMUWbq_m1sDhhaD8 cc8Mp1ZuGbVGjpIlXh6naE7dy_KrtPcCAscYvYlpX3lbbg0Xc3ag8reCZr2s dLJZVQEehHUEwHiCtg5ksA43bmZDnoIaowChZHVtl7J0UsWsyvJbZttDpUWa 289qYmNmTPEvayIAos6cTS.hcJdAl3a8W2jyNUyLz1yyCi6gzK.zWvdawEXz 8DYE8kCQpPwfalwKbW5mX3XxPyj2BueUacB2OnpRgQLqtfWu4YvMocUvaN7Q FET6PZoF0odXck3DJXYw4y4d127tcxE3ipXlXVeEm9G9ck_6Fh8g_OfdBPoT SV51uciaCLL8YCBhmnNZ8CGuniVvnHcVHbu7dT2.sfN_hvkx7Ks12Bmn5L3F Z9UFI.wPNPcc7TSKQb6qdNKbsD.zNYQMpR5JNHESa.yk15dBPTQAPj_WBFxV DoosW Received: from [64.140.94.67] by web181309.mail.ne1.yahoo.com via HTTP; Tue, 22 May 2012 13:18:17 PDT X-RocketYMMF: edmundjay@sbcglobal.net X-Mailer: YahooMailRC/708 YahooMailWebService/0.8.118.349524 References: <026e01cd37a4$e406d670$ac148350$@augustcellars.com> Message-ID: <1337717897.88719.YahooMailRC@web181309.mail.ne1.yahoo.com> Date: Tue, 22 May 2012 13:18:17 -0700 (PDT) From: Edmund Jay To: Axel.Nennker@telekom.de, ietf@augustcellars.com, jose@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-939539953-826603341-1337717897=:88719" Subject: Re: [jose] Disscussion Issue - Algorithm Parameters 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, 22 May 2012 20:18:25 -0000 ---939539953-826603341-1337717897=:88719 Content-Type: text/plain; charset=us-ascii I agree with Axel that specs should be simple and that the various algorithms' parameters default/supported values should be fully described. I was working on adding AES-GCM support to my PHP library and the algorithm has options for IV size, tag size, and addtional authentication data. The JWE spec described what the parameter values should be or what values are supported. This cuts down on having to specify the values somewhere. If the complicated way of using a JSON structure is added and the parameter values are the same as the defaults, then it pretty much means that all applications would need to support the complicated case just to read the default values. ________________________________ From: "Axel.Nennker@telekom.de" To: ietf@augustcellars.com; jose@ietf.org Sent: Tue, May 22, 2012 12:32:59 AM Subject: Re: [jose] Disscussion Issue - Algorithm Parameters I agree with the fact that all described algorithms must be fully described to eliminate ambiguity. But we have to find a balance between long and complicated and short and simple. With regard to RSA-OAEP I suggest to keep the name "RSA-OAEP" and describe the default parameters in the text or table-cell. If an implementer chooses other parameters than the default then they could use your suggested format. alg: { name:"RSA-OAEP", hash: "PSI-384", mgf: "mgfX" } Which then leads to the requirement that servers MUST reject the whole thing if one of the parameters is not supported. Things are getting complicated. It is best to stay with the defaults (fully describe them in the text but keep the name) and leave other parameters than default ones to extensions. I have implemented an early version of the JW? Specs in Java https://code.google.com/p/openinfocard/source/browse/trunk/src/org/xmldap/json/WebToken.java which uses Bouncycastle http://bouncycastle.org/docs/docs1.5on/org/bouncycastle/asn1/pkcs/RSAESOAEPparams.html which use sha1 and mgf1SHA1 as default. These same defaults are specified in Table5 of http://self-issued.info/docs/draft-jones-json-web-encryption.html "RSA using Optimal Asymmetric Encryption Padding (OAEP) RSA-OAEP http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p RSA/ECB/OAEPWithSHA-1AndMGF1Padding" So everything in this spec (related to RSA_OAEP) looks fully specified to me. I see no reason to make things more complicated. -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Tuesday, May 22, 2012 12:56 AM To: jose@ietf.org Subject: [jose] Disscussion Issue - Algorithm Parameters An issue I would like to see some discussion on Should an algorithm be able to specific parameters rather than making them part of the algorithm name string? If so should we change the way that we are doing parameters to allow for this better? As an example of this, the RSA-OAEP algorithm needs to specify two parameters: The mask function and a hash function. We can say that these are to be encoded in the name of the algorithm (i.e. RSA-OAEP-mf1-sha256) or we can change the alg parameter to allow for the following: Either a string specifying the name of the algorithm (with defaults values in some cases) (i.e. alg: "RSA-OAEP-mf2-sha256") OR A JSON structure with the name of the algorithm and the parameters alg: { name:"RSA-OAEP", hash: "SHA-256", mgf: "mgf1" } jim _______________________________________________ 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 ---939539953-826603341-1337717897=:88719 Content-Type: text/html; charset=us-ascii
I agree with Axel that specs should be simple and that the various algorithms' parameters default/supported values should be fully described.
I was working on adding AES-GCM support to my PHP library and the algorithm has options for IV size, tag size, and addtional authentication data. The JWE spec described what the parameter values should be or what values are supported. This cuts down on having to specify the values somewhere.
If the complicated way of using a JSON structure is added and the parameter values are the same as the defaults, then it pretty much means that all applications would need to support the complicated case just to read the default values.





From: "Axel.Nennker@telekom.de" <Axel.Nennker@telekom.de>
To: ietf@augustcellars.com; jose@ietf.org
Sent: Tue, May 22, 2012 12:32:59 AM
Subject: Re: [jose] Disscussion Issue - Algorithm Parameters

I agree with the fact that all described algorithms must be fully described to eliminate ambiguity.
But we have to find a balance between long and complicated and short and simple.

With regard to RSA-OAEP I suggest to keep the name "RSA-OAEP" and describe the default parameters in the text or table-cell.
If an implementer chooses other parameters than the default then they could use your suggested format. alg: { name:"RSA-OAEP", hash: "PSI-384", mgf: "mgfX" }
Which then leads to the requirement that servers MUST reject the whole thing if one of the parameters is not supported.

Things are getting complicated. It is best to stay with the defaults (fully describe them in the text but keep the name) and leave other  parameters than default ones to extensions.

I have implemented an early version of the JW? Specs in Java
https://code.google.com/p/openinfocard/source/browse/trunk/src/org/xmldap/json/WebToken.java
which uses Bouncycastle
http://bouncycastle.org/docs/docs1.5on/org/bouncycastle/asn1/pkcs/RSAESOAEPparams.html
which use sha1 and mgf1SHA1 as default.
These same defaults are specified in Table5 of http://self-issued.info/docs/draft-jones-json-web-encryption.html
"RSA using Optimal Asymmetric Encryption Padding (OAEP)     RSA-OAEP     http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p     RSA/ECB/OAEPWithSHA-1AndMGF1Padding"

So everything in this spec (related to RSA_OAEP) looks fully specified to me.
I see no reason to make things more complicated.

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Tuesday, May 22, 2012 12:56 AM
To: jose@ietf.org
Subject: [jose] Disscussion Issue - Algorithm Parameters

<no hat>

An issue I would like to see some discussion on

Should an algorithm be able to specific parameters rather than making them part of the algorithm name string?  If so should we change the way that we are doing parameters to allow for this better?


As an example of this, the RSA-OAEP algorithm needs to specify two
parameters:  The mask function and a hash function.  We can say that these are to be encoded in the name of the algorithm (i.e. RSA-OAEP-mf1-sha256) or we can change the alg parameter to allow for the following:

Either a string specifying the name of the algorithm (with defaults values in some cases)  (i.e. alg: "RSA-OAEP-mf2-sha256")

OR

A JSON structure with the name of the algorithm and the parameters

alg: { name:"RSA-OAEP", hash: "SHA-256", mgf: "mgf1" }


jim


_______________________________________________
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
---939539953-826603341-1337717897=:88719-- From Michael.Jones@microsoft.com Tue May 22 16:24: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 14EC821F8613 for ; Tue, 22 May 2012 16:24:26 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8WUXtruAEAJ for ; Tue, 22 May 2012 16:24:25 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id B68A821F85F6 for ; Tue, 22 May 2012 16:24:24 -0700 (PDT) Received: from mail59-db3-R.bigfish.com (10.3.81.254) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Tue, 22 May 2012 23:24:09 +0000 Received: from mail59-db3 (localhost [127.0.0.1]) by mail59-db3-R.bigfish.com (Postfix) with ESMTP id 690224009E; Tue, 22 May 2012 23:24:09 +0000 (UTC) X-SpamScore: -30 X-BigFish: VS-30(zz9371I103dK542M1528Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail59-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=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail59-db3 (localhost.localdomain [127.0.0.1]) by mail59-db3 (MessageSwitch) id 1337729048607191_29970; Tue, 22 May 2012 23:24:08 +0000 (UTC) Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.236]) by mail59-db3.bigfish.com (Postfix) with ESMTP id 901D14E0075; Tue, 22 May 2012 23:24:08 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 22 May 2012 23:24:06 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0298.005; Tue, 22 May 2012 23:24:17 +0000 From: Mike Jones To: Vladimir Dzhuvinov / NimbusDS , "jose@ietf.org" Thread-Topic: [jose] Pleased with new -02 spec structure Thread-Index: AQHNNzWD8nACtd+4506mpg1oun0DcJbWdXeg Date: Tue, 22 May 2012 23:24:17 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366513E18@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <20120521023831.cc40c4f3d92d2001859047cd8cabb9ab.433456133a.wbe@email07.europe.secureserver.net> In-Reply-To: <20120521023831.cc40c4f3d92d2001859047cd8cabb9ab.433456133a.wbe@email07.europe.secureserver.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] Pleased with new -02 spec structure 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, 22 May 2012 23:24:26 -0000 Thanks! -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Vla= dimir Dzhuvinov / NimbusDS Sent: Monday, May 21, 2012 2:39 AM To: jose@ietf.org Subject: [jose] Pleased with new -02 spec structure I just went through the new -02 specs in order to update our Java JWT libra= ry and have to say I'm very pleased with the new spec structure where the a= lgorithms have been moved entirely to the JWA doc. The whole spec suite rea= ds easier now. The new JWK terms are also a much better match! Thanks to everyone who worked on that! Vladimir -- Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From vladimir@nimbusds.com Wed May 23 01:58:08 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA13421F85A4 for ; Wed, 23 May 2012 01:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5ZQmqgPaXyE for ; Wed, 23 May 2012 01:58:07 -0700 (PDT) Received: from n1plwbeout07-01.prod.ams1.secureserver.net (n1plsmtp07-01-02.prod.ams1.secureserver.net [188.121.52.106]) by ietfa.amsl.com (Postfix) with SMTP id 1751B21F859F for ; Wed, 23 May 2012 01:58:06 -0700 (PDT) Received: (qmail 32148 invoked from network); 23 May 2012 08:58:01 -0000 Received: from unknown (HELO localhost) (188.121.52.246) by n1plwbeout07-01.prod.ams1.secureserver.net with SMTP; 23 May 2012 08:58:00 -0000 Received: (qmail 20168 invoked by uid 99); 23 May 2012 08:58:00 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 79.100.241.224 User-Agent: Workspace Webmail 5.6.17 Message-Id: <20120523015759.cc40c4f3d92d2001859047cd8cabb9ab.1c4940ddeb.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: "jose@ietf.org" Date: Wed, 23 May 2012 01:57:59 -0700 Mime-Version: 1.0 Subject: Re: [jose] Disscussion Issue - Algorithm Parameters 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, 23 May 2012 08:58:08 -0000 I don't understand many of the specifics, but I'm totally for the spirit=0A= of this proposal.=0A=0AWe may have great crypto algorithms, but they're onl= y as usable as=0Amainstream developers find them easy to implement.=0A=0ASo= let's have simple "alg" strings that package well chosen=0Acombinations. P= eople who choose to have something different can create=0Atheir private "al= g" identifiers and/or header parameters (it appears to=0Ame that with some = careful design both methods for describing custom algs=0Ashould be possible= ).=0A=0A+1=0A=0A--=0AVladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbu= sds.com=0A=0A=0A=0A-------- Original Message --------=0ASubject: Re: [jose]= Disscussion Issue - Algorithm Parameters=0AFrom: Mike Jones =0ADate: Tue, May 22, 2012 6:49 am=0ATo: Jim Schaad , "'Manger, James H'"=0A, = "jose@ietf.org" =0A=0A As background on the current spec de= sign, both JSMS and the JWS family=0Aof specs independently made a consciou= s design choice to specify a=0Asmall, limited set of cryptographic algorith= ms and algorithm=0Acombinations to simplify implementations and increase in= teroperability. =0AQuoting from the introduction to JSMS (with my emphasis= ):=0A =0A Many applications require the ability to send cryptographical= ly=0A secured (encrypted, digitally signed, etc.) messages. While the= =0AIETF=0A has defined a number of formats for such messages, those for= mats=0Aare=0A widely viewed as being excessively complicated for the dem= ands of=0AWeb=0A applications, which typically only need the ability to = secure simple=0A messages. ...=0A =0A This document describes a new= cryptographic message format,=0A JavaScript Message Security (JSMS) int= ended to meet the need of the=0A Web environment. While JSMS is modeled= on existing formats --=0A principally CMS [RFC5652] -- it uses JavaScri= pt Object Notation=0A (JSON) rather than ASN.1/BER/DER, making it far ea= sier for Web=0A applications to handle. In the interest of simplicity, = JSMS also=0A omits as many as possible of the CMS modes (multiple signat= ures,=0A password-based encryption).=0A =0A In parallel, the consensus = decisions in the design discussions behind=0Athe JWE design included:=0A = =E2=80=9Cwe should specify a small set of composite operations that will= =0Ameet the needs of common use cases=E2=80=9D=0A =0A We=E2=80=99re trying= to make simple things simple to facilitate widespread=0Adeployment of stro= ng crypto. The alternative is XML ENC, where all=0Aparameters and paramete= r combinations *can* be specified but with no=0Aguarantees that any particu= lar combination, other than a=0Amandatory-to-implement set, will actually b= e supported or interoperable=0Aamong any particular implementations.=0A = =0A I believe that the designers of both sets of JOSE precursor specs=0Area= ched the conclusion that simple specs with a small set of useful,=0Awidely = implemented, carefully chosen cryptographic primitives and=0Acombinations w= ould be of more practical value to developers and result=0Ain more deployme= nt and interoperability than a highly general spec that=0Aallows for a larg= e combinatorial set of parameter combinations.=0A =0A If new parameter com= binations are needed in practice, they can easily=0Abe specified in the JWA= spec or in the registries that it defines.=0A =0A I hope that understandi= ng this rationale behind the intentionally=0Alimited sets of algorithms spe= cified in both JSMS and JWA will be useful=0Ato the working group.=0A =0A = Best=0Awishes,= =0A -- Mike=0A = =0A -----Original Message-----=0A From: jose-bounces@ietf.org [mailto:jose= -bounces@ietf.org] On Behalf Of=0AJim Schaad=0A Sent: Monday, May 21, 2012 = 8:55 PM=0A To: 'Manger, James H'; jose@ietf.org=0A Subject: Re: [jose] Diss= cussion Issue - Algorithm Parameters=0A =0A =0A =0A > -----Original Mess= age-----=0A > From: Manger, James H [mailto:James.H.Manger@team.telstra.co= m]=0A > Sent: Monday, May 21, 2012 8:25 PM=0A > To: Jim Schaad; jose@ietf.o= rg=0A > Subject: RE: [jose] Disscussion Issue - Algorithm Parameters=0A > = =0A > > Should an algorithm be able to specific parameters rather than =0A = > > making them part of the algorithm name string? If so should we =0A > >= change the way that we are doing parameters to allow for this=0Abetter?=0A= > =0A > > alg: "RSA-OAEP-mf2-sha256"=0A > > OR=0A > > alg: { name:"RSA-OAE= P", hash: "SHA-256", mgf: "mgf1" }=0A > =0A > =0A > Another option is:=0A >= "alg": "RSA-OAEP"=0A > "mgf": "MGF1"=0A > "hash": "SHA-256"=0A =0A = That is an option that is doable as well. I happen to think that it=0Amigh= t lead to problems down the road. If you have two algorithms in the=0Ahead= er, then one must make sure that there is no possibility that the=0Atwo alg= orithms will want to use the same field. =0A =0A Given that anybody can d= efine a new algorithm, it is not possible to do=0Aan exhaustive search for = collisions in the use of field names. It might=0Abe better to have them sc= oped already.=0A =0A =0A > =0A > I suspect additional parameters in the h= eader (like "mgf" and "hash"=0A above)=0A > was the intention. This is why = the algorithms spec (in sections 3.6 =0A > and=0A 4.11 for=0A > signature a= nd encryption algorithms) says: "additional reserved=0Aheader =0A > paramet= er names MAY be defined".=0A > The result is a flat structure for all sorts= of parameters: about the=0A payload=0A > ("typ"); about JWE processing ("e= nc", "int"); about a specific =0A > algorithm ("mgf", "hash") etc.=0A > A f= lat structure will cause headaches at some point (cf trying to =0A > separa= te transport and content details from HTTP's flat header =0A > structure), = but it=0A is=0A > simpler to start with.=0A > I suggest we stick with a fla= t structure for JOSE.=0A > =0A > =0A > =0A > > As an example of this, the R= SA-OAEP algorithm needs to specify two=0A > > parameters: The mask functio= n and a hash function.=0A > =0A > For RSA-OAEP specifically, I suggest:=0A = > * picking one hash algorithm (SHA-256) and including it in the name =0A >= "RSA- OAEP256"=0A > * hardwiring the mask-generation function (to be MGF1 = with the same =0A > hash=0A > algorithm) (so no "mgf" parameter is needed)= =0A > * hardwiring the label to be empty.=0A > =0A > The resulting spec tex= t could be:=0A > =3D=3D=3D=3D=3D=0A > 4.5 "RSA-OAEP256"=0A > =0A > The "R= SA-OAEP256" key encryption algorithm is RSA encryption with=0A > Optimal = Asymmetric Encryption Padding (OAEP) using SHA-256.=0A > The algorithm is= specified in PKCS#1 [RFC 3447], where it is=0A > called RSAES-OAEP-ENCRY= PT.=0A > =0A > The hash function is SHA-256 [FIPS 180-4].=0A > =0A > Th= e mask generation function is MGF1 [RFC 3447], using SHA-256 as=0A > the = hash function.=0A > =0A > The label is the empty string.=0A > =3D=3D=3D= =3D=3D=0A > =0A > --=0A > James Manger=0A =0A ____________________________= ___________________=0A jose mailing list=0A jose@ietf.org=0A https://www.ie= tf.org/mailman/listinfo/jose=0A =0A =0A___________________________________= ____________=0Ajose mailing list=0Ajose@ietf.org=0Ahttps://www.ietf.org/mai= lman/listinfo/jose=0A From Michael.Jones@microsoft.com Wed May 23 13:40:02 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563BD21F848C for ; Wed, 23 May 2012 13:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkg89C+XI8nw for ; Wed, 23 May 2012 13:40:01 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD5121F848B for ; Wed, 23 May 2012 13:40:01 -0700 (PDT) Received: from mail43-va3-R.bigfish.com (10.7.14.254) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Wed, 23 May 2012 20:39:53 +0000 Received: from mail43-va3 (localhost [127.0.0.1]) by mail43-va3-R.bigfish.com (Postfix) with ESMTP id 19FC212046A for ; Wed, 23 May 2012 20:39:53 +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: -20 X-BigFish: VS-20(zz9371Ic85fhzz1202hzz1033IL8275eh8275bh8275dha1495iz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail43-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail43-va3 (localhost.localdomain [127.0.0.1]) by mail43-va3 (MessageSwitch) id 1337805590926231_1994; Wed, 23 May 2012 20:39:50 +0000 (UTC) Received: from VA3EHSMHS032.bigfish.com (unknown [10.7.14.245]) by mail43-va3.bigfish.com (Postfix) with ESMTP id DF51740004A for ; Wed, 23 May 2012 20:39:50 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS032.bigfish.com (10.7.99.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 23 May 2012 20:39:46 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0298.005; Wed, 23 May 2012 20:39:33 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: [OAUTH-WG] Initial Standards Track JSON Web Token (JWT) Specifications Thread-Index: Ac05JChC4J6VxwUyS8W1+yIUqfei/w== Date: Wed, 23 May 2012 20:39:32 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366515ECB@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366515ECBTK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [jose] FW: [OAUTH-WG] Initial Standards Track JSON Web Token (JWT) Specifications X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 20:40:02 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366515ECBTK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Wednesday, May 23, 2012 1:38 PM To: oauth@ietf.org Subject: [OAUTH-WG] Initial Standards Track JSON Web Token (JWT) Specificat= ions The JSON Web Token (JWT) specification and the OAuth 2.0 JWT Bearer Token Profiles specification are now IETF= standards track documents in the OAuth working group. These versions are based upon the individual submission = versions draft-jones-json-web-token-10 and draft-jones-oauth-jwt-bearer-04 with no normative changes. The = JWT specification builds upon the JWS, JWE, JWK, and JWA specifications in the JOSE working group. These specifications are available at: * http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-00 * http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-00 HTML formatted versions are available at: * http://self-issued.info/docs/draft-ietf-oauth-json-web-token-00.h= tml * http://self-issued.info/docs/draft-ietf-oauth-jwt-bearer-00.html -- Mike (This message also posted at http://self-issued.info/?p=3D735.) --_000_4E1F6AAD24975D4BA5B168042967394366515ECBTK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, May 23, 2012 1:38 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Initial Standards Track JSON Web Token (JWT) Spe= cifications

 

The JSON Web Token (JWT) specification and the OAuth 2.0 JWT Bearer Token Profiles specif= ication are now IETF standards track documents in the OAuth working group. These versions are based upon the indi= vidual submission versions draft-jones-json-web-token-10 and draft-jones-oauth-jwt-bearer-04 with n= o normative changes.  The JWT specification builds upon the JWS, JWE, JWK, and JWA specifications in the JOSE working group.

 

These specifications are available at:

·         http://tools.ie= tf.org/html/draft-ietf-oauth-json-web-token-00

·         http://tools.ietf.o= rg/html/draft-ietf-oauth-jwt-bearer-00

 

HTML formatted versions are available at:

·         http://s= elf-issued.info/docs/draft-ietf-oauth-json-web-token-00.html=

·         http://self-= issued.info/docs/draft-ietf-oauth-jwt-bearer-00.html<= /p>

 

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

 

(This message also posted at http://self-issued.info/?p=3D735.)

 

--_000_4E1F6AAD24975D4BA5B168042967394366515ECBTK5EX14MBXC284r_-- From Axel.Nennker@telekom.de Fri May 25 03:58:46 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A29521F8642 for ; Fri, 25 May 2012 03:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=-1.039, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9DpWRNAhVo0 for ; Fri, 25 May 2012 03:58:41 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id AE7DF21F863E for ; Fri, 25 May 2012 03:58:40 -0700 (PDT) Received: from he111296.emea1.cds.t-internal.com ([10.125.90.14]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 25 May 2012 12:58:37 +0200 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.88]) by HE111296.EMEA1.CDS.T-INTERNAL.COM ([fe80::19ac:3fb4:a382:6df4%16]) with mapi; Fri, 25 May 2012 12:58:35 +0200 From: To: , Date: Fri, 25 May 2012 12:58:32 +0200 Thread-Topic: JWA ECSH-ES Thread-Index: Ac06ZVGN3rTyePMfQuSi9YW637yN8A== Message-ID: 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_CE8995AB5D178F44A2154F5C9A97CAF402512C72572EHE111541eme_" MIME-Version: 1.0 Subject: [jose] JWA ECSH-ES 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, 25 May 2012 10:58:46 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF402512C72572EHE111541eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 4 of https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithm= s-02 defines: | ECDH-ES | Elliptic Curve Diffie-Hellman Ephemeral Static, as | | | defined in RFC 6090 [= RFC6090], and using the Concat | | | KDF, as defined in Section 5.8.1 of [NIST.800-56A], | | | where the Digest Method is SHA-256 and all OtherInfo | | | parameters are the empty bit string | I suggest to change the KDF to KDF2 as described here http://www.di-mgt.com.au/cryptoKDFs.html and defined in ISO18033. Reasons are: - The kdf defined in NIST.800-56A section 5.8.1 is not implemented= in Bouncycastle while KDF1 and KDF2 are implemented. - NIST is a national standard while the ISO standard is internatio= nal and I assume that there is a NIST adaption of it. - There are currently not many implementations of JWA using ECDH-E= S. So this change is currently probably non-breaking. - The current definition seems to be difficult to implement using o http://msdn.microsoft.com/en-us/library/windows/desktop/aa375393%28v=3D= vs.85%29.aspx too because OtherInfo can not be the empty bit string because parts of OtherInf= o are required like ALGORITHMID Input about other commonly used crypto libraries should be collected. I got= the impression that some of them like openssl implement only PBKDF but not= KDF1, KDF2, KDF3 (prove me wrong) Cheers Axel From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik= e Jones Sent: Sunday, May 13, 2012 2:09 AM To: jose@ietf.org Subject: [jose] Draft -02 of JSON Crypto Specs: JWS, JWE, JWK, JWA New -02 versions of the JSON Object Signing and Encryption (JOSE) specifications are now available that incorpor= ate working decisions made since the previous versions, including decisions= made at IETF 83 in Paris and in follow-up discussions on the working group= list. The drafts contain numerous clarifications, refinements, and editor= ial improvements. They are: * JSON Web Signature (JWS) - Digital signature/HMAC specification * JSON Web Encryption (JWE) - Encryption specification * JSON Web Key (JWK) - Public key specification * JSON Web Algorithms (JWA) - Algorithms and identifiers specificat= ion These specifications are available at: * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-02 * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-02 * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-02 * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-02 The document history entries (also in the specifications) are as follows: http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-02: * Clarified that it is an error when a kid value is included and no matc= hing key is found. * Removed assumption that kid (key ID) can only refer to an asymmetric k= ey. * Clarified that JWSs with duplicate Header Parameter Names MUST be reje= cted. * Clarified the relationship between typ header parameter values and MIM= E types. * Registered application/jws MIME type and "JWS" typ header parameter va= lue. * Simplified JWK terminology to get replace the "JWK Key Object" and "JW= K Container Object" terms with simply "JSON Web Key (JWK)" and "JSON Web Ke= y Set (JWK Set)" and to eliminate potential confusion between single keys a= nd sets of keys. As part of this change, the header parameter name for a pu= blic key value was changed from jpk (JSON Public Key) to jwk (JSON Web Key)= . * Added suggestion on defining additional header parameters such as x5t#= S256 in the future for certificate thumbprints using hash algorithms other = than SHA-1. * Specify RFC 2818 server identity validation, rather than RFC 6125 (par= alleling the same decision in the OAuth specs). * Generalized language to refer to Message Authentication Codes (MACs) r= ather than Hash-based Message Authentication Codes (HMACs) unless in a cont= ext specific to HMAC algorithms. * Reformatted to give each header parameter its own section heading. http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-02: * When using AEAD algorithms (such as AES GCM), use the "additional auth= enticated data" parameter to provide integrity for the header, encrypted ke= y, and ciphertext and use the resulting "authentication tag" value as the J= WE Integrity Value. * Defined KDF output key sizes. * Generalized text to allow key agreement to be employed as an alternati= ve to key wrapping or key encryption. * Changed compression algorithm from gzip to DEFLATE. * Clarified that it is an error when a kid value is included and no matc= hing key is found. * Clarified that JWEs with duplicate Header Parameter Names MUST be reje= cted. * Clarified the relationship between typ header parameter values and MIM= E types. * Registered application/jwe MIME type and "JWE" typ header parameter va= lue. * Simplified JWK terminology to get replace the "JWK Key Object" and "JW= K Container Object" terms with simply "JSON Web Key (JWK)" and "JSON Web Ke= y Set (JWK Set)" and to eliminate potential confusion between single keys a= nd sets of keys. As part of this change, the header parameter name for a pu= blic key value was changed from jpk (JSON Public Key) to jwk (JSON Web Key)= . * Added suggestion on defining additional header parameters such as x5t#= S256 in the future for certificate thumbprints using hash algorithms other = than SHA-1. * Specify RFC 2818 server identity validation, rather than RFC 6125 (par= alleling the same decision in the OAuth specs). * Generalized language to refer to Message Authentication Codes (MACs) r= ather than Hash-based Message Authentication Codes (HMACs) unless in a cont= ext specific to HMAC algorithms. * Reformatted to give each header parameter its own section heading. http://tools.ietf.org/html/draft-ietf-jose-json-web-key-02: * Simplified JWK terminology to get replace the "JWK Key Object" and "JW= K Container Object" terms with simply "JSON Web Key (JWK)" and "JSON Web Ke= y Set (JWK Set)" and to eliminate potential confusion between single keys a= nd sets of keys. As part of this change, the top-level member name for a se= t of keys was changed from jwk to keys. * Clarified that values with duplicate member names MUST be rejected. * Established JSON Web Key Set Parameters registry. * Explicitly listed non-goals in the introduction. * Moved algorithm-specific definitions from JWK to JWA. * Reformatted to give each member definition its own section heading. http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-02: * For AES GCM, use the "additional authenticated data" parameter to prov= ide integrity for the header, encrypted key, and ciphertext and use the res= ulting "authentication tag" value as the JWE Integrity Value. * Defined minimum required key sizes for algorithms without specified ke= y sizes. * Defined KDF output key sizes. * Specified the use of PKCS #5 padding with AES-CBC. * Generalized text to allow key agreement to be employed as an alternati= ve to key wrapping or key encryption. * Clarified that ECDH-ES is a key agreement algorithm. * Required implementation of AES-128-KW and AES-256-KW. * Removed the use of A128GCM and A256GCM for key wrapping. * Removed A512KW since it turns out that it's not a standard algorithm. * Clarified the relationship between typ header parameter values and MIM= E types. * Generalized language to refer to Message Authentication Codes (MACs) r= ather than Hash-based Message Authentication Codes (HMACs) unless in a cont= ext specific to HMAC algorithms. * Established registries: JSON Web Signature and Encryption Header Param= eters, JSON Web Signature and Encryption Algorithms, JSON Web Signature and= Encryption "typ" Values, JSON Web Key Parameters, and JSON Web Key Algorit= hm Families. * Moved algorithm-specific definitions from JWK to JWA. * Reformatted to give each member definition its own section heading. -- Mike --_000_CE8995AB5D178F44A2154F5C9A97CAF402512C72572EHE111541eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 4 of https://tools.ietf.org/html/draft-ietf-jose-= json-web-algorithms-02 defines:

 

 &nb= sp; | ECDH-ES   | Elliptic Curve Diffie-Hellman Ephemeral Static,= as    |

   |  = ;         | defined in RFC 6090 [RFC6090], and using the Concat   |<= /o:p>

   |      &nbs= p;    | KDF, as defined in Section 5.8.1 of [NIST.800-56A],   |

 &nbs= p; |           | where th= e Digest Method is SHA-256 and all OtherInfo  |

<= p class=3DMsoNormal>   |         &nb= sp; | parameters are the empty bit string     &nbs= p;             = |

<= o:p> 

I suggest to change the KDF to KDF2 as described here =

http://www.di-mgt.co= m.au/cryptoKDFs.html

and defined in ISO18033.

 

Reasons are:

- &n= bsp;        The kdf defined in NIST.800-56A section 5.= 8.1 is not implemented in Bouncycastle while KDF1 and