“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: [email protected] [mailto:[email protected]] On Behalf Of Jim Schaad Sent: Friday, 4 October 2013 5:13 AM To: [email protected] 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 mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
