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

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


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

Received on Monday, 22 July 2013 19:47:55 UTC