- 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>
+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 Tuesday, 17 July 2012 15:27:53 UTC