Guia de Implementação da SES GO - Segurança
0.0.2 - draft
Guia de Implementação da SES GO - Segurança
0.0.2 - draft
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
Define o processo de criação de assinatura digital avançada na qual o signatário produz uma assinatura que permite a qualquer outro ator, com acesso ao conteúdo assinado, atestar, de forma inequívoca, a autoria, a integridade, a autenticidade e o não-repúdio da informação registrada digitalmente. A validação de assinatura é definida em caso de uso próprio.
Este caso de uso detalha o processo de criação de assinatura digital em conformidade com a Política de Assinatura Digital Avançada definida no presente guia.
Uma instância do recurso Bundle (FHIR versão 4.0.1), serializada em JSON, contendo o conjunto de instâncias a ser assinado. O conjunto deve possuir pelo menos uma instância. Ou seja, a instância do Bundle deve conter pelo menos uma entrada (Bundle.entry).
Uma instância do recurso Provenance (FHIR versão 4.0.1), serializada em JSON, contendo uma entrada em Provenance.target para cada instância do conjunto a ser assinado. Cada entrada deste array referencia uma instância disponível em uma entrada da instância do Bundle (item anterior). As instâncias a serem assinadas serão consideradas na ordem em que são referenciadas em Provenance.target e esta ordem terá que ser preservada.
Nota
Os protocolos de transporte, métodos de comunicação com dispositivos criptográficos, drivers específicos de hardware e detalhes de descoberta automática de dispositivos são considerações de implementação que não fazem parte desta política de assinatura digital. As configurações operacionais de middleware (item 8) definem parâmetros técnicos necessários para garantir interoperabilidade e segurança, mas a implementação específica desses mecanismos permanece fora do escopo normativo da política.
x5c do protected header JWS durante a etapa 7.3. Cada elemento do array da cadeia é uma string contendo um certificado X.509v3 no formato DER (Distinguished Encoding Rules) codificado em base64 padrão. A ordenação deve formar uma cadeia de confiança válida. A cadeia deve possuir pelo menos dois certificados. Observe que:
i é assinado pelo certificado na posição i+1. Observe que pode não existir certificado intermediário.i deve validar a assinatura do certificado na posição i-1.subject do certificado i+1 deve corresponder ao campo issuer do certificado i2.16.76.1 (ICP-Brasil).notBefore ≤ timestamp ≤ notAfter).iat (quando estratégia iat).Requisitos obrigatórios:
iat: usa o timestamp de referência (item 5) como instante da assinatura (estratégia padrão). A compatibilidade temporal com o certificado signatário será verificada durante o processo de validação.tsa: solicita carimbo de tempo de uma TSA (Timestamping Authority) externa conforme RFC 3161. Fornece prova criptográfica independente do momento da assinatura. A configuração da TSA é fornecida no item 8.sigPId (Signature Policy Identifier) do JAdES durante a etapa 7.5 do processo. Formato obrigatório:
https://fhir.saude.go.gov.br/r4/seguranca/ImplementationGuide/br.go.ses.seguranca| (pipe character)major.minor.patch (ex: 0.0.2){baseUri}|{versão}Exemplo: https://fhir.saude.go.gov.br/r4/seguranca/ImplementationGuide/br.go.ses.seguranca|0.0.2
Configurações operacionais: parâmetros estruturados para controle do processo de assinatura. Estas configurações são fornecidas por um objeto JSON cujas propriedades identificam domínios funcionais (também detalhados por objetos JSON):
verification):
ocspCacheTtl: valor positivo em segundos, padrão 3600 (1 hora), intervalo válido [300, 86400], define tempo de vida para respostas OCSP em cache. Implementação: usar timestamp Unix UTC para controle de expiração.crlCacheTtl: valor positivo em segundos, padrão 3600 (1 hora), intervalo [300, 86400], define tempo de vida para listas CRL em cache. Implementação: usar timestamp Unix UTC para controle de expiração.ocspTimeout: valor positivo em segundos, padrão 20, intervalo [5, 120]. Note: em ambiente browser pode ser limitado por políticas CORS.crlTimeout: valor positivo em segundos, padrão 20, intervalo [5, 120]. Note: em ambiente browser pode ser limitado por políticas CORS.tsaTimeout: valor positivo em segundos, padrão 20, intervalo [5, 120].maxRetries: inteiro positivo, padrão 3, intervalo [1, 5], define número máximo de tentativas para consultas OCSP/CRL/TSA em caso de falha de rede.retryInterval: valor positivo em segundos, padrão 2, intervalo [1, 10], define intervalo entre tentativas de retry para consultas OCSP/CRL/TSA.tsaUrl: string não vazia iniciada por https:// exigida quando a estratégia é tsa (item 6 da entrada), deve ser uma URL válida conforme RFC 3986 para serviços TSA RFC 3161. Validação: usar regex ^https://[^\s]+$ ou parser de URL nativo da linguagem.tsaUsername: (opcional) string UTF-8 para autenticação HTTP Basic na TSA, se requerida pelo servidor TSA. Implementação: codificar como Base64(usuario:senha) no header Authorization: Basic <base64>.tsaPassword: (opcional) string UTF-8 para autenticação HTTP Basic na TSA, se requerida pelo servidor TSA. Implementação: usar junto com usuário para formar credencial Base64.trustStore):
rootCertificates: array não vazio de strings, cada elemento contendo um certificado AC-Raiz ICP-Brasil completo em formato PEM (incluindo delimitadores -----BEGIN CERTIFICATE----- e -----END CERTIFICATE-----)temporalPolicy):
minCertificateDate: timestamp Unix UTC (inteiro positivo), padrão 1751328000 (1º julho 2025), define a data mínima para aceitação de certificados signatários emitidos após esta datasecurity):
maxEntriesBundle: número máximo de entradas na instância do Bundle definido por um inteiro positivo, padrão 1000, intervalo [100, 10000]maxBundleSize: tamanho máximo da instância do Bundle definido por um inteiro positivo, padrão 52428800 (50MB), intervalo [1048576, 209715200] (1MB-200MB).timoutVerificationBundle: timeout de verificação do Bundle em segundos definido por um inteiro positivo, padrão 10, intervalo [5, 300].middlewareCrypto):
A assinatura digital em conformidade com a Política de Assinatura Digital Avançada conforme a versão da política identificada na entrada. A assinatura é registrada em uma instância do tipo de dados Signature em conformidade com o perfil assinatura avançada.
A instância de Signature é retornada apenas em caso de sucesso. Em caso de falha é retornada uma instância do recurso OperationOutcome contendo detalhes da situação excepcional que impede a produção da assinatura. Para garantir consistência e interoperabilidade, implementações devem utilizar o perfil Falha de Assinatura Digital e os códigos padronizados definidos no CodeSystem Situações Excepcionais.
Registros de auditoria devem ser realizados, conforme caso de uso de auditoria, para garantir rastreabilidade e capacidade de investigação de incidentes de segurança.
A saída é produzida a partir das entradas por um processo dividido em 14 etapas que agrupam dezenas de ações. Muitas delas podem resultar em falhas. Todas as falhas são identificadas ao longo do processo e a ocorrência de qualquer uma delas interrompe o processo sem que a assinatura seja criada. Toda falha resulta em um instância de OperationOutcome retornada com um código específico.
Abaixo segue um diagrama com as dependências de dados entre as várias ações.
Todos os itens da entrada serão rigorosamente verificados quanto à conformidade com os requisitos da versão da política de assinatura digital avançada (uma das entradas).
1.1 Verificação da política de assinatura:
https://fhir.saude.go.gov.br/r4/seguranca/ImplementationGuide/br.go.ses.seguranca|| (pipe character)| segue o formato semântico major.minor.patch (ex: 0.0.2)POLICY.URI-INVALIDPOLICY.VERSION-UNSUPPORTED, detalhando:
Nota
A verificação prévia da política garante que toda a operação de assinatura seja executada conforme regras conhecidas e testadas pela implementação.
1.2 Verificação do timestamp de referência:
CONFIG.INVALID-TIMESTAMP-FORMAT.CONFIG.TIMESTAMP-OUT-OF-RANGE.1.3 Verificação da estratégia de timestamp:
iat ou tsa.iat ou tsa, retorne OperationOutcome com código CONFIG.INVALID-STRATEGY.tsa: verifique se as configurações de TSA estão presentes no item 8 (URL da TSA, timeout para solicitações TSA). Se alguma configuração obrigatória estiver ausente, retorne código CONFIG.TSA-CONFIG-MISSING.1.4 Verificação estrutural da instância do Bundle:
FORMAT.BUNDLE-MALFORMED.FORMAT.BUNDLE-EMPTY.urn:uuid: seguido de UUID RFC 4122).FORMAT.BUNDLE-MALFORMED com detalhes específicos em diagnostics.SECURITY.BUNDLE-SIZE-LIMIT-EXCEEDED.SECURITY.BUNDLE-MEMORY-LIMIT-EXCEEDED.SECURITY.BUNDLE-TIMEOUT-EXCEEDED.1.5 Verificação estrutural da instância do Provenance:
FORMAT.PROVENANCE-INVALID.FORMAT.PROVENANCE-INVALID.urn:uuid: seguido de UUID RFC 4122. Se o tipo é inválido, retorne FORMAT.PROVENANCE-TARGET-INVALID.FORMAT.PROVENANCE-TARGET-DUPLICATE.SECURITY.PROVENANCE-SIZE-LIMIT-EXCEEDED.1.6 Verificação da disponibilidade na instância do Bundle das referências em Provenance.target. Para cada referência em Provenance.target deve existir exatamente uma única entrada (Bundle.entry) correspondente na instância do Bundle:
FORMAT.TARGET-REFERENCE-MISSING.FORMAT.BUNDLE-DUPLICATE-ENTRY.1.7 Verificação da disponibilidade das instâncias referenciadas:
FORMAT.BUNDLE-RESOURCE-MISSING.1.8 Verificação do conteúdo das instâncias referenciadas:
FORMAT.BUNDLE-MALFORMED. Não é feita nenhuma verificação de conformidade da instância com eventuais perfis declarados em meta.profile. A verificação apenas garante que se trata de uma instância FHIR em conformidade com a versão 4.0.1, sem incluir perfis específicos.Nota
A não verificação de conformidade com perfis específicos declarados em meta.profile pode representar riscos que estão além do escopo da assinatura digital.
1.9 Verificação de referências do conteúdo assinado:
Reference.identifier está presente e Reference.reference está ausente.Reference.reference no formato urn:uuid: seguido de UUID RFC 4122 válido e Reference.identifier está ausente.Reference.reference com fragmento #id para recurso incorporado na mesma instância e Reference.identifier está ausente.Reference.reference com valor # (usado quando instância contida referencia sua instância container) e Reference.identifier está ausente.FORMAT.REFERENCE-INVALID especificando a instância e o elemento problemático.fullUrl igual ao valor da referência. Se não existir, retorne código FORMAT.REFERENCE-MISSING.contained da mesma instância. Se não existir, retorne código FORMAT.REFERENCE-MISSING.1.10 Verificação do instante de tempo:
FORMAT.INVALID-TIMESTAMP.1.11 Verificação das configurações operacionais (item 8 das entradas):
CONFIG.TTL-OUT-OF-RANGE.CONFIG.TIMEOUT-OUT-OF-RANGE.tsa):
CONFIG.TSA-URL-INVALID.CONFIG.TRUST-STORE-EMPTY.FORMAT.CERT-PEM-INVALID.CERT.INVALID-FORMAT.CONFIG.TRUST-STORE-NOT-ICP-BRASIL.CONFIG.CERT-MIN-DATE-INVALID.CONFIG.CERT-MIN-DATE-OUT-OF-RANGE.CONFIG.BUNDLE-SIZE-LIMIT-OUT-OF-RANGE.CONFIG.BUNDLE-MEMORY-LIMIT-OUT-OF-RANGE.CONFIG.BUNDLE-TIMEOUT-OUT-OF-RANGE.MIDDLEWARE.TOKEN-LABEL-INVALID.CONFIG.MISSING-PARAMETER.FORMAT.BASE64-INVALID.MIDDLEWARE.LIBRARY-PATH-INVALID.MIDDLEWARE.LIBRARY-INVALID-FORMAT.MIDDLEWARE.LIBRARY-NOT-FOUND.MIDDLEWARE.SLOT-ID-INVALID.MIDDLEWARE.TOKEN-LABEL-INVALID.MIDDLEWARE.UNSUPPORTED-MECHANISMS.MIDDLEWARE.SESSION-MODE-INVALID.MIDDLEWARE.TIMEOUT-OUT-OF-RANGE.MIDDLEWARE.AUTH-ATTEMPTS-OUT-OF-RANGE.MIDDLEWARE.TIMEOUT-OUT-OF-RANGE.MIDDLEWARE.RETRY-CONFIG-INVALID.MIDDLEWARE.RETRY-CONFIG-INVALID.CONFIG.INVALID-PARAMETER ou MIDDLEWARE.INVALID-CONFIG especificando o parâmetro problemático.CONFIG.MISSING-PARAMETER.2.1 Obtenha a cadeia de certificados X.509 fornecida na entrada (item 4 das entradas).
2.2 Verifique se a cadeia possui pelo menos 2 certificados (signatário/folha + pelo menos um certificado adicional de uma AC). Se contiver menos de 2 certificados, retorne código CERT.CHAIN-INCOMPLETE.
2.3 Verifique o formato de cada certificado da cadeia de certificados:
FORMAT.BASE64-INVALID.CERT.INVALID-FORMAT.2.4 Validação da raiz ICP-Brasil:
CERT.NOT-ICP-BRASIL.2.5 Verificação de elegibilidade ICP-Brasil:
2.16.76.1 (raiz da árvore de políticas ICP-Brasil).CERT.NOT-ICP-BRASIL informando que o certificado não é elegível para assinatura digital avançada.2.6 Validação do certificado do signatário:
notBefore) é posterior ou igual à data mínima configurada. Se anterior, retorne código CERT.ISSUE-DATE-TOO-OLD.notBefore ≤ timestamp de referência ≤ notAfter. Se inválido, retorne código CERT.EXPIRED ou CERT.NOT-YET-VALID conforme aplicável.Nota
Certificados ICP-Brasil emitidos a partir da data mínima configurada garantem conformidade com as normas técnicas de segurança vigentes, incluindo algoritmos criptográficos e tamanhos de chave adequados aos padrões atuais. A data mínima padrão (1º julho 2025) reflete os requisitos de segurança desta versão da política de assinatura.
2.7 Validação da cadeia de certificados. Para cada certificado da cadeia na posição i (de 0 a n-2, onde n é o total de certificados):
2.7.1 Validação criptográfica:
i usando a chave pública do certificado i+1.CERT.CHAIN-VALIDATION-FAILED.2.7.2 Validação da hierarquia:
subject do certificado i+1 corresponde ao issuer do certificado i. Esta validação garante a continuidade da cadeia de confiança.CERT.CHAIN-VALIDATION-FAILED.2.7.3 Validação temporal:
notBefore ≤ timestamp de referência ≤ notAfter.notAfter, retorne código CERT.EXPIRED.notBefore, retorne código CERT.NOT-YET-VALID.2.8.4 Validação de revogação: Obtenha as configurações operacionais da entrada (item 8) para TTL de cache e timeouts. Se for empregado cache, consulte o cache antes da consulta online usando o TTL configurado.
REVOCATION.NO-DISTRIBUTION-POINTS. Não será utilizada nenhuma fonte alternativa para identificação de revogação.REVOCATION.OCSP-UNAVAILABLE ou REVOCATION.CRL-UNAVAILABLE.REVOCATION.NO-CONNECTIVITY.CERT.REVOKED com detalhes da fonte (OCSP/CRL).REVOCATION.RESPONSE-MALFORMED.CERT.REVOKED com detalhes.rRefs durante a etapa 12.2 ou 13.1.3.1 Identifique as instâncias a serem assinadas:
3.2 Crie uma cópia de cada instância a ser assinada: para cada instância recuperada na etapa anterior, crie uma cópia onde os elementos id, meta.versionId, meta.lastUpdated, meta.source e meta.tag são removidos (caso existam). Observe que a remoção não inclui os elementos meta.profile e meta.security. Todos os demais elementos na cópia devem ser rigorosamente idênticos àqueles da instância original.
3.3 A partir deste ponto, todas as operações subsequentes serão realizadas exclusivamente sobre estas cópias com a alteração realizada no item anterior. As instâncias originais não são mais utilizadas no processo de assinatura.
Nota
Os elementos id, meta.versionId, meta.lastUpdated, meta.source e meta.tag são ignorados no processo de geração e validação da assinatura. Isso significa que valores destes elementos podem ser alterados sem invalidar a assinatura ou afetar sua validação.
4.1 Para cada uma das cópias das instâncias a serem assinadas (obtidas na etapa 3), aplique o processo de canonicalização JSON conforme especificado na RFC 8785 (JSON Canonicalization Scheme - JCS).
4.2 A canonicalização produz uma representação padronizada e determinística de cada instância JSON, eliminando variações irrelevantes da representação como:
4.3 O resultado da canonicalização para cada instância é uma sequência de bytes UTF-8 que representa de forma única e determinística o conteúdo da instância, independentemente de como o JSON original foi formatado.
4.4 Mantenha a ordem das instâncias canonicalizadas conforme definido pelas referências em Provenance.target.
5.1 Obtenha as sequências de bytes UTF-8 canonicalizadas de cada instância (resultado da etapa 4).
5.2 Concatene as sequências de bytes das instâncias canonicalizadas na ordem exata definida pelas referências em Provenance.target. A concatenação deve ser realizada byte a byte, sem separadores, delimitadores ou caracteres adicionais entre as instâncias.
5.3 Calcule o hash SHA-256 da sequência de bytes resultante da concatenação. O resultado será uma sequência de 32 bytes (256 bits) que representa a impressão digital única do conjunto de instâncias assinadas.
5.4 Esta impressão digital garante a integridade do conjunto de dados: qualquer alteração em qualquer uma das instâncias ou mudança na ordem resultará em um hash completamente diferente.
Nota
A ordem de concatenação é crucial para a integridade da assinatura. A mesma ordem definida em Provenance.target deve ser preservada em todas as etapas.
6.1 Obtenha a impressão digital SHA-256 (sequência de 32 bytes) produzida na etapa 5.
6.2 Aplique a codificação base64Url à sequência de bytes do hash SHA-256.
6.3 O resultado será uma sequência de exatamente 43 caracteres (não 44 como no formato base64 padrão, pois o base64Url remove o padding).
6.4 Esta sequência de 43 caracteres base64Url representa de forma compacta a impressão digital do conjunto de instâncias assinadas, adequada para uso em estruturas JWS.
Nota
A codificação base64Url é especificada na RFC 4648 seção 5 e é o padrão para uso em JWS/JWT conforme RFC 7515.
7.1 Crie um objeto JSON que servirá como protected header do JWS JSON Serialization contendo as seguintes propriedades obrigatórias: alg, x5c e sigPId. A propriedade iat depende da estratégia de indicação do instante de tempo (entrada 5). Estas propriedades e os valores admitidos são documentados nesta seção.
7.2 Defina a propriedade alg (algoritmo de assinatura):
RS256 para chaves RSA (RSA com SHA-256).ES256 para chaves ECC (ECDSA com SHA-256).CERT.WEAK-KEY.CERT.UNSUPPORTED-ALGORITHM.Nota:
O algoritmo de assinatura e o tamanho da chave devem estar de acordo com as normas técnicas vigentes da ICP-Brasil e com a política de assinatura digital vigente.
7.3 Defina a propriedade x5c com o valor da cadeia de certificados fornecida na entrada (item 4 das entradas).
7.4 Se a estratégia para indicação do instante de tempo (entrada 5) é para o instante auto-declarado, então defina a propriedade iat com o valor fornecido na entrada 7 (instante auto-declarado) se e somente se:
iat deve ser maior ou igual ao notBefore do certificado folha (data de início da validade).iat deve ser menor ou igual ao notAfter do certificado folha (data de expiração).iat estiver fora do intervalo de validade do certificado folha, o certificado do signatário, retorne OperationOutcome com código TEMPORAL.IAT-OUT-OF-CERT-PERIOD.Nota
Estratégia iat: timestamp auto-declarado pelo signatário, limitado ao período de validade do certificado. Mitiga riscos de backdating e uso de certificados expirados, mas baseado na confiança no signatário.
Estratégia tsa: Carimbo de tempo fornecido por TSA externa. Inclui prova verificável do momento da assinatura através de terceira parte confiável. A propriedade sigTst será inserida no unprotected header durante a etapa 12.2.
7.5 Defina a propriedade sigPId (Signature Policy Identifier):
{"id": "https://fhir.saude.go.gov.br/r4/seguranca/ImplementationGuide/br.go.ses.seguranca|0.0.2"}.Nota
Este atributo identifica unicamente a política de assinatura vigente no momento da geração, permitindo que cada assinatura seja validada conforme as regras específicas da versão da política utilizada. Garante rastreabilidade e evolução normativa do guia.
7.6 Codifique o objeto JSON do protected header em base64Url:
iat: o protected header deve conter {"alg": "RS256|ES256", "x5c": [...], "iat": timestamp, "sigPId": {"id": "URI"}}.tsa: o protected header deve conter {"alg": "RS256|ES256", "x5c": [...], "sigPId": {"id": "URI"}}.Nota
As propriedades alg e x5c são definidas no padrão JWS (RFC 7515) e utilizadas pelo JAdES. As propriedades sigPId e iat são definidas pelo padrão JAdES (JSON Advanced Electronic Signatures). O iat especifica o tempo alegado pelo signatário para a execução do processo de assinatura. O sigTst (quando presente) é colocado no unprotected header e contém o timestamp criptográfico verificável fornecido por uma TSA (Timestamping Authority). Consulte seção 12.2 para detalhes.
8.1 Obtenha a sequência de caracteres base64Url produzida na etapa 6 (impressão digital SHA-256 codificada em base64Url).
8.2 Use diretamente esta sequência de caracteres base64Url como payload do JWS. Não aplique uma nova codificação base64Url, pois o conteúdo já está no formato correto.
8.3 O payload final é exatamente a string base64Url de 43 caracteres obtida na etapa 6, sem modificações adicionais.
8.4 Este payload representa a impressão digital do conteúdo assinado, pronta para ser utilizada na construção do JWS.
Nota
A assinatura é produzida para o valor de hash do conteúdo original. O conteúdo original não acompanha a assinatura JWS - apenas seu hash está presente no payload. Isso permite que a assinatura seja gerada e verificada sem transmitir o conteúdo completo, mas exige que o conteúdo original seja preservado separadamente para permitir a validação posterior.
9.1 Obtenha o protected header base64Url produzido na etapa 7.6 e o payload base64Url da etapa 8.
9.2 Crie a string de assinatura (signing input):
protected_header.payload (note o ponto . como separador obrigatório).eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJqb2UifQ.9.3 Codifique a string de assinatura em UTF-8:
protected_header.payload deve ser codificada usando a codificação UTF-8.10.1 Carregue os bytes produzidos na etapa 9.3 para a criação da assinatura JWS.
10.2 Determine o algoritmo de assinatura:
10.3 Acesse a chave privada conforme o tipo fornecido na entrada (item 3 das entradas):
DEVICE.CERTIFICATE-NOT-FOUND.DEVICE.KEY-ACCESS-DENIED.CRYPTO.PIN-INVALID após o número máximo de tentativas configurado (entrada 8). Se o dispositivo estiver bloqueado, retornar CRYPTO.DEVICE-BLOCKED. Se a chave não puder ser acessada, retornar CRYPTO.KEY-INACCESSIBLE.10.4 Execute a operação criptográfica:
10.5 Codifique a sequência de bytes da assinatura digital obtida no passo 10.4 na base64Url. O valor codificado é a assinatura JWS.
Nota
RS256 e ES256 são algoritmos aprovados pela ICP-Brasil e atendem aos requisitos de segurança.
11.1 Crie a estrutura JWS JSON preliminar:
Esta seção é exclusiva para o cenário em que a estratégia para indicação do instante de tempo em que a assinatura é gerada deve usar carimbo de tempo (tsa) conforme a entrada (item 5). Se a estratégia, conforme a entrada é iat, então prossiga diretamente para a seção 13, neste caso, nenhuma ação da seção 12 será realizada.
12.1 Solicite carimbo de tempo da TSA:
TSA.UNAVAILABLE.TSA.INVALID-RESPONSE.TSA.VALIDATION-FAILED.TEMPORAL.TSA-TIMESTAMP-OUT-OF-BOUNDS.12.2 Crie o unprotected header com carimbo de tempo TSA e evidências LTV:
"http://www.w3.org/2001/04/xmlenc#sha512""http://www.w3.org/2001/04/xmlenc#sha512"{"sigTst": "token_tsa_base64", "rRefs": {"ocspRefs": [{"digestAlg": "http://www.w3.org/2001/04/xmlenc#sha512", "digestValue": "hash_base64"}], "crlRefs": [{"digestAlg": "http://www.w3.org/2001/04/xmlenc#sha512", "digestValue": "hash_base64"}]}}.Nota
Para estratégia tsa, o carimbo de tempo é aplicado à assinatura criptográfica, garantindo prova verificável do momento em que a assinatura foi gerada. O uso de unprotected header permite adicionar o carimbo de tempo TSA e as evidências de revogação LTV sem invalidar a assinatura criptográfica já criada, conforme especificação JAdES.
Nota A ação 12.2 armazena a CRL/OCSP para cada assinatura, o que pode ser oneroso em termos de espaço de armazenamento.
13.1 Finalize a estrutura JWS JSON conforme a estratégia de timestamp:
Para estratégia iat:
"http://www.w3.org/2001/04/xmlenc#sha512""http://www.w3.org/2001/04/xmlenc#sha512"{"rRefs": {"ocspRefs": [{"digestAlg": "http://www.w3.org/2001/04/xmlenc#sha512", "digestValue": "hash_base64"}], "crlRefs": [{"digestAlg": "http://www.w3.org/2001/04/xmlenc#sha512", "digestValue": "hash_base64"}]}}.header no elemento signatures[0].Para estratégia tsa:
sigTst e rRefs).header contendo o objeto JSON no elemento signatures[0].13.2 Serialize a estrutura JSON final:
Estruturas resultantes:
Para estratégia iat (exemplo com ambas as evidências disponíveis):
{
"payload": "payload_base64url",
"signatures": [
{
"protected": "protected_header_base64url",
"header": {
"rRefs": {
"ocspRefs": [
{
"digestAlg": "http://www.w3.org/2001/04/xmlenc#sha512",
"digestValue": "3mK8xVeRjP7nQw9mF2kLqX1z5vH8tN4sE7dU6oC9bA2yI0rM5jL3xW8kQ7vP1nZ4fG6hJ9sT2eR5uY0aS3iO8"
}
],
"crlRefs": [
{
"digestAlg": "http://www.w3.org/2001/04/xmlenc#sha512",
"digestValue": "7qZ9mL2xV5eP8nR3fK6jH4tS1oC0bA9yI7rM8xW2kQ4vP6nZ5fG1hJ0sT9eR8uY3aS2iO7dU5oC6bA3yI4rM1"
}
]
}
},
"signature": "signature_base64url"
}
]
}
Para estratégia tsa (exemplo com apenas OCSP disponível):
{
"payload": "payload_base64url",
"signatures": [
{
"protected": "protected_header_base64url",
"header": {
"sigTst": "token_tsa_base64",
"rRefs": {
"ocspRefs": [
{
"digestAlg": "http://www.w3.org/2001/04/xmlenc#sha512",
"digestValue": "9sL4xW2eQ8pN7fM5kJ3hG6tR0oD1cB8yI5rP9xV4kL7vN2nX6fH3hK0sU8eT9uY1aQ4iP7dV5oD6cB3yJ4sM2"
}
]
}
},
"signature": "signature_base64url"
}
]
}
Nota sobre evidências de revogação
As evidências LTV em rRefs incluem apenas os tipos de evidência disponíveis conforme determinado na etapa 2.8.4:
ocspRefscrlRefsocspRefs e crlRefsdigestValue contêm hashes SHA-512 reais das evidências DER codificados em base64 (88 caracteres)Nota
A estrutura JWS criada nas etapas anteriores atende aos requisitos de conformidade JAdES (JSON Advanced Electronic Signatures). Os elementos obrigatórios alg, x5c, sigPId no protected header (etapa 7), as evidências LTV rRefs no unprotected header (etapas 12.2/13.1), e o carimbo de tempo sigTst quando aplicável (etapa 12.2) garantem plena conformidade com a especificação JAdES para assinaturas digitais avançadas.
14.1 Serialize o JWS JSON para o formato FHIR Signature:
14.2 Extraia metadados do certificado digital:
2.16.76.1.3.3 (CNPJ da pessoa jurídica titular do certificado).2.16.76.1.3.1 (CPF da pessoa física titular do certificado).CERT.MISSING-IDENTIFICATION.14.3 Instancie o tipo de dados Signature conforme especificação FHIR R4:
Signature.data (obrigatório): valor base64 da string JWS produzida na etapa 14.1.
Signature.sigFormat (obrigatório): application/jose - identifica o formato JWS/JAdES.
Signature.targetFormat (obrigatório): application/octet-stream - especifica que o conteúdo efetivamente assinado são bytes de hash SHA-256, não os dados FHIR JSON originais dos quais o hash foi obtido.
urn:iso-astm:E1762-95:2013.1.2.840.10065.1.12.1.1 para assinatura de autoria (autor do conteúdo).1.2.840.10065.1.12.1.6 para assinatura de validação/aprovação.Reference.identifier para identificação por CNPJ/CPF.{"identifier": {"system": "urn:brasil:cnpj|urn:brasil:cpf", "value": "documento"}}.14.4 Verificação da instância criada:
Signature.data contém uma string base64 válida.Signature.who.identifier corresponde ao certificado utilizado.Nota
O encapsulamento transforma a assinatura JWS JSON Serialization (formato JSON RFC 7515 seção 3.2) para o tipo de dados FHIR Signature, preservando toda a informação criptográfica dentro do elemento data enquanto fornece metadados estruturados nos demais elementos para interoperabilidade no ecossistema FHIR.
Nota
O targetFormat especifica o formato do conteúdo que foi efetivamente submetido à operação criptográfica de assinatura. Neste caso, são os bytes do hash SHA-256 (application/octet-stream), não os dados FHIR JSON originais. Os dados FHIR JSON são o conteúdo semântico preservado para validação, mas o target criptográfico é sua impressão digital SHA-256.
Nota
As evidências LTV (Long Term Validation) incluídas no unprotected header JWS (rRefs) garantem que a assinatura possa ser validada no futuro, mesmo quando os serviços OCSP/CRL originais não estiverem mais disponíveis. Estas evidências seguem o padrão JAdES e contêm provas criptográficas do status de revogação dos certificados no momento da criação da assinatura.
Nota
Esta etapa conclui o processo de criação da assinatura digital. A instância Signature resultante contém toda a informação necessária para validação posterior e deve ser tratada como um artefato criptográfico íntegro.
O processo de criação de assinatura digital é determinístico e livre de efeitos colaterais (side-effect free) para um determinado contexto temporal. Isso significa que:
Não modifica nenhuma das instâncias fornecidas como entrada (Bundle, Provenance, certificados).
Produz resultado consistente quando executado com as mesmas entradas no mesmo contexto temporal.
Retorna como saída principal uma instância do tipo de dados Signature (em caso de sucesso) ou uma instância de OperationOutcome (em caso de falha).
Produz registros de auditoria conforme especificado no caso de uso de auditoria, independentemente do resultado da operação.
O processo não é idempotente no sentido clássico, pois depende de fatores temporais implícitos:
notBefore ≤ timestamp de referência ≤ notAfter) baseadas no timestamp fornecido na entrada.tsa, a disponibilidade da autoridade de carimbo de tempo.Executar o mesmo processo com as mesmas entradas explícitas em momentos diferentes pode produzir:
CERT.EXPIRED, CERT.REVOKED, TSA.UNAVAILABLE.iat, reflete o instante fornecido na entrada.A validação é tratada em caso de uso próprio. Adicionalmente, a expectativa é que o próprio signatário, ao produzir uma assinatura, faça a validação correspondente conforme esse caso de uso. Desta forma, garantindo que toda a cadeia de certificados será verificada, dentre outras operações. Naturalmente, o próprio signatário deveria evitar o uso de um certificado expirado ou regovado, ao produzir uma assinatura.