Re: An initial editor's draft: high-level API

On 02/19/2013 03:35 PM, David Dahl wrote:
> ----- Original Message -----
>> From: "Emily Stark" <estark@MIT.EDU>
>> To: "Aymeric Vitte" <vitteaymeric@gmail.com>
>> Cc: "Ryan Sleevi" <sleevi@google.com>, "David Dahl" <ddahl@mozilla.com>, public-webcrypto-comments@w3.org
>> Sent: Tuesday, February 19, 2013 7:34:22 AM
>> Subject: Re: An initial editor's draft: high-level API
>>
>> I was wondering if we could revisit sign/verify. I'm curious to hear
>> why Adam Langley thought these should be dropped; I understand that
>> messages can be signed with encryptAndSign, but it seems wasteful and
>> confusing to always require encryption along with signatures. NaCl,
>> KeyCzar, and SJCL all have sign()/verify() (as well as MACs) that
>> don't also require the user to encrypt/decrypt.
>>
> I was deferring to the smallest footprint possible. I would not be opposed to re-introducing them.
>
>> Also, a couple things about seal/open:
>> 1.) Could seal() explicitly be defined as authenticated encryption
>> instead of just symmetric encryption?
> It certainly could. The intention here is (mainly) encrypting locally-stored data, so I left it out thinking the interface would become complex. I imagine we could hide the details of the authentication with an implied signing key pair created for each host and used behind the scene.
>
>> 2.) This is pedantic, but once I saw seal() I started looking for
>> unseal() and took me a minute to realize that open() was what I
>> should
>> be looking for. Is there any reason not to use seal/unseal instead of
>> seal/open?
> Naming *is* hard.:) I think Adam Langley suggest seal/open based on other APIs.

FYI, I'm against this "seal/box" metaphor. Programmers at this point 
generally know what encrypt/decrypt/sign and verify are, even if they 
don't know details of algorithms. Re-naming them I think only confuses 
people.
>
>> 3.) Why does seal generate a fresh key each time instead of having a
>> createKey function? This seems like it could cause extra complication
>> for developers; NaCl/SJCL allow you to specify a key to use for
>> symmetric encryption.
>>
> Again, this is for utter simplicity, the key is generated and used and the dev does not need to know the details. We could add an optional symKey argument, a JSON Web Key.

This is related to ongoing import/export key being an open issue I 
believe - i.e. do we limit ourselves to ephemeral keys (with edge-case 
for symmetric pre-provionsed) or not?
>
> Regards,
>
> David
>
>> On Tue, Jan 29, 2013 at 5:21 AM, Aymeric Vitte
>> <vitteaymeric@gmail.com> wrote:
>>> Le 28/01/2013 22:56, Ryan Sleevi a écrit :
>>>
>>>>>> 7) You make use of DOMString in the following methods:
>>>>>>>>    a) encryptAndSign (aPlainText)
>>>>>>>>    b) protect (aPlaintext)
>>>>>>>>    c) unprotect (aPlaintext - see 5)
>>>>>>>>    d) sign (aClearData)
>>>>>>>>    e) verify (aDataToVerify)
>>>>>>>> How is this data supposed to be canonicalized? How is
>>>>>>>> arbitrary
>>>>>>>> binary
>>>>>>>> data supposed to be encoded? What about decoded?
>>>>>> While I would like to make the interface as simple as possible
>>>>>> (using
>>>>>> strings), this is an issue that may require the use of
>>>>>> ArrayBufferViews
>>>>>> after all. I am unsure how to make DOMStrings viable here.
>>>> http://encoding.spec.whatwg.org/  ?
>>>>
>>> If this can help, simple example here
>>> (https://github.com/Ayms/node-typedarray) how to use ArrayBuffers,
>>> TextEncoder/Decoder, and make all this more "high-level".
>>>
>>> --
>>> jCore
>>> Email :  avitte@jcore.fr
>>> iAnonym : http://www.ianonym.com
>>> node-Tor : https://www.github.com/Ayms/node-Tor
>>> GitHub : https://www.github.com/Ayms
>>> Web :    www.jcore.fr
>>> Webble : www.webble.it
>>> Extract Widget Mobile : www.extractwidget.com
>>> BlimpMe! : www.blimpme.com
>>>
>>>
>>
>> On Tue, Jan 29, 2013 at 5:21 AM, Aymeric Vitte
>> <vitteaymeric@gmail.com> wrote:
>>> Le 28/01/2013 22:56, Ryan Sleevi a écrit :
>>>
>>>>>> 7) You make use of DOMString in the following methods:
>>>>>>>>    a) encryptAndSign (aPlainText)
>>>>>>>>    b) protect (aPlaintext)
>>>>>>>>    c) unprotect (aPlaintext - see 5)
>>>>>>>>    d) sign (aClearData)
>>>>>>>>    e) verify (aDataToVerify)
>>>>>>>> How is this data supposed to be canonicalized? How is
>>>>>>>> arbitrary
>>>>>>>> binary
>>>>>>>> data supposed to be encoded? What about decoded?
>>>>>> While I would like to make the interface as simple as possible
>>>>>> (using
>>>>>> strings), this is an issue that may require the use of
>>>>>> ArrayBufferViews
>>>>>> after all. I am unsure how to make DOMStrings viable here.
>>>> http://encoding.spec.whatwg.org/  ?
>>>>
>>> If this can help, simple example here
>>> (https://github.com/Ayms/node-typedarray) how to use ArrayBuffers,
>>> TextEncoder/Decoder, and make all this more "high-level".
>>>
>>> --
>>> jCore
>>> Email :  avitte@jcore.fr
>>> iAnonym : http://www.ianonym.com
>>> node-Tor : https://www.github.com/Ayms/node-Tor
>>> GitHub : https://www.github.com/Ayms
>>> Web :    www.jcore.fr
>>> Webble : www.webble.it
>>> Extract Widget Mobile : www.extractwidget.com
>>> BlimpMe! : www.blimpme.com
>>>
>>>
>>
>>

Received on Tuesday, 19 February 2013 14:40:17 UTC