Re: [jose] Distinguishing signed, encrypted, and unprotected tokens

[Mike Jones <[e-mail]>]

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-serialization-01
	http://tools.ietf.org/html/draft-jones-json-web-encryption-json-serialization-01

				-- Mike

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Richard L. Barnes
Sent: Sunday, May 20, 2012 12:24 PM
To: Jim Schaad
Cc: 'John Bradley'; 'Manger, James H'; [e-mail]
Subject: Re: [jose] Distinguishing signed, encrypted, and unprotected tokens

+1

Distinguishing based on number of dots seems really fragile.  




On May 20, 2012, at 3:12 PM, Jim Schaad wrote:

> <no hat>
> 
> 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: [e-mail] [mailto:[e-mail]] On Behalf 
>> Of Manger, James H
>> Sent: Sunday, May 20, 2012 12:48 AM
>> To: John Bradley
>> Cc: [e-mail]
>> 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 (<header>.<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".<header>.<wrappedkey>.<ciphertext>.<MAC>; a JWS is 
>> "S".<header>.<payload>.<signature>, and an unprotected payload is 
>> "P".<header>.<payload>.
>> 
>> 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:[e-mail]]
>> Sent: Friday, 18 May 2012 9:45 PM
>> To: Manger, James H
>> Cc: [e-mail]
>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/jose
>> 
>> _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/jose