cert8.db rewrite reasons and exceptions?

[helpcrypto helpcrypto]

Hi all.

Due some problems using Thunderbird ESR, we have found the following,
and would like to ask the experts...

We have noticed Thunderbird 10.3 (probably older versions too)
"rewrites" cert8.db each time it closes. The file its the same, but
the modified date has changed.
- Is this normal?
- There is a technical/security reason?

More test have shown cert8.db is not modified/rewrited after adding
our PKCS#11 module in secmod.db. (!)
Our PKCS#11 is working OK for a long time without any problems, but
there must be something wrong in here to prevent the "default
behaviour", right?
Why is this happening?

Going to test on a debug environment to get some traces.

[helpcrypto helpcrypto]

[helpcrypto helpcrypto]

Cough, cough...exit(CKR_OK) != return CKR_OK...cough, cough
Now cert8 is modified always (with or without our module).

Anyway, can someone tell me why cert8 is rewrited on each run/close?

[helpcrypto helpcrypto]

[Robert Relyea]

On 03/27/2012 01:00 AM, helpcrypto helpcrypto wrote:
> Cough, cough...exit(CKR_OK) != return CKR_OK...cough, cough
> Now cert8 is modified always (with or without our module).
>
> Anyway, can someone tell me why cert8 is rewrited on each run/close?

Because that's how the old berkeley DB works. It's weirdness like this
that caused us to implement the new sql-lite db. It just hasn't been
integrated into mozilla yet.

bob

[helpcrypto helpcrypto]

Thanks for the info. Countdown to sqlite...

[Anders Rundgren]

On 2012-04-02 21:07, Robert Relyea wrote:
> On 03/27/2012 01:00 AM, helpcrypto helpcrypto wrote:
>> Cough, cough...exit(CKR_OK) != return CKR_OK...cough, cough
>> Now cert8 is modified always (with or without our module).
>>
>> Anyway, can someone tell me why cert8 is rewrited on each run/close?
> Because that's how the old berkeley DB works. It's weirdness like this
> that caused us to implement the new sql-lite db. It just hasn't been
> integrated into mozilla yet.

I think that NSS is in need of a major upgrade:

http://nelenkov.blogspot.se/2011/11/ics-credential-storage-implementation.html

PC-based *NIX will soon be the only system lacking a *unified* keystore
scheme based on a system service.

Anders

[helpcrypto helpcrypto]

IIRC, NSS doesnt have an official mantainer on Mozilla bugs, isnt it?
If this happens, its probably the source of many problems here. I have
filed a few bugs and most of then arent even checked.
To be fair & honest, im also guilty of that, but i dont feel confident
enough to edit Mozilla source.
Could any expert make a workshop and teach us(me) how to ?
I thinks this could be a quite simple
start:https://bugzilla.mozilla.org/show_bug.cgi?id=670895

Having this "unified keystore", has ever been discussed between
mozilla and unix people?
What did they decide?

[Anders Rundgren]

I think this remains something that only vendors like Microsoft,
Google and Apple can do; the general *NIX lot is too divided to
settle on such a thing. Mozilla should IMO rather hook into the
other vendors cryptographic solution, possibly at the expense of NSS.

According to a college of mine Chrome even use the platform's SSL
implementation! Well, not in *NIX since there is no such thing...

In JDK/JRE Oracle (previously SUN) have native support for CAPI
which is "unclean" but is what Windows(-only) developers would prefer.
Then you get away from spicing your server-apps with a gazillion static
password configs that fill absolutely no security purpose!

Anders

[Wan-Teh Chang]

On Wed, Apr 4, 2012 at 12:47 PM, Anders Rundgren
<anders....@telia.com> wrote:
>
> Mozilla should IMO rather hook into the
> other vendors cryptographic solution, possibly at the expense of NSS.
>

> According to a [colleage] of mine Chrome even use the platform's SSL

> implementation!  Well, not in *NIX since there is no such thing...

Yes, early versions of Chrome used the platform's SSL implementation.
That strategy became restrictive when we needed the server name
indication extension support but it isn't available by the SChannel
library on Windows XP. Today Chrome uses the SSL implementation from
NSS, but still uses the platform's certificate and key store and the
platform's certificate verification function.

On Linux Chrome uses the NSS sqlite certificate and key databases in
$HOME/.pki/nssdb, as proposed in
https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX.

Using the platform's certificate and key store has worked well in
general. There are some minor problems due to uneven support of
features across versions of the platform. For example, ECC
certificates are not supported on Windows XP, and SHA-256 certificate
support on Windows XP requires service pack 3.

As for hooking into other vendors cryptographic solution -- in my
biased opinion, although some OS vendors cryptographic solutions are
indeed better than NSS, NSS is still better than others. My current
recommendation is to only use the platform certificate and key store
(and the trusted root certificate list, if appropriate for your
product). This may require using the OS vendors cryptographic library
for private key operations because private keys cannot be extracted
from the platform key store in general.

Wan-Teh

[helpcrypto helpcrypto]

So, IIUC, both of you consider using system/os/platform keystore
(directly [or hooked]) the "best" option?

[helpcrypto helpcrypto]

[Anders Rundgren]

On 2012-04-09 10:27, helpcrypto helpcrypto wrote:
> So, IIUC, both of you consider using system/os/platform keystore
> (directly [or hooked]) the "best" option?

IMHO it depends quite a bit on what your target audience is.

If you (for example) are working with server-applications you
are likely to either use .NET or Java. For .NET the Windows
keystore is by far the easiest to use. For Java the situation
is a little bit less clear but most people probably use the Java
system unless they use HSMs which typically are supported by
PKCS #11 which can be used from java but unfortunately not on
Windows 64-bit.

For client-based solutions, I definitely think that the native
platform keystore should be used if possible. For 1-2% using
Desktop *NIX the options are plentiful which for some people
is considered an advantage but I consider difficult.

Anders

[helpcrypto helpcrypto]

> IMHO it depends quite a bit on what your target audience is.

Document signing on a web browser, its *always* done using a java applets.

Tax payment, traffic bills, more taxes...in hour case, official
documents signed by the "ministry" autorized people.

[Anders Rundgren]

That's interesting! You might want to look into this:

http://www.w3.org/2011/11/webcryptography-charter.html

"The ability to select credentials and sign statements can be necessary to perform
high-value transactions such as those involved in finance, corporate security, and
identity-related claims about personal data"


I'm rather skeptical about this group's ability creating a standard for web signatures.
FWIW, I have since *very* long time back toyed with a web standards proposal

http://webpki.org/papers/wasp/wasp-tutorial.pdf

which I may turn into real when/if I succeed with the enrollment/keystore standard
that I [nowadays...] consider having *much* higher priority than signatures:

http://webpki.org/papers/keygen2/sks-keygen2-exec-level-presentation.pdf

Anders

[helpcrypto helpcrypto]

> http://www.w3.org/2011/11/webcryptography-charter.html

BSmith ans RRelyea directed me there also. All fishes go to sea... ;)

> http://webpki.org/papers/wasp/wasp-tutorial.pdf
> http://webpki.org/papers/keygen2/sks-keygen2-exec-level-presentation.pdf

I think i already read both documents some time ago.

[Anders Rundgren]

On 2012-04-09 12:13, helpcrypto helpcrypto wrote:
>> http://www.w3.org/2011/11/webcryptography-charter.html
>
> BSmith ans RRelyea directed me there also. All fishes go to sea... ;)

The really big fishes (Google, Apple, and Microsoft) haven't said a word
(in public) about their interest in this. I think they have reasons to
wait for Mozilla to release their signature solution...

>> http://webpki.org/papers/wasp/wasp-tutorial.pdf
>> http://webpki.org/papers/keygen2/sks-keygen2-exec-level-presentation.pdf
>
> I think i already read both documents some time ago.

Isn't the inferiority of the soft token implementations a problem?

In Sweden, banks rejected these since PIN-code protection isn't controllable.
They opted for PKCS #12 containers protected by 12-character passphrases.
Pretty inconvenient but what else could they possible do?

Related: The IETF has recently started the development of yet another
PKI enrollment scheme that doesn't support PIN-code provisioning!

Anders

[helpcrypto helpcrypto]

On Mon, Apr 9, 2012 at 6:16 PM, Anders Rundgren
<anders....@telia.com> wrote:
> On 2012-04-09 12:13, helpcrypto helpcrypto wrote:
>>> http://www.w3.org/2011/11/webcryptography-charter.html
>>
>> BSmith ans RRelyea directed me there also. All fishes go to sea... ;)
>
> The really big fishes (Google, Apple, and Microsoft) haven't said a word
> (in public) about their interest in this.  I think they have reasons to
> wait for Mozilla to release their signature solution...

Really? And the mozilla signature solution (apart from current NSS)
is/going to be...? shared nss db? the result of that wg?

>>>    http://webpki.org/papers/wasp/wasp-tutorial.pdf
>>> http://webpki.org/papers/keygen2/sks-keygen2-exec-level-presentation.pdf
>>
>> I think i already read both documents some time ago.
>
> Isn't the inferiority of the soft token implementations a problem?

Well...the real problem is thats not working as it should (IMHO). With
a few changes in the way its compiled +sqlite, nss will be greatly
improved.

> In Sweden, banks rejected these since PIN-code protection isn't controllable.
> They opted for PKCS #12 containers protected by 12-character passphrases.
> Pretty inconvenient but what else could they possible do?

Disagree. PKCS#12 is easier to crack than a crypto-card protected by
the simplest PIN.

> Related: The IETF has recently started the development of yet another
> PKI enrollment scheme that doesn't support PIN-code provisioning!

link?