Re: [bulk] PKCS#11 platform integration

2015-05-09 Thread David Woodhouse
On Fri, 2015-05-08 at 15:00 -0700, Ryan Sleevi wrote:
 On Fri, May 8, 2015 6:09 am, David Woodhouse wrote:
   On Linux distributions it *is* the platform's
   mechanism of choice for configuring PKCS#11 tokens. NSS needs to
   support it if it wants to integrate with the platform properly.
 
 I'm sorry to continually push back on this, but you continue to make this
 claim. This is a heady claim that lacks any evidence (so far) to support
 it, beyond a particular distro.

I believe it's *all* the major distros. Fairly much anything that ships
GNOME, anything that ships with a fully functional GnuTLS. But maybe I'm
nit-picking :)

 1) You can't really talk about the platform's mechanism for Linux,
 unless/until it's part of LSB.

That's a good idea; we should look at including p11-kit in the LSB.

But yes, I said Linux and that's not what I meant. Linux really means
just the kernel, not the whole GNU/MIT/Xorg/etc/Linux operating system,
and not the LSB either.

Please forgive my laziness and pretend I actually said all the major
desktop Linux distributions instead of just Linux.

Let's try again...

It would be nice if NSS would integrate with the system-wide
configuration for PKCS#11 providers that exists in all the major desktop
Linux distributions. One of them has recently added packaging guidelines
that its packages SHOULD do so, and for the others it's just a good
idea.

There, is that better?

  So you can equally argue (and more accurately argue)
 that p11-kit is failing to integrate with the platform properly by failing
 to register itself with NSS.

I'm happy with looking at it like that. Perfectly happy.

So tell me: how does a PKCS#11 provider module register itself with
NSS such that it's automatically loaded in NSS applications? I know how
to do it for GnuTLS and I know how to do it for OpenSSL(+engine_pkcs11).
Tell me how to do it for NSS and my work here is done.

In fact, if you look at the straw-man patch I sent, that was basically
all I *was* doing. It would be a configure/build-time option to load a
specific module automatically. On systems that *want* it, that they'd
configure it to load p11-kit-proxy.so. On others, they wouldn't.

-- 
dwmw2


-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: [bulk] PKCS#11 platform integration

2015-05-08 Thread Wouter Verhelst

On 08-05-15 15:09, David Woodhouse wrote:

On Fri, 2015-05-08 at 14:58 +0200, Wouter Verhelst wrote:

In light of that, it would be great if firefox/libnss were to allow
configuration of PKCS#11 modules externally -- not just on Linux,
but on OSX and Windows too.


Well, p11-kit does build on OSX and Windows too but it doesn't have
the same status there. On Linux distributions it *is* the platform's
mechanism of choice for configuring PKCS#11 tokens. NSS needs to
support it if it wants to integrate with the platform properly.

On OSX and Windows, p11-kit is just some third-party software.


Which would mean that if this gets to be the way to do it, we don't 
fix the problem on those platforms -- instead, we just move it from 
install an individual PKCS#11 module to install p11-kit.



But then again, isn't PKCS#11 itself an impostor on those platforms
anyway?


Yeah, sortof. That is, Windows' and OSX' native browsers (IE and Safari) 
each have their very own model of dealing with crypto hardware, which in 
neither case involves PKCS#11 (I must admit that my colleague knows the 
details there better than I do, though).


Firefox is the odd one out in that regard, where it doesn't use the 
platform-specific crypto hardware APIs. That isn't a problem from our 
POV (we support PKCS#11 for more than just firefox; and even if that 
wasn't the case, having an option that uses a different mechanism is 
useful as a debugging aid); but it does mean that with the current state 
of affairs, Firefox is the only browser that doesn't support installing 
our eID middleware without a step internal to the browser -- except for 
Chrome on Linux, since it also uses libnss there.



Windows has a *different* model for installing crypto hardware —
really, your problem on Windows is that NSS doesn't use nss_capi by
default, isn't it? (And that nss_capi hasn't been updated to CNG and
that you should be shipping a minidriver or a CSP...)

I think the same is true for OSX, with something like PKCS11_keychain?


Something along those lines, yes. As I said, I'm not too sure about the 
details here, since my colleague usually deals with those.


--
Wouter Verhelst
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [bulk] PKCS#11 platform integration

2015-05-08 Thread Wouter Verhelst

On 08-05-15 15:46, David Woodhouse wrote:

FWIW on Linux your installer/package needs to be shipping a module
file like the one in /usr/share/p11-kit/modules/opensc.module


Well, since p11-kit is not found on the older distributions that we 
still support, and non-functional on some newer distributions that we do 
support, I'm not taking that step just yet; but yeah, I'll probably do 
so at some point.



(or
isn't the eID card supported by OpenSC anyway, so do people need a
third-party provider?)


There is some support in OpenSC, yes, but it lacks a few things that our 
module does provide (e.g., we provide identity information through 
CKO_DATA objects, which OpenSC doesn't do; also, there's two keys on the 
card, but due to some peculiar strangeness in access rights of the 
other, OpenSC only supports one of them).


--
Wouter Verhelst
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: [bulk] PKCS#11 platform integration

2015-05-08 Thread David Woodhouse
On Fri, 2015-05-08 at 15:23 +0200, Wouter Verhelst wrote:
 On 08-05-15 15:09, David Woodhouse wrote:
  On Fri, 2015-05-08 at 14:58 +0200, Wouter Verhelst wrote:
   In light of that, it would be great if firefox/libnss were to 
   allow
   configuration of PKCS#11 modules externally -- not just on Linux,
   but on OSX and Windows too.
  
  Well, p11-kit does build on OSX and Windows too but it doesn't have
  the same status there. On Linux distributions it *is* the 
  platform's
  mechanism of choice for configuring PKCS#11 tokens. NSS needs to
  support it if it wants to integrate with the platform properly.
  
  On OSX and Windows, p11-kit is just some third-party software.
 
 Which would mean that if this gets to be the way to do it, we 
 don't fix the problem on those platforms -- instead, we just move it 
 from install an individual PKCS#11 module to install p11-kit.

Right. On platforms where p11-kit doesn't *already* exist, using it
doesn't help you. It only *adds* work for the end-user.

I suspect the best answer for Windows and OSX is to make NSS integrate
properly by automatically loading nss_capi and its OSX equivalent,
if/when those modules are production-ready. Perhaps it's something to
bear in mind when adding the code to load p11-kit-proxy.so; that on
other platform it might be some *other* module that gets loaded.

FWIW on Linux your installer/package needs to be shipping a module
file like the one in /usr/share/p11-kit/modules/opensc.module (or
isn't the eID card supported by OpenSC anyway, so do people need a
third-party provider?)

-- 
dwmw2


smime.p7s
Description: S/MIME cryptographic signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [bulk] PKCS#11 platform integration

2015-05-08 Thread Wouter Verhelst

On 08-05-15 14:38, David Woodhouse wrote:

Bug 248722¹ has been open since 2004 requesting a system-wide
configuration for PKCS#11 modules. At the time, such a thing didn't
exist.

These days it does. Modern systems ship with p11-kit², which exists
precisely to fill that gap and provide a standard discoverable
configuration for installed PKCS#11 modules.


As an additional data point, I'd like to point out that as a PKCS#11 
_provider_, having a system-wide PKCS#11 registry would avoid ugliness 
like https://addons.mozilla.org/en-US/firefox/addon/belgium-eid/; the 
sole reason for which this extension exists is that if we ship it 
together with our PKCS#11, we don't have to include instructions that 
tell people to click 10+ times¹ just to configure their browser so they 
can do their tax declaration (But I've just installed it!). As it is, 
the extension is the only way we can do all of that, but it causes a lot 
of confusion (people who believe it will work if they just install the 
extension from addons.mozilla.org without the PKCS#11 module, and 
similar things).


In light of that, it would be great if firefox/libnss were to allow 
configuration of PKCS#11 modules externally -- not just on Linux, but on 
OSX and Windows too. From where I'm standing, it's perfectly fine if 
there's a did you install this kind of question on the next firefox 
start, as long as a process external to the browser can install such a 
module.


Regards,

¹ = - preferences - advanced - certificates - security devices - 
load - browse - open - ok - ok - close; that's 11 by my count (and 
then you haven't selected the file yet).


--
Wouter Verhelst
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [bulk] PKCS#11 platform integration

2015-05-08 Thread David Woodhouse
On Fri, 2015-05-08 at 14:58 +0200, Wouter Verhelst wrote:
 In light of that, it would be great if firefox/libnss were to allow 
 configuration of PKCS#11 modules externally -- not just on Linux, 
 but on OSX and Windows too.

Well, p11-kit does build on OSX and Windows too but it doesn't have
the same status there. On Linux distributions it *is* the platform's
mechanism of choice for configuring PKCS#11 tokens. NSS needs to
support it if it wants to integrate with the platform properly.

On OSX and Windows, p11-kit is just some third-party software.

But then again, isn't PKCS#11 itself an impostor on those platforms
anyway?

Windows has a *different* model for installing crypto hardware —
really, your problem on Windows is that NSS doesn't use nss_capi by
default, isn't it? (And that nss_capi hasn't been updated to CNG and
that you should be shipping a minidriver or a CSP...)

I think the same is true for OSX, with something like PKCS11_keychain?

-- 
dwmw2


smime.p7s
Description: S/MIME cryptographic signature
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [bulk] PKCS#11 platform integration

2015-05-08 Thread Ryan Sleevi
On Fri, May 8, 2015 6:09 am, David Woodhouse wrote:
  On Linux distributions it *is* the platform's
  mechanism of choice for configuring PKCS#11 tokens. NSS needs to
  support it if it wants to integrate with the platform properly.

I'm sorry to continually push back on this, but you continue to make this
claim. This is a heady claim that lacks any evidence (so far) to support
it, beyond a particular distro.

1) You can't really talk about the platform's mechanism for Linux,
unless/until it's part of LSB. Beyond that, you're just waving your hands
in your air saying for some distros. Linux is a world where a thousand
flowers bloom and a distro exists for every particular person's needs, so
you can't just make broad sweeping statements like this.

2) It is _an_ option for the platform. Indeed, I'd suggest you've got a
cart leading the horse. AFAICT, NSS *is* part of LSB (
http://www.linuxbase.org/betaspecs/lsb/LSB-Common/LSB-Common/requirements.html
) but p11-kit is not. So you can equally argue (and more accurately argue)
that p11-kit is failing to integrate with the platform properly by failing
to register itself with NSS.


I have no fundamental objections to p11-kit - indeed, I think it's quite
handy. But I do take issue with such broad sweeping claims used to argue
for supporting it. It's an option, I get that some distros really like I,
I *personally* like it for some cases, but that does *not* argue it's a
good thing.

-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto