Re: Beyond HTTP Authentication: OAuth, OpenID, and BrowserID: Meeting on March 29th at IETF83

On 2012-03-21 22:10, David Dahl wrote:
> ----- Original Message -----
>> From: "Jarred Nicholls" <jarred@webkit.org>
>> To: "Anders Rundgren" <anders.rundgren@telia.com>
>> Cc: "Henry Story" <henry.story@bblfish.net>, "Francisco Corella" <fcorella@pomcor.com>, "Harry Halpin"
>> <hhalpin@w3.org>, public-identity@w3.org, "Karen Lewison" <kplewison@pomcor.com>
>> Sent: Wednesday, March 21, 2012 3:17:55 PM
>> Subject: Re: Beyond HTTP Authentication: OAuth, OpenID, and BrowserID: Meeting  on March 29th at IETF83
> 
>>> Mozilla's crypto.signText () is IMO a better JS+X.509 fit than
>>> DOMCrypt.
>>> They build on quite different principles.
>>>
>>
>> DOMCrypt can be whatever we want it to be.  Nothing locks its future
>> expansions into being solely domain-based.
> 
> Indeed. There is no reason to rule out additional methods for working
> with/importing/exporting certificates. The WG is just getting started.

This sounds scary.  I hope you are wise enough to define a version #1 and get
that out of the door in time before taking on a next step which I think will
prove to be "slightly" worse.   For certificates the WG will be facing a bunch
of very different and partially competing solutions.

I still don't see that there are particularly many use-cases for addressing
certificates from *untrusted browser-code*.  My experiences with "CertEnroll"
indicates that this is a very messy thing that introduces security and privacy
issues that you don't want to deal with in future browsers.  In Windows 7
Microsoft have also added an XML-based protocol replacement.  No API.

For that very reason my two contributions to this field, WASP and KeyGen2
were designed as distinct high-level do-it-all-functions that carry out
their duties in trusted code.  This is essentially what crypto.signText ()
does as well although WASP takes it one step further by doing the sending
as well (WASP signatures are "targeted").

Anders

> 
> Cheers,
> 
> 
> David
> 
> 
>

Received on Thursday, 22 March 2012 05:59:52 UTC