[Bug 27814] Section A.2 - the usage mapping of "enc" is incorrect

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27814

--- Comment #9 from Ryan Sleevi <sleevi@google.com> ---
(In reply to jimsch from comment #8)
> JOSE defined the JWK structure.
> JOSE defined the "use" parameter within that structure.
> JOSE defined the value of the "use" parameter for types of type "EC".

For which JOSE only allows composed operations, whereas WebCrypto allows
arbitrary primitives.

> WebCrypto should follow the standard produced by the JOSE group.

I suspect we'll just get in an unproductive discussion here. I just want to
reiterate that this group has repeatedly made clear that there exist
differences between Web Crypto and JOSE and for good reason.

This has born out in past discussions (e.g. regarding key ID, algorithm names)
that there are fundamentally differences between APIs and wire-messaging
formats like JWK/JOSE.

This is why it's a weak argument. It's the same reasoning that constraints that
exist in JWS (e.g.
https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-39#section-3.3
requiring a >= 2048-bit RSA key) are not applied to the base JWK format.

> If you would prefer that the bug be filed against the JWK import of ECDH
> keys (there is no jwk import for DH so it would not apply there yet), I am
> willing to make that change.  I don't see that it changes any of the base
> arguments what the title is.  The text of the initial bug says that this
> needs to be done as well.

The argument is that Appendix A.2 probably shouldn't be changed, but perhaps
ECDH should be. That runs counter to your argument (which is ECDH should be
changed because A.2 is changed)

> I find the argument you make about the fact that WebCrypto does not tag a
> use at export time to be weak.  I would never expect that WebCrypto would
> ever define a use parameter on export.  It should only use the key_ops
> parameter as this has much better security properties.  I could extend your
> argument to be - since we never export a jwk with a use parameter, we should
> never import one which has the parameter set.  Is that your intent?

No, I fear you have misunderstood this argument. I'm going to try to restate
the point to make it clear:
- WebCrypto will NEVER tag a 'use', so this does NOT cause any issues between
two Web Crypto implementations
- For keys that are not wrapped, the JS author can ALWAYS remove the use field
if necessary. This is no different than the JS author needing to fix up 'alg'
into the appropriate composite Web Crypto operations.
- Therefore, the ONLY issue is when receiving a wrapped key from some other,
non-WebCrypto implementation

In the same way that WebCrypto does NOT allow/define reliable wrapping of JWK
(e.g. to meet the padding requirements of AES-KW), and that is left to the
external system, it COULD be simply an API requirement that any implementation
sending such a key to WebCrypto should be explicitly using the key_ops field,
rather than 'use'

This argument fails IFF it's possible for JOSE implementations to generate
wrapped keys that are used in JOSE messages, where the JOSE implementation is
defined to use 'use'. I can find no such support in the spec, but obviously,
I'm not implementing JOSE.

> 
> I don't expect that the WebCrypto group would ever define RSA-KEM
> (http://tools.ietf.org/html/rfc5990 and ASN-X9.44) as one of its algorithms,
> but it is not immediately clear if the correct set of usages for this
> algorithm is encrypt/decrypt or deriveBits/deriveKeys (returning both the
> encrypted secret and the derived bits/key).   This means that there is a
> possibility (however remote) that a use of enc is the wrong value for an RSA
> key as well as an EC key.  

It's not clear why you suggest RSA-KEM would be derive*, when all of the past
discussions have been in the context of it being a key wrapping method.

> The main reason for using KEM rather than OAEP is that the security proofs
> are so much better with KEM.  There are real tight proofs for KEM.  As an
> aside, it is also a demonstration for Mark as to why one does not want to
> put an upper limit on the amount of entropy that can be given to a KDF
> algorithm.

I'm aware. We've discussed this in the past, for some time, and it was always
in the context of wrap/unwrap (aka encrypt/decrypt). It's not clear why you
would suggest it's a deriveKey operation, since KEM as an operation involves a
set of composite steps.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Thursday, 15 January 2015 00:46:20 UTC