Resumo

  • A solicitação de assinatura do RFC 9987 contém chave pública, dados e flags; a resposta contém assinatura ou falha. Não há campos obrigatórios para processo iniciador, pessoa, host, conta, comando ou finalidade.
  • O protocolo do agente não autentica o cliente nem protege o transporte por conta própria. O controle costuma depender do acesso ao endpoint local, e o encaminhamento do agente leva a capacidade de uso para outro host sem levar a chave privada.
  • Confirmação, validade temporal, bloqueio, resultado do agente, autenticação do servidor e autorização de aplicação são decisões separadas. Daniel Kade propõe um comprovante de intenção em seis estágios, ligado por hashes e sem segredos.

A assinatura responde a uma pergunta menor

Uma equipe de segurança encontra uma assinatura válida associada a uma chave armazenada em hardware. O agente registrou sucesso e ninguém conseguiu extrair o segredo. A conclusão tentadora é chamar o uso de aprovado. Mas a evidência ainda não diz qual processo alcançou o endpoint, se a conexão era local ou encaminhada, quais restrições estavam ativas, qual contexto apareceu para o usuário e o que o servidor remoto decidiu depois.

Publicado em maio de 2026 como Proposed Standard do IETF, o RFC 9987 especifica a conversa entre clientes e agentes que mantêm chaves privadas ou delegam seu uso. O cliente conduz pedidos para adicionar, remover e listar identidades, gerar assinaturas, bloquear o agente ou usar extensões. A padronização é importante porque dá forma comum à interface. Ela não transforma o agente em intérprete de todos os objetivos possíveis dos dados assinados.

SSH_AGENTC_SIGN_REQUEST leva o blob de chave pública, uma cadeia de dados e indicadores. O sucesso retorna SSH_AGENT_SIGN_RESPONSE com a assinatura. A mensagem não exige identificação de executável, principal humano, máquina de destino, conta remota, comando, chamado de mudança ou política de autorização. Os dados podem ser uma estrutura de autenticação SSH, mas o agente genérico não tem um campo que declare essa finalidade e suas consequências.

Não se trata de defeito do protocolo. Uma interface estreita é mais fácil de interoperar e proteger. O problema surge no plano operacional, quando “o agente assinou” vira “o usuário consentiu”. Why BTW Media Exists recomenda preservar a diferença entre observação e narrativa. A operação criptográfica foi observada; consentimento e autorização continuam dependendo de evidências próprias.

Proteger a posse não basta para proteger a invocação

O RFC 9987 declara que o protocolo do agente não fornece autenticação de clientes nem segurança de transporte. Em sistemas comuns, socket Unix ou canal nomeado depende das permissões do ambiente local. Obter acesso ao endpoint costuma ser suficiente para pedir operações com as chaves expostas ao cliente. A fronteira de segurança passa, portanto, pelos processos e hosts que conseguem alcançar o agente.

Um código hostil pode não conseguir exportar a chave e mesmo assim usar um agente sem restrições para assinar. O documento ainda alerta para a possibilidade de o agente virar um excelente oráculo de observação lateral. O atributo “não exportável” prova algo valioso sobre custódia, mas não prova finalidade legítima. Uso roubado não requer necessariamente segredo roubado.

No caso de token físico, remover uma identidade do agente e apagar a chave do token são operações diferentes. Carregar uma identidade pode apenas delegar futuras ações ao dispositivo. Uma nota de contenção precisa dizer de qual inventário a identidade saiu, qual epoch de carga terminou e se existe um caminho para adicioná-la novamente. “Removida” sem a camada cria uma falsa sensação de revogação.

The Policy Mirror sugere alinhar política e controle real. O sistema operacional admite acesso ao endpoint. O agente aplica restrições. O token protege material e talvez presença local. O servidor SSH decide se a chave serve para o usuário solicitado. A política de serviço decide o que a sessão autenticada pode fazer. A assinatura toca essas camadas, mas não transfere o veredito de uma para outra.

Restrições precisam de tempo e estado

O protocolo permite carregar uma chave com prazo de vida ou com confirmação antes de cada operação privada. Extensões nomeadas podem estabelecer outros limites. Se o agente não entender uma restrição pedida, deve rejeitar a carga em vez de aceitá-la sem a proteção. Isso evita uma degradação silenciosa, porém não elimina a necessidade de registrar o estado efetivo.

Ao adicionar novamente a mesma chave, a nova solicitação deve substituir as restrições anteriores, ou o agente pode recusá-la. A impressão digital, sozinha, não descreve a autoridade corrente. É necessário associar a assinatura ao epoch de carga ou substituição, à validade, à confirmação, às extensões e ao estado de bloqueio daquele instante. Um inventário obtido depois pode mostrar uma política diferente da que valeu durante o evento.

A confirmação também pode ser superestimada. Um clique registra que uma interface recebeu aprovação. Para representar consentimento informado, ela precisa ter mostrado protocolo, destino, conta e consequência de forma segura e verdadeira. Os dados brutos talvez contenham segredos; uma pergunta genérica como “usar a chave?” oferece contexto insuficiente. O caminho equilibrado registra a versão da apresentação e um hash do material exato, sem duplicar o conteúdo sensível.

Bloquear o agente suspende pelo menos as operações de chave privada até o desbloqueio correto. Esse ato controla disponibilidade. Ele não nomeia o próximo cliente, não escolhe um destino e não autoriza todos os pedidos futuros. Usar o desbloqueio como consentimento amplo transforma uma mudança temporária em permissão sem limites.

Encaminhamento transfere capacidade

O encaminhamento do agente permite usar uma chave local a partir de um sistema remoto sem entregar a ele o segredo. É uma propriedade útil, mas também uma delegação. RFC 9987 chama essa relação de confiança transitiva, recomenda que ela não seja padrão e alerta para não encaminhar o agente a hosts que não sejam plenamente confiáveis. Um invasor no host remoto pode invocar a chave através do canal.

Além do risco, existe uma lacuna de atribuição. agent-connect não carrega identificador do canal de sessão que originou a conexão. Uma única conexão SSH pode manter várias sessões, e o agente local pode observar pedidos encaminhados simultâneos. Identificar o transporte não equivale sempre a identificar shell, processo ou pessoa.

Running Code Primary desloca a atenção para os limites executados: permissões do socket, informação do peer, escolha de encaminhamento, restrições ativas, correlação temporal e resultado do verificador. Uma regra escrita contra encaminhamento não comprova o trajeto de uma assinatura; o estado em execução precisa deixar evidência.

O servidor possui o resultado de autenticação

O RFC 4252 define a autenticação de usuário com chave pública. A assinatura inclui o identificador de sessão e campos como usuário, serviço, método, algoritmo e chave. Cabe ao servidor decidir se a chave é autenticadora válida para a conta e verificar a assinatura. Ele ainda pode exigir fatores adicionais. O êxito final chega em SSH_MSG_USERAUTH_SUCCESS, não na resposta do agente.

O RFC 4253 estabelece transporte protegido e identificador de sessão; o RFC 4254 trata canais e serviços posteriores; o RFC 4251 organiza a arquitetura. Assim, uso de chave, autenticação de conta e autorização de ação continuam sendo fatos distintos.

Nem os registros de algoritmos concedem autoridade. O RFC 8332 especifica RSA com SHA-2; o RFC 8709, Ed25519 e Ed448; o RFC 8308, negociação de extensões. O registro de parâmetros SSH da IANA fornece nomes interoperáveis. Registro não é prova de implantação, exposição, aprovação ou permissão.

Um comprovante em seis estágios

O primeiro estágio registra a admissão do solicitante: caminho local ou encaminhado, referência mínima do peer, epoch de política e identificador opaco. O segundo registra a chave: impressão pública, escopo de visibilidade, epoch de carga, validade, confirmação, extensões, delegação a token e bloqueio.

O terceiro descreve a operação por comprimento e hash resistente dos dados exatos, flags e algoritmo. O quarto registra se houve confirmação, que resumo seguro foi exibido, em qual superfície confiável e com qual resultado. O quinto preserva sucesso ou falha do agente e sua classe. O sexto captura o sistema dependente: protocolo, destino, sessão, conta, verificação, fatores adicionais e decisão de autorização.

É uma proposta de governança de Daniel Kade, não um conjunto de campos imposto pelo RFC 9987. O objetivo é manter a cadeia unida sem copiar chave privada, PIN, frase secreta ou dados sensíveis assinados.

Fontes