W3C home > Mailing lists > Public > public-webcrypto@w3.org > May 2014

[Bug 25711] Not clear if keys persist across sessions

From: <bugzilla@jessica.w3.org>
Date: Wed, 14 May 2014 16:14:55 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-25711-7213-ep5jQ6wtGW@http.www.w3.org/Bugs/Public/>

--- Comment #1 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Kelsey Cairns from comment #0)
> It isn't clear whether key objects are intended to persist after a
> session is closed. If they do, how are they re-identified? Will the
> browser guarantee they always get the same handle? If not, are you
> supposed to re-key each time?

Also fairly certain this is an INVALID bug.

That is, each question seems to stem from a lack of understanding about the
language or operating environment. I'm curious if there is a concrete proposal
to reduce this confusion, but at the same time, the spec should be able to
reasonably assume familiarity with it's normative dependencies.

1) Do Key objects persist after a session is closed?

No, ECMAScript makes it quite clear the lifetime of objects, and HTML/DOM make
it quite clear how that applies to the top level browsing context.

Changing the top level browsing context by definition invalidates all objects.

2) If they do, how are they re-identified?

The specification provides a definition for Structured Clone Algorithm of DOM.
Structured Clone can be used with a variety of other APIs, such as Message
Ports / Message Channels / postMessage (from the DOM spec), or with storage
APIs such as IndexedDB.

The identification of Key objects is left to callers, who can apply their own
semantics (IDB storage key, associated meta-data in a postMessage)

3) Will the browser guarantee they always get the same handle?

The spec is clear that they will refer to the same cryptographic key material -
- and present the same observable object.

However, Structured Clone is quite clear that it does not require the same
equivalence in a language sense.

You are receiving this mail because:
You are on the CC list for the bug.
Received on Wednesday, 14 May 2014 16:14:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:22 UTC