Re: Bug # 2267 and #24056

I just updated these two bugs.

As Ryan says, the wrap/unwrap operations need to refer to the actual
encrypt/decrypt algorithms, not to the encrypt/decrypt methods. This is
wrong in the specification right now. The methods describe the creation of
the Promise and mapping of the inputs/outputs, which is not relevant when
we are already inside the wrap/unwrap method.

These are distinct issues: 22677 is a mistake in the spec that needs to be
fixed as noted above. 24056 is a decision that any algorithm that supports
encrypt/decrypt can also be used with wrap/unwrap, since we have defined
those methods in terms of the encrypt/decrypt operations.

...Mark


On Fri, Jan 24, 2014 at 4:02 PM, Ryan Sleevi <sleevi@google.com> wrote:

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