Re: [jose] gen-art telechat review of draft-ietf-jose-json-web-key-33

[Mike Jones <[e-mail]>]

Thanks again for your review, Scott.  Based upon our discussions, no changes were made to the -34 draft as a result of your comments.

				Thanks again,
				-- Mike

-----Original Message-----
From: jose [mailto:[e-mail]] On Behalf Of Mike Jones
Sent: Tuesday, September 30, 2014 3:27 PM
To: Scott Brim
Cc: [e-mail]; gen-art; [e-mail]
Subject: Re: [jose] gen-art telechat review of draft-ietf-jose-json-web-key-33

I agree with your observation about the surrounding protocol.  Thanks again for the time you put into reviewing the document.

				-- Mike

-----Original Message-----
From: Scott Brim [mailto:[e-mail]]
Sent: Tuesday, September 30, 2014 12:59 PM
To: Mike Jones
Cc: gen-art; [e-mail]; [e-mail]
Subject: Re: gen-art telechat review of draft-ietf-jose-json-web-key-33

On Tue, Sep 30, 2014 at 2:29 PM, Mike Jones <[e-mail]> wrote:
> Minor issues:
>
>   More than once it is said that members that are not understood
>   should or must be ignored. Wouldn't this depend on context? Couldn't
>   there be uses of the data structure where a negative reply would be
>   needed if something is not understood, so the sender can adapt?
>
> This language is present so that extensions carrying additional 
> information can be added in a non-breaking fashion.  You’re right 
> that, in theory, a “must-understand” capability could be added for 
> particular fields, as was done for JOSE header parameters in 
> https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-33#sect
> ion-4.1.11, but in practice, no working group member has come forward 
> saying they are aware of an application that needs this for key 
> representations.  Rather, the working group’s thoughts were that 
> multiple keys would be present in a JWK Set, some of which might not 
> be understood, but those that are understood would be used.  This 
> might be the case, for instance, when an entirely new key type (not 
> RSA, Elliptic Curve, or Symmetric) is invented and added at some point 
> in the future.
>
> Do you have a specific example in mind that requires a “must-understand”
> capability for key representations?

I don't do keys (this is gen-art, where reviews are often done by experienced generalists, not experts in the field), so it doesn't do any good asking me for text :-). Now that I think about it, I don't need what I'm looking for to be in this draft -- it could be in the larger context. Essentially it has to be possible (not required) for there to be some kind of feedback from whoever receives this to whoever sent it. That can be in the surrounding protocol.

>   In Section 4.3, you give the general principle that multiple
>   unrelated key operations shouldn't be specified for a key, and give
>   an example. Since this is a security issue of unknown magnitude (the
>   future isn't here yet), what do you think of removing uncertainty by
>   being more exhaustive in the principles and/or examples?
>
> This is a “SHOULD NOT” rather than a “MUST NOT” because there are 
> existing use cases in which the same RSA key is used for both signing and encryption.
> I’m not an expert in the underlying cryptography, but it’s my 
> understanding that this is quasi-OK for RSA because both RSA 
> signatures and RSA encryption actually are based on an RSA encryption 
> operation, and so what appears to be using a key being used for 
> unrelated operations actually isn’t under the covers, in this 
> particular case.  However, if you want to supply additional proposed 
> security considerations text on this issue (or possibly even better, 
> cite pertinent security considerations text in an existing RFC that we could reference), that would be appreciated.

OK, it seems the boundaries are clear to you and implementers who will read the RFC, which is all I ask.

Thanks ... Scott
_______________________________________________
jose mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/jose