1 | Entrega 1.0: |
---|
2 | -Functionalidades de assinatura e verificação de assinaturas concluída |
---|
3 | -Geração de PDF concluído |
---|
4 | -correcção dos problemas reportados anteriormente concluídos |
---|
5 | |
---|
6 | |
---|
7 | |
---|
8 | |
---|
9 | |
---|
10 | |
---|
11 | |
---|
12 | |
---|
13 | |
---|
14 | |
---|
15 | |
---|
16 | |
---|
17 | |
---|
18 | Esta entrega contém as seguintes alterações principais: |
---|
19 | |
---|
20 | 1) Visual Studio SDK automaticamente descarregado e instalado se detectada ausência no sistema anfitreão. |
---|
21 | Deixa de ser preciso instalação explicita pelo cidadão. |
---|
22 | |
---|
23 | 2) O algoritmo de autenticação foi simplificado. A lógica que presidiu às alterações foi : |
---|
24 | |
---|
25 | - Não faz sentido o cliente validar a sua própria identidade (cadeia de certificação no cartão). |
---|
26 | Não dá garantias nenhumas ao servidor e é redundante com a verificação sugerida do lado do |
---|
27 | servidor. |
---|
28 | |
---|
29 | - Faz sentido garantir que uma aplicação assinada pela AMA impeça a informação do cidadão de ser enviada |
---|
30 | de forma não encriptada (o que acontecería se o servidor configurasse um url para envio de informação |
---|
31 | que não fosse HTTPS). |
---|
32 | |
---|
33 | - Relativamente à autenticidade do servidor: é o servidor que envia a página em que a applet está contida |
---|
34 | e é ele também que define o url para envio da informação seleccionada. Um certificado válido nesse url |
---|
35 | não garante idoneidade na utilização da informação enviada. Por outro lado um certificado inválido |
---|
36 | levanta suspeitas legitimas sobre a identidade e logo sobre a idoneidade, das quais um cidadão utilizador |
---|
37 | duma aplicação assinada pela AMA espera ser informado. Mas esta validação é executada automaticamente |
---|
38 | pelo browser quando a applet o redirige para esse URL. A única coisa que os browsers actuais não fazem |
---|
39 | é ter a verficação OCSP activada por default, eminentemente por questões de manutenção de privacidade |
---|
40 | da navegação na web relativamente ao servidor OCSP. Exceptuando a verificação de que o URL é HTTPS, |
---|
41 | todas as outras verificações de autenticidade do URL de submissão que estavam a ser feitas são |
---|
42 | redundantes com as efectuadas pelo browser e foram removidas. |
---|
43 | |
---|
44 | - Faz todo o sentido continuar a assinar digitalmente a informação enviada, com a chave privada contida no |
---|
45 | cartão. É isto que autentica de facto o utilizador. |
---|
46 | |
---|
47 | 3) Inclui versões windows-x86 e linux-x86 e linux-amd64 do SDK (bibliotecas nativas) com o bug da |
---|
48 | assinatura nos cartões GemSafe corrigido. |
---|
49 | |
---|
50 | 4) Extende a interface javascript esperada pela applet em modo headless para : |
---|
51 | - utilização de pinpads (apenas Xiring por enquanto) |
---|
52 | |
---|
53 | 5) Fornece uma implementação-exemplo da interface javascript proposta para o modo headless, que usa |
---|
54 | prompts javascript para a introdução do pin, em vez da janela Swing anterior (estes prompts serão |
---|
55 | evoluidos para esconderem o PIN introduzido)que interferiría com o aspecto gráfico do site do integrador. |
---|
56 | |
---|
57 | |
---|
58 | Combinações testadas com sucesso : |
---|
59 | ---------------------------------- |
---|
60 | Windows 32 XP - Chrome 16.0.912.63 m |
---|
61 | Windows 32 XP - Firefox 9.0.1 |
---|
62 | Windows 7 (64 bits) - IE 9 (32 bits) - (headless ainda com problemas de renderização de javascript) |
---|
63 | Linux 64 bits (Slackware/código nativo Caixa Magica 16) - Firefox 8.0.1 (32 bits) |
---|
64 | Linux 32 bits (Caixa Mágica 16) - Firefox 8 |
---|
65 | |
---|
66 | Combinações testadas sem sucesso: |
---|
67 | --------------------------------- |
---|
68 | Windows 32 XP - IE8 (32 bits) |
---|
69 | Linux 64 bits (Slackware/código nativo Caixa Magica 16) - Chrome 15.0.874.121 (32 bits) |
---|
70 | |
---|