US20080209208A1 - Method and apparatus for managing digital certificates - Google Patents
Method and apparatus for managing digital certificates Download PDFInfo
- Publication number
- US20080209208A1 US20080209208A1 US11/712,278 US71227807A US2008209208A1 US 20080209208 A1 US20080209208 A1 US 20080209208A1 US 71227807 A US71227807 A US 71227807A US 2008209208 A1 US2008209208 A1 US 2008209208A1
- Authority
- US
- United States
- Prior art keywords
- directory
- encryption certificate
- owner
- certificate
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
Definitions
- the present invention relates generally to digital certificates. More particularly, this invention relates to managing digital certificates.
- 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.
- LDAP lightweight directory access protocol
- X.500 directory a publicly accessible repository
- CA certificate authority or certifying authority
- FIG. 1 is a block diagram illustrating a network configuration which may be used with an embodiment of the invention.
- FIG. 2 is an example of an email which may be used with one embodiment of the invention.
- FIG. 3 is an example of a directory entry according to one embodiment of the invention.
- FIG. 4 is a block diagram illustrating an example of a certificate handler according to one embodiment of the invention.
- FIG. 5 is a flow diagram illustrating a process for managing digital certificates according to one embodiment of the invention.
- FIG. 6 is a block diagram of a digital processing system, which may be used with one embodiment of the invention.
- a mechanism e.g., an email bot or a certificate handler
- a mechanism 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.
- a user may send a signed email (e.g., with a digital signature or signature certificate).
- 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.
- 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.
- this mechanism e.g., certificate handler
- this mechanism will be described to store an encryption certificate in an entry of a directory (e.g., an LDAP directory).
- update e.g., add, delete, modify, and/or query
- 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.
- a directory is not limited to an LDAP directory; other types of directories (e.g., X.509) may also be applied.
- FIG. 1 is a block diagram illustrating a network configuration which may be used with an embodiment of the invention.
- network configuration 100 includes, but is not limited to, a computing device 101 having an email client application 109 communicatively coupled to an email server 103 over a network 102 .
- Computing device 101 may 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 client 109 may be any email application, such as, for example, OUTLOOKTM, EUDORATM, etc.
- Email server 103 is configured to handle outgoing and incoming emails for email client 109 , using a variety of communication protocols, such as, for example, SMTP (simple mail transfer protocol), IMAP (Internet message access protocol) or POP3 (post office protocol 3 ).
- Network 102 may 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.
- Network 102 may include multiple sub-networks.
- network configuration 100 includes a directory server 104 for providing directory services to email client 109 and/or email server 103 .
- Directory server 104 may be coupled to a directory repository 107 (also simply referred to as a directory) for storing email related information, such as, for example, digital certificates 110 .
- 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.
- 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.
- directory 107 may 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.
- network configuration 100 includes a certificate handler 105 (also referred to as an email handler) coupled to network 102 and accessible by server 103 .
- Certificate handler 105 is configured to handle any certificates received from email clients 109 and to store or update the corresponding certificate entry in directory 107 associated with the user.
- the email client 109 sends 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 server 103 .
- server 103 invokes certificate handler 105 to handle the digital certificate(s) within the email.
- the certificate handler 105 in turn accesses, via directory server 104 , directory 107 to 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 CAs 108 .
- 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.
- 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.
- certificate handler 105 receives an email from email client 109 to specifically request for updating a certificate entry (e.g., certificate entry 110 ) associated with the email client 109 .
- a certificate entry e.g., certificate entry 110
- 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 in FIG. 2 .
- Email 200 is sent to a dedicated email destination address 201 from an email client identified via a source email address 205 .
- Email 200 may be signed by a digital signature 202 and authorized via a signature certificate 203 issued by a CA (e.g., CA 108 ).
- email 200 may be an S/MIME (secure/multipurpose Internet mail extension) compatible email.
- email 200 may include or attach encryption certificate 204 (e.g., an encryption certificate of a sender who sends email 200 ) issued by a CA (e.g., CA 108 ).
- Signature certificate 203 and encryption certificate 204 may be issued by the same or different CAs.
- title field 206 of email 200 may 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.
- the body of email 200 may also be used for similar purposes.
- email client 109 in order to allow other users to send an encrypted email to email client 109 , email client 109 has to publish its encryption certificate (typically including its public key) in directory 107 .
- the encryption certificate typically including its public key
- client 109 can look up in the directory 107 to retrieve the encryption certificate of client 109 and use the retrieved encryption certificate to encrypt the email.
- Such an encrypted email can then be decrypted (using a corresponding private key) by client 109 as a recipient.
- certificate handler 105 may be implemented as part of server 103 or alternatively, it may be implemented remotely and accessible by server 103 . Certificate handler 105 may 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 directory 107 .
- FIG. 3 An example of a certificate entry is shown in FIG. 3 . Note that entry 300 of FIG. 3 is shown for purpose of illustration only; each entry may include one or more certificates. Other formats may exist.
- FIG. 4 is a block diagram illustrating an example of a certificate handler according to one embodiment of the invention.
- certificate handler 400 may be implemented as part of certificate handler 105 of FIG. 1 .
- certificate handler 400 includes, but is not limited to, a certificate processing unit 401 which can communicate with an email facility (e.g., email server 103 of FIG. 1 ) via email interface 402 to receive an email to request updating a certificate entry of a directory communicatively coupled to certificate processing unit 401 via directory interface 403 .
- certificate processing unit 401 may communicate with one or more CAs via CA interface 404 to obtain certain trusted roots for verifying emails (e.g., digital signatures or signature certificates) and/or other digital certificates (e.g., encryption certificates).
- certificate processing unit 401 includes, but is not limited to, certificate extractor 404 , directory entry processing unit 405 , and email/certificate verifier 406 .
- certificate extractor 404 Upon receiving an email to request for updating a certificate entry, certificate extractor 404 is 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.
- certificates e.g., encryption certificate and/or signature certificate
- verifier 406 is 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, verifier 406 may optionally verify that the email message is signed by a proper signature certificate issued by a proper CA (e.g., CA 108 of FIG. 1 ). Verifier 406 may maintain trust roots of certain CAs used by a client (e.g., client 109 of FIG. 1 ). Such trust roots may be used for verification purposes (e.g., verifying signature certificate or encryption certificate).
- the certificate handler 400 may optionally verify the ownership of the signature certificate and the encryption certificate from the email.
- verifier 406 may 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.
- verifier 406 may 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.
- directory entry processing unit 405 looks up, via directory interface 403 , in a directory (e.g., directory 107 of FIG. 1 ) to locate a corresponding entry associated with the owner of the encryption certificate. If there is no existing entry, directory entry processing unit 405 may 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 in FIG. 4 may be implemented in hardware, software, or a combination of both. Other configurations may exist.
- FIG. 5 is a flow diagram illustrating a process for managing digital certificates according to one embodiment of the invention.
- process 500 may 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.
- processing logic may be performed by certificate handler 400 of FIG. 4 .
- 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.
- processing logic extracts the certificate from the email, where the certificate is issued from a CA based on an identity (ID) of the sender.
- ID identity
- 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.
- ID identity
- processing logic optionally verifies the signature on the email to ensure that the sender is trusted, for example, by verifying the associated signature certificate.
- 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.
- 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.
- 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. 6 is a block diagram of a digital processing system, which may be used with one embodiment of the invention.
- the system 600 may be used as a client and/or a server as described above with respect to FIG. 1 .
- system 600 may be implemented as a certificate handler 400 of FIG. 4 .
- FIG. 6 illustrates 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.
- the system 600 which is a form of a data processing system, includes a bus or interconnect 602 which is coupled to one or more microprocessors 603 and a ROM 607 , a volatile RAM 605 , and a non-volatile memory 606 .
- the microprocessor 603 is coupled to cache memory 604 as shown in the example of FIG. 6 .
- Processor 603 may be, for example, a PowerPC microprocessor or an Intel compatible processor.
- processor 603 may 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.
- ASIC Application-Specific Integrated Circuit
- CISC Complex Instruction Set Computing
- RISC Reduced Instruction Set Computing
- VLIW Very Long Instruction Word
- the bus 602 interconnects these various components together and also interconnects these components 603 , 607 , 605 , and 606 to a display controller and display device 608 , as well as to input/output (I/O) devices 610 , which may be mice, keyboards, modems, network interfaces, printers, and other devices which are well-known in the art.
- I/O input/output
- the input/output devices 610 are coupled to the system through input/output controllers 609 .
- the volatile RAM 605 is typically implemented as dynamic RAM (DRAM) which requires power continuously in order to refresh or maintain the data in the memory.
- the non-volatile memory 606 is 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.
- the non-volatile memory will also be a random access memory, although this is not required.
- FIG. 6 shows that the non-volatile memory is a local device coupled directly to the rest of the components in the data processing system
- 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 bus 602 may include one or more buses connected to each other through various bridges, controllers, and/or adapters, as is well-known in the art.
- the I/O controller 609 includes a USB (Universal Serial Bus) adapter for controlling USB peripherals.
- I/O controller 609 may include an IEEE-1394 adapter, also known as FireWire adapter, for controlling FireWire devices.
- Embodiments of the present invention also relate to an apparatus for performing the operations herein.
- This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer.
- a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), erasable programmable ROMs (EPROMs), electrically erasable programmable ROMs (EEPROMs), magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
- ROMs read-only memories
- RAMs random access memories
- EPROMs erasable programmable ROMs
- EEPROMs electrically erasable programmable ROMs
- magnetic or optical cards or any type of media suitable for storing electronic
- a machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer).
- a machine-readable medium includes read only memory (“ROM”); random access memory (“RAM”); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.); etc.
Abstract
Description
- The present invention relates generally to digital certificates. More particularly, this invention relates to managing digital certificates.
- 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.
- The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements.
-
FIG. 1 is a block diagram illustrating a network configuration which may be used with an embodiment of the invention. -
FIG. 2 is an example of an email which may be used with one embodiment of the invention. -
FIG. 3 is an example of a directory entry according to one embodiment of the invention. -
FIG. 4 is a block diagram illustrating an example of a certificate handler according to one embodiment of the invention. -
FIG. 5 is a flow diagram illustrating a process for managing digital certificates according to one embodiment of the invention. -
FIG. 6 is a block diagram of a digital processing system, which may be used with one embodiment of the invention. - In the following description, numerous details are set forth to provide a more thorough explanation of embodiments of the present invention. It will be apparent, however, to one skilled in the art, that embodiments of the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring embodiments of the present invention.
- Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification do not necessarily all refer to the same embodiment.
- 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. 1 is a block diagram illustrating a network configuration which may be used with an embodiment of the invention. Referring toFIG. 1 ,network configuration 100 includes, but is not limited to, acomputing device 101 having anemail client application 109 communicatively coupled to anemail server 103 over anetwork 102.Computing device 101 may 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 client 109 may be any email application, such as, for example, OUTLOOK™, EUDORA™, etc. -
Email server 103 is configured to handle outgoing and incoming emails foremail client 109, using a variety of communication protocols, such as, for example, SMTP (simple mail transfer protocol), IMAP (Internet message access protocol) or POP3 (post office protocol 3). Network 102 may 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. Network 102 may include multiple sub-networks. - In addition,
network configuration 100 includes adirectory server 104 for providing directory services toemail client 109 and/oremail server 103.Directory server 104 may be coupled to a directory repository 107 (also simply referred to as a directory) for storing email related information, such as, for example,digital certificates 110. - 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 to
FIG. 1 ,directory 107 may 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 configuration 100 includes a certificate handler 105 (also referred to as an email handler) coupled tonetwork 102 and accessible byserver 103.Certificate handler 105 is configured to handle any certificates received fromemail clients 109 and to store or update the corresponding certificate entry indirectory 107 associated with the user. In one embodiment, theemail client 109 sends 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) toserver 103. In response,server 103invokes certificate handler 105 to handle the digital certificate(s) within the email. Thecertificate handler 105 in turn accesses, viadirectory server 104,directory 107 to 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
CAs 108. 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 to
FIG. 1 , according to one embodiment,certificate handler 105 receives an email fromemail client 109 to specifically request for updating a certificate entry (e.g., certificate entry 110) associated with theemail client 109. 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 to
FIGS. 1 and 2 , according to one embodiment,email 200 is sent to a dedicatedemail destination address 201 from an email client identified via asource email address 205.Email 200 may be signed by adigital signature 202 and authorized via asignature certificate 203 issued by a CA (e.g., CA 108). For example,email 200 may be an S/MIME (secure/multipurpose Internet mail extension) compatible email. In addition,email 200 may include or attach encryption certificate 204 (e.g., an encryption certificate of a sender who sends email 200) issued by a CA (e.g., CA 108).Signature certificate 203 andencryption certificate 204 may be issued by the same or different CAs. Further,title field 206 ofemail 200 may 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 ofemail 200 may also be used for similar purposes. - Referring back to
FIG. 1 , in order to allow other users to send an encrypted email to emailclient 109,email client 109 has to publish its encryption certificate (typically including its public key) indirectory 107. When another user wishes to sendclient 109 an encrypted email, that user can look up in thedirectory 107 to retrieve the encryption certificate ofclient 109 and use the retrieved encryption certificate to encrypt the email. Such an encrypted email can then be decrypted (using a corresponding private key) byclient 109 as a recipient. - According to one embodiment, to publish an encryption certificate of
client 109,client 109 sends a specific email toserver 103. Upon receiving such an email,server 103 invokescertificate handler 105.Certificate handler 105 may be implemented as part ofserver 103 or alternatively, it may be implemented remotely and accessible byserver 103.Certificate handler 105 may parse the email to extract one or more certificates from the email and update (e.g., adding, deleting, modifying, or querying) the corresponding entry indirectory 107. For the purpose of illustration only, an example of a certificate entry is shown inFIG. 3 . Note thatentry 300 ofFIG. 3 is shown for purpose of illustration only; each entry may include one or more certificates. Other formats may exist. -
FIG. 4 is a block diagram illustrating an example of a certificate handler according to one embodiment of the invention. For example,certificate handler 400 may be implemented as part ofcertificate handler 105 ofFIG. 1 . Referring toFIG. 4 , in one embodiment,certificate handler 400 includes, but is not limited to, acertificate processing unit 401 which can communicate with an email facility (e.g.,email server 103 ofFIG. 1 ) viaemail interface 402 to receive an email to request updating a certificate entry of a directory communicatively coupled tocertificate processing unit 401 viadirectory interface 403. In addition,certificate processing unit 401 may communicate with one or more CAs viaCA interface 404 to 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 unit 401 includes, but is not limited to,certificate extractor 404, directoryentry processing unit 405, and email/certificate verifier 406. Upon receiving an email to request for updating a certificate entry,certificate extractor 404 is 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,
verifier 406 is 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,verifier 406 may optionally verify that the email message is signed by a proper signature certificate issued by a proper CA (e.g.,CA 108 ofFIG. 1 ).Verifier 406 may maintain trust roots of certain CAs used by a client (e.g.,client 109 ofFIG. 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 handler 400 may optionally verify the ownership of the signature certificate and the encryption certificate from the email. In a particular embodiment,verifier 406 may 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,verifier 406 may 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 unit 405 looks up, viadirectory interface 403, in a directory (e.g.,directory 107 ofFIG. 1 ) to locate a corresponding entry associated with the owner of the encryption certificate. If there is no existing entry, directoryentry processing unit 405 may 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. 4 may be implemented in hardware, software, or a combination of both. Other configurations may exist. -
FIG. 5 is a flow diagram illustrating a process for managing digital certificates according to one embodiment of the invention. Note thatprocess 500 may 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,process 500 may be performed bycertificate handler 400 ofFIG. 4 . Referring toFIG. 5 , atblock 501, 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. Atblock 502, 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
block 503, 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. Atblock 504, processing logic optionally verifies the signature on the email to ensure that the sender is trusted, for example, by verifying the associated signature certificate. Atblock 505, 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, atblock 506, 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. Atblock 507, 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. 6 is a block diagram of a digital processing system, which may be used with one embodiment of the invention. For example, thesystem 600 may be used as a client and/or a server as described above with respect toFIG. 1 . Alternatively,system 600 may be implemented as acertificate handler 400 ofFIG. 4 . Note that whileFIG. 6 illustrates 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 in
FIG. 6 , thesystem 600, which is a form of a data processing system, includes a bus or interconnect 602 which is coupled to one ormore microprocessors 603 and aROM 607, avolatile RAM 605, and anon-volatile memory 606. Themicroprocessor 603 is coupled tocache memory 604 as shown in the example ofFIG. 6 .Processor 603 may be, for example, a PowerPC microprocessor or an Intel compatible processor. Alternatively,processor 603 may 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
bus 602 interconnects these various components together and also interconnects thesecomponents display device 608, as well as to input/output (I/O)devices 610, which may be mice, keyboards, modems, network interfaces, printers, and other devices which are well-known in the art. - Typically, the input/
output devices 610 are coupled to the system through input/output controllers 609. Thevolatile RAM 605 is typically implemented as dynamic RAM (DRAM) which requires power continuously in order to refresh or maintain the data in the memory. Thenon-volatile memory 606 is 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. - While
FIG. 6 shows 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. Thebus 602 may 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 controller 609 includes a USB (Universal Serial Bus) adapter for controlling USB peripherals. Alternatively, I/O controller 609 may include an IEEE-1394 adapter, also known as FireWire adapter, for controlling FireWire devices. - Some portions of the preceding detailed descriptions have been presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the ways used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.
- It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
- Embodiments of the present invention also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), erasable programmable ROMs (EPROMs), electrically erasable programmable ROMs (EEPROMs), magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
- The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method operations. The required structure for a variety of these systems will appear from the description below. In addition, embodiments of the present invention are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of embodiments of the invention as described herein.
- A machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium includes read only memory (“ROM”); random access memory (“RAM”); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.); etc.
- In the foregoing specification, embodiments of the invention have been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope of the invention as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.
Claims (22)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/712,278 US8135950B2 (en) | 2007-02-27 | 2007-02-27 | Method and apparatus for managing digital certificates |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/712,278 US8135950B2 (en) | 2007-02-27 | 2007-02-27 | Method and apparatus for managing digital certificates |
Publications (2)
Publication Number | Publication Date |
---|---|
US20080209208A1 true US20080209208A1 (en) | 2008-08-28 |
US8135950B2 US8135950B2 (en) | 2012-03-13 |
Family
ID=39717281
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/712,278 Expired - Fee Related US8135950B2 (en) | 2007-02-27 | 2007-02-27 | Method and apparatus for managing digital certificates |
Country Status (1)
Country | Link |
---|---|
US (1) | US8135950B2 (en) |
Cited By (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090150169A1 (en) * | 2007-05-17 | 2009-06-11 | Unlimited Cad Services, Llc | Document acquisition and authentication system |
US20090234925A1 (en) * | 2008-03-14 | 2009-09-17 | International Business Machines Corporation | Dyanmic Domain Based Electronic Mail Signature Lines |
US20100100728A1 (en) * | 2008-10-22 | 2010-04-22 | Research In Motion Limited | Method of handling a certification request |
US20100241851A1 (en) * | 2009-03-17 | 2010-09-23 | Research In Motion Limited | System and method for validating certificate issuance notification messages |
US20110145567A1 (en) * | 2009-12-16 | 2011-06-16 | Verisign, Inc. | Method and system to combine multiple digital certificates using the subject alternative name extension |
US20110145569A1 (en) * | 2009-12-16 | 2011-06-16 | Verisign, Inc. | Method and system for provisioning multiple digital certificates |
US20110154027A1 (en) * | 2009-12-23 | 2011-06-23 | Verisign, Inc. | Method and system for co-termination of digital certificates |
US20110161662A1 (en) * | 2009-12-30 | 2011-06-30 | Hong Fu Jin Precision Industry (Shenzhen) Co., Ltd | System and method for updating digital certificate automatically |
US20110265016A1 (en) * | 2010-04-27 | 2011-10-27 | The Go Daddy Group, Inc. | Embedding Variable Fields in Individual Email Messages Sent via a Web-Based Graphical User Interface |
US20140331310A1 (en) * | 2008-06-22 | 2014-11-06 | Microsoft Corporation | Signed ephemeral email addresses |
US9055059B1 (en) | 2009-12-16 | 2015-06-09 | Symantec Corporation | Combining multiple digital certificates |
US9141789B1 (en) | 2013-07-16 | 2015-09-22 | Go Daddy Operating Company, LLC | Mitigating denial of service attacks |
US9178888B2 (en) | 2013-06-14 | 2015-11-03 | Go Daddy Operating Company, LLC | Method for domain control validation |
US9276887B2 (en) * | 2014-03-19 | 2016-03-01 | Symantec Corporation | Systems and methods for managing security certificates through email |
US9521138B2 (en) | 2013-06-14 | 2016-12-13 | Go Daddy Operating Company, LLC | System for domain control validation |
US9525554B2 (en) * | 2008-05-30 | 2016-12-20 | Google Inc. | Device and method for identifying a certificate for multiple identities of a user |
US9565147B2 (en) | 2014-06-30 | 2017-02-07 | Go Daddy Operating Company, LLC | System and methods for multiple email services having a common domain |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8719121B1 (en) * | 2008-01-15 | 2014-05-06 | David Leason | System and method for automated construction of time records based on electronic messages |
US10153899B2 (en) | 2016-11-18 | 2018-12-11 | Airwatch, Llc | System for retrieval of email certificates from remote certificate repository |
US10841103B2 (en) * | 2018-03-16 | 2020-11-17 | Microsoft Technology Licensing, Llc | Relying party certificate validation when client uses relying party's IP address |
Citations (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020026575A1 (en) * | 1998-11-09 | 2002-02-28 | Wheeler Lynn Henry | Account-based digital signature (ABDS) system |
US20020059144A1 (en) * | 2000-04-28 | 2002-05-16 | Meffert Gregory J. | Secured content delivery system and method |
US20030051134A1 (en) * | 2001-08-28 | 2003-03-13 | International Business Machines Corporation | Secure authentication using digital certificates |
US20030126431A1 (en) * | 2001-10-12 | 2003-07-03 | Beattie Douglas D. | Methods and systems for automated authentication, processing and issuance of digital certificates |
US20030149740A1 (en) * | 2002-02-04 | 2003-08-07 | Wookey Michael J. | Remote services delivery architecture |
US6640301B1 (en) * | 1999-07-08 | 2003-10-28 | David Way Ng | Third-party e-mail authentication service provider using checksum and unknown pad characters with removal of quotation indents |
US20050198170A1 (en) * | 2003-12-12 | 2005-09-08 | Lemay Michael | Secure electronic message transport protocol |
US20050246534A1 (en) * | 2004-04-30 | 2005-11-03 | Kirkup Michael G | System and method for administering digital certificate checking |
US20050257057A1 (en) * | 2004-05-12 | 2005-11-17 | Viatcheslav Ivanov | System, method and computer product for sending encrypted messages to recipients where the sender does not possess the credentials of the recipient |
US20060059333A1 (en) * | 2004-08-31 | 2006-03-16 | Gentry Craig B | Revocation of cryptographic digital certificates |
US20060064581A1 (en) * | 2004-08-20 | 2006-03-23 | Miller Ronald W | Email encryption method and system |
US20060075222A1 (en) * | 2004-10-06 | 2006-04-06 | Seamus Moloney | System for personal group management based on subscriber certificates |
US20060200661A1 (en) * | 2000-05-16 | 2006-09-07 | Wesley Doonan | Method and apparatus for self-authenticating digital records |
US20060259762A1 (en) * | 2005-05-13 | 2006-11-16 | Murata Kikai Kabushiki Kaisha | E-mail server device and certificate management method of the e-mail server device |
US20070083749A1 (en) * | 2005-10-12 | 2007-04-12 | The Boeing Company | Systems and methods for automated exchange of electronic mail encryption certificates |
US7251728B2 (en) * | 2000-07-07 | 2007-07-31 | Message Secure Corporation | Secure and reliable document delivery using routing lists |
US7484089B1 (en) * | 2002-09-06 | 2009-01-27 | Citicorp Developmemt Center, Inc. | Method and system for certificate delivery and management |
US20090235069A1 (en) * | 2006-04-10 | 2009-09-17 | Trust Integration Services B.V. | Arrangement of and method for secure data transmission |
US7644270B1 (en) * | 2004-05-10 | 2010-01-05 | Sprint Communications Company L.P. | Web services security architecture |
US7653008B2 (en) * | 2004-05-21 | 2010-01-26 | Bea Systems, Inc. | Dynamically configurable service oriented architecture |
-
2007
- 2007-02-27 US US11/712,278 patent/US8135950B2/en not_active Expired - Fee Related
Patent Citations (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020026575A1 (en) * | 1998-11-09 | 2002-02-28 | Wheeler Lynn Henry | Account-based digital signature (ABDS) system |
US6640301B1 (en) * | 1999-07-08 | 2003-10-28 | David Way Ng | Third-party e-mail authentication service provider using checksum and unknown pad characters with removal of quotation indents |
US20020059144A1 (en) * | 2000-04-28 | 2002-05-16 | Meffert Gregory J. | Secured content delivery system and method |
US20060200661A1 (en) * | 2000-05-16 | 2006-09-07 | Wesley Doonan | Method and apparatus for self-authenticating digital records |
US7251728B2 (en) * | 2000-07-07 | 2007-07-31 | Message Secure Corporation | Secure and reliable document delivery using routing lists |
US20030051134A1 (en) * | 2001-08-28 | 2003-03-13 | International Business Machines Corporation | Secure authentication using digital certificates |
US20030126431A1 (en) * | 2001-10-12 | 2003-07-03 | Beattie Douglas D. | Methods and systems for automated authentication, processing and issuance of digital certificates |
US7562212B2 (en) * | 2001-10-12 | 2009-07-14 | Geotrust, Inc. | Methods and systems for automated authentication, processing and issuance of digital certificates |
US20030149740A1 (en) * | 2002-02-04 | 2003-08-07 | Wookey Michael J. | Remote services delivery architecture |
US7484089B1 (en) * | 2002-09-06 | 2009-01-27 | Citicorp Developmemt Center, Inc. | Method and system for certificate delivery and management |
US20050198170A1 (en) * | 2003-12-12 | 2005-09-08 | Lemay Michael | Secure electronic message transport protocol |
US20050246534A1 (en) * | 2004-04-30 | 2005-11-03 | Kirkup Michael G | System and method for administering digital certificate checking |
US7644270B1 (en) * | 2004-05-10 | 2010-01-05 | Sprint Communications Company L.P. | Web services security architecture |
US20050257057A1 (en) * | 2004-05-12 | 2005-11-17 | Viatcheslav Ivanov | System, method and computer product for sending encrypted messages to recipients where the sender does not possess the credentials of the recipient |
US7653008B2 (en) * | 2004-05-21 | 2010-01-26 | Bea Systems, Inc. | Dynamically configurable service oriented architecture |
US20060064581A1 (en) * | 2004-08-20 | 2006-03-23 | Miller Ronald W | Email encryption method and system |
US20060059333A1 (en) * | 2004-08-31 | 2006-03-16 | Gentry Craig B | Revocation of cryptographic digital certificates |
US20060075222A1 (en) * | 2004-10-06 | 2006-04-06 | Seamus Moloney | System for personal group management based on subscriber certificates |
US20060259762A1 (en) * | 2005-05-13 | 2006-11-16 | Murata Kikai Kabushiki Kaisha | E-mail server device and certificate management method of the e-mail server device |
US20070083749A1 (en) * | 2005-10-12 | 2007-04-12 | The Boeing Company | Systems and methods for automated exchange of electronic mail encryption certificates |
US7664947B2 (en) * | 2005-10-12 | 2010-02-16 | The Boeing Company | Systems and methods for automated exchange of electronic mail encryption certificates |
US20090235069A1 (en) * | 2006-04-10 | 2009-09-17 | Trust Integration Services B.V. | Arrangement of and method for secure data transmission |
Cited By (30)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090150169A1 (en) * | 2007-05-17 | 2009-06-11 | Unlimited Cad Services, Llc | Document acquisition and authentication system |
US20090234925A1 (en) * | 2008-03-14 | 2009-09-17 | International Business Machines Corporation | Dyanmic Domain Based Electronic Mail Signature Lines |
US7827246B2 (en) * | 2008-03-14 | 2010-11-02 | International Business Machines Corporation | Dynamic domain based electronic mail signature lines |
US9525554B2 (en) * | 2008-05-30 | 2016-12-20 | Google Inc. | Device and method for identifying a certificate for multiple identities of a user |
US9894039B2 (en) * | 2008-06-22 | 2018-02-13 | Microsoft Technology Licensing, Llc | Signed ephemeral email addresses |
US20140331310A1 (en) * | 2008-06-22 | 2014-11-06 | Microsoft Corporation | Signed ephemeral email addresses |
US9300654B2 (en) | 2008-10-22 | 2016-03-29 | Blackberry Limited | Method of handling a certification request |
US20100100728A1 (en) * | 2008-10-22 | 2010-04-22 | Research In Motion Limited | Method of handling a certification request |
US8826009B2 (en) | 2008-10-22 | 2014-09-02 | Blackberry Limited | Method of handling a certification request |
US8296563B2 (en) | 2008-10-22 | 2012-10-23 | Research In Motion Limited | Method of handling a certification request |
US8255685B2 (en) * | 2009-03-17 | 2012-08-28 | Research In Motion Limited | System and method for validating certificate issuance notification messages |
US8826007B2 (en) | 2009-03-17 | 2014-09-02 | Blackberry Limited | System and method for validating certificate issuance notification messages |
US20100241851A1 (en) * | 2009-03-17 | 2010-09-23 | Research In Motion Limited | System and method for validating certificate issuance notification messages |
US11251974B2 (en) | 2009-12-16 | 2022-02-15 | Digicert, Inc. | Provisioning multiple digital certificates |
US8364954B2 (en) | 2009-12-16 | 2013-01-29 | Symantec Corporation | Method and system for provisioning multiple digital certificates |
US8375204B2 (en) | 2009-12-16 | 2013-02-12 | Symantec Corporation | Method and system to combine multiple digital certificates using the subject alternative name extension |
US20110145569A1 (en) * | 2009-12-16 | 2011-06-16 | Verisign, Inc. | Method and system for provisioning multiple digital certificates |
US9055059B1 (en) | 2009-12-16 | 2015-06-09 | Symantec Corporation | Combining multiple digital certificates |
US9100191B2 (en) | 2009-12-16 | 2015-08-04 | Symantec Corporation | Combining multiple digital certificates |
US20110145567A1 (en) * | 2009-12-16 | 2011-06-16 | Verisign, Inc. | Method and system to combine multiple digital certificates using the subject alternative name extension |
US20110154027A1 (en) * | 2009-12-23 | 2011-06-23 | Verisign, Inc. | Method and system for co-termination of digital certificates |
US9680819B2 (en) | 2009-12-23 | 2017-06-13 | Symantec Corporation | Method and system for co-termination of digital certificates |
US20110161662A1 (en) * | 2009-12-30 | 2011-06-30 | Hong Fu Jin Precision Industry (Shenzhen) Co., Ltd | System and method for updating digital certificate automatically |
US8572496B2 (en) * | 2010-04-27 | 2013-10-29 | Go Daddy Operating Company, LLC | Embedding variable fields in individual email messages sent via a web-based graphical user interface |
US20110265016A1 (en) * | 2010-04-27 | 2011-10-27 | The Go Daddy Group, Inc. | Embedding Variable Fields in Individual Email Messages Sent via a Web-Based Graphical User Interface |
US9521138B2 (en) | 2013-06-14 | 2016-12-13 | Go Daddy Operating Company, LLC | System for domain control validation |
US9178888B2 (en) | 2013-06-14 | 2015-11-03 | Go Daddy Operating Company, LLC | Method for domain control validation |
US9141789B1 (en) | 2013-07-16 | 2015-09-22 | Go Daddy Operating Company, LLC | Mitigating denial of service attacks |
US9276887B2 (en) * | 2014-03-19 | 2016-03-01 | Symantec Corporation | Systems and methods for managing security certificates through email |
US9565147B2 (en) | 2014-06-30 | 2017-02-07 | Go Daddy Operating Company, LLC | System and methods for multiple email services having a common domain |
Also Published As
Publication number | Publication date |
---|---|
US8135950B2 (en) | 2012-03-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8135950B2 (en) | Method and apparatus for managing digital certificates | |
AU2021206913B2 (en) | Systems and methods for distributed data sharing with asynchronous third-party attestation | |
US8925108B2 (en) | Document access auditing | |
US8832047B2 (en) | Distributed document version control | |
US7930757B2 (en) | Offline access in a document control system | |
US8627077B2 (en) | Transparent authentication process integration | |
US8627489B2 (en) | Distributed document version control | |
US9002018B2 (en) | Encryption key exchange system and method | |
US20130212707A1 (en) | Document control system | |
US20070061456A1 (en) | Data access control | |
KR20090015026A (en) | Peer-to-peer contact exchange | |
WO2009104285A1 (en) | Electronic mail ciphering system | |
CN108460577A (en) | Students' archives management method, platform and its system | |
US20070288746A1 (en) | Method of providing key containers | |
RU2373572C2 (en) | System and method for resolution of names | |
MX2015004756A (en) | Method for the registration and certification of receipt of electronic mail. | |
US6839842B1 (en) | Method and apparatus for authenticating information | |
JP2021158678A (en) | Certificate management device | |
CN115150360B (en) | Mailbox address and blockchain address binding method based on blockchain technology | |
JP6967847B2 (en) | Certificate management device | |
AU2005220240B1 (en) | Method of providing key containers |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: RED HAT, INC.,NORTH CAROLINA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:PARKINSON, STEVEN W.;REEL/FRAME:019030/0102 Effective date: 20070227 Owner name: RED HAT, INC., NORTH CAROLINA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:PARKINSON, STEVEN W.;REEL/FRAME:019030/0102 Effective date: 20070227 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FEPP | Fee payment procedure |
Free format text: PAT HOLDER NO LONGER CLAIMS SMALL ENTITY STATUS, ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: STOL); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 8 |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |