Resumo

  • No BRSKI-AE, a solicitação combina prova de posse da nova chave com prova de origem baseada no IDevID de fábrica, permitindo verificação por uma AR depois de filas e múltiplos saltos.
  • O objeto assinado sustenta uma decisão, mas não concede a si mesmo autorização. Mesmo com a AR no backend, a RFC 9733 mantém o registrador do domínio dentro da decisão de ingresso.
  • Voucher, consentimento, autorização, emissão, confirmação, telemetria e admissão são recibos distintos. Um único indicador de “dispositivo integrado” é incapaz de explicar o que realmente ocorreu.

O equipamento chegou a uma instalação onde o enlace com a PKI central funcionava apenas em janelas curtas. O registrador local recebeu o pedido, mas o backend estava indisponível. Horas depois, outro mecanismo transportou a mensagem. A sessão TLS que autenticara o dispositivo já terminara. A autoridade remota precisava verificar o pedido original sem aceitar apenas a palavra do intermediário.

Esse é o espaço que a RFC 9733 organiza. O BRSKI com inscrição alternativa usa objetos de certificação autenticados e autocontidos. A mensagem mantém uma prova de que o pledge controla a chave privada nova e outra de que o pedido veio da identidade IDevID instalada na fabricação. A evidência continua verificável quando a mensagem espera ou atravessa componentes.

Autocontido não significa autoautorizado. O pedido não escolhe sozinho o domínio, não aprova os próprios atributos e não obriga uma autoridade certificadora. Ele entrega fatos aos decisores. O valor institucional do desenho está em permitir que a evidência circule sem apagar quem pode dizer sim ou não.

A chave nova não responde quem é o solicitante

A prova de posse testa o vínculo com a chave. Em PKCS #10, o pedido costuma ser assinado pela chave privada correspondente à pública que será certificada. CRMF oferece outros métodos, inclusive para tipos de chave que não assinam. Se o teste passa, sabe-se que o solicitante dispõe do segredo.

Ainda não se sabe sua identidade. Qualquer agente pode criar uma chave e provar que a possui. Por isso, a RFC 9733 exige prova de identidade, também chamada de prova de origem. No contexto BRSKI-AE, uma assinatura com o segredo IDevID vincula o pedido a uma credencial anterior e a um identificador forte do pledge.

As duas provas podem divergir. Um invasor possui corretamente a própria chave, mas não um IDevID autorizado. Um dispositivo autêntico pode pedir um nome, função ou uso incompatível. Mesmo quando ambos os testes criptográficos passam, propriedade, inventário, revogação ou política podem exigir rejeição.

O registro operacional precisa mostrar posse, origem e autorização como resultados separados. “Assinatura válida” é informação insuficiente tanto para emitir quanto para investigar.

Evidência que não morre com a primeira conexão

No BRSKI tradicional, o EST consegue ligar um pedido PKCS #10 à autenticação do cliente no canal TLS entre pledge e registrador. O vizinho imediato recebe uma evidência útil. Porém, uma segunda AR situada no backend pode não ver aquela sessão nem conseguir reproduzir sua vinculação transitória.

O BRSKI-AE adota protocolos em que o próprio objeto é autenticado. A instanciação normativa usa CMP conforme o perfil leve. A proteção do PKIMessage carrega a origem IDevID; CRMF ou PKCS #10 carrega a posse da futura chave LDevID. O registrador encaminha a prova original em vez de transformar a sessão encerrada numa afirmação que o backend apenas teria de acreditar.

Isso permite colocar o registrador perto do ativo e a política mais profunda numa AR central. Também permite processamento assíncrono. A fila movimenta um objeto verificável; não recebe autoridade para representar o dispositivo.

Independência do transporte não elimina a segurança de transporte. Entre pledge e registrador, o canal TLS ou DTLS existente continua obrigatório. A troca entre registrador e backend fica fora do escopo. A proteção CMP autentica e preserva integridade, mas não cifra automaticamente a mensagem. Sem confidencialidade no trecho seguinte, um observador pode identificar dispositivos em inscrição ou bloquear alguns deles.

O voucher estabelece confiança; não é o LDevID

Antes do pedido alternativo, o pledge realiza a troca de voucher do BRSKI por meio do registrador e da MASA. O voucher entrega uma âncora para reconhecer o domínio-alvo, normalmente o certificado fixado do domínio. Assim, o dispositivo não aceita qualquer serviço que apareça na rede.

Mas o voucher não é o certificado LDevID. Ele não demonstra que a AR autorizou a chave, que a AC emitiu ou que a rede aceitou o equipamento. Seu papel é delimitar em quem o pledge confiará durante as próximas etapas.

Depois do imprint, o pledge cria a chave LDevID e envia o pedido autocontido. Com CMP, valida a resposta usando a âncora estabelecida pelo voucher. São duas correntes ligadas: a primeira identifica o domínio confiável; a segunda decide se a PKI desse domínio concede um certificado específico.

Um painel que chama voucher aceito de “dispositivo aprovado” antecipa uma decisão. Um painel que guarda somente o certificado apaga por que o dispositivo confiou naquele emissor. A auditoria precisa dos dois fatos.

O backend não pode apagar a decisão local

A RFC 9733 permite ao registrador delegar parte ou toda a função de AR. Mesmo assim, ele deve participar da decisão de aceitar o pledge no domínio. A arquitetura não pode oferecer um atalho em que o dispositivo ignore o registrador e obtenha o LDevID diretamente da AC.

O consentimento do registrador pode ser implícito numa relação estritamente governada, registrado fora de banda, enviado numa mensagem adicional ou expresso por assinatura. Para CMP, recomenda-se aninhar o pedido original do pledge dentro de uma mensagem assinada pelo registrador. O backend recebe duas declarações: o dispositivo originou este conteúdo; o domínio consente que ele seja avaliado.

Preservar o pedido impede que um intermediário substitua o que foi solicitado por um resumo. Acrescentar o consentimento impede que uma identidade de fabricação seja tratada como autorização local. A AR ainda pode rejeitar. A AC só emite depois das verificações necessárias. Autenticidade do equipamento e direito ao domínio continuam sendo coisas diferentes.

Essa separação também localiza responsabilidade. Falha do IDevID pertence à origem; consentimento ausente, ao registrador; perfil indevido, à AR; certificado incorreto, à AC. O rótulo genérico “erro de PKI” não oferece essa capacidade de reparo.

A fila assíncrona não congela a política

Em instalações desconectadas, o objeto autocontido permite esperar por conectividade sem perder a origem. Durante esse intervalo, porém, o mundo muda. O ativo pode trocar de proprietário, o consentimento pode ser revogado, o perfil pode evoluir e a âncora pode girar.

O mesmo pedido também pode aparecer duas vezes porque uma resposta foi perdida. Uma assinatura antiga permanece matematicamente válida, embora a autorização associada tenha expirado. Validade criptográfica não é sinônimo de atualidade da decisão.

Por isso o operador precisa de uma transação durável que ligue identidade do voucher, impressão da chave, resultados de posse e origem, atributos, consentimento, identificador do backend, decisão da AR, resposta da AC e impressão do certificado. A repetição deve distinguir uma emissão concluída com resposta perdida de um pedido nunca aprovado. A idade da fila é um dado de política.

Há mais de um fim depois da resposta

Uma resposta bem-sucedida traz o certificado e pode incluir intermediárias ou novas âncoras. CMP permite uma confirmação opcional. O pledge valida o resultado e informa positiva ou negativamente se o certificado foi inscrito e atende à necessidade. A PKI ou o registrador acusa o recebimento dessa confirmação.

Separadamente, o BRSKI mantém a telemetria obrigatória de estado entre pledge e registrador. A RFC 9733 a trata como fase final distinta. A confirmação CMP informa a PKI sobre a avaliação do certificado; a telemetria BRSKI informa o registrador sobre o processo. O recibo de uma confirmação não demonstra uso em produção.

Instalação, controle de acesso, configuração e serviço vêm depois. Uma AC pode emitir corretamente e o equipamento não usar o certificado. O pledge pode confirmar e a rede negar entrada. A rede pode admitir e a função industrial ainda falhar.

O status confiável nomeia o limite: voucher aceito; posse e origem verificadas; consentimento presente; AR aprovou; AC emitiu; pledge confirmou; telemetria chegou; admissão ainda não observada. Cada etapa superior exige seu próprio recibo.

Descobrir um endpoint não descobre sua legitimidade

A RFC 9733 generaliza caminhos como /.well-known/<enrollment-protocol>/<request> e registra brski-reg-cmp para descoberta mínima de um registrador CMP. O pledge pode tentar a operação e ler o estado HTTP para saber se há suporte.

Isso descobre capacidade, não autoridade. O serviço encontrado pode não ser o registrador correto para o pledge. O registro IANA não comprova implantação nem conformidade. Um sucesso HTTP pode significar apenas que o envelope chegou enquanto a transação CMP continua pendente ou recusada.

Logs úteis correlacionam endpoint, par TLS, âncora de domínio, protocolo, transação interna e proprietário da decisão. Nenhuma fonte congelada prova implantação por fabricante, ferrovia, subestação, prédio ou rede de recarga específica. Os exemplos da RFC motivam o desenho; não constituem observação de produção.

Fontes