We need to support the generation of Certificates containing the otherName SAN type.
This is still used in some traditional systems to indicate unique identity, it is usually just an email UPN but we can be fairly generic.
Currently we only support the most common subset of SANs, SANs are "GeneralName" types:

   SubjectAltName ::= GeneralNames

   GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

   GeneralName ::= CHOICE {
        otherName                       [0]     OtherName,
        rfc822Name                      [1]     IA5String,
        dNSName                         [2]     IA5String,
        x400Address                     [3]     ORAddress,
        directoryName                   [4]     Name,
        ediPartyName                    [5]     EDIPartyName,
        uniformResourceIdentifier       [6]     IA5String,
        iPAddress                       [7]     OCTET STRING,
        registeredID                    [8]     OBJECT IDENTIFIER }

   OtherName ::= SEQUENCE {
        type-id    OBJECT IDENTIFIER,
        value      [0] EXPLICIT ANY DEFINED BY type-id }

   EDIPartyName ::= SEQUENCE {
        nameAssigner            [0]     DirectoryString OPTIONAL,
        partyName               [1]     DirectoryString }

From https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.6

We've currently "deconstructed" the type and offered straight array string Certificate types to represent the most common: dns, email, ip,uri are available, however some legacy systems like ldap still leverage the otherName type.

Unfortunately otherName is a complicated type in that it is an escape hatch that allows the setting of arbitrary oids:

   OtherName ::= SEQUENCE {
        type-id    OBJECT IDENTIFIER,
        value      [0] EXPLICIT ANY DEFINED BY type-id }

The most common use case is the UPN otherName type, meaning the type-id is set to:
1.3.6.1.4.1.311.20.2.3 UPN (which actually just means a valid rfc0822 email address..)
and the actual format type is just a string.
You might wonder why not just use email SAN (which are rfc822Names), but this is the pattern established by microsoft AD servers for LDAP: https://4sysops.com/archives/understand-the-upn-and-samaccountname-user-account-attributes/

Describe the solution you'd like
I propose we continue the tradition of decomposing the generalName attribute and keep doing these niche SANs in a case by case basis, for example we can add a Certificate field called:
otherNameSANs, we can easily get a fair bit of extensibility while hitting our use case by making that a struct of type:

type otherNameSANs []struct{
  type-id string (can be upn, or oid:some.oid.value)
  value string
}

Describe alternatives you've considered
One possible alternative would be to just add a UPN SANs field for example:

type upnSANs []string

and these could be directly encoded as otherName UPN values.. this would accomplish our objective but might be less forward compatible with any future otherName types we could require, we know at least of one other type that "exists" like DNS SRV RR otherName although we're not clear if it's still in use.

Additional context:

• we've done a bit of research of the different generalNames around and came to this analysis:
  otherName -> TBD: UPN

x400Address has been kind of discontinued since 2006
ediPartyName is used by US Dept of Defense smart cards (https://news.ycombinator.com/item?id=25350821)
registeredID -> ??
directoryName -> ??

We looked at the subset that ACM's api uses for example and it includes some of these obscure types:
https://docs.aws.amazon.com/privateca/latest/APIReference/API_GeneralName.html
where they do include the additional directoryName EdiPartyName registerID and otherName types but also ignore x400Address.

• smallstep have built this particular generalName implementation here

/kind feature