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

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

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

I don't think it would make them any more unhappy than what it currently is
doing.  After all complete rejection is easier to code for.

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

I had not really expected this point to generate a lot of discussion - this is
a bit surprising to me.

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

I would never call this a key agreement scheme - it does not involve two keys
so that would be impossible.  I would call it a scheme that is doing key
derivation of a secret with a KDF algorithm.  I think that is a very different
beast.

> 
> 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 have a much more restricted version of secret than I do.  By your
definition a CEK is never a secret because it is passed over the wire.

One of the reasons that I would not care for you implementation is the same as
the current problem of adding a new hash for signatures, there is no way to do
it for a key trapped in a browser.  In the same way a KDF is never going to be
able to be added to the system.  The KDF needs to be passed in as an argument
to the encryption and decryption operations for RSA-KEM.  The same restriction
also is placed on new key wrap algorithms as the key wrap algorithm is going to
need to be passed into the encryption and decryption operations for RSA-KEM. 
And I thought you did not really want to have composite algorithms if they
could be easily avoided.

You are also not allowing for the secret encrypted by RSA to be shared among
multiple recipients, something that my reading of the documents says is a
perfectly secure method of using the algorithm.

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

Received on Thursday, 15 January 2015 06:20:07 UTC