Page d'accueil	encyclopedie-enligne.com en page d'accueil
Liste Articles: [0-A] [A-C] [C-F] [F-J] [J-M] [M-P] [P-S] [S-Z] | Liste Catégories | Une page au hasard | Pages liées

XKMS

La gestion des certificats numériques X.509 repose actuellement sur des Infrastructures à Clé Publique (PKI en anglais). Cependant, ces dernières sont extrêmement complexes à mettre en place et à administrer. De plus, l'intéropérabilité entre les différentes implémentations est très faible car il n'existe pas de standard. Enfin, elles nécessitent un support par les applications clientes.

Objectifs

Les objectifs principaux de XKMS (XML Key Management Specification) sont :

1. créer une couche abstraite entre les applications et la solution de PKI. Cela autorise une application à se connecter à différentes solutions de PKI selon ses besoins sans nécessiter de modifier l'application ;
2. éliminer le besoin pour une application de gérer la syntaxe et sémantique complexe des PKI en utilisant un protocole simple formaté en XML en vue d'obtenir des informations sur une clé auprès d'un service XKMS ;
3. déplacer la complexité de l'application cliente au niveau de l'infrastructure, rendant ainsi l'application plus simple et petite. De ce fait, même des périphériques à faibles capacités peuvent utiliser XKMS.
4. implémenter XKMS de telle sorte qu'il soit neutre du point de vue de la plateforme, du vendeur ou du protocole de transport.

Historique

XKMS est développé par le XKMS Working Group du W3C. Le premier document de travail de la version 2.0 de XKMS a été publié le 18 Mars 2002. Un second document est sorti le 18 April 2003. Le 5 April 2004, la proposition a été jugée assez mature pour être élevée au rang de candidat à recommandation, la prochaine étape étant celui de recommandation officielle.

Description

XKMS est destiné à être implémenté en tant que service web permettant à un client d'accéder à des fonctions de PKI.

Le protocole XKMS est composé de deux parties :

1. XKISS (XML Key Information Service Specification) pour les requêtes d'information sur les clés ;
2. XKRSS (XML Key Registration Service Specification) pour enregistrer, régénérer, retrouver et révoquer des clés.

XKISS

Cette partie de XKMS gère le mécanisme permettant aux applications clientes d'authentifier des données chiffrées et/ou signées.

Le client authentifie ces données en donnant des informations sur la clé correspondante au fournisseur de service, lequel répond par vrai ou faux. Vrai indique que la clé publique correspondant à la clé privée utilisée pour signer appartient à l'entité qui déclare avoir signé les données.

La spécification XKISS définit les deux opérations suivantes :

Locate 

recherche des informations sur la clé publique correspondant à l'élément <ds:KeyInfo>. Cette opération n'assure pas la validité des données liées à la clé ;

Validate 

non seulement elle recherche la clé publique correspondant à l'élément <ds:KeyInfo>, mais elle assure également que les informations liées à la clé retournées sont dignes de confiance.

XKRSS

Cette partie de XKMS est liée au mécanisme d'enregistrement d'une paire de clés auprès d'un fournisseur de services. Il existe deux façons d'enregistrer des clés auprès d'un service XKMS :

1. le client génère une paire de clés et donne sa clé publique, avec d'autres informations au service d'enregistrement ;
2. le service XKMS génère la paire pour le client, enregistre la clé publique et envoie la clé privée au client. Le client peut aussi demander au service XKMS de garder la clé privée. La clé privée est gardée par le service au cas où le client la perdrait.

La spécification du service XKRSS définit quatre opérations :

Register 

attache des informations à une clé avec un key binding. Soit le client donne sa clé publique accompagnée d'une preuve de la possession de la clé privée associée, soit le service génère la paire de clés pour le client. Le service peut demander davantage d'informations au client avant d'enregistrer la clé publique (et éventuellement la clé privée).

Reissue 

un key binding enregistré est régénéré. De nouveaux credentials sont générés dans la PKI sous-jacente. Même s'il n'y a pas de durée de vie pour un key binding XKMS, les credentials générés par la PKI peuvent en avoir et doivent donc être régénérés périodiquement.

Revoke 

cette opération permet à un client de détruire les objets de données attachés à une clé. Par exemple, un certificat X.509 attaché à une clé d'un service XKMS est détruit quand cette opération est appelée ;

Recover 

cette opération permet à un client de recouvrer sa clé privée. Afin que cette opération soit possible, il faut que la clé privée ait été enregistrée par le service. L'une des façons pour le service d'obtenir cette clé est quand le service génère une paire de clés.

L'opération de recouvrement est très utile si la clé privée est utilisée pour chiffrer des données. Si elle est perdue, les données chiffrées deviennent inaccessibles et sont donc perdues. Dans ce cas, il est intéressant de générer la clé privée côté serveur et de la mémoriser.

Si la clé privée perdue servait uniquement à signer des documents, une nouvelle clé peut être générée sans influence sur la validité des documents signés existants. Ainsi, les clés utilisées dans cette optique peuvent être générées par le client en toute sécurité, et la clé privée ne devrait jamais être enregistrée par le service.

Un service XKMS implémentant la spécification XKRSS peut choisir d'offrir certaines, toutes ou aucune de ces opérations. La spécification XKRSS n'oblige pas un service XKMS à implémenter l'une ou l'autre de ces opérations.

--Tifauv' 28 jul 2004 à 13:03 (CEST)