7

Using the BouncyCastle library (although I guess the library is sort of irrelevant) I often run into algorithm IDs specified as ASN.1 identifiers. For example, the signature algorithm for a certificate might be "1.2.840.113549.1.1.11".

Is there a proper way to convert this into some kind of human-readable form that doesn't involve finding every ID I can get my hands on and manually building a gigantic lookup table?

Hakanai
  • 12,010
  • 10
  • 62
  • 132

4 Answers4

2

Specifically for signature algorithms, you can use the class org.bouncycastle.operator.DefaultAlgorithmNameFinder. But - if I'm not wrong - this was introduced only in newer versions (I'm using Bouncy Castle 1.57 - I also checked in 1.46 and it doesn't have this class).

The use is straighforward:

DefaultAlgorithmNameFinder algFinder = new DefaultAlgorithmNameFinder();
System.out.println(algFinder.getAlgorithmName(new ASN1ObjectIdentifier("1.2.840.113549.1.1.11")));

The output is:

SHA256WITHRSA

According to javadoc, if it can't find a human-friendly name, it returns the same OID used in the input.

Also note that (as stated in @pepo's answer) the human-friendly names might not be the same among different tools. While BouncyCastle returns SHA256WITHRSA, the OID repository website uses sha256WithRSAEncryption.

For other OIDs (such as extensions and other fields), I couldn't find anything in the API, so the only alternative seems to be the big lookup table.

1

There is IMHO no other way than building a mapping table. Every crypto library does that, ie. Openssl, .NET framework, BouncyCastle etc.

The problem is, that every library could (and often does) have different FriendlyName assigned to the same OID. For example Openssl has emailAddress while .NET translates it as E.

BouncyCastle has this mapping table implemented (sorry for the c# version link) here (and maybe in other places).

pepo
  • 8,644
  • 2
  • 27
  • 42
  • Yeah, they seem to spread it across multiple files all over the place too... one table for signature algorithms, one table for key purposes, one table for extensions, ... at the moment I'm building a giant lookup table from OID -> resource bundle key and then looking it up from there, but it's crazy if all applications which want to account for an invalid certificate have to go to this much effort just to show a nice-looking dialog to the user. :/ – Hakanai Sep 20 '17 at 23:10
1

Is there a proper way to convert this into some kind of human-readable form that doesn't involve finding every ID I can get my hands on and manually building a gigantic lookup table?

My experience with ASN.1 is that modules actually bind name to the OID:

sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 }

So that your ASN.1 parser can theoretically build the lookup table for you automatically.

Even more convenient would be if your ASN.1 library's OBJECT IDENTIFIER type implementation would attach the name to the OID object so that the humanity would be able to ask questions like:

oid.name

Instead of running the OID through a lookup table:

name = gigantic_oid2name_map[oid]

Ilya Etingof
  • 5,440
  • 1
  • 17
  • 21
  • I agree, it's too bad that BC doesn't at least put the standard symbolic name into the identifier. Then I'd have the perfect value I could just slap a prefix on and bam, there's my lookup key for the user-readable string. :) Maybe I'll try asking them whether they think it's worth adding. – Hakanai Sep 20 '17 at 23:13
1

Yes. It is this one: org.bouncycastle.asn1.pkcs.PKCSObjectIdentifiers.sha256WithRSAEncryption.

For extensions, see org.bouncycastle.asn1.x509.Extension list of ASN1ObjectIdentifier.

ezzadeen
  • 1,033
  • 10
  • 9