Re: Web Sigining in Action

On Thu, Mar 26, 2009 at 8:49 PM, Channy Yun <channy@gmail.com> wrote:
> Japan made own cryptographic algorithm called Camella with Nokia pushing it
> to all browsers.

Funny, I work for Nokia, on a web browser. And I don't recall being
told to care about Camella.

I also don't recall Nokia having a significant presence in Japan.

There are groups trying to get their pet crypto systems into Gecko,
but Camella isn't one that i can find. By contrast, South Korea's SEED
was added to NSS by
https://bugzilla.mozilla.org/show_bug.cgi?id=453234 (there's another
bug about exposing it in PSM, but...).

That said, this group generally doesn't want API definitions, and
every group with which I'm involved where people start w/ API
definitions suffers because it's an awful starting point.

What input is there and what output is actually needed?

<form>
<input id=author>
<textarea id=message>
<input type=submit>
<input id=signature>
</form>

Supposing you had a very simple form of this kind. Do you ever want to
sign more than one field? i.e. do you need to be able to sign the set
{author}+{message}? Or do you only need to be able to sign {message}.

I'm hoping you only need a signature on {message}.

Is there a *good* reason to allow JavaScript access to signature apis?

if we had:
<form signedfield=message>
<input id=author>
<textarea id=message>
<input type=submit>
</form>

and the browser automatically asked the user to select a key and sign
the message when the user clicked submit, would that be sufficient?

Personally, given how important my signature is, I don't really like
the idea of providing scriptable access to a signing API.

It seems like I'd want to be able to review what I'm signing.

Note that the fact that a bank wants to be able to scramble random
words together is not a good reason to provide a scriptable signing
API, nor is the fact that a bank today will be evil and use a Java
Applet or an ActiveX control.

Received on Sunday, 29 March 2009 07:41:55 UTC