Regression/bug with OID content verification 1.77->1.78 ?

[martinpaljak]

This used to parse as valid OID with 1.77 with ASN1ObjectIdentifier.fromByteArray(oid):

[TRACE] GPData - Parsing 06092A864886FC6B048000 as OID
Tag 6: 1.2.840.114283.4.0

This also matches the result from https://lapo.it/asn1js/#BgkqhkiG_GsEgAA

With 1.78 I get instead:

Caused by: org.bouncycastle.asn1.ASN1Exception: invalid OID contents
	at org.bouncycastle.provider/org.bouncycastle.asn1.ASN1InputStream.createPrimitiveDERObject(Unknown Source)
	at org.bouncycastle.provider/org.bouncycastle.asn1.ASN1InputStream.buildObject(Unknown Source)
	at org.bouncycastle.provider/org.bouncycastle.asn1.ASN1InputStream.readObject(Unknown Source)
	at org.bouncycastle.provider/org.bouncycastle.asn1.ASN1Primitive.fromByteArray(Unknown Source)
	at pro.javacard.globalplatform@23.08.10-SNAPSHOT/pro.javacard.gp.GPData.oid2string(GPData.java:392)
	... 36 more
Caused by: java.lang.IllegalArgumentException: invalid OID contents
	at org.bouncycastle.provider/org.bouncycastle.asn1.ASN1ObjectIdentifier.createPrimitive(Unknown Source)
	... 41 more

This data comes from hardware and can't be changed. Even if incorrect by content, the visualization/parsing is handy. Is this a bug and/or is it possible to invoke parsing without content verification?

[martinpaljak]

OpenSSL also barfs on this (the last 0x80):

$ echo -n 06092A864886FC6B048000 | xxd -p -r | openssl asn1parse -inform der      
    0:d=0  hl=2 l=   9 prim: OBJECT            :BAD OBJECT:[2A864886FC6B048000]

[dghgit]

Okay, so the "8000" is the problem - I'm not surprised OpenSSL doesn't like it either - very odd thing for someone to do and definitely a violation of the encoding rules. I've added a system property, "org.bouncycastle.asn1.allow_wrong_oid_enc" which will ignore the specific case of a pointless extension byte.

Now up on https://www.bouncycastle.org/betas actual patch should appear shortly.

[dghgit]

Released.