Guia de Implementação da SES GO - Segurança
0.1.2 - draft BR

Guia de Implementação da SES GO - Segurança - Downloaded Version 0.1.2 See the Directory of published versions

Validar assinatura digital

A confiança em uma assinatura digital depende da validação adequada. Esta validação está definida especificamente para assinaturas digitais criadas pelo caso de uso criar assinatura.

Objetivo

Validar uma assinatura digital avançada produzida conforme o caso de uso de criação. Isso inclui:

  • Verificação criptográfica da assinatura
  • Validação da cadeia de certificados conforme ICP-Brasil
  • Verificação de revogação usando evidências LTV e/ou consultas online
  • Validação temporal usando timestamp auto-declarado (iat) ou token TSA
  • Conformidade com a política de assinatura especificada
  • Verificação de propósito do certificado digital (key usage)

IMPORTANTE: outras verificações podem ser necessárias dependendo do contexto de uso da assinatura digital. Este caso de uso foca exclusivamente na validação técnica da assinatura conforme os padrões e políticas aplicáveis.

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).