Bug 1534761 - SignerInfo class inserts wrong version # into the resulting structure
Summary: SignerInfo class inserts wrong version # into the resulting structure
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: jss
Version: 7.5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Christina Fu
QA Contact: ipa-qe
URL:
Whiteboard:
Depends On: 1534760
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-01-15 21:59 UTC by Matthew Harmsen
Modified: 2018-04-10 17:57 UTC (History)
13 users (show)

Fixed In Version: jss-4.4.0-11.el7
Doc Type: No Doc Update
Doc Text:
undefined
Clone Of: 1534760
Environment:
Last Closed: 2018-04-10 17:56:52 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Test program for verifying the fix. (2.28 KB, text/plain)
2018-01-31 08:10 UTC, Fraser Tweedale
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Mozilla Foundation 386351 0 None None None 2019-04-03 07:13:02 UTC
Red Hat Product Errata RHBA-2018:0958 0 None None None 2018-04-10 17:57:58 UTC

Description Matthew Harmsen 2018-01-15 21:59:06 UTC
+++ This bug was initially created as a clone of Bug #1534760 +++

The CMS rfc (http://www.faqs.org/rfcs/rfc3852.html) says the following about SignerInfo version:

     "version is the syntax version number.  If the SignerIdentifier is
      the CHOICE issuerAndSerialNumber, then the version MUST be 1.  If
      the SignerIdentifier is subjectKeyIdentifier, then the version
      MUST be 3."

I have constructed a SignerInfo object passing in a SignerIdentifier as the first argument that was constructed with an IssuerAndSerialNumber and the resulting structure has a version of 3 when it should have a version of 1 according to the spec.

Reproducible: Always

Steps to Reproduce:
1. construct an IssuerAndSerialNumber
2. construct a SignerIdentifier using the IssuerAndSerialNumber you just created
3. construct a SignerInfo using the SignerIdentifier you just created
4. call getVersion() on the resulting SignerInfo object and get a 3
Actual Results:  
SignerInfo.getVersion() returns a 3

Expected Results:  
SignerInfo.getVersion() returns a 1

I haven't tested what version you get if you make a SignerIdentifier with a SubjectKeyIdentifier.

Comment 5 Fraser Tweedale 2018-01-31 08:08:52 UTC
Steps to verify.

0. yum install java-1.8.0-openjdk-devel

1. download test program (which I am about to attach as 'test.java')

2. create a new NSSDB: `mkdir nssdb && certutil -d nssdb -N`
   Set a password for the nssdb.

3. compile test program: javac -classpath /usr/lib/java/jss4.jar test.java

4. run test program: java -classpath /usr/lib/java/jss4.jar:. Main nssdb
   Provide password from step 2.

5. Check that program output is correct.  A fixed version should display:

      Version (should be 1) = 1
      Version (should be 3) = 3

whereas the older version will have `3' on both lines:

      Version (should be 1) = 3 
      Version (should be 3) = 3

HTH!
Fraser

Comment 6 Fraser Tweedale 2018-01-31 08:10:18 UTC
Created attachment 1388794 [details]
Test program for verifying the fix.

Comment 7 Sumedh Sidhaye 2018-01-31 09:01:59 UTC
Build used for verification

root@csqa4-guest01 test1534761 # rpm -qi jss
Name        : jss
Version     : 4.4.0
Release     : 11.el7
Architecture: x86_64
Install Date: Monday 29 January 2018 10:37:07 PM EST
Group       : System Environment/Libraries
Size        : 1029926
License     : MPLv1.1 or GPLv2+ or LGPLv2+
Signature   : RSA/SHA256, Monday 22 January 2018 07:02:01 PM EST, Key ID 199e2f91fd431d51
Source RPM  : jss-4.4.0-11.el7.src.rpm
Build Date  : Monday 22 January 2018 06:17:27 PM EST
Build Host  : x86-040.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://www.mozilla.org/projects/security/pki/jss/
Summary     : Java Security Services (JSS)


root@csqa4-guest01 test1534761 # mkdir nssdb; certutil -d nssdb -N
Enter a password which will be used to encrypt your keys.
The password should be at least 7 characters long,
and should consist of at least three character classes.
The available character classes are: digits (0-9), ASCII
lowercase letters, ASCII uppercase letters, ASCII
non-alphanumeric characters, and non-ASCII characters.

If an ASCII uppercase letter appears at the beginning of
the password, it is not counted toward its character class.
Similarly, if a digit appears at the end of the password,
it is not counted toward its character class.

Enter new password: 
Re-enter password: 


root@csqa4-guest01 test1534761 # vim test.java

root@csqa4-guest01 test1534761 # javac -classpath /usr/lib/java/jss4.jar test.java

root@csqa4-guest01 test1534761 # java -classpath /usr/lib/java/jss4.jar:. Main nssdb
Enter password for NSS FIPS 140-2 User Private Key

Version (should be 1) = 1
Version (should be 3) = 3

Since the test java program gives us the expected result marking this bug verified.

Comment 10 errata-xmlrpc 2018-04-10 17:56:52 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0958


Note You need to log in before you can comment on or make changes to this bug.