RE: I want to have unsafe key exchange.

Yup, that sums up my thoughts as well.

-----Original Message-----
From: David Dahl [mailto:ddahl@mozilla.com] 
Sent: Tuesday, July 17, 2012 8:27 AM
To: Ryan Sleevi
Cc: Eric Rescorla; Mark Watson; GALINDO Virginie; Wan-Teh Chang; Zooko Wilcox-OHearn; public-webcrypto@w3.org; Vijay Bharadwaj
Subject: Re: I want to have unsafe key exchange.

+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 MAY 
> 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 Saturday, 21 July 2012 00:38:19 UTC