Re: [secdir] secdir review of draft-ietf-jose-jws-signing-input-options-06

[Mike Jones <[e-mail]>]

Done in -07.

-----Original Message-----
From: Kathleen Moriarty [mailto:[e-mail]] 
Sent: Sunday, December 13, 2015 9:16 PM
To: Mike Jones <[e-mail]>
Cc: Jim Schaad <[e-mail]>; [e-mail]; Benjamin Kaduk <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Re: secdir review of draft-ietf-jose-jws-signing-input-options-06



Sent from my iPhone

> On Dec 13, 2015, at 11:34 PM, Mike Jones <[e-mail]> wrote:
> 
> Kathleen - do you now concur with Jim that we should leave the Updates clause for 7519 in?  Let me know and then I'll post the resolutions to the Gen-Art and Sec-Dir comments.

Yes, that's fine.  Thanks, Jim.

Kathleen 
> 
>                -- Mike
> 
> -----Original Message-----
> From: Jim Schaad [mailto:[e-mail]]
> Sent: Sunday, December 13, 2015 8:15 PM
> To: 'Kathleen Moriarty' <[e-mail]>; Mike Jones 
> <[e-mail]>; [e-mail]
> Cc: 'Benjamin Kaduk' <[e-mail]>; [e-mail]; [e-mail]; 
> [e-mail]
> Subject: RE: secdir review of 
> draft-ietf-jose-jws-signing-input-options-06
> 
> Please note that the write up addresses two different updates.
> 
> 7519  which was in the document and updates JWT with the statement 
> that says - don't do this
> 7515  which would be an update of JWS - however it was determined that updating the registry is sufficient without updating the document itself.
> 
> While I don't know that there is a need to update 7519 - there is not really a strong statement to be made either way, so I did not ask for it to be removed.  I was more worried about the question of having an update to 7515 which was not present. Karen and I determined that we probably did not need to have this document updated so there were no changes to be made to the document.
> 
> I would keep the 7519 update since that was seen by the WG.  And not put in an update to 7515 since, again, that was what the WG saw.
> 
> Jim
> 
> 
>> -----Original Message-----
>> From: Kathleen Moriarty [mailto:[e-mail]]
>> Sent: Sunday, December 13, 2015 7:59 PM
>> To: Mike Jones <[e-mail]>; 
>> [e-mail]
>> Cc: Benjamin Kaduk <[e-mail]>; [e-mail]; [e-mail];
>> draft- [e-mail]
>> Subject: Re: secdir review of
>> draft-ietf-jose-jws-signing-input-options-06
>> 
>> Jim & Karen,
>> 
>> I see the updates in the last 2 versions in both the header and 
>> abstract, prior to when the shepherd report was posted.  I see in the 
>> shepherd report that you do not agree that this draft updates RFC7519.
>> Is there a reason this change was not already made to the draft?
>> Please confirm that removing this is the right action, it seems to be 
>> from your shepherd report reasoning.
>> 
>> Best regards,
>> Kathleen
>> 
>> On Sun, Dec 13, 2015 at 10:50 PM, Mike Jones 
>> <[e-mail]>
>> wrote:
>>> To confirm, you want me to remove the Updates 7519 clause, and the 
>>> second
>> paragraph of the abstract, which says:
>>> 
>>>   This specification updates RFC 7519 by prohibiting the use of the
>>>   unencoded payload option in JSON Web Tokens (JWTs).
>>> 
>>> Correct?  I'll do that then shortly.
>>> 
>>>                                Thanks,
>>>                                -- Mike
>>> 
>>> -----Original Message-----
>>> From: Kathleen Moriarty [mailto:[e-mail]]
>>> Sent: Sunday, December 13, 2015 7:37 PM
>>> To: Mike Jones <[e-mail]>
>>> Cc: Benjamin Kaduk <[e-mail]>; [e-mail]; [e-mail]; 
>>> [e-mail]
>>> Subject: Re: secdir review of
>>> draft-ietf-jose-jws-signing-input-options-06
>>> 
>>> Mike,
>>> 
>>> Sorry, I take that back.  The chairs make a good point in the shepherd writeup.
>> This really doesn't update 7519, so it should not say that in the abstract.
>>> 
>>> Thanks.
>>> 
>>> On Sun, Dec 13, 2015 at 10:05 PM, Kathleen Moriarty
>> <[e-mail]> wrote:
>>>> Mike,
>>>> 
>>>> Please do add that to the abstract and post as soon as you can with 
>>>> all updates from last call received so far and agreed upon.
>>>> 
>>>> Thanks,
>>>> Kathleen
>>>> 
>>>> On Sat, Dec 12, 2015 at 10:30 PM, Mike Jones 
>>>> <[e-mail]> wrote:
>>>>> Sounds good.  Thanks, Kathleen.
>>>>> 
>>>>>                                -- Mike
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Kathleen Moriarty [mailto:[e-mail]]
>>>>> Sent: Saturday, December 12, 2015 7:28 PM
>>>>> To: Mike Jones <[e-mail]>
>>>>> Cc: Benjamin Kaduk <[e-mail]>; [e-mail]; 
>>>>> [e-mail]; 
>>>>> [e-mail]
>>>>> Subject: Re: secdir review of
>>>>> draft-ietf-jose-jws-signing-input-options-06
>>>>> 
>>>>> 
>>>>> 
>>>>> Sent from my iPhone
>>>>> 
>>>>>> On Dec 12, 2015, at 9:33 PM, Mike Jones 
>>>>>> <[e-mail]>
>> wrote:
>>>>>> 
>>>>>> Hi Ben,
>>>>>> 
>>>>>> Thanks for the useful review.  Replies are inline below...
>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Benjamin Kaduk [mailto:[e-mail]]
>>>>>>> Sent: Friday, December 11, 2015 10:05 AM
>>>>>>> To: [e-mail]; [e-mail];
>>>>>>> draft-ietf-jose-jws-signing-input-
>>>>>>> [e-mail]
>>>>>>> Subject: secdir review of
>>>>>>> draft-ietf-jose-jws-signing-input-options-06
>>>>>>> 
>>>>>>> Hi all,
>>>>>>> 
>>>>>>> I have reviewed this document as part of the security 
>>>>>>> directorate's ongoing effort to review all IETF documents being 
>>>>>>> processed by the IESG.  These comments were written primarily 
>>>>>>> for the benefit of the security area directors.  Document 
>>>>>>> editors and WG chairs should treat these comments just like any 
>>>>>>> other last call
>> comments.
>>>>>>> 
>>>>>>> This document is Ready.
>>>>>>> 
>>>>>>> The main JWS spec (RFC 7515) required that the signed payload 
>>>>>>> was base64url-encoded prior to signing.  This results in a 
>>>>>>> noticeable size expansion; in some circumstances it is desirable 
>>>>>>> to avoid this expansion and reencoding.  I did not follow the 
>>>>>>> JWS document closely at the time, but I believe this issue was 
>>>>>>> raised at the time and consensus reached on the published 
>>>>>>> version because it is always
>> safe for applications to use.
>>>>>>> This document provides an opt-in mechanism for application 
>>>>>>> (protocol)s to avoid the extra encoding and expansion, leaving 
>>>>>>> the burden on the application to determine whether it is safe to 
>>>>>>> do so and perform the relevant input checking/sanitization.  The 
>>>>>>> security considerations correctly describe the implications of 
>>>>>>> the loss of encoding and the restrictions on the signed content 
>>>>>>> when detached payloads are not used, interoperability concerns 
>>>>>>> for applications not supporting the b64 header parameter, and 
>>>>>>> proposes
>> appropriate countermeasures.
>>>>>> 
>>>>>> Thanks for letting us know that the security considerations were 
>>>>>> clear=
>