Subject Alternative Name

A extens˜ao Subject Alternative Name permite que outras identidades sejam relacionadas ao sujeito do certificado. Estas identidades podem ser inclu´ıdas em adi¸c˜ao ou no lugar da iden- tidade no campo de sujeito do certificado. Op¸c˜oes previamente definidas incluem endere¸co de correio eletrˆonico da Internet, um nome de DNS, um endere¸co IP, e um Uniform Re- source Identifier (URI). Existem outras op¸c˜oes, incluindo defini¸c˜oes completamente locais. Formas m´ultiplas de nome, e v´arias instˆancias de cada forma de nome, podem ser inclu´ıdas. Sempre que essas identidades tiverem que ser relacionadas em um, a extens˜ao subject al- ternative name (ou issuer alternative name) DEVEM ser usadas. No entanto, um nome de DNS tamb´em PODE ser representado no campo subject, usando o atributo DomainCompo- nent como descrito na Se¸c˜ao 4.1.2.4. Observe que onde tais nomes forem representados nas implementa¸c˜oes do campo subject n˜ao ´e requerido a convers˜ao dos mesmos em nomes DNS.

Ern

an

des

33

Pelo motivo do subject alternative name ser considerado definitivamente ligada `a chave p´ublica, todas as sua partes devem ser verificadas pela AC.

Al´em disso, se a ´unica identidade de sujeito inclu´ıda no certificado for uma forma de nome alternativo (por exemplo, um endere¸co de correio eletrˆonico), ent˜ao, o nome distinto do sujeito deve permanecer vazio (uma sequˆencia vazia), e a extens˜ao subjectAltName devem estar presentes. Se o campo subject tiver uma seq¨uˆencia vazia, ent˜ao a AC que emissora DEVE incluir uma extens˜ao subjectAltName que ´e marcada como cr´ıtica. Quando inclu´ıda a extens˜ao subjectAltName em um certificado que tem um campo subject distinguished name n˜ao-vazio, as ACs em conformidade DEVERIAM marcar a extens˜ao subjectAltName como n˜ao-cr´ıtica.

Quando a extens˜ao subjectAltName tiver um endere¸co de correio da Internet, o endere¸co DEVE ser armazenado em rfc822Name. O formato de um nome rfc822Name ´e uma “caixa de correio”, como definido na Se¸c˜ao 4.1.2 da [RFC2821]. Uma caixa de correio tem o formato “Parte-Local@Dom´ınio”. Note que uma caixa de correio n˜ao possui nenhuma ex- press˜ao (tal como um nome comum), antes dele, n˜ao cont´em observa¸c˜oes (texto limitado por parˆenteses) ap´os ele, e n˜ao ´e limitado por “<” e “>”. As regras para codifica¸c˜ao de endere¸cos de e-mail que incluem nomes de dom´ınio internacionalizados s˜ao especificados na sec¸c˜ao 7.5. Quando a extens˜ao subjectAltName tiver um IPAddress, o endere¸co deve ser armazenado em string de octeto de “ordem de byte da rede”, conforme especificado no [RFC791]. O bit menos significativo (LSB) de cada octeto ´e o bit menos significativo do byte correspondente do endere¸co de rede. Para o IP vers˜ao 4, conforme especificado em [RFC791], o string de octeto deve conter exatamente quatro octetos. Para o IP vers˜ao 6, conforme especificado em [RFC2460], o string de octeto deve conter exatamente 16 octetos.

Quando a extens˜ao subjectAltName tiver um r´otulo de sistema de nome de dom´ınio, o nome de dom´ınio DEVE ser armazenado no dNSName (um IA5String). O nome DEVE estar na “prefered name syntax”, conforme especificado pela Se¸c˜ao de 3.5 da [RFC1034] e como modificado pela Sec¸c˜ao de 2.1 da [RFC1123]. Observe que, embora letras mai´uscu- las e min´usculas sejam permitidas para nomes de dom´ınio, nenhum significado existe em rela¸c˜ao ao tamanho de caractere. Al´em disso, apesar do string “” ser um nome de dom´ınio legal, extens˜oes subjectAltName com dNSName de “” N ˜AO DEVE ser usado. Finalmente, o uso da representa¸c˜ao DNS para endere¸cos de correio da Internet (em vez de subscri- [email protected] usar subscriber.example.com) N ˜AO DEVE ser usado; essas identidades s˜ao codificados como rfc822Name. As regras para codifica¸c˜ao de nomes de dom´ınio inter- nacionalizados s˜ao especificados na sec¸c˜ao 7.2.

Quando a extens˜ao subjectAltName tiver uma URI, o nome deve ser armazenado no uni- formResourceIdentifier (um IA5String). O nome n˜ao deve ser um nome URI relativo, e ele deve seguir a sintaxe de URI e as regras de codifica¸c˜ao especificado em [RFC3986]. O nome deve incluir tanto o esquema (por exemplo, “http” ou “ftp”) e um esquema da parte espec´ıfica. URIs que incluem uma autoridade ([RFC3986], Se¸c˜ao 3.2) DEVE conter um nome de dom´ınio totalmente qualificado ou endere¸co IP do host. Regras para codifica¸c˜ao de identificadores de recurso internacionalizados (IRIS) s˜ao especificadas na sec¸c˜ao 7.4. Conforme especificado em [RFC3986], o nome do esquema n˜ao diferencia mai´usculas de min´usculas (por exemplo, “http” ´e equivalente a “HTTP”). A parte do host, se estiver pre- sente, tamb´em n˜ao ´e sens´ıvel a mai´usculas e min´usculas, mas outros componentes da parte

Ern

an

des

34

espec´ıfica do esquema podem ser sens´ıveis ao tamanho do caractere. Regras para comparar URIs s˜ao especificados na sec¸c˜ao 7.4.

Quando a extens˜ao subjectAltName tiver um DN no directoryName, as regras de codifica- ¸c˜ao s˜ao as mesmas especificadas para o campo emissor na Sec¸c˜ao 4.1.2.4. O DN deve ser ´

unico para cada entidade de sujeita certificada por uma AC, tal como definido pelo campo issuer. A AC pode emitir mais de um certificado com o mesmo DN para a mesma entidade sujeito.

O subjectAltName PODE conter tipos de nome adicionais atrav´es da utiliza¸c˜ao do campo Othername. O formato e a semˆantica do nome s˜ao indicados atrav´es do identificador do objeto no campo type-id. O pr´oprio nome ´e transmitido como campo value do Othername. Por exemplo,formatos de nomes Kerberos [RFC4120] podem ser codificados no Othername, usando o OID para Kerberos 5 principal name e uma sequˆencia de realM e PrincipalName. Nomes alternativos de sujeito PODEM ser limitados da mesma forma que nomes distintos de sujeitos usando a extens˜ao name constraints como descrito na Se¸c˜ao 4.2.1.10.

Se a extens˜ao subjectAltName estiver presente, a sequˆencia DEVE ter pelo menos uma entrada. Ao contr´ario do campo subject, as AC em conformidade N ˜AO DEVEM emitir certificados com subjectAltNames contendo campos GeneralName vazios. Por exemplo, um rfc822Name ´e representado como um IA5String. Enquanto um string vazio ´e um IA5String v´alido, tal rfc822Name n˜ao ´e permitido por este perfil. O comportamento dos clientes que encontrarem esse tipo de certificado, ao processar um caminho de certifica¸c˜ao, n˜ao ´e defi- nido neste perfil.

Finalmente, a semˆantica de nomes alternativos de sujeito que incluem caracteres curinga (por exemplo, como um espa¸co reservado para um conjunto de nomes) n˜ao s˜ao abordados por esta especifica¸c˜ao. Aplica¸c˜oes com requisitos espec´ıficos podem usar tais nomes, mas eles devem definir a semˆantica.

id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }

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 {

Ern

an

des

35

value [0] EXPLICIT ANY DEFINED BY type-id }

EDIPartyName ::= SEQUENCE {

nameAssigner [0] DirectoryString OPTIONAL,

partyName [1] DirectoryString }