Как определено в стандарте RFC-3986, название схемы адресации не зависит от регистра написания символов (например, «http» эквивалент «HTTP»). Название схемы со специфическим кодированием частей адреса, если оно представлено, также не зависит от регистра написания символов, но другие компоненты адреса со специфическим кодированием его частей могут зависеть от регистра написания символов. Правила сравнения URI-идентификаторов рассматриваются ниже.
Когда субполе «subjectAltName» поля «Расширения» содержит имя Службы единого каталога (СЕК, The Directory) в формате «directoryName», тогда правила кодирования альтернативного имени владельца сертификата аналогичны правилам, которые установлены для поля «Issuer» (4.1.2.4). СЕК-имя должно быть уникальным для каждого держателя сертификата и заверенным тем же УЦ, как это определено в поле «Issuer». УЦ может издать несколько сертификатов с одним и тем же СЕК-именем и для одного и того же владельца сертификата.
Субполе «subjectAltName» может содержать дополнительные типы наименований путём использования последовательности «otherName». Формат и семантика такого наименования указывается с помощью OID, расположенного в субпоследовательности «type-id». Само же имя располагается в субпоследовательности «value» последовательности «otherName». Например, имена в Kerberos-формате стандарта RFC-4120 могут быть закодированы в последовательности «otherName» с использованием OID («type-id»), определяющего имя участника информационного обмена согласно пятой версии Kerberos-стандарта, и последовательности символов («value»), состоящей из наименования зоны («Realm») и имени участника информационного обмена («PrincipalName»).
Конструкции альтернативных имён владельцев сертификатов могут иметь ограничения по аналогии с уникальными именами владельцев сертификатов на основе субполя «nameConstraints» (4.2.1.10).
Если субполе «subjectAltName» представлено, то в нём должна обязательно присутствовать хотя бы одна последовательность (строка). В отличие от поля «Subject», придерживающиеся данного стандарта УЦ не должны выпускать сертификаты с субполями «subjectAltName», включающими пустые последовательности «GeneralName». Например, имя в.html822Name-формате должно иметь кодировку «IA5String». Несмотря на то, что пустая последовательность может иметь допустимую кодировку «IA5String», использовать имя в.html822Name-формате данным стандартом запрещено. Поведение клиентов, которые «наталкиваются» на такие сертификаты при обработке МС, данным стандартом не определено.
И в заключении, семантика альтернативных имён владельцев сертификатов, которые включают произвольные (wildcard) символы (например, «заполнитель» (структурный ноль) для совокупности имён), в данном стандарте не рассматривается. Прикладным системам со специфическими требованиями разрешено использовать указанные имена, но в таких случаях они обязаны указывать семантику.
id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }
SubjectAltName ::= GeneralNames
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
GeneralName ::= CHOICE {
otherName [0] OtherName,
.html822Name [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 }