Re: JWK attributes for WebCrypto keys: last call

On Thu, Dec 19, 2013 at 1:05 PM, Jim Schaad <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
>
>
>
>
>