Re: JWK web crypto attributes

The problem I see with that is that it's clear that Mark would see
some element of secrecy preserved with some key/attributes, so we'd
need a way to distinguish what's 'safe' to expose - ideally without
having the UA have to worry about the interpretation of the
attributes.

Do you have a proposal you'd like to make?

On Fri, Jul 26, 2013 at 1:29 PM, Jim Schaad <ietf@augutscellars.com> wrote:
>
>
>> -----Original Message-----
>> From: Ryan Sleevi [mailto:sleevi@google.com]
>> Sent: Friday, July 26, 2013 12:25 AM
>> To: Jim Schaad
>> Cc: public-webcrypto@w3.org
>> Subject: 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.
>>
>
> It was not my intent to have the values stored with the key.  It was my
> question should the values be settable as a new parameter to be passed in
> (and returned) which contains the additional fields.
>
>> >
>> > 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 Friday, 26 July 2013 21:01:39 UTC