I think you need to take a step back and consider which
market and user-base you are targeting. Linux on the
desktop? Why bother with that? Linux servers? Well,
*that* could be interesting. Unfortunately it doesn't
help much since most servers run JBoss etc so it is
actually more a JDK problem. Although JBoss can use
NSS I bet essentially nobody use it.
Regarding per-application storage of private keys, Android
solved that by creating a specific user for each app.
Anders
On 2012-07-27 10:03, David Woodhouse wrote:
> 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 mailman breakage?
> My own S/MIME signed posts seem to have survived unscathed, but the
> actual signature part was missing from yours.)
>
>>> So what I actually want is
>>> - To fix the API to the NSS system database so it isn't insane.
>> Do you have any suggestions on how the API would be changes. One thing=20
>> I'm always fighting is providing an API for apps without breaking=20
>> existing apps.
>
> Well, *not* having to grub around for 'library=libnsssysinit.so'
> in /etc/pki/nssdb/pkcs11.txt in order to decide whether to open
> sql:/etc/pki/nssdb or sql:$HOME/.pki/nssdb would be my main request.
>
>> One idea might be to just for the use of NSS system DB under the covers. =
>>
>> We can control this from some sort of outside control (like an=20
>> environment variable). There is an issue about what the default should=20
>> be (on or off). Since NSS can open more than one database, we can open=20
>> the database the user requested as well. This would also mean apps will=20
>> start using the NSS system DB without requiring applications to change.
>
> That sounds ideal to me. In the general case, if a system database has
> been set up in /etc/pki/nssdb by the {sysadmin,distribution}, it should
> be used. If not, it shouldn't. The default behaviour, if it's *there*,
> should be to use it. With an environment variable to override that.
>
>> You may be thinking in a different direction, I would be interested in=20
>> hearing your ideas.
>
> I'd also pondered allowing a NULL argument as the dbpath to NSS_Init(),
> to indicate that the default database should be opened.
>
>>> - To fix Firefox, Thunderbird and the NSS samples to use it correctly=
>> =2E
>> Legacy is what has been holding FF and TB back. It would be relatively=20
>> easy to get FF or TB to use the sqlite database. It's been a real bear=20
>> trying to get anyone to work on doing database migration.
>
> Well, if we allow the old database to be used as a third slot, perhaps
> we don't *need* to migrate. For per-application private keys, we're
> going to need a "private" database in addition to the system-wide and
> user-wide ones anyway, right?
>
> So how about automatically opening not only /etc/pki/nssdb as a separate
> slot if that directory has a database in it, but *also* ~/.pki/nssdb. So
> firefox et all would just continue to open their legacy database, but
> automatically pull in the trusted CAs and any private keys which are
> installed in the other databases.
>
>>> - To go on a bombing run across all other NSS-using applications to
>>> fix those too (I've done Evolution already, but it'll need fixing
>>> once the API is made saner and it doesn't need to go grubbing aroun=
>> d
>>> in /etc/pki/nssdb/pkcs11.txt to work out what DB path to open.
>>> - To make the 'combined' system and user trust databases (two slots
>>> in the same token)
>> I'm not sure about your terminology here. Slots are locations for tokens =
>> to be plugged into (mapping to the PKCS #11 slots, which usually refer=20
>> to physical readers). Do you mean 2 slots in the same module?
>
> Sorry, yes. I mean 2 slots in the same module. I've managed to access
> *one* or the other of ~/.pki/nssdb and /etc/pki/nssdb by loading the
> softokn module via p11-kit, but not both.
>
> If we go for the "automatically open the extra slot" option that you
> suggested, I think this problem just solves itself.
>
>
>
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
