Re: ISSUE-30: Key import/export?

The API presently makes no statements about certificates, which I
strongly believe is a good thing.

If JOSE were to adopt that proposal (which, I believe, there is still
a lack of consensus on), then it would simply mean that the ability to
import a Key object derived from Certificates would exist. This would
be functionally equivalent to importing an SPKI - although it would
also permit key types where algorithm parameters may be inherited from
the certificate chain, for example.

On Mon, Feb 25, 2013 at 4:18 PM, Mountie Lee <mountie@paygate.net> wrote:
> If JWK wrap PKIX certificate as drafted in
> http://tools.ietf.org/id/draft-miller-jose-pkix-key-00.html
> how the certificate can be validated when imported?
>
>
>
>
>
> On Tue, Feb 26, 2013 at 5:52 AM, Ryan Sleevi <sleevi@google.com> wrote:
>>
>> On Mon, Feb 25, 2013 at 12:44 PM, Harry Halpin <hhalpin@w3.org> wrote:
>> > Now, if we don't have key import/export, it seems to me it seems we're
>> > limiting ourselves to ephemeral keys generated in the JS by the same
>> > origin.
>> > Since we have no multi-origin policies and same-origin is the de-facto
>> > way
>> > to do this, I'm happy with that.
>> >
>> >  In the spec now, there is just a place-holder:
>> >
>> > "
>> > 15.2.8. The importKey method
>> >
>> > 15.2.9. The exportKey method"
>> >
>> >  Nonetheless, I think a key import/export function might be useful.
>> > High-level libraries like Keyczar do key import/export, see their
>> > Encrypter
>> > method [1]. Could we do something similar and just lean on the File API
>> > to
>> > do the reading of keys [2], with a check to make sure the file is a
>> > valid
>> > bytestream or serialized JOSE key. That would also cause a dependency on
>> > the
>> > File API. Arun, when is the File API supposed to go to Rec?
>>
>> I do not think it at all necessary to depend on the File API.
>>
>> The issue with Import/Export, as raised on previous calls, was the
>> interaction between the key formats (ASN.1, JOSE, etc) and
>> supplementary parameters. In an earlier proposal, Netflix raised a use
>> case where they wanted wrapped keys which could then provide arbitrary
>> parameters, with a proposal of extending the JWK format to provide
>> associative name/value pairs. This has been retracted in the Named
>> Keys proposal, and support for arbitrary key parameters is no longer a
>> primary issue with format.
>>
>> I don't know of anyone who has proposed removing import/export
>> support. There is simply the question about the exact semantics and
>> formats.
>>
>> Requiring a JWK format is useful for some cases, but EXTREMELY
>> developer hostile for others. Likewise, requiring ASN.1 is useful for
>> some cases, but EXTREMELY developer hostile for others.
>>
>> If your concern is the lack of normative text, that's because the
>> normative text was not written while we still worked out the issues in
>> the IDL:
>>
>>   KeyOperation importKey(KeyFormat format,
>>                          ArrayBufferView keyData,
>>                          AlgorithmIdentifier? algorithm,
>>                          bool extractable = false,
>>                          KeyUsage[] keyUsages = []);
>>   KeyOperation exportKey(KeyFormat format, Key key);
>>
>> >
>> > The hard issue is how this interfaces with same-origin and privacy. Two
>> > thoughts:
>>
>> I don't know why you say that. These are not issues that have been
>> raised in any discussion of import or export. Perhaps you
>> misunderstand?
>>
>> >
>> > Re privacy, I think we should say that if the key-material is a private
>> > key,
>> > moving it into structured clone localStorage/indexedDB should require a
>> > user
>> > prompt, and leave it to the implementer to define the security/privacy
>> > message to be stated.
>>
>> I disagree. There should be no need for any prompt.
>>
>> >
>> > Re same-origin, we could state that if the key is imported by explicit
>> > user
>> > selection (i.e. see privacy), then the key is treated as if it were
>> > generated by same-origin of the JS that called the File API to import
>> > the
>> > key. In export, we don't worry about it. Thus we don't have to deal with
>> > same origins. Thus we can still close ISSUE-19/ISSUE-26.
>>
>> I don't know why you see there being any requirement for user
>> selection. These are key bytes being imported. There is no magical UI
>> involved.
>>
>> >
>> > Before writing a WebIDL, I wanted a sanity-check on the thinking.
>>
>> The Web IDL is already written. See
>>
>> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#subtlecrypto-interface
>>
>> It's been written since the FPWD - see
>> http://www.w3.org/TR/WebCryptoAPI/#crypto-interface
>>
>> >
>> >    cheers,
>> >    harry
>> >
>> > [1]http://www.keyczar.org/javadocs/index.html?org/keyczar/Encrypter.html
>> > [2]http://www.w3.org/TR/FileAPI/
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>
>
>
> --
> Mountie Lee
>
> PayGate
> CTO, CISSP
> Tel : +82 2 2140 2700
> E-Mail : mountie@paygate.net
>
> =======================================
> PayGate Inc.
> THE STANDARD FOR ONLINE PAYMENT
> for Korea, Japan, China, and the World
>

Received on Tuesday, 26 February 2013 00:25:57 UTC