Bug 1577991 - org.mozilla.jss.netscape.security.util.ObjectIdentifier cannot parse OID arcs larger than Integer.MAX_VALUE
Summary: org.mozilla.jss.netscape.security.util.ObjectIdentifier cannot parse OID arcs...
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: jss
Version: 7.6
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Jack Magne
QA Contact: Asha Akkiangady
Depends On:
TreeView+ depends on / blocked
Reported: 2018-05-14 14:51 UTC by Alex Wood
Modified: 2018-10-30 11:01 UTC (History)
4 users (show)

Fixed In Version: jss-4.4.4-2.el7
Doc Type: No Doc Update
Doc Text:
This is a very low level fix with code that didn't even previously exist in JSS, thus not need for doco here in my opinion.
Clone Of:
Last Closed: 2018-10-30 11:00:36 UTC
Target Upstream Version:

Attachments (Terms of Use)
Test case to replicate error (1.19 KB, text/x-csrc)
2018-05-21 14:43 UTC, Alex Wood
no flags Details
Proposed patch to fix issue. (4.23 KB, patch)
2018-05-24 23:10 UTC, Jack Magne
no flags Details | Diff
Revised patch with BigInteger support. (7.60 KB, patch)
2018-06-05 01:31 UTC, Jack Magne
no flags Details | Diff

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:3188 None None None 2018-10-30 11:01:21 UTC

Description Alex Wood 2018-05-14 14:51:17 UTC
Description of problem:

We have an OID with a very long component, 1526059423098, which is greater than Integer.MAX_VALUE (2147483647). Unfortunately, org.mozilla.jss.netscape.security.util.ObjectIdentifier parses the OID components with Integer.valueOf(comp).intValue(); which obviously fails with a NumberFormatException.

For my purposes, a Long would be sufficient, but near as I can tell, the specifications don't have any real limit on the maximum value of an arc (except for the limits imposed by DER encoding). BouncyCastle works correctly [1], using Longs and BigIntegers as necessary.


Version-Release number of selected component (if applicable): jss-4.4.2

How reproducible: Always

Steps to Reproduce:
1. Attempt to create an ObjectIdentifier object with an arc larger than Integer.MAX_VALUE

Actual results: NumberFormatException

Expected results: an ObjectIdentifier object

Comment 3 Alex Wood 2018-05-21 14:43:45 UTC
Created attachment 1439642 [details]
Test case to replicate error

% javac -cp ~/.m2/repository/org/mozilla/jss/4.4.0/jss-4.4.0.jar OIDTest.java
% java -Djava.library.path=/usr/lib64/jss -cp ~/.m2/repository/org/mozilla/jss/4.4.0/jss-4.4.0.jar:. OIDTest
java.lang.NumberFormatException: For input string: "1526913300628"
        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
        at java.lang.Integer.parseInt(Integer.java:583)
        at java.lang.Integer.valueOf(Integer.java:766)
        at org.mozilla.jss.netscape.security.util.ObjectIdentifier.<init>(ObjectIdentifier.java:74)
        at OIDTest.testOidLong(OIDTest.java:29)
        at OIDTest.main(OIDTest.java:34)

Note that I am using an upstream version of JSS that has the ObjectIdentifier class that previously resided in Dogtag.

Comment 4 Jack Magne 2018-05-23 18:54:50 UTC
I will take this and get the ball rolling. Unless someone else on the team feels a need to look into it.

Comment 5 Jack Magne 2018-05-24 17:39:22 UTC
I"ve hopped on this already.

Looks like we are treating each component of the oid as an int, of course. The test case is useful, thanks.

The fix will be to modify the class to keep a list of longs instead of ints.

Once the code is done, some decent testing will need to take place, since there is a lot of encoding and decoding of the values taking place.

Will attach a patch here as soon as something is working.

Comment 6 Jack Magne 2018-05-24 23:09:51 UTC
Coded up solution to this, based on some simple testing.

Will attach the patch I have here in case you guys would want to try it out.

Tested simply with the following test code:

public static void main(String[] args) {

        long[] oid_components_long = { 1L, 3L,6L,1L,4L,1L,2312L,9L,1L,1L,1526913300628L, 1L};
        int[] oid_components_int =  { 1, 3,6,1,4,1,2312,9,1,1,15269, 1, 1};

        String oidIn = "";
        ObjectIdentifier oid = new ObjectIdentifier(oidIn);

        ObjectIdentifier fromDer = null;
        ObjectIdentifier fromStaticMethod = null;
        ObjectIdentifier fromComponentList = null;
        ObjectIdentifier  fromComponentListInt = null;

        System.out.println("oid: " + oid.toString());

        DerOutputStream out = new DerOutputStream();

        try {
            DerInputStream  in = new DerInputStream(out.toByteArray());
            fromDer = new ObjectIdentifier(in);

            System.out.println("fromDer: " + fromDer.toString());

            fromStaticMethod = ObjectIdentifier.getObjectIdentifier(oidIn);

            System.out.println("fromStaticMethod: " + fromStaticMethod.toString());

            fromComponentList = new ObjectIdentifier(oid_components_long);

            System.out.println("fromComponentList: " + fromComponentList.toString());

            fromComponentListInt = new ObjectIdentifier(oid_components_int);

            System.out.println("fromComponentListInt: " + fromComponentListInt);

        } catch (IOException e) {


Comment 7 Jack Magne 2018-05-24 23:10:39 UTC
Created attachment 1441303 [details]
Proposed patch to fix issue.

Comment 8 Jack Magne 2018-05-24 23:12:44 UTC
Test output:


Comment 9 Alex Wood 2018-05-25 13:49:10 UTC

I think maybe the OID arcs should be read as BigIntegers since the ASN.1 spec doesn't place a limit on any arcs beyond the first and second: "Primary integer values for arcs (and the corresponding integer-valued Unicode label) are unbounded, except [root arcs and arcs under root arcs 0 and 1]"

Comment 10 Jack Magne 2018-05-25 18:22:08 UTC

I see what you are saying, but I wanted to take a quick pass to get it working. Also going from an int to a long seemed a more straightforward jump.

I will take a look though.


Comment 11 Jack Magne 2018-06-05 01:31:14 UTC
Created attachment 1447663 [details]
Revised patch with BigInteger support.

This seems to work.

Comment 12 Jack Magne 2018-06-21 02:45:48 UTC
Putting this one on POST due to the fact that this feature bug includes this fix:

Bug 1560682 - (RFE) Migrate RHCS x509 cert and crl functionality to JSS.

Comment 13 Matthew Harmsen 2018-06-22 05:12:37 UTC
Jack Magne 2018-06-20 22:35:29 EDT


 Address Bugzilla: Bug 1560682 - (RFE) Migrate RHCS x509 cert and crl …

…functionality to JSS.

    This consists of a migration of low level X509 cert and crl related classes from dogtag into JSS.
    This initial migration will allow users of jss to utilize these classes to create certs and crls.

    The initial goal is to simply provide the classes from dogtag to be used in JSS.
    A later goal will be to refactor dogtag to use the classes moved to JSS, but that will be for
    a future ticket.

    This migration will also address this issue:

    Bug 1577991 - org.mozilla.jss.netscape.security.util.ObjectIdentifier cannot parse OID arcs larger than Integer.MAX_VALUE.

    The file ObjectIdentifier.java has been modified to use BigInt instead of the int type, allowing for a greater range of values.
    Fixed minor classpath issue.

    JSS_4_4_BRANCH (#10) 

jmagne committed 5 days ago
1 parent f6df4da commit 06eacad918e745d632067deea398f14ce9da29ac

Comment 15 Roshni 2018-08-30 20:55:10 UTC
[root@nocp1 ecc]# rpm -q jss
[root@nocp1 ecc]# rpm -qi jss
Name        : jss
Version     : 4.4.4
Release     : 3.el7
Architecture: x86_64
Install Date: Thu 26 Jul 2018 10:38:39 AM EDT
Group       : Unspecified
Size        : 1456493
License     : MPLv1.1 or GPLv2+ or LGPLv2+
Signature   : RSA/SHA256, Mon 16 Jul 2018 04:07:45 PM EDT, Key ID 199e2f91fd431d51
Source RPM  : jss-4.4.4-3.el7.src.rpm
Build Date  : Mon 16 Jul 2018 03:48:21 PM EDT
Build Host  : x86-038.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://www.dogtagpki.org/wiki/JSS
Summary     : Java Security Services (JSS)

Sanity tests look good

Comment 17 errata-xmlrpc 2018-10-30 11:00:36 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.


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