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 KDF2 are implemented.=

-          NIST is a national standar=
d while the ISO standard is international and I assume that there is a NIST=
 adaption of it.
-        &nb=
sp; There are =
currently not many implementations of JWA using ECDH-ES. 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=3Dvs.85%29.a=
spx too
because OtherInfo can not be the empty bit string because pa=
rts of OtherInfo are required like ALGORITHMID
 
Input about other commonly used crypto libraries should be collec=
ted. I got the impression that some of them like openssl implement only PBK=
DF but not KDF1, KDF2, KDF3 (prove me wrong)
 
Cheers
=

Axel
 
 <=
/span>
From: jose-bounces@ietf.org [mai=
lto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: S=
unday, 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 avai=
lable that incorporate working decisions made since the previous versions, =
including decisions made at IETF 83 in Paris and in follow-up discussions o=
n the working group list.  The drafts contain numerous clarifications,=
 refinements, and editorial improvements.  They are:
· =
;        =
JSON Web Signature (JWS) – Digital signature/HMAC specification<=
/o:p>
·         JSON Web Encryption (JWE) – Encryption specification=

·         JSON Web Key (JWK) – Public key specification=

··  &nb=
sp;      http://t=
ools.ietf.org/html/draft-ietf-jose-json-web-signature-02 
·&=
nbsp;        http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-02 
·         http://tools.ietf.org/html/draft-ietf-jose-json-web-key-02<=
/a> 
·         http://tools.ietf.org/html/draft-ietf-jose-json-we=
b-algorithms-02 
 
The document history entries (also in the specificat=
ions) are as follows:
 <=
/p>
http://tools.ietf.org/html/draft-ietf-jose-json-w=
eb-signature-02:
  • Clarified that it is=
 an error when a kid value is included and no matching key is found. 
  • Removed assum=
ption that kid (key ID) can only refer to an asymmetric key. 
    • =

  • Clarified that JWSs w=
ith duplicate Header Parameter Names MUST be rejected. 
  • Clarified the rela=
tionship between typ header parameter values and MIME types. 
    • =

  • Registered applicatio=
n/jws MIME type and "JWS" typ header parameter value. =

  • Simplifie=
d JWK terminology to get replace the "JWK Key Object" and "J=
WK Container Object" terms with simply "JSON Web Key (JWK)" =
and "JSON Web Key Set (JWK Set)" and to eliminate potential confu=
sion between single keys and sets of keys. As part of this change, the head=
er parameter name for a public key value was changed from jpk (JSON Public Key) to <=
/span>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 th=
an SHA-1. 
  • Specify RFC 2818 server identity validation, rather than RFC 61=
25 (paralleling the same decision in the OAuth specs). 
  • Generalized langua=
ge to refer to Message Authentication Codes (MACs) rather than Hash-based M=
essage Authentication Codes (HMACs) unless in a context specific to HMAC al=
gorithms. 
  • Reformatted to give each header parameter its own section headi=
ng. 
 
<=
p class=3DMsoNormal>http://tools.ietf.org/html/draft-ietf-jose-json-web-=
encryption-02:
    <=
li class=3DMsoNormal style=3D'color:black;mso-list:l6 level1 lfo4'>When using AEAD algori=
thms (such as AES GCM), use the "additional authenticated data" p=
arameter to provide integrity for the header, encrypted key, and ciphertext=
 and use the resulting "authentication tag" value as the JWE Inte=
grity Value. 
  • Defined KDF output key sizes. 
  • Generalized text to allow ke=
y agreement to be employed as an alternative to key wrapping or key encrypt=
ion. 
  • Changed compression algorithm from gzip to DEFLATE. 
  • =
Clarified that=
 it is an error when a kid value is included and no matching key is found. 
  • Clarifi=
ed that JWEs with duplicate Header Parameter Names MUST be rejected. <=
/o:p>
  • Clar=
ified the relationship between typ header parameter values and MIME types. 
  • Registe=
red application/jwe MIME type and "JWE" typ header parameter valu=
e. 
  • Simplified JWK terminology to get replace the "JWK Key Object&quo=
t; and "JWK Container Object" terms with simply "JSON Web Ke=
y (JWK)" and "JSON Web Key Set (JWK Set)" and to eliminate p=
otential confusion between single keys and sets of keys. As part of this ch=
ange, the header parameter name for a public key value was changed from jpk (JSON Pu=
blic Key) to jwk (JSON Web Key). 
  • Added suggestion on defining additional header p=
arameters such as x5t#S256 in the future for certificate thumbprints using hash algo=
rithms other than SHA-1. 
  • Specify RFC 2818 server identity validation, rat=
her than RFC 6125 (paralleling the same decision in the OAuth specs). =

  • Gen=
eralized language to refer to Message Authentication Codes (MACs) rather th=
an Hash-based Message Authentication Codes (HMACs) unless in a context spec=
ific to HMAC algorithms. 
  • Reformatted to give each header parameter its ow=
n section heading. 
&n=
bsp;
http://tools.ietf.org/html/draft-ietf-jose-j=
son-web-key-02:
    =

  • Simplified JWK termin=
ology to get replace the "JWK Key Object" and "JWK Container=
 Object" terms with simply "JSON Web Key (JWK)" and "JS=
ON Web Key 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 set of keys was changed from jwk to keys. 
  • Clarified that values with duplicat=
e member names MUST be rejected. 
  • Established JSON Web Key Set Parameters =
registry. 
  • Explicitly listed non-goals in the introduction. 
  • Moved algori=
thm-specific definitions from JWK to JWA. 
  • Reformatted to give each membe=
r 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 provide integrity for the header, encrypted key, and cipherte=
xt and use the resulting "authentication tag" value as the JWE In=
tegrity Value. 
  • Defined minimum required key sizes for algorithms 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 employed as an alternative to key wrapping or key encryption. 
  • Clarifi=
ed 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. =

  • Rem=
oved A512KW since it turns out that it's not a standard algorithm. 
  • <=
span lang=3DEN style=3D'font-family:"Verdana","sans-serif"'>Clarified the r=
elationship between typ header parameter values and MIME types. 
  • Generalized langua=
ge to refer to Message Authentication Codes (MACs) rather than Hash-based M=
essage Authentication Codes (HMACs) unless in a context specific to HMAC al=
gorithms. 
  • Established registries: JSON Web Signature and Encryption Heade=
r Parameters, JSON Web Signature and Encryption Algorithms, JSON Web Signat=
ure and Encryption "typ" Values, JSON Web Key Parameters, and JSO=
N Web Key Algorithm Families. 
  • Moved algorithm-specific definitions from J=
WK to JWA. 
  • Reformatted to give each member definition its own section hea=
ding. 
 
         =
;            &n=
bsp;            =
;            &n=
bsp;            =
; -- Mike
 
=

--_000_CE8995AB5D178F44A2154F5C9A97CAF402512C72572EHE111541eme_--

From Michael.Jones@microsoft.com  Fri May 25 16:10:42 2012
Return-Path: 
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39F621F884A; Fri, 25 May 2012 16:10:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.748
X-Spam-Level: 
X-Spam-Status: No, score=-3.748 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 jetS4vP0O6FI; Fri, 25 May 2012 16:10:38 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id CA7D821F8849; Fri, 25 May 2012 16:10:37 -0700 (PDT)
Received: from mail124-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.23; Fri, 25 May 2012 23:10:24 +0000
Received: from mail124-ch1 (localhost [127.0.0.1])	by mail124-ch1-R.bigfish.com (Postfix) with ESMTP id CCFF9202CB; Fri, 25 May 2012 23:10:24 +0000 (UTC)
X-SpamScore: -5
X-BigFish: VS-5(zzc85fh1b0bMzz1202hzz8275bh8275dhz2fh2a8h668h839hd25hf0ah)
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 (mail124-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 mail124-ch1 (localhost.localdomain [127.0.0.1]) by mail124-ch1 (MessageSwitch) id 1337987423251400_32087; Fri, 25 May 2012 23:10:23 +0000 (UTC)
Received: from CH1EHSMHS008.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.249])	by mail124-ch1.bigfish.com (Postfix) with ESMTP id 2F975100078;	Fri, 25 May 2012 23:10:23 +0000 (UTC)
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS008.bigfish.com (10.43.70.8) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 25 May 2012 23:10:22 +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; Fri, 25 May 2012 23:10:33 +0000
From: Mike Jones 
To: "oauth@ietf.org" , "jose@ietf.org" 
Thread-Topic: Dominick Baier's JWT implementation
Thread-Index: Ac06yQfegSSKbZSrQveyTTB2LcYQgA==
Date: Fri, 25 May 2012 23:10:32 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436651A42A@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.36]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436651A42ATK5EX14MBXC284r_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Subject: [jose] Dominick Baier's JWT implementation
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.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 23:10:42 -0000

--_000_4E1F6AAD24975D4BA5B16804296739436651A42ATK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

FYI - Dominick Baier sent me a note letting me know about his JWT implement=
ation:

http://leastprivilege.com/2012/05/25/json-web-token-jwt-support-in-thinktec=
ture-identitymodel/

Have a good weekend, everyone!

                                                            -- Mike


--_000_4E1F6AAD24975D4BA5B16804296739436651A42ATK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











FYI - Dominick Baier sent me a not=
e letting me know about his JWT implementation:


 


http://leastprivilege.com/2012/05/25/json-web-token-jwt-=
support-in-thinktecture-identitymodel/


 


Have a good weekend, everyone!


 


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


 






--_000_4E1F6AAD24975D4BA5B16804296739436651A42ATK5EX14MBXC284r_--

From sakimura@gmail.com  Sat May 26 04:36:09 2012
Return-Path: 
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D8621F85A5; Sat, 26 May 2012 04:36:09 -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 uaEmg5l6+3Hk; Sat, 26 May 2012 04:36:08 -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 5ABA821F8533; Sat, 26 May 2012 04:36:08 -0700 (PDT)
Received: by bkty8 with SMTP id y8so1600055bkt.31 for ; Sat, 26 May 2012 04:36:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=S+rashWNgMsvjmRVojFo6oJW/jetoXjbdts+NgtnsJA=; b=x+DFw5xzG0clk3zyotTWitDWbMdrnhZfNZ8NNZa7A3BgnlY/XN1i6yM+bvo2q98jh4 Sz2ZvX01mGoAtp/T+Lp0Ly1D4vIj71cTBpQ3PNtowMAQXWbZgx9yoT8Zpag9V+J9GML9 ztFWkl2kdzlcx9liuD0qkRPuhZ121n5n0Q6PZIG6VxYLImovYp98PHVUewV7DCEWUyPq rXXlIxDnOdrzWxWsstbgQYN7oqNqjCOR9tmEWD0BSuZyiUGx/Z4ro9J+I8DtLzQPb2Kg jPag9FJU9pA/e4OEUSMrMmaK68KQT90GNjGF7I+QioJc+Vxtw8gzC1QIJHWxgNSRiUnH b/Cg==
MIME-Version: 1.0
Received: by 10.204.145.78 with SMTP id c14mr837771bkv.43.1338032167065; Sat, 26 May 2012 04:36:07 -0700 (PDT)
Received: by 10.204.240.143 with HTTP; Sat, 26 May 2012 04:36:07 -0700 (PDT)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436651A42A@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B16804296739436651A42A@TK5EX14MBXC284.redmond.corp.microsoft.com>
Date: Sat, 26 May 2012 20:36:07 +0900
Message-ID: 
From: Nat Sakimura 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=00151759338c0418bd04c0eee440
Cc: "oauth@ietf.org" , "jose@ietf.org" 
Subject: Re: [jose] Dominick Baier's JWT implementation
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.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, 26 May 2012 11:36:09 -0000

--00151759338c0418bd04c0eee440
Content-Type: text/plain; charset=ISO-8859-1

So that you know, Edmund Jay has implemented JWS including GCM for PHP.

On Sat, May 26, 2012 at 8:10 AM, Mike Jones wrote:

>  FYI - Dominick Baier sent me a note letting me know about his JWT
> implementation:****
>
> ** **
>
>
> http://leastprivilege.com/2012/05/25/json-web-token-jwt-support-in-thinktecture-identitymodel/
> ****
>
> ** **
>
> Have a good weekend, everyone!****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> _______________________________________________
> 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

--00151759338c0418bd04c0eee440
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

So that you know, Edmund Jay has implemented JWS including GCM for PHP.=A0<=
br>
On Sat, May 26, 2012 at 8:10 AM, Mike Jon=
es <Michael.Jones@microsoft.com> wrote:













FYI - Dominick Baier sent me a not=
e letting me know about his JWT implementation:


=A0


http://leastprivilege.com/2012/05/25/j=
son-web-token-jwt-support-in-thinktecture-identitymodel/<=
u>



=A0


Have a good weekend, everyone!


=A0


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







_______________________________________________

jose mailing list

jose@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/jose





-- 
Nat Saki=
mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
=




--00151759338c0418bd04c0eee440--

From leifj@mnt.se  Sun May 27 13:32: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 6AA3521F854E for ; Sun, 27 May 2012 13:32:49 -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 LbbCNujEAVAB for ; Sun, 27 May 2012 13:32:48 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 05F4421F8547 for ; Sun, 27 May 2012 13:32:47 -0700 (PDT)
Received: by lbbgo11 with SMTP id go11so1795335lbb.31 for ; Sun, 27 May 2012 13:32:46 -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=FGeTvLIGpjFxQT4TZ5IsleKDnq2FlXNefvFwRSXKvJs=; b=RDiEDXtT3ZtKAQsZQcFhsIcEsYdYUEHZINgSNMVEoumgxIDwSS52yDfqgqTRD0XzGv oBWVF93INejphf4A4hNhx0eAg0i/c9VFOZrUdG//Nom2Cmb2L4V0PfppCXwwP7/C2nlo duXVgDe/qidwPX5Q5phW7fkyQeC8oS3vD4lUsgnt1fqJuT/yOslq4fPDDlhUS0cVypFd zZQ2AKudcXKhExPyfMVEgvNODPwi13W5gU8d0YIP4F3BHsLzZyzWwhMfou4XWUAnZpQR 0hLx/4DJmzZTP6NwW9fX/E5XeMN6XjFJ4r3+6LkJ46ki3EVnw1zKPNy19s9V0MNAMz+Y N9OA==
Received: by 10.152.125.116 with SMTP id mp20mr5985504lab.19.1338150766542; Sun, 27 May 2012 13:32:46 -0700 (PDT)
Received: from [10.0.0.232] (ua-83-227-179-169.cust.bredbandsbolaget.se. [83.227.179.169]) by mx.google.com with ESMTPS id hz16sm15057554lab.6.2012.05.27.13.32.44 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 May 2012 13:32:45 -0700 (PDT)
References: <4E1F6AAD24975D4BA5B16804296739436651A42A@TK5EX14MBXC284.redmond.corp.microsoft.com> 
In-Reply-To: 
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary=Apple-Mail-EFFFCB7F-5E11-48FA-95C6-ABF8839B7C0F
Message-Id: <9146C20B-A06A-4EB7-B515-F008AB136398@mnt.se>
X-Mailer: iPad Mail (9B206)
From: Leif Johansson 
Date: Sun, 27 May 2012 22:32:40 +0200
To: Nat Sakimura 
X-Gm-Message-State: ALoCoQmlNFhL3nUFFQpX7DGkfk1OJwPYQcauxWQ5oDnNwaurM6O5xh8hlSzYSwvPZUvmoJzuZO94
Cc: Mike Jones , "oauth@ietf.org" , "jose@ietf.org" 
Subject: Re: [jose] Dominick Baier's JWT implementation
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.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, 27 May 2012 20:32:49 -0000

--Apple-Mail-EFFFCB7F-5E11-48FA-95C6-ABF8839B7C0F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On that topic: what is the most current/complete implementation for python?



26 maj 2012 kl. 13:36 skrev Nat Sakimura :

> So that you know, Edmund Jay has implemented JWS including GCM for PHP.=20=

>=20
> On Sat, May 26, 2012 at 8:10 AM, Mike Jones  w=
rote:
> FYI - Dominick Baier sent me a note letting me know about his JWT implemen=
tation:
>=20
> =20
>=20
> http://leastprivilege.com/2012/05/25/json-web-token-jwt-support-in-thinkte=
cture-identitymodel/
>=20
> =20
>=20
> Have a good weekend, everyone!
>=20
> =20
>=20
>                                                             -- Mike
>=20
> =20
>=20
>=20
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>=20
>=20
>=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

--Apple-Mail-EFFFCB7F-5E11-48FA-95C6-ABF8839B7C0F
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=utf-8


On that topic: what is the most current/complete implementation for python?



26 maj 2012 kl. 13:36 skrev Nat Sakimura <sakimura@gmail.com>:

So that you know, Edmund Jay has implemented JWS including GCM for PHP. 

On Sat, May 26, 2012 at 8:10 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:













FYI - Dominick Baier sent me a note letting me know about his JWT implementation:


 


http://leastprivilege.com/2012/05/25/json-web-token-jwt-support-in-thinktecture-identitymodel/



 


Have a good weekend, everyone!


 


                                                            -- Mike


 







_______________________________________________

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

--Apple-Mail-EFFFCB7F-5E11-48FA-95C6-ABF8839B7C0F--

From turners@ieca.com  Sun May 27 18:18: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 318BD21F8585 for ; Sun, 27 May 2012 18:18:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.382
X-Spam-Level: 
X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2amsJ97Oj4MI for ; Sun, 27 May 2012 18:18:32 -0700 (PDT)
Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [69.56.224.23]) by ietfa.amsl.com (Postfix) with ESMTP id BC92221F8577 for ; Sun, 27 May 2012 18:18:32 -0700 (PDT)
Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id 3802175983E04; Sun, 27 May 2012 20:18:32 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway07.websitewelcome.com (Postfix) with ESMTP id 2D66075983DE1 for ; Sun, 27 May 2012 20:18:32 -0500 (CDT)
Received: from [71.191.15.83] (port=36702 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SYobP-0006Cb-Qh for jose@ietf.org; Sun, 27 May 2012 20:18:32 -0500
Message-ID: <4FC2D266.4060606@ieca.com>
Date: Sun, 27 May 2012 21:18:30 -0400
From: Sean Turner 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: jose@ietf.org
References: <20120522005309.cc40c4f3d92d2001859047cd8cabb9ab.67beb32ca3.wbe@email07.europe.secureserver.net>
In-Reply-To: <20120522005309.cc40c4f3d92d2001859047cd8cabb9ab.67beb32ca3.wbe@email07.europe.secureserver.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator1743.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (thunderfish.local) [71.191.15.83]:36702
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 1
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 May 2012 01:18:33 -0000

On 5/22/12 3:53 AM, Vladimir Dzhuvinov / NimbusDS wrote:
>
>>> 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"
>
> +1 for deprecating none.
>
> The same information can be expressed by simply omitting "alg". This
> makes plain JWTs nimbler too. I see no problem with having empty headers
> for plain JWTs.
>
> Also, by removing "none", "alg" would become consistent with the rest of
> the parameters which don't have "none" values (we don't have
> "enc":"none", etc.). Very much like the recent change to "zip" (JWS,
> section 4.1.6) which no longer has the (optional) "none": it's either
> "zip":"DEF" or nothing.

Just make sure to explain what it means when alg is omitted.  Assume 
this would apply equally to both JSW and JWE?

spt

From vladimir@nimbusds.com  Sun May 27 22:47: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 2AAB421F8597 for ; Sun, 27 May 2012 22:47:18 -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 JDNTtjsCJVtP for ; Sun, 27 May 2012 22:47:17 -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 E6FFA21F8595 for ; Sun, 27 May 2012 22:47:16 -0700 (PDT)
Received: (qmail 2537 invoked from network); 28 May 2012 05:47:10 -0000
Received: from unknown (HELO localhost) (188.121.52.246) by n1plwbeout07-01.prod.ams1.secureserver.net with SMTP; 28 May 2012 05:47:10 -0000
Received: (qmail 2723 invoked by uid 99); 28 May 2012 05:47:10 -0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Originating-IP: 95.43.49.162
User-Agent: Workspace Webmail 5.6.17
Message-Id: <20120527224709.cc40c4f3d92d2001859047cd8cabb9ab.7bdf13f113.wbe@email07.europe.secureserver.net>
From: "Vladimir Dzhuvinov / NimbusDS" 
To: jose@ietf.org
Date: Sun, 27 May 2012 22:47: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: Mon, 28 May 2012 05:47:18 -0000

> On 5/22/12 3:53 AM, Vladimir Dzhuvinov / NimbusDS wrote:=0A> >=0A> >>> Se=
ction 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 fo=
r removing "none"=0A> >=0A> > +1 for deprecating none.=0A> >=0A> > The same=
 information can be expressed by simply omitting "alg". This=0A> > makes pl=
ain JWTs nimbler too. I see no problem with having empty headers=0A> > for =
plain JWTs.=0A> >=0A> > Also, by removing "none", "alg" would become consis=
tent with the rest of=0A> > the parameters which don't have "none" values (=
we don't have=0A> > "enc":"none", etc.). Very much like the recent change t=
o "zip" (JWS,=0A> > section 4.1.6) which no longer has the (optional) "none=
": it's either=0A> > "zip":"DEF" or nothing.=0A> =0A> Just make sure to exp=
lain what it means when alg is omitted. Assume =0A> this would apply equall=
y to both JSW and JWE?=0A> =0A> spt=0A=0AMy understanding is that this shou=
ld actually be explained in the JSON=0AWeb Token (JWT) spec where the conce=
pt of plain tokens is originally=0Aintroduced. Therefore, the case of a mis=
sing "alg" should fall outside=0Athe scope of the JWS and JWE specs.=0A=0AV=
ladimir=0A=0A--=0AVladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds=
.com=0A=0A

From roland.hedberg@adm.umu.se  Sun May 27 23:49:16 2012
Return-Path: 
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838F521F84FF; Sun, 27 May 2012 23:49:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.76
X-Spam-Level: 
X-Spam-Status: No, score=-4.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_SE=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 BaNwuJXmiFX1; Sun, 27 May 2012 23:49:16 -0700 (PDT)
Received: from smtp1.umu.se (kaffir.umdc.umu.se [130.239.2.98]) by ietfa.amsl.com (Postfix) with ESMTP id B953221F847C; Sun, 27 May 2012 23:49:15 -0700 (PDT)
Received: by smtp1.umu.se (Postfix, from userid 8) id 18824176; Mon, 28 May 2012 08:49:14 +0200 (CEST)
X-Scanned-By: ClamAV
Received: from lingon.ladok.umu.se (lingon.ladok.umu.se [130.239.200.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.umu.se (Postfix) with ESMTP id E733E109; Mon, 28 May 2012 08:49:13 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=iso-8859-1
From: Roland Hedberg 
In-Reply-To: <9146C20B-A06A-4EB7-B515-F008AB136398@mnt.se>
Date: Mon, 28 May 2012 08:49:25 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <354C79A3-6A11-4B49-86FA-830269B99767@adm.umu.se>
References: <4E1F6AAD24975D4BA5B16804296739436651A42A@TK5EX14MBXC284.redmond.corp.microsoft.com>  <9146C20B-A06A-4EB7-B515-F008AB136398@mnt.se>
To: Leif Johansson 
X-Mailer: Apple Mail (2.1278)
Cc: Mike Jones , Nat Sakimura , "oauth@ietf.org" , "jose@ietf.org" 
Subject: Re: [jose] Dominick Baier's JWT implementation
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.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, 28 May 2012 06:49:16 -0000

27 maj 2012 kl. 22:32 skrev Leif Johansson:

> On that topic: what is the most current/complete implementation for =
python?

I did a search half a year ago for JWT implementations in Python.
Found two: PyJWT by Jeff Lindsay and jwt-python by Andrew Ekstedt.

I used parts from both of them and did my own version.
It's part of my OpenID Connect implementation.

-- Roland
------------------------------------------------------
Roland Hedberg
IT Architect/Senior Researcher
ICT Services and System Development (ITS)=20
Ume=E5 University=20
SE-901 87 Ume=E5, Sweden=09
Phone +46 90 786 68 44
Mobile +46 70 696 68 44=20
www.its.umu.se=20


From turners@ieca.com  Mon May 28 08:21:36 2012
Return-Path: 
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F4521F8622 for ; Mon, 28 May 2012 08:21:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.365
X-Spam-Level: 
X-Spam-Status: No, score=-102.365 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XagFJZAV8LSK for ; Mon, 28 May 2012 08:21:36 -0700 (PDT)
Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [69.56.144.11]) by ietfa.amsl.com (Postfix) with ESMTP id 21B3621F85C3 for ; Mon, 28 May 2012 08:21:36 -0700 (PDT)
Received: by gateway11.websitewelcome.com (Postfix, from userid 5011) id B23BE6EE175B3; Mon, 28 May 2012 10:21:35 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway11.websitewelcome.com (Postfix) with ESMTP id A240A6EE17583 for ; Mon, 28 May 2012 10:21:35 -0500 (CDT)
Received: from [71.191.15.83] (port=33450 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SZ1lH-0006sq-93; Mon, 28 May 2012 10:21:35 -0500
Message-ID: <4FC397FE.3040001@ieca.com>
Date: Mon, 28 May 2012 11:21:34 -0400
From: Sean Turner 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Vladimir Dzhuvinov / NimbusDS 
References: <20120527224709.cc40c4f3d92d2001859047cd8cabb9ab.7bdf13f113.wbe@email07.europe.secureserver.net>
In-Reply-To: <20120527224709.cc40c4f3d92d2001859047cd8cabb9ab.7bdf13f113.wbe@email07.europe.secureserver.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator1743.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (thunderfish.local) [71.191.15.83]:33450
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 1
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Cc: jose@ietf.org
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 May 2012 15:21:36 -0000

On 5/28/12 1:47 AM, Vladimir Dzhuvinov / NimbusDS wrote:
>> On 5/22/12 3:53 AM, Vladimir Dzhuvinov / NimbusDS wrote:
>>>
>>>>> 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"
>>>
>>> +1 for deprecating none.
>>>
>>> The same information can be expressed by simply omitting "alg". This
>>> makes plain JWTs nimbler too. I see no problem with having empty headers
>>> for plain JWTs.
>>>
>>> Also, by removing "none", "alg" would become consistent with the rest of
>>> the parameters which don't have "none" values (we don't have
>>> "enc":"none", etc.). Very much like the recent change to "zip" (JWS,
>>> section 4.1.6) which no longer has the (optional) "none": it's either
>>> "zip":"DEF" or nothing.
>>
>> Just make sure to explain what it means when alg is omitted. Assume
>> this would apply equally to both JSW and JWE?
>>
>> spt
>
> My understanding is that this should actually be explained in the JSON
> Web Token (JWT) spec where the concept of plain tokens is originally
> introduced. Therefore, the case of a missing "alg" should fall outside
> the scope of the JWS and JWE specs.

That's one possibility but then you're introducing a normative 
reference.  If draft-ietf-jose-json-web-algorithms, is going to retain 
the section on creating plaintext JWS then it's worth saying how empty 
would be handled - and then you can avoid the reference.

spt


From Michael.Jones@microsoft.com  Mon May 28 09:44: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 4956E21F866C for ; Mon, 28 May 2012 09:44:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.735
X-Spam-Level: 
X-Spam-Status: No, score=-3.735 tagged_above=-999 required=5 tests=[AWL=-0.136, 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 BiMiiquYp-Ll for ; Mon, 28 May 2012 09:44:06 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7FC21F866B for ; Mon, 28 May 2012 09:44:06 -0700 (PDT)
Received: from mail44-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Mon, 28 May 2012 16:43:45 +0000
Received: from mail44-va3 (localhost [127.0.0.1])	by mail44-va3-R.bigfish.com (Postfix) with ESMTP id 3747238027A; Mon, 28 May 2012 16:43:45 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI
X-SpamScore: -36
X-BigFish: VS-36(zzbb2dI9371I542M1432N98dKzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah)
Received-SPF: pass (mail44-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=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail44-va3 (localhost.localdomain [127.0.0.1]) by mail44-va3 (MessageSwitch) id 1338223424606137_27279; Mon, 28 May 2012 16:43:44 +0000 (UTC)
Received: from VA3EHSMHS019.bigfish.com (unknown [10.7.14.238])	by mail44-va3.bigfish.com (Postfix) with ESMTP id 86EB31E004A; Mon, 28 May 2012 16:43:44 +0000 (UTC)
Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS019.bigfish.com (10.7.99.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 28 May 2012 16:43:43 +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; Mon, 28 May 2012 16:44:02 +0000
From: Mike Jones 
To: Sean Turner , Vladimir Dzhuvinov / NimbusDS 
Thread-Topic: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
Thread-Index: AQHNPJVSCAHMzxPmQDC/RwzlQzAQz5bfUfcAgAAURHA=
Date: Mon, 28 May 2012 16:44:01 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436651CC6A@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <20120527224709.cc40c4f3d92d2001859047cd8cabb9ab.7bdf13f113.wbe@email07.europe.secureserver.net> <4FC397FE.3040001@ieca.com>
In-Reply-To: <4FC397FE.3040001@ieca.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.36]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "jose@ietf.org" 
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 May 2012 16:44:07 -0000

For what it's worth, "alg":"none" was moved from JWT to JWS based upon Jim =
Schaad's suggestion in http://www.ietf.org/mail-archive/web/jose/current/ms=
g00365.html for closing the open issue about whether it belongs in JWT or J=
WS.  In it, he wrote:

[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 believe his rationale was correct and has been proven out by events.  At =
this point I now of several usages of "none" both within JWTs, and signific=
antly, in at least one context where the structure is a JWS but *not* a JWT=
.  I believe Jim was right to suggest that "alg":"none" belongs in the Algo=
rithms specification.

				Best wishes,
				-- Mike

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Sea=
n Turner
Sent: Monday, May 28, 2012 8:22 AM
To: Vladimir Dzhuvinov / NimbusDS
Cc: jose@ietf.org
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

On 5/28/12 1:47 AM, Vladimir Dzhuvinov / NimbusDS wrote:
>> On 5/22/12 3:53 AM, Vladimir Dzhuvinov / NimbusDS wrote:
>>>
>>>>> Section 3.1
>>>>>
>>>>> 1. I am not overly happy with the existence of a "none" algorithm.=20
>>>>> Does it really need to exist?
>>>>
>>>> +1 for removing "none"
>>>
>>> +1 for deprecating none.
>>>
>>> The same information can be expressed by simply omitting "alg". This=20
>>> makes plain JWTs nimbler too. I see no problem with having empty=20
>>> headers for plain JWTs.
>>>
>>> Also, by removing "none", "alg" would become consistent with the=20
>>> rest of the parameters which don't have "none" values (we don't have=20
>>> "enc":"none", etc.). Very much like the recent change to "zip" (JWS,=20
>>> section 4.1.6) which no longer has the (optional) "none": it's=20
>>> either "zip":"DEF" or nothing.
>>
>> Just make sure to explain what it means when alg is omitted. Assume=20
>> this would apply equally to both JSW and JWE?
>>
>> spt
>
> My understanding is that this should actually be explained in the JSON=20
> Web Token (JWT) spec where the concept of plain tokens is originally=20
> introduced. Therefore, the case of a missing "alg" should fall outside=20
> the scope of the JWS and JWE specs.

That's one possibility but then you're introducing a normative reference.  =
If draft-ietf-jose-json-web-algorithms, is going to retain the section on c=
reating plaintext JWS then it's worth saying how empty would be handled - a=
nd then you can avoid the reference.

spt

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



From turners@ieca.com  Mon May 28 10:26:17 2012
Return-Path: 
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A636421F866D for ; Mon, 28 May 2012 10:26:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.353
X-Spam-Level: 
X-Spam-Status: No, score=-102.353 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGlLiJm+6rJV for ; Mon, 28 May 2012 10:26:17 -0700 (PDT)
Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [67.18.62.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF5021F866B for ; Mon, 28 May 2012 10:26:17 -0700 (PDT)
Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id B424E769B7DBD; Mon, 28 May 2012 12:26:16 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway07.websitewelcome.com (Postfix) with ESMTP id 9EEFF769B7D57 for ; Mon, 28 May 2012 12:26:16 -0500 (CDT)
Received: from [71.191.15.83] (port=34519 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SZ3hw-0006bX-1p; Mon, 28 May 2012 12:26:16 -0500
Message-ID: <4FC3B537.5040909@ieca.com>
Date: Mon, 28 May 2012 13:26:15 -0400
From: Sean Turner 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Mike Jones 
References: <20120527224709.cc40c4f3d92d2001859047cd8cabb9ab.7bdf13f113.wbe@email07.europe.secureserver.net> <4FC397FE.3040001@ieca.com> <4E1F6AAD24975D4BA5B16804296739436651CC6A@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436651CC6A@TK5EX14MBXC284.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator1743.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (thunderfish.local) [71.191.15.83]:34519
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 3
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Cc: "jose@ietf.org" , Vladimir Dzhuvinov / NimbusDS 
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 May 2012 17:26:17 -0000

I think it's fine that it stays where it is, but if you decide to get 
rid of it you'll need to say something about what omitting alg means in 
this draft.

spt

On 5/28/12 12:44 PM, Mike Jones wrote:
> For what it's worth, "alg":"none" was moved from JWT to JWS based upon Jim Schaad's suggestion in http://www.ietf.org/mail-archive/web/jose/current/msg00365.html for closing the open issue about whether it belongs in JWT or JWS.  In it, he wrote:
>
> [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 believe his rationale was correct and has been proven out by events.  At this point I now of several usages of "none" both within JWTs, and significantly, in at least one context where the structure is a JWS but *not* a JWT.  I believe Jim was right to suggest that "alg":"none" belongs in the Algorithms specification.
>
> 				Best wishes,
> 				-- Mike
>
> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Sean Turner
> Sent: Monday, May 28, 2012 8:22 AM
> To: Vladimir Dzhuvinov / NimbusDS
> Cc: jose@ietf.org
> Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
>
> On 5/28/12 1:47 AM, Vladimir Dzhuvinov / NimbusDS wrote:
>>> On 5/22/12 3:53 AM, Vladimir Dzhuvinov / NimbusDS wrote:
>>>>
>>>>>> 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"
>>>>
>>>> +1 for deprecating none.
>>>>
>>>> The same information can be expressed by simply omitting "alg". This
>>>> makes plain JWTs nimbler too. I see no problem with having empty
>>>> headers for plain JWTs.
>>>>
>>>> Also, by removing "none", "alg" would become consistent with the
>>>> rest of the parameters which don't have "none" values (we don't have
>>>> "enc":"none", etc.). Very much like the recent change to "zip" (JWS,
>>>> section 4.1.6) which no longer has the (optional) "none": it's
>>>> either "zip":"DEF" or nothing.
>>>
>>> Just make sure to explain what it means when alg is omitted. Assume
>>> this would apply equally to both JSW and JWE?
>>>
>>> spt
>>
>> My understanding is that this should actually be explained in the JSON
>> Web Token (JWT) spec where the concept of plain tokens is originally
>> introduced. Therefore, the case of a missing "alg" should fall outside
>> the scope of the JWS and JWE specs.
>
> That's one possibility but then you're introducing a normative reference.  If draft-ietf-jose-json-web-algorithms, is going to retain the section on creating plaintext JWS then it's worth saying how empty would be handled - and then you can avoid the reference.
>
> spt
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>
>

From turners@ieca.com  Mon May 28 10:36: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 7C8D221F869A for ; Mon, 28 May 2012 10:36:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.864
X-Spam-Level: 
X-Spam-Status: No, score=-101.864 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 d-R3HCZ71Pme for ; Mon, 28 May 2012 10:36:19 -0700 (PDT)
Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [64.5.38.13]) by ietfa.amsl.com (Postfix) with ESMTP id B862B21F8699 for ; Mon, 28 May 2012 10:36:19 -0700 (PDT)
Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id 336DD73684F84; Mon, 28 May 2012 12:36:19 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway09.websitewelcome.com (Postfix) with ESMTP id 2583E73684F64 for ; Mon, 28 May 2012 12:36:19 -0500 (CDT)
Received: from [71.191.15.83] (port=40170 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SZ3re-0002ML-TV for jose@ietf.org; Mon, 28 May 2012 12:36:19 -0500
Message-ID: <4FC3B77F.6080803@ieca.com>
Date: Mon, 28 May 2012 13:35:59 -0400
From: Sean Turner 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
CC: jose@ietf.org
References: <20120512234350.9160.80183.idtracker@ietfa.amsl.com>
In-Reply-To: <20120512234350.9160.80183.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator1743.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (thunderfish.local) [71.191.15.83]:40170
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 7
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
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: Mon, 28 May 2012 17:36:20 -0000

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

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

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

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

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

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

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

spt

From turners@ieca.com  Mon May 28 10:36: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 B991B21F8661 for ; Mon, 28 May 2012 10:36:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.137
X-Spam-Level: 
X-Spam-Status: No, score=-101.137 tagged_above=-999 required=5 tests=[AWL=-1.172, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MANGLED_SAVELE=2.3, 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 ZqZdrtM8bU9W for ; Mon, 28 May 2012 10:36:18 -0700 (PDT)
Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [67.18.21.16]) by ietfa.amsl.com (Postfix) with ESMTP id 926B021F8665 for ; Mon, 28 May 2012 10:36:18 -0700 (PDT)
Received: by gateway11.websitewelcome.com (Postfix, from userid 5011) id DC1D96F0D1C50; Mon, 28 May 2012 12:36:17 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway11.websitewelcome.com (Postfix) with ESMTP id CE1D76F0D1C30 for ; Mon, 28 May 2012 12:36:17 -0500 (CDT)
Received: from [71.191.15.83] (port=41655 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SZ3rc-0002Lh-UW for jose@ietf.org; Mon, 28 May 2012 12:36:17 -0500
Message-ID: <4FC3B77A.7060107@ieca.com>
Date: Mon, 28 May 2012 13:35:54 -0400
From: Sean Turner 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: jose@ietf.org
References: <20120512234538.9868.10035.idtracker@ietfa.amsl.com>
In-Reply-To: <20120512234538.9868.10035.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator1743.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (thunderfish.local) [71.191.15.83]:41655
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 6
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
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, 28 May 2012 17:36:21 -0000

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

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

  in the face of changes in
  the set of required, recommended, optional, and deprecated algorithms
  over time.

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

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

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

4) s3: Expand MAC

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

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

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

8) s3.1: HMAC SHA-256 is the default?  UGH!

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

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

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

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

The HMAC SHA-256 MAC is generated as follows:

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

- use HMAC-256 as the hash algorithm H

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

Ditto for the validation bit.

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

14) Not sure we need the following:

  Note that while Section 8 of RFC 3447 [RFC3447] explicitly calls for
  people not to adopt RSASSA-PKCS1 for new applications and instead
  requests that people transition to RSASSA-PSS, for interoperability
  reasons, this specification does use RSASSA-PKCS1 because it commonly
  implemented.

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

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

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

17) s3.4: In this step:

  2.  The output of the base64url decoding MUST be a 64 byte array.

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

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

  The consequence of this is that one must validate an ECDSA digital
  signature by submitting the previously specified inputs to an ECDSA
  validator.

SHS points to ASNI for signature verification and I don't have that 
handy so I went to the Suite B implementers guide 
(http://www.nsa.gov/ia/_files/ecdsa.pdf) to look for the signature ECDSA 
verification steps.  I didn't see k as being needed when you verify.

19) s3.5: Is this section for authenticated encryption algs or because 
the lower layers are taking care of authentication/integrity?

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

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

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

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

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

20.2) Algorithm naming: Being new to the block, I'm trying to understand 
why we can't reuse an already well know identifier for the algs.  (just 
picking on the first set of algs but this applies to them all) 
HMAC-SHA256 is pretty well understood so I'm wondering whether it is 
really worth saving five bytes over HS256?  Ditto for RSAwithSHA* and 
ECDSAwithSHA*;  I guess you're saving more with these, but I question 
whether it's really worth adding yet another way to name an alg.

20.3) Duplication identifiers (might partially go away based on 20.2): 
(just picking on the first set of algs but this applies to them all) 
What are we going to do about duplicate identifiers?  Right now 
HMAC-SHA256, HMAC-SHA384, and HMAC-SHA512 are defined as well as 
ECDSA/RSA with SHA-256, etc. in XMLDsig.  There's also some defined by 
RSA in RFC 4231.  Don't we need to say something about preferring one 
over the other?

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

  | RSA1_5    | RSAES-PKCS1-1.5 [RFC3447]                             |
  | RSA-OAEP  | RSAES-Optimal Asymmetric Encryption Padding (OAEP)    |
  |           | (OAEP) [RFC3447]                                      |

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

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

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

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

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

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

27) s4.3: r//>/

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

    r/It is RECOMMENDED that
    implementations also support the RSA SHA-256 and ECDSA P-256 SHA-256
    algorithms./It is RECOMMENDED that
    implementations also support the HMAC SHA-256 and HMAC SHA-384
    algorithms.

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

30) s4.4: r/RSA using RSA-PKCS1-1.5 padding, as defined in RFC 3447 
[RFC3447]/RSAES-PKCS1-v1_5 [RFC3447]

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

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

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

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

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

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

37) s5.3.2: Should we specifying that e=65537 must be used?

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

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

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

  Receiving agents that validate signatures and sending agents that
  encrypt messages need to be cautious of cryptographic processing
  usage when validating signatures and encrypting messages using keys
  larger than those mandated in this specification.  An attacker could
  send certificates with keys that would result in excessive
  cryptographic processing, for example, keys larger than those
  mandated in this specification, which could swamp the processing
  element.  Agents that use such keys without first validating the
  certificate to a trust anchor are advised to have some sort of
  cryptographic resource management system to prevent such attacks.

Some other motherhood and apple pie that you might also include:

  All of the security issues faced by any cryptographic application
  must be faced by a JWS/JWE agent.  Among these issues are protecting
  the user's private key, preventing various attacks, and helping the
  user avoid mistakes such as inadvertently encrypting a message for
  the wrong recipient.  The entire list of security considerations is
  beyond the scope of this document, but some significant concerns are
  listed here.

spt

From turners@ieca.com  Mon May 28 10:36: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 9F73721F8661 for ; Mon, 28 May 2012 10:36:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.031
X-Spam-Level: 
X-Spam-Status: No, score=-101.031 tagged_above=-999 required=5 tests=[AWL=-1.066, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MANGLED_SAVELE=2.3, 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 udl5DFtMTLoH for ; Mon, 28 May 2012 10:36:21 -0700 (PDT)
Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.56.236.20]) by ietfa.amsl.com (Postfix) with ESMTP id DFB5D21F8665 for ; Mon, 28 May 2012 10:36:20 -0700 (PDT)
Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id 6F1EE72CFA97B; Mon, 28 May 2012 12:36:20 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway02.websitewelcome.com (Postfix) with ESMTP id 64D7B72CFA95B for ; Mon, 28 May 2012 12:36:20 -0500 (CDT)
Received: from [71.191.15.83] (port=33388 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SZ3rf-0002Mj-UL for jose@ietf.org; Mon, 28 May 2012 12:36:20 -0500
Message-ID: <4FC3B783.1050101@ieca.com>
Date: Mon, 28 May 2012 13:36:03 -0400
From: Sean Turner 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: jose@ietf.org
References: <20120512234138.8590.1100.idtracker@ietfa.amsl.com>
In-Reply-To: <20120512234138.8590.1100.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator1743.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (thunderfish.local) [71.191.15.83]:33388
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 8
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-encryption-02.txt
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 May 2012 17:36:21 -0000

Here are some comments:

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

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

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

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

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

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

6) s4: Contains the following:

  The Header Parameter Names within this object
  MUST be unique; JWEs with duplicate Header Parameter Names MUST be
  rejected.

I'd prefer to see that if this is actually enforceable (not sure it is) 
that an error gets thrown or the message gets rejected.

7) s4: How are the different types of parameters (res,pub,priv) named? 
Is there going to be some kind of designator in front of them?  If so, 
then I would definitely try to get an early review from some Apps folks 
because they're deprecating X-.

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

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

  The processing of the "alg/enc" header parameter requires that
  the value MUST be one that is both supported ..

Not sure what this means?

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

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

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

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

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

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

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

and add the following normative reference

   [X.690]  ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
            Information technology - ASN.1 encoding rules:
            Specification of Basic Encoding Rules (BER), Canonical
            Encoding Rules (CER) and Distinguished Encoding Rules
            (DER).

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

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

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

   While hash algorithms provide collision resistance, this property
   is not needed for key identifiers or thumbprints.

19) s11.1: encoding considerations: isn't it base64url encoded?
            applications that use this media type: is it just OpenId 
connect or can this be generalized a bit?

spt


From turners@ieca.com  Mon May 28 10:36: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 E39E421F869A for ; Mon, 28 May 2012 10:36:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.092
X-Spam-Level: 
X-Spam-Status: No, score=-102.092 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WeKV-u4hO7D for ; Mon, 28 May 2012 10:36:22 -0700 (PDT)
Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.93.35.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4229621F8698 for ; Mon, 28 May 2012 10:36:22 -0700 (PDT)
Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 9AA9A6F591862; Mon, 28 May 2012 12:36:21 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 8B4666F591838 for ; Mon, 28 May 2012 12:36:21 -0500 (CDT)
Received: from [71.191.15.83] (port=33543 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SZ3rh-0002NC-4A for jose@ietf.org; Mon, 28 May 2012 12:36:21 -0500
Message-ID: <4FC3B788.7060003@ieca.com>
Date: Mon, 28 May 2012 13:36:08 -0400
From: Sean Turner 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: jose@ietf.org
References: <20120512233953.7770.62608.idtracker@ietfa.amsl.com>
In-Reply-To: <20120512233953.7770.62608.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator1743.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (thunderfish.local) [71.191.15.83]:33543
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 9
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Subject: Re: [jose] I-D Action: draft-ietf-jose-json-web-signature-02.txt
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 May 2012 17:36:23 -0000

Here are some comments on the draft (a lot of these are duplicates from 
web-encryption):

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

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

3) s4: Contains the following:

  The Header Parameter Names within this object
  MUST be unique; JWEs with duplicate Header Parameter Names MUST be
  rejected.

I'd prefer to see that if this is actually enforceable (not sure it is) 
that an error gets thrown or the message gets rejected.

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

4) s4: How are the different types of parameters (res,pub,priv) named? 
Is there going to be some kind of designator in front of them?  If so, 
then I would definitely try to get an early review from some Apps folks 
because they're deprecating X-.

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

6) s4.1.2/s4.1.4: Add normative reference to [RFC3986] for absolute URL. 
  And I think they call it a URI.

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

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

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

and add the following normative reference

   [X.690]  ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
            Information technology - ASN.1 encoding rules:
            Specification of Basic Encoding Rules (BER), Canonical
            Encoding Rules (CER) and Distinguished Encoding Rules
            (DER).

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

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

   While hash algorithms provide collision resistance, this property
   is not needed for key identifiers or thumbprints.


11) s11.1: encoding considerations: isn't it base64url encoded?
            applications that use this media type: is it just OpenId 
connect or can this be generalized a bit?

spt

From ietf@augustcellars.com  Mon May 28 16:09:03 2012
Return-Path: 
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D5121F8712 for ; Mon, 28 May 2012 16:09: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 uGZNOifi7Fo3 for ; Mon, 28 May 2012 16:09:02 -0700 (PDT)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 310E921F8710 for ; Mon, 28 May 2012 16:08:57 -0700 (PDT)
Received: from Tobias (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (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 DBB5038F0E; Mon, 28 May 2012 16:08:56 -0700 (PDT)
From: "Jim Schaad" 
To: "'Mike Jones'" , "'Sean Turner'" , "'Vladimir Dzhuvinov / NimbusDS'" 
References: <20120527224709.cc40c4f3d92d2001859047cd8cabb9ab.7bdf13f113.wbe@email07.europe.secureserver.net>	<4FC397FE.3040001@ieca.com> <4E1F6AAD24975D4BA5B16804296739436651CC6A@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436651CC6A@TK5EX14MBXC284.redmond.corp.microsoft.com>
Date: Mon, 28 May 2012 16:07:49 -0700
Message-ID: <047401cd3d26$b4152a70$1c3f7f50$@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: AQIdT9Rs/SJOJh5Xk6n2z6Qj+ZffaAIS1VXgAeDb47uWIA2lQA==
Content-Language: en-us
Cc: jose@ietf.org
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 May 2012 23:09:03 -0000

I agree that if this is going to be done as an alg notation it should be in
the algorithm draft.

I am not so sure that I think that marking this as an algorithm is a good
idea and that should be discussed.  It is possible that we should talk about
some type of degenerate signature structure where we can know that it is a
signature structure but that there is no signature algorithm might be
better.

One possible way of doing this might be to have a field which says
"unsigned: true" instead.

Jim


> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> Mike Jones
> Sent: Monday, May 28, 2012 9:44 AM
> To: Sean Turner; Vladimir Dzhuvinov / NimbusDS
> Cc: jose@ietf.org
> Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
> 
> For what it's worth, "alg":"none" was moved from JWT to JWS based upon
> Jim Schaad's suggestion in http://www.ietf.org/mail-
> archive/web/jose/current/msg00365.html for closing the open issue about
> whether it belongs in JWT or JWS.  In it, he wrote:
> 
> [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 believe his rationale was correct and has been proven out by events.  At
this
> point I now of several usages of "none" both within JWTs, and
significantly, in
> at least one context where the structure is a JWS but *not* a JWT.  I
believe
> Jim was right to suggest that "alg":"none" belongs in the Algorithms
> specification.
> 
> 				Best wishes,
> 				-- Mike
> 
> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> Sean Turner
> Sent: Monday, May 28, 2012 8:22 AM
> To: Vladimir Dzhuvinov / NimbusDS
> Cc: jose@ietf.org
> Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
> 
> On 5/28/12 1:47 AM, Vladimir Dzhuvinov / NimbusDS wrote:
> >> On 5/22/12 3:53 AM, Vladimir Dzhuvinov / NimbusDS wrote:
> >>>
> >>>>> 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"
> >>>
> >>> +1 for deprecating none.
> >>>
> >>> The same information can be expressed by simply omitting "alg". This
> >>> makes plain JWTs nimbler too. I see no problem with having empty
> >>> headers for plain JWTs.
> >>>
> >>> Also, by removing "none", "alg" would become consistent with the
> >>> rest of the parameters which don't have "none" values (we don't have
> >>> "enc":"none", etc.). Very much like the recent change to "zip" (JWS,
> >>> section 4.1.6) which no longer has the (optional) "none": it's
> >>> either "zip":"DEF" or nothing.
> >>
> >> Just make sure to explain what it means when alg is omitted. Assume
> >> this would apply equally to both JSW and JWE?
> >>
> >> spt
> >
> > My understanding is that this should actually be explained in the JSON
> > Web Token (JWT) spec where the concept of plain tokens is originally
> > introduced. Therefore, the case of a missing "alg" should fall outside
> > the scope of the JWS and JWE specs.
> 
> That's one possibility but then you're introducing a normative reference.
If
> draft-ietf-jose-json-web-algorithms, is going to retain the section on
creating
> plaintext JWS then it's worth saying how empty would be handled - and then
> you can avoid the reference.
> 
> spt
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
> 
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose


From James.H.Manger@team.telstra.com  Mon May 28 17:23: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 815F221F8749 for ; Mon, 28 May 2012 17:23:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.576
X-Spam-Level: 
X-Spam-Status: No, score=-0.576 tagged_above=-999 required=5 tests=[AWL=0.325,  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 8msbHMRr9CWr for ; Mon, 28 May 2012 17:23:24 -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 7422321F8744 for ; Mon, 28 May 2012 17:23:24 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.75,674,1330866000"; d="scan'208";a="75639575"
Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipobvi.tcif.telstra.com.au with ESMTP; 29 May 2012 10:23:23 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6725"; a="64943515"
Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipccvi.tcif.telstra.com.au with ESMTP; 29 May 2012 10:23:23 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Tue, 29 May 2012 10:23:22 +1000
From: "Manger, James H" 
To: Mike Jones , Sean Turner ,  Vladimir Dzhuvinov / NimbusDS 
Date: Tue, 29 May 2012 10:23:21 +1000
Thread-Topic: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
Thread-Index: AQHNPJVSCAHMzxPmQDC/RwzlQzAQz5bfUfcAgAAURHCAAHcoEA==
Message-ID: <255B9BB34FB7D647A506DC292726F6E114F4D32D9C@WSMSG3153V.srv.dir.telstra.com>
References: <20120527224709.cc40c4f3d92d2001859047cd8cabb9ab.7bdf13f113.wbe@email07.europe.secureserver.net> <4FC397FE.3040001@ieca.com> <4E1F6AAD24975D4BA5B16804296739436651CC6A@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436651CC6A@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: "jose@ietf.org" 
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 May 2012 00:23:25 -0000

"alg":"none" certainly doesn't belong in the OAuth JWT spec that defines a =
format for identity claims.

Sticking "alg":"none" in a JOSE core spec is not the answer, however. The s=
olution is to make unprotected data a first-class citizen alongside signed =
data (JWS) and encrypted data (JWE) in the (embarrassingly unnamed) top-lev=
el JOSE structure that can hold any of these 3 forms of data -- and is the =
JOSE structure that other specs will use.

Having JWS and JWE in separate specs means there isn't an obvious place to =
specify the top-level JOSE structure (so it is done awkwardly in the OAuth =
JWT spec). We could add two more JOSE specs: JWP (plain/unprotected data) a=
nd JOSE (top-level structure =3D {JWS|JWE|JWP}). I think a better approach =
would be to (re-)combine JWS and JWE. The combined spec would include unpro=
tected data as a third mode. The algorithms spec can remain separate.

--
James Manger


-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik=
e Jones
Sent: Tuesday, 29 May 2012 2:44 AM
To: Sean Turner; Vladimir Dzhuvinov / NimbusDS
Cc: jose@ietf.org
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

For what it's worth, "alg":"none" was moved from JWT to JWS based upon Jim =
Schaad's suggestion in http://www.ietf.org/mail-archive/web/jose/current/ms=
g00365.html for closing the open issue about whether it belongs in JWT or J=
WS.  In it, he wrote:

[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 believe his rationale was correct and has been proven out by events.  At =
this point I now of several usages of "none" both within JWTs, and signific=
antly, in at least one context where the structure is a JWS but *not* a JWT=
.  I believe Jim was right to suggest that "alg":"none" belongs in the Algo=
rithms specification.

				Best wishes,
				-- Mike

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Sea=
n Turner
Sent: Monday, May 28, 2012 8:22 AM
To: Vladimir Dzhuvinov / NimbusDS
Cc: jose@ietf.org
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

On 5/28/12 1:47 AM, Vladimir Dzhuvinov / NimbusDS wrote:
>> On 5/22/12 3:53 AM, Vladimir Dzhuvinov / NimbusDS wrote:
>>>
>>>>> Section 3.1
>>>>>
>>>>> 1. I am not overly happy with the existence of a "none" algorithm.=20
>>>>> Does it really need to exist?
>>>>
>>>> +1 for removing "none"
>>>
>>> +1 for deprecating none.
>>>
>>> The same information can be expressed by simply omitting "alg". This=20
>>> makes plain JWTs nimbler too. I see no problem with having empty=20
>>> headers for plain JWTs.
>>>
>>> Also, by removing "none", "alg" would become consistent with the=20
>>> rest of the parameters which don't have "none" values (we don't have=20
>>> "enc":"none", etc.). Very much like the recent change to "zip" (JWS,=20
>>> section 4.1.6) which no longer has the (optional) "none": it's=20
>>> either "zip":"DEF" or nothing.
>>
>> Just make sure to explain what it means when alg is omitted. Assume=20
>> this would apply equally to both JSW and JWE?
>>
>> spt
>
> My understanding is that this should actually be explained in the JSON=20
> Web Token (JWT) spec where the concept of plain tokens is originally=20
> introduced. Therefore, the case of a missing "alg" should fall outside=20
> the scope of the JWS and JWE specs.

That's one possibility but then you're introducing a normative reference.  =
If draft-ietf-jose-json-web-algorithms, is going to retain the section on c=
reating plaintext JWS then it's worth saying how empty would be handled - a=
nd then you can avoid the reference.

spt


From Michael.Jones@microsoft.com  Mon May 28 21:34: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 9EE9221F872D for ; Mon, 28 May 2012 21:34:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.724
X-Spam-Level: 
X-Spam-Status: No, score=-3.724 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 j1G5KKCtPxhp for ; Mon, 28 May 2012 21:34:56 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 969A821F8633 for ; Mon, 28 May 2012 21:34:56 -0700 (PDT)
Received: from mail41-va3-R.bigfish.com (10.7.14.244) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Tue, 29 May 2012 04:34:33 +0000
Received: from mail41-va3 (localhost [127.0.0.1])	by mail41-va3-R.bigfish.com (Postfix) with ESMTP id D6C3432028D; Tue, 29 May 2012 04:34:33 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI
X-SpamScore: -37
X-BigFish: VS-37(zzbb2dI9371I542M1432N1418I98dKzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah)
Received-SPF: pass (mail41-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail41-va3 (localhost.localdomain [127.0.0.1]) by mail41-va3 (MessageSwitch) id 1338266072262120_32327; Tue, 29 May 2012 04:34:32 +0000 (UTC)
Received: from VA3EHSMHS010.bigfish.com (unknown [10.7.14.240])	by mail41-va3.bigfish.com (Postfix) with ESMTP id 317C6C0047; Tue, 29 May 2012 04:34:32 +0000 (UTC)
Received: from TK5EX14MLTC104.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; Tue, 29 May 2012 04:34:31 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.189]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0298.005; Tue, 29 May 2012 04:34:51 +0000
From: Mike Jones 
To: Jim Schaad , 'Sean Turner' , 'Vladimir Dzhuvinov / NimbusDS' 
Thread-Topic: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
Thread-Index: AQHNPJVSCAHMzxPmQDC/RwzlQzAQz5bfUfcAgAAURHCAAG4AgIAAVgaQ
Date: Tue, 29 May 2012 04:34:51 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436651D0DF@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <20120527224709.cc40c4f3d92d2001859047cd8cabb9ab.7bdf13f113.wbe@email07.europe.secureserver.net> <4FC397FE.3040001@ieca.com> <4E1F6AAD24975D4BA5B16804296739436651CC6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <047401cd3d26$b4152a70$1c3f7f50$@augustcellars.com>
In-Reply-To: <047401cd3d26$b4152a70$1c3f7f50$@augustcellars.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.36]
Content-Type: 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 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, 29 May 2012 04:34:57 -0000

In my view, introducing an extra "unsigned" parameter would unnecessarily c=
omplicate processing, as currently implementations can completely determine=
 the structure based only upon the "alg" parameter value.  This would force=
 implementations to potentially look at both an "unsigned" parameter and an=
 "alg" parameter to determine the structure.

The invariant between signed/MACed JWS, encrypted JWE, and unsigned JWS str=
uctures is that the structure of all three is unambiguously distinguished b=
y the value of the "alg" parameter.  (And of course, if the "alg" value is =
not understood, the values MUST be rejected.)

				-- Mike

-----Original Message-----
From: Jim Schaad [mailto:ietf@augustcellars.com]=20
Sent: Monday, May 28, 2012 4:08 PM
To: Mike Jones; 'Sean Turner'; 'Vladimir Dzhuvinov / NimbusDS'
Cc: jose@ietf.org
Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

I agree that if this is going to be done as an alg notation it should be in=
 the algorithm draft.

I am not so sure that I think that marking this as an algorithm is a good i=
dea and that should be discussed.  It is possible that we should talk about=
 some type of degenerate signature structure where we can know that it is a=
 signature structure but that there is no signature algorithm might be bett=
er.

One possible way of doing this might be to have a field which says
"unsigned: true" instead.

Jim


> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20
> Of Mike Jones
> Sent: Monday, May 28, 2012 9:44 AM
> To: Sean Turner; Vladimir Dzhuvinov / NimbusDS
> Cc: jose@ietf.org
> Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
>=20
> For what it's worth, "alg":"none" was moved from JWT to JWS based upon=20
> Jim Schaad's suggestion in http://www.ietf.org/mail-=20
> archive/web/jose/current/msg00365.html for closing the open issue=20
> about whether it belongs in JWT or JWS.  In it, he wrote:
>=20
> [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=20
> to
be
> done the in the base specification.
>=20
> I believe his rationale was correct and has been proven out by events. =20
> At
this
> point I now of several usages of "none" both within JWTs, and
significantly, in
> at least one context where the structure is a JWS but *not* a JWT.  I
believe
> Jim was right to suggest that "alg":"none" belongs in the Algorithms=20
> specification.
>=20
> 				Best wishes,
> 				-- Mike
>=20
> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20
> Of Sean Turner
> Sent: Monday, May 28, 2012 8:22 AM
> To: Vladimir Dzhuvinov / NimbusDS
> Cc: jose@ietf.org
> Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
>=20
> On 5/28/12 1:47 AM, Vladimir Dzhuvinov / NimbusDS wrote:
> >> On 5/22/12 3:53 AM, Vladimir Dzhuvinov / NimbusDS wrote:
> >>>
> >>>>> 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"
> >>>
> >>> +1 for deprecating none.
> >>>
> >>> The same information can be expressed by simply omitting "alg".=20
> >>> This makes plain JWTs nimbler too. I see no problem with having=20
> >>> empty headers for plain JWTs.
> >>>
> >>> Also, by removing "none", "alg" would become consistent with the=20
> >>> rest of the parameters which don't have "none" values (we don't=20
> >>> have "enc":"none", etc.). Very much like the recent change to=20
> >>> "zip" (JWS, section 4.1.6) which no longer has the (optional)=20
> >>> "none": it's either "zip":"DEF" or nothing.
> >>
> >> Just make sure to explain what it means when alg is omitted. Assume=20
> >> this would apply equally to both JSW and JWE?
> >>
> >> spt
> >
> > My understanding is that this should actually be explained in the=20
> > JSON Web Token (JWT) spec where the concept of plain tokens is=20
> > originally introduced. Therefore, the case of a missing "alg" should=20
> > fall outside the scope of the JWS and JWE specs.
>=20
> That's one possibility but then you're introducing a normative reference.
If
> draft-ietf-jose-json-web-algorithms, is going to retain the section on
creating
> plaintext JWS then it's worth saying how empty would be handled - and=20
> then you can avoid the reference.
>=20
> spt
>=20
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>=20
>=20
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose




From Michael.Jones@microsoft.com  Mon May 28 21:35: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 99D0321F8618 for ; Mon, 28 May 2012 21:35:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.714
X-Spam-Level: 
X-Spam-Status: No, score=-3.714 tagged_above=-999 required=5 tests=[AWL=-0.115, 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 QvSzZZZfug7d for ; Mon, 28 May 2012 21:35:10 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 85BA921F874A for ; Mon, 28 May 2012 21:35:04 -0700 (PDT)
Received: from mail98-am1-R.bigfish.com (10.3.201.252) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Tue, 29 May 2012 04:34:40 +0000
Received: from mail98-am1 (localhost [127.0.0.1])	by mail98-am1-R.bigfish.com (Postfix) with ESMTP id 53F6DC035B; Tue, 29 May 2012 04:34:40 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI
X-SpamScore: -36
X-BigFish: VS-36(zzbb2dI9371I542M1432N98dKzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah)
Received-SPF: pass (mail98-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail98-am1 (localhost.localdomain [127.0.0.1]) by mail98-am1 (MessageSwitch) id 1338266078233131_18830; Tue, 29 May 2012 04:34:38 +0000 (UTC)
Received: from AM1EHSMHS018.bigfish.com (unknown [10.3.201.230])	by mail98-am1.bigfish.com (Postfix) with ESMTP id 2A49C380047; Tue, 29 May 2012 04:34:38 +0000 (UTC)
Received: from TK5EX14MLTC103.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, 29 May 2012 04:34:36 +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, 29 May 2012 04:34:54 +0000
From: Mike Jones 
To: "Manger, James H" , Sean Turner , Vladimir Dzhuvinov / NimbusDS 
Thread-Topic: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
Thread-Index: AQHNPJVSCAHMzxPmQDC/RwzlQzAQz5bfUfcAgAAURHCAAHcoEIAATa+g
Date: Tue, 29 May 2012 04:34:53 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436651D0E6@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <20120527224709.cc40c4f3d92d2001859047cd8cabb9ab.7bdf13f113.wbe@email07.europe.secureserver.net> <4FC397FE.3040001@ieca.com> <4E1F6AAD24975D4BA5B16804296739436651CC6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4D32D9C@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F4D32D9C@WSMSG3153V.srv.dir.telstra.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.36]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "jose@ietf.org" 
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 May 2012 04:35:12 -0000

Actually, the third mode already exists, and is parallel, by design, to the=
 signed/MACed and encrypted modes.  No restructuring is necessary to achiev=
e this.  The three are all unambiguously distinguished by the value of the =
"alg" parameter (the value of which MUST be understood, or else the structu=
re must be rejected).

					-- Mike

-----Original Message-----
From: Manger, James H [mailto:James.H.Manger@team.telstra.com]=20
Sent: Monday, May 28, 2012 5:23 PM
To: Mike Jones; Sean Turner; Vladimir Dzhuvinov / NimbusDS
Cc: jose@ietf.org
Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

"alg":"none" certainly doesn't belong in the OAuth JWT spec that defines a =
format for identity claims.

Sticking "alg":"none" in a JOSE core spec is not the answer, however. The s=
olution is to make unprotected data a first-class citizen alongside signed =
data (JWS) and encrypted data (JWE) in the (embarrassingly unnamed) top-lev=
el JOSE structure that can hold any of these 3 forms of data -- and is the =
JOSE structure that other specs will use.

Having JWS and JWE in separate specs means there isn't an obvious place to =
specify the top-level JOSE structure (so it is done awkwardly in the OAuth =
JWT spec). We could add two more JOSE specs: JWP (plain/unprotected data) a=
nd JOSE (top-level structure =3D {JWS|JWE|JWP}). I think a better approach =
would be to (re-)combine JWS and JWE. The combined spec would include unpro=
tected data as a third mode. The algorithms spec can remain separate.

--
James Manger


-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik=
e Jones
Sent: Tuesday, 29 May 2012 2:44 AM
To: Sean Turner; Vladimir Dzhuvinov / NimbusDS
Cc: jose@ietf.org
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

For what it's worth, "alg":"none" was moved from JWT to JWS based upon Jim =
Schaad's suggestion in http://www.ietf.org/mail-archive/web/jose/current/ms=
g00365.html for closing the open issue about whether it belongs in JWT or J=
WS.  In it, he wrote:

[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 believe his rationale was correct and has been proven out by events.  At =
this point I now of several usages of "none" both within JWTs, and signific=
antly, in at least one context where the structure is a JWS but *not* a JWT=
.  I believe Jim was right to suggest that "alg":"none" belongs in the Algo=
rithms specification.

				Best wishes,
				-- Mike

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Sea=
n Turner
Sent: Monday, May 28, 2012 8:22 AM
To: Vladimir Dzhuvinov / NimbusDS
Cc: jose@ietf.org
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

On 5/28/12 1:47 AM, Vladimir Dzhuvinov / NimbusDS wrote:
>> On 5/22/12 3:53 AM, Vladimir Dzhuvinov / NimbusDS wrote:
>>>
>>>>> Section 3.1
>>>>>
>>>>> 1. I am not overly happy with the existence of a "none" algorithm.=20
>>>>> Does it really need to exist?
>>>>
>>>> +1 for removing "none"
>>>
>>> +1 for deprecating none.
>>>
>>> The same information can be expressed by simply omitting "alg". This=20
>>> makes plain JWTs nimbler too. I see no problem with having empty=20
>>> headers for plain JWTs.
>>>
>>> Also, by removing "none", "alg" would become consistent with the=20
>>> rest of the parameters which don't have "none" values (we don't have=20
>>> "enc":"none", etc.). Very much like the recent change to "zip" (JWS,=20
>>> section 4.1.6) which no longer has the (optional) "none": it's=20
>>> either "zip":"DEF" or nothing.
>>
>> Just make sure to explain what it means when alg is omitted. Assume=20
>> this would apply equally to both JSW and JWE?
>>
>> spt
>
> My understanding is that this should actually be explained in the JSON=20
> Web Token (JWT) spec where the concept of plain tokens is originally=20
> introduced. Therefore, the case of a missing "alg" should fall outside=20
> the scope of the JWS and JWE specs.

That's one possibility but then you're introducing a normative reference.  =
If draft-ietf-jose-json-web-algorithms, is going to retain the section on c=
reating plaintext JWS then it's worth saying how empty would be handled - a=
nd then you can avoid the reference.

spt




From James.H.Manger@team.telstra.com  Mon May 28 22:13:11 2012
Return-Path: 
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B6211E8076 for ; Mon, 28 May 2012 22:13:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.612
X-Spam-Level: 
X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[AWL=0.289,  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 M3i7Eia1FwHO for ; Mon, 28 May 2012 22:13:11 -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 5A12D11E8074 for ; Mon, 28 May 2012 22:13:09 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.75,675,1330866000"; d="scan'208";a="74642851"
Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 29 May 2012 15:13:09 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6725"; a="65420544"
Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcbni.tcif.telstra.com.au with ESMTP; 29 May 2012 15:13:09 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Tue, 29 May 2012 15:13:08 +1000
From: "Manger, James H" 
To: Mike Jones , Sean Turner ,  Vladimir Dzhuvinov / NimbusDS 
Date: Tue, 29 May 2012 15:13:07 +1000
Thread-Topic: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
Thread-Index: AQHNPJVSCAHMzxPmQDC/RwzlQzAQz5bfUfcAgAAURHCAAHcoEIAATa+ggAAGurA=
Message-ID: <255B9BB34FB7D647A506DC292726F6E114F4D3351F@WSMSG3153V.srv.dir.telstra.com>
References: <20120527224709.cc40c4f3d92d2001859047cd8cabb9ab.7bdf13f113.wbe@email07.europe.secureserver.net> <4FC397FE.3040001@ieca.com> <4E1F6AAD24975D4BA5B16804296739436651CC6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4D32D9C@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436651D0E6@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436651D0E6@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: "jose@ietf.org" 
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 May 2012 05:13:11 -0000

Sure, the third mode (plaintext) already exists -- but it is not parallel t=
o the signed/MACed and encrypted modes. It is an awkward sub-mode of the si=
gned/MACed mode -- reusing the same fields, but with dummy or blank values;=
 providing completely different security; not mentioned in the JWS abstract=
; only appearing in an appendix (A.4. Example Plaintext JWS); without a sep=
arate "typ" value or MIME type etc.

I think the alg value is a poor way to distinguish unprotected, signed, and=
 encrypted JWx messages. Even it that mechanism remains though, I would lik=
e plaintext mode to be a "first-class citizen". The fact that plaintext mod=
e is hidden away is actually a symptom of not having a place to specify the=
 JOSE top-level structure {signed data | encrypted data | unprotected data}=
.

--
James Manger


-----Original Message-----
From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20
Sent: Tuesday, 29 May 2012 2:35 PM
To: Manger, James H; Sean Turner; Vladimir Dzhuvinov / NimbusDS
Cc: jose@ietf.org
Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

Actually, the third mode already exists, and is parallel, by design, to the=
 signed/MACed and encrypted modes.  No restructuring is necessary to achiev=
e this.  The three are all unambiguously distinguished by the value of the =
"alg" parameter (the value of which MUST be understood, or else the structu=
re must be rejected).

					-- Mike

-----Original Message-----
From: Manger, James H [mailto:James.H.Manger@team.telstra.com]=20
Sent: Monday, May 28, 2012 5:23 PM
To: Mike Jones; Sean Turner; Vladimir Dzhuvinov / NimbusDS
Cc: jose@ietf.org
Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

"alg":"none" certainly doesn't belong in the OAuth JWT spec that defines a =
format for identity claims.

Sticking "alg":"none" in a JOSE core spec is not the answer, however. The s=
olution is to make unprotected data a first-class citizen alongside signed =
data (JWS) and encrypted data (JWE) in the (embarrassingly unnamed) top-lev=
el JOSE structure that can hold any of these 3 forms of data -- and is the =
JOSE structure that other specs will use.

Having JWS and JWE in separate specs means there isn't an obvious place to =
specify the top-level JOSE structure (so it is done awkwardly in the OAuth =
JWT spec). We could add two more JOSE specs: JWP (plain/unprotected data) a=
nd JOSE (top-level structure =3D {JWS|JWE|JWP}). I think a better approach =
would be to (re-)combine JWS and JWE. The combined spec would include unpro=
tected data as a third mode. The algorithms spec can remain separate.

--
James Manger


-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik=
e Jones
Sent: Tuesday, 29 May 2012 2:44 AM
To: Sean Turner; Vladimir Dzhuvinov / NimbusDS
Cc: jose@ietf.org
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

For what it's worth, "alg":"none" was moved from JWT to JWS based upon Jim =
Schaad's suggestion in http://www.ietf.org/mail-archive/web/jose/current/ms=
g00365.html for closing the open issue about whether it belongs in JWT or J=
WS.  In it, he wrote:

[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 believe his rationale was correct and has been proven out by events.  At =
this point I now of several usages of "none" both within JWTs, and signific=
antly, in at least one context where the structure is a JWS but *not* a JWT=
.  I believe Jim was right to suggest that "alg":"none" belongs in the Algo=
rithms specification.

				Best wishes,
				-- Mike

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Sea=
n Turner
Sent: Monday, May 28, 2012 8:22 AM
To: Vladimir Dzhuvinov / NimbusDS
Cc: jose@ietf.org
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

On 5/28/12 1:47 AM, Vladimir Dzhuvinov / NimbusDS wrote:
>> On 5/22/12 3:53 AM, Vladimir Dzhuvinov / NimbusDS wrote:
>>>
>>>>> Section 3.1
>>>>>
>>>>> 1. I am not overly happy with the existence of a "none" algorithm.=20
>>>>> Does it really need to exist?
>>>>
>>>> +1 for removing "none"
>>>
>>> +1 for deprecating none.
>>>
>>> The same information can be expressed by simply omitting "alg". This=20
>>> makes plain JWTs nimbler too. I see no problem with having empty=20
>>> headers for plain JWTs.
>>>
>>> Also, by removing "none", "alg" would become consistent with the=20
>>> rest of the parameters which don't have "none" values (we don't have=20
>>> "enc":"none", etc.). Very much like the recent change to "zip" (JWS,=20
>>> section 4.1.6) which no longer has the (optional) "none": it's=20
>>> either "zip":"DEF" or nothing.
>>
>> Just make sure to explain what it means when alg is omitted. Assume=20
>> this would apply equally to both JSW and JWE?
>>
>> spt
>
> My understanding is that this should actually be explained in the JSON=20
> Web Token (JWT) spec where the concept of plain tokens is originally=20
> introduced. Therefore, the case of a missing "alg" should fall outside=20
> the scope of the JWS and JWE specs.

That's one possibility but then you're introducing a normative reference.  =
If draft-ietf-jose-json-web-algorithms, is going to retain the section on c=
reating plaintext JWS then it's worth saying how empty would be handled - a=
nd then you can avoid the reference.

spt




From bcampbell@pingidentity.com  Tue May 29 05:27: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 1FE2121F87D8 for ; Tue, 29 May 2012 05:27:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.977
X-Spam-Level: 
X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWTEV9oIVJnx for ; Tue, 29 May 2012 05:27:06 -0700 (PDT)
Received: from na3sys009aog133.obsmtp.com (na3sys009aog133.obsmtp.com [74.125.149.82]) by ietfa.amsl.com (Postfix) with ESMTP id BECAB21F87D5 for ; Tue, 29 May 2012 05:27:05 -0700 (PDT)
Received: from mail-vb0-f52.google.com ([209.85.212.52]) (using TLSv1) by na3sys009aob133.postini.com ([74.125.148.12]) with SMTP ID DSNKT8TAmYLL1lcJQJzYYxeEI0n3/XpE3HG8@postini.com; Tue, 29 May 2012 05:27:05 PDT
Received: by vbzb23 with SMTP id b23so3777758vbz.39 for ; Tue, 29 May 2012 05:27:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=QGGIhMjgt2jgFKJa5vS74Yhe49fvF4OCrpBbF7UzSXE=; b=dnOROss03633uBdanM71q9WMO0aJ4llOqpbziDvcvqpQHPxgh2LL7NZiRrLTWxs0N5 pEM5VM4wWI1GvQvLSBur+QMFrgQ08AK4ELbXIx28Ti8DWLDb/nWV/t9bK6WXii9yyRjN SXjogHzXzo9P3rK39aeZoADgQ0MuVDLjxQI733aWkFT2s27/+mQ0Gjrloa0Of22B06Zb kVUFOIirQ+09vbLJo+4FdeF+didgDg7EsBzRI/hyCImg/HyK5fuYhmAh5l6y8SaVBpGh sXDVawjDZVkKAcOu3a1WRw2WZGIFS2cKEw6Qrd5aSwdNgesKpIrZAaEE5tvNnAHwZYA8 0N/A==
Received: by 10.52.24.179 with SMTP id v19mr10610736vdf.127.1338294424329; Tue, 29 May 2012 05:27:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.182.68 with HTTP; Tue, 29 May 2012 05:26:34 -0700 (PDT)
In-Reply-To: <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>  <5F239486-031A-47FB-A508-83ACFD76EEFD@salesforce.com>
From: Brian Campbell 
Date: Tue, 29 May 2012 06:26:34 -0600
Message-ID: 
To: Chuck Mortimore 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmhL+dDhvlC+OIB+F/TP9aYHMYd/egtTBBco+U0ZSzK6UsY/Wk9we0jVn/zre+uRwTTlKpo
Cc: "jose@ietf.org" , "Michael.Jones@microsoft.com" , "James.H.Manger@team.telstra.com" , "ietf@augustcellars.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, 29 May 2012 12:27:07 -0000

+1

On Tue, May 22, 2012 at 10: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:=A0jose-bounces@ietf.org=A0[mailto:jose-bounces@ietf.org]=A0On Behal=
f Of=A0Mike
> Jones
> Sent:=A0Tuesday, May 22, 2012 7:50 AM
> To:=A0Jim Schaad; 'Manger, James H';=A0jose@ietf.org
> Subject:=A0Re: [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.=A0 Quoting from
> the=A0introduction to JSMS=A0(with=A0my emphasis):
>
> =A0=A0 Many applications require the ability to send cryptographically
> =A0=A0 secured (encrypted, 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 viewed as being excessively complicated for the demands of =
Web
> =A0=A0 applications, which typically only need the ability to secure simp=
le
> =A0=A0 messages.=A0 ...
>
> =A0=A0 This document describes a new cryptographic message format,
> =A0=A0 JavaScript Message Security (JSMS) intended to meet the need of th=
e
> =A0=A0 Web environment.=A0 While JSMS is modeled on existing formats --
> =A0=A0 principally CMS [RFC5652] -- it uses JavaScript Object Notation
> =A0=A0 (JSON) rather than ASN.1/BER/DER, making it far easier for Web
> =A0=A0 applications to handle.=A0=A0In the interest of simplicity, JSMS a=
lso
> =A0=A0 omits as many as possible of the CMS modes=A0(multiple signatures,
> =A0=A0 password-based encryption).
>
> In parallel, the consensus decisions in the=A0design discussions behind t=
he
> JWE=A0design included:
> =A0=A0=A0 =93we should specify a small set of composite operations that w=
ill meet
> the needs of common use cases=94
>
> We=92re trying to make simple things simple to facilitate widespread
> deployment 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 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 deploym=
ent
> 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.
>
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=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
>
> -----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
>
>
>
>> -----Original Message-----
>> From: Manger, James H=A0[mailto:James.H.Manger@team.telstra.com]
>> 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
>> > 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:
>>=A0=A0 "alg": "RSA-OAEP"
>>=A0=A0 "mgf": "MGF1"
>>=A0=A0 "hash": "SHA-256"
>
> That is an option that is doable as well.=A0 I happen to think that it mi=
ght
> 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 algorit=
hms
> will want to use the same field.
>
> 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.=A0 It might b=
e
> 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:=A0 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"
>>
>>=A0=A0 The "RSA-OAEP256" key encryption algorithm is RSA encryption with
>>=A0=A0 Optimal Asymmetric Encryption Padding (OAEP) using SHA-256.
>>=A0=A0 The algorithm 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 as
>>=A0=A0 the hash function.
>>
>>=A0=A0 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
>

From ve7jtb@ve7jtb.com  Tue May 29 17:12: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 7ECE711E8161 for ; Tue, 29 May 2012 17:12:24 -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 xccgKLMCGek8 for ; Tue, 29 May 2012 17:12:23 -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 7272D11E8121 for ; Tue, 29 May 2012 17:12:23 -0700 (PDT)
Received: by yhq56 with SMTP id 56so3349689yhq.31 for ; Tue, 29 May 2012 17:12:22 -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=qqbhRpNJDkMCtMIb/WIWfHRxWf558nraiRP2K2jBonI=; b=LAlhgL2aaIUGIFVevT1OVP9XznLEamMeL+02RTAHnU/3mBL7m9u5QsUVhengaLtMWO M7IdhNOU15UHeK+derD5Ra4es4kKW2hD7LqIViWHRVxKEQykxdr3ka15TUUwNOEEm1jd 10N61YFCtphYTxpP8s8RcC4LUgHMM8/xrPCgFrC1YpyvdrKv05zVpccl69vXRxsuTreb xxUjSkdybUPS0n+s7Kgtta2JciF39vtwhsu+oTUDhI+nE84ar3Yj7vzGXTSXC46i8ipH XsjRoEtlOYVuixF7+iCHFQcrMQ7OrS882nwOnTorwjmXsle7pT5WW4xFdccMreKtnzqJ R37Q==
Received: by 10.50.181.225 with SMTP id dz1mr9066349igc.2.1338336742291; Tue, 29 May 2012 17:12:22 -0700 (PDT)
Received: from [192.168.1.2] ([74.220.36.163]) by mx.google.com with ESMTPS id bj4sm9698076igc.16.2012.05.29.17.12.19 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 May 2012 17:12:21 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=us-ascii
From: John Bradley 
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F4D3351F@WSMSG3153V.srv.dir.telstra.com>
Date: Tue, 29 May 2012 18:12:15 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <8A66CBDB-2159-437E-B322-0BCC9E4F7657@ve7jtb.com>
References: <20120527224709.cc40c4f3d92d2001859047cd8cabb9ab.7bdf13f113.wbe@email07.europe.secureserver.net> <4FC397FE.3040001@ieca.com> <4E1F6AAD24975D4BA5B16804296739436651CC6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4D32D9C@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436651D0E6@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4D3351F@WSMSG3153V.srv.dir.telstra.com>
To: "Manger, James H" 
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQnL7Y7RHt07AzGsldZTiohYr4zNUcQ7IKrva/vnD4+gIDN9PMf/h0MIxkdd0tnUQ1wao0UE
Cc: Mike Jones , Sean Turner , "jose@ietf.org" , Vladimir Dzhuvinov / NimbusDS 
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: Wed, 30 May 2012 00:12:24 -0000

All of the alg modes provide different security.  Some are signing, =
integrity, encryption or combinations.
I would not want to get rid of none as a valid alg.   It was part of =
signing originally because we thought of it as a null hash.

Making it clearer is fine, if we can do that. =20

One thought this brings up, is should we have a simple hash alg defined =
as well as hmac?

John B.


On 2012-05-28, at 11:13 PM, Manger, James H wrote:

> Sure, the third mode (plaintext) already exists -- but it is not =
parallel to the signed/MACed and encrypted modes. It is an awkward =
sub-mode of the signed/MACed mode -- reusing the same fields, but with =
dummy or blank values; providing completely different security; not =
mentioned in the JWS abstract; only appearing in an appendix (A.4. =
Example Plaintext JWS); without a separate "typ" value or MIME type etc.
>=20
> I think the alg value is a poor way to distinguish unprotected, =
signed, and encrypted JWx messages. Even it that mechanism remains =
though, I would like plaintext mode to be a "first-class citizen". The =
fact that plaintext mode is hidden away is actually a symptom of not =
having a place to specify the JOSE top-level structure {signed data | =
encrypted data | unprotected data}.
>=20
> --
> James Manger
>=20
>=20
> -----Original Message-----
> From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20
> Sent: Tuesday, 29 May 2012 2:35 PM
> To: Manger, James H; Sean Turner; Vladimir Dzhuvinov / NimbusDS
> Cc: jose@ietf.org
> Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
>=20
> Actually, the third mode already exists, and is parallel, by design, =
to the signed/MACed and encrypted modes.  No restructuring is necessary =
to achieve this.  The three are all unambiguously distinguished by the =
value of the "alg" parameter (the value of which MUST be understood, or =
else the structure must be rejected).
>=20
> 					-- Mike
>=20
> -----Original Message-----
> From: Manger, James H [mailto:James.H.Manger@team.telstra.com]=20
> Sent: Monday, May 28, 2012 5:23 PM
> To: Mike Jones; Sean Turner; Vladimir Dzhuvinov / NimbusDS
> Cc: jose@ietf.org
> Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
>=20
> "alg":"none" certainly doesn't belong in the OAuth JWT spec that =
defines a format for identity claims.
>=20
> Sticking "alg":"none" in a JOSE core spec is not the answer, however. =
The solution is to make unprotected data a first-class citizen alongside =
signed data (JWS) and encrypted data (JWE) in the (embarrassingly =
unnamed) top-level JOSE structure that can hold any of these 3 forms of =
data -- and is the JOSE structure that other specs will use.
>=20
> Having JWS and JWE in separate specs means there isn't an obvious =
place to specify the top-level JOSE structure (so it is done awkwardly =
in the OAuth JWT spec). We could add two more JOSE specs: JWP =
(plain/unprotected data) and JOSE (top-level structure =3D =
{JWS|JWE|JWP}). I think a better approach would be to (re-)combine JWS =
and JWE. The combined spec would include unprotected data as a third =
mode. The algorithms spec can remain separate.
>=20
> --
> James Manger
>=20
>=20
> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf =
Of Mike Jones
> Sent: Tuesday, 29 May 2012 2:44 AM
> To: Sean Turner; Vladimir Dzhuvinov / NimbusDS
> Cc: jose@ietf.org
> Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
>=20
> For what it's worth, "alg":"none" was moved from JWT to JWS based upon =
Jim Schaad's suggestion in =
http://www.ietf.org/mail-archive/web/jose/current/msg00365.html for =
closing the open issue about whether it belongs in JWT or JWS.  In it, =
he wrote:
>=20
> [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.
>=20
> I believe his rationale was correct and has been proven out by events. =
 At this point I now of several usages of "none" both within JWTs, and =
significantly, in at least one context where the structure is a JWS but =
*not* a JWT.  I believe Jim was right to suggest that "alg":"none" =
belongs in the Algorithms specification.
>=20
> 				Best wishes,
> 				-- Mike
>=20
> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf =
Of Sean Turner
> Sent: Monday, May 28, 2012 8:22 AM
> To: Vladimir Dzhuvinov / NimbusDS
> Cc: jose@ietf.org
> Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
>=20
> On 5/28/12 1:47 AM, Vladimir Dzhuvinov / NimbusDS wrote:
>>> On 5/22/12 3:53 AM, Vladimir Dzhuvinov / NimbusDS wrote:
>>>>=20
>>>>>> Section 3.1
>>>>>>=20
>>>>>> 1. I am not overly happy with the existence of a "none" =
algorithm.=20
>>>>>> Does it really need to exist?
>>>>>=20
>>>>> +1 for removing "none"
>>>>=20
>>>> +1 for deprecating none.
>>>>=20
>>>> The same information can be expressed by simply omitting "alg". =
This=20
>>>> makes plain JWTs nimbler too. I see no problem with having empty=20
>>>> headers for plain JWTs.
>>>>=20
>>>> Also, by removing "none", "alg" would become consistent with the=20
>>>> rest of the parameters which don't have "none" values (we don't =
have=20
>>>> "enc":"none", etc.). Very much like the recent change to "zip" =
(JWS,=20
>>>> section 4.1.6) which no longer has the (optional) "none": it's=20
>>>> either "zip":"DEF" or nothing.
>>>=20
>>> Just make sure to explain what it means when alg is omitted. Assume=20=

>>> this would apply equally to both JSW and JWE?
>>>=20
>>> spt
>>=20
>> My understanding is that this should actually be explained in the =
JSON=20
>> Web Token (JWT) spec where the concept of plain tokens is originally=20=

>> introduced. Therefore, the case of a missing "alg" should fall =
outside=20
>> the scope of the JWS and JWE specs.
>=20
> That's one possibility but then you're introducing a normative =
reference.  If draft-ietf-jose-json-web-algorithms, is going to retain =
the section on creating plaintext JWS then it's worth saying how empty =
would be handled - and then you can avoid the reference.
>=20
> spt
>=20
>=20
>=20
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose


From Michael.Jones@microsoft.com  Tue May 29 17:19:52 2012
Return-Path: 
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E962B11E8126 for ; Tue, 29 May 2012 17:19:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.699
X-Spam-Level: 
X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 n9a3fS6aDj8N for ; Tue, 29 May 2012 17:19:52 -0700 (PDT)
Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB7311E8187 for ; Tue, 29 May 2012 17:19:51 -0700 (PDT)
Received: from mail45-db3-R.bigfish.com (10.3.81.249) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Wed, 30 May 2012 00:19:26 +0000
Received: from mail45-db3 (localhost [127.0.0.1])	by mail45-db3-R.bigfish.com (Postfix) with ESMTP id B528B4C0427; Wed, 30 May 2012 00:19:26 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI
X-SpamScore: -39
X-BigFish: VS-39(zzbb2dI9371I936eK542M1432N98dKzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah)
Received-SPF: pass (mail45-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail45-db3 (localhost.localdomain [127.0.0.1]) by mail45-db3 (MessageSwitch) id 1338337164276031_27429; Wed, 30 May 2012 00:19:24 +0000 (UTC)
Received: from DB3EHSMHS011.bigfish.com (unknown [10.3.81.234])	by mail45-db3.bigfish.com (Postfix) with ESMTP id 3721236005C; Wed, 30 May 2012 00:19:24 +0000 (UTC)
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS011.bigfish.com (10.3.87.111) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 30 May 2012 00:19:23 +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; Wed, 30 May 2012 00:19:45 +0000
From: Mike Jones 
To: John Bradley , "Manger, James H" 
Thread-Topic: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
Thread-Index: AQHNPJVSCAHMzxPmQDC/RwzlQzAQz5bfUfcAgAAURHCAAHcoEIAATa+ggAAGurCAAUbFgIAAAdUA
Date: Wed, 30 May 2012 00:19:44 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436651EB52@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <20120527224709.cc40c4f3d92d2001859047cd8cabb9ab.7bdf13f113.wbe@email07.europe.secureserver.net> <4FC397FE.3040001@ieca.com> <4E1F6AAD24975D4BA5B16804296739436651CC6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4D32D9C@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436651D0E6@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4D3351F@WSMSG3153V.srv.dir.telstra.com> <8A66CBDB-2159-437E-B322-0BCC9E4F7657@ve7jtb.com>
In-Reply-To: <8A66CBDB-2159-437E-B322-0BCC9E4F7657@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.75]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: Sean Turner , "jose@ietf.org" , Vladimir Dzhuvinov / NimbusDS 
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: Wed, 30 May 2012 00:19:53 -0000

John, you wrote: "One thought this brings up, is should we have a simple ha=
sh alg defined as well as hmac?"

What use case do you have in mind, and what kind of simple hash algorithm d=
id you have in mind?

					-- Mike

-----Original Message-----
From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20
Sent: Tuesday, May 29, 2012 5:12 PM
To: Manger, James H
Cc: Mike Jones; Sean Turner; Vladimir Dzhuvinov / NimbusDS; jose@ietf.org
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

All of the alg modes provide different security.  Some are signing, integri=
ty, encryption or combinations.
I would not want to get rid of none as a valid alg.   It was part of signin=
g originally because we thought of it as a null hash.

Making it clearer is fine, if we can do that. =20

One thought this brings up, is should we have a simple hash alg defined as =
well as hmac?

John B.


On 2012-05-28, at 11:13 PM, Manger, James H wrote:

> Sure, the third mode (plaintext) already exists -- but it is not parallel=
 to the signed/MACed and encrypted modes. It is an awkward sub-mode of the =
signed/MACed mode -- reusing the same fields, but with dummy or blank value=
s; providing completely different security; not mentioned in the JWS abstra=
ct; only appearing in an appendix (A.4. Example Plaintext JWS); without a s=
eparate "typ" value or MIME type etc.
>=20
> I think the alg value is a poor way to distinguish unprotected, signed, a=
nd encrypted JWx messages. Even it that mechanism remains though, I would l=
ike plaintext mode to be a "first-class citizen". The fact that plaintext m=
ode is hidden away is actually a symptom of not having a place to specify t=
he JOSE top-level structure {signed data | encrypted data | unprotected dat=
a}.
>=20
> --
> James Manger
>=20
>=20
> -----Original Message-----
> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> Sent: Tuesday, 29 May 2012 2:35 PM
> To: Manger, James H; Sean Turner; Vladimir Dzhuvinov / NimbusDS
> Cc: jose@ietf.org
> Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
>=20
> Actually, the third mode already exists, and is parallel, by design, to t=
he signed/MACed and encrypted modes.  No restructuring is necessary to achi=
eve this.  The three are all unambiguously distinguished by the value of th=
e "alg" parameter (the value of which MUST be understood, or else the struc=
ture must be rejected).
>=20
> 					-- Mike
>=20
> -----Original Message-----
> From: Manger, James H [mailto:James.H.Manger@team.telstra.com]
> Sent: Monday, May 28, 2012 5:23 PM
> To: Mike Jones; Sean Turner; Vladimir Dzhuvinov / NimbusDS
> Cc: jose@ietf.org
> Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
>=20
> "alg":"none" certainly doesn't belong in the OAuth JWT spec that defines =
a format for identity claims.
>=20
> Sticking "alg":"none" in a JOSE core spec is not the answer, however. The=
 solution is to make unprotected data a first-class citizen alongside signe=
d data (JWS) and encrypted data (JWE) in the (embarrassingly unnamed) top-l=
evel JOSE structure that can hold any of these 3 forms of data -- and is th=
e JOSE structure that other specs will use.
>=20
> Having JWS and JWE in separate specs means there isn't an obvious place t=
o specify the top-level JOSE structure (so it is done awkwardly in the OAut=
h JWT spec). We could add two more JOSE specs: JWP (plain/unprotected data)=
 and JOSE (top-level structure =3D {JWS|JWE|JWP}). I think a better approac=
h would be to (re-)combine JWS and JWE. The combined spec would include unp=
rotected data as a third mode. The algorithms spec can remain separate.
>=20
> --
> James Manger
>=20
>=20
> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20
> Of Mike Jones
> Sent: Tuesday, 29 May 2012 2:44 AM
> To: Sean Turner; Vladimir Dzhuvinov / NimbusDS
> Cc: jose@ietf.org
> Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
>=20
> For what it's worth, "alg":"none" was moved from JWT to JWS based upon Ji=
m Schaad's suggestion in http://www.ietf.org/mail-archive/web/jose/current/=
msg00365.html for closing the open issue about whether it belongs in JWT or=
 JWS.  In it, he wrote:
>=20
> [JLS] If it is believe that a parameter this list is going to be "commonl=
y" used by many different profilers, then I believe that the core items nee=
ds to be done the in the base specification.
>=20
> I believe his rationale was correct and has been proven out by events.  A=
t this point I now of several usages of "none" both within JWTs, and signif=
icantly, in at least one context where the structure is a JWS but *not* a J=
WT.  I believe Jim was right to suggest that "alg":"none" belongs in the Al=
gorithms specification.
>=20
> 				Best wishes,
> 				-- Mike
>=20
> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20
> Of Sean Turner
> Sent: Monday, May 28, 2012 8:22 AM
> To: Vladimir Dzhuvinov / NimbusDS
> Cc: jose@ietf.org
> Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
>=20
> On 5/28/12 1:47 AM, Vladimir Dzhuvinov / NimbusDS wrote:
>>> On 5/22/12 3:53 AM, Vladimir Dzhuvinov / NimbusDS wrote:
>>>>=20
>>>>>> Section 3.1
>>>>>>=20
>>>>>> 1. I am not overly happy with the existence of a "none" algorithm.=20
>>>>>> Does it really need to exist?
>>>>>=20
>>>>> +1 for removing "none"
>>>>=20
>>>> +1 for deprecating none.
>>>>=20
>>>> The same information can be expressed by simply omitting "alg".=20
>>>> This makes plain JWTs nimbler too. I see no problem with having=20
>>>> empty headers for plain JWTs.
>>>>=20
>>>> Also, by removing "none", "alg" would become consistent with the=20
>>>> rest of the parameters which don't have "none" values (we don't=20
>>>> have "enc":"none", etc.). Very much like the recent change to "zip"=20
>>>> (JWS, section 4.1.6) which no longer has the (optional) "none":=20
>>>> it's either "zip":"DEF" or nothing.
>>>=20
>>> Just make sure to explain what it means when alg is omitted. Assume=20
>>> this would apply equally to both JSW and JWE?
>>>=20
>>> spt
>>=20
>> My understanding is that this should actually be explained in the=20
>> JSON Web Token (JWT) spec where the concept of plain tokens is=20
>> originally introduced. Therefore, the case of a missing "alg" should=20
>> fall outside the scope of the JWS and JWE specs.
>=20
> That's one possibility but then you're introducing a normative reference.=
  If draft-ietf-jose-json-web-algorithms, is going to retain the section on=
 creating plaintext JWS then it's worth saying how empty would be handled -=
 and then you can avoid the reference.
>=20
> spt
>=20
>=20
>=20
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose




From James.H.Manger@team.telstra.com  Tue May 29 17:25: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 0E91111E817B for ; Tue, 29 May 2012 17:25:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.641
X-Spam-Level: 
X-Spam-Status: No, score=-0.641 tagged_above=-999 required=5 tests=[AWL=0.260,  BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWlBAz5yNVpP for ; Tue, 29 May 2012 17:25:50 -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 3B05D11E8177 for ; Tue, 29 May 2012 17:25:49 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.75,681,1330866000"; d="scan'208";a="75850218"
Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 30 May 2012 10:25:48 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6726"; a="69038658"
Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcavi.tcif.telstra.com.au with ESMTP; 30 May 2012 10:25:48 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Wed, 30 May 2012 10:25:48 +1000
From: "Manger, James H" 
To: John Bradley 
Date: Wed, 30 May 2012 10:25:46 +1000
Thread-Topic: [jose] Comments on draft-ietf-jose-json-web-algorithms-02: hash
Thread-Index: Ac09+OYm448TIvBlQ2CtzgXR6+OjygAARS2g
Message-ID: <255B9BB34FB7D647A506DC292726F6E114F4EB4363@WSMSG3153V.srv.dir.telstra.com>
References: <20120527224709.cc40c4f3d92d2001859047cd8cabb9ab.7bdf13f113.wbe@email07.europe.secureserver.net> <4FC397FE.3040001@ieca.com> <4E1F6AAD24975D4BA5B16804296739436651CC6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4D32D9C@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436651D0E6@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4D3351F@WSMSG3153V.srv.dir.telstra.com> <8A66CBDB-2159-437E-B322-0BCC9E4F7657@ve7jtb.com>
In-Reply-To: <8A66CBDB-2159-437E-B322-0BCC9E4F7657@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] Comments on draft-ietf-jose-json-web-algorithms-02: hash
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.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, 30 May 2012 00:25:51 -0000

> One thought this brings up, is should we have a simple hash alg defined a=
s well as hmac?

No.
I assume you mean a non-keyed hash of the data -- providing a checksum agai=
nst accidental modification. JOSE does not need this. It really has to be h=
andled much further down the protocol stack.

--
James Manger

From ve7jtb@ve7jtb.com  Tue May 29 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 0F48111E817B for ; Tue, 29 May 2012 17:27: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 DTI8773pfI2j for ; Tue, 29 May 2012 17:27:02 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D616411E8177 for ; Tue, 29 May 2012 17:27:01 -0700 (PDT)
Received: by obbeh20 with SMTP id eh20so9300626obb.31 for ; Tue, 29 May 2012 17:27:01 -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=cwnozYkl91ywHHOyHjT1t5pq3NOuhNgyhjJ0KFyQpfQ=; b=Vf6SMubcDVJIZaAMxN19BVc1eWUBqU02061LVk41zwhG1mIWWWpPmzba9jDMCu0PHW IbeWS1ZQ1YVYNHVaWTDjmdcpAyTu/GBwQ5xsMlJYsnudMOBBqoXHQUpVLzhrAUfYFdT/ hG2SB7s/tvF1aCmm8ELhS8HFUsAnDFajqZbG2JHIs4jeKtb1So+ZJ7YTs7TbyvErmvu+ Keu+goXf82qEDm1Y5JbPzzFte7o8k6AGrlQL43rzjvitAdLUE7o3D++NwNDHoRLqZUEQ RLAA63N/IWqXI67qh/HfpvXyv1DqO5DWiJxPV6NQJyksJZP4phUjN155miwMlKzuLUHk wiEw==
Received: by 10.182.8.99 with SMTP id q3mr13245294oba.63.1338337621313; Tue, 29 May 2012 17:27:01 -0700 (PDT)
Received: from [192.168.1.2] ([74.220.36.163]) by mx.google.com with ESMTPS id js6sm12818543obb.2.2012.05.29.17.26.57 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 May 2012 17:27:00 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=us-ascii
From: John Bradley 
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436651EB52@TK5EX14MBXC284.redmond.corp.microsoft.com>
Date: Tue, 29 May 2012 18:26:53 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20120527224709.cc40c4f3d92d2001859047cd8cabb9ab.7bdf13f113.wbe@email07.europe.secureserver.net> <4FC397FE.3040001@ieca.com> <4E1F6AAD24975D4BA5B16804296739436651CC6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4D32D9C@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436651D0E6@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4D3351F@WSMSG3153V.srv.dir.telstra.com> <8A66CBDB-2159-437E-B322-0BCC9E4F7657@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739436651EB52@TK5EX14MBXC284.redmond.corp.microsoft.com>
To: Mike Jones 
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQko721SbbuQopR1j66OrpxwkcVKRkoC7shPSKVywz6rlrXodL6CW3WoGQpaRuC7k0G3r/J3
Cc: Sean Turner , "Manger, James H" , "jose@ietf.org" , Vladimir Dzhuvinov / NimbusDS 
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: Wed, 30 May 2012 00:27:03 -0000

A HMAC is useful to protect against intentional manipulation of a =
message, but requires a shared secret.

Sometimes you just want to message integrity against accidental =
modification.  In that case a SHA256 or other hash would do without the =
need to have a shared secret.

John B.
On 2012-05-29, at 6:19 PM, Mike Jones wrote:

> John, you wrote: "One thought this brings up, is should we have a =
simple hash alg defined as well as hmac?"
>=20
> What use case do you have in mind, and what kind of simple hash =
algorithm did you have in mind?
>=20
> 					-- Mike
>=20
> -----Original Message-----
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20
> Sent: Tuesday, May 29, 2012 5:12 PM
> To: Manger, James H
> Cc: Mike Jones; Sean Turner; Vladimir Dzhuvinov / NimbusDS; =
jose@ietf.org
> Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
>=20
> All of the alg modes provide different security.  Some are signing, =
integrity, encryption or combinations.
> I would not want to get rid of none as a valid alg.   It was part of =
signing originally because we thought of it as a null hash.
>=20
> Making it clearer is fine, if we can do that. =20
>=20
> One thought this brings up, is should we have a simple hash alg =
defined as well as hmac?
>=20
> John B.
>=20
>=20
> On 2012-05-28, at 11:13 PM, Manger, James H wrote:
>=20
>> Sure, the third mode (plaintext) already exists -- but it is not =
parallel to the signed/MACed and encrypted modes. It is an awkward =
sub-mode of the signed/MACed mode -- reusing the same fields, but with =
dummy or blank values; providing completely different security; not =
mentioned in the JWS abstract; only appearing in an appendix (A.4. =
Example Plaintext JWS); without a separate "typ" value or MIME type etc.
>>=20
>> I think the alg value is a poor way to distinguish unprotected, =
signed, and encrypted JWx messages. Even it that mechanism remains =
though, I would like plaintext mode to be a "first-class citizen". The =
fact that plaintext mode is hidden away is actually a symptom of not =
having a place to specify the JOSE top-level structure {signed data | =
encrypted data | unprotected data}.
>>=20
>> --
>> James Manger
>>=20
>>=20
>> -----Original Message-----
>> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
>> Sent: Tuesday, 29 May 2012 2:35 PM
>> To: Manger, James H; Sean Turner; Vladimir Dzhuvinov / NimbusDS
>> Cc: jose@ietf.org
>> Subject: RE: [jose] Comments on =
draft-ietf-jose-json-web-algorithms-02
>>=20
>> Actually, the third mode already exists, and is parallel, by design, =
to the signed/MACed and encrypted modes.  No restructuring is necessary =
to achieve this.  The three are all unambiguously distinguished by the =
value of the "alg" parameter (the value of which MUST be understood, or =
else the structure must be rejected).
>>=20
>> 					-- Mike
>>=20
>> -----Original Message-----
>> From: Manger, James H [mailto:James.H.Manger@team.telstra.com]
>> Sent: Monday, May 28, 2012 5:23 PM
>> To: Mike Jones; Sean Turner; Vladimir Dzhuvinov / NimbusDS
>> Cc: jose@ietf.org
>> Subject: RE: [jose] Comments on =
draft-ietf-jose-json-web-algorithms-02
>>=20
>> "alg":"none" certainly doesn't belong in the OAuth JWT spec that =
defines a format for identity claims.
>>=20
>> Sticking "alg":"none" in a JOSE core spec is not the answer, however. =
The solution is to make unprotected data a first-class citizen alongside =
signed data (JWS) and encrypted data (JWE) in the (embarrassingly =
unnamed) top-level JOSE structure that can hold any of these 3 forms of =
data -- and is the JOSE structure that other specs will use.
>>=20
>> Having JWS and JWE in separate specs means there isn't an obvious =
place to specify the top-level JOSE structure (so it is done awkwardly =
in the OAuth JWT spec). We could add two more JOSE specs: JWP =
(plain/unprotected data) and JOSE (top-level structure =3D =
{JWS|JWE|JWP}). I think a better approach would be to (re-)combine JWS =
and JWE. The combined spec would include unprotected data as a third =
mode. The algorithms spec can remain separate.
>>=20
>> --
>> James Manger
>>=20
>>=20
>> -----Original Message-----
>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20=

>> Of Mike Jones
>> Sent: Tuesday, 29 May 2012 2:44 AM
>> To: Sean Turner; Vladimir Dzhuvinov / NimbusDS
>> Cc: jose@ietf.org
>> Subject: Re: [jose] Comments on =
draft-ietf-jose-json-web-algorithms-02
>>=20
>> For what it's worth, "alg":"none" was moved from JWT to JWS based =
upon Jim Schaad's suggestion in =
http://www.ietf.org/mail-archive/web/jose/current/msg00365.html for =
closing the open issue about whether it belongs in JWT or JWS.  In it, =
he wrote:
>>=20
>> [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.
>>=20
>> I believe his rationale was correct and has been proven out by =
events.  At this point I now of several usages of "none" both within =
JWTs, and significantly, in at least one context where the structure is =
a JWS but *not* a JWT.  I believe Jim was right to suggest that =
"alg":"none" belongs in the Algorithms specification.
>>=20
>> 				Best wishes,
>> 				-- Mike
>>=20
>> -----Original Message-----
>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20=

>> Of Sean Turner
>> Sent: Monday, May 28, 2012 8:22 AM
>> To: Vladimir Dzhuvinov / NimbusDS
>> Cc: jose@ietf.org
>> Subject: Re: [jose] Comments on =
draft-ietf-jose-json-web-algorithms-02
>>=20
>> On 5/28/12 1:47 AM, Vladimir Dzhuvinov / NimbusDS wrote:
>>>> On 5/22/12 3:53 AM, Vladimir Dzhuvinov / NimbusDS wrote:
>>>>>=20
>>>>>>> Section 3.1
>>>>>>>=20
>>>>>>> 1. I am not overly happy with the existence of a "none" =
algorithm.=20
>>>>>>> Does it really need to exist?
>>>>>>=20
>>>>>> +1 for removing "none"
>>>>>=20
>>>>> +1 for deprecating none.
>>>>>=20
>>>>> The same information can be expressed by simply omitting "alg".=20
>>>>> This makes plain JWTs nimbler too. I see no problem with having=20
>>>>> empty headers for plain JWTs.
>>>>>=20
>>>>> Also, by removing "none", "alg" would become consistent with the=20=

>>>>> rest of the parameters which don't have "none" values (we don't=20
>>>>> have "enc":"none", etc.). Very much like the recent change to =
"zip"=20
>>>>> (JWS, section 4.1.6) which no longer has the (optional) "none":=20
>>>>> it's either "zip":"DEF" or nothing.
>>>>=20
>>>> Just make sure to explain what it means when alg is omitted. Assume=20=

>>>> this would apply equally to both JSW and JWE?
>>>>=20
>>>> spt
>>>=20
>>> My understanding is that this should actually be explained in the=20
>>> JSON Web Token (JWT) spec where the concept of plain tokens is=20
>>> originally introduced. Therefore, the case of a missing "alg" should=20=

>>> fall outside the scope of the JWS and JWE specs.
>>=20
>> That's one possibility but then you're introducing a normative =
reference.  If draft-ietf-jose-json-web-algorithms, is going to retain =
the section on creating plaintext JWS then it's worth saying how empty =
would be handled - and then you can avoid the reference.
>>=20
>> spt
>>=20
>>=20
>>=20
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>=20
>=20
>=20


From ve7jtb@ve7jtb.com  Tue May 29 17:31: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 884F311E8185 for ; Tue, 29 May 2012 17:31:07 -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 z15AqZ7KNPmz for ; Tue, 29 May 2012 17:31:07 -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 011FA11E817B for ; Tue, 29 May 2012 17:31:06 -0700 (PDT)
Received: by yhq56 with SMTP id 56so3358629yhq.31 for ; Tue, 29 May 2012 17:31:06 -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=KbK0KdHniL1o3/dbPDyso10u9qp6FjfthKivCpY21jI=; b=IrWmGsst9P74HIOumVHppSteW47bACzdWxr7hajjSDxsf+jJNAdVfouxy74GbRlevv 3qgytp+4QD3fq6ml8W4VZ1fDl7SBsMLbwEwD3NYVf4BGC9RvGd+BVeTatbZ/Hqp6Ev5c karDZlVz4jI+jB544R5uPptZbuktSIEO7pg0TWZSNfCLAIHa6DPVGWGLKAOs8OAQ8MPg vsWJei5yVzkxUszGwpXmltFS9/YbGyCGI2vyJVj69OqWXBjqh87CPCHu4VIBkqbE85cr rKWpHT/0mmrtXe24VC4RL0H0rC8UUs4dLde5MrnhMUg/liWE8Vg4EwLblYG8R4jJFDgI Mnbg==
Received: by 10.60.14.193 with SMTP id r1mr13345232oec.16.1338337866439; Tue, 29 May 2012 17:31:06 -0700 (PDT)
Received: from [192.168.1.2] ([74.220.36.163]) by mx.google.com with ESMTPS id b8sm6177229obw.1.2012.05.29.17.31.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 May 2012 17:31:05 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=us-ascii
From: John Bradley 
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F4EB4363@WSMSG3153V.srv.dir.telstra.com>
Date: Tue, 29 May 2012 18:30:59 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <651BC67B-ADA1-4DD7-AAC8-7B69EEE23FB8@ve7jtb.com>
References: <20120527224709.cc40c4f3d92d2001859047cd8cabb9ab.7bdf13f113.wbe@email07.europe.secureserver.net> <4FC397FE.3040001@ieca.com> <4E1F6AAD24975D4BA5B16804296739436651CC6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4D32D9C@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436651D0E6@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4D3351F@WSMSG3153V.srv.dir.telstra.com> <8A66CBDB-2159-437E-B322-0BCC9E4F7657@ve7jtb.com> <255B9BB34FB7D647A506DC292726F6E114F4EB4363@WSMSG3153V.srv.dir.telstra.com>
To: "Manger, James H" 
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQkbivIktxqo7Gsdz8GjbD5xSa1FyT/5FPAzFd4xSY+9t2116FZL/Ux6K1Apv76iKrG7YR8g
Cc: "jose@ietf.org" 
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02: hash
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.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, 30 May 2012 00:31:07 -0000

In general it is handled much further down the stack. =20

I am not saying we defiantly need a way to do integrity without a shared =
key or asymmetric signing,  but sometimes it is nice to expose that to =
the higher layer for integrity audit or even testing.   We have SHA256 =
anyway for HMAC it is not a big add.

Not something I will loose any sleep over.

John B.
On 2012-05-29, at 6:25 PM, Manger, James H wrote:

>> One thought this brings up, is should we have a simple hash alg =
defined as well as hmac?
>=20
> No.
> I assume you mean a non-keyed hash of the data -- providing a checksum =
against accidental modification. JOSE does not need this. It really has =
to be handled much further down the protocol stack.
>=20
> --
> James Manger


From turners@ieca.com  Tue May 29 17:45:29 2012
Return-Path: 
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48C411E8127 for ; Tue, 29 May 2012 17:45:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.046
X-Spam-Level: 
X-Spam-Status: No, score=-102.046 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWJmvtoLr-61 for ; Tue, 29 May 2012 17:45:29 -0700 (PDT)
Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [67.18.55.14]) by ietfa.amsl.com (Postfix) with ESMTP id E08C821F8675 for ; Tue, 29 May 2012 17:45:28 -0700 (PDT)
Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id 7693E762C2293; Tue, 29 May 2012 19:45:28 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 6B92B762C225A for ; Tue, 29 May 2012 19:45:28 -0500 (CDT)
Received: from [96.231.119.226] (port=37214 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SZX2U-00058q-Sp; Tue, 29 May 2012 19:45:28 -0500
Message-ID: <4FC56D9A.1070208@ieca.com>
Date: Tue, 29 May 2012 20:45:14 -0400
From: Sean Turner 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Mike Jones 
References: <20120527224709.cc40c4f3d92d2001859047cd8cabb9ab.7bdf13f113.wbe@email07.europe.secureserver.net> <4FC397FE.3040001@ieca.com> <4E1F6AAD24975D4BA5B16804296739436651CC6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4D32D9C@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436651D0E6@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4D3351F@WSMSG3153V.srv.dir.telstra.com> <8A66CBDB-2159-437E-B322-0BCC9E4F7657@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739436651EB52@TK5EX14MBXC284.redmond.corp.microsoft.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator1743.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (thunderfish.local) [96.231.119.226]:37214
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 1
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Cc: John Bradley , "Manger, James H" , "jose@ietf.org" , Vladimir Dzhuvinov / NimbusDS 
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: Wed, 30 May 2012 00:45:29 -0000

On 5/29/12 8:26 PM, John Bradley wrote:
> A HMAC is useful to protect against intentional manipulation of a message, but requires a shared secret.
>
> Sometimes you just want to message integrity against accidental modification.  In that case a SHA256 or other hash would do without the need to have a shared secret.

I support this idea.

spt

> John B.
> On 2012-05-29, at 6:19 PM, Mike Jones wrote:
>
>> John, you wrote: "One thought this brings up, is should we have a simple hash alg defined as well as hmac?"
>>
>> What use case do you have in mind, and what kind of simple hash algorithm did you have in mind?
>>
>> 					-- Mike
>>
>> -----Original Message-----
>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>> Sent: Tuesday, May 29, 2012 5:12 PM
>> To: Manger, James H
>> Cc: Mike Jones; Sean Turner; Vladimir Dzhuvinov / NimbusDS; jose@ietf.org
>> Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
>>
>> All of the alg modes provide different security.  Some are signing, integrity, encryption or combinations.
>> I would not want to get rid of none as a valid alg.   It was part of signing originally because we thought of it as a null hash.
>>
>> Making it clearer is fine, if we can do that.
>>
>> One thought this brings up, is should we have a simple hash alg defined as well as hmac?
>>
>> John B.
>>
>>
>> On 2012-05-28, at 11:13 PM, Manger, James H wrote:
>>
>>> Sure, the third mode (plaintext) already exists -- but it is not parallel to the signed/MACed and encrypted modes. It is an awkward sub-mode of the signed/MACed mode -- reusing the same fields, but with dummy or blank values; providing completely different security; not mentioned in the JWS abstract; only appearing in an appendix (A.4. Example Plaintext JWS); without a separate "typ" value or MIME type etc.
>>>
>>> I think the alg value is a poor way to distinguish unprotected, signed, and encrypted JWx messages. Even it that mechanism remains though, I would like plaintext mode to be a "first-class citizen". The fact that plaintext mode is hidden away is actually a symptom of not having a place to specify the JOSE top-level structure {signed data | encrypted data | unprotected data}.
>>>
>>> --
>>> James Manger
>>>
>>>
>>> -----Original Message-----
>>> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
>>> Sent: Tuesday, 29 May 2012 2:35 PM
>>> To: Manger, James H; Sean Turner; Vladimir Dzhuvinov / NimbusDS
>>> Cc: jose@ietf.org
>>> Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
>>>
>>> Actually, the third mode already exists, and is parallel, by design, to the signed/MACed and encrypted modes.  No restructuring is necessary to achieve this.  The three are all unambiguously distinguished by the value of the "alg" parameter (the value of which MUST be understood, or else the structure must be rejected).
>>>
>>> 					-- Mike
>>>
>>> -----Original Message-----
>>> From: Manger, James H [mailto:James.H.Manger@team.telstra.com]
>>> Sent: Monday, May 28, 2012 5:23 PM
>>> To: Mike Jones; Sean Turner; Vladimir Dzhuvinov / NimbusDS
>>> Cc: jose@ietf.org
>>> Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
>>>
>>> "alg":"none" certainly doesn't belong in the OAuth JWT spec that defines a format for identity claims.
>>>
>>> Sticking "alg":"none" in a JOSE core spec is not the answer, however. The solution is to make unprotected data a first-class citizen alongside signed data (JWS) and encrypted data (JWE) in the (embarrassingly unnamed) top-level JOSE structure that can hold any of these 3 forms of data -- and is the JOSE structure that other specs will use.
>>>
>>> Having JWS and JWE in separate specs means there isn't an obvious place to specify the top-level JOSE structure (so it is done awkwardly in the OAuth JWT spec). We could add two more JOSE specs: JWP (plain/unprotected data) and JOSE (top-level structure = {JWS|JWE|JWP}). I think a better approach would be to (re-)combine JWS and JWE. The combined spec would include unprotected data as a third mode. The algorithms spec can remain separate.
>>>
>>> --
>>> James Manger
>>>
>>>
>>> -----Original Message-----
>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf
>>> Of Mike Jones
>>> Sent: Tuesday, 29 May 2012 2:44 AM
>>> To: Sean Turner; Vladimir Dzhuvinov / NimbusDS
>>> Cc: jose@ietf.org
>>> Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
>>>
>>> For what it's worth, "alg":"none" was moved from JWT to JWS based upon Jim Schaad's suggestion in http://www.ietf.org/mail-archive/web/jose/current/msg00365.html for closing the open issue about whether it belongs in JWT or JWS.  In it, he wrote:
>>>
>>> [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 believe his rationale was correct and has been proven out by events.  At this point I now of several usages of "none" both within JWTs, and significantly, in at least one context where the structure is a JWS but *not* a JWT.  I believe Jim was right to suggest that "alg":"none" belongs in the Algorithms specification.
>>>
>>> 				Best wishes,
>>> 				-- Mike
>>>
>>> -----Original Message-----
>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf
>>> Of Sean Turner
>>> Sent: Monday, May 28, 2012 8:22 AM
>>> To: Vladimir Dzhuvinov / NimbusDS
>>> Cc: jose@ietf.org
>>> Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
>>>
>>> On 5/28/12 1:47 AM, Vladimir Dzhuvinov / NimbusDS wrote:
>>>>> On 5/22/12 3:53 AM, Vladimir Dzhuvinov / NimbusDS wrote:
>>>>>>
>>>>>>>> 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"
>>>>>>
>>>>>> +1 for deprecating none.
>>>>>>
>>>>>> The same information can be expressed by simply omitting "alg".
>>>>>> This makes plain JWTs nimbler too. I see no problem with having
>>>>>> empty headers for plain JWTs.
>>>>>>
>>>>>> Also, by removing "none", "alg" would become consistent with the
>>>>>> rest of the parameters which don't have "none" values (we don't
>>>>>> have "enc":"none", etc.). Very much like the recent change to "zip"
>>>>>> (JWS, section 4.1.6) which no longer has the (optional) "none":
>>>>>> it's either "zip":"DEF" or nothing.
>>>>>
>>>>> Just make sure to explain what it means when alg is omitted. Assume
>>>>> this would apply equally to both JSW and JWE?
>>>>>
>>>>> spt
>>>>
>>>> My understanding is that this should actually be explained in the
>>>> JSON Web Token (JWT) spec where the concept of plain tokens is
>>>> originally introduced. Therefore, the case of a missing "alg" should
>>>> fall outside the scope of the JWS and JWE specs.
>>>
>>> That's one possibility but then you're introducing a normative reference.  If draft-ietf-jose-json-web-algorithms, is going to retain the section on creating plaintext JWS then it's worth saying how empty would be handled - and then you can avoid the reference.
>>>
>>> spt
>>>
>>>
>>>
>>> _______________________________________________
>>> jose mailing list
>>> jose@ietf.org
>>> https://www.ietf.org/mailman/listinfo/jose
>>
>>
>>
>
>

From Michael.Jones@microsoft.com  Tue May 29 17:45: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 3130D11E818D for ; Tue, 29 May 2012 17:45:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.693
X-Spam-Level: 
X-Spam-Status: No, score=-3.693 tagged_above=-999 required=5 tests=[AWL=-0.094, 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 hGMG2D2IHT+z for ; Tue, 29 May 2012 17:45:57 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id A195C21F8687 for ; Tue, 29 May 2012 17:45:55 -0700 (PDT)
Received: from mail203-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Wed, 30 May 2012 00:45:31 +0000
Received: from mail203-va3 (localhost [127.0.0.1])	by mail203-va3-R.bigfish.com (Postfix) with ESMTP id 2C80E7C0189; Wed, 30 May 2012 00:45:31 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI
X-SpamScore: -34
X-BigFish: VS-34(zz9371I1102I148cI542M1432Nzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah)
Received-SPF: pass (mail203-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=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail203-va3 (localhost.localdomain [127.0.0.1]) by mail203-va3 (MessageSwitch) id 1338338729566346_22731; Wed, 30 May 2012 00:45:29 +0000 (UTC)
Received: from VA3EHSMHS013.bigfish.com (unknown [10.7.14.251])	by mail203-va3.bigfish.com (Postfix) with ESMTP id 7E94A680045; Wed, 30 May 2012 00:45:29 +0000 (UTC)
Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS013.bigfish.com (10.7.99.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 30 May 2012 00:45:28 +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; Wed, 30 May 2012 00:45:49 +0000
From: Mike Jones 
To: "Manger, James H" , "jose@ietf.org" 
Thread-Topic: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
Thread-Index: Ac02D5hCCAHMzxPmQDC/RwzlQzAQzwBonveQAZLLC/A=
Date: Wed, 30 May 2012 00:45:48 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436651EC73@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <026d01cd37a3$8215dc00$86419400$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E114F2FE718A@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F2FE718A@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.75]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
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: Wed, 30 May 2012 00:45:58 -0000

Hi James,

Thanks for pointing out the legal AES GCM "authentication tag" sizes.  The =
next version of the JWE spec will say "The requested size of the 'authentic=
ation tag' output MUST be 128 bits, regardless of the key size", as you sug=
gested.

				-- Mike

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Man=
ger, James H
Sent: Monday, May 21, 2012 6:32 PM
To: jose@ietf.org
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

> Section 3.1
>
> 1.  I am not overly happy with the existence of a "none" algorithm. =20
> 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=20
> the fact that this document is saying that the output should be=20
> base64url encoded.  If the JWS document says the same thing=20
> injudiciously then one could easily see that people might double encode t=
he 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
_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose



From James.H.Manger@team.telstra.com  Tue May 29 17:59: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 5CDAC21F870E for ; Tue, 29 May 2012 17:59:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.664
X-Spam-Level: 
X-Spam-Status: No, score=-0.664 tagged_above=-999 required=5 tests=[AWL=0.237,  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 buzakRAeuDBf for ; Tue, 29 May 2012 17:59:49 -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 967AA21F85CC for ; Tue, 29 May 2012 17:59:48 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.75,681,1330866000"; d="scan'208";a="77891336"
Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 30 May 2012 10:59:46 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6726"; a="65398619"
Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipcdvi.tcif.telstra.com.au with ESMTP; 30 May 2012 10:59:45 +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, 30 May 2012 10:59:46 +1000
From: "Manger, James H" 
To: Sean Turner , John Bradley 
Date: Wed, 30 May 2012 10:59:44 +1000
Thread-Topic: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
Thread-Index: Ac09/YV1UZblHL4kS5q0iqLl8CHilgAAEjZg
Message-ID: <255B9BB34FB7D647A506DC292726F6E114F4EB4474@WSMSG3153V.srv.dir.telstra.com>
References: <20120527224709.cc40c4f3d92d2001859047cd8cabb9ab.7bdf13f113.wbe@email07.europe.secureserver.net> <4FC397FE.3040001@ieca.com> <4E1F6AAD24975D4BA5B16804296739436651CC6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4D32D9C@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436651D0E6@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4D3351F@WSMSG3153V.srv.dir.telstra.com> <8A66CBDB-2159-437E-B322-0BCC9E4F7657@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739436651EB52@TK5EX14MBXC284.redmond.corp.microsoft.com>  <4FC56D9A.1070208@ieca.com>
In-Reply-To: <4FC56D9A.1070208@ieca.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] 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: Wed, 30 May 2012 00:59:49 -0000

>On 5/29/12 8:26 PM, John Bradley wrote:
>> A HMAC is useful to protect against intentional manipulation of a messag=
e, but requires a shared secret.
>>
>> Sometimes you just want to message integrity against accidental modifica=
tion.  In that case a SHA256 or other hash would do without the need to hav=
e a shared secret.

Sean Turner wrote:
>I support this idea.


I doubt this is useful enough to warrant inclusion, but if it is can we ple=
ase not sneak it in as a fake signature algorithm that doesn't actually off=
er authenticity. That is, don't pretend it is a JWS. Make it a first-class =
citizen amongst the JOSE modes (so we need somewhere to describe all the mo=
des).

Crypto-strength collision-resistant secure hashes can be used as checksums,=
 but there are a bunch of "better" algorithms specifically designed for the=
 task (eg CRCs, or even error correcting codes...).

--
James Manger

From James.H.Manger@team.telstra.com  Tue May 29 18:04: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 30BFD21F8722 for ; Tue, 29 May 2012 18:04:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.684
X-Spam-Level: 
X-Spam-Status: No, score=-0.684 tagged_above=-999 required=5 tests=[AWL=0.217,  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 xZscm7I8-xeU for ; Tue, 29 May 2012 18:04: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 4B77A21F8714 for ; Tue, 29 May 2012 18:04:30 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.75,681,1330866000"; d="scan'208";a="80824092"
Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipoani.tcif.telstra.com.au with ESMTP; 30 May 2012 11:04:29 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6726"; a="66240021"
Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipccni.tcif.telstra.com.au with ESMTP; 30 May 2012 11:04:29 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Wed, 30 May 2012 11:04:29 +1000
From: "Manger, James H" 
To: "jose@ietf.org" 
Date: Wed, 30 May 2012 11:04:27 +1000
Thread-Topic: JWE: encrypted key as component vs header element
Thread-Index: Ac0+ACks+lG4TUwESkicPwXCSR2HFw==
Message-ID: <255B9BB34FB7D647A506DC292726F6E114F4EB4492@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] JWE: encrypted key as component vs header element
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 01:04:31 -0000

Encrypted data (JWE) uses the syntax: 
..=
.

Is there a reason that the encrypted key isn't included as a header element=
?

I thought it could be because the encrypted key is specific to one recipien=
t (eg it is encrypted with the recipient's public key) and it might be usef=
ul to separate per-recipient details for cases where a message is encrypted=
 for multiple recipients (using another serialization, such as JWE-JS).

However that doesn't work. JWE-JS repeats the header for each recipient, an=
d it has to since the header needs to include an id for the recipient's key=
.


It could be slightly helpful (eg for performance) to separate details that =
definitely vary per message from details that will probably remain the same=
 for all messages between two parties. For this benefit, though, the IV wou=
ld need to be moved out of the header (and conveyed as a prefix on the ciph=
ertext).

--
James Manger



From sakimura@gmail.com  Tue May 29 18:12: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 087C011E8127 for ; Tue, 29 May 2012 18:12:32 -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, 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 JfnQ7bnN0wrP for ; Tue, 29 May 2012 18:12:31 -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 3F0F021F8758 for ; Tue, 29 May 2012 18:12:31 -0700 (PDT)
Received: by bkty8 with SMTP id y8so4452545bkt.31 for ; Tue, 29 May 2012 18:12:30 -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:content-transfer-encoding; bh=zo+SWe8LVrolGplWDhCPDY2PAbTdEq3ihQVAqUJZPjI=; b=mPsDxOs48dYGtJd0LHcGtXfn5N86sWFukmd6zNJAglNbh0iSCMYe/TWKDmTu9GuSzH Jb5Z941U7VXtfE+UBk6hRFU7ydRMDP3V2go/xtXTuYyicrVRRbUydfzAPO6JFvDTmirY AU27HiG9bTj3npPqTXkEqtAvpu+KjbAoXurfpmv27LmyBkatefv5L78mRY54WJ+PFKvu gui642SG5byyR88+Sj90i2CMQ6tEy5H0cByfJF+O5k3LSiXp9q6/uHr1blUlUljaWwDG IY1a+AEJvojEzIN5CAsvPVEfkgh7bX2GNBFeetMt/UAXWtkONq1ohNbPC9Ec324bEVhG GiRQ==
Received: by 10.204.154.18 with SMTP id m18mr7953640bkw.23.1338340350127; Tue, 29 May 2012 18:12:30 -0700 (PDT)
References: <255B9BB34FB7D647A506DC292726F6E114F4EB4492@WSMSG3153V.srv.dir.telstra.com>
From: Nat Sakimura 
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F4EB4492@WSMSG3153V.srv.dir.telstra.com>
Mime-Version: 1.0 (1.0)
Date: Wed, 30 May 2012 10:12:29 +0900
Message-ID: <-242476885365442395@unknownmsgid>
To: "Manger, James H" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "jose@ietf.org" 
Subject: Re: [jose] JWE: encrypted key as component vs header element
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 01:12:32 -0000

I pushed the same couple of months ago for the sake if uniformity and
the composability across JWS and JWE but did not get a support.

The reason given and had support if I remember correctly was a desire
to avoid double base64 encoding.

=3Dnat via iPhone

On 2012/05/30, at 10:04, "Manger, James H"
 wrote:

> Encrypted data (JWE) uses the syntax: 
...
>
> Is there a reason that the encrypted key isn't included as a header eleme=
nt?
>
> I thought it could be because the encrypted key is specific to one recipi=
ent (eg it is encrypted with the recipient's public key) and it might be us=
eful to separate per-recipient details for cases where a message is encrypt=
ed for multiple recipients (using another serialization, such as JWE-JS).
>
> However that doesn't work. JWE-JS repeats the header for each recipient, =
and it has to since the header needs to include an id for the recipient's k=
ey.
>
>
> It could be slightly helpful (eg for performance) to separate details tha=
t definitely vary per message from details that will probably remain the sa=
me for all messages between two parties. For this benefit, though, the IV w=
ould need to be moved out of the header (and conveyed as a prefix on the ci=
phertext).
>
> --
> James Manger
>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose

From Michael.Jones@microsoft.com  Tue May 29 18:13: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 B5D5511E8127 for ; Tue, 29 May 2012 18:13:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.687
X-Spam-Level: 
X-Spam-Status: No, score=-3.687 tagged_above=-999 required=5 tests=[AWL=-0.088, 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 5e5+SzZH+bJN for ; Tue, 29 May 2012 18:13:19 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id BFEC221F8758 for ; Tue, 29 May 2012 18:13:18 -0700 (PDT)
Received: from mail81-am1-R.bigfish.com (10.3.201.235) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 30 May 2012 01:12:54 +0000
Received: from mail81-am1 (localhost [127.0.0.1])	by mail81-am1-R.bigfish.com (Postfix) with ESMTP id 1D81E6009A; Wed, 30 May 2012 01:12:54 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI
X-SpamScore: -30
X-BigFish: VS-30(zz9371I542M98aLzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah)
Received-SPF: pass (mail81-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail81-am1 (localhost.localdomain [127.0.0.1]) by mail81-am1 (MessageSwitch) id 1338340371964011_10572; Wed, 30 May 2012 01:12:51 +0000 (UTC)
Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.239])	by mail81-am1.bigfish.com (Postfix) with ESMTP id E977740043; Wed, 30 May 2012 01:12:51 +0000 (UTC)
Received: from TK5EX14MLTC103.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; Wed, 30 May 2012 01:12:51 +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; Wed, 30 May 2012 01:13:12 +0000
From: Mike Jones 
To: "Manger, James H" , "jose@ietf.org" 
Thread-Topic: JWE: encrypted key as component vs header element
Thread-Index: Ac0+ACks+lG4TUwESkicPwXCSR2HFwAAMoFw
Date: Wed, 30 May 2012 01:13:11 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436651ED39@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <255B9BB34FB7D647A506DC292726F6E114F4EB4492@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F4EB4492@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.75]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Subject: Re: [jose] JWE: encrypted key as component vs header element
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 01:13:19 -0000

This question was considered during the open issues discussion by the worki=
ng group members present in Paris and there was a clear consensus to have t=
he encrypted key remain in its own field to avoid double base64url encoding=
 a potentially large value.

				-- Mike

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Man=
ger, James H
Sent: Tuesday, May 29, 2012 6:04 PM
To: jose@ietf.org
Subject: [jose] JWE: encrypted key as component vs header element

Encrypted data (JWE) uses the syntax: 
..=
.

Is there a reason that the encrypted key isn't included as a header element=
?

I thought it could be because the encrypted key is specific to one recipien=
t (eg it is encrypted with the recipient's public key) and it might be usef=
ul to separate per-recipient details for cases where a message is encrypted=
 for multiple recipients (using another serialization, such as JWE-JS).

However that doesn't work. JWE-JS repeats the header for each recipient, an=
d it has to since the header needs to include an id for the recipient's key=
.


It could be slightly helpful (eg for performance) to separate details that =
definitely vary per message from details that will probably remain the same=
 for all messages between two parties. For this benefit, though, the IV wou=
ld need to be moved out of the header (and conveyed as a prefix on the ciph=
ertext).

--
James Manger


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



From James.H.Manger@team.telstra.com  Tue May 29 18:17:14 2012
Return-Path: 
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80CA511E8186 for ; Tue, 29 May 2012 18:17:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level: 
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[AWL=0.200,  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 hi+OsdU-kAeQ for ; Tue, 29 May 2012 18:17:13 -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 5451B11E8127 for ; Tue, 29 May 2012 18:17:13 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.75,681,1330866000"; d="scan'208";a="74777510"
Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 30 May 2012 11:17:12 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6726"; a="65764805"
Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcbni.tcif.telstra.com.au with ESMTP; 30 May 2012 11:17:12 +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, 30 May 2012 11:17:12 +1000
From: "Manger, James H" 
To: "jose@ietf.org" 
Date: Wed, 30 May 2012 11:17:11 +1000
Thread-Topic: JWE: encrypted key as component vs header element
Thread-Index: Ac0+ACks+lG4TUwESkicPwXCSR2HFwAAMoFwAAAgp+A=
Message-ID: <255B9BB34FB7D647A506DC292726F6E114F4EB44FB@WSMSG3153V.srv.dir.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E114F4EB4492@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436651ED39@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436651ED39@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
Subject: Re: [jose] JWE: encrypted key as component vs header element
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 01:17:14 -0000

>> Is there a reason that the encrypted key isn't included as a header elem=
ent?

Nat answered:
> I pushed the same couple of months ago for the sake if uniformity and the=
 composability across JWS and JWE but did not get a support.
>
>The reason given and had support if I remember correctly was a desire to a=
void double base64 encoding.

Mike answered:
> This question was considered during the open issues discussion by the wor=
king group members present in Paris and there was a clear consensus to have=
 the encrypted key remain in its own field to avoid double base64url encodi=
ng a potentially large value.


Thanks. Makes sense.

--
James Manger

From James.H.Manger@team.telstra.com  Tue May 29 18:52: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 3F72611E815D for ; Tue, 29 May 2012 18:52:59 -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 rTbSH5XSwEnQ for ; Tue, 29 May 2012 18:52:58 -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 7B7F111E80E1 for ; Tue, 29 May 2012 18:52:58 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.75,681,1330866000"; d="scan'208";a="77902429"
Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 30 May 2012 11:52:57 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6726"; a="69075876"
Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcavi.tcif.telstra.com.au with ESMTP; 30 May 2012 11:52:57 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Wed, 30 May 2012 11:52:57 +1000
From: "Manger, James H" 
To: "jose@ietf.org" 
Date: Wed, 30 May 2012 11:52:56 +1000
Thread-Topic: JWE: key agreement algorithms and the content master key
Thread-Index: Ac0+Bu7R5rDWfxGBRm6jQhhXYQKaCw==
Message-ID: <255B9BB34FB7D647A506DC292726F6E114F4EB45F6@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] JWE: key agreement algorithms and the content master key
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 01:52:59 -0000

One option for constructing an encrypted message (JWE) is to use a key agre=
ement mechanism. The draft says:

  when key agreement is employed,
  use the key agreement algorithm to compute the value
  of the Content Master Key (CMK)

  when key agreement is employed,
  let the JWE Encrypted Key be an empty byte array

Is this a good approach?

It differs from the approach in Crypto Message Syntax Standard (CMS) [rfc56=
52#section-6.2.2], where the secret that the key agreement mechanism genera=
tes is used to encrypt a randomly chosen CMK.

Sharing the ciphertext when encrypting for multiple recipients (as done in =
the JWE-JS serialization) presumably cannot work when JWE key agreement is =
used since the CMK is per-recipient, not per-message.

The JWE key agreement might also generates the same CMK for all messages ex=
changed between two parties. That sounds unacceptable. Perhaps this is avoi=
dable by assuming/requiring the sender uses a per-message ephemeral key pai=
r?

I am inclined to stick with the CMS approach. It adds about 32 chars to the=
 message (for a 128-bit key) and a key wrapping step.

--
James Manger



From vladimir@nimbusds.com  Wed May 30 03:35: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 5D76021F869F for ; Wed, 30 May 2012 03:35:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.166
X-Spam-Level: 
X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433,  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 KptuTIqwk5H8 for ; Wed, 30 May 2012 03:35:34 -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 CAB7C21F869E for ; Wed, 30 May 2012 03:35:33 -0700 (PDT)
Received: (qmail 20390 invoked from network); 30 May 2012 10:35:32 -0000
Received: from unknown (HELO localhost) (188.121.52.246) by n1plwbeout07-02.prod.ams1.secureserver.net with SMTP; 30 May 2012 10:35:31 -0000
Received: (qmail 22635 invoked by uid 99); 30 May 2012 10:35:31 -0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Originating-IP: 79.100.211.163
User-Agent: Workspace Webmail 5.6.17
Message-Id: <20120530033530.cc40c4f3d92d2001859047cd8cabb9ab.796e470ee8.wbe@email07.europe.secureserver.net>
From: "Vladimir Dzhuvinov / NimbusDS" 
To: "Mike Jones" , "Manger,  James H" , "Sean Turner" 
Date: Wed, 30 May 2012 03:35:30 -0700
Mime-Version: 1.0
Cc: "jose@ietf.org" 
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 10:35:35 -0000

Hi guys,=0A=0AI have to say I quite liked James Manger's comment. Giving pl=
ain=0Awhatever-data with JSON Web Header "first-class-citizen" status is no=
t=0Awithout merit. As a programmer I love it when the language + structure=
=0Aof a spec is crafted in such a way as to flow by itself into well=0Astru=
ctured code. For instance, taking the terms of a spec and turning=0Athem in=
to a nice hierarchy of classes.=0A=0AIn our Nimbus-JWT library PlainJWT, Si=
gnedJWT and EncryptedJWT all=0Aextend the base class JWT. From a programmer=
's perspective this is the=0Anatural way of seeing JWT protection. We do no=
t have a=0ASignedJWT.isPlain() or similar method to convey the meaning of a=
 plain=0AJWT (and have undefined method for all signature related operation=
s).=0A=0AIf naming is the problem, then let's acknowledge this and then we'=
ll sit=0Adown and meditate on a suitable term for this unprotected-data-wit=
h JSON=0AWeb header.=0A=0AAnd if we need a common name for this header, why=
 not call it JSON Web=0AHeader (JWH) :-)=0A=0A=0AVladimir=0A=0A--=0AVladimi=
r Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com=0A=0A=0A=0A-------- =
Original Message --------=0ASubject: RE: [jose] Comments on draft-ietf-jose=
-json-web-algorithms-02=0AFrom: Mike Jones =0A=
Date: Tue, May 29, 2012 5:34 am=0ATo: "Manger, James H" , Sean Turner=0A, Vladimir Dzhuvinov / Nimb=
usDS=0A=0ACc: "jose@ietf.org" =0A=0A=
=0AActually, the third mode already exists, and is parallel, by design, to=
=0Athe signed/MACed and encrypted modes. No restructuring is necessary to=
=0Aachieve this. The three are all unambiguously distinguished by the value=
=0Aof the "alg" parameter (the value of which MUST be understood, or else=
=0Athe structure must be rejected).=0A=0A -- Mike=0A=0A-----Original Messag=
e-----=0AFrom: Manger, James H [mailto:James.H.Manger@team.telstra.com] =0A=
Sent: Monday, May 28, 2012 5:23 PM=0ATo: Mike Jones; Sean Turner; Vladimir =
Dzhuvinov / NimbusDS=0ACc: jose@ietf.org=0ASubject: RE: [jose] Comments on =
draft-ietf-jose-json-web-algorithms-02=0A=0A"alg":"none" certainly doesn't =
belong in the OAuth JWT spec that defines=0Aa format for identity claims.=
=0A=0ASticking "alg":"none" in a JOSE core spec is not the answer, however.=
=0AThe solution is to make unprotected data a first-class citizen alongside=
=0Asigned data (JWS) and encrypted data (JWE) in the (embarrassingly=0Aunna=
med) top-level JOSE structure that can hold any of these 3 forms of=0Adata =
-- and is the JOSE structure that other specs will use.=0A=0AHaving JWS and=
 JWE in separate specs means there isn't an obvious place=0Ato specify the =
top-level JOSE structure (so it is done awkwardly in the=0AOAuth JWT spec).=
 We could add two more JOSE specs: JWP=0A(plain/unprotected data) and JOSE =
(top-level structure =3D {JWS|JWE|JWP}).=0AI think a better approach would =
be to (re-)combine JWS and JWE. The=0Acombined spec would include unprotect=
ed data as a third mode. The=0Aalgorithms spec can remain separate.=0A=0A--=
=0AJames Manger=0A=0A=0A-----Original Message-----=0AFrom: jose-bounces@iet=
f.org [mailto:jose-bounces@ietf.org] On Behalf Of=0AMike Jones=0ASent: Tues=
day, 29 May 2012 2:44 AM=0ATo: Sean Turner; Vladimir Dzhuvinov / NimbusDS=
=0ACc: jose@ietf.org=0ASubject: Re: [jose] Comments on draft-ietf-jose-json=
-web-algorithms-02=0A=0AFor what it's worth, "alg":"none" was moved from JW=
T to JWS based upon=0AJim Schaad's suggestion in=0Ahttp://www.ietf.org/mail=
-archive/web/jose/current/msg00365.html for=0Aclosing the open issue about =
whether it belongs in JWT or JWS. In it, he=0Awrote:=0A=0A[JLS] If it is be=
lieve that a parameter this list is going to be=0A"commonly" used by many d=
ifferent profilers, then I believe that the=0Acore items needs to be done t=
he in the base specification.=0A=0AI believe his rationale was correct and =
has been proven out by events.=0AAt this point I now of several usages of "=
none" both within JWTs, and=0Asignificantly, in at least one context where =
the structure is a JWS but=0A*not* a JWT. I believe Jim was right to sugges=
t that "alg":"none"=0Abelongs in the Algorithms specification.=0A=0A Best w=
ishes,=0A -- Mike=0A=0A-----Original Message-----=0AFrom: jose-bounces@ietf=
.org [mailto:jose-bounces@ietf.org] On Behalf Of=0ASean Turner=0ASent: Mond=
ay, May 28, 2012 8:22 AM=0ATo: Vladimir Dzhuvinov / NimbusDS=0ACc: jose@iet=
f.org=0ASubject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms=
-02=0A=0AOn 5/28/12 1:47 AM, Vladimir Dzhuvinov / NimbusDS wrote:=0A>> On 5=
/22/12 3:53 AM, Vladimir Dzhuvinov / NimbusDS wrote:=0A>>>=0A>>>>> Section =
3.1=0A>>>>>=0A>>>>> 1. I am not overly happy with the existence of a "none"=
 algorithm. =0A>>>>> Does it really need to exist?=0A>>>>=0A>>>> +1 for rem=
oving "none"=0A>>>=0A>>> +1 for deprecating none.=0A>>>=0A>>> The same info=
rmation can be expressed by simply omitting "alg". This =0A>>> makes plain =
JWTs nimbler too. I see no problem with having empty =0A>>> headers for pla=
in JWTs.=0A>>>=0A>>> Also, by removing "none", "alg" would become consisten=
t with the =0A>>> rest of the parameters which don't have "none" values (we=
 don't have =0A>>> "enc":"none", etc.). Very much like the recent change to=
 "zip" (JWS, =0A>>> section 4.1.6) which no longer has the (optional) "none=
": it's =0A>>> either "zip":"DEF" or nothing.=0A>>=0A>> Just make sure to e=
xplain what it means when alg is omitted. Assume =0A>> this would apply equ=
ally to both JSW and JWE?=0A>>=0A>> spt=0A>=0A> My understanding is that th=
is should actually be explained in the JSON =0A> Web Token (JWT) spec where=
 the concept of plain tokens is originally =0A> introduced. Therefore, the =
case of a missing "alg" should fall outside =0A> the scope of the JWS and J=
WE specs.=0A=0AThat's one possibility but then you're introducing a normati=
ve=0Areference. If draft-ietf-jose-json-web-algorithms, is going to retain=
=0Athe section on creating plaintext JWS then it's worth saying how empty=
=0Awould be handled - and then you can avoid the reference.=0A=0Aspt=0A

From ietf@augustcellars.com  Wed May 30 07:57: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 1403111E8087 for ; Wed, 30 May 2012 07:57:08 -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 uy6-rF+8r4Op for ; Wed, 30 May 2012 07:57:06 -0700 (PDT)
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id A0AAD21F8620 for ; Wed, 30 May 2012 07:57:06 -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 1E32838F24; Wed, 30 May 2012 07:57:06 -0700 (PDT)
From: "Jim Schaad" 
To: "'Manger, James H'" , "'Mike Jones'" , "'Sean Turner'" , "'Vladimir Dzhuvinov / NimbusDS'" 
References: <20120527224709.cc40c4f3d92d2001859047cd8cabb9ab.7bdf13f113.wbe@email07.europe.secureserver.net>	<4FC397FE.3040001@ieca.com>	<4E1F6AAD24975D4BA5B16804296739436651CC6A@TK5EX14MBXC284.redmond.corp.microsoft.com>	<255B9BB34FB7D647A506DC292726F6E114F4D32D9C@WSMSG3153V.srv.dir.telstra.com>	<4E1F6AAD24975D4BA5B16804296739436651D0E6@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4D3351F@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F4D3351F@WSMSG3153V.srv.dir.telstra.com>
Date: Wed, 30 May 2012 07:55:58 -0700
Message-ID: <050f01cd3e74$53013950$f903abf0$@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: AQIdT9Rs/SJOJh5Xk6n2z6Qj+ZffaAIS1VXgAeDb47sBhk+kJAFhbl/1AVWEeYeWAMEOgA==
Content-Language: en-us
Cc: jose@ietf.org
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 14:57:08 -0000

One additional reason that I have thought of why we may want something other
than just alg to distinguish between the types is to that it would not be
possible to report to the user

I do not understand the signing algorithm FooBar.  You know the name but no
the algorithm type.

Jim


> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> Manger, James H
> Sent: Monday, May 28, 2012 10:13 PM
> To: Mike Jones; Sean Turner; Vladimir Dzhuvinov / NimbusDS
> Cc: jose@ietf.org
> Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
> 
> Sure, the third mode (plaintext) already exists -- but it is not parallel
to the
> signed/MACed and encrypted modes. It is an awkward sub-mode of the
> signed/MACed mode -- reusing the same fields, but with dummy or blank
> values; providing completely different security; not mentioned in the JWS
> abstract; only appearing in an appendix (A.4. Example Plaintext JWS);
without
> a separate "typ" value or MIME type etc.
> 
> I think the alg value is a poor way to distinguish unprotected, signed,
and
> encrypted JWx messages. Even it that mechanism remains though, I would
> like plaintext mode to be a "first-class citizen". The fact that plaintext
mode is
> hidden away is actually a symptom of not having a place to specify the
JOSE
> top-level structure {signed data | encrypted data | unprotected data}.
> 
> --
> James Manger
> 
> 
> -----Original Message-----
> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> Sent: Tuesday, 29 May 2012 2:35 PM
> To: Manger, James H; Sean Turner; Vladimir Dzhuvinov / NimbusDS
> Cc: jose@ietf.org
> Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
> 
> Actually, the third mode already exists, and is parallel, by design, to
the
> signed/MACed and encrypted modes.  No restructuring is necessary to
> achieve this.  The three are all unambiguously distinguished by the value
of
> the "alg" parameter (the value of which MUST be understood, or else the
> structure must be rejected).
> 
> 					-- Mike
> 
> -----Original Message-----
> From: Manger, James H [mailto:James.H.Manger@team.telstra.com]
> Sent: Monday, May 28, 2012 5:23 PM
> To: Mike Jones; Sean Turner; Vladimir Dzhuvinov / NimbusDS
> Cc: jose@ietf.org
> Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
> 
> "alg":"none" certainly doesn't belong in the OAuth JWT spec that defines a
> format for identity claims.
> 
> Sticking "alg":"none" in a JOSE core spec is not the answer, however. The
> solution is to make unprotected data a first-class citizen alongside
signed data
> (JWS) and encrypted data (JWE) in the (embarrassingly unnamed) top-level
> JOSE structure that can hold any of these 3 forms of data -- and is the
JOSE
> structure that other specs will use.
> 
> Having JWS and JWE in separate specs means there isn't an obvious place to
> specify the top-level JOSE structure (so it is done awkwardly in the OAuth
> JWT spec). We could add two more JOSE specs: JWP (plain/unprotected
> data) and JOSE (top-level structure = {JWS|JWE|JWP}). I think a better
> approach would be to (re-)combine JWS and JWE. The combined spec would
> include unprotected data as a third mode. The algorithms spec can remain
> separate.
> 
> --
> James Manger
> 
> 
> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> Mike Jones
> Sent: Tuesday, 29 May 2012 2:44 AM
> To: Sean Turner; Vladimir Dzhuvinov / NimbusDS
> Cc: jose@ietf.org
> Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
> 
> For what it's worth, "alg":"none" was moved from JWT to JWS based upon
> Jim Schaad's suggestion in http://www.ietf.org/mail-
> archive/web/jose/current/msg00365.html for closing the open issue about
> whether it belongs in JWT or JWS.  In it, he wrote:
> 
> [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 believe his rationale was correct and has been proven out by events.  At
this
> point I now of several usages of "none" both within JWTs, and
significantly, in
> at least one context where the structure is a JWS but *not* a JWT.  I
believe
> Jim was right to suggest that "alg":"none" belongs in the Algorithms
> specification.
> 
> 				Best wishes,
> 				-- Mike
> 
> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> Sean Turner
> Sent: Monday, May 28, 2012 8:22 AM
> To: Vladimir Dzhuvinov / NimbusDS
> Cc: jose@ietf.org
> Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
> 
> On 5/28/12 1:47 AM, Vladimir Dzhuvinov / NimbusDS wrote:
> >> On 5/22/12 3:53 AM, Vladimir Dzhuvinov / NimbusDS wrote:
> >>>
> >>>>> 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"
> >>>
> >>> +1 for deprecating none.
> >>>
> >>> The same information can be expressed by simply omitting "alg". This
> >>> makes plain JWTs nimbler too. I see no problem with having empty
> >>> headers for plain JWTs.
> >>>
> >>> Also, by removing "none", "alg" would become consistent with the
> >>> rest of the parameters which don't have "none" values (we don't have
> >>> "enc":"none", etc.). Very much like the recent change to "zip" (JWS,
> >>> section 4.1.6) which no longer has the (optional) "none": it's
> >>> either "zip":"DEF" or nothing.
> >>
> >> Just make sure to explain what it means when alg is omitted. Assume
> >> this would apply equally to both JSW and JWE?
> >>
> >> spt
> >
> > My understanding is that this should actually be explained in the JSON
> > Web Token (JWT) spec where the concept of plain tokens is originally
> > introduced. Therefore, the case of a missing "alg" should fall outside
> > the scope of the JWS and JWE specs.
> 
> That's one possibility but then you're introducing a normative reference.
If
> draft-ietf-jose-json-web-algorithms, is going to retain the section on
creating
> plaintext JWS then it's worth saying how empty would be handled - and then
> you can avoid the reference.
> 
> spt
> 
> 
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose


From Michael.Jones@microsoft.com  Wed May 30 10:17: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 123FA11E8097 for ; Wed, 30 May 2012 10:17:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.382
X-Spam-Level: 
X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, J_CHICKENPOX_35=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 Xjm479QhOonM for ; Wed, 30 May 2012 10:17:53 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id DB19021F859A for ; Wed, 30 May 2012 10:17:52 -0700 (PDT)
Received: from mail27-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Wed, 30 May 2012 17:17:26 +0000
Received: from mail27-va3 (localhost [127.0.0.1])	by mail27-va3-R.bigfish.com (Postfix) with ESMTP id 353793A0345; Wed, 30 May 2012 17:17:26 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI
X-SpamScore: -36
X-BigFish: VS-36(zzbb2dI9371I542M1432N98dKzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah)
Received-SPF: pass (mail27-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail27-va3 (localhost.localdomain [127.0.0.1]) by mail27-va3 (MessageSwitch) id 1338398244290825_11451; Wed, 30 May 2012 17:17:24 +0000 (UTC)
Received: from VA3EHSMHS001.bigfish.com (unknown [10.7.14.240])	by mail27-va3.bigfish.com (Postfix) with ESMTP id 432A746004A; Wed, 30 May 2012 17:17:24 +0000 (UTC)
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS001.bigfish.com (10.7.99.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 30 May 2012 17:17:22 +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; Wed, 30 May 2012 17:17:44 +0000
From: Mike Jones 
To: Jim Schaad , "'Manger, James H'" , 'Sean Turner' , 'Vladimir Dzhuvinov / NimbusDS' 
Thread-Topic: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
Thread-Index: AQHNPJVSCAHMzxPmQDC/RwzlQzAQz5bfUfcAgAAURHCAAHcoEIAATa+ggAAGurCAAj2tAIAAIUfA
Date: Wed, 30 May 2012 17:17:44 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436651F9DA@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <20120527224709.cc40c4f3d92d2001859047cd8cabb9ab.7bdf13f113.wbe@email07.europe.secureserver.net> <4FC397FE.3040001@ieca.com> <4E1F6AAD24975D4BA5B16804296739436651CC6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4D32D9C@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436651D0E6@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4D3351F@WSMSG3153V.srv.dir.telstra.com> <050f01cd3e74$53013950$f903abf0$@augustcellars.com>
In-Reply-To: <050f01cd3e74$53013950$f903abf0$@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: 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 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: Wed, 30 May 2012 17:17:54 -0000

There already is a method other than the "alg" value for distinguishing bet=
ween the types.  If the "enc" header parameter is present, then the "alg" v=
alue names an encryption algorithm.  So code to accomplish what you're aski=
ng for below would be:

    if alg.value not understood {
        if enc value present {
            print "Encryption";
        } else {
            print "Signature or MAC";
        }
        print " \"alg\" value " + alg.value + " not understood\n";
        throw exception ...;
    }

BTW, this is already explained in http://tools.ietf.org/html/draft-ietf-oau=
th-json-web-token-00#section-5, which says:

   There are two ways of distinguishing whether the JWT is a JWS or JWE.
   The first is by examining the "alg" (algorithm) header value.  If the
   value represents a signature algorithm, the JWT is a JWS; if it
   represents an encryption algorithm, the JWT is a JWE.  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.

Since JOSE uses other than JWTs may need to distinguish between JWEs and JW=
Ss, however, I'll plan on moving this text from the JWT spec to the JOSE sp=
ecs in the next round of edits.

				-- Mike

-----Original Message-----
From: Jim Schaad [mailto:ietf@augustcellars.com]=20
Sent: Wednesday, May 30, 2012 7:56 AM
To: 'Manger, James H'; Mike Jones; 'Sean Turner'; 'Vladimir Dzhuvinov / Nim=
busDS'
Cc: jose@ietf.org
Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

One additional reason that I have thought of why we may want something othe=
r than just alg to distinguish between the types is to that it would not be=
 possible to report to the user

I do not understand the signing algorithm FooBar.  You know the name but no=
 the algorithm type.

Jim


> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20
> Of Manger, James H
> Sent: Monday, May 28, 2012 10:13 PM
> To: Mike Jones; Sean Turner; Vladimir Dzhuvinov / NimbusDS
> Cc: jose@ietf.org
> Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
>=20
> Sure, the third mode (plaintext) already exists -- but it is not=20
> parallel
to the
> signed/MACed and encrypted modes. It is an awkward sub-mode of the=20
> signed/MACed mode -- reusing the same fields, but with dummy or blank=20
> values; providing completely different security; not mentioned in the=20
> JWS abstract; only appearing in an appendix (A.4. Example Plaintext=20
> JWS);
without
> a separate "typ" value or MIME type etc.
>=20
> I think the alg value is a poor way to distinguish unprotected,=20
> signed,
and
> encrypted JWx messages. Even it that mechanism remains though, I would=20
> like plaintext mode to be a "first-class citizen". The fact that=20
> plaintext
mode is
> hidden away is actually a symptom of not having a place to specify the
JOSE
> top-level structure {signed data | encrypted data | unprotected data}.
>=20
> --
> James Manger
>=20
>=20
> -----Original Message-----
> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> Sent: Tuesday, 29 May 2012 2:35 PM
> To: Manger, James H; Sean Turner; Vladimir Dzhuvinov / NimbusDS
> Cc: jose@ietf.org
> Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
>=20
> Actually, the third mode already exists, and is parallel, by design,=20
> to
the
> signed/MACed and encrypted modes.  No restructuring is necessary to=20
> achieve this.  The three are all unambiguously distinguished by the=20
> value
of
> the "alg" parameter (the value of which MUST be understood, or else=20
> the structure must be rejected).
>=20
> 					-- Mike
>=20
> -----Original Message-----
> From: Manger, James H [mailto:James.H.Manger@team.telstra.com]
> Sent: Monday, May 28, 2012 5:23 PM
> To: Mike Jones; Sean Turner; Vladimir Dzhuvinov / NimbusDS
> Cc: jose@ietf.org
> Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
>=20
> "alg":"none" certainly doesn't belong in the OAuth JWT spec that=20
> defines a format for identity claims.
>=20
> Sticking "alg":"none" in a JOSE core spec is not the answer, however.=20
> The solution is to make unprotected data a first-class citizen=20
> alongside
signed data
> (JWS) and encrypted data (JWE) in the (embarrassingly unnamed)=20
> top-level JOSE structure that can hold any of these 3 forms of data --=20
> and is the
JOSE
> structure that other specs will use.
>=20
> Having JWS and JWE in separate specs means there isn't an obvious=20
> place to specify the top-level JOSE structure (so it is done awkwardly=20
> in the OAuth JWT spec). We could add two more JOSE specs: JWP=20
> (plain/unprotected
> data) and JOSE (top-level structure =3D {JWS|JWE|JWP}). I think a better=
=20
> approach would be to (re-)combine JWS and JWE. The combined spec would=20
> include unprotected data as a third mode. The algorithms spec can=20
> remain separate.
>=20
> --
> James Manger
>=20
>=20
> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20
> Of Mike Jones
> Sent: Tuesday, 29 May 2012 2:44 AM
> To: Sean Turner; Vladimir Dzhuvinov / NimbusDS
> Cc: jose@ietf.org
> Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
>=20
> For what it's worth, "alg":"none" was moved from JWT to JWS based upon=20
> Jim Schaad's suggestion in http://www.ietf.org/mail-=20
> archive/web/jose/current/msg00365.html for closing the open issue=20
> about whether it belongs in JWT or JWS.  In it, he wrote:
>=20
> [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=20
> to
be
> done the in the base specification.
>=20
> I believe his rationale was correct and has been proven out by events. =20
> At
this
> point I now of several usages of "none" both within JWTs, and
significantly, in
> at least one context where the structure is a JWS but *not* a JWT.  I
believe
> Jim was right to suggest that "alg":"none" belongs in the Algorithms=20
> specification.
>=20
> 				Best wishes,
> 				-- Mike
>=20
> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20
> Of Sean Turner
> Sent: Monday, May 28, 2012 8:22 AM
> To: Vladimir Dzhuvinov / NimbusDS
> Cc: jose@ietf.org
> Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
>=20
> On 5/28/12 1:47 AM, Vladimir Dzhuvinov / NimbusDS wrote:
> >> On 5/22/12 3:53 AM, Vladimir Dzhuvinov / NimbusDS wrote:
> >>>
> >>>>> 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"
> >>>
> >>> +1 for deprecating none.
> >>>
> >>> The same information can be expressed by simply omitting "alg".=20
> >>> This makes plain JWTs nimbler too. I see no problem with having=20
> >>> empty headers for plain JWTs.
> >>>
> >>> Also, by removing "none", "alg" would become consistent with the=20
> >>> rest of the parameters which don't have "none" values (we don't=20
> >>> have "enc":"none", etc.). Very much like the recent change to=20
> >>> "zip" (JWS, section 4.1.6) which no longer has the (optional)=20
> >>> "none": it's either "zip":"DEF" or nothing.
> >>
> >> Just make sure to explain what it means when alg is omitted. Assume=20
> >> this would apply equally to both JSW and JWE?
> >>
> >> spt
> >
> > My understanding is that this should actually be explained in the=20
> > JSON Web Token (JWT) spec where the concept of plain tokens is=20
> > originally introduced. Therefore, the case of a missing "alg" should=20
> > fall outside the scope of the JWS and JWE specs.
>=20
> That's one possibility but then you're introducing a normative reference.
If
> draft-ietf-jose-json-web-algorithms, is going to retain the section on
creating
> plaintext JWS then it's worth saying how empty would be handled - and=20
> then you can avoid the reference.
>=20
> spt
>=20
>=20
>=20
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose




From ietf@augustcellars.com  Wed May 30 10:22: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 4E94211E80CB for ; Wed, 30 May 2012 10:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=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 aQo+IC4EAF2e for ; Wed, 30 May 2012 10:22:49 -0700 (PDT)
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2FC11E80C6 for ; Wed, 30 May 2012 10:22:48 -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 smtp1.pacifier.net (Postfix) with ESMTPSA id 305252CA3A; Wed, 30 May 2012 10:22:47 -0700 (PDT)
From: "Jim Schaad" 
To: "'Mike Jones'" , "'Manger, James H'" , "'Sean Turner'" , "'Vladimir Dzhuvinov / NimbusDS'" 
References: <20120527224709.cc40c4f3d92d2001859047cd8cabb9ab.7bdf13f113.wbe@email07.europe.secureserver.net>	<4FC397FE.3040001@ieca.com>	<4E1F6AAD24975D4BA5B16804296739436651CC6A@TK5EX14MBXC284.redmond.corp.microsoft.com>	<255B9BB34FB7D647A506DC292726F6E114F4D32D9C@WSMSG3153V.srv.dir.telstra.com>	<4E1F6AAD24975D4BA5B16804296739436651D0E6@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4D3351F@WSMSG3153V.srv.dir.telstra.com> <050f01cd3e74$53013950$f903abf0$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436651F9DA@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436651F9DA@TK5EX14MBXC284.redmond.corp.microsoft.com>
Date: Wed, 30 May 2012 10:21:39 -0700
Message-ID: <051c01cd3e88$acfbf440$06f3dcc0$@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: AQIdT9Rs/SJOJh5Xk6n2z6Qj+ZffaAIS1VXgAeDb47sBhk+kJAFhbl/1AVWEeYcCHe32bQFJNEVeleWw5jA=
Content-Language: en-us
Cc: jose@ietf.org
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 17:22:53 -0000

And if I were enrcrypting with a pre-shared secret then I would no alg but
an enc?

> -----Original Message-----
> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> Sent: Wednesday, May 30, 2012 10:18 AM
> To: Jim Schaad; 'Manger, James H'; 'Sean Turner'; 'Vladimir Dzhuvinov /
> NimbusDS'
> Cc: jose@ietf.org
> Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
> 
> There already is a method other than the "alg" value for distinguishing
> between the types.  If the "enc" header parameter is present, then the
"alg"
> value names an encryption algorithm.  So code to accomplish what you're
> asking for below would be:
> 
>     if alg.value not understood {
>         if enc value present {
>             print "Encryption";
>         } else {
>             print "Signature or MAC";
>         }
>         print " \"alg\" value " + alg.value + " not understood\n";
>         throw exception ...;
>     }
> 
> BTW, this is already explained in
http://tools.ietf.org/html/draft-ietf-oauth-
> json-web-token-00#section-5, which says:
> 
>    There are two ways of distinguishing whether the JWT is a JWS or JWE.
>    The first is by examining the "alg" (algorithm) header value.  If the
>    value represents a signature algorithm, the JWT is a JWS; if it
>    represents an encryption algorithm, the JWT is a JWE.  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.
> 
> Since JOSE uses other than JWTs may need to distinguish between JWEs and
> JWSs, however, I'll plan on moving this text from the JWT spec to the JOSE
> specs in the next round of edits.
> 
>                                 -- Mike
> 
> -----Original Message-----
> From: Jim Schaad [mailto:ietf@augustcellars.com]
> Sent: Wednesday, May 30, 2012 7:56 AM
> To: 'Manger, James H'; Mike Jones; 'Sean Turner'; 'Vladimir Dzhuvinov /
> NimbusDS'
> Cc: jose@ietf.org
> Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
> 
> One additional reason that I have thought of why we may want something
> other than just alg to distinguish between the types is to that it would
not be
> possible to report to the user
> 
> I do not understand the signing algorithm FooBar.  You know the name but
> no the algorithm type.
> 
> Jim
> 
> 
> > -----Original Message-----
> > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf
> > Of Manger, James H
> > Sent: Monday, May 28, 2012 10:13 PM
> > To: Mike Jones; Sean Turner; Vladimir Dzhuvinov / NimbusDS
> > Cc: jose@ietf.org
> > Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
> >
> > Sure, the third mode (plaintext) already exists -- but it is not
> > parallel
> to the
> > signed/MACed and encrypted modes. It is an awkward sub-mode of the
> > signed/MACed mode -- reusing the same fields, but with dummy or blank
> > values; providing completely different security; not mentioned in the
> > JWS abstract; only appearing in an appendix (A.4. Example Plaintext
> > JWS);
> without
> > a separate "typ" value or MIME type etc.
> >
> > I think the alg value is a poor way to distinguish unprotected,
> > signed,
> and
> > encrypted JWx messages. Even it that mechanism remains though, I would
> > like plaintext mode to be a "first-class citizen". The fact that
> > plaintext
> mode is
> > hidden away is actually a symptom of not having a place to specify the
> JOSE
> > top-level structure {signed data | encrypted data | unprotected data}.
> >
> > --
> > James Manger
> >
> >
> > -----Original Message-----
> > From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> > Sent: Tuesday, 29 May 2012 2:35 PM
> > To: Manger, James H; Sean Turner; Vladimir Dzhuvinov / NimbusDS
> > Cc: jose@ietf.org
> > Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
> >
> > Actually, the third mode already exists, and is parallel, by design,
> > to
> the
> > signed/MACed and encrypted modes.  No restructuring is necessary to
> > achieve this.  The three are all unambiguously distinguished by the
> > value
> of
> > the "alg" parameter (the value of which MUST be understood, or else
> > the structure must be rejected).
> >
> >                                       -- Mike
> >
> > -----Original Message-----
> > From: Manger, James H [mailto:James.H.Manger@team.telstra.com]
> > Sent: Monday, May 28, 2012 5:23 PM
> > To: Mike Jones; Sean Turner; Vladimir Dzhuvinov / NimbusDS
> > Cc: jose@ietf.org
> > Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
> >
> > "alg":"none" certainly doesn't belong in the OAuth JWT spec that
> > defines a format for identity claims.
> >
> > Sticking "alg":"none" in a JOSE core spec is not the answer, however.
> > The solution is to make unprotected data a first-class citizen
> > alongside
> signed data
> > (JWS) and encrypted data (JWE) in the (embarrassingly unnamed)
> > top-level JOSE structure that can hold any of these 3 forms of data --
> > and is the
> JOSE
> > structure that other specs will use.
> >
> > Having JWS and JWE in separate specs means there isn't an obvious
> > place to specify the top-level JOSE structure (so it is done awkwardly
> > in the OAuth JWT spec). We could add two more JOSE specs: JWP
> > (plain/unprotected
> > data) and JOSE (top-level structure = {JWS|JWE|JWP}). I think a better
> > approach would be to (re-)combine JWS and JWE. The combined spec
> would
> > include unprotected data as a third mode. The algorithms spec can
> > remain separate.
> >
> > --
> > James Manger
> >
> >
> > -----Original Message-----
> > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf
> > Of Mike Jones
> > Sent: Tuesday, 29 May 2012 2:44 AM
> > To: Sean Turner; Vladimir Dzhuvinov / NimbusDS
> > Cc: jose@ietf.org
> > Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
> >
> > For what it's worth, "alg":"none" was moved from JWT to JWS based upon
> > Jim Schaad's suggestion in http://www.ietf.org/mail-
> > archive/web/jose/current/msg00365.html for closing the open issue
> > about whether it belongs in JWT or JWS.  In it, he wrote:
> >
> > [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 believe his rationale was correct and has been proven out by events.
> > At
> this
> > point I now of several usages of "none" both within JWTs, and
> significantly, in
> > at least one context where the structure is a JWS but *not* a JWT.  I
> believe
> > Jim was right to suggest that "alg":"none" belongs in the Algorithms
> > specification.
> >
> >                               Best wishes,
> >                               -- Mike
> >
> > -----Original Message-----
> > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf
> > Of Sean Turner
> > Sent: Monday, May 28, 2012 8:22 AM
> > To: Vladimir Dzhuvinov / NimbusDS
> > Cc: jose@ietf.org
> > Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
> >
> > On 5/28/12 1:47 AM, Vladimir Dzhuvinov / NimbusDS wrote:
> > >> On 5/22/12 3:53 AM, Vladimir Dzhuvinov / NimbusDS wrote:
> > >>>
> > >>>>> 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"
> > >>>
> > >>> +1 for deprecating none.
> > >>>
> > >>> The same information can be expressed by simply omitting "alg".
> > >>> This makes plain JWTs nimbler too. I see no problem with having
> > >>> empty headers for plain JWTs.
> > >>>
> > >>> Also, by removing "none", "alg" would become consistent with the
> > >>> rest of the parameters which don't have "none" values (we don't
> > >>> have "enc":"none", etc.). Very much like the recent change to
> > >>> "zip" (JWS, section 4.1.6) which no longer has the (optional)
> > >>> "none": it's either "zip":"DEF" or nothing.
> > >>
> > >> Just make sure to explain what it means when alg is omitted. Assume
> > >> this would apply equally to both JSW and JWE?
> > >>
> > >> spt
> > >
> > > My understanding is that this should actually be explained in the
> > > JSON Web Token (JWT) spec where the concept of plain tokens is
> > > originally introduced. Therefore, the case of a missing "alg" should
> > > fall outside the scope of the JWS and JWE specs.
> >
> > That's one possibility but then you're introducing a normative
reference.
> If
> > draft-ietf-jose-json-web-algorithms, is going to retain the section on
> creating
> > plaintext JWS then it's worth saying how empty would be handled - and
> > then you can avoid the reference.
> >
> > spt
> >
> >
> >
> > _______________________________________________
> > jose mailing list
> > jose@ietf.org
> > https://www.ietf.org/mailman/listinfo/jose
> 



From Michael.Jones@microsoft.com  Wed May 30 10:27: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 B885C11E80C1 for ; Wed, 30 May 2012 10:27:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.362
X-Spam-Level: 
X-Spam-Status: No, score=-3.362 tagged_above=-999 required=5 tests=[AWL=-0.363, BAYES_00=-2.599, J_CHICKENPOX_35=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 kP46pH8krlWC for ; Wed, 30 May 2012 10:27:11 -0700 (PDT)
Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADE311E80BB for ; Wed, 30 May 2012 10:27:11 -0700 (PDT)
Received: from mail54-db3-R.bigfish.com (10.3.81.234) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Wed, 30 May 2012 17:26:44 +0000
Received: from mail54-db3 (localhost [127.0.0.1])	by mail54-db3-R.bigfish.com (Postfix) with ESMTP id 69D488019F; Wed, 30 May 2012 17:26:44 +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: -36
X-BigFish: VS-36(zzbb2dI9371I542M1432N98dKzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah)
Received-SPF: pass (mail54-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail54-db3 (localhost.localdomain [127.0.0.1]) by mail54-db3 (MessageSwitch) id 1338398802506636_11876; Wed, 30 May 2012 17:26:42 +0000 (UTC)
Received: from DB3EHSMHS017.bigfish.com (unknown [10.3.81.254])	by mail54-db3.bigfish.com (Postfix) with ESMTP id 7984F20113; Wed, 30 May 2012 17:26:42 +0000 (UTC)
Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS017.bigfish.com (10.3.87.117) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 30 May 2012 17:26:40 +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, 30 May 2012 17:27:01 +0000
From: Mike Jones 
To: Jim Schaad , "'Manger, James H'" , 'Sean Turner' , 'Vladimir Dzhuvinov / NimbusDS' 
Thread-Topic: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
Thread-Index: AQHNPJVSCAHMzxPmQDC/RwzlQzAQz5bfUfcAgAAURHCAAHcoEIAATa+ggAAGurCAAj2tAIAAIUfAgAAHbYCAAAEQwA==
Date: Wed, 30 May 2012 17:27:01 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436651FAC5@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <20120527224709.cc40c4f3d92d2001859047cd8cabb9ab.7bdf13f113.wbe@email07.europe.secureserver.net> <4FC397FE.3040001@ieca.com> <4E1F6AAD24975D4BA5B16804296739436651CC6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4D32D9C@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436651D0E6@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4D3351F@WSMSG3153V.srv.dir.telstra.com> <050f01cd3e74$53013950$f903abf0$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436651F9DA@TK5EX14MBXC284.redmond.corp.microsoft.com> <051c01cd3e88$acfbf440$06f3dcc0$@augustcellars.com>
In-Reply-To: <051c01cd3e88$acfbf440$06f3dcc0$@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: 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 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: Wed, 30 May 2012 17:27:12 -0000

If you were encrypting with a pre-shared secret you'd have both "alg" and "=
enc" members to name the algorithms, even if the key was shared out of band=
.

-----Original Message-----
From: Jim Schaad [mailto:ietf@augustcellars.com]=20
Sent: Wednesday, May 30, 2012 10:22 AM
To: Mike Jones; 'Manger, James H'; 'Sean Turner'; 'Vladimir Dzhuvinov / Nim=
busDS'
Cc: jose@ietf.org
Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

And if I were enrcrypting with a pre-shared secret then I would no alg but =
an enc?

> -----Original Message-----
> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> Sent: Wednesday, May 30, 2012 10:18 AM
> To: Jim Schaad; 'Manger, James H'; 'Sean Turner'; 'Vladimir Dzhuvinov=20
> / NimbusDS'
> Cc: jose@ietf.org
> Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
>=20
> There already is a method other than the "alg" value for=20
> distinguishing between the types.  If the "enc" header parameter is=20
> present, then the
"alg"
> value names an encryption algorithm.  So code to accomplish what=20
> you're asking for below would be:
>=20
>     if alg.value not understood {
>         if enc value present {
>             print "Encryption";
>         } else {
>             print "Signature or MAC";
>         }
>         print " \"alg\" value " + alg.value + " not understood\n";
>         throw exception ...;
>     }
>=20
> BTW, this is already explained in
http://tools.ietf.org/html/draft-ietf-oauth-
> json-web-token-00#section-5, which says:
>=20
>    There are two ways of distinguishing whether the JWT is a JWS or JWE.
>    The first is by examining the "alg" (algorithm) header value.  If the
>    value represents a signature algorithm, the JWT is a JWS; if it
>    represents an encryption algorithm, the JWT is a JWE.  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.
>=20
> Since JOSE uses other than JWTs may need to distinguish between JWEs=20
> and JWSs, however, I'll plan on moving this text from the JWT spec to=20
> the JOSE specs in the next round of edits.
>=20
>                                 -- Mike
>=20
> -----Original Message-----
> From: Jim Schaad [mailto:ietf@augustcellars.com]
> Sent: Wednesday, May 30, 2012 7:56 AM
> To: 'Manger, James H'; Mike Jones; 'Sean Turner'; 'Vladimir Dzhuvinov=20
> / NimbusDS'
> Cc: jose@ietf.org
> Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
>=20
> One additional reason that I have thought of why we may want something=20
> other than just alg to distinguish between the types is to that it=20
> would
not be
> possible to report to the user
>=20
> I do not understand the signing algorithm FooBar.  You know the name=20
> but no the algorithm type.
>=20
> Jim
>=20
>=20
> > -----Original Message-----
> > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20
> > Of Manger, James H
> > Sent: Monday, May 28, 2012 10:13 PM
> > To: Mike Jones; Sean Turner; Vladimir Dzhuvinov / NimbusDS
> > Cc: jose@ietf.org
> > Subject: Re: [jose] Comments on=20
> > draft-ietf-jose-json-web-algorithms-02
> >
> > Sure, the third mode (plaintext) already exists -- but it is not=20
> > parallel
> to the
> > signed/MACed and encrypted modes. It is an awkward sub-mode of the=20
> > signed/MACed mode -- reusing the same fields, but with dummy or=20
> > blank values; providing completely different security; not mentioned=20
> > in the JWS abstract; only appearing in an appendix (A.4. Example=20
> > Plaintext JWS);
> without
> > a separate "typ" value or MIME type etc.
> >
> > I think the alg value is a poor way to distinguish unprotected,=20
> > signed,
> and
> > encrypted JWx messages. Even it that mechanism remains though, I=20
> > would like plaintext mode to be a "first-class citizen". The fact=20
> > that plaintext
> mode is
> > hidden away is actually a symptom of not having a place to specify=20
> > the
> JOSE
> > top-level structure {signed data | encrypted data | unprotected data}.
> >
> > --
> > James Manger
> >
> >
> > -----Original Message-----
> > From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> > Sent: Tuesday, 29 May 2012 2:35 PM
> > To: Manger, James H; Sean Turner; Vladimir Dzhuvinov / NimbusDS
> > Cc: jose@ietf.org
> > Subject: RE: [jose] Comments on=20
> > draft-ietf-jose-json-web-algorithms-02
> >
> > Actually, the third mode already exists, and is parallel, by design,=20
> > to
> the
> > signed/MACed and encrypted modes.  No restructuring is necessary to=20
> > achieve this.  The three are all unambiguously distinguished by the=20
> > value
> of
> > the "alg" parameter (the value of which MUST be understood, or else=20
> > the structure must be rejected).
> >
> >                                       -- Mike
> >
> > -----Original Message-----
> > From: Manger, James H [mailto:James.H.Manger@team.telstra.com]
> > Sent: Monday, May 28, 2012 5:23 PM
> > To: Mike Jones; Sean Turner; Vladimir Dzhuvinov / NimbusDS
> > Cc: jose@ietf.org
> > Subject: RE: [jose] Comments on=20
> > draft-ietf-jose-json-web-algorithms-02
> >
> > "alg":"none" certainly doesn't belong in the OAuth JWT spec that=20
> > defines a format for identity claims.
> >
> > Sticking "alg":"none" in a JOSE core spec is not the answer, however.
> > The solution is to make unprotected data a first-class citizen=20
> > alongside
> signed data
> > (JWS) and encrypted data (JWE) in the (embarrassingly unnamed)=20
> > top-level JOSE structure that can hold any of these 3 forms of data=20
> > -- and is the
> JOSE
> > structure that other specs will use.
> >
> > Having JWS and JWE in separate specs means there isn't an obvious=20
> > place to specify the top-level JOSE structure (so it is done=20
> > awkwardly in the OAuth JWT spec). We could add two more JOSE specs:=20
> > JWP (plain/unprotected
> > data) and JOSE (top-level structure =3D {JWS|JWE|JWP}). I think a=20
> > better approach would be to (re-)combine JWS and JWE. The combined=20
> > spec
> would
> > include unprotected data as a third mode. The algorithms spec can=20
> > remain separate.
> >
> > --
> > James Manger
> >
> >
> > -----Original Message-----
> > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20
> > Of Mike Jones
> > Sent: Tuesday, 29 May 2012 2:44 AM
> > To: Sean Turner; Vladimir Dzhuvinov / NimbusDS
> > Cc: jose@ietf.org
> > Subject: Re: [jose] Comments on=20
> > draft-ietf-jose-json-web-algorithms-02
> >
> > For what it's worth, "alg":"none" was moved from JWT to JWS based=20
> > upon Jim Schaad's suggestion in http://www.ietf.org/mail-=20
> > archive/web/jose/current/msg00365.html for closing the open issue=20
> > about whether it belongs in JWT or JWS.  In it, he wrote:
> >
> > [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=20
> > needs to
> be
> > done the in the base specification.
> >
> > I believe his rationale was correct and has been proven out by events.
> > At
> this
> > point I now of several usages of "none" both within JWTs, and
> significantly, in
> > at least one context where the structure is a JWS but *not* a JWT. =20
> > I
> believe
> > Jim was right to suggest that "alg":"none" belongs in the Algorithms=20
> > specification.
> >
> >                               Best wishes,
> >                               -- Mike
> >
> > -----Original Message-----
> > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf=20
> > Of Sean Turner
> > Sent: Monday, May 28, 2012 8:22 AM
> > To: Vladimir Dzhuvinov / NimbusDS
> > Cc: jose@ietf.org
> > Subject: Re: [jose] Comments on=20
> > draft-ietf-jose-json-web-algorithms-02
> >
> > On 5/28/12 1:47 AM, Vladimir Dzhuvinov / NimbusDS wrote:
> > >> On 5/22/12 3:53 AM, Vladimir Dzhuvinov / NimbusDS wrote:
> > >>>
> > >>>>> 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"
> > >>>
> > >>> +1 for deprecating none.
> > >>>
> > >>> The same information can be expressed by simply omitting "alg".
> > >>> This makes plain JWTs nimbler too. I see no problem with having=20
> > >>> empty headers for plain JWTs.
> > >>>
> > >>> Also, by removing "none", "alg" would become consistent with the=20
> > >>> rest of the parameters which don't have "none" values (we don't=20
> > >>> have "enc":"none", etc.). Very much like the recent change to=20
> > >>> "zip" (JWS, section 4.1.6) which no longer has the (optional)
> > >>> "none": it's either "zip":"DEF" or nothing.
> > >>
> > >> Just make sure to explain what it means when alg is omitted.=20
> > >> Assume this would apply equally to both JSW and JWE?
> > >>
> > >> spt
> > >
> > > My understanding is that this should actually be explained in the=20
> > > JSON Web Token (JWT) spec where the concept of plain tokens is=20
> > > originally introduced. Therefore, the case of a missing "alg"=20
> > > should fall outside the scope of the JWS and JWE specs.
> >
> > That's one possibility but then you're introducing a normative
reference.
> If
> > draft-ietf-jose-json-web-algorithms, is going to retain the section=20
> > on
> creating
> > plaintext JWS then it's worth saying how empty would be handled -=20
> > and then you can avoid the reference.
> >
> > spt
> >
> >
> >
> > _______________________________________________
> > jose mailing list
> > jose@ietf.org
> > https://www.ietf.org/mailman/listinfo/jose
>=20





From James.H.Manger@team.telstra.com  Wed May 30 17:17: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 9249621F84F0 for ; Wed, 30 May 2012 17:17:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.428
X-Spam-Level: 
X-Spam-Status: No, score=-0.428 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_35=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 4LHH+NOFY7CO for ; Wed, 30 May 2012 17:17:34 -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 A279611E80D5 for ; Wed, 30 May 2012 17:17:32 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.75,688,1330866000"; d="scan'208";a="75967686"
Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 31 May 2012 10:17:30 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6727"; a="65690528"
Received: from wsmsg3752.srv.dir.telstra.com ([172.49.40.173]) by ipccvi.tcif.telstra.com.au with ESMTP; 31 May 2012 10:17:30 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3752.srv.dir.telstra.com ([172.49.40.173]) with mapi; Thu, 31 May 2012 10:17:29 +1000
From: "Manger, James H" 
To: Mike Jones , Jim Schaad , 'Sean Turner' , 'Vladimir Dzhuvinov / NimbusDS' , John Bradley 
Date: Thu, 31 May 2012 10:17:28 +1000
Thread-Topic: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
Thread-Index: AQHNPJVSCAHMzxPmQDC/RwzlQzAQz5bfUfcAgAAURHCAAHcoEIAATa+ggAAGurCAAj2tAIAAIUfAgABssWA=
Message-ID: <255B9BB34FB7D647A506DC292726F6E114F4FC07AB@WSMSG3153V.srv.dir.telstra.com>
References: <20120527224709.cc40c4f3d92d2001859047cd8cabb9ab.7bdf13f113.wbe@email07.europe.secureserver.net> <4FC397FE.3040001@ieca.com> <4E1F6AAD24975D4BA5B16804296739436651CC6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4D32D9C@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436651D0E6@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4D3351F@WSMSG3153V.srv.dir.telstra.com> <050f01cd3e74$53013950$f903abf0$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436651F9DA@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436651F9DA@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: "jose@ietf.org" 
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2012 00:17:34 -0000

Handling John Bradley's suggestion for data with a checksum further highlig=
hts why using "alg" values (or the presence/absence of "enc") is a poor des=
ign for distinguishing modes.

A JOSE message with a checksum, but no security could be:
1.  {"alg":"CRC16"}."Hello, World!".83F4

A JOSE message with compressed content, but no security could be:
2.  {"alg":"GZIP"}.H4sIAAAAAAAAAPNIzcnJ11EIzy_KSVEEANDDSuwNAAAA

A receiver that doesn't support "CRC16" could still usefully process messag=
e #1, passing "Hello, World!" to the rest of the program (just without sayi=
ng any checksum was checked). Effectively, the receiver acts like it got:
3.  {"alg":"none"}."Hello, World!".

A receiver that doesn't support "GZIP", in contrast, MUST reject the messag=
e.

Different behaviour for different "unknown" algorithms, based on only knowi=
ng the mode.

--
James Manger


-----Original Message-----
From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20
Sent: Thursday, 31 May 2012 3:18 AM
To: Jim Schaad; Manger, James H; 'Sean Turner'; 'Vladimir Dzhuvinov / Nimbu=
sDS'
Cc: jose@ietf.org
Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

There already is a method other than the "alg" value for distinguishing bet=
ween the types.  If the "enc" header parameter is present, then the "alg" v=
alue names an encryption algorithm.  So code to accomplish what you're aski=
ng for below would be:

    if alg.value not understood {
        if enc value present {
            print "Encryption";
        } else {
            print "Signature or MAC";
        }
        print " \"alg\" value " + alg.value + " not understood\n";
        throw exception ...;
    }

BTW, this is already explained in http://tools.ietf.org/html/draft-ietf-oau=
th-json-web-token-00#section-5, which says:

   There are two ways of distinguishing whether the JWT is a JWS or JWE.
   The first is by examining the "alg" (algorithm) header value.  If the
   value represents a signature algorithm, the JWT is a JWS; if it
   represents an encryption algorithm, the JWT is a JWE.  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.

Since JOSE uses other than JWTs may need to distinguish between JWEs and JW=
Ss, however, I'll plan on moving this text from the JWT spec to the JOSE sp=
ecs in the next round of edits.

				-- Mike


From Michael.Jones@microsoft.com  Wed May 30 17:21: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 5096D11E811A for ; Wed, 30 May 2012 17:21:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.344
X-Spam-Level: 
X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[AWL=-0.345, BAYES_00=-2.599, J_CHICKENPOX_35=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 MfZIygbnZFG7 for ; Wed, 30 May 2012 17:21:58 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 3EECA11E80D5 for ; Wed, 30 May 2012 17:21:58 -0700 (PDT)
Received: from mail42-am1-R.bigfish.com (10.3.201.229) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 31 May 2012 00:21:30 +0000
Received: from mail42-am1 (localhost [127.0.0.1])	by mail42-am1-R.bigfish.com (Postfix) with ESMTP id BF6952E037B; Thu, 31 May 2012 00:21:30 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI
X-SpamScore: -26
X-BigFish: VS-26(zz9371I542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah)
Received-SPF: pass (mail42-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 mail42-am1 (localhost.localdomain [127.0.0.1]) by mail42-am1 (MessageSwitch) id 1338423688710713_15623; Thu, 31 May 2012 00:21:28 +0000 (UTC)
Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.229])	by mail42-am1.bigfish.com (Postfix) with ESMTP id AA9A420058; Thu, 31 May 2012 00:21:28 +0000 (UTC)
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 31 May 2012 00:21:28 +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; Thu, 31 May 2012 00:21:53 +0000
From: Mike Jones 
To: "Manger, James H" , Jim Schaad , 'Sean Turner' , 'Vladimir Dzhuvinov / NimbusDS' , John Bradley 
Thread-Topic: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
Thread-Index: AQHNPJVSCAHMzxPmQDC/RwzlQzAQz5bfUfcAgAAURHCAAHcoEIAATa+ggAAGurCAAj2tAIAAIUfAgABssWCAAA90AA==
Date: Thu, 31 May 2012 00:21:52 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394366520BAB@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <20120527224709.cc40c4f3d92d2001859047cd8cabb9ab.7bdf13f113.wbe@email07.europe.secureserver.net> <4FC397FE.3040001@ieca.com> <4E1F6AAD24975D4BA5B16804296739436651CC6A@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4D32D9C@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739436651D0E6@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4D3351F@WSMSG3153V.srv.dir.telstra.com> <050f01cd3e74$53013950$f903abf0$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436651F9DA@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E114F4FC07AB@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F4FC07AB@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.72]
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 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: Thu, 31 May 2012 00:21:59 -0000

Except that, since this is a security protocol, if a receiver doesn't under=
stand CRC16, it MUST reject the message.  There is no difference between th=
e handling of not-understood algorithms (of any kind).

				-- Mike

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Man=
ger, James H
Sent: Wednesday, May 30, 2012 5:17 PM
To: Mike Jones; Jim Schaad; 'Sean Turner'; 'Vladimir Dzhuvinov / NimbusDS';=
 John Bradley
Cc: jose@ietf.org
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

Handling John Bradley's suggestion for data with a checksum further highlig=
hts why using "alg" values (or the presence/absence of "enc") is a poor des=
ign for distinguishing modes.

A JOSE message with a checksum, but no security could be:
1.  {"alg":"CRC16"}."Hello, World!".83F4

A JOSE message with compressed content, but no security could be:
2.  {"alg":"GZIP"}.H4sIAAAAAAAAAPNIzcnJ11EIzy_KSVEEANDDSuwNAAAA

A receiver that doesn't support "CRC16" could still usefully process messag=
e #1, passing "Hello, World!" to the rest of the program (just without sayi=
ng any checksum was checked). Effectively, the receiver acts like it got:
3.  {"alg":"none"}."Hello, World!".

A receiver that doesn't support "GZIP", in contrast, MUST reject the messag=
e.

Different behaviour for different "unknown" algorithms, based on only knowi=
ng the mode.

--
James Manger


-----Original Message-----
From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20
Sent: Thursday, 31 May 2012 3:18 AM
To: Jim Schaad; Manger, James H; 'Sean Turner'; 'Vladimir Dzhuvinov / Nimbu=
sDS'
Cc: jose@ietf.org
Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

There already is a method other than the "alg" value for distinguishing bet=
ween the types.  If the "enc" header parameter is present, then the "alg" v=
alue names an encryption algorithm.  So code to accomplish what you're aski=
ng for below would be:

    if alg.value not understood {
        if enc value present {
            print "Encryption";
        } else {
            print "Signature or MAC";
        }
        print " \"alg\" value " + alg.value + " not understood\n";
        throw exception ...;
    }

BTW, this is already explained in http://tools.ietf.org/html/draft-ietf-oau=
th-json-web-token-00#section-5, which says:

   There are two ways of distinguishing whether the JWT is a JWS or JWE.
   The first is by examining the "alg" (algorithm) header value.  If the
   value represents a signature algorithm, the JWT is a JWS; if it
   represents an encryption algorithm, the JWT is a JWE.  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.

Since JOSE uses other than JWTs may need to distinguish between JWEs and JW=
Ss, however, I'll plan on moving this text from the JWT spec to the JOSE sp=
ecs in the next round of edits.

				-- Mike

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



From James.H.Manger@team.telstra.com  Wed May 30 17:56: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 CE7FB11E8121 for ; Wed, 30 May 2012 17:56:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.025
X-Spam-Level: 
X-Spam-Status: No, score=0.025 tagged_above=-999 required=5 tests=[AWL=-0.563,  BAYES_05=-1.11, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rNaJSFTXhux for ; Wed, 30 May 2012 17:56:27 -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 1532A11E80D2 for ; Wed, 30 May 2012 17:56:26 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.75,688,1330866000"; d="scan'208";a="80996844"
Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipoani.tcif.telstra.com.au with ESMTP; 31 May 2012 10:56:20 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6727"; a="14209536"
Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcani.tcif.telstra.com.au with ESMTP; 31 May 2012 10:56:19 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Thu, 31 May 2012 10:56:18 +1000
From: "Manger, James H" 
To: "jose@ietf.org" 
Date: Thu, 31 May 2012 10:56:17 +1000
Thread-Topic: JOSE top-level syntax proposal
Thread-Index: Ac0+yC9F1J33FhOVR8SetMC1+0wtsA==
Message-ID: <255B9BB34FB7D647A506DC292726F6E114F4FC08C1@WSMSG3153V.srv.dir.telstra.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-cr-puzzleid: {4AC283E5-A8A1-4723-91AD-4AB054DD9038}
x-cr-hashedpuzzle: ArID Areu CBVF CTfF EMw9 EN8G Eght EzbA Fap7 GDsL GHGr GYI1 GfIr Htph ILwe IUfT; 1; agBvAHMAZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {4AC283E5-A8A1-4723-91AD-4AB054DD9038}; agBhAG0AZQBzAC4AaAAuAG0AYQBuAGcAZQByAEAAdABlAGEAbQAuAHQAZQBsAHMAdAByAGEALgBjAG8AbQA=; Thu, 31 May 2012 00:56:17 GMT; SgBPAFMARQAgAHQAbwBwAC0AbABlAHYAZQBsACAAcwB5AG4AdABhAHgAIABwAHIAbwBwAG8AcwBhAGwA
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [jose] JOSE top-level syntax proposal
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.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, 31 May 2012 00:56:27 -0000

Here is a concrete proposal for the syntax of JOSE messages that explicitly=
 indicates the mode of protection, independently of specific algorithm valu=
es.

jwsec  =3D ("Z" "." header64 "." compressed64) /
         ("S" "." header64 "." data64 "." signature64) /
         ("I" "." header64 "." data64 "." checksum64) /
         ("E" "." header64 "." enckey64 "." ciphertext64 "." mac64) /
         (ext "." header64 *("." component64))

ext =3D 1*b64url ; future modes

header64 =3D 1*b64url ; base64url-encoded UTF-8-encoded JSON object

; the following 8 items hold base64url-encoded byte arrays
compressed64 =3D *b64url
data64       =3D *b64url
signature64  =3D *b64url
checksum64   =3D *b64url
enckey64     =3D *b64url
ciphertext64 =3D *b64url
mac64        =3D *b64url
component64  =3D *b64url

b64url =3D %x41-5A / %x61-7A / %x30-39 / %x2D / %x5F
          ; A-Z       a-z       0-9       -      _

Mode "Z" carries unsecured data that is optionally compressed.
Mode "I" carries unsecured data with a checksum to detect accidental errors=
.
Mode "S" provide data origin authentication.
Mode "E" provides confidentiality.

--
James Manger



From James.H.Manger@team.telstra.com  Wed May 30 18:33: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 A437221F855D for ; Wed, 30 May 2012 18:33:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.387
X-Spam-Level: 
X-Spam-Status: No, score=-0.387 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_35=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 KX5tjpggcpMr for ; Wed, 30 May 2012 18:33:19 -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 C0A8F21F855B for ; Wed, 30 May 2012 18:33:18 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.75,688,1330866000"; d="scan'208";a="74947193"
Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 31 May 2012 11:33:17 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6727"; a="14225030"
Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcani.tcif.telstra.com.au with ESMTP; 31 May 2012 11:33:17 +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, 31 May 2012 11:33:16 +1000
From: "Manger, James H" 
To: "jose@ietf.org" 
Date: Thu, 31 May 2012 11:33:15 +1000
Thread-Topic: [jose] Comments on draft-ietf-jose-json-web-algorithms-02
Thread-Index: AQHNPJVSCAHMzxPmQDC/RwzlQzAQz5bfUfcAgAAURHCAAHcoEIAATa+ggAAGurCAAj2tAIAAIUfAgABssWCAAA90AIAAANpggAATh2A=
Message-ID: <255B9BB34FB7D647A506DC292726F6E114F4FC09D2@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] FW:  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: Thu, 31 May 2012 01:33:19 -0000

> Except that, since this is a security protocol, if a receiver doesn't und=
erstand CRC16, it MUST reject the message.  There is no difference between =
the handling of not-understood algorithms (of any kind).

I totally disagree with this approach of "MUST reject if any aspect is not =
understood".

This security protocol supports modes *without any security* ("alg":"none")=
.
Pretending that it is harmful to ignore an unsupported checksum (so harmful=
 that a message must be totally rejected) -- even though the same message w=
ith no checksum would have been accepted -- is not a good approach. Many de=
velopers will ignore the pretence.

--
James Manger


-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Man=
ger, James H
Sent: Wednesday, May 30, 2012 5:17 PM
To: Mike Jones; Jim Schaad; 'Sean Turner'; 'Vladimir Dzhuvinov / NimbusDS';=
 John Bradley
Cc: jose@ietf.org
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

Handling John Bradley's suggestion for data with a checksum further highlig=
hts why using "alg" values (or the presence/absence of "enc") is a poor des=
ign for distinguishing modes.

A JOSE message with a checksum, but no security could be:
1.  {"alg":"CRC16"}."Hello, World!".83F4

A JOSE message with compressed content, but no security could be:
2.  {"alg":"GZIP"}.H4sIAAAAAAAAAPNIzcnJ11EIzy_KSVEEANDDSuwNAAAA

A receiver that doesn't support "CRC16" could still usefully process messag=
e #1, passing "Hello, World!" to the rest of the program (just without sayi=
ng any checksum was checked). Effectively, the receiver acts like it got:
3.  {"alg":"none"}."Hello, World!".

A receiver that doesn't support "GZIP", in contrast, MUST reject the messag=
e.

Different behaviour for different "unknown" algorithms, based on only knowi=
ng the mode.

--
James Manger


-----Original Message-----
From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20
Sent: Thursday, 31 May 2012 3:18 AM
To: Jim Schaad; Manger, James H; 'Sean Turner'; 'Vladimir Dzhuvinov / Nimbu=
sDS'
Cc: jose@ietf.org
Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

There already is a method other than the "alg" value for distinguishing bet=
ween the types.  If the "enc" header parameter is present, then the "alg" v=
alue names an encryption algorithm.  So code to accomplish what you're aski=
ng for below would be:

    if alg.value not understood {
        if enc value present {
            print "Encryption";
        } else {
            print "Signature or MAC";
        }
        print " \"alg\" value " + alg.value + " not understood\n";
        throw exception ...;
    }

BTW, this is already explained in http://tools.ietf.org/html/draft-ietf-oau=
th-json-web-token-00#section-5, which says:

   There are two ways of distinguishing whether the JWT is a JWS or JWE.
   The first is by examining the "alg" (algorithm) header value.  If the
   value represents a signature algorithm, the JWT is a JWS; if it
   represents an encryption algorithm, the JWT is a JWE.  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.

Since JOSE uses other than JWTs may need to distinguish between JWEs and JW=
Ss, however, I'll plan on moving this text from the JWT spec to the JOSE sp=
ecs in the next round of edits.

				-- Mike

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



From Michael.Jones@microsoft.com  Wed May 30 18:35: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 EE30B21F856F for ; Wed, 30 May 2012 18:35:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[AWL=-0.328, BAYES_00=-2.599, J_CHICKENPOX_35=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 UUfLoGPWbO8Z for ; Wed, 30 May 2012 18:35:05 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id CAB6521F8569 for ; Wed, 30 May 2012 18:35:04 -0700 (PDT)
Received: from mail85-am1-R.bigfish.com (10.3.201.253) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 31 May 2012 01:34:37 +0000
Received: from mail85-am1 (localhost [127.0.0.1])	by mail85-am1-R.bigfish.com (Postfix) with ESMTP id 4C001180230; Thu, 31 May 2012 01:34:37 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI
X-SpamScore: -26
X-BigFish: VS-26(zz9371I542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah)
Received-SPF: pass (mail85-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 mail85-am1 (localhost.localdomain [127.0.0.1]) by mail85-am1 (MessageSwitch) id 1338428075732305_11342; Thu, 31 May 2012 01:34:35 +0000 (UTC)
Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.237])	by mail85-am1.bigfish.com (Postfix) with ESMTP id B128E300048; Thu, 31 May 2012 01:34:35 +0000 (UTC)
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 31 May 2012 01:34:35 +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; Thu, 31 May 2012 01:34:57 +0000
From: Mike Jones 
To: "Manger, James H" , "jose@ietf.org" 
Thread-Topic: [jose] FW:  Comments on draft-ietf-jose-json-web-algorithms-02
Thread-Index: AQHNPs1h64nzByNbcUqHPXMpIneydZbjHVRw
Date: Thu, 31 May 2012 01:34:57 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394366520E2B@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <255B9BB34FB7D647A506DC292726F6E114F4FC09D2@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F4FC09D2@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.72]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Subject: Re: [jose] FW:  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: Thu, 31 May 2012 01:35:06 -0000

But the whole point of adding a checksum is to reject the message if the ch=
ecksum fails, right?

-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Man=
ger, James H
Sent: Wednesday, May 30, 2012 6:33 PM
To: jose@ietf.org
Subject: [jose] FW: Comments on draft-ietf-jose-json-web-algorithms-02

> Except that, since this is a security protocol, if a receiver doesn't und=
erstand CRC16, it MUST reject the message.  There is no difference between =
the handling of not-understood algorithms (of any kind).

I totally disagree with this approach of "MUST reject if any aspect is not =
understood".

This security protocol supports modes *without any security* ("alg":"none")=
.
Pretending that it is harmful to ignore an unsupported checksum (so harmful=
 that a message must be totally rejected) -- even though the same message w=
ith no checksum would have been accepted -- is not a good approach. Many de=
velopers will ignore the pretence.

--
James Manger


-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Man=
ger, James H
Sent: Wednesday, May 30, 2012 5:17 PM
To: Mike Jones; Jim Schaad; 'Sean Turner'; 'Vladimir Dzhuvinov / NimbusDS';=
 John Bradley
Cc: jose@ietf.org
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

Handling John Bradley's suggestion for data with a checksum further highlig=
hts why using "alg" values (or the presence/absence of "enc") is a poor des=
ign for distinguishing modes.

A JOSE message with a checksum, but no security could be:
1.  {"alg":"CRC16"}."Hello, World!".83F4

A JOSE message with compressed content, but no security could be:
2.  {"alg":"GZIP"}.H4sIAAAAAAAAAPNIzcnJ11EIzy_KSVEEANDDSuwNAAAA

A receiver that doesn't support "CRC16" could still usefully process messag=
e #1, passing "Hello, World!" to the rest of the program (just without sayi=
ng any checksum was checked). Effectively, the receiver acts like it got:
3.  {"alg":"none"}."Hello, World!".

A receiver that doesn't support "GZIP", in contrast, MUST reject the messag=
e.

Different behaviour for different "unknown" algorithms, based on only knowi=
ng the mode.

--
James Manger


-----Original Message-----
From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20
Sent: Thursday, 31 May 2012 3:18 AM
To: Jim Schaad; Manger, James H; 'Sean Turner'; 'Vladimir Dzhuvinov / Nimbu=
sDS'
Cc: jose@ietf.org
Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

There already is a method other than the "alg" value for distinguishing bet=
ween the types.  If the "enc" header parameter is present, then the "alg" v=
alue names an encryption algorithm.  So code to accomplish what you're aski=
ng for below would be:

    if alg.value not understood {
        if enc value present {
            print "Encryption";
        } else {
            print "Signature or MAC";
        }
        print " \"alg\" value " + alg.value + " not understood\n";
        throw exception ...;
    }

BTW, this is already explained in http://tools.ietf.org/html/draft-ietf-oau=
th-json-web-token-00#section-5, which says:

   There are two ways of distinguishing whether the JWT is a JWS or JWE.
   The first is by examining the "alg" (algorithm) header value.  If the
   value represents a signature algorithm, the JWT is a JWS; if it
   represents an encryption algorithm, the JWT is a JWE.  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.

Since JOSE uses other than JWTs may need to distinguish between JWEs and JW=
Ss, however, I'll plan on moving this text from the JWT spec to the JOSE sp=
ecs in the next round of edits.

				-- Mike

_______________________________________________
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 30 18:40: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 65B0621F85B1 for ; Wed, 30 May 2012 18:40:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.682
X-Spam-Level: 
X-Spam-Status: No, score=-0.682 tagged_above=-999 required=5 tests=[AWL=0.219,  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 n1JRIzzdrWVw for ; Wed, 30 May 2012 18:40:22 -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 7DCB621F85AF for ; Wed, 30 May 2012 18:40:21 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.75,688,1330866000"; d="scan'208";a="75986811"
Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipoavi.tcif.telstra.com.au with ESMTP; 31 May 2012 11:40:20 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6727"; a="65508030"
Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcbvi.tcif.telstra.com.au with ESMTP; 31 May 2012 11:40:20 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Thu, 31 May 2012 11:40:19 +1000
From: "Manger, James H" 
To: Mike Jones , "jose@ietf.org" 
Date: Thu, 31 May 2012 11:40:18 +1000
Thread-Topic: [jose] FW:  Comments on draft-ietf-jose-json-web-algorithms-02
Thread-Index: AQHNPs1h64nzByNbcUqHPXMpIneydZbjHVRwgAAAZwA=
Message-ID: <255B9BB34FB7D647A506DC292726F6E114F4FC0A10@WSMSG3153V.srv.dir.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E114F4FC09D2@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B168042967394366520E2B@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366520E2B@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
Subject: Re: [jose] FW:  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: Thu, 31 May 2012 01:40:22 -0000

> But the whole point of adding a checksum is to reject the message if the =
checksum fails, right?

Not quite. The point of a sender adding a checksum is to give a receiver th=
e ability to detect (or correct) some accidental transmission errors if the=
 receiver thinks do so is worthwhile. That is subtly different from a sende=
r forcing the receiver to reject messages if certain accidental transmissio=
n errors occur.

--
James Manger


-----Original Message-----
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Man=
ger, James H
Sent: Wednesday, May 30, 2012 6:33 PM
To: jose@ietf.org
Subject: [jose] FW: Comments on draft-ietf-jose-json-web-algorithms-02

> Except that, since this is a security protocol, if a receiver doesn't und=
erstand CRC16, it MUST reject the message.  There is no difference between =
the handling of not-understood algorithms (of any kind).

I totally disagree with this approach of "MUST reject if any aspect is not =
understood".

This security protocol supports modes *without any security* ("alg":"none")=
.
Pretending that it is harmful to ignore an unsupported checksum (so harmful=
 that a message must be totally rejected) -- even though the same message w=
ith no checksum would have been accepted -- is not a good approach. Many de=
velopers will ignore the pretence.

--
James Manger

From vladimir@nimbusds.com  Thu May 31 04:01: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 41E8F21F8592 for ; Thu, 31 May 2012 04:01:57 -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 in7x3r3ewl-U for ; Thu, 31 May 2012 04:01:56 -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 F2C6D21F858E for ; Thu, 31 May 2012 04:01:55 -0700 (PDT)
Received: (qmail 12221 invoked from network); 31 May 2012 11:01:54 -0000
Received: from unknown (HELO localhost) (188.121.52.246) by n1plwbeout07-02.prod.ams1.secureserver.net with SMTP; 31 May 2012 11:01:53 -0000
Received: (qmail 23558 invoked by uid 99); 31 May 2012 11:01:53 -0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Originating-IP: 95.43.60.168
User-Agent: Workspace Webmail 5.6.18
Message-Id: <20120531040152.cc40c4f3d92d2001859047cd8cabb9ab.ea4ca89ae0.wbe@email07.europe.secureserver.net>
From: "Vladimir Dzhuvinov / NimbusDS" 
To: jose@ietf.org
Date: Thu, 31 May 2012 04:01:52 -0700
Mime-Version: 1.0
Subject: Re: [jose] JOSE top-level syntax proposal
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.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, 31 May 2012 11:01:57 -0000

Hi James,=0A=0AIf I understand correctly, the main purpose of these prefixe=
s is to=0Aenable the message/alg type to be determined without decoding the=
=0Aheader? Do you see any particular cases/scenarios where this could=0Amat=
ter?=0A=0AApart from this, the prefix seems redundant to me.=0A=0A=0AVladim=
ir=0A=0A--=0AVladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com=
=0A =0A=0A=0A-------- Original Message --------=0ASubject: [jose] JOSE top-=
level syntax proposal=0AFrom: "Manger, James H" =0ADate: Thu, May 31, 2012 1:56 am=0ATo: "jose@ietf.org" =0A=0A=0AHere is a concrete proposal for the syntax of JOSE messages tha=
t=0Aexplicitly indicates the mode of protection, independently of specific=
=0Aalgorithm values.=0A=0Ajwsec =3D ("Z" "." header64 "." compressed64) /=
=0A ("S" "." header64 "." data64 "." signature64) /=0A ("I" "." header64 ".=
" data64 "." checksum64) /=0A ("E" "." header64 "." enckey64 "." ciphertext=
64 "." mac64) /=0A (ext "." header64 *("." component64))=0A=0Aext =3D 1*b64=
url ; future modes=0A=0Aheader64 =3D 1*b64url ; base64url-encoded UTF-8-enc=
oded JSON object=0A=0A; the following 8 items hold base64url-encoded byte a=
rrays=0Acompressed64 =3D *b64url=0Adata64 =3D *b64url=0Asignature64 =3D *b6=
4url=0Achecksum64 =3D *b64url=0Aenckey64 =3D *b64url=0Aciphertext64 =3D *b6=
4url=0Amac64 =3D *b64url=0Acomponent64 =3D *b64url=0A=0Ab64url =3D %x41-5A =
/ %x61-7A / %x30-39 / %x2D / %x5F=0A ; A-Z a-z 0-9 - _=0A=0AMode "Z" carrie=
s unsecured data that is optionally compressed.=0AMode "I" carries unsecure=
d data with a checksum to detect accidental=0Aerrors.=0AMode "S" provide da=
ta origin authentication.=0AMode "E" provides confidentiality.=0A=0A--=0AJa=
mes Manger=0A=0A=0A_______________________________________________=0Ajose m=
ailing list=0Ajose@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/jose=0A

From vladimir@nimbusds.com  Thu May 31 04:50: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 3572321F8596 for ; Thu, 31 May 2012 04:50:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6]
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 kU5G0GCg4bl1 for ; Thu, 31 May 2012 04:50:56 -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 5251B21F857A for ; Thu, 31 May 2012 04:50:52 -0700 (PDT)
Received: (qmail 15842 invoked from network); 31 May 2012 11:44:11 -0000
Received: from unknown (HELO localhost) (188.121.52.246) by n1plwbeout07-01.prod.ams1.secureserver.net with SMTP; 31 May 2012 11:44:11 -0000
Received: (qmail 2473 invoked by uid 99); 31 May 2012 11:44:11 -0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Originating-IP: 95.43.60.168
User-Agent: Workspace Webmail 5.6.18
Message-Id: <20120531044410.cc40c4f3d92d2001859047cd8cabb9ab.548d0e08b2.wbe@email07.europe.secureserver.net>
From: "Vladimir Dzhuvinov / NimbusDS" 
To: jose@ietf.org
Date: Thu, 31 May 2012 04:44:10 -0700
Mime-Version: 1.0
Subject: [jose] Suggestion for new term: JSON Web Object (JWO) or JSON Web Message (JWM)
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.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, 31 May 2012 11:50:57 -0000

Hi guys,=0A=0AYesterday, during work on the Nimbus-JWT library, we realised=
 the need=0Ato come up with a common term for the _things_ that are encoded=
 by=0Aalg:none, JWS and JWE, whether they serialise to the compact or the J=
S=0Aform.=0A=0AAfter a bit of brain storming two favourites emerged:=0A=0AJ=
SON Web Object (JWO)=0A=0Aand =0A=0AJSON Web Message (JWM).=0A=0A=0AJSON We=
b Object is more general. It may however cause confusion, due to=0Aits "JSO=
N object" connotation, as the packaged content isn't always=0AJSON, it can =
be arbitrary.=0A=0AJSON Web Message doesn't have this potential confusion, =
and it also=0Aimplies content that is carried in a specific form.=0A=0A=0AA=
nother candidate was JSON Web Serialization. It's weaknesses are that=0Ait =
is not a clean noun and its abbreviation conflicts with the=0Aestablished J=
WS term.=0A=0A=0AI think it makes sense to define such a common term. It's =
difficult to=0Ahave a conversation on JOSE without one. If a specific term =
is not=0Adefined, people will sooner or later come up with one. We, for ins=
tance,=0Awill have to give this base class a name, from which plain, JWS an=
d JWE=0Asubclass.=0A=0A=0AVladimir=0A=0A--=0AVladimir Dzhuvinov : www.Nimbu=
sDS.com : vladimir@nimbusds.com=0A

From vladimir@nimbusds.com  Thu May 31 05: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 9A01E21F862B for ; Thu, 31 May 2012 05:01:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.423
X-Spam-Level: 
X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.024,  BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152]
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 0cWGlS-1G6Ln for ; Thu, 31 May 2012 05:01:50 -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 D62A421F862A for ; Thu, 31 May 2012 05:01:49 -0700 (PDT)
Received: (qmail 16892 invoked from network); 31 May 2012 12:01:49 -0000
Received: from unknown (HELO localhost) (188.121.52.246) by n1plwbeout07-01.prod.ams1.secureserver.net with SMTP; 31 May 2012 12:01:49 -0000
Received: (qmail 20687 invoked by uid 99); 31 May 2012 12:01:49 -0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Originating-IP: 95.43.60.168
User-Agent: Workspace Webmail 5.6.18
Message-Id: <20120531050148.cc40c4f3d92d2001859047cd8cabb9ab.af6dca8411.wbe@email07.europe.secureserver.net>
From: "Vladimir Dzhuvinov / NimbusDS" 
To: jose@ietf.org
Date: Thu, 31 May 2012 05:01:48 -0700
Mime-Version: 1.0
Subject: [jose] =?utf-8?q?Allow_compression_of_plain_and_JWS_too=3F?=
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.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, 31 May 2012 12:01:50 -0000

Is there a reason to have compression only with JWE?=0A=0A=0AVladimir=0A=0A=
--=0AVladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com=0A

From James.H.Manger@team.telstra.com  Thu May 31 06:26: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 7E4AC21F864F for ; Thu, 31 May 2012 06:26:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.413
X-Spam-Level: 
X-Spam-Status: No, score=-0.413 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_34=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 0LyYYvZpqH8C for ; Thu, 31 May 2012 06:26:01 -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 A583C21F863B for ; Thu, 31 May 2012 06:26:00 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.75,693,1330866000"; d="scan'208";a="75229549"
Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipocni.tcif.telstra.com.au with ESMTP; 31 May 2012 23:25:59 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6727"; a="66423042"
Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcbni.tcif.telstra.com.au with ESMTP; 31 May 2012 23:25:59 +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, 31 May 2012 23:25:59 +1000
From: "Manger, James H" 
To: Vladimir Dzhuvinov / NimbusDS , "jose@ietf.org" 
Date: Thu, 31 May 2012 23:25:48 +1000
Thread-Topic: [jose] Suggestion for new term: JSON Web Object (JWO) or JSON Web	Message (JWM)
Thread-Index: Ac0/I6oAXT058feVQd6Huz/6XEDabgACcWKw
Message-ID: <255B9BB34FB7D647A506DC292726F6E114F4FC12CF@WSMSG3153V.srv.dir.telstra.com>
References: <20120531044410.cc40c4f3d92d2001859047cd8cabb9ab.548d0e08b2.wbe@email07.europe.secureserver.net>
In-Reply-To: <20120531044410.cc40c4f3d92d2001859047cd8cabb9ab.548d0e08b2.wbe@email07.europe.secureserver.net>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [jose] Suggestion for new term: JSON Web Object (JWO) or JSON Web	Message (JWM)
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.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, 31 May 2012 13:26:01 -0000

PiBZZXN0ZXJkYXksIGR1cmluZyB3b3JrIG9uIHRoZSBOaW1idXMtSldUIGxpYnJhcnksIHdlIHJl
YWxpc2VkIHRoZSBuZWVkDQo+IHRvIGNvbWUgdXAgd2l0aCBhIGNvbW1vbiB0ZXJtIGZvciB0aGUg
X3RoaW5nc18gdGhhdCBhcmUgZW5jb2RlZCBieQ0KPiBhbGc6bm9uZSwgSldTIGFuZCBKV0UsIHdo
ZXRoZXIgdGhleSBzZXJpYWxpc2UgdG8gdGhlIGNvbXBhY3Qgb3IgdGhlIEpTDQo+IGZvcm0uDQoN
CkkgYWdyZWUuDQoNCj4gQWZ0ZXIgYSBiaXQgb2YgYnJhaW4gc3Rvcm1pbmcgdHdvIGZhdm91cml0
ZXMgZW1lcmdlZDoNCj4gDQo+IEpTT04gV2ViIE9iamVjdCAoSldPKQ0KPiANCj4gYW5kDQo+IA0K
PiBKU09OIFdlYiBNZXNzYWdlIChKV00pLg0KDQoNCkpXTyBhbmQgSldNIGFyZSBib3RoIG1pc3Np
bmcgdGhlIHNlY3VyaXR5IGFuZ2xlLCB3aGljaCBpcyB0aGUgcHJpbWFyeSByZWFzb24gZm9yIEpP
U0UuDQoNCkhvdyBhYm91dCAiSldzZWMiLCBhbmQgSSB3b3VsZCBjYWxsIHRoZSBzcGVjICJKU09O
IFdlYiBNZXNzYWdlIFNlY3VyaXR5IEZvcm1hdCIuDQoNCg0KSSBkb24ndCB0aGluayB3ZSB3aWxs
IG5lZWQgc2VwYXJhdGUgYWNyb255bXMgZm9yIHNwZWNpZmljIG1vZGVzIG9uY2Ugd2UgaGF2ZSBh
IG5pY2tuYW1lIGZvciB0aGUgdG9wLWxldmVsIHN0cnVjdHVyZS4gRm9yIGluc3RhbmNlLCBzYXkg
InNpZ25lZCBKV3NlYyIgYW5kICJlbmNyeXB0ZWQgSldzZWMiLCBpbnN0ZWFkIG9mIEpXUyBhbmQg
SldFLg0KKE9yIGFyZSAiYXV0aGVudGljIEpXc2VjIiBhbmQgImNvbmZpZGVudGlhbCBKV3NlYyIg
YmV0dGVyIHBocmFzZXM/KQ0KDQoNCi0tDQpKYW1lcyBNYW5nZXINCg==

From James.H.Manger@team.telstra.com  Thu May 31 07:01: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 B7B6E21F859F for ; Thu, 31 May 2012 07:01:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.708
X-Spam-Level: 
X-Spam-Status: No, score=-0.708 tagged_above=-999 required=5 tests=[AWL=0.193,  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 9ptxIWW-XTkK for ; Thu, 31 May 2012 07:01:51 -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 CC95921F858A for ; Thu, 31 May 2012 07:01:45 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.75,693,1330866000"; d="scan'208";a="76105118"
Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipoavi.tcif.telstra.com.au with ESMTP; 01 Jun 2012 00:01:44 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6727"; a="65683427"
Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcbvi.tcif.telstra.com.au with ESMTP; 01 Jun 2012 00:01:44 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Fri, 1 Jun 2012 00:01:43 +1000
From: "Manger, James H" 
To: Vladimir Dzhuvinov / NimbusDS , "jose@ietf.org" 
Date: Fri, 1 Jun 2012 00:01:41 +1000
Thread-Topic: [jose] Allow compression of plain and JWS too?
Thread-Index: Ac0/JS0k9vXGkur0QFew5hdyTilRGAAC8aMw
Message-ID: <255B9BB34FB7D647A506DC292726F6E114F4FC12D3@WSMSG3153V.srv.dir.telstra.com>
References: <20120531050148.cc40c4f3d92d2001859047cd8cabb9ab.af6dca8411.wbe@email07.europe.secureserver.net>
In-Reply-To: <20120531050148.cc40c4f3d92d2001859047cd8cabb9ab.af6dca8411.wbe@email07.europe.secureserver.net>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [jose] Allow compression of plain and JWS too?
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.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, 31 May 2012 14:01:51 -0000

PiBJcyB0aGVyZSBhIHJlYXNvbiB0byBoYXZlIGNvbXByZXNzaW9uIG9ubHkgd2l0aCBKV0U/DQoN
CkNvbXByZXNzaW9uIHNob3VsZCBiZSBhdmFpbGFibGUgaW4gc2lnbmVkIGFuZCB1bnByb3RlY3Rl
ZCBtZXNzYWdlcyBhcyB3ZWxsLiBTcGVjaWZ5aW5nIHRoZSAiemlwIiBoZWFkZXIgZWxlbWVudCBm
b3Igc2lnbmVkIEpXc2VjIG1lc3NhZ2VzIChha2EgSldTKSBhbmQgdW5wcm90ZWN0ZWQgSldzZWMg
bWVzc2FnZXMgKGFrYSAiYWxnIjoibm9uZSIpIHdvdWxkIGJlIGEgZ29vZCBhcHByb2FjaC4NCg0K
DQpUaGUgREVGTEFURSBhbGdvcml0aG0gZG9lcyBhIHJlYWxseSBnb29kIGpvYiBvZiBhbG1vc3Qg
ZWxpbWluYXRpbmcgdGhlIDMzJSBvdmVyaGVhZCBpbnRyb2R1Y2VkIGJ5IGEgYmFzZTY0dXJsIGVu
Y29kaW5nLg0KKiBERUZMQVRFKEI2NChyYW5kb20pKSBpcyBvbmx5IDElIGxvbmdlciB0aGFuIHJh
bmRvbQ0KKiBERUZMQVRFKEI2NChERUZMQVRFKHRleHQpKSkgaXMgbGVzcyB0aGFuIDElIGxvbmdl
ciB0aGFuIERFRkxBVEUodGV4dCkNCiogREVGTEFURShCNjQodGV4dCkpIGhvd2V2ZXIgaXMgc2ln
bmlmaWNhbnRseSBsb25nZXIgdGhhbiBERUZMQVRFKHRleHQpDQoNCi0tDQpKYW1lcyBNYW5nZXIN
Cg==

From James.H.Manger@team.telstra.com  Thu May 31 07:50: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 6610D21F871A for ; Thu, 31 May 2012 07:50:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.716
X-Spam-Level: 
X-Spam-Status: No, score=-0.716 tagged_above=-999 required=5 tests=[AWL=0.185,  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 U05coqKQVbof for ; Thu, 31 May 2012 07:50:43 -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 72AF221F8722 for ; Thu, 31 May 2012 07:50:42 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.75,693,1330866000"; d="scan'208";a="81107785"
Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipoani.tcif.telstra.com.au with ESMTP; 01 Jun 2012 00:50:41 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6727"; a="66792866"
Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipccni.tcif.telstra.com.au with ESMTP; 01 Jun 2012 00:50:41 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Fri, 1 Jun 2012 00:50:41 +1000
From: "Manger, James H" 
To: Vladimir Dzhuvinov / NimbusDS , "jose@ietf.org" 
Date: Fri, 1 Jun 2012 00:50:37 +1000
Thread-Topic: [jose] JOSE top-level syntax proposal
Thread-Index: Ac0/HNGw52a7UjdxRoGmpLzRSNVfRQAGT1qQ
Message-ID: <255B9BB34FB7D647A506DC292726F6E114F4FC12DB@WSMSG3153V.srv.dir.telstra.com>
References: <20120531040152.cc40c4f3d92d2001859047cd8cabb9ab.ea4ca89ae0.wbe@email07.europe.secureserver.net>
In-Reply-To: <20120531040152.cc40c4f3d92d2001859047cd8cabb9ab.ea4ca89ae0.wbe@email07.europe.secureserver.net>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [jose] JOSE top-level syntax proposal
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.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, 31 May 2012 14:50:43 -0000

Pj4gandzZWMgPSAoIloiICIuIiBoZWFkZXI2NCAiLiIgY29tcHJlc3NlZDY0KSAvDQo+PiAgICAg
ICAgICgiUyIgIi4iIGhlYWRlcjY0ICIuIiBkYXRhNjQgIi4iIHNpZ25hdHVyZTY0KSAvDQo+PiAg
ICAgICAgICgiSSIgIi4iIGhlYWRlcjY0ICIuIiBkYXRhNjQgIi4iIGNoZWNrc3VtNjQpIC8NCj4+
ICAgICAgICAgKCJFIiAiLiIgaGVhZGVyNjQgIi4iIGVuY2tleTY0ICIuIiBjaXBoZXJ0ZXh0NjQg
Ii4iIG1hYzY0KSAvDQo+PiAgICAgICAgIChleHQgIi4iIGhlYWRlcjY0ICooIi4iIGNvbXBvbmVu
dDY0KSkNCg0KVmxhZGltaXIgRHpodXZpbm92IC8gTmltYnVzRFMgc2FpZDoNCj4gSWYgSSB1bmRl
cnN0YW5kIGNvcnJlY3RseSwgdGhlIG1haW4gcHVycG9zZSBvZiB0aGVzZSBwcmVmaXhlcyBpcyB0
bw0KPiBlbmFibGUgdGhlIG1lc3NhZ2UvYWxnIHR5cGUgdG8gYmUgZGV0ZXJtaW5lZCB3aXRob3V0
IGRlY29kaW5nIHRoZQ0KPiBoZWFkZXI/IERvIHlvdSBzZWUgYW55IHBhcnRpY3VsYXIgY2FzZXMv
c2NlbmFyaW9zIHdoZXJlIHRoaXMgY291bGQNCj4gbWF0dGVyPw0KDQpUaGUgIkUiIHByZWZpeCB0
ZWxscyB5b3UgdGhhdCB5b3UgaGF2ZSBhbiBlbmNyeXB0ZWQgbWVzc2FnZSwgc28geW91ciBpbml0
aWFsIGNvZGUgY2FuIGltbWVkaWF0ZWx5IHBhc3MgaXQgdG8geW91ciBkZWNyeXB0aW9uIGNsYXNz
IHdpdGhvdXQgaGF2aW5nIHRvIGtub3cgYWxsIHRoZSBlbmNyeXB0aW9uIGFsZ29yaXRobSBpZGVu
dGlmaWVycy4NCkkgdGhpbmsgdGhlIChuaWNlIGxvb2tpbmcpIE5pbWJ1cyBjb2RlLCBmb3IgaW5z
dGFuY2UsIHNwbGl0cyBvbiBkb3RzLCBiYXNlNjR1cmwtZGVjb2RlcywgaW50ZXJwcmV0cyBhcyBV
VEYtOCwgcGFyc2VzIGFzIEpTT04sIGV4dHJhY3RzIHRoZSAiYWxnIiBlbGVtZW50LCBsb29rcyB1
cCB0aGUgYWxnIHZhbHVlIHRvIGxlYXJuIGl0cyB0eXBlLi4uIHRoZW4gc2VlcyBpdCBpcyBhbiBl
bmNyeXB0ZWQgbWVzc2FnZSBhbmQgcGFzc2VzIHRoZSBvcmlnaW5hbCBzdHJpbmcgdG8gdGhlIGVu
Y3J5cHRpb24gY29kZSAod2hlcmUgc3BsaXR0aW5nL2RlY29kaW5nL2ludGVycHJldGluZy9wYXJz
aW5nIGhhcHBlbnMgYWxsIG92ZXIgYWdhaW4pLg0KDQoNClRoZSAiUyIgcHJlZml4IGltbWVkaWF0
ZWx5IHRlbGxzIHlvdSB0aGUgM3JkIGRvdC1zZXBhcmF0ZWQgc2VnbWVudCBpcyB0aGUgY29udGVu
dC4gS25vd2luZyB0aGF0IGlzIHN1ZmZpY2llbnQgdG8gZG8gdGhpbmdzIHdpdGggdGhlIGNvbnRl
bnQgZXZlbiBpZiB5b3UgZG9uJ3QgaGF2ZSB0aGUgc2lnbmF0dXJlIHZlcmlmaWNhdGlvbiBrZXks
IG9yIGV2ZW4gaWYgeW91IGRvbid0IHJlY29nbml6ZSB0aGUgc2lnbmF0dXJlIGFsZ29yaXRobS4N
CkZvciBpbnN0YW5jZSwgYSB3ZWIgYXBwIGZpcmV3YWxsIG1pZ2h0IHBlcmZvcm0gc29tZSBzYW5p
dHkgY2hlY2tzIG9uIHRoZSBjb250ZW50Lg0KT3IgKGlmIHlvdXIgYXBwIGFjY2VwdHMgdW5wcm90
ZWN0ZWQgYW5kIHNpZ25lZCBtZXNzYWdlcyksIHlvdSBjYW4gY29udmVydCBhIHNpZ25lZCBtZXNz
YWdlIHRvIGFuIHVucHJvdGVjdGVkIG9uZSB3aGVuIHRoZSBzaWduaW5nIGFsZ29yaXRobSBpcyB1
bnJlY29nbml6ZWQuIEF0IGxlYXN0IHRoYXQgZG9lc24ndCBwdW5pc2ggdGhlIHNlbmRlciBmb3Ig
dHJ5aW5nIHRvIG9mZmVyIHNvbWUgc2VjdXJpdHkgKGJ5IHNpZ25pbmcpLCBldmVuIGlmIHlvdSBk
b24ndCBzdXBwb3J0IHRoYXQgYWxnb3JpdGhtIHlldC4NCg0KSWYgYSBuZXcgbW9kZSBpcyBkZWZp
bmVkIChzdWNoIGFzIHRoZSBjaGVja3N1bSBtb2RlIG1lbnRpb25lZCByZWNlbnRseSkgeW91IGNh
biByZWNvZ25pemUgdGhhdCBzdHJhaWdodCBhd2F5IGFuZCBvZmZlciBhbiBhcHByb3ByaWF0ZSBl
cnJvciBtZXNzYWdlLCBpbnN0ZWFkIG9mIHRoaW5raW5nIGl0IGlzIGFuIHVua25vd24gc2lnbmF0
dXJlIGFsZ29yaXRobSBvciBhIG1lc3NhZ2Ugd2l0aCBhIG1pc3NpbmcgaGVhZGVyIGVsZW1lbnQu
DQoNCkFzIGEgYm9udXMsIGEgbWVzc2FnZSdzIG1vZGUgaXMgaW5zdGFudGx5IG9idmlvdXMgdG8g
ZGV2ZWxvcGVycyAod2l0aG91dCBjdXQgJ24gcGFzdGluZyBhIGhlYWRlciBpbnRvIGEgYmFzZTY0
dXJsIGRlY29kaW5nIHRvb2wpLg0KDQo+IEFwYXJ0IGZyb20gdGhpcywgdGhlIHByZWZpeCBzZWVt
cyByZWR1bmRhbnQgdG8gbWUuDQoNCkV2ZW4gaWYgdGhlcmUgaXMgYWx3YXlzIGVub3VnaCBpbmZv
IHNvbWV3aGVyZSBpbiBhIGhlYWRlciB0byBkaXN0aW5ndWlzaCBhIG1lc3NhZ2UncyBtb2RlIChz
aWduZWQvZW5jcnlwdGVkL3VucHJvdGVjdGVkLy4uLikgc28gdGhhdCBhIHByZWZpeCBpcyB0aGVv
cmV0aWNhbGx5IHJlZHVuZGFudCwgdGhlIHByZWZpeCBpcyBhIGZhciBlYXNpZXIsIG1vcmUgZGly
ZWN0LCB3YXkgdG8gZGV0ZXJtaW5lIHRoZSBtb2RlLg0KDQoNClAuUy4gTXkgIloiIG1vZGUgc2hv
dWxkIGJlIGNoYW5nZWQgdG8gIlUiIGZvciB1bnByb3RlY3RlZCwgYW5kIGNvbXByZXNzaW9uIHNo
b3VsZCBiZSBpbnRlZ3JhdGVkIGludG8gYWxsIG1vZGVzIChpZSBub3QgYmUgYSBzZXBhcmF0ZSBt
b2RlKS4NCg0KLS0NCkphbWVzIE1hbmdlcg0K

From Axel.Nennker@telekom.de  Thu May 31 08:06: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 0FF2721F86DC for ; Thu, 31 May 2012 08:06:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.8
X-Spam-Level: 
X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=-0.410,  BAYES_20=-0.74, 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 XOmjgPF4k9tf for ; Thu, 31 May 2012 08:06:26 -0700 (PDT)
Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 2848D21F867F for ; Thu, 31 May 2012 08:06:25 -0700 (PDT)
Received: from he111297.emea1.cds.t-internal.com ([10.125.90.15]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 31 May 2012 17:06:24 +0200
Received: from HE113599.emea1.cds.t-internal.com (10.125.65.118) by HE111297.EMEA1.CDS.T-INTERNAL.COM (10.125.90.15) with Microsoft SMTP Server (TLS) id 8.3.245.1; Thu, 31 May 2012 17:06:23 +0200
Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.88]) by HE113599.emea1.cds.t-internal.com ([2002:7cd:4176::7cd:4176]) with mapi; Thu, 31 May 2012 17:06:23 +0200
From: 
To: , 
Date: Thu, 31 May 2012 17:06:23 +0200
Thread-Topic: ECDH-ES in Java for JWE
Thread-Index: Ac0/PvCLSDIDtrrBSQSUv/KIvrcQig==
Message-ID: 
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: [jose] ECDH-ES in Java for 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: Thu, 31 May 2012 15:06:27 -0000

I whipped something up that I think is not completely bogus.

Encryption:
https://code.google.com/p/openinfocard/source/browse/trunk/src/org/xmldap/j=
son/WebToken.java#699

Decryption:
https://code.google.com/p/openinfocard/source/browse/trunk/src/org/xmldap/j=
son/WebToken.java#644

KDFConcatGenerator:
https://code.google.com/p/openinfocard/source/browse/trunk/src/org/xmldap/c=
rypto/KDFConcatGenerator.java

JUNIT test cases:
https://code.google.com/p/openinfocard/source/browse/trunk/testsrc/org/xmld=
ap/json/WebTokenTest.java#723

I know the code needs more work to make it adhere to the spec. Currently I =
am not using the epk field but x and y but the semantic should be the same =
I hope.

Have fun
Axel