Abstract: A certificate issuer (210) can periodically request, receive, and store current server-based certificate validation protocol (SCVP) staples (225) for supported relying parties (205) from at least one server-based certificate validation protocol (SCVP) responder (215). The certificate issuer (210) can receive a contact initiation request (220) from one of the relying parties (205). Responsive to receiving the contact initiation request (220), the certificate issuer (210) can identify a current SCVP staple from the saved staples that is applicable to the relying party (205). The certificate issuer (210) can conveying a response to the contact initiation request (220) to the relying party (205). The response can comprise the identified SCVP staple and a public key infrastructure (PKI) certificate (230) of the certificate issuer. The SCVP staple can validate a certification path between the PKI certificate (230) and a different certificate trusted by the relying party (205).

Abstract: A Public Key Infrastructure (PM) device receives a certificate signing request (CSR) from an end entity. The PKI device obtains at least one of: a controlling attribute of at least one PKI device associated with processing of the certificate signing request and a controlling attribute associated with the CSR. The PKI device obtains an end entity policy object (EEPO) to be associated with the end entity based on at least one obtained controlling attribute. Based on the obtained EEPO, the PKI device determines at least one attribute and at least one value associated with the attribute this is to be included in a certificate and issues, to the end entity, the certificate including the at least one attribute.

Abstract: A certificate management processor (CMP) in a public key infrastructure (PKI) receives a request for a certificate management operation. The CMP determines that the request is associated with at least one of an end entity and a service. The CMP identifies a certificate management identifier associated with at least one of the end entity and the service. The CMP retrieves at least one status associated with the certificate management identifier and/or at least one status associated with the certificate management operation. The CMP performs the certificate management operation on a certificate when the retrieved at least one status is determined to not be suspended.

Abstract: A first communication device having a secure access to a security module establishes a collaborative network by forming a collaborative security association with a second communication device associated with a user of the first communication device. The first communication device (a) sends an advertisement of services associated with the security module to the second communication device and receives an advertisement response from the second communication device or (b) receives a solicitation request for services associated with the security module from the second communication device. Responsive to receiving one of the advertisement response and the solicitation request, the first communication device determines whether the second communication device is authorized to access the security module.

Abstract: A certificate issuer (210) can periodically request, receive, and store current server-based certificate validation protocol (SCVP) staples (225) for supported relying parties (205) from at least one server-based certificate validation protocol (SCVP) responder (215). The certificate issuer (210) can receive a contact initiation request (220) from one of the relying parties (205). Responsive to receiving the contact initiation request (220), the certificate issuer (210) can identify a current SCVP staple from the saved staples that is applicable to the relying party (205). The certificate issuer (210) can conveying a response to the contact initiation request (220) to the relying party (205). The response can comprise the identified SCVP staple and a public key infrastructure (PKI) certificate (230) of the certificate issuer. The SCVP staple can validate a certification path between the PKI certificate (230) and a different certificate trusted by the relying party (205).

Abstract: A first communication device having a secure access to a security module establishes a collaborative network by forming a collaborative security association with a second communication device associated with a user of the first communication device. The first communication device (a) sends an advertisement of services associated with the security module to the second communication device and receives an advertisement response from the second communication device or (b) receives a solicitation request for services associated with the security module from the second communication device. Responsive to receiving one of the advertisement response and the solicitation request, the first communication device determines whether the second communication device is authorized to access the security module.

Abstract: A certificate issuer (210) can periodically request, receive, and store current server-based certificate validation protocol (SCVP) staples (225) for supported relying parties (205) from at least one server-based certificate validation protocol (SCVP) responder (215). The certificate issuer (210) can receive a contact initiation request (220) from one of the relying parties (205). Responsive to receiving the contact initiation request (220), the certificate issuer (210) can identify a current SCVP staple from the saved staples that is applicable to the relying party (205). The certificate issuer (210) can conveying a response to the contact initiation request (220) to the relying party (205). The response can comprise the identified SCVP staple and a public key infrastructure (PKI) certificate (230) of the certificate issuer. The SCVP staple can validate a certification path between the PKI certificate (230) and a different certificate trusted by the relying party (205).

Abstract: A first device initiates a handshake message exchange with a second device according to a security protocol. The first device determines that an application datagram is to be transmitted according to a first transport protocol that limits a size of a datagram based on a defined size. The first device also determines that an application datagram size is larger than the defined size. The first device fragments the application datagram if the application datagram size is larger than the defined size and secures the application datagram with the security protocol. The first device also encapsulates the application datagram fragments in handshake messages, wherein an encapsulated application datagram fragment is transmitted from the first device to the second device in a first security protocol record. The first device may also transmit, to the second device, another application datagram secured with the security protocol.

Abstract: Methods and apparatuses for validating the status of digital certificates include a relying party receiving at least one digital certificate and determining if the at least one digital certificate is to be validated against a private certificate status database. The relying party accesses the private certificate status database and cryptographically validates the authenticity of data in the private certificate status database. The relying party also validates the at least one digital certificate based on information in at least one of the private certificate status database and a public certificate status database.

Abstract: A first device initiates a handshake message exchange with a second device according to a security protocol. The first device determines that an application datagram is to be transmitted according to a first transport protocol that limits a size of a datagram based on a defined size. The first device also determines that an application datagram size is larger than the defined size. The first device fragments the application datagram if the application datagram size is larger than the defined size and secures the application datagram with the security protocol. The first device also encapsulates the application datagram fragments in handshake messages, wherein an encapsulated application datagram fragment is transmitted from the first device to the second device in a first security protocol record. The first device may also transmit, to the second device, another application datagram secured with the security protocol.

Abstract: A relying party obtains a certificate of a certificate subject and acquires a status information object for the certificate. The relying party validates the certificate using information in the status information object and compares authorization attributes present in the status information object with policy attributes associated with the requested service. A policy attribute is a set of constraints used by the relying party to determine if the authorization attributes associated with the certificate subject are sufficient to allow the certificate subject to access the requested service. If the authorization attributes present in the status information object match the policy attributes associated with the requested service, the relying party may grant the certificate subject access to the requested service.

Abstract: A method and device for confirming authenticity of a public key infrastructure (PKI) transaction event between a relying node and a subject node in a communication network enables improved network security. According to some embodiments, the method includes establishing at a PKI event logging (PEL) server a process to achieve secure communications with the relying node (step 705). Next, the PEL server processes reported PKI transaction event data received from the relying node (step 710). The reported PKI transaction event data describe the PKI transaction event between the relying node and the subject node. The reported PKI transaction event data are then transmitted from the PEL server to the subject node (step 715). The subject node can thus compare the reported PKI transaction event data with corresponding local PKI transaction event data to confirm the authenticity of the PKI transaction event.

Abstract: A method and device is provided for dynamically maintaining and updating public key infrastructure (PKI) certificate path data across remote trusted domains to enable relying parties to efficiently authenticate other nodes in an autonomous ad-hoc network. A certificate path management unit (CPMU) monitors a list of sources for an occurrence of a life cycle event capable of altering an existing PKI certificate path data. Upon determining that the life cycle event has occurred, the CPMU calculates a new PKI certificate path data to account for the occurrence of the life cycle event and provides the new PKI certificate path data to at least one of a relying party in a local domain or a remote CPMU in a remote domain.

Abstract: A method and device for distributing public key infrastructure (PKI) certificate path data enables relying nodes to efficiently authenticate other nodes in an autonomous ad-hoc network. The method includes compiling, at a certificate path management unit (CPMU), the PKI certificate path data (step 405). One or more available certificate paths are then determined at the CPMU for at least one relying node (step 410). Next, the PKI certificate path data are distributed by transmitting a certificate path data message from the CPMU to the at least one relying node (step 415). The certificate path data message includes information identifying one or more trusted certification authorities associated with the one or more available certificate paths.

Abstract: A certificate issuer (210) can periodically request, receive, and store current server-based certificate validation protocol (SCVP) staples (225) for supported relying parties (205) from at least one server-based certificate validation protocol (SCVP) responder (215). The certificate issuer (210) can receive a contact initiation request (220) from one of the relying parties (205). Responsive to receiving the contact initiation request (220), the certificate issuer (210) can identify a current SCVP staple from the saved staples that is applicable to the relying party (205). The certificate issuer (210) can conveying a response to the contact initiation request (220) to the relying party (205). The response can comprise the identified SCVP staple and a public key infrastructure (PKI) certificate (230) of the certificate issuer. The SCVP staple can validate a certification path between the PKI certificate (230) and a different certificate trusted by the relying party (205).

Abstract: A relying party obtains a certificate of a certificate subject and acquires a status information object for the certificate. The relying party validates the certificate using information in the status information object and compares authorization attributes present in the status information object with policy attributes associated with the requested service. A policy attribute is a set of constraints used by the relying party to determine if the authorization attributes associated with the certificate subject are sufficient to allow the certificate subject to access the requested service. If the authorization attributes present in the status information object match the policy attributes associated with the requested service, the relying party may grant the certificate subject access to the requested service.

Abstract: A method and apparatus for distributing Certificate Revocation List (CRL) information in an ad hoc network are provided. Ad hoc nodes in an ad hoc network can each transmit one or more certificate revocation list advertisement message(s) (CRLAM(s)). Each CRLAM includes an issuer certification authority (CA) field that identifies a certification authority (CA) that issued a particular certificate revocation list (CRL), a certificate revocation list (CRL) sequence number field that specifies a number that specifies the version of the particular certificate revocation list (CRL) that was issued by the issuer certification authority (CA). Nodes that receive the CRLAMs can then use the CRL information provided in the CRLAM to determine whether to retrieve the particular certificate revocation list (CRL).

Abstract: Methods and apparatuses for validating the status of digital certificates include a relying party receiving at least one digital certificate and determining if the at least one digital certificate is to be validated against a private certificate status database. The relying party accesses the private certificate status database and cryptographically validates the authenticity of data in the private certificate status database. The relying party also validates the at least one digital certificate based on information in at least one of the private certificate status database and a public certificate status database.

Abstract: A certificate manager transmits a certificate service advertisement to a plurality of certificate clients. The certificate service advertisement identifies the certificate manager and includes segregation data. The segregation data indicates a set of services offered or a set of clients for which the certificate manager offers service. Responsive to the transmitting of the certificate service advertisement, the certificate manager receives a certificate service request from at least one certificate client of the plurality of certificate clients. The certificate manager verifies that the at least one certificate client is associated with the set of clients for which the certificate manager offers service, and the certificate manager fulfills the certificate service request.

Abstract: A certificate policy management tool (100) is provided which targets the automated creation of customized certificate policies and the management of these policies within a public key infrastructure (PKI). A certificate policy parser 108, a certificate policy creation engine (110), a policy query engine (112), and an audit engine (114) interoperate to automate certificate policy creation, interpretation, and enforcement.