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

On 02/19/2013 03:11 PM, Tom Ritter wrote:
> On 19 February 2013 08:34, Emily Stark <estark@mit.edu 
> <mailto: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