System and method for cross directory authentication in public key infrastructure
Abstract
[Task] Provides a mutual directory authentication system and method for public key infrastructure.
Solution.The first directory is configured to contact the second directory when it receives an inquiry about signature authentication from the second company PKI. The first directory is part of the first company PKI and the second directory is part of the second company PKI. The user presents the signature authentication from the second company PKI to the server and receives the authentication. The server sends an inquiry to the first directory, and the user determines whether access to the server is permitted. An inquiry is sent from the first directory to the second directory to determine whether or not the user is a member of the PKI of the second company. The server authorizes access to the server if the user is a member of a second company PKI.

Term
Term ended
Projected expiry passed 11 June 2021, 5.3 years ago.
- Priority
- Filed
- Published
- Projected expiry
- Today
10 claims: 3 independent, 7 dependent
- 1【特許請求の範囲】 【請求項1】 公開鍵インフラストラクチャ(PKI)における相互ディレクトリ認証方法であって、 第2企業のPKIから署名認証に関する問い合わせを受信したとき、第2ディレクトリに問い合わせするように第1ディレクトリを構成するステップであって、前記第1ディレクトリが第1企業のPKIの一部であり、前記第2ディレクトリが前記第2企業のPKIの一部である、ステップと、 ユーザがサーバにアクセスを試みるステップであって、前記サーバが前記第1企業のPKIの一部であり、前記ユーザが前記第2企業PKIからの署名認証を前記サーバに提示し、認証を求めるステップと、 前記サーバから前記第1ディレクトリに問い合わせを送り、前記ユーザが前記サーバに対するアクセスを許可されているか否か判定を行なうステップと、 前記第1ディレクトリから前記第2ディレクトリに問い合わせを送り、前記ユーザが前記第2企業PKIの構成員であるか否か判定を行なうステップと、 前記ユーザが前記第2企業PKIの構成員である場合、前記第1ディレクトリによって、前記サーバに、前記ユーザが前記サーバに対するアクセスを許可されていることを通知するステップと、を含む方法。
- 2【請求項2】 請求項1記載の方法であって、更に、前記第1ディレクトリを、ネットワーク管理者によって構成するステップを含む方法。
- 3【請求項3】 請求項1記載の方法であって、更に、前記サーバに対するアクセスが許可されており、前記第2企業のPKIからの署名認証を有するユーザに関する情報を用いて、前記サーバを構成するステップを含む方法。
- 4【請求項4】 請求項1記載の方法であって、更に、前記サーバに対するアクセスが許可されており、前記第2企業のPKIからの署名認証を有するユーザに関する情報を用いて、前記第1ディレクトリを構成するステップを含む方法。
- 5【請求項5】 請求項4記載の方法であって、更に、前記サーバをネットワーク管理者によって構成するステップを含む方法。
- 6【請求項6】 公開鍵インフラストラクチャ(PKI)における相互ディレクトリ認証システムであって、 少なくとも1つのサーバであって、第1企業のPKIの一部である、少なくとも1つのサーバと、 少なくとも1つのクライアント・プラットフォームであって、少なくとも一人のユーザが前記少なくとも1つのサーバに対するアクセスを要求するために使用可能な、少なくとも1つのクライアント・プラットフォームと、 第2ディレクトリであって、第2企業のPKIに対する署名認証を有する少なくとも一人のユーザに関する情報を収容し、前記第2企業PKIの一部である、第2ディレクトリと、 第1ディレクトリであって、該第1ディレクトリは、少なくとも一人のユーザから前記少なくとも1つのサーバにおいて認証のために受信した第2企業のPKIに対する署名認証に関して、少なくとも1つのサーバから問い合わせを受信したとき、前記第2ディレクトリに問い合わせを送り、前記少なくとも1つのサーバから前記第1ディレクトリに送る問い合わせは、前記少なくとも一人のユーザが前記少なくとも1つのサーバに対するアクセスを許可されているか否か判定するためのものであり、前記第1ディレクトリが前記第1企業のPKIの一部であり、前記第1ディレクトリから前記第2ディレクトリに送られる問い合わせは、前記少なくとも一人のユーザが前記第2企業のPKIの構成員であるか否か判定を行なうために送られ、前記第1ディレクトリは、前記ユーザが前記第2企業PKIの構成員である場合、前記少なくとも一人のユーザは前記少なくとも1つのサーバに対するアクセスが許可されていることを、前記少なくとも1つのサーバに通知する、第1ディレクトリと、を備えるシステム。
- 7【請求項7】 請求項6記載のシステムにおいて、前記第1ディレクトリはデータベースから成るシステム。
- 8【請求項8】 請求項6記載のシステムにおいて、前記第2ディレクトリはデータベースから成るシステム。
- 9【請求項9】 請求項6記載のシステムにおいて、前記少なくとも1つのサーバ、前記少なくとも1つのクライアント・プラットフォーム、および前記第1ディレクトリは、ネットワークを通じて動作可能に接続されているシステム。
- 10【請求項10】 命令が格納されている記憶媒体から成る物品であって、前記命令を実行すると、処理装置に、 第2企業のPKIに対する署名認証に関する問い合わせを受信すると、前記処理装置にディレクトリに問い合わせを送らせる構成情報を受信するステップであって、前記処理装置が第1企業PKIの一部であり、前記ディレクトリが前記第2PKIの一部である、ステップと、 ユーザがサーバに対するアクセスが許可されているか否かを尋ねる問い合わせを、前記サーバから受信するステップであって、前記サーバが前記第1企業のPKIの一部である、ステップと、 前記ディレクトリに問い合わせを送り、前記ユーザが前記第2企業のPKIの構成員であるか否か判定するステップと、 前記ユーザが前記第2企業のPKIの構成員である場合、前記ユーザが前記サーバに対するアクセスが許可されていることを、前記サーバに通知するステップと、を実行させる物品。
Independent claims10
80 paragraphs in 1 section, as filed
Description: TECHNICAL FIELD [Detailed description of the invention]
【0001】
[Technical field to which the invention belongs]
The present invention relates to a public key infrastructure (PKI) and, more specifically, to mutual directory authentication in a PKI.
【0002】
[Conventional technology]
This application claims priority to US Patent Provisional Application No. 60 / 210,461 filed June 9, 2000, and US Patent Provisional Application No. 60 / 229,336 filed September 1, 2000. The contents are incorporated herein by reference.
【0003】
Public Key Infrastructure (PKI) distributes and manages thousands of unique public / private cryptographic keys to an organization, company or company, allowing users to trust the identity of the owner of each public / private key pair. It is a collection of servers and software that enables high-quality judgment. If each member of the enterprise has a unique key, the paper-based business process can be transitioned to an online electronic equivalent. The public / private key pair has the property that for any given public key, there is only one private key and vice versa. Public key cryptography (ie, the ability to publicly distribute cryptographic keys) allows documents to be digitally signed. If one member of the key pair can be used to decrypt a particular message, it can be assumed that the message must have been encrypted using the other member. Assuming that only one person knows the key that was initially used to encrypt the document, the recipient who can decrypt the document must be the sender of the document. I can be sure that there is no such thing.
【0004】
However, in order for a digital signature to be significant, the recipient of the object on which the digital signature is signed must first determine its owner and the integrity of the key used to sign the object. You must be able to judge with high reliability. Public infrastructure accomplishes this with electronic documents called digital authentication. The authentication can include information that identifies the owner of the key pair, the public part of the key pair, and the time period during which the authentication is valid. Authentication can also identify technical information about the key itself, such as the algorithm used to generate the key, the length of the key, and so on. It is the organization, company, or company that generates the certificate, which is responsible for verifying the identity of the individual (or possibly the organization) for which the certificate is issued. The certification organization is known as a certificate authority. The certificate authority signs each certificate using a public key known only to the certificate authority itself. This allows PKI users to verify both the integrity of the authentication and the identity of the station that issued it. By issuing the certificate, the certificate authority states that it has verified that the public key (further, the corresponding private key) found within the certificate belongs to the individual listed within the certificate. .. Therefore, the integrity of the registration process in operation is very important. This process must provide a mechanism to reliably identify an individual and to verify that the public key listed in the certificate belongs to that individual.
【0005】
FIG. 1 is a block diagram showing an example of a PKI system architecture. The current PKI, which provides strong authentication of user identity, is responsible for achieving this with the local registration authority (LRAO). officer) 12 is used. LRAO12 runs on a workstation or server platform 14 running the local registry software application 16. The server platform 14 may be any known computer capable of functioning as a server, and examples thereof include a computer and a workstation. The local registrar application 16 interfaces with other server platforms that include applications such as certificate authority application 18, registrar application 20, and / or key recovery authority application 22. Each application may be on the same server flat form or on a separate individual server platform 14. User 10 accesses the system through a web browser 22 on the client platform 24 if he / she is using or wants to access the PKI system architecture. A hardware token 26, such as a smart card, may be operationally connectable to the client platform 24. Typically, in the current system, the user 10 presents the photo ID to the local registrant officer 12 to authenticate the user's identity. The local registrant officer 12 then uses workstation 14 and the local registrant application 16 to instruct the registrant application 20 to register a new user 10 in the system. The local registration authority application 16 can be a commercially available software product typically bundled with certificate authority application 18, registration authority application 20, and key recovery authority 22 software.
【0006】
It is either the Local Registry Application 16 or the Registry Application 20 that generates the public / private key pair (depending on the product selected and how they are configured). The public key is sent to the certificate authority application 18 to be signed, thereby generating an authentication for the new user 10. A backup copy of the private key can also be sent to the key recovery station application 22, but the private key is typically held on token 26 or by user 10 on client platform 24. Once the public key is sent to Certificate Authority 18 and signed, user authentication is generated and supplied to the local Registration Authority server. The Local Registry Officer 12 copies the authentication (including the private key) onto a floppy disk, hardware token, or other storage medium, and then gives the user the authentication and private key.
【0007】
Individual companies use different PKIs. For example, if Company A wants to grant access to a server that is part of Company A's PKI for a user from a different company, eg Company B, Server A will identify the user from Company B. Unable to authenticate. This is because the user from company B is not a part of company A's PKI, but presents the signature authentication from company B's PKI and asks for authentication.
【0008】
Currently, a process called cross-certification is used to allow a large number of companies to coordinate certifications between specific company PKIs. In the current system, the certificate authority from the 1st PKI signs the public key of the certificate authority from the 2nd PKI. Similarly, the certificate authority from the 2nd PKI signs the public key of the certificate authority from the 1st PKI. Then, when the user or server in the PKI of the first company receives the signature authentication from the user from the PKI of the second company, the signature authentication of the user from the PKI of the second company is signed by the signing authority from the first company. Will be done. Usually, the user or server from the first company does not know whether or not the signature authentication from the second company can be trusted. This is because the signature authentication is from a different PKI. However, since the signature from the certificate authority from the second company is itself signed by the certificate authority from the first company, the user and server from the first company are authenticated in the signature authentication from the second company. The signature of the station turns out to be reliable.
【0009】
[Problems to be Solved by the Invention]
However, such current systems have the problem that they cannot be scaled up well. For example, if there are N PKIs, then N<sup>2</sup>Individual mutual authentication signatures must be made. Therefore, within the network of the first company, it is necessary to enable the first company to authenticate the identity of the user from the second company.
【0010】
[Means for solving problems]
The present invention relates to a mutual directory authentication method in a public key infrastructure (PKI), and is a step of configuring a first directory so as to inquire the second directory when receiving an inquiry about signature authentication from the PKI of a second company. The first directory is part of the first company's PKI, the second directory is part of the second company's PKI, the step and the step in which the user attempts to access the server, and the server is the first. It is a part of one company's PKI, and the user presents the signature authentication from the second company PKI to the server, asks for authentication, and sends a query from the server to the first directory, allowing the user to access the server. A step of determining whether or not the user has been authenticated, a step of sending an inquiry from the first directory to the second directory and determining whether or not the user is a member of the second company PKI, and a step of determining whether or not the user is a member of the second company PKI. If a member, the first directory includes a step of notifying the server that the user is allowed access to the server.
【0011】
The present invention also relates to a mutual directory authentication system in a public key infrastructure (PKI). One or more servers are part of the PKI of the first company. One or more client platforms can be used for at least one user to request access to at least one server. The second directory contains information about users who have signature authentication for the second company's PKI. The second directory is part of the second company PKI. The first directory sends an inquiry to the second directory when it receives an inquiry from the server regarding the signature authentication for the PKI of the second company received from one user for authentication on at least one server. Inquiries from the server are sent to the first directory to determine if the user is allowed access to the server. The first directory is part of the first company's PKI. Inquiries sent from the first directory to the second directory are sent to determine whether the user is a member of the PKI of the second company. The first directory notifies the server that the user is authorized to access the server if the user is a member of the second company PKI. The first directory and / or server can be configured to have access to the server and information about users with signature authentication from a second company PKI.
【0012】
Further, the present invention relates to an article composed of a storage medium in which an instruction is stored, and when these instructions are executed, the processing apparatus receives an inquiry regarding signature authentication for a second company's PKI, and the processing apparatus queries the directory. The step of receiving the configuration information to send, the processing device is part of the first company PKI, and the directory is part of the second PKI, and whether the user is allowed access to the server. Whether or not the user is a member of the PKI of the second company by sending the inquiry to the step and the directory, which is the step of receiving the inquiry from the server and the server is a part of the PKI of the first company. If the user is a member of the PKI of the second company, the step of determining whether or not the server is executed and the step of notifying the server that access to the server is permitted are executed.
【0013】
In the following detailed description, the present invention will be described in more detail with reference to a plurality of representative drawings with reference to examples of non-limiting embodiments of the present invention. In the drawings, similar reference numbers shall represent similar parts throughout.
【0014】
BEST MODE FOR CARRYING OUT THE INVENTION
The specific matters shown below are merely examples, and an object of the present invention is to exemplify an embodiment of the present invention. By explaining with reference to the drawings, it will be clear to those skilled in the art how the present invention is actually embodied.
【0015】
Further, in order to avoid obscuring the present invention, and in consideration of the fact that the specific matters concerning the implementation of such a block diagram configuration are highly dependent on the platform on which the present invention is implemented, the configuration is configured as a block diagram. Shown in form. That is, the specific matters should be within the range that can be understood by those skilled in the art. When specific details (eg, circuits, flowcharts) are specified to illustrate examples of embodiments of the invention, it will be appreciated by those skilled in the art that the invention is feasible without these specific details. Is an obvious invention. Finally, any combination of hard wire circuits and software instructions can be used to implement embodiments of the invention, i.e. the invention is specific to any of the hardware circuits and software instructions. It is also clear that it is not limited to combinations.
【0016】
In explaining an example of the embodiment of the present invention, an example of a system block diagram in an example of a host unit environment will be used, but the implementation of the present invention is not limited to this. That is, the present invention can be implemented using other types of systems and in other types of environments (eg, servers).
【0017】
When referring to "one embodiment" or "embodiment" in the specification, it means that the specific function, structure, or property described with respect to the embodiment is included in at least one embodiment of the present invention. The appearance of the phrase "in one embodiment" in various places in the specification does not necessarily mean all the same embodiments.
【0018】
FIG. 2 shows a block diagram of Example 100 of a system architecture capable of implementing a public key infrastructure (PKI) process according to an example of an embodiment of the present invention. The present invention is not limited to the system architecture 100 shown in FIG. The box shown in FIG. 2 represents an entity that can be hardware, software, or a combination of both. The entities are operationally connected to each other on the network. Entities that are not shown to be connected to the network represent one or more people performing the functions shown in the box.
【0019】
System architecture 100 includes data entry 102 that performs the data entry function of the authoritative database 104. The base database 104 resides on server platform 106. Although this specification refers to server platform 106, it should be understood that the invention is not limited to any particular server architecture. Server platform 106 can be, for example, a UNIX (R) or Windows (R) NT server.
【0020】
The basic database 104 contains information about members of a group or company (eg, a company) capable of performing the PKI services according to the invention. The present invention is not limited to the structure of a group or company that stores information in the basic database 104. The information contained in the basic database 104 can include, for example, the names, addresses, telephone numbers, boss names, employee identifications, etc. of members of the group or company. Directory 108 contains the same information that is stored in database 104, but is optimized for fast references to internally stored data rather than fast data input. The information contained in directory 108 can be accessed faster than the information from database 104. Directory 108 functions like a fast-accessible online telephone directory that contains reference information about group or company members stored in the base database 104.
【0021】
The certificate authority 110 may be conventional commercially available software that runs on the server platform 106. Certificate authority 110 stores authentication and related information. This will be described in more detail below. The registration authority 112 may also be commercially available software that can be executed on the server platform 106. The registration authority 112 will also be described in more detail below. The key recovery station 114 may also be commercially available server software that can run on server platform 106, with keys for group or corporate members (eg, stored or lost keys). Can be equipped with a function to restore.
【0022】
Windows (R) 2000 Domain Certificate Authority (CA) 116 is shown and connected to the network with a dotted line. This may or may not be part of the system according to the invention. Windows (R) 2000 can use PKI authentication for single sign-on on the network, but Windows (R) 2000 should only use Windows (R) Certificate Authority Windows (R) Is designed for. Therefore, the system according to the present invention may include not only the 2000 domain CA116 but also the conventional certificate authority 110.
【0023】
The legacy server 118 runs the legacy application program 120. Old-fashioned servers 118 can be, but are not limited to, mainframes, minicomputers, workstations, or other servers capable of running legacy (old-fashioned) software applications. Older software applications may generally not be designed to be essentially interoperable with PKIs. Older applications 120 may be made client-side accessible by a custom client 128, such as an emulator or custom database graphic user interface (GUI). Examples of emulators are IBM 3270 terminal emulators or vt100 terminal emulators.
【0024】
The registration web page 122 can be one or more pages and serves as a user interface to the system architecture 100 shown in FIG. A web server 124 is a software application that supports web pages (such as web page 122) or other HTML output to a web browser client (such as web browser 126). The web server 124 can be any software application that supports web pages or HTML output, such as Apache, Microsoft Internet Information Server applications, and so on.
【0025】
The web browser 126 resides on the client platform 128. Client platform 128 can be any user computer or computer. The web browser 126 may be a client software application that browses web pages, such as the THML protocol, XML protocol, or other protocol. Web browser 126 can be programmed to work with PKI certification issued by Certificate Authority 110. Examples of web browsers with this capability include Netscape Navigator and Microsoft Internt Explorer. Token 130 can be a smart card, a device with a universal serial bus (USB), or any other hardware token that can generate, store, and / or use PKI authentication.
【0026】
User 132 is someone who uses or wants access to System Architecture 100. User 132 can migrate through a number of states, including, for example, new users, current users, and old users. Old users are no longer members of a group or company. System architecture 100 is described with reference to two levels of security. Each level corresponds to different security requirements. The number of security levels is not limited to the present invention. Level 1 search engine 134 should be a search engine that is allowed to search system architecture 100, but only to access Level 1 data with the lowest security level. Can be done. Level 1 data is, for example, freely distributable data, while Level 2 data can be considered enterprise-specific. The level 2 search engine 136 can be a search engine that is allowed to search both level 1 and level 2 data. A level N search engine (not shown) can be a search engine that is allowed to search the entire server that processes data from level 1 to N.
【0027】
A protection level server with Level 1 data can be a web server containing only Level 1 data. Level 1 data is protected so that users must have (at least) Level 1 access to access Level 1 data. A protected web server with Level 2 data 140 can be a web server containing Level 2 data. Level 2 data is protected so that users must have at least Level 2 access to access Level 2 servers. Users with Level 2 access can access both Level 1 and Level 2 servers. A protected web server with Level N data (not shown) is a web server that houses Level N data accessible to Level N or higher users. Users of level N and above can access all data levels up to level N data.
【0028】
VPN Extranet 142 is a software application that acts as a network gateway. As shown, this leads to either the old server 118 and the old application 120, or an external network such as the Internet. The individual abolition authority 144 can be one or more persons engaged in the abolition of members from the system network 100. The individual registration authority 146 can be one or more persons engaged in the registration of members in the system network 100. The personal restoration approver 148 can be one or more persons engaged in obtaining the restoration of certification. The restore agent 150 can be one or more people who restore the authentication, and only needs to restore the authentication when the authentication is first designated as recoverable by another person. Personal role Approver (personal role) approval) 152 can be one or more people who approve different role functions within the system network 100. The web server (manager) administrator can be one or more people engaged in various web functions in the system network 100.
【0029】
The present invention relates to a mutual directory authentication system and method in which a directory in a first company PKI receives an inquiry relating to a user having signature authentication from a second company PKI. The directory in the first company queries the directory in the PKI of the second company to determine the validity of the user from the second company. The directory in the PKI of the first company (company A) has a directory entry for the user from the PKI of the second company (company B), and the PKI of the second company is one of the PKIs of the first company. You can access the above servers. The server that is part of the first company's PKI may contain some data that is unique to the first company, but has data hosted on the server (server A) from company A. A non-disclosure agreement can be entered into with Company B for some specific projects. Therefore, a user from Company B may need access to data on Server A, which is part of Company A.
【0030】
Different companies usually use different PKIs, so if Company A wants to give access to one or more of its servers to a user from Company B, the user from Company B once requests access to the server from Company A. If so, the server from company A sends a query to company A's directory (directory A) to authenticate the user's identity from company B. A directory in company A can contain directory entries for users from company B that may need access to servers in company A, so directory A is received by directory A in relation to users in company B. For all inquiries, it is programmed to query the directory from company B (directory B). Directory B determines whether the user is still a member of company B, and if it is a member, permits user B to access the server of company A in response to an inquiry from directory A. Answer. In addition, the directory A may be composed of all users who are allowed to access the server in the company A, and therefore the user from the company B is a member of the company B, but this user. May not be posted in Directory A as someone who has access to a particular server for Company A, which may deny access to that particular server.
【0031】
FIG. 3 shows a flowchart of an example of a mutual directory authentication process according to an example of the embodiment of the present invention. The directory in company A can be configured to query the directory in company B when it receives a PKI signature authentication inquiry from company B (S1). Company A's web server can be configured to allow Company B's users (who have Company B's PKI signature authentication) access to Company A's web server (S2). A user from Company B presents PKI authentication from Company B in an attempt to access Company A's web server (S3). Company A's web server queries Company A's directory and determines whether users from Company B are allowed access to the server (S4). Note that the directory of company A has the user signing authentication from the PKI of company B, and therefore queries the directory in company B to authenticate the user from company B (S5). The directory of company B determines whether or not the user is a member of company B, and confirms or denies that the user is a member of company B (S6). The directory of company B notifies the directory of company A accordingly. When the user is confirmed, the directory of company A notifies the web server of company A that the user from company B is allowed to access the server (S7). Then, if the web server from company A is configured to allow the user from company B to access this web server, the web server from company A will access the user from company B. Allow (S8).
【0032】
The mutual directory authentication system and method according to the present invention has the advantage of being less complex than the current mutual PKI authentication process. Further, the present invention has an advantage that even if the PKI is completely composed of the PKI of the company B, the present invention only allows access to data on a server shared with each other. Data residing on servers maintained by only one of the two companies is kept secure.
【0033】
It should be noted that the above examples are presented merely for the purpose of explanation and should never be construed as a limitation of the present invention. Although the present invention has been described with reference to preferred embodiments, it will be appreciated that the terms used herein are explanatory and exemplary terms and are not limiting terms. Within the scope of the claims, even after the present description and amendments, the embodiments may be modified without departing from the scope and spirit of the invention. Although the present invention has been described here with reference to specific methods, materials, and embodiments, the present invention is not intended to be limited to the specific matters disclosed herein, and the present invention is patentable. It extends to all functionally equivalent structures, methods and uses that fall within the claims.
[Simple explanation of drawings]
[Figure 1]
It is a block diagram of an example of a PKI system architecture.
[Figure 2]
It is a block diagram of an example of a system architecture in which a PKI process can be carried out according to an example of an embodiment of the present invention.
[Fig. 3]
It is a flowchart of the process example of mutual directory authentication in the public key infrastructure by an example of embodiment of this invention.
[Explanation of symbols]
100 system architecture 102 Data entry 104 Basic database 106 server platform 108 directory 110 Certificate Authority 112 Registration Bureau 114 Key Recovery Bureau 116 Domain Certificate Authority (CA)
25 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16 Sheet 17 Sheet 18 Sheet 19 Sheet 20 Sheet 21 Sheet 22 Sheet 23 Sheet 24 Sheet 25
73 members in 7 offices
Priority claims15
| Document | Office | Kind | Date |
|---|---|---|---|
| 21046100 | United States of America | P | |
| 21046100 | United States of America | P | |
| 60210461 | United States of America | – | |
| 22933600 | United States of America | P | |
| 22933600 | United States of America | P | |
| 60229336 | United States of America | – | |
| 09823477 | United States of America | – | |
| 82347701 | United States of America | A | |
| 82347701 | United States of America | A | |
| 2000210461 | – | – | – |
| 2000229336 | – | – | – |
| 2001823477 | – | – | – |
| US20000210461P | – | – | – |
| US20000229336P | – | – | – |
| US20010823477 | – | – | – |
Members73
| Document | Office | Kind | |
|---|---|---|---|
| EP1074427A2 | European Patent Office (EPO) | A2 | |
| WO0110667A1 | World Intellectual Property Organization (WIPO) | A1 | |
| JP2001055066A | Japan | A | |
| AU3359900A | Australia | A | |
| US6199945B1 | United States of America | B1 | |
| KR20010020638A | Republic of Korea | A | |
| EP1162779A2 | European Patent Office (EPO) | A2 | |
| EP1162780A2 | European Patent Office (EPO) | A2 | |
| EP1162781A2 | European Patent Office (EPO) | A2 | |
| EP1162782A2 | European Patent Office (EPO) | A2 | |
| EP1162783A2 | European Patent Office (EPO) | A2 | |
| EP1162807A2 | European Patent Office (EPO) | A2 | |
| EP1164745A2 | European Patent Office (EPO) | A2 | |
| WO0196140A1 | World Intellectual Property Organization (WIPO) | A1 | |
| AU6669901A | Australia | A | |
| EP1175037A2 | European Patent Office (EPO) | A2 | |
| EP1175038A2 | European Patent Office (EPO) | A2 | |
| EP1175039A2 | European Patent Office (EPO) | A2 | |
| JP2002033726A | Japan | A | |
| JP2002049311A | Japan | A | |
| JP2002057660A | Japan | A | |
| JP2002057661A | Japan | A | |
| JP2002064485A | Japan | A | |
| US2002024245A1 | United States of America | A1 | |
| JP2002082913A | Japan | A | |
| JP2002123492A | Japan | A | |
| JP2002124944A | Japan | A | |
| JP2002135244A | Japan | A | |
| JP2002135245AThis record | Japan | A | |
| US2002138724A1 | United States of America | A1 | |
| US2002141592A1 | United States of America | A1 | |
| US2002144111A1 | United States of America | A1 | |
| US2002176582A1 | United States of America | A1 | |
| US6488333B2 | United States of America | B2 | |
| US6494531B1 | United States of America | B1 | |
| EP1074427A3 | European Patent Office (EPO) | A3 | |
| EP1162782A3 | European Patent Office (EPO) | A3 | |
| EP1162781A3 | European Patent Office (EPO) | A3 | |
| US2003208690A1 | United States of America | A1 | |
| EP1162807A3 | European Patent Office (EPO) | A3 | |
| EP1175038A3 | European Patent Office (EPO) | A3 | |
| EP1162783A3 | European Patent Office (EPO) | A3 | |
| EP1175037A3 | European Patent Office (EPO) | A3 | |
| EP1162779A3 | European Patent Office (EPO) | A3 | |
| EP1175039A3 | European Patent Office (EPO) | A3 | |
| EP1164745A3 | European Patent Office (EPO) | A3 | |
| EP1162780A3 | European Patent Office (EPO) | A3 | |
| US6898710B1 | United States of America | B1 | |
| JP3660274B2 | Japan | B2 | |
| US6934393B2 | United States of America | B2 | |
| US6934859B2 | United States of America | B2 | |
| US6941455B2 | United States of America | B2 | |
| US7028180B1 | United States of America | B1 | |
| US7028181B1 | United States of America | B1 | |
| US7047409B1 | United States of America | B1 | |
| EP1162807B1 | European Patent Office (EPO) | B1 | |
| US7069440B2 | United States of America | B2 | |
| DE60119834D1 | Germany | D1 | |
| EP1175038B1 | European Patent Office (EPO) | B1 | |
| KR100611570B1 | Republic of Korea | B1 | |
| DE60121517D1 | Germany | D1 | |
| EP1162781B1 | European Patent Office (EPO) | B1 | |
| DE60119834T2 | Germany | T2 | |
| DE60122828D1 | Germany | D1 | |
| DE60121517T2 | Germany | T2 | |
| DE60122828T2 | Germany | T2 | |
| US7275155B1 | United States of America | B1 | |
| US2007234039A1 | United States of America | A1 | |
| EP1162780B1 | European Patent Office (EPO) | B1 | |
| DE60132733D1 | Germany | D1 | |
| DE60132733T2 | Germany | T2 | |
| US7747852B2 | United States of America | B2 | |
| EP1175039B1 | European Patent Office (EPO) | B1 |
10 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Decision of refusalJAPANESE INTERMEDIATE CODE: A02A02 | A02 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written permission of extension of timeJAPANESE INTERMEDIATE CODE: A602A602 | A602 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Notification of change in applicantJAPANESE INTERMEDIATE CODE: A711A711 | A711 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written permission of extension of timeJAPANESE INTERMEDIATE CODE: A602A602 | A602 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 |
Numbers
- Publication
- 2002-135245
- Publication, DOCDB
- 2002135245
- Publication, EPODOC
- JP2002135245
- Application
- 175360
- Application, DOCDB
- 2001175360
- Application, EPODOC
- JP20010175360
Titles2
- Japanese
- 【発明の名称】公開鍵インフラストラクチャにおける相互ディレクトリ認証システムおよび方法
- English
- Invention: Mutual Directory Authentication System and Method in Public Key Infrastructure
Classification
- CPC, 17
- H04L63/0823
- G06F21/33
- G06F21/604
- G06F21/6209
- G06F21/6218
- G06F21/6236
- G06F2221/2113
- G06F2221/2119
- H04L63/0227
- H04L63/0272
- H04L63/0442
- H04L63/083
- H04L63/12
- H04L9/006
- H04L9/3234
- H04L9/3247
- H04L9/3263
- IPC, 5
- G06F21 00
- G06F21 24
- H04L9 32
- G06F12 14
- H04L29 06