RETIFICADA EM 16/01/2009
INSTITUTO NACIONAL DE TECNOLOGIA DA INFORMAÇÃO
INSTRUÇÃO NORMATIVA Nº 03, DE 09 DE JANEIRO DE 2009
Aprova a versão 1.0 dos REQUISITOS MÍNIMOS PARA
POLÍTICAS DE ASSINATURA DIGITAL NA ICP-
BRASIL.
O DIRETOR-PRESIDENTE DO INSTITUTO NACIONAL DE TECNOLOGIA DA
INFORMAÇÃO, no uso das atribuições que lhe foram conferidas pelo inciso I, do art. 1º, do anexo
I, do Decreto nº 4.689, de 7 de maio de 2003, e pelo art. 1º da Resolução nº 33 do Comitê Gestor da
ICP-Brasil, de 21 de outubro de 2004;
R E S O L V E :
Art. 1º Fica aprovada a versão 1.0 do documento REQUISITOS MÍNIMOS PARA POLÍTICAS
DE ASSINATURA DIGITAL NA (DOC-ICP-15.03), em anexo.
Art. 2º Esta Instrução Normativa entra em vigor na data de sua publicação.
RENATO DA SILVEIRA MARTINI
ANEXO
REQUISITOS MÍNIMOS PARAPOLÍTICAS DE ASSINATURA DIGITAL
NA ICP-BRASIL
DOC-ICP-15.03
Versão 1.0
1 INFORMAÇÕES GERAIS
1.1 Este documento estabelece os requisitos mínimos a serem obrigatoriamente observados pelas
entidades criadoras de Políticas de Assinatura Digital no âmbito da Infra-Estrutura de Chaves
Públicas Brasileira – ICP-Brasil, em conformidade com a estrutura proposta pelos padrões ETSI TR
102 272 [6] e ETSI TR 102.038 [9].
1.2 Ele faz parte de um conjunto de normativos criados para regulamentar a geração e verificação
de assinaturas digitais no âmbito da Infra-estrutura de Chaves Públicas Brasileira -ICP-Brasil. Tal
conjunto se compõe de:
a) ASSINATURAS DIGITAIS NA ICP-BRASIL – DOC-ICP-15;
REVOGADA
b) REQUISITOS TÉCNICOS PARA GERAÇÃO E VERFICAÇÃO DE ASSINATURAS
DIGITAIS NA ICP-BRASIL – DOC-ICP-15.01;
c) PERFIL DE USO GERAL PARA ASSINATURAS ICP-BRASIL – DOC-ICP-15.02;
d) REQUISITOS MÍNIMOS PARA AS POLÍTICAS DE ASSINATURA NA ICP-BRASIL
– DOC-ICP-15.03 (este documento).
1.3 Toda Política de Assinatura elaborada no âmbito da ICP-Brasil DEVE adotar a mesma sintaxe
de estrutura empregada neste documento.
1.4 Esta estrutura prevê a criação de uma única assinatura digital (também conhecida como
assinatura digital simples ou primária), a criação de assinaturas digitais em paralelo (também
conhecidas como co-assinaturas) ou a criação de assinaturas digitais em série (também conhecidas
como contra-assinaturas).
1.5 As Políticas de Assinatura Aprovadas ICP-Brasil DEVEM ser escritas de uma forma inteligível
por seres humanos e; opcionalmente, PODEM ser escritas de uma forma inteligível por sistemas de
processamento.
1.6 No caso de políticas que sejam escritas com base no presente documento, a forma inteligível por
sistemas de processamento DEVE ser ASN.1 ou XML.
1.7 Antes de entrar em utilização, uma Política de Assinatura criada no âmbito da ICP-Brasil DEVE
ser submetida à AC-Raiz para fins de obtenção de um identificador único (Object Identifier), que a
diferencie de outras políticas e permita seu correto processamento pelos sistemas. Após esse proce-
dimento, a política será reconhecida como Política de Assinatura Aprovada ICP-Brasil.
1.8 As Políticas de Assinatura Aprovadas ICP-Brasil são protegidas contra alterações indevidas por
meio da publicação, no repositório da AC Raiz, de seu conteúdo assinado digitalmente por chave
privada associada a certificado digital do Instituto Nacional de Tecnologia da Informação (ITI).
1.9 Para facilitar a utilização de políticas de assinatura pelos usuários finais, o ITI criou 10 Políticas
de Assinatura-padrão, que estão detalhadas no Anexo 1 neste documento.
1.10 O processo de gerenciamento das Políticas de Assinatura pela AC Raiz da ICP-Brasil está
descrito no Anexo 2 deste documento.
1.1 TERMINOLOGIA
Os termos abaixo, quando encontrados ao longo deste documento grafados em maiúsculas, DEVEM
ser interpretados conforme descrito neste item:
1.1.1 DEVE (D) - Esta palavra, ou os termos "EXIGIDO" ou "OBRIGATÓRIO, significa que a
definição é um requisito absoluto da especificação.
1.1.2 NÃO DEVE (ND) - Esta expressão, ou o termo “PROIBIDO¨ significa que a definição é
uma proibição absoluta na especificação.
1.1.3 É RECOMENDADO (R) - Esta expressão, ou o adjetivo "RECOMENDADO", significa
que podem existir razões válidas, em circunstâncias particulares, para ignorar um ponto específico,
mas as implicações completas precisam ser entendidas e ponderadas cuidadosamente antes de esco-
lher um caminho diferente.
1.1.4 NÃO É RECOMENDADO (NR) - Esta expressão significa que podem existir razões
válidas, em circunstâncias particulares, em que o comportamento possa ser aceitável ou mesmo útil,
mas as implicações completas devem ser entendidas e ponderadas cuidadosamente, antes de se rea-
lizar qualquer comportamento descrito com este rótulo.
1.1.5 PODE (P) - Esta palavra, ou o adjetivo "OPCIONAL", significa que é um item verdadei-
ramente opcional. Um implementador pode optar por incluir o item, enquanto outro pode omitir o
mesmo item. Uma aplicação que não inclui uma determinada opção DEVE estar preparada para in-
teroperar com outra aplicação que inclui aquela opção, embora talvez com funcionalidade reduzida.
No mesmo espírito, uma aplicação que inclui uma determinada opção DEVE estar preparada para
interoperar com outra aplicação que não a inclui (exceto, é claro, para o recurso que a opção ofere-
ce.)
2. CONTEÚDO DA POLÍTICA DE ASSINATURA
Os itens a seguir relacionam os conteúdos que DEVEM, obrigatoriamente, fazer parte de uma
Política de Assinatura Aprovada ICP-Brasil
2.1 Identificador da Política de Assinatura
2.1.1 Neste item DEVE ser identificada a Política de Assinatura e indicado o seu OID (Object
Identifier).
2.1.2 No âmbito da ICP-Brasil, será atribuído um OID à Política de Assinatura na conclusão do
processo de aprovação por parte ITI, o qual terá o formato 2.16.76.1.7.n.o.p, onde:
n: valor atribuído à entidade que solicita a aprovação da Política de Assinatura;
o: valor atribuído seqüencialmente às Políticas de Assinatura da entidade solicitante;
p: versão da Política de Assinatura Aprovada.
2.1.3 Toda Política de Assinatura Aprovada ICP-Brasil DEVE estar disponível publicamente a
todos interessados. Neste item DEVE ser indicada a URL onde a Política de Assinatura PODE ser
consultada.
2.1.4 Neste item DEVE ser mencionado que as Políticas de Assinatura Aprovadas estarâo
disponíveis para consulta também no repositório da AC-Raiz.
2.2 Data da Criação
Neste item DEVE ser informada a data de criação da Política de Assinatura.
2.3 Entidade Criadora da Política de Assinatura
Este item DEVE conter uma identificação da entidade responsável pela criação da Política de
Assinatura e da comunidade que fará uso dela. No âmbito da ICP-Brasil, qualquer entidade (pessoa
física ou jurídica, órgão de governo etc.) PODE criar Políticas de Assinatura, conforme sua
necessidade e conveniência.
2.4 Campo de Aplicação
2.4.1 Neste item DEVE ser definido, em termos gerais, o campo de aplicação da assinatura digital
gerada conforme a Política de Assinatura, bem como os propósitos específicos para os quais a
assinatura digital é aplicável.
2.4.2 Deverão estar relacionadas, quando cabível, as aplicações para as quais existam restrições ou
proibições para o uso da PA.
2.5 Política de Validação da Assinatura
O campo Política de Validação estabelece as regras gerais e específicas aplicadas à Assinatura
Digital e que DEVEM ser observadas pelo assinante e pelo verificador da assinatura.
2.5.1 Período para Assinatura
2.5.1.1 Deve ser definido o período de validade (data e hora) inicial e final de abrangência das
regras definidas na Política de Assinatura aplicáveis às assinaturas digitais que se utilizarem da
Política.
2.5.1.2 O período de validade máximo admitido para uma Política de Assinatura no âmbito da ICP-
Brasil é de 05 (cinco) anos.
2.5.2 Regras Comuns
Este campo define as regras comuns e gerais, tanto para o processo de assinatura pelo signatário,
quanto para o processo de verificação pelo verificador.
Se um campo estiver presente nas Regras Comuns então ele NÃO DEVERÁ estar presente em
nenhum campo de Regras para Propósitos Específicos de Assinatura.
2.5.2.1 Regras do Signatário e do Verificador
2.5.2.1.1 Regras do Signatário
Este campo define as regras que DEVEM ser observadas e incluídas no pacote da assinatura pelo
signatário, no momento da assinatura digital do documento eletrônico. Todas as assinaturas geradas
segundo uma Política de Assinatura Aprovada ICP-Brasil DEVEM estar em conformidade com o
disposto no DOC-ICP-15.01, capítulo 4.
OBS.: Permite-se, adicionalmente, o uso de qualquer dos atributos e propriedades previstos nos
padrões CMS, CAdES, XMLDSIG e XAdES, definidos respectivamente na RFC 3852 [14], no
documento ETSI TR 102733 [7], na RFC 3275 [15] e no documento ETSI TS 102903 [10].
2.5.2.1.1.1 Dados Externos ou Internos a Assinatura
Neste item DEVE ser descrito se existe ou não a obrigatoriedade de inclusão do conteúdo assinado
(documento eletrônico) na assinatura digital.
No caso de o conteúdo não ser incluído, ou seja, se ele ficar externo ao pacote de assinatura digital,
DEVE ser descrita a forma de obter o conteúdo para verificação da assinatura.
2.5.2.1.1.2 Atributos ou Propriedades Assinados Obrigatórios
2.5.2.1.1.2.1 Neste item DEVEM ser relacionados os atributos ou propriedades que DEVEM
constar, obrigatoriamente, no pacote da assinatura digital no âmbito desta Política de Assinatura e
que são assinados juntamente com o documento eletrônico.
2.5.2.1.1.2.2 O documento DOC-ICP-15.01, capítulo 4, define os atributos ou propriedades
obrigatórios, para todos os formatos de assinatura digital ICP-Brasil.
2.5.2.1.1.3 Atributos ou Propriedades Não-Assinados Obrigatórios
2.5.2.1.1.3.1 Neste item DEVEM ser relacionados os atributos ou propriedades que DEVEM
constar, obrigatoriamente, no pacote da assinatura digital no âmbito desta Política de Assinatura, e
que não são assinados juntamente com o documento eletrônico.
2.5.2.1.1.3.2 O documento DOC-ICP-15.01, capítulo 4, define, os atributos ou propriedades
obrigatórios, para todos os formatos de assinatura digital ICP-Brasil.
2.5.2.1.1.3.3 A inclusão desses atributos ou propriedades não assinados PODE, opcionalmente, ser
realizada pelo verificador ao invés do signatário. Nestes casos DEVEM ser informados neste item
apenas os atributos que DEVEM ser incluídos pelo signatário. Os que DEVEM ser incluídos pelo
verificador DEVEM ser relacionados no item 2.5.2.1.2.1.
2.5.2.1.1.4 Referências à Cadeia de Certificação
2.5.2.1.1.4.1 Neste item DEVE ser descrito que todas as assinaturas digitais criadas com base nesta
Política de Assinatura DEVEM conter obrigatoriamente a referência ao certificado do signatário,
por meio do identificador Serial do Emissor.
2.5.2.1.1.5 Valores da Cadeia de Certificação
2.5.2.1.1.5.1 Neste item DEVE ser descrito se as assinaturas digitais criadas com base nesta Política
de Assinatura devem ou não conter, obrigatoriamente, os certificados do signatário bem como todos
os certificados da cadeia de certificação.
2.5.2.1.1.5.3 Caso o verificador possa encontrar um ou mais certificados da cadeia de certificação
através de alguma outra forma, PODE ser incluído na assinatura digital apenas o certificado do
signatário ou até mesmo nenhum dos certificados. Nestes casos, DEVE ser descrito de que forma os
certificados estarão disponíveis e podem ser utilizados para a verificação da assinatura.
2.5.2.1.1.6 Regras Adicionais do Signatário
Caso haja a necessidade de incluir regras adicionais relacionadas ao processo de Assinatura Digital
executado pelo signatário, estas DEVEM ser incluídas neste item.
2.5.2.1.2 Regras do Verificador
Este item descreve as regras de validação da Assinatura Digital, aplicáveis a atributos ou
propriedades não incluídos pelo signatário no momento da assinatura, os quais DEVEM então ser
incluídos pelo verificador.
2.5.2.1.2.1 Atributos Não-Assinados Obrigatórios
Este item DEVE conter obrigatoriamente os atributos descritos no item 2.5.2.1.1.3 que não são
incluídos pelo signatário.
2.5.2.1.2.2 Regras Adicionais do Verificador
Caso haja a necessidade de regras adicionais relacionadas ao verificador, essas DEVEM ser
incluídas neste item.
2.5.2.2 Condições de Confiabilidade dos Certificados dos Signatários
2.5.2.2.1 Validação da Cadeia de Certificação
Neste item DEVE constar que o processo de validação dos certificados da cadeia de certificação do
signatário DEVE ser realizado em conformidade com a RFC 3280 e com o disposto nesta Política
de Assinatura.
2.5.2.2.1.1 Raiz Confiável
Neste item DEVE constar que a validação DEVE ser feita tomando como ponto de confiança o
certificado da AC-Raiz da ICP-Brasil, que se encontra disponível em
http://acraiz.icpbrasil.gov.br/CertificadoACRaiz.crt.
2.5.2.2.1.2 Restrição do Caminho de Certificação
Neste item DEVE constar que o número máximo de certificados de AC, no caminho de certificação
entre o certificado do signatário e o da AC-Raiz é 2 (dois).
2.5.2.2.1.3 Conjunto de Políticas de Certificação Aceitáveis
Neste item DEVEM constar os tipos de certificados ICP-Brasil, cujas chaves privadas associadas
PODEM gerar assinaturas digitais segundo a Política de Assinatura. Entre os tipos aceitáveis, tem-
se:
T
i
p
o
d
e
C
e
r
t
i
f
i
c
a
d
o
O
I
D
A
1
2
.
1
6
.
7
6
.
1
.
2
.
1
.
n
A
2
2
.
1
6
.
7
6
.
1
.
2
.
2
.
n
A
3
2
.
1
6
.
7
6
.
1
.
2
.
3
.
n
A
4
2
.
1
6
.
7
6
.
1
.
2
.
4
.
n
2.5.2.2.1.4 Restrições de Nome
Neste item, caso existam, DEVEM constar os nomes (Subject Distinguished Name e/ou Subject
Alternative Name) para os quais os certificados DEVEM ser rejeitados.
2.5.2.2.1.5 Restrições de Políticas (Aceitável e Não-Aceitáveis)
2.5.2.2.1.5.1 Neste item PODEM constar os indicadores relativos às Políticas de Certificado
permitidas para garantir a aceitação dos certificados da cadeia de certificação. Opcionalmente
PODEM ser definidos os certificados da cadeia que DEVEM ter suas Políticas verificadas.
2.5.2.2.1.5.2 Caso existam, também PODEM constar os indicadores relativos às Políticas de
Certificado correspondentes aos certificados que DEVEM ser rejeitados. Opcionalmente PODEM
ser definidos os certificados da cadeia que DEVEM ter suas Políticas verificadas.
2.5.2.2.2 Forma de Verificação do Estado da Cadeia de Certificação
2.5.2.2.2.1 Neste item DEVE constar que é obrigatória a verificação do estado do certificado do
signatário. Deve ser especificado o método a ser utilizado para essa verificação.
2.5.2.2.2.2 Também DEVE constar que é obrigatória a verificação do estado dos certificados das
Autoridades Certificadoras da cadeia de certificação do signatário. Deve ser especificado o método
a ser utilizado para essa verificação.
2.5.2.2.2.3 Entre os métodos de verificação de estado estão a consulta a LCR (Lista de Certificados
Revogados) em conformidade com a RFC 3280, a consulta OCSP (Online Certificate Status
Protocol) em conformidade com a RFC 2560 ou algum outro método aprovado pela ICP-Brasil.
2.5.2.3 Condições de Confiabilidade do Carimbo de Tempo
NOTA: Este item não se aplica a assinaturas formato EPES
2.5.2.3.1 Validação da Cadeia de Certificação
Neste item DEVE constar que o processo de validação dos certificados da cadeia de certificação da
Autoridade de Carimbo de Tempo DEVE ser realizado em conformidade com a RFC 3280 e com o
disposto nesta Política de Assinatura.
2.5.2.3.1.1 Raiz Confiável
Neste item DEVE constar que a validação DEVE ser feita tomando como ponto de confiança o
certificado da AC-Raiz da ICP-Brasil, que se encontra disponível em
http://acraiz.icpbrasil.gov.br/CertificadoACRaiz.crt
2.5.2.3.1.2 Restrição do Caminho de Certificação
Neste item DEVE constar o tamanho máximo do caminho de certificação, ou seja, número de
Autoridades Certificadoras entre a Raiz confiável e o certificado da Autoridade de Carimbo de
Tempo. No caso da ICP-Brasil, o máximo é 2 (dois).
2.5.2.3.1.3 Conjunto de Políticas de Certificação Aceitáveis
Neste item DEVEM constar os tipos de certificados ICP-Brasil, cujas chaves privadas associadas
PODEM gerar carimbos de tempo, aceitos segundo esta Política de Assinatura. Entre os tipos
aceitáveis tem-se:
T
i
p
o
d
e
C
e
r
t
i
f
i
c
a
d
o
O
I
D
T
3
2
.
1
6
.
7
6
.
1
.
2
.
3
0
3
.
n
T
4
2
.
1
6
.
7
6
.
1
.
2
.
3
0
4
.
n
2.5.2.3.1.4 Restrições de Nome
Neste item, caso existam, DEVEM constar os nomes (Subject Distinguished Name e/ou Subject
Alternative Name) para os quais os certificados DEVEM ser rejeitados.
2.5.2.3.1.5 Restrições de Políticas (Aceitável e Não-Aceitáveis)
2.5.2.2.3.1.5.1 Neste item PODEM constar os indicadores relativos as Políticas de Certificado
permitidos para garantir a aceitação dos certificados da cadeia de certificação da Autoridade de
Carimbo de Tempo. Opcionalmente PODEM ser definidos os certificados dessa cadeia de
certificação que DEVEM ter suas Políticas verificadas.
2.5.2.2.3.1.5.2 Caso existam, também PODEM constar os indicadores relativos as Políticas de
Certificado correspondentes aos certificados que DEVEM ser rejeitados. Opcionalmente PODEM
ser definidos os certificados da cadeia que DEVEM ter suas Políticas verificadas.
2.5.2.3.2 Forma de Verificação do Estado da Cadeia de Certificação
2.5.2.3.2.1 Neste item DEVE constar que é obrigatória a verificação do estado do certificado da
Autoridade de Carimbo de Tempo. Deve ser especificado o método a ser utilizado para essa
verificação.
2.5.2.3.2.2 Também DEVE constar que é obrigatória a verificação do estado dos certificados das
Autoridades Certificadoras da cadeia de certificação da Autoridade de Carimbo de Tempo. Deve ser
especificado o método a ser utilizado para essa verificação
2.5.2.3.2.3 Entre os métodos de verificação de estado estão a consulta a LCR (Lista de Certificados
Revogados) em conformidade com a RFC 3280, a consulta OCSP (Online Certificate Status
Protocol) em conformidade com a RFC 2560 ou algum outro método aprovado pela ICP-Brasil.
2.5.2.3.3 Restrições de Nome
Neste item, caso existam, DEVEM constar as restrições dos nomes (Subject Distinguished Name e/
ou Subject Alternative Name) aceitos para as Autoridades de Carimbo de Tempo que PODEM atuar
como tal no âmbito desta Política de Assinatura.
2.5.2.3.4 Período de Cautela
Opcionalmente, PODE ser informado neste item o período de tempo necessário após a data e hora
do atributo assinado “Signing Time” para que seja realizada a validação da assinatura digital.
2.5.2.3.5 Atraso do Carimbo de Tempo
Nos casos de assinaturas digitais que incluem o atributo assinado “Signing Time”, opcionalmente
PODE ser definido um período de tempo máximo permitido entre a data e hora do atributo assinado
e a data e hora do carimbo de tempo. Este item determina o período de latência de data e hora entre
a data e hora da máquina onde foi realizada a assinatura e a data e hora oficial dada pela ACT.
2.5.2.4 Condições de Confiabilidade dos Atributos
2.5.2.4.1 Atributos Obrigatórios
Item não aplicável.
2.5.2.4.2 Atributos Exigidos
Item não aplicável.
2.5.2.4.3 Validação da Cadeia de Certificação
2.5.2.4.3.1 Raiz Confiável
Item não aplicável.
2.5.2.4.3.2 Restrição do Caminho de Certificação
Item não aplicável.
2.5.2.4.3.3 Conjunto de Políticas de Certificação Aceitáveis
Item não aplicável.
2.5.2.4.3.4 Restrições de Nome
Item não aplicável.
2.5.2.4.3.5 Restrições de Políticas (Aceitável e Não-Aceitáveis)
Item não aplicável.
2.5.2.4.4 Forma de Verificação do Estado da Cadeia de Certificação
Item não aplicável.
2.5.2.4.5 Restrições de Atributos
Item não aplicável.
2.5.2.5 Conjunto de Restrições de Algoritmos
2.5.2.5.1 Caso existam restrições quanto aos algoritmos e tamanhos de chaves, associados a
assinatura digital e às entidades que têm algum tipo de participação na assinatura digital, aceitos no
âmbito desta Política de Assinatura, essas DEVEM ser descritas neste item.
2.5.2.5.2 Podem ser incluídas restrições de aceitação do algoritmo utilizado pelo signatário para a
realização da assinatura digital, do algoritmo do usado para assinar o certificado do signatário, dos
certificados das Autoridades Certificadoras que compõe a cadeia de certificação do signatário, da
Autoridade de Atributo e da Autoridade de Carimbo de Tempo, indicando para cada um desses
tipos quais são as restrições quanto aos algoritmos (hash, chave pública, combinação do hash com
chave pública) e quanto ao tamanho de chave mínimo exigido para esses algoritmos de assinatura.
2.5.2.5.3 Opcionalmente, PODEM também ser descritas quaisquer outras restrições de aceitação
relacionadas a algoritmos.
2.5.2.5.4 Os algoritmos DEVEM ser escolhidos entre os listados no documento Padrões e
Algoritmos Criptográficos da ICP-Brasil – DOC-ICP-01.01.
2.5.2.6 Regras Adicionais
Caso haja a necessidade de incluir regras adicionais para geração ou verificação de assinaturas
digitais, como por exemplo o ambiente mínimo exigido para assinatura digital, elas DEVEM ser
incluídas neste item.
2.5.3 Regras para Propósitos Específicos de Assinatura
Caso existam regras para propósitos específicos de assinatura, diferentes das regras definidas no
item 2.5.2., essas DEVEM ser detalhadas nos próximos itens.
2.5.3.1 Tipos de Propósitos Selecionados
Deve ser identificado o tipo de propósito para o qual a assinatura se destina, dentre aqueles
definidos nos padrões ETSI TR 102 733 [7] e ETSI TS 101 903 [9].
2.5.3.2 Regras de Signatário e Verificador
Caso existam regras específicas para determinados tipos de compromisso, elas DEVEM ser
detalhadas neste item, usando a mesma estrutura definida em 2.5.2.1.
2.5.3.3 Condições de Confiabilidade dos Certificados dos Signatários
Caso existam regras específicas para determinados tipos de compromisso, elas DEVEM ser
detalhadas neste item, usando a mesma estrutura definida em 2.5.2.2.
2.5.3.4 Condições de Confiabilidade do Carimbo de Tempo
Caso existam regras específicas para determinados tipos de compromisso, elas DEVEM ser
detalhadas neste item, usando a mesma estrutura definida em 2.5.2.3.
2.5.3.5 Condições de Confiabilidade dos Atributos
Caso existam regras específicas para determinados tipos de compromisso, elas DEVEM ser
detalhadas neste item, usando a mesma estrutura definida em 2.5.2.4.
2.5.3.6 Conjunto de Restrições de Algoritmos
Caso existam regras específicas para determinados tipos de compromisso, elas DEVEM ser
detalhadas neste item, usando a mesma estrutura definida em 2.5.2.5.
2.5.3.7 Regras Adicionais
Caso haja a necessidade de regras adicionais para geração ou verificação de assinaturas digitais para
determinado propósito específico, elas DEVEM ser incluídas neste item.
2.5.4 Informações Adicionais sobre a Validação das Assinaturas
Caso haja a necessidade de informações adicionais quanto a validação das assinaturas digitais no
âmbito desta Política de Assinatura, ela DEVEM ser incluídas neste item.
2.6 Informações Adicionais sobre a Política de Assinatura
Caso haja a necessidade de informações adicionais sobre a Política de Assinatura, elas DEVEM
estar incluídas neste item.
3. BIBLIOGRAFIA
[1] ITI. Glossário ICP-Brasil. Instituto Nacional de Tecnologia da Informação. Versão 1.2; Brasília:
ICP-Brasil, 2007.
[2] SCHNEIER, Bruce. Applied Cryptografy, Second Edition: protocols, algorithms, and source
code in C. USA: Wiley, 1996.
[3] DOURNAEE, Blake. XML Security. Berkely: McGraw-Hill/Osborne, 2002.
[4] ETSI. Signature Policies Report. ETSI TR 102 041 (2002-02); European Telecomunications
Standards Institute, 2002.
[5] ETSI. Eletronic Signature and Infraestructures (ESI); Signature policy for extended business
model. ETSI TR 102 045 (2005-03); European Telecomunications Standards Institute, 2005.
[6] ETSI. Electronic Signatures and Infrastructures (ESI); ASN.1 format for signature policies.
ETSI TR 102 272 (2003-12); European Telecomunications Standards Institute, 2003.
[7] EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE. ETSI TS 101 733
V1.7.4 (2008-07), Electronic Signatures and Infrastructures (ESI); CMS Advanced Electronic
Signatures (CAdES), Technical Specification, 2008.
[8] ETSI. Electronic Signatures and Infrastructures; Profiles of CMS Advanced Electronic
Signatures based on TS 101 733 (CAdES); ETSI TS 102 734 (2007-02); European
Telecomunications Standards Institute, 2007.
[9] ETSI. TC Security - Electronic Signatures and Infrastructures (ESI); XML format for signature
policies; ETSI TR 102 038 (2002-04); European Telecomunications Standards Institute, 2002.
[10] ETSI. XML Advanced Electronic Signatures (XAdES); ETSI TS 101 903 (2006-03); European
Telecomunications Standards Institute, 2006.
[11] ETSI. Electronic Signatures and Infrastructures; Profiles of XML Advanced Electronic
Signatures based on TS 101 903 (XAdES); ETSI TS 102 904 (2007-02); European
Telecomunications Standards Institute, 2007.
[12] ETSI. Electronic Signatures and Infrastructures (ESI); Algorithms and Parameters for Secure
Electronic Signatures; Part 1: Hash functions and asymmetric algorithms; ETSI TR 102 176 A
(2005-07); European Telecomunications Standards Institute, 2005.
[13] ETSI.Electronic Signatures and Infrastructures (ESI); Algorithms and Parameters for Secure
Electronic Signatures; Part 2: Secure channel protocols and algorithms for signature creation
devices; ETSI TR 102 176 B (2005-07); European Telecomunications Standards Institute, 2005.
[14] HOUSLEY, R. RFC 3852: Cryptographic message syntax (CMS). Internet Engineering Task
Force (IETF), July 2004. (disponível em http://www.ietf.org/rfc/rfc3852.txt).
[15] RFC 3275 (Extensible Markup Language) XML - Signature Syntax and Processing (2002-03);
[16] RFC 2560 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP
(1999-06);
[17] RFC 3126 Electronic Signature Formats for long term electronic signatures (2001-09);
[18] RFC 3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List
(CRL) Profile (2002-04);
[19] W3-IET-XML SIG XML- Signature Syntax and Processing W3C Recommendation (2002-02).
[20] REQUISITOS MÍNIMOS PARA AS DECLARAÇÕES DE PRÁTICAS DAS
AUTORIDADES DE CARIMBO DO TEMPO DA ICP-BRASIL DOC-ICP-12 - V 1.0
[21] ITI. PADRÕES E ALGORITMOS CRIPTOGRÁFICOS DA ICP-BRASIL. DOC-ICP-01.01
Instituto Nacional de Tecnologia da Informação. Versão 1.0; Brasília: ICP-Brasil, 2006.
[22] RIVAU Fernandes, Murilo SIPEX: Uma proposta de modelo de política de assinatura / M.
Rivau Fernandes. -- ed.rev. -- São Paulo, 2006. 105 p. Dissertação (Mestrado) - Escola Politécnica
da Universidade de São Paulo. Departamento de Engenharia de Sistemas Eletrônicos.
[23] EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE. ETSI TS 101 861
V1.2.1 (2002-03): Time stamping profile, technical specification, 2002.
[24] ADAMS, C.; CAIN, P.; PINKAS, D.; ZUCCHERATO, R. RFC 3161 – Internet X.509 public
key infrastructure: Time-Stamp Protocol (TSP) Internet Engineering Task Force (IETF), August
2001. (disponível em http://www.ietf.org/rfc/rfc3161.txt).
4. DOCUMENTOS REFERENCIADOS
Os documentos abaixo são aprovados por Resolução do Comitê-Gestor da ICP-Brasil, podendo ser
alterados, quando necessário, pelo mesmo tipo de dispositivo legal. O sítio http://www.iti.gov.br
publica a versão mais atualizada desses documentos e as Resoluções que os aprovaram.
Código Nome do documento
DOC-ICP-12 REQUISITOS MÍNIMOS PARA AS DECLARAÇÕES DE
PRÁTICAS DAS AUTORIDADES DE CARIMBO DO TEMPO DA
ICP-BRASIL
DOC-ICP-01.01 PADRÕES E ALGORITMOS CRIPTOGRÁFICOS DA ICP-BRASIL
ANEXO 1 - POLÍTICAS DE ASSINATURA-PADRÃO ICP-BRASIL
1. Para facilitar a utilização de Políticas de Assinatura pelos usuários finais, o ITI criou 10 Políticas
de Assinatura-padrão, que estão detalhadas a seguir.
2. Essas Políticas de Assinatura-padrão foram criadas a partir do cruzamento do Perfil de Uso Geral
para Assinaturas Digitais ICP-Brasil, definido no documento DOC-ICP-15.02, com os cinco
Formatos de Assinatura Digital da ICP-Brasil, derivados dos padrões CAdES e XAdES, citados no
documento DOC-ICP-15.01, a saber:
a) assinatura digital de curto prazo (AD-CP);
b) assinatura digital com carimbo do tempo (AD-T);
c) assinatura digital com referências para validação (AD-R);
d) assinatura digital com referências completas (AD-C);
e) assinatura digital com informações para arquivamento (AD-A); ou
f) uma combinação dos formatos citados nos subitens a) até e).
3. Nas tabelas 1 a 12, nas páginas seguintes, temos a combinação dos elementos citados no
parágrafo acima, aplicada aos diferentes contextos de assinatura.
4. Nos documentos “A” até “J” temos as 10 Políticas de Assinatura-padrão.
Tabela 1 – Presença de atributos assinados no SignerInfo do signatário
Nome do atributo Identificação do atributo Origem do
requisito de
inclusão do
atributo
Perfil AD
Tipo do conteúdo CP T R C A
Tipo de conteúdo
(content type)
id-contentType RFC 3852 [14]
ETSI CAdES [7]
seção 5.6
O O O O O
ContentType
hash da mensagem
(message digest)
id-messageDigest RFC 3852 [14]
ETSI CAdES [7]
seção 5.6
O O O O O
MessageDigest
Certificado do signatário
v1
(ESS signing certificate)
id-aa-signingCertificate RFC 2634 [14] e
ETSI CAdES [7]
seção 5.6
O O O O O
SigningCertificate
Certificado do signatário
v2
(ESS signing certificate
v2)
id-aa-signingCertificatev2 FC5035 [14] e
ETSI CAdES [7]
seção 5.6
SigningCertificateV2
Identificador da política
de assinatura
(signature policy
identifier)
id-aa-ets-sigPolicyId Requisito do
perfil ICP-Brasil
O O O O O
SignaturePolicyIdentifier
Indicação de tipo de
compromisso
(commitment type
indication)
id-aa-ets-
commitmentType
ETSI CAdES [7] R R R R R
CommitmentTypeIndicati
on
Atributos do signatário
(signer attributes)
id-aa-ets-signerAttr ETSI CAdES [7] P P P P P
SignerAttribute
Instante da assinatura
(signing time)
id-signingTime RFC 3852 [14] P P P P P
SigningTime
Localização do
signatário
(signer location)
id-aa-ets-signerLocation ETSI CAdES [7] P P P P P
SignerLocation
Carimbo de tempo de
conteúdo
(content time stamp)
id-aa-ets-
contentTimeStamp
ETSI CAdES [7] P P P P P
ContentTimeStamp
Legenda: O-obrigatório, P-permitido, R-recomendado, ND-não deve (proibido)
Tabela 2 – Presença de atributos não assinados no SignerInfo do
signatário
Nome do atributo Identificação do atributo Origem do
requisito de
inclusão do
atributo
Perfil AD
Tipo do conteúdo CP T R C A
Contra assinatura id-countersignature RFC 3852 [14] P P P P P
(countersignature) CounterSignature
Carimbo de tempo de
assinatura
(signature time stamp)
id-aa-
s
i
g
n
a
t
u
r
e
T
i
m
e
S
t
a
m
p
T
o
k
e
n
ETSI CAdES
[7], ETSI TS
101 861 [23] e
RFC 3161 [24]
P O O O O
SignatureTimeStampToken
Referências completas
aos certificados
(complete certificate
references)
id-aa-ets-certificateRefs ETSI CAdES [7] P P O O O
CompleteCertificateRefs
Referências completas à
revogação
(complete revogation
references)
id-aa-ets-revocationRefs ETSI CAdES [7] P P O O O
CompleteRevocationRefs
Referências aos
certificados de atributo
(attribute certificate
references)
id-aa-ets-attrCertificateRefs ETSI CAdES [7] P P O O O
AttributeCertificateRefs
Referências à
revogação de atributo
(attribute revogation
references)
id-aa-ets-attrRevocationRefs ETSI CAdES [7] P P O O O
AttributeRevocationRefs
Carimbo de tempo das
referências
(time-stamped
certificate crls
references)
id-aa-ets-certCRLTimestamp ETSI CAdES[7] P P O O P
TimestampedCertsCRLs
Valores dos
certificados
(certificate values)
id-aa-ets-certValues ETSI CAdES [7] P P P O O
CertificateValues
Valores de revogação
(revocation values)
id-aa-ets-revocationValues ETSI CAdES [7] P P P O O
RevocationValues
Carimbo de tempo de
arquivamento
(archive time-stamp)
id-aa-
a
r
c
h
i
v
e
T
i
m
e
S
t
a
m
p
T
o
k
e
n
ETSI CAdES
[7], ETSI TS
101 861 [23] e
RFC 3161 [24]
N
D
N
D
N
D
N
D
O
ArchiveTimeStampToken
Legenda: O-obrigatório, P-permitido, R-recomendado, ND-não deve (proibido)
Tabela 3 – Presença de atributos assinados no SignerInfo de “contra assinatura”
Nome do atributo Identificação do atributo Origem do
requisito de
inclusão do
atributo
Perfil AD
Tipo do conteúdo CP T R C A
Tipo de conteúdo
(content type)
id-contentType RFC 3852 [14]
seção 11.4
ND ND ND ND ND
ContentType
hash da mensagem
(message digest)
id-messageDigest RFC 3852 [14]
seção 11.4 e
ETSI CAdES
[7] seção 5.6
O O O O O
MessageDigest
Certificado do signatário
v1
(ESS signing certificate)
id-aa-signingCertificate ETSI CAdES
[7] seção 5.6
O O O O O
SigningCertificate
Certificado do signatário
v2
(ESS signing certificate
v2)
id-aa-signingCertificatev2
SigningCertificateV2
Identificador da
política de assinatura
(signature policy
identifier)
id-aa-ets-sigPolicyId Requisito do
perfil ICP-
Brasil
O O O O O
SignaturePolicyIdentifier
Indicação de tipo de
compromisso
(commitment type
indication)
id-aa-ets-commitmentType Requisito do
perfil ICP-
Brasil
R R R R R
CommitmentTypeIndicatio
n
Atributos do signatário
(signer attributes)
id-aa-ets-signerAttr P P P P P
SignerAttribute
Instante da assinatura
(signing time)
id-signingTime P P P P P
SigningTime
Localização do
signatário
(signer location)
id-aa-ets-signerLocation P P P P P
SignerLocation
Carimbo de tempo de
conteúdo
(content time stamp)
id-aa-ets-
contentTimeStamp
ND ND ND ND ND
ContentTimeStamp
Legenda: O-obrigatório, P-permitido, R-recomendado, ND-não deve (proibido)
Tabela 4 – Presença de atributos não assinados no SignerInfo de “contra
assinatura”
Nome do atributo Identificação do atributo Origem do
requisito de
inclusão do
atributo
Perfil AD
Tipo do conteúdo CP T R C A
Contra assinatura
(countersignature)
id-countersignature RFC 3852 [14]
seção 11.4
P P P P P
CounterSignature
Carimbo de tempo de
assinatura
(signature time stamp)
id-aa-
signatureTimeStampToken
ETSI CAdES [7],
ETSI TS 101 861
[23] e RFC 3161
[24]
P O O O O
SignatureTimeStampToke
n
Referências completas id-aa-ets-certificateRefs ETSI CAdES [7] P P O O O
aos certificados
(complete certificate
references)
CompleteCertificateRefs
Referências completas à
revogação
(complete revogation
references)
id-aa-ets-revocationRefs ETSI CAdES [7] P P O O O
CompleteRevocationRefs
Referências aos
certificados de atributo
(attribute certificate
references)
id-aa-ets-
attrCertificateRefs
ETSI CAdES [7] P P O O O
AttributeCertificateRefs
Referências à
revogação de atributo
(attribute revogation
references)
id-aa-ets-
a
t
t
r
R
e
v
o
c
a
t
i
o
n
R
e
f
s
ETSI CAdES [7] P P O O O
AttributeRevocationRefs
Carimbo de tempo das
referências
(time-stamped
certificate crls
references)
id-aa-ets-
certCRLTimestamp
ETSI CAdES [7] P P O O O
TimestampedCertsCRLs
Valores dos
certificados
(certificate values)
id-aa-ets-certValues ETSI CAdES [7] P P P O O
CertificateValues
Valores de revogação
(revocation values)
id-aa-ets-revocationValues ETSI CAdES [7] P P P O O
RevocationValues
Carimbo de tempo de
arquivamento
(archive time-stamp)
id-aa-
archiveTimeStampToken
ETSI CAdES [7] N
D
N
D
N
D
N
D
ND
ArchiveTimeStampToken
Legenda: O-obrigatório, P-permitido, R-recomendado, ND-não deve (proibido)
Tabela 5 – Presença de atributos assinados no TimeStampToken de
“carimbo de tempo de conteúdo”
Nome do atributo Identificação do
atributo
Origem do
requisito de
inclusão do
atributo
Perfil AD
Tipo do conteúdo CP T R C A
Tipo de conteúdo
(content type)
id-contentType RFC 3161 [24]
seção 2.4.2
(ref.
SigningCertifica
te attribute)
ETSI CAdES [7]
seção 5.6
O O O O O
ContentType
hash da mensagem
(message digest)
id-messageDigest RFC 3161 [24]
seção 2.4.2
(ref.
SigningCertifica
te attribute)
ETSI CAdES [7]
seção 5.6
O O O O O
MessageDigest
Certificado do signatário
v1
(ESS signing certificate)
id-aa-signingCertificate RFC 3161 [24]
seção 2.4.2
(ref.
SigningCertifica
te attribute)
ETSI CAdES [7]
seção 5.6
O O O O O
SigningCertificate
id-aa-
signingCertificatev2
Certificado do signatário
v2
(ESS signing certificate v2)
SigningCertificateV2
Identificador da política
de assinatura
(signature policy
identifier)
id-aa-ets-sigPolicyId ND ND ND ND ND
SignaturePolicyIdentifier
Indicação de tipo de
compromisso
(commitment type
indication)
id-aa-ets-
commitmentType
ND ND ND ND ND
CommitmentTypeIndicati
on
Atributos do signatário
(signer attributes)
id-aa-ets-signerAttr ND ND ND ND ND
SignerAttribute
Instante da assinatura
(signing time)
id-signingTime ND ND ND ND ND
SigningTime
Localização do
signatário
(signer location)
id-aa-ets-signerLocation ND ND ND ND ND
SignerLocation
Carimbo de tempo de
conteúdo
id-aa-ets-
contentTimeStamp
ND ND ND ND ND
(content time stamp) ContentTimeStamp
Legenda: O-obrigatório, P-permitido, R-recomendado, ND-não deve (proibido)
Tabela 6 – Presença de atributos não assinados no TimeStampToken de
“carimbo de tempo de conteúdo”
Nome do atributo Identificação do atributo Origem do
requisito de
inclusão do
atributo
Perfil AD
Tipo do conteúdo CP T R C A
Contra assinatura
(countersignature)
id-countersignature ND ND ND ND ND
CounterSignature
Carimbo de tempo de
assinatura
(signature time stamp)
id-aa-
s
i
g
n
a
t
u
r
e
T
i
m
e
S
t
a
m
p
T
o
k
e
n
ND ND ND ND ND
SignatureTimeStampToken
Referências completas aos
certificados
(complete certificate
references)
id-aa-ets-certificateRefs ETSI CAdES
[7] seção 6.2.1
R
(*)
R
(*)
O
(*)
O
(*)
O
(*)
CompleteCertificateRefs
Referências completas à
revogação
(complete revogation
references)
id-aa-ets-revocationRefs ETSI CAdES
[7] seção 6.2.2
R
(*)
R
(*)
O
(*)
O
(*)
O
(*)
CompleteRevocationRefs
Referências aos certificados
de atributo
(attribute certificate
references)
id-aa-ets-attrCertificateRefs ND ND ND ND ND
AttributeCertificateRefs
Referências à revogação
de atributo
(attribute revogation
references)
id-aa-ets-attrRevocationRefs ND ND ND ND ND
AttributeRevocationRefs
Carimbo de tempo das
referências
(time-stamped certificate
crls references)
id-aa-ets-certCRLTimestamp ETSI CAdES
[7] seção 6.3.6
R
(*)
R
(*)
O
(*)
O
(*)
O
(*)
TimestampedCertsCRLs
Valores dos certificados
(certificate values)
id-aa-ets-certValues ETSI CAdES
[7] seção 6.3.3
R
(*)
R
(*)
R
(*)
O
(*)
O
(*)
CertificateValues
Valores de revogação
(revocation values)
id-aa-ets-revocationValues ETSI CAdES
[7] seção 6.3.4
R
(*)
R
(*)
R
(*)
O
(*)
O
(*)
RevocationValues
Carimbo de tempo de
arquivamento
(archive time-stamp)
id-aa-
archiveTimeStampToken
ND ND ND ND ND
ArchiveTimeStampToken
Legenda: O-obrigatório, P-permitido, R-recomendado, ND-não deve (proibido)
(*) Como o atributo “carimbo de tempo de conteúdo” é assinado, antes da assinatura do signatário
devem ser incluídos os atributos não assinados necessários para o perfil de AD mais complexo
considerando seu ciclo de vida completo, pois não poderão ser incluídos posteriormente.
Tabela 7 – Presença de atributos assinados no SignerInfo do
TimeStampToken de “carimbo de tempo de assinatura.”
Nome do atributo Identificação do
atributo
Origem do
requisito de
inclusão do
atributo
Perfil AD
CP T R C A
Tipo do conteúdo
Tipo de conteúdo
(content type)
id-contentType RFC 3161 [24]
seção 2.4.2
(ref.
SigningCertific
ate attribute)
ETSI CAdES
[7] seção 5.6
O O O O O
ContentType
hash da mensagem
(message digest)
id-messageDigest RFC 3161 [24]
seção 2.4.2
(ref.
SigningCertifica
te attribute)
ETSI CAdES [7]
seção 5.6
O O O O O
MessageDigest
Certificado do signatário v1
(ESS signing certificate)
id-aa-signingCertificate RFC 3161 [24]
seção 2.4.2
(ref.
SigningCertifica
te attribute)
ETSI CAdES [7]
seção 5.6
O O O O O
SigningCertificate
Certificado do signatário v2
(ESS signing certificate v2)
id-aa-signingCertificatev2
SigningCertificateV2
Identificador da política
de assinatura
(signature policy
identifier)
id-aa-ets-sigPolicyId N
D
N
D
N
D
N
D
ND
SignaturePolicyIdentifie
r
Indicação de tipo de
compromisso
(commitment type
indication)
id-aa-ets-
commitmentType
N
D
N
D
N
D
N
D
ND
CommitmentTypeIndica
tion
Atributos do signatário
(signer attributes)
id-aa-ets-signerAttr N
D
N
D
N
D
N
D
ND
SignerAttribute
Instante da assinatura
(signing time)
id-signingTime N
D
N
D
N
D
N
D
ND
SigningTime
Localização do signatário
(signer location)
i
d
-
a
a
-
e
t
s
-
s
i
g
n
e
r
L
o
c
a
t
i
o
n
N
D
N
D
N
D
N
D
ND
SignerLocation
Carimbo de tempo de
conteúdo
(content time stamp)
id-aa-ets-
contentTimeStamp
N
D
N
D
N
D
N
D
ND
ContentTimeStamp
Legenda: O-obrigatório, P-permitido, R-recomendado, ND-não deve (proibido)
Tabela 8 – Presença de atributos não assinados no SignerInfo do
TimeStampToken de “carimbo de tempo de assinatura.”
Nome do atributo Identificação do atributo Origem do
requisito de
inclusão do
atributo
Perfil AD
Tipo do conteúdo CP T R C A
Contra assinatura
(countersignature)
id-countersignature ND ND ND ND ND
CounterSignature
Carimbo de tempo de
assinatura
(signature time stamp)
id-aa-
signatureTimeStampToken
ND ND ND ND ND
SignatureTimeStampToken
Referências completas
aos certificados
(complete certificate
references)
id-aa-ets-certificateRefs ETSI
CAdES [7]
seção 6.2.1
P P O O O
CompleteCertificateRefs
Referências completas à
revogação
(complete revogation
references)
id-aa-ets-revocationRefs ETSI
CAdES [7]
seção 6.2.2
P P O O O
CompleteRevocationRefs
Referências aos
certificados de atributo
(attribute certificate
references)
id-aa-ets-attrCertificateRefs ND ND ND ND ND
AttributeCertificateRefs
Referências à
revogação de atributo
(attribute revogation
references)
id-aa-ets-attrRevocationRefs ND ND ND ND ND
AttributeRevocationRefs
Carimbo de tempo das
referências
(time-stamped
certificate crls
references)
id-aa-ets-certCRLTimestamp ETSI
CAdES [7]
seção 6.3.6
P P O O O
TimestampedCertsCRLs
Valores dos
certificados
(certificate values)
id-aa-ets-certValues ETSI
CAdES [7]
seção 6.3.3
P P P O O
CertificateValues
Valores de revogação
(revocation values)
id-aa-ets-revocationValues ETSI
CAdES [7]
seção 6.3.4
P P P O O
RevocationValues
Carimbo de tempo de
arquivamento
(archive time-stamp)
id-aa-
archiveTimeStampToken
ND ND ND ND ND
ArchiveTimeStampToken
Legenda: O-obrigatório, P-permitido, R-recomendado, ND-não deve (proibido)
Tabela 9 – Presença de atributos assinados no SignerInfo do
TimeStampToken de “carimbo de tempo das referências”
Nome do atributo Identificação do atributo Origem do
requisito de
inclusão do
atributo
Perfil AD
Tipo do conteúdo CP T R C A
Tipo de conteúdo
(content type)
id-contentType RFC 3161 [24]
seção 2.4.2
(ref.
SigningCertificat
e attribute)
ETSI CAdES [7]
seção 5.6
O O O O O
ContentType
hash da mensagem
(message digest)
id-messageDigest RFC 3161 [24]
seção 2.4.2
(ref.
SigningCertificat
e attribute)
ETSI CAdES [7]
seção 5.6
O O O O O
MessageDigest
Certificado do signatário
v1
(ESS signing certificate)
id-aa-signingCertificate RFC 3161 [24]
seção 2.4.2
(ref.
SigningCertificat
e attribute)
ETSI CAdES [7]
seção 5.6
O O O O O
SigningCertificate
Certificado do signatário
v2
(ESS signing certificate
v2)
id-aa-signingCertificatev2
SigningCertificateV2
Identificador da
política de assinatura
(signature policy
identifier)
id-aa-ets-sigPolicyId ND ND ND ND ND
SignaturePolicyIdentifier
Indicação de tipo de
compromisso
(commitment type
indication)
id-aa-ets-commitmentType ND ND ND ND ND
CommitmentTypeIndicatio
n
Atributos do signatário
(signer attributes)
id-aa-ets-signerAttr ND ND ND ND ND
SignerAttribute
Instante da assinatura
(signing time)
id-signingTime ND ND ND ND ND
SigningTime
Localização do
signatário
(signer location)
id-aa-ets-signerLocation ND ND ND ND ND
SignerLocation
Carimbo de tempo de
conteúdo
(content time stamp)
id-aa-ets-
contentTimeStamp
ND ND ND ND ND
ContentTimeStamp
Legenda: O-obrigatório, P-permitido, R-recomendado, ND-não deve (proibido)
Tabela 10 – Presença de atributos não assinados no SignerInfo do
TimeStampToken de “carimbo de tempo das referências”
Nome do atributo Identificação do atributo Origem do
requisito de
inclusão do
atributo
Perfil AD
Tipo do conteúdo CP T R C A
Contra assinatura
(countersignature)
id-countersignature ND ND ND ND ND
CounterSignature
Carimbo de tempo de
assinatura
(signature time stamp)
id-aa-
signatureTimeStampToken
ND ND ND ND ND
SignatureTimeStampToken
Referências completas
aos certificados
(complete certificate
references)
id-aa-ets-certificateRefs ETSI CAdES
[7] seção 6.2.1
P P O O O
CompleteCertificateRefs
Referências completas à
revogação
(complete revogation
references)
id-aa-ets-revocationRefs ETSI CAdES
[7] seção 6.2.2
P P O O O
CompleteRevocationRefs
Referências aos
certificados de atributo
(attribute certificate
references)
id-aa-ets-attrCertificateRefs ND ND ND ND ND
AttributeCertificateRefs
Referências à
revogação de atributo
(attribute revogation
references)
id-aa-ets-attrRevocationRefs ND ND ND ND ND
AttributeRevocationRefs
Carimbo de tempo
das referências
(time-stamped
certificate crls
references)
id-aa-ets-certCRLTimestamp ETSI CAdES
[7] seção 6.3.6
P P O O O
TimestampedCertsCRLs
Valores dos
certificados
(certificate values)
id-aa-ets-certValues ETSI CAdES
[7] seção 6.3.3
P P P O O
CertificateValues
Valores de revogação
(revocation values)
id-aa-ets-revocationValues ETSI CAdES
[7] seção 6.3.4
P P P O O
RevocationValues
Carimbo de tempo de
arquivamento
(archive time-stamp)
id-aa-
a
r
c
h
i
v
e
T
i
m
e
S
t
a
m
p
T
o
k
e
n
ND ND ND ND ND
ArchiveTimeStampToken
Legenda: O-obrigatório, P-permitido, R-recomendado, ND-não deve (proibido)
Tabela 11 – Presença de atributos assinados no SignerInfo do
TimeStampToken de “carimbo de tempo de arquivamento”
Nome do atributo Identificação do
a
t
r
i
b
u
t
o
Origem do
requisito de
inclusão do
atributo
Carimbo de
Arquivamento
Tipo do conteúdo
Anterior Corrente
Tipo de conteúdo
(content type)
id-contentType RFC 3852 [14]
seção 5.3 e RFC
3161 [24] seção
2.4.2 (ref.
SigningCertificate
attribute)
O O
ContentType
hash da mensagem
(message digest)
id-messageDigest RFC 3852 [14]
seção 5.3 e RFC
3161 [24] seção
2.4.2 (ref.
SigningCertificate
attribute)
O O
MessageDigest
Certificado do
signatário v1
(ESS signing
certificate)
id-aa-signingCertificate RFC 3161 [24]
seção 2.4.2 (ref.
SigningCertificate
attribute)
O O
SigningCertificate
Certificado do
signatário v2
id-aa-
signingCertificatev2
(ESS signing
certificate v2)
SigningCertificateV2
Identificador da
política de
assinatura
(signature policy
identifier)
id-aa-ets-sigPolicyId ND ND
SignaturePolicyIdentifier
Indicação de tipo de
compromisso
(commitment type
indication)
id-aa-ets-
commitmentType
ND ND
CommitmentTypeIndicati
on
Atributos do
signatário
(signer attributes)
id-aa-ets-signerAttr ND ND
SignerAttribute
Instante da
assinatura
(signing time)
id-signingTime ND ND
SigningTime
Localização do
signatário
(signer location)
id-aa-ets-signerLocation ND ND
SignerLocation
Carimbo de tempo
de conteúdo
(content time
stamp)
id-aa-ets-
contentTimeStamp
ND ND
ContentTimeStamp
Legenda: O-obrigatório, P-permitido, R-recomendado, ND-não deve (proibido)
Tabela 12 – Presença de atributos não assinados no SignerInfo do
TimeStampToken de “carimbo de tempo de arquivamento”
Nome do atributo Identificação do
atributo
Origem do
requisito de
inclusão do
atributo
Carimdo de
Arquivamento
Tipo do conteúdo Anterior Corrente
Contra assinatura
(countersignature)
id-countersignature ND ND
CounterSignature
Carimbo de tempo de
assinatura
(signature time stamp)
id-aa-
signatureTimeStampTok
en
ND ND
SignatureTimeStampTok
en
Referências completas
aos certificados
(complete certificate
references)
id-aa-ets-certificateRefs ETSI CAdES
[7] seção 6.2.1
O O
CompleteCertificateRefs
Nome do atributo Identificação do
atributo
Origem do
requisito de
inclusão do
atributo
Carimdo de
Arquivamento
Referências completas à
revogação
(complete revogation
references)
id-aa-ets-revocationRefs ETSI CAdES
[7] seção 6.2.2
O O
CompleteRevocationRef
s
Referências aos
certificados de atributo
(attribute certificate
references)
id-aa-ets-
a
t
t
r
C
e
r
t
i
f
i
c
a
t
e
R
e
f
s
ND ND
AttributeCertificateRefs
Referências à
revogação de atributo
(attribute revogation
references)
id-aa-ets-
attrRevocationRefs
ND ND
AttributeRevocationRefs
Carimbo de tempo das
referências
(time-stamped
certificate and crls)
id-aa-ets-
certCRLTimestamp
ETSI CAdES
[7] seção 6.3.6
O R
TimestampedCertsCRLs
Valores dos
certificados
(certificate values)
id-aa-ets-certValues ETSI CAdES
[7] seção 6.3.3
O P
CertificateValues
Valores de revogação
(revocation values)
id-aa-ets-
revocationValues
ETSI CAdES
[7] seção 6.3.4
O P
RevocationValues
Carimbo de tempo de
arquivamento
(archive time-stamp)
id-aa-
archiveTimeStampToken
ND ND
ArchiveTimeStampToke
n
Legenda: O-obrigatório, P-permitido, R-recomendado, ND-não deve (proibido)
A - POLÍTICA-PADRÃO ICP-BRASIL AD-CP PARA ASSINATURAS
BASEADAS EM CMS / CADES
1. Identificador da Política de Assinatura
O nome desta Política de Assinatura é POLÍTICA ICP-BRASIL PARA ASSINATURA DIGITAL
DE CURTO PRAZO NO FORMATO CMS, versão 1.0.
O Object Identifier (OID) desta PA, atribuído pelo ITI é: 2.16.76.1.7.1.1.1. Novas versões desta
política, se criadas, receberão OID diferenciado, do tipo 2.16.76.1.7.1.1.n+1.
Esta PA está protegida contra alterações indevidas por meio da publicação, no repositório da AC
Raiz da ICP-Brasil (http://www.iti.gov.br/twiki/bin/view/Certificacao/RepositoriodaACRaiz), do
seu conteúdo assinado digitalmente por chave privada associada a certificado digital do Instituto
Nacional de Tecnologia da Informação, utilizando algoritmo Sha1withRSAEncryption(1 2 840
113549 1 1 5).
2 .Data da Criação
A data de criação desta PA é 31.10.2008.
3. Entidade Criadora da Política de Assinatura
A entidade criadora desta PA é o Instituto Nacional de Tecnologia da Informação (ITI). Ela pode
ser utilizada por qualquer pessoa física ou jurídica, órgão de governo ou outro tipo de entidade, sem
restrições.
4. Campo de Aplicação
Neste tipo de assinatura não são armazenados os dados fundamentais para sua validação futura e
nem é colocado carimbo de tempo de assinatura. Como não existem condições de garantir a
irretratabilidade da assinatura digital, este tipo de assinatura não pode ser usado para arbitragem, em
caso de disputa entre signatário e verificador.
Por esse motivo, assinaturas do tipo AD-CP somente devem ser utilizadas em situações especiais,
por exemplo, para serviços transacionais que exigem autenticação de entidades e/ou
verificação de integridade.
Caso seja necessário verficar a assinatura posteriormente devem existam ferramentas adicionais
para isso. As informações de validação deverão poder ser obtidas por outras fontes, como o sistema
operacional da parte verificadora, por exemplo. Nessas situações, é recomendável que exista um
acordo prévio, assinado por ambas as partes, signatário e verificador, concordando com a guarda
unilateral desses dados complementares.
Segundo esta PA, é permitido o emprego de múltiplas assinaturas.
5. Política de Validação da Assinatura
Os campos a seguir definem os processos para geração e verificação de assinaturas realizadas
segundo esta PA.
5.1 Período para Assinatura
Esta PA terá validade desde a data de publicação até 31.12.2010.
5.2 Regras Comuns
5.2.1 Regras de Signatário e Verificador
5.2.1.1 Regras do Signatário
5.2.1.1.1 Dados Externos ou Internos a Assinatura
As assinaturas realizadas segundo esta PA podem ou não incluir o conteúdo assinado na assinatura
digital (attached, ou detached).
5.2.1.1.2 Atributos Assinados Obrigatórios
As assinaturas feitas segundo esta PA devem conter, obrigatoriamente, os seguintes atributos
assinados:
a) Id-contentType
b) Id-messageDigest
c) id-aa-signingCertificate ou Id-aa-signingCertificateV2
d) Id-aa-ets-sigPolicyId
5.2.1.1.3 Atributos Não-Assinados Obrigatórios
Não se aplica.
5.2.1.1.4 Referências à Cadeia de Certificação
O atributo signingCertificate deve conter apenas referência ao certificado do signatário, por meio do
Identificador Serial do Emissor e do hash do certificado.
5.2.1.1.5 Valores da Cadeia de Certificação
Não se aplica.
5.2.1.1.6 Regras Adicionais do Signatário
Na utilização de múltiplas assinaturas, todas elas devem empregar os mesmos algoritmos definidos
no item 5.2.5. As formas possíveis de múltiplas assinaturas são:
a) Paralelas: quando a ordem de inserção das assinaturas não é importante; ou
b) Contra-assinaturas: quando a ordem de aplicação das assinaturas é relevante, ou seja,
quando a função da segunda assinatura é, no mínimo, atestar o recebimento do documento
com a primeira assinatura já presente.
No caso de assinaturas paralelas haverá múltiplas estruturas SignerInfo.
Para contra-assinaturas, deverão ser empregados atributos Id-countersignature.
Para a indicação do tipo de comprometimento devem ser empregados aqueles tipos definidos no
Anexo 1 do DOC-ICP-15.01.
Deve-se utilizar a codificação MIME para o valor do campo eContent da estrutura
EncapsulatedContentInfo, e o MIME type para identificação do formato de apresentação dos dados.
O signatário é responsável por se certificar que o documento assinado não contém qualquer
conteúdo dinâmico capaz de modificar o resultado do documento visualizado ao longo do tempo,
como, por exemplo, quantias ou sentenças que se alteram após certa data.
5.2.1.2 Regras do Verificador
5.2.1.2.1 Atributos Não-Assinados Obrigatórios
Não se aplica.
5.2.1.2.2 Regras Adicionais do Verificador
Caso esteja presente mais de uma assinatura, aposta ao mesmo documento assinado, deve-se validar
cada assinatura encontrada independentemente, segundo o item 5.2.1.1
5.2.2 Condições de Confiabilidade dos Certificados dos Signatários
5.2.2.1 Validação da Cadeia de Certificação
5.2.2.1.1 Raiz Confiável
A validação deve ser feita tomando como ponto de confiança os certificados da AC-Raiz da ICP-
Brasil, disponíveis em http://acraiz.icpbrasil.gov.br/CertificadoACRaiz.crt e
http://acraiz.icpbrasil.gov.br/ICP-Brasil.crt
5.2.2.1.2 Restrição do Caminho de Certificação
O número máximo de certificados de ACs, no caminho de certificação, entre o certificado do
signatário e a AC-Raiz é 2 (dois).
5.2.2.1.3 Conjunto de Políticas de Certificado Aceitável
Assinaturas digitais geradas segundo esta Política de Assinatura deverão ser criadas com chave
privada associada a certificados ICP-Brasil tipo A3 (cujo OID é 2.16.76.1.2.3.n) ou A4 (cujo OID é
2.16.76.1.2.4.n), conforme definido no DOC-ICP-04.
5.2.2.1.4 Restrições de Nome
Não se aplica.
5.2.2.1.5 Restrições de Políticas de Certificado
Não se aplica.
5.2.2.1.6 Forma de Verificação do Status da Cadeia de Certificação (Revogação)
Tanto para o certificado do signatário quanto para os certificados das Autoridades Certificadoras da
cadeia de certificação a verificação do status dos certificados deve ser realizada através de LCRs
(Lista de Certificados Revogados) em conformidade com o perfil de LCR definido no documento
DOC-ICP-04 ou através de consultas OCSP (Online Certificate Status Protocol) em conformidade
com a RFC 2560 ou algum outro método presente em DOC-ICP-04.
O método mínimo aplicável deve ser a verificação por LCR.
5.2.3 Condições de Confiabilidade do Carimbo de Tempo
Não se aplica
5.2.4 Condições de Confiabilidade dos Atributos
Não se aplica.
5.2.5 Conjunto de Restrições de Algoritmos
Os processos para criação e verificação de assinaturas segundo esta PA devem utilizar os
algoritmos:
a) Sha1(1 3 14 3 2 26)
b) Sha1withRSAEncryption(1 2 840 113549 1 1 5)
c) RsaEncryption(1 2 840 113549 1 1 1) com minKeyLength=1024
5.2.6 Regras Adicionais
Não se aplica.
5.3 Regras para Propósitos Específicos de Assinatura
Não se aplica.
5.4 Informações Adicionais sobre a Validação das Assinaturas
Não se aplica.
6. Informações Adicionais sobre a Política de Assinatura
Não se aplica.
B - POLÍTICA-PADRÃO ICP-BRASIL AD-T PARA PARA
ASSINATURAS BASEADAS EM CMS / CADES
1. Identificador da Política de Assinatura
O nome desta Política de Assinatura é POLÍTICA ICP-BRASIL PARA ASSINATURA DIGITAL
COM CARIMBO DE TEMPO NO FORMATO CMS, versão 1.0.
O Object Identifier (OID) desta PA, atribuído pelo ITI é: 2.16.76.1.7.1.2.1. Novas versões desta
política, se criadas, receberão OID diferenciado, do tipo 2.16.76.1.7.1.2.n+1.
Esta PA está protegida contra alterações indevidas por meio da publicação, no repositório da AC
Raiz da ICP-Brasil (http://www.iti.gov.br/twiki/bin/view/Certificacao/RepositoriodaACRaiz), do
seu conteúdo assinado digitalmente por chave privada associada a certificado digital do Instituto
Nacional de Tecnologia da Informação, utilizando algoritmo Sha1withRSAEncryption(1 2 840
113549 1 1 5).
2. Data da Criação
A data de criação desta PA é 31.10.2008.
3. Entidade Criadora da Política de Assinatura
A entidade criadora desta PA é o Instituto Nacional de Tecnologia da Informação (ITI). Ela pode
ser utilizada por qualquer pessoa física ou jurídica, órgão de governo ou outro tipo de entidade, sem
restrições.
4. Campo de Aplicação
Este tipo de assinatura deve ser utilizado em aplicações ou processos de negócios nos quais a
assinatura digital necessita de segurança em relação à irretratabilidade de sua geração, pois o
carimbo de tempo serve como evidência de que o certificado do signatário não estava revogado ou
expirado no momento da assinatura.
Como esse tipo de assinatura não traz, de forma auto-contida, referências ou valores dos
certificados e das informações de revogação (LCRs ou respostas OCSP) necessários para sua
validação posterior, ele deve ser utilizado somente quando esses dados puderem ser obtidos por
meios externos, de forma inequívoca. Mesmo assim, uma assinatura desse tipo pode ser contestada
se houver, por exemplo, o comprometimento da chave da AC que emitiu qualquer um dos
certificados da cadeia de certificação.
Segundo esta PA, é permitido o emprego de múltiplas assinaturas.
5. Política de Validação da Assinatura
Os campos a seguir definem os processos para geração e verificação de assinaturas realizadas
segundo esta PA.
5.1 Período para Assinatura
Esta PA terá validade desde a data de publicação até 31.12.2010.
5.2 Regras Comuns
5.2.1 Regras de Signatário e Verificador
5.2.1.1 Regras do Signatário
5.2.1.1.1 Dados Externos ou Internos a Assinatura
As assinaturas realizadas segundo esta PA podem ou não incluir o conteúdo assinado na assinatura
digital (attached, ou detached).
5.2.1.1.2 Atributos Assinados Obrigatórios
As assinaturas feitas segundo esta PA devem conter, obrigatoriamente, os seguintes atributos
assinados:
a) Id-contentType
b) Id-messageDigest
c) id-aa-signingCertificate ou Id-aa-signingCertificateV2
d) Id-aa-ets-sigPolicyId
5.2.1.1.3 Atributos Não-Assinados Obrigatórios
a) id-aa-signatureTimeStampToken
5.2.1.1.4 Referências à Cadeia de Certificação
O atributo signingCertificate deve conter apenas referência ao certificado do signatário, por meio do
Identificador Serial do Emissor e do hash do certificado.
5.2.1.1.5 Valores da Cadeia de Certificação
Não se aplica.
5.2.1.1.6 Regras Adicionais do Signatário
Na utilização de múltiplas assinaturas, todas elas devem empregar os mesmos algoritmos definidos
no item 5.2.5. As formas possíveis de múltiplas assinaturas são:
a) Paralelas: quando a ordem de inserção das assinaturas não é importante; ou
b)Contra-assinaturas: quando a ordem de aplicação das assinaturas é relevante, ou seja,
quando a função da segunda assinatura é, no mínimo, atestar o recebimento do documento
com a primeira assinatura já presente.
No caso de assinaturas paralelas haverá múltiplas estruturas SignerInfo.
Para contra-assinaturas, deverão ser empregados atributos Id-countersignature.
Para a indicação do tipo de comprometimento devem ser empregados aqueles tipos definidos no
Anexo 1 do DOC-ICP-15.01.
Deve-se utilizar a codificação MIME para o valor do campo eContent da estrutura
EncapsulatedContentInfo, e o MIME type para identificação do formato de apresentação dos dados.
O signatário é responsável por se certificar que o documento assinado não contém qualquer
conteúdo dinâmico capaz de modificar o resultado do documento visualizado ao longo do tempo,
como, por exemplo, quantias ou sentenças que se alteram após certa data.
5.2.1.2 Regras do Verificador
5.2.1.2.1 Atributos Não-Assinados Obrigatórios
Caso não tenha sido incluído pelo signatário, o seguinte atributo DEVE ser incluído pelo
verificador:
a) id-aa-signatureTimeStampToken.
5.2.1.2.2 Regras Adicionais do Verificador
Caso esteja presente mais de uma assinatura, aposta ao mesmo documento assinado, deve-se validar
cada assinatura encontrada independentemente, segundo o item 5.2.1.1
5.2.2 Condições de Confiabilidade dos Certificados dos Signatários
5.2.2.1 Validação da Cadeia de Certificação
5.2.2.1.1 Raiz Confiável
A validação deve ser feita tomando como ponto de confiança os certificados da AC-Raiz da ICP-
Brasil, disponíveis em http://acraiz.icpbrasil.gov.br/CertificadoACRaiz.crt e
http://acraiz.icpbrasil.gov.br/ICP-Brasil.crt
5.2.2.1.2 Restrição do Caminho de Certificação
O número máximo de certificados de ACs, no caminho de certificação, entre o certificado do
signatário e a AC-Raiz é 2 (dois).
5.2.2.1.3 Conjunto de Políticas de Certificado Aceitável
Assinaturas digitais geradas segundo esta Política de Assinatura deverão ser criadas com chave
privada associada a certificados ICP-Brasil tipo A3 (cujo OID é 2.16.76.1.2.3.n) ou A4 (cujo OID é
2.16.76.1.2.4.n), conforme definido no DOC-ICP-04.
5.2.2.1.4 Restrições de Nome
Não se aplica.
5.2.2.1.5 Restrições de Políticas de Certificado
Não se aplica.
5.2.2.1.6 Forma de Verificação do Status da Cadeia de Certificação (Revogação)
Tanto para o certificado do signatário quanto para os certificados das Autoridades Certificadoras da
cadeia de certificação a verificação do status dos certificados deve ser realizada através de LCRs
(Lista de Certificados Revogados) em conformidade com o perfil de LCR definido no documento
DOC-ICP-04 ou através de consultas OCSP (Online Certificate Status Protocol) em conformidade
com a RFC 2560 ou algum outro método presente em DOC-ICP-04.
O método mínimo aplicável deve ser a verificação por LCR.
5.2.3 Condições de Confiabilidade do Carimbo de Tempo
5.2.3.1 Validação da Cadeia de Certificação
5.2.3.1.1 Raiz Confiável
A validação da assinatura constante no carimbo de tempo deve ser feita tomando como ponto de
confiança os certificados da AC-Raiz da ICP-Brasil, disponíveis em
http://acraiz.icpbrasil.gov.br/CertificadoACRaiz.crt e http://acraiz.icpbrasil.gov.br/ICP-Brasil.crt
5.2.3.1.2 Restrição do Caminho de Certificação
O número máximo de certificados de ACs, no caminho de certificação, entre o certificado do
equipamento emissor do carimbo de tempo (SCT) e a AC-Raiz é 2 (dois).
5.2.3.1.3 Conjunto de Políticas de Certificado Aceitável
Os carimbos de tempo deverão ser criados com chave privada associada a certificados ICP-Brasil
tipo T3 (cujo OID é 2.16.76.1.2.303.n) ou T4 (cujo OID é 2.16.76.1.2.304.n), conforme definido no
DOC-ICP-04.
5.2.3.1.4 Restrições de Nome
Não se aplica.
5.2.3.1.5 Restrições de Políticas de Certificado
Não se aplica.
5.2.3.2 Forma de Verificação do Status da Cadeia de Certificação (Revogação)
Tanto para o certificado do SCT quanto para os certificados das Autoridades Certificadoras da
cadeia de certificação, a verificação do status deve ser realizada através de LCRs (Lista de
Certificados Revogados) em conformidade com o perfil de LCR definido no documento DOC-ICP-
04 ou através de consultas OCSP (Online Certificate Status Protocol) em conformidade com a RFC
2560 ou algum outro método presente em DOC-ICP-04.
O método mínimo aplicável deve ser a verificação por LCR.
5.2.3.3 Restrições de Nome
Não se aplica.
5.2.3.4 Período de Cautela
Não se aplica.
5.2.3.5 Atraso do Carimbo de Tempo
Não se aplica.
5.2.4 Condições de Confiabilidade dos Atributos
Não se aplica.
5.2.5 Conjunto de Restrições de Algoritmos
Os processos para criação e verificação de assinaturas segundo esta PA devem utilizar os
algoritmos:
a) Sha1(1 3 14 3 2 26)
b) Sha1withRSAEncryption(1 2 840 113549 1 1 5)
c) RsaEncryption(1 2 840 113549 1 1 1) com minKeyLength=1024
5.2.6 Regras Adicionais
Não se aplica.
5.3 Regras para Propósitos Específicos de Assinatura
Não se aplica.
5.4 Informações Adicionais sobre a Validação das Assinaturas
Não se aplica.
6. Informações Adicionais sobre a Política de Assinatura
Não se aplica.
C - POLÍTICA-PADRÃO ICP-BRASIL AD-R PARA PARA
ASSINATURAS BASEADAS EM CMS / CADES
1. Identificador da Política de Assinatura
O nome desta Política de Assinatura é POLÍTICA ICP-BRASIL PARA ASSINATURA DIGITAL
COM REFERÊNCIAS PARA VALIDAÇÃO NO FORMATO CMS, versão 1.0.
O Object Identifier (OID) desta PA, atribuído pelo ITI é: 2.16.76.1.7.1.3.1. Novas versões desta
política, se criadas, receberão OID diferenciado, do tipo 2.16.76.1.7.1.3.n+1.
Esta PA está protegida contra alterações indevidas por meio da publicação, no repositório da AC
Raiz da ICP-Brasil (http://www.iti.gov.br/twiki/bin/view/Certificacao/RepositoriodaACRaiz), do
seu conteúdo assinado digitalmente por chave privada associada a certificado digital do Instituto
Nacional de Tecnologia da Informação, utilizando algoritmo Sha1withRSAEncryption(1 2 840
113549 1 1 5).
2. Data da Criação
A data de criação desta PA é 31.10.2008.
3. Entidade Criadora da Política de Assinatura
A entidade criadora desta PA é o Instituto Nacional de Tecnologia da Informação (ITI). Ela pode
ser utilizada por qualquer pessoa física ou jurídica, órgão de governo ou outro tipo de entidade, sem
restrições.
4. Campo de Aplicação
Este tipo de assinatura inclui, no seu próprio corpo, referências sobre os certificados que compõem
a cadeia de certificação e sobre as informações de revogação do certificado digital do signatário.
Um carimbo de tempo provê a ligação entre essas informações e o conteúdo assinado.
Ele deve ser usado em aplicações onde se necessita verificar a assinatura a qualquer momento e
onde os dados necessários para isso (que estão referenciados no corpo da assinatura), estejam
disponíveis para recuperação.
Além de oferecer segurança quanto à irretratabilidade, ele permite que se verifique a validade da
assinatura digital mesmo que ocorra comprometimento da chave privada da AC que emitiu o
certificado do signatário, desde que o carimbo de tempo sobre as referências tenha sido colocado
antes desse comprometimento.
Segundo esta PA, é permitido o emprego de múltiplas assinaturas.
5. Política de Validação da Assinatura
Os campos a seguir definem os processos para geração e verificação de assinaturas realizadas
segundo esta PA.
5.1 Período para Assinatura
Esta PA terá validade desde a data de publicação até 31.12.2010.
5.2 Regras Comuns
5.2.1 Regras de Signatário e Verificador
5.2.1.1 Regras do Signatário
5.2.1.1.1 Dados Externos ou Internos a Assinatura
As assinaturas realizadas segundo esta PA podem ou não incluir o conteúdo assinado na assinatura
digital (attached, ou detached).
5.2.1.1.2 Atributos Assinados Obrigatórios
As assinaturas feitas segundo esta PA devem conter, obrigatoriamente, os seguintes atributos
assinados:
i. Id-contentType
ii. Id-messageDigest
e) id-aa-signingCertificate ou Id-aa-signingCertificateV2
iii. Id-aa-ets-sigPolicyId
5.2.1.1.3 Atributos Não-Assinados Obrigatórios
a) id-aa-signatureTimeStampToken
b) id-aa-ets-certificateRefs
c) id-aa-ets-revocationRefs
d) id-aa-ets-escTimeStamp
5.2.1.1.4 Referências à Cadeia de Certificação
O atributo signingCertificate deve conter apenas referência ao certificado do signatário, por meio do
Identificador Serial do Emissor e do hash do certificado.
5.2.1.1.5 Valores da Cadeia de Certificação
Não se aplica.
5.2.1.1.6 Regras Adicionais do Signatário
Na utilização de múltiplas assinaturas, todas elas devem empregar os mesmos algoritmos definidos
no item 5.2.5. As formas possíveis de múltiplas assinaturas são:
a) Paralelas: quando a ordem de inserção das assinaturas não é importante; ou
b) Contra-assinaturas: quando a ordem de aplicação das assinaturas é relevante, ou seja,
quando a função da segunda assinatura é, no mínimo, atestar o recebimento do
documento com a primeira assinatura já presente.
No caso de assinaturas paralelas haverá múltiplas estruturas SignerInfo.
Para contra-assinaturas, deverão ser empregados atributos Id-countersignature.
Para a indicação do tipo de comprometimento devem ser empregados aqueles tipos definidos no
Anexo 1 do DOC-ICP-15.01.
Deve-se utilizar a codificação MIME para o valor do campo eContent da estrutura
EncapsulatedContentInfo, e o MIME type para identificação do formato de apresentação dos dados.
O signatário é responsável por se certificar que o documento assinado não contém qualquer
conteúdo dinâmico capaz de modificar o resultado do documento visualizado ao longo do tempo,
como, por exemplo, quantias ou sentenças que se alteram após certa data.
5.2.1.2 Regras do Verificador
5.2.1.2.1 Atributos Não-Assinados Obrigatórios
Caso não tenham sido incluídos pelo signatário, os seguintes atributos DEVEM ser incluídos pelo
verificador:
a) id-aa-signatureTimeStampToken
b) id-aa-ets-certificateRefs
c) id-aa-ets-revocationRefs
d) id-aa-ets-escTimeStamp
5.2.1.2.2 Regras Adicionais do Verificador
Caso esteja presente mais de uma assinatura, aposta ao mesmo documento assinado, deve-se validar
cada assinatura encontrada independentemente, segundo o item 5.2.1.1
5.2.2 Condições de Confiabilidade dos Certificados dos Signatários
5.2.2.1 Validação da Cadeia de Certificação
5.2.2.1.1 Raiz Confiável
A validação deve ser feita tomando como ponto de confiança os certificados da AC-Raiz da ICP-
Brasil, disponíveis em http://acraiz.icpbrasil.gov.br/CertificadoACRaiz.crt e
http://acraiz.icpbrasil.gov.br/ICP-Brasil.crt
5.2.2.1.2 Restrição do Caminho de Certificação
O número máximo de certificados de ACs, no caminho de certificação, entre o certificado do
signatário e a AC-Raiz é 2 (dois).
5.2.2.1.3 Conjunto de Políticas de Certificado Aceitável
Assinaturas digitais geradas segundo esta Política de Assinatura deverão ser criadas com chave
privada associada a certificados ICP-Brasil tipo A3 (cujo OID é 2.16.76.1.2.3.n) ou A4 (cujo OID é
2.16.76.1.2.4.n), conforme definido no DOC-ICP-04.
5.2.2.1.4 Restrições de Nome
Não se aplica.
5.2.2.1.5 Restrições de Políticas de Certificado
Não se aplica.
5.2.2.1.6 Forma de Verificação do Status da Cadeia de Certificação (Revogação)
Tanto para o certificado do signatário quanto para os certificados das Autoridades Certificadoras da
cadeia de certificação a verificação do status dos certificados deve ser realizada através de LCRs
(Lista de Certificados Revogados) em conformidade com o perfil de LCR definido no documento
DOC-ICP-04 ou através de consultas OCSP (Online Certificate Status Protocol) em conformidade
com a RFC 2560 ou algum outro método presente em DOC-ICP-04.
O método mínimo aplicável deve ser a verificação por LCR.
5.2.3 Condições de Confiabilidade do Carimbo de Tempo
5.2.3.1 Validação da Cadeia de Certificação
5.2.3.1.1 Raiz Confiável
A validação da assinatura constante no carimbo de tempo deve ser feita tomando como ponto de
confiança os certificados da AC-Raiz da ICP-Brasil, disponíveis em
http://acraiz.icpbrasil.gov.br/CertificadoACRaiz.crt e http://acraiz.icpbrasil.gov.br/ICP-Brasil.crt
5.2.3.1.2 Restrição do Caminho de Certificação
O número máximo de certificados de ACs, no caminho de certificação, entre o certificado do
equipamento emissor do carimbo de tempo (SCT) e a AC-Raiz é 2 (dois).
5.2.3.1.3 Conjunto de Políticas de Certificado Aceitável
Os carimbos de tempo deverão ser criados com chave privada associada a certificados ICP-Brasil
tipo T3 (cujo OID é 2.16.76.1.2.303.n) ou T4 (cujo OID é 2.16.76.1.2.304.n), conforme definido no
DOC-ICP-04.
5.2.3.1.4 Restrições de Nome
Não se aplica.
5.2.3.1.5 Restrições de Políticas de Certificado
Não se aplica.
5.2.3.1.6 Forma de Verificação do Status da Cadeia de Certificação (Revogação)
Tanto para o certificado do SCT quanto para os certificados das Autoridades Certificadoras da
cadeia de certificação, a verificação do status deve ser realizada através de LCRs (Lista de
Certificados Revogados) em conformidade com o perfil de LCR definido no documento DOC-ICP-
04 ou através de consultas OCSP (Online Certificate Status Protocol) em conformidade com a RFC
2560 ou algum outro método presente em DOC-ICP-04.
O método mínimo aplicável deve ser a verificação por LCR.
5.2.3.3 Restrições de Nome
Não se aplica.
5.2.3.4 Período de Cautela
Não se aplica.
5.2.3.5 Atraso do Carimbo de Tempo
Não se aplica.
5.2.4 Condições de Confiabilidade dos Atributos
Não se aplica.
5.2.5 Conjunto de Restrições de Algoritmos
Os processos para criação e verificação de assinaturas segundo esta PA devem utilizar os
algoritmos:
a) Sha1(1 3 14 3 2 26)
b) Sha1withRSAEncryption(1 2 840 113549 1 1 5)
c) RsaEncryption(1 2 840 113549 1 1 1) com minKeyLength=1024
5.2.6 Regras Adicionais
Não se aplica.
5.3 Regras para Propósitos Específicos de Assinatura
Não se aplica.
5.4 Informações Adicionais sobre a Validação das Assinaturas
Não se aplica.
6. Informações Adicionais sobre a Política de Assinatura
Não se aplica.
D - POLÍTICA-PADRÃO ICP-BRASIL AD-C PARA PARA
ASSINATURAS BASEADAS EM CMS / CADES
1. Identificador da Política de Assinatura
O nome desta Política de Assinatura é POLÍTICA ICP-BRASIL PARA ASSINATURA DIGITAL
COM INFORMAÇÕES COMPLETAS NO FORMATO CMS, versão 1.0.
O Object Identifier (OID) desta PA, atribuído pelo ITI é: 2.16.76.1.7.1.4.1. Novas versões desta
política, se criadas, receberão OID diferenciado, do tipo 2.16.76.1.7.1.4.n+1.
Esta PA está protegida contra alterações indevidas por meio da publicação, no repositório da AC
Raiz da ICP-Brasil (http://www.iti.gov.br/twiki/bin/view/Certificacao/RepositoriodaACRaiz), do
seu conteúdo assinado digitalmente por chave privada associada a certificado digital do Instituto
Nacional de Tecnologia da Informação, utilizando algoritmo Sha1withRSAEncryption(1 2 840
113549 1 1 5).
2. Data da Criação
A data de criação desta PA é 31.10.2008.
3. Entidade Criadora da Política de Assinatura
A entidade criadora desta PA é o Instituto Nacional de Tecnologia da Informação (ITI). Ela pode
ser utilizada por qualquer pessoa física ou jurídica, órgão de governo ou outro tipo de entidade, sem
restrições.
4. Campo de Aplicação
Este tipo de assinatura inclui, no seu próprio corpo, além das referências, os certificados que
compõem a cadeia de certificação e as informações de revogação do certificado digital do
signatário. Ele demanda uma maior capacidade de armazenamento.
Ele deve ser usado em situações onde é necessária a verificação completa da validade da assinatura
digital a qualquer momento, pois os dados necessários estão auto-contidos na assinatura.
Além de oferecer segurança quanto à irretratabilidade, ele permite que se verifique a validade da
assinatura digital mesmo que ocorra comprometimento da chave privada da AC que emitiu o
certificado do signatário, desde que o carimbo de tempo sobre as referências/valores dos
certificados tenha sido colocado antes desse comprometimento.
Segundo esta PA, é permitido o emprego de múltiplas assinaturas.
5. Política de Validação da Assinatura
Os campos a seguir definem os processos para geração e verificação de assinaturas realizadas
segundo esta PA.
5.1 Período para Assinatura
Esta PA terá validade desde a data de publicação até 31.12.2010.
5.2 Regras Comuns
5.2.1 Regras de Signatário e Verificador
5.2.1.1 Regras do Signatário
5.2.1.1.1 Dados Externos ou Internos a Assinatura
As assinaturas realizadas segundo esta PA podem ou não incluir o conteúdo assinado na assinatura
digital (attached, ou detached).
5.2.1.1.2 Atributos Assinados Obrigatórios
As assinaturas feitas segundo esta PA devem conter, obrigatoriamente, os seguintes atributos
assinados:
i. Id-contentType
ii. Id-messageDigest
f) id-aa-signingCertificate ou Id-aa-signingCertificateV2
iii. Id-aa-ets-sigPolicyId
5.2.1.1.3 Atributos Não-Assinados Obrigatórios
a) id-aa-signatureTimeStampToken
b) id-aa-ets-certificateRefs
c) id-aa-ets-revocationRefs
d) id-aa-ets-escTimeStamp
e) id-aa-ets-certValues
f) id-aa-ets-revocationValues
5.2.1.1.4 Referências à Cadeia de Certificação
O atributo signingCertificate deve conter apenas referência ao certificado do signatário, por meio do
Identificador Serial do Emissor e do hash do certificado.
5.2.1.1.5 Valores da Cadeia de Certificação
Não se aplica.
5.2.1.1.6 Regras Adicionais do Signatário
Na utilização de múltiplas assinaturas, todas elas devem empregar os mesmos algoritmos definidos
no item 5.2.5. As formas possíveis de múltiplas assinaturas são:
a) Paralelas: quando a ordem de inserção das assinaturas não é importante; ou
b) Contra-assinaturas: quando a ordem de aplicação das assinaturas é relevante, ou seja,
quando a função da segunda assinatura é, no mínimo, atestar o recebimento do
documento com a primeira assinatura já presente.
No caso de assinaturas paralelas haverá múltiplas estruturas SignerInfo.
Para contra-assinaturas, deverão ser empregados atributos Id-countersignature.
Para a indicação do tipo de comprometimento devem ser empregados aqueles tipos definidos no
Anexo 1 do DOC-ICP-15.01.
Deve-se utilizar a codificação MIME para o valor do campo eContent da estrutura
EncapsulatedContentInfo, e o MIME type para identificação do formato de apresentação dos dados.
O signatário é responsável por se certificar que o documento assinado não contém qualquer
conteúdo dinâmico capaz de modificar o resultado do documento visualizado ao longo do tempo,
como, por exemplo, quantias ou sentenças que se alteram após certa data.
5.2.1.2 Regras do Verificador
5.2.1.2.1 Atributos Não-Assinados Obrigatórios
Caso não tenham sido incluídos pelo signatário, os seguintes atributos DEVEM ser incluídos pelo
verificador:
a) id-aa-signatureTimeStampToken
b) id-aa-ets-certificateRefs
c) id-aa-ets-revocationRefs
d) id-aa-ets-escTimeStamp
e) id-aa-ets-certValues
f) id-aa-ets-revocationValues
5.2.1.2.2 Regras Adicionais do Verificador
Caso esteja presente mais de uma assinatura, aposta ao mesmo documento assinado, deve-se validar
cada assinatura encontrada independentemente, segundo o item 5.2.1.1
5.2.2 Condições de Confiabilidade dos Certificados dos Signatários
5.2.2.1 Validação da Cadeia de Certificação
5.2.2.1.1 Raiz Confiável
A validação deve ser feita tomando como ponto de confiança os certificados da AC-Raiz da ICP-
Brasil, disponíveis em http://acraiz.icpbrasil.gov.br/CertificadoACRaiz.crt e
http://acraiz.icpbrasil.gov.br/ICP-Brasil.crt
5.2.2.1.2 Restrição do Caminho de Certificação
O número máximo de certificados de ACs, no caminho de certificação, entre o certificado do
signatário e a AC-Raiz é 2 (dois).
5.2.2.1.3 Conjunto de Políticas de Certificado Aceitável
Assinaturas digitais geradas segundo esta Política de Assinatura deverão ser criadas com chave
privada associada a certificados ICP-Brasil tipo A3 (cujo OID é 2.16.76.1.2.3.n) ou A4 (cujo OID é
2.16.76.1.2.4.n), conforme definido no DOC-ICP-04.
5.2.2.1.4 Restrições de Nome
Não se aplica.
5.2.2.1.5 Restrições de Políticas de Certificado
Não se aplica.
5.2.2.1.6 Forma de Verificação do Status da Cadeia de Certificação (Revogação)
Tanto para o certificado do signatário quanto para os certificados das Autoridades Certificadoras da
cadeia de certificação a verificação do status dos certificados deve ser realizada através de LCRs
(Lista de Certificados Revogados) em conformidade com o perfil de LCR definido no documento
DOC-ICP-04 ou através de consultas OCSP (Online Certificate Status Protocol) em conformidade
com a RFC 2560 ou algum outro método presente em DOC-ICP-04.
O método mínimo aplicável deve ser a verificação por LCR.
5.2.3 Condições de Confiabilidade do Carimbo de Tempo
5.2.3.1 Validação da Cadeia de Certificação
5.2.3.1.1 Raiz Confiável
A validação da assinatura constante no carimbo de tempo deve ser feita tomando como ponto de
confiança os certificados da AC-Raiz da ICP-Brasil, disponíveis em
http://acraiz.icpbrasil.gov.br/CertificadoACRaiz.crt e http://acraiz.icpbrasil.gov.br/ICP-Brasil.crt
5.2.3.1.2 Restrição do Caminho de Certificação
O número máximo de certificados de ACs, no caminho de certificação, entre o certificado do
equipamento emissor do carimbo de tempo (SCT) e a AC-Raiz é 2 (dois).
5.2.3.1.3 Conjunto de Políticas de Certificado Aceitável
Os carimbos de tempo deverão ser criados com chave privada associada a certificados ICP-Brasil
tipo T3 (cujo OID é 2.16.76.1.2.303.n) ou T4 (cujo OID é 2.16.76.1.2.304.n), conforme definido no
DOC-ICP-04.
5.2.3.1.4 Restrições de Nome
Não se aplica.
5.2.3.1.5 Restrições de Políticas de Certificado
Não se aplica.
5.2.3.1.6 Forma de Verificação do Status da Cadeia de Certificação (Revogação)
Tanto para o certificado do SCT quanto para os certificados das Autoridades Certificadoras da
cadeia de certificação, a verificação do status deve ser realizada através de LCRs (Lista de
Certificados Revogados) em conformidade com o perfil de LCR definido no documento DOC-ICP-
04 ou através de consultas OCSP (Online Certificate Status Protocol) em conformidade com a RFC
2560 ou algum outro método presente em DOC-ICP-04.
O método mínimo aplicável deve ser a verificação por LCR.
5.2.3.3 Restrições de Nome
Não se aplica.
5.2.3.4 Período de Cautela
Não se aplica.
5.2.3.5 Atraso do Carimbo de Tempo
Não se aplica.
5.2.4 Condições de Confiabilidade dos Atributos
Não se aplica.
5.2.5 Conjunto de Restrições de Algoritmos
Os processos para criação e verificação de assinaturas segundo esta PA devem utilizar os
algoritmos:
a) Sha1(1 3 14 3 2 26)
b) Sha1withRSAEncryption(1 2 840 113549 1 1 5)
c) RsaEncryption(1 2 840 113549 1 1 1) com minKeyLength=1024
5.2.6 Regras Adicionais
Não se aplica.
5.3 Regras para Propósitos Específicos de Assinatura
Não se aplica.
5.4 Informações Adicionais sobre a Validação das Assinaturas
Não se aplica.
6. Informações Adicionais sobre a Política de Assinatura
Não se aplica.
E - POLÍTICA-PADRÃO ICP-BRASIL AD-A PARA PARA
ASSINATURAS BASEADAS EM CMS / CADES
1. Identificador da Política de Assinatura
O nome desta Política de Assinatura é POLÍTICA ICP-BRASIL PARA ASSINATURA DIGITAL
COM INFORMAÇÕES PARA ARQUIVAMENTO NO FORMATO CMS, versão 1.0.
O Object Identifier (OID) desta PA, atribuído pelo ITI é: 2.16.76.1.7.1.5.1. Novas versões desta
política, se criadas, receberão OID diferenciado, do tipo 2.16.76.1.7.1.5.n+1.
Esta PA está protegida contra alterações indevidas por meio da publicação, no repositório da AC
Raiz da ICP-Brasil (http://www.iti.gov.br/twiki/bin/view/Certificacao/RepositoriodaACRaiz), do
seu conteúdo assinado digitalmente por chave privada associada a certificado digital do Instituto
Nacional de Tecnologia da Informação, utilizando algoritmo Sha1withRSAEncryption(1 2 840
113549 1 1 5).
2. Data da Criação
A data de criação desta PA é 31.10.2008.
3. Entidade Criadora da Política de Assinatura
A entidade criadora desta PA é o Instituto Nacional de Tecnologia da Informação (ITI). Ela pode
ser utilizada por qualquer pessoa física ou jurídica, órgão de governo ou outro tipo de entidade, sem
restrições.
4. Campo de Aplicação
digital assinado por longos períodos, sabendo-se que podem surgir fraquezas, vulnerabilidades ou
exposição a fragilidades dos algoritmos, funções e chaves criptográficas utilizadas no processo de
geração de assinatura digital.
Ele provê proteção contra fraqueza dos algoritmos, funções e tamanho de chaves criptográficas,
desde que o carimbo de tempo de arquivamento seja realizado tempestivamente e utilize algoritmos,
funções e tamanhos de chave considerados seguros no momento de sua geração.
Além disso, oferece segurança quanto à irretratabilidade, e permite que se verifique a validade da
assinatura digital mesmo que ocorra comprometimento da chave privada da AC que emitiu o
certificado do signatário (desde que o carimbo de tempo sobre as referências/valores dos
certificados tenha sido colocado antes desse comprometimento).
Segundo esta PA, é permitido o emprego de múltiplas assinaturas.
5. Política de Validação da Assinatura
Os campos a seguir definem os processos para geração e verificação de assinaturas realizadas
segundo esta PA.
5.1 Período para Assinatura
Esta PA terá validade desde a data de publicação até 31.12.2010.
5.2 Regras Comuns
5.2.1 Regras de Signatário e Verificador
5.2.1.1 Regras do Signatário
5.2.1.1.1 Dados Externos ou Internos a Assinatura
As assinaturas realizadas segundo esta PA podem ou não incluir o conteúdo assinado na assinatura
digital (attached, ou detached).
5.2.1.1.2 Atributos Assinados Obrigatórios
As assinaturas feitas segundo esta PA devem conter, obrigatoriamente, os seguintes atributos
assinados:
a) Id-contentType
b) Id-messageDigest
g) id-aa-signingCertificate ou Id-aa-signingCertificateV2
c) Id-aa-ets-sigPolicyId
5.2.1.1.3 Atributos Não-Assinados Obrigatórios
a) id-aa-signatureTimeStampToken
b) id-aa-ets-certificateRefs
c) id-aa-ets-revocationRefs
d) id-aa-ets-certValues
e) id-aa-ets-revocationValues
f) id-aa-ets-archiveTimestamp
5.2.1.1.4 Referências à Cadeia de Certificação
O atributo signingCertificate deve conter apenas referência ao certificado do signatário, por meio do
Identificador Serial do Emissor e do hash do certificado.
5.2.1.1.5 Valores da Cadeia de Certificação
Não se aplica.
5.2.1.1.6 Regras Adicionais do Signatário
Na utilização de múltiplas assinaturas, todas elas devem empregar os mesmos algoritmos definidos
no item 5.2.5. As formas possíveis de múltiplas assinaturas são:
a) Paralelas: quando a ordem de inserção das assinaturas não é importante; ou
b) Contra-assinaturas: quando a ordem de aplicação das assinaturas é relevante, ou seja,
quando a função da segunda assinatura é, no mínimo, atestar o recebimento do
documento com a primeira assinatura já presente.
No caso de assinaturas paralelas haverá múltiplas estruturas SignerInfo.
Para contra-assinaturas, deverão ser empregados atributos Id-countersignature.
Para a indicação do tipo de comprometimento devem ser empregados aqueles tipos definidos no
Anexo 1 do DOC-ICP-15.01.
Deve-se utilizar a codificação MIME para o valor do campo eContent da estrutura
EncapsulatedContentInfo, e o MIME type para identificação do formato de apresentação dos dados.
O signatário é responsável por se certificar que o documento assinado não contém qualquer
conteúdo dinâmico capaz de modificar o resultado do documento visualizado ao longo do tempo,
como, por exemplo, quantias ou sentenças que se alteram após certa data.
5.2.1.2 Regras do Verificador
5.2.1.2.1 Atributos Não-Assinados Obrigatórios
Caso não tenham sido incluídos pelo signatário, os seguintes atributos DEVEM ser incluídos pelo
verificador:
a) id-aa-signatureTimeStampToken
b) id-aa-ets-certificateRefs
c) id-aa-ets-revocationRefs
d) id-aa-ets-certValues
e) id-aa-ets-revocationValues
f) id-aa-ets-archiveTimestamp
5.2.1.2.2 Regras Adicionais do Verificador
Caso esteja presente mais de uma assinatura, aposta ao mesmo documento assinado, deve-se validar
cada assinatura encontrada independentemente, segundo o item 5.2.1.1
5.2.2 Condições de Confiabilidade dos Certificados dos Signatários
5.2.2.1 Validação da Cadeia de Certificação
5.2.2.1.1 Raiz Confiável
A validação deve ser feita tomando como ponto de confiança os certificados da AC-Raiz da ICP-
Brasil, disponíveis em
http://acraiz.icpbrasil.gov.br/CertificadoACRaiz.crt e
http://acraiz.icpbrasil.gov.br/ICP-Brasil.crt
5.2.2.1.2 Restrição do Caminho de Certificação
O número máximo de certificados de ACs, no caminho de certificação, entre o certificado do
signatário e a AC-Raiz é 2 (dois).
5.2.2.1.3 Conjunto de Políticas de Certificado Aceitável
Assinaturas digitais geradas segundo esta Política de Assinatura deverão ser criadas com chave
privada associada a certificados ICP-Brasil tipo A3 (cujo OID é 2.16.76.1.2.3.n) ou A4 (cujo OID é
2.16.76.1.2.4.n), conforme definido no DOC-ICP-04.
5.2.2.1.4 Restrições de Nome
Não se aplica.
5.2.2.1.5 Restrições de Políticas de Certificado
Não se aplica.
5.2.2.1.6 Forma de Verificação do Status da Cadeia de Certificação (Revogação)
Tanto para o certificado do signatário quanto para os certificados das Autoridades Certificadoras da
cadeia de certificação a verificação do status dos certificados deve ser realizada através de LCRs
(Lista de Certificados Revogados) em conformidade com o perfil de LCR definido no documento
DOC-ICP-04 ou através de consultas OCSP (Online Certificate Status Protocol) em conformidade
com a RFC 2560 ou algum outro método presente em DOC-ICP-04.
O método mínimo aplicável deve ser a verificação por LCR.
5.2.3 Condições de Confiabilidade do Carimbo de Tempo
5.2.3.1 Validação da Cadeia de Certificação
5.2.3.1.1 Raiz Confiável
A validação da assinatura constante no carimbo de tempo deve ser feita tomando como ponto de
confiança os certificados da AC-Raiz da ICP-Brasil, disponíveis em
http://acraiz.icpbrasil.gov.br/CertificadoACRaiz.crt e http://acraiz.icpbrasil.gov.br/ICP-Brasil.crt
5.2.3.1.2 Restrição do Caminho de Certificação
O número máximo de certificados de ACs, no caminho de certificação, entre o certificado do
equipamento emissor do carimbo de tempo (SCT) e a AC-Raiz é 2 (dois).
5.2.3.1.3 Conjunto de Políticas de Certificado Aceitável
Os carimbos de tempo deverão ser criados com chave privada associada a certificados ICP-Brasil
tipo T3 (cujo OID é 2.16.76.1.2.303.n) ou T4 (cujo OID é 2.16.76.1.2.304.n), conforme definido no
DOC-ICP-04.
5.2.3.1.4 Restrições de Nome
Não se aplica.
5.2.3.1.5 Restrições de Políticas de Certificado
Não se aplica.
5.2.3.1.6 Forma de Verificação do Status da Cadeia de Certificação (Revogação)
Tanto para o certificado do SCT quanto para os certificados das Autoridades Certificadoras da
cadeia de certificação, a verificação do status deve ser realizada através de LCRs (Lista de
Certificados Revogados) em conformidade com o perfil de LCR definido no documento DOC-ICP-
04 ou através de consultas OCSP (Online Certificate Status Protocol) em conformidade com a RFC
2560 ou algum outro método presente em DOC-ICP-04.
O método mínimo aplicável deve ser a verificação por LCR.
5.2.3.3 Restrições de Nome
Não se aplica.
5.2.3.4 Período de Cautela
Não se aplica.
5.2.3.5 Atraso do Carimbo de Tempo
Não se aplica.
5.2.4 Condições de Confiabilidade dos Atributos
Não se aplica.
5.2.5 Conjunto de Restrições de Algoritmos
Os processos para criação e verificação de assinaturas segundo esta PA devem utilizar os
algoritmos:
a) Sha1(1 3 14 3 2 26)
b) Sha1withRSAEncryption(1 2 840 113549 1 1 5)
c) RsaEncryption(1 2 840 113549 1 1 1) com minKeyLength=1024
5.2.6 Regras Adicionais
Não se aplica.
5.3 Regras para Propósitos Específicos de Assinatura
Não se aplica.
5.4 Informações Adicionais sobre a Validação das Assinaturas
Não se aplica.
6. Informações Adicionais sobre a Política de Assinatura
Não se aplica.
F - POLÍTICA-PADRÃO ICP-BRASIL AD-CP PARA ASSINATURAS
BASEADAS EM XMLDSIG / XADES
1. Identificador da Política de Assinatura
O nome desta Política de Assinatura é POLÍTICA ICP-BRASIL PARA ASSINATURA DIGITAL
DE CURTO PRAZO NO FORMATO XMLdSIG versão 1.0.
O Object Identifier (OID) desta PA, atribuído pelo ITI é: 2.16.76.1.7.1.6.1. Novas versões desta
política, se criadas, receberão OID diferenciado, do tipo 2.16.76.1.7.1.6.n+1.
Esta PA está protegida contra alterações indevidas por meio da publicação, no repositório da AC
Raiz da ICP-Brasil (http://www.iti.gov.br/twiki/bin/view/Certificacao/RepositoriodaACRaiz), do
seu conteúdo assinado digitalmente por chave privada associada a certificado digital do Instituto
Nacional de Tecnologia da Informação, utilizando algoritmo Sha1withRSAEncryption(1 2 840
113549 1 1 5).
2. Data da Criação
A data de criação desta PA é 31.10.2008.
3. Entidade Criadora da Política de Assinatura
A entidade criadora desta PA é o Instituo Nacional de Tecnologia da Informação (ITI). Ela pode ser
utilizada por qualquer pessoa física ou jurídica, órgão de governo ou outro tipo de entidade, sem
restrições.
4. Campo de Aplicação
Neste tipo de assinatura não são armazenados os dados fundamentais para sua validação futura e
nem é colocado carimbo de tempo de assinatura. Como não existem condições de garantir a
irretratabilidade da assinatura digital, este tipo de assinatura não pode ser usado para arbitragem, em
caso de disputa entre signatário e verificador.
Por esse motivo, assinaturas do tipo AD-CP somente devem ser utilizadas em situações especiais,
por exemplo, para serviços transacionais que exigem autenticação de entidades e/ou
verificação de integridade.
Caso seja necessário verficar a assinatura posteriormente devem existam ferramentas adicionais
para isso. As informações de validação deverão poder ser obtidas por outras fontes, como o sistema
operacional da parte verificadora, por exemplo. Nessas situações, é recomendável que exista um
acordo prévio, assinado por ambas as partes, signatário e verificador, concordando com a guarda
unilateral desses dados complementares.
Segundo esta PA, é permitido o emprego de múltiplas assinaturas.
5. Política de Validação da Assinatura
Os campos a seguir definem os processos para geração e verificação de assinaturas realizadas
segundo esta PA.
5.1 Período para Assinatura
Esta PA terá validade desde a data de publicação até 31.12.2010.
5.2 Regras Comuns
5.2.1 Regras de Signatário e Verificador
5.2.1.1 Regras do Signatário
5.2.1.1.1 Dados Externos ou Internos a Assinatura
As assinaturas regulamentadas por esta PA podem ser realizadas usando uma das seguintes
representações:
a) Estrutura assinada com conteúdo digital separado (detached);
b) Estrutura assinada com conteúdo digital anexado (enveloping);
c) Estrutura assinada incluída no conteúdo digital (enveloped).
5.2.1.1.2 Propriedades Assinadas Obrigatórias
As assinaturas feitas segundo esta PA definem como obrigatórias as seguintes propriedades
assinadas:
a) DataObjectFormat (em assinaturas do tipo detached);
b) SigningCertificate;
c) SignaturePolicyIdentifier.
5.2.1.1.3 Propriedades Não-Assinadas Obrigatórias
Não se aplica.
5.2.1.1.4 Referências à Cadeia de Certificação
A propriedade SigningCertificate deve conter apenas referência ao certificado do signatário, por
meio do Identificador Serial do Emissor e do hash do certificado.
5.2.1.1.5 Valores da Cadeia de Certificação
Não se aplica.
5.2.1.1.6 Regras Adicionais do Signatário
Na utilização de múltiplas assinaturas, todas elas devem empregar os mesmos algoritmos definidos
no item 5.2.5. As formas possíveis de múltiplas assinaturas são:
a) Paralelas: quando a ordem de inserção das assinaturas não é importante; ou
b) Contra-assinaturas: quando a ordem de aplicação das assinaturas é relevante, ou seja,
quando a função da segunda assinatura é, no mínimo, atestar o recebimento do
documento com a primeira assinatura já presente.
No caso de assinaturas paralelas haverá múltiplas assinaturas XMLDSIG referenciado o mesmo
documento por meio do elemento ds:Reference.
Para contra-assinaturas, deverão ser empregadas propriedades xades:CounterSignature.
Para a indicação do tipo de comprometimento devem ser empregados aqueles tipos definidos no
Anexo 1 do DOC-ICP-15.01.
A identificação do formato de apresentação dos dados deve ser realizada por meio da propriedade
MimeType da propriedade DataObjectFormat.
O signatário é responsável por se certificar que o documento assinado não contém qualquer
conteúdo dinâmico capaz de modificar o resultado do documento visualizado ao longo do tempo,
como, por exemplo, quantias ou sentenças que se alteram após certa data.
5.2.1.2 Regras do Verificador
5.2.1.2.1 Atributos Não-Assinados Obrigatórios
Não se aplica.
5.2.1.2.2 Regras Adicionais do Verificador
Caso esteja presente mais de uma assinatura, aposta ao mesmo documento assinado, deve-se validar
cada assinatura encontrada independentemente, segundo o item 5.2.1.1
5.2.2 Condições de Confiabilidade dos Certificados dos Signatários
5.2.2.1 Validação da Cadeia de Certificação
5.2.2.1.1 Raiz Confiável
A validação deve ser feita tomando como ponto de confiança os certificados da AC-Raiz da ICP-
Brasil, disponíveis em http://acraiz.icpbrasil.gov.br/CertificadoACRaiz.crt e
http://acraiz.icpbrasil.gov.br/ICP-Brasil.crt
5.2.2.1.2 Restrição do Caminho de Certificação
O número máximo de certificados de ACs, no caminho de certificação, entre o certificado do
signatário e a AC-Raiz é 2 (dois).
5.2.2.1.3 Conjunto de Políticas de Certificado Aceitável
Assinaturas digitais geradas segundo esta Política de Assinatura deverão ser criadas com chave
privada associada ao certificado ICP-Brasil tipo A3, com OID 2.16.76.1.2.3.n, ou A4, com OID
2.16.76.1.2.4.n, conforme definido em DOC-ICP-04.
5.2.2.1.4 Restrições de Nome
Não se aplica.
5.2.2.1.5 Restrições de Políticas de Certificado
Não se aplica.
5.2.2.1.6 Forma de Verificação do Status da Cadeia de Certificação (Revogação)
Tanto para o certificado do signatário quanto para os certificados das Autoridades Certificadoras da
cadeia de certificação a verificação do status dos certificados deve ser realizada através de LCRs
(Lista de Certificados Revogados) em conformidade com o perfil de LCR definido no documento
DOC-ICP-04 ou através de consultas OCSP (Online Certificate Status Protocol) em conformidade
com a RFC 2560 ou algum outro método presente em DOC-ICP-04.
O método mínimo aplicável deve ser a verificação por LCR.
5.2.3 Condições de Confiabilidade do Carimbo de Tempo
Não se aplica
5.2.4 Condições de Confiabilidade dos Atributos
Não se aplica.
5.2.5 Conjunto de Restrições de Algoritmos
Os processos para criação e verificação de assinaturas segundo esta PA devem utilizar os
algoritmos:
a) Sha1(1 3 14 3 2 26)
b) Sha1withRSAEncryption(1 2 840 113549 1 1 5)
c) RsaEncryption(1 2 840 113549 1 1 1) com minKeyLength=1024
5.2.6 Regras Adicionais
Não se aplica.
5.3 Regras para Propósitos Específicos de Assinatura
Não se aplica.
5.4 Informações Adicionais sobre a Validação das Assinaturas
Não se aplica.
6. Informações Adicionais sobre a Política de Assinatura
Não se aplica.
G - POLÍTICA-PADRÃO ICP-BRASIL AD-T PARA ASSINATURAS
BASEADAS EM XMLDSIG / XADES
1. Identificador da Política de Assinatura
O nome desta Política de Assinatura é POLÍTICA ICP-BRASIL PARA ASSINATURA DIGITAL
COM CARIMBO DE TEMPO NO FORMATO XMLdSIG versão 1.0.
O Object Identifier (OID) desta PA, atribuído pelo ITI é: 2.16.76.1.7.1.7.1. Novas versões desta
política, se criadas, receberão OID diferenciado, do tipo 2.16.76.1.7.1.7.n+1.
Esta PA está protegida contra alterações indevidas por meio da publicação, no repositório da AC
Raiz da ICP-Brasil (http://www.iti.gov.br/twiki/bin/view/Certificacao/RepositoriodaACRaiz), do
seu conteúdo assinado digitalmente por chave privada associada a certificado digital do Instituto
Nacional de Tecnologia da Informação, utilizando algoritmo Sha1withRSAEncryption(1 2 840
113549 1 1 5).
2. Data da Criação
A data de criação desta PA é 31.10.2008.
3. Entidade Criadora da Política de Assinatura
A entidade criadora desta PA é o Instituo Nacional de Tecnologia da Informação (ITI). Ela pode ser
utilizada por qualquer pessoa física ou jurídica, órgão de governo ou outro tipo de entidade, sem
restrições.
4. Campo de Aplicação
Este tipo de assinatura deve ser utilizado em aplicações ou processos de negócios nos quais a
assinatura digital necessita de segurança em relação à irretratabilidade de sua geração, pois o
carimbo de tempo serve como evidência de que o certificado do signatário não estava revogado ou
expirado no momento da assinatura.
Como esse tipo de assinatura não traz, de forma auto-contida, referências ou valores dos
certificados e das informações de revogação (LCRs ou respostas OCSP) necessários para sua
validação posterior, ele deve ser utilizado somente quando esses dados puderem ser obtidos por
meios externos, de forma inequívoca. Mesmo assim, uma assinatura desse tipo pode ser contestada
se houver, por exemplo, o comprometimento da chave da AC que emitiu qualquer um dos
certificados da cadeia de certificação.
Segundo esta PA, é permitido o emprego de múltiplas assinaturas.
5. Política de Validação da Assinatura
Os campos a seguir definem os processos para geração e verificação de assinaturas realizadas
segundo esta PA.
5.1 Período para Assinatura
Esta PA terá validade desde a data de publicação até 31.12.2010.
5.2 Regras Comuns
5.2.1 Regras de Signatário e Verificador
5.2.1.1 Regras do Signatário
5.2.1.1.1 Dados Externos ou Internos a Assinatura
As assinaturas regulamentadas por esta PA podem ser realizadas usando uma das seguintes
representações:
a) Estrutura assinada com conteúdo digital separado (detached);
b) Estrutura assinada com conteúdo digital anexado (enveloping);
c) Estrutura assinada incluída no conteúdo digital (enveloped).
5.2.1.1.2 Propriedades Assinadas Obrigatórias
As assinaturas feitas segundo esta PA definem como obrigatórias as seguintes propriedades
assinadas:
a) DataObjectFormat (em assinaturas do tipo detached);
b) SigningCertificate;
c) SignaturePolicyIdentifier.
5.2.1.1.3 Propriedades Não-Assinadas Obrigatórias
a) SignatureTimeStamp
5.2.1.1.4 Referências à Cadeia de Certificação
A propriedade SigningCertificate deve conter apenas referência ao certificado do signatário, por
meio do Identificador Serial do Emissor e do hash do certificado.
5.2.1.1.5 Valores da Cadeia de Certificação
Não se aplica.
5.2.1.1.6 Regras Adicionais do Signatário
Na utilização de múltiplas assinaturas, todas elas devem empregar os mesmos algoritmos definidos
no item 5.2.5. As formas possíveis de múltiplas assinaturas são:
Paralelas: quando a ordem de inserção das assinaturas não é importante; ou
Contra-assinaturas: quando a ordem de aplicação das assinaturas é relevante, ou seja, quando a
função da segunda assinatura é, no mínimo, atestar o recebimento do documento com a primeira
assinatura já presente.
No caso de assinaturas paralelas haverá múltiplas assinaturas XMLDSIG referenciado o mesmo
documento por meio do elemento ds:Reference.
Para contra-assinaturas, deverão ser empregadas propriedades xades:CounterSignature.
Para a indicação do tipo de comprometimento devem ser empregados aqueles tipos definidos no
Anexo 1 do DOC-ICP-15.01.
A identificação do formato de apresentação dos dados deve ser realizada por meio da propriedade
MimeType da propriedade DataObjectFormat.
O signatário é responsável por se certificar que o documento assinado não contém qualquer
conteúdo dinâmico capaz de modificar o resultado do documento visualizado ao longo do tempo,
como, por exemplo, quantias ou sentenças que se alteram após certa data.
5.2.1.2 Regras do Verificador
5.2.1.2.1 Propriedades Não-Assinadas Obrigatórias
Caso não tenha sido incluída pelo signatário, a seguinte propriedade DEVE ser incluída pelo
verificador:
a) SignatureTimeStamp
5.2.1.2.2 Regras Adicionais do Verificador
Caso esteja presente mais de uma assinatura, aposta ao mesmo documento assinado, deve-se validar
cada assinatura encontrada independentemente, segundo o item 5.2.1.1
5.2.2 Condições de Confiabilidade dos Certificados dos Signatários
5.2.2.1 Validação da Cadeia de Certificação
5.2.2.1.1 Raiz Confiável
A validação deve ser feita tomando como ponto de confiança os certificados da AC-Raiz da ICP-
Brasil, disponíveis em http://acraiz.icpbrasil.gov.br/CertificadoACRaiz.crt e
http://acraiz.icpbrasil.gov.br/ICP-Brasil.crt
5.2.2.1.2 Restrição do Caminho de Certificação
O número máximo de certificados de ACs, no caminho de certificação, entre o certificado do
signatário e a AC-Raiz é 2 (dois).
5.2.2.1.3 Conjunto de Políticas de Certificado Aceitável
Assinaturas digitais geradas segundo esta Política de Assinatura deverão ser criadas com chave
privada associada ao certificado ICP-Brasil tipo A3, com OID 2.16.76.1.2.3.n, ou A4, com OID
2.16.76.1.2.4.n, conforme definido em DOC-ICP-04.
5.2.2.1.4 Restrições de Nome
Não se aplica.
5.2.2.1.5 Restrições de Políticas de Certificado
Não se aplica.
5.2.2.1.6 Forma de Verificação do Status da Cadeia de Certificação (Revogação)
Tanto para o certificado do signatário quanto para os certificados das Autoridades Certificadoras da
cadeia de certificação a verificação do status dos certificados deve ser realizada através de LCRs
(Lista de Certificados Revogados) em conformidade com o perfil de LCR definido no documento
DOC-ICP-04 ou através de consultas OCSP (Online Certificate Status Protocol) em conformidade
com a RFC 2560 ou algum outro método presente em DOC-ICP-04.
O método mínimo aplicável deve ser a verificação por LCR.
5.2.3 Condições de Confiabilidade do Carimbo de Tempo
5.2.3.1 Validação da Cadeia de Certificação
5.2.3.1.1 Raiz Confiável
A validação da assinatura constante no carimbo de tempo deve ser feita tomando como ponto de
confiança os certificados da AC-Raiz da ICP-Brasil, disponíveis em
http://acraiz.icpbrasil.gov.br/CertificadoACRaiz.crt e http://acraiz.icpbrasil.gov.br/ICP-Brasil.crt
5.2.3.1.2 Restrição do Caminho de Certificação
O número máximo de certificados de ACs, no caminho de certificação, entre o certificado do
equipamento emissor do carimbo de tempo (SCT) e a AC-Raiz é 2 (dois).
5.2.3.1.3 Conjunto de Políticas de Certificado Aceitável
Os carimbos de tempo deverão ser criados com chave privada associada a certificados ICP-Brasil
tipo T3 (cujo OID é 2.16.76.1.2.303.n) ou T4 (cujo OID é 2.16.76.1.2.304.n), conforme definido no
DOC-ICP-04.
5.2.3.1.4 Restrições de Nome
Não se aplica.
5.2.3.1.5 Restrições de Políticas de Certificado
Não se aplica.
5.2.3.1.6 Forma de Verificação do Status da Cadeia de Certificação (Revogação)
Tanto para o certificado do SCT quanto para os certificados das Autoridades Certificadoras da
cadeia de certificação, a verificação do status deve ser realizada através de LCRs (Lista de
Certificados Revogados) em conformidade com o perfil de LCR definido no documento DOC-ICP-
04 ou através de consultas OCSP (Online Certificate Status Protocol) em conformidade com a RFC
2560 ou algum outro método presente em DOC-ICP-04.
O método mínimo aplicável deve ser a verificação por LCR.
5.2.3.3 Restrições de Nome
Não se aplica.
5.2.3.4 Período de Cautela
Não se aplica.
5.2.3.5 Atraso do Carimbo de Tempo
Não se aplica.
5.2.4 Condições de Confiabilidade dos Atributos
Não se aplica.
5.2.5 Conjunto de Restrições de Algoritmos
Os processos para criação e verificação de assinaturas segundo esta PA devem utilizar os
algoritmos:
a) Sha1(1 3 14 3 2 26)
b) Sha1withRSAEncryption(1 2 840 113549 1 1 5)
c) RsaEncryption(1 2 840 113549 1 1 1) com minKeyLength=1024
5.2.6 Regras Adicionais
Não se aplica.
5.3 Regras para Propósitos Específicos de Assinatura
Não se aplica.
5.4 Informações Adicionais sobre a Validação das Assinaturas
Não se aplica.
6. Informações Adicionais sobre a Política de Assinatura
Não se aplica.
H - POLÍTICA-PADRÃO ICP-BRASIL AD-R PARA ASSINATURAS
BASEADAS EM XMLDSIG / XADES
1. Identificador da Política de Assinatura
O nome desta Política de Assinatura é POLÍTICA ICP-BRASIL PARA ASSINATURA DIGITAL
COM REFERÊNCIAS PARA VALIDAÇÃO NO FORMATO XMLdSIG versão 1.0.
O Object Identifier (OID) desta PA, atribuído pelo ITI é: 2.16.76.1.7.1.8.1. Novas versões desta
política, se criadas, receberão OID diferenciado, do tipo 2.16.76.1.7.1.8.n+1.
Esta PA está protegida contra alterações indevidas por meio da publicação, no repositório da AC
Raiz da ICP-Brasil (http://www.iti.gov.br/twiki/bin/view/Certificacao/RepositoriodaACRaiz), do
seu conteúdo assinado digitalmente por chave privada associada a certificado digital do Instituto
Nacional de Tecnologia da Informação, utilizando algoritmo Sha1withRSAEncryption(1 2 840
113549 1 1 5).
2. Data da Criação
A data de criação desta PA é 31.10.2008.
3. Entidade Criadora da Política de Assinatura
A entidade criadora desta PA é o Instituo Nacional de Tecnologia da Informação (ITI). Ela pode ser
utilizada por qualquer pessoa física ou jurídica, órgão de governo ou outro tipo de entidade, sem
restrições.
4. Campo de Aplicação
Este tipo de assinatura inclui, no seu próprio corpo, referências sobre os certificados que compõem
a cadeia de certificação e sobre as informações de revogação do certificado digital do signatário.
Um carimbo de tempo provê a ligação entre essas informações e o conteúdo assinado.
Ele deve ser usado em aplicações onde se necessita verificar a assinatura a qualquer momento e
onde os dados necessários para isso (que estão referenciados no corpo da assinatura), estejam
disponíveis para recuperação.
Além de oferecer segurança quanto à irretratabilidade, ele permite que se verifique a validade da
assinatura digital mesmo que ocorra comprometimento da chave privada da AC que emitiu o
certificado do signatário, desde que o carimbo de tempo sobre as referências tenha sido colocado
antes desse comprometimento.
Segundo esta PA, é permitido o emprego de múltiplas assinaturas.
5. Política de Validação da Assinatura
Os campos a seguir definem os processos para geração e verificação de assinaturas realizadas
segundo esta PA.
5.1 Período para Assinatura
Esta PA terá validade desde a data de publicação até 31.12.2010.
5.2 Regras Comuns
5.2.1 Regras de Signatário e Verificador
5.2.1.1 Regras do Signatário
5.2.1.1.1 Dados Externos ou Internos a Assinatura
As assinaturas regulamentadas por esta PA podem ser realizadas usando uma das seguintes
representações:
a) Estrutura assinada com conteúdo digital separado (detached);
b) Estrutura assinada com conteúdo digital anexado (enveloping);
c) Estrutura assinada incluída no conteúdo digital (enveloped).
5.2.1.1.2 Propriedades Assinadas Obrigatórias
As assinaturas feitas segundo esta PA definem como obrigatórias as seguintes propriedades
assinadas:
i. DataObjectFormat (em assinaturas do tipo detached);
ii. SigningCertificate;
iii. SignaturePolicyIdentifier.
5.2.1.1.3 Propriedades Não-Assinadas Obrigatórias
a) SignatureTimeStamp
b) CompleteCertificateRefs
c) CompleteRevocationRefs
d) SigAndRefsTimeStamp
5.2.1.1.4 Referências à Cadeia de Certificação
A propriedade SigningCertificate deve conter apenas referência ao certificado do signatário, por
meio do Identificador Serial do Emissor e do hash do certificado.
5.2.1.1.5 Valores da Cadeia de Certificação
Não se aplica.
5.2.1.1.6 Regras Adicionais do Signatário
Na utilização de múltiplas assinaturas, todas elas devem empregar os mesmos algoritmos definidos
no item 5.2.5. As formas possíveis de múltiplas assinaturas são:
a) Paralelas: quando a ordem de inserção das assinaturas não é importante; ou
b) Contra-assinaturas: quando a ordem de aplicação das assinaturas é relevante, ou seja,
quando a função da segunda assinatura é, no mínimo, atestar o recebimento do
documento com a primeira assinatura já presente.
No caso de assinaturas paralelas haverá múltiplas assinaturas XMLDSIG referenciado o mesmo
documento por meio do elemento ds:Reference.
Para contra-assinaturas, deverão ser empregadas propriedades xades:CounterSignature.
Para a indicação do tipo de comprometimento devem ser empregados aqueles tipos definidos no
Anexo 1 do DOC-ICP-15.01.
A identificação do formato de apresentação dos dados deve ser realizada por meio da propriedade
MimeType da propriedade DataObjectFormat.
O signatário é responsável por se certificar que o documento assinado não contém qualquer
conteúdo dinâmico capaz de modificar o resultado do documento visualizado ao longo do tempo,
como, por exemplo, quantias ou sentenças que se alteram após certa data.
5.2.1.2 Regras do Verificador
5.2.1.2.1 Propriedades Não-Assinadas Obrigatórias
Caso não tenham sido incluídas pelo signatário, as seguintes propriedades DEVEM ser incluídas
pelo verificador:
a) SignatureTimeStamp
b) CompleteCertificateRefs
c) CompleteRevocationRefs
d) SigAndRefsTimeStamp
5.2.1.2.2 Regras Adicionais do Verificador
Caso esteja presente mais de uma assinatura, aposta ao mesmo documento assinado, deve-se validar
cada assinatura encontrada independentemente, segundo o item 5.2.1.1
5.2.2 Condições de Confiabilidade dos Certificados dos Signatários
5.2.2.1 Validação da Cadeia de Certificação
5.2.2.1.1 Raiz Confiável
A validação deve ser feita tomando como ponto de confiança os certificados da AC-Raiz da ICP-
Brasil, disponíveis em http://acraiz.icpbrasil.gov.br/CertificadoACRaiz.crt e
http://acraiz.icpbrasil.gov.br/ICP-Brasil.crt
5.2.2.1.2 Restrição do Caminho de Certificação
O número máximo de certificados de ACs, no caminho de certificação, entre o certificado do
signatário e a AC-Raiz é 2 (dois).
5.2.2.1.3 Conjunto de Políticas de Certificado Aceitável
Assinaturas digitais geradas segundo esta Política de Assinatura deverão ser criadas com chave
privada associada ao certificado ICP-Brasil tipo A3, com OID 2.16.76.1.2.3.n, ou A4, com OID
2.16.76.1.2.4.n, conforme definido em DOC-ICP-04.
5.2.2.1.4 Restrições de Nome
Não se aplica.
5.2.2.1.5 Restrições de Políticas de Certificado
Não se aplica.
5.2.2.1.6 Forma de Verificação do Status da Cadeia de Certificação (Revogação)
Tanto para o certificado do signatário quanto para os certificados das Autoridades Certificadoras da
cadeia de certificação a verificação do status dos certificados deve ser realizada através de LCRs
(Lista de Certificados Revogados) em conformidade com o perfil de LCR definido no documento
DOC-ICP-04 ou através de consultas OCSP (Online Certificate Status Protocol) em conformidade
com a RFC 2560 ou algum outro método presente em DOC-ICP-04.
O método mínimo aplicável deve ser a verificação por LCR.
5.2.3 Condições de Confiabilidade do Carimbo de Tempo
5.2.3.1 Validação da Cadeia de Certificação
5.2.3.1.1 Raiz Confiável
A validação da assinatura constante no carimbo de tempo deve ser feita tomando como ponto de
confiança os certificados da AC-Raiz da ICP-Brasil, disponíveis em
http://acraiz.icpbrasil.gov.br/CertificadoACRaiz.crt e http://acraiz.icpbrasil.gov.br/ICP-Brasil.crt
5.2.3.1.2 Restrição do Caminho de Certificação
O número máximo de certificados de ACs, no caminho de certificação, entre o certificado do
equipamento emissor do carimbo de tempo (SCT) e a AC-Raiz é 2 (dois).
5.2.3.1.3 Conjunto de Políticas de Certificado Aceitável
Os carimbos de tempo deverão ser criados com chave privada associada a certificados ICP-Brasil
tipo T3 (cujo OID é 2.16.76.1.2.303.n) ou T4 (cujo OID é 2.16.76.1.2.304.n), conforme definido no
DOC-ICP-04.
5.2.3.1.4 Restrições de Nome
Não se aplica.
5.2.3.1.5 Restrições de Políticas de Certificado
Não se aplica.
5.2.3.1.6 Forma de Verificação do Status da Cadeia de Certificação (Revogação)
Tanto para o certificado do SCT quanto para os certificados das Autoridades Certificadoras da
cadeia de certificação, a verificação do status deve ser realizada através de LCRs (Lista de
Certificados Revogados) em conformidade com o perfil de LCR definido no documento DOC-ICP-
04 ou através de consultas OCSP (Online Certificate Status Protocol) em conformidade com a RFC
2560 ou algum outro método presente em DOC-ICP-04.
O método mínimo aplicável deve ser a verificação por LCR.
5.2.3.3 Restrições de Nome
Não se aplica.
5.2.3.4 Período de Cautela
Não se aplica.
5.2.3.5 Atraso do Carimbo de Tempo
Não se aplica.
5.2.4 Condições de Confiabilidade dos Atributos
Não se aplica.
5.2.5 Conjunto de Restrições de Algoritmos
Os processos para criação e verificação de assinaturas segundo esta PA devem utilizar os
algoritmos:
a) Sha1(1 3 14 3 2 26)
b) Sha1withRSAEncryption(1 2 840 113549 1 1 5)
c) RsaEncryption(1 2 840 113549 1 1 1) com minKeyLength=1024
5.2.6 Regras Adicionais
Não se aplica.
5.3 Regras para Propósitos Específicos de Assinatura
Não se aplica.
5.4 Informações Adicionais sobre a Validação das Assinaturas
Não se aplica.
6. Informações Adicionais sobre a Política de Assinatura
Não se aplica.
I - POLÍTICA-PADRÃO ICP-BRASIL AD-C PARA ASSINATURAS
BASEADAS EM XMLDSIG / XADES
1. Identificador da Política de Assinatura
O nome desta Política de Assinatura é POLÍTICA ICP-BRASIL PARA ASSINATURA DIGITAL
COM INFORMAÇÕES COMPLETAS NO FORMATO XMLdSIG versão 1.0.
O Object Identifier (OID) desta PA, atribuído pelo ITI é: 2.16.76.1.7.1.9.1. Novas versões desta
política, se criadas, receberão OID diferenciado, do tipo 2.16.76.1.7.1.9.n+1.
Esta PA está protegida contra alterações indevidas por meio da publicação, no repositório da AC
Raiz da ICP-Brasil (http://www.iti.gov.br/twiki/bin/view/Certificacao/RepositoriodaACRaiz), do
seu conteúdo assinado digitalmente por chave privada associada a certificado digital do Instituto
Nacional de Tecnologia da Informação, utilizando algoritmo Sha1withRSAEncryption(1 2 840
113549 1 1 5).
2. Data da Criação
A data de criação desta PA é 31.10.2008.
3. Entidade Criadora da Política de Assinatura
A entidade criadora desta PA é o Instituo Nacional de Tecnologia da Informação (ITI). Ela pode ser
utilizada por qualquer pessoa física ou jurídica, órgão de governo ou outro tipo de entidade, sem
restrições.
4. Campo de Aplicação
Este tipo de assinatura inclui, no seu próprio corpo, além das referências, os certificados que
compõem a cadeia de certificação e as informações de revogação do certificado digital do
signatário. Ele demanda uma maior capacidade de armazenamento.
Ele deve ser usado em situações onde é necessária a verificação completa da validade da assinatura
digital a qualquer momento, pois os dados necessários estão auto-contidos na assinatura.
Além de oferecer segurança quanto à irretratabilidade, ele permite que se verifique a validade da
assinatura digital mesmo que ocorra comprometimento da chave privada da AC que emitiu o
certificado do signatário, desde que o carimbo de tempo sobre as referências/valores dos
certificados tenha sido colocado antes desse comprometimento.
Segundo esta PA, é permitido o emprego de múltiplas assinaturas.
5. Política de Validação da Assinatura
Os campos a seguir definem os processos para geração e verificação de assinaturas realizadas
segundo esta PA.
5.1 Período para Assinatura
Esta PA terá validade desde a data de publicação até 31.12.2010.
5.2 Regras Comuns
5.2.1 Regras de Signatário e Verificador
5.2.1.1 Regras do Signatário
5.2.1.1.1 Dados Externos ou Internos a Assinatura
As assinaturas regulamentadas por esta PA podem ser realizadas usando uma das seguintes
representações:
a) Estrutura assinada com conteúdo digital separado (detached);
b) Estrutura assinada com conteúdo digital anexado (enveloping);
c) Estrutura assinada incluída no conteúdo digital (enveloped).
5.2.1.1.2 Propriedades Assinadas Obrigatórias
As assinaturas feitas segundo esta PA definem como obrigatórias as seguintes propriedades
assinadas:
1. DataObjectFormat (em assinaturas do tipo detached);
2. SigningCertificate;
3. SignaturePolicyIdentifier.
5.2.1.1.3 Propriedades Não-Assinadas Obrigatórias
a) SignatureTimeStamp
b) CompleteCertificateRefs
c) CompleteRevocationRefs
d) SigAndRefsTimeStamp
e) CertificateValues
f) RevocationValues
5.2.1.1.4 Referências à Cadeia de Certificação
A propriedade SigningCertificate deve conter apenas referência ao certificado do signatário, por
meio do Identificador Serial do Emissor e do hash do certificado.
5.2.1.1.5 Valores da Cadeia de Certificação
Não se aplica.
5.2.1.1.6 Regras Adicionais do Signatário
Na utilização de múltiplas assinaturas, todas elas devem empregar os mesmos algoritmos definidos
no item 5.2.5. As formas possíveis de múltiplas assinaturas são:
a) Paralelas: quando a ordem de inserção das assinaturas não é importante; ou
b) Contra-assinaturas: quando a ordem de aplicação das assinaturas é relevante, ou seja,
quando a função da segunda assinatura é, no mínimo, atestar o recebimento do
documento com a primeira assinatura já presente.
No caso de assinaturas paralelas haverá múltiplas assinaturas XMLDSIG referenciado o mesmo
documento por meio do elemento ds:Reference.
Para contra-assinaturas, deverão ser empregadas propriedades xades:CounterSignature.
Para a indicação do tipo de comprometimento devem ser empregados aqueles tipos definidos no
Anexo 1 do DOC-ICP-15.01.
A identificação do formato de apresentação dos dados deve ser realizada por meio da propriedade
MimeType da propriedade DataObjectFormat.
O signatário é responsável por se certificar que o documento assinado não contém qualquer
conteúdo dinâmico capaz de modificar o resultado do documento visualizado ao longo do tempo,
como, por exemplo, quantias ou sentenças que se alteram após certa data.
5.2.1.2 Regras do Verificador
5.2.1.2.1 Propriedades Não-Assinadas Obrigatórias
Caso não tenham sido incluídas pelo signatário, as seguintes propriedades DEVEM ser incluídas
pelo verificador:
a) SignatureTimeStamp
b) CompleteCertificateRefs
c) CompleteRevocationRefs
d) SigAndRefsTimeStamp
e) CertificateValues
f) RevocationValues
5.2.1.2.2 Regras Adicionais do Verificador
Caso esteja presente mais de uma assinatura, aposta ao mesmo documento assinado, deve-se validar
cada assinatura encontrada independentemente, segundo o item 5.2.1.1
5.2.2 Condições de Confiabilidade dos Certificados dos Signatários
5.2.2.1 Validação da Cadeia de Certificação
5.2.2.1.1 Raiz Confiável
A validação deve ser feita tomando como ponto de confiança os certificados da AC-Raiz da ICP-
Brasil, disponíveis em http://acraiz.icpbrasil.gov.br/CertificadoACRaiz.crt e
http://acraiz.icpbrasil.gov.br/ICP-Brasil.crt
5.2.2.1.2 Restrição do Caminho de Certificação
O número máximo de certificados de ACs, no caminho de certificação, entre o certificado do
signatário e a AC-Raiz é 2 (dois).
5.2.2.1.3 Conjunto de Políticas de Certificado Aceitável
Assinaturas digitais geradas segundo esta Política de Assinatura deverão ser criadas com chave
privada associada ao certificado ICP-Brasil tipo A3, com OID 2.16.76.1.2.3.n, ou A4, com OID
2.16.76.1.2.4.n, conforme definido em DOC-ICP-04.
5.2.2.1.4 Restrições de Nome
Não se aplica.
5.2.2.1.5 Restrições de Políticas de Certificado
Não se aplica.
5.2.2.1.6 Forma de Verificação do Status da Cadeia de Certificação (Revogação)
Tanto para o certificado do signatário quanto para os certificados das Autoridades Certificadoras da
cadeia de certificação a verificação do status dos certificados deve ser realizada através de LCRs
(Lista de Certificados Revogados) em conformidade com o perfil de LCR definido no documento
DOC-ICP-04 ou através de consultas OCSP (Online Certificate Status Protocol) em conformidade
com a RFC 2560 ou algum outro método presente em DOC-ICP-04.
O método mínimo aplicável deve ser a verificação por LCR.
5.2.3 Condições de Confiabilidade do Carimbo de Tempo
5.2.3.1 Validação da Cadeia de Certificação
5.2.3.1.1 Raiz Confiável
A validação da assinatura constante no carimbo de tempo deve ser feita tomando como ponto de
confiança os certificados da AC-Raiz da ICP-Brasil, disponíveis em
http://acraiz.icpbrasil.gov.br/CertificadoACRaiz.crt e http://acraiz.icpbrasil.gov.br/ICP-Brasil.crt
5.2.3.1.2 Restrição do Caminho de Certificação
O número máximo de certificados de ACs, no caminho de certificação, entre o certificado do
equipamento emissor do carimbo de tempo (SCT) e a AC-Raiz é 2 (dois).
5.2.3.1.3 Conjunto de Políticas de Certificado Aceitável
Os carimbos de tempo deverão ser criados com chave privada associada a certificados ICP-Brasil
tipo T3 (cujo OID é 2.16.76.1.2.303.n) ou T4 (cujo OID é 2.16.76.1.2.304.n), conforme definido no
DOC-ICP-04.
5.2.3.1.4 Restrições de Nome
Não se aplica.
5.2.3.1.5 Restrições de Políticas de Certificado
Não se aplica.
5.2.3.1.6 Forma de Verificação do Status da Cadeia de Certificação (Revogação)
Tanto para o certificado do SCT quanto para os certificados das Autoridades Certificadoras da
cadeia de certificação, a verificação do status deve ser realizada através de LCRs (Lista de
Certificados Revogados) em conformidade com o perfil de LCR definido no documento DOC-ICP-
04 ou através de consultas OCSP (Online Certificate Status Protocol) em conformidade com a RFC
2560 ou algum outro método presente em DOC-ICP-04.
O método mínimo aplicável deve ser a verificação por LCR.
5.2.3.3 Restrições de Nome
Não se aplica.
5.2.3.4 Período de Cautela
Não se aplica.
5.2.3.5 Atraso do Carimbo de Tempo
Não se aplica.
5.2.4 Condições de Confiabilidade dos Atributos
Não se aplica.
5.2.5 Conjunto de Restrições de Algoritmos
Os processos para criação e verificação de assinaturas segundo esta PA devem utilizar os
algoritmos:
a) Sha1(1 3 14 3 2 26)
b) Sha1withRSAEncryption(1 2 840 113549 1 1 5)
c) RsaEncryption(1 2 840 113549 1 1 1) com minKeyLength=1024
5.2.6 Regras Adicionais
Não se aplica.
5.3 Regras para Propósitos Específicos de Assinatura
Não se aplica.
5.4 Informações Adicionais sobre a Validação das Assinaturas
Não se aplica.
6. Informações Adicionais sobre a Política de Assinatura
Não se aplica.
J - POLÍTICA-PADRÃO ICP-BRASIL AD-A PARA ASSINATURAS
BASEADAS EM XMLDSIG / XADES
1. Identificador da Política de Assinatura
O nome desta Política de Assinatura é POLÍTICA ICP-BRASIL PARA ASSINATURA DIGITAL
COM INFORMAÇÕES DE ARQUIVAMENTO NO FORMATO XMLdSIG versão 1.0.
O Object Identifier (OID) desta PA, atribuído pelo ITI é: 2.16.76.1.7.1.10.1. Novas versões desta
política, se criadas, receberão OID diferenciado, do tipo 2.16.76.1.7.1.10.n+1.
Esta PA está protegida contra alterações indevidas por meio da publicação, no repositório da AC
Raiz da ICP-Brasil (http://www.iti.gov.br/twiki/bin/view/Certificacao/RepositoriodaACRaiz), do
seu conteúdo assinado digitalmente por chave privada associada a certificado digital do Instituto
Nacional de Tecnologia da Informação, utilizando algoritmo Sha1withRSAEncryption(1 2 840
113549 1 1 5).
2. Data da Criação
A data de criação desta PA é 31.10.2008.
3. Entidade Criadora da Política de Assinatura
A entidade criadora desta PA é o Instituo Nacional de Tecnologia da Informação (ITI). Ela pode ser
utilizada por qualquer pessoa física ou jurídica, órgão de governo ou outro tipo de entidade, sem
restrições.
4. Campo de Aplicação
Este tipo de assinatura é adequado para aplicações que necessitam realizar o arquivamento do
conteúdo digital assinado por longos períodos, sabendo-se que podem surgir fraquezas,
vulnerabilidades ou exposição a fragilidades dos algoritmos, funções e chaves criptográficas
utilizadas no processo de geração de assinatura digital.
Ele provê proteção contra fraqueza dos algoritmos, funções e tamanho de chaves criptográficas,
desde que o carimbo de tempo de arquivamento seja realizado tempestivamente e utilize algoritmos,
funções e tamanhos de chave considerados seguros no momento de sua geração.
Além disso, oferece segurança quanto à irretratabilidade, e permite que se verifique a validade da
assinatura digital mesmo que ocorra comprometimento da chave privada da AC que emitiu o
certificado do signatário (desde que o carimbo de tempo sobre as referências/valores dos
certificados tenha sido colocado antes desse comprometimento).
Segundo esta PA, é permitido o emprego de múltiplas assinaturas.
5. Política de Validação da Assinatura
Os campos a seguir definem os processos para geração e verificação de assinaturas realizadas
segundo esta PA.
5.1 Período para Assinatura
Esta PA terá validade desde a data de publicação até 31.12.2010.
5.2 Regras Comuns
5.2.1 Regras de Signatário e Verificador
5.2.1.1 Regras do Signatário
5.2.1.1.1 Dados Externos ou Internos a Assinatura
As assinaturas regulamentadas por esta PA podem ser realizadas usando uma das seguintes
representações:
a) Estrutura assinada com conteúdo digital separado (detached);
b) Estrutura assinada com conteúdo digital anexado (enveloping);
c) Estrutura assinada incluída no conteúdo digital (enveloped).
5.2.1.1.2 Propriedades Assinadas Obrigatórias
As assinaturas feitas segundo esta PA definem como obrigatórias as seguintes propriedades
assinadas:
a) DataObjectFormat (em assinaturas do tipo detached);
b) SigningCertificate;
c) SignaturePolicyIdentifier.
5.2.1.1.3 Propriedades Não-Assinadas Obrigatórias
a) SignatureTimeStamp
b) CompleteCertificateRefs
c) CompleteRevocationRefs
d) CertificateValues
e) RevocationValues
f) ArchiveTimeStamp
5.2.1.1.4 Referências à Cadeia de Certificação
A propriedade SigningCertificate deve conter apenas referência ao certificado do signatário, por
meio do Identificador Serial do Emissor e do hash do certificado.
5.2.1.1.5 Valores da Cadeia de Certificação
Não se aplica.
5.2.1.1.6 Regras Adicionais do Signatário
Na utilização de múltiplas assinaturas, todas elas devem empregar os mesmos algoritmos definidos
no item 5.2.5. As formas possíveis de múltiplas assinaturas são:
a) Paralelas: quando a ordem de inserção das assinaturas não é importante; ou
b) Contra-assinaturas: quando a ordem de aplicação das assinaturas é relevante, ou seja,
quando a função da segunda assinatura é, no mínimo, atestar o recebimento do
documento com a primeira assinatura já presente.
No caso de assinaturas paralelas haverá múltiplas assinaturas XMLDSIG referenciado o mesmo
documento por meio do elemento ds:Reference.
Para contra-assinaturas, deverão ser empregadas propriedades xades:CounterSignature.
Para a indicação do tipo de comprometimento devem ser empregados aqueles tipos definidos no
Anexo 1 do DOC-ICP-15.01.
A identificação do formato de apresentação dos dados deve ser realizada por meio da propriedade
MimeType da propriedade DataObjectFormat.
O signatário é responsável por se certificar que o documento assinado não contém qualquer
conteúdo dinâmico capaz de modificar o resultado do documento visualizado ao longo do tempo,
como, por exemplo, quantias ou sentenças que se alteram após certa data.
5.2.1.2 Regras do Verificador
5.2.1.2.1 Propriedades Não-Assinadas Obrigatórias
Caso não tenham sido incluídas pelo signatário, as seguintes propriedades DEVEM ser incluídas
pelo verificador:
a) SignatureTimeStamp
b) CompleteCertificateRefs
c) CompleteRevocationRefs
d) CertificateValues
e) RevocationValues
f) ArchiveTimeStamp
5.2.1.2.2 Regras Adicionais do Verificador
Caso esteja presente mais de uma assinatura, aposta ao mesmo documento assinado, deve-se validar
cada assinatura encontrada independentemente, segundo o item 5.2.1.1
5.2.2 Condições de Confiabilidade dos Certificados dos Signatários
5.2.2.1 Validação da Cadeia de Certificação
5.2.2.1.1 Raiz Confiável
A validação deve ser feita tomando como ponto de confiança os certificados da AC-Raiz da ICP-
Brasil, disponíveis em http://acraiz.icpbrasil.gov.br/CertificadoACRaiz.crt e
http://acraiz.icpbrasil.gov.br/ICP-Brasil.crt
5.2.2.1.2 Restrição do Caminho de Certificação
O número máximo de certificados de ACs, no caminho de certificação, entre o certificado do
signatário e a AC-Raiz é 2 (dois).
5.2.2.1.3 Conjunto de Políticas de Certificado Aceitável
Assinaturas digitais geradas segundo esta Política de Assinatura deverão ser criadas com chave
privada associada ao certificado ICP-Brasil tipo A3, com OID 2.16.76.1.2.3.n, ou A4, com OID
2.16.76.1.2.4.n, conforme definido em DOC-ICP-04.
5.2.2.1.4 Restrições de Nome
Não se aplica.
5.2.2.1.5 Restrições de Políticas de Certificado
Não se aplica.
5.2.2.1.6 Forma de Verificação do Status da Cadeia de Certificação (Revogação)
Tanto para o certificado do signatário quanto para os certificados das Autoridades Certificadoras da
cadeia de certificação a verificação do status dos certificados deve ser realizada através de LCRs
(Lista de Certificados Revogados) em conformidade com o perfil de LCR definido no documento
DOC-ICP-04 ou através de consultas OCSP (Online Certificate Status Protocol) em conformidade
com a RFC 2560 ou algum outro método presente em DOC-ICP-04.
O método mínimo aplicável deve ser a verificação por LCR.
5.2.3 Condições de Confiabilidade do Carimbo de Tempo
5.2.3.1 Validação da Cadeia de Certificação
5.2.3.1.1 Raiz Confiável
A validação da assinatura constante no carimbo de tempo deve ser feita tomando como ponto de
confiança os certificados da AC-Raiz da ICP-Brasil, disponíveis em
http://acraiz.icpbrasil.gov.br/CertificadoACRaiz.crt e http://acraiz.icpbrasil.gov.br/ICP-Brasil.crt
5.2.3.1.2 Restrição do Caminho de Certificação
O número máximo de certificados de ACs, no caminho de certificação, entre o certificado do
equipamento emissor do carimbo de tempo (SCT) e a AC-Raiz é 2 (dois).
5.2.3.1.3 Conjunto de Políticas de Certificado Aceitável
Os carimbos de tempo deverão ser criados com chave privada associada a certificados ICP-Brasil
tipo T3 (cujo OID é 2.16.76.1.2.303.n) ou T4 (cujo OID é 2.16.76.1.2.304.n), conforme definido no
DOC-ICP-04.
5.2.3.1.4 Restrições de Nome
Não se aplica.
5.2.3.1.5 Restrições de Políticas de Certificado
Não se aplica.
5.2.3.1.6 Forma de Verificação do Status da Cadeia de Certificação (Revogação)
Tanto para o certificado do SCT quanto para os certificados das Autoridades Certificadoras da
cadeia de certificação, a verificação do status deve ser realizada através de LCRs (Lista de
Certificados Revogados) em conformidade com o perfil de LCR definido no documento DOC-ICP-
04 ou através de consultas OCSP (Online Certificate Status Protocol) em conformidade com a RFC
2560 ou algum outro método presente em DOC-ICP-04.
O método mínimo aplicável deve ser a verificação por LCR.
5.2.3.3 Restrições de Nome
Não se aplica.
5.2.3.4 Período de Cautela
Não se aplica.
5.2.3.5 Atraso do Carimbo de Tempo
Não se aplica.
5.2.4 Condições de Confiabilidade dos Atributos
Não se aplica.
5.2.5 Conjunto de Restrições de Algoritmos
Os processos para criação e verificação de assinaturas segundo esta PA devem utilizar os
algoritmos:
a) Sha1(1 3 14 3 2 26)
b) Sha1withRSAEncryption(1 2 840 113549 1 1 5)
c) RsaEncryption(1 2 840 113549 1 1 1) com minKeyLength=1024
5.2.6 Regras Adicionais
Não se aplica.
5.3 Regras para Propósitos Específicos de Assinatura
Não se aplica.
5.4 Informações Adicionais sobre a Validação das Assinaturas
Não se aplica.
6. Informações Adicionais sobre a Política de Assinatura
Não se aplica.
ANEXO 2 – GERENCIAMENTO DE POLÍTICAS DE ASSINATURA
NA ICP-BRASIL
1. Introdução
1.1 Na verificação da validade de uma Assinatura Digital ICP-Brasil diversos atributos e
propriedades devem ser checados. É preciso verificar, por exemplo, se a assinatura contém apenas
algoritmos e parâmetros permitidos pelas normas da ICP-Brasil.
1.2 Além disso, é necessário validar também se a assinatura foi criada com a utilização de uma
Política de Assinatura (PA) aprovada pela AC Raiz da ICP-Brasil.
1.3 O objetivo do presente documento é introduzir regras claras e transparentes para determinar
a validade das PA aprovadas e definir processos de aprovação, prorrogação e revogação de uma PA.
1.4 Para facilitar a verificação da validade de uma PA aprovada e para permitir a criação de
sistemas que decidam de forma automatizada se uma determinada PA foi aprovada, a AC Raiz, além
de publicá-la em seu repositório web, gera e assina digitalmente uma Lista de Políticas de
Assinatura Aprovadas (LPA), contendo dados resumidos sobre a PA.
1.5 O formato da LPA e a forma de utilizá-la estão definidos no presente documento, bem como
os procedimentos de administração de PA aprovadas, o que inclui: a forma de aprovação e de
publicação de uma PA e os procedimentos a serem adotados em caso de término da validade,
prorrogação da validade e revogação de PA aprovadas.
2. Administração e ciclo de vida de uma PA
2.1 PA aprovadas são gerenciadas pela AC Raiz da ICP-Brasil com base neste documento.
2.2 Uma Política de Assinatura passa pelas seguintes etapas de vida:
a) Criação;
b) Aprovação;
c) Publicação;
d) Expiração (se for o caso);
e) Prorrogação de validade (se for o caso);
f) Revogação (se for o caso).
3. Comunicação entre as partes
3.1 Políticas de assinatura são aprovadas pela AC Raiz da ICP-Brasil em nome de uma pessoa
física ou jurídica, doravante designada Entidade Criadora de Política de Assinatura (ECP).
3.2 Toda e qualquer comunicação entre a ECP e a AC Raiz da ICP-Brasil, no que tange aos
processos regulamentados por este normativo, DEVE ser formalizada mediante o envio de
mensagem de correio eletrônico, que DEVE conter assinatura digital baseada em certificado digital
emitido no âmbito da ICP-Brasil.
3.3 No caso das mensagens eletrônicas enviadas da ECP para a AC Raiz, o certificado digital
referido no parágrafo 3.2 DEVE ser da pessoa física interessada na aprovação da PA ou, em se
tratando de solicitação formulada por pessoa jurídica, DEVE ter como titular a própria pessoa
jurídica interessada e como responsável uma pessoa física que será indicada, conforme definido no
parágrafo 4.1.1.a
3.4 No caso das mensagens eletrônicas enviadas da AC Raiz à ECP, o certificado digital referido
no parágrafo 3.2 DEVE ser de pessoa jurídica, tendo como seu titular a AC Raiz.
3.5 Todas mensagens eletrônicas enviadas pela ECP à AC Raiz DEVEM ser destinadas ao
endereço eletrônico normalizacao@iti.gov.br.
3.6 Todas mensagens eletrônicas enviadas pela AC Raiz à ECP serão destinadas aos endereços
eletrônicos do responsável definido no parágrafo 4.1.1.a.
4. Aprovação de uma PA
Os procedimentos administrativos a serem empreendidos em todos os processos de aprovação de
Políticas de Assinatura no âmbito da ICP-Brasil DEVEM observar a forma definida neste
documento.
4.1 Formalização do pedido
4.1.1 Um pedido para aprovação de uma PA e para sua integração na LPA DEVE conter:
a) Dados de identificação básicos do requerente e do responsável, em se tratando de
solicitação formulada por pessoa jurídica;
b) Política de Assinatura codificada em linguagem humana, em conformidade com o
documento DOC-ICP-15.03;
c) Resumo criptográfico da política de assinatura, para os dois formatos citados acima;
d) Razão pela qual a PA deve ser aprovada;
e) Propósito de uso da Política de Assinatura;
f) Restrições Básicas;
g) Início e fim de validade esperados da PA.
4.2 Organização dos processos
4.2.1 Para cada solicitação de aprovação de uma PA corresponderá, individualmente, um processo
administrativo com numeração própria e independente.
4.2.2 Para efeito de deferimento ou indeferimento das solicitações, os processos administrativos
são independentes entre si, não implicando os resultados de uns nos dos outros.
4.2.3 Todas as mensagens eletrônicas trocadas entre a ECP e a AC Raiz serão impressas,
autenticadas por servidor público e integradas aos autos dos respectivos processos administrativos.
4.3 Avaliação dos pedidos
4.3.1 Depois de analisar o pedido, sua validade e conformidade com os padrões e a legislação
aplicável, a AC Raiz irá emitir uma decisão sobre a aprovação ou desaprovação de uma PA,
juntamente com a justificativa da sua decisão.
4.3.2 É possível aplicar um recurso contra essa decisão, conforme procedimentos descritos na
seção 8.
4.3.3 Uma PA, após a aprovação, será publicada no repositório da AC Raiz da ICP-Brasil e
incluída na nova LPA, que será assinada por um certificado digital emitido especificamente para a
assinatura de LPA.
5. Publicação da PA e da LPA
5.1 Os arquivos com as PAs aprovadas são publicados no repositório da AC Raiz da ICP-Brasil
e são utilizados para a criação da LPA.
5.2 A LPA é assinada e publicada pela AC Raiz da ICP-Brasil, de forma segura, no seu
repositório no endereço web www.acraiz.icpbrasil.gov.br/LPA.
5.3 A LPA é atualizada pela AC Raiz mensalmente, no primeiro dia útil de cada mês, e contém
em seu corpo a data da sua próxima atualização.
5.4 A LPA é assinada com uma Assinatura Digital ICP-Brasil, por funcionário da AC Raiz
nomeado e autorizado, a quem foi emitido um certificado por uma das autoridades certificadoras
credenciadas na ICP-Brasil.
5.5 A LPA é escrita com base em um XML Schema e traz, para cada PA aprovada, os seguintes
dados:
iv. uma breve descrição da política: os aplicativos assinadores poderão exibir essa
informação para que o usuário decida qual PA empregar;
v. período de validade da Política;
vi. URLs da PA em formato textual e processável por máquina (XML/DER);
vii. resultados hash dos arquivos da PA, no formato textual e processável por
máquina (XML/DER).
5.6 Uma PA aprovada é válida pelo período indicado no campo validade, se ela não tiver sido
revogada. Nesse caso, seu prazo de validade será reduzido na próxima LPA a ser publicada e
assinada pela AC Raiz.
6. Prorrogação da validade de uma PA aprovada
6.1 A política de assinatura PODE ser publicada por um período ilimitado, caso o campo
Validade esteja setado como NULO.
6.2 Se a validade de uma PA aprovada estiver limitada a um certo período, ela poderá ser
prorrogada antes da expiração, a pedido da ECP, usando os mesmos procedimentos para aprovação
descritos na seção anterior.
6.3 Para que a prorrogação da validade seja aprovada, é preciso que não tenham sido
encontradas fraquezas na PA, as quais não sejam mais aceitáveis para o período de validade
seguinte.
6.4 A prorrogação é feita por meio da publicação de uma nova versão da PA contendo os dados
alterados sobre data de publicação, começo e término da validade da PA. A publicação é feita
utilizando os procedimentos citados no capítulo anterior.
7. Revogação de uma PA
7.1 PAs aprovadas PODEM ser revogadas pela AC Raiz da ICP-Brasil a qualquer tempo, a
pedido da ECP. A AC Raiz também PODE revogar uma PA aprovada a pedido de outra pessoa
física ou jurídica, nos casos em que determinada PA não deveria ter sido aprovada ou por motivos
de segurança ou ainda em razão de outros conflitos e problemas legais.
7.2 Um pedido de revogação de uma PA aprovada DEVE conter:
a) Dados de identificação básicos do requerente;
b) Dados de identificação da política de assinatura a ser revogada;
c) Razão pela qual a política de assinatura deve ser revogada.
7.3 Depois de analisar o pedido e sua conformidade com as normas e padrões da ICP-Brasil, a
AC Raiz irá emitir uma decisão sobre a rejeição do pedido ou sobre a revogação da Política de
Assinatura, juntamente com a justificativa para sua decisão.
7.4 É possível aplicar um recurso contra essa decisão, conforme procedimentos descritos na
seção 8.
7.5 Em caso de revogação de uma PA aprovada, ela será publicada no site da AC Raiz da ICP-
Brasil como revogada e sua validade, constante na LPA, será encurtada até o momento da sua
revogação. Uma nova LPA será publicada e assinada pelo certificado emitido para assinatura de
LPA.
7.6 A nova LPA irá conter o momento de revogação da validade de uma PA aprovada, o qual
será o instante imediatamente após o momento da assinatura e publicação da nova LPA.
8. Recursos
8.1 Caberá recurso quanto ao indeferimento de pedido de aprovação ou revogação de PA, em até
20 (vinte) dias úteis após a data da notificação da decisão da AC Raiz.
8.2 O recurso será dirigido ao Diretor de Auditoria, Fiscalização e Normalização do ITI e DEVE
incluir:
a) dados de identificação básicos do requerente;
b) resumo criptográfico da política de assinatura;
c) o número do processo administrativo correspondente à solicitação;
d) a justificativa para o recurso;
e) discriminação da correspondente documentação e material apresentados comprobatórios
dos fatos justificados.
8.3 O recurso será analisado pela Diretoria de Auditoria, Fiscalização e Normalização do ITI
(DAFN/ITI), que PODE, se necessário, formular outras exigências ao solicitante, que DEVEM ser
cumpridas no prazo estabelecido.
8.4 Caso a DAFN/ITI decida pelo indeferimento do recurso, o processo será submetido ao
Diretor-Presidente do ITI, em segunda instância, que PODE:
a) acatar as justificativas apresentadas no recurso, o que implicará a observância do
disposto nos parágrafos 11.6 e 11.7, conforme o caso; ou
b) ratificar o indeferimento do recurso, mediante notificação ao solicitante.
8.5 A decisão do recurso, em segunda instância, é final e irrecorrível na esfera administrativa.
8.6 Antes de sua decisão, o Diretor-Presidente do ITI PODE encaminhar o processo à
Procuradoria Federal Especializada do ITI para elaboração de manifestação jurídica, que subsidie
sua decisão.
9. Procedimentos para criação e verificação da LPA
9.1 A estrutura do arquivo LPA é a seguinte:
a) campo NOME: contém o nome da PA, conforme consta no campo
IDENTIFICADOR DA POLÍTICA DE ASSINATURA, existente no corpo da PA;
b) campo APLICACAO: descreve as situações em que a PA pode ser empregada,
conforme conteúdo constante no campo CAMPO DE APLICAÇÃO, existente no
corpo da PA;
c) campo VALIDADE: contém a data de fim de validade da PA, em Generlized Time;
d) campo URL TEXTUAL: contém a URL do repositório da AC Raiz da ICP-Brasil
onde está publicada a PA aprovada, em formato textual;
e) campo URL MAQUINA: contém a URL do repositório da AC Raiz da ICP-Brasil
onde está publicada a PA aprovada, em formato DER ou XML;
f) campo HASH TEXTUAL: contém o hash da PA em formato textual;
g) campo HASH MAQUINA: contém o hash da PA codificada em DER ou XML.
9.2 A data da revogação da política de assinatura indicada no campo VALIDADE, para as PA
aprovadas que não tenham sido revogadas, DEVE corresponder à data indicada no campo Validade
no arquivo da PA aprovada. Em caso de revogação de qualquer PA aprovada, o campo VALIDADE
DEVE conter a data de revogação da PA, ao invés da data indicada no campo Validade constante do
arquivo da PA aprovada.
9.3 A LPA DEVE ser verificada em relação ao momento atual e DEVE conter sempre todas as
PAs aprovadas. Isso significa que também aquelas que tenham expirado ou tenham sido revogadas
DEVEM ter a data da sua expiração ou revogação indicada no campo AVISO.
9.4 Esta propriedade da LPA é muito importante especialmente para verificação de Assinaturas
Digitais ICP-Brasil criadas no passado por meio de PA aprovadas que tenham sido válidas por um
período, mas posteriormente tenham sido revogadas.
9.5 Os campos com resumos hash DEVEM conter um algoritmo seguro, compatível com o
documento “PADRÕES E ALGORTIMOS CRIPTOGRÁFICOS DA ICP-BRASIL – DOC-ICP-
01.01”.
9.7 Na verificação da LPA em relação ao momento atual, a aplicação que realiza a verificação
tenta obter a LCR atual (OCSP) a ser utilizada para verificação da validade do certificado do
signatário da LPA.
9.8 Os dados contidos na LPA PODEM ser declarados como válidos apenas para o momento da
emissão da LCR atual (OCSP) para verificação da validade do certificado do signatário da LPA.
9.8 Assim, uma plena verificação da validade da Assinatura Digital ICP-Brasil DEVE ser feita
apenas no que diz respeito a períodos de tempo mais antigos ou iguais ao momento da emissão da
LCR atual (OCSP), que foi utilizada para verificar a validade do certificado do signatário da LPA.
9.9 Uma descrição mais detalhada dos campos da PA e do processo de controle dos campos
individuais na verificação das Assinaturas Digitais ICP-Brasil está no documento "REQUISITOS
MÍNIMOS PARA POLÍTICAS DE ASSINATURA DIGITAL NA ICP-BRASIL - DOC-ICP-15.03”
10. A validade da Assinatura Digital ICP-Brasil de um documento eletrônico
10.1 A validade da Assinatura Digital ICP-Brasil de um documento é sempre determinada no que
diz respeito ao momento da assinatura do documento.
10.2 O momento da assinatura do documento é um dentre:
1. o tempo constante de um carimbo de tempo emitido sobre a assinatura do documento;
2. o tempo a partir de um registro seguro de auditoria contendo o hash da assinatura;
3. um tempo próximo ao momento de verificação da LCR (OCSP) que permite validar o
certificado do signatário do documento. É necessário também obter as LCRs (OCSP) para
verificação de todo o caminho de certificação até o certificado confiável, sendo que todas
elas devem ter sido emitidas ao mesmo tempo ou após a LCR (OCSP) relativa ao
certificado do signatário.
10.3 Se a PA aprovada utilizada é válida com relação ao momento da assinatura e se os outros
requisitos legais em relação à validade das Assinaturas Digitais ICP-Brasil também são atendidos, é
possível declarar que a Assinatura Digital ICP-Brasil do documento é válida.
10.4 No caso de a PA aprovada ser inválida com relação ao momento da assinatura do
documento, é necessário declarar a Assinatura Digital ICP-Brasil do documento como inválida.
11 - Exemplos de LPA
A tabela 1 demonstra uma lista de PA aprovadas
Tabela 1 - Lista de PA aprovadas (PA01, PA02 e PA03)
Nome Aplicacao Validade URL
textual
URL
máquina
hash
textual
hash
máquina
1. Política de
assinatura-
padrão ICP-
Brasil de
uso restrito
Aplicação
X
2015052000
0000Z
www.a-
craiz.icp-
brasil.gov.-
br/LPA/
PA01.txt
www.a-
craiz.icp-
brasil.gov.-
br/LPA/
PA01.der
Hash T1 Hash M1
2. Política de
assinatura-
padrão ICP-
Brasil com
carimbo de
tempo
Aplicação Y 2015052000
0000Z
www.a-
craiz.icp-
brasil.gov.-
br/LPA/
PA02.txt
www.a-
craiz.icp-
brasil.gov.-
br/LPA/
PA02.der
Hash T2 Hash M2
3. Política de
assinatura
padrão ICP-
Brasil com
referências
para valida-
ção
Aplicação Z 2015052000
0000Z
www.a-
craiz.icp-
brasil.gov.-
br/LPA/
PA02.txt
www.a-
craiz.icp-
brasil.gov.-
br/LPA/
PA02.der
Hash T3 Hash M3
A tabela 2 demonstra a revogação de uma PA aprovada na terceira linha e o momento da revogação
na coluna “Validade”.
Tabela 2 - Lista de PA aprovadas com uma PA revogada (PA03)
Descrição Aplicacao Validade URL
textual
URL
máquina
hash
textual
hash
máquina
1. Política de
assinatura-
padrão ICP-
Brasil de
uso restrito
Aplicação
X
2015052000
0000Z
www.a-
craiz.icp-
brasil.gov.-
br/LPA/
PA01.txt
www.a-
craiz.icp-
brasil.gov.-
br/LPA/
PA01.der
Hash T1 Hash M1
2. Política de
assinatura-
padrão ICP-
Brasil com
carimbo de
tempo
Aplicação Y 2015052000
0000Z
www.a-
craiz.icp-
brasil.gov.-
br/LPA/
PA02.txt
www.a-
craiz.icp-
brasil.gov.-
br/LPA/
PA02.der
Hash T2 Hash M2
3. Política de
assinatura
padrão ICP-
Brasil com
referências
para valida-
ção
Aplicação Z 2008101300
00000Z
www.a-
craiz.icp-
brasil.gov.-
br/LPA/
PA03.txt
www.a-
craiz.icp-
brasil.gov.-
br/LPA/
PA03.der
Hash T3 Hash M3
Uma nova PA aprovada é adicionada na LPA
Tabela 3 - Lista de PA aprovadas com adição de uma nova PA (PA04)
Descrição Aplicacao Validade URL
textual
URL
máquina
hash
textual
hash
máquina
1. Política de
assinatura-
padrão ICP-
Brasil de
uso restrito
Aplicação X 2015052000
0000Z
www.a-
craiz.icpbra-
sil.gov.br/
LPA/
PA01.txt
www.a-
craiz.icpbra-
sil.gov.br/
LPA/
PA01.der
Hash T1 Hash M1
2. Política de
assinatura-
padrão ICP-
Brasil com
carimbo de
tempo
Aplicação Y 2015052000
0000Z
www.a-
craiz.icpbra-
sil.gov.br/
LPA/
PA02.txt
www.a-
craiz.icpbra-
sil.gov.br/
LPA/
PA02.der
Hash T2 Hash M2
3. Política de
assinatura
padrão ICP-
Brasil com
referências
para valida-
ção
Aplicação Z 2008101300
00000Z
www.a-
craiz.icpbra-
sil.gov.br/
LPA/
PA03.txt
www.a-
craiz.icpbra-
sil.gov.br/
LPA/
PA03.der
Hash T3 Hash M3
4. Política de
assinatura-
padrão ICP-
Brasil com
Aplicação
W
2015102000
0000Z
www.a-
craiz.icpbra-
sil.gov.br/
LPA/
www.a-
craiz.icpbra-
sil.gov.br/
LPA/
Hash T4 Hash M4
referências
completas
PA04.txt PA04.der
RETIFICADA EM 16/01/2009
