As we work closer with Certificate Authorities (CAs) on building LEI information into Digital Certificates a standard implementation schema is necessary. As of February 2019 the following definitions are considered best practice:
LEI
DEFINITIONS IMPLICIT TAGS ::= BEGIN
ub-leiRole-length INTEGER ::= 100
Lei ::= SEQUENCE {
leiCode PrintableString(SIZE(20)),
leiRole [0] EXPLICIT PrintableString(SIZE(1..ub-leiRole-length))
OPTIONAL
}
EXTENSION ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&ExtnType }
WITH SYNTAX {
SYNTAX &ExtnType,
IDENTIFIED BY &id
}
lei OBJECT IDENTIFIER ::= {1 3 6 1 4 1 5222266 1}
leiExtension EXTENSION ::= {
SYNTAX Lei,
IDENTIFIED BY lei
}
Extension ::= SEQUENCE {
extnId EXTENSION.&id({ExtensionSet}),
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING
(CONTAINING EXTENSION.&ExtnType({ExtensionSet}{@extnId})
ENCODED BY der),
...
}
der OBJECT IDENTIFIER ::=
{joint-iso-itu-t asn1(1) ber-derived(2) distinguished-encoding(1)}
ExtensionSet EXTENSION ::= {leiExtension,...}
END
Object Identifier Details
CAs wishing to embed identity data into the Subject Distinguished Name of a Digital Certificate can view the Object Identifier (OID) at the following OID-Repository link:
http://www.oid-info.com/get/1.3.6.1.4.1.52266.1
Further Reading
GLEIF (Global Legal Entity Identifier Foundation):
Ubisecure / RapidLEI:
- Why the Certificate Authority world should embrace Legal Entity Identifiers (part i)
- Why the Certificate Authority world should embrace Legal Entity Identifiers (part ii)
- Widening the scope of best practice for LEIs for SSL/TLS identity
TrustCubes:
CA stakeholders please get in touch with our RapidLEI team to discuss implementation.
