:/$HOME/.pki/nssdb and the additional slot is automatically loaded
from /etc/pki/nssdb *if* a database exists there, this may all just
work... is that something we can consider?
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
On Tue, 2012-07-24 at 16:12 +0200, Anders Rundgren wrote:
IMO, this is not an NSS issue, it is rather a *NIX issue. All other
operating systems (that I'm aware of NB...) including *NIX-derivates
like Android, already have a system-wide cryptographic architecture.
Yes. It's an issue I'm
On Wed, 2012-07-25 at 08:33 +0200, Anders Rundgren wrote:
I think the lack of progress [*] here has a lot to do with the fact that
there's really nothing to gather around. Making security solutions
for security-conscious people is probably quite fun but since this
only addresses a tiny
On Thu, 2012-07-26 at 14:13 -0700, Robert Relyea wrote:
Error verifying signature
parse error
--ms050908010406000106010405
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
(Want to investigate that off-list, or is it expected
On Fri, 2012-07-27 at 10:53 +0200, Anders Rundgren wrote:
I think you need to take a step back and consider which
market and user-base you are targeting.
No, I believe that's been clear from the beginning. Apologies if I
didn't make it explicit enough.
Linux on the desktop? Why bother with
On Fri, 2012-07-27 at 10:08 -0700, Robert Relyea wrote:
Oh, so you switch between sql:/etc/pki/nssdb and sql:$HOME/.pki/nssdb=20
depending on whether libnsssysinit.so exists.
It's worse than that. It's not just whether libnsssysinit.so *exists*,
but whether it's actually loaded by a line in
On Fri, 2012-07-27 at 12:07 -0700, Robert Relyea wrote:
The news to me is that applications care, which means I need to
figure out an api to give the application that information.
The applications actively don't *want* to care, but the existing
interface by which they use the shared system
On Wed, 2012-08-01 at 11:58 +0200, Anders Rundgren wrote:
http://www.finextra.com/news/announcement.aspx?pressreleaseid=45624
Current platforms are useless for banking so what else could they do?
The big problem with the VbV insanity wasn't the current platforms. It
was largely the user
On Mon, 2013-06-17 at 10:58 -0700, Chris Newman wrote:
I'll mention one other usability issue. I am getting pressure from my
employer to stop using NSS due to the MPL 2 license. I got less
pressure when I could use NSS under the LGPL 2.1 branch of the
tri-license. Switching to OpenSSL has
On Mon, 2014-02-03 at 12:13 +, Alan Braggins wrote:
Having support for PKCS#11 tokens at all is a pro, even if one
irrelevant to the vast majority of users.
That gets less true as we start to use PKCS#11 a little more. It isn't
*just* about hardware tokens — things like gnome-keyring
On Mon, 2014-12-01 at 17:22 -0800, Robert Relyea wrote:
This is still the issue with nsssysinit. It currently only works if the
the application open sql:/etc/pki/nssdb. Currently firefox doesn't even
use the sql database.
Which has always been a bit of a facepalm realisation: Hey... we
On Tue, 2014-12-02 at 11:16 -0500, Miloslav Trmač wrote:
Hello,
It has largely been superseded by p11-kit-trust, which in the NSS case
provides a replacement for libnssckbi.so and gives us consistency across
the entire system regardless of the crypto libraries in use. (This
wasn't in
On Tue, 2014-12-02 at 12:00 -0500, Miloslav Trmač wrote:
Great. So that should solve Patrik's CA issues without needing to do
anything special. All that remains is to get the smartcards working by
loading p11-kit-proxy.so (or preferably the individual modules) too.
Is that something we
On Tue, 2014-12-02 at 18:24 +, Martinsson Patrik wrote:
So here's a round of new questions,
- There are different ways of loading pkcs11-modules into an application
where nss is one and p11-kit is another. And where p11-kit is a library
that an application can link to, and where nss is
On Tue, 2014-12-02 at 18:24 +, Martinsson Patrik wrote:
I quickly tried to import libp11-proxy.so in the users nssdb (and
in .mozillas) and it worked as expected. However, since all my
keyrings (?) now are in the slots, evolution (and chrome/ff etc) now
asks me for passwords to all my
On Tue, 2014-12-02 at 19:59 +, David Woodhouse wrote:
That doesn't happen here on F21, FWIW.
Firefox only asks me to log into my p11-kit-provided hardware tokens
when I go to a web site which wants a certificate, which is fair
enough.
And I haven't actually got Evolution to show me
On Tue, 2014-12-02 at 20:30 +, David Woodhouse wrote:
On Tue, 2014-12-02 at 19:59 +, David Woodhouse wrote:
That doesn't happen here on F21, FWIW.
Firefox only asks me to log into my p11-kit-provided hardware tokens
when I go to a web site which wants a certificate, which
On Thu, 2014-12-04 at 11:31 +, David Woodhouse wrote:
That one. libnssckbi.so is what provides the default trust roots. It's
*always* supposed to be loaded in an NSS system. You shouldn't need to
add it manually. I don't.
... except in the specific case where I was testing pam_pkcs11
On Thu, 2014-12-04 at 10:33 -0800, Robert Relyea wrote:
That one. libnssckbi.so is what provides the default trust roots. It's
*always* supposed to be loaded in an NSS system. You shouldn't need to
add it manually. I don't.
Huh? that is not true. libnssckbi.so is loaded by nssysinit, or
On Mon, 2014-12-08 at 10:15 +, Martinsson Patrik wrote:
So, to summarize,
$ sudo update-alternatives --install /usr/lib64/libnssckbi.so
libnssckbi.so.x86_64 /usr/lib64/p11-kit-proxy.so 1000
$ cat /etc/pki/nssdb/pkcs11.txt
library=/usr/lib64/p11-kit-proxy.so
name=p11-kit-proxy
On Mon, 2014-12-08 at 13:05 +, David Woodhouse wrote:
If you fix the unlock-at-login issue then you shouldn't have to disable
this in any application for which there isn't already a Does not
support Protected Authentication Path bug filed. I.e. evolution.
I just fixed Evolution, FWIW
On Mon, 2014-12-08 at 13:53 -0800, Robert Relyea wrote:
Nothing in the above paragraph is true.
openning
1)sql:/etc/pki/nssdb is *STILL* the recommended action for applications
(whether or not nssysinit is installed), and
Recommended in the sense of do as I say, not as I do, of course :)
On Mon, 2014-12-08 at 13:56 -0800, Robert Relyea wrote:
On 12/08/2014 08:59 AM, David Woodhouse wrote:
I still maintain that the path to sanity involves killing
/etc/pki/nssdb entirely, and then you can look at applying *correct*
fixes to whatever's still not behaving correctly
On Tue, 2014-12-09 at 13:15 +, Martinsson Patrik wrote:
So, If I don't have opensc-module, one way or another in
(sql):/etc/pki/nssdb I will loose all functionality that gsd brings me,
for example lock screen at card removal.
Not sql:/etc/pki/nssdb; this is another one that that uses the
On Tue, 2014-12-09 at 14:18 +, Martinsson Patrik wrote:
On Tue, 2014-12-09 at 13:54 +, David Woodhouse wrote:
On Tue, 2014-12-09 at 13:15 +, Martinsson Patrik wrote:
So, If I don't have opensc-module, one way or another in
(sql):/etc/pki/nssdb I will loose all functionality
On Tue, 2014-12-09 at 14:18 +, Martinsson Patrik wrote:
It's cute that GNOME keyring can provide PKCS#11 functionality and you
can store certificates and keys in there. But you aren't *using* that
functionality. So just unregister the module entirely by deleting its
file from
On Tue, 2015-01-13 at 12:25 -0500, John Dennis wrote:
On 01/13/2015 09:58 AM, Robert Daniels wrote:
I also need to serialize private keys in the same fashion. Any hints
greatly appreciated.
By design NSS prohibits access to private keys therefore you cannot
serialize private keys.
The
Has anyone looked at implementing RFC7512 support, allowing an object
to be specified by a PKCS#11 URI?
I can now do this with both GnuTLS and OpenSSL, and it would be good
to get NSS fixed too.
I'd also very much like NSS to be able to load the default PKCS#11
tokens listed in the system's
On Fri, 2015-05-01 at 11:35 +0100, Alan Braggins wrote:
On 30/04/15 17:56, David Woodhouse wrote:
Has anyone looked at implementing RFC7512 support, allowing an object
to be specified by a PKCS#11 URI?
I don't suppose you know why RFC 7512 uses CKA_ID but not CKA_SUBJECT,
when PKCS#11 says
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 Sun, 2015-05-10 at 12:47 -0700, Ryan Sleevi wrote:
- Don't load a module unless the user has explicitly asked or configured
that module to be loaded.
- Do not patch NSS to load modules outside of the explicitly requested
modules.
Quite right; that's absolutely how we should behave.
As
On Tue, 2015-05-05 at 09:47 -0700, Ryan Sleevi wrote:
On Tue, May 5, 2015 8:55 am, David Woodhouse wrote:
I'm talking about the serial numbers of the certs issued *by* the two
My CAs.
Good to have that clarification :)
Different CAs (in as much as different public keys
On Tue, 2015-05-05 at 12:29 +0100, Alan Braggins wrote:
On 04/05/15 21:53, David Woodhouse wrote:
On Mon, May 4, 2015 1:25 pm, David Woodhouse wrote:
Surely that's not unique? Using the above example, surely the first
certificate issued by the 2010 instance of 'My CA
On Mon, 2015-05-04 at 09:21 -0700, Robert Relyea wrote:
So in NSS, CKA_LABEL is simply a short cut to CKA_SUBJECT. That is NSS
looks up a cert from the nickname and picks all the certs that match
that cert's subject.
Hm... so if I have two certificates; one with:
CKA_SUBJECT: My CA
On Mon, May 4, 2015 1:25 pm, David Woodhouse wrote:
Surely that's not unique? Using the above example, surely the first
certificate issued by the 2010 instance of 'My CA', and the first
certificate issued by the 2015 instance, are both going to have
identical CKA_ISSUER
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
On Fri, 2015-05-08 at 15:07 -0700, Ryan Sleevi wrote:
On Fri, May 8, 2015 5:38 am, David Woodhouse wrote:
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
On Sun, 2015-05-10 at 12:07 -0700, Ryan Sleevi wrote:
On Sat, May 9, 2015 3:30 pm, David Woodhouse wrote:
On Fri, 2015-05-08 at 15:07 -0700, Ryan Sleevi wrote:
Yes, it should. You'll introduce your users to a host of security issues
if you ignore them (especially for situations like
On Sun, 2015-05-10 at 12:11 -0700, Ryan Sleevi wrote:
On Sat, May 9, 2015 3:30 pm, David Woodhouse wrote:
No, you should be able to do it w/o patching NSS.
OK... how?
If the Shared System Database wasn't such an utter failure, not even
being used by Firefox itself, then just
On Sun, 2015-05-10 at 12:47 -0700, Ryan Sleevi wrote:
If the user requests NSS to load a module. It should load that module.
And that module only. Period.
The canonical per-user way to request an application to load a module is
for me to create a file in ~/.config/pkcs11/modules/*.module which
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
when it
is being loaded into an NSS application which might have its own
database in another directory (some broken applications like Firefox
still don't use ~/.pki/nssdb ☹) or indeed in the *same* directory
(like Chrome does).
--
David WoodhouseOpen Source Technology
On Tue, 2015-05-12 at 10:17 -0700, Ryan Sleevi wrote:
On Tue, May 12, 2015 9:44 am, Peter Bowen wrote:
How about an even simpler solution? Don't have p11-kit load the
PKCS#11 modules, just provide a list of paths and let the application
pass those to NSS. That way the application can
On Mon, 2015-05-11 at 11:24 -1000, Brian Smith wrote:
Said differently, there is nothing special about Linux. Just as Firefox
intentionally doesn't use Windows's central certificate trust database on
Windows, and just as it doesn't use Mac OS X's central certificate trust
database on Mac OS
On Mon, 2015-05-11 at 11:21 -0700, Ryan Sleevi wrote:
It's not simply sufficient to load module X into Chrome or not. p11-kit's
security model is *broken* for applications like Chrome, at least with
respect to how you propose to implement.
I've proposed at least four different options and
function. They'll almost
certainly do precisely the same thing that was apparently undesirable
for NSS to do for itself — if it's a valid PKCS#11 URI then look it up
as one, else treat it as a nickname and look it up that way.
--
David WoodhouseOpen Source Technology Centre
On Mon, 2015-07-27 at 18:34 +0200, Trick, Daniel wrote:
Thanks for your reply, Bob!
You said:
When you need fine grain control, the application should use
issuer/serial number to identify the cert (I think all the mozilla
apps have gone to this now)
Well, I agree that it /should/
> I am still strongly opposed to introducing this behaviour to the existing
> functions. The nickname functions already have significant magic attached
> to them, both in parsing from NSS APIs and in providing to NSS APIs
> (filtering or setting the token via parsing or adding to the token name,
On Mon, 2016-04-04 at 16:23 -0700, Ryan Sleevi wrote:
>
> I understand and appreciate that you want the standard to be "Show me
> the code." But that's not the standard we set.
Not at all. I fully appreciate that just because you can't provide any
specific failure mode doesn't mean that no such
On Thu, 2016-04-07 at 05:01 -0700, Julien Pierre wrote:
> The problem really stems from the design of NSS, specifically the
> CERTCertificate*, which maps to a unique DER encoded cert, but not to
> a single PKCS#11 object in a single token. Since the same cert can
> exist in multiple tokens, but
On Tue, 2016-04-05 at 12:49 -0400, John Dennis wrote:
>
> If the API does not have documented behavior constraints then you can't
> be causing a API breakage.
I think that's overstating the case a little.
Even if the behaviour is undocumented, if real applications are
depending on it in
On Thu, 2016-04-07 at 17:13 -0700, Julien Pierre wrote:
> > Hm, I thought PK11_ListCerts tried to eliminate duplicates too, which
> > is why it has that crappy O(n²) behaviour? Does it *really* return more
> > than one of the 'same' certificate? Don't you *still* get a randomly-
> > chosen one
NGINE_PKCS11).
> Anyway, I have digressed quite a bit from the PKCS#11 URI subject at
> this point, so I will stop.
I don't think you really have — it cuts to the heart of what we're
actually trying to do here.
--
David WoodhouseOpen Source Technology Ce
On Wed, 2016-04-06 at 16:09 -0700, Julien Pierre wrote:
> David,
>
> On 4/6/2016 05:57, David Woodhouse wrote:
> > ... all this is mostly solved. You can use any or all of CKA_CLASS,
> > CKA_ID and CKA_LABEL to identify the objects you want to use.
>
> Except th
As Varun ramps up for the potential GSoC project on implementing URI
support, I'd really like to get some consensus on the implementation
details — there is at least one choice which needs to be made, which
will affect his development from day one.
As discussed in
ind myself wondering why
the PK11_FindCertsFrom*() functions even *noticed* this issue. We
should apply the filter *before* building up the results in a
collection, surely?
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
of NSS.
This is obviously not the ideal solution; let's make NSS play nicely
too :)
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
¹ https://bugzilla.mozilla.org/show_bug.cgi?id=1162897
² https
On Thu, 2016-03-17 at 15:18 +, David Woodhouse wrote:
>
> > I am still strongly opposed to introducing this behaviour to the existing
> > functions. The nickname functions already have significant magic attached
> > to them, both in parsing from NSS APIs and in
On Mon, 2016-04-04 at 07:48 -0700, Ryan Sleevi wrote:
>
> On Apr 4, 2016 7:15 AM, "David Woodhouse" <dw...@infradead.org> wrote:
> >
> > Ryan?
> >
> > Unless you are able to provide an explanation of how this would "break
> > Chrom
On Mon, 2016-04-04 at 12:21 -0700, Ryan Sleevi wrote:
> On Mon, Apr 4, 2016 at 11:32 AM, David Woodhouse <dw...@infradead.org> wrote:
> >
> > I don't see it. I still don't see *any* way for you to get a PKCS#11
> > URI anywhere in the memory space of your application,
On Mon, 2016-04-04 at 12:17 -0700, Ryan Sleevi wrote:
>
> Your justification seems to be that because you can't imagine my
> application doing it, I shouldn't be concerned. But just re-read the
> above and you can see how it affects every application - there's now a
> new structure and form, and
On Mon, 2016-04-04 at 08:23 -0700, Ryan Sleevi wrote:
> This is, of course, demonstrably false. One can no longer filter the inputs
> to this API if your change is accepted, because the format will have
> changed. For example, colon no longer becomes the separator between the
> token and the
On Mon, 2016-04-04 at 15:19 -0700, Ryan Sleevi wrote:
> On Mon, Apr 4, 2016 at 12:39 PM, David Woodhouse <dw...@infradead.org> wrote:
> >
> >
> > We usually reserve the term "breaks the API" for when something *used*
> > to work, and now does
On Mon, 2016-04-04 at 15:49 -0700, Ryan Sleevi wrote:
> I appreciate your argument "but user provided!", but you seem to be
> missing the core point - you're changing the syntax of an API's
> arguments, in a way that breaks the previously-held pre and post
> conditions. That's an API change.
>
>
On Mon, 2016-04-04 at 16:04 -0700, Ryan Sleevi wrote:
>
> I've already tried to explain this several times to you. I don't feel
> there's anything more useful to contribute.
Very well. From my point of view it seems that you have offered straw
men, and talked about what would happen if NSS
OF SUCH
+ * DAMAGE.
+ *
+ * Author: Stef Walter <st...@collabora.co.uk>
+ *
+ * Ported to NSS by David Woodhouse <dw...@infradead.org> and thus parts
+ *
+ * Copyright (C) 2016 Intel Corporation
+ *
+ */
+
+#include "p11uri.h"
+
+#include "base.h"
+#include "secport.h"
From: David Woodhouse <david.woodho...@intel.com>
This is based very heavily on p11-kit/uri.c as of commit e49fba714
(which was 2 years ago in 2014, but it hasn't actually changed since
then. And even then it was only being tweaked to accommodate minor
changes between the I-D and the
On Mon, 2016-08-15 at 15:23 +0100, David Woodhouse wrote:
>
> Obviously I've added nothing that *uses* this yet; Varun is currently
> working on tidying that up for submission as part of his GSoC project.
Here's the first use of it, and a request for opinions...
The first p
From: David Woodhouse <david.woodho...@intel.com>
Is this really worth the complexity? It's a *lot* of complexity on
the providing side, to remove a *small* amount of complexity (having
to free the string) on the calling side. And it loses the flexibility
of being able to specify the URI ty
From: David Woodhouse <david.woodho...@intel.com>
The result must be freed by calling P11URI_FreeString()
---
cmd/certutil/certutil.c | 3 +++
lib/nss/nss.def | 1 +
lib/pk11wrap/pk11pub.h | 2 ++
lib/pk11wrap/pk11slot.c | 18 ++
4 files changed, 24 inse
FromNickname() with the occasional bug fix applied to one
but not the other. I fixed that already in my tree and will submit that
cleanup separately. Again, I didn't want Varun doing the same thing
with the equivalent FromURI() functions.)
--
David WoodhouseOpen Source Techn
On Sat, 2016-11-05 at 13:16 +0100, Matthias B. wrote:
>
>
> int rc = 0;
>
> PKCS11_CTX *pkcs11_ctx;
>
> pkcs11_ctx = PKCS11_CTX_new();
>
> PKCS11_CTX_init_args(pkcs11_ctx,
> "configdir='C:/Users/Username/AppData/Roaming/Mozilla/Firefox/Profiles/5wzkdcjx.default'
> certPrefix=''
On Thu, 2016-11-03 at 13:41 +0100, Matthias B. wrote:
> Thanks ro reply and thanks for the information, but is there a way to
> access the NSS (shared) Database with OpenSSL in C++? The Code you
> told me is using the binary files. So first i want a solution for
> accessing it in C++-Code. Is it
73 matches
Mail list logo
