Binding a digital certificate to multiple trust domains

• US 20090210703A1
• Filed: 01/16/2009
• Published: 08/20/2009
• Est. Priority Date: 01/18/2008
• Status: Active Grant

• Current Assignee: IdenTrust, Inc. (Assa Abloy AB)
• Original Assignee: IdenTrust, Inc. (Assa Abloy AB)
• Inventors: Epstein, William C., Miller, Lawrence R.
• Granted Patent: US 8,793,487 B2
• Time in Patent Office: Days
• US Class Current: 713/157
• CPC Class Codes: G06F 21/33 using certificates
• CPC Class Codes: G06Q 20/02 involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
• CPC Class Codes: H04L 63/0442 wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption cryptographic mechanisms or cryptographic arrangements for public-key encryption H04L9/30
• CPC Class Codes: H04L 63/0823 using certificates cryptographic mechanisms or cryptographic arrangements for entity authentication involving certificates H04L9/3263
• CPC Class Codes: H04L 63/20 for managing network security; network security policies in general filtering policies H04L63/0227
• CPC Class Codes: H04L 9/006 involving public key infrastructure [PKI] trust models network architecture or network communication protocol for supporting authentication of entities using certificates in a packet data network H04L63/0823
• CPC Class Codes: H04L 9/3247 involving digital signatures
• CPC Class Codes: H04L 9/3263 involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements network architectures or network communication protocols for supporting authentication of entities using certificates in a packet data network H04L63/0823
• CPC Class Codes: H04L 9/3265 using certificate chains, trees or paths; Hierarchical trust model

Abstract

A public key infrastructure comprising a participant that issues digital certificates. Each digital certificate can be relied upon in at least two different trust domains. The public key infrastructure does not employ policy mapping between or among the trust domains. Furthermore, the public key infrastructure does not link any pair of trust domains via cross-certificates. Just one trust domain is bound to the digital certificate at any given moment. The current trust domain that is to be bound to the digital certificate is elected by a relying party at the time of reliance, based upon a specific certificate validation methodology selected by the relying party.

Claims

1. A public key infrastructure comprising a participant that issues a digital certificate, wherein the digital certificate can be relied upon in at least two different trust domains, wherein:

said public key infrastructure does not employ policy mapping between or among the trust domains; and

said public key infrastructure does not link any pair of trust domains via cross-certificates.

2. The public key infrastructure of claim 1 wherein at least one trust domain is a closed contractual domain.

3. The public key infrastructure of claim 1 wherein at least one trust domain is an open trust domain.

4. The public key infrastructure of claim 3 wherein the digital certificate is qualified under the law of a European country that complies with the European Digital Signature Directive.

5. The public key infrastructure of claim 1 wherein just one trust domain is bound to the digital certificate at any given moment.

6. The public key infrastructure of claim 1 wherein the digital certificate is relied upon by a relying party;

and

the current trust domain that is to be bound to the digital certificate is elected by the relying party at the time of reliance, based upon a specific certificate validation methodology selected by the relying party.

7. The public key infrastructure of claim 6 wherein the certificate validation methodology is a methodology from the group of methodologies consisting of:

a signed validation request made via an Online Certificate Status Protocol; and

making reference to a publicly posted Certificate Revocation List issued by the participant.

8. The public key infrastructure of claim 1 wherein different trust domains have different rules governing liability, recourse, and dispute resolution.

9. The public key infrastructure of claim 1 wherein each trust domain comprises a policy that is uniquely identified by an Object Identifier.

10. The public key infrastructure of claim 9 wherein each Object Identifier comprises at least one of:

a customer agreement;

documents incorporated by reference in a customer agreement;

public law under which a policy is enforced;

a Certificate Policy;

a Certification Practices Statement;

public law under which digital signatures are locally enforceable and digital certificates are locally valid.

11. The public key infrastructure of claim 1 wherein a first trust domain is trust anchored by a root digital certificate issued to the participant, and a second trust domain is trust anchored by a digital certificate self-signed by a certificate authority of the participant.

12. The public key infrastructure of claim 1 wherein a first trust domain is trust anchored by a first digital certificate that is issued to the participant by a first root certificate authority, and a second trust domain is trust anchored by a second digital certificate that is issued to the participant by a second root certification authority.

13. The public key infrastructure of claim 1 wherein a first trust domain is trust anchored by a first digital certificate issued to the participant by a first root certificate authority, and a second trust domain is trust anchored by a second digital certificate that is coupled to the participant by a bridge certification authority digital certificate.