IETF Logo Mail Archive

Re: [jose] implementing JOSE in Java: jsoncrypto

<Axel.Nennker@telekom.de> Thu, 02 August 2012 04:55 UTC

Return-Path: <Axel.Nennker@telekom.de>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1769321F8AAE for <jose@ietfa.amsl.com>; Wed, 1 Aug 2012 21:55:36 -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 9ikbdFxheFoL for <jose@ietfa.amsl.com>; Wed, 1 Aug 2012 21:55:34 -0700 (PDT)
Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 492F821F8AAD for <jose@ietf.org>; Wed, 1 Aug 2012 21:55:33 -0700 (PDT)
Received: from he113414.emea1.cds.t-internal.com ([10.125.65.80]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 02 Aug 2012 06:55:32 +0200
Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.25]) by HE113414.emea1.cds.t-internal.com ([2002:7cd:4150::7cd:4150]) with mapi; Thu, 2 Aug 2012 06:55:31 +0200
From: Axel.Nennker@telekom.de
To: James.H.Manger@team.telstra.com, jose@ietf.org
Date: Thu, 02 Aug 2012 06:55:30 +0200
Thread-Topic: implementing JOSE in Java: jsoncrypto
Thread-Index: Ac1wJYQ5vWKU92MjQua7if8t15zj5gAJIbggAAf6HlA=
Message-ID: <CE8995AB5D178F44A2154F5C9A97CAF402517DACDC8C@HE111541.emea1.cds.t-internal.com>
References: <CE8995AB5D178F44A2154F5C9A97CAF402517DACDC53@HE111541.emea1.cds.t-internal.com> <255B9BB34FB7D647A506DC292726F6E114FA10EDE1@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FA10EDE1@WSMSG3153V.srv.dir.telstra.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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [jose] implementing JOSE in Java: jsoncrypto
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Aug 2012 04:55:36 -0000

I wanted to wait a little more before implementing that because the discussion here about it seems to bring too many changes to the code.
There are other things too that need to be improved. But jsoncrypto implements all proposed alg and enc values other than none (which I find strange) and dir (which I had implemented first but the group at that time seemed to think that this might make it too easy for developers to use the same cek too often (always)).

-----Original Message-----
From: Manger, James H [mailto:James.H.Manger@team.telstra.com] 
Sent: Thursday, August 02, 2012 3:26 AM
To: Nennker, Axel; jose@ietf.org
Subject: RE: implementing JOSE in Java: jsoncrypto

Axel,

> I moved my JOSE implementation out of my openinfocard project into a 
> new repository:
> https://code.google.com/p/jsoncrypto/

It is good to see another JOSE implementation.

Does jsoncrypto implement the "MUST understand everything" rule?

  [JWE-05, section 4]
  Implementations MUST understand the entire contents of the
  header; otherwise, the JWE MUST be rejected.

  [JWE-05, section 6]
  4. The resulting JWE Header MUST be validated to only include
     parameters and values whose syntax and semantics are both
     understood and supported.

Jsoncrypto does not appear to implement this rule. It appears to take the obvious approach of looking in the header for the fields it needs -- and ignoring anything else that might be there.

[Regardless of any possible merit in a "MUST understand everything" rule, the fact that it will often not be implemented seems like a really good reason to drop the rule so the spec reflects reality.]

--
James Manger

v2.23.0 | Report a Bug | By Email