W3C home > Mailing lists > Public > public-webcrypto@w3.org > January 2015

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

From: <bugzilla@jessica.w3.org>
Date: Thu, 15 Jan 2015 01:52:30 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-27814-7213-gDtNJjdxtY@http.www.w3.org/Bugs/Public/>

--- Comment #10 from jimsch <ietf@augustcellars.com> ---
(In reply to Ryan Sleevi from comment #9)
> (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.

I guess that would make my life as a designated expert for IANA on the issue of
algorithm registration easier.  I can deny the registration of the "alg" values
that are being requested because there are "fundamental differences between the
usage of the parameter and the WebCrypto registrations are incompatible with
those of 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 am happy to flip the argument if it makes you happy.  I don't care.

> > 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.

Given that PBKDF2 does not support anything that would look like an "import
wrapped key" that is not doable by definition.

> > 
> > 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.

But the composite operations are:
*Generate a secret
*Derive a key or bytes from a secret

The question is do you treat that as a single operation, or do you force the
secret to be exported before doing the derive.  I would probably have a
preference for making this a single operation, and thus allow it to stay inside
of the implementation, rather than two step process.  This is obviously not
your view, and I can understand your view.

> > 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 01:52:32 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 15 January 2015 01:52:32 UTC