Trust negotiation in a client/server data processing network using automatic incremental credential disclosure

Trust negotiation in a master-slave data processing network revealed by auto-incrementing certificates

<u>Invention category</u>

The present invention describes the field of master-slave (also known as "distributed") computing, in which a computing device ("the client") requests another computing device ("the server") to perform part of the client's work.

<u>Background of the invention</u>

In the past few years, master-slave computing has become more and more important in the information technology industry. This distributed computing type allows a software process (such as the client) to be executed on one machine to authorize some of its tasks to be executed on another machine, for example, a software process that may be more suitable to perform the task (such as the server). The client and server can also be separate software processes running on the same machine.

In the master-slave system, it is very important for the client and the server to develop a sufficient level of trust with each other before engaging in a meaningful conversation. It should be possible during the "processing period of the client's request to the server", and/ Or the information exchanged during "the processing result of the server is returned to the customer" may be extremely sensitive information. Usually, the client and the server have no previous relationship with each other, and if they have to start a certain type of initial conversation, they can determine whether they can trust each other before revealing any potentially sensitive information. . An appropriate example to illustrate its special benefits is "when the customer is a World Wide Web browser application that sends an e-commerce request on the Internet to a World Wide Web server application." In the initial conversation between these parties, the Internet client and the Internet server did not have any connection before, and for example, the Internet client may be very uncomfortable to provide a credit card number to the international Internet This web server on the network.

In the prior art, it is known to exchange certificates (that is, the digitized sign of the certificate issuer to the certificate owner) between a client and a server to develop trust between them. The issuer's exclusive base code is used to represent the symbol of a certificate, and the issuer's public key can be used to verify a certificate. The certificate aggregates one or more attributes of the owner, each attribute is composed of a pair of name/value, and indicates a certain characteristic of the owner that the issuer has confirmed. Each certificate also contains the public key of the owner of the certificate. The owner can use the corresponding exclusive base code to respond to cross-examination, or otherwise prove the ownership of the certificate. The owner can also use the exclusive base code to represent the symbol of another certificate owned by a third entity.

If so, as everyone knows in the prior art, the certificates can be combined into a chain, where the owner of the one certificate is the issuer of the next certificate in the chain. These chains can be proposed to trace a trust network from a known entity (the issuer of the first certificate in the chain) to the proposed entity, which must be between a known entity and the proposed entity Establish trust between. The proposed entity is the owner of the last document in the chain. The proposed entity can prove the ownership of the certificate by certifying one of the pair of exclusive base codes containing the public key value. An entity directly or indirectly related to the proposing entity owns these other supporting documents, and although the proposing entity does not possess these other supporting documents, the proposing entity does maintain and submit copies of these other supporting documents . Each supporting certificate contains the public key value-one of the exclusive base code pairs of the public key value is used to represent the symbol of the next certificate in the chain.

All the documents presented are directly related to the (possibly indirect) association between the presenting entity and the known entity that issued the first document in the chain. The nature of the association can be inferred by checking the attributes of the certificates in the chain. Multiple chains can be proposed to establish a higher level of trust, or to prove the supplementary characteristics of the proposing entity and the relevance of the proposing entity to known entities.

The previous technique of using certificates to establish mutual trust can be divided into two basic methods. The first method is explained below: "SSL 3.0 Protocol" (Netscape Communications Corporation) by A. Frier, P. Karlton and P. Kocher, November 8, 1996; "TLS Protocol" by T. Dierks and C. Allen , Version 1.0", draft-ietf-tls-protocol-06.txt, November 12, 1998; S.Farrell's "TLS extension based on authorized attribute certificates", draft-ietf-tls-atrr-cert-01 .txt, August 20, 1998. The method will be referred to as the SSL method, because the method is used by SSL, TLS, and TLS based on the extension of attribute-certificate authorization. In the SSL method, the client and the server can exchange certificates as follows. The server unilaterally reveals a pre-selected certificate to initiate the negotiation. It may include a request for a "client certificate", the request including the certificate type acceptable to the server, and in the case of the attribute-certificate, it is a template indicating the required attributes.

The second method is described by N. Ching, V. Jones and M. Winslett "Authorization in the Digital Archive: Safe Access to Services Across the Enterprise Boundary" (1996, ADL Annual Report --- Digital File Library Research and Technology Promotion Symposium, May 1996, Washington), available at http://drl.cs.uiuc.edu/security/pubs.html; it is also sponsored by M. Winslett, N. Ching, V. Jones and I. Slepchin explained in "Using World Wide Web Digital ID" (Computer Security Log, May 1997, pages 255-267), available at http://drl.cs.uiuc.edu/securlty/pubs.html. We call this second method the digital document method. In this method, when a customer submits a service request to a server without attaching sufficient credentials, the server transmits a policy governing the service to the customer. A policy is a certificate formula, that is, a logical combination of the required certificates and the attributes contained in the required certificates that express restrictions. Policies can be used to describe the demand characteristics of the proposing entity and the relevance of the proposing entity to known entities. By receiving the certificate policy as a certificate request, the client has the opportunity to select from private certificates to provide approval services. By sending the policy to the client, the server removes the certificate selection. The implementation also enables different servers to have very different policies, require different customer attributes, and accept certificates issued by different powers.

The two prior art methods both support the server to send a request for a certificate to the client, including a description of the certificate acceptable to the server. However, the present inventor has recorded the current insufficient state of this technique.

In the SSL method, the server has no chance to recognize any information about the client before the server reveals its certificate. The server can treat its certificate as highly confidential, and if the client and the server fail to establish mutual trust, the server will deliver a piece of highly sensitive (confidential) information to the client. In addition, if the certificate disclosed by the server cannot satisfy the client, the client has no opportunity to request additional certificates from the server. This is a serious problem when the client and server have no previous connection. In this case, it is impossible for any single certificate issuer to have an acceptable authority for all interested server attributes for all customers.

The disadvantage of the previous system based on the digital certificate method is that the client only wants to reveal the certificate to the server that has established a certain level of trust. The system previously developed using this digital certificate method has supported the differentiation of services into equivalent categories of customer-certificates to propose policies, and then assigns each customer certificate to one of the two categories for each equivalent category . The first type of certificate can be submitted for any service request in the equivalent category. Only after the users authorization is consulted in a conversational manner, the second type of certificate can be presented. These consultations allow the user to move the certificate from the second type to the first type, so that it can be automatically submitted later. However, this device is not completely automatic, because it requires a user to make trust decisions when exposed to a new service category.

In the text of the digital ID method, Winslett, et al. (quoted above) briefly describes an optional technique whereby the client can request the server ID to unlock the ID that reveals itself. This technique can be used to perform a negotiation in which each participant has a single certificate request. When the customer requests the service, each service is associated with a policy sent by the server to the customer. When the communication definition table is retained, the purpose of the server to present the certificate to the customer will become unclear. One possibility is to establish customer trust as the general purpose of talking to the server. Another possibility is to explicitly establish trust to encourage customers to reveal their credentials. In the latter case, this method can be used to enable a client to request a certificate from the server before revealing any of his own certificates to the server. However, it is impossible for the server to request the client's credentials before revealing its own credentials. Executing this will lead to a cycle of dependencies, and the negotiation will lead to a deadlock. Because in this model, all client certificates are managed by the same policy, any subsequent server requests will lead to a complete transaction for the client. The same request.

<u>Invention summary</u>

According to a first point of view, the present invention provides a data processing device used in a master-slave network, in which a customer data processing device sends a data processing request to the server data processing device, and the server data processing The device performs data processing according to the request and sends a reply back to the customer data processing device. The data processing device includes: a storage device for storing a plurality of regional venue certificates; for receiving data from an opposite venue data processing device A device for the first certificate request, the certificate requested by the first certificate request is a regional venue certificate stored in the storage device, which satisfies a first logical representation for the first certificate request; And a device for transmitting a second certificate request (depending on the content of the first certificate request) to the opposite site data processing device, and the certificate requested by the second certificate request is the opposite site A certificate that satisfies a second logical representation for the second certificate request.

According to a second viewpoint, the present invention provides a method of operating the data processing device of the first viewpoint.

According to a third viewpoint, the present invention provides a computer program product stored on a computer readable storage medium, which when executed on a computer, is used to implement the steps of the second viewpoint and the method.

According to a fourth viewpoint, the present invention provides a computer data signal embedded in a carrier wave, the signal having program elements for instructing a computer to execute the steps of the second viewpoint and the method.

If so, the present invention extends the digital certificate method of the prior art to support a sequence of related certificate disclosure requests. In order to allow a sequence of interrelated document disclosure requests, different documents must be managed by different policies. The certificate request received by the client from the server is not a request for an individual certificate, or even a special certificate combination, but a request to satisfy a logical representation of an indefinite certificate. In the present invention, the incoming certificate request is logically combined with the certificates actually processed by the customer, and a new opposite location certificate is derived together with the access-control policy associated with each certificate ask. If so, the present invention includes any certificate request for a reply and an incoming certificate request derived from a regional certificate-access policy (except for cases where the reply request is not related to the incoming request). And in the latter exceptional case, the dependence of the solid cycle (as discussed above), so an additional document revealing sequence is impossible.

There is no previous solution that explicitly recommends the use of certificates as a basis for managing certificate disclosures. It did not mention the issue of the interdependency between the certificates, and did not mention that different policies require different certificate-access policies to avoid some kind of deadlock. This is the point of view of automated trust establishment among strangers (keep their documents that have been viewed in the past secret).

There was also no mention of the dynamic comprehensive document request during the trust establishment period. The previous solution has selected the document-requested content from the pre-existing policies.

If so, the present invention provides fully automated trust negotiation between data processing devices of strangers (protecting their credentials). A simple negotiation strategy can be used immediately. It is also possible to consider a more sophisticated technique that balances the relationship of successful negotiation and avoids unintentionally revealing information about holding documents.

An important advantage provided by the present invention is that it can automatically establish trust, even when the parties involved may require a little knowledge of their mutual relationship before revealing some of their certificates to their counterparties. Pairing party. In the previous solution, each participant has only one opportunity to present a certificate in each negotiation, and one of the participants must start first. Unlike the previous solution, the present invention does not require negotiation participants to immediately reveal all their credentials without knowing the other participants at all. In order to obtain a highly sensitive service, a customer may have to present a highly sensitive certificate, which is only revealed after obtaining a moderately sensitive server certificate for the first time. To this end, the server may request some less sensitive credentials in turn.

The present invention makes it possible to negotiate a dependent document exchange sequence of variable length. In some cases, the sequence can negotiate a higher level of trust than a single exchange. In terms of e-commerce among strangers, this makes this new solution more important, in which automated business negotiation will require a high level of trust, so that these participants can trade with good trust and handle them appropriately Information revealed.

The present invention provides a basis for increasing the automatic negotiation of certificate disclosure. By "associating an access policy with every certificate held on a regional venue based on the opposite venue certificate" and by "providing the incoming certificate request to the logical combination of the policy, the co-education response can be derived "Execute this.

<u>Detailed description of the preferred system</u>

In the preferred system of the present invention, a plurality of data processing units communicate with each other via a data communication network. In Figure 1, it is illustrated that a regional site 10 communicates with an opposite site 11 via the network (not shown). In the preferred system, the two sites are data processing units (in another system). , The two venues can be separate processing performed on the same data processing unit). Following the second prior art method discussed above [Ching, et al., Winslett, et al.], a security agent 101 is used to represent a data processing unit (ie, negotiation participant) in trust negotiation, as shown in the figure As described in 1. Each negotiation participant can receive a certificate request (Figure 1, incoming certificate request 21). (Each credential request has the format of the credential formula, just like the second prior art method discussed above). The request is to reveal the regional venue credentials to the opposite venue. The purpose of the disclosure may be to unlock the service, or to unlock the disclosure of the opposite venue certificate that must promote the trust negotiation. When facilitating the negotiation, the question that arises immediately is to determine whether the regional venue 10 has enough trust in the opposite venue 11 to reveal the requested certificates, and if not, construct a counter venue certificate that can establish the trust ( Outgoing document request 22) request.

As depicted in Figure 1, each location associates a certificate access policy 102 with each of its own certificates 103. The access policy identifies the opposite location certificate that reveals the unlocking of the regional venue certificate. When receiving a credential request 21, the security agent 101 determines which action is appropriate. The determination is explained in the following paragraphs, together with the architecture diagram in FIG. 1 and the steps 31-37 of the flowchart described in FIG. 2.

When a certificate request 21 in a logical representation format is received from the opposite venue, the security agent's action starts from step 31. In step 32, if the regional venue finds that it does not have the credentials to satisfy the request (and if the security agent belongs to a server and requires some kind of response in real time), a rejection can be sent in step 33. Otherwise, the security agent must determine in step 34 whether sufficient trust has been established in the opposite venue to prove that it is appropriate to provide a combination of credentials that satisfies the request. In particular, "the opposite venue certificate 23 accompanying the request 21" or the "regional cached 104" may satisfy the access policy 102 of the management area certificate 103 (which will in turn satisfy the incoming request 21). In this case, the regional ID combination (26) that is unlocked in this way and satisfies the incoming request 21 can be sent to the opposite venue 11 immediately, as shown in step 35. When receiving the currently incoming request as a response to a previous request in the area, under the assumption that "these documents will now generate trust to unlock the implementation of the earlier request", step 35 Repeat the previous request, together with the documents being transmitted.

On the other hand, step 34 can determine that the opposite venue credentials (23 and/or 104) available in the area are not sufficient to unlock the combination of credentials 103 possessed in the area that satisfies the incoming request 21. In this case, the security agent logically combines the incoming certificate request 21 with the regional venue certificate access policy 102 in step 36 to derive an outgoing request 22 from the opposite venue 11 as a further certificate. The purpose of requesting these opposite venue certificates is to unlock the regional venue certificates that have been requested for the opposite location. If so, in order to avoid unnecessarily requesting certificates, the derivation process borrows "considering which requested certificates are actually processed by the area 103", and also borrows "reverse site certificates that do not require supplementation, and the accumulated opposite site certificates 104 and /Or the area where the field ID 103 has been unlocked and the field ID is unlocked" to simplify the request.

In step 37, when the security agent 101 transmits the request for further opposite venue certificates to unlock the regional venue certificates, the security agent 101 can choose to provide certain unlocked regional venue certificates at the same time. For example, certain regional venue certificates mentioned in the incoming certificate request 21 may be provided. When taking the risk of unnecessary document disclosure, the negotiation strategy decision can increase the probability and speed of the negotiation success. By "increasing the opportunity for the opposite venue to immediately provide the documents that are being requested" and by "reducing the opposite venue, inferring that the combined document-access policy of the two locations has a cyclical dependency and therefore is interrupted The opportunity to negotiate "execute this."

As shown in FIG. 1, when a regional venue is a server and when the opposite venue is a client, the content of the message entered into the server from the client may include a service request 24. The service request is a typical initiation message in a certificate disclosure negotiation between a client and a server. Once a service request 24 is received, the security agent 101 of the server refers to a service management policy (not shown in FIG. 1) to determine whether the opposite venue certificate 23 accompanying the request is sufficient to satisfy the service management policy (for this The second prior art method discussed above is also true). Although some servers are stateless and therefore do not save the client certificate after each client request, other servers (such as the client) cache the opposite venue certificate 104. These servers use the cached opposite venue certificate 104 and the opposite venue certificate 23 accompanying the request to try to satisfy their service management policies. When the service management policy is satisfied, the service (25) is authorized to determine whether to use the cached opposite venue certificate 104. Otherwise, the security agent 101 returns the service management policy in the form of an outgoing certificate request 22. Then, the certificate disclosure is negotiated between the client and the server, and if successful, the client can attach enough certificates to the authorized service to repeat the service request. An example of this exchange is illustrated in FIG. 3.

In Fig. 3, stage 1, the client sends a request for a special service to the server site, requesting the server to perform a special processing task on behalf of the client (for example, reading and accessing a database). Assume that because the client does not know the certificate policy governing the service, no certificate is attached to the request. In stage 2, the server security agent sends the service management policy to the customer security agent, and informs the customer security agent of the options proposed by the certificate, so as to generate enough trust in the server security agent to implement the request Service. The policy constitutes a certificate request, and when the client security agent receives the policy in phase 3, the policy is deemed to constitute a certificate request. The client security agent reacts according to the steps discussed above in conjunction with the flowchart of FIG. 2.

That is, the client security agent receives the certificate request (step 31) (to authorize the service requested in phase 1). It determines that the client has processed at least one combination of credentials that meets the request (step 32). It determines that there are not enough server certificates to satisfy the access control policies of any satisfactory combination of the certificates (step 34). Therefore, it derives a new request (step 36) (where the new request is designed to "unlock the satisfactory combination of its own credentials), and then unlock the appropriate service in turn. Finally, without any attachment Send the request to the server. (In a variation of the example, the client can attach certain certificates requested by the server in phase 2 to the out-of-office request at this point Above, for example, if their access-control policy permits to reveal them without knowing the server in advance).

When the security agent of the server receives the certificate request sent by the client at the end of phase 3, phase 4 begins. The request is processed as discussed above and in conjunction with the flowchart of FIG. 2. The security agent of the server determines that the request has the credentials that satisfy the client's security agent request (step 32), and has not unlocked all the credentials to disclose to the client's security agent (step 34) (the server The security agent has not received any certificates from the client's security agent). It derives a request for a client certificate (step 36), intending to unlock the certificates requested by the client's security agent, and combine it with some of the certificates requested by the client's security agent (where the access control policy for these certificates permits The documents are revealed without first knowing any customer documents) and sent to the customer's security agent (step 37).

When the client's security agent receives the request and the certificates sent by the server's security agent at the end of phase 4, phase 5 begins. The user security agent determines that it has the credentials that satisfy the request (step 32), but none of the satisfactory combinations is based on the credentials. The server credentials received so far have not yet changed the access control policy of the credentials. One of the unlocked certificates is composed (step 34). In an effort to unlock more of its own certificates, the client security agent then derives a new server certificate request as follows (step 36). The client security agent corrects the incoming document request by replacing the document reference that it does not hold with the unchanging fake. Then, the client security agent uses a credential access policy. Replace the certificate for every remaining occurrence (where the client security agent does hold the certificate). Represent the generated formula (such as the access policies) in the form of the opposite venue certificate. Then, it is combined with the certificate request sent by the client to the server at the end of phase 3, and the certificates received from the server may not yet be fully satisfied. The security agent simplifies the generated connection to avoid unnecessary requests for credentials. By exempting each occurrence of a certificate in the formula, the simplification is implemented, where the certificate has been received by the client security agent and satisfies the attribute restrictions indicated in the formula." The document of is regarded as the unchanging truth, and as such is the connection of simplified logic. (Simply exempt a connection from happening; replace an empty connection with true; replace a union containing true with true ). Finally, the client security agent transmits the formula derived and simplified in this way, and at the same time transmits any requested credentials in the incoming request, wherein the access control policy for the requested credentials is determined by the beginning of the phase. The received server certificate was unlocked.

When the security agent of the server receives the request and the certificates sent to it by the client's security agent at the end of phase 5, phase 6 begins. The server security agent determines that it has the credentials that satisfy the request (step 32), and does not unlock all the credentials (step 34). Next, the server security agent derives a new client certificate request by using the very same procedure on the client side in stage 5, which exemplifies the client side (step 36). The basic difference between the server and the client is that in the negotiation strategy exemplified in the example, the server does not reuse its previous client certificate request.

When the client's security agent receives the request and the certificates sent by the server's security agent at the end of phase 6, phase 7 begins. The host security agent determines that it has at least one credential combination that satisfies the request (step 32). Now, the client has received enough server credentials to unlock the combination of credentials (step 34). Therefore, at the end of phase 7, the client security agent sends "the combination" and "the same certificate request sent to the server at the end of phase 5" to the server.

When the security agent of the server receives the repeated request and the certificates sent to it by the client at the end of phase 7, phase 8 starts. The server security agent determines that it has the credentials that satisfy the request (step 32), and because the client credentials sent by the client at the end of phase 7 meet the access control policy of the credentials, it is determined that the credentials are cancelled Locked (step 34). Then, the server security agent sends the certificates to the host.

When the client's security agent receives the certificates sent by the server at the end of phase 8, phase 9 begins. "These certificates", together with "the certificates received by the customer security agent at the beginning of phases 5 and 7" and "the certificates that the customer security agent has picked up since then", and at the same time satisfy the deposit of these customer certificates Access-control policies, where the access-control policies meet the service-management policy received by the client security agent in phase 3. Then, the client security agent transmits an unlocked combination of credentials that also meets the service management policy. The customer security agent also repeats the original service request.

When the security agent of the server receives the service request and the certificates sent by the client at the end of phase 9, phase 10 begins. These certificates meet the service management policy, so the service is authorized and executed, and the result of the service is returned. The client receives the result at stage 11 and ends the example.

<u>Negotiation example</u>

The example presented here illustrates the eleven steps of the hypothetical negotiation described in the diagram in Figure 3. It is intended to illustrate the use of the formulas specified by the preferred system of the present invention. These formulas are expressed informally. This example is for illustrative purposes only, and is not intended to accurately describe any real negotiations, documents, or policies.

<u>Hypothetical document</u>

In the remainder of the example, the entry for each document starts with the abbreviation used for that document.

Security-implementation certificate-jointly held by the client and the server

We assume security-implementation-standards-consultants issue security-implementation-certificates to entities, and set the level of entity security foundation. A third party can use this level to assess the likelihood that the entity will disclose the information provided to the entity due to negligence. In order to enable a graded entity to prove that it meets the requirements of a certain grade, while the children that the entity cannot meet are kept secret, a separate certificate is issued for each grade. The certificate has a certificate called The attribute of "passed", when it meets the requirements of the level, the value of the attribute is "true", otherwise it is "false".

In our example, there are four levels of security implementation, low, intermediate, high, and extremely high. The maximum level that the server meets is "high", and the maximum level that the client meets is "middle". Each entity provides protection for the level of failure of the document. If the pass level of the certificate is also not protected, the difference in protection will make the level of failure obvious. Therefore, regardless of whether the owner passes or fails, all certificates of double blood (except for the lowest level) will be protected.

Very high security-implementation level. High sensitivity.

High security-implementation level. Intermediate sensitivity.

Intermediate security-implementation level. Low sensitivity.

Low security-implementation level. Not sensitive.

Customer ID

Contract destination contract. Issued by the party requesting delivery. Extremely sensitive. It must be ensured that this information will not be disclosed to a competitor.

Letter of credit. Issued by creditors to owners. Medium to high sensitivity.

The warehouse agreement of the terminal starting point. Issued by terminal managers. Intermediate sensitivity. Must avoid spreading to competitors.

S-Receipt The previous shipping receipt. Issued by shippers who shipped goods in the past. In this example, the customer does not have any previous shipment receipts. The account has an account established for the server/shipper. Issued by the shipper. In this example, the customer does not have an account with the server/shipper.

Membership certificate of B-Org business organization. Issued by a commercial organization (such as the International Chamber of Commerce). Not sensitive.

Server certificate

The previous reply slip of the receipt. Issued by the owner of the goods shipped in the past. Not sensitive.

Proof of bond mortgage. Issued by bond agent. Not sensitive.

Ref is derived from the manufacturer's reference. Issued by manufacturers who are willing to recommend the shipper based on previous business experience. Low sensitivity. In this example, the server has at least two of these references from different manufacturers.

Membership certificate of B-Org business organization. Issued by a commercial organization (such as the International Chamber of Commerce). Not sensitive.

Hypothetical policy

Respectively X_clientOr X_serverIndicates the policy for managing a client or server certificate X. The policies presented here are incomplete. In particular, these policies do not express the need for supporting documents (which indicate that the demand for supporting documents is basic). Although it is not entirely or practical, the clauses (terms) introduced by "where" exemplify the use of such restrictions on the attributes of the certificate. For example, the client's access control policy for the certificate of the destination contract requires reference to two different certificate issuers.

Client's document management policy

contract_client= High and reference₁And reference₂And (bond or (receipt₁And receipt₂)) where high.pass=true and reference_1.Issuer reference_2.Issuer and receipt_1.IssuerReceipt_2.Issuer

CEDIT_client= Middle and reference, and reference₂Where middle.pass=true and reference₁.Issuer Reference_2.Issuer

pier_client= Intermediate and (bond or (receipt₁And receipt₂)) where middle.pass=true and receipt_1.IssuerReceipt_2.Issuer

Extremely high c_client= High and B-Org where high. pass = true

middle_client= Low and B-Org where low. pass = true

Low_client= No documents required

Server document management policy

Receipt_server= No documents required

Bond_server= No documents required

refer to_server= Low where low. pass = true

Extremely high_server= High and B-Org where high. pass = true

middle_server= Low and B-Org where low. pass = true

Low_server= No documents required

Service management policy for a server used to arrange transportation

Account or (terminal and ((S-receipt₁And S-receipt₂) Or contract) and credit) where S-receipt_1.IssuerS receipt_2.Issuer

Negotiation steps

This example is a successful negotiation. At the end of phase 2~7, the certificate request is sent. The services requested by the server at the end of phase 2 must be authorized with these client credentials. The remaining part of the negotiation is used to establish sufficient trust for the client to reveal the credentials to the server. The certificates requested in phases 3 to 7 must be unlocked in order to sequentially access a certificate required for successful negotiation.

In each stage when a venue receives a certificate request, it is successful to have the venue that satisfies the request and step 32 in FIG. 2. At the end of each stage, the security agent of the operation transmits all the requested documents in the incoming request (among them, the access policy of the requested documents is unlocked by the opposite venue certificate available on the area) to the opposite site. Refer to these documents as "request documents for unlocking". In the negotiation strategy exemplified in this example, the client's security agent caches and repeats the previous request, but the server's security agent does not do so.

Phase 1-Customer transmits service request: Arrange shipping date

Phase 2-The server receives the request and returns the service management policy

The server must be set up to trust that the customer is really in the market for the transportation service and that the customer can pay for the transportation service.

The service management policy is transmitted as shown above to arrange a transportation.

Phase 3-The client receives the certificate request to authorize the service

Server credentials available in the region: none

Request document for unlocking: None (Failed in step 34)

To simplify the incoming request by exempting the documents that the client does not hold:

Terminals and contracts and credit

This formula replaces each certificate with the (bracket) access policy of each certificate:

[Intermediate and (bond or (receipt₁And receipt₂)) where middle.pass=true and receipt_1.IssuerReceipt_2.Issuer] and

[Gaohe Reference₁And reference₂And (bond or (receipt₁And receipt₂)) where high.pass=true and reference_1.Issuer reference_2.Issuer and receipt_1.IssuerReceipt_2.Issuer] and

[Intermediate and reference₁And reference₂Where middle.pass=true and reference_1.Issuer reference_2.Issuer]

Simplify the formula to send a credential request to the server at the end of phase 3:

Gaohe Reference₁And reference₂And (bond or (receipt₁And receipt₂)) and the middle of the high. Pass = true and reference_2.Issuer reference_2.Issuer and receipt_1.IssuerReceipt_2.Issuer" and low. Pass = True

Phase 4-Service receives the certificate request

Customer ID available in the region: None

Request document for unlocking: bond (Failed in step 34)

This incoming request replaces each certificate with the (bracket) access policy for each certificate:

[Middle and B-Org where middle. Pass=True] and

[Low where low. pass = true] and

[Low where low. pass = true] and

([No documents required] or ([No documents required] and [No documents required])) and

[Low and B-Org where low pass = true]

Simplify the formula to be delivered to the customer at the end of phase 4:

Middle and low and B-Org where middle. pass = true and low. pass = true

Stage 5-The client receives the certificate request and a server certificate

Server credentials available on the region: Bond

Request document for unlocking: Low, B-Org (Failed in step 34)

This incoming request replaces each certificate with the (bracket) access policy for each certificate:

[Low and B-Org where low pass = true] and

[No documents required] and [No documents required]

The formula is combined with the request sent to the server at the end of phase 3:

[[Low and B-Org where low. Pass=True] and [No ID required] and [No ID required]] and

[Gaohe Reference₁And reference₂And (bond or (receipt₁And receipt₂)) and the middle of the high. Through the two truths and reference_1.Issuer reference_2.Issuer and receipt_1.Issuer's receipt_2.Issuer and intermediate.pass=true]

Borrow the server credentials available in the exempt area to simplify the request to the server at the end of phase 5:

Low and B-Org and high and reference₁And reference₂And the middle of which is low. Pass = true and high. Pass = true and reference_1.Issuer reference_2.Issuer and intermediate pass = true

Stage 6-The server receives the certificate request and two client certificates

Customer ID available on the region: Low, B-Org

Request ID for unlocking: Low, B-Org, Middle (Failed in step 34)

The incoming request replaces each certificate with the (bracket) access policy for each certificate.

[No documents required] and

[No documents required] and

[Middle and B-Org where middle. Pass=True] and

[Low where low. pass = true] and

[Low where low. pass = true]

[Low and B-Org where low. Pass=True]

Borrow the client credentials available in the exempt area to simplify the request to the client at the end of phase 6:

Middle of the middle. pass = true

Stage 7-The client receives the certificate request and the three server certificates

Server credentials available on the area: bond (cached since stage 5), low, B-Org, middle

Unlocked request certificate: middle (step 34 succeeded)

At the end of phase 5, send the request to the server (see step 35):

Low and B-Org and high and reference₁And reference₂And middle where low. pass = true and high pass = true and reference_1.Publisher Proverbs Reference_2.Issuer and intermediate.pass=true

Borrow the server credentials available in the exempt area to simplify the request to the server at the end of stage 7.

Gaohe Reference₁And reference₂Where high.pass=true and reference_1.Issuer reference_2.Issuer

Phase 8-The server receives the credential request and a client credential

Customer IDs available in the region: low, B-Org both are cached from stage 6), middle

Request document for unlocking: high, reference₁,refer to₂(Step 34 is successful, send the certificate at step 35)

Stage 9-The customer receives three server certificates, of which the three server certificates complete unlocking of the client certificates that will authorize the service. Since no further certificate request has been received, the relevant request (step 31) It becomes the service management policy received at the beginning of phase 3 again.

Server credentials available in the area: bond (received in stage 5) low, B-Org, middle (received in stage 7) high, reference₁,refer to₂(Received in stage 9)

Request documents for unlocking: dock, contract, credit (step 34 is successful) Now repeat "service request", "arrange shipping date", and "transmit first in phase 1" with the attached request document.

Stage 10-The server receives the service request and three attached certificates, and authorizes the service

The server confirms that the attached certificates meet the service management policy, and authorizes the requested service. The result of the service is returned at the end of phase 10.

Stage 11-the customer receives the service requested

With reference to the detailed descriptions and links of these preferred systems of the present invention provided below

The same as the following figure, will better understand the present invention;

Figure 1 is a block diagram illustrating the software components according to a preferred system of the present invention;

Figure 2 is a flowchart illustrating the processing steps carried out by a regional venue according to a preferred system of the present invention; and

Figure 3 is a representative sequence diagram illustrating a request and reply sequence according to a preferred system of the present invention.