Re: ISSUE-30: Key import/export?

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