On 2012-03-21 22:10, David Dahl wrote: > ----- Original Message ----- >> From: "Jarred Nicholls" <[email protected]> >> To: "Anders Rundgren" <[email protected]> >> Cc: "Henry Story" <[email protected]>, "Francisco Corella" >> <[email protected]>, "Harry Halpin" >> <[email protected]>, [email protected], "Karen Lewison" >> <[email protected]> >> 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 > > >
