1112487 - The signing certificates with key usage only non-repudiation is taken as invalid for signing

Status: RESOLVED FIXED

(Core :: Security: PSM, defect)

Description

[Toomas Nurmoja]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 20141127110442

Steps to reproduce:

1. Import signing certificate (key usage: only non-repudiation) to Thunderbird certificate manager.
2. set the signing certificate to the imported certificate
3. sign with certificate and send the message.



Actual results:

For the received singed message Thunderbird claims that:

"The received message has signature, but the signature is invalid"
"The certificate used to sign the message was issued by a certificate authority that you do not trust for issuing this kind of certificate."




Expected results:

Thunderbird should inform that "message is signed" and "includes a valid signature". 

If the signing certificate has in key usage field in addition to  non-repudiation the digital signature usage, then message "includes a valid signature".  According the RFC5820:

"The digitalSignature bit is asserted when the subject public key is used for verifying digital signatures, other than signatures on certificates (bit 5) and CRLs (bit 6), such as those used in an entity authentication service, a data origin authentication service, and/or an integrity service.
The nonRepudiation bit is asserted when the subject public key is used to verify digital signatures, other than signatures on certificates (bit 5) and CRLs (bit 6), used to provide a non-repudiation service that protects against the signing entity falsely denying some action."

Not to trust the certificates with only non-repudiation key usage field is not correct way.

Comment 1

[Kaspar]

(In reply to Toomas Nurmoja from comment #0)
> Not to trust the certificates with only non-repudiation key usage field is
> not correct way.

It's usually better to only describe the issue rather than trying to diagnose/guess the cause, unless you've really looked at the underlying code. NSS (and Thunderbird, therefore) will gladly accept a nonRepudiation-(aka contentCommitment)-KU-extension-only certficate for S/MIME message signing, cf.

https://hg.mozilla.org/projects/nss/annotate/05473539d2c3/lib/certdb/certdb.c#l1179

and bug 217721 comment 16 ff.

The cause of your issue must be different one, though the current PSM code makes it fairly difficult to figure out what the real verification error is, unfortunately - quite a few of these cases are collapsed into "SIUntrustedCA" (as mentioned in bug 336599 comment 30), see

https://hg.mozilla.org/comm-central/file/d655acbc5efe/mailnews/extensions/smime/content/msgReadSecurityInfo.js#l95

(Also, note that without having a test message [.eml file] attached to this bug which allows reproducing the problem it's virtually impossible to further track this down.)

Comment 2

[Kaspar]

(In reply to Kaspar Brand from comment #1)
> The cause of your issue must be different one

Wait... seems that your guess was probably right, when considering Tb 31 or later - as a consequence of bug 915930: I didn't realize that PSM completely abandoned NSS in favor of mozilla::pkix for certificate validation, even for S/MIME (I was under the impression that mozilla::pkix was targeted at SSL/TLS only).

The current implementation in CertVerifier.cpp indeed only supports the digitalSignature KU for email signing. I'm going to attach a patch which adds support for a nonRepudiation-only KU cert for the certificateUsageEmailSigner case.

Comment 3

[Kaspar]

Attachment: Also accept nonRepudiation only keyUsage extension for message signing

David, are you ok with restoring the certUsageEmailSigner case from NSS (and CERT_VerifyCertificate) in CertVerifier (see also comment 1 above)?

Comment 4

[Toomas Nurmoja]

(In reply to Kaspar Brand from comment #3)
> Created attachment 8538283 [details] [diff] [review]
> Also accept nonRepudiation only keyUsage extension for message signing

Thank you ! This patch will help me a lot.

Comment 5

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Comment on attachment 8538283 [details] [diff] [review]
Also accept nonRepudiation only keyUsage extension for message signing

Review of attachment 8538283 [details] [diff] [review]:
-----------------------------------------------------------------

This seems reasonable, but please do a try build and ensure that this fixes the problem before checking it in.

Comment 6

[Kaspar]

(In reply to David Keeler (:keeler) [use needinfo?] from comment #5)
> This seems reasonable, but please do a try build and ensure that this fixes
> the problem before checking it in.

I neither have tryserver nor commit privileges, but I did build Tb with this patch applied and verified that a message signed with a non-repudiation-KU-only cert again successfully verifies. (Note that for Tb 31.3.0, there's still the option to temporarily disable security.use_mozillapkix_verification, which will make verification succeed again - that's what originally helped me in tracking down the issue).

If someone else submits a try build, this would allow the reporter to re-test, I assume (Toomas: are you able to attach a sample message, in any case?).

Comment 7

[Toomas Nurmoja]

Attachment: Sample message

> If someone else submits a try build, this would allow the reporter to
> re-test, I assume (Toomas: are you able to attach a sample message, in any
> case?).

Yes, I created in test environment a sample message. I attach it with CA certificate. 

Toomas

Comment 8

[Kaspar]

(In reply to Toomas Nurmoja from comment #7)
> Yes, I created in test environment a sample message. I attach it with CA
> certificate. 

Thanks. I can confirm that applying the patch from attachment 8538283 [details] [diff] [review] does fix the issue - verification of the message signed by the "User 1" certificate (with a nonRepudiation-only KU extension) succeeds again.

Adding the checkin-needed keyword.

Comment 9

[Carsten Book [:Tomcat]]

can we get a try run link here thanks!

Comment 10

[Kaspar]

(In reply to Carsten Book [:Tomcat] from comment #9)
> can we get a try run link here thanks!

Magnus, would you be willing to submit a tryserver build for me? Seems that otherwise we can't proceed with fixing this bug (a regression introduced with Tb 31, actually).

Comment 11

[Magnus Melin [:mkmelin]]

Sure, here you go - https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=1e69ec931de3

Comment 12

[Kaspar]

(In reply to Magnus Melin from comment #11)
> Sure, here you go -
> https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=1e69ec931de3

Thanks. Looking at other runs from these days, "533 success 2 failed 5 busted 0 exception 11 retry" seems like the expected outcome for a mozilla-central build these days (or more specifically, the failures can't be attributed to the changes introduced with this patch).

Re-adding the checkin-needed keyword.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f1ba8432414d

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/f1ba8432414d