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

[John Bradley <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 
> 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:
>> 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
>> 
>>> -----Original Message-----
>>> From: Stephen Farrell [mailto:[e-mail]]
>>> Sent: Thursday, December 17, 2015 2:32 PM
>>> To: Mike Jones <[e-mail]>; The IESG <[e-mail]>
>>> Cc: [e-mail]; [e-mail]; draft-ietf-jose-jws-signing-
>>> [e-mail]; [e-mail]
>>> Subject: Re: Stephen Farrell's Discuss on draft-ietf-jose-jws-signing-input-
>>> options-08: (with DISCUSS and COMMENT)
>>> 
>>> 
>>> Hiya,
>>> 
>>> On 17/12/15 13:20, Mike Jones wrote:
>>>> Thanks for your review, Stephen.  Replies inline below...
>>>> 
>>>>> -----Original Message----- From: Stephen Farrell
>>>>> [mailto:[e-mail]] Sent: Thursday, December 17,
>>>>> 2015 12:20 PM To: The IESG <[e-mail]> Cc:
>>>>> [e-mail]; Mike Jones
>>>>> <[e-mail]>; Jim Schaad <[e-mail]>;
>>>>> [e-mail]; [e-mail]; [e-mail] Subject:
>>>>> Stephen Farrell's Discuss on draft-ietf-jose-jws-signing-input-
>>>>> options-08: (with DISCUSS and COMMENT)
>>>>> 
>>>>> 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-op
>>>>> tions/
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>> ----------------------------------------------------------------------
>>>>> 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.
>>>> 
>>>> Jim's shepherd write-up at
>>>> 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"
>>>> 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?
>>> 
>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> -
>>>>> 
>>>>> 
>>> 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.)
>>>> 
>>>> 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."
>>> 
>>> 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:-)
>>> 
>>>> 
>>>>> - 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"
>>> 
>>> Also better,
>>> Ta,
>>> S.
>>> 
>>> 
>>>> 
>>>> Thanks again, -- Mike
>>>> 
>> _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose
>> 
> 
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose