Re: [jose] Issue #102

Re: [jose] Issue #102 - Bullet B

"Manger, James H" <James.H.Manger@team.telstra.com> Fri, 04 October 2013 04:35 UTC

From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: Jim Schaad <ietf@augustcellars.com>, "jose@ietf.org" <jose@ietf.org>
Date: Fri, 04 Oct 2013 14:34:55 +1000
Thread-Topic: [jose] Issue #102 - Bullet B
Thread-Index: Ac7AaE6X8XciYK7BQB2WVHJobOEzngAUPUVA
Message-ID: <255B9BB34FB7D647A506DC292726F6E11531983E57@WSMSG3153V.srv.dir.telstra.com>
References: <008a01cec06c$8cc08030$a6418090$@augustcellars.com>
In-Reply-To: <008a01cec06c$8cc08030$a6418090$@augustcellars.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E11531983E57WSMSG3153Vsrv_"
MIME-Version: 1.0
Subject: Re: [jose] Issue #102 - Bullet B
Precedence: list

“collision resistant namespaces” is a broken concept in JOSE docs (and JWT) because, of course, you lose collision-resistance when you combine namespaces as is done here.

My suggestion for JWT was < http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-11>:


Could the reserved/public/private mess be simplified by saying (at the end of section 4 "JWT Claims"):



  A claim name can be any string. Using URIs as claim names is one

  way to ensure claim names are unambiguous. Claim names that are

  not URIs SHOULD be registered in the IANA Claims registry [section 9.1]



Then drop the last paragraph of section 4 "JWT claims" that starts "there are three classes of JWT Claim Names"; drop section 4.2 "Public claim names"; drop section 4.3 "Private claim names"; drop the "collision resistant namespace" term.


Similar language can apply to “alg” values, header parameters names, etc.

--
James Manger

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Friday, 4 October 2013 5:13 AM
To: jose@ietf.org
Subject: [jose] Issue #102 - Bullet B

I find myself slightly worried about the fact that we say that some names are either from our registry or are from a collision resistant namespace, without explicitly stating what this means.

Consider the following strings

1.2.3.4
http://example.com/algoirthm/sha-1
RSAES-PKCS1-v1.5

All three of these are names from a collision resistant name space (OID, URL, WebCrypto Algorithm names), but in only one case has the namespace been identified.  If we don’t require that the namespace be part of the string then it would appear that there is a potential problem waiting to raise its ugly head.

I can see a couple of potential places to address this, however the easiest would be to make the definition of a Collision Resistant Name to include the concept that it is composed of a name space identifier and a name in the name space.  This would make the first item in my list be oid:1.2.3.4 and the last one not usable unless and until a namespace identifier is created for it.

The language in a couple of places should also be cleaned up to make it slightly  more readable so that


"alg" values SHOULD either be registered in the IANA JSON Web

   Signature and Encryption Algorithms registry defined in [JWA<http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-16#ref-JWA>] or be a
   value that contains a Collision Resistant Name.

becomes


An "alg" value SHOULD be from the IANA JSON Web

   Signature and Encryption Algorithms registry or be a
   Collision Resistant Name.

Comments?

Jim

[jose] Issue #102 - Bullet B Jim Schaad
Re: [jose] Issue #102 - Bullet B Manger, James H