Support otherName
SAN type
#6393
Labels
kind/feature
Categorizes issue or PR as related to a new feature.
lifecycle/stale
Denotes an issue or PR has remained open with no activity and has become stale.
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:
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:
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: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:
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
andotherName
types but also ignore x400Address./kind feature
The text was updated successfully, but these errors were encountered: