RE: Bug # 2267 and #24056

 

 

From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Friday, January 24, 2014 4:02 PM
To: Jim Schaad
Cc: public-webcrypto@w3.org
Subject: Re: Bug # 2267 and #24056

 

 

 

On Fri, Jan 24, 2014 at 2:34 PM, Jim Schaad <ietf@augustcellars.com> wrote:

I will note that 24056 is basically  a duplicate of #2267 just stating the case from the other side of the issue.

 

These two bugs exist solely because of the issues involved with crossing the boundary between the script and the embedded code.  If the wrap and unwrap operations are contained either only in script or only in the embedded code then the wrapKey operation can be defined without resorting to the use of the encryption operation.  

 

There are some security issues that I would like to have considered before we just decide that we can make the statement that the encryption key usage is required for doing key wrap.  Doing so means that one cannot protect a key from possible exposure to the script (may not be considered to be an issue by some but is by others).  Changing the definition of the wrap function so that there are two different descriptions so that there is effectively one for inside of the embedded system and one for crossing the security boundary makes things slightly more complicated in description, but addresses this problem.  

 

In looking at the question of modifying the description of the wrapKey and unwrapKey methods, is it reasonable to be able to have a step which asks the question:

 

X. If executing in embedded code and the wrappingKey is in embedded code then ….

 

>From earlier messages from Ryan, I think that the answer would be yes as the first statement is easy to check and the second have is going to be a tautology because we don’t reflect keys back into the script from the embedded system.

 

If so then I would suggest  a modification to step 10.

 

10.  Encrypt bytes with the wrappingKey, with wrappingKey as key, normalizedAlgorithm as algorithm, and with bytes as buffer

   1. If in the embedded code

                Execute the encrypt algorithm checking for the usage of wrappingKey rather than key usage encrypt.

   2. If not in embedded code

                Execute the normal encrypt algorithm

 

Jim

 

 

Jim,

 

I appreciate you attempting to make a distinction here, but I definitely have issue with codifying the notion of "embedded code"

 

Regardless, we discussed how this would work at Shenzhen, and it was explained how the "encrypt" key usage is *never* needed for wrap, just like the "decrypt" key usage is *never* needed for unwrap.

 

The "proceed as if it was export/encrypt or decrypt/import" are with respect to the so-called "sub-algorithms".

 

That is, for any encrypt operation, there is a common set of implementation checks, which we'll call the Encrypt algorithm (note the Big E). Additionally, for every algorithm, there is algorithm-specific implementation details, which we'll call encrypt-Foo (note, little E, Foo to indicate the algorithm).

 

That is, think of window.crypto.subtle.encrypt({name: "AES-GCM"}).

 

An implementation first runs Encrypt, which does things like algorithm normalization, makes sure "AES-GCM" defines an algorithm, __makes sure that key is valid for "encrypt"__, etc.

It then runs encrypt-AES-GCM, which performs the AES-GCM encryption steps.

 

The idea of wrap/unwrap is that you have Wrap (again, Big W), which performs checks like making sure that the Key is suitable for "wrap", and then calls wrap-Foo-Bar, where Foo is the Algorithm and Bar is the format.

 

The generic case is that wrap-Foo-Bar is composed of export-Bar and encrypt-Foo (note the lack of capitalization). That is, there are no key usage checks.

 

This entirely avoids the notion of things like "embedded code", which the spec absolutely should not specify.

 

I don’t understand, and now really wish I had been healthy for the F2F.  Does this mean that there are going to be two different encrypt methods exposed to the script?