Method and apparatus for managing digital certificates

Method and apparatus for managing digital certificates are described herein. In one embodiment, an encryption certificate is extracted from an email received from an owner of the encryption certificate, where the encryption certificate being issued from a trusted party other than the owner. Then the encryption certificate is associated with an entry of a directory based on an identity (ID) of the owner, where the directory provides directory services to one or more email servers. Other methods and apparatuses are also described.

FIELD

The present invention relates generally to digital certificates. More particularly, this invention relates to managing digital certificates.

BACKGROUND

The use of digital certificates using public and private key encryption methods is widely known in the field of computing, particularly networked computing. Digital certificates generally follow the X.509 standard, developed by the International Standards Organization (ISO). These certificates create a binding between an entity's public key and its identity. Obtaining authentic copies of public key certificates is critical in deploying secure public key systems. Often a digital certificate is stored in a publicly accessible repository such as an LDAP (lightweight directory access protocol) or X.500 directory.

Typically, when a digital certificate is requested by a user and issued from a certificate authority or certifying authority (CA), the CA would normally distribute the digital certificate to a directory service provider to publish the digital certificate in a directory. However, under certain circumstances, a digital certificate may be obtained from a trusted party that would not normally distribute to the directory server provider. There has been a lack of mechanism to allow a user to publish a digital certificate in a directory.

DETAILED DESCRIPTION

As mentioned above, for people who have received a certificate from an organization's CA, the CA is usually automatically configured to add the certificate to an LDAP directory when the certificate is issued. However, a user may have a certificate received through other means and also wish to place that certificate in the directory so that others may find it. According to certain embodiments of the invention, a mechanism (e.g., an email bot or a certificate handler) is provided to allow a user to send an email or message to request for storing or updating a user's certificate in the directory. For example, a user may send a signed email (e.g., with a digital signature or signature certificate). In addition, the mail may include or attach an encryption certificate of the user, where the encryption certificate allows others to send an encrypted email (e.g., encrypted by the encryption certificate) to the user.

In response, according to one embodiment, the certificate handler may pull apart the signed email; extract the certificate (e.g., encryption certificate) from the email; and store the extracted certificate in the directory which is publicly accessible by others. The certificate handler may be equipped with a set of root certificates that the certificate handler trusts, which may be used to verify the signature that signs the email and/or the certificates (e.g., encryption certificate) extracted from the email. Note that throughout this application, this mechanism (e.g., certificate handler) will be described to store an encryption certificate in an entry of a directory (e.g., an LDAP directory). However, it is not so limited, such a mechanism may also be used to update (e.g., add, delete, modify, and/or query) an entry of certificate within a directory. In addition, a certificate stored within an entry of the directory is not limited to an encryption certificate; other types of digital certificates may also be applied. Further, a directory is not limited to an LDAP directory; other types of directories (e.g., X.509) may also be applied.

FIG. 1is a block diagram illustrating a network configuration which may be used with an embodiment of the invention. Referring toFIG. 1, network configuration100includes, but is not limited to, a computing device101having an email client application109communicatively coupled to an email server103over a network102. Computing device101may be any computing device capable of sending and receiving messages over a network, such as, for example, an individual computer, cellular phone, or PDA (personal digital assistant), etc. Email client109may be any email application, such as, for example, OUTLOOK™, EUDORA™, etc.

Email server103is configured to handle outgoing and incoming emails for email client109, using a variety of communication protocols, such as, for example, SMTP (simple mail transfer protocol), IMAP (Internet message access protocol) or POP3 (post office protocol3). Network102may be a wide area network (e.g., Internet) or a local area network (e.g., Intranet). The network connections may be wired, wireless, or a combination of both wired and wireless. Network102may include multiple sub-networks.

In addition, network configuration100includes a directory server104for providing directory services to email client109and/or email server103. Directory server104may be coupled to a directory repository107(also simply referred to as a directory) for storing email related information, such as, for example, digital certificates110.

A directory service is a software application or a set of applications that stores and organizes information about a computer network's users and network resources, and that allows network administrators to manage users' access to the resources. Additionally, directory services act as an abstraction layer between users and shared resources.

A simple directory service called a naming service maps the names of network resources to their respective network addresses. With the name service type of directory, a user does not have to remember the physical address of a network resource; providing a name will locate the resource. Each resource on the network is considered an object on the directory server. Information about a particular resource is stored as attributes of that object. Information within objects can be made secure so that only users with the available permissions are able to access it.

A directory service defines the namespace for the network. A namespace in this context is the term that is used to hold one or more objects as named entries. The directory design process normally has a set of rules that determine how network resources are named and identified. The rules specify that the names be unique and unambiguous.

Referring back toFIG. 1, directory107may be an LDAP compatible directory. An LDAP directory is supported by an LDAP engine, server, or application that performs storage and retrieval processes with respect to a database in accordance with the LDAP protocol. LDAP directory entries can store many information items, such as, a subject's name, organization, etc; a subject's digital certificate would be stored within a directory entry in association with other information for a subject.

Further, according to one embodiment, network configuration100includes a certificate handler105(also referred to as an email handler) coupled to network102and accessible by server103. Certificate handler105is configured to handle any certificates received from email clients109and to store or update the corresponding certificate entry in directory107associated with the user. In one embodiment, the email client109sends an email signed with a digital signature (e.g., with a signature certificate) and/or embedded or attached with a digital certificate (e.g., an encryption certificate) to server103. In response, server103invokes certificate handler105to handle the digital certificate(s) within the email. The certificate handler105in turn accesses, via directory server104, directory107to update the corresponding certificate entry with respect to the digital certificates from the email.

A digital certificate is a digital document that vouches for the identity and key ownership of entities, such as an individual, a computer system, a specific server routing on that system, etc. Certificates are issued by certificate authorities (CAs), such as CAs108. A CA is an entity, usually a trusted third party to a transaction, that is trusted to sign or issue certificates for other people or entities. A CA usually has some kind of legal responsibilities for its vouching of the binding between a public key and its owner that allow one to trust the entity that signed a certificate. There are many such certificate authorities, such as VeriSign, Entrust, etc. These authorities are responsible for verifying the identity and key ownership of an entity when issuing the certificate.

Referring back toFIG. 1, according to one embodiment, certificate handler105receives an email from email client109to specifically request for updating a certificate entry (e.g., certificate entry110) associated with the email client109. As mentioned above, such an email may be signed with a digital signature (e.g., signature certificate) and may include or attach an encryption certificate therein, similar to an email example as shown inFIG. 2.

Referring toFIGS. 1 and 2, according to one embodiment, email200is sent to a dedicated email destination address201from an email client identified via a source email address205. Email200may be signed by a digital signature202and authorized via a signature certificate203issued by a CA (e.g., CA108). For example, email200may be an S/MIME (secure/multipurpose Internet mail extension) compatible email. In addition, email200may include or attach encryption certificate204(e.g., an encryption certificate of a sender who sends email200) issued by a CA (e.g., CA108). Signature certificate203and encryption certificate204may be issued by the same or different CAs. Further, title field206of email200may be used to specifically request certain actions in updating a certificate entry, such as, for example, adding, deleting, modifying, or querying a specific certificate entry. Alternatively, the body of email200may also be used for similar purposes.

Referring back toFIG. 1, in order to allow other users to send an encrypted email to email client109, email client109has to publish its encryption certificate (typically including its public key) in directory107. When another user wishes to send client109an encrypted email, that user can look up in the directory107to retrieve the encryption certificate of client109and use the retrieved encryption certificate to encrypt the email. Such an encrypted email can then be decrypted (using a corresponding private key) by client109as a recipient.

According to one embodiment, to publish an encryption certificate of client109, client109sends a specific email to server103. Upon receiving such an email, server103invokes certificate handler105. Certificate handler105may be implemented as part of server103or alternatively, it may be implemented remotely and accessible by server103. Certificate handler105may parse the email to extract one or more certificates from the email and update (e.g., adding, deleting, modifying, or querying) the corresponding entry in directory107. For the purpose of illustration only, an example of a certificate entry is shown inFIG. 3. Note that entry300ofFIG. 3is shown for purpose of illustration only; each entry may include one or more certificates. Other formats may exist.

FIG. 4is a block diagram illustrating an example of a certificate handler according to one embodiment of the invention. For example, certificate handler400may be implemented as part of certificate handler105ofFIG. 1. Referring toFIG. 4, in one embodiment, certificate handler400includes, but is not limited to, a certificate processing unit401which can communicate with an email facility (e.g., email server103ofFIG. 1) via email interface402to receive an email to request updating a certificate entry of a directory communicatively coupled to certificate processing unit401via directory interface403. In addition, certificate processing unit401may communicate with one or more CAs via CA interface404to obtain certain trusted roots for verifying emails (e.g., digital signatures or signature certificates) and/or other digital certificates (e.g., encryption certificates).

In one embodiment, certificate processing unit401includes, but is not limited to, certificate extractor404, directory entry processing unit405, and email/certificate verifier406. Upon receiving an email to request for updating a certificate entry, certificate extractor404is configured to parse the email to locate the certificates (e.g., encryption certificate and/or signature certificate) within the email and to extract the certificates from the email.

In one embodiment, verifier406is configured to determine from the certificates identity information about the owner of the certificates (e.g., full name and/or email address). In addition, according to one embodiment, verifier406may optionally verify that the email message is signed by a proper signature certificate issued by a proper CA (e.g., CA108ofFIG. 1). Verifier406may maintain trust roots of certain CAs used by a client (e.g., client109ofFIG. 1). Such trust roots may be used for verification purposes (e.g., verifying signature certificate or encryption certificate).

Further, according to one embodiment, the certificate handler400may optionally verify the ownership of the signature certificate and the encryption certificate from the email. In a particular embodiment, verifier406may match the identity information stored in a predetermined field of the signature certificate, which the email was signed with, with the identity information in the encryption certificate. For example, verifier406may verify an email address specified within a “subject alternative name” (e.g., “subjectAltName”, also referred to as a subject alternative name extension) field of a signature certificate against the corresponding one in an encryption certificate. The subject alternative name extension allows various literal values to be included in the configuration file. These include an email address, URI (uniform resource indicator), DNS (domain name), RID (a registered ID: object identifier), IP address, a distinguished name, etc.

Thereafter, directory entry processing unit405looks up, via directory interface403, in a directory (e.g., directory107ofFIG. 1) to locate a corresponding entry associated with the owner of the encryption certificate. If there is no existing entry, directory entry processing unit405may optionally create a new entry and store the new encryption certificate in the new entry. Note that some or all of the components as shown inFIG. 4may be implemented in hardware, software, or a combination of both. Other configurations may exist.

FIG. 5is a flow diagram illustrating a process for managing digital certificates according to one embodiment of the invention. Note that process500may be performed by processing logic which may include hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both. For example, process500may be performed by certificate handler400ofFIG. 4. Referring toFIG. 5, at block501, processing logic receives an email from a sender to request accessing (e.g., add, delete, modify and/or query) a certificate (e.g., encryption certificate) associated with the sender and stored within an entry of a directory. The email may be signed with a digital signature and may include or attach an encryption certificate of the sender. At block502, processing logic extracts the certificate from the email, where the certificate is issued from a CA based on an identity (ID) of the sender.

At block503, processing logic determines identity (ID) information from the certificate (e.g., signature certificate and/or encryption certificate) regarding an owner of the certificate, such as, for example, name and/or email address of the owner. At block504, processing logic optionally verifies the signature on the email to ensure that the sender is trusted, for example, by verifying the associated signature certificate. At block505, processing logic optionally verifies the identity information of the signature certificate that signs the email against the identity information of the encryption certificate. The identity information from both certificates should match since they are owned by the same person or entity. Once all the identity information has been verified, at block506, processing logic looks up in a directory to locate an existing entry associated with an owner of the certificates and optionally, creates a new entry if there is no existing entry in the directory. At block507, processing logic updates the entry according to an instruction (e.g., add, delete, modify, and/or query) of the email. Other operations may also be performed.

FIG. 6is a block diagram of a digital processing system, which may be used with one embodiment of the invention. For example, the system600may be used as a client and/or a server as described above with respect toFIG. 1. Alternatively, system600may be implemented as a certificate handler400ofFIG. 4. Note that whileFIG. 6illustrates various components of a computer system, it is not intended to represent any particular architecture or manner of interconnecting the components; as such details are not germane to the present invention. It will also be appreciated that network computers, handheld computers, cell phones and other data processing systems which have fewer components or perhaps more components may also be used with the present invention.

As shown inFIG. 6, the system600, which is a form of a data processing system, includes a bus or interconnect602which is coupled to one or more microprocessors603and a ROM607, a volatile RAM605, and a non-volatile memory606. The microprocessor603is coupled to cache memory604as shown in the example ofFIG. 6. Processor603may be, for example, a PowerPC microprocessor or an Intel compatible processor. Alternatively, processor603may be a digital signal processor or processing unit of any type of architecture, such as an ASIC (Application-Specific Integrated Circuit), a CISC (Complex Instruction Set Computing), RISC (Reduced Instruction Set Computing), VLIW (Very Long Instruction Word), or hybrid architecture, although any appropriate processor may be used.

The bus602interconnects these various components together and also interconnects these components603,607,605, and606to a display controller and display device608, as well as to input/output (I/O) devices610, which may be mice, keyboards, modems, network interfaces, printers, and other devices which are well-known in the art.

Typically, the input/output devices610are coupled to the system through input/output controllers609. The volatile RAM605is typically implemented as dynamic RAM (DRAM) which requires power continuously in order to refresh or maintain the data in the memory. The non-volatile memory606is typically a magnetic hard drive, a magnetic optical drive, an optical drive, or a DVD RAM or other type of memory system which maintains data even after power is removed from the system. Typically, the non-volatile memory will also be a random access memory, although this is not required.

WhileFIG. 6shows that the non-volatile memory is a local device coupled directly to the rest of the components in the data processing system, embodiments of the present invention may utilize a non-volatile memory which is remote from the system; such as, a network storage device which is coupled to the data processing system through a network interface such as a modem or Ethernet interface. The bus602may include one or more buses connected to each other through various bridges, controllers, and/or adapters, as is well-known in the art. In one embodiment, the I/O controller609includes a USB (Universal Serial Bus) adapter for controlling USB peripherals. Alternatively, I/O controller609may include an IEEE-1394 adapter, also known as FireWire adapter, for controlling FireWire devices.