GB2382006A

GB2382006A - Digital certificate containing the identity of an entity which will rely on the certificate

Info

Publication number: GB2382006A
Application number: GB0126596A
Authority: GB
Inventors: Peter Roy Dare; John Owlett
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2001-11-06
Filing date: 2001-11-06
Publication date: 2003-05-14
Also published as: GB0126596D0

Abstract

A method and system for supply of data relating to a described entity 302 to a relying entity 304. The method includes generating a first digital certificate referred to as an empowerment certificate signed with an electronic signature by a first signing entity which may be the described entity. The empowerment certificate includes one or more attributes of the described entity 302. The empowerment certificate also includes an indication of data relating to the described entity 302 which is to be supplied and an indication of one or more sources 306 for the data to be supplied. The empowerment certificate also includes one or more attributes identifying one or more relying entities 304 to which the data is authorised to be supplied. The method also includes the relying entity 304 forwarding the empowerment certificate for processing and a source (306) supplying the data indicated in the empowerment certificate. The data relating to the described entity 302 may be supplied to the relying entity 304 by means of a second digital certificate referred to as a custom certificate. The custom certificate is signed with an electronic signature by a second signing entity, preferably the certificate authority 308.

Description

METHOD AND SYSTEM FOR SUPPLY OF DATA The invention relates to a method and system for supply of data. This invention also relates to a method for providing a digital signature and digital certificates. The field of the invention is public key cryptography.

Public key cryptography uses an asymmetric algorithm in which the encryption and decryption keys are different and for which it is infeasible to compute one key knowing only the other. Users receive (or, with suitable hardware or software, can generate for themselves) a pair of keys - that is, two large numbers. The user keeps one of these keys private and never discloses it. The other key can be safely made public, just like a phone number or similar personal data. Because of the nature of the algorithm and the way the keys are generated, information encrypted with the private key can only be decrypted with the public key and vice versa.

So the sender and receiver do not need to share any secret.

Public key cryptography enables several possibilities: * Anyone knowing the user's public key can send the user a message encrypted with that key and can be sure that only the user-who alone has the private key-can decrypt it. This provides confidentiality.

* The user might also encrypt a message with his private key. This cannot provide confidentiality, because anyone who knows the public key can decrypt it. But the fact that they can decrypt it means the message must have come from the user-who alone has the private key. This provides integrity and authentication and can also be used as a basis

for non-repudiation-the digital equivalent of a signature.

* If a sender signs a message with her own private key and then encrypts it with the recipient's public key, confidentiality, integrity, authentication and non-repudiation are provided together.

In practice, things are actually more complex. In the first example, for performance and operational reasons, the sender will choose a random symmetric session key and use a symmetric cipher to encrypt the message.

The public key will be used to encrypt just the session key. Similarly, in the second example, the user will first"digest"the message he wishes to sign, and encrypt the digest with his private key; the recipient will recompute the digest and compare its value with the value he decrypts from the user. A digest is a mathematical construct with a relatively short

fixed length, which is derived from an arbitrarily long message; it has the essential property that it is infeasible, knowing a message and a corresponding digest, to compute another message with the same digest.

All the processing is done by software ; the real human users do not really "do"any of this.

It is important to understand that public keys do not actually have to be published to the world. They can be shared as widely or narrowly as business and privacy requirements dictate.

In prior art public keys can be linked together to form a public key infrastructure-a PKI. The links are data structures (or data files) called certificates. Here is how it works: Alice may decide co register her public key (and identity information) with a Registration Authority (RA). (In this description of prior art, the usual names"Alice"and"Bob"are used to describe the roles of signatory and relying party, respectively.) Using the information collected by the RA, a Certificate Authority (CA) may then create a computer file containing Alice's public key together with information which identifies Alice and a validity period. The CA signs the file with its own private key, creating a certificate.

* A CA's public key may in its turn be certified by another CA ; and that CA's certificate will be certified by another and so on until eventually there is a root, that is, an unsigned (or self-signed) public key whose value has to be known some other way.

* So starting from a root it is possible to traverse a certificate chain to discover a public key value.

A set of public keys linked in this way form a public key infrastructure.

The simplest PKI has a single CA which acts as the root and which signs all the certificates. It is also possible to build a PKI in prior art using cross-certification instead of a hierarchy, but the end result is broadly the same.

Anybody with the right software can be an RA or a CA; whatever the legal or business constraints, there is no technical requirement for an authority to be authorised by anybody.

It is important to understand that the linking of a public key into a PKI does not affect what can be done with the matching private key. Some common misconceptions can be clarified as follows : * A certificate is"used"by a relying party, not by a holder of a private key. The relying party extracts from the certificate the public key to be used for encryption or signature checking.

* A certificate is not needed to create a digital signature or to decrypt a received message.

* A user does not need to be named in any certificate at all to check someone else's signature or to send them an encrypted message.

* Not even an Advanced Electronic Signature (as defined in the EU Electronic Signatures Directive) requires a certificate to exist in respect of the matching public key.

A typical method in which a PKI is implemented in prior art is as follows.

* As well as agreeing to look after her private key, Alice applies her ordinary handwritten signature to a paper application form which references"certificate policies"and"certificate practice statements".

* Alice then constructs and signs a PKCS#10 object which she sends to her RA. PKCS#10 is an industry standard data format.

* The RA checks the contents of the received object against what it knows about Alice and sends a certificate request to a CA.

'The CA signs, and sends to Alice, a certificate upon which any Bob in the world can rely. The certificate will probably have an expiry date a year or so in the future. Alice might have to remember to take action to renew the certificate when it expires, perhaps again using a handwritten signature for that purpose.

* When Alice digitally signs anything, her software sends the certificate to the relying party along with her signature block and the object that has been signed.

When Bob receives the transmission, he (that is, his software) first examines the certificate, and checks that it is within its period of validity. If he recognises the"issuer", and knows the issuer's public key, he can also check the signature on the certificate. If it computes, he can extract the public key from the certificate and check the signature on the data that was signed.

Except, of course, that he might not know the public key of the issuer.

He now needs a chain of certificates which link to a public key that he does know. Perhaps Alice sent him the chain, or perhaps he has to search public directories to assemble it himself. He may or may not have to pay a charge to access a directory. Bob needs to process the ! chain by checking that the issuer name in one certificate is the same as the subject name in the next, that all the signatures on all the certificates check out, and that the validity periods within the chain make sense relative to each other. There is a possibility, of course, that no chain can be constructed which includes both the original certificate and a certificate signed by any public key he knows implicitly.

* Except, of course, that the original certificate, or any of the certificates in the chain, may have been revoked. So Bob's software must now go in turn to an Internet address (URL-Uniform Resource Locator) included in each certificate, extract the most recent certificate revocation list (CRL) from that URL, and check that the serial number of the next certificate in the chain does not appear. He may or may not have to pay a charge for access to each CRL.

* As an alternative to the last three bullets, Bob can instead pass the certificate to a validation authority (VA) which will do much of the work for him, and return to him a signed go/no-go response on the validity of the original certificate. If validation services are sufficiently integrated, they may be able to succeed more often than Bob alone could. Use of a validation service will probably be chargeable.

* Bob archives the certificate of interest and either the rest of the chain and the CRLs or the signed validation response. To guard against later revocation of Alice's certificate, Bob would also do well to get from a timestamp authority a timestamp of the signature block on the signed data to prove that he had it in his possession before the revocation occurred.

Ever since the invention of public key cryptography, the vision has been held out of a universal infrastructure that would enable everyone in the world to verify with assurance the digital signatures of everyone else.

Electronic transactions exploiting this infrastructure would acquire the important properties of integrity and non-repudiation.

Achievement of the vision would empower individuals because they could digitally sign anything, anywhere, any time. And it would consequently deliver business competitiveness-a typical company, already participating in one e-marketplace as a buyer perhaps, could smoothly enter another, perhaps as a seller, with the same identity. This vision has the potential to alter the nature-and the economics-of the e-marketplace concept.

The whole world could develop rapidly into a single e-marketplace-an integrated e-economy.

The prior art does not easily enable subjects to participate in a public key infrastructure with an ability to sign anything, anywhere. Key-pairs in the prior art are generally seen as part of a"managed identity"rather than an extension of personality, independent of certification.

The prior art PKI is largely relevant only in a managed identity context in which a subject is related directly with a single affiliate and the identity only makes sense within that context. For example, an affiliation as an employee, as a customer of a bank, or as a vendor to a major corporation etc. Having acquired or generated a key-pair, the subject convinces a single business partner (a bank, for example, or an employer, or a major customer) of the binding of the subject's identity to its public key. Any particular individual would be likely to have multiple managed identities outstanding at any one time.

A further major problem with the prior art in delivering the universal infrastructure vision is that the CA's contract is typically with the subject and not with the relying party. There is a realisation among traditional CA businesses that the subject will be unwilling to pay the full cost-or perhaps any part of the cost-of"being issued with a certificate".

There is a furthermore a perverse liability issue which arises from the fact that the CA's contract is with Alice-the subject named in the certificate-and not with Bob-who relies on its correctness. In prior art PKI any per-certificate liability is unbounded, because whoever signed the certificate never gets to know who is relying on it until there is a problem. Alice can send the same certificate to a million Bobs and the CA will never know how much liability is building up. The"value"of a

certificate can be reused and reused without the CA (the source of that value) ever becoming aware.

Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures ("the Directive") defines a number of the terms used in the present document.

However, the definition of"certificate"is wider in the present document than in the Directive; the Directive's use of this word corresponds to the use in the present document of the term "verification certificate". The

term"digital signature"in the present document is a technique for implementing the Directive's notion of an advanced electronic signature" According to a first aspect of the present invention there is provided a method for supply of data relating to a described entity to a relying entity comprising: generating a first digital certificate signed with an electronic signature by a first signing entity and including: one or more attributes of the described entity ; one or more attributes of the first digital certificate which include one or more attributes identifying the first signing entity; an indication of data relating to the described entity which is to be supplied; an indication of one or more sources for the data to be supplied; and one or more attributes identifying one or more relying entities to which the data is to be supplied; the relying entity forwarding the first digital certificate for processing; a source supplying the data indicated in the first digital certificate.

The first digital certificate empowers the relying entity to gain access to the personal data of the described entity which may be held by a source in a data store and may be referred to in this document as an empowerment certificate. The described entity and the relying entity may be individuals, groups of individuals, individuals in a particular role, corporations, organisations, computer applications or systems, automated machines, etc.

Electronic signatures are defined in the Directive as data in electronic form which is attached to or logically associated with other electronic data and which serves as a method of authentication.

The first digital certificate may include any data which the relying entity has previously requested to be included such as a reference, nonce or other data.

A source can hold data or can refer to one or more data sources.

The first digital certificate may be sent with an object signed with a digital signature, but could also be sent on its own. The signing entity

of the first digital certificate may be the described entity such that the first digital certificate is a form of self-signed certificate. If an object signed with a digital signature is sent with the first digital certificate, the digital signature and the electronic signature in the first digital certificate may use different key pairs for signing.

The data relating to the described entity may include one or more public keys corresponding to private keys controlled by the described entity.

The data relating to the described entity may be supplied by means of a second digital certificate to the relying entity, the second digital certificate signed with an electronic signature by a second signing entity and including ; one or more attributes of a described entity including the data which is to be supplied; one or more attributes of the second digital certificate which include one or more attributes identifying the second signing entity; and one or more attributes identifying one or more relying entities to which the data is to be supplied.

The second digital certificate may be referred to in this document as a custom certificate. The first and second digital certificates may be in the format prescribed by international and industry standards for certificates with the electronic signature using public key cryptography.

The first and second digital certificates may include attributes which are sufficient to identify the described entity as well as the relying entity.

These may be a single attribute or a combination of more than one attribute. For example, a name may not be sufficient to identify uniquely an entity, whereas a combination of a name, a date of birth and an address will often uniquely identify the entity.

The first digital certificate may authorise the relying entity to use the first digital certificate to obtain a second digital certificate. The relying entity may be authorised to obtain a second digital certificate which is marked as qualified."Qualified certificates"are defined in the Directive.

The second digital certificate may include one or more attributes of the first digital certificate. At least some of the contents of the first digital certificate may be copied to the second digital certificate.

The method may include the relying entity forwarding the first digital certificate to an intermediate entity to obtain data from a source. The intermediate entity may provide a service for the relying entity and may provide insurance and take financial liability for the supply of the data

from the source. The intermediate entity may generate the second digital certificate.

The second digital certificate may include one or more attributes identifying the relying entity which are different from the one or more attributes identifying the relying entity included in the first digital certificate.

The second digital certificate may include one or more attributes identifying the described entity which are different from the one or more attributes identifying the described entity included in the first digital certificate.

The described entity may generate a digital signature using a private key with a corresponding public key and the first signing entity may include the digital signature or a cryptographic digest thereof in the first digital certificate and the data to be supplied to the relying entity may include the public key. A cryptographic digest may be obtained using a hash function. Once the indicated data, including the public key, is received by the relying entity from the source, the digital signature can be verified.

The first digital certificate and the second digital certificate may include a period of validity. The period of validity of the first digital certificate or the second digital certificate may be that short period of time during which a digital signature was generated. For example, this may be 1 or 2 seconds. A digital certificate can be generated with a validity period which begins prior to the generation of the digital certificate.

The period of validity may be in the past, prior to the generation of the digital certificate, or in the future or for a period spanning the past and the future.

The data indicated in the first digital certificate may include confirmation of a payment or a debt due from the described entity identified in the first digital certificate to the relying entity identified in the first digital certificate. A second signing entity may indicate in a second digital certificate a guarantee of a debt indicated as due in a first digital certificate.

A change in previously supplied data may be indicated by the supply of a list identifying a second digital certificate relating to the previously supplied data. A list may identify a first or second digital certificate specifying data which is no longer authorised to be supplied to the relying entity. The generation of the list may include one or more attributes

identifying relying entities to which the list relates. The list may be a certificate revocation list.

The method may include generating and storing a list for the second digital certificates, which is indexed by one or more attributes identifying relying entities such that all second digital certificates in the list relevant to a relying entity can be identified.

According to a second aspect of the present invention there is provided a system for supply of data relating to a described entity to a relying entity, the system comprising: a first signing entity application, a relying entity application and a data store wherein the data store holds data relating to the described entity; the first signing entity application has means for generating a first digital certificate signed with an electronic signature by the first signing entity application and including: one or more attributes of the described entity; one or more attributes of the first digital certificate which include one or more attributes identifying the first signing entity; an indication of data relating to the described entity which is to be supplied; an indication of one or more sources for the data to be supplied; and one or more attributes identifying one or more relying entities to which the data is to be supplied; the relying entity application has means for forwarding the first digital certificate for processing; and means for supplying the data indicated in the first digital certificate from the data store.

The system may be provided using a secure messaging system across a network, for example the Internet. The described entity and the relying entity may use software applications to generate and sign messages and certificates. The data to be supplied may be held in a data store by a source and the data store may be an electronic database. A source may hold the data store or may refer to one or more further sources. The first signing entity may be the described entity. The system may include more than one data store holding data relating to the described entity.

A second digital certificate may be provided for supplying the data relating to the described entity to the relying entity application, the second digital certificate signed with an electronic signature by a second signing entity application and including: one or more attributes of the described entity including the data which is to be supplied; one or more attributes of the second digital certificate which include one or more

attributes identifying the second signing entity; and one or more attributes identifying one or more relying entities to which the data is to be supplied.

The first digital certificate may authorise the relying entity to use the first digital certificate to obtain a second digital certificate. The relying entity may be authorised to obtain a second digital certificate which is marked as qualified. The second digital certificate may include one or more attributes of the first digital certificate. At least some of the contents of the first digital certificate may be copied to the second digital certificate.

The system may include an intermediate entity application to which the relying entity application forwards the digital certificate to obtain data from the data store. The intermediate entity may use a software application to act between the relying entity and a source. An intermediate entity application may generate the second digital

certificate.

The first digital certificate and the second digital certificate may include a period of validity. The period of validity of the first digital certificate or the second digital certificate may be that short period of time during which a digital signature was generated. A digital certificate can be generated with a validity period which begins prior to the generation of the digital certificate. The period of validity may be in

the past, prior to the generation of the digital certificate, or in the future or for a period spanning the past and the future.

A change in previously supplied data may be indicated by the supply of a list identifying a second digital certificate relating to the previously supplied data. A list may identify a first or second digital certificate specifying data which is no longer authorised to be supplied to the relying entity. The generation of the list may include one or more attributes identifying relying entities to which the list relates. The list may be a certificate revocation list.

The data store may have a means of determining for an item of data included in the data store information concerning or contained in a first digital certificate which has referenced that item, or information concerning or contained in a second digital certificate which provides the value of that item. The certificate lists just described may be generated through this means.

The intermediate entity application may include a storage means for storing second digital certificates referenced by the relying entities identified in the second digital certificates.

The system may include a proxy entity application to which the relying entity application or the intermediate entity application may forward the first digital certificate to obtain information specifying to which data store or other proxy entity application the first certificate should next be forwarded.

According to a third aspect of the present invention there is provided a computer program product stored on a computer readable storage medium, comprising computer readable program code means for performing the steps of: generating a digital certificate signed with an electronic signature by a signing entity and including: one or more attributes of a described entity; one or more attributes of the digital certificate which include one or more attributes identifying the signing entity; either an indication of data relating to the described entity which is to be supplied and an indication of one or more sources or the data itself; and one or more

attributes identifying one or more relying entities to which the data is to be supplied.

A computer program product may be provided with one or more of the features of the first and second aspects of the present invention.

According to a fourth aspect of the present invention there is provided a digital certificate signed with an electronic signature by a signing entity and comprising: one or more attributes of a described entity; one or more attributes of the digital certificate which include one or more attributes identifying the signing entity; either an indication of data relating to the described entity which is to be supplied and an indication of one or more sources or the data itself; and one or more attributes identifying one or more relying entities, wherein the relying entities are entities to which the data relating to the described entity is to be supplied.

The digital certificate identifying the relying entity may be authorising the relying entity to obtain the indicated data relating to the described entity or may be supplying the data itself to the relying entity.

The digital certificate may be provided with one or more of the features of the first and second aspects of the present invention.

According to a fifth aspect of the present invention there is provided a method of providing a digital signature based on a digital certificate comprising: generating a digital signature using a private key corresponding to a public key, the signed data including: one or more attributes identifying a digital certificate to be generated; generating a digital certificate signed with an electronic signature by a signing entity and including: one or more attributes of a described entity which are sufficient to obtain the public key; one or more attributes of the digital certificate which include one or more attributes identifying the signing entity; and an indicated period of validity of the digital certificate which begins earlier than the time of generation of the digital certificate; wherein the digital certificate is generated after the generation of the digital signature.

An object may be signed with a digital signature which forward references a digital certificate which has not yet been generated and then a digital certificate may be generated which references back to the digital signature and has a period of validity which includes the time of the generation of the digital signature.

More than one digital signature may be generated which identifies the same digital certificate. The signing entity may be the described entity.

The period of validity of the digital certificate may be that short period in which the digital signature was generated.

The one or more attributes identifying the digital certificate to be generated given in the digital signature may include a serial number. The lowest available serial number which can be used for the next digital certificate to be generated or the last used serial number using each private key may be recorded.

According to a sixth aspect of the present invention there is provided a system for providing a digital signature based on a digital certificate, the system comprising: a described entity application with means for generating a digital signature using a private key corresponding to a public key, the signed data including: one or more attributes identifying a digital certificate to be generated; a signing entity application having means for generating a digital certificate with an electronic signature and including: one or more attributes of a described entity which are sufficient to obtain the public key; one or more attributes of the digital certificate which include one or more attributes identifying the signing entity; and an indicated period of validity of the digital certificate which begins earlier than the time of generation of the digital certificate; wherein the digital certificate is generated after the generation of the digital signature.

A system may be provided with one or more of the features of the fifth aspect of the present invention.

According to a seventh aspect of the present invention there is provided a computer program product stored on a computer readable storage medium, comprising computer readable program code means for performing the steps of : generating a digital signature using a private key corresponding to a public key, the signed data including: one or more attributes identifying a digital certificate to be generated; generating a digital certificate signed with an electronic signature by a signing entity and including: one or more attributes of a described entity which are sufficient to obtain the public key; one or more attributes of the digital certificate which include one or more attributes identifying the signing entity ; and an indicated period of validity of the digital certificate which begins earlier than the time of generation of the digital certificate; wherein the digital certificate is generated after the generation of the digital signature.

A computer program product may be provided with one or more of the features of the fifth aspect of the present invention.

According to a eighth aspect of the present invention there is provided a digital certificate signed with an electronic signature by a signing entity and comprising: one or more attributes of a described entity; one or more attributes of the digital certificate which include one or more attributes identifying the signing entity; and an indicated period of validity of the digital certificate which begins earlier than the time of generation of the digital certificate.

The indicated period of validity of the digital certificate may end no later than the time of generation of the digital certificate such that the period of validity of the digital certificate is all in the past.

Alternatively, the period of validity may extend from the past to a future time.

The described entity may be the signing entity such that the digital signature is a form of self-signed certificate. The electronic signature may use public key cryptography. The digital certificate may include a time stamp indicating the time of generation.

According to a ninth aspect of the present invention there is provided a digital signature using a private key corresponding to the public key derived from a digital certificate as defined in the eighth aspect of the present invention, wherein the digital certificate is generated after the generation of the digital signature, the signed data including: one or more attributes identifying the digital certificate to be generated.

The proposed"empowerment infrastructure"which can be implemented through the invention describes a public key infrastructure (PKI) in the sense that it provides for a relying party to establish the value of a public key matching the private key held by an identified subject, and in the sense that it extends the prior art constructs of PKI, including certificates and certificate revocation lists (CRLs) signed by certificate authorities (CAs). The invention itself relies on public key cryptography, but fundamentally challenges the conventional wisdom about the role of keys and certificates in a workable PKI model.

The empowerment approach that the invention enables goes well beyond the possibilities of PKI prior art to allow a wide range of personal data items - not just public keys-to be certified within a privacy enhancing framework that empowers the subject to control who can access his personal data, and how and when. The invention enables a method of delivering, not

just public keys, but any piece of assured personal data. In other words, an architecture for an e-marketplace which brings together the buyers and sellers of personal data. The brokers of this marketplace are the data subjects themselves; no personal data moves in the empowerment infrastructure except with the explicit authorisation of the subject to whom that data relates.

The invention also provides a payments mechanism integrated into the personal data framework. Imagine the sale, empowered by Alice, of a piece of personal data of the form"Alice is indeed able to pay you the sum of 100". Usually, when personal data is sold, the database from which it is derived is not altered. But this case has to be an exception, and some database attribute, controlled by the seller of Alice's personal information, has to be altered by exactly-or, where commission or interest are involved, approximately-one hundred. It now just takes a small leap of imagination to see a payment as simply a piece of personal data that changes when it is sold. So the invention also permits a secure payments architecture. By extension, it is also possible to use the infrastructure to confirm a debt due from the signatory to the relying party, and even to indicate a guarantee for such a debt.

Embodiments of the invention are now described, by means of examples only, with reference to the accompanying drawings in which: Figure 1 is a diagram of a system of delivery of data of the prior art; Figure 2 is a flow diagram of the system of Figure 1; Figure 3 is a diagram of a system of delivery of data in accordance with the present invention; Figure 4 is a flow diagram of the overall system of Figure 3; Figure 5 is a diagrammatic representation of part of the system in accordance with the present invention; Figure 6 is a flow diagram of part of the system of Figure 3; and Figure 7 is a diagram of a system in accordance with the present invention.

Referring to Figure 1, the traditional system of delivery of a data object in the form of a certificate as known from the prior art is shown. Figure

1 shows a first user of the system, Alice 102, and a second user, Bob 104.

There are also provided a registration authority (RA) 106, a certification authority (CA) 108 and a validation authority (VA) 110.

In the prior art system, the data object to be delivered is a certificate for use in public key cryptography. In public key cryptography, a public key certificate associates a public key value with the certificate's subject. The certificate's subject is a particular person, role, device or other entity that controls the corresponding private key.

A public key certificate is digitally signed by a person or entity called a

certification authorlty.

A registration authority (RA) traditionally manages interactions between a certification authority (CA) and its subscribers or certificate applicants.

There may be multiple RAs for a CA. The issuance of a certificate may involve a personal presence for verifying the applicant's identity through presentation of identifying documents. The RA does not itself issue the certificates but may validate, approve or reject certificate applications.

In prior art, the method of delivering a certificate starts with Alice's self-signed token (PKCS#10) 112. PKCS#10 defines a format for a message to request the issuance of a certificate from a CA. The PKCS#10 token 112 allows the requesting entity, Alice 102, to supply her public key and other values requested for inclusion in the certificate. Alice 102 sends the token 112 to the RA 106, which converts it to a certificate request 114.

The certificate request is sent by the RA to the CA 108. The CA 108 converts it to a certificate 116 which it sends to Alice 102. Alice 102 sends the certificate 116 unchanged to Bob 104. Bob then sends the certificate unchanged to a validation authority (VA) 110, which converts it to a validation response 118 to Bob 104. Figure 1 shows the order of these actions in numbers given in parentheses.

Figure 2 shows a flow diagram of the traditional system 200 of the prior art described above. Alice creates a self-signed token in the first step 201 and sends this 202 to an RA. The RA converts the token to a certificate request 203 and sends 204 the certificate request to a CA. The CA converts the certificate request to a certificate 205 and sends 206 the certificate to Alice. Alice sends 207 the certificate to Bob. Bob need to have the certificate validated so he sends the certificate to a VA 208.

The VA converts 209 the certificate to a validation response either confirming or denying that the certificate is valid. The validation response is sent by the VA to Bob 210.

In a described embodiment of the present invention, a method and system are referred to as an empowerment method or system. This system is shown in Figure 3 using the same structure as Figure 1 for comparison purposes.

The embodiment is described in terms of delivery of a certificate for use in public key cryptography; however, as will become evident, the present invention is not restricted to the delivery of certificates only for this particular use. Alice 302 is a described entity and Bob 304 is a relying entity.

Referring to Figure 3, Alice 302 has previously registered 320 with an RA 306 and the RA 306 has information about Alice 302. Alice 302 sends a self-signed token 312 to Bob 304. Bob 304 sends the token 312 unchanged to a CA 308. The CA 308 converts the token to a request 314 to one (or more) RAs 306. The RA 306 converts the request to a response 316 to the CA 308.

The CA 308 converts it to a pre-validated certificate 318 which it sends to Bob 304. As the certificate is pre-validated, Bob 304 does not need the explicit services of a VA to validate the certificate. The functions of the VA 310 are combined with the CA 308. Figure 3 shows the order of these actions by numbers in parentheses.

The method 400 of the described embodiment is shown in a flow diagram in Figure 4. In the first step 401 Alice creates a self-signed token. Alice sends 402 the token to Bob. Bob sends 403 the token to a CA. The CA converts 404 the token to a data request and sends 405 the request to a RA. The RA converts 406 the request to a response and sends 407 the response to the CA. The CA converts 408 the response to a pre-validated certificate and sends 409 the pre-validated certificate to Bob.

The traditional system of the prior art and the described embodiment of the system both execute three conversions. Both systems start with Alice self-signing a token and end with Bob possessing a validated certificate naming Alice as subject. But the Alice-to-Bob portion is the first of five steps in the empowerment system of the described embodiment and the fourth of six steps in the traditional system.

This difference of sequence turns out to have far-reaching consequences.

In the empowerment system 300, Alice 302 can choose at the granularity of each transaction which of her identities (as employee, taxpayer, bank customer, pseudonym,...) to assert and which of her attributes (items of personal data) to empower her RA 306-or RAs-to disclose. Since Bob 304 is now in the customer role with the CA 308, the certificate policy reflects what he is willing to pay, enabling an improved PKI business model in which liabilities are understood and controlled. Because there is no requirement for a certificate to exist before Alice makes her first ever

signature, she can sign her RA agreement digitally rather than in handwritten form.

The empowerment system 300 shifts mindset away from the notion of a certificate as part of a managed identity towards a mechanism through which a data subject (Alice 302) empowers an RA to reveal validated personal data to a relying party (Bob 304). A public key value becomes just another piece of validated personal data delivered through this process.

The empowerment system of the described embodiment is now considered in more detail.

THE DATABASE The described embodiment of the empowerment system assumes that personal data is held in databases at one or more sources. (The term database is taken to include directories.) Databases model what is going on in the real world. A change in a database reflects a change in the real world.

The embodiment only applies to those database entries which identify the subject-that is, where there is sufficient information in the entry to distinguish the subject from all other subjects in that database. There is no requirement that databases must be digital-hardcopy databases are included.

Generally, there can be expected to be more than one way to identify a subject. The following is an imagined extract from Alice Earthling's entry in the personnel database of her employer Acme SA: Name Alice Earthling Date of birth 19631117 Home address 65 Southview Road Employee number 65193

Alice's unique number at the Internal Revenue Service (Acme hold this information to pay withholding tax) DF456781A Alice's banker Rutland Bank Alice's bank account number (Acme hold this information in order to pay Alice each month) 01081208 Alice's work e-mail address alice. earthling@acme. com Alice's home e-mail address Alice@earthling. name Alice's work phone number +99 12 3000 3274 Alice's cellphone number +99 73 0578 2407 Alice's home phone number +99 13 2553 8109 Alice's registered domain name alice. earthling. name The value of the public key matching the private key under Alice's control 956DF57E4...

A JPEG file containing a full face photograph of Alice AD53827D5C88E575EAB6678...

A TIFF file containing a digitised image of Alice's handwritten signature FE4368AB543C55FDE653FB6...

A pseudonym 756384928475 Alice's salary 60,500 Alice's external purchasing limit at Acme 100,000 The data in the database entry for Alice Earthling includes attributes which provide identification, authentication, location and authorisation.

Note that a pseudonym is permitted as an identifier.

As the Alice/Acme example includes several data items, it is possible to take several views of the entry, each with a different identifier. So for each view there is a primary identifier and a predicate. The predicate contains all the attributes of the entry except those in the primary identifier which characterise the view. It might be necessary to use a combination of attributes (for example, bank and account number) to construct a single primary identifier, or a single attribute (for example, personnel number) might suffice. In the example, Alice's salary will always be part of the predicate. Her work e-mail address will be part of the predicate in all views except one, namely the view which has her work e-mail address as the primary identifier.

Note that the possibility of the public key value being a primary identifier is allowed for-making the practical assumption that the same key pair will never be generated twice.

This description is for the general case. The system also allows for the simpler case of an entry which has only one possible view because it has only one attribute or set of attributes that could be a primary identifier.

Databases of the form just described already exist pervasively throughout the world in government departments and agencies, large corporations and most other sorts of organisation.

THE CERTIFICATE One way of storing data about individuals is in the form of certificates.

In the described embodiment, in respect of individuals, a certificate can be seen as a digitally signed extract of an entry in a database. This can

be extended further to include certificates relating to entities that are not individuals. In the described system, certificates are the mechanism through which entries become visible outside the organisation operating each database.

A certificate in the described embodiment must contain information from a single view of a single entry. As will be described later, it may also contain other information. This is a crucial difference between a certificate and a database entry. A database entry sits there with all views equally possible. In a certificate, the identifier is committed to a single view.

A certificate must contain the full primary identifier relating to the selected view. The identifier in a certificate is called the"distinguished name". A certificate may also contain information from the predicate of the selected view, either the whole predicate or any sensible subset of it.

There little value in a certificate that contains only a distinguished name.

In particular, the predicate information may contain authenticators (including, public key values), locators, authorisers and non-primary identifiers.

Where one or more non-primary identifiers are included, they may be useful as a redundancy checking mechanism. For example, in a certificate which has a bank account number as the primary identifier, one or more of the other identifiers (common name, say) can be used by the bank to double-check against mis-identification.

A traditional certificate known from the prior art identifies a subject or described entity but does not identify any particular relying party or entity. A relying entity is a user of a certificate, that is, someone who relies on the accuracy of the contents of the certificate.

The model's taxonomy then develops as follows: * A certificate containing as authenticator a public key which matches a private key used for creating digital signatures is classed as a verification certificate.

'Verification certificates are either issued to the public, or not, and either qualified or not. The difference is important because the European Union Electronic Signatures Directive treats each class differently.

'The model assigns certificates to one of three further classes.

The classes are traditional, empowerment and custom. Further information on these classes appear later, but in summary: * A traditional certificate identifies a subject but does not identify any particular relying party A relying party is a user of a certificate, that is, someone who relies on the accuracy of the contents of the certificate. This class of certificate is found extensively in prior art.

* A custom certificate identifies both a relying party and a subject, and the entity who signs the certificate is not the subject of the certificate.

* An empowerment certificate identifies both a relying party and a subject, and is signed by the subject.

Empowerment and custom certificates are either instantaneous or long term.

(Traditional certificates are always long term.) The period of validity of an instantaneous certificate is short enough to practically prevent more than one signature being created in that time with the same private key.

It is possible to create many such signatures with the same private key during the period of validity of a long term certificate.

In the model all empowerment and custom verification certificates are classed as issued to the public. In the model custom certificates can be either qualified or unqualified while empowerment certificates can never be qualified.

THE REGISTRATION AUTHORITY The traditional notion of a registration authority (RA) persists in the described system in the form of sources for data to be supplied. In the embodiment, the registration authority for a given subject is defined as: * The controller of a database... who has agreed with the subject to become an RA in respect of the subject...

* and includes in its database entry for the subject the value of the subject's public verification key.

In respect of a given subject, an RA is either a direct RA (DRA) or an indirect RA (IRA). The difference is as follows: 'A direct RA holds the value of the subject's public key as primary data, updating it in accordance with events in the real world. To achieve this, a DRA probably has some sort of contract with the subject to cover notification in the case of loss or compromise of the corresponding private key.

'An indirect RA has cached a longterm custom certificate which contains the value of the public key, and has access to a current certificate revocation list (CRL) which enables the continuing validity of such a certificate to be checked. (CRLs are explained further below.) The same organisation might be a DRA in respect of one subject and an IRA in respect of another.

No subject can have an IRA without also having at least one DRA, although it is possible for a subject to have a DRA and no IRAs. This is because there must be somewhere in the infrastructure where the public key value is bootstrapped. Unless a subject had a DRA in the first place, there could be no longterm custom certificates for any IRA to cache. If a subject stopped having a relationship with its last DRA, then it is likely that all the relevant longterm custom certificates would very soon appear in the CRLs which the IRAs check, so very quickly the subject would cease to have any IRA relationships either.

There is nothing in the described system which prevents a subject having more than one DRA-either because the subject has more than one key pair or because one or more key pairs are tracked by one or more DRAs.

The mechanism through which the DRA is sure of the subject's public key value is outside the description given here and is not part of the invention. There are however plenty of examples in prior art of how this relationship can be implemented. In fact, any RA-DRA or IRA-has to have some method of establishing the value of all the data items it holds "for real"on each subject, not just the public key. Again, there is a mass of existing prior art in this area. ("For real" means "not in a certificate signed by somebody else".)

The correct operation of this unspecified mechanism is axiomatic to the whole model. Everything that happens elsewhere in the model depends on this part being done correctly.

Figure 5 shows a representation of the RA 500 of the described system. The RA holds a database 504. 506, 507,508, 509 are single views of the database. Each view 506,507, 508,509 has a distinguished name 510,512, 513,514 for that view which is the primary identifier. The views 506, 507,508, 509 can also include attributes from the predicate of the selected view of the database, including public key values, locators, authorisers, etc.

In the described system, RAs have the following capabilities.

An RA (of either class), in its role as a database controller, can maintain and process the data it holds on each subject for whatever reason it lS, apart from being an RA, that it holds that data. So, for example, the personnel department of Alice Earthling's employer Acme will continue to process the monthly payroll against the employee database.

An RA (of either class) can receive and process entry updates digitally signed by the subject. The RA knows the subject's public key (either because, as a DRA, it is tracking it or, as an IRA, because it can validate the cached certificate against the CRL), so it is always able to check the signature.

Importantly, an RA can send a message to a certificate authority (CA) which can result in the CA signing or revoking a digital certificate.

The described system predicts that many organisations-and perhaps most organisations within the public sector-will become RAs. In such cases, being an RA will be incidental to being something else. There is no specific requirement in the system for organisations whose whole business mission is that of an RA, although such organisations are obviously possible.

THE SIGNING DEVICE The model abstracts a digital signature to the operation of a finite state machine called a signing device. The signing device has access to a source of local time which corresponds to the usual standards notion of GeneralizedTime and which increments with a granularity of one second. The state of the machine is defined by:

* the value of a key pair, which can change from time to time; * the value of an empowerment certificate serial number, which is an integer that increases before or after each signature operation; and (optionally) by a set of values that enable intelligent guesses to be made of data to be included in an empowerment certificate.

How the machine and its state are implemented is not defined in the model and are not part of the invention, but it may prove helpful to think of a smart card or a wireless device. There are minor privacy advantages in incrementing the serial number by amounts other than unity to obfuscate the rate at which Alice is effecting signing operations.

A signing operation might proceed as follows:

* The device takes the value of the local time.

* The device increments the empowerment certificate (EC) serial number.

* For each of zero or more objects to be signed in turn it displays each object to Alice, and receives from her a decision whether or not to sign.

For each object that Alice wants to sign, if any, the device computes a signature block over a data structure consisting of: * the object to be signed; * a reference, by serial number and the hash of Alice's public key value, to the EC about to be created; and * possibly other information.

* The device then displays an EC confirmation screen with intelligent guesses of the values to be included in the EC, together with the EC serial number. These intelligent guesses are computed from information provided externally to the device when it was invoked, and from the internally-held optional values.

* The device builds the EC from the information Alice provided (or accepted from the intelligent guesses) and from the signature blocks of the signed objects. The period of validity of the EC is set no begin at the time taken at the start of the operation (in the first bullet above), and ends one second after the GeneralizedTime recorded at the end of the operation, or, with Alice's approval, a longer period. The device appends Alice's signature to the EC.

THE EMPOWERMENT CERTIFICATE As an alternative to certificates described in prior art, the described system provides for Alice's software to send Bob an empowerment certificate. This alternative mechanism has a number of unique advantages that mean that Alice does not need to be"issued"with a traditional certificate (or, indeed, any digital certificate at all).

Although Alice has not been"issued"with a certificate, her software still transmits a certificate with every object she signs, but it is always a certificate that her software has built for her and that she herself signs immediately after signing the object to be signed. The whole transaction can sometimes be completely encapsulated in the self-signed certificate alone, making the signing of an associated object unnecessary. The described system calls these special self-signed certificates"empowerment certificates".

Empowerment certificates can be seen as a mechanism by which a user empowers others to gain access to their personal data, including their public key which can be considered to be an ordinary piece of personal data.

The generation of an empowerment certificate includes the following steps.

The objects to be signed, if any, are signed first, with a forward reference to the empowerment certificate about to be created included in the data to be signed. The empowerment certificate is then created and signed, with a backward reference to the signature blocks of the signed objects (if any).

The following information is contained in an empowerment certificate: - 1 A distinguished name that Alice asserts as"issuer".

- 2 The same distinguished name as subject.

. 3 The distinguished name of the relying party.

. 4 The distinguished name of an RA who can resolve Alice's distinguished name to a public key value (or to one or more such values).

- 5 A period of validity beginning one second before the time taken at the start of the signing operation and ending no earlier than two seconds after that time.

- 6 (Optionally) a set of attribute definitions.

- 7 For each attribute definition, either an asserted value or the distinguished name of an RA who holds that attribute value for the subject.

- 8 (Optionally) the distinguished name of an RA who holds the particular attribute that is the subject's public key value.

. 9 (If any) the signature block (s) over the previously signed object (s).

. 10 (If any) a random nonce or other information provided by the relying party. A nonce is typically a large number whose value until it is generated is unpredictable.

- 11 (Optionally) the subject's public key or one of the subject's public keys, or a reference to such a key.

- 12 (Optionally) policy information. Alice might include a statement of the purposes for which she agrees that the personal information asserted or referenced in the empowerment certificate may be used, or the purposes for which she states that it may not be used. She may also indicate her approval for the later generation of a custom qualified certificate using the EC.

- 13The subject's signature over all the above. There are circumstances (basically, those circumstances in which the signature on the empowerment certificate will never be verified) in which the signature can be omitted, but these circumstances are not discussed further.

Optionally, the model allows for the possibility that one or more of the RAs which hold the data to be provided are referenced indirectly in the empowerment certificate rather than by distinguished name. The EC might identify a proxy service which knows which RA is to be used for each attribute. There is clearly no limit to the amount of such indirection (one proxy pointing to another proxy, and so on) which might in principle be implemented.

On receiving the empowerment certificate and any signed object (s) from Alice, Bob has four options:

1. Bob may just simply believe what Alice has asserted, not even bothering to check the signature on the empowerment certificate.

At its simplest. the described system acts as a method of transmitting unauthenticated personal data. If Bob is a government agency and Alice wants to be malled an information leaflet, then it does not much matter if she is lying about her name and home address. This simple use of the empowerment certificate can also deliver the same sort of benefits as browser cookies.

More usually, if there is an accompanying signed object, Bob may not bother to check the signature on the empowerment certificate if he has an longterm custom certificate cached which contains Alice's public key. He will simply pull Alice's distinguished name from the empowerment certificate, find the relevant longterm custom certificate and extract her public key from there to check the signature on the signed object.

2. Alternatively, Bob may check the signature using an asserted value of the public key and just simply believe the rest of the asserted information (if any) if the signature checks out.

This is of some use because, if Bob caches empowerment certificates, it can provide a session mechanism in applications where key revocation is not important. That is, Bob will associate Alice's first visit to his website with her second and subsequent visits, without necessarily getting to know for sure any of Alice's personal data except her public key value. Bob can prevent replay attacks by supplying a nonce for each visit or by checking for increasing empowerment certificate serial numbers. If Alice asserts some other identifier (even a pseudonym) on any visit, then she need not assert her public key on subsequent visits. This mechanism cannot, however, recover from compromise of Alice's signing device, or from Alice rolling over her key. In the first case, someone else can take over the"session" ; in the second case the session ends without the possibility of any in-band explanation to Bob.

Despite its limitations, this mechanism has considerable advantages compared to password-based website logon schemes.

3. Another possibility is that Bob checks the signature on the empowerment certificate using a public key value for Alice that he has cached on a longterm custom certificate or knows in some other way (because he is her DRA, for example).

This provides a method of authentication that can cope with revocation.

Once again, Bob can use a nonce or a serial number check to guard against replays. Bob may also be happy to believe without further assurance the asserted information (if any) in the empowerment certificate that differs from what he already has cached or otherwise knew.

This use of empowerment certificates provides a method for subjects to inform RAs of changes they need to make to their databases. Archive of the empowerment certificate provides an audit record signed by the subject.

4. Most importantly of all, Bob can use the empowerment infrastructure to convert a properly-signed empowerment certificate into a custom certificate (or, indeed, more than one custom certificate). This is a crucial part of the described system and is explained next. If Bob takes this route, it is prudent for him to check that Alice has correctly copied the object signature block (if any) to the empowerment certificate.

THE CUSTOM CERTIFICATE Just as Alice has a contract with one or more RAs, so Bob, if he wants to convert an empowerment certificate into a custom certificate, needs to have a contract with one or more CAs. The process is straightforward. At any time before the expiry of the empowerment certificate (or as soon as possible after the expiry of an instantaneous empowerment certificate), and as many times as he likes, Bob sends to a CA an empowerment certificate which he has received and the CA signs and returns an equivalent custom certificate, customised to Bob's requirements. There are no restrictions in the system on Bob's choice of CA, or on how many times (provided, in the case of an instantaneous empowerment certificate that he is quick), or to how many different CAs he sends the same empowerment certificate.

What the CA is doing is executing Alice's mandate, given when she created the empowerment certificate, for certain of her personal data to be shared with Bob. Her public key a piece of personal data which may be shared in this way.

The following describes the method steps. If anything goes wrong, the process ends and Bob's request is rejected with a reason code.

The CA generates the serial number of the custom certificate being prepared and copies the empowerment certificate serial number, the hash of the empowerment certificate, the object signature blocks (if any) and the nonce (if any) as attributes in the custom certificate. The CA copies its own distinguished name into the issuer field along with a timestamp

For a longterm empowerment certificate, the CA checks that the period of validity of the empowerment certificate will not have expired before the time likely to assemble and sign a custom certificate. For an instantaneous empowerment certificate, the CA checks that only a reasonable period of time has passed since the empowerment certificate was signed.

"Reasonable" means that Alice's personal data is highly unlikely to have changed since she signed the empowerment certificate.

For both longterm empowerment certificates and instantaneous empowerment certificates (for which the reasonable period has not passed), the CA will set the validity period start time of the custom certificate the same as the start time of the empowerment certificate. Otherwise (and this will clearly apply to longterm custom certificates only), the validity period start time will be set to the time by the CAs clock. As an option, to support store-and-forward transactions, it may be useful for the start time to be set to a significantly earlier time.

The custom certificate validity period end time will be set to the empowerment certificate validity period end time, or to an earlier time that Bob specifies.

The CA checks that Bob is named as relying party in the empowerment certificate and names Bob as the relying party in the custom certificate.

Within defined rules, certain changes to the presentation of Bob's name is permitted. (The analogy here is the flexibility with which banks match payee names on cheques to accountholder names.) The CA checks that the empowerment certificates subject name and"issuer" name are identical and copies the value into the subject field of the custom certificate. Again, within defined rules, changes to Alice's name are permitted.

The CA ignores (that is, treats as if they were not present) any attribute in the empowerment certificate that has been asserted rather than referenced to an RA. Asserted attribute values in empowerment certificates have benefit in the part of the communication between Alice and Bob not involving a CA. Asserted public key values do have one use within the infrastructure. which is explained below.

The CA then presents the empowerment certificate to the RA identified in the empowerment certificate as able to resolve Alice's distinguished name into her public key. If this is a longterm empowerment certificate, the RA will first check to see if Alice has revoked it. How the RA does that is explained later. (The instantaneous or longterm status of the custom

certificate is irrelevant. ) In any case, the RA checks the validity period of the empowerment certificate.

The RA consults its database, extracts the value of the public key and checks the empowerment certificate. If it knows of more than one public key for Alice it will try each in turn, guided by hints she has included in the empowerment certificate (for example, asserting the value of, or the value of the hash of, a public key), until the signature on the empowerment certificate checks out.

For a longterm custom certificates only, the RA adds, to each of the attributes that compose the distinguished name, a label of the following form ("DN flag", CA's distinguished name, custom certificate serial number, expiry date). No label is added for an instantaneous custom certificate.

(The instantaneous or longterm status of the empowerment certificate is irrelevant for this decision.) The RA examines the empowerment certificate to see if it is named as the RA for any of the predicate attributes, including the public key. It pulls out of its database any values that Alice has empowered. For a longterm custom certificate only, the RA adds to each attribute a label of the form ("att flag", CA's distinguished name, custom certificate serial number, expiry date). No label is added for an instantaneous custom certificate.

(The instantaneous or longterm status of the empowerment certificate is irrelevant for this decision.) For longterm custom certificates, the RA caches the empowerment certificate, and records the mapping of empowerment certificate and custom certificate serial numbers, expiry dates and"issuers".

The RA sends the following information back to the CA: - 14Alice's public key value.

. 15The values of any predicate attributes for which it is responsible.

If a public key value is included among the predicate attributes and Alice has more than one public key, the RA will choose one on the basis of the public key value or hash value that Alice asserted. This may or may not be the same value as the public key value returned above, because Alice might approve with a signature using one private key the creation of a custom certificate containing the public key corresponding to another of her private keys.

The CA is now able to check the signature on the empowerment certificate, and does so If there are any more RAs to be consulted, the CA sends out the empowerment certificate in parallel to them, along with the first public key value returned by the first RA. The RAs check the empowerment certificate, including again its expiry and revocation status, use the distinguished name in the empowerment certificate, or the public key value, to identify the subject, and return the values. As before, for longterm custom certificates they label"att flag"attributes, cache the empowerment certificate and map the empowerment certificate to the custom certificate.

Note that the public key to be included in a public key custom certificate may be provided by an RA other than the RA who initially resolved Alice's distinguished name into her public key.

With all the attribute information back, the CA now marks the certificate to indicate the certificate policy that Bob has requested. In particular, if Bob has asked for a qualified certificate, and the CA is happy that this is possible, the CA marks the certificate as qualified, with a liability limitation the lower of what Bob has requested and what the CA is willing to offer. The policy Alice set in the EC will also constrain whether or not a custom qualified certificate can be generated.

To get the policy and liability he wants, Bob can even submit the empowerment certificate independently to two or more CAs, or to the same CA multiple times, playing off the weakness in one policy with the strength of another, to use one custom certificate to reinforce another, or to spread a qualified certificate liability over two or more CAs.

There is one important constraint on the policy that the CA defines in the custom certificate. Any personal data policy limitations that Alice defined in the original empowerment certificate are carried forward into the custom certificate.

Finally, the CA informs the RA who resolved Alice's distinguished name into her public key the fact of transfer to Bob of the custom certificate. The CA will provide the serial numbers of the empowerment certificate and longterm custom certificate, and say whether the longterm custom certificate is qualified or not (so that Alice knows if her signature was upgraded to qualified status as defined in article 5.1 of the EU Electronic Signatures Directive). The RA is specifically not told anything else about the policy, and is not told the amount of any liability limitation. (It is none of Alice's business what value Bob attaches to his relationship with her.)

Bob obviously has an option to ask for only a subset of the possible predicate attributes to be included.

Figure 6 shows a flow diagram of the method 600 carried out by the CA. The method 600 starts with the empowerment certificate being sent by Bob to the CA 601. At step 602, the CA generates a serial number for the new custom certificate, checks that the data of the empowerment certificate is consistent and copies the data into the custom certificate and enters its name as the issuer of the custom certificate. If any data is inconsistent 603, the empowerment certificate is rejected and returned to Bob 604.

The CA checks the validity of the empowerment certificate by first ascertaining if the certificate is instantaneous or longterm 605. If the empowerment certificate is instantaneous, the time since it was generated is checked to make sure this is within a predetermined time 606. If the empowerment certificate is longterm, the validity period is checked 607.

If the empowerment certificate is outside its validity period, the empowerment certificate is rejected and returned to Bob 604.

The CA then sets the validity period of the custom certificate 608 and sends the custom certificate to the RA 609. The RA processes the custom certificate and sends Alice's public key to the CA 610. The CA checks the signature of the empowerment certificate with the public key 611. If some of the data referred to in the empowerment certificate is held in other RAs the CA will send requests to the other RAs for the data. The CA signs the custom certificate and transmits it to Bob 612. The CA also informs the RA that the data has been sent to Bob.

THE CUSTOM CERTIFICATE REVOCATION LIST Just as the system provides for custom certificates, so too there are custom certificate revocation lists. They apply to longterm custom certificates only, because instantaneous custom certificates expire within a second of their generation, so the question of their revocation never arises.

Through a mechanism that is about to be explained, a CA will become aware of any change to information included in a longterm custom certificate that it has signed, provided that the change occurs before the expiry of the longterm custom certificate concerned. Also, Alice can at any time revoke any of the empowerment certificates she has signed, which means that the corresponding longterm custom certificates must also be revoked. Bob can also ask for any longterm custom certificate in which he is named as relying party to be revoked.

A CA maintains a separate custom certificate revocation list (CRL) for each of its customers, and each customer only gets to see its own CRL. Bob can consult his CRL anytime he wishes, can specify the normal frequency he wants CRLs updated, and can even force the creation of a new CRL at any time. Bob can also be asked to be notified each time a new CRL is available for his inspection. Bob can archive CRLs so that he can later prove that a particular longterm custom certificate was unrevoked at any particular time.

Whenever a certificate serial number appears in a CRL, Bob will want to archive the revoked certificate. If the empowerment certificate that matched the revoked longterm custom certificate is still unexpired, then Bob can resubmit the matching empowerment certificate and try to get a new longterm custom certificate with updated content. Whether he is successful or not depends on the reason for revocation, and Bob can see the revocation reason code in his CRL.

Clearly, if Alice revoked the empowerment certificate, then no way is the infrastructure going to yield up a longterm custom certificate to Bob.

Alice has withdrawn that particular empowerment to her personal data. And a longterm custom certificate will not be recoverable if Alice's distinguished name is deleted.

If only the value of an attribute or a public key has changed, or if Alice has simply changed the way her personal data is allocated to RAs, then the empowerment certificate can usually be resubmitted and a replacement longterm custom certificate obtained, valid for the remaining duration of the empowerment certificate.

Bob can request a longterm custom certificate at any time before the empowerment certificate expiry. Bob can even contract with the CA for the CA to automatically process a new request every time a revocation occurs, without Bob needing to start the exercise off. And Bob can present the same empowerment certificate to different CAs during its lifetime.

So, as Alice rolls over her key pair, or changes her name on marriage, or receives an increased purchasing limit from Acme, or changes bank, or moves house, or changes phone number, or even changes employer, the longterm custom certificates around the world which name her as subject will quickly get revoked and replaced. Bob's address book will always be up to date.

Alice needs to tell just one of her RAs of her change of circumstances, and everyone she has empowered to know about those circumstances will very soon know what has happened. This applies to every piece of data in unexpired

longterm custom certificates-identifiers, predicate, authenticators, authorisers, locators.

*Every time a CA revokes a longterm custom certificate it flags the serial number of the revoked longterm custom certificate to the RA who resolved Alice's distinguished name into her public key.

The following describes how the method works in detail.

. 16 Alice is optionally able to maintain, through her software functionality, constructs known as empowerment certificate revocation lists (ECRLs). At any time she can present to any of her RAs an ECRL listing the serial numbers of previously-generated longterm empowerment certificates still valid that she wishes to revoke. (Instantaneous empowerment certificates expire shortly after their creation, so the question of their revocation never arises.) When any of the RAs receives an ECRL, it extracts from the list the serial numbers of all the empowerment certificates which it has processed for Alice, looks at its mapping table to find the matching CA names and custom certificate serial numbers, and sends signed messages to each CA instructing revocation on the grounds of"empowerment certificate revocation".

If a particular empowerment certificate names more than one RA, Alice can send the ECRL to any one of them. This provides her with the ability to revoke a part of an empowerment certificate, at the granularity of the RA. It is even possible to allow revocation at the granularity of an attribute. There is a requirement for a revocation code"partial empowerment certificate revocation".

* If Alice decides to move an item of her personal data from one RA to another, the RA will look at the labels on that item of data, extract the serial numbers of unexpired custom certificates and send signed revocation messages to the relevant CAs, with a reason code"change of RA".

* Every time a piece of Alice's data changes value in its database, the RA will examine the labels attached and will send out signed revocation messages for each custom certificate. For custom certificates where the DN flag is set, the revocation reason will be"identity deleted". Where the att flag is set, the reason will be"attribute change".

Finally, if, through methods not defined in the system, an RA learns of the death of a subject, it will cause the revocation of all that subject's unexpired custom certificates with a reason code"death of subject".

It is worthwhile resubmitting unexpired empowerment certificates only it the revocation reason was"partial empowerment certificate revocation", "change of RA"or"attribute change".

Figure 7 shows the diagram of Figure 3 with the addition of the certificate revocation lists. An empowerment certificate revocation list 701 is transmitted by Alice 302 to the RA 306. The RA 306 has a mapping table 702 in which a record of all empowerment certificates and custom certificates is kept with reference to their serial numbers and a record of the CAs to which the data has been supplied. The RA 306 can inform the CAs of any custom certificates which should be revoked further to a revocation request from Alice 302. The CA 310 keeps a certificate revocation list 703 for each relying entity such as Bob 304.

THE INFRASTRUCTURE The empowerment infrastructure consists of a secure (that is, signed and encrypted) messaging and transaction system linking a set of RAs and CAs which offer empowerment services to their customers. Methods of implementing such transaction systems are well described in prior art.

As the CAs and RAs communicate securely among themselves, they in turn could exploit the same mechanisms as we have shown Alice and Bob to exploit.

Improvements and modifications can be made to the foregoing without departing from the scope of the present invention.

Claims

CLAIMS 1. A method for supply of data relating to a described entity (302) to a

relying entity (304) comprising : . ," generating a first digital certificate signed with an electronic signature by a first signing entity and including : (one or more attributes of the described entity (302)) one or more attributes of the first digital certificate which include one or more attributes identifying the first signing entity ; an indication of data relating to the described entity (302) which is to be supplied ; an indication of one or more sources (306,500) for the data to be supplied ; and

one or more attributes identifying one or more relying entities (304)

to which the data is to be supplied ; r she relying entity (304) forwarding the first digital certificate for . f. ') processing ;--

a source (306, 500) supplying the data indicated in the first digital certificate. ~

2. A method as claimed in claim 1, wherein a source (306, 500) can hold data or can refer to one or more further sources (306,500).

3. A method as claimed in claim 1 or claim 2, wherein the first signing entity is the described entity (302).

4. A method as claimed in any one of claims 1 to 3, wherein the first digital certificate includes a reference, nonce or other data which the relying entity (304) has previously requested to be included.

5. A method as claimed in any one of claims 1 to 4, wherein some or all of the data relating to the described entity (302) is supplied by means of a second digital certificate to the relying entity (304), the second digital certificate signed with an electronic signature by a second signing entity and including: one or more attributes of the described entity (302) including the data which is to be supplied; one or more attributes of the second digital certificate which include one or more attributes identifying the second signing entity; and one or more attributes identifying one or more relying entities (304) to which the data is to be supplied.

<Desc/Clms Page number 38>

6. A method as claimed in claim 5, wherein the first digital certificate authorises the relying entity (304) to use the first digital certificate to obtain a second digital certificate.

7. A method as claimed in claim 6, wherein the relying entity (304) is authorised to obtain a second digital certificate which is marked as qualified.

8. A method as claimed in any one of claims 5 to 7, wherein the second digital certificate includes one or more attributes of the first digital certificate.

9. A method as claimed in any one of claims 5 to 8, wherein at least some of the contents of the first digital certificate is copied to the second digital certificate.

10. A method as claimed in any one of the preceding claims, wherein the method includes the relying entity (304) forwarding the first digital certificate to an intermediate entity (308) to obtain data from a source (306,500).

11. A method as claimed in claim 10, wherein the intermediate entity (308) generates the second digital certificate.

12. A method as claimed in any one of claims 5 to 11, wherein the second digital certificate includes one or more attributes identifying the relying entity (304) which are different from the one or more attributes identifying the relying entity (304) included in the first digital certificate.

13. A method as claimed in any one of claims 5 to 12, wherein the second digital certificate includes one or more attributes identifying the described entity (302) which are different from one or more attributes identifying the described entity (302) included in the first digital certificate.

14. A method as claimed in any one of the preceding claims, wherein the described entity (302) generates a digital signature using a private key with a corresponding public key and the first signing entity includes the digital signature or a cryptographic digest thereof in the first digital certificate, and the data to be supplied to the relying entity (304) includes the public key.

<Desc/Clms Page number 39>

15. A method as claimed in any one of the preceding claims, wherein the first digital certificate includes a period of validity.

16. A method as claimed in any one of claims 5 to 15, wherein the second digital certificate includes a period of validity.

17. A method as claimed in claim 15 or claim 16, wherein the period of validity of the first digital certificate or the second digital certificate is that short period of time during which a digital signature was generated.

18. A method as claimed in any one of the preceding claims, wherein the data indicated in the first digital certificate includes confirmation of a payment or debt due from the described entity (302) identified in the first digital certificate to the relying entity (304) identified in the first digital certificate.

19. A method as claimed in claim 18, wherein a second signing entity indicates in a second digital certificate a guarantee of a debt indicated as due in a first digital certificate.

20. A method as claimed in claims 5 to 19, wherein a change in previously supplied data is indicated by the supply of a list identifying a second digital certificate relating to the previously supplied data.

21. A method as claimed in any one of the preceding claims, wherein a list (701,703) identifies a first or second digital certificate specifying data which is no longer authorised to be supplied to the relying entity (304).

22. A method as claimed in claim 20 or claim 21, wherein the generation of the list (701,703) includes one or more attributes identifying the relying entities (304) to which the list (701,703) relates.

23. A method as claimed in any one of claims 5 to 22, which includes generating and storing a list (703) for the second digital certificates, which is indexed by one or more attributes identifying relying entities (304) such that all second digital certificates in the list (703) relevant

to a relying entity (304) can be identified.

ta S A system for supply of data relating to a described entity (302) to a relying entity (304), the system comprising :

<Desc/Clms Page number 40>

a first signing entity application, a relying entity application and a data store (504) wherein the data store (504) holds data relating to the described entity (302); the first signing entity application has means for generating a first digital certificate signed with an electronic signature by the first signing entity application and including : one or more attributes of the described entity (302) ; one or more attributes of the first digital certificate which include one or more attributes identifying the first signing entity; an indication of data relating to the described entity (302) which is to be supplied; an indication of one or more sources (306, 500) for the data to be supplied; and one or more attributes identifying one or more relying entities (304) to which the data is to be supplied; the relying entity application has means for forwarding the first digital certificate for processing ; and means for supplying the data indicated in the first digital certificate from the data store (504).

25. A system as claimed in claim 24, wherein a source (306, 500) holds the data store (504) or can refer to one or more further sources (306, 500).

26. A system as claimed in claim 24 or claim 25, wherein the first signing entity is the described entity (302).

27. A system as claimed in any one of claims 24 to 26, wherein the first digital certificate includes a reference, nonce or other data which the relying entity (304) has previously requested to be included.

28. A system as claimed in any one of claims 24 to 27, wherein a second digital certificate is provided for supplying the data relating to the described entity (302) to the relying entity application, the second digital certificate signed with an electronic signature by a second signing entity application and including : one or more attributes of the described entity (302) including the data which is to be supplied; one or more attributes of the second digital certificate which include one or more attributes identifying the second signing entity ; and one or more attributes identifying one or more relying entities (304) to which the data is to be supplied.

<Desc/Clms Page number 41>

29. A system as claimed in any one of claims 24 to 28, wherein the system includes an intermediate entity application to which the relying entity application forwards the first digital certificate to obtain data from the data store (504).

30. A system as claimed in any one of claims 24 to 29, wherein the system includes more than one data store (504) holding data relating to the described entity (302).

31. A system as claimed in any one of claims 24 to 30, wherein a data store (504) has a means of determining for an item of data included in the data store (504) information concerning or contained in a first digital certificate which has referenced that item 32. A system as claimed in any one of claims 28 to 31, wherein a data store (504) has a means of determining for an item of data included in the data store (504) information concerning or contained in a second digital certificate which provides the value of that item.

33. A system as claimed in any one of claims 29 to 32, wherein the intermediate entity application has a storage means for storing second digital certificates referenced by the relying entities (304) identified in the second digital certificates.

34. A system as claimed in any one of claims 24 to 33, wherein the system includes a proxy entity application to which the relying entity application or the intermediate entity application forwards the first digital certificate to obtain information specifying to which data store (504) or other proxy entity application the first certificate should next be forwarded

A computer program product stored on a computer readable storage tedium, comprising computer readable program code means for performing the

steps of : generating a digital certificate signed with an electronic signature by a signing entity and including: one or more attributes of a described entity (302) ; one or more attributes of the digital certificate which include one or more attributes identifying the signing entity; either an indication of data relating to the described entity (302) which is to be supplied and an indication of one or more sources (306,500) or the data itself; and one or more attributes identifying one or more relying entities (304) to which the data is to be supplied.

<Desc/Clms Page number 42>

I , 6) A digital certificate signed with an electronic signature by a signing entity and comprising: one or more attributes of a described entity (302) ; one or more attributes of the digital certificate which include one or more attributes identifying the signing entity; either an indication of data relating to the described entity (302) which is to be supplied and an indication of one or more sources (306,500) or the data itself; and one or more attributes identifying one or more relying entities (304), wherein the relying entities (304) are entities to which the data relating to the described entity (302) is to be supplied.

37. A method of providing a digital signature based on a digital certificate comprising: generating a digital signature using a private key corresponding to a public key, the signed data including: one or more attributes identifying a digital certificate to be generated; generating a digital certificate signed with an electronic signature by a signing entity and including: one or more attributes of a described entity (302) which are sufficient to obtain the public key; one or more attributes of the digital certificate which include one or more attributes identifying the signing entity; and an indicated period of validity of the digital certificate which begins earlier than the time of generation of the digital certificate ; '----/ ;/ wherein the digital certificate is generated after the generation of the digital signature.

18.

38. A method as claimed in claim 37, wherein more than one digital signature can be generated which identifies the same digital certificate.

39. A method as claimed in claim 37 or claim 38, wherein the period of validity of the digital certificate is that short period in which the digital signature was generated.

40. A method as claimed in any one of claims 37 to 39, wherein the one or more attributes identifying the digital certificate to be generated given in the digital signature include a serial number.

41. A method as claimed in claim 40, wherein the lowest available serial number which can be used for the next digital certificate to be generated or the last used serial number using each private key is recorded.

<Desc/Clms Page number 43>

42 : A system for providing a digital signature based on a digital certificate, the system comprising: a described entity application with means for generating a digital signature using a private key corresponding to a public key, the signed data including: one or more attributes identifying a digital certificate to be generated; a signing entity application having means for generating a digital certificate with an electronic signature and including: one or more attributes of a described entity (302) which are sufficient to obtain the public key; one or more attributes of the digital certificate which include one or more attributes identifying the signing entity; and an indicated period of validity of the digital certificate which begins earlier than the time of generation of the digital certificate; wherein the digital certificate is generated after the generation of the digital signature.

43 J A computer program product stored on a computer readable storage medium, comprising computer readable program code means for performing the steps of: generating a digital signature using a private key corresponding to a public key, the signed data including: one or more attributes identifying a digital certificate to be generated; generating a digital certificate signed with an electronic signature by a signing entity and including: one or more attributes of a described entity (302) which are sufficient to obtain the public key; one or more attributes of the digital certificate which include one or more attributes identifying the signing entity; and an indicated period of validity of the digital certificate which begins earlier than the time of generation of the digital certificate; wherein the digital certificate is generated after the generation of the digital signature.

44. A digital certificate signed with an electronic signature by a

signing entity and comprising :

(.-- one or more attributes of a described entity (302) ; ''/.'' one or more attributes of the digital certificate which include one

or more attributes identifying the signing entity ;

<Desc/Clms Page number 44>

an indicated period of validity of the digital certificate which begins earlier than the time of generation of the digital certificate.

45. A digital certificate as claimed in claim 44, wherein the indicated period of validity of the digital certificate ends no later than the time of generation of the digital certificate.

46. A digital certificate as claimed in claim 44 or claim 45, wherein the described entity (302) is the signing entity.

47. A digital certificate as claimed in any one of claims 44 to 46, wherein the digital certificate includes a time stamp indicating the time of generation.

48. A digital signature using a private key corresponding to the public key derivable from a digital certificate as claimed in claim 44, wherein the digital certificate is generated after the generation of the digital signature, the signed data including: one or more attributes identifying the digital certificate to be generated.