Resumo

  • A RFC 10031 cria o otherName id-on-MACAddress, com seis octetos exatos para EUI-48 e oito para EUI-64. A comparação é byte a byte, sem curinga.
  • Certificado, caminho válido e Name Constraints tratam de uma afirmação de PKI. Não observam a porta atual, a origem de um quadro, a integridade do equipamento, a identidade humana ou a permissão da rede.
  • Uma decisão responsável junta recibos separados para alocação IEEE ou local, validação da AC, caminho X.509, observação de camada 2, autorização e duração do identificador.

O endereço MAC parece chegar pronto para o papel de identidade. É curto, está próximo da interface e pode ser comparado sem interpretação semântica. Ao vinculá-lo a uma chave pública em um certificado, surge a tentação de chamá-lo de identidade do dispositivo.

A RFC 10031 oferece um mecanismo mais preciso e menos abrangente. Publicada na trilha de padrões do IETF em agosto de 2026, Media Access Control (MAC) Addresses in X.509 Certificates tem cinco autores: Russ Housley, Corey Bonnell, Joe Mandel, Tomofumi Okubo e Michael StJohns. O documento define id-on-MACAddress em GeneralName.otherName. Um EUI-48 ocupa exatamente seis octetos; um EUI-64, oito. A pontuação usada para mostrar endereços a pessoas não faz parte da codificação.

A parte confiante compara o valor apresentado com o certificado byte por byte. Não há curinga. Essa regra elimina dúvidas sobre dois-pontos, hífens, letras maiúsculas e zeros iniciais e fornece um nome interoperável para projetos de autenticação em camada 2 ou provisionamento seguro em áreas como IoT e redes automotivas.

É uma possibilidade técnica, não prova de adoção. A RFC não demonstra que uma fabricante, autoridade certificadora, plataforma veicular ou rede em produção implementou o mecanismo. Também não transforma o certificado em um sensor de tráfego.

O histórico de Housley dá contexto a esse recorte. O perfil do IETF capturado em 31 de agosto de 2026 lista 127 RFCs, inclusive a RFC 10031. A biografia registra atuação em segurança desde 1982, a fundação da Vigil Security em 2002, o cargo de IETF Chair entre 2007 e 2013 e de IAB Chair entre 2013 e 2015. Na mesma data, a tabela pública o mostrava como chair de LAMPS e liaison manager para IEEE-SA. São fatos de uma carreira em padrões; não o tornam autor único, operador de uma AC ou dono de uma alocação.

A origem do valor fica fora da PKI

Antes de emitir o certificado, é preciso provar por que o solicitante pode usar o endereço. A resposta depende da classe de endereço.

A IEEE Registration Authority mantém registros e emite identificadores de acordo com padrões IEEE. Ela separa MA-L, MA-M e MA-S de CID; um CID não pode gerar valores EUI-48 ou EUI-64. A RFC 9542 também distingue espaço EUI-48 globalmente atribuído de endereçamento administrado localmente e trata as fontes IEEE como referência autorizada de registro.

Logo, alguns octetos iniciais não bastam para provar fabricante ou proprietário atual. Em um endereço local, o titular de um OUI não adquire autoridade especial só porque o valor se parece com seu prefixo. A RFC 9542 observa ainda que não há método automatizado para saber se uma rede local segue o Structured Local Address Plan.

O recibo de alocação deve guardar a classe, o alocador, o bloco ou regra local, o valor subordinado, a interface prevista, o escopo e a data. Para espaço local, deve incluir o plano e o tratamento de colisão. O padrão de bits informa uma categoria; não revela a decisão administrativa que escolheu o valor.

É uma divisão de agência. IEEE controla seus registros. Fabricante, proprietário ou operador escolhe valores dentro de seu domínio. A AC avalia uma alegação. A rede de destino decide se permite uma ação. Uma assinatura não transfere essas competências entre as partes.

A força do vínculo é a força do cadastramento

A RFC 10031 exige que a AC assegure que o endereço incluído pertence, ou deve pertencer, ao dispositivo sujeito durante a vida do certificado. O mesmo valor não deve aparecer em certificados de dispositivos diferentes, a menos que compartilhem a mesma interface de camada 2. No certificado autoassinado, o valor deve ser o endereço de uma porta física.

Essas obrigações tornam o método de validação decisivo. Um cadastro baseado em registro de fabricação é diferente de uma afirmação do assinante. Um canal controlado, uma prova de chave dentro do equipamento e uma inspeção física suportam conclusões diferentes. A própria RFC alerta que o vínculo depende do processo da AC e que spoofing precisa ser considerado. Atribuição dinâmica e valores compartilhados enfraquecem unicidade e prestação de contas.

O recibo de emissão deveria nomear assinante, dispositivo, interface, octetos exatos, método e horário da prova, emissor, número de série, validade e revogação. Sem isso, o campo diz o que foi assinado, não por que foi considerado verdadeiro.

Os fatos também envelhecem. Uma porta é trocada; uma interface virtual renasce; o endereço gira ou passa para outro equipamento. O certificado pode continuar formalmente válido. A revogação só reduz a distância se a mudança for detectada, comunicada e consultada a tempo.

A restrição de nome não é uma inspeção de rede

A RFC 10031 define Name Constraints para o novo nome. Uma restrição combina padrão de valor e padrão de máscara. São doze octetos em EUI-48 e dezesseis em EUI-64. A combinação descreve subespaços permitidos ou excluídos para certificados posteriores.

O nome do certificado não recebe um curinga. Ele continua sendo um valor completo sujeito à igualdade exata. Valor e máscara pertencem à avaliação do caminho de certificação.

A RFC 5280 situa esse recurso em certificados de AC. Name Constraints limitam nomes de certificados subsequentes; agem sobre subjectAltName quando a forma está presente e em geral não se aplicam a certificados autoemitidos, exceto quando o autoemitido encerra o caminho.

Uma correspondência positiva prova que, sob determinada âncora, cadeia, política e hora, o nome caiu dentro do espaço permitido. Não prova alocação IEEE, presença em uma porta, origem do quadro ou autorização de VLAN. A máscara distribui um espaço de nomes da PKI; não torna os endereços globalmente exclusivos.

Por isso o resultado deve ter recibo próprio: âncora de confiança, cadeia, política, horário, SAN exato, restrições permitidas e excluídas, e situação de revogação. Chamá-lo de prova física elimina a fronteira necessária para investigar falhas.

O endereço observado pertence a um escopo

MACs normalmente são locais. A RFC 10031 desaconselha presumir unicidade além da rede local, pois esses valores não costumam ser roteados através de fronteiras de camada 3. Redes separadas podem usar legitimamente o mesmo endereço local. Dentro de uma rede, duplicação pode vir de erro, cópia deliberada ou ataque.

O sistema dependente precisa vincular o evento criptográfico ao evento de rede. Isso inclui protocolo e resultado de autenticação, prova da chave, MAC de origem observado, interface física ou lógica, ponto de conexão, VLAN ou escopo equivalente, estado de atribuição ou randomização, detecção de duplicidade e horário.

Com esses elementos, igualdade de bytes ganha uma interpretação limitada: o valor apresentado é igual ao nome certificado. Ela não comprova que todos os quadros seguintes vêm do mesmo hardware, que o firmware está íntegro ou que determinada pessoa usa o equipamento.

Running-Code Primacy mantém as camadas honestas. O padrão coordena a sintaxe. Certificado e caminho coordenam uma afirmação criptográfica. A rede em funcionamento entrega observação e resultado. A terceira etapa não deve ser preenchida por inferência da primeira.

A rede ainda precisa dizer “sim”

Autenticar não é autorizar. Um equipamento pode apresentar chave, certificado e MAC coerentes e ser colocado em quarentena porque apareceu em uma porta inesperada, pediu uma ação além de seu perfil ou ultrapassou uma janela de manutenção.

O recibo de autorização precisa de regra, proprietário, versão, atributos, ação concedida, escopo, vencimento, exceção e resultado. Uma intervenção humana deve identificar responsável e motivo. Se o caminho for válido e a ação for negada, ambos os fatos devem permanecer no registro.

Essa separação impede que a AC seja tratada como administradora da rede. Os autores definem um mecanismo compartilhado. A AC controla emissão segundo sua política. O operador observa o ambiente. A aplicação decide como transformar evidência em consequência. Cada verbo pertence a um agente diferente.

Persistência melhora correlação — para todos os observadores

A RFC 10031 alerta que um MAC estável em certificado pode facilitar rastreamento prolongado de dispositivo e usuário. Recomenda considerar rotação de endereço, certificados curtos ou randomização quando viável.

A RFC 6973 chama de correlação a combinação de informações ligadas a uma pessoa e de fingerprinting a identificação de uma instância ou dispositivo por vários elementos. Um identificador persistente em qualquer camada, inclusive certificado ou ID do dispositivo, pode conectar comunicações ao longo do tempo.

Criptografia não elimina essa capacidade. O certificado pode ser visível ou registrado, e sistemas de autenticação, comutação e segurança podem juntar o valor a outros campos estáveis. Por outro lado, randomização universal pode ser impraticável em controles que precisam de referência fixa e pode desalinhar o endereço da validade do certificado.

O registro de privacidade deve esclarecer por que a estabilidade é necessária, quem observa, em qual escopo, por quanto tempo endereço e certificado persistem, quais atributos podem ser associados, se rotação foi avaliada e quando os registros serão apagados. Um identificador protegido continua sendo identificador.

Seis recibos, uma decisão

Uma implantação demonstrável conserva seis trilhas: base de alocação IEEE ou local; evidência aceita pela AC; resultado do caminho; interface e evento observados; autorização local; persistência e encerramento da correlação.

Cada etapa pode estar certa enquanto a próxima falha. Endereço bem alocado pode ser mal cadastrado. Certificado correto pode estar revogado. Caminho válido pode acompanhar origem falsificada. Equipamento autêntico pode não ter permissão. Acesso legítimo pode produzir retenção excessiva.

A RFC 10031 entrega uma chave exata para unir esses registros. A boa arquitetura usa a chave para fazer a junção; a má arquitetura usa a chave para fingir que os demais registros não são necessários.

Fontes