Re: Charter and the NetFlix UC

On 2012-02-17 21:13, David Dahl wrote:
> Also, the current (incomplete) draft spec for DOMCrypt is here: 
> 
> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
> 
> Here is the sign and verify interface:
> 
> interface CryptoSign {
>   void sign(ArrayBuffer keyID, ArrayBuffer plainText, PKSignCallback callback);
>   void verify(ArrayBuffer signature, ArrayBuffer pubKey, ArrayBuffer plainText, PKVerifyCallback callback);
> };
> 
> The browser stores your signing keys outside the reach of the unprivileged content DOM, you only have to provide the ID of the keypair. This discussion is useful as I have not specified an additional method that will be needed: 
> 
> void GenerateSignatureKeyPair(long aAlgorithm, CSGenerateKeyPairCallback callback); // the callback is handed a keyID and publicKey
> 
> The thinking right now is that this API is bound by the same-origin policy. Which I think makes sense in order to control the scope. I am not too worried about incompatibility with older, onerous standards that are not in widespread use anyway. Perhaps I am naive? No, I know am naive, that is the only way I could have proposed this API:)

David,

I'm fine with that, it is the following part which I have issues with and as far as I can see made it to the charter

https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest

<FROMTHESPEC>

Possible Additions

One possible addition we might consider is providing the web site with a secure mechanism having the user confirm a transaction. For example, a bank web site might wish to have the user sign a
statement authorizing the transfer of funds from one account to another. Unlike the DOMCrypt APIs described above, this API involves interacting with the user to achieve non-repudiation:
1.[Supplemental]
2.interface CryptoSign {
3.void signWithUserConfirmation(in ArrayBuffer keyID, in DOMString description, in ArrayBuffer data, in PKSignCallback callback);
4.};

The signWithUserConfirmation method causes the user agent to display some user interface element containing the human-readable description. If the user confirms the description, the user agent with
sign both the human-readable description and the binary data with the key designated by the keyId and supply the signature to the caller via the callback. There are still many details to work out,
such as the format of the signed message, but this description is a starting point for discussion.

to deploy this feature to production level, we have to consider following issues.

    is passphase of private key safely entered?. means the confirmation screen need anti-keylogger mechanism.

</FROMTHESPEC>

My comments:

There is no passphrase for the keys provisioned by the rest of the API.
Is the user supposed to set the passphrase at his/her whim?
In the bank-world it is the bank who defines and enforces PIN policies.

BTW, anti-keylogger is a [desirable] platform characteristic.
It is not a part of any app-level standard mainly because it can't be
successfully dealt with at the app-level.  "Trusted GUI" is a part of
efforts trying to create securer operating systems.

"KeyID", it comes from where?

In all, this design departs considerably from similar stuff that
actually is in pretty big use, onerous or not.  They are either
server-based or client-based.  The latter are as far as I know (been
into this since 1997) exclusively relying on users having X.509 certificates.

regards,
Anders

> 
> David
> 
> ----- Original Message -----
>> From: "Ron Garret" <ron@flownet.com>
>> To: "Anders Rundgren" <anders.rundgren@telia.com>
>> Cc: public-identity@w3.org
>> Sent: Friday, February 17, 2012 1:35:10 PM
>> Subject: Re: Charter and the NetFlix UC
>>
>>
>> On Feb 17, 2012, at 11:15 AM, Anders Rundgren wrote:
>>
>>> On 2012-02-17 20:00, Ron Garret wrote:
>>>>
>>> <snip>
>>>> It is possible that the solution to all our problems is simply to
>>>> document signText.
>>>
>>> I just mentioned that there are a bunch of "standards" out there
>>> already.
>>
>> And what does the existence of "a bunch of standards" have to do with
>> what is wrong with signText?
>>
>>> If I were to create a standard I would begin with researching these
>>> to see
>>> if there is something worth stealing :-)
>>
>> So, did you?  Is there?
>>
>>> https://github.com/daviddahl/domcrypt/blob/master/demos/demo.js#L47
>>
>> All I see is a bunch of uncommented Javascript code.  How that is
>> intended to address the issue that signText is undocumented I do not
>> understand.  I might be able to back out an API by
>> reverse-engineering this code, but that would be missing the point
>> rather badly.
>>
>>> I don't know how window.mozCipher.pk.sign works but signText(v1996)
>>> uses X.509
>>> certificates which I believe what is generally requested.
>>
>> Personally, I think X.509 is part of the problem, not the solution.
>>  But that is a different issue altogether.
>>
>> rg
>>
>>
>>
> 
>

Received on Saturday, 18 February 2012 06:35:14 UTC