Guia de Implementação da SES GO - Segurança
0.0.2 - draft Brazil flag

Guia de Implementação da SES GO - Segurança - Local Development build (v0.0.2) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Validar assinatura digital

A assinatura digital é fundamental para a segurança, mas precisa ser validada. O processo de validação permite confirmar que a informação não foi alterada após a assinatura, identificar inequivocamente o autor e garantir que o responsável não pode negar sua participação.

Objetivo

Validar uma assinatura digital avançada produzida conforme a política, garantindo a integridade, autoria, autenticidade, não-repúdio e validade da cadeia de certificados, verificando também sua revogação por CRL ou OCSP.

Este processo de validação é compatível com assinaturas criadas conforme o caso de uso de criação e utiliza os mesmos códigos de situações excepcionais padronizados.

Entrada

  1. Sequência em base64 (padrão FHIR) contendo a string da JWS JSON Serialization completa (RFC 7515 seção 3.2). Este é exatamente o valor produzido pelo caso de uso criar assinatura e armazenado em Signature.data.

  2. Configurações operacionais:
    • Trust store ICP-Brasil: array não vazio de hashes SHA-256 (hex, 64 chars) das AC-Raiz aceitas.
    • Data mínima de certificados (minCertIssueDate): timestamp Unix UTC inteiro (padrão 1751328000 – 2025-07-01).
    • Timeouts OCSP / CRL / TSA: cada um em segundos (padrão 30, faixa [5, 120]).
    • TTL de cache de revogação: segundos (padrão 3600, faixa [300, 86400]).
    • Limiar de proximidade de expiração (nearExpiryThresholdDays): inteiro dias (padrão 30, faixa [1, 180]).
    • Limiar de idade máxima da assinatura (signatureAgeThresholdDays): inteiro dias (padrão 365, faixa [1, 1825]).
    • Política de revogação (revocationPolicy): enum ['strict','soft-fail','warn'].
      • strict: falha se OCSP/CRL indisponível.
      • soft-fail: continua com warning.
      • warn: continua e registra warning; trata 'unknown' como warning.
    • Tratamento de status OCSP 'unknown' (ocspUnknownHandling): enum ['treat-as-revoked','treat-as-warning'].
    • Limites de segurança (para verificação opcional de integridade): maxEntriesBundle, maxBundleBytes, bundleVerifyTimeout.

  3. Timestamp de referência: inteiro Unix UTC (segundos) usado para TODAS as checagens temporais. Intervalo aceito (inclusivo): 1751328000 (2025-07-01T00:00:00Z) a 4102444800 (2100-01-01T00:00:00Z). A diferença entre o relógio local e este valor não deve exceder ±300s.

  4. Política de assinatura (URI versionada): usada para conferir suporte e requisitos.

  5. (Opcional) Bundle original: necessário apenas se for executar a verificação de integridade opcional.

  6. (Opcional) Provenance original: necessário apenas se for executar a verificação de integridade opcional.

Nota
Itens 1–4 são obrigatórios. Itens 5–6 somente quando habilitada a verificação de integridade do conteúdo. Qualquer ausência ou valor fora de faixa em itens obrigatórios resulta em OperationOutcome. Todas as validações são realizadas durante o processo.

Saída

Resultado da validação, indicativo de sucesso ou rejeição (invalidação), em formato OperationOutcome, detalhando os motivos de eventual invalidação. Em caso de rejeição, implementações devem utilizar o perfil resultado para Assinatura Digital e os códigos padronizados do CodeSystem de Situações Excepcionais para garantir consistência e interoperabilidade.

Processo

Ao longo da validação podem ocorrer condições de rejeição; a ocorrência de qualquer uma interrompe a validação. Cada condição de rejeição resulta em uma instância de OperationOutcome com um código específico.

0. Verificação das configurações operacionais

  • Validar presença de todos os parâmetros obrigatórios listados nas entradas 2–5.
  • Trust store vazio → CONFIG.TRUST-STORE-EMPTY.
  • Hash raiz com formato inválido → FORMAT.BASE64-INVALID ou CONFIG.INVALID-PARAMETER (se não hex de 64).
  • Data mínima inválida (não inteiro positivo) → CONFIG.CERT-MIN-DATE-INVALID.
  • Data mínima fora de faixa [1609459200, 4102444800] → CONFIG.CERT-MIN-DATE-OUT-OF-RANGE.
  • Timeouts fora de [5, 120] → CONFIG.TIMEOUT-OUT-OF-RANGE.
  • TTL fora de [300, 86400] → CONFIG.TTL-OUT-OF-RANGE.
  • nearExpiryThresholdDays fora de [1, 180] → CONFIG.INVALID-PARAMETER.
  • signatureAgeThresholdDays fora de [1, 1825] → CONFIG.INVALID-PARAMETER.
  • revocationPolicy não em ['strict','soft-fail','warn'] → CONFIG.INVALID-PARAMETER.
  • ocspUnknownHandling inválido → CONFIG.INVALID-PARAMETER.
  • Qualquer falha interrompe a validação antes de processamento criptográfico.

1. Extração e parsing do JWS JSON Serialization

  • Recupera o JWS JSON Serialization codificado na base64 (item 1 da entrada).
  • Decodifica o valor recebido da base64 para a string JSON correspondente.
  • Realiza parsing da string JSON para obter a estrutura JWS:
    • Verifica se possui a propriedade payload (obrigatória)
    • Verifica se possui a propriedade signatures como array (obrigatória)
    • Confirma que signatures[0] contém as propriedades protected e signature (obrigatórias)
    • Se está presente signatures[0].header, então a entrada contém evidências para LTV).
  • Extrai os componentes principais:
    • payload: conteúdo assinado (hash SHA-256 em base64Url)
    • protected header: em base64Url, contém alg, x5c, sigPId e opcionalmente iat
    • unprotected header: objeto JSON contendo evidências rRefs e opcionalmente sigTst
    • signature: assinatura criptográfica em base64Url
  • Se qualquer verificação estrutural falhar, retorne código FORMAT.JWS-MALFORMED especificando o problema detectado.

2. Validação dos headers JWS (protected e unprotected)

2.1 Validação do Protected Header:

  • Decodifica signatures[0].protected (base64Url) para obter o objeto JSON correspondente.
  • Verifica o campo alg (obrigatório):
    • Confirma que o valor é RS256 ou ES256 (únicos algoritmos suportados).
    • Se inválido, retorne código VALIDATION.UNSUPPORTED-ALGORITHM.
    • Para ES256: após decodificação da assinatura (ver 4.2), confirme que o comprimento decodificado é 64 bytes (r   s); se não for, VALIDATION.SIGNATURE-VERIFICATION-FAILED.
  • Verifica o campo x5c (obrigatório):
    • Confirma que está presente e é um array não vazio de strings.
    • Garante que cada string é um certificado válido em base64 DER.
    • Se inválido, retorne código CERT.INVALID-FORMAT.
  • Verifica o campo sigPId (obrigatório):
    • Confirma que está presente e contém a propriedade id com URI da política.
    • Valida se a política especificada é suportada pela implementação.
    • Se política não suportada, retorne código POLICY.VERSION-UNSUPPORTED.
  • Verifica o campo iat (condicional):
    • Se presente (estratégia iat), confirme que é um timestamp Unix UTC válido.
    • Garante que não indica data futura e está no período de validade do certificado.
    • Se inválido, retorne código TEMPORAL.IAT-INVALID.

2.2 Validação do Unprotected Header:

  • Acessa signatures[0].header (objeto JSON não codificado).
  • Verifica evidências LTV em rRefs (obrigatório):
    • Confirma presença de ocspRefs e/ou crlRefs conforme disponibilidade.
    • Valida estrutura: cada evidência deve ter digestAlg e digestValue.
    • Confirma que digestAlg é "http://www.w3.org/2001/04/xmlenc#sha512".
    • Valida que digestValue são hashes SHA-512 válidos (88 caracteres base64).
    • Garante unicidade de cada digestValue dentro de seu array e ausência de duplicação cruzada entre ocspRefs e crlRefs.
    • Se estrutura inválida, retorne código VALIDATION.LTV-EVIDENCE-INVALID.
  • Verifica sigTst (condicional):
    • Se presente (estratégia tsa), confirme que contém token TSA válido em base64.
    • Se inválido, retorne código TSA.INVALID-TOKEN.

2.3 Determinação da Estratégia de Timestamp:

  • Se protected.iat presente e unprotected.sigTst ausente: estratégia iat
  • Se protected.iat ausente e unprotected.sigTst presente: estratégia tsa
  • Se ambos presentes ou ambos ausentes: retorne código VALIDATION.TIMESTAMP-STRATEGY-INVALID

3. Validação da cadeia de certificados

3.1 Extração e decodificação:

  • Obtenha a cadeia de certificados do campo x5c do protected header.
  • Decodifique cada certificado de base64 para formato DER.
  • Se alguma decodificação falhar, retorne código FORMAT.BASE64-INVALID.
  • Valide o formato DER de cada certificado. Se inválido, retorne código CERT.INVALID-FORMAT.

3.2 Verificação da estrutura da cadeia:

  • Confirme que a cadeia possui pelo menos 2 certificados (signatário + AC).
  • Se insuficiente, retorne código CERT.CHAIN-INCOMPLETE.
  • Identifique os papéis:
    • Posição 0: certificado do signatário (folha/end-entity)
    • Posições 1 a n-2: certificados das ACs intermediárias
    • Posição n-1: certificado da AC Raiz ICP-Brasil

3.3 Validação da raiz ICP-Brasil:

  • Obtenha o certificado raiz (última posição da cadeia).
  • Calcule o hash SHA-256 do certificado em formato DER.
  • Compare com os hashes do trust store ICP-Brasil (das configurações ou padrão).
  • Se não encontrado, retorne código CERT.NOT-ICP-BRASIL.

3.4 Verificação de elegibilidade ICP-Brasil:

  • Examine a extensão Certificate Policies (OID 2.5.29.32) do certificado folha.
  • Confirme que existe pelo menos uma política com OID iniciado por 2.16.76.1.
  • Se ausente, retorne código CERT.NOT-ICP-BRASIL.

3.5 Verificação da data mínima de emissão (issue date):

  • Obtenha notBefore do certificado folha.
  • Compare com a data mínima (entrada 2: minCertIssueDate).
  • Se notBefore < data mínima → CERT.ISSUE-DATE-TOO-OLD.

3.6 Validação temporal da cadeia:

  • Para cada certificado na cadeia, verifique a validade temporal:
    • Use SEMPRE o timestamp de referência (entrada 4). Para estratégia iat, o valor iat deve também estar dentro do mesmo intervalo; divergências serão tratadas em 6.1.
    • Confirme: notBefore ≤ timestamp ≤ notAfter
    • Se certificado expirado, retorne código CERT.EXPIRED
    • Se certificado ainda não válido, retorne código CERT.NOT-YET-VALID
    • Se (notAfter - timestamp) < nearExpiryThresholdDays * 86400 → adicionar warning CERT.NEAR-EXPIRY (não interrompe processo)

3.7 Validação criptográfica da hierarquia:

  • Para cada certificado i de 0 a n-2:
    • Verifique a assinatura do certificado i usando a chave pública do certificado i+1
    • Confirme que subject do certificado i+1 = issuer do certificado i
    • Se verificação falhar, retorne código CERT.CHAIN-VALIDATION-FAILED

3.8 Verificação de algoritmos e tamanhos de chave:

  • Para chaves RSA: mínimo 2048 bits, algoritmo rsaEncryption (OID 1.2.840.113549.1.1.1)
  • Para chaves ECC: mínimo 256 bits, curva P-256, algoritmo id-ecPublicKey (OID 1.2.840.10045.2.1)
  • Se inadequado, retorne código CERT.WEAK-KEY ou CERT.UNSUPPORTED-ALGORITHM

4. Verificação da assinatura criptográfica

4.1 Construção da string de assinatura (signing input):

  • Obtenha o protected header base64Url de signatures[0].protected.
  • Obtenha o payload base64Url da propriedade payload.
  • Concatene ambos com ponto como separador: protected_header.payload.
  • Esta é a string que foi efetivamente assinada pelo signatário.

4.2 Preparação para verificação:

  • Codifique a string de assinatura em bytes UTF-8.
  • Decodifique signatures[0].signature de base64Url para obter os bytes da assinatura.
  • Extraia a chave pública do certificado do signatário (primeiro certificado em x5c).

4.3 Verificação criptográfica:

  • Determine o algoritmo baseado no campo alg do protected header:
    • Para RS256: Use RSA com SHA-256 (RSASSA-PKCS1-v1_5)
    • Para ES256: Use ECDSA com SHA-256 e curva P-256
  • Execute a verificação da assinatura:
    • Input: bytes UTF-8 da string protected_header.payload
    • Algoritmo: conforme determinado acima
    • Chave pública: extraída do certificado do signatário
    • Assinatura: bytes decodificados de signatures[0].signature
  • Se a verificação criptográfica falhar, retorne código VALIDATION.SIGNATURE-VERIFICATION-FAILED.

4.4 Verificações de segurança adicionais:

  • Confirme que o algoritmo da chave pública é compatível com o algoritmo declarado em alg.
  • Para ECDSA, implemente verificações timing-safe para prevenir side-channel attacks.
  • Valide que os parâmetros criptográficos estão em conformidade com as normas ICP-Brasil.
  • Monitore tempo de execução de operações criptográficas; padrões anômalos estatisticamente significativos podem gerar warning CRYPTO.TIMING-ATTACK-DETECTED.

5. Verificação de revogação usando evidências LTV

5.1 Estratégia de validação:

  • Prioridade 1: Use evidências LTV armazenadas em rRefs (recomendado para Long Term Validation)
  • Prioridade 2: Consulte serviços OCSP/CRL online se evidências LTV indisponíveis
  • Fallback: Aplicação pode configurar política de falha (rejeitar ou aceitar com warning)
  • Cache: se respostas OCSP/CRL previamente armazenadas estiverem dentro do TTL, reutilizar; se expiradas, tentar atualizar. Falha de atualização por indisponibilidade → aplicar política (possível warning REVOCATION.CACHE-EXPIRED).
  • Metadados: cada entrada de cache DEVE armazenar fetchedAt, nextUpdate (se fornecido) e calcular expiresAt = min(fetchedAt + TTL, nextUpdate).
  • Expiração: se referenceTimestamp > expiresAt e renovação falhar → REVOCATION.CACHE-EXPIRED (erro em strict, warning em soft-fail/warn).

5.2 Validação usando evidências LTV (rRefs):

  • Para cada certificado na cadeia (exceto raiz), processe as evidências:

5.2.1 Evidências OCSP (ocspRefs):

  • Para cada entrada em rRefs.ocspRefs:
    • Valide a estrutura: digestAlg = "http://www.w3.org/2001/04/xmlenc#sha512"
    • Confirme que digestValue é hash SHA-512 válido (88 caracteres base64)
    • Nota: As evidências LTV contêm apenas as referências (hashes), não os dados OCSP completos
    • A validação completa requer acesso às respostas OCSP originais ou consulta online
    • Se evidências LTV inconsistentes, retorne código VALIDATION.LTV-EVIDENCE-INVALID

5.2.2 Evidências CRL (crlRefs):

  • Para cada entrada em rRefs.crlRefs:
    • Aplique as mesmas validações da seção 5.2.1 para estrutura
    • Nota: Similar às evidências OCSP, contêm apenas hashes das CRLs

5.3 Consulta online de revogação (quando necessário):

  • Se evidências LTV indisponíveis ou política exigir verificação online:
    • Extraia URLs OCSP da extensão AIA (OID 1.3.6.1.5.5.7.48.1)
    • Extraia URLs CRL da extensão CDP (OID 2.5.29.31)
    • Realize consultas com timeouts configurados (padrão 30 segundos)
    • Para certificado revogado, retorne código CERT.REVOKED
    • Para serviços indisponíveis, retorne código REVOCATION.OCSP-UNAVAILABLE ou REVOCATION.CRL-UNAVAILABLE
    • Aplicar política de fallback:
      • revocationPolicy = strict → indisponibilidade resulta em erro imediato.
      • revocationPolicy = soft-fail → registrar código de erro + continuar (pode resultar em sucesso com warnings agregados).
      • revocationPolicy = warn → registrar como warning quando possível (ex.: mapear indisponibilidade para warning equivalente, se definido; caso contrário, erro padrão).
    • Tratamento de status 'unknown' conforme ocspUnknownHandling: treat-as-revoked → CERT.REVOKED; treat-as-warning → warning + continuar.
    • Se revocationPolicy = warn, REVOCATION.OCSP-UNAVAILABLE, REVOCATION.CRL-UNAVAILABLE, REVOCATION.CACHE-EXPIRED e status 'unknown' são sempre warnings (não erros), exceto se combinado com evidência explícita de revogação.
    • Se cache existente expirou e não foi possível renovar devido a indisponibilidade → REVOCATION.CACHE-EXPIRED (warning em soft-fail/warn; erro em strict).

5.4 Interpretação de resultados:

  • Status "good/valid": Certificado não revogado
  • Status "revoked": Certificado revogado - falha imediata
  • Status "unknown": Tratar conforme política (geralmente como revogado)
  • Erro de comunicação: Aplicar política de fallback configurada

Nota sobre evidências LTV: As evidências em rRefs permitem validação offline e futura, mas contêm apenas hashes das respostas OCSP/CRL originais. Para validação completa, pode ser necessário acesso aos dados originais ou consulta online conforme política de segurança.

6. Validação de timestamp e conformidade com política

6.1 Validação por estratégia de timestamp:

Estratégia iat (timestamp auto-declarado):

  • Obtenha o valor iat do protected header.
  • Validações temporais:
    • Confirme que iat ≥ notBefore do certificado signatário
    • Confirme que iat ≤ notAfter do certificado signatário
    • Confirme que iat ≤ timestamp de referência (entrada 4)
    • Se diferença absoluta entre iat e timestamp de referência > 300s, emitir warning TEMPORAL.CLOCK-SKEW-DETECTED (se ainda dentro da validade) ou erro se quebra limites de validade.
    • Se fora dos limites, retorne código TEMPORAL.IAT-OUT-OF-CERT-PERIOD
  • Limitação: Baseado na confiança no signatário, sujeito a manipulação

Estratégia tsa (timestamp por TSA):

  • Obtenha o token TSA de sigTst no unprotected header.
  • Decodifique o token TSA de base64 para formato DER.
  • Valide o token TSA conforme RFC 3161:
    • Verifique a assinatura criptográfica do token
    • Confirme que o hash do token corresponde ao hash da assinatura JWS
    • Valide a cadeia de certificados da TSA
    • Confirme que o timestamp está no período de validade do certificado signatário
  • Utilize o timeout TSA configurado; excesso de tempo → TSA.UNAVAILABLE (ou aplicar política revocationPolicy se alinhado a fallback temporal).
  • Diferencie falhas:
    • Estrutura / sintaxe / ASN.1 inválida → TSA.INVALID-RESPONSE
    • Falha criptográfica (assinatura, hash não confere, cadeia TSA inválida) → TSA.VALIDATION-FAILED
    • Indisponibilidade / timeout → TSA.UNAVAILABLE
  • Avalie skew: se tsaTimestamp - timestamp de referência > 300s: emitir TEMPORAL.CLOCK-SKEW-DETECTED (warning) se ainda dentro da validade, caso contrário erro apropriado (ex.: TEMPORAL.TSA-TIMESTAMP-OUT-OF-BOUNDS).
  • Vantagem: Prova criptográfica verificável de terceira parte confiável

6.2 Validação da política de assinatura:

  • Obtenha a URI da política de sigPId.id no protected header.
  • Confirme que a política especificada é suportada pela implementação atual.
  • Verifique se todos os requisitos da política foram atendidos:
    • Algoritmos utilizados são aprovados pela política
    • Tamanhos de chave atendem aos requisitos mínimos
    • Certificados atendem às exigências temporais (data mínima)
    • Evidências LTV foram coletadas conforme especificado
  • Se política não suportada, retorne código POLICY.VERSION-UNSUPPORTED
  • Se requisitos não atendidos, retorne código VALIDATION.POLICY-COMPLIANCE-FAILED

6.3 Verificações de segurança adicionais:

  • Confirme que não há sinais de manipulação temporal (backdating)
  • Para estratégia tsa, valide que o timestamp TSA está consistente com as evidências LTV
  • Verifique se a assinatura atende aos requisitos de não-repúdio da política
  • Calcule idade da assinatura: diff = timestamp de referência − (iat ou tsaTimestamp). Se diff > signatureAgeThresholdDays * 86400 → adicionar warning TEMPORAL.SIGNATURE-TOO-OLD.

7. Resultado da validação

7.1 Sucesso:

  • Se todas as etapas anteriores foram concluídas com sucesso, retorne um OperationOutcome com:
    • issue.severity = information
    • issue.code = informational
    • issue.details.coding usando código VALIDATION.SUCCESS do CodeSystem de situações excepcionais
    • issue.details.text = "Assinatura digital validada com sucesso"
    • issue.diagnostics com detalhes da validação (algoritmo, política, estratégia de timestamp)

7.2 Tabela de códigos de retorno (sucesso e condições de rejeição): Todos os códigos retornáveis neste processo (sucesso e condições de rejeição) em ordem alfabética. A severidade efetiva é definida no CodeSystem; aqui lista-se o significado textual. O termo "condição de rejeição" neste documento significa que a assinatura é considerada inválida, não implicando defeito interno no software validador.

Código Descrição
CERT.CHAIN-VALIDATION-FAILED Cadeia de certificados inválida
CERT.EXPIRED Certificado expirado na cadeia
CERT.INVALID-FORMAT Array x5c malformado ou certificados inválidos
CERT.NOT-ICP-BRASIL Certificado não elegível ICP-Brasil
CERT.REVOKED Certificado revogado detectado
CERT.WEAK-KEY Tamanho de chave insuficiente
FORMAT.BASE64-INVALID Dados base64 inválidos em componentes JWS
FORMAT.JWS-MALFORMED Estrutura JWS JSON não conforme RFC 7515
POLICY.VERSION-UNSUPPORTED Versão da política não implementada
REVOCATION.CACHE-EXPIRED Entrada de cache de revogação expirada e não renovada
REVOCATION.CRL-UNAVAILABLE Serviço CRL indisponível
REVOCATION.OCSP-UNAVAILABLE Serviço OCSP indisponível
TEMPORAL.IAT-OUT-OF-CERT-PERIOD Timestamp iat fora da validade do certificado
TSA.VALIDATION-FAILED Falha na validação do token TSA
VALIDATION.LTV-EVIDENCE-INVALID Evidências LTV inconsistentes
VALIDATION.POLICY-COMPLIANCE-FAILED Assinatura não conforme com política
VALIDATION.SIGNATURE-VERIFICATION-FAILED Falha na verificação da assinatura digital
VALIDATION.SUCCESS Assinatura digital validada com sucesso
VALIDATION.UNSUPPORTED-ALGORITHM Algoritmo de assinatura não suportado

7.3 Formato do OperationOutcome:

  • Utilize o perfil resultado para Assinatura Digital.
  • Inclua contexto específico em issue.diagnostics quando apropriado
  • Especifique localização do problema em issue.location quando possível
  • Para múltiplos problemas, use múltiplas entradas issue

Verificação da integridade do conteúdo assinado (opcional)

Esta seção é opcional e aplicável apenas quando o validador tem acesso ao conteúdo original (Bundle e Provenance) que foi assinado e deseja verificar se não foi alterado.

Pré-requisitos:

  • Acesso ao Bundle original com as instâncias assinadas
  • Acesso ao Provenance original com a ordem de assinatura
  • Conhecimento da versão da política de assinatura utilizada

Processo de verificação:

1. Preparação das instâncias:

  • Para cada instância referenciada em Provenance.target, crie uma cópia
  • Remova os elementos especificados: id, meta.versionId, meta.lastUpdated, meta.source e meta.tag
  • Preserve meta.profile e meta.security (estes elementos fazem parte da assinatura)
  • Mantenha todos os demais elementos rigorosamente idênticos

2. Canonicalização:

  • Aplique canonicalização JSON conforme RFC 8785 a cada cópia
  • A canonicalização deve produzir bytes UTF-8 determinísticos
  • Mantenha a ordem das instâncias conforme Provenance.target

3. Concatenação e hash:

  • Concatene as sequências de bytes das instâncias canonicalizadas
  • Use a ordem exata definida em Provenance.target
  • Não adicione separadores ou delimitadores entre as instâncias
  • Calcule o hash SHA-256 da concatenação resultante

4. Codificação e comparação:

  • Codifique o hash SHA-256 em base64Url (43 caracteres, sem padding)
  • Compare com o valor payload extraído do JWS JSON Serialization
  • Se valores idênticos: Integridade do conteúdo confirmada
  • Se valores diferentes: Conteúdo foi alterado ou há inconsistência no processo

Nota importante: Esta verificação é independente da validação da assinatura digital. Uma assinatura pode ser criptograficamente válida mesmo se o conteúdo original não estiver disponível ou tiver sido alterado após a assinatura.

Segurança na implementação:

  • Implemente verificações timing-safe para prevenir side-channel attacks
  • Valide todos os inputs antes do processamento criptográfico
  • Use bibliotecas criptográficas atualizadas e validadas
  • Registre todas as operações de validação para auditoria
  • Registre todas as operações de validação para auditoria conforme especificado no caso de uso de auditoria
  • Ao executar esta verificação opcional, aplicar limites de segurança das entradas: se número de entradas > maxEntriesBundle → SECURITY.BUNDLE-SIZE-LIMIT-EXCEEDED; se tamanho serializado > maxBundleBytes → SECURITY.BUNDLE-MEMORY-LIMIT-EXCEEDED; se tempo de processamento exceder bundleVerifyTimeout → SECURITY.BUNDLE-TIMEOUT-EXCEEDED.
  • Ausência de Bundle/Provenance (não fornecidos) → verificação opcional simplesmente não executada (nenhum código de erro gerado).