Le 29 Nov 01, Remy Mathieu-Daudé a écrit :
> Je trouve votre point de vue bien pessimiste !
>
Ce n'était pas directement mon point de vue ; excusez-moi s'il y
avait confusion. Je me faisais l'écho d'un article que je trouvais
intéressant (bien que sur certain points je ne partage pas l'opinion
de l'auteur). J'avais mis le lien vers l'article original au début de mon
texte. Pour mémoire, c'est
http://www.itworld.com/nl/java_sec/11022001/pf_index.html, le titre
original (que j'aurais dû citer) étant "Simplification, not XML, is the
Key to PKI success"
Ce texte me semblait bien argumenté, être proche de ce que je
pensais, et de plus je l'ai trouvé par l'intermédiaire de la liste de
discussion xml sécurité du W3C, grâce à un "forward" posté par un
des responsables de ce groupe soi même ! Voir
http://lists.w3.org/Archives/Public/w3c-ietf-
xmldsig/2001OctDec/0093.html (Forward: Simplifying PKI and PMI
configuration), par Christian Geuer-Pollmann.
Même si l'on pouvait, et devait, critiquer ce texte, il me semblait
important de le reproduire d'abord le plus fidèlement possible.
> D'accord sur le fait que la mise en place d'une PKI est une affaire
> fastidieuse qui rebute beaucoup d'entreprises, car gérer une CA
> (Certification Authority) demande de gros moyens (gestion du cycle de vie
> des certificats, infrastructure physique sécurisée, etc), et de plus il
> faut assurer l'intégration des services PKI avec les applications
> clientes, etc...
>
Alors, nous sommes donc d'accord : c'est compliqué !
Le point sur lequel on pourrait discuter, c'est de savoir si cela vient
du problème lui-même, que l'on aurait pas encore bien compris, ou
de la solution qu'on lui apporte, qui serait inutilement compliquée.
Moi j'ai la sensation que le problème est mal posé. Que les
solutions techniques existent, et que l'on essaye de les
normaliser, d'accord. Mais ces problèmes, qui touchent à la
sécurité, à la confiance, touchent forcément aussi au domaine du
social, ou même du politique.
Et là je vois apparaitre des concepts informes, mondialisants en
diable, à base de "end user", "x2x", "business xx", et j'en passe.
Plutôt que de partir de la technique, qui est bonne, je crois que l'on
ferait mieux de partir de ces "xx", pour voir comment ils établissent
des relations de confiance, et voir comment on peut les
informatiser.
> L'initiative XKMS a pour vocation de démocratiser et normaliser l'accès
> aux infrastructures PKI en définissant un protocole simple (XKISS, XKRSS)
> entre une application cliente et un "Trust Service" : demande de
> validation d'un certificat, récupération du certificat de tel destinataire
> pour crypter un document, etc .... La complexité de la PKI (gestion des
> certificats, relations d'approbations entre CA, etc) se retrouve donc au
> niveau du "Trust Service" , elle est masquée à l'application cliente qui
> se contente d'invoquer des primitives simples. Enfin le protocole entre
> l'application cliente et le trust service s'appuie sur le protocole de
> transport standard SOAP.
>
> L'abstraction de la complexité de la PKI et l'utilisation sous-jacente de
> protocoles comme SOAP, couronné par le fait que cette initiative est sous
> contrôle du W3C, laisse donc présager un certain succès - du moins
> l'espère-t-on - à XKMS. Bien sur ce succès est assujetti à l'adoption de
> SOAP, mais je pense que personne n'ose aujourd'hui parier sur l'échec de
> ce protocole. De plus des acteurs comme Verisign proposent déja des
> versions beta de "Trust Services" XKMS.
>
Je crois que la situation du XML en général, et du SOAP en
particulier, est beaucoup plus délicate que l'on croit.
Oui, c'est une immense réussite informatique ; mais, plus de 2 (ou
de 3, je ne suis pas historien ! ) après l'apparition du XML, le
support au niveau du poste client est toujours lamentable ; je veux
bien admettre que le support XML / XSLT au niveau de IE 6
commence à être bon, mais, une fois de plus, il a fallut plus de 2
ans à Microsoft soit même pour y arriver, et de plus il faut
s'enregistrer auprès de Microsoft, crois-je avoir compris, pour le
faire fonctionner, ce qui est fort de café.
Quand à SOAP, cela fait je ne sais combien de temps que ce
N'EST PAS une recommendation du W3C. Pourquoi ? Pourquoi
depuis si longtemps tout le monde en parle et que le W3C ne le
fait pas ? Pour répondre à cela, il n'y a que des bruits de couloirs...
> Pour revenir à vos propos, bien sur les applications clientes (browsers,
> applis Web, Windows, Java..) devront intégrer SOAP et les APIs clientes
> XKMS pour invoquer les Trust Services, mais on n'a rien sans rien...Ce
> n'est pas vraiment un obstacle, surtout si l'on se place du point de vue
> d'un responsable informatique qui devra comparer (couts, difficulté
> [...]
Je ne sais pas si vous le dites sans y penser, mais effectivement il
faudra un "responsable informatique". Dans la plupart des "xx",
cette personne n'existe pas. Et même quand elle existe, je ne suis
pas du tout sûr qu'elle trouve simple de mettre à jour les
navigateurs, d'ailleurs.
De plus, quand elle existe, que lui apporte vraiment les nouvelles
techniques de sécurité à base de XML ? Depuis longtemps, le
responsable informatique sait gérer ces questions.
Ces nouvelles techniques ne trouvent leurs justifications que si
elles peuvent toucher le grand public, c'est à dire les milieux
familiaux, et tous les groupements plus ou moins stables de
PME/PMI, bref un "no man's land de responsable informatique".
Et dans ces milieux, la simple évoquation d'une "déléguation",
aussi justifiée soit-elle, sur les questions de confiance et de
sécurité est déjà toute une question, et je ne crois pas que ce soit
le W3C qui puisse apporter la solution.
>
> Enfin, en ce qui concerne XKMS (W3C) versus SAML (OASIS), ces deux
> initiatives sont complémentaires mais l'une ne cherche pas à renverser
> l'autre, car XKMS permet l'interopérabilité de PKI (gestion des
> certificats) alors que SAML permet(tra) l'interopérabilité entre systèmes
> d'authentification. Je ne pense donc pas que les travaux de W3C et OASIS
> soient contre-productifs en ce domaine, comme vous le suggérez, puisqu'il
> s'agit de deux directions différentes.
>
Vous auriez raison sur le coté technique, mais cela reste à
prouver. Quand on a mis plus de deux ans à ne pas installer le
support de XML / XSLT dans les naviguateurs, on peut craindre le
pire sur ces questions autrement plus sensibles.
Mais sur le coté social, tous ces montages sont extrêmement
fragiles. Qui seront ces tiers de confiance et systèmes
d'authentification ? En France, cela fait déjà un moment que l'on en
parle ! Et sur les postes clients, où seront stockées les clefs
privées ?! Sur la 15ème page du contrat avec le tiers de confiance,
en petits caractères, il y aura juste écrit "Vous êtes responsable
de votre clef privée" !?
Bien sûr, les choses avancent. Mais on a l'impression qu'il y a une
déconnexion entre la technique et le social (peut être même la
réalité, tout simplement). W3C, OASIS, etc, semblent être des
véhicules qui se dépêchent d'accélerer pour être les premiers,
pendant que les Chambres de Commerces peinent à vendre des
clefs publiques assermentées...
> Je ne partage donc pas votre pessimisme quant à l'adoption des
> technologies XML pour les services de sécurité, bien au contraire !
>
Au niveau du grand public, moi je suis assez pessimiste.
Tant que l'on oubliera - ou fera semblant d'oublier - les questions
d'ordre social que ces technologies posent, elles resteront un
simple terrain de jeu pour responsables informatiques à gros
budget.
L'auteur de l'article original n'abordait pas du tout cette question,
merci de m'avoir donné l'occasion de donner ma propre opinion !
Vous avez peut être remarqué que je me spécialise sur les
questions relatives à la sécurité chez les rédacteurs de xmlfr, c'est
bien que ces questions m'interessent !
Cordialement.
--
Sur le Web, tout de suite.
Herve AGNOUX - diaam informatique
http://www.diaam-informatique.com
--
Devenez redacteur <XML>fr et contribuez au developpement
du xml francophone (http://xmlfr.org/infos/redacteurs) !
Liste de diffusion "xml-decid@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet lie a XML.
Pour resilier votre abonnement, envoyez un message contenant la
commande "unsubscribe" a xml-decid-request@xmlfr.org
(mailto:xml-decid-request@xmlfr.org?Subject=unsubscribe)
Received on Fri Nov 30 04:50:34 2001
