405966 - Unknown signature OID 1.3.14.3.2.29 causes sec_error_bad_signature, 3.11 ignores it

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Kai Engert [:KaiE:]]

Attachment: server cert

Originally reported in bug 403220.

Test: attempt to open https://75.127.66.155:8443/

Firefox + NSS 3.11:
  Cert is reported with error dialogs "problem with issuer" 
  and "domain mismatch". 
  After overriding these errors, connecting is possible.

Firefox + NSS 3.12:
  Cert is rejected with error code sec_error_bad_signature


I'm attaching the server cert.
The attachment is a PEM file that contains both ascii encoding and a human readable dump. It can be converted to DER if needed.

Did NSS 3.12 regress?

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

The signature algorithm OID in this cert is OID.1.3.14.3.2.29 
That's an unknown OID to NSS.  
According to http://www.alvestrand.no/objectid/1.3.14.3.2.29.html 
it is SHA1 with RSA signature.

NSS 3.11.x would decode it producing SEC_OID_UNKNOWN, but then would
ignore that OID completely.  It used the fact that the signer's key
is an RSA key to decode the signature (that is, do the public key 
operation) and then took the hash algorithm ID from the decoded 
signature.  

NSS 3.12 has a bunch of new code to deal with Alg IDs that represent
both a hash algorithm and a public key signature algorithm (such as RSA).
NSS 3.12 uses that new code in the verification of cert signatures, 
and the new code does NOT ignore unknown algorithm IDs.  

So, from NSS's perspective, this is not a regression but rather a long 
standing bug (not recognizing this algorithm OID) that was prevsiously 
masked (hidden) by another bug (ignoring signature OIDs for RSA signatures)
that has now been fixed.  

The solution, I think, is to add this algorithm OID to NSS's table of 
known OIDs, and add the SECOIDTag for it into the switch in function 
sec_DecodeSigAlg in file secvfy.c.  I suspect there are other similar OIDs
(which represent hash and signature algorithms) that also should be added.

Bob, let me suggest that you take this bug.

Comment 2

[Robert Relyea]

I agree:

1.3.14.3.2 is the ISO SEC-SIG Algorithm space. Unfortunately ISO isn't happy with the standard OIDs defined in PKCS #1 and often include their own duplicates. This is one of those duplicates. As an ISO oid, it's prefectly valid (though not necessarily prefered), so we should support it.


bob

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Another example:   https://mail.wyke.ac.uk/

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Attachment: patch v1

This patch seems to fix it.  Julien, please review.

Comment 5

[Julien Pierre]

Comment on attachment 306190 [details] [diff] [review]
patch v1

Looks fine.

The change to VFY_VerifyDataWithAlgorithmID is not necessary. I prefer the existing code since sigAlg is only used once and is a read-only argument passed by value, unlike encAlg and hashAlg which are returned and thus have to be locals.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Thanks, Julien.  
The change to the VFY_ function enables me to set a conditional breakpoint, 
stopping in that function if the sigAlg is SEC_OID_UNKNOWN.

Checking in util/secoidt.h;    new revision: 1.27; previous revision: 1.26
Checking in util/secoid.c;     new revision: 1.43; previous revision: 1.42
Checking in cryptohi/secvfy.c; new revision: 1.22; previous revision: 1.21

Comment 7

[Steffan Corley]

While this fix does solve the issue for https://75.127.66.155:8443/, it doesn't solve the issue for https://mail.wyke.ac.uk/ (which now just reports a bad signature with no opportunity to add an exception).

Should this be the behaviour for https://mail.wyke.ac.uk/?  It's a pretty annoying regression over Firefox 2.0.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

When I visit the wyke URL, I get this error message:

> An error occurred during a connection to mail.wyke.ac.uk.
> Certificate key usage inadequate for attempted operation.
> (Error code: sec_error_inadequate_key_usage)

That's a different issue than this bug.  
The certificate is self-signed, which means that it is acting like a 
CA cert, and its public key is being used to verify the signature on 
a certificate, yet the certificate's extensions say that it is NOT a 
CA and that its key is NOT allowed to sign certificates.  NSS correctly
diagnoses all that.  There is no NSS bug here.  Your question concerns
how PSM handles a certificate with those errors.  You may file a bug 
against PSM if you wish.  

Comment 9

[Kai Engert [:KaiE:]]

See also bug 424077, bug 412277