313945 - Cannot use qualified certificate from every Mozilla product

Status: RESOLVED WORKSFORME

(NSS :: Libraries, enhancement)

Description

[Varga Viktor]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050803 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050803 Firefox/1.0+

Qualified certificates which are compatible with the corresponing RFCs should have only NonRep bit exclusively.

Now if i have an RFC compatible certificate, I can only use it from Thunderbird, but not from the Netscape Mail, and the Mozilla Mail.

This signing was not tested from Form Signing and with browsers side of these applications, but maybe they affect the browsers too.



Reproducible: Always

Steps to Reproduce:
1. get an RFC compilant certficate (it is enough if you make a certificate with NonRep bit only)
2. try to sign mails other than Thunderbird (Mozilla Mail, Netscape Mail)


Actual Results:  
tested versions
Mozilla Thunderbird 20050804 - ok
Netscape (Mail) 7.2, 8.0 - bug
Mozilla (Mail) (1.7.11 20050804) - bug

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Varga,  Is this bug a duplicate of bug 217721 or bug 191303 ??

Comment 2

[Varga Viktor]

(In reply to comment #1)
> Varga,  Is this bug a duplicate of bug 217721 or bug 191303 ??

No.

Because the hungarian law needs that the Qualified certificate should be 100% RCF compatible, now the Qualified certificates have only the Non Repudation bit.

This certificate profile (only nonrep bit in a certificate) was tested with the Mozilla and the Microsoft product line, from these products, only the Thunderbird can wokr with this profile.

I will do today, or on the next week more test, and ther results will be posted here.

(I think the previous bug, you mentioned is the qcStatement bug, which is not a bug, it is a RFC compatible working, with the unknown extensions.)

Comment 3

[Julien Pierre]

Viktor,

Which RFC(s) do you believe only allow your cert to have the non-repudiation key usage ?

Comment 4

[Varga Viktor]

You have right, i have forgotten the rfc.
It is RFC 3039.

Here it is:
http://www.ietf.org/rfc/rfc3039.txt

3.2.3  Key Usage

   The key usage extension SHALL be present.  If the key usage
   nonRepudiation bit is asserted then it SHOULD NOT be combined with
   any other key usage , i.e., if set, the key usage non-repudiation
   SHOULD be set exclusively.

   The key usage extension MAY be marked critical.

So a qualified certificate should have only a nonRep bit.
This is a reuirement in Hungary (by law) and I think, in the EU too.

Comment 5

[Kaspar]

(In reply to comment #4)
> It is RFC 3039.

Note that this one has been superseded by RFC 3739 in the meantime - which is less restrictive about the keyUsage bits:

> 1.1.  Changes since RFC 3039
> [...]
>       *  To better facilitate broad applicability of this profile, some
>          constraints on key usage settings in the key usage extension
>          have been removed.

> 3.2.4.  Key Usage
>
>    The key usage extension SHALL be present.  Key usage settings SHALL
>    be set in accordance with RFC 3280 definitions.  Further requirements
>    on key usage settings MAY be defined by local policy and/or local
>    legal requirements.

>  4.  Security Considerations
> [...]
>    Combining the nonRepudiation bit in the keyUsage certificate
>    extension with other keyUsage bits may have security implications
>    depending on the context in which the certificate is to be used.
>    Applications validating electronic signatures based on such
>    certificates should determine whether the present key usage
>    combination is appropriate for their use.


> This is a reuirement in Hungary (by law) and I think, in the EU too.

In Switzerland, the situation was comparable to yours until November last year. At that time, the technical specifications were adapted to allow qualified certificates to have the digitalSignature bit set, too... maybe the same will happen in Hungary also?

Comment 6

[Varga Viktor]

Yes, you have right again, this is superseeded, at first, i get here the older RFC, whicxh was in my memory.

In Hungary at the august 2005 was strictly prohibited, to leave something other in a qualified certificate than NonRep bit. It was a huge problem at that time, because none of the older software supported it, only the the Firefox, Thunderbird line supported it that time.
Now, these certificates are working on MS software too, first was the Office 2003 line.

The only thing that was needed in the MS Software, to modify the filtering the certificate selection, because they filtered the DigSig bit.

Now Im checked , what kind of software cannot work with qualified, and i saw, they were very old product lines:
Netscape (Mail) 7.2, 8.0 - bug 
Mozilla (Mail) (1.7.11 20050804) - bug 

Original Mozilla works as Seamonkey, and maybe the Netscape code line is not merged with the Firefox/Thunderbird prod. line.

I heard something about the Swiss version, but if i know well, at the end, these certificates also have nonrep only.
https://bugzilla.mozilla.org/show_bug.cgi?id=281811

I don't think that the in future of Hungarian qualified certificates will have DigSig together with NonREp, because, the govermental criteria is out, and the govermental usage releated certificates are spreading now.

Comment 7

[Kaspar]

(In reply to comment #6)
> I heard something about the Swiss version, but if i know well, at the end,
> these certificates also have nonrep only.

Yes, it's true that the three Swiss CAs currently certified under Swiss law (http://www.seco.admin.ch/sas/00229/00251/index.html?lang=en) still issue nonRepudiation-only certs for the time being, since they haven't updated their CP/CPS documents and procedures yet (Stephen, any plans for doing so? when?).

> https://bugzilla.mozilla.org/show_bug.cgi?id=281811

That bug is about the qcStatements and the criticality flag - that's yet another issue... But also in this case the latest regulation by the Swiss Government (http://www.bakom.admin.ch/org/grundlagen/00563/00564/00682/index.html?lang=en - only available in German and French, unfortunately) has been updated to allow the qcStatements extension to be either critical or non-critical.

Comment 8

[Varga Viktor]

That bug was linked here, to give some info about the Swiss Law, because, i didnt find it.

I didn't find any sources requesting critical qcStatement, it was a not too good decision. And it is the correct way to reject a critical extension, if you don't handle it.

Nowadays the qcStatement seems to be like an EULA.

The main question regarding this bug ticket is that, when will the Netscape change to Firefox/Thunderbird codebase. (Mozilla is discontinued, so this will not be corrected in it.)

Because the main problem with these softwares were, that you cannot import and use qualified certificates, because they are filtering (I think) only on DigSig bit.

Comment 9

[Julien Pierre]

NSS aims to comply with RFC3280, which allows nonRepudiation to be combined with other key usages. Even with the old RFC3039, such certs would have been compliant, since it was only a "SHALL NOT" recommendation. NSS never aimed to enforce that restriction in any way.
So, if you ran into problems with Mozilla applications, there might be another cause to the failure.

Please attach a cert with which you are having the problem. We don't need your private key.

Also, please retest in the current versions of Mozilla applications and report which are failing.

Comment 10

[Varga Viktor]

Seamonkey and Thunderbird works well, the old Mozilla is dsicontinued, and the Netscape now doesnot have mailer software. (i didnt find it in the Netscape 9.)
so because the problem is only in discontinued products, maybe this bug ticket is closeable.

Comment 11

[Julien Pierre]

Viktor,

Seamonkey is still around. Did you try version 1.1.5 ?

Comment 12

[Varga Viktor]

(In reply to comment #11)
> Viktor,
> 
> Seamonkey is still around. Did you try version 1.1.5 ?
> 
Yes. I tried, and works well.
(please check comment #10)

So this problem is only in discontinued products.

Comment 13

[Julien Pierre]

Due to comment 12, I am marking this bug WORKSFORME.