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

On Mon, Jul 22, 2013 at 12:46 PM, Jim Schaad <ietf@augustcellars.com> wrote:
>
>
>> -----Original Message-----
>> From: Ryan Sleevi [mailto:sleevi@google.com]
>> Sent: Monday, July 22, 2013 9:47 AM
>> 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 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."
>
> Ah - Yes I can see that now.  I was reading key as being a crypto key not a
> dictionary key.
>
> At this point I would say that I cannot write a generic normalizer as
> without knowing the dictionary structure there is no way for me to know that
> this is an algorithm or something else.   One can always see if it happens
> to work, but one cannot fail because it is not an algorithm identifier and
> may accidently normalize something that should not be normalized.

Sure, but that's inescapable.

The whole issue of 'algorithm normalization' is only introduced
because of the desire for DOMString to represent algorithms.

If we wanted, we could describe 'algorithm normalization' as an
internal only process. This makes it more difficult to compare two
objects for equality, and even moreso for persistence, but it 'could'
simplify things.

Regardless though, whether we always specify explicit Dictionaries
(and nested dictionaries), your algorithm normalization will always be
gated on the type of normalization you're doing - and that will always
be algorithm specific. Whether you're looking at IDL that says this is

typedef (FooParams1 or FooParams2 or FooParams3) FooParams
or
dictionary {
  DOMString name;  // One of "Foo1" or "Foo2" or "Foo3"
  Dictionary subparams
};

It's the same implementation.


>
>
>>
>>
>> >
>> >>
>> >> >
>> >> > {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?
>
> There is no missing property, the question is should the KDF be placed in
> the same location - i.e. parameter to the function or parameter of the
> algorithm dictionary.  The same data is going to be used in either way.
>
> Jim
>
>

I can see the argument for keeping them separate - the KDF on an
RSA-KEM operation is not the same as the KDF on a secret agreement.

Received on Monday, 22 July 2013 20:00:38 UTC