Re: About 's future...

2015-09-17 Thread helpcrypto helpcrypto
On Thu, Sep 17, 2015 at 8:59 PM, Rob Stradling 
wrote:

> The existence of this bug...
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1191414
> "gather telemetry on usage of "
>
> ...would seem to suggest that Mozilla "haven't decided anything yet".
>

IMHO that's not a good approach. A coomon user uses  each 3 years
or so...so percents will be very low, but impact on organizations based on
this will be severe.
Consider also there people that doesn't have telemetry on (blame me).

Regards
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


About 's future...

2015-09-17 Thread helpcrypto helpcrypto
Hi all


As previously raised on this list, there's a open wardiscussion about
removing [1]

Some people, like Sir Tim Berners-Lee doesn't seem to agree with that,
hence another thread is taking place at [2]

For Google, it seems the decision has been made, nothing is going to
change, and   could dissappear on Chrome 47 [3].

As MDN has marked the element as deprecated (according to WHATWG, I guess)
and there is -at least- one related bug open [4]:


*I will love someone @mozilla giving an official position, a blog post or
saying something (even "we haven't decided anything yet") about this issue,
and -if it's going to happen- aproximate date of the removal.*


Thanks a lot.

[1]
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0Xack
[2] https://lists.w3.org/Archives/Public/www-tag/2015Sep/thread.html
[3] https://code.google.com/p/chromium/issues/detail?id=514767
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1024871
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Smart Card and WebCrypto (Re: On the future of and application/x-x509-*-cert MIME handling)

2015-08-31 Thread helpcrypto helpcrypto
On Sun, Aug 30, 2015 at 12:10 PM, Anne van Kesteren 
wrote:

> it seems they're not using  either, so that solution was probably
> not sufficient either way.
>


At least in Spain,  is the only way to generate a key pair inside
smartcard (using Firefox) before sending PKCS#10 to CA.
Then, you go to the office to verify your identity and when done you can
download the X509 cert inside the card.
Hence you have "qualified signature", to be able to do taxes/whatever
online.

Anyhow, I would love to know, if  removal its going to happen, when
it will be. 4Q-2015? 2Q-2016?
Regards
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: On the future of and application/x-x509-*-cert MIME handling

2015-08-28 Thread helpcrypto helpcrypto
So...may I know if a decision was made?

 element is marked as deprecated on MDN, and as stated by rsleevi,
Chrome seems will drop it.

Will Mozilla do the same? Do you have a roadmap/date for such change? It's
going to be supported "by now" until next call?
Please, consider we are *that little percent *using the component "on a
weekly basis", so we have to start taking measures and planning changes, if
this is going to happen.

Thanks in advance.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: On the future of and application/x-x509-*-cert MIME handling

2015-08-20 Thread helpcrypto helpcrypto
Hi

In our case, we use  to generate a keypair on our SSCD (smartcard)
using Firefox, cause -with the PKCS#11 module configured-, it asks where to
store the keys, so the user select CARD.

Using Webcrypto or other JS stuff I wont be able to populate my smartcards,
so -IMHO- you should keep it as long as there's a real alternative for this
kind of operations.
You already removed signText and since then I cannot use "national
certificates renewal" feature on Firefox (only on IE)...not with Edge or
Firefox.

I know a lot of colleagues with the same problem, and that's why there has
been a rumble about "out of scope smartcards on Webcrypto".

I could agree with you that smartcards are not intended for Web, they suck
and whatever...but if you start to remove this feature, then it's time I
start looking for other Job :P




On Fri, Jul 31, 2015 at 1:00 PM, Hubert Kario  wrote:

> On Thursday 30 July 2015 14:32:01 Richard Barnes wrote:
> > On Thu, Jul 30, 2015 at 6:53 AM, Hubert Kario  wrote:
> > > On Wednesday 29 July 2015 16:35:41 David Keeler wrote:
> > > > [cc'd to dev-security for visibility. This discussion is intended to
> > > > happen on dev-platform; please reply to that list.]
> > > >
> > > > Ryan Sleevi recently announced the pre-intention to deprecate and
> > > > eventually remove support for the  element and special-case
> > > > handling of the application/x-x509-*-cert MIME types from the blink
> > > > platform (i.e. Chrome).
> > > >
> > > > Much, if not all, of that reasoning applies to gecko as well.
> > > > Furthermore, it would be a considerable architectural improvement if
> > > > gecko were to remove these features (particularly with respect to
> e10s).
> > > > Additionally, if they were removed from blink, the compatibility
> impact
> > > > of removing them from gecko would be lessened.
> > > >
> > > > I therefore propose we follow suit and begin the process of
> deprecating
> > > > and removing these features. The intention of this post is to begin a
> > > > discussion to determine the feasibility of doing so.
> > >
> > > because pushing people to use Internet Explorer^W^W Spartan^W Edge in
> > > enterprise networks is a good plan to continue loosing market share for
> > > Mozilla products! /s
> > >
> > > lack of easy, cross-application certificate deployment is the _reason_
> for
> > > low
> > > rates of deployment of client certificates, but where they are
> deployed,
> > > they
> > > are _critical_
> >
> >  doesn't help you with cross-application deployment.  After all,
> IE
> > doesn't support it.
>
> and how removing  makes the situation better?
>
> yes, Firefox doesn't deploy to system cert store (by default), but it's a
> bug
> in Firefox, not a feature
> --
> Regards,
> Hubert Kario
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Please help test the new NPAPI plugin sandbox on Windows

2015-01-26 Thread helpcrypto helpcrypto
...installed nightly64 and realized I don't have java 64 installed.
Then installed nightly(32) and got a blank page instead of my lovely HTML
(I see nothing)

Is this normal? Shall I remove 64 versiĆ³n? Something i could do?
Perhaps open a new thread or file a bug?



On Mon, Jan 26, 2015 at 9:43 AM, Chris Peterson 
wrote:

>  The NPAPI sandbox is off by default. The "dom.ipc.plugins.sandbox.flash"
> pref will only enable the sandbox for Flash. There is another pref,
> "dom.ipc.plugins.sandbox.default", that will enable the sandbox for all
> NPAPI plugins, including Java. I didn't mention the "default" pref because
> we wanted people to focus their testing on Flash, but if you find any Java
> crashes or bugs with the "default" pref, please let us know!
>
> thanks,
> chris
>
>
>
> On 1/26/15 12:35 AM, helpcrypto helpcrypto wrote:
>
>  Do any of these affect NPAPI Java behaviour somehow? (ie: can it break
> applet running or privileges?)
>  Thanks.
>
>
> On Sat, Jan 24, 2015 at 9:55 AM, Chris Peterson 
> wrote:
>
>> Bob Owen just landed a basic sandbox for Firefox's NPAPI plugin container
>> (bug 1123245) in Nightly 38. This NPAPI sandbox is orthogonal to Adobe's
>> Flash Protected Mode sandbox.
>>
>> The sandbox is Windows-only and preffed off for now. To enable it, flip
>> the "dom.ipc.plugins.sandbox.flash" pref to true. Flash features that could
>> use focused testing are file uploads/downloads, camera/mic access, and
>> clipboard.
>>
>> A more restricted NPAPI sandbox is coming in bug 1123759.
>>
>>
>> chris
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Please help test the new NPAPI plugin sandbox on Windows

2015-01-26 Thread helpcrypto helpcrypto
Do any of these affect NPAPI Java behaviour somehow? (ie: can it break
applet running or privileges?)
Thanks.


On Sat, Jan 24, 2015 at 9:55 AM, Chris Peterson 
wrote:

> Bob Owen just landed a basic sandbox for Firefox's NPAPI plugin container
> (bug 1123245) in Nightly 38. This NPAPI sandbox is orthogonal to Adobe's
> Flash Protected Mode sandbox.
>
> The sandbox is Windows-only and preffed off for now. To enable it, flip
> the "dom.ipc.plugins.sandbox.flash" pref to true. Flash features that
> could use focused testing are file uploads/downloads, camera/mic access,
> and clipboard.
>
> A more restricted NPAPI sandbox is coming in bug 1123759.
>
>
> chris
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: JS-Ctype IRC Room

2015-01-20 Thread helpcrypto helpcrypto
Is there a maillist for jsctypes? Wouldn't that be better than an irc
channel?


On Tue, Jan 20, 2015 at 5:39 AM, Philip Chee  wrote:

> On 20/01/2015 07:21, noitid...@gmail.com wrote:
> > New irc room we're trying to establish. #jsctypes
> >
> >
> https://client00.chat.mibbit.com/?url=irc%3A%2F%2Firc.mozilla.org%2F%23jsctypes
>
> That's wrong. The correct link is irc://moznet/jsctypes
>
> Phil
>
> --
> Philip Chee , 
> http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
> Guard us from the she-wolf and the wolf, and guard us from the thief,
> oh Night, and so be good for us to pass.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: WebCrypto for http:// origins

2014-09-11 Thread helpcrypto helpcrypto
On Thu, Sep 11, 2014 at 6:58 PM, Adam Roach  wrote:

> When you force people into an "all or nothing" situation regarding
> security,
>

Nature finds his own way: As nothing was invented for doing Javscript
Cryptography, someone started using Java Applets. Java applets are much
more insecure than the first option, but consumers NEED something to make
web crypto.

In other words: is security vs usability, but at least you have to give an
option!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to ship: WebCrypto API

2014-09-09 Thread helpcrypto helpcrypto
Thanks for your answers, Tim.

On Tue, Sep 9, 2014 at 12:38 PM, Tim Taubert  wrote:

> helpcrypto helpcrypto wrote:
> > I'll love to know if Mozilla/Firefox is going to provide something (even
> > out-of-standard) to make possible using PKCS#11/NSS with Webcrypto.
>
> The WebCrypto API basically exposes PKCS#11/NSS functionality with a DOM
> API.
>

I mean to actually use current secmod.db pkcs#11 modules/keys
AFAIK, Webcrypto just talks about "operations with keys" but doesnt say
anything about "where the keys came from" (just on-demand generated). This
is left for KeyDiscovery.
Is there any public place where i can look for such a thing as
"KeyDiscovery implementation status on Firefox"?


>  > This will fill the gap that currently exist with hardware token support
>
> Not sure what exactly what you are referring to here but I don't know of
> any current plans to extend the WebCrypto API beyond what the spec says.
>

Will be possible to request an specific PKCS#11 token to generate a keypair?
Will be possible to request a certificate which contains an specific string?

Thats the kind of operations im talking about.

Regards
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to ship: WebCrypto API

2014-09-03 Thread helpcrypto helpcrypto
I'll love to know if Mozilla/Firefox is going to provide something (even
out-of-standard) to make possible using PKCS#11/NSS with Webcrypto.

This will fill the gap that currently exist with hardware token support
(which, is going to be discussed nexr 10th September)
Regards.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Plug-in feature not available in the web platform. Alternatives?

2013-12-04 Thread helpcrypto helpcrypto
Sorry to appear so late, busy weeks!.

On Mon, Dec 2, 2013 at 9:27 AM, fma spew  wrote:

> 1) WebCrypto does not initially plan support for making end-user
> certificates available.
>
W3C WG divided this on 2 specs: Webcrypto and Key Discovery.

Webcrypto is about operations like sign(), cypher()...but doesnt take care
of "where the keys came from", just use them. Kind of correct spec, maybe
with some lacks (IMHO)

Key Discovery is about how the keys are generated, but they doesnt consider
user-keys but server-keys.

When i asked them about using user keys/certs to sign documents -IMHO- they
werent very open to discussion, and more or less said "it is not going to
happen (at least in this spec version)".
My suspect is that Google is pushing for their own platform (U2F, Wallet,
Tee) and Netflix is pushing form DRM, but none for document signing.
Mozilla had some guy working with WG, David Dahl, but seems not working at
Mozilla anymore, and i dont know if anyone from Mozilla still there.


As we are doing "the same thing" as you, we are also worried about our
future, and this is what we plan to do:
 - Use URL schemes (myapp://sign=ABC...Z) to invoke a local application
The main problem is that you cannoit return the signature to browser,
so you need an intermediate service/server
 - Use a local application running as a service (listening on
localhost:1234) to accept requests.
The main problem is that cannot be made on some systems like iOs or RT.


 2) Our use case, currently implemented as a NPAPI plug-in, needs Mozilla to

> continue supporting NPAPI until WebCrypto makes end-user certficates
> available.
>
We are working on the app to avoid doing 2 (or more) plugins


> I have a disturbing feeling. I hope that Microsoft's IE does not become the
> less problematic option for us and our customers.
>
Probably it will be (as it is ATM) for running Java Applets


Dont hesitate to contact me if you want some discussion ;)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Plug-in feature not available in the web platform. Alternatives?

2013-11-13 Thread helpcrypto helpcrypto
Hi.
My two cents.


On Sat, Nov 9, 2013 at 5:13 PM, Benjamin Smedberg 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?

In our case, our Java Applet is being used to sign a bunch of documents
with our smartcard (which contains a user x509 cert).
Its using MSCAPI, NSS and PKCS#11 APIs.



>
>  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.

IMHO Firefox should use system-store (like Chrome does), but that way
Mozilla will loose the control over Certificate registration, that could be
a way to earn some money.
Maybe using OpenSC minidriver could help you bypass this -unrelated- issue.



>
>  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.

So far, webcrypto (key discovery api neither) doesnt seem to be considering
user keys, so -to my knowledge- signing documents with a local installed
x509 cert wont be possible. I'll love to be wrong.
Perhaps Chrome native messaging could be an option, but as firefox plugins
its not cross-browser.

In our case, we are starting to test custom URL/scheme. ie: installing a
local app which manages an specific protocol like "mysign://..." and when
invoking from browser, the app will be launched.
Dont hesitate to request any more info you may need.



>  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.
>
I have to agree with Benjamin Smedberg. Firefox is not your problem, but
the lack of standarization.
Using the custom URL/scheme you will have "the same solution for all
browsers"...until browser stop supporting this feature (or start annoying
the users with more dialogs).
My advice: start to fix your software to be prepared to click-and-play
issues, while developing a new one.



> 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.
>
My case: batch signning documents with user x509 cert stored on a smartcard.



On Tue, Nov 12, 2013 at 11:10 PM, Matt Brubeck  wrote:

> One alternative is a Firefox extension.  Firefox extensions can access
> both native platform APIs and web content.  In particular, extensions can
> use js-ctypes to call C/C++ code.

As said before, we will love having a cross-browser solution.



> We've also mentioned the possibility of bundling a traditional plugin with
> a Firefox extension to change the default click-to-play behavior:
> "If a plugin is installed bundled within a Firefox extension, the
> extention can enable the plugin by default (for all sites or for particular
> sites) via preferences/permissions. Because the user chose to install the
> addon, I see no problem with allowing this sort of default activating."
> --
> https://mail.mozilla.org/pipermail/firefox-dev/2013-September/000903.html
>
Maybe this is a workaround



On Wed, Nov 13, 2013 at 10:12 AM, Henri Sivonen wrote:

> On Wed, Nov 13, 

Re: Supporting the Windows Certificate Store

2013-03-06 Thread helpcrypto helpcrypto
Just for confirmation:

Is Mozilla point to implement MSCAPI access trough a PKCS#11 module?
(http://mxr.mozilla.org/security/source/security/nss/lib/ckfw/capi/)

or

Is mozilla point to integrate with MSCAPI (transparently)?

Just to know which answer give next time this topic raises.

On Wed, Mar 6, 2013 at 12:54 AM,   wrote:
> On Wednesday, January 9, 2013 9:17:12 AM UTC-8, joshu...@gmail.com wrote:
>> I know that there are probably well thought out reasons that this isn't a 
>> features already...BUT! Lot's of US Government users can't use Firefox 
>> because it doesn't use the Windows certificate store.
>>
>>
>>
>> Would anyone be totally opposed to adding this feature and having it enabled 
>> via group policy? That would allow some IT shops to roll it out with their 
>> preferred smart card middleware...like ActivClient.
>>
>>
>>
>> Thoughts?
>
> I would be very much in favor of adding this feature. We are getting ready to 
> remove Firefox and restrict its use across our 5000 PCs because it is such a 
> righteous PITA to add our internal CA certificates to Firefox remotely and we 
> don't want to deal with the flood of inevitable user calls "I don't know what 
> to choose, this security certificate stuff scares me." "Why am I getting 
> prompted for internal websites?" "Don't you IT guys know how to do certs?" 
> "Do I have to accept it, or do I install it?"
>
> I read the articles for certutil and I have to ask, "what idiot came up with 
> that as the only method???" Seriously, not being able to do it easily through 
> Group Policy or some other centralized method is a GIGANTIC FAIL. If you want 
> enterprises to take you seriously, take us and our needs seriously. Otherwise 
> whatever point Mozilla is trying to make is being lost and you will never be 
> installed again in our shop.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: How to automatically register a PKCS#11 module into firefox?

2013-02-25 Thread helpcrypto helpcrypto
Have you considered browser's addmodule js function?

https://developer.mozilla.org/en/docs/JavaScript_crypto#Loading_PKCS_.2311_modules


On Mon, Feb 25, 2013 at 12:26 PM,   wrote:
> Hi,
> I have a pkcs#11 dll library and want it to register it in the firefox 
> browser using a MSI setup.
> I checked with 'modutil' tool, but unfortunately, it shows me an unexpected 
> error message even when you create new key/certificate database set. It says 
> "certificate/key database is in an old unsupported format!!". I use the 
> 18.0.2 version of firefox, which is a very recent version.
> Does anybody know another affordable and always reliable method to register 
> this module, or at least, can explain how to cope with 'modutil' utility 
> problem? Is it technically possible to use this tool for very old firefox 
> versions (such as 6.0)?
>
> Thanks
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Let's never, ever, shut down NSS -- even in debug builds

2013-01-29 Thread helpcrypto helpcrypto
After reading bsmith message i have two questions coming to my mind...

In normal usage, cert8/key3/secmod (some may apply) are rewrited on
firefox close. Is this really necessary?

> But, AFAICT, it is OK to do I/O during shutdown as long as you don't care 
> whether you get interrupted or not.

Didnt interrupting the shutdown process could corrupt cert8/key3/secmod?


> 3. Some buggy PKCS#11 modules (such as smart card readers) may
> need to be updated to support this. (A PKCS#11 module should gracefully
> handle the process exiting without "proper" shutdown, because it has to
> deal with programs crashing, but I've heard rumors that some don't.)

As we have developed our own pkcs#11 module (hence, it can be buggy),
ill love to know what should we check regarding this.
We have noticed sometimes Firefox doesnt invoke C_Finalice, so how
could we clean-exit?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform