-
Bug
-
Resolution: Fixed
-
P2
-
1.4.0
-
None
-
beta2
-
generic
-
generic
sun.security.provider.certpath.X509CertificatePair has an incorrect ASN.1 encoding. It uses IMPLICIT tagging, whereas it should use EXPLICIT tagging. See X.509(2000) or X.509(1997) Annex A, which defines the CertificatePair structure in a module that uses EXPLICIT tagging (since the tagging method employed is not stated).
This means that this class will not be able to decode properly encoded CertificatePair structures. It will throw a CertificateException instead (with message string "Unable to initialize, java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big."). Also, any CertificatePair structures encoded using this class are not correctly encoded and will almost certainly be indecipherable to other implementations.
Fortunately, this class is not directly accessible using public APIs. Our LDAP CertStore implementation uses the class to parse values retrieved from crossCertificatePair attributes. So we will not be able to parse properly encoded values from such attributes until this bug is fixed, harming the ability of our CertPathBuilder to build paths using an LDAP directory. However, bug 4452233 harms this ability even more seriously. So the inability to parse properly encoded CertificatePairs is probably not a big issue, especially if we can fix it at the same time as 4452233. However, it will cause big problems if we don't fix it until after 4452233, so I have marked this bug with a fairly high priority and severity.
Our failure to properly encode CertificatePairs is not likely to cause problems (except for us), because this feature is not exposed (directly or indirectly) via any public APIs. The improper encoding has caused us (Sun Labs) some pain, as we had to reencode all of the CertificatePairs in our directory. We will help the JSSN SQE team to repopulate your directory once you have fixed this bug.
I have attached an incorrectly encoded CertificatePair, a correctly encoded CertificatePair, and code to dump a CertificatePair to this bug. The dump code can be used to demostrate the problem and its fix.
This means that this class will not be able to decode properly encoded CertificatePair structures. It will throw a CertificateException instead (with message string "Unable to initialize, java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big."). Also, any CertificatePair structures encoded using this class are not correctly encoded and will almost certainly be indecipherable to other implementations.
Fortunately, this class is not directly accessible using public APIs. Our LDAP CertStore implementation uses the class to parse values retrieved from crossCertificatePair attributes. So we will not be able to parse properly encoded values from such attributes until this bug is fixed, harming the ability of our CertPathBuilder to build paths using an LDAP directory. However, bug 4452233 harms this ability even more seriously. So the inability to parse properly encoded CertificatePairs is probably not a big issue, especially if we can fix it at the same time as 4452233. However, it will cause big problems if we don't fix it until after 4452233, so I have marked this bug with a fairly high priority and severity.
Our failure to properly encode CertificatePairs is not likely to cause problems (except for us), because this feature is not exposed (directly or indirectly) via any public APIs. The improper encoding has caused us (Sun Labs) some pain, as we had to reencode all of the CertificatePairs in our directory. We will help the JSSN SQE team to repopulate your directory once you have fixed this bug.
I have attached an incorrectly encoded CertificatePair, a correctly encoded CertificatePair, and code to dump a CertificatePair to this bug. The dump code can be used to demostrate the problem and its fix.
- relates to
-
JDK-4452233 LDAPCertStore omits binary option
-
- Resolved
-