Je trouve votre point de vue bien pessimiste !
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...
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.
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é technique..)
la mise en place d'une PKI classique contre l'invocation de "Trust
Services", hébergés chez Verisign ou autres : Dans ce dernier cas le travail
consiste "simplement" à intégrer aux applications -existantes, nouvelles-
les services XKMS grâce à des APIs Windows, Java, déja disponibles
(http://www.xmltrustcenter.org/xkms/index.htm) - ou plus simple encore, pour
reprendre votre exemple, à mettre à jour sa version de naviguateur ! - et à
passer un accord avec le fournisseur du "Trust Service".
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.
Je ne partage donc pas votre pessimisme quant à l'adoption des technologies
XML pour les services de sécurité, bien au contraire !
Cordialement,
Rémy Mathieu-Daudé
Octo Technology
P.S : Je vous invite à downloader notre livre blanc sur la sécurité
(http://www.octo.com)
----- Original Message -----
From: <redacteurs@xmlfr.org>
To: <xml-decid@xmlfr.org>
Sent: Thursday, November 29, 2001 9:37 AM
Subject: [xml-decid] INFO : PKI est trop complique
> PKI est trop complique
> Les promesses de XML quant a la securite ne seront tenues que si l'on
> parvient a une simplification generale des procedures en cause,
> particulierement au niveau de la configuration des postes clients.
> Par Herve AGNOUX [1] , de la SARL diaam informatique [2] , pour XMLfr
> [3] et le groupe XML Securite d'Annecy Multimedia [4] .
> ---------------
> Retrouvez cet article en ligne
> (http://xmlfr.org/actualites/decid/011129-0001).
>
> Donnez votre avis !
> mailto:xml-decid@xmlfr.org?subject=Re:%20INFO%20:%20PKI
> est%20trop%20complique
> ---------------
>
> C'est un probleme qui est regulierement releve [5] chez les analystes
> de la securite : le montage a base de double clef et de tiers de
> confiance ( PKI pour Public Key Infrastructure ) est trop complique.
>
> Les acteurs du domaine en sont heureusement conscients.
>
> De jeunes standards se developpent, avec en premiere ligne le XKMS (
> XML Key Management Specification ), SAML ( Security Assertion Markup
> Language ), PMI ( Permission Management Infrastructure ) ou XACML ( XML
> Access Control Markup Language ).
>
> Mais, prises telles quelles, ces technologies ne rendront pas les
> infrastructures de confiance plus simples a deployer et a organiser.
>
> XKMS , par exemple, croit simplifier la mise en oeuvre des postes
> clients en deleguant la gestion des certificats a des tiers de
> confiance. Mais, pour conduire les echanges necessaires a cette
> delegation, il se base sur le protocole SOAP , alors que celui-ci n'est
> pris en compte que par les nouveaux navigateurs. Que doit-on faire de
> la base installee ?...
>
> De plus, XKMS et SAML obligent a un accroissement considerable du
> nombre de tiers de confiance, et exigent une collaboration tres forte
> entre eux, tout en les specialisant selon des taches d'enregistrement
> des parties prenantes et d'enregistrement d'affirmations. Personne ne
> sait vraiment, aujourd'hui, faire fonctionner ce nouveau monde.
>
> Pour reussir les enjeux afferents a la securite XML , deux points sont
> fondamentaux.
>
> Le premier est la coordination des organismes de normalisation. Il faut
> qu'un seul organisme soit referent en ces domaines. Les dispersions
> entre IETF , W3C et OASIS sont contre-productives. Cet organisme unique
> devra non seulement produire des recommandations stables, mais encore
> des applications de references ouvertes.
>
> Le deuxieme est le plus important. Il s'agit de la mise en oeuvre de la
> securite sur les postes clients. Celle-ci devra etre parfaitement
> simple si l'on veut toucher le grand public.
>
> Si ces deux points, qui ne concernent pas directement la technologie
> XML , sont atteints, alors nous pourrons reparler de XML avec quelques
> chances de reussite.
>
> Autres articles:
>
> - Une introduction a XML Signature. [6]
> - Le W3C doit mettre de l'ordre dans la boite a outils. [7]
> Copyright 2001 , Herve AGNOUX .
>
> ---------------------------------------------------------
> References:
> [1] mailto:herve.agnoux@diaam-informatique.com
> [2] http://www.diaam-informatique.com
> [3] http://xmlfr.org
> [4] http://www.jeudinet.com
> [5] http://www.itworld.com/nl/java_sec/11022001/pf_index.html
> [6] http://xmlfr.org/actualites/tech/010913-0001
> [7] http://xmlfr.org/actualites/decid/010316-0003
> ---------------------------------------------------------
> Mail genere par FormatedTextOutputHandler pour XT
> (http://4xt.org/downloads/examples/outputhandlers/formatedtext/).
>
>
> --
> 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)
>
>
--
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 Thu Nov 29 11:57:59 2001
