Re: ACTION-84: Finishing support for key derivation/key agreement (take 2)

On Fri, Jul 19, 2013 at 10:49 AM, Jim Schaad <ietf@augustcellars.com> wrote:
>
>
>> -----Original Message-----
>> From: Ryan Sleevi [mailto:sleevi@google.com]
>> Sent: Thursday, July 18, 2013 5:45 PM
>> To: Jim Schaad
>> Cc: Vijay Bharadwaj; public-webcrypto@w3.org; Israel Hilerio
>> Subject: Re: ACTION-84: Finishing support for key derivation/key agreement
>> (take 2)
>>
>> On Mon, Jul 15, 2013 at 9:08 AM, Jim Schaad <ietf@augustcellars.com>
>> wrote:
>> > I was going through things and came up with a question I would like to
> pose.
>> >
>> > How does one go about implementing RSA-KEM?
>> >
>> > RSA-KEM is basically something that looks a lot like a key agreement
>> > algorithm, but uses RSA rather than DH for transporting the secret.
>> > Thus you do
>> >
>> > Decrypt the RSA encrypted secret
>> > Run a KDF on the secret
>> > Execute a key wrap algorithm using the derived key
>> >
>> > Currently, I think that I would need to do something strange like
>>
>> Why do you think that's strange? We already have a number of algorithms
>> that take an AlgorithmIdentifier as parameters.
>
> I will also note that the current algorithm normalization algorithm does not
> deal with this fact as it does not normalize embedded algorithm identifiers.

Yes it does.

See https://dvcs.w3.org/hg/webcrypto-api/raw-file/f5734f8b2e6a/spec/Overview.html#algorithm-normalizing-rules

Section 19, Step 4, Bullet 1.

"If the associated value V is an AlgorithmIdentifier, set the
associated value for K in result to be the result of executing the
algorithm normalization rules."


>
>>
>> >
>> > {name:"RSA-KEM", params: {kdf:<KDF Algorithm>}}
>> >
>> > And running decrypt on that would produce a Key rather than a
>> ArrayBuffer.
>>
>> Decrypt should never produce a key. Call a wrap a wrap :)
>>
>> Let's say you're using RSA-KEM to transport an RSA private key for use
> with
>> RSA-PSS (eg: provisioning a new key)
>>
>> Presumably, this could look something like
>>
>> let unwrapAlg = {
>>   name: "RSA-KEM",
>>   kdf: { name: "CONCAT", hash: "SHA-256", algorithmId: "x",
>> partyUInfo: "y", partyVInfo: "z" }
>> };
>> let tempAlg = {
>>   name: "AES-KW",
>>   length: 192,
>> };
>> let destAlg = {
>>   name: "RSA-PSS",
>> };
>>
>> window.crypto.subtle.unwrapKey("raw", rsaKEMKeyData, rsaKey, unwrapAlg,
>> tempAlg).then(tempKey => {
>>   return window.crypto.subtle.unwrapKey("raw", wrappedKeyData, tempAlg,
>> destAlg); }).then(unwrappedKey => {
>>   // Do something with the new RSA-PSS key.
>> });
>>
>> This presumes that the caller can distinguish between the RSA-KEM key data
>> (eg: the first 1024 bits of a message) and the KEK-protected data.
>>
>> This has RSA-KEM unwrap the secret, then feeds it through the KDF to
>> generate a key of tempAlg type - an AES-192 key for use with AES Key Wrap.
>>
>> The AES Key Wrap key is then used unwrap the KEK-protected data, yielding
>> unwrappedKey as a result.
>>
>> Have I missed something?
>>
>> >
>> > If we have to do this with RSA-KEM, is there a reason why we should
>> > not make the DH algorithms behave in a similar manner?
>>
>> Am I missing why the above does or does not work for the DH case?
>
> You are not missing anything in the above, however this does not match what
> is currently proposed for the DH case.  In the DH case the KDF is an
> explicit argument  for the function call.  My question was should we match
> these two cases so they will work in a similar manner.
>
> Jim

Ok, I follow what you mean now.

I was thinking in the context of what the ED said pre-Vijay's suggestion.

However, in the case of a DH-protected key, why can't you use
secretAgreement("DH").then(return unwrap("AES-KW", ...)) ? What's the
missing security property?

Received on Monday, 22 July 2013 16:47:22 UTC