W3C home > Mailing lists > Public > public-webcrypto@w3.org > July 2012

Re: I want to have unsafe key exchange.

From: David Dahl <ddahl@mozilla.com>
Date: Tue, 17 Jul 2012 08:27:18 -0700 (PDT)
To: Ryan Sleevi <sleevi@google.com>
Cc: Eric Rescorla <ekr@rtfm.com>, Mark Watson <watsonm@netflix.com>, GALINDO Virginie <Virginie.GALINDO@gemalto.com>, Wan-Teh Chang <wtc@google.com>, Zooko Wilcox-OHearn <zooko@leastauthority.com>, public-webcrypto@w3.org, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
Message-ID: <1586445487.12370107.1342538838984.JavaMail.root@mozilla.com>
+1, an excellent summary.

----- Original Message -----
> From: "Ryan Sleevi" <sleevi@google.com>
> To: "Vijay Bharadwaj" <Vijay.Bharadwaj@microsoft.com>
> Cc: "Eric Rescorla" <ekr@rtfm.com>, "Mark Watson" <watsonm@netflix.com>, "GALINDO Virginie"
> <Virginie.GALINDO@gemalto.com>, "Wan-Teh Chang" <wtc@google.com>, "David Dahl" <ddahl@mozilla.com>, "Zooko
> Wilcox-OHearn" <zooko@leastauthority.com>, public-webcrypto@w3.org
> Sent: Monday, July 16, 2012 7:21:30 PM
> Subject: Re: I want to have unsafe key exchange.

> >From reading the replies, it seems like most everyone on this thread
> is in agreement, but we may be talking past eachother.
> In working out the state machine for how key generation works, my
> thought is:
> Handling for generate() method [as part of the KeyGenerator
> interface]
> - If "privateKeyMaterial" is not supplied, then it will be
> initialized
> to the default value of "false"
> - If "privateKeyMaterial" is equal to "false", then whether or not
> the
> key material will be accessible is IMPLEMENTATION-DEFINED. Future
> calls to ("raw key" method) MAY return the raw keying material, or
> return NULL.
> - If "privateKeyMaterial" is equal to "true", then the implementation
> MUST allow access to the keying material for as long as the key
> handle
> remains available/discoverable by the application. If the
> implementation cannot do so, it MUST fail the key generation
> operation.
> For key discovery:
> - If the application provisioned the key via generateKey(), and
> specified "true" for "privateMaterialAccess", then the ("raw key"
> method) MUST be implemented and MUST return the raw keying material
> that was previously generated via generateKey().
> - For all other cases, then the ("raw key" method) MAY be
> implemented.
> If the raw keying material is not available, it MUST return null.
> I'm 100% in favour of implementation-defined storage. For example,
> the
> browser may decide to store the key in a plaintext file on disk, for
> a
> pure software implementation. It may decide (likely based on some
> form
> of user input) to store the key in protected storage - whether the OS
> store or a secure element/TPM.
> The only requirement/guarantee is that if an application says it
> requires raw key material, then that raw key material will be
> accessible to that application for the lifetime of that key, or the
> operation should fail.
Received on Tuesday, 17 July 2012 15:27:53 UTC

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