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.