Re: JWK attributes for WebCrypto keys: last call

Mike,

IIUC, JOSE agreed to this at the Jan 13 meeting, except the field will be
renamed "key_ops" and will be mutually exclusive with "use", right ? When
do you expect to have a new draft available ?

...Mark


On Tue, Dec 24, 2013 at 3:55 PM, Mike Jones <Michael.Jones@microsoft.com>wrote:

>  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.comdon'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>
> написал(а):
>
>
>
>   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<Michael.Jones@microsoft.com>
> ]
> *Sent:* Thursday, December 19, 2013 10:29 PM
> *To:* Ryan Sleevi; Jim Schaad
> *Cc:* Mark Watson; 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 <sleevi@google.com>]
> *Sent:* Thursday, December 19, 2013 5:41 PM
> *To:* Jim Schaad
> *Cc:* Mark Watson; 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>
> 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
>
>
>
>
>