On Wed, Nov 20, 2013 at 2:40 PM, Benjamin Smedberg <benja...@smedbergs.us>wrote:
> 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?
>
The prompt part is not needed to be provided by WebCrypto. In the latest
releases, the prompt part has been taken care of our plugin. However, in
our new prototype, the scripting UI part (Dojo) will take care of it. Apart
from the good effect of having the same look and feel, we get rid of a
nasty issue related to the modal dialog displayed by the plugin; which is
giving us some instability headaches.
>
> 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.
Supporting CAPI on Windows and KeyChain on OSX is definitively a win,
regardless of honoring or not system root certificates. In our sector, our
customers have own PKI with own root CAs and intermediary CAs. And if they
are not own ones, they are created and controlled by governmental or alike
organizations.
>
>
>
>>
>>> 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.
Yes, that's what we are afraid of. In that case, Mozilla will be in a very
good position if CAPI/KeyChain/etc are supported by WebCrypto. Once we
explain the situation to our customers that demand Chrome support, they
will understand why Firefox is an option and why Chrome is not.
>
>
>> 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?).
>
That's good to know. That means that we can continue with our current
roadmap and that we will continue working on our new plugin prototype.
I need to check one more thing. We've heard of js-ctypes. However, you
mostly talk about WebCrypto. Our js-ctypes knowledge is pretty limited. We
know that it is only supported by Mozilla. We really do not know whether we
could use it. The first reaction of our client-side developers showed that
it was not that popular after reading some Mozilla docs ( the "lib.declare(
"MessageBoxW"... example scared them a bit as client-side developers are
not necessarily used to dll methods declarations and stuff like that.
Nothing impossible to overcome, though; cooperation between different areas
of knowledge needed). In any case, my feeling from your words is that the
way to go is to use WebCrypto, once it is available. Is this perception
right? And btw, is WebCrypto an only-Mozilla thing?
/FMA
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
