RE: Possible "key discovery" specification

> -----Original Message-----
> From: Mark Watson [mailto:watsonm@netflix.com]
> Sent: Monday, December 10, 2012 9:21 AM
> To: Ryan Sleevi
> Cc: public-webcrypto@w3.org Group
> Subject: Re: Possible "key discovery" specification
> 
> 
> On Dec 10, 2012, at 1:25 AM, Ryan Sleevi wrote:
> 
> > On Sun, Dec 9, 2012 at 11:34 PM, Mark Watson <watsonm@netflix.com>
> wrote:
> >> All,
> >>
> >> To further this discussion, I created a draft of a possible "key discovery"
> >> specification. This draft covers only named origin-specific
> >> pre-provisioned keys, since this is the case I am familiar with.
> >> However, I would see no problem extending this for other forms of key
> >> (so long as there are proponents prepared to do the implementation
> >> and specification work on the appropriate timescales.)
> >>
> >> I couldn't get this committed to a repository giving you all access
> >> via a URL, so the HTML of the specification is attached.
> >>
> >> Best regards,
> >>
> >> Mark
> >>
> >>
> >>
> >
> > Mark,
> >
> > Thanks for this. We should make sure you have appropriate Mercurial
> > access (everyone in the WG should).
> >
> > A few thoughts:
> > 1) KeyArray seems to implement a read-only pseudo-array. It seems like
> > you could just have the IDL say "void complete(Key[] keys)", and let
> > it be a "Real" array type. After all, once it's returned to the
> > caller, just let them treat it like a normal array type (and do things
> > like slice and splice and whatever other array modification they want)
> 
> Ok.
> 
> > 2) There's no form of error feedback (eg: an onerror callback). It
> > would seem applications would have to, at best, guess by using
> > .setTimeout(). Is that intentional?
> 
> Yes and no. It's intentional that there's no error callback. But the intention is
> that the single callback will always be called, possibly with an empty list.
> 
> I'm not sure there are any "error" cases as such. Either the key can be found,
> or it cannot (for some reason). Can you think of any cases where we want to
> expose the difference between key-not-found and some error case ? Are
> there any "temporary" errors that might be resolved by retrying ?
[Acar, Tolga] 
If a key is found by name matching, but there is an error in reading the key (file permissions, storage problems, parsing problems, platform-dependent key validation problems), it would be good to know the error code for diagnosis and perhaps remedial action by an app.

> 
> > 3) It's not available to Workers, as I understand it. Perhaps you
> > could have WorkerContext implement WindowCryptoKeys, although I'm
> not
> > sure how SharedWorkerContext behaves there.
> 
> Are you proposing that it should be available to Workers ? (btw, how is the
> Crypto object itself made available to Workers, or is it ?)
> 
> > 4) Having getKeysByName() return multiple keys seems a little
> > confusing. For example, if getKeysByName({ name: 'myKey', ... }), and
> > I get two keys back:
> >  4.a) Are they ordered in a particular order. For example, is
> > keys.get(0) always going to be the public key, and keys.get(1) always
> > going to be a private key?
> >  4.b) Are they supposed to be disambiguated via another means (such as
> > an id attribute?). In the latest ED, I removed the ID attribute
> > because it doesn't quite fit in the realm of 'arbitrary keys and
> > arbitrary key storage'.
> >
> > One way to resolve this might be
> > interface NamedKey : Key {
> >  readonly attribute DOMString name;
> >  readonly attribute DOMString id;
> > };
> 
> I assumed they would have attributes that disambiguated them, but the
> NamedKey suggestion is better.
> 
> >
> > With supporting text to provide clarification on what name contains
> > and what ID contains (as well as structured clone definition, I
> > believe)
> >
> > With Key being structured cloneable, I just want to confirm that it's
> > fine if someone does a .getKeysByName(...), gets a series of Key (or
> > NamedKey) objects back, and then sticks them into IndexedDB. At that
> > point, they "never" have to call getKeysByName() again, unless
> > IndexedDB is cleared. That seems a nice "feature", but I wasn't sure
> > if your use case dictated that Key/NamedKey objects returned by this
> > should NOT be structured cloneable. If so, we'll have to proceed
> > carefully here.
> 
> Yes, the intention is that you can structured clone these like any other Key.
> The only constraint with pre-provisioned keys is that the keying material
> itself stays where it is, but structured clone doesn't move the keying
> material, IIUC.
> 
> btw, I must say I find the structured clone algorithm itself rather abstruse. Is
> there any material which explains why it is the way it is ? (the 'structured
> clone' and 'internal structured clone algorithm' links in your draft don't go
> anywhere).
> 
> >
>

Received on Monday, 10 December 2012 18:55:25 UTC