search

DanElbert / vt-middleware

Automatically exported from code.google.com/p/vt-middleware
0 stars 0 forks source link

vt-crypt: Cannot Read CRLDistributionPoints for Some Certificates #100

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
ExtensionReader#readCRLDistributionPoints() produces the following error when 
trying to read some certificates:

java.lang.IllegalArgumentException: Expected ASN1Sequence but got 
org.bouncycastle.asn1.DERApplicationSpecific@d92a5694
  at edu.vt.middleware.crypt.x509.ExtensionFactory.createDistributionPointList(ExtensionFactory.java:452)
  at edu.vt.middleware.crypt.x509.ExtensionReader.readCRLDistributionPoints(ExtensionReader.java:281)

The certificate that produced the error above had the following CRL:

http://balamood2.cc.vt.edu:8080/ejbca/publicweb/webdist/certdist?cmd=crl&issuer=
CN=DEV Virginia Tech User CA,O=Virginia Polytechnic Institute and State 
University,DC=vt,DC=edu,C=US

Note this is an unusually long URI.

Original issue reported on code.google.com by marvin.addison@gmail.com on 28 Jan 2011 at 9:21

GoogleCodeExporter commented 8 years ago

Original comment by marvin.addison@gmail.com on 28 Jan 2011 at 9:21

GoogleCodeExporter commented 8 years ago 
Attached PEM-encoded certificate that produced stack trace in issue description.

Original comment by marvin.addison@gmail.com on 28 Jan 2011 at 9:24

Attachments:

GoogleCodeExporter commented 8 years ago 
Committed fix in r1813.  The root cause of this problem was a naive 
implementation of extracting the octets inside a DER octet string.  The former 
implementation always assumed that the length was encoded as a single byte, 
which is incorrect per the ASN.1 specification that allows an arbitrary number 
of bytes as needed to encode the octet length.  The cert attached to this issue 
would had a CRL URI of length 180, whose length would have been encoded as 2 
bytes.  The broken implementation thus treated the third byte of the length as 
the first byte of octets, which happened to be a non-standard DER tag and was 
thus interpreted as an application-specific type.

The new implementation only provides the "discard wrapper" feature for DER 
octet strings since that is the only use case for which the feature is needed 
at present.

Original comment by marvin.addison@gmail.com on 31 Jan 2011 at 8:45