WO2006021665A1 - Procede d'attribution de certificat d'authentification et infrastructure d'attribution de certificat - Google Patents

Procede d'attribution de certificat d'authentification et infrastructure d'attribution de certificat Download PDF

Info

Publication number
WO2006021665A1
WO2006021665A1 PCT/FR2005/002040 FR2005002040W WO2006021665A1 WO 2006021665 A1 WO2006021665 A1 WO 2006021665A1 FR 2005002040 W FR2005002040 W FR 2005002040W WO 2006021665 A1 WO2006021665 A1 WO 2006021665A1
Authority
WO
WIPO (PCT)
Prior art keywords
identity
server
certificate
identifier
information
Prior art date
Application number
PCT/FR2005/002040
Other languages
English (en)
Inventor
Loïc HOUSSIER
Laurent Frisch
David Arditti
Original Assignee
France Telecom
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom filed Critical France Telecom
Priority to DE602005005201T priority Critical patent/DE602005005201T2/de
Priority to US11/660,543 priority patent/US20070283426A1/en
Priority to EP05796241A priority patent/EP1779635B1/fr
Publication of WO2006021665A1 publication Critical patent/WO2006021665A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0421—Anonymous communication, i.e. the party's identifiers are hidden from the other party or parties, e.g. using an anonymizer

Definitions

  • the invention relates to key management infrastructures for open network computer systems. More particularly, the invention relates to a certificate granting method as well as to a system for assigning a certificate according to the method.
  • a certificate should be understood as the certificate for validating a cryptographic key used on an open computer network.
  • a standard commonly used on the Internet for public key management, certificate and certificate revocation list infrastructures is known as X.509 and more particularly X.509v3 defined in RFC3280 ( Request For Comment n ° 3280) published by the Internet Engineering Task Force (IETF).
  • the certificate is an object comprising, among others, a public key to be certified, the identity of its owner, a period of validity, a list of the rights of use of the key and a cryptographic signature of these data made using the public key of a Certificate Authority issuing the certificate.
  • PKI Public Key Infrastructure
  • Certificate management platform PKI's role is not only to create certificates but also to manage their validity, ie their revocation and renewal.
  • Figure 1 shows an example of PKI according to the state of the art.
  • the PKI mainly comprises a certification authority (CA) materialized by a certificate server 1, and a registration authority (RA) materialized by a registration server 2.
  • CA certification authority
  • RA registration authority
  • the certificate server 1 and the registration server 2 are for example linked together via the Internet, and communicate securely.
  • the certification authority is an organization recognized as competent and trusted to issue and manage certificates as well as to ensure their validity.
  • the authority of certification calculates a public key and a private key to assign to a requester.
  • the private key is then provided to the requester with the certificate so that the certificate can be used by the requester as a message signing key or access key to secure WEB services or for other applications requiring secure access.
  • the certification authority will be asked to check the validity of this key and the various data concerning the certificate, including its validity and activation or revocation.
  • the registration authority is used to establish a certificate request from the certificate authority for a certificate requester.
  • the registration authority must establish a complete certificate request in which different information will be sent according to the requested certificate.
  • the Registration Authority is responsible for verifying the information provided by the requester as to his identity and verifying if the requester is authorized to request such a certificate with the requested attribute list. in the certificate.
  • the object of the invention is to eliminate the drawbacks mentioned above.
  • a pre-registration of the identity of the applicant is carried out by a third party entity so that the registration authority can obtain certified information on the identity of the applicant.
  • the registration server verifies information from an identity server previously informed about the identity of the applicant. Thanks to the use of an identifier for obtaining identity information certified from an identity server, the registration server can make the request more quickly by checking the validity and possibly complete, with the identity server, the information required on the identity and in a certified way, to obtain a new certificate.
  • An applicant only needs to register once with an identity management authority to produce his or her identity with a plurality of registration servers. Also, the registration authority no longer needs to systematically verify identity information verified once and for all by the identity management authority.
  • the invention is a method for assigning an electronic certificate in a distributed certificate allocation infrastructure in a network, the infrastructure including at least one certificate server, an identity server and a linked registration server. to the network.
  • the identity server Prior to a request for a certificate request, information relating to the identity of a certificate requester is stored in the identity server, the identity information being accessible via an identifier.
  • An applicant requires a certificate from the registration server.
  • the identifier is sent to the identity server.
  • the identity server After verifying the identifier, sends the previously registered identity of the requester, said identity being provided to the registration server.
  • the registration server After receiving the identity, sends a certificate request including the identity of the requestor to the certificate server.
  • the certificate server sends the certificate to the applicant.
  • the registration server asks the requester for his identifier, in order to send it to the identity server.
  • the identity server After verifying the identifier, the identity server sends the registration server the previously registered identity of the requester to the registration server (20).
  • the certificate server sends the certificate to the registration server.
  • the registration server provides the certificate to the requester.
  • the identifier may be an anonymous identifier.
  • the identifier can itself be a certificate.
  • the identifier may be accompanied by a verification means.
  • the verification means may be provided by the requestor to the registration server that provides it to the identity server, and the identity server returns the identity to the registration server only if the verification means validates the identifier.
  • the verification means may be a certificate verified by the registration server.
  • each server comprising complementary identity information registered prior to a request for a certificate request, the identity information being accessible via an identifier specific to each identity server.
  • the registration server retrieves the identity information of the different identity servers in order to reconstruct a complete identity before sending it to the certificate server.
  • the invention is also a computer program product comprising instructions for implementing the method during execution by processing means implementing the method.
  • the invention relates to a computer readable recording medium, which comprises a computer program implementing the method when said program is executed by processing means implementing the method.
  • the invention is a certificate allocation infrastructure on a computer network.
  • the infrastructure has at least one authentication certificate server connected to the network and capable of providing an electronic certificate for an applicant, for a given duration and for a defined object, the certificate being issued after the receipt of an identity of a requester; an identity server connected to the network, the identity server containing information relating to the identity of a certificate requester, the identity server being able to provide, after receiving an identifier, the identity registered by the applicant; a registration server connected to the network and able to request the identity information relating to the requester from the identity server, following a certificate request from a requester, and then to send a certificate request to the certificate server including the identity information of the applicant.
  • the identity server is able to verify the validity of the identifier in order to return the identity to the registration server only if the identifier is valid.
  • a plurality of identity servers are connected to the network, each server comprising complementary identity information registered prior to a request for a certificate request, the identity information being accessible via an identifier specific to each identity server.
  • the registration server is able to retrieve the identity information of the different identity servers in order to reconstruct a complete identity before sending it to the certificate server.
  • FIG. 1 represents an example of a public key management infrastructure according to FIG. 2 represents a first embodiment of a public key management infrastructure according to the invention
  • FIG. 3 schematically represents the exchanges inside the infrastructure of FIG. 2 to request a certificate
  • FIG. 4 represents a second embodiment of a public key management infrastructure according to the invention
  • Figure 5 schematically shows the exchanges required to obtain a certificate using the infrastructure of Figure 4.
  • Figure 2 represents a first mode of implementation of a public key management infrastructure according to the invention.
  • This infrastructure comprises a certificate server 10, a registration server 20 and an identity server 30. Said servers 10, 20 and 30 are physically distinct and are interconnected via the Internet and communicate by means of a link secure.
  • the certificate server 10 materializes the certification authority.
  • the certificate server 10 upon receipt of a certificate request request issued in good form by the registration server 20, is able to calculate a public key and a private key and then to provide a certificate containing the public key as well as the other attributes of the certificate.
  • the registration server 20 materializes the registration authority.
  • the registration server 20 is able to receive requests for registration requests from a user 40, possibly via a terminal 41, itself connected to the Internet.
  • the registration server 20 is able to obtain from the identity server 30 the information concerning the identity of the requester 40.
  • the identity server 30 embodies an identity management authority and contains information on the identity
  • the interaction between the identity server 30 and the requester 40 can be via a terminal 40 via the Internet or directly, either physically or by another means of communication such as conventional mail with the applicant.
  • Each server 10, 20 and 30 is provided with a computer program for interacting with the other servers in order to carry out the process for obtaining a certificate which will be described later.
  • the program can be stored on a computer readable recording medium prior to implementation on said servers.
  • a certificate application according to the invention is made in two phases as shown in FIG. 3.
  • the The requester registers his identity with the identity server 30.
  • the requester 40 provides the identity server with information concerning his identity, namely surname, first name, and others.
  • the requestor 40 will provide the identity management authority with all the supporting documents necessary to prove the veracity of the information given in order to register them in the identity server 30.
  • the identity is registered in the server 30 and the latter provides the requester 40 with an anonymous identifier associated with the identity information in the course of time.
  • a second step 302. The identifier provides access to the identity information in the identity server. If the complete registration of the identity information could not be done during step 301, the applicant can in a third step 303, provide additional credentials to the identity management authority that will record in the identity server the additional information after having checked them.
  • the identity management authority comprises, in addition to the identity server 30, interface means with the requestor 40.
  • These interface means are, for example a physical operator located in an agency or near the server, or a remote agency connected to said server over the Internet via a secure link.
  • the requestor 40 may provide the information and credentials of his identity in a step 301 or in two steps 301 and 303. When the identity and credentials are provided in two or more steps, the requestor can contact one or more agencies connected to said identity server 30.
  • the requestor 40 will be able to request certificates from the public key management infrastructure via a terminal 41, the first phase is then completed.
  • a second phase corresponding to the certificate request can then begin.
  • the requestor sends to the server registration 20 a certificate request request.
  • the registration server will, among other things, ask to justify its identity to the applicant.
  • the applicant merely sends his identifier to said registration server 20.
  • the registration server 20 Upon receipt of the identifier, the registration server 20 will request, during a step 306, the request. identity server 30 to send him the certified information corresponding to said identifier.
  • the identity server 30 provides the registration server 20 with the information present in its database that is associated with said identifier and relating to the identity. the applicant 40.
  • the registration server 20 Upon receipt of the identity information, and in a step 307, the registration server 20 sends a complete request for a certificate request to the certificate server 10.
  • the certificate server 10 will then calculate a public key and a certificate. private key and establish a corresponding certificate for the applicant 40.
  • the certificate and the private key are then transmitted during a step 309 to the registration server 20.
  • the registration server 20 provides the applicant the certificate and the private key during a step 310.
  • the information exchanged between the terminal 41 and the registration server 20 and between the three servers 10, 20 and 30 are via the Internet.
  • a secure protocol for example the protocol known as HTTPS or HTTP (from the English HyperText Transfer Protocol) with SSL (English Secure Socket Layer).
  • HTTPS HyperText Transfer Protocol
  • SSL English Secure Socket Layer
  • the advantage of such a public key management infrastructure as well as the process of certificate assignment comes from the fact that the identity, once stored in the identity server 30, can be used by a plurality of servers 20 and that this registration of identity is made only once.
  • the identifier provided to the requestor 40 by the identity server 30 may be of different types. According to a first embodiment, the identifier can be a simple password allowing access to the identity information 30. The password is then securely provided to the registration server 20 which will then provide it to the identity server 30.
  • the identity server 30 will provide the identity information corresponding to the identifier.
  • the identifier can itself be a certificate.
  • information relating to the identity of the applicant is filled in the fields of a form provided to the requestor 40 by the registration server.
  • the fields are then signed using the private key associated with the. certificate of the identifier.
  • the form thus signed is then sent by the registration server 20 to the identity server 30.
  • the identity server 30 verifies the signature of the form using its public key and if the latter is verified, it provides then the registration server 20 the identity information of said form by certifying, and possibly adding additional identity information not present on the form.
  • the certificate can also be a non-personal or anonymous certificate contained in a smart card accompanied by its PIN code.
  • the identity information relating to a person can be relatively numerous. We have previously mentioned the name and surname. To these basic identity information can be added other complementary identity information such as date and place of birth, nationality, sex, but also biometric information or information, for example relating to the bank account. It is not necessary that all this information be provided for a given certificate request. Similarly, for reasons of confidentiality, it may be preferable not to store in a single server all this information relating to the identity of a person. Also, the storage of all the identity information relating to a person may require relatively large means that are difficult to manage by a single authority. For this purpose, an alternative embodiment of the infrastructure according to the invention is shown in FIG. 4. In this FIG.
  • the identity server 30 is replaced by two identity servers 31 and 32 that are physically separate and connected. Internet.
  • Identity servers 31 and 32 will have common and complementary identity information.
  • the identity server 31 will include for example the name and first name of the person accompanied by biometric information such as fingerprints or voice signature.
  • the identity server 32 will record him more conventional information such as civil identity information, surname, first name, date of birth, place of birth, nationality, sex, social security number, bank account number, etc.
  • the identity server 31 it is imperative that the person moves for the measurement of the biometric information and that it justifies its identity with the aid of a legal identity document.
  • all this information can be provided by mail, using conventional credentials.
  • a certificate request is made in two phases as shown in Figure 5.
  • the applicant will inform the servers 31 and 32 independently of one another.
  • the requestor 40 will provide the server 31 with first information concerning its identity, for example, biometric information.
  • the applicant 40 will therefore move to an agency that will first verify his identity by presenting an identity card and record for example these fingerprints or record a voice identification.
  • the server 31 will provide a first identifier in the course of step 402. If by chance the requester 40 wishes to modify or record new biometric information, he may still do so during a step 403 by simultaneously providing its identifier with the data of the additional information by also moving to the identity management authority associated with the server 31.
  • the applicant 40 will also take the necessary steps to register his identity with the server 32.
  • a step 404 he will provide information accompanied by supporting documents of his identity, for example his card. identity as well as all the papers to prove that his home is real, etc.
  • a second identifier is provided to the applicant 40 in the step 405.
  • the applicant wishes to record other information about his identity, for example his bank account or possibly his number social security, it can always in a step 406 provide them with the necessary supporting documents accompanied by its identifier.
  • the requestor 40 can then ask the registration server 20 to assign a certificate via a terminal 41 connected to the Internet.
  • the request is sent during a step 416.
  • the registration server and the requestor will dialogue in order to fill the forms required by the registration server for a certificate request and to provide at the registration server 20 the first and second identifiers respectively corresponding to the servers 31 and 32.
  • the registration server Once the registration server has recovered the identifiers, it will simultaneously send them to the identity servers 31 and 32 during steps 408 and 409.
  • the steps 408 and 409 are almost simultaneous and the registration server does not need to wait for the response of the identity servers before sending the next identifier.
  • the identity server 31 will verify this first identifier and send the certified identity information in a step 410.
  • the identity server 32 will verify this identifier and provide back the complementary identity information in a step 411.
  • the registration server will compile the different identity information received in a single form to the certificate server 10. The information from the server 31 and those from the server 32 are put in a single form.
  • the registration server sends the duly completed request containing the identity information of the requestor 40 to the certificate server 10. The latter in return calculates a public key and a secret key and establishes a certificate that it sends to the registration server during a step 413.
  • the certificate is then issued by the registration server at applicant 40 during a step 414.
  • the registration server may simply ask the identity server 31 or 32 for a limited number of information relating to the identity with respect to the information contained in said servers.
  • the server 31 includes biometric information, for example fingerprints and voice signature, while the request for identity information may concern only the voice signature, it is therefore not necessary to transfer information relating to fingerprints.
  • the requester 40 provides the identifier to the registration server 20 which queries the identity server 30 to obtain the identity information of the requester.
  • the requestor 40 it is possible for the requestor 40 to query the identity server 30 directly for the identity server 30 to provide the identity information to the registration server 20.
  • the identity is provided to the requestor. by the identity server 30 in the form of a certificate. The applicant can then produce the certificate to the registration server 20 which merely checks the validity of the certificate with the identity server.
  • the certificate and the associated private key provided by the certificate server 10 to the requestor 40 pass through the registration server 20. It is quite possible to issue the certificate and the private key to the applicant 40 without passing by the registration server 20.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • General Health & Medical Sciences (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Un pré-enregistrement de l'identité d'une personne demanderesse est réalisé par une entité tierce afin que, l'autorité d'enregistrement puisse obtenir des informations certifiées sur l'identité du demandeur. Ainsi, lorsqu'un demandeur (40) requiert (304) un certificat auprès du serveur d'enregistrement (20), le serveur d'enregistrement (20) vérifie (306) des informations auprès d'un serveur d'identité (30) préalablement renseigné sur l'identité du demandeur. Un demandeur (40) n'a besoin que de s'enregistrer qu'une seule fois auprès de l'autorité de gestion d'identité pour produire son identité auprès d'une pluralité de serveurs d'enregistrement. Egalement, l'autorité d'enregistrement n'a plus besoin de vérifier systématiquement des informations d'identité vérifiées une fois pour toute par l'autorité de gestion d'identité.

Description

PROCEDE D'ATTRIBUTION DE CERTIFICAT D'AUTHENTIFICATION ET INFRASTRUCTURE D'ATTRIBUTION DE CERTIFICAT
L'invention se rapporte aux infrastructures de gestion de clés pour des systèmes informatiques sur réseau ouvert. Plus particulièrement, l'invention se rapporte à un procédé d'attribution de certificat ainsi qu'à un système qui permet d'attribuer un certificat selon le procédé. Dans la présente invention, ce qui est appelé certificat doit être compris comme le certificat permettant de valider une clé cryptographique utilisée sur un réseau informatique ouvert. A titre d'exemple, un standard communément utilisé sur Internet pour les infrastructures de gestion de clé publique, de certificat et de liste de révocation de certificat est connue sous le nom de X.509 et plus particulièrement X.509v3 défini dans la RFC3280 (Request For Comment n° 3280) publiée par l'IETF (Internet Engineering Task Force). Le certificat est un objet comportant, entre autres, une clé publique à certifier, l'identité de son possesseur, une période de validité, une liste des droits d'utilisation de la clé et une signature cryptographique de ces données réalisées à l'aide de la clé publique d'une autorité de certification émettrice du certificat.
On appelle communément infrastructure à clé publique, ci-après PKI (de l'anglais Public Key Infrastructure), une plate forme de gestion des certificats. La PKI a pour rôle non seulement de créer les certificats mais aussi de gérer leur validité, c'est à dire leur révocation et leur renouvellement. La figure 1 montre un exemple de PKI selon l'état de la technique. La PKI comprend principalement une autorité de certification (AC) matérialisée par un serveur de certificat 1 , et une autorité d'enregistrement (RA) matérialisée par un serveur d'enregistrement 2. Le serveur de certificat 1 et le serveur d'enregistrement 2 sont par exemple reliés entre eux par Internet, et communiquent de manière sécurisée.
L'autorité de certification est un organisme reconnu comme étant compétent et de confiance pour délivrer et gérer des certificats ainsi que pour en assurer la validité. Lors de la délivrance d'un certificat, l'autorité de certification calcule une clé publique et une clé privée pour l'attribuer à un demandeur. La clé privée est ensuite fournie au demandeur avec le certificat afin que celui-ci puisse l'utiliser comme clé de signature de message ou clé d'accès à des services WEB sécurisés ou pour d'autres applications nécessitant un accès sécurisé. Lors d'une utilisation de la clé privée, l'autorité de certification sera sollicitée pour vérifier la validité de cette clé et des différentes données concernant le certificat, notamment sa validité et son activation ou sa révocation.
L'autorité d'enregistrement sert à établir une requête de certificat auprès de l'autorité de certification pour un demandeur de certificat. L'autorité d'enregistrement doit établir une requête de certificat complète dans laquelle différentes informations vont être envoyées en fonction du certificat demandé.
Pour les certificats nécessitant un niveau de sécurité élevé, l'autorité d'enregistrement est chargée de vérifier les informations fournies par le demandeur concernant son identité et de vérifier si celui-ci est autorisé à requérir un tel certificat comportant la liste d'attribut demandé dans le certificat.
Actuellement, lorsqu'un demandeur 3 requiert un certificat auprès du serveur d'enregistrement 2 par l'intermédiaire d'un terminal 4 également connecté à Internet, l'autorité d'enregistrement peut lui demander soit de se déplacer pour vérifier de visu certaines informations, soit d'envoyer par courrier classique des pièces justificatives de son identité. Cette méthode relativement fiable présente cependant quelques inconvénients :
- l'émission d'une requête de demande de certificat par l'autorité d'enregistrement auprès de l'autorité de contrôle est soumise à la vérification de l'identité de la personne, cela peut nécessiter un délai dans la délivrance lorsque la personne demanderesse doit se déplacer ou envoyer des justificatifs pour prouver son identité ;
- un demandeur souhaitant obtenir plusieurs certificats correspondant à différents PKI, doit effectuer son enregistrement auprès de différentes autorités d'enregistrement et renouveler systématiquement les opérations visant à prouver son identité bien que celle-ci n'ait pas changée ;
- les vérifications sur l'identité de la personne demanderesse de certificat doivent nécessairement se faire par l'intermédiaire d'un opérateur et ne permettent pas à une autorité d'enregistrement de se contenter d'un simple serveur centralisant les données.
L'invention vise à supprimer les inconvénients cités précédemment. Selon l'invention, un pré-enregistrement de l'identité de la personne demanderesse est réalisé par une entité tierce afin que, l'autorité d'enregistrement puisse obtenir des informations certifiées sur l'identité du demandeur. Ainsi, lorsqu'un demandeur requiert un certificat auprès du serveur d'enregistrement, le serveur d'enregistrement vérifie des informations auprès d'un serveur d'identité préalablement renseigné sur l'identité du demandeur. Grâce à l'utilisation d'un identifiant permettant d'obtenir des informations d'identité certifiées auprès d'un serveur d'identité, le serveur d'enregistrement peut effectuer la requête plus rapidement en allant vérifier la validité et éventuellement compléter, auprès du serveur d'identité, les informations requises sur l'identité et de manière certifiée, pour l'obtention d'un nouveau certificat. Un demandeur n'a besoin que de s'enregistrer qu'une seule fois auprès d'une autorité de gestion d'identité pour produire son identité auprès d'une pluralité de serveurs d'enregistrement. Egalement, l'autorité d'enregistrement n'a plus besoin de vérifier systématiquement des informations d'identité vérifiées une fois pour toute par l'autorité de gestion d'identité.
Ainsi, l'invention est un procédé d'attribution de certificat électronique dans une infrastructure d'attribution de certificat distribuée dans un réseau, l'infrastructure incluant au moins un serveur de certificat, un serveur d'identité et un serveur d'enregistrement reliés au réseau. Préalablement à une requête de demande de certificat, des informations relatives à l'identité d'un demandeur de certificat sont stockées dans le serveur d'identité, les informations d'identité étant accessibles par l'intermédiaire d'un identifiant. Un demandeur requiert un certificat auprès du serveur d'enregistrement. L'identifiant est envoyé au serveur d'identité. Après vérification de l'identifiant, le serveur d'identité envoie l'identité préalablement enregistrée du demandeur, ladite identité étant fournie au serveur d'enregistrement. Après réception de l'identité, le serveur d'enregistrement envoie une requête de certificat incluant l'identité du demandeur au serveur de certificat. Le serveur de certificat envoie le certificat à destination du demandeur.
Préférentiellement, le serveur d'enregistrement demande au demandeur son identifiant, afin de l'envoyer au serveur d'identité. Après vérification de l'identifiant, le serveur d'identité envoie au serveur d'enregistrement l'identité préalablement enregistrée du demandeur au serveur d'enregistrement (20). Le serveur de certificat envoie le certificat au serveur d'enregistrement. Le serveur d'enregistrement fournit le certificat au demandeur.
Selon différents modes de réalisation, l'identifiant peut être un identifiant anonyme. L'identifiant peut être lui-même un certificat. L'identifiant peut être accompagné d'un moyen de vérification. Le moyen de vérification peut être fourni par le demandeur au serveur d'enregistrement qui le fournit au serveur d'identité, et le serveur d'identité renvoie l'identité au serveur d'enregistrement uniquement si le moyen de vérification valide l'identifiant. Le moyen de vérification peut être un certificat vérifié par le serveur d'enregistrement.
Selon une variante, plusieurs serveurs d'identité sont reliés au réseau, chaque serveur comportant des informations d'identité complémentaires enregistrées préalablement à une requête de demande de certificat, les informations d'identité étant accessibles par l'intermédiaire d'un identifiant propre à chaque serveur d'identité. Le serveur d'enregistrement récupère les informations d'identité des différents serveurs d'identité afin de reconstituer une identité complète avant de l'envoyer au serveur de certificat.
L'invention est aussi un produit programme d'ordinateur comprenant des instructions pour mettre en oeuvre le procédé lors d'une exécution par des moyens de traitement mettant en œuvre le procédé.
Egalement, l'invention porte sur un support d'enregistrement lisible par ordinateur, qui comporte un programme d'ordinateur mettant en œuvre le procédé lorsque ledit programme est exécuté par des moyens de traitement mettant en œuvre le procédé.
Selon un autre aspect, l'invention est une infrastructure d'attribution de certificat sur un réseau informatique. L'infrastructure comporte au moins un serveur de certificat d'authentification relié au réseau et apte à fournir un certificat électronique pour un demandeur, pour une durée donnée et pour un objet défini, le certificat étant délivré après la réception d'une identité d'un demandeur ; un serveur d'identité relié au réseau, le serveur d'identité contenant des informations relatives à l'identité d'un demandeur de certificat, le serveur d'identité étant apte à fournir, après réception d'un identifiant, l'identité préalablement enregistrée du demandeur ; un serveur d'enregistrement relié au réseau et apte à requérir les informations d'identité relatives au demandeur auprès du serveur d'identité, suite à une requête de certificat d'un demandeur, puis à envoyer une requête de certificat au serveur de certificat incluant les informations d'identité du demandeur.
Préférentiellement, le serveur d'identité est apte à vérifier la validité de l'identifiant afin de renvoyer l'identité au serveur d'enregistrement uniquement si l'identifiant est valide. Selon une variante, plusieurs serveurs d'identités sont reliés au réseau, chaque serveur comportant des informations d'identité complémentaires enregistrées préalablement à une requête de demande de certificat, les informations d'identité étant accessible par l'intermédiaire d'un identifiant propre à chaque serveur d'identité. Le serveur d'enregistrement est apte à récupérer les informations d'identité des différents serveurs d'identité afin de reconstituer une identité complète avant de l'envoyer au serveur de certificat.
L'invention sera mieux comprise et d'autres particularités et avantages apparaîtront à la lecture de la description qui va suivre, la description faisant référence aux figures annexées parmi lesquelles : la figure 1 représente un exemple d'infrastructure de gestion de clé publique selon l'état de la technique, la figure 2 représente un premier mode de réalisation d'une infrastructure de gestion de clé publique selon l'invention, la figure 3 représente schématiquement les échanges à l'intérieur de l'infrastructure de la figure 2 pour requérir un certificat,
la figure 4 représente un deuxième mode de réalisation d'une infrastructure de gestion de clé publique selon l'invention, la figure 5 représente de manière schématique les échanges nécessaires pour l'obtention d'un certificat à l'aide de l'infrastructure de la figure 4. La figure 2 représente un premier mode de réalisation d'une infrastructure de gestion de clé publique selon l'invention. Cette infrastructure comporte un serveur de certificat 10, un serveur d'enregistrement 20 et un serveur d'identité 30. Lesdits serveurs 10, 20 et 30 sont physiquement distincts et sont reliés entre eux par Internet et communiquent à l'aide d'une liaison sécurisée. Le serveur de certificat 10 matérialise l'autorité de certification. Le serveur de certificat 10, à réception d'une requête de demande de certificat émise en bonne et due forme par le serveur d'enregistrement 20, est apte à calculer une clé publique et une clé privée puis à fournir un certificat contenant la clé publique ainsi que les autres attributs du certificat. Le serveur d'enregistrement 20 matérialise l'autorité d'enregistrement. Le serveur d'enregistrement 20 est apte à recevoir des requêtes de demandes d'enregistrement provenant d'un utilisateur 40, éventuellement par l'intermédiaire d'un terminal 41 , lui-même relié à Internet. Le serveur d'enregistrement 20 est apte à aller chercher auprès du serveur d'identité 30 les informations concernant l'identité du demandeur 40. Le serveur d'identité 30 matérialise une autorité de gestion d'identité et contient des informations sur l'identité d'un demandeur de certificat 40. L'interaction entre ie serveur d'identité 30 et le demandeur 40 peut se faire par l'intermédiaire d'un terminal 40 via Internet ou de manière directe, soit physiquement, soit par un autre moyen de communication tel que le courrier classique avec le demandeur.
Chaque serveur 10, 20 et 30 est muni d'un programme d'ordinateur pour interagir avec les autres serveurs afin de réaliser le procédé d'obtention de certificat qui va être décrit par la suite. Le programme peut être stocké sur un support d'enregistrement lisible par ordinateur préalablement à la mise en œuvre sur lesdits serveurs.
Une demande de certificat selon l'invention est réalisée en deux phases comme montrées sur la figure 3. Pendant une première phase, le demandeur enregistre son identité auprès du serveur d'identité 30. Au cours d'une première étape 301 , le demandeur 40 fournit au serveur d'identité des informations concernant son identité, à savoir nom, prénom, et autres. Au cours de cette première étape 301 , le demandeur 40 va fournir auprès de l'autorité de gestion d'identité tous les justificatifs nécessaires pour prouver la véracité des informations données afin de les enregistrer dans le serveur d'identité 30. A partir du moment ou un minimum de justificatifs d'identité a été fourni à l'autorité de gestion d'identité, l'identité est enregistrée dans le serveur 30 et celui-ci fournit au demandeur 40 un identifiant anonyme associé aux informations d'identité au cours d'une deuxième étape 302. L'identifiant permet d'accéder aux informations d'identité dans le serveur d'identité. Si l'enregistrement complet des informations d'identité n'a pu se faire au cours de l'étape 301 , le demandeur peut au cours d'une troisième étape 303, fournir des justificatifs complémentaires à l'autorité de gestion d'identité qui enregistrera dans le serveur d'identité les informations complémentaires après les avoir vérifiées.
Sur les figures 2 et 3, il est représenté un unique serveur d'identité 30, il est à noter que l'autorité de gestion d'identité comporte en plus du serveur d'identité 30 des moyens d'interface avec le demandeur 40. Ces moyens d'interface sont, par exemple un opérateur physique situé dans une agence, soit à proximité du serveur, soit une agence distante reliée audit serveur par Internet via une liaison sécurisée. Il est à noter que le demandeur 40 peut fournir les informations et justificatifs de son identité en une étape 301 ou en deux étapes 301 et 303. Lorsque l'identité et les justificatifs d'identité sont fournis en deux ou plusieurs étapes, le demandeur peut s'adresser à une ou plusieurs agences reliées audit serveur d'identité 30.
Une fois que le serveur d'identité 30 est correctement renseigné sur l'identité, le demandeur 40 va pouvoir demander des certificats auprès de l'infrastructure de gestion de clé publique par l'intermédiaire d'un terminal 41 , la première phase est alors terminée.
Une deuxième phase correspondant à la requête de certificat peut alors commencer. Au cours d'une étape 304, le demandeur envoie au serveur d'enregistrement 20 une requête de demande de certificat. Pendant une étape 305, le serveur d'enregistrement va, entre autre, demander de justifier de son identité au demandeur. En réponse à cette requête d'identité, Ie demandeur se contente d'envoyer son identifiant audit serveur d'enregistrement 20. A réception de l'identifiant, le serveur d'enregistrement 20 va demander, au cours d'une étape 306, au serveur d'identité 30 de lui envoyer les informations certifiées correspondant audit identifiant. Au cours d'une étape 307 et après avoir contrôlé la validité de l'identifiant, le serveur d'identité 30 fournit au serveur d'enregistrement 20 les informations présentes dans sa base de données qui sont associées audit identifiant et relatives à l'identité du demandeur 40.
A réception des informations d'identité, et au cours d'une étape 307, le serveur d'enregistrement 20 envoie une requête complète de demande de certificat au serveur de certificat 10. Le serveur de certificat 10 va alors calculer une clé publique et une clé privée et établir un certificat correspondant pour le demandeur 40. Le certificat et la clé privée sont ensuite transmis au cours d'une étape 309 au serveur d'enregistrement 20. Le serveur d'enregistrement 20 fournit au demandeur le certificat et la clé privée au cours d'une étape 310.
Il est à noter que les informations échangées, d'une part, entre le terminal 41 et le serveur d'enregistrement 20 et, d'autre part, entre les trois serveurs 10, 20 et 30 se font par l'intermédiaire d'Internet à l'aide d'un protocole sécurisé, par exemple le protocole connu sous l'appellation HTTPS ou HTTP (de l'anglais HyperText Transfer Protocol) avec SSL (de l'anglais Secure Socket Layer). L'intérêt d'une telle infrastructure de gestion de clé publique ainsi que du procédé d'attribution de certificat, provient du fait que l'identité, une fois stockée dans le serveur d'identité 30, peut être utilisée par une pluralité de serveur d'enregistrement 20 et que cet enregistrement d'identité se fait une seule et unique fois. L'identifiant fournit au demandeur 40 par le serveur d'identité 30 peut être de différents types. Selon un premier mode de réalisation, l'identifiant peut être un simple mot de passe permettant d'accéder aux informations d'identité contenues dans le serveur 30. Le mot de passe est alors fourni de manière sécurisée au serveur d'enregistrement 20 qui va ensuite le fournir au serveur d'identité 30. En réponse audit mot de passe, le serveur d'identité 30 va fournir les informations d'identité correspondant à l'identifiant. Selon une variante plus sécurisée, l'identifiant peut lui-même être un certificat. Ainsi, des informations relatives à l'identité du demandeur sont renseignées dans les champs d'un formulaire fourni au demandeur 40 par le serveur d'enregistrement. Les champs sont ensuite signés à l'aide de la clé privée associée au. certificat de l'identifiant. Le formulaire ainsi signé est ensuite envoyé par le serveur d'enregistrement 20 au serveur d'identité 30. Le serveur d'identité 30 vérifie la signature du formulaire à l'aide de sa clé publique et si celle-ci est vérifiée, il fournit alors au serveur d'enregistrement 20 les informations d'identité dudit formulaire en les certifiant, et en ajoutant éventuellement des informations d'identité complémentaires non présentes sur le formulaire.
Le certificat peut également être un certificat non personnel ou anonyme contenu dans une carte à puce accompagnée de son code PIN.
Les informations d'identité relatives à une personne peuvent être relativement nombreuses. On a cité précédemment le nom et le prénom. A ces informations d'identité de base peuvent s'ajouter d'autres informations d'identité complémentaires telles que date et lieu de naissance, nationalité, sexe, mais aussi des informations biométriques ou des informations, par exemple relatives au compte bancaire. Il n'est pas nécessaire que toutes ces informations soient fournies pour une demande de certificat donnée. De même, pour une raison de confidentialité, il peut être préféré de ne pas stocker dans un seul et unique serveur toutes ces informations relatives à l'identité d'une personne. Egalement, le stockage de la totalité des informations d'identité relatives à une personne peut nécessiter des moyens relativement importants difficilement gérables par une unique autorité. A cet effet, une variante de réalisation d'infrastructure selon l'invention est représentée sur la figure 4. Sur cette figure 4, le serveur d'identité 30 est remplacé par deux serveurs d'identité 31 et 32 physiquement distincts et reliés à Internet. Les serveurs d'identité 31 et 32 vont comporter des informations d'identité communes et complémentaires. A titre d'exemple, le serveur d'identité 31 va comporter par exemple le nom et le prénom de la personne accompagnés d'informations biométriques telles qu'empreintes digitales ou signature vocale. Et le serveur d'identité 32 va lui enregistrer des informations plus conventionnelles telles que les informations d'identité civile, nom, prénom, date de naissance, lieu de naissance, nationalité, sexe, numéro de sécurité sociale, numéro de compte en banque, etc. Bien évidemment, pour le serveur 31 , il est impératif que la personne se déplace pour la mesure des informations biométriques et que celle-ci justifie de son identité à l'aide d'une pièce d'identité légale. Pour le serveur d'identité 32, toutes ces informations peuvent être fournies de manière postale, à l'aide de justificatifs d'identité conventionnels.
Là encore, une demande de certificat est réalisée en deux phases comme montré sur la figure 5. Au cours de la première phase, le demandeur va renseigner les serveurs 31 et 32 de manière indépendante l'une de l'autre. Ainsi, au cours d'une première étape 401 , le demandeur 40 va fournir au serveur 31 des premières informations concernant son identité, par exemple, des informations biométriques. Le demandeur 40 va donc se déplacer dans une agence qui va tout d'abord vérifier son identité en présentant une carte d'identité et enregistrer par exemple ces empreintes digitales ou encore enregistrer une identification vocale. Une fois ces informations enregistrées dans ce serveur biométrique, le serveur 31 va fournir un premier identifiant au cours de l'étape 402. Si par hasard, le demandeur 40 désire modifier ou enregistrer de nouvelles informations biométriques, il peut toujours le faire au cours d'une étape 403 en fournissant simultanément son identifiant avec les données des informations supplémentaires en se déplaçant également auprès de l'autorité de gestion d'identité associée au serveur 31.
Toujours au cours de la première phase, le demandeur 40 va également faire le nécessaire pour enregistrer son identité auprès du serveur 32. Au cours d'une étape 404, il va fournir des informations accompagnées de papiers justificatifs de son identité, par exemple sa carte d'identité ainsi que tous les papiers permettant de prouver que son domicile est bien réel, etc. Les différentes informations étant vérifiées par une personne lors de l'enregistrement dans le serveur 32, un deuxième identifiant est fourni au demandeur 40 au cours de l'étape 405. Là encore, si le demandeur souhaite enregistrer d'autres informations concernant son identité, par exemple son compte en banque ou éventuellement son numéro de sécurité sociale, il peut toujours au cours d'une étape 406 les fournir avec les justificatifs nécessaires accompagnés de son identifiant.
Une fois les différentes informations relatives à son identité enregistrées auprès des serveurs 31 et 32, le demandeur 40 peut alors demander au serveur d'enregistrement 20 de lui attribuer un certificat par l'intermédiaire d'un terminal 41 connecté à Internet. La requête est envoyée au cours d'une étape 416. Au cours d'une étape 407, le serveur d'enregistrement et le demandeur vont dialoguer afin de remplir les formulaires requis par le serveur d'enregistrement pour une demande de certificat et de fournir au serveur d'enregistrement 20 les premier et deuxième identifiants correspondants respectivement aux serveurs 31 et 32. Une fois que le serveur d'enregistrement a récupéré les identifiants, il va simultanément les envoyer aux serveurs d'identité 31 et 32 au cours d'étapes 408 et 409. Les étapes 408 et 409 sont quasi simultanées et il n'est pas besoin au serveur d'enregistrement d'attendre la réponse des serveurs d'identité avant d'envoyer l'identifiant suivant. En réponse à l'identifiant reçu au cours de l'étape 408, le serveur d'identité 31 va vérifier ce premier identifiant et envoyer les informations d'identité certifiées au cours d'une étape 410. Après avoir reçu le deuxième identifiant au cours de l'étape 409, le serveur d'identité 32 va vérifier cet identifiant et fournir en retour les informations d'identité complémentaires au cours d'une étape 411. Ensuite, le serveur d'enregistrement va compiler les différentes informations d'identité reçues dans un unique formulaire à destination du serveur de certificat 10. Les informations provenant du serveur 31 et celles provenant du serveur 32 sont mises dans un unique formulaire. Au cours d'une étape 412, le serveur d'enregistrement envoie la requête dûment complétée et contenant les informations d'identité du demandeur 40 au serveur de certificat 10. Celui-ci en retour calcule une clé publique et une clé secrète et établit un certificat qu'il envoie au serveur d'enregistrement au cours d'une étape 413. Le certificat est ensuite délivré par le serveur d'enregistrement au demandeur 40 au cours d'une étape 414.
Il est à noter que le serveur d'enregistrement peut se contenter de demander au serveur d'identité 31 ou 32 qu'un nombre limité d'informations relative à l'identité par rapport aux informations contenues dans lesdits serveurs. En effet, le serveur 31 comporte des informations biométriques, par exemple empreintes digitales et signature vocale, alors que la demande d'informations d'identité peut ne concerner que la signature vocale, il n'est donc pas nécessaire de transférer des informations relatives aux empreintes digitales. Dans les exemples décrits, le demandeur 40 fournit l'identifiant au serveur d'enregistrement 20 qui interroge le serveur d'identité 30 pour obtenir les informations d'identité du demandeur. Selon une variante, il est possible que le demandeur 40 interroge directement le serveur d'identité 30 pour que celui-ci fournisse les informations d'identité au serveur d'enregistrement 20. Egalement, il est possible que l'identité soit fournie au demandeur par le serveur d'identité 30 sous forme d'un certificat. Le demandeur peut alors produire le certificat au serveur d'enregistrement 20 qui se contente de vérifier la validité du certificat auprès du serveur d'identité.
Dans les exemples décrits, le certificat et la clé privée associée fournis par le serveur de certificat 10 au demandeur 40 transitent par le serveur d'enregistrement 20. Il est tout à fait possible de délivrer le certificat et la clé privée au demandeur 40 sans passer par le serveur d'enregistrement 20.

Claims

R E V E N D I C A T I O N S
1. Procédé d'attribution de certificat électronique dans une infrastructure d'attribution de certificat distribuée dans un réseau, l'infrastructure incluant au moins un serveur de certificat (10), un serveur d'identité (30, 31, 32) et un serveur d'enregistrement (20) reliés au réseau, dans lequel, préalablement à une requête (304, 306) de demande de certificat, des informations relatives à l'identité d'un demandeur (40) de certificat sont stockées dans le serveur d'identité (30), les informations d'identité étant accessibles par l'intermédiaire d'un identifiant, et dans lequel :
- un demandeur (40) requiert (304, 306) un certificat auprès du serveur d'enregistrement (20),
- l'identifiant est envoyé (306, 408, 409) au serveur d'identité (30, 31, 32), - après vérification de l'identifiant, le serveur d'identité (30, 31, 32) envoie (307, 410, 411) l'identité préalablement enregistrée du demandeur (40), ladite identité étant fournie au serveur d'enregistrement (20),
- après réception de l'identité, le serveur d'enregistrement (20) envoie (308, 413) une requête de certificat incluant l'identité du demandeur au serveur de certificat (10), et
- le serveur de certificat (10) envoie le certificat à destination du demandeur (40).
2. Procédé selon la revendication 1 , dans lequel :
- le serveur d'enregistrement (20) demande (305, 407) au demandeur (40) son identifiant, afin de l'envoyer (306, 408, 409) au serveur d'identité (30, 31 , 32), et
- après vérification de l'identifiant, le serveur d'identité (30, 31, 32) envoie (307, 410, 411) au serveur d'enregistrement (20) l'identité préalablement enregistrée du demandeur (40) au serveur d'enregistrement (20).
3. Procédé selon l'une des revendications 1 ou 2, dans lequel :
- le serveur de certificat (10) envoie (309, 412) le certificat au serveur d'enregistrement (20), et
- le serveur d'enregistrement (20) fournit (310, 414) le certificat au demandeur (40).
4. Procédé selon l'une des revendications 1 à 3, dans lequel l'identifiant est un identifiant anonyme.
5. Procédé selon l'une des revendications 1 à 4, dans lequel l'identifiant est accompagné d'un moyen de vérification.
6. Procédé selon la revendication 5, dans lequel :
- le moyen de vérification est fourni par le demandeur (40) au serveur d'enregistrement (20) qui le fournit au serveur d'identité (30), et
- le serveur d'identité (30) renvoie l'identité au serveur d'enregistrement uniquement si le moyen de vérification valide l'identifiant.
7. Procédé selon la revendication 5, dans lequel le moyen de vérification est un certificat vérifié par le serveur d'enregistrement.
8. Procédé selon l'une des revendications 1 à 7, dans lequel plusieurs serveurs d'identité (31, 32) sont reliés au réseau, chaque serveur comportant des informations d'identité complémentaires enregistrées préalablement à une requête de demande de certificat, les informations d'identité étant accessibles par l'intermédiaire d'un identifiant propre à chaque serveur d'identité, et dans lequel le serveur d'enregistrement (20) récupère (410, 411) les informations d'identité des différents serveurs d'identité afin de reconstituer une identité complète avant de l'envoyer au serveur de certificat (10).
9. Procédé selon l'une des revendications 1 à 8, dans lequel les échanges d'informations entre le demandeur et le serveur d'enregistrement se font par l'intermédiaire du réseau.
10. Procédé selon l'une des revendications 1 à 9, dans lequel l'identifiant est lui-même un certificat.
11. Produit programme d'ordinateur comprenant des instructions pour mettre en œuvre le procédé selon l'une des revendications 1 à 10 lors d'une exécution par des moyens de traitement mettant en œuvre le procédé.
12. Support d'enregistrement lisible par ordinateur caractérisé en ce qu'il comporte un programme d'ordinateur mettant en œuvre le procédé selon l'une des revendications 1 à 10 lorsque ledit programme est exécuté par des moyens de traitement mettant en œuvre le procédé.
13. Infrastructure d'attribution de certificat sur un réseau informatique, caractérisé en ce qu'elle comporte au moins : - un serveur de certificat (10) d'authentification relié au réseau et apte à fournir un certificat électronique pour un demandeur (40), pour une durée donnée et pour un objet défini, le certificat étant délivré après la réception d'une identité d'un demandeur ;
- un serveur d'identité (30, 31 , 32) relié au réseau, le serveur d'identité (30, 31 , 32) contenant des informations relatives à l'identité d'un demandeur (40) de certificat, le serveur d'identité (30, 31 , 32) étant apte à fournir, après réception d'un identifiant, l'identité préalablement enregistrée du demandeur ;
- un serveur d'enregistrement relié au réseau et apte à requérir les informations d'identité relatives au demandeur (40) auprès du serveur d'identité (30), suite à une requête de certificat d'un demandeur (40), puis à envoyer une requête de certificat (10) au serveur de certificat incluant les informations d'identité du demandeur.
14. Infrastructure selon la revendication 13, dans laquelle l'identifiant est un identifiant anonyme.
15. Infrastructure selon l'une des revendications 13 ou 14, dans laquelle le serveur d'identité (30, 31 , 32) est apte à vérifier la validité de l'identifiant afin de renvoyer l'identité au serveur d'enregistrement uniquement si l'identifiant est valide.
16. Infrastructure selon l'une des revendications 13 à 15, dans laquelle plusieurs serveurs d'identités (31 , 32) sont reliés au réseau, chaque serveur comportant des informations d'identité complémentaires enregistrées préalablement à une requête de demande de certificat, les informations
5 d'identité étant accessible par l'intermédiaire d'un identifiant propre à chaque serveur d'identité, et dans laquelle le serveur d'enregistrement (20) est apte à récupérer les informations d'identité des différents serveurs d'identité (31 , 32) afin de reconstituer une identité complète avant de l'envoyer au serveur de o certificat.
17. Infrastructure selon l'une des revendications 13 à 16, comportant en outre un terminal d'accès (41) relié au réseau, le terminal d'accès (41) étant apte à communiquer avec le serveur d'enregistrement (20) afin de servir d'interface au demandeur (40).
5 18. Infrastructure selon l'une des revendications 13 à 17, dans laquelle l'identifiant est un certificat.
PCT/FR2005/002040 2004-08-19 2005-08-05 Procede d'attribution de certificat d'authentification et infrastructure d'attribution de certificat WO2006021665A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
DE602005005201T DE602005005201T2 (de) 2004-08-19 2005-08-05 Verfahren zur zuweisung eines authentifizierungszertifikats und infrastruktur zur zuweisung eines zertifikats
US11/660,543 US20070283426A1 (en) 2004-08-19 2005-08-05 Method for Assigning an Authentication Certificate and Infrastructure for Assigning Said Certificate
EP05796241A EP1779635B1 (fr) 2004-08-19 2005-08-05 Procede d'attribution de certificat d'authentification et infrastructure d'attribution de certificat

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0408992 2004-08-19
FR0408992 2004-08-19

Publications (1)

Publication Number Publication Date
WO2006021665A1 true WO2006021665A1 (fr) 2006-03-02

Family

ID=34948282

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2005/002040 WO2006021665A1 (fr) 2004-08-19 2005-08-05 Procede d'attribution de certificat d'authentification et infrastructure d'attribution de certificat

Country Status (5)

Country Link
US (1) US20070283426A1 (fr)
EP (1) EP1779635B1 (fr)
AT (1) ATE388573T1 (fr)
DE (1) DE602005005201T2 (fr)
WO (1) WO2006021665A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009503967A (ja) * 2005-07-26 2009-01-29 フランス テレコム 単一の物理デバイスを用いた保護されたトランザクションの制御方法、それに対応する物理デバイス、システム及びコンピュータプログラム

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011120583A1 (fr) * 2010-04-01 2011-10-06 Nokia Siemens Networks Oy Autorité de certificat
US10397215B2 (en) 2016-09-27 2019-08-27 Visa International Service Assocation Secure element installation and provisioning

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020108042A1 (en) * 2001-01-10 2002-08-08 Makoto Oka Public key certificate issuing system, Public key certificate issuing method, digital certification apparatus, and program storage medium
US20020194471A1 (en) * 2001-06-14 2002-12-19 International Business Machines Corporation Method and system for automatic LDAP removal of revoked X.509 digital certificates

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7680819B1 (en) * 1999-11-12 2010-03-16 Novell, Inc. Managing digital identity information
US8015600B2 (en) * 2000-12-22 2011-09-06 Oracle International Corporation Employing electronic certificate workflows
US20030154376A1 (en) * 2001-02-05 2003-08-14 Yeoul Hwangbo Optical storage medium for storing, a public key infrastructure (pki)-based private key and certificate, a method and system for issuing the same and a method for using
US20030074555A1 (en) * 2001-10-17 2003-04-17 Fahn Paul Neil URL-based certificate in a PKI
KR100449484B1 (ko) * 2001-10-18 2004-09-21 한국전자통신연구원 공개키 기반 구조 인증시스템에서 생체정보를 이용한인증서 발급 방법
US7275260B2 (en) * 2001-10-29 2007-09-25 Sun Microsystems, Inc. Enhanced privacy protection in identification in a data communications network
US6641037B2 (en) * 2001-12-13 2003-11-04 Peter Williams Method and system for interactively providing product related information on demand and providing personalized transactional benefits at a point of purchase
US7376624B2 (en) * 2002-02-27 2008-05-20 Imagineer Software, Inc. Secure communication and real-time watermarking using mutating identifiers
US7472423B2 (en) * 2002-03-27 2008-12-30 Tvworks, Llc Method and apparatus for anonymously tracking TV and internet usage
US7558955B2 (en) * 2002-11-20 2009-07-07 Aol Llc, A Delaware Limited Liability Company Method and apparatus for secure instant messaging utilizing server-supervised publication

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020108042A1 (en) * 2001-01-10 2002-08-08 Makoto Oka Public key certificate issuing system, Public key certificate issuing method, digital certification apparatus, and program storage medium
US20020194471A1 (en) * 2001-06-14 2002-12-19 International Business Machines Corporation Method and system for automatic LDAP removal of revoked X.509 digital certificates

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ADAMS C. ET AL: "Internet X.509 Public Key Infrastructure Certificate Management Protocols", IETF, RFC 2510, March 1999 (1999-03-01), XP015008293 *
ADAMS C., LLOYD S.: "Understanding PKI, Concepts, Standards, and Deployment Considerations", 2003, ADDISON-WESLEY, BOSTON, XP002316632 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009503967A (ja) * 2005-07-26 2009-01-29 フランス テレコム 単一の物理デバイスを用いた保護されたトランザクションの制御方法、それに対応する物理デバイス、システム及びコンピュータプログラム

Also Published As

Publication number Publication date
US20070283426A1 (en) 2007-12-06
DE602005005201D1 (de) 2008-04-17
ATE388573T1 (de) 2008-03-15
EP1779635A1 (fr) 2007-05-02
EP1779635B1 (fr) 2008-03-05
DE602005005201T2 (de) 2009-03-12

Similar Documents

Publication Publication Date Title
AU2021206913B2 (en) Systems and methods for distributed data sharing with asynchronous third-party attestation
TWI725793B (zh) 用於將分散識別符映射到真實世界實體的系統及方法
CN111316278B (zh) 安全身份和档案管理系统
EP3547203A1 (fr) Méthode et système de gestion d'accès à des données personnelles au moyen d'un contrat intelligent
US7293098B2 (en) System and apparatus for storage and transfer of secure data on web
US8019881B2 (en) Secure cookies
RU2434340C2 (ru) Инфраструктура верификации биометрических учетных данных
KR101105121B1 (ko) 진정문서의 전달, 저장 및 회복에 대한 시스템 및 방법
CA2647248C (fr) Procede et serveur de coffres-forts electroniques avec mutualisation d'informations
US7925878B2 (en) System and method for creating a trusted network capable of facilitating secure open network transactions using batch credentials
EP3343425A1 (fr) Système et procédé pour la création et la gestion d'autorisations décentralisées pour des objets connectés
KR102410006B1 (ko) 사용자 권한 관리가 가능한 did 생성 방법 및 이를 이용한 사용자 권한 관리 시스템
KR101816652B1 (ko) Utxo 기반 프로토콜에서 머클 트리 구조를 사용하여 서비스 제공 서버에 의하여 제공되는 서비스를 이용하기 위한 사용자의 로그인 요청에 대하여 pki 기반의 인증을 통해 로그인을 대행하는 방법 및 이를 이용한 서버
CN109862024A (zh) 一种云管理系统的网络授权协议访问控制方法及系统
EP1779635B1 (fr) Procede d'attribution de certificat d'authentification et infrastructure d'attribution de certificat
Adams et al. PKI: Ten years later
Yeh et al. Applying lightweight directory access protocol service on session certification authority
JP2002132996A (ja) 情報存在証明サーバ、情報存在証明方法、および情報存在証明制御プログラム
JP4783992B2 (ja) 属性証明書管理サーバ、属性証明書管理方法およびそのプログラム
US11954672B1 (en) Systems and methods for cryptocurrency pool management
CN114444129B (zh) 一种对电子印章进行动态控制的方法及系统
FR2898423A1 (fr) Procede securise de configuration d'un dispositif de generation de signature electronique.
Park Secure attribute services on the web
EP4078495A1 (fr) Procédé et dispositif de gestion d'une autorisation d'accès à un service de paiement fourni à un utilisateur
EP1258844A1 (fr) Procédé et système pour l'établissement de la preuve d'une transaction électronique

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 11660543

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2005796241

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2005796241

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 11660543

Country of ref document: US

WWG Wipo information: grant in national office

Ref document number: 2005796241

Country of ref document: EP