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

[Kathleen Moriarty <[e-mail]>]

On Thu, Dec 17, 2015 at 9:32 AM, John Bradley <[e-mail]> wrote:
> 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.

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

Thanks!
Kathleen


>
> John B.
>
>> On Dec 17, 2015, at 3:04 PM, John Bradley <[e-mail]> wrote:
>>
>> 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
>>
>



-- 

Best regards,
Kathleen