Closed Bug 405966 Opened 14 years ago Closed 14 years ago

Unknown signature OID causes sec_error_bad_signature, 3.11 ignores it


(NSS :: Libraries, defect, P1)



(Not tracked)



(Reporter: KaiE, Assigned: nelson)




(Keywords: regression, Whiteboard: NSS312)


(2 files)

Attached file server cert
Originally reported in bug 403220.

Test: attempt to open

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?
The signature algorithm OID in this cert is OID. 
That's an unknown OID to NSS.  
According to 
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 

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.
Assignee: nobody → rrelyea
Priority: -- → P1
Target Milestone: --- → 3.12
Version: 3.12 → trunk
Summary: nss 3.12 rejects cert with sec_error_bad_signature, 3.11 accepts it → Unknown signature OID causes sec_error_bad_signature, 3.11 ignores it
I agree: 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.

Another example:
Whiteboard: NSS312
Attached patch patch v1Splinter Review
This patch seems to fix it.  Julien, please review.
Assignee: rrelyea → nelson
Attachment #306190 - Flags: review?(julien.pierre.boogz)
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.
Attachment #306190 - Flags: review?(julien.pierre.boogz) → review+
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
Closed: 14 years ago
Resolution: --- → FIXED
While this fix does solve the issue for, it doesn't solve the issue for (which now just reports a bad signature with no opportunity to add an exception).

Should this be the behaviour for  It's a pretty annoying regression over Firefox 2.0.
When I visit the wyke URL, I get this error message:

> An error occurred during a connection to
> 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.  
See also bug 424077, bug 412277
You need to log in before you can comment on or make changes to this bug.