Subject: [jose] FOR WG DISCUSSION: #103: Rename "alg" to avoid future collision problems

From: Mike Jones <[email-masked]>
Date: Fri, 23 Aug 2013 16:26:14 +0000

Dear WG.  While going through the open issues that have been filed, I plan to highlight proposed changes that I believe warrant WG discussion before action.  This is the first of those issues.

Please initiate discussion on the proposal to rename "alg" to "int" in JWS.  My personal view is already stated below.

				Thank you,
				-- Mike

-----Original Message-----
From: jose issue tracker [mailto:[email-masked]] 
Sent: Friday, August 23, 2013 9:22 AM
To: [email-masked]; Mike Jones
Cc: [email-masked]
Subject: Re: [jose] #103: Rename "alg" to avoid future collision problems

#103: Rename "alg" to avoid future collision problems

Comment (by [email-masked]):

 Renaming "alg" to "int" would be a breaking change for every JWS and every  JWT, with no commensurate benefit.

 The premise of this pre-supposes reopening the already (twice!) decided  issue #2 (No key management for MAC).  Given that the working group has  already decided not to do this, it should be up to those proposing this as  future work to propose syntax for this new feature at that time in a way  that doesn't break what already exists.  We certainly shouldn't make  breaking changes now for an eventuality that may never occur.

-- 
-------------------------+----------------------------------------------
-------------------------+---
 Reporter:               |       Owner:  draft-ietf-jose-json-web-
  [email-masked] |  [email-masked]
     Type:  defect       |      Status:  new
 Priority:  major        |   Milestone:
Component:  json-web-    |     Version:
  signature              |  Resolution:
 Severity:  -            |
 Keywords:               |
-------------------------+----------------------------------------------
-------------------------+---

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/103#comment:1>
jose <http://tools.ietf.org/jose/>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 23 Aug 2013 12:52:50 -0400

I find the current use of "alg" horrendously inconsistent and dirty.  In
JWS, it's the algorithm used to process the content.  In JWE, it's the key
management algorithm, and "enc" is used to process the content.

Any idea of "symmetry" between JWE and JWS on this basis is illusory and
unnecessary in any case.

But all that griping aside, I don't see a compelling reason to change it.

On Fri, Aug 23, 2013 at 12:26 PM, Mike Jones <[email-masked]>wrote:

> Dear WG.  While going through the open issues that have been filed, I plan
> to highlight proposed changes that I believe warrant WG discussion before
> action.  This is the first of those issues.
>
> Please initiate discussion on the proposal to rename "alg" to "int" in
> JWS.  My personal view is already stated below.
>
>                                 Thank you,
>                                 -- Mike
>
>  The premise of this pre-supposes reopening the already (twice!) decided
>  issue #2 (No key management for MAC).  Given that the working group has
>  already decided not to do this, it should be up to those proposing this as
>  future work to propose syntax for this new feature at that time in a way
>  that doesn't break what already exists.  We certainly shouldn't make
>  breaking changes now for an eventuality that may never occur.
>
> --
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 23 Aug 2013 16:19:59 -0400

Renaming it doesn't make any sense to me, and the reasons given are 
conjecture at best. Leave it as is.

  -- Justin

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 26 Aug 2013 06:55:07 -0700

My understanding of the resolution of issue #2 is that we are not going to
do this in the first version of the specification.  I am not asking in this
item to define the necessary pieces to do the work of allowing for key
management to occur in this version.  Rather I am asking for a field to be
re-named so that when the future specification appears, it will be sensibly
written.  The odds that this work will done in the future is bordering on a
certainty.  This is a glaring hole in the current set of capabilities in the
document set and we have  use cases that discuss this capability.  This is
one of the more sensible ways to deal with the entire security issues of
"Don't use a shared key for a lot of operations."  

The current template documentation has the following text:

The same   Header Parameter Name MAY be registered multiple times, provided
that
 the parameter usage is compatible between the specifications.

However, this would not be doable for a key management header name because
it would not be consistent between the JWE and JWS objects.  In one case it
would be alg and in the other case it would be new header name.

It is also not clear that the current definition uses alg in a compatible
way between the two specifications.  For JWS, this is the algorithm that
processes the content.  For JWE, this is the key management algorithm.  The
algorithm that processes the content is placed in enc.

Allowing for the same code to be used to process the key management sections
of the two documents is highly useful and should not be underestimated.   I
understand that this is a significant hit for the existing code base, but
they would have some time that both could be looked at until the new key
management work for JWS would be rolled out.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Mike Jones
> Sent: Friday, August 23, 2013 9:26 AM
> To: [email-masked]
> Subject: [jose] FOR WG DISCUSSION: #103: Rename "alg" to avoid future
> collision problems
> 
to
> highlight proposed changes that I believe warrant WG discussion before
JWS.  My
> personal view is already stated below.
> 
> 				Thank you,
> 				-- Mike
> 
>  Renaming "alg" to "int" would be a breaking change for every JWS and
every
> JWT, with no commensurate benefit.
> 
that
> doesn't break what already exists.  We certainly shouldn't make  breaking
> changes now for an eventuality that may never occur.
> 
> --

---

From: Mike Jones <[email-masked]>
Date: Mon, 26 Aug 2013 17:24:26 +0000

It's my assumption that in the hypothetical hybrid objects you're describing, in which a key is encrypted and then used for a signature or MAC calculation, the same key encryption "alg" values would be used as used in JWE and integrity algorithm would specified using a new parameter.  This could be called "int" if the WG chooses.  All of this could be done in the future without making any breaking changes, as described above.

The fact that the integrity algorithm parameter would be called something other than "alg" for this hybrid case isn't an impediment to implementations, and in fact, one could argue that it's a feature.  Not all JWS "alg" values could be used as "int" values - the symmetric algorithms like HS256 could - the asymmetric algorithms like ES256 couldn't.  The algorithms registry would be extended to support a new use value "int" to register those algorithms that can be used for integrity in this case.  No problem.

This use case can be cleanly supported without a breaking change.  We therefore should not make this change, as it would provide no practical benefit and has a clear and significant downside.

				-- Mike

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Monday, August 26, 2013 6:55 AM
To: Mike Jones; [email-masked]
Subject: RE: [jose] FOR WG DISCUSSION: #103: Rename "alg" to avoid future collision problems

My understanding of the resolution of issue #2 is that we are not going to do this in the first version of the specification.  I am not asking in this item to define the necessary pieces to do the work of allowing for key management to occur in this version.  Rather I am asking for a field to be re-named so that when the future specification appears, it will be sensibly written.  The odds that this work will done in the future is bordering on a certainty.  This is a glaring hole in the current set of capabilities in the document set and we have  use cases that discuss this capability.  This is one of the more sensible ways to deal with the entire security issues of "Don't use a shared key for a lot of operations."  

However, this would not be doable for a key management header name because it would not be consistent between the JWE and JWS objects.  In one case it would be alg and in the other case it would be new header name.

It is also not clear that the current definition uses alg in a compatible way between the two specifications.  For JWS, this is the algorithm that processes the content.  For JWE, this is the key management algorithm.  The algorithm that processes the content is placed in enc.

Allowing for the same code to be used to process the key management sections
of the two documents is highly useful and should not be underestimated.   I
understand that this is a significant hit for the existing code base, but they would have some time that both could be looked at until the new key management work for JWS would be rolled out.

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Mike Jones
to
JWS.  My
every
>  The premise of this pre-supposes reopening the already (twice!) 
> decided issue #2 (No key management for MAC).  Given that the working 
> group has already decided not to do this, it should be up to those 
> proposing this as future work to propose syntax for this new feature 
> at that time in a way
that
> doesn't break what already exists.  We certainly shouldn't make  
> -------------------------+--------------------------------------------
> -------------------------+--
> -------------------------+--------------------------------------------
> -------------------------+--
> Ticket URL: 
> <http://trac.tools.ietf.org/wg/jose/trac/ticket/103#comment:1>

---

From: Tim Bray <[email-masked]>
Date: Mon, 26 Aug 2013 10:46:21 -0700

What Mike said. It would require a huge, heal-a-bleeding-neck-wound benefit
to even thinking about breaking the deployed universe of JWT producers and
consumers, and this doesn’t feel like it comes close. -T

On Mon, Aug 26, 2013 at 10:24 AM, Mike Jones <[email-masked]>wrote:

> It's my assumption that in the hypothetical hybrid objects you're
> describing, in which a key is encrypted and then used for a signature or
> MAC calculation, the same key encryption "alg" values would be used as used
> in JWE and integrity algorithm would specified using a new parameter.  This
> could be called "int" if the WG chooses.  All of this could be done in the
> future without making any breaking changes, as described above.
>
> The fact that the integrity algorithm parameter would be called something
> other than "alg" for this hybrid case isn't an impediment to
> implementations, and in fact, one could argue that it's a feature.  Not all
> JWS "alg" values could be used as "int" values - the symmetric algorithms
> like HS256 could - the asymmetric algorithms like ES256 couldn't.  The
> algorithms registry would be extended to support a new use value "int" to
> register those algorithms that can be used for integrity in this case.  No
> problem.
>
> This use case can be cleanly supported without a breaking change.  We
> therefore should not make this change, as it would provide no practical
> benefit and has a clear and significant downside.
>
>                                 -- Mike
>
> certainty.  This is a glaring hole in the current set of capabilities in
> the document set and we have  use cases that discuss this capability.  This
> is one of the more sensible ways to deal with the entire security issues of

---

From: John Bradley <[email-masked]>
Date: Mon, 26 Aug 2013 13:51:19 -0400

+1

On 2013-08-26, at 1:46 PM, Tim Bray <[email-masked]> wrote:

> What Mike said. It would require a huge, heal-a-bleeding-neck-wound benefit to even thinking about breaking the deployed universe of JWT producers and consumers, and this doesn’t feel like it comes close. -T
> 
> 
> On Mon, Aug 26, 2013 at 10:24 AM, Mike Jones <[email-masked]> wrote:

---

From: Matias Woloski <[email-masked]>
Date: Mon, 26 Aug 2013 15:15:08 -0300

+1

tons of libraries already using "alg" out there. Please don't do it.

On Mon, Aug 26, 2013 at 2:46 PM, Tim Bray <[email-masked]> wrote:

> What Mike said. It would require a huge, heal-a-bleeding-neck-wound
> benefit to even thinking about breaking the deployed universe of JWT
> producers and consumers, and this doesn’t feel like it comes close. -T
>
>
>> My understanding of the resolution of issue #2 is that we are not going
>> to do this in the first version of the specification.  I am not asking in
>> this item to define the necessary pieces to do the work of allowing for key
>> However, this would not be doable for a key management header name
>> because it would not be consistent between the JWE and JWS objects.  In one
>> case it would be alg and in the other case it would be new header name.
>>

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 27 Aug 2013 08:12:47 +0900

+1. From Cost/Benefit perspective, I do not find the proposal attractive.

2013/8/27 Matias Woloski <[email-masked]>

>> On Mon, Aug 26, 2013 at 10:24 AM, Mike Jones <[email-masked]
>> > wrote:
>>
>>> The fact that the integrity algorithm parameter would be called
>>> something other than "alg" for this hybrid case isn't an impediment to
>>> It is also not clear that the current definition uses alg in a
>>> compatible way between the two specifications.  For JWS, this is the
>>> algorithm that processes the content.  For JWE, this is the key management
>>> algorithm.  The algorithm that processes the content is placed in enc.
>>>
>>> understand that this is a significant hit for the existing code base,
>>> but they would have some time that both could be looked at until the new
>>> key management work for JWS would be rolled out.
>>>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 27 Aug 2013 10:50:07 +1000

> describing, in which a key is encrypted and then used for a signature
> or MAC calculation, the same key encryption "alg" values would be used
> as used in JWE and integrity algorithm would specified using a new
> parameter.  This could be called "int" if the WG chooses.  All of this
> could be done in the future without making any breaking changes, as
> described above.
> 
> implementations, and in fact, one could argue that it's a feature.  Not
> all JWS "alg" values could be used as "int" values - the symmetric
> algorithms like HS256 could - the asymmetric algorithms like ES256
> couldn't.  The algorithms registry would be extended to support a new
> use value "int" to register those algorithms that can be used for
> integrity in this case.  No problem.
> 

I suspect that would break things. The 4 ways offered for distinguishing a JWE and JWS would no longer work [JWE section 8] -- they would give inconsistent answers. Some code looking at a JOSE message would incorrectly assume the content had confidentiality protection when it only had authenticity protection.

Perhaps we would need extra hacks like "enc":"none" along with "alg" identifying the key exchange and "int" identifying a MAC algorithm. I wonder if we would need a "crit" value as well?

The overloaded hacks with "alg", 4 options for distinguishing JWE/JWS, and wonky "crit" field are going to make it very hard to guess how implementations will react when new features are considered.

--
James Manger

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 27 Aug 2013 09:58:01 -0700

Such an approach would fail some of the current JWE/JWS selection code as
the same alg value would be used for both JWS and JWE objects.

> Sent: Monday, August 26, 2013 10:24 AM
> To: Jim Schaad; [email-masked]
> Subject: Re: [jose] FOR WG DISCUSSION: #103: Rename "alg" to avoid
> future collision problems
> 
describing,
> in which a key is encrypted and then used for a signature or MAC
calculation,
> the same key encryption "alg" values would be used as used in JWE and
> integrity algorithm would specified using a new parameter.  This could be
> called "int" if the WG chooses.  All of this could be done in the future
> without making any breaking changes, as described above.
> 
all
> My understanding of the resolution of issue #2 is that we are not going to
do
> this in the first version of the specification.  I am not asking in this
item to
> define the necessary pieces to do the work of allowing for key management
> to occur in this version.  Rather I am asking for a field to be re-named
so
> that when the future specification appears, it will be sensibly written.
The
> odds that this work will done in the future is bordering on a certainty.
This is
> a glaring hole in the current set of capabilities in the document set and
we
> have  use cases that discuss this capability.  This is one of the more
sensible
> ways to deal with the entire security issues of "Don't use a shared key
for a
> lot of operations."
> because it would not be consistent between the JWE and JWS objects.  In
> one case it would be alg and in the other case it would be new header
> name.
> 
way
> between the two specifications.  For JWS, this is the algorithm that
they
> would have some time that both could be looked at until the new key

---

From: Mike Jones <[email-masked]>
Date: Tue, 27 Aug 2013 17:15:43 +0000

At that point, implementations supporting the additional hybrid object type (half-encrypted, half-MAC) would need to revise their code.  That's true regardless of the parameter naming.

You haven't demonstrated any compelling value justifying breaking every deployed JWS and JWT and it's been demonstrated that this can be done in a non-breaking way.  Are you willing with withdraw this proposal?

				-- Mike

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Tuesday, August 27, 2013 9:58 AM
To: Mike Jones; [email-masked]
Subject: RE: [jose] FOR WG DISCUSSION: #103: Rename "alg" to avoid future collision problems

Such an approach would fail some of the current JWE/JWS selection code as the same alg value would be used for both JWS and JWE objects.

describing,
calculation,
> integrity algorithm would specified using a new parameter.  This could 
> be called "int" if the WG chooses.  All of this could be done in the 
all
> JWS "alg" values could be used as "int" values - the symmetric 
> therefore should not make this change, as it would provide no 
> practical benefit and has a clear and significant downside.
> 
> 				-- Mike
> 
do
item to
> define the necessary pieces to do the work of allowing for key 
> management to occur in this version.  Rather I am asking for a field 
> to be re-named
so
The
This is
we
sensible
for a
> because it would not be consistent between the JWE and JWS objects.  
> In one case it would be alg and in the other case it would be new 
> header name.
> 
> compatible
way
> Allowing for the same code to be used to process the key management 
> sections of the two documents is highly useful and should not be 
> underestimated.
I
> but
they
> > Subject: [jose] FOR WG DISCUSSION: #103: Rename "alg" to avoid 
> > highlight proposed changes that I believe warrant WG discussion 
> > before action.  This is the first of those issues.
> >
> > decided issue #2 (No key management for MAC).  Given that the 
> > working group has already decided not to do this, it should be up to 
> > those proposing this as future work to propose syntax for this new 
> > feature at that time in a way
> that
> > -------------------------+------------------------------------------
> > -------------------------+------------------------------------------

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 27 Aug 2013 17:24:35 +0000

I don't see that this proposed breaking change is really necessary, I don't see the rationale here. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Tuesday, August 27, 2013 9:58 AM
To: Mike Jones; [email-masked]
Subject: Re: [jose] FOR WG DISCUSSION: #103: Rename "alg" to avoid future collision problems

describing,
calculation,
all
do
item to
so
The
This is
we
sensible
for a
way
I
they

---

From: Richard Barnes <[email-masked]>
Date: Tue, 27 Aug 2013 13:42:01 -0400

On Tue, Aug 27, 2013 at 1:15 PM, Mike Jones <[email-masked]>wrote:

> At that point, implementations supporting the additional hybrid object
> type (half-encrypted, half-MAC) would need to revise their code.  That's
> true regardless of the parameter naming.
>

The problem that James pointed out is that *legacy* implementations would
also need to revise their code, or else they would do odd things (e.g.,
interpreting JWS as JWE) instead of failing cleanly.  That means that your
proposed design is not backward compatible and thus (IMO) not acceptable.

> You haven't demonstrated any compelling value justifying breaking every
> deployed JWS and JWT and it's been demonstrated that this can be done in a
> non-breaking way.  Are you willing with withdraw this proposal?
>

I think James and Jim have both demonstrated that your proposed
"non-breaking" way doesn't actually work.  Or at least, it breaks other
things.  So you need to do one of the following:
(1) Argue that key management for JWS will never be necessary
(2) Argue that a field other than "alg" should be used for the key
management algorithms in JWS (and say how this would work)
(3) Change the JWS "alg" field to something else

--Richard

---

From: Edmund Jay <[email-masked]>
Date: Tue, 27 Aug 2013 12:52:58 -0700 (PDT)

fwiw +1 for keeping 'alg' since key management hasn't been clearly defined and/or understood yet.

________________________________
 From: Matias Woloski <[email-masked]>
To: Tim Bray <[email-masked]> 
Cc: Mike Jones <[email-masked]>; Jim Schaad <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Monday, August 26, 2013 11:15 AM
Subject: Re: [jose] FOR WG DISCUSSION: #103: Rename "alg" to avoid future collision problems

+1

---

From: Richard Barnes <[email-masked]>
Date: Tue, 27 Aug 2013 17:58:39 -0400

It's not that mysterious.  Any of the key management modes for JWE could
just as well be used for JWS/MAC.  In the JSON syntax:

{
  "unprotected": { "alg": "A128KW", "int": "HS256" },
  "encrypted_key": "...",
  "payload": "...",
  "signature": "..."
}

I think we all know when we look at that object how it should be processed.
 You decrypt the "encrypted_key" value using AES-KW, then verify the MAC.

But as James and Jim have pointed out, you can't do that under the current
spec, because implementations will see "A128KW" and think it's a JWE.
 That's a bad, dirty failure instead of a nice clean one.

On Tue, Aug 27, 2013 at 3:52 PM, Edmund Jay <[email-masked]> wrote:

>   ------------------------------
>  *From:* Matias Woloski <[email-masked]>
> *To:* Tim Bray <[email-masked]>
> *Cc:* Mike Jones <[email-masked]>; Jim Schaad <
> [email-masked]>; "[email-masked]" <[email-masked]>
> *Sent:* Monday, August 26, 2013 11:15 AM
> *Subject:* Re: [jose] FOR WG DISCUSSION: #103: Rename "alg" to avoid
> sections

---

From: Mike Jones <[email-masked]>
Date: Tue, 27 Aug 2013 23:46:25 +0000

Yes, to support this new kind of object, legacy implementations would have to revise their code.  That would be true whether Jim's proposal was accepted or not, since they would have to be extended to recognize and process the new hybrid part-encrypted, part-MAC'ed objects.

Let's assume, for sake of discussion, that if a key encryption is every used with MAC'ed payloads, that the key encryption algorithm is represented by the same set of "alg" parameters as currently used by JWE and that the MAC algorithm is represented by an "int" parameter, using a subset of the algorithm identifiers used for JWS "alg" values.  Call this choice (4) (which is not any of your choices (1)-(3)).

Unmodified JWE implementations would safely reject such input, since it would use a JWE "alg" value but contain no "enc" value.  JWS implementations would likewise safely not process such input, as the "alg" value wouldn't be a JWS algorithm.  In both cases, no security problem arises - only rejection of unanticipated input.

Thus, this works fine, both for modified implementations that are extended to recognize and support this new kind of object, and for existing implementation that safely reject them as unrecognized input.

Summary:  Should such a hybrid part-encrypted part-MAC'ed object ever be created, it could be supported without any breaking changes to existing implementations.  Unmodified JWS and JWE implementations will safely reject this unrecognized input.  Modified implementations can recognize and process both legacy JWS and JWE inputs and new hybrid inputs.  Thus, there is no compelling case to modify what we have today.

I therefore request that Jim withdraw this issue, as no breaking change is required now or in the future to support this potential new functionality in the future.

                                                                -- Mike

From: Richard Barnes [mailto:[email-masked]]
Sent: Tuesday, August 27, 2013 10:42 AM
To: Mike Jones
Cc: Jim Schaad; [email-masked]
Subject: Re: [jose] FOR WG DISCUSSION: #103: Rename "alg" to avoid future collision problems

On Tue, Aug 27, 2013 at 1:15 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
At that point, implementations supporting the additional hybrid object type (half-encrypted, half-MAC) would need to revise their code.  That's true regardless of the parameter naming.

The problem that James pointed out is that *legacy* implementations would also need to revise their code, or else they would do odd things (e.g., interpreting JWS as JWE) instead of failing cleanly.  That means that your proposed design is not backward compatible and thus (IMO) not acceptable.

I think James and Jim have both demonstrated that your proposed "non-breaking" way doesn't actually work.  Or at least, it breaks other things.  So you need to do one of the following:
(1) Argue that key management for JWS will never be necessary
(2) Argue that a field other than "alg" should be used for the key management algorithms in JWS (and say how this would work)
(3) Change the JWS "alg" field to something else

--Richard

                                -- Mike

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, August 27, 2013 9:58 AM
To: Mike Jones; [email-masked]<mailto:[email-masked]>
Subject: RE: [jose] FOR WG DISCUSSION: #103: Rename "alg" to avoid future collision problems

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> Of Mike Jones
> To: Jim Schaad; [email-masked]<mailto:[email-masked]>
describing,
calculation,
all
> From: Jim Schaad [mailto:[email-masked]<mailto:[email-masked]>]
> To: Mike Jones; [email-masked]<mailto:[email-masked]>
do
item to
so
The
This is
we
sensible
for a
way
I
they
> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> > Of Mike Jones
> > To: [email-masked]<mailto:[email-masked]>
> > From: jose issue tracker [mailto:[email-masked]<mailto:[email-masked]>]
> > To: [email-masked]<mailto:[email-masked]>; Mike Jones
> > Cc: [email-masked]<mailto:[email-masked]>
> > Comment (by [email-masked]<mailto:[email-masked]>):
> >
> >   [email-masked]<mailto:[email-masked]> |  [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

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

---

From: Naveen Agarwal <[email-masked]>
Date: Tue, 27 Aug 2013 17:52:34 -0700

+1

I therefore request that Jim withdraw this issue, as no breaking change is
> required now or in the future to support this potential new functionality
> in the future.

On Tue, Aug 27, 2013 at 4:46 PM, Mike Jones <[email-masked]>wrote:

>  Yes, to support this new kind of object, legacy implementations would
> have to revise their code.  That would be true whether Jim’s proposal was
> accepted or not, since they would have to be extended to recognize and
> process the new hybrid part-encrypted, part-MAC’ed objects.****
>
> ** **
>
> Let’s assume, for sake of discussion, that if a key encryption is every
> used with MAC’ed payloads, that the key encryption algorithm is represented
> by the same set of “alg” parameters as currently used by JWE and that the
> MAC algorithm is represented by an “int” parameter, using a subset of the
> algorithm identifiers used for JWS “alg” values.  Call this choice (4)
> (which is not any of your choices (1)-(3)).****
>
> ** **
>
> Unmodified JWE implementations would safely reject such input, since it
> would use a JWE “alg” value but contain no “enc” value.  JWS
> implementations would likewise safely not process such input, as the “alg”
> value wouldn’t be a JWS algorithm.  In both cases, no security problem
> arises – only rejection of unanticipated input.****
>
> ** **
>
> Thus, this works fine, both for modified implementations that are extended
> to recognize and support this new kind of object, and for existing
> implementation that safely reject them as unrecognized input.****
>
> ** **
>
> Summary:  Should such a hybrid part-encrypted part-MAC’ed object ever be
> created, it could be supported without any breaking changes to existing
> implementations.  Unmodified JWS and JWE implementations will safely reject
> this unrecognized input.  Modified implementations can recognize and
> process both legacy JWS and JWE inputs and new hybrid inputs.  Thus, there
> is no compelling case to modify what we have today.****
>
> ** **
>
> I therefore request that Jim withdraw this issue, as no breaking change is
> required now or in the future to support this potential new functionality
> in the future.****
>
> ** **
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *From:* Richard Barnes [mailto:[email-masked]]
> *Sent:* Tuesday, August 27, 2013 10:42 AM
> *To:* Mike Jones
> *Cc:* Jim Schaad; [email-masked]
>
> future collision problems****
>
> ** **
>
> On Tue, Aug 27, 2013 at 1:15 PM, Mike Jones <[email-masked]>
> wrote:****
>
> true regardless of the parameter naming.****
>
>  ** **
>
> proposed design is not backward compatible and thus (IMO) not acceptable.*
> ***
>
> ** **
>
>  ****
>
> non-breaking way.  Are you willing with withdraw this proposal?****
>
>  ** **
>
> things.  So you need to do one of the following:****
>
> (1) Argue that key management for JWS will never be necessary****
>
> management algorithms in JWS (and say how this would work)****
>
> (3) Change the JWS "alg" field to something else****
>
> ** **
>
> --Richard****
>
> ** **
>
> ** **
>
>  ****
>
>
>                                 -- Mike
>
> From: Jim Schaad [mailto:[email-masked]]****
>
> > > -------------------------+------------------------------------------**
> **
>
> > > -------------------------+--****
>
> > > -------------------------+------------------------------------------**
> **
>
> > > -------------------------+--****
>
> https://www.ietf.org/mailman/listinfo/jose****
>
>  ** **
>

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 28 Aug 2013 11:48:35 +1000

> used with MAC’ed payloads, that the key encryption algorithm is
> represented by the same set of “alg” parameters as currently used by
> JWE and that the MAC algorithm is represented by an “int” parameter,
> using a subset of the algorithm identifiers used for JWS “alg” values.
> Call this choice (4) (which is not any of your choices (1)-(3)).

So the message could be:
  B64({"alg":"A128KW","int":"HS256",…}).B64(encrypted_key).B64(plaintext).B64(HMAC)

Recipient A uses the dot-counting method [JWE section 8, 1st option]; sees 4 segments; says "ERROR: unknown sort of JOSE message".

Recipient B uses the alg method [JWE section 8, 3rd option]; sees "A128KW"; so treats it as a JWE; fails to find "enc"; says "ERROR: invalid JWE as enc is missing".

Recipient C uses the enc method [JWE section 8, 4th option]; sees no "enc"; so treats it as a JWS; says "ERROR: JWS with unsupported signature algorithm A128KW".

Recipient D understands MAC-with-session-key; says "OK: valid MACed message".

A, B, and C haven't implemented MAC-with-session-key so obviously they are not expected to successfully fully process this new message. The fact that they fail for quite different reasons probably doesn't matter in most situations.

If these recipients were only filtering messages (eg ensuring all passing messages have confidentiality protection) then the difference between recipients might matter.

Consider a different message:
  B64({"alg":"A128KW","int":"HS256","enc":"A128GCM"…}).…

Who knows how recipients will react to this. It actually looks possible for a message like this to simultaneously be a valid encrypted message for recipients B & C, and a valid MACed message for recipient D -- each getting different content. Ouch!

This might be more relevant to issue #179 "Section 8 Distinguishing between JWS and JWE objects".

--
James Manger

---

From: George Fletcher <[email-masked]>
Date: Tue, 27 Aug 2013 22:47:26 -0400

+1

On 8/27/13 7:46 PM, Mike Jones wrote:
> have to revise their code.  That would be true whether Jim's proposal 
> was accepted or not, since they would have to be extended to recognize 
> and process the new hybrid part-encrypted, part-MAC'ed objects.
>
> Let's assume, for sake of discussion, that if a key encryption is 
> every used with MAC'ed payloads, that the key encryption algorithm is 
> represented by the same set of "alg" parameters as currently used by 
> JWE and that the MAC algorithm is represented by an "int" parameter, 
> using a subset of the algorithm identifiers used for JWS "alg" 
> values.  Call this choice (4) (which is not any of your choices (1)-(3)).
>
> Unmodified JWE implementations would safely reject such input, since 
> it would use a JWE "alg" value but contain no "enc" value.  JWS 
> implementations would likewise safely not process such input, as the 
> "alg" value wouldn't be a JWS algorithm.  In both cases, no security 
> problem arises -- only rejection of unanticipated input.
>
> Thus, this works fine, both for modified implementations that are 
> extended to recognize and support this new kind of object, and for 
> existing implementation that safely reject them as unrecognized input.
>
> Summary: Should such a hybrid part-encrypted part-MAC'ed object ever 
> be created, it could be supported without any breaking changes to 
> existing implementations.  Unmodified JWS and JWE implementations will 
> safely reject this unrecognized input. Modified implementations can 
> recognize and process both legacy JWS and JWE inputs and new hybrid 
> inputs.  Thus, there is no compelling case to modify what we have today.
>
> I therefore request that Jim withdraw this issue, as no breaking 
> change is required now or in the future to support this potential new 
> functionality in the future.
>
> -- Mike
>
> *From:*Richard Barnes [mailto:[email-masked]]
> On Tue, Aug 27, 2013 at 1:15 PM, Mike Jones 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     At that point, implementations supporting the additional hybrid
>     object type (half-encrypted, half-MAC) would need to revise their
>     code.  That's true regardless of the parameter naming.
>
> The problem that James pointed out is that *legacy* implementations 
> would also need to revise their code, or else they would do odd things 
> (e.g., interpreting JWS as JWE) instead of failing cleanly.  That 
> means that your proposed design is not backward compatible and thus 
> (IMO) not acceptable.
>
>     You haven't demonstrated any compelling value justifying breaking
>     every deployed JWS and JWT and it's been demonstrated that this
>     can be done in a non-breaking way.  Are you willing with withdraw
>     this proposal?
>
> "non-breaking" way doesn't actually work.  Or at least, it breaks 
> other things.  So you need to do one of the following:
>
>     To: Mike Jones; [email-masked] <mailto:[email-masked]>
>     Such an approach would fail some of the current JWE/JWS selection
>     code as the same alg value would be used for both JWS and JWE objects.
>
>
>     > From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     Behalf
>     > Of Mike Jones
>     > To: Jim Schaad; [email-masked] <mailto:[email-masked]>
>     > To: Mike Jones; [email-masked] <mailto:[email-masked]>
>     > a glaring hole in the current set of capabilities in the
>     document set
>     > and
>     we
>     > processes the content.  For JWE, this is the key management
>     algorithm.
>     The
>     > > From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     Behalf
>     > > Of Mike Jones
>     > > To: [email-masked] <mailto:[email-masked]>
>     > > Dear WG.  While going through the open issues that have been
>     filed,
>     > > I plan
>     > to
>     > > Please initiate discussion on the proposal to rename "alg" to
>     "int"
>     > > in
>     > JWS.  My
>     > > From: jose issue tracker [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     > > To: [email-masked]
>     <mailto:[email-masked]>; Mike Jones
>     > > Cc: [email-masked] <mailto:[email-masked]>
>     > > [email-masked] <mailto:[email-masked]> |
>     [email-masked] <mailto:[email-masked]>
>     > > [email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

-- 
George Fletcher <http://connect.me/gffletch>