A mon sens, un des soucis de ce genre de réseau (PGP/GPG ou SSH) est qu'il est basé sur des clefs ayant la plupart du temps une durée de vie infini. Donc on monte son réseau et puis un jour ... patatras, il y a un article qui dis que les clefs ne sont pas si géniale que cela à terme.
Au final, cela me donne comme pour SSH le sentiment d'un défaut de conception. Les clefs de chiffrement à usage pour le réseau devrait toujours avoir une durée de vie limitée (c'est souvent le cas des certificat X509 que le trouve pour les sites HTTPS, mais pas toujours). La durée de vie limité résout à terme le problème des failles inévitable (cf carte bleu).
La solution de la révocation n'est pas bonne car elle demande au client d'aller voir des listes centralisées, de se mettre à jour et que celui-ci ai effectivement implémenté ce mécanisme de révocation. Bref, c'est bien mais pas assez fiable pour se baser la dessus sur du long terme.
A partir du moment ou les clefs ont une durée de vie limité, il faut dès la conception penser à la mise à jour de ces clefs et assurer la période transitoire à deux clefs. C'est souvent mal fait, même sur les certificats X509. Le CNRS a d'ailleurs été confronté au passage aux certificats CNRS2 il n'y a pas longtemps et nous avons deux ans pour mettre à jour tous nos certificats dans les laboratoires. Malgré cela, pas mal d'applications n'aiment pas le changement de certificat. Par exemple, comment mettre à jour le certificat de mon serveur OCS qui me déploie mes logiciels sachant que celui-ci a soit le nouveau, soit l'ancien certificat mais ne peut pas avoir les deux ! Cela se mors la queue et je n'ai pas trouvé de bonne solution intégrée dans OCS...
Au final, je dirais qu'il y a du travail sur la planche pour que les développeurs de ces applications modifient leurs protocoles pour tenir compte de cet aspect temporel et que le protocole lui-même gère la phase de transition avec une mise à jour automatique des clients vers les nouvelles clefs et que les deux clefs soient équivalentes pour les clients. Pour le moment, un serveur web ou ssh ne peut avoir deux clefs !
Debian l'a bien compris puisque chaque distribution est lié a une et une seule clef. Lorsqu'elle sors une distribution, la clef de la future stable est déjà dans le paquetage keyring pour que la mise à jour de la stable vers la future stable (testing) puisse se faire sans hurlement de la part d'APT. C'est ce genre de mécanisme qui doit être pensé et généralisé, bien sur en s'adaptant à la problémtique !
[^] # Re: Annonce un peu hâtive ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Nouvelles attaques sur SHA-1 : Debian pourrait migrer vers SHA-2. Évalué à 10.
Au final, cela me donne comme pour SSH le sentiment d'un défaut de conception. Les clefs de chiffrement à usage pour le réseau devrait toujours avoir une durée de vie limitée (c'est souvent le cas des certificat X509 que le trouve pour les sites HTTPS, mais pas toujours). La durée de vie limité résout à terme le problème des failles inévitable (cf carte bleu).
La solution de la révocation n'est pas bonne car elle demande au client d'aller voir des listes centralisées, de se mettre à jour et que celui-ci ai effectivement implémenté ce mécanisme de révocation. Bref, c'est bien mais pas assez fiable pour se baser la dessus sur du long terme.
A partir du moment ou les clefs ont une durée de vie limité, il faut dès la conception penser à la mise à jour de ces clefs et assurer la période transitoire à deux clefs. C'est souvent mal fait, même sur les certificats X509. Le CNRS a d'ailleurs été confronté au passage aux certificats CNRS2 il n'y a pas longtemps et nous avons deux ans pour mettre à jour tous nos certificats dans les laboratoires. Malgré cela, pas mal d'applications n'aiment pas le changement de certificat. Par exemple, comment mettre à jour le certificat de mon serveur OCS qui me déploie mes logiciels sachant que celui-ci a soit le nouveau, soit l'ancien certificat mais ne peut pas avoir les deux ! Cela se mors la queue et je n'ai pas trouvé de bonne solution intégrée dans OCS...
Au final, je dirais qu'il y a du travail sur la planche pour que les développeurs de ces applications modifient leurs protocoles pour tenir compte de cet aspect temporel et que le protocole lui-même gère la phase de transition avec une mise à jour automatique des clients vers les nouvelles clefs et que les deux clefs soient équivalentes pour les clients. Pour le moment, un serveur web ou ssh ne peut avoir deux clefs !
Debian l'a bien compris puisque chaque distribution est lié a une et une seule clef. Lorsqu'elle sors une distribution, la clef de la future stable est déjà dans le paquetage keyring pour que la mise à jour de la stable vers la future stable (testing) puisse se faire sans hurlement de la part d'APT. C'est ce genre de mécanisme qui doit être pensé et généralisé, bien sur en s'adaptant à la problémtique !