RE: JWK attributes for WebCrypto keys: last call

FYI, having heard no objections here - I just proposed the "use_details" JWK member to JOSE in http://www.ietf.org/mail-archive/web/jose/current/msg03801.html.  Please discuss the proposed JOSE changes on the JOSE mailing list.

                                                            -- Mike

From: Alexey Proskuryakov [mailto:ap@webkit.org]
Sent: Friday, December 20, 2013 9:55 AM
To: Mike Jones
Cc: Ryan Sleevi; Jim Schaad; Mark Watson; public-webcrypto@w3.org
Subject: Re: JWK attributes for WebCrypto keys: last call

Hello Mike,

I think that having everything defined in the JWK spec would be a huge improvement.

There are some details to work out, which could affect security and interoperability.

- Will all implementations be required to support "use_details"? How can we enforce this? I understand that a haphazard implementation could easily overlook "use" as well, yet it's a large step up in complexity to support both, especially if example JWK keys a developer sees on stackoverflow.com<http://stackoverflow.com> don't have "use_details".

- What will encrypt/decrypt/wrap/unwrap map to in "use"? Given that WebCrypto has algorithms that support both encryption and wrapping, this is a meaningful combination.

- WebCrypto has separate deriveKey and deriveBits, so if we want 100% round-trip fidelity, we need separate values for these.

>From a web platform developer perspective, it is crucial to have a very clear spec, and some means of enforcing it. It's pretty much the normal mode of operation on the Web that applications rely on a multitude of engine "features" that original spec writers consider horrible bugs.

I'm not a crypto expert, but I'm already hearing stories that the same happens in crypto world - e.g. there are hardware security devices that incorrectly verify key usages, and there are authorities that issue keys with incorrect usages. And so actual implementations only work through a combination of these two mistakes, with no practical way - and even no incentive - to correct them.

- WBR, Alexey Proskuryakov


20 дек. 2013 г., в 7:37, Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> написал(а):


Thinking about it over night, I think that the JWK field should be called
               use_details

It should be array-valued.  The array should contain a combination of the values:
               "encrypt", "decrypt",  "sign",  "verify",  "derive",  "wrap",  "unwrap"
Other values should also be allowed to be registered and used.

I chose the name "use_details" because it makes it clear that this supplements the simple "use" field for those wanting finer-grained usage information.

Both could be used if the usages described are compatible.  However, if, for instance, the "use_details" contained both "encrypt" and "sign", neither "use":"enc" or "use":"sig" would be accurate, and so including "use" in that case would be prohibited.

That seems like it would address everyone's needs.

If people are OK with that approach, I'll suggest it to the JOSE working group.

                                                            -- Mike

From: Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Thursday, December 19, 2013 10:29 PM
To: Ryan Sleevi; Jim Schaad
Cc: Mark Watson; public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
Subject: RE: JWK attributes for WebCrypto keys: last call

I don't think anyone in JOSE is presenting "use" as the One True Interpretation of key usage.  It's just a simple, convenient one that appears to be working fine in practice for simple applications.

I realize that full-fidelity key import/export is not necessarily a simple application and that more granularity of key usage may be needed in that context.  I've actually almost convinced myself that *JOSE* should define the "uses" field for keys using the WebCrypto JSON value, to allow for fine-grained key usage specifications, where needed.  The only downside to that is that there'd then be two key usage fields - a simple one and multi-valued one, and we'd have to be clear about the relationships between them.

Then at least we'd clearly be able to put an end to the unproductive statements (which I believe to be totally false) that JWK is only intended for use by JWS and JWE.  (Frankly, I don't know anyone in the JOSE working group who believes that!).

Comments?

                                                            -- Mike

From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Thursday, December 19, 2013 5:41 PM
To: Jim Schaad
Cc: Mark Watson; public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
Subject: Re: JWK attributes for WebCrypto keys: last call



On Thu, Dec 19, 2013 at 1:05 PM, Jim Schaad <ietf@augustcellars.com<mailto:ietf@augustcellars.com>> wrote:
There is a group of individuals in the JOSE group that have strongly felt that


1.       Usages of keys need to be restricted, although not necessarily as restricted as what the WebCrypto keys call for, thus the insistence for a single value in the field and

2.       If there if a proliferation of values for key usage is bad because it makes the code bases harder to work with.  This lead to the decision that 'enc' should be used both for key wrapping algorithms and content encryption algorithms.

Key wrapping algorithms -> using JWE
Content encryption algorithms -> using JWE

I think that is, at least in my view, part of my concern here. JWK is baking a presumption of the choice of methods for using JWK, and as such, limiting the flexibility of JWK. I realize you're the messenger, and I shouldn't shoot you, but I'm just trying to restate the concern.

'enc' could just as well be called 'jwe' with zero loss of fidelity, and perhaps addressing the second point - the proliferation of values for key usage is no longer an issue, because it clearly indicates the *spec* that the JWK was intended to use for.

I think this is also part of why Mike has suggested "webcrypto_use" - the recognition that "use" today has nothing to do with key usage as traditionally viewed, but instead has to do with which *spec(s)* the JWK can be used with.

For what it's worth, I have zero problem with a "use" triple of (jwe, jws, webcrypto), with jwe/jws finding "use"+"alg" sufficient to discuss their security properties, and webcrypto using an extended/enumerated attribute (eg: "webcrypto_use") for full-fidelity serialization and deserialization. I do have problem, however, with JWE/JWS presenting "enc" and "sign" being the One True Interpretation of these keywords, and I'm convinced it's only going to cause issues for further spec utilization of JWK.


On a purely personal level, I don't necessarily agree with these decisions but they are what we have as the stated positions of the working group at the moment.

The real issue that I see is the question of having strings that allow for multiple different types of operations the can occur.  I could easily get behind the idea of registering "enc", "enc-only", "dec-only" as three strings that map to "encrypt+decrypt", "encrypt", "decrypt".  Where I have a greater problem is when we get into the concept that we are going to allow for keys to do different things that might be bad for them.  Thus the ability to have a key usage of "wrapKey+encrypt" seems more problematic based on the fact that the algorithm is designed to either encrypt content or encrypt keys.  I am also not sure if you want to be able to make statements along the lines of "encrypt+decrypt+sign+verify" for an RSA public key.

Just as an attempt to get the set of issues clearly outlined, I think that this is where things fall:


1.       Should there be an ability to decompose the encrypt usage into its component items, and can the union need to be a new string rather than a combined string? (i.e. enc vs enc-only vs dec-only)

2.       Are there cases where there is a need to combine together different types of operations together in the use string (i.e. wrap + encrypt)  (I think that if the answer to this is no then we might not need the array which is going to get very strong pushback.)

3.       What is the level of importance of being able to restrict the usage of a key without knowing what the algorithm that the key is to be used with.

Looking at the current text, the statement 'enc' is equivalent to 'enconly, deconly,wrap,unwrap' is incorrect.  The expectation is that the value of enc is to be interpreted based on the current algorithm value.  Thus it would be either 'enconly,deconly' or 'wrap,unwrap'.

Jim