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

From: "Vladimir Dzhuvinov / NimbusDS" <[email-masked]>
Date: Sun, 27 May 2012 22:47:09 -0700

> On 5/22/12 3:53 AM, Vladimir Dzhuvinov / NimbusDS wrote:
> >
> >>> Section 3.1
> >>>
> >>> 1. I am not overly happy with the existence of a "none" algorithm. Does it
> >>> really need to exist?
> >>
> >> +1 for removing "none"
> >
> > +1 for deprecating none.
> >
> > The same information can be expressed by simply omitting "alg". This
> > makes plain JWTs nimbler too. I see no problem with having empty headers
> > for plain JWTs.
> >
> > Also, by removing "none", "alg" would become consistent with the rest of
> > the parameters which don't have "none" values (we don't have
> > "enc":"none", etc.). Very much like the recent change to "zip" (JWS,
> > section 4.1.6) which no longer has the (optional) "none": it's either
> > "zip":"DEF" or nothing.
> 
> Just make sure to explain what it means when alg is omitted. Assume 
> this would apply equally to both JSW and JWE?
> 
> spt

My understanding is that this should actually be explained in the JSON
Web Token (JWT) spec where the concept of plain tokens is originally
introduced. Therefore, the case of a missing "alg" should fall outside
the scope of the JWS and JWE specs.

Vladimir

--
Vladimir Dzhuvinov : www.NimbusDS.com : [email-masked]

---

From: Sean Turner <[email-masked]>
Date: Mon, 28 May 2012 11:21:34 -0400

> the scope of the JWS and JWE specs.

That's one possibility but then you're introducing a normative 
reference.  If draft-ietf-jose-json-web-algorithms, is going to retain 
the section on creating plaintext JWS then it's worth saying how empty 
would be handled - and then you can avoid the reference.

spt

---

From: Mike Jones <[email-masked]>
Date: Mon, 28 May 2012 16:44:01 +0000

For what it's worth, "alg":"none" was moved from JWT to JWS based upon Jim Schaad's suggestion in http://www.ietf.org/mail-archive/web/jose/current/msg00365.html for closing the open issue about whether it belongs in JWT or JWS.  In it, he wrote:

[JLS] If it is believe that a parameter this list is going to be "commonly" used by many different profilers, then I believe that the core items needs to be done the in the base specification.

I believe his rationale was correct and has been proven out by events.  At this point I now of several usages of "none" both within JWTs, and significantly, in at least one context where the structure is a JWS but *not* a JWT.  I believe Jim was right to suggest that "alg":"none" belongs in the Algorithms specification.

				Best wishes,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sean Turner
Sent: Monday, May 28, 2012 8:22 AM
To: Vladimir Dzhuvinov / NimbusDS
Cc: [email-masked]
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

On 5/28/12 1:47 AM, Vladimir Dzhuvinov / NimbusDS wrote:
>>>>> 1. I am not overly happy with the existence of a "none" algorithm. 
>>>>> Does it really need to exist?
>>>>
>>>> +1 for removing "none"
>>>
>>> +1 for deprecating none.
>>>
>>> makes plain JWTs nimbler too. I see no problem with having empty 
>>> headers for plain JWTs.
>>>
>>> Also, by removing "none", "alg" would become consistent with the 
>>> rest of the parameters which don't have "none" values (we don't have 
>>> section 4.1.6) which no longer has the (optional) "none": it's 
>>> either "zip":"DEF" or nothing.
>>

That's one possibility but then you're introducing a normative reference.  If draft-ietf-jose-json-web-algorithms, is going to retain the section on creating plaintext JWS then it's worth saying how empty would be handled - and then you can avoid the reference.

spt

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

---

From: Sean Turner <[email-masked]>
Date: Mon, 28 May 2012 13:26:15 -0400

I think it's fine that it stays where it is, but if you decide to get 
rid of it you'll need to say something about what omitting alg means in 
this draft.

spt

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 28 May 2012 16:07:49 -0700

I agree that if this is going to be done as an alg notation it should be in
the algorithm draft.

I am not so sure that I think that marking this as an algorithm is a good
idea and that should be discussed.  It is possible that we should talk about
some type of degenerate signature structure where we can know that it is a
signature structure but that there is no signature algorithm might be
better.

One possible way of doing this might be to have a field which says
"unsigned: true" instead.

Jim

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Mike Jones
> Sent: Monday, May 28, 2012 9:44 AM
> To: Sean Turner; Vladimir Dzhuvinov / NimbusDS
> Cc: [email-masked]
> For what it's worth, "alg":"none" was moved from JWT to JWS based upon
> Jim Schaad's suggestion in http://www.ietf.org/mail-
> archive/web/jose/current/msg00365.html for closing the open issue about
> whether it belongs in JWT or JWS.  In it, he wrote:
> 
> [JLS] If it is believe that a parameter this list is going to be
"commonly" used
> by many different profilers, then I believe that the core items needs to
be
> done the in the base specification.
> 
> I believe his rationale was correct and has been proven out by events.  At
this
> point I now of several usages of "none" both within JWTs, and
significantly, in
> at least one context where the structure is a JWS but *not* a JWT.  I
believe
> Jim was right to suggest that "alg":"none" belongs in the Algorithms
> specification.
> 
> 				Best wishes,
> 				-- Mike
> 
> That's one possibility but then you're introducing a normative reference.
If
> draft-ietf-jose-json-web-algorithms, is going to retain the section on
creating
> plaintext JWS then it's worth saying how empty would be handled - and then
> you can avoid the reference.
> 
> spt
>

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 29 May 2012 10:23:21 +1000

"alg":"none" certainly doesn't belong in the OAuth JWT spec that defines a format for identity claims.

Sticking "alg":"none" in a JOSE core spec is not the answer, however. The solution is to make unprotected data a first-class citizen alongside signed data (JWS) and encrypted data (JWE) in the (embarrassingly unnamed) top-level JOSE structure that can hold any of these 3 forms of data -- and is the JOSE structure that other specs will use.

Having JWS and JWE in separate specs means there isn't an obvious place to specify the top-level JOSE structure (so it is done awkwardly in the OAuth JWT spec). We could add two more JOSE specs: JWP (plain/unprotected data) and JOSE (top-level structure = {JWS|JWE|JWP}). I think a better approach would be to (re-)combine JWS and JWE. The combined spec would include unprotected data as a third mode. The algorithms spec can remain separate.

--
James Manger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Tuesday, 29 May 2012 2:44 AM
To: Sean Turner; Vladimir Dzhuvinov / NimbusDS
Cc: [email-masked]
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

				Best wishes,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sean Turner
Sent: Monday, May 28, 2012 8:22 AM
To: Vladimir Dzhuvinov / NimbusDS
Cc: [email-masked]
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

spt

---

From: Mike Jones <[email-masked]>
Date: Tue, 29 May 2012 04:34:51 +0000

In my view, introducing an extra "unsigned" parameter would unnecessarily complicate processing, as currently implementations can completely determine the structure based only upon the "alg" parameter value.  This would force implementations to potentially look at both an "unsigned" parameter and an "alg" parameter to determine the structure.

The invariant between signed/MACed JWS, encrypted JWE, and unsigned JWS structures is that the structure of all three is unambiguously distinguished by the value of the "alg" parameter.  (And of course, if the "alg" value is not understood, the values MUST be rejected.)

				-- Mike

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Monday, May 28, 2012 4:08 PM
To: Mike Jones; 'Sean Turner'; 'Vladimir Dzhuvinov / NimbusDS'
Cc: [email-masked]
Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

I agree that if this is going to be done as an alg notation it should be in the algorithm draft.

I am not so sure that I think that marking this as an algorithm is a good idea and that should be discussed.  It is possible that we should talk about some type of degenerate signature structure where we can know that it is a signature structure but that there is no signature algorithm might be better.

Jim

> archive/web/jose/current/msg00365.html for closing the open issue 
> about whether it belongs in JWT or JWS.  In it, he wrote:
> 
"commonly" used
be
this
significantly, in
believe
> >>> The same information can be expressed by simply omitting "alg". 
> >>> This makes plain JWTs nimbler too. I see no problem with having 
> >>> empty headers for plain JWTs.
> >>>
> >>> rest of the parameters which don't have "none" values (we don't 
> >>> have "enc":"none", etc.). Very much like the recent change to 
> >>> "zip" (JWS, section 4.1.6) which no longer has the (optional) 
> >>> "none": it's either "zip":"DEF" or nothing.
> >>
> > My understanding is that this should actually be explained in the 
> > JSON Web Token (JWT) spec where the concept of plain tokens is 
> > originally introduced. Therefore, the case of a missing "alg" should 
> > fall outside the scope of the JWS and JWE specs.
> 
If
creating
> plaintext JWS then it's worth saying how empty would be handled - and 
> then you can avoid the reference.
> 
> spt
>

---

From: Mike Jones <[email-masked]>
Date: Tue, 29 May 2012 04:34:53 +0000

Actually, the third mode already exists, and is parallel, by design, to the signed/MACed and encrypted modes.  No restructuring is necessary to achieve this.  The three are all unambiguously distinguished by the value of the "alg" parameter (the value of which MUST be understood, or else the structure must be rejected).

					-- Mike

-----Original Message-----
From: Manger, James H [mailto:[email-masked]] 
Sent: Monday, May 28, 2012 5:23 PM
To: Mike Jones; Sean Turner; Vladimir Dzhuvinov / NimbusDS
Cc: [email-masked]
Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

--
James Manger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Tuesday, 29 May 2012 2:44 AM
To: Sean Turner; Vladimir Dzhuvinov / NimbusDS
Cc: [email-masked]
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

				Best wishes,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sean Turner
Sent: Monday, May 28, 2012 8:22 AM
To: Vladimir Dzhuvinov / NimbusDS
Cc: [email-masked]
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

spt

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 29 May 2012 15:13:07 +1000

Sure, the third mode (plaintext) already exists -- but it is not parallel to the signed/MACed and encrypted modes. It is an awkward sub-mode of the signed/MACed mode -- reusing the same fields, but with dummy or blank values; providing completely different security; not mentioned in the JWS abstract; only appearing in an appendix (A.4. Example Plaintext JWS); without a separate "typ" value or MIME type etc.

I think the alg value is a poor way to distinguish unprotected, signed, and encrypted JWx messages. Even it that mechanism remains though, I would like plaintext mode to be a "first-class citizen". The fact that plaintext mode is hidden away is actually a symptom of not having a place to specify the JOSE top-level structure {signed data | encrypted data | unprotected data}.

--
James Manger

-----Original Message-----
From: Mike Jones [mailto:[email-masked]] 
Sent: Tuesday, 29 May 2012 2:35 PM
To: Manger, James H; Sean Turner; Vladimir Dzhuvinov / NimbusDS
Cc: [email-masked]
Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

					-- Mike

-----Original Message-----
From: Manger, James H [mailto:[email-masked]] 
Sent: Monday, May 28, 2012 5:23 PM
To: Mike Jones; Sean Turner; Vladimir Dzhuvinov / NimbusDS
Cc: [email-masked]
Subject: RE: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

--
James Manger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Tuesday, 29 May 2012 2:44 AM
To: Sean Turner; Vladimir Dzhuvinov / NimbusDS
Cc: [email-masked]
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

				Best wishes,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sean Turner
Sent: Monday, May 28, 2012 8:22 AM
To: Vladimir Dzhuvinov / NimbusDS
Cc: [email-masked]
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

spt

---

From: John Bradley <[email-masked]>
Date: Tue, 29 May 2012 18:12:15 -0600

All of the alg modes provide different security.  Some are signing, integrity, encryption or combinations.
I would not want to get rid of none as a valid alg.   It was part of signing originally because we thought of it as a null hash.

Making it clearer is fine, if we can do that.  

One thought this brings up, is should we have a simple hash alg defined as well as hmac?

John B.

---

From: Mike Jones <[email-masked]>
Date: Wed, 30 May 2012 00:19:44 +0000

John, you wrote: "One thought this brings up, is should we have a simple hash alg defined as well as hmac?"

What use case do you have in mind, and what kind of simple hash algorithm did you have in mind?

					-- Mike

-----Original Message-----
From: John Bradley [mailto:[email-masked]] 
Sent: Tuesday, May 29, 2012 5:12 PM
To: Manger, James H
Cc: Mike Jones; Sean Turner; Vladimir Dzhuvinov / NimbusDS; [email-masked]
Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

John B.

On 2012-05-28, at 11:13 PM, Manger, James H wrote:

>>>> have "enc":"none", etc.). Very much like the recent change to "zip" 
>>>> (JWS, section 4.1.6) which no longer has the (optional) "none": 
>>>> it's either "zip":"DEF" or nothing.
>>>

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 30 May 2012 10:25:46 +1000

> One thought this brings up, is should we have a simple hash alg defined as well as hmac?

No.
I assume you mean a non-keyed hash of the data -- providing a checksum against accidental modification. JOSE does not need this. It really has to be handled much further down the protocol stack.

--
James Manger

---

From: John Bradley <[email-masked]>
Date: Tue, 29 May 2012 18:26:53 -0600

A HMAC is useful to protect against intentional manipulation of a message, but requires a shared secret.

Sometimes you just want to message integrity against accidental modification.  In that case a SHA256 or other hash would do without the need to have a shared secret.

John B.

---

From: John Bradley <[email-masked]>
Date: Tue, 29 May 2012 18:30:59 -0600

In general it is handled much further down the stack.  

I am not saying we defiantly need a way to do integrity without a shared key or asymmetric signing,  but sometimes it is nice to expose that to the higher layer for integrity audit or even testing.   We have SHA256 anyway for HMAC it is not a big add.

Not something I will loose any sleep over.

John B.

---

From: Sean Turner <[email-masked]>
Date: Tue, 29 May 2012 20:45:14 -0400

> Sometimes you just want to message integrity against accidental modification.  In that case a SHA256 or other hash would do without the need to have a shared secret.

I support this idea.

spt

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 30 May 2012 10:59:44 +1000

>I support this idea.

I doubt this is useful enough to warrant inclusion, but if it is can we please not sneak it in as a fake signature algorithm that doesn't actually offer authenticity. That is, don't pretend it is a JWS. Make it a first-class citizen amongst the JOSE modes (so we need somewhere to describe all the modes).

Crypto-strength collision-resistant secure hashes can be used as checksums, but there are a bunch of "better" algorithms specifically designed for the task (eg CRCs, or even error correcting codes...).

--
James Manger

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 30 May 2012 07:55:58 -0700

One additional reason that I have thought of why we may want something other
than just alg to distinguish between the types is to that it would not be
possible to report to the user

I do not understand the signing algorithm FooBar.  You know the name but no
the algorithm type.

Jim

> Manger, James H
> Sent: Monday, May 28, 2012 10:13 PM
> Sure, the third mode (plaintext) already exists -- but it is not parallel
to the
> signed/MACed and encrypted modes. It is an awkward sub-mode of the
> signed/MACed mode -- reusing the same fields, but with dummy or blank
> values; providing completely different security; not mentioned in the JWS
> abstract; only appearing in an appendix (A.4. Example Plaintext JWS);
without
> a separate "typ" value or MIME type etc.
> 
> I think the alg value is a poor way to distinguish unprotected, signed,
and
> encrypted JWx messages. Even it that mechanism remains though, I would
> like plaintext mode to be a "first-class citizen". The fact that plaintext
mode is
> hidden away is actually a symptom of not having a place to specify the
JOSE
> top-level structure {signed data | encrypted data | unprotected data}.
> 
> --
> James Manger
> 
> 
> Actually, the third mode already exists, and is parallel, by design, to
the
> signed/MACed and encrypted modes.  No restructuring is necessary to
> achieve this.  The three are all unambiguously distinguished by the value
of
> the "alg" parameter (the value of which MUST be understood, or else the
> structure must be rejected).
> 
> 					-- Mike
> 
> Sticking "alg":"none" in a JOSE core spec is not the answer, however. The
> solution is to make unprotected data a first-class citizen alongside
signed data
> (JWS) and encrypted data (JWE) in the (embarrassingly unnamed) top-level
> JOSE structure that can hold any of these 3 forms of data -- and is the
JOSE
> structure that other specs will use.
> 
> Having JWS and JWE in separate specs means there isn't an obvious place to
> specify the top-level JOSE structure (so it is done awkwardly in the OAuth
> JWT spec). We could add two more JOSE specs: JWP (plain/unprotected
> data) and JOSE (top-level structure = {JWS|JWE|JWP}). I think a better
> approach would be to (re-)combine JWS and JWE. The combined spec would
> include unprotected data as a third mode. The algorithms spec can remain
> separate.
> 
> --
> James Manger
> 
> 
"commonly" used
be
this
significantly, in
believe
> Sean Turner
If
creating

---

From: Mike Jones <[email-masked]>
Date: Wed, 30 May 2012 17:17:44 +0000

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

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

One additional reason that I have thought of why we may want something other than just alg to distinguish between the types is to that it would not be possible to report to the user

I do not understand the signing algorithm FooBar.  You know the name but no the algorithm type.

Jim

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Manger, James H
to the
> values; providing completely different security; not mentioned in the 
> JWS abstract; only appearing in an appendix (A.4. Example Plaintext 
> JWS);
without
and
mode is
JOSE
the
of
> the "alg" parameter (the value of which MUST be understood, or else 
> the structure must be rejected).
> 
> 					-- Mike
> 
> Sticking "alg":"none" in a JOSE core spec is not the answer, however. 
> The solution is to make unprotected data a first-class citizen 
> alongside
signed data
> (JWS) and encrypted data (JWE) in the (embarrassingly unnamed) 
> top-level JOSE structure that can hold any of these 3 forms of data -- 
> and is the
JOSE
> Having JWS and JWE in separate specs means there isn't an obvious 
> place to specify the top-level JOSE structure (so it is done awkwardly 
> in the OAuth JWT spec). We could add two more JOSE specs: JWP 
> (plain/unprotected
> include unprotected data as a third mode. The algorithms spec can 
> remain separate.
> 
> --
> James Manger
> 
> 
"commonly" used
be
this
significantly, in
believe
If
creating

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 30 May 2012 10:21:39 -0700

And if I were enrcrypting with a pre-shared secret then I would no alg but
an enc?

> Sent: Wednesday, May 30, 2012 10:18 AM
> To: Jim Schaad; 'Manger, James H'; 'Sean Turner'; 'Vladimir Dzhuvinov /
> NimbusDS'
> Cc: [email-masked]
> 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:
> 
> BTW, this is already explained in
http://tools.ietf.org/html/draft-ietf-oauth-
> json-web-token-00#section-5, which says:
> 
> 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
> 
> One additional reason that I have thought of why we may want something
> other than just alg to distinguish between the types is to that it would
not be
> > Of Mike Jones
> > Of Sean Turner
reference.

---

From: Mike Jones <[email-masked]>
Date: Wed, 30 May 2012 17:27:01 +0000

If you were encrypting with a pre-shared secret you'd have both "alg" and "enc" members to name the algorithms, even if the key was shared out of band.

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

And if I were enrcrypting with a pre-shared secret then I would no alg but an enc?

> To: Jim Schaad; 'Manger, James H'; 'Sean Turner'; 'Vladimir Dzhuvinov 
> / NimbusDS'
> Cc: [email-masked]
> 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:
> 
> 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
> 
not be
> > signed/MACed mode -- reusing the same fields, but with dummy or 
> > blank values; providing completely different security; not mentioned 
> > in the JWS abstract; only appearing in an appendix (A.4. Example 
> > Plaintext JWS);
> without
> > encrypted JWx messages. Even it that mechanism remains though, I 
> > would like plaintext mode to be a "first-class citizen". The fact 
> > that plaintext
> mode is
> > top-level JOSE structure that can hold any of these 3 forms of data 
> > -- and is the
> JOSE
> > place to specify the top-level JOSE structure (so it is done 
> > awkwardly in the OAuth JWT spec). We could add two more JOSE specs: 
> > JWP (plain/unprotected
> > data) and JOSE (top-level structure = {JWS|JWE|JWP}). I think a 
> > better approach would be to (re-)combine JWS and JWE. The combined 
> > spec
> would
> > For what it's worth, "alg":"none" was moved from JWT to JWS based 
> > upon Jim Schaad's suggestion in http://www.ietf.org/mail- 
> > >> Just make sure to explain what it means when alg is omitted. 
> > >> Assume this would apply equally to both JSW and JWE?
> > >>
> > >> spt
> > >
> > > originally introduced. Therefore, the case of a missing "alg" 
> > > should fall outside the scope of the JWS and JWE specs.
> >
reference.
> > plaintext JWS then it's worth saying how empty would be handled - 
> > and then you can avoid the reference.
> >
> > spt
> >
> >
> >

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 31 May 2012 10:17:28 +1000

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

				-- Mike

---

From: Mike Jones <[email-masked]>
Date: Thu, 31 May 2012 00:21:52 +0000

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).

				-- Mike

-----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