Subject: [jose] Stephen Farrell's Discuss on draft-ietf-jose-jws-signing-input-options-08: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 17 Dec 2015 03:20:25 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-jose-jws-signing-input-options-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-jose-jws-signing-input-options/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The "crit" point raised in the gen-art review and maybe elsewhere
is I think correct but I don't think section 6 of -08 is a good
resolution of this topic. However, I'll clear if this is the WG
consensus but it's hard to know that's the case for text just
added yesterday. To resolve this discuss we just need to see what
the WG list says about the new text.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- abstract: the description of the update to 7519 is odd. It
seems to be saying "Here we define a thing. This specification
updates 7519 to say you must not use this thing." but prohibiting
is an odd verb to use there. (Since it wasn't previously there to
be allowed or not.)

- section 6: "It is intended that application profiles specify up
front whether" "intended" is very wishy washy and "up front"
makes no sense at all.

---

From: Mike Jones <[email-masked]>
Date: Thu, 17 Dec 2015 13:20:27 +0000

Thanks for your review, Stephen.  Replies inline below...

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Thursday, December 17, 2015 12:20 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Mike Jones
> <[email-masked]>; Jim Schaad <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked]
> Subject: Stephen Farrell's Discuss on draft-ietf-jose-jws-signing-input-
> options-08: (with DISCUSS and COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> The "crit" point raised in the gen-art review and maybe elsewhere is I think
> correct but I don't think section 6 of -08 is a good resolution of this topic.
> However, I'll clear if this is the WG consensus but it's hard to know that's the
> case for text just added yesterday. To resolve this discuss we just need to see
> what the WG list says about the new text.

Jim's shepherd write-up at https://datatracker.ietf.org/doc/draft-ietf-jose-jws-signing-input-options/shepherdwriteup/ records the working group's desire to not require the use of "crit" when it isn't needed.  He wrote:

"(6)  The fact that there are two different versions of encoding that produce the same text string for signing is worrisome to me.  The WG had the ability to address this when producing the JWS specification and decided not to do so that time.  In this document, the desire to allow for things to be smaller has lead to the fact that the b64 and crit headers can be omitted as being implicit.  This was the desire of the WG, but I personally feel that it is the wrong decision."

> - abstract: the description of the update to 7519 is odd. It seems to be saying
> "Here we define a thing. This specification updates 7519 to say you must not
> use this thing." but prohibiting is an odd verb to use there. (Since it wasn't
> previously there to be allowed or not.)

Would you like this text better?

"This specification updates RFC 7519 by stating that JSON Web Tokens (JWTs) MUST NOT use the unencoded payload option defined by this specification."

Or do you think this spec doesn't need to have the "Updates 7519" clause at all?  People seemed split on whether this was needed or not.

> - section 6: "It is intended that application profiles specify up front whether"
> "intended" is very wishy washy and "up front"
> makes no sense at all.

How about this wording change?
"It is intended that application profiles specify up front whether" -> "Application profiles should specify whether"

				Thanks again,
				-- Mike

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 17 Dec 2015 13:31:37 +0000

Hiya,

On 17/12/15 13:20, Mike Jones wrote:
>> -----Original Message----- From: Stephen Farrell
>> [mailto:[email-masked]] Sent: Thursday, December 17,
>> 2015 12:20 PM To: The IESG <[email-masked]> Cc:
>> [email-masked]; Mike Jones 
>> <[email-masked]>; Jim Schaad
>> <[email-masked]>; [email-masked];
>> [email-masked]; [email-masked] Subject: Stephen Farrell's
>> Discuss on draft-ietf-jose-jws-signing-input- options-08: (with
>> DISCUSS and COMMENT)
>> 
>> When responding, please keep the subject line intact and reply to
>> all email addresses included in the To and CC lines. (Feel free to
>> cut this introductory paragraph, however.)
>> 
>> 
>> Please refer to
>> https://www.ietf.org/iesg/statement/discuss-criteria.html for more
>> information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> correct but I don't think section 6 of -08 is a good resolution of
>> this topic. However, I'll clear if this is the WG consensus but
>> it's hard to know that's the case for text just added yesterday. To
>> resolve this discuss we just need to see what the WG list says
>> about the new text.
> 
> Jim's shepherd write-up at
> https://datatracker.ietf.org/doc/draft-ietf-jose-jws-signing-input-options/shepherdwriteup/
> records the working group's desire to not require the use of "crit"
> when it isn't needed.  He wrote:
> 
> "(6)  The fact that there are two different versions of encoding that
> produce the same text string for signing is worrisome to me.  The WG
> had the ability to address this when producing the JWS specification
> and decided not to do so that time.  In this document, the desire to
> allow for things to be smaller has lead to the fact that the b64 and
> crit headers can be omitted as being implicit.  This was the desire
> of the WG, but I personally feel that it is the wrong decision."

Fair enough, so the chair/shepherd, gen-art reviewer and seems like
a few IESG members all find the current position unconvincing as
does the one implementer who posted to the WG list since the new
text was added. Wouldn't you agree there's enough there to justify
asking the WG once more what they think about that 13 byte overhead
to prevent interop and maybe even security problems?

- abstract: the description of the update to 7519 is odd. It seems to be
saying
>> "Here we define a thing. This specification updates 7519 to say you
>> must not use this thing." but prohibiting is an odd verb to use
>> there. (Since it wasn't previously there to be allowed or not.)
> 
> "This specification updates RFC 7519 by stating that JSON Web Tokens
> (JWTs) MUST NOT use the unencoded payload option defined by this
> specification."

Better yep. Thanks.

> 
> Or do you think this spec doesn't need to have the "Updates 7519"
> clause at all?  People seemed split on whether this was needed or
> not.

Happens all the time. Personally I mostly don't care about updates
which is the case this time too:-)

>> front whether" "intended" is very wishy washy and "up front" makes
>> no sense at all.
> 
> How about this wording change? "It is intended that application
> profiles specify up front whether" -> "Application profiles should
> specify whether"

Also better,
Ta,
S.

> Thanks again, -- Mike

---

From: Mike Jones <[email-masked]>
Date: Thu, 17 Dec 2015 13:44:55 +0000

Sure, I'm obviously fine asking the working group what they think of the new text.  Working group - this new text at https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-08#section-6 is:

   6.  Using "crit" with "b64"

   If a JWS using "b64" with a value of "false" might be processed by
   implementations not implementing this extension, then the "crit"
   Header Parameter MUST be included with "b64" in its set of values to
   cause such implementations to reject the JWS.  Conversely, if used in
   environments in which all participants implement this extension, then
   "crit" need not be included, since its inclusion would have no
   effect, other than increasing the JWS size and processing costs.

				Thanks all,
				-- Mike

> Sent: Thursday, December 17, 2015 2:32 PM
> To: Mike Jones <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; draft-ietf-jose-jws-signing-
> [email-masked]; [email-masked]
> Subject: Re: Stephen Farrell's Discuss on draft-ietf-jose-jws-signing-input-
> >> [email-masked]; [email-masked]; [email-masked] Subject:
> >> Stephen Farrell's Discuss on draft-ietf-jose-jws-signing-input-
> >> email addresses included in the To and CC lines. (Feel free to cut
> >> this introductory paragraph, however.)
> >>
> >>
> >> Please refer to
> >> this topic. However, I'll clear if this is the WG consensus but it's
> >> hard to know that's the case for text just added yesterday. To
> >> resolve this discuss we just need to see what the WG list says about
> >> the new text.
> >
> > https://datatracker.ietf.org/doc/draft-ietf-jose-jws-signing-input-opt
> > ions/shepherdwriteup/ records the working group's desire to not
> > require the use of "crit"
> > crit headers can be omitted as being implicit.  This was the desire of
> > the WG, but I personally feel that it is the wrong decision."
> 
> Fair enough, so the chair/shepherd, gen-art reviewer and seems like a few
> IESG members all find the current position unconvincing as does the one
> implementer who posted to the WG list since the new text was added.
> Wouldn't you agree there's enough there to justify asking the WG once more
> what they think about that 13 byte overhead to prevent interop and maybe
> even security problems?
> 
> >
> > clause at all?  People seemed split on whether this was needed or not.
> 
> Happens all the time. Personally I mostly don't care about updates which is
> the case this time too:-)
> 
> >
> >> front whether" "intended" is very wishy washy and "up front" makes no
> >> sense at all.
> >

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 17 Dec 2015 13:48:49 +0000

Great. For completeness, the alternative proposed by James Manger
(which I'd also prefer) was:

   The "crit" Header Parameter MUST be included with "b64" in its set
   of values to ensure the JWS is rejected (instead of being
   misinterpreted) by implementations that do not understand this
   specification.

My discuss then is asking if, after all this discussion, the WG
prefer the above or that below. I'll take the WG chairs word on what
they conclude as the outcome.

S.

On 17/12/15 13:44, Mike Jones wrote:
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

---

From: John Bradley <[email-masked]>
Date: Thu, 17 Dec 2015 15:04:29 +0100

I prefer making crit only required if the producer is not certain that all potential recipients understand/the extension.

However it would not be the end of the world for me from a size perspective if crit was always required.  Trading 6 octets for saving 1/4 of the body size is not a bad trade off.

The issue for me is more always requiring something to be sent that is known to not be used.

So I am on the not forcing crit side but could live with the consensus if it goes the other way.

John B.

> On Dec 17, 2015, at 2:48 PM, Stephen Farrell <[email-masked]> wrote:
> 
>

---

From: John Bradley <[email-masked]>
Date: Thu, 17 Dec 2015 15:32:40 +0100

Sorry I just recounted, it is a extra 20 bytes per message with the encoded header and not 6.

That is a bit more but probably not worth dying over.   I still prefer the smaller option.

John B.

> On Dec 17, 2015, at 3:04 PM, John Bradley <[email-masked]> wrote:
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 17 Dec 2015 10:39:25 -0500

> That is a bit more but probably not worth dying over.   I still prefer the smaller option.

If we could get to a consensus on this and which text is preferred,
that would be helpful.

Thanks!
Kathleen

-- 

Best regards,
Kathleen

---

From: John Bradley <[email-masked]>
Date: Thu, 17 Dec 2015 17:16:00 +0100

One additional requirement that I would like to add to Mikes text is that if the signer is signing any sort of external content then it MUST include crit.

If the sender is bad then it doesn’t need to confuse the client and is going to do what it wants with including crit anyway.

If the sender is good it won’t attack itself unless you can get it to sign external content.

I can see an attack where the attacker provides the signer with external content that has a bad part that is base64 encoded and a unencoded part, the signer might verify the unencoded part, and the base64 decoding at the receiver decode the base64 and discard the unencoded portion leaving only the bad part of the message.

So I on consideration I strongly prefer any signing over external content to include crit.

John B.

> On Dec 17, 2015, at 4:39 PM, Kathleen Moriarty <[email-masked]> wrote:
>

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Thu, 17 Dec 2015 17:19:06 +0000

I prefer James' proposed text.  I believe this draft came about primarily because there are use cases where the content to sign is large enough that the burden of base64url encoding is too great.  By that measure, I'm not sure how worthwhile size-of-header arguments are, as content so large that base64url might be prohibitive would dwarf the concerns around header size.  I think the risk of bad verifies outweighs the reduced-headher-size benefits.

--
- m&m

Matt Miller
Cisco Systems, Inc.

> On Dec 17, 2015, at 08:39, Kathleen Moriarty <[email-masked]> wrote:
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 17 Dec 2015 12:42:32 -0500

I prefer Jame’s proposal as well.

 — Justin

> On Dec 17, 2015, at 12:19 PM, Matt Miller (mamille2) <[email-masked]> wrote:
>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Sun, 20 Dec 2015 18:13:39 +0200

I read the entire discussion and my opinion is that "b64" must be
explicitly stated as a critical parameter in "crit".

Here is what JWS (RFC 7515), the parent spec of
draft-ietf-jose-jws-signing-input-options, says about "crit":

http://tools.ietf.org/html/rfc7515#section-4.1.11

   The "crit" (critical) Header Parameter indicates that extensions to
   this specification and/or [JWA <http://tools.ietf.org/html/rfc7515#ref-JWA>] are being used that MUST be
   understood and processed.  Its value is an array listing the Header
   Parameter names present in the JOSE Header that use those extensions.

Not marking "b64" as a critical parameter breaks the general contract of
the JWS framework. Signing input options is an extension, and
understanding "b64":false is critical to processing the JWS correctly.

There is an argument that parties will have to understand "b64":false
anyhow in order to participate. But if we follow this line of thought,
then one could also argue that "b64":false in itself is redundant. I
don't think we should be setting such a precedent here with a spec that
inherits from base JWS. I mean a precedent for future JWS extensions.

Another argument for "crit":

I help maintain one of the libraries for JOSE. Developers often reuse
code, or put existing code to uses that weren't originally intended.
Also, because of tight schedules and other pressures, security
considerations are not always given their proper due. Because base JWS
is already mainstream, and signing input options isn't yet, I imagine a
lot of developers will take existing code and try to apply it for
signing-input options. Having "b64" marked as "crit" will make it easier
to trigger the correct behaviour for an extension such as this one, and
not lead to other unexpected exceptions if unencoded payloads are fed by
mistake into a verifier where such are not expected. Having said that, I
also suspect there are libraries which don't observe "crit" at all, so
this is another argument for insisting on its usage.

Finally, I think section 8 - Security considerations - will become a lot
simpler and straightforward if "crit" is used.

Thanks,

Vladimir

-- 
Vladimir Dzhuvinov :: [email-masked]

---

From: <[email-masked]>
Date: Mon, 21 Dec 2015 14:26:54 +0100

I think that the larger a payload is the higher is the risk of a bad verify and that few extra bytes don't matter then.
And I follow Vladimir's argument to try to keep the security concideration section simpler.

So +1 to James proposed text.

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Matt Miller (mamille2)
Sent: Donnerstag, 17. Dezember 2015 18:19
To: Kathleen Moriarty; [email-masked]
Cc: [email-masked]; [email-masked]; Michael Jones; The IESG; John Bradley; Stephen Farrell; [email-masked]
Subject: Re: [jose] Stephen Farrell's Discuss on draft-ietf-jose-jws-signing-input-options-08: (with DISCUSS and COMMENT)

--
- m&m

Matt Miller
Cisco Systems, Inc.

>>>> prefer the above or that below. I'll take the WG chairs word on 
>>>> what they conclude as the outcome.
>>>> 
>>>> S.
>>>> 
>>>>> Header Parameter MUST be included with "b64" in its set of values 
>>>>> to cause such implementations to reject the JWS.  Conversely, if 
>>>>> used in environments in which all participants implement this 
>>>>> extension, then "crit" need not be included, since its inclusion 
>>>>> would have no effect, other than increasing the JWS size and processing costs.
>>>>> 
>>>>>                           Thanks all,
>>>>>                           -- Mike
>>>>> 
>>>>>> Cc: [email-masked]; [email-masked]; 
>>>>>> draft-ietf-jose-jws-signing- [email-masked]; 
>>>>>> [email-masked]
>>>>>>>> <[email-masked]>; [email-masked]; [email-masked]; [email-masked] Subject:
>>>>>>>> When responding, please keep the subject line intact and reply 
>>>>>>>> to all email addresses included in the To and CC lines. (Feel 
>>>>>>>> free to cut this introductory paragraph, however.)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Please refer to
>>>>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for 
>>>>>>>> more information about IESG DISCUSS and COMMENT positions.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-jose-jws-signing-in
>>>>>>>> put-op
>>>>>>>> tions/
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> ---------------------------------------------------------------
>>>>>>>> ------
>>>>>>>> -
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>> is I think
>>>>>>>> correct but I don't think section 6 of -08 is a good resolution 
>>>>>>>> of this topic. However, I'll clear if this is the WG consensus 
>>>>>>>> but it's hard to know that's the case for text just added 
>>>>>>>> yesterday. To resolve this discuss we just need to see what the 
>>>>>>>> WG list says about the new text.
>>>>>>> 
>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-jose-jws-signing-inp
>>>>>>> ut-opt ions/shepherdwriteup/ records the working group's desire 
>>>>>>> to not require the use of "crit"
>>>>>>> "(6)  The fact that there are two different versions of encoding 
>>>>>>> that produce the same text string for signing is worrisome to 
>>>>>>> me.  The WG had the ability to address this when producing the 
>>>>>>> JWS specification and decided not to do so that time.  In this 
>>>>>>> document, the desire to allow for things to be smaller has lead 
>>>>>>> to the fact that the b64 and crit headers can be omitted as 
>>>>>>> being implicit.  This was the desire of the WG, but I personally feel that it is the wrong decision."
>>>>>> 
>>>>>> Fair enough, so the chair/shepherd, gen-art reviewer and seems 
>>>>>> like a few IESG members all find the current position 
>>>>>> unconvincing as does the one implementer who posted to the WG list since the new text was added.
>>>>>> Wouldn't you agree there's enough there to justify asking the WG 
>>>>>> once more what they think about that 13 byte overhead to prevent 
>>>>>> interop and maybe even security problems?
>>>>>> 
>>>>>>> 
>>>>>>>> ---------------------------------------------------------------
>>>>>>>> ------
>>>>>>>> -
>>>>>>>> 
>>>>>>>> 
>>>>>> COMMENT:
>>>>>>>> ---------------------------------------------------------------
>>>>>>>> ------
>>>>>>>> -
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>> seems to be saying
>>>>>>>> "Here we define a thing. This specification updates 7519 to say 
>>>>>>>> you must not use this thing." but prohibiting is an odd verb to 
>>>>>>>> use there. (Since it wasn't previously there to be allowed or 
>>>>>>>> not.)
>>>>>>> 
>>>>>> Happens all the time. Personally I mostly don't care about 
>>>>>> updates which is the case this time too:-)
>>>>>> 
>>>>>>> 
>>>>>>>> - section 6: "It is intended that application profiles specify 
>>>>>>>> up front whether" "intended" is very wishy washy and "up front" 
>>>>>>>> makes no sense at all.
>>>>>>> 
>>>>>>> profiles specify up front whether" -> "Application profiles 
>>>>>>> should specify whether"
>>>>>> 
>>>>>> Also better,
>>>>>> Ta,
>>>>>> S.
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> Thanks again, -- Mike
>>>>>>>

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 21 Dec 2015 23:55:15 +0900

I also think it is better to make the b64 parameter critical. Being
deterministic makes the life of programmers simpler. It also decreases the
vulnerability surface. So +1 to James's text.

2015-12-21 22:26 GMT+09:00 <[email-masked]>:

> I think that the larger a payload is the higher is the risk of a bad
> verify and that few extra bytes don't matter then.
> Cc: [email-masked]; [email-masked]; Michael Jones; The
> IESG; John Bradley; Stephen Farrell;
> [email-masked]
> Subject: Re: [jose] Stephen Farrell's Discuss on
> draft-ietf-jose-jws-signing-input-options-08: (with DISCUSS and COMMENT)
>
> I prefer James' proposed text.  I believe this draft came about primarily
> because there are use cases where the content to sign is large enough that
> the burden of base64url encoding is too great.  By that measure, I'm not
> sure how worthwhile size-of-header arguments are, as content so large that
> base64url might be prohibitive would dwarf the concerns around header
> size.  I think the risk of bad verifies outweighs the reduced-headher-size
> benefits.
>
>
> --
> - m&m
>
> Matt Miller
> Cisco Systems, Inc.
>
> >>> I prefer making crit only required if the producer is not certain that
> all potential recipients understand/the extension.
> >>>
> >>> However it would not be the end of the world for me from a size
> perspective if crit was always required.  Trading 6 octets for saving 1/4
> of the body size is not a bad trade off.
> >>>
> >>>>> Sure, I'm obviously fine asking the working group what they think of
> the new text.  Working group - this new text at
> https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-08#section-6
> is:
> >>>>>
> [email-masked]; [email-masked] Subject:

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

---

From: Roland Hedberg <[email-masked]>
Date: Mon, 21 Dec 2015 16:46:18 +0000

+1

21 dec. 2015 kl. 15:55 skrev Nat Sakimura <[email-masked]<mailto:[email-masked]>>:

I also think it is better to make the b64 parameter critical. Being deterministic makes the life of programmers simpler. It also decreases the vulnerability surface. So +1 to James's text.

2015-12-21 22:26 GMT+09:00 <[email-masked]<mailto:[email-masked]>>:
I think that the larger a payload is the higher is the risk of a bad verify and that few extra bytes don't matter then.
And I follow Vladimir's argument to try to keep the security concideration section simpler.

-----Original Message-----
From: jose [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Matt Miller (mamille2)
Sent: Donnerstag, 17. Dezember 2015 18:19
To: Kathleen Moriarty; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Michael Jones; The IESG; John Bradley; Stephen Farrell; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Stephen Farrell's Discuss on draft-ietf-jose-jws-signing-input-options-08: (with DISCUSS and COMMENT)

--
- m&m

Matt Miller
Cisco Systems, Inc.

> On Dec 17, 2015, at 08:39, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:
>
> On Thu, Dec 17, 2015 at 9:32 AM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
>>> On Dec 17, 2015, at 3:04 PM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>> On Dec 17, 2015, at 2:48 PM, Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:
>>>>
>>>>
>>>>>> From: Stephen Farrell [mailto:[email-masked]<mailto:[email-masked]>]
>>>>>> To: Mike Jones <[email-masked]<mailto:[email-masked]>>; The IESG
>>>>>> <[email-masked]<mailto:[email-masked]>>
>>>>>> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
>>>>>> draft-ietf-jose-jws-signing- [email-masked]<mailto:[email-masked]>;
>>>>>> [email-masked]<mailto:[email-masked]>
>>>>>>>> [mailto:[email-masked]<mailto:[email-masked]>] Sent: Thursday, December 17,
>>>>>>>> 2015 12:20 PM To: The IESG <[email-masked]<mailto:[email-masked]>> Cc:
>>>>>>>> [email-masked]<mailto:[email-masked]>; Mike Jones
>>>>>>>> <[email-masked]<mailto:[email-masked]>>; Jim Schaad
>>>>>>>> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> Subject:
>>>>> [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

--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: "Preibisch, Sascha H" <[email-masked]>
Date: Mon, 21 Dec 2015 17:53:42 +0000

+1

From: jose <[email-masked]<mailto:[email-masked]>> on behalf of Roland Hedberg <[email-masked]<mailto:[email-masked]>>
Date: Monday, December 21, 2015 at 8:46 AM
To: Nat Sakimura <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Axel Nennker <[email-masked]<mailto:[email-masked]>>, Jim Schaad <[email-masked]<mailto:[email-masked]>>, Mike Jones <[email-masked]<mailto:[email-masked]>>, Kathleen Moriarty <[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]>>, Matthew Miller <[email-masked]<mailto:[email-masked]>>, John Bradley <[email-masked]<mailto:[email-masked]>>, The IESG <[email-masked]<mailto:[email-masked]>>, Stephen Farrell <[email-masked]<mailto:[email-masked]>>
Subject: Re: [jose] Stephen Farrell's Discuss on draft-ietf-jose-jws-signing-input-options-08: (with DISCUSS and COMMENT)

+1

-----Original Message-----
From: jose [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Matt Miller (mamille2)
Sent: Donnerstag, 17. Dezember 2015 18:19
To: Kathleen Moriarty; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Michael Jones; The IESG; John Bradley; Stephen Farrell; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Stephen Farrell's Discuss on draft-ietf-jose-jws-signing-input-options-08: (with DISCUSS and COMMENT)

--
- m&m

Matt Miller
Cisco Systems, Inc.

>>>>> Sure, I'm obviously fine asking the working group what they think of the new text.  Working group - this new text at https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-08#section-6<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Djose-2Djws-2Dsigning-2Dinput-2Doptions-2D08-23section-2D6&d=CwMFAg&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=tevYWz1lgHjtwlrld6RGUwDmuvlCuJw1Ryc17kjJxYc&m=rPr_MDrtA5TV8cVpReqg_XIkoWdGNUqptpRHwfzV3Nw&s=6h1ckn5Dg9eXWhm7uBzIv5nlfE0hRhBXnepM4VkYTF4&e=> is:
>>>>>
>>>>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=CwMFAg&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=tevYWz1lgHjtwlrld6RGUwDmuvlCuJw1Ryc17kjJxYc&m=rPr_MDrtA5TV8cVpReqg_XIkoWdGNUqptpRHwfzV3Nw&s=F-Oeeqy3nqyCXNTlMMsbDn0uum3p2s8B_C_bPHv-iWU&e=> for
>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-jose-jws-signing-in<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Djose-2Djws-2Dsigning-2Din&d=CwMFAg&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=tevYWz1lgHjtwlrld6RGUwDmuvlCuJw1Ryc17kjJxYc&m=rPr_MDrtA5TV8cVpReqg_XIkoWdGNUqptpRHwfzV3Nw&s=Ch214Lh2tm6Ix64rIOcKk79Za-NwaV61Nvq6pVT91Hk&e=>
>>>>>>>> put-op
>>>>>>>> tions/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-jose-jws-signing-inp<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Djose-2Djws-2Dsigning-2Dinp&d=CwMFAg&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=tevYWz1lgHjtwlrld6RGUwDmuvlCuJw1Ryc17kjJxYc&m=rPr_MDrtA5TV8cVpReqg_XIkoWdGNUqptpRHwfzV3Nw&s=_3qBc6exQH8Nd356HMWzlscgfNDHK0jEbj_cdpJtUXI&e=>
>>>>> https://www.ietf.org/mailman/listinfo/jose<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose&d=CwMFAg&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=tevYWz1lgHjtwlrld6RGUwDmuvlCuJw1Ryc17kjJxYc&m=rPr_MDrtA5TV8cVpReqg_XIkoWdGNUqptpRHwfzV3Nw&s=Qyndlk0bv0B8HTrwp6eO0l_J1-gyQihx8hClD34fnos&e=>
>>>>>
>>>>
>>>> https://www.ietf.org/mailman/listinfo/jose<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose&d=CwMFAg&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=tevYWz1lgHjtwlrld6RGUwDmuvlCuJw1Ryc17kjJxYc&m=rPr_MDrtA5TV8cVpReqg_XIkoWdGNUqptpRHwfzV3Nw&s=Qyndlk0bv0B8HTrwp6eO0l_J1-gyQihx8hClD34fnos&e=>
>>>
>>
>
>
>
> --
>
> Best regards,
> Kathleen

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose&d=CwMFAg&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=tevYWz1lgHjtwlrld6RGUwDmuvlCuJw1Ryc17kjJxYc&m=rPr_MDrtA5TV8cVpReqg_XIkoWdGNUqptpRHwfzV3Nw&s=Qyndlk0bv0B8HTrwp6eO0l_J1-gyQihx8hClD34fnos&e=>

--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/<https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=CwMFAg&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=tevYWz1lgHjtwlrld6RGUwDmuvlCuJw1Ryc17kjJxYc&m=rPr_MDrtA5TV8cVpReqg_XIkoWdGNUqptpRHwfzV3Nw&s=B1oKcaNgmP1aOC-WZgfxNIOlZoW1gZ5MrL-Ju1XK9uc&e=>
@_nat_en
_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jose&d=CwQFAg&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=tevYWz1lgHjtwlrld6RGUwDmuvlCuJw1Ryc17kjJxYc&m=rPr_MDrtA5TV8cVpReqg_XIkoWdGNUqptpRHwfzV3Nw&s=Qyndlk0bv0B8HTrwp6eO0l_J1-gyQihx8hClD34fnos&e=>

---

From: Mike Jones <[email-masked]>
Date: Tue, 22 Dec 2015 14:34:33 +0000

It's clear that most people prefer the 100% safe option over the current text that relies upon application semantics in some cases.  Thanks, James, for suggesting this and thanks to all of you who took the time to look at the issue.

I'll prepare a new draft reflecting this outcome.  Vladimir, could I ask you to once again verify the examples, once they've been updated?

                                                          Thanks all,
                                                          -- Mike

From: Preibisch, Sascha H [mailto:[email-masked]]
Sent: Monday, December 21, 2015 9:54 AM
To: Roland Hedberg <[email-masked]>; Nat Sakimura <[email-masked]>
Cc: [email-masked]; Axel Nennker <[email-masked]>; Jim Schaad <[email-masked]>; Mike Jones <[email-masked]>; Kathleen Moriarty <[email-masked]>; [email-masked]; [email-masked]; Matthew Miller <[email-masked]>; John Bradley <[email-masked]>; The IESG <[email-masked]>; Stephen Farrell <[email-masked]>
Subject: Re: [jose] Stephen Farrell's Discuss on draft-ietf-jose-jws-signing-input-options-08: (with DISCUSS and COMMENT)

+1

+1

-----Original Message-----
From: jose [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Matt Miller (mamille2)
Sent: Donnerstag, 17. Dezember 2015 18:19
To: Kathleen Moriarty; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Michael Jones; The IESG; John Bradley; Stephen Farrell; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Stephen Farrell's Discuss on draft-ietf-jose-jws-signing-input-options-08: (with DISCUSS and COMMENT)

--
- m&m

Matt Miller
Cisco Systems, Inc.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 22 Dec 2015 11:13:22 -0500

Thanks, Mike.  Let me know when this is all ready.

Best regards,
Kathleen

On Tue, Dec 22, 2015 at 9:34 AM, Mike Jones <[email-masked]> wrote:
> It’s clear that most people prefer the 100% safe option over the current
> text that relies upon application semantics in some cases.  Thanks, James,
> for suggesting this and thanks to all of you who took the time to look at
> the issue.
>
>
>
> I’ll prepare a new draft reflecting this outcome.  Vladimir, could I ask you
> to once again verify the examples, once they’ve been updated?
>
>
>
>                                                           Thanks all,
>
>                                                           -- Mike
>
>
>
> Cc: [email-masked]; Axel Nennker <[email-masked]>; Jim Schaad
> <[email-masked]>; Mike Jones <[email-masked]>; Kathleen
> Moriarty <[email-masked]>;
> [email-masked]; [email-masked]; Matthew
> Miller <[email-masked]>; John Bradley <[email-masked]>; The IESG
> <[email-masked]>; Stephen Farrell <[email-masked]>
>
>
> From: jose <[email-masked]> on behalf of Roland Hedberg
> <[email-masked]>
> To: Nat Sakimura <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Axel Nennker
> <[email-masked]>, Jim Schaad <[email-masked]>, Mike Jones
> <[email-masked]>, Kathleen Moriarty
> <[email-masked]>,
> "[email-masked]"
> <[email-masked]>, "[email-masked]"
> <[email-masked]>, Matthew Miller <[email-masked]>, John Bradley
> <[email-masked]>, The IESG <[email-masked]>, Stephen Farrell
> <[email-masked]>
> 21 dec. 2015 kl. 15:55 skrev Nat Sakimura <[email-masked]>:
>
>
>
> I think that the larger a payload is the higher is the risk of a bad verify
> and that few extra bytes don't matter then.
> Cc: [email-masked]; [email-masked]; Michael Jones; The IESG;
> John Bradley; Stephen Farrell;
> base64url might be prohibitive would dwarf the concerns around header size.
> I think the risk of bad verifies outweighs the reduced-headher-size
> benefits.
>
>
> --
> - m&m
>
> Matt Miller
> Cisco Systems, Inc.
>
>> On Dec 17, 2015, at 08:39, Kathleen Moriarty
>> <[email-masked]> wrote:
>>
>>>> perspective if crit was always required.  Trading 6 octets for saving 1/4 of
>>>> the body size is not a bad trade off.
>>>>

-- 

Best regards,
Kathleen

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Thu, 24 Dec 2015 11:02:11 +0200

Thank you Mike for updating the spec. I verified the -09 JWS examples,
the HMAC check passes.

The examples now include the "crit" header, but the requirement for
"crit" and why it's needed appears much later in the spec, in section
six. Do you think the "Using crit with b64" section could be moved up,
just before the "Examples" section?

Happy holidays,

Vladimir