Impedimento ao uso restrito de assinatura digital na ICP-BR

Apresentado ao Comitê de Informática e Interoperabilidade do
Conselho Nacional de Justiça

Prof. Pedro Antonio Dourado de Rezende
Representante da Sociedade Civil no CG-ICP-BR
Brasília, 27 de Novembro de 2005

NOTA DO EDITOR:  Textos incluídos, ou eventualmente linkados, neste documento de autoria de Jeroen van de Graaf são trabalhos em andamento (work in progress). No momento esses textos não estão licenciados para remissão (linkagem) ou redistribuição. Nem autor nem editor se responsabilizam por eventuais erros factuais neles contidos. Qualquer crítica à análise normativa neles expressa endereçada ao autor serão bem-vindas.

---

1- Introdução

Este documento se destina a registrar alguns dos problemas relacionados a suposto impedimento do uso restrito de assinatura digital sob o regime da ICP-Brasil, impedimento este totalmente desnecessário do ponto de vista técnico, e que, doutra feita, amplifica os riscos descritos no relatório "Privacidade e Riscos num mundo de chaves públicas", apresentado no II seminário de Certificação Digital do Instituto Nacional de Tecnologia da Informação, autarquia responsável pela certificadora raiz da ICP-BR, disponível em http://www.pedro.jmrezende.com.br/trabs/forumiti.htm

Todas as certificadoras credenciadas junto à ICP-Brasil consultadas se negam a emitir certificados contendo, em campo apropriado, declaração do titular restringindo o uso do seu par de chaves de assinatura. Embora tecnicamente factível sob o modelo de certificação adotado pela ICP-BR (X.509 v.3), essas certificadoras alegam que a norma vigente da ICP-BR as impede de emitir certificados com tais declarações restritivas, embora se neguem peremptoriamente a apontar qual dispositivo regulatório as impede de fazê-lo, ou mesmo a prestar tal declaração por escrito.


2- Tentativa de levantamento da natureza regulatória deste impedimento

Na tentativa de elucidar a veracidade das alegações das certificadores com respeito a tal impedimento normativo, o autor trocou mensagens com Jeroen von der Graaf, criptógrafo e pesquisador da UFMG e da comissão de avaliação do Sistema Eleitoral Brasileiro da Sociedade Brasileira de Computação, sobre o estado atual do regulamento da ICP-Brasil.

[OBS: A troca de correspondência neste documento corresponde a trabalho em andamento (work in progress), não devendo ser tomada como definitiva. Observe-se, também, que dizem respeido à data em que foram trocadas].

Abaixo, as mensagens replicadas:

e-mail 1:

-------- Mensagem Original --------
Assunto: Re: Resolução 7 ---> 31
Data: Sat, 23 Apr 2005
De: Pedro A.D.Rezende
Para: jvdg@lcc.ufmg.br

jvdg@lcc.ufmg.br wrote:

Caro Pedro,

Resolução 7 [do Comitê Gestor da ICP Brasil] foi modificada pelas Resoluções 11, 13, 21, 26, 28,31, da seguinte forma:

Resolução 11 modifica seção
1.3.4*,
7.1.2*

Resolução 13 modifica seção
4.1*;
6.1.1;
8.3

Resolução 21 modifica seção
1.3.3; 1.3.4;
2.1.1; 2.1.2*; 2.1.3; 2.2.1; 2.2.2; 2.3.2; 2.6.1*; 2.8; 2.8.1; 2.8.3;
3.1.1; 3.1.9*; 3.2;
4.3; 4.9;
6.1.1;
7.1.4;

Resolução 26 modifica seção
1.3.2;
2.1.2; 2.6.1;
3.1; 3.1.9*; 4.1

Resolução 28 modifica seção
7.1.2*

Resolução 31 modifica seção
3.1.8; 3.1.9;
7.1.2

Um asterisco quer dizer que houve uma modificação posterior.

Depois eu editei manualmente Res 7 para refletir estas mudanças; o anexo icpbrasil.txt é uma compilação crua em txt de Resolução 7, inclusive as modificações por Resoluções posteriores. Se a resolução mais recente que se aplica a uma seção NÃO for a Resolução 7, aparece o número desta resolução entre ``[" e ``]". Na realidade, este é o documento que a ICP-Brasil deveria disponibilizar.

(Consulte o arquivo anexado: icpbrasil.txt)

O texto de Seção 7.1.2 do meu documento começa assim:

"7.1.2 Extensões de certificado [31] Neste item, a Política de Certificação (PC) deve descrever todas as extensões de certificado utilizadas e sua criticalidade. A ICP -Brasil define como obrigatórias as seguintes extensões: -"Authority Key Identifier", não crítica: o campo "keyIdentifier" deve conter o hash SHA-1 da chave pública da Autoridade Certificadora emitente (AC); -"Key Usage", crítica: em certificados de assinatura digital, somente os bits digitalSignature, nonRepudiation e keyEncipherment podem estar ativados; em certificados de sigilo, somente os bits keyEncipherment e dataEncipherment podem estar ativados;

• "Certificate Policies", não crítica: deve conter o OID da PC correspondente e o endereço Web da DPC da AC que emite o certificado;
• "CRL Distribution Points",não crítica:deve conter o endereço na Web onde se obtém a LCR correspondente; ....."

Acredito que o que você procure é a extensão "Key Usage", portanto, deve conferir a Resolução 31. Ninguém verificou meu trabalho, portanto não tem status oficial. Na realidade eu fiz uma comparação entre várias DPC, convertendo de PDF ou HTML para txt; depois usando AWK e LaTeX para gerar o seguinte documento. Há algumas imperfeições (por este motivo é minuta) mas presta. (Consulte o arquivo Res7Act.pdf)

Seção 7.1.2 encontra-se na página 95.   Gostaria de saber se respondi a sua pergunta.

Um abraço, 

Jerô
  ================= Jeroen van de Graaf

Caro Jeroen,

Muito obrigado pelo envio do seu trabalho.

Gostaria de saber como podemos valida-lo para depois torna-lo público. Pensei em fazer uma checagem do seu levantamento com as resoluçoes, mas vejo que não terei tempo tão cedo. Talvez eu consiga que alguém do COTEC se interesse em faze-lo.

E sim, voce respondeu a minha pergunta [sobre qual a regulamentação da ICP-BR relativo a extensões em certificados]

Pelo que entendi na sua resposta, um certificado deve conter apenas campos que estejam descritos na política de certificação da entidade certificadora credenciada emitente, sendo que algumas são obrigatorias, de acordo com 7.1.2, e dentre as obrigatórias, a extensão "CERTIFICATE key usage".

O que eu procurava saber é, como vc sugere em sua resposta, se a norma permite ou não o uso da extensão "EXTENDED key usage", onde restrições de uso para a chave transportada, como as que me interessariam se fosse adquirir um certificado, poderiam ser declaradas. Pelo que entendi do 7.1.2, a inclusão do campo "EXTENDED key usage" é permitida desde que conste na Politica de Certificação da certificadora credenciada emitente.

Resta agora saber quais PCs já aprovadas pelo ITI incluem esse campo e, se nenhuma inclui, se a inclusão foi deliberadamente vetada durante o processo de credenciamento.

Obrigado.

--

3- Caso concreto de conflito normativo emanado deste impedimento
O primeiro caso concreto de que temos notícia, de conflito normativo que cria riscos ao usuário de assinaturas digitais emanado deste impedimento estabalecido na ICP-BR, tem origem no uso de assinatura digital no processo eleitoral brasileiro, que é regulamentado pelo TSE.

A Lei 10.740 de 2003 obriga o uso de assinatura digital nos Registros Digitais do Voto e estabelece o Ministério Público (MP), a Ordem dos Advogados do Brasil (OAB) e os partidos políticos como AGENTES EXTERNOS para acompanhar a produção, assinatura e lacração dos programas de computador do sistema eleitoral. Esta lei nada afirma sobre ICP-Brasil mas o TSE, fazendo uso de seu poder normativo, emitiu instruções para regulamentar a assinatura digital dos programas de computador pelos agentes externos. É nestas regulamentações do TSE que se materializa o conflito com a regulamentação da ICP-BR que acaba por expor a riscos desncessários os agentes OBRIGADOS a utilizar certificados da  ICP-BR neste caso.

A Resolução TSE 21.740 de 2004, que regulamenta seus dispositivos relativos ao uso de assinatura digital, em seu Art. 4º afirma que o TSE utilizará chaves compatíveis com a ICP-Brasil "no que cabível", enquanto no Inciso II do Art 5º e no § 1º Inc. IV do mesmo Art. 5º obriga ao Ministério Público (MP), à OAB e aos Partidos Políticos a usarem certificados da ICP-BR .

Porém, o § 2º do Art. 5º, posteriormente incluido por demanda da OAB, afirma que a MP e a OAB poderão gerar e certificar as próprias chaves "respeitando a ICP-BR no que cabivel", sem exigir que as mesas certificações estejam HOMOLOGADAS na ICP-BR. Já aos representantes dos Partidos resta estabelecida a exigência de certificados homologados na ICP-BR. 

Também na Resolução TSE 22.039 de 2005, emitida para o Referendo do Desarmamento, o Art. 23 diz que o TSE utilizará chaves e certificados compativeis com a ICP-Brasil "no que couber" (a administração de chaves do TSE é própria e não é homologada na ICP-BR). Enquanto, nessa mesma resolução o Inciso II do Art 25 obriga ao MP, OAB e Partidos a usarem certificados da ICP-BR, seu Art. 27 diz que a MP e a OAB poderão gerar as próprias chaves e certificados "respeitando a ICP-BR no que couber", mas não exigiu que fossem homologados pela ICP-BR.

O fato é que, desde 2004, o MP e a OAB usaram certificados por elas emitidos, e softwares de sua titularidade, para assinar digitalmente arquivos do sistema eleitoral no processo de homologação de softwares para a eleição informatizada. Mas os representantes dos Partidos Políticos, para poderem exercer o dever civil de fiscais externos do Sistema Eletrônico de Eleições, continuam obrigados a utilizar os certificados da ICP-BR, caracterizados pelo impedimento do titular em restingir o seu uso, no caso, à assinatura dos programas de computador do TSE.

O motivo  da OAB demandar à Justiça Eleitoral o uso de certificado por ela mesma emitido, no lugar da certificados da ICP-BR, para fins de homologação do sistema eleitoral brasileiro, se prende ao fato de que, para lavrar sua assinatura digital nos arquivos deste sistema, tanto a OAB como os fiscais de partido são obrigados, pela forma como a Justiça Eleitoral regulamenta e controla o processo de homologação, a RENUNCIAR O CONTROLE DE SUA CHAVE PRIVADA, em frontal violação do Art 6º da MP2200-2 (Lei que criou a ICP-BR), violação esta que implica em riscos e responsabilidades imanentes ao § 1º do Art. 10º da mesma MP, riscos e responsabilidades especialmente agravados pela recusa das certificadoras credenciadas na ICP-BR a emitir certificados em que o titular declara intenção de uso restrito.

Diante dos problemas que emanam de uma regulamentação defeituosa, a Justiça Eleitoral houve por bem acatar o pleito da OAB em relação à sua autonomia, não só para identificar eletronicamente seus representados, mas principalmente, também para exercer tal autonomia no controle dos riscos a que seus representados se expõem colateralmente, ao se verem obrigados a operar no Direito de forma eletrônica, conforme explicado em http://www.pedro.jmrezende.com.br/trabs/forumiti.htm. Em independência à normatização jurídica da ICP-BR, mas enquanto em consonância com sua normatização técnica, para efeitos de interoperabilidade.

Contudo, os representates dos Partidos, obrigados pelas duas regulamentações conflitantes a: a) utilizar um certificado de uso irrestrido; e b) vulnerar a sua chave privada, continuam cerceados na sua obrigação de controle exclusivo na manipulação de suas chaves privadas, explicitada no Art. 6º da MP2200., impedidos de administrar os riscos inerentes à lavra de assinaturas digitais sob o regime da ICP-BR., explicitados no § 1º do Art. 10º da MP2200.

Ressalte-se que, mantidas as exigências atuais das normas e leis pertinentes, os problemas aqui narrados não decorrem de falhas operacionais corrigíveis por uma reescrita casuística desses instrumentos legais, seja de natureza jurídica ou técnica, mas de problemas estruturais nada simples, que não devem ser desprezados por interesses imediatistas, tendo em vista a experiência acumulada pelo resto do mundo em tentativas semelhantes de se estabelecer infra-estruturas de chaves públicas (vide referências, principalmente os artigos "The possible Laws on Digital/Electronic Signature" e "Why PKI has failed")

4 - Proposta

Depois da publicação deste artigo, o autor continuou a se corresponder com o criptógrafo Jeroen van de Graaf, com o objetivo de trocar idéias sobre as formas de se implementar meios para que titulares de certificados digitais ICP-Br possam declarar sua intenção de restringir o uso de suas assinaturas digitais.

Esta correspondência foi desdobrada em forma de debate, em anexo, a partir da versão 4.0 deste documento.

---

Histórico deste documento

v.0 - 27.11.05 - Distribuido no Conselho Nacional de Justiça
v.1 - 03.01.02 - Revisado e publicado em "segurança computacional"
v.2 - 19.01.06 - revisão de redação
v.3 - 29.01.06 - revisão, fotos e seção 4 incluídos
v.4 - 31.01.04 - revisão, seção 4 desdobrada em debate anexo

---

Debate sobre implementação de declarativas de intenção de uso em certificados ICP-BR

e-mail 2:

-------- Original Message --------
Subject: ICP-BR, conselho nacional de justiça
Date: Sat, 28 Jan 2006 22:02:26 -0200
From: Pedro A.D.Rezende <prezende@unb.br>
To: Jeroen Antonius Maria van de Graaf <jvdg@lcc.ufmg.br>

No meu entender, a solução mais simples para o problema de certificado único (de uso geral) na ICP-BR pode ser encontrada dentre as extensões padronizadas no PKIX, mais especificamente, dentro de uma extensão que já é obrigatória nos certificados ICP-BR, por conta do dispositivo 7.1.2 da resolução 7, modificado pela resolução 35.

Pode ser incluído e usado o subcampo userNotice do campo policyQualifyer da extensão certificatePolicies.

Observe que o campo policyQualifyer, opcional no padrão PKIX, já é obrigatório nos certificados da ICP-BR para conter o subcampo CPS (item 7.1.2 da resolução 7). Mais precisamente, a restrição que o titular deseja fazer valer para seu certificado pode ser informada, com até 200 caracteres, no sub-subcampo DisplayText do subcampo userNotice.

Replico aqui o trecho das notas do curso de extensão em criptografia e segurança computacional da UnB sobre programação para ICPs, disponível em http://www.pedro.jmrezende.com.br/c003/C2c.htm:

3.4.1.5  Certificate Policies

Esta extensão contém uma sequência não vazia de termos de informação sobre política de certificação. Cada item consiste de um identificador de objeto (OID) e, opcionalmente, qualificadores que especializam a política correspondente. Uma política de certificação mapeia a funcionalidade pretendida para o uso do certificado e da chave por ele transportada, para elementos das camadas superiores da ICP, quais sejam, o seu regime jurídico e regulativo, e seus procedimentos não computacionais. O uso da extensão é o seguinte:

   # Num certificado de entidade final, a extensão descreve o conjunto de políticas sob as quais o certificado foi emitido, inclindo o seu uso pretendido. Usuários de certificados devem conhecer as políticas aceitáveis para suas aplicações.
  # Num certificado de entidade certificadora, a extensão descreve as políticas que podem ser incluídas entre as políticas vigentes para certificados que lhe sejam subordinados numa cadeia de certificação.

Se uma entidade certificadora não deseja limitar o conjunto de políticas vigentes em certificados subordinados aos que emite, pode incluir nesse certificado a extensão any-policy, cujo OID é { 2 5 29 32 0 }

Aplicações com requisitos específicos de políticas de certificação devem operar com uma lista de identificadores e qualificadores aceitáveis, e compará-los com os OIDs da política do certificado que se tenta inserir numa cadeia de certificação.

Se esta extensão for marcada como crítica, a aplicação deve também ser capaz de, após montar a cadeia de certificação (da entidade final até a raiz) e percorrer a cadeia de verificação (a mesma cadeia em sentido contrário, da raiz até a entidade final), interpretar esta extensão à luz das limitações decorrentes das políticas que ocorrem na cadeia, e decidir pela sua adequação aos requisitos da aplicação, rejeitando o
certificado, e portanto a cadeia, em caso de não adequação.

Requisitos para o processamento de qualificativos à política de certificação é assunto local, afeto a cada implementação: nenhuma ação é mandatória se a exetnsão for marcada como crítica. Por isso, para promover interoperabilidade, os perfis PKIX recomendam que seja usado nessa extensão apenas o OID de políticas, sem qualificativos. *Se o uso de qualificativos for inevitável, recomenda-se que se restrinjam esses ao CPS pointer e ao User Notice*, abaixo descritos.

O CPS pointer é o qualificativo que transporta um URI (Universal Resource Identifier) apontando para um documento que define a política de certificação do emissor. Nos regimes normativos hora em uso, este documento é chamado "Declaração de Práticas de Certificação" (ou CPS, Certificate Practice Statement).

O User Notice é um qualificativo destinado a permitir à aplicação exibir ao usuário texto informativo sobre a política de certificação do emissor do certificado. Trata-se de um objeto com dois campos opcionais, um deles -- explicitText -- para transportar texto de até 200 carcateres (limite nem sempre respeitado por emissoras). A aplicação deve exibir o explicitText de cada certificado que contenha um, numa cadeia de certificação.

   id-ce-certificatePolicies OBJECT IDENTIFIER ::=  { id-ce 32 }

   anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificate-policies 0 }

   certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation

   PolicyInformation ::= SEQUENCE
   {    policyIdentifier   CertPolicyId,
        policyQualifiers  SEQUENCE SIZE (1..MAX) OF PolicyQualifierInfo OPTIONAL
   }
   CertPolicyId ::= OBJECT IDENTIFIER

      PolicyQualifierInfo ::= SEQUENCE
   {    policyQualifierId  PolicyQualifierId,
        qualifier          ANY DEFINED BY policyQualifierId
   }
   -- policyQualifierIds for Internet policy qualifiers

   id-qt          OBJECT IDENTIFIER ::=  { id-pkix 2 }
   id-qt-cps      OBJECT IDENTIFIER ::=  { id-qt 1 }
   id-qt-unotice  OBJECT IDENTIFIER ::=  { id-qt 2 }

   PolicyQualifierId ::=
        OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )

   Qualifier ::= CHOICE {
        cPSuri           CPSuri,
        userNotice       UserNotice }

   CPSuri ::= IA5String

   UserNotice ::= SEQUENCE {
        noticeRef        NoticeReference OPTIONAL,
        explicitText     DisplayText OPTIONAL}

   NoticeReference ::= SEQUENCE {
        organization     DisplayText,
        noticeNumbers    SEQUENCE OF INTEGER }

   DisplayText ::= CHOICE {
        ia5String        IA5String      (SIZE (1..200)),
        visibleString    VisibleString  (SIZE (1..200)),
        bmpString        BMPString      (SIZE (1..200)),
        utf8String       UTF8String     (SIZE (1..200)) }

---

e-mail 3:
-------- Original Message --------
Subject: Re: ICP-BR, conselho nacional de justiça
Date: Sun, 29 Jan 2006 02:21:00 -0200
From: Pedro A.D.Rezende <prezende@unb.br>
To: Jeroen Antonius Maria van de Graaf <jvdg@lcc.ufmg.br>

JG:> Primeiro: a AOB usa este campo, mas apenas para as ACs "ICP-OAB - CHAVE RAIZ
1. Este certificado raiz foi emitido pelo Conselho Federal da OAB.
2. A ICP-OAB tem por finalidade emitir certificados digitais para os advogados e estagiários, para uso exclusivamente profissional.
3. Clique em mais informações para ter acesso à nossa declaração de  práticas de certificação."

Segundo: não tenho certeza, mas acredito que muitos softwares de emissão de certificados não permitem este campo seja diferente para certificados diferentes, mas isto pode ser resolvido

Se isto for fato, é por um detalhe de programação ou configuração: diante deste pleito, só funcionaria como justificativa para incompetência, preguiça ou algum rabo preso de quem opera a CA;

JG:> Terceiro: não acredito que somente um texto livre pode dar a solução. Como um programa vai poder verificar automaticamente se o uso deste certificado naquele contexto é válido?

Se vc não entende a instância do problema do fiscal de partido no TSE, vc não entende o problema. Se vc não entende o problema, não estará em boa posição para escolher uma solução.

O problema é:

O titular precisa ter como dizer que tipo de documentos ele pretende assinar com aquele par de chaves, se não quiser certificado de uso geral. Motivo para não querer: diminuir o valor que o acesso indevido à sua chave privada representa para fins fraudulentos. Como diminuir? Evitando que tais fraudes possam ser eficazes. Como evitar? A meu ver, a forma mais simples de evitar que tais fraudes possam ter eficácia é dizer, no certificado, que tipo de documentos o titular pretende assinar com seu par de chaves.

Se o titular for dizer, no certificado, que tipo de documento ele assinaria com a chave privada correspondente, ele deve dizer isso na linguagem de quem, junto com dele, pode vir a ser vítima de fraude via acesso indevido à sua chave privada. Portanto, ele deve dizer isso na linguagem das pessoas que usam seu certificado para aceitar documentos, não na semântica do software que manipula o certificado para verificar se uma assinatura em um documento está ou não corretamente formada. Por que?

Porque quem tem de decidir se aceita ou não o documento não é o software, é quem comanda o software para verificar assinatura com o certificado. O papel do software é APENAS dizer se conseguiu formar uma cadeia de certificados válidos, com o certificado do titular numa ponta e um certificado raiz que o usuário confia na outra, e com a assinatura do titular no documento corretamente verificada, ou não.

O software não deve decidir nada sobre restrição de uso. O software deve apenas avisar a terceira parte sobre a intenção de uso do titular (para o quê, então, serviriam campos com nome "DisplayText"?). Em caso de eventual repúdio, com ou sem alegação de fraude por parte do titular, quem decide se o documento manifesta vontade ou faz prova é o juiz (também baseado no "DisplayText"), não é o software.

Assim como no mundo do papel, uma coisa é verificar assinatura num documento, outra coisa é aceitar vincular-se a um documento assinado. Para entender melhor o que digo, leia o estudo jurídico que o presidente da Comissão de Informática da Ordem dos Advogados do Brasil apresentou no I Fórum sobre Segurança, Privacidade e Certificação Digital organizado pelo ITI em 2003.

JG:> Quatro: Na realidade, não é comum emitir certificados com extensões diferentes pela mesma AC Intermediária. É mais comum criar ACInt separadas, para cada política.

 
Não se trata de uma política diferente para cada certificado, trata-se de uma QUALIFICAÇÂO da política para aquele certificado. Por que razão, então, um campo na extensão certificatePolicies se chamaria userNotice?
 

JG:> Cinco: não estou entendendo o que a OAB e os partidos políticos tem a ver com isto. Estou preocupado com o pobre José, que não entende o que é um certificado digital, e cujo coronel local pode enganá-lo, assinando documentos em seu nome.

Sobre a OAB:

Está ciente e preocupada com o problema (de que o certificado ICP-BR é de uso geral). Resolveu para si e a seu modo a instância do problema gerada pela norma do TSE.

Sobre os Partidos:

-> Fiscal tem que usar par de chaves certificado na ICP-BR

-> Certificadora ICP-BR só emite certificado de uso geral

-> TSE obriga titular (fiscal de partido) a assinar na máquina do TSE

-> Para isso, fiscal cede acesso à sua chave privada a sistema do TSE

-> Ao fazer isso o fiscal viola, por força da norma do TSE, o art.6 da MP2200:

-> O sistema do TSE, ou quem o intercepte, pode fazer o que quiser com a chave privada do fiscal!!!

Sobre o pobre jose:

Como vc bem descreve, ele vai se ferrar de qualquer jeito. O que vc pode fazer para proteger o pobre jose? Quase nada, pois o problema dele é sócio-cultural (veja o adendo à nota do editor no artigo supracitado).

Mesmo assim, se voce acha que pode ajudar o josé melhorando a usabilidade, estaremos preocupados com problemas diferentes. Voce com a usabilidade, eu com o ucasse. Usabilidade se enfrenta no desenvolvimento de softwares, ucasse se enfrenta no embate político.

---

email 4:
-------- Original Message --------
Subject: Re: ICP-BR, conselho nacional de justiça
Date: Tue, 31 Jan 2006 13:35:14 -0200
From: Pedro A.D.Rezende <prezende@unb.br>
To: Jeroen Antonius Maria van de Graaf <jvdg@lcc.ufmg.br>

PADR:> Porque quem tem de decidir se aceita ou não o documento não é o software, é quem comanda o software para verificar assinatura com o certificado. O papel do software é APENAS dizer se conseguiu formar uma cadeia de certificados válidos com o certificado do titular numa ponta e um certificado raiz que o terceiro confia na outra e a assinatura do titular no documento correta, ou não.

JG:> Esta deve ser a sua opinião pessoal; com certeza não é a de X509/PKIX, que reza que, além do caminho de certificação, as extensões relativas às politicas devem ser verificadas (o que, na prática, quase nunca acontece).

Sim, mas estou me referindo ESPECIFICAMENTE ao que o software poderia fazer no contexto em discussão, que inclui dois fatos:

1- o tipo do subcampo userNotice prescreve semântica expressável em texto pleno,
2- estamos tratando de assinaturas de uso geral.

Usar esse campo com outras OIDs, com codificação específica, seria fugir do padrão PKIX e criar problemas de interoperabilidade. Por outro lado, embutir semântica específica em texto pleno abre a porta para todo tipo de efeito colateral indesejado, pela via de variações ou erros ortográficos.

PADR:> O software não deve decidir nada sobre restrição de uso. O software deve apenas avisar a terceira parte sobre a intenção de uso do titular (para que serviriam campos com nome "DisplayText"?). Em caso de posterior repúdio, com ou sem alegação de fraude por parte do titular, quem decide é o juiz (também baseado no "DisplayText"), não é o software.

JG:> (Quer dizer userNotice, suponho? displayText não existe em RFC3280.)

Me enganei com nomes: deveria dizer ExplicitText, de tipo displayText. displayText é o tipo do sub-subcampo ExplicitText do subcampo userNotice, conforme copiado e colado do texto da RFC3280, em http://www.pedro.jmrezende.com.br/c003/rfc3280.txt. A menos que o RFC 3280 tenha se modificado, com supressões na estrutura de dados, desde que o espelhei para o endereço acima, o que duvido.

JG:> Já que um juiz não entende nada de sofware, seu argumento em favor de userNotice é forte. Num projeto em que trabalho também pretendemos usar este campo, mas seu texto depende de um advogado, o que pode complicar ou atrasar a implementação. :-)

Não vejo problema em que os textos admissíveis neste campo sejam controlados, no ato da certificação, por orientação jurídica. Pelo contrário. Neste caso o formulário de solicitação do certificado pode gerar, para esse campo, um texto pre-aprovado pelo jurídico contendo opções selecionáveis pelo titular, caso o titular opte por incluir o userNotice (opte por restringir o uso do certificado).

Esta solução serve também para controlar os efeitos colaterias da enxurrada de requisições de inclusão  de campos de identificadores e indexadores obrigatórios, da parte dos mais diversos órgãos públicos e serviços, que vão continuar chegando ao Comite gestor enquanto a regra geral para emissão der a impressão que certificados são, por natureza, de uso geral.

Para desarmar a bomba relógio que tal impressão implica para a privacidade, cada requisição de 'inclusão de (mais um) identificador' obrigatório no certificado poderá ser atendida com uma resolução que torna esse identificador opcional no certificado, e obrigatório na lista de opções de restrição de uso (para preenchimento do campo userNotice). Isso permite ao titular ter algum controle sobre seu direito à privacidade, garantido pelo art.5 da Constituição Federal.

JG:> Quatro: Na realidade, não é comum emitir certificados com extensões diferentes pela mesma AC Intermediária. É mais comum criar ACInt separadas, para cada política.

PADR:> Não se trata de uma política diferente para cada certificado, trata-se de uma QUALIFICAÇÂO da política para aquele certificado. Por que razão um campo na extensão se chamaria userNotice?

JG:> Eu te entendo, mas acredito que haja pessoas que diriam que uma qualificação da política é uma outra política, pelo menos neste contexto.

Isso é "red herring", sofisma útil apenas para quem queira arrastar os pés na obrigação de resgardar o direito à privacidade dos seus clientes, garantido pelo art. 5 da Constituição Federal:

Primeiro, a ICP-BR já obriga o uso de qualificadores da política de certificação, para incluir URI da CPS.

Segundo, pode-se argumentar que a adoção da medida aqui sugerida mantém a mesma coleção de políticas anteriores: as mesmas de antes acrescidas da opção do usuário qualificar, no ato da certificação, intenção de uso para o certificado. Se o exercício dessa qualificação for implementado através da seleção de opções, com ajuda de um menu montado dinamicamente a partir dos dados pessoais que o certificado irá incluir em outros campos, tal grau de automação desqualificaria esse argumento.

PADR:> Partidos:
Fiscal tem que usar par de chaves certificado na ICP-BR ->
Certificadora ICP-BR só emite certificado de uso geral ->
TSE obriga titular (fiscal de partido) a assinar na máquina do TSE ->
Para isso, fiscal cede acesso à sua chave privada a sistema do TSE ->
Nesse momento o fiscal é obrigado a violar o art.6 da MP2200 :
O sistema do TSE pode fazer o que quiser com a chave privada do fiscal

 

JG:> Este é um problema geral: mesmo tendo sua chave privada num smart card/token, se você não controla a plataforma computacional você não sabe qual é o programa usando a sua chave portanto você não sabe o que vai ser assinado com a sua chave privada. Com um disquete (tipo A1) é ainda pior: alguém poderia roubar seu arquivo com a chave cifrada e a sua senha ...

Acho que nós técnicos não deveríamos alimentar sofismas no trato de assunto tão sério. Estamos aqui falando de direitos, não de riscos. Estamos falando do direito de quem se expõe aos riscos associados à responsabilidade pela guarda e uso de uma chave privada, de poder exercer a cautela que julgue devida para controlar sua exposição a esses riscos.

Não estamos falando dos riscos em si, embora os riscos dêem a dimensão da importância dos direitos. Devemos começar lembrando que os bits introduzem riscos que não existem com o papel. A assinatura manual é lavrada na(s) folha(s) que mostra(m) o texto, enquanto a digital não é lavrada na tela que o mostra. No papel, não existe o risco de se assinar um texto diferente daquele mostrado na folha onde se assina.

Na minha máquina, eu tenho direito de escolher que programas instalar. Inclusive softwares que podem interagir com minha chave privada, e inclusive sob o regime da ICP-BR, se sustentarmos a crença de que esse regime não constitui um cartel, mas sim uma infraestrutura normativa onde o mercado pode livremente atuar. Dentre os motivos para se buscar equilíbrio normativo neste regime, está o de sustentar esta crença. E em máquina de terceiros, eu não tenho o direito de escolher que programas instalar.

Se, na minha máquina, eu faço uso desse direito, com vistas a exercer devida cautela no controle dos riscos associados, ou não o faço, por incompetência ou por outro motivo que seja, isso é uma prerrogativa minha, como cidadão e titular de um par de chaves sob o regime da MP2200. Se poucos sabem como exercer esse direito com eficácia, tal fato deve ser, antes de mais nada, um alerta sobre a gravidade dos riscos associados, e nunca uma justificativa para o cerceamento desse direito (ao contrário!).

JG:> Eu concordo com você que incluir no userNotice é necessário para seres humanos, porém, me pergunto como programas vão conseguir interpretar este texto. Verificar o texto com um programa de inteligência artificial? Verificar o hash do texto :-)  ?

Da mesma forma que compiladores processam comentários no código fonte. Programas não têm que interpretar o texto do userNotice, programas têm que apenas exibir o texto. Pelo menos é o que sugere a tipagem dos campos da extensão CertificatePolicy para o X.509/PKIX. Basta incluir mais uma opção para exibição de alerta, durante a validação da cadeia de certificação, com um botão para visualização do texto. Se as alternativas na sua pergunta retórica não forem uma brincadeira, observe que não há razão para verficiar hash do texto, pois a validação da cadeia de certificação atesta a integridade do certificado final, onde está o texto.

Quanto ao problema das aplicações insensíveis à presença de qualificativo 'userNotice' no certificado final da cadeia, trata-se de uma situação parecida com a das aplicações que não avisam usuários quando CRLs não podem ser encontradas, comportamento da cryptoAPI do ruindows relativo a CRLs.

Se, no ruindows, mesmo com a variável "verficar CRL" ligada, quando a assinatura é dada como válida o usuário não pode saber se ocorreu o fato das CRLs pertinentes terem sido varridas e não conterem nenhuma revogação referente à cadeia, ou o fato da varredura ter falhado porque alguma CRL não pôde ser localizada, eu pergunto: em que sentido essa situação é mais aceitável do que o certificado conter um campo que qualifica a intenção de uso do titular?

Entendo o contrário: enquanto os casos se assemelham tecnicamente, por apresentarem riscos decorrentes de deficiências no processamento de qualificadores da politica de certificação, informação é tudo que o usuário precisa para avaliar adequadamente esses riscos, ao passo que, no segundo caso, ele terá mais controle da situação. O usuário pode (e já deve, para casos fora do escopo da ICP-BR) ser instruído a vizualizar o certificado, à procura do campo UserNotice na extensão CertificatePolicies, antes de aceitar documento de valor significativo, coisa muito mais simples, e mas inteligível para o leigo em informática, do que sair no ruindows verificando a disponibilidade de repositórios de CRLs em certificadoras.

Usuários de certificados precisam saber que a responsabilidade por aceitar um documento eletronico com assinatura digital verificada, mas datado num prazo em que a chave esteja revogada, é dele, independente do software que ele usa para verificar a assinatura avisá-lo, ou não, de que varreu as CRLs pertinentes ou não. Em que isso difere do usuário assumir, junto com a responsabilidade pelas datações (do documento na da validade do certificado), também a responsabilidade pela aceitação de documentos cuja natureza esteja no propósito de uso do certificado?

Não entendo os motivos pelos quais quem responde por certificadoras, ou pela regulamentação da ICP-BR, poderia estar mais preocupado com as consequências de usários ignorarem declarativas de intenção de uso nos certificados, do que com os riscos associados ao uso indevido da chave privada de seus clientes, riscos esses que só podem aumentar com o impedimento atual na ICP-BR a tais declarativas. Afinal, as responsabilidades maiores da certificadora são, ou deveriam ser, antes com os seus clientes do que com os clientes destes. Se uma proposta como esta (UserNotice), para a qual parece que estamos convergindo, encontrar oposição, saudável seria se a encontrasse por claros e convincentes motivos.

JG:> Para ser sincero, estou mais preocupado com o Pobre José que com os fiscais do partidos, já que dos últimos podemos esperar uma certa formação na área de informática. Não estou entendendo porque você está ligando esta questão da restricão do uso dos certificados da ICP-Brasil ao exemplo do TSE, que você, implicitemente, está acusando de abusar o acesso à chave privada do fiscal para assinar um outro documento.

Não estou implicitamente acusando o TSE de abusar o acesso à chave privada de fiscal nenhum. Estou, sim, apontando a POSSIBILIDADE desse tipo INIMPUTÁVEL de abuso. Estou apontando esta possibilidade ao acusar implicitamente OUTRO abuso, do qual ela decorre. Acuso o abuso da prerrogativa que a justiça eleitoral se arvora, INJUSTIFICADAMENTE NUMA REPÚBLICA FEDERATIVA SOB ESTADO DEMOCRÁTICO DE DIREITO, de regulamentar a fiscalização dos seus próprios atos, à guisa de uma alegada necessidade de modernizar seus processos, na forma em que o faz.

Ao ponto dos seus mais altos mandatários se imiscuirem no processo legislativo sobre temas eleitorais por entenderem, nas palavras do líder do governo no senado em 2001, "melhor que ninguém" da informatização desse processo. Ao ponto desse líder, tendo se empenhado pela aprovação de emendas na lei eleitoral, a pedido do então presidente do TSE, que tornavam inócuas as medidas fiscalizatórias demandadas pela sociedade na esteira do escândalo do painel do Senado, receber do TSE, quinze dias depois de aprovadas as tais emendas, o cargo de governador do seu estado, o Piauí, no primeiro caso de cassação por irregularidades na campanha, do governador empossado que havia lhe derrotado nas urnas.

Se estou insinuando algo sobre a justiça eleitoral Brasileira, é que me recuso a colocá-la em pedestal de santo. Por outro lado, os que não vêem nada de errado ou perigoso na concentração de poderes executivo, legislativo e judiciário em um só agente, palpável na esfera eleitoral no Brasil, deveriam saber que deles discordam os "pais-fundadores" da democracia moderna, autores da venerada constituição norte-americana. Segundo James Madison,

The "accumulation of all powers, legislative, executive, and judiciary, in the same hands ... may justly be pronounced the very definition of tyranny."
--James Madison, Federalist Paper No. 47

JG:> Você deve ter seus motivos para fazer desta forma, mas com certeza vai perder uma parte do público alvo, o que prejudica, na minha opinião, a causa: restrição ao uso dos certs ICP-Brasil.

Meu objetivo não é atingir, em detrimento da mensagem, o maior público possivel. A impossibilidade do titular restringir o uso do seu certificado é apenas um dos problemas que me preocupa na ICP-Brasil.

Se a norma do TSE obriga o fiscal, por um lado, a submeter-se à jurisdição da MP2200 para cumprir sua função social, enquanto, para cumpri-la, o obriga a violar o art. 6 desta mesma MP2200, como fica a tarefa de educar um público, por mais restrito a especialistas que seja, sobre os riscos inerentes à responsabilidade pelo manuseio da chave privada, diante de tão mau exemplo?

JG:> Acredito que com o exemplo do Pobre José você tenha mais chances de ser ouvido

Voce deve ter em foco o contexto que provocou a elaboração do meu texto [ao qual este debate está anexado] e o seu público alvo inicial. O caso do TSE surgiu no texto APENAS pelos seguintes motivos

1- Trata-se de um caso (até onde sei o primeiro) em que um ramo do judiciário concede à OAB o direito de isentar-se de uma regra geral, que, doutra forma, a obrigaria ao uso de certificados emitidos por certificadora credenciada na ICP-BR.

2- O caso do TSE foi citado no âmbito da discussão de uma representação da OAB contra uma regra parecida, baixada por um outro órgão do mesmo poder judiciário, o TST. O caso é pertinente pois se trata do mesmo pleito que foi atendido pelo TSE.

3- Na segunda reunião, o objetivo da citação já foi parcialmente atendido: alguém do TST se manifestou favorável a que se examinasse a possibilidade da OAB ser ali também isentada da obrigatoriedade do uso de certificados emitidos por certificadora credenciada pela ICP-BR.

4- Os supracitados objetivos, que me levaram a aceitar o convite para assessorar tecnicamante a OAB na primeira reunião sobre o tema no CNJ, para a qual preparei a primeira versão desse texto.

JG:> mas sua abordagem deve se encaixar num Plano Maior, e eu não tenho a esperança que vá mudar de idéia somente porque eu não concordo :-).

O documento foi depois divulgado e ampliado, com sua consentida colaboração, para o público em geral por tratar do segundo caso concreto (representação da OAB contra a norma do TST) em que alguns dos problemas levantados por nós, no primeiro seminário sobre a ICP-BR patrocinado pelo ITI dois anos antes, são questionados na justiça. Porque se trata de um documento onde se pode citar uma solução, mesmo que ad-hoc, admitida para o primeiro caso concreto (na fiscalização no TSE), para ilustrar que a norma da ICP-BR não é o suprassumo da saberia messiânica lavrada em pedra.

A regulamentação da ICP-BR tem problemas que são finalmente questionados na justiça, justamente quando órgãos do Poder Judiciário decidem sobre sua adesão. O "Plano Maior" em que minha abordagem busca se encaixar é descrita pelo cientista político Newton Bignotto, da sua mesma UFMG, no artigo "Problemas atuais da teoria republicana": "Um ordenamento jurídico bem estruturado será a presa fácil de interesses de grupos particulares, se não for refeito e recomposto pela ação dos homens ao longo do tempo".

JG:> Porém, nossa correspondência não te induz a acrescentar seu texto?

Eu estou, sim, usando nossa correspondência como laboratório. Dela estou tentando extrair elementos de convencimento que podem ser usados em outras ocasiões. Mas é claro que vou lhe consultar sobre o que posso ou não publicar, da nossa correspondência.

JG:> Seu argumento de não usar extensões incompreensíveis e sim userNotice é interessante e talvez mereça mais destaque.

Meu argumento não é bem o de usar uma alternativa EM DETRIMENTO da outra. Não tenho nada contra extensões com semântica implementável em software. Apenas acho que, no contexto da ICP-BR, onde sequer as resoluções seguem direito a especificação do X.509, quando a MP2200 estabelece o X.509 como padrão, seria muito complicado fazê-las funcionar.

Ao passo que, se formos discutir primeiro as soluções com semanticas implementáveis por sw, temo que acabe prevalecendo a desculpa de que é muito complicado, para se varrer novamente problemas de natureza jurídica para debaixo do tapete.

Como as consequências do problema são também de natureza jurídica, e não técnica, acho que a solução mais simples, que encaminha a solução do problema em tela (impossibilidade de restrição de uso) para a esfera onde suas consequências se manifestam, é o melhor a se fazer se quisermos evitar armadilhas que só beneficiam a interesses inconfessáveis.