Re: Proposal for key wrap/unwrap (ISSUE-35)

On Mar 4, 2013, at 1:19 PM, Ryan Sleevi wrote:

On Mon, Mar 4, 2013 at 1:03 PM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:
All,

We didn't have time to discuss this on the call. I have updated the proposal
at: http://www.w3.org/2012/webcrypto/wiki/KeyWrap_Proposal

There are a few things we need to discuss. Perhaps we can make progress on
over email. From the Overview:

We propose that key wrapping in the WebCrypto API be supported through the
use of JWE-protected JWK objects [5] [6]. We propose specific algorithms for
wrapping with AES keys and with RSA-OAEP keys.
The following issues require discussion with the Working Group:

Should the JWE object be passed to/from the UA in serialized form, or as a
Javascript object ? In serialized form, it could be either the Compact
Serialization or the JSON serialization. In object form, it would be a
Javascript object that would JSON-serialize into the "JSON Serialization" of
JWE
For wrapping with RSA-OAEP keys, JWE works by RSA-OAEP encrypting a
symmetric Content Master Key which is then used to encrypt/integrity protect
the payload. Where should we specify the encryption/integrity protection
algorithm (likely A128CBC+HS256 or A128GCM) ? Possibly there should be an
additional member in the parameters object used with generateKey when
generating an RSA-OAEP wrapping key.
If the above parameter is added to the "RSA-OAEP wrapping" key type, how
should it be encoded into JWK when such keys are exported ? (including when
they themselves are wrapped)
For wrapping with RSA-OAEP keys, JWE allows the public key to be included in
the JWE header, to assist in identification of the private key needed to
perform unwrapping (in the jwk member of the header). How should we specify
during wrapping whether to include the public key ? (Note that if the answer
to (1) is object form, then we could always include the public key and the
script could just remove it before serialization if it wanted to).
The compatibility and mapping between WebCrypto algorithm names and JOSE
algorithm names needs to be defined (as it does for import/export as well)

[Switching to text for archives]

The mapping between the WebCrypto Key attribute "extractable" and a JWK
equivalent needs to be defined
The compatibility and mapping between WebCrypro Key attribute 'usages' and
the JWK equivalent needs to be defined

I'm not sure I understand these last two points. Is this because you
expect them to be protected attributes (eg: defined by the one who
does the wrapping), rather than by unprotected attributes (eg: defined
by one who does the unwrapping)?

Yes.


If you do expect them to be protected, I think there would need to be
a fairly clear use case / threat model as to why and what benefits.

This is described in our use case: http://www.w3.org/TR/webcrypto-usecases/#video-service

The session keys are delivered wrapped and are unwrapped using the pre-provisioned key. The browser implementation is trusted in this case by the service provider (at least more than the JS application, which could more easily have been modified). The trust in the browser implementation is based on knowledge of the system into which the pre-provisioned key was placed (a combination of the difficulty of migrating that key or of modifying the software on the device which originally got the key).

Every assumption about the API so far has been that the web page
interacting with the API is part of the trust zone. The "Key
Discovery" API introduces the first deviation from that assumption (in
that it has keys that the application doesn't know about and cannot
access), but this seems further along that path, and I think it should
be spelled out.

Yep, it's been spelled out in our use-cases from the very beginning of the WebCrypto Working Group: the whole point of the pre-provisioned keys is to bootstrap some kind of trust in the UA and key unwrapping enables this trust to be propagated into the temporary session keys.

…Mark


Otherwise, if it's something done by the unwrapper, then there doesn't
need to be any JWK/JWE aspects - it's an API parameter, pure and
simple.




…Mark


On Mar 1, 2013, at 5:02 PM, Vijay Bharadwaj wrote:

Sounds like a reasonable approach.

From: Mark Watson [mailto:watsonm@netflix.com]
Sent: Friday, March 1, 2013 4:36 PM
To: Vijay Bharadwaj
Cc: Ryan Sleevi; public-webcrypto@w3.org<mailto:public-webcrypto@w3.org> Group
Subject: Re: Proposal for key wrap/unwrap (ISSUE-35)


On Mar 1, 2013, at 9:53 AM, Vijay Bharadwaj wrote:


I've been looking at key wrap formats lately. My observations based on
having maintained crypto APIs:

1. More wrapping formats means more confusion for developers and pain for
vendors.
2. Having wrapAlgorithm be a separate option on the import interface leads
to various opportunities for inconsistency, since key wrapping formats
include varying amounts of metadata. It is better to have import only deal
with formats that are self-describing.

So given that we generally look to JOSE for high-level formats, I'd like to
propose using JWE encapsulation for the wrap/unwrap formats, and removing
the wrapAlgorithm parameter (and perhaps keyAlgorithm, though this needs
more thought) from createKeyImporter in Mark's proposal.

A good starting point seems to be the JWE-protected JWK I-D at
https://datatracker.ietf.org/doc/draft-miller-jose-jwe-protected-jwk/?include_text=1

Three simple example usages of this format to illustrate what I expect will
be the most common use cases:

1. For RSA wrapping: Proceed as in Section 5 of the above I-D. JWE header
has alg set to RSA-OAEP, and jwk.kty set to RSA. Most people would likely
use enc of A128CBC+HS256 or A128GCM.

2. For wrapping a key using AES: JWE header has alg set to dir, and enc as
in #1. In this case the jwk element in the header is not necessary. This
allows the use of any authenticated encryption mode, not just AES key wrap.
This seems to be in line with the current consensus of the cryptographic
community - NIST has also Approved the use of authenticated encryption modes
for key wrapping:
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf


3. For working with existing legacy formats such as PKCS#8: JWE header has
alg set to dir, and enc set to the appropriate value (e.g. "pkcs-8" in this
case).


IIUC, alg=dir means only that the symmetric Content Master Key (used to
derive the Content Encryption Key for encrypting the JWE-payload) is
pre-shared, rather than being encrypted and communicated in the JWE.

The enc parameter stands for "encryption" not "encoding", so it's assumed in
JWE that the content is always encoded (either with a CEK derived from a
pre-shared CMK - alg=dir - or with a CEK derived from a CMK communicated in
encrypted form in the JWE itself).

So - at least based on my reading - it doesn't make sense to use JWE to
carry unencrypted PKCS#8 format data for key import/export, though I guess
you could specify enc = null - i.e. no encryption applied.

The data type of the payload carried by the JWE can be specified in the
"cty" (Content Type) member, which can be a MIME type, but usually you
assume that the recipient is expecting a given data type. For our
wrap/unwrap this would be implicitly a (serialization of) JWK, but I suppose
we could use cty values to indicate that the payload is a PKCS#8 object etc.
But this all feels rather messy.

So, for the moment, I am leaning towards keeping import/export separate -
with the import/export format indicated in a KeyFormat parameter. I'll
update the proposal so that wrap/unwrap always expect a JWE: we will need to
decide whether this is the Compact Serialization (passed as an
ArrayBufferView) or the JSON Serialization (passed as an ArrayBufferView) or
the JSON Serialization unserialized into a Javascript object (which could be
defined in IDL as an explicit Dictionary Type that mirrors JWK-in-JWE).

If, after we have fleshed out wrap/unwrap, we can see a clean way to make
plain import/export sub-cases of that, then we can consolidate the
operations into one pair of methods.

Ryan makes a good point that translation between the different JWE
serializations in Javascript is made ugly by the use of base64url (instead
of plain base64). Another example of a simple data transformation function
that is currently missing from the Web APIs. It would be nice to have zip as
well...

…Mark




The nice thing about this mechanism is that it's web-developer friendly, and
adds minimal overhead for the case of the legacy formats.

Thoughts? If people are okay with the general idea, I can work with Mark to
revise the proposal as per our action item from the last meeting.

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Monday, February 25, 2013 1:51 PM
To: Mark Watson
Cc: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org> Group
Subject: Re: Proposal for key wrap/unwrap (ISSUE-35)

On Mon, Feb 25, 2013 at 1:18 PM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:



________________________________________

From: Ryan Sleevi [sleevi@google.com<mailto:sleevi@google.com>]

Sent: Wednesday, January 16, 2013 7:13 PM

To: Mark Watson

Cc: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org> Group

Subject: Re: Proposal for key wrap/unwrap (ISSUE-35)



Can you provide more design rationale for choosing RSA-KEM, rather

than the much more widely supported RSA-OAEP (eg: RFC 3560). I don't

know of a single well-tested, CORRECT implementation of RSA-KEM in the

popular cryptographic libraries and bindings.



MW> Ryan, we looked in detail at RSA-OAEP key transport and there is an
issue in that it does not support payloads of arbitrary size - as required
for JWK format payloads. At least not without using RSA keys of arbitrary
size.


I'm not sure I follow. In the JOSE space, you perform an RSA-OAEP transport
of the CMK, and the CMK protects the message. This is conceptually similar
to RSA-KEM.

Certainly, given that OAEP, but not KEM, is supported by JOSE, it seems more
in line with your needs?




Do you have any other suggestions for RSA-based key wrap/unwrap ?



We also looked in detail at RSA-KEM and it doesn't look so bad after all. In
fact it's much easier to understand than the RSA-OAEP documentation.



...Mark