Resumo

  • A RFC 9690 afirma que rsaEncryption não sinaliza a disposição do dono da chave para aceitar RSA-KEM; essa disposição precisa de evidência própria.
  • O remetente deve vincular certificado, origem e idade da capacidade, duas KDFs, tamanho da KEK, algoritmo de wrap e tipo CMS antes de declarar a rota utilizável.

O erro começa em uma tabela aparentemente inocente. A linha do destinatário diz “RSA”, a cadeia X.509 passa e a chave tem tamanho suficiente. Outra camada lê esses dados e marca “RSA-KEM disponível”. A primeira linha descreve uma chave; a segunda inventa uma política.

A RFC 9690 é explícita: o AlgorithmIdentifier rsaEncryption não informa que o destinatário aceitará RSA-KEM com aquela chave. O certificado pode continuar válido enquanto o software, a configuração, o tipo de conteúdo ou a política local já mudaram.

Também não existe uma única escolha chamada “KEM”. RSA-KEM cifra um inteiro aleatório novo z e usa uma KDF para formar o segredo compartilhado. A camada CMS usa outra KDF para produzir a chave que desembrulha a chave de conteúdo. As duas KDFs podem ser diferentes. KDF3/SHA-256 e AES-Wrap-128 são o piso obrigatório; outras combinações continuam possíveis.

A lista de capacidades é parcial

O destinatário pode anunciar RSA-KEM em SMIMECapabilities dentro de signed-data segundo a RFC 8551, ou na extensão de certificado da RFC 4262. É uma evidência melhor que a forma da chave, mas não uma licença sem prazo. A lista é parcial. Um anúncio antigo comprova o que um cliente declarou naquele momento, não o estado atual do endpoint.

Por isso, o registro deve guardar assinante, horário, certificado relacionado, canal e parâmetros. A presença não prova serviço ativo nem autorização para esta mensagem; a ausência tampouco basta para provar incapacidade.

Quando a chave serve exclusivamente para RSA-KEM, id-rsa-kem-spki expressa uma intenção mais estreita. Parâmetros ausentes implicam KDF3/SHA-256 na derivação interna; parâmetros presentes usam GenericHybridParameters e limitam KDF, tamanho da KEK e wrap. Se keyUsage existir, somente keyEncipherment é permitido. Ainda falta provar posse atual da chave privada, decapsulação e aceite da aplicação.

Dois formatos de migração, duas trilhas

A RFC 5990 usava KeyTransRecipientInfo e juntava C com WK. A RFC 9690 adota o KEMRecipientInfo da RFC 9629, separando kemct de encryptedKey. Compatibilidade retroativa ajuda a migração, mas não autoriza esconder qual processamento foi escolhido.

O recibo precisa nomear RFC 5990 ou RFC 9690, certificado, anúncio e tupla. Do lado do destinatário, deve separar teste de tamanho e faixa, operação da chave privada, derivação do segredo, derivação da KEK, unwrap, processamento do conteúdo e decisão da aplicação. Um ciphertext bem construído no remetente não comprova essas etapas.

Uma decisão com validade

O remetente registra impressão digital e validação da cadeia; OID e bytes de parâmetros; keyUsage; procedência e idade da capacidade; KDF/hash internos; KDF CMS; tamanho da KEK; wrap; conteúdo; e a rota de compatibilidade escolhida.

Rotação de certificado, atualização do cliente, retirada de algoritmo, mudança de conteúdo ou primeiro erro da tupla vencem o registro. Sem evidência atual, o sistema pede confirmação ou usa um mecanismo autorizado à parte. Não presume consentimento porque viu rsaEncryption.

As RFC 8017, RFC 3394, RFC 4086 e RFC 5280 definem RSA, wrap, aleatoriedade e certificados. Nenhuma delas observa a aplicação viva.

O princípio de especificação inicial mínima de Lu Heng favorece um piso comum pequeno, sem converter escolhas futuras em obrigação universal. A lente das camadas de realidade separa certificado, capacidade, estrutura, cálculo e decisão. A primazia do código em execução reserva o último fato ao que o destinatário realmente fez.

Fontes