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

Urgh, I can't use email. I sent this to Tom at the exact same moment
as Harry's reply, but will paste to the whole list even though it's a
bit redundant with Harry's points:

> I haven't seen a use case that convinced me we need a sign() function, and
> encryptAndSign() won't do.  Could you provide some examples where a messages
> *requires* authenticity but also *cannot* have confidentiality, particularly
> if we're talking about mostly-opaque data values?

Are you asking for use cases that could be accomplished with sign()
but could not be accomplished with encryptAndSign()? I don't expect
there are many of those out there... I think the more relevant class
of use cases is those that where sign() would suffice and using
encryptAndSign() instead adds performance overhead or complexity. For
example, I could imagine adapting the web-based messaging use case
that's in the current spec to just provide signatures and not
encryption, so that the server can still process the messages (e.g.
allow users to search their messages on the server). Using
encryptAndSign() instead of sign() would require the server to store
two copies of each message (plaintext and ciphertext). So of course
only having encryptAndSign() would not make the use case impossible,
but it would be a significant storage overhead over sign().

On Tue, Feb 19, 2013 at 9:38 AM, Harry Halpin <hhalpin@w3.org> wrote:
> On 02/19/2013 03:11 PM, Tom Ritter wrote:
>
> On 19 February 2013 08:34, Emily Stark <estark@mit.edu> wrote:
>>
>> 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 also thought they should be removed.  My argument is simplicity.  While it
> is true other libraries expose a 'sign' function, our goal for this High
> Level API is to make it as simple to use as possible.  Part of that includes
> making it as minimal as possible.
>
> I haven't seen a use case that convinced me we need a sign() function, and
> encryptAndSign() won't do.  Could you provide some examples where a messages
> *requires* authenticity but also *cannot* have confidentiality, particularly
> if we're talking about mostly-opaque data values?
>
> *Cannot* may be a bit strong. Perhaps better is "is there a use-case for
> signatures without encryption?"
>
> Here's a few off the top of my head:
>
> 1) OAuth tokens with digital signatures being passed around over TLS need to
> be authenticated, but can rely on the transport layer for opacity.
>
> 2) In open public data, use-cases likely exist where you may want to sign
> some data in an authorized WebApp and paste it on the Web, but make it
> available to the public on a domain you own. Of course, a malicious party
> could copy your data and place their own signature on it, but not on the
> domain you own. This has been discussed in context of data.gov.uk.
>
> 3) Also, cases were verifying the signature is less computationally
> expensive than encrypt/decrypt and there are performance constraints. I
> imagine that might come up, but can't think of any real concrete ones.
>
>
> -tom
>
>

Received on Tuesday, 19 February 2013 14:41:49 UTC