Who assigns algorithm OIDs for cryptographic algorithms?

Question

I am aware that this is at the border to security but I guess that I will rather find an answer here. The question is which institution generally assigns object identifiers for cryptographic algorithms so that they can be used in higher level protocols (with corresponding adoption of standards). I am aware that theoretically everyone can become an OID registry but I guess there is one that takes care of cryptographic algorithms.

Answer 1

No, there isn't a single one that takes care of the algorithms. Many algorithms do not have an OID, and many proprietary ones have OID's that aren't known.

The OID's are strictly hierarchical. The first digit is either 0, 1 or 2 indicating ITU-T, ISO or both. ITU-T and ISO are both international standards organizations that are then responsible for the next digits. This may include internal associations, but they may also be other organizations. Those organizations are then responsible for their part of the tree.

Of course, if anything is standardized by e.g. ISO then it will probably get an identifier somewhere in the tree of ISO. It could however be that the algorithm is already registered somewhere else, and in that case it may not get a new one. Or it could and you would have two ones identifying the same thing. It is up to the protocols to choose which ones you should use.

As there isn't one global registration authority for the insurmountable amount of algorithms, there isn't a single location in the tree either. And there doesn't need to be: an ID doesn't need to be ordered.

Commercial entities

It is perfectly possible for a commercial organization to get their own space in the OID tree:

{iso(1) member-body(2) nl(528) nederlandse-organisatie(1) enschede-sdu(1006)}

This space seems empty but the organization no doubt build their own tree internally. In this case I have very little doubt, in fact.

Examples

{joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) aes(1) aes128-CBC(2)}

So here the joint ISO / ITU-T has created a space for countries, and those countries can decide how to create their trees. Here CSOR is part of NIST, which has created a subspace for AES and then CBC mode.

---

 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) rsassa-pss(10)}

Here ISO identified the US, who has identified the RSA digital signature algorithm, PKCS#1 / PSS version.

---

{iso(1) member-body(2) us(840) ansi-x962(10045) signatures(4) ecdsa-with-SHA2(3) ecdsa-with-SHA384(3)}

Same thing, but now a national standardization institute: ANSI has created a standard with associated OID's.

Configuration

Important note: there are generally two ways of handling algorithms and OID's in data structures such as ASN.1, shown in the following X.509 (certificate) specification:

 AlgorithmIdentifier  ::=  SEQUENCE  {
      algorithm               OBJECT IDENTIFIER,
      parameters              ANY DEFINED BY algorithm OPTIONAL  }

1. every algorithm is fully identified, including any configuration option and the parameters are not present or NUL
2. the algorithm is specified, but it requires additional parameters to be specified.

You can see this in the above examples where the ECDSA algorithm is defined with the hash, while RSA PSS requires additional configuration parameters.

Structure?

For some fun, please see the following quote in the OID database here:

To the question "Are the OIW OIDs still in common use?", Peter Gutmann replied on June 23, 2004: "Some of the crypto ones still in use, this would include the DES-modes OIDs and some of the weird (obsolete) Secure Hash Algorithm (SHA) and Digital Signature Algorithm (DSA) ones that were (incorrectly) copied into Java Cryptography Extension (JCE) implementations. Examples of obsolete OIDs: {iso(1) identified-organization(3) oiw(14) secsig(3) algorithms(2) sha-1WithRSAEncryption(29)}; an obsolete DSA one that ended up in Common Data Security Architecture (CDSA) (so presumably "OS X crypto" will use it) and the German Public Key Infrastructure (PKI) work; and a variety of other odd bits and pieces. In general you need a many-to-one mapping where on write you emit the most appropriate OID and on read you allow any one of a number of OIDs, including incorrect ones (the Java Development Kit (JDK) one is actually dsaWithSHA0, but it's used as if it was dsaWithSHA1)."

Please do not expect all that much structure in the OID tree.