Name Constraints

A extens˜ao name constraints, que DEVE ser usada apenas em certificado de AC, indica o espa¸co de nome dentro do qual todos os nomes de sujeito em certificados subsequentes do caminho de certifica¸c˜ao DEVEM estar contidos. As restri¸c˜oes se aplicam ao nome distinto de sujeito e nomes alternativos de sujeito. As restri¸c˜oes s˜ao aplic´aveis apenas quando a forma de nome especificado estiver presente. Se nenhum nome do tipo estiver no certificado, o certificado ´e aceit´avel.

Name constraints n˜ao s˜ao aplicados em certificados auto-assinados (a menos que o certifi- cado seja o certificado final no caminho). (Isso poderia impedir que AC que usam name constraints em certificados auto-assinados, implementem substitui¸c˜ao de chave.)

As restri¸c˜oes s˜ao definidas em termos de sub´arvores de nomes permitidas ou exclu´ıdas. Qualquer nome correspondente em um campo excludedSubtrees ´e inv´alido independente- mente da informa¸c˜ao contida na permittedSubtrees. As ACs em conformidade DEVEM marcar esta extens˜ao como cr´ıtica e N ˜AO DEVERIAM impor restri¸c˜oes de nomes as for- mas x400address, ediPartyName ou formas de nome registeredID. As ACs em conformidade N ˜AO DEVEM emitir certificados onde name constraints ´e uma sequˆencia vazia. Ou seja, tanto o permittedSubtree quanto o excludedSubtree DEVEM estar presentes.

As aplica¸c˜oes em conformidade com este perfil DEVEM ser capazes de processar restri¸c˜oes de nome que s˜ao impostas em formas de nome directoryName e DEVERIAM ser capazes de processar restri¸c˜oes de nome que s˜ao impostas nas formas rfc822Name, uniformResour- ceIdentifier, dNSName, e iPAddress. Se a extens˜ao name constraints que ´e marcada como

Ern

an

des

37

cr´ıtica impor restri¸c˜oes a uma forma espec´ıfica, e uma instˆancia daquelas formas de nome aparecerem em um campo subject ou extens˜ao subjectAltName de um certificado subse- quente, ent˜ao a aplica¸c˜ao DEVE processar a restri¸c˜ao ou rejeitar o certificado.

Dentro deste perfil, os campos m´ınimo e m´aximo n˜ao s˜ao utilizados nas formas any name, assim, o m´ınimo DEVE ser zero, e o m´aximo DEVE estar ausente. Entretanto, se uma aplica¸c˜ao encontra uma extens˜ao name constraints cr´ıtica que especifica outros valores para m´ınimo ou m´aximo para uma forma de nome que aparece em um certificado subsequente, a aplica¸c˜ao DEVE processar estes campos ou rejeitar o certificado.

Para URIs, a restri¸c˜ao ´e aplicada a parte host do nome. A restri¸c˜ao DEVE ser especificada como um nome de dom´ınio totalmente qualificado e PODE especificar um host ou um do- m´ınio. Seriam exemplos “host.example.com” e “.example.com”. Quando a restri¸c˜ao come¸ca com um ponto, ela PODE ser expandida com um ou mais r´otulos. Ou seja, a restri¸c˜ao “.example.com” ´e satisfeita por tanto host.example.com quanto por my.host.example.com. Entretanto, a restri¸c˜ao “.example.com” n˜ao ´e satisfeita por “example.com”. Quando a res- tri¸c˜ao n˜ao come¸car com um ponto, ela especifica um host. Se uma restri¸c˜ao ´e aplicada a forma de nome uniformResourceIdentifier e um certificado subsequente inclui uma exten- s˜ao subjectAltName com um uniformResourceIdentifier que n˜ao inclui uma componente autoridade com o nome de host especificado como nome de dom´ınio totalmente qualificado (por exemplo, se uma URI nao inclui um componente autoridade ou inclui um componente autoridade no qual o nome do host ´e especificado como um endere¸co IP), ent˜ao a aplica¸c˜ao DEVE rejeitar o certificado.

Uma restri¸c˜ao de nome para endere¸co de correio eletrˆonico Internet PODE especificar uma caixa de correio particular, todos os endere¸cos de um host em particular, ou todas as caixas postais de um dom´ınio. Para indicar uma caixa de correio particular, a restri¸c˜ao ´e o ende- re¸co completo de correio eletrˆonico. Por exemplo, “[email protected]” indica a caixa postal root no host “example.com”, a restri¸c˜ao “example.com” ´e satisfeita por qualquer endere¸co de correio eletrˆonico no host “example.com”. Para especificar qualquer endere¸co dentro de um dom´ınio, a restri¸c˜ao ´e especificada com ponto na frente (como ocorre com URIs). Por exemplo, “.example.com” indica todos os endere¸cos de correio eletrˆonico no dom´ınio “example.com”, mas n˜ao todos os endere¸cos de correio eletrˆonico no host “example.com”.

As restri¸c˜oes a nomes DNS s˜ao expressas como host.example.com. Qualquer nome DNS que possa ser constru´ıdo simplesmente adicionando zero ou mais r´otulos ao lado mais a esquerda do nome satisfar´a a restri¸c˜ao de nome. Por exemplo, www.host.example.com sa- tisfaria a restri¸c˜ao, mas host1.example.com n˜ao satisfaria.

Existem implementa¸c˜oes no legado nas quais um endere¸co de correio eletrˆonico foi incor- porado no nome distinto de sujeito em um atributo do tipo emailAddress (se¸c˜ao 4.1.2.6). Quando s˜ao impostas restri¸c˜oes na forma de nome rfc822Name, mas o certificado n˜ao inclui um nome alternativo de sujeito, a limita¸c˜ao rfc822Name DEVE ser aplicada ao atri- buto do tipo emailAddress no campo subject distinguished name. A sintaxe ASN.1 para emailAddress e o seu OID correspondente ´e fornecida no Apˆendice A.

Restri¸c˜oes da forma directoryName DEVEM ser aplicadas ao campo subject do certifi- cado (quando o certificado incluir um campo subject n˜ao vazio) e a qualquer nome do tipo directoryName da extens˜ao subjectAltName. Restri¸c˜oes da forma x400Address DEVEM ser aplicadas a qualquer nome do tipo x400Address na extens˜ao subjectAltName.

Ern

an

des

38

Quando aplicar restri¸c˜oes da forma directoryName, a aplica¸c˜ao DEVE comparar os atri- butos DN. No m´ınimo, as aplica¸c˜oes DEVEM executar as regras de compara¸c˜ao para DN especificadas na se¸c˜ao 7.1. As ACs que emitem certificados com uma restri¸c˜ao da forma directoryName N ˜AO DEVERIAM confiar em implementa¸c˜oes do algoritmo de compara¸c˜ao de nome ISO DN completo. Isso implica que as restri¸c˜oes de nome DEVEM ser defini- das de maneira idˆentica para a codifica¸c˜ao usada no campo subject ou para a extens˜ao subjectAltName.

A sintaxe de iPAddress DEVE ser aquela descrita na se¸c˜ao 4.2.1.6 com as adi¸c˜oes seguin- tes especificamente para restri¸c˜oes de nomes. Para endere¸cos IPv4, o campo endere¸co de GeneralName DEVE conter oito (8) octetos, condificados no estilo da RFC 4632 (CIDR) para representar o escopo de endere¸camento [RFC4632]. Para endere¸cos IPv6, o campo iPAddress DEVE conter 32 octetos codificados de maneira similar. Por exemplo, uma restri¸c˜ao de nome para subrede “classe C” 192.0.2.0 ´e representado ´e representada pelos octetos C0 00 02 00 FF FF FF 00, representando a nota¸c˜ao CIDR 192.0.2.0/24 (m´ascara 255.255.255.0).

Regras adicionais para codifica¸c˜ao e processamento de restri¸c˜oes de nome s˜ao especificadas na se¸c˜ao 7.

A sintaxe e a semˆantica para restri¸c˜oes de nome para otherName, ediPartyName, e re- gisteredID n˜ao s˜ao definidas nesta especifica¸c˜ao, entretanto, a sintaxe e a semˆantica para restri¸c˜oes de nome para formas other name podem ser especificadas em outros documentos.

id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 }

NameConstraints ::= SEQUENCE {

permittedSubtrees [0] GeneralSubtrees OPTIONAL,

excludedSubtrees [1] GeneralSubtrees OPTIONAL }

GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree

GeneralSubtree ::= SEQUENCE {

base GeneralName,

minimum [0] BaseDistance DEFAULT 0,

maximum [1] BaseDistance OPTIONAL }

BaseDistance ::= INTEGER (0..MAX)