Source: http://www.google.com/patents/US20030115342?dq=5708422
Timestamp: 2017-11-19 11:09:04
Document Index: 534306254

Matched Legal Cases: ['arty 404', 'arty 404', 'arty 404', 'arty 404', 'arty 404', 'arty 502', 'arty 404', 'arty 700', 'arty 704', 'arty 706', 'arty 800', 'arty 804', 'arty 806']

Patent US20030115342 - Method of assembling authorization certificate chains - Google Patents
A method for assembling authorization certificate chains among an authorizer, a client, and a third party allows the client to retain control over third party access. The client stores a first certificate from the authorizer providing access to a protected resource and delegates some or all of the privileges...http://www.google.com/patents/US20030115342?utm_source=gb-gplus-sharePatent US20030115342 - Method of assembling authorization certificate chains
Publication number US20030115342 A1
Application number US 10/022,592
Also published as US7571314, US8769266, US8880877, US9124577, US9407629, US20090282242, US20120096522, US20150006888, US20150373014
Publication number 022592, 10022592, US 2003/0115342 A1, US 2003/115342 A1, US 20030115342 A1, US 20030115342A1, US 2003115342 A1, US 2003115342A1, US-A1-20030115342, US-A1-2003115342, US2003/0115342A1, US2003/115342A1, US20030115342 A1, US20030115342A1, US2003115342 A1, US2003115342A1
US 20030115342 A1
providing, by the client to the third party, at least one second certificate and the universal resource identifier (URI); and
providing, by the client to the authorizer, the at least one first certificate, upon the authorizer accessing the universal resource identifier (URI);
wherein the client retains control over the third party's use of the first certificate.
providing, by the client to the third party, a third certificate with a short-term usage, upon demand by the authorizer.
3. The method as recited in claim 2, wherein the third certificate is a one-time use certificate.
limiting, by the client, the third party's use of the first certificate.
tracking, by the client, the third party's use of the first certificate.
7. The method as recited in claim 1, wherein the contents of the first certificate are not revealed to the third party.
revoking, by the client, the first certificate, upon the authorizer accessing the universal resource identifier (URI).
9. A machine-accessible medium having associated content capable of directing the machine to perform a method comprising:
generating, by the client, a universal resource identifier (URI) associated with both the at least one first certificate and a third party;
providing, by the client to the third party, a second certificate and the universal resource identifier (URI); and
providing, by the client to the authorizer, the first certificate, upon the authorizer accessing the universal resource identifier (URI), upon the third party providing the second certificate and universal resource identifier (URI) to the authorizer.
10. The machine-accessible medium recited in claim 9, wherein the third party provides the second certificate and universal resource identifier (URI) to the authorizer in an extensible Markup language (XML) signature.
11. The machine-accessible medium recited in claim 10, wherein the first and second certificates are Simple Public Key Infrastructure (SPKI) certificates.
12. The machine-accessible medium recited in claim 9, further comprising:
granting, by the authorizer, access to the third party.
13. The machine-accessible medium recited in claim 9, further comprising:
14. The machine-accessible medium recited in claim 9, further comprising:
revoking, by the client, the second certificate.
15. A data signal, comprising:
a second digital certificate issued from a client to a third party; and
an universal resource identifier (URI) capable of retrieving a first digital certificate from a database associated with the client, wherein the first digital certificate issued from an authorizer to the client.
16. The data signal recited in claim 15, wherein the second digital certificate grants less power than the first digital certificate.
17. The data signal recited in claim 15, wherein the first and second digital certificates are Simple Public Key Infrastructure (SPKI) certificates.
Computer security provides confidentiality, authentication, integrity, and non-repudiation. Confidentiality prevents an eavesdropper from reading a message. Authentication prevents an intruder from masquerading as the originator of a message. Integrity prevents an intruder from modifying a message in transit or substituting a false message for a legitimate one. Non-repudiation prevents a sender from falsely denying later that he sent a message.
Encrypting a message is one way to ensure confidentiality. FIG. 1 is a block diagram of a typical encryption method in the prior art. Suppose Alice wants to send a confidential message to Bob. First, Bob sends Alice his public key 102. Then, Alice creates a cleartext 104 (an unencrypted message) encrypts it using Bob's public key 102, and sends the resulting ciphertext 106 to Bob. Next, Bob decrypts the ciphertext 108 with his private key 110, enabling him to read the cleartext 112. Eve, an eavesdropper, is unable to read the ciphertext 106 during transit and cannot decrypt it with the public key, so it is confidential. Suppose, however, when Bob initially sent his public key 102 to Alice, Eve intercepted Bob's public key 102 and substituted her own public key. Alice-thinking she had Bob's public key-encrypted the message and sent it to Bob. Eve intercepted again and decrypted the ciphertext 106 and read the cleartext 112. Even worse, Eve then substituted different cleartext using Bob's public key and Bob thought it came from Alice. How can Bob tell if the message came from Alice? Bob can tell by authenticating with an identity certificate.
[0003]FIG. 2A is a block diagram of an identity certificate 202 in the prior art. The identity certificate 202 associates an identity 204 with a public key 206 to ensure the public key 206 belongs to the identity 204. Identity certificates 202 contain information from a Certification Authority (CA) 208 and a digital signature 210. The digital signature 210 is proof of authorship by the person identified in the identity 204. If Bob digitally signs 210 an identity certificate 202 through a CA, who verifies his identity, Eve is thwarted from substituting her public key 102 for Bob's. This is because Alice verifies Bob's public key 102 using his identity certificate 202, before encrypting the cleartext 104. Thus, the identity certificate 202 provides authentication. It also ensures integrity and non-repudiation.
[0009]FIG. 1 is a block diagram of a typical encryption method in the prior art.
[0010]FIG. 2A is a block diagram of an identity certificate in the prior art.
[0011]FIG. 2B is a block diagram of an authorization certificate to be contrasted with the identity certificate shown in FIG. 2A.
[0012]FIG. 3 is a block diagram of an authorization certificate chain.
[0013]FIGS. 4A and 4B are block diagrams that together show a method embodiment of the present invention for assembling authorization certificate chains among an authorizer, a client, and a third party.
[0014]FIG. 5 is a block diagram of a data signal embodiment of the present invention that is sent from a client to a third party.
[0015]FIG. 6 is a block diagram of an example embodiment of the data signal shown in FIG. 5 as a Simple Object Access Protocol (SOAP) request and an example method of using it.
[0016]FIGS. 7 and 8 are flow charts of additional method embodiments of the present invention for assembling authorization certificate chains among an authorizer, a client, and a third party.
Methods for assembling authorization certificate chains and associated data signals are described. In the following detailed description, reference is made to the accompanying drawings, which form a part hereof. These drawings show, by way of illustration, specific embodiments in which the invention may be practiced. In the drawings, like numerals describe substantially similar components throughout the several views. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. Other embodiments may be used and structural, logical, and electrical changes may be made without departing from the scope of the present invention.
[0018]FIG. 2B is a block diagram of an authorization certificate 220 to be contrasted with the identity certificate 204 shown in FIG. 2A. The identity certificate shown in FIG. 2A associates an identity 204 with a public key 206, while the authorization certificate 220 shown in FIG. 2B associates an authorization 222 with a public key 224. Thus, an authorization certificate 220 issued to a third party does not reveal the identity of the third party. The authorization certificate 220 also contains delegated privileges 226 and a validity interval 228. Delegated privileges 226 may include conditions, limitations, and restrictions on those privileges, including scope, time, and context. The validity interval 228 defines if and when the authorization certificate is valid.
Traditional identity certificates 204 have significant drawbacks, while authorization certificates 220 are capable of delegating limited privileges to a third party, without revealing the identity 204 of the third party, while still providing confidentiality, authentication, integrity, and non-repudiation. Traditional identity certificates 204 are implemented according to the X.509 standard, while authorization certificates 220 are implemented according to the SPKI standard. SPKI certificates can directly encode authorizations, while X.509 certificates merely bind public keys to identities. Software applications must subsequently interpret X.509 identities to make authorization decisions using mechanisms subject to additional security risk, such as compromising a database mapping certificate identities to login account names. SPKI certificates also support constrained delegation of authority.
The delegation features of SPKI certificates enable certificate issuers to specify whether the entity to which an authorization certificate is issued is capable of empowering other keys to obtain the same or more limited authorization. These features enable web service providers to use subcontractors to perform specific aspects of the service on behalf of the client without the client needing to know of or issue credentials to the subcontractors. Interestingly, many of the scenarios used to describe and motivate the use of web services describe the same “service is a client of other services” model. However, the trust and security issues that arise in this context are an open issue. For example, suppose a client authorizes a service to access one of its own protected resources, e.g. a client-side database by agreeing on a shared secret or digital certificate value. Current web service proposals have no good way for the service to delegate access to subcontractors. Divulging the shared secret or other credential to a subcontractor is unacceptable, because there is often no long-term trust relationship with the subcontractor. SPKI certificates provide an elegant and robust solution to this open issue.
[0022]FIG. 3 is a block diagram of an authorization certificate chain 300. An authorizer is an entity that makes an authorization decision based on a key used to sign a certificate that is recognized, known, and trusted by the authorizer. Any holder of an SPKI cert6ificate can act as an authorizer. An authorization certificate chain 300 is a sequence of one or more certificates issued by a holder of authorized keys. The chain conveys the authorization where the root key is trusted by prior knowledge. For example, Major has a root key stored on a secure computer system used in creating certificates. In the Fly-By-Night scenario, Major is the authorizer and signer of an authorizer-to-client certificate 304 and E-Commerce signs the client-to-third-party certificate 306.
[0023]FIG. 3 shows a certificate chain 300 from an authorizer 302 to an authorizer-to-client certificate 304 to a client-to-third party certificate 306. In the Fly-By-Night scenario, the authorizer 302 is Major, the authorizer-to-client certificate 304 is the certificate issued from Major to E-Commerce, and the client-to-third party certificate 306 is the certificate issued from E-Commerce to Fly-By-Night. When Fly-By-Night exercises the privileges in the client-to-third party certificate 306, E-Commerce is notified to control the access and to provide the authorizer-to-client certificate 304. Thus, Fly-By-Night never has knowledge of the authorizer-to-client certificate 304, keeping E-Commerce in the loop. In addition, E-Commerce is in the loop so that it can reconsider the access at the time it is being exercised and, if necessary, revoke the privilege. For example, E-Commerce might revoke a privilege if Fly-By-Night was no longer doing business with E-Commerce or if other circumstances had changed.
Unlike X.509 identity certificates, SPKI authorization certificates do not need CAs and do not require Certificate Revocation Lists (CRLs). A CRL is a mechanism that a CA uses to publish and disseminate information about revoked certificates to certificate-issuers. A CRL is analogous to a list of bad checking accounts maintained by a grocery store. Maintaining and publishing notices of revoked certificates is widely acknowledged to be expensive and problematic. One aspect of the present invention is a method where an intermediary, e.g. a client, issues a long-lived SKPI authorization certificate to a third party so that the validity of the certificate and corresponding potential for harm is implicitly limited by the subsequent involvement of the intermediary in the certificate processing. This increases security in cases where services are outsourced across organizational boundaries where trust relationships are less stable than in traditional business models.
[0027]FIGS. 4A and 4B are block diagrams that together show a method embodiment of the present invention for assembling authorization certificate chains among an authorizer 400, a client 402, and a third party 404. FIG. 4A shows how the certificates are initially setup. First, an authorizer 400 delivers 406 a first certificate to a client 402. For example, Major delivers a first certificate to ECommerce. Then, the client 402 stores 408 the first certificate and a Universal Resource Indicator (URI) that is associated with a third party 404 in a database 410. Next, the client 402 delivers 412 a second certificate and the URI to the third party 404.
[0028]FIG. 4B shows what happens when the third party 404 requests access to a protected resource using the second certificate. The third party 404 passes 414 the second certificate and URI to the authorizer 400. Next, the authorizer 400 performs an HTTP “Get” 416 on the URI. Then, the client 402 retrieves 418 the first certificate using the URI and performs additional processing. As a result, the client returns 420 the first certificate to the authorizer 400. Finally, the authorizer 400 grants the request 422.
[0029]FIG. 5 is a block diagram of a data signal embodiment of the present invention that is sent from a client to a third party. One aspect of the present invention is a data signal 500 sent from a client to a third party. The data signal comprises a second digital certificate issued from the client to the third party 502 and a URI 503. The URI is capable of retrieving a first digital certificate from a database associated with the client, wherein the first digital certificate issued from an authorizer to the client. FIG. 5 shows an example where the URI 503 uses the Internet 506 to execute a client script 508 to retrieve an authorizer-to-client certificate 510. The client script is an Active Server Page (ASP) or a Common Gateway Interface (CGI) program or some other code executable over the Internet. In one embodiment, the second digital certificate grants less power than the first digital certificate. In another embodiment, the first and second digital certificates are SPKI certificates. SPKI certificates are examples of the type of certificate capable of performing the method of the present invention and other kinds of digital certificates having cryptographic techniques capable of expressing the methods of the present invention also work.
[0030]FIG. 6 is a block diagram of an example embodiment of the data signal shown in FIG. 5 as a Simple Object Access Protocol (SOAP) request 600 and an example method of using it. The SOAP Request 600 comprises header data 602 that comprises an SPKI certificate 604 and a Retrieval Method including a URI 606. First, the third party 404 signs 608 the SOAP request and sends it to the authorizer 400. The authorizer 400 extracts 610 the SPKI certificate from the SOAP request and performs an HTTP “Get” 612 on the URI. The URI invokes 614 a client web server 616 that performs additional processing 618 and returns 620 a certificate issued by the authorizer to the client 622.
[0031]FIGS. 7 and 8 are flow charts of additional method embodiments 700, 800 of the present invention for assembling authorization certificate chains among an authorizer, a client, and a third party. As shown in FIG. 7, one aspect of the present invention is a method for assembling authorization certificate chains among an authorizer, a client, and a third party 700. First, the client stores at least one first certificate from the authorizer 702. Also, the client stores a URI associated with both the at least one first certificate and the third party 704. Then, the client provides at least one second certificate and the URI to the third party 706. When the authorizer accesses the URI 708, the client provides the at least one first certificate to the authorizer 710, so that the client retains control over the third party's use of the first certificate 712.
In one embodiment, the client provides a third certificate with a short-term usage to the third party, upon demand by the authorizer. In another embodiment, the third certificate is a one-time use certificate. In another embodiment, the third certificate is a short-lived certificate. In another embodiment, the one-time use or short-lived certificate is generated on demand. In another embodiment, the one-time use or short-lived certificate is generated on demand by the authorizer. For example; suppose Major issued a long-lived certificate to E-Commerce and E-Commerce issued a long-lived certificate to Fly-By-Night, but E-Commerce also issued a short-lived or one-time use certificate to Fly-By-Night. This forces Fly-By-Night to go back to E-Commerce after a short time or one use to get another certificate, giving E-Commerce more control. The short-lived or one-time use certificate could be generated during the additional processing of step 6 of FIG. 4B and returned to the authorizer along with the first certificate in step 7. Short-lived and one-time use certificates prevent bypassing of the client by the third party. In another embodiment, a secure channel is established with the authorizer in place of a onetime use certificate.
As shown in FIG. 8, another aspect of the present invention is a machine-accessible medium having associated content capable of directing the machine to perform a method of assembling authorization certificate chains among an authorizer, a client, and a third party 800. In one embodiment, the associated content is a software development kit. The client receives a first certificate from the authorizer 802 and then generates a URI associated with both the at least one first certificate and the third party 804. The client provides a second certificate and the URI to the third party 806. After the third party provides the second certificate and URI to the authorizer 808, the authorizer access the URI 810 and, then, the client provides the first certificate to the authorizer 812. In one embodiment, the third party provides the second certificate and URI to the authorizer in an XML signature. In another embodiment, the first and second certificates are SPKI certificates. In another embodiment, the authorizer grants access to the third party. In another embodirnent, the client tracks at least one use of the second certificate. In another embodiment the client revokes the second certificate.
In an example embodiment of the present invention, the client maintains a database of third parties to which it has issued authorization certificates. The database contains enough information to construct certificates and store them. Other information, such as the client's arrangement with each third party and information related to later processing is optionally included in the database. Each such certificate is identified by a certificate identification value (certID). The certID is scoped by the particular context of the client and third party, so it need not be globally unique. When the client issues a certificate to the third party, it also provides the third party with a URI string of the form URI_prefix#certID. For example, the third party may provide the URI string http://www.TheClient.com/SubDomain/SPKI/Auth1234#delegate5678. The URI can also contain information about the third party and other information to help the client web server later on when it processes the request for that URI. When the third party signs a SOAP request to send to the authorizer, it first includes its own SPKI certificate. For example, the third party includes its own SPKI certificate in an <SPKIData> element of the XML signature's <KeyInfo> element. To complete the authorization information for the signature, the third party also includes a <RetrievalMethod> element of the signature's <KeyInfo> with the URI value specified by the client. For example, <RetrievalMethod URI= http://www.TheClient.com/SubDomain/SPKI/Auth1234delegate5678/>.
It is to be understood that the above description it is intended to be illustrative, and not restrictive. Many other embodiments are possible and some will be apparent to those skilled in the art, upon reviewing the above description. For example various types of digital certificates may be used in place of SPKI certificates, languages other than XML may be used, communications other than SOAP requests may be used, Universal Resource Locators (URLs) may be used in place of URIs, Intranets, Local Area Networks (LANs) or other networks may be used in place of the Internet, and more. Therefore, the spirit and scope of the appended claims should not be limited to the above description. The scope of the invention should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.
US7395550 * Dec 21, 2006 Jul 1, 2008 Intertrust Technologies Corp. Trust management systems and methods
US7546463 Nov 30, 2004 Jun 9, 2009 Sap Ag Method and system for delegating authority in an online collaborative environment
US7694334 * Dec 3, 2004 Apr 6, 2010 Nokia Corporation Apparatus and method for traversing gateway device using a plurality of batons
US7822988 * Oct 23, 2003 Oct 26, 2010 Microsoft Corporation Method and system for identity recognition
US8312526 Nov 30, 2004 Nov 13, 2012 Sap Aktiengesellschaft Method and system for delegating authority with restricted access right in an online collaborative environment
US8589519 Jun 18, 2008 Nov 19, 2013 Telefonaktiebolaget Lm Ericsson (Publ) Method and device for uniform resource identifier handling of user device
US8601558 * Nov 15, 2012 Dec 3, 2013 Blackberry Limited Pushing certificate chains to remote devices
US9762555 Jul 24, 2015 Sep 12, 2017 Huawei Technologies Co., Ltd. Data processing method and apparatus
US20060123475 * Dec 3, 2004 Jun 8, 2006 Williams Michael G Apparatus and method for traversing gateway device using a plurality of batons
US20130073846 * Nov 15, 2012 Mar 21, 2013 Research In Motion Limited Pushing certificate chains to remote devices
EP1507381A2 * Aug 10, 2004 Feb 16, 2005 Ricoh Company, Ltd. Information processing apparatus, an authentication apparatus, and an external apparatus
EP1507381A3 * Aug 10, 2004 Apr 18, 2007 Ricoh Company, Ltd. Information processing apparatus, an authentication apparatus, and an external apparatus
EP1662696A1 * Oct 27, 2005 May 31, 2006 Sap Ag Method and system for delegating authority with restricted access right in an online collaborative environment
EP1662698A1 * Nov 23, 2005 May 31, 2006 Sap Ag Method and system for delegating authority in an online collaborative environment
EP2991268A4 * Dec 29, 2014 Mar 2, 2016 Huawei Tech Co Ltd Data processing method and apparatus
WO2005045579A3 * Jul 29, 2004 May 10, 2007 Colin Brace Method and system for identity recognition
WO2009154525A1 * Jun 18, 2008 Dec 23, 2009 Telefonaktiebolaget L M Ericsson (Publ) Method and device for uniform resource identifier handling of user device
U.S. Classification 709/229, 713/156
Cooperative Classification H04L2209/68, H04L2209/60, H04L9/3265, H04L63/0823, H04L63/0428, H04L63/0884, H04L9/321, H04L2463/102
European Classification H04L9/32T, H04L63/08C, H04L63/04B
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:LORTZ, VICTOR B.;REEL/FRAME:012399/0788