Source: https://cic.unb.br/~rezende/trabs/fsfla_srf.html
Timestamp: 2020-01-24 23:35:52+00:00

Document:
Para publicação na revista do IBDI
Alexandre Oliva*
Pedro Antonio Dourado de Rezende**
Este artigo denuncia a violação de princípios constitucionais estabelecidos para a administração pública; a violação de direitos constitucionais fundamentais de cidadãos; a imposição de insegurança jurídica e a discriminação injustificada entre contribuintes, por parte da Secretaria de Receita Federal, do Ministério da Fazenda, no contexto de declarações de Imposto de Renda de Pessoas Físicas.
A lei 9250 [L9250], de 26 de dezembro de 1995, estabelece:
Art. 7º A pessoa física deverá [...] apresentar anualmente [...] declaração de rendimentos em modelo aprovado pela Secretaria da Receita Federal.
Ainda que a lei conceda à Receita Federal a prerrogativa de aprovar o modelo da declaração, não lhe concede a prerrogativa de impor obrigações adicionais.
De fato, o princípio da legalidade [PLJ,PLW], imposto à administração pública no artigo 37 da Constituição Federal de 1988 [CF1988], limita a discricionariedade de entes públicos como a Receita Federal, limitação esta corroborada noutro artigo:
Atos normativos da Receita Federal a cada ano aprovam os formulários e os programas de computador e estabelecem as condições em que se exige a apresentação da declaração em formato eletrônico.
Não sendo leis, não poderiam criar obrigações, ou impor restrições arbitrárias aos contribuintes. Muito menos se tais obrigações ou restrições forem inconstitucionais.
Porém tais atos normativos de fato obrigam contribuintes em situações arbitrárias a não utilizar formulários em papel, mas sim programas de computador que trazem consigo questões de infração de direito autoral, de insegurança jurídica, de falta de transparência e de exigência de licenciamento oneroso e/ou restritivo, com agravante discriminatório, de ainda outros programas de computador (software).
Infração de Direito Autoral
Os programas de computador distribuídos pela Receita Federal não acompanham uma licença de uso. Porém, consta da lei 9609 [L9609], de 19 de fevereiro de 1998, que:
Em geral, violação de direito autoral somente gera penalidades ao infrator em caso de queixa pelo titular. Como a própria Receita Federal é titular do direito autoral sobre os programas de computador que ela fornece, segundo os próprios programas, a possibilidade de queixa seria irrisória. Há, porém, ressalva no artigo 12 da lei 9609:
Vige uma interpretação de que uso de programa de computador sem licença constitui prejuízos ao titular dos direitos autorais. Portanto a Receita Federal, uma entidade de direito público que detém os direitos autorais sobre os programas que ela obriga contribuintes a utilizar, sujeita todos os contribuintes que utilizem tais programas, seja por escolha pessoal do contribuinte ou por obrigação normatizada "interna corporis", à pena especificada na mesma lei 9609:
Além do risco jurídico decorrente da ausência de licença, há diversos outros associados com a forma em que o software é oferecido, com o processo de entrega de declarações eletrônicas, tanto através da Internet quanto em escritórios da Receita Federal, e com a validade jurídica do recibo emitido.
Para melhor apresentar os riscos, vamos supor que a Receita Federal, ou uma quadrilha envolvendo seus funcionários envolvidos no processamento de declarações de imposto de renda, decida prejudicar um determinado contribuinte através dos mecanismos à sua disposição.
Enumeramos a seguir algumas formas de afetar o contribuinte alvo sem efeitos visíveis aos demais, só permitidas graças à intensa obscuridade do processo:
impedir a entrega da declaração via Internet
impedir o preenchimento da declaração eletrônica
emitir recibo inválido, de forma imperceptível ao contribuinte, ou evitar sua emissão
adulterar a declaração, antes, durante ou após a entrega, sem conhecimento do contribuinte
alegar o recebimento de declarações retificadoras
vazar informações do contribuinte sem seu conhecimento, inclusive certificados digitais
Para evitar esses problemas, é necessário que todo contribuinte tenha a possibilidade de entregar sua declaração de forma juridicamente segura, como por exemplo através de formulário em papel, mas que aquele que optar por utilizar a entrega eletrônica possa inspecionar os programas oferecidos pela Receita Federal ou implementar seus próprios, de acordo com especificações que a própria Receita Federal deveria publicar no tocante a formatos de arquivos, protocolos de comunicação e requisitos para validação de declarações e recibos, como já faz o Servicio de Rentas Internas (Receita Federal) do Equador [SRI,EqSL] e como deveria fazer o Brasil, conforme recomendação do e-PING: Padrões de Interoperabilidade de Governo Eletrônico, versão 2.0 [ePING2]:
Adoção Preferencial de Padrões Abertos: a e­PING define que, sempre que possível, serão adotados padrões abertos nas especificações técnicas. [...] soluções em Software Livre são consideradas preferenciais
No Apêndice Detalhes técnicos, detalhamos os artifícios técnicos que podem ser utilizados para causar inconveniência ou prejuízo a contribuintes específicos e justificamos a necessidade das informações acima como forma de impedi-los ou ao menos de permitir sua comprovação.
Desrespeito ao Princípio da Transparência
Conforme explicado na seção anterior, o acesso ao código fonte das aplicações, especificação pública dos formatos de arquivo e protocolos envolvidos são essenciais para trazer segurança jurídica ao contribuinte. A Constituição Federal, além de submeter a administração pública ao princípio da publicidade em seu artigo 37, estabelece, em seu artigo 5º:
A lei 11111 [L11111], de 5 de maio de 2005, que regulamenta este inciso, traz ressalvas a questões de preservação de privacidade e de segurança da sociedade e do Estado.
O estabelecimento de um canal seguro de comunicação para o envio da declaração é essencial para preservar a privacidade, mas a divulgação do código fonte das aplicações, dos formatos de arquivo e protocolos em nada prejudica o estabelecimento desse canal seguro.
Poder-se-ia argumentar que há necessidade de controle do código fonte das aplicações e segredo sobre os formatos de arquivo e os protocolos para impedir a submissão de declarações inválidas.
Porém, se a segurança fosse utilizada como argumento para não exposição dessa informação, isso indicaria a vulnerabilidade do sistema de recepção de declarações na Receita Federal: se for possível, de maneira acidental ou intencional, induzir esse sistema a se comportar fora das especificações, aceitando como legítimas declarações inválidas, ele já é vulnerável e deve ser corrigido.
Não se pode depender da falta de informação de terceiros para garantir a segurança de um sistema. As salvaguardas devem ser internas, caso contrário algum esforço de engenharia reversa seria muito recompensador, e provavelmente já teria sido explorado.
Em face dos fracos argumentos contra a publicação do código fonte e da especificação de formatos de arquivos e protocolos, contrapostos aos fortíssimos argumentos em prol de sua transparência, cabe objeção legal à prática corrente.
Desrespeito ao Princípio da Impessoalidade
A Constituição Federal, em seu artigo 37, submete a administração pública ao princípio da impessoalidade. Como justificar, então, a escolha arbitrária de plataformas de software para os programas da Receita Federal?
Talvez se pudesse justificar a plataforma MS-Windows em função de sua imensa penetração, mas, ao invés de o poder público favorecer a preservação do monopólio de uma empresa estrangeira conhecida por abuso de poder monopolístico, desrespeito ao consumidor e ameaça à soberania dos países que utilizam suas tecnologias inauditáveis, parece-nos que seria mais adequado favorecer a livre concorrência e as empresas brasileiras de pequeno porte, conforme os princípios da ordem econômica estabelecidos na Constituição Federal:
A introdução da possibilidade de uso de máquinas virtuais Java, disponíveis gratuitamente, ainda que com licença restritiva, ao invés do oneroso MS-Windows, foi um passo correto no sentido de deixar de favorecer o maior monopólio da indústria de software.
Porém, ao invés de alcançar a almejada impessoalidade, apenas passou a favorecer mais uma empresa, também estrangeira.
Java é uma linguagem de programação e um ambiente de execução (máquina virtual) de especificações públicas, abertas e não sujeitas ao pagamento de royalties. Dessa forma, qualquer um pode implementar a especificação e oferecer ambientes de desenvolvimento e máquinas virtuais capazes de interpretar programas criados de acordo com a especificação.
Infelizmente, os programas da Receita Federal dependem de funcionalidades que não fazem parte da especificação nem acompanham o próprio programa. Tais funcionalidades estão presentes, ainda que não documentadas, apenas na máquina virtual desenvolvida pela própria Sun Microsystems e noutras nela baseadas.
Há outras implementações de Java que não oferecem essas funcionalidades. Nem poderiam, por causa das regras de nomenclatura da linguagem e dos nomes dados pela Sun a essas funcionalidades.
Algumas dessas outras implementações são licenciadas em termos que permitem, sem ônus, a modificação e a distribuição das versões modificadas, pois são Software Livre [DSL], que respeita as liberdades do usuário de usar o programa para qualquer propósito, estudá-lo, modificá-lo de acordo com suas necessidades e distribuí-lo, na forma original ou com modificações.
Mesmo que às máquinas virtuais livres fosse possível adicionar as funcionalidades exigidas pelos programas da Receita Federal, seria mais conveniente e correto se a Receita Federal se mantivesse fiel ao princípio da impessoalidade, oferecendo suas aplicações de acordo com a especificação da linguagem, e não de modo que favoreça uma determinada implementação em detrimento das demais.
Por mais que a implementação da própria Sun esteja em processo gradual de liberação como Software Livre, de modo a ingressar na categoria de software preferida pela Constituição Brasileira [PSL], não há previsão de que esse processo esteja completo antes do prazo limite para entrega das declarações de imposto de renda do exercício de 2006.
Uma vez que o processo de liberação esteja concluído, a escolha dessa implementação deixa de ser favorecimento a um único fornecedor, já que, tratando-se de Software Livre, qualquer um pode se dispor a oferecer serviços sobre a mesma base de software.
A publicação de todos os códigos fontes e documentação de formatos de arquivos e protocolos, defendida na seção anterior, possibilitaria que a sociedade contribuísse diretamente para a melhoria das aplicações, não apenas no aspecto de facilidade de uso ou praticidade, mas também no sentido de possibilitar a usuários das mais diversas plataformas de software preparar e enviar suas declarações, seja através da adaptação da aplicação disponibilizada pela Receita Federal, seja através do desenvolvimento de novas aplicações.
A possibilidade de investigação e correção de erros nessas aplicações também seria desejável. Por certo há erros, ainda que os conhecidos pelos autores sejam pequenos. Na declaração do exercício de 2005 de um dos autores deste artigo, tanto o resumo quanto a declaração diziam:
Total do imposto retido na fonte (Operações em bolsa - Lei nº 11.033/2004), conforme dados informados pelo contribuinte: 5,[...]E306
enquanto o valor correto seria zero, não 5 seguido de 306 zeros à esquerda da vírgula.
Na mesma declaração, o resumo caberia numa única página, mas o programa insistia em gerar uma página vazia a mais, tanto no resumo isolado quanto na declaração completa.
A possibilidade de a Receita Federal poder contar com correções e melhoramentos voluntários aos seus programas aumentaria a eficiência de seu investimento no desenvolvimento desses programas, atendendo ao princípio constitucional de mesmo nome estabelecido para a administração pública também no artigo 37.
Mesmo que haja interesses comerciais na criação e distribuição de modificações, ou mesmo de programas alternativos completos, não há violação do princípio da impessoalidade se a possibilidade for estendida a todas as pessoas físicas e jurídicas, de modo a reduzir desigualdades regionais, conforme princípio da ordem econômica.
Defendemos, portanto, o oferecimento dos programas da Receita Federal na forma de Software Livre, sob licença "copyleft", ou seja, que exija o uso dos mesmos termos de licenciamento para distribuição de versões modificadas.
Isso garante que não apenas os softwares originais distribuídos pela Receita Federal, mas também as versões dele modificadas por terceiros sejam disponibilizadas em termos de licenciamento livres. Isso possibilita o exercício das liberdades fundamentais do Software Livre [DSL], não só respeitando o princípio da impessoalidade, mas também fomentando a indústria de software local e por conseguinte favorecendo o pleno emprego, ambos princípios da ordem econômica.
Discriminação filosófica
A exigência de uso de software que não respeita as liberdades de seus usuários consiste em discriminação filosófica e política.
O movimento pelo Software Livre é um movimento político, filosófico e técnico que prega o respeito às liberdades de usuários e desenvolvedores de software, conforme estabelecido da Definição de Software Livre [DSL].
O projeto GNU foi criado com o intuito de criar um sistema operacional constituído exclusivamente de Software Livre, de modo que usuários pudessem utilizar computadores sem abrir mão dessas liberdades.
Com o surgimento do Linux, uma peça de software que preenchia uma lacuna ainda existente no projeto GNU, pôde-se combinar GNU+Linux e tornar o intuito uma realidade.
A licença GNU GPL (General Public License, ou Licença Pública Geral), utilizada pela imensa maioria dos Softwares Livres, inclusive o Linux, foi criada de modo a garantir que o respeito às liberdades seja inseparável do software que ela acompanha, através do mecanismo de "copyleft" por ela introduzido.
Participantes desse movimento procuram rejeitar, por questões morais e éticas, software licenciado sob termos que não respeitem essas liberdades.
O respeito a essa opção política e filosófica é exigido pela Constituição Federal, em seu artigo 5º, combinando-se o já citado inciso II com o seguinte:
A Receita Federal, no momento em que exige de um contribuinte, sem respaldo de lei, o preenchimento e entrega de sua declaração em programa de computador não Livre, sem oferecer-lhe as alternativas de preenchimento em papel ou da criação de Software Livre para esse fim, impõe ao contribuinte a escolha entre trair suas convicções políticas e filosóficas, utilizando o Software não Livre, ou deixar de cumprir com suas obrigações fiscais, com as penalidades e privações de direitos que isso possa acarretar.
Nenhuma das alternativas é adequada e a Receita Federal não tem a prerrogativa de impor essa restrição ao contribuinte.
Vale mencionar que a ressalva no inciso VIII se aplica quando a obrigação legal é imposta a todos, mas a receita exige o uso do software apenas de alguns contribuintes, portanto a ressalva não se aplica a este caso.
Também cabe argumentar contra a discriminação dos que elegem entregar a declaração em formato não eletrônico, seja por alinhamento político ou filosófico, seja por mera falta de confiança em função da fragilidade e insegurança jurídica do processo eletrônico.
Não deveria haver atraso no pagamento de restituição de acordo com o formato escolhido para a entrega da declaração.
A constituição federal exige o respeito às convicções políticas e filosóficas que não conflitem com a lei e, de fato, proíbe a discriminação a tais convicções, também em seu artigo 5º:
A fim de garantir o respeito da Receita Federal aos Princípios Constitucionais da Legalidade, Impessoalidade, Publicidade e Eficiência e a segurança jurídica dos contribuintes, assim como para evitar discriminação e oferecer maior conveniência aos contribuintes, sugerimos aos contribuintes que solicitem ou, quando couber, exijam:
que o código fonte de todos os programas necessários à preparação e ao envio de declarações de imposto de renda, e quaisquer outras obrigações fiscais, sejam disponibilizados a todos;
que a licença de uso dessas aplicações permita a execução, o estudo, a modificação e a distribuição do software, com ou sem modificações, sem porém permitir que terceiros efetuem modificações e as distribuam sem conceder as mesmas permissões a outros usuários;
que os formatos de arquivos e protocolos de comunicação dessas aplicações com os servidores da Receita Federal, inclusive os mecanismos de criptografia e assinatura digital, sejam documentados de forma pública, de modo a permitir implementações alternativas;
que a Receita Federal publique os procedimentos internos de validação de consistência de declarações e de recibos, incluindo uma chave pública ou certificado utilizado para comprovar a autenticidade dos recibos, a fim de possibilitar validação independente de declarações;
que a Receita Federal estabeleça mecanismos para notificação de contribuintes a respeito de submissões de declarações em seu nome, mesmo na existência de mecanismos que dificultem essa prática, a fim de possibilitar recurso de repúdio ou confirmação em tempo hábil.
Essas práticas favoreceriam o cumprimento da Constituição Federal:
Por todas razões apontadas, cabe oposição à distribuição desses programas na forma como vem sendo feita, possivelmente através de mandado de segurança, conforme artigo 5º da Constituição Federal:
Esperamos que este artigo forneça à Receita Federal orientações sobre como melhor cumprir com suas obrigações; aos contribuintes, mais argumentos para recuperar seus direitos violados e, aos órgãos internos de fiscalização do governo, tais como o Ministério Público e a Procuradoria Geral da República, elementos para buscar a defesa dos direitos de todos os contribuintes através da correção imediata dos problemas apontados, cumprindo seu papel de garantir a segurança dos cidadão em face de arbitrariedades cometidas pelo poder público.
Estendemos nossa gratidão a Omar Kaminski pelos valiosos comentários e sugestões. Os erros, naturalmente, são nossos e não dele.
Apêndice: Detalhes técnicos
Uma forma relativamente simples de prejudicar um contribuinte seria impedir que ele entregasse a declaração. O programa de transmissão, ReceitaNet, pode estar configurado para reconhecer o CPF do contribuinte e simular uma falha na transmissão. Se o programa afirmar não ser capaz, naquele momento, de estabelecer contato com o computador da Receita Federal responsável pela recepção da declaração, o usuário provavelmente apenas tentará novamente a transmissão mais tarde.
À medida em que o prazo final para entrega se aproxime, o programa pode passar a afirmar que o servidor está congestionado, o que o contribuinte considerará crível. Acabará não conseguindo entregar a declaração via Internet no prazo, não poderá mais efetuar a entrega através de disquete pois o prazo também já se terá encerrado e, não tendo qualquer suspeita sobre o mau funcionamento do programa, entregará a declaração com atraso, arcando com a multa correspondente. Somente o acesso ao código fonte do programa ReceitaNet permitiria a comprovação de seu comportamento discriminatório nesse cenário fictício, mas perfeitamente plausível.
Falha semelhante poderia ser introduzida no programa que recebe as transmissões, e de forma ainda mais preocupante por ser possível, a qualquer momento, a alteração do programa de modo a remover quaisquer traços do comportamento discriminatório.
A fim de evitar tal situação, um recibo de transmissão precisaria ser emitido antes de o programa conhecer a identidade do contribuinte.
Não há como saber se a Receita Federal tomou essas precauções, pois nem o código fonte do ReceitaNet nem o protocolo de comunicação entre ele e o servidor da Receita Federal que recebe as declarações são de conhecimento público.
Segue uma descrição detalhada de uma forma de implementar a transmissão segura da declaração e do recibo correspondente, usando técnicas criptográficas conhecidas:
O contribuinte envia a declaração em duas partes criptografada com chaves distintas geradas pelo programa do contribuinte, portanto não conhecida pela Receita Federal. A primeira parte contém apenas informação que deva constar do recibo e uma assinatura digital sobre a segunda parte, gerada com a chave da primeira; a segunda contém o restante da declaração e a chave para decodificar a primeira.
O computador da Receita Federal gera um recibo contendo assinaturas digitais das duas partes, e outras informações de confirmação do recebimento, criptografa o recibo com uma chave gerada nesse momento e o assina com sua chave privada.
O contribuinte pode nesse momento verificar a autenticidade do recibo através da chave pública da Receita Federal.
Após a troca de declaração por recibo criptografados, e portanto incompreensíveis para os receptores, dá-se início a um procedimento seguro de revelação mútua de segredos, de modo que a Receita Federal tenha acesso à chave usada para a segunda parte da declaração no momento em que o contribuinte tenha acesso à chave usada para o recibo.
Neste momento, o contribuinte já possui um recibo que comprova a entrega de sua declaração. O protocolo pode ainda prever uma fase seguinte em que o computador da Receita Federal verifica e atesta a integridade da declaração recebida, para possível anexação ao recibo.
O contribuinte pode então apresentar como prova de entrega da declaração o recibo criptografado e assinado pela Receita Federal, a primeira parte da declaração e as chaves para decodificação do recibo e da primeira parte da declaração.
O mecanismo descrito acima coíbe outras formas de prejudicar um contribuinte específico:
a adulteração de informação da declaração em trânsito ou
nos bancos de dados da Receita Federal.
O programa de transmissão de declarações, o programa de recepção na Receita Federal e quaisquer sistemas que tenham possibilidade de modificação do banco de dados de declarações, dentro da Receita Federal, podem ser programados para adulterar o conteúdo de uma declaração específica, de forma a que a declaração seja considerada inconsistente, incompleta ou mesmo falsa.
Isso por óbvio poderá ocasionar ao contribuinte desde atraso no recebimento de restituição até processos por sonegação ou falsidade, em que o contribuinte se verá incapaz de sustentar qualquer argumento contrário às alegações da Receita Federal, por não poder inspecionar os programas que utilizou e por não ser capaz de comprovar ter enviado as informações que espera ter enviado, uma vez que não tem acesso à especificação do formato do arquivo da declaração nem do recibo.
O mecanismo descrito acima, em que as duas partes criptografadas da declaração tenham sido assinadas digitalmente pela Receita Federal, no recibo emitido antes de ela conhecer a identidade do contribuinte, permite ao contribuinte comprovar eventuais modificações posteriores ao envio.
Porém, para comprovar ou evitar modificações introduzidas pelo próprio programa de envio, ele necessitaria acesso ao código fonte desse programa, ou que os arquivos gravados para transmissão da declaração já estivessem em formato criptografado, acompanhado das chaves necessárias para acessar a informação na declaração, mas não para gerar a assinatura digital da segunda parte, presente na primeira.
Para sua segurança jurídica, o contribuinte deve ainda poder verificar de maneira independente que o recibo emitido diz respeito aos arquivos que preparou para transmissão, e não a uma versão adulterada deles.
Resta ainda outro ponto para introdução de adulterações: o programa de preenchimento da declaração. Ele pode estar programado para gerar os arquivos para transmissão de modo a prejudicar o contribuinte alvo.
Para evitar esse risco, é necessário que a descrição do formato do arquivo de envio seja pública, de modo que seja possível verificar que a informação contida no arquivo é efetivamente aquela que o contribuinte pretende enviar.
Ainda assim, o programa de preenchimento de declaração pode guardar surpresas.
Pode, por exemplo, ser programado para rejeitar um determinado CPF como inválido; para apresentar defeitos diversos tais como falhas na gravação, recuperação ou apresentação de informações da declaração; simulação de erros de programação que resultem em término do programa sem gravar informações preenchidas; geração de assinaturas inválidas ou mesmo o uso de chaves conhecidas a fim de possibilitar adulteração da declaração ou do recibo, ou rejeição da entrega.
Todos esses mecanismos podem estar presentes no programa, mas desativados, exceto para o contribuinte alvo, identificado pelo CPF fornecido ao programa no início do preenchimento. Mesmo para o contribuinte alvo, o desvio do comportamento esperado pode ser imperceptível. Somente com acesso ao código fonte do programa de preenchimento se pode garantir que ele não contenha tais medidas.
Todavia, há outra maneira de garantir ao contribuinte a possibilidade de preparar sua declaração corretamente para entrega. Basta que haja documentação pública sobre o formato do arquivo de transmissão, ainda que nesse caso possa ser necessário ao contribuinte desenvolver seu próprio programa de preparação da declaração.
Outra forma de causar prejuízo a um contribuinte específico seria a recusa em emitir-lhe um recibo de entrega.
Por isso, no mecanismo descrito acima, o computador da Receita Federal emite um recibo antes de conhecer a identidade do contribuinte, inviabilizando a recusa discriminatória.
A assinatura digital sobre o recibo criptografado impede o repúdio do recibo, atrelado à declaração através das assinaturas digitais incluídas no recibo, e coíbe a emissão impune de recibos inconsistentes, incorretos ou falsos, já que a assinatura digital comprova a origem do recibo.
Como a assinatura do recibo é emitida e enviada antes de se conhecer a identidade do contribuinte, impede-se ainda a emissão de recibos com assinaturas inválidas para contribuintes específicos.
Resta, porém, o risco de envio de múltiplas declarações do mesmo contribuinte.
Como qualquer um pode gerar e enviar declarações em nome de qualquer contribuinte, não cabe à Receita Federal se recusar a emitir um recibo em função de envio de declaração anterior, do contrário seria possível causar prejuízo a um contribuinte enviando, ou fazendo parecer que foi enviada, uma declaração falsa antes que ele tivesse oportunidade de fazê-lo, ou enviando, ou fazendo parecer que foi enviada, uma retificação após o envio legítimo.
De fato, para possibilitar a recusa de emissão de recibo nesses casos, seria necessário revelar a identidade do contribuinte mais cedo, expondo-o à possibilidade das formas de discriminação descritas anteriormente.
Uma forma de oferecer segurança ao contribuinte contra esse tipo de ameaça seria o uso de certificados digitais para incluir, no conteúdo não criptografado da primeira parte da declaração, uma assinatura digital gerada através do certificado digital do contribuinte.
Para contribuintes que não possuam ou prefiram não usar seus certificados digitais nesse caso, pode-se utilizar assinatura gerada com uma chave utilizada no envio anterior, da mesma forma que hoje se solicita o número do recibo do envio anterior.
É importante que essa medida seja utilizada para a segurança do contribuinte, e não contra ele. A entrega de declaração em papel acompanha assinatura de próprio punho do contribuinte e portanto pode colocar o ônus da prova no contribuinte caso ele tente repudiar uma declaração em seu nome.
Porém, dada a vulnerabilidade dos sistemas computacionais, a assinatura digital não deve receber o mesmo peso jurídico que uma assinatura de próprio punho, não podendo servir de prova definitiva de que uma declaração tenha sido enviada em nome do contribuinte a que corresponde a assinatura eletrônica, ao menos enquanto perdurar tal vulnerabilidade.
De fato, sem acesso ao código fonte das aplicações oferecidas pela Receita Federal, não há razão para o contribuinte confiar que elas mesmas não provoquem o vazamento de chaves ou certificados.
Mesmo que implementadas essas formas de assinatura digital, em caráter opcional, devem-se ainda estabelecer mecanismos de notificação de contribuintes a respeito de submissões múltiplas em seu nome, a fim de possibilitar correções e eventuais investigações criminais em tempo hábil, o que pode até mesmo coibir o envio indevido de declarações.
Cabe ainda argumentar em favor da publicação dos procedimentos de verificação de consistência aplicados a uma declaração enviada.
Ainda que a Receita Federal possa oferecer um serviço que apresente o resultado de sua validação, dada a identificação de uma declaração enviada anteriormente ou mesmo uma declaração ainda não enviada, convém que se possa verificar um declaração numa implementação independente, de forma manual ou automática, antes ou mesmo depois de seu envio.
Caso contrário, o cidadão novamente se vê à mercê de atos arbitrários emanados pela Receita Federal, através de alegações infundadas mas incontestáveis de que sua declaração seja inválida.
Reiteramos que todos os riscos ao contribuinte expostos acima só existem graças à obscuridade do processo, que se traduz em violação do princípio da transparência, oriundo do princípio constitucional da publicidade.
[L9250] http://www.planalto.gov.br/ccivil/Leis/L9250.htm
[PLJ] http://jus2.uol.com.br/doutrina/texto.asp?id=2275
[PLW] http://pt.wikipedia.org/wiki/Princ%C3%ADpio_da_legalidade
[CF1988] http://www.planalto.gov.br/ccivil/Constituicao/Constitui%E7ao.htm
[L9609] http://www.planalto.gov.br/ccivil/Leis/L9609.htm
[SRI] http://declaraciones.sri.gov.ec/rec-declaraciones-internet/general/especificacionesTec.jsp
[EqSL] http://blog.gmane.org/gmane.linux.distributions.equinux.general/month=20060801/page=7
[ePING2] http://www.governoeletronico.gov.br/governoeletronico/publicacao/down_anexo.wsp? tmp.arquivo=E15_677e-PING_v2.0_17112006_LINUX_FINAL.pdf
[L11111] http://www.planalto.gov.br/ccivil/_Ato2004-2006/2005/Lei/L11111.htm
[DSL] http://www.gnu.org/philosophy/free-sw.pt.html
[PSL] http://www.fsfla.org/?q=pt/node/108
Autores e Direito Autoral
* Alexandre Oliva é Doutor em Ciência da Computação pela Unicamp, engenheiro da RedHat e conselheiro da FSF America Latina (FSFLA)
** Pedro Antônio Dourado de Rezende é matemático, professor de Ciência da Computação na Universidade de Brasília (UnB), Coordenador do Programa de Extensão em Criptografia e Segurança Computacional da UnB, conselheiro da FSFLA e ex-representante da sociedade civil no Comitê Gestor da Infra-estrutura de Chaves Públicas brasileira (ICP-BR). www.cic.unb.br/~rezende/sd.htm
Permissão é concedida para criar, publicar e distribuir cópias fiéis integrais deste documento completo, sem royalties, desde que esta nota de direito autoral, esta nota de permissão e a URL abaixo sejam preservadas.

References: artigo 37
 artigo 12
 artigo 37
 artigo 5
 artigo 37
 artigo 37
 artigo 5
 artigo 5
 artigo 5