On Sat, Nov 9, 2013 at 5:13 PM, Benjamin Smedberg <benja...@smedbergs.us>wrote:
> On 11/8/2013 4:33 AM, fma spew wrote:
>
>> We have a npapi-npruntime plug-in that access the Windows certificate
>> store
>> via CAPI to provide the end-user with its personal certificates to perform
>> different operations.
>>
> What is the use case you're solving? Are you trying to install a
> personal/client certificate that the user can use again in the future? Or
> is this a server certificate that isn't signed using normal root servers?
No, neither installing nor it is such a server certificate. I will try to
elaborate more.
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.
Our plug-in uses CAPI to get to the "Personal" store. Then it opens a
dialog that lists the end-user certificates. The end-user selects one of
the certificates and a digital signature is created from the provided
data-to-be-signed.
So we do not make use of NSS. The reason is customer-driven: they use the
certificates for other purposes as well and the Windows certificate store
is a central storage point from where other Windows applications can access
those certificates. Replicating on NSS db would only need complexity to the
management tasks. According to our surveys, it is simply not viable.
>
>
> We have found a little pointer to some CAPI related work:
>>
>> https://groups.google.com/forum/#!searchin/mozilla.dev.platform/windows$20certificate$20store/mozilla.dev.platform/IafIvMyuzYg/vGaH9CE2fBEJ
>>
> This seems unrelated. Firefox currently manages its own set of root
> certificates and does not use the builtin Windows certificate system. This
> gives us extra control over some things like EV certificate policy, and has
> the property that system administrators who want to add a new root
> certificate (in a managed environment) have more difficulty doing so. But
> it doesn't seem directly related to the feature you seem to need.
You are right. That's unrelated. I copied the wrong link. This is the link:
http://mxr.mozilla.org/security/source/security/nss/lib/ckfw/capi/. But we
have not checked out that code and we are not sure about what the purpose
of that code is or how to use it.
>
>
> 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).
We are planning out the implementation of WebCrypto, but it's not clear
> from your post whether that would meet your needs or not.
>From the name, it sounds interesting. Can you elaborate a little what
WebCrypto is about? Based on the info I've provided about the use case, I
hope we can see whether it would meet our needs.
>
> 4- So, as encouraged by Benjamin Smedberg in the mentioned
>> "plugin-activation-in-firefox" blog post, we post here our quesiton: Can
>> you provide some guidance and/or advice? We feel ourselves stuck.
>> Customers
>> are asking for the new release and we have difficult to decide how to
>> proceed. In the worst case, we will need to drop support for Firefox and
>> encourage our customers to use a different browser.
>>
> Can you be more specific about why this would be necessary? Plugins
> continue to work in Firefox as long as the user chooses to activate them,
> and unlike chrome we currently do not have any plans to remove NPAPI
> support from our desktop products.
>
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. If that's not the case, it is a welcome
information. We face now a review of the plug-in roadmap and felt ourselves
unsure due to the decision for Chrome and the uncertainty about how that
could affect inside Mozilla. The whole thing is quite difficult to manage.
Now when we had decided to ship a version of the plug-in for Chrome, they
drop NPAPI support. We already have an ActiveX version. So now, it seems
like we will need to support 3 different "plug-in" technologies for a
single functionality (cert. choosing + signing) that it is served via a
browser. And waiting to see how it will be for Safari...
>
> Obviously we want to give people a full webAPI solution for valid use
> cases, so that websites will work on platforms where plugins are not
> supported (mobile/Windows Metro). Let's figure out what the use-case is and
> whether there is already a web API that will solve it (already implemented
> or in a draft) or whether we would need to write one.
>
I appreciate that.
On Sat, Nov 9, 2013 at 5:13 PM, Benjamin Smedberg <benja...@smedbergs.us>wrote:
> On 11/8/2013 4:33 AM, fma spew wrote:
>
>> We have a npapi-npruntime plug-in that access the Windows certificate
>> store
>> via CAPI to provide the end-user with its personal certificates to perform
>> different operations.
>>
> What is the use case you're solving? Are you trying to install a
> personal/client certificate that the user can use again in the future? Or
> is this a server certificate that isn't signed using normal root servers?
>
>
> We have found a little pointer to some CAPI related work:
>> https://groups.google.com/forum/#!searchin/mozilla.dev.platform/windows$
>> 20certificate$20store/mozilla.dev.platform/IafIvMyuzYg/vGaH9CE2fBEJ
>>
> This seems unrelated. Firefox currently manages its own set of root
> certificates and does not use the builtin Windows certificate system. This
> gives us extra control over some things like EV certificate policy, and has
> the property that system administrators who want to add a new root
> certificate (in a managed environment) have more difficulty doing so. But
> it doesn't seem directly related to the feature you seem to need.
>
>
> 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? We are planning
> out the implementation of WebCrypto, but it's not clear from your post
> whether that would meet your needs or not.
>
> 4- So, as encouraged by Benjamin Smedberg in the mentioned
>> "plugin-activation-in-firefox" blog post, we post here our quesiton: Can
>> you provide some guidance and/or advice? We feel ourselves stuck.
>> Customers
>> are asking for the new release and we have difficult to decide how to
>> proceed. In the worst case, we will need to drop support for Firefox and
>> encourage our customers to use a different browser.
>>
> Can you be more specific about why this would be necessary? Plugins
> continue to work in Firefox as long as the user chooses to activate them,
> and unlike chrome we currently do not have any plans to remove NPAPI
> support from our desktop products.
>
> Obviously we want to give people a full webAPI solution for valid use
> cases, so that websites will work on platforms where plugins are not
> supported (mobile/Windows Metro). Let's figure out what the use-case is and
> whether there is already a web API that will solve it (already implemented
> or in a draft) or whether we would need to write one.
>
> --BDS
>
>
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
