This is the ASN.1 OID space for the ARPA2 / InternetWide project.

Allocations underneath it will be allocated per project that requires it. This is most likely to scale well, might it ever come to distributing the control over the OID space over self-supporting projects.

Currently reserved OID trees -- do not grab any of these without discussion; you'll probably get a delegation further down to allow for neighbouring project work; we will add owner names other than ARPA2 to actually handed-out OIDs.

Top-level listing

Details follow for some of the trees.

OID                                      | Descriptive name              | Owner
-----------------------------------------+-------------------------------+----------                        | ARPA2                         | ARPA2                     | ARPA2-PKCS11                  | ARPA2                     | ARPA2-DNS                     | ARPA2                  | ARPA2-DNSSEC                  | ARPA2              | ARPA2-DNSSEC-SNMP             | ARPA2                  | ARPA2-DANE                    | ARPA2                   | ARPA2-Service                 | ARPA2                | ARPA2-Service-YOURREALM       | ARPA2               | ARPA2-Service-LDAPhosting     | ARPA2               | ARPA2-Service-ENUM            | ARPA2                     | ARPA2-Kerberos                | ARPA2                 | ARPA2-Kerberos-DH             | ARPA2                    | ARPA2-SNMP                    | ARPA2                    | ARPA2-LDAP                    | ARPA2                  | ARPA2-SteamWorks              | ARPA2                  | ARPA2-TLSPool                 | ARPA2                 | ARPA2-Access                  | ARPA2                    | ARPA2-Experimental            | ARPA2

Experimental work (such as Student assignments)

OID                                 | Descriptive name                         | Owner
------------------------------------+--------------------------------------+----------               | ARPA2-Experimental                       | ARPA2        | ARPA2-Experimental-PKCS11-LDAP           | ARPA2      | ARPA2-Experimental-PKCS11-LDAP-URI       | Van Rein      | ARPA2-Experimental-TLSPool-LDAP          | Van Rein          | ARPA2-Experimental-SMTP-CommFilter       | Van Rein            | ARPA2-Experimental-DNS                   | ARPA2         | ARPA2-Experimental-DNSSEC                | ARPA2     | ARPA2-Experimental-DNSSEC-SNMP           | ARPA2   | ARPA2-Experimental-DNSSEC-MIBv1          | Leucht & Nyczak            | ARPA2-Experimental-DB-TupleShare         | Van Rein          | ARPA2-Experimental-KRB5-XOVER            | Van Rein         | ARPA2-Experimental-SteamWorks            | ARPA2       | ARPA2-Experimental-SteamWorks-Cfg        | Van Rein       | ARPA2-Experimental-SteamWorks-Hachee     | Van Rein       | ARPA2-Experimental-ServiceDIT            | Van Rein         | ARPA2-Experimental-Reservoir             | Van Rein         | ARPA2-Experimental-LifeCycleManagement   | Van Rein         | ARPA2-Experimental-KIP                   | Van Rein         | ARPA2-Experimental-Helm                  | Van Rein         | ARPA2-Experimental-Access-v2             | Van Rein           | ARPA2-Experimental-PKIX                  | ARPA2        | ARPA2-Experimental-PKIX-KRB5             | ARPA2      | ARPA2-Experimental-PKIX-KRB5-AlgId       | Van Rein      | ARPA2-Experimental-PKIX-XMSS             | Vrancken    | ARPA2-Experimental-PKIX-XMSS-AlgId       | Vrancken          | ARPA2-Experimental-GSSAPI                | Van Rein        | ARPA2-Experimental-GSSAPI-SXOVER         | Van Rein

Identifiers for Kerberos5 in PKIX (Van Rein)

The tree is and below that we have:

  • .1 for Kerberos [APPLICATION n]-tagged items, with n at the next level:
    • .1 for Ticket, functioning as "viewer-specific public key"

    • .2 for Authenticator, functioning as "viewer-specific signature"
      • when using cksum, append the OID of the hash used for example: .1.2 .2.16.840. for a SHA-256 value in cksum
    • .22 for KRB_CRED as a method of passing multiple Tickets, where the first has the same meaning as under .1 but the rest could be for additional uses, such as user-to-user exchanges, relaying ticket information to the recipient, and supporting applications like S4U2Proxy (that would also pass a session-key).

  • .2 for Kerberos message-types, with that type at the next level:
    • .20 for KRB_SAFE message, functioning as "authenticated data"
    • .21 for KRB_PRIV message, functioning as "enveloped data"
    • .22 for KRB_CRED message, functioning as "list of tickets"

Identifiers for Kerberos5 Realm Crossover Certificates (Van Rein)

The tree is and below that we have:

  • 1 for a sum or logical or of the following normative values:

    • 0 for id-kxover-*-*-service
    • 1 for id-kxover-*-*-client
    • 0 for id-kxover-*-kdc-*
    • 2 for id-kxover-*-princ-*
  • 2 for subjectAltNames:

    • 1 for id-kxover-krb5realm

Folding out these options, we find the folloing informative values:

  • 1.0 for id-kxover-kdc-service
  • 1.1 for id-kxover-kdc-client
  • 1.2 for id-kxover-princ-service
  • 1.3 for id-kxover-princ-client


  • 2.1 for id-kxover-krb5realm

Identifiers for LDAP-notation of PKCS #11 references (Van Rein)

The following identities have been assigned under

  • .1 for the pkcs11PrivateKeyURI attribute type
  • .2 for the pkcs11Certificate attribute type
  • .3 for the pkcs11CertificateURI attribute type
  • .4 for the pkcs11DeprecatedBy attribute type
  • .5 for the pkcs11LocalProviderModule attribute type
  • .6 for the pkcs11RemoteServiceProtocol attribute type
  • .7 for the pkcs11RemoteServiceLocation attribute type
  • .10 for the pkcs11PrivateKey object class
  • .11 for the pkcs11PrivateKeyLocal auxiliary object class
  • .12 for the pkcs11PrivateKeyRemote auxiliary object class

The pkcs11RemoteProtocol attribute type holds an OID that indicates a remote service protocol. The following OID values are reserved for that purpose:

  • .100 for the GSS-RPC protocol of RFC 5403, run over TCP, UDP or SCTP or perhaps for GSS-API exchanges wrapping what would otherwise be sent over TLS or so.
  • TODO: SOAP over HTTP, ...

Identifiers for LDAP-notation of TLS Pool configuration (Van Rein)

The following identities have been assigned under

  • .1 for the tlsPoolCredentialType attribute type
  • .2 for the tlsPoolSupportedRole attribute type
  • .3 for the tlsPoolValidationExpression attribute type
  • .6 for the tlsPoolTrustedIssuer object class
  • .7 for the tlsPoolLocalUserCredential object class
  • .8 for the tlsPoolIdentityDisclosure object class
  • .9 for the tlsPoolValidationRequirements auxiliary object class

Identifiers for LDAP-notation of INI-file and other nested settings (Van Rein)


Identifiers for Hachee data in SteamWorks (Van Rein)


Identifiers for ServiceDIT data in SteamWorks (Van Rein)


Identifiers for Reservoir data in LDAP (Van Rein)


Identifiers for Life Cycle Management data in LDAP (Van Rein)

These cover the lifecycleObject object class, the lifecycleAttribute attribute type and numerous other attributes that can be used to store object data throughout the life cycles. These all help to localise the changing data into one LDAP object.


Identifiers for KIP, Keyfile Identity Protocol (Van Rein)

  • TODO: details, but see KIP branch kip-documents directory doc

Identifiers for Communication Filters (Van Rein)

Reserved for a demonstration article of the principle, published on

Identifiers for Database Tuple Sharing (Van Rein)

Reserved for declaring database tuple sharing over LDAP. The reason to use LDAP is that it is useful for sharing the information. These records are defined to welcome in-transit encryption with a tool such as LillyDAP.

The following attributes are part of this schema; they represent alternative representations of which a database usually offers only one kind:

  • .1 for the abstract attribute type dbTuple
  • .1.1 for the abstract attribute type dbTupleCharSeparated
  • .1.1.32 for the space-separated dbTupleWords
  • .1.1.44 for the comma-separated dbTupleCSV
  • .1.2 for the abstract attribute type dbTupleASN1Sequence
  • .1.2.1 for the DER-encoded sequence dbTupleDERSequence
  • .1.2.2 for the PER-encoded sequence dbTuplePERSequence
  • .1.2.3 for the XER-encoded sequence dbTupleXERSequence
  • .1.2.4 for the (future) JER-encoded sequence dbTupleJERSequence
  • .2 for the abstract encryption key type dbTupleEncryptionKeyAbstraction
  • .2.1 for OpenPGP's binary "tag 1" packet dbTupleEncryptionKeyPGP
  • .3 for a string describing the encryption under dbTupleEncryptionMethod

The following classes are part of this schema:

  • .9 for the database class dbTupleSet
  • .8 for the fragment class dbTupleSubSet
  • .8.1 for the fragment class dbTupleSubSetEncrypted
  • .8.2 for the fragment class dbTupleSubSetPlainText
  • .7 for the tuple list class dbTuples

To retrieve data, one would generally start at a dbTupleSet, ignore any intermediate dbTupleSubSet by searching with sub scope, end retrieve the expected data tuple attribute types from the dbTuples leaf nodes. For an encrypted database schema this would not work; there, the dbTupleSubSet describes the encryption for its entire subtree. This is helpful because it allows database subsets to be encrypted differently.

Encrypted data is always binary, and the recommendation is to use the dbTupleDERSequence to represent the sequence of independently encrypted tuple elements.

We might choose to add more metadata, but that probably defeats its purpose. The dbTupleEncryptionMethod is minimally required, as it may be needed during encryption method rollovers. However, for such things as using OpenPGP or X.509 for delivering the encryption key, or the tuple representation in DER or CSV we should really specify it in its application (as the application syntax and usage profiles tend to dictate what is practical, without much variation).

Identifiers for XMSS (Vrancken)

Reserved for use with XMSS.

Current allocations for XMSS in general are:

  • .1 for WOTS+ as defined in RFC 8391
  • .2 for XMSS as defined in RFC 8391
  • .3 for XMSS^MT as defined in RFC 8391

Each of these defines extra levels following this general pattern:

For example, is the OID for the XMSS-SHA2_20_512 algorithm in Section 5.3 of RFC 8391.

In an AlgorithmIdentifier according to RFC 5280, there is an optional second field parameters that can hold further information. The format of this field is specific to the algorithms WOTS+, XMSS or XMSS^MT as indicated by the first number under this "Identifiers for XMSS" subtree.




Identifiers for Experimental ARPA2 Access v2 (Van Rein)

Reserved as ARPA2-Experimental-Access-v2.

Current allocations are in the arpa2-access.schema for LDAP.