"IllegalArgumentException: string 2.5.4.8 not an OID" in verifyPki()

[GoogleCodeExporter]

Here is another exception case we need to handle with X.509. It's on 0.11.3, 
but I think the code hasn't changed much on 0.12.

The relevant line of code is:
org.spongycastle.asn1.x500.X500Name name = new X500Name(principal.getName());

java.lang.IllegalArgumentException: string 2.5.4.8 not an OID
at 
org.spongycastle.asn1.DERObjectIdentifier.<init>(DERObjectIdentifier.java:128)
at 
org.spongycastle.asn1.ASN1ObjectIdentifier.<init>(ASN1ObjectIdentifier.java:8)
at 
org.spongycastle.asn1.x509.X509ObjectIdentifiers.<clinit>(X509ObjectIdentifiers.
java:15)
at org.spongycastle.asn1.x500.style.BCStyle.<clinit>(BCStyle.java:160)
at org.spongycastle.asn1.x500.X500Name.<clinit>(X500Name.java:33)
at 
com.google.bitcoin.protocols.payments.PaymentSession.verifyPki(PaymentSession.ja
va:503)

Original issue reported on code.google.com by andreas....@gmail.com on 1 Oct 2014 at 4:06

[GoogleCodeExporter]

Odd. How often does this happen? The <clinit> suggests this is a bug in library 
initialisation code rather than the certificate itself:

    /** Subject RDN components: stateOrProvinceName = 2.5.4.8 */
    static final ASN1ObjectIdentifier    stateOrProvinceName     = new ASN1ObjectIdentifier("2.5.4.8");

Why is it not happy? This code should be executed by all users and is just 
initialising a static constant. Also 2.5.4.8 *is* an OID (in string format).

Original comment by mh.in.en...@gmail.com on 1 Oct 2014 at 5:56

[GoogleCodeExporter]

This specific exception is very rare. I emailed the reporter for details.

However there are similar errors in the ECKey constructor (maybe a wallet 
corrupt at byte level?):

java.lang.IllegalArgumentException: string 1.3.132.0.35 not an OID
at 
org.spongycastle.asn1.DERObjectIdentifier.<init>(DERObjectIdentifier.java:128)
at 
org.spongycastle.asn1.ASN1ObjectIdentifier.<init>(ASN1ObjectIdentifier.java:8)
at 
org.spongycastle.asn1.ASN1ObjectIdentifier.branch(ASN1ObjectIdentifier.java:24)
at 
org.spongycastle.asn1.sec.SECObjectIdentifiers.<clinit>(SECObjectIdentifiers.jav
a:41)
at org.spongycastle.asn1.sec.SECNamedCurves.<clinit>(SECNamedCurves.java:932)
at com.google.bitcoin.core.ECKey.<clinit>(ECKey.java:88)
at 
com.google.bitcoin.store.WalletProtobufSerializer.readWallet(WalletProtobufSeria
lizer.java:428)

The same happens with "1.3.132.0.33 not an OID" and "1.3.132.0.28 not an OID".

Original comment by andreas....@gmail.com on 2 Oct 2014 at 8:07

[GoogleCodeExporter]

That's kind of nuts. Well, the code has changed in the new Bouncy Castle. Let's 
see if these still crop up after 0.12 has rolled out. Perhaps there was a bug 
in the old version. Marking this as Low because the relevant code is old.

Original comment by mh.in.en...@gmail.com on 2 Oct 2014 at 10:51

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

The reporter from the first exception got back to me. He was using an "Oppo N1 
CyanogenMod Limited Edition" at a bar. He was able to pay with another phone, 
also others were able to pay with their phones against the same POS system (all 
using Bitcoin Wallet against a Bitpay POS).

So to me it looks like Cyanogenmod has a broken X.509 impl. It would not be the 
first time they break something seriously, but to their defense it can be said 
that their community is very run-nightly-builds-happy.

Original comment by andreas....@gmail.com on 4 Oct 2014 at 8:37

[GoogleCodeExporter]

Well this code is coming from SpongyCastle which is shipped with our app, so I 
doubt it is directly a broken X.509 impl there, unless they are (stupidly) 
shipping SC with the OS. The failure feels more like some kind of JVM 
b0rkenness really.

But seeing as we have no explanation, no way to reproduce and the user was 
running on a configuration known to sometimes be experimental, I will close 
this.

BTW how comes you don't get OS names back with error reports?

Original comment by mh.in.en...@gmail.com on 4 Oct 2014 at 1:19

• Changed state: WontFix

[GoogleCodeExporter]

Well this code is coming from SpongyCastle which is shipped with our app, so I 
doubt it is directly a broken X.509 impl there, unless they are (stupidly) 
shipping SC with the OS. The failure feels more like some kind of JVM 
b0rkenness really.

But seeing as we have no explanation, no way to reproduce and the user was 
running on a configuration known to sometimes be experimental, I will close 
this.

BTW how comes you don't get OS names back with error reports?

Original comment by mh.in.en...@gmail.com on 4 Oct 2014 at 1:19

[GoogleCodeExporter]

I do see OS names (if people report through app) but I didn't pay attention to 
it.

btw. The second exception (involving the ECKey initializer) happens on 
Blackphones.

I'm fine with closing this.

Original comment by andreas....@gmail.com on 4 Oct 2014 at 1:31