O envelope de transporte

Este documento apenas modela as especificações pertinentes ao problema, em particular as RFC 3161 e 3852, além dos regulamentos complementares da ICP-Brasil. Seu objetivo, portanto, é apenas melhorar o entendimento daquelas especificações e não elaborar um modelo de classes para a aplicação, atividade desenvolvida em outro momento. De um modo geral, nem todos os objetos modelados aqui são de interesse imediato para a aplicação. Para o detalhamento das classes Certificate e CertificateList, consulte a modelagem da RFC 5280. Para detalhes sobre carimbos de tempo, consulte a modelagem da RFC 3161.

O envelope CMS SignedData (RFC 3852)

Regras aplicáveis

O envelope SignedData deve ser codificado em DER;
Para um documento genérico, EncapsulatedContentInfo (eContentType) deve ser um tipo Data, onde id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 };
O campo certificates deve conter o caminho de certificação completo (se disponível; caso contrário deve conter pelo menos o certificado do assinante, mas não obrigatoriamente) do certificado digital de cada assinante designado pela coleção SignerInfo;
O campo crls deve conter todas as LCR's coletadas, se o foram, durante o processo de validação dos certificados de todos os assinantes;
O campo version do objeto SignerInfo deve ser igual a 1;
A implementação deve incluir como atributos assinados:
- O atributo ContentType deve ter o mesmo valor do campo eContentType de SignedData;
- O atributo MessageDigest deve ter o mesmo valor do hash calculado para o campo eContent de SignedData;
- O atributo SigningTime (opcional, por escolha do usuário) deve ser codificado como um GeneralizedTime na forma YYYYMMDDHHMMSSZ;
O cálculo do resumo criptográfico a ser assinado deve incluir:
- o conteúdo do campo eContent;
- o conteúdo codificado em DER de todos os atributos assinados;
A assinatura deve ser codificada como um OCTET STRING;
A verificação da assinatura deve:
- calcular novamente o hash originalmente assinado;
- verificar o valor do atributo assinado MessageDigest, que deve ser igual ao hash do campo eContent;
- verificar o valor do atributo ContentType, que deve ser igual ao valor do campo eContentType.

Algoritmos suportados (RFC 3370)

Algoritmo	OID
SHA-1	1.3.14.3.2.26
MD5	1.2.840.113549.2.5
DSA com SHA-1	1.2.840.10040.4.3
RSA com SHA-1	1.2.840.113549.1.1.5
RSA com MD5	1.2.840.113549.1.1.4

CMS Advanced Electronic Signatures (CAdES - RFC 5126)

A RFC 5126 define um conjunto mínimo de formatos para assinaturas digitais. Tais formatos CAdES são definidos pela presença obrigatória de determinados atributos assinados, além daqueles já previstos na RFC 3280. Mais especificamente, a RFC obriga a utilização do atributo SigningCertificateV2, definido na RFC 2634, e recomenda a utilização opcional, entre outros, do atributo CommitmentTypeIndication, que representa o comprometimento do assinante com a assinatura aposta, além do já conhecido SigningTime.

A presença obrigatória dos atributos assinados ContentType, MessageDigest e SigningCertificateV2 compõe o padrão CAdES Basic Electronic Signature (CAdES-BES). Como assinalamos, CAdES-BES admite inúmeros atributos opcionais; no entanto, adotamos especificamente os dois citados em vista das necessidades da ICP-Brasil.

CAdES-BES pode ser estendido para o padrão CAdES Explicit Policy-based Electronic Signatures (CAdES-EPES) pela inclusão do atributo obrigatório SignaturePolicy, que define uma determinada política de assinaturas digitais.

Regras CAdES aplicáveis

O primeiro certificado identificado no campo certs, se presente, deve ser obrigatoriamente o certificado utilizado para validar a assinatura;
O campo certHash é computado sobre todo o conteúdo codificado em DER do certificado (incluindo sua assinatura) com o algoritmo SHA-1;
O campo issuerSerial só é necessário se não for incluído no campo SignerIdentifier do objeto SignedData.

Formatos com dados de validação

Na especificação, a validação das assinaturas requer os seguintes itens de dados:

Os certificados digitais;
Informações sobre a revogação dos certificados envolvidos;
Carimbos de tempo confiáveis aplicados à assinatura:
Quando apropriado, os detalhes da política de assinatura necessários à sua validação.

Tais dados podem ser coletados tanto pelo assinante quanto por quem verifica a assinatura, na dependência da política de certificado definida. Para isso, a especificação define um conjunto de atributos não assinados que contêm as referências necessárias à validação correta.

A utilização do atributo não assinado SignatureTimeStamp caracteriza o formato CAdES-T. A agregação ao formato CAdES-T dos atributos CompleteCertificateReferences e CompleteRevocationReferences caracteriza o formato de assinatura digital com informações completas de validação (CAdES-C).

O formato CAdES-C pode ser estendido através da utilização de vários atributos não assinados definidos na especificação, a saber:

O formato CAdES-X Long inclui os atributos não assinados CertificateValues e RevocationValues;
O formato CAdES-X Type 1 inclui um atributo ESCTimeStampToken, um time-stamp cujo valor é calculado sobre o conteúdo da estrutura CAdES-C, de modo a assegurar a integridade daquelas referências;
O formato CAdES-X Type 2 inclui um atributo TimestampedCertsCRLs, um time-stamp cujo valor é calculado somente sobre o valor das referências de certificado e assinatura;
Os formatos CAdES-X Long Type 1 e 2, combinações dos formatos CAdES X Type 1 e 2 com o formato CAdES-X Long;
O formato CAdES-A de arquivamento, que incorpora um atributo ArchiveTimeStampToken às estruturas dos formatos CAdES-X Long, CAdES-X Long Type 1 ou 2.

Identificadores de objeto usados

Tipo de dado	OID
Tipo Data (eContentType)	1.2.840.113549.1.7.1
Tipo SignedData	1.2.840.113549.1.7.2
Atributo Content Type	1.2.840.113549.1.9.3
Atributo Message Digest	1.2.840.113549.1.9.4
Atributo Signing Time	1.2.840.113549.1.9.5
Atributo ESS Signing Certificate v2	1.2.840.113549.1.9.16.2.47
Atributo Commitment-type-indication	1.2.840.113549.1.9.16.2.16
Atributo SignaturePolicy	1.2.840.113549.1.9.16.2.15
Atributo SignatureTimeStamp	1.2.840.113549.1.9.16.2.
Atributo CompleteCertificateReferences	1.2.840.113549.1.9.16.2.21
Atributo CompleteRevocationReferences	1.2.840.113549.1.9.16.2.22
Atributo CertificateValues	1.2.840.113549.1.9.16.2.23
Atributo RevocationValues	1.2.840.113549.1.9.16.2.24
Atributo ESCTimeStampToken	1.2.840.113549.1.9.16.2.25
Atributo TimestampedCertsCRLs	1.2.840.113549.1.9.16.2.26
ATributo ArchiveTimeStampToken	1.2.840.113549.1.9.16.2.48

Requisitos de conformidade

A RFC define que uma implementação está em conformidade com ela na geração e verificação de assinaturas digitais se um dos dois formatos CAdES-BES ou CAdES-EPES for suportado. Além disso, para os dados de validação, apenas os formatos CAdES-T e CAdES-C precisam obrigatoriamente ser suportados.

O suporte ao formato CAdES-BES requer:

O atendimento à sintaxe definida na RFC 3852;
A utilização de um objeto SignedData ccom o valor do campo version igual a 3 e com a presença de pelo menos um SignerInfo;
A inclusão dos atributos assinados ContentType, MessageDigest e SigningCertificate ou SigningCertificateV2.

O suporte ao formato CAdES-EPES requer:

Suporte ao formato CAdES-BES;
A inclusão do atributo assinado SignaturePolicy.

A verificação utilizando carimbos de tempo requer:

O suporte ao formato CAdES-BES;
A inclusão do atributo não assinado SignatureTimeStamp;
A inclusão dos atributos CompleteCertificateReferences e CompleteRevocationReferences;
A obtenção dos certificados digitais necessários à validação;
A obtenção das listas de certificados revogados necessárias ou o suporte ao protoclo OCSP (Online Certificate Status Protocol).

Restrições da ICP-Brasil

Algoritmo criptográfico e tamanhos mínimos para geração de chaves assimétricas de usuário final: RSA 1024 bits para certificados A1, A2, A3, S1, S2, S3 e RSA 2048 bits para certificados A4, S4 (DOC-ICP-01.01, em revisão);

A conformidade ao DOC-ICP-15.01 admite apenas o suporte ao formato CAdES-EPES, com as seguintes características:

Assinatura digital de curto prazo (AD-CP), que corresponde diretamente ao formato CAdES-EPES sem dados de validação, isto é, incluindo pelo menos os atributos assinados ContentType, MessageDigest, SigningCertificateV2 e SignaturePolicy;
Assinatura digital com carimbo de tempo (AD-T), que corresponde diretamente ao formato CAdES-T sobre CAdES-EPES, isto é, incluindo ao formato AD-CP um atributo não assinado SignatureTimeStamp;
Assinatura digital com referências para validação (AD-R), que agrega ao formato AD-T os atributos CompleteCertificateReferences e CompleteRevocationReferences (REF) e um atributo ESCTimeStampToken calculado sobre AD-T + REF;
Assinatura digital com informações completas (AD-C), que agrega ao formato AD-R os atributos CertificateValues e RevocationValues (VAL);
Assinatura digital com informações para arquivamento (AD-A), que agrega ao formato AD-C um atributo ArchiveTimeStampToken calculado sobre AD-R + VAL.

O DOC-ICP-15.01 recomenda o suporte ao atributo assinado CommitmentTypeIndication com os seguintes tipos de compromisso:

Nome	OID	Descrição
Prova de origem	1.2.840.113549.1.9.16.6.1	Indica que o signatário reconhece a criação, aprovação e o envio de uma mensagem.
Prova de recebimento	1.2.840.113549.1.9.16.6.2	Indica que o signatário reconhece o recebimento do conteúdo de uma mensagem.
Prova de entrega	1.2.840.113549.1.9.16.6.3	Indica que o "fornecedor de serviço confiável" (TSP - Trusted Service Provider) emissor da indicação disponibilizou uma mensagem em uma área de armazenamento local acessível ao destinatário da mensagem.
Prova de envio	1.2.840.113549.1.9.16.6.4	Indica que a entidade emissora da indicação enviou a mensagem (mas não necessariamente a criou).
Prova de aprovação	1.2.840.113549.1.9.16.6.5	Indica que o signatário criou a mensagem (mas não necessariamente a aprovou ou a enviou.
Concordância	2.16.76.1.8.1	A assinatura aposta indica que o signatário concorda com o conteúdo assinado.
Autorização	2.16.76.1.8.2	A assinatura aposta indica que o signatário autoriza o constante no conteúdo assinado.
Testemunho	2.16.76.1.8.3	A assinatura aposta indica o compromisso de testemunho do signatário. Não necessariamente indica concordância do signatário com o conteúdo.
Autoria	2.16.76.1.8.4	A assinatura aposta indica que o signatário foi autor do conteúdo assinado. Não necessariamente indica concordância do signatário com o conteúdo.
Conferência	2.16.76.1.8.5	A assinatura aposta indica que o signatário realizou a conferência do conteúdo.
Revisão	2.16.76.1.8.6	A assinatura aposta indica que o signatário revisou o conteúdo assinado. Não necessariamente indica concordância do signatário com o conteúdo.
Ciência	2.16.76.1.8.7	A assinatura aposta indica que o signatário tomou ciência do conteúdo assinado. Não necessariamente indica concordância do signatário com o conteúdo.
Publicação	2.16.76.1.8.8	A assinatura tem o propósito de indicar que o signatário publicou o documento em algum meio de comunicação externo à entidade que o originou.
Protocolo	2.16.76.1.8.9	A assinatura aposta indica a intenção do signatário em protocolar o conteúdo.
Integridade	2.16.76.1.8.10	A assinatura aposta indica a intenção do signatário em garantir somente a integridade da mensagem.
Autenticação de usuário	2.16.76.1.8.11	A assinatura aposta é utilizada somente como prova de autenticação do signatário.
Teste	2.16.76.1.8.12	A assinatura aposta indica a intenção do signatário em realizar um teste.

A implementação Signthing deverá suportar todas as políticas de assinatura da ICP-Brasil. No entanto, para assegurar a possibilidade de sua utilização por usuários de outras PKI's, deverá igualmente suportar políticas baseadas no padrão CAdES-BES. Consulte o documento Implementação das políticas de assinatura para os detalhes do modelo a ser implementado.