Subject: [jose] FW: Comments on draft-ietf-jose-json-web-algorithms-02

From: "Manger, James H" <[email-masked]>
Date: Thu, 31 May 2012 11:33:15 +1000

> Except that, since this is a security protocol, if a receiver doesn't understand 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 with no checksum would have been accepted -- is not a good approach. Many developers will ignore the pretence.

--
James Manger

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

Handling John Bradley's suggestion for data with a checksum further highlights why using "alg" values (or the presence/absence of "enc") is a poor design 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 message #1, passing "Hello, World!" to the rest of the program (just without saying 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 message.

Different behaviour for different "unknown" algorithms, based on only knowing the mode.

--
James Manger

-----Original Message-----
From: Mike Jones [mailto:[email-masked]] 
Sent: Thursday, 31 May 2012 3:18 AM
To: Jim Schaad; Manger, James H; 'Sean Turner'; 'Vladimir Dzhuvinov / NimbusDS'
Cc: [email-masked]
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

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

---

From: Mike Jones <[email-masked]>
Date: Thu, 31 May 2012 01:34:57 +0000

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Wednesday, May 30, 2012 6:33 PM
To: [email-masked]
Subject: [jose] FW: Comments on draft-ietf-jose-json-web-algorithms-02

--
James Manger

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

--
James Manger

-----Original Message-----
From: Mike Jones [mailto:[email-masked]] 
Sent: Thursday, 31 May 2012 3:18 AM
To: Jim Schaad; Manger, James H; 'Sean Turner'; 'Vladimir Dzhuvinov / NimbusDS'
Cc: [email-masked]
Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

				-- Mike

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 31 May 2012 11:40:18 +1000

> 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 the ability to detect (or correct) some accidental transmission errors if the receiver thinks do so is worthwhile. That is subtly different from a sender forcing the receiver to reject messages if certain accidental transmission errors occur.

--
James Manger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Wednesday, May 30, 2012 6:33 PM
To: [email-masked]
Subject: [jose] FW: Comments on draft-ietf-jose-json-web-algorithms-02

--
James Manger