Techniquement le certificat n'a rien d'exceptionnel, il peut être utilisé par toute entité qui reconnaît la Direction Générale des Impôts comme une autorité de certification et qui sait interpréter le CN de ce certificat (rien de bien difficile).
À l'inverse la Direction Générale des Impôts peut utiliser tout certificat signé par une autorité reconnue, elle a choisi de ne pas le faire dans le cadre des impôts des particuliers (encore que... faudrait tester un certificat généré par une autorité tierce avec un CN "qui va bien"... si ça se trouve ça passe), mais elle le fait dans le cadre des impôts des professionnels.
Je ne sais plus comment se passe la délivrance du certificat précisément, en tout cas derrière la façade commune c'est deux applications bien différentes qui se chargent d'une part de la génération / distribution, et d'autre part de la saisie de l'impôt. Ce serait peut-être plus clair (et plus sûr ?) si les deux étapes étaient clairement séparées, mais ça se ferait au coût de la convivialité de l'opération, critère manifestement important aux yeux du ministère.
Le PDF est bien généré côté client, mais je ne crois pas que ce soit pour un quelconque critère de sécurité : c'est soit pour économiser de la bande passante, soit parce que quand cette partie a été développée (aux environs de 2004 je crois) il n'y avait pas de bonne techno stable de génération PDF côté serveur, soit enfin pour économiser du CPU et de la RAM côté serveur.
Ils pourraient peut-être se contenter d'afficher du PDF pour les parties critiques, mais ce serait beaucoup moins convivial voire très confus (cas des PDF qui s'affichent systématiquement hors du navigateur) ; en termes d'ergonomie c'est beaucoup plus propre d'intégrer une applet au sein du site qui a exactement la même apparence que le reste du HTML. Par contre pour ces sections critiques, une applet est bien utile, car outre l'aspect juridique qui est vraiment important (en cas de bug, on peut sortir le code source, alors que sinon on peut juste dire "faute à pas de chance" et ça marche pas génial dans un tribunal), elle diminue également les chances d'injection de HTML ou de JavaScript de provenance externe (les navigateurs ont eu pas mal de failles de sécurité à ces niveaux).
Pour ce qui est de la "mise en échec totale des avantages de la signature" il faudrait que tu t'expliques plus en détail, car je ne te comprends pas. Il me semble au contraire qu'on a là une utilisation correcte des certificats, mais je ne suis pas expert en la matière. Arguments bienvenus.
Enfin pour conclure, Java a bien été choisi sur des critères techniques (et également architecturaux et stratégiques) et non pas administrativo-bureaucrato-légaux-truc. Clairement la démarche a abouti à Java et n'est pas partie d'un a priori.
(Et au fait, il y a aussi une version ActiveX de secours pour ceux qui sont sur un poste Windows sans Java correct. La sélection est transparente lors de la phase de détection initiale.)
[^] # Re: Web, form et certificats...
Posté par Boa Treize (site web personnel) . En réponse au journal Télédéclarer ses impôts et citoyenneté. Évalué à 1.
À l'inverse la Direction Générale des Impôts peut utiliser tout certificat signé par une autorité reconnue, elle a choisi de ne pas le faire dans le cadre des impôts des particuliers (encore que... faudrait tester un certificat généré par une autorité tierce avec un CN "qui va bien"... si ça se trouve ça passe), mais elle le fait dans le cadre des impôts des professionnels.
Je ne sais plus comment se passe la délivrance du certificat précisément, en tout cas derrière la façade commune c'est deux applications bien différentes qui se chargent d'une part de la génération / distribution, et d'autre part de la saisie de l'impôt. Ce serait peut-être plus clair (et plus sûr ?) si les deux étapes étaient clairement séparées, mais ça se ferait au coût de la convivialité de l'opération, critère manifestement important aux yeux du ministère.
Le PDF est bien généré côté client, mais je ne crois pas que ce soit pour un quelconque critère de sécurité : c'est soit pour économiser de la bande passante, soit parce que quand cette partie a été développée (aux environs de 2004 je crois) il n'y avait pas de bonne techno stable de génération PDF côté serveur, soit enfin pour économiser du CPU et de la RAM côté serveur.
Ils pourraient peut-être se contenter d'afficher du PDF pour les parties critiques, mais ce serait beaucoup moins convivial voire très confus (cas des PDF qui s'affichent systématiquement hors du navigateur) ; en termes d'ergonomie c'est beaucoup plus propre d'intégrer une applet au sein du site qui a exactement la même apparence que le reste du HTML. Par contre pour ces sections critiques, une applet est bien utile, car outre l'aspect juridique qui est vraiment important (en cas de bug, on peut sortir le code source, alors que sinon on peut juste dire "faute à pas de chance" et ça marche pas génial dans un tribunal), elle diminue également les chances d'injection de HTML ou de JavaScript de provenance externe (les navigateurs ont eu pas mal de failles de sécurité à ces niveaux).
Pour ce qui est de la "mise en échec totale des avantages de la signature" il faudrait que tu t'expliques plus en détail, car je ne te comprends pas. Il me semble au contraire qu'on a là une utilisation correcte des certificats, mais je ne suis pas expert en la matière. Arguments bienvenus.
Enfin pour conclure, Java a bien été choisi sur des critères techniques (et également architecturaux et stratégiques) et non pas administrativo-bureaucrato-légaux-truc. Clairement la démarche a abouti à Java et n'est pas partie d'un a priori.
(Et au fait, il y a aussi une version ActiveX de secours pour ceux qui sont sur un poste Windows sans Java correct. La sélection est transparente lors de la phase de détection initiale.)