Re: JWK web crypto attributes

On Thu, Jul 25, 2013 at 3:19 PM, Jim Schaad <ietf@augustcellars.com> wrote:
>
>
>> -----Original Message-----
>> From: Ryan Sleevi [mailto:sleevi@google.com]
>> Sent: Monday, July 22, 2013 6:43 PM
>> To: Jim Schaad
>> Cc: public-webcrypto@w3.org
>> Subject: Re: JWK web crypto attributes
>>
>> On Mon, Jul 22, 2013 at 4:27 PM, Jim Schaad <ietf@augustcellars.com>
>> wrote:
>> > It would be useful for the JOSE working group if there could be a
>> > decision about what attributes need to be defined in the JWK document
>> > for import/export of keys before the F2F meeting next week.
>> >
>> > If we are just going to define them in the W3C document it is not an
>> > issue and we can take care of that when this document goes final.
>> >
>> > As of now, I am assuming that two possible attributes are needed:
>> >
>> > Extractable - which takes a true/false value Name - which takes a
>> > string value and allows for a key to be named in the event it is to be
>> > saved.  (Currently not clear to me if keys are named at the time of
>> > import or at the time they would be saved into the database).
>> >
>> > Jim
>> >
>> >
>> >
>>
>> I believe Mark has previously indicated that both extractable and usages
> are
>> needed.
>>
>> Currently, 3.2 of JWK-draft-13 (
>> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-13#section-3.2
>> ) only supports 'sig' and 'enc'. It specifies other values MAY be used,
> but the
>> field only supports a SINGLE usage, whereas WebCrypto keys may support
>> MULTIPLE usages.
>>
>> So if we go that route, "use" may need to change - especially in light of
>> public/private keys anyways (eg: decryption-only keys)
>>
>> I don't understand why Name is needed - WebCrypto Key objects have no
>> such property, and the other spec indicates they're *Pre-Provisioned*
> keys.
>>
>> For WebCrypto Key objects, they're structured cloned into other storage -
> eg:
>> IndexedDB - and the IDB key (of key-value pair) may be used to describe
> the
>> name - or any number of other ways of storing name/value pairs that store
> a
>> keys name, without requiring it in the JWK or WebCrypto.
>>
>> So -1 to standardizing name. Especially given "kid".
>
> Is there any requirement to be able to set and/or retrieve other attributes
> directly from Wrap/Unwrap?  While kid exists, it is not directly retrievable
> by a call to Unwrap.

I'd definitely be opposed to exposing attributes on keys, because that
creates yet another key-value storage mechanism. A Key object is NOT
meant to be a 1:1 equivalent for a JWK.

>
> Also was wondering if there is any requirement to be able to export a key
> pair so that you can get both the public and private halves of an asymmetric
> key in one shot?  My guess is this is not a current requirement.
>
>

Not only is that not a requirement, it's explicitly incompatible with
the design - which is that the public and private keys are distinct
Key objects. Asymmetric key generation uses a KeyPair return - a pair
of keys.

So you would not do an exportKey(pubKey) and get an RSA key. Nor is
exportKey([pubKey, privKey]) a reasonable format - in that it does not
map at all to any of the formats (SPKI = pub only, PKCS#8 = priv only.
JWK != JWKSet, so it's pub || priv, but not both)

Received on Thursday, 25 July 2013 22:25:09 UTC