Inpriva

Certificate Authority and Identity Services

Inpriva has designed its identity management and Certificate Authority services (“Inpriva-CA”) in such a way that the Certificate Authority services can be considered a subset of the identity management services.  These CA services may be “private labeled” so that the “CA” that is presented to the world may be designated by you. The CA may issue Digital Certificates intended for different purposes and that reflect different Certificate Policies—e.g. Direct Digital Certificates and Digital Identity Certificates (supporting digital signatures). The Inpriva-provided CA services can issue digital certificates cross-certified to the Federal Bridge and referencing a Certificate Policy that reflects the identity proofing and assurance policies required by you. A related identity management service is secure two-factor, person-centric authentication that allows a provider to be proofed once but use that same identity to gain authorized access to sensitive healthcare resources across organization boundaries.

Policies and Procedures
Inpriva closely follows the policies and procedures required by the “X.509 Certificate Policy For The Federal Bridge Certification Authority (FBCA)” (“FBCA Certificate Policy”) published by the Federal Public Key Infrastructure Policy Authority and available at http://www.idmanagement.gov/fpkipa/documents/FBCA_CP_RFC3647.pdf . In addition, Inpriva will enforce any more specific policies and procedures specified in the Certificate Policy Profiles referenced in its certificate policies or those of your company.

Registration Authority
Customers may serve as the Registration Authority (RA) for the Inpriva-CA and would have primary responsibility for establishing Subscriber identity either directly or through designated qualified Trusted Agents or approved procedures allowing an entity certified and authorized by a State or Federal Entity to confirm identities (e.g. a Notary Public). The identity proofing will conform to FBCA Medium Assurance Level (maps to NIST Level 3).
Both Inpriva-CA and your company, in its capacity as an RA, must enforce the policy and procedure requirements as specified in the FBCA Certificate Policy. Individuals representing your company-RA must be proofed to FBCA Medium Assurance Level and authenticated using two-factor methods upon login to the Enrollment System. Initially, we will provide two-factor authentication using one time password (OTP) hard tokens in a manner compliant with the OpenID and OAuth specifications.
Inpriva also provides OpenID-compliant and OAuth-compliant services that allow the Subscriber to create an OpenID Identifier and bind it to the Inpriva-CA proofed identity. This Identifier together with an OTP hard token is used to provide the two-factor authentication required for access to the Enrollment System. Inpriva can optionally provide support for the use of PKI-based credentials, which may be preferred in some cases.

Certificate Expiration
As a digital certificate’s expiration date approaches, the Inpriva-CA can be configured to send out notification emails to interested parties. Configurable parameters for the notifications include recipient(s), message content, date, relative date (with respect to expiration) and frequency. Default schedules can be established and these can be modified by the RA Administrator.
If the existing digital certificate has not expired, the Subscriber can access their Inpriva-CA account, either by going to the the Inpriva-CA website directly or by following a link provided in a email expiration notice send to the Subscriber. After the Subscriber affirms that no material changes have occurred and makes any payment required, Inpriva-CA will revalidate as necessary and flag the digital certificate as extended and reissuable. The Subscriber’s HISP may then submit a request to renew the Subscriber’s Direct Digital Certificate. Optionally, notifications of the renewal of the digital certificate may be sent to the Subscriber’s designated HISP.

Certificate Revocation
Many situations or events may result in the need to revoke a digital certificate. Depending on the circumstances, the revocation may be initiated by Inpriva-CA or the Subscriber. For example, the Inpriva-CA may need to revoke a certificate due a change in status of a proofed attribute or a compromise of a CA private key. Reasons that the Subscriber may request a revocation or reissue include private key compromise, a change in HISP, a change in sponsored employee status or changes in a proofed attribute. Depending on the situation, the request for a revocation or reissue may come directly from the Subscriber, through your company-RA or from a HISP acting as the agent for the Subscriber.
Inpriva utilizes redundant logging with cryptographically enforced integrity checking to ensure critical key material is only utilized in authorized transactions. Key material itself are created and stored in FIPS-certified Hardware Security Modules (HSMs). Policy, subscriber and relying party agreements require key material outside the contol of Inpriva to be protected to minimal standards which may include the use of FIPS-certified hardware devices to protect private keys. Any violations require revocation of corresponding certificates.
Certificate revocation processes follow the requirements of the FBCA Certificate Policy. Publish of certificate revocation status to OCSP servers and Certificate Revocation Lists (CRLs) is carried out according to applicable technical specifications and standards
CRLs are generated and published daily. However, the Inpriva-CA can optionally publish more frequently if required by emerging federal policy and guidelines. Certificate revocation status is published in near real-time using the Online Certificate Status Protocol (OCSP).
Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP) are both available to other systems in accordance with requirements of the FBCA Certificate Policy. Digital Certificates issued by the Inpriva-CA include fields referencing the location of published CRLs and the real-time OCSP service.