On 11/20/2013 3:10 AM, fma spew wrote:
Our customers' end-users have their end-user certificates stored in the
"Personal logical certificate store" on Windows. The rest of needed
certificates, ("Intermediary" and/or "Trusted Root Certificates") are also
stored on Windows certificate stores. Our plug-in allows the end-user to
choose one of those "Personal" certificates and create digital signatures.
ok, there are several different actions here:
* get access to a personal signing certificate
* sign a document with it
I'm pretty sure that WebCrypto will have a way so sign a document with a
certificate. It's not clear to me whether WebCrypto as currently specced
also has a way to prompt the user to access personal certificates.
bsmith/ekr, do you know what the capabilities are?
It seems like a clear win to me for our cryptosystem to be able to
access certificates in CAPI, whether or not we honor the system root
certificates by default or not. This could also be used with the
existing system of HTTPS client certificates, which is seldom used on
the web currently primarily because the UI sucks.
3- We haven't found any indication of Mozilla about alternatives for these
kind of plug-ins, meaning plug-ins that need access to, in this case,
Windows stuff. Google has provided alternatives though.
Can you be more specific about the alternatives in Chrome?
I was referring to NaCl. We have not tested yet using CAPI to get to
Personal certificates from NaCl. So we do not know yet whether this case
falls into the "unsafe activities" that NaCl prevents (see
https://developers.google.com/native-client/overview#common-use-cases).
From what I know of NaCl, you won't be able to get outside the sandbox
and access any system libraries, so unless Chrome makes client
certificates available to you via API, it won't help this use case.
We might have wrongly interpreted Mozilla's position and plan regarding the
support of NPAPI. Our perception was that even Mozilla was thinking about
phasing out NPAPI in the near future (end of 2014) and that no alternative
technology was present.
This is simply not true, it is FUD spread by Chrome developers who ought
to know better. We believe NPAPI plugins are a legacy technology, and we
want to build the web platform so that plugins aren't necessary. We also
have security and stability issues with common plugins, and so we have
designed the opt-in click to activate mechanism so that users are aware
of the third-party code running in their browser. But for desktop
Firefox, NPAPI is likely to be around for the predictable future (three
years?).
--BDS
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
