Re: ISSUE-35 - Wrap/Unwrap - Why JOSE?

Thanks for your quick response, Mark.

Unfortunately, I find it still needs quite a bit of unpacking to get
to the meat of the issue. I've attempted to ask clarifying questions
from your remarks, and to make sure I've properly unpackaged the
requirements implicit in your statements.

Please let me know if and where mistakes have been made.

On Fri, Apr 26, 2013 at 3:43 PM, Mark Watson <watsonm@netflix.com> wrote:
>
>
> On Fri, Apr 26, 2013 at 2:50 PM, Ryan Sleevi <sleevi@google.com> wrote:
>>
>> Out of curiosity when reviewing wrap/unwrap, what technical reasons
>> are there to require the format be JOSE?
>
>
> 1) This is what was proposed and noone objected
> 2) There is no existing format for wrapping WebCrypto keys, which have
> attributes as well as keying material. So we have to create something new.
> Using JOSE, which already has an active community developing it is a much
> better choice than rolling our own format in WebCrypto

#1 isn't a technical reason, but is useful information.

If I can attempt to correctly distill #2 into a technical requirement,

- Wrapped keys should preserve attributes

This is not true for imported/exported keys, given the formats
supported, so this seems to be a *new* requirement being introduced.

Is this a correct statement of the *technical* requirement being
introduced here though?

>
>>
>>
>> To put it differently, if it is to be implemented, why can it not be
>> treated simply as a specialized form of export+encrypt/decrypt+import,
>> where, just like export/import, it takes a key format specifier.
>
>
> Someone objected pretty strongly to the original proposal for overloading
> import/export to perform wrap/unwrap as well. I wonder who that was ... ;-)

I objected to conflating the API under a single method call.

I'm talking about formats here. Perhaps you've misunderstood - I'm
only talking about logical/mental models here, not about the API
semantics.

If JWK/PKCS#8 are sufficient for import/export, why are they not
sufficient for wrap/unwrap?

>
>>
>>
>> Recall that we have the key formats "raw", "pkcs8", "spki", and "jwk".
>>
>> The current wrap/unwrap proposal can ONLY be used with JWKs, which
>> creates a divergence from the support for import/export, which
>> supports more than just JWK.
>
>
> Right, exactly because there are other formats that can represent raw keying
> material, but there aren't existing formats that can securely wrap the key
> and attributes together.
>
> Having said that, if you have a use case for wrapping other key formats it
> is indeed easy to add that by adding the KeyFormat field.

Before we start making proposals for API changes, lets first make sure
we've actually discussed the problem. As discussed at the F2F this
week, it's very easy to make proposals that address a single members'
problem space, but fails to actually appreciate or establish what the
underlying issue is.

>
>>
>>
>> Was this an arbitrary design decision, or are there some set of
>> technical requirements? It seems like the JOSE support (including
>> transliteration of JOSE algorithms, params, SPIs, etc) can all be
>> handled via polyfill, and that a simple, composed,
>> "export-but-then-encrypt" or "decrypt-and-then-import" is more robust
>> and useful.
>
>
> At least the mapping of algorithms and other WebCrypto Key attributes
> to/from JWK is needed for pure import/export in JWK format.

This is something that's not been specified yet, and not something
that was clear to me that you were assuming would be the case.

You see attributes being preserved via import/export - is this a
correct statement?

>
> Regarding the idea that the JWE object could be constructed by Javascript if
> the UA provides the necessary primitives: In addition to export+encrypt and
> decrypt+import we would also need primitives to wrap and unwrap the Content
> Master Key in the JWE structure.

I'm sorry, why?

The CEK (nee CMK) is simply a series of octets - this corresponds to
the 'raw' key type.

generateKey - yields an appropriately sized CEK
wrapKey with raw - encrypts the set of octets that correspond to the
CEK and returns that.

Why would the above be insufficient?

Again, I'm exploring what a wrap/unwrap SHOULD look like, presuming
it's supported. Your current proposal has a series of assumptions
baked into the proposal, and I'm attempting to better understand them
to better understand the design.

>
> For RSA-OAEP, the wrapping of the CMK is just RSA-OAEP encryption, so that
> would be decrypt+import with a key format which is the raw AES CMK bytes.
> For AES, the CMK is wrapped using AES Key Wrap, so we would need support for
> that. In both cases there needs to be a "usage" for decrypt+import that is
> separate from simple decryption, otherwise the key encryption key can be
> used to do just a decrypt, rather than a decrypt+import.

As an aside, you made an unqualified statement here that is not
entirely obvious - why does there need to be a distinct usage / why is
it bad (since you imply it is) to be able to use a key for just
decrypt, rather than decrypt+import? For the purposes of understanding
your proposal, it would be good to explain this - but I suspect this
is correlated to the other thread related to why can't you polyfill
wrap/unwrap.

The argument you've made suggests you read *this* message as arguing
against wrap/unwrap. That's not the case. I'm trying to explore what
wrap SHOULD look like, IF it is to be supported. The current
wrap/unwrap bakes in format assumptions, without fully explaining why
or their use case. That's the intent of this message.

For example, your current proposal fails to address the requirements
you set forward in
http://www.w3.org/2012/webcrypto/wiki/KeyWrap_Proposal - namely, #3 on
Requirements, that it supports the same formats import/export support.
I'm trying to explore why that is.

If it helps you to understand the question I'm asking, presume you had
some distinct key usage for "wrap"/"unwrap". With such a usage, why
does the format itself matter?

> The problem is that
> there is no usage associated with the wrapped CMK. The JS could
> decrypt+import the CMK with a usage of decrypt, allowing the JWE payload to
> then be decrypted and returned to the script. That might be resolved with
> Richard's proposal that the CMK be represented as a JWK object, though I'm
> not sure that you don't eventually have the same problem when his recursion
> terminates.
>
> For the case where the payload is protected with AES-GCM, there's additional
> authentication data to take care of.

Please explain why this is an issue, or why the current ability to
supply AAD when using AES-GCM is insufficient. See
https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#dfn-AesGcmParams

> For the case where the payload is
> AES-CBC + HMAC protected then you have to deal with deriving the encryption
> key and the MAC key from the Content Master Key.

Please explain why this is an issue, or why the current ability to
perform key derivation is insufficient.

Note, Richard and Vijay have already taken an action item to explore
this, and we already have a dedicated call set up to explore key
derivation, as this extends beyond the JOSE case.

So the question to you is - how or why is this different from the use
cases we discussed at the F2F and which were identified that are fully
independent of JOSE.

>
> So, I think it's not possible to do with the present JWE format and even if
> that is changed the operation doesn't factor well like this - you end up
> with a number of additional primitives and I'm not sure the complexity cost
> is worth the gain which is only partial decoupling from JOSE.

The only coupling to JOSE, as I see it, is in translating the JWK.

I *only* see UAs being required to understand "kty". As noted in the
JWK, all other fields are OPTIONAL, and that is the ONLY field needed
to understand the remaining structure from
http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-10#section-5

It seems you expect UAs MUST understand other parameters, but this is
not clear from http://www.w3.org/2012/webcrypto/wiki/KeyWrap_Proposal
#4-#6 Requirements

>
>>
>>
>> For example, the current proposal of wrap/unwrap would effectively
>> prevent any security benefits from being realized from applications
>> which use PKCS#11, as they make use of PKCS#8 ( see
>> http://www.cryptsoft.com/pkcs11doc/STANDARD/pkcs-11v2-30m1-d7.pdf ,
>> Section 6.5 ). Likewise, CNG equally supports PKCS#8 ( see
>>
>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa376263(v=vs.85).aspx
>> ).
>
>
> I'm not sure there *are* any security benefits to be gained from key
> wrapping/unwrapping if the WebCrypto attributes - specifically extractable
> and usages - are not also protected within the wrapper. In that case you
> might as well do decrypt and then import in JS.

Agreed. And I don't see the protection of attributes as being part of
wrap/unwrap.

This matches the existing cryptographic APIs that such implementations
will be built on.

The assumption of the Web Crypto API is the same assumptions made by
native code dealing with 'native' APIs like CAPI/CNG/PKCS#11/CDSA/etc
- that is, the application performing the operation is, itself,
trusted.

To restate, my view of support for JWK within import/export is that
the *only* attribute that MUST be understood by a UA is "kty" - since
that's necessary to extract the actual key material. All other
attributes MAY be ignored.

>
>>
>> This seems to address at least one criticism, and seems like it would
>> greatly reduce the testing overhead.
>>
>> The question is - will it work, and if not, why not?
>>
>

Received on Friday, 26 April 2013 23:21:28 UTC