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

On Fri, Apr 26, 2013 at 4:21 PM, Ryan Sleevi <sleevi@google.com> wrote:

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

The attributes of a key are clearly visible on the Key object, so when you
export a Key you also have access to the attributes.

When you import a Key you specify the attributes of the Key in the call to
importKey().

The different between import/export and unwrap/wrap is just that the
information flowing over the API is in-the-clear in the former case and
cryptographically protected in the latter, not that the information is
different.


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

You could think of the technical requirement being like import/export
except that the information transferred is cryptographically protected. The
essence of key wrap/unwrap is that the information is being transported
between entities in possession of a particular key (or halves of a key
pair).

WebCrypto Keys consist of keying material and additional attributes, all of
which can be transferred between script and UA unprotected using
import/export and the Key object attributes themselves.

I guess that, a priori, a WebCrypto wrap/unwrap capability may or may not
encompass the attributes, but clearly since we have import/export a
wrap/unwrap function is pointless if it doesn't encompass at least
extractable. Our example explains why usages should also be included.


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

IIUC, you're asking why an encrypted JWK or PKCS#8 object isn't sufficient
as the wrapped key format (rather than using JWE).

The only reason I know is that the JWK object is not a fixed size and so
cannot be encrypted with a fixed size RSA-OAEP key (and noone likes
RSA-KEM). You need to encrypt and integrity protect with randomly generated
symmetric keys, encrypt those keys (or the key from which they were
generated) with RSA-OAEP and then format the encrypted key, encrypted
payload and integrity check into some kind of structure. JWE provides just
that.

For a symmetric key encryption key the situation is simpler. I think you
could just apply AES KW to the JWK, but the integrity protection is weak, I
think.


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

Sure. JWK has key type, algorithm and use fields. I assume they should be
populated on export and should not be ignored on import. Our proposal for
wrap/unwrap adds an extractable field to JWK.


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

That's fine. The problem is on the unwrap side. We need a primitive that
can be used to decrypt+import the CEK into a non-extractable Key object,
without there being the possibility for the JS to access the raw bytes of
the CEK.


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

As I say the point of wrap/unwrap is to deliver a key to an entity that has
the key encryption key. If the key encryption key is not itself extractable
we want to pass that property on to the keys that it unwraps. That is, they
should also not be extractable and as a consequence the keying material
should not be visible to the JS. That seems reasonable if the extractable
property has any value at all (you seem to be leaning towards an argument
which implies it does not).

Why does this mean there needs to be a distinct usage ? If there was not,
then the key encryption key could simply be used to decrypt the wrapped key
(or rather the CEK), effectively "extracting" the wrapped key, which we
have just said should not be extractable.


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

Sure. My argument above was attempting to explain why decrypt+import and
encrypt+export doesn't (quite) work for the JWE format, and thus why a
format assumption was baked in to the proposal. With some changes I could
see how a decrypt+import and encrypt+export approach could work, but it
becomes quite complex. I'm just not sure that's a good way to factor this
problem.


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

Ah, that would be because I forgot to update that when it seemed from the
list discussion that there was no demand for other formats ;-)

Note that supporting JWE-encrypted-X within the current proposal instead of
only JWE-encrypted-JWK is simple and I'd have no problem with that (if
there's a use-case). There would still be a "wrapping format" assumption,
if not a "key format" assumption. The "wrapping format" assumption is what
I address above.

So, just to be clear, there are two format assumptions: a wrapping format
where we propose JWE and a key format where we propose JWK. Supporting
multiple key formats is straightforward. Supporting other wrapping formats
is also simple to add. Re-factoring so that wrapping format becomes an
issue for the script is possible but trickier.


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

If the question is whether I could build some kind of wrap/unwrap in JS
with the properties I want using
- decrypt+import and encrypt+export primitives (attached to their own
usages) and
- the existing WebCrypto algorithms
- the existing WebCrypto key formats (including JWK with attribute mapping)

then I believe the answer is yes.

But if the question is whether I could build the JWE-protected-JWK format
in JS with these primitives the answer is no. The reasons are:
(i) the method JWE uses to wrap the CEK doesn't include attributes (yet)
(ii) we don't have a key derivation algorithm that matchs the way JWE
derives the encryption and HMAC keys from the CEK
(iii) we don't have AES Key Wrap
(iv) we don't have the AES CBC + HMAC SHA-1 authenticated encryption
algorithm specified for JWE and we can't build it out of the separate AES
CBC and HMAC SHA-1 WebCrypto algorithms (because the JS could just skip the
integrity check and so integrity protection all the way to the entity with
the key encryption key is broken).

Now, all these could be addressed: (ii) and (iii) are easy to add and for
(iv) we could just use AES GCM instead.


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


Yeah, I think this is ok. It's just something we have to consider.


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

As noted above, it's fine if I'm to craft my own wrap/unwrap format based
on the caapbilities WebCrypto offers, but WebCrypto doesn't offer the
capabilities needed to do JWE-encrypted-JWK. Not that they are hard to add.


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

I think this is answered above.


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

Ok, I can add this.


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

If you also apply that to wrap/unwrap we have a pretty fundamental
disagreement, then. (For import/export it's moot because the contents of
the JWK can be modified by the script).

Btw, I'm going to be on vacation for a week from - well, about now - so if
you don't hear much from me for a while, that will be why.

...Mark


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