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 02:22:50 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-27814-7213-kt9nohGbPq@http.www.w3.org/Bugs/Public/>

--- Comment #11 from Ryan Sleevi <sleevi@google.com> ---
(In reply to jimsch from comment #10)
> 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".

I guess, put differently, I would prefer that WebCrypto not have to deal with
'use' at all, because it is understandably a no-fidelity comparison to
WebCrypto's model.

Though we've tried to map it (to make it easier for users), it might equally be
desirable to reject 'use' entirely [for all keys]. However, I suspect that
would make many a JWK proponent unhappy.

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

While we run the risk of veering off into a side-discussion on RSA-KEM, to the
extent it's relevant to what does 'use': 'enc' mean for an RSA key, I think
it's good to continue.

In my reading of RSA-KEM, it isn't
"generate a secret" + "derive a secret"

It is:
"wrap", where the wrapping scheme is composed of:
"generate a secret" + "encrypt with that secret" + concat (secret, encrypted
message) as "wrapped key"

The input wrapping key is an RSA key. No ability to specify the random value.

Now, I can certainly appreciate how Steps 1&2 of RFC 5990, Section 1 may, on
their face, appear to be agreement scheme (after all, "generate a random value"
& "do some exponention" is functionally quite similar to DH-schemes), but I
feel like the lack of a confirmation/exchange step, and in particular, Step 5
of Section 1 make it much more akin to a wrapping scheme with a nonce prepended
[and, hopefully, a MAC covering it all]. That's why I see the 'enc' use for a
hypothetical RSA-KEM still being a 'wrap' / 'unwrap' use, not a derive.

To be clear, if the 'secret' was some implicit value that the two parties
arrived on in secret and never exchanged over the wire and wasn't reversible
(e.g. as PBKDF2 tries to be, as HKDF / ECDH are), then I think sure, it'd be a
derive operation, and likely composite. That is, derive to generate that
CryptoKey for the secret, then feed the Secret in to an operation. But that's
not RSA-KEM.

You are receiving this mail because:
You are on the CC list for the bug.
Received on Thursday, 15 January 2015 02:22:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:00 UTC