W3C home > Mailing lists > Public > public-identity@w3.org > February 2012

Re: Charter and the NetFlix UC

From: Anders Rundgren <anders.rundgren@telia.com>
Date: Fri, 17 Feb 2012 21:03:03 +0100
Message-ID: <4F3EB277.8000402@telia.com>
To: public-identity@w3.org
On 2012-02-17 20:46, Richard Barnes wrote:
> Signing, by definition, uses private keys, which are associated to X.509 certificates; you cannot, however, sign something with a certificate.

I think we all know that.  However, the corresponding certificate is usually supplied with the signed data.


> 
> To address your problem directly, there are a number of problems with signText(), mainly around the assumptions it makes:
> -- The signing key is implicit (the key corresponding the client certificate used to load the page?  a smart card key?)
> -- The thing being signed is a DOMString, when it should be something like an ArrayBuffer

You mean window.mozCipher.pk.sign() right?


> 
> Note that the latter fix would also address your concerns about digital signature formats.  
> If you can sign octets, then you can implement PDF signing or XAdES.

I think you need to rephrase a bit.  If you can sign *hashed data* you can do that.

Anders

> 
> --Richard
> 
> 
> 
> 
> On Feb 17, 2012, at 2:15 PM, 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.
>>
>> If I were to create a standard I would begin with researching these to see
>> if there is something worth stealing :-)
>>
>> https://github.com/daviddahl/domcrypt/blob/master/demos/demo.js#L47
>>
>> I don't know how window.mozCipher.pk.sign works but signText(v1996) uses X.509
>> certificates which I believe what is generally requested.
>>
>> Anders
>>
>>
>>
>>
>> I doubt it, but if you disagree the way to resolve the dispute is not to argue about it but to go write some documentation.
>>>
>>> rg
>>>
>>>
>>>
>>
>>
> 
> 
> 
Received on Friday, 17 February 2012 20:03:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 17 February 2012 20:03:47 GMT