IRP Front End – Add IRP to Existing Certificate Authorities
The IRP Front End is a special version of Sixscape Certificate Manager that allows you to add the incredible power of IRP to other Certificate Authorities. With this, your users can use SixWallet to create and submit Certificate Signing Requests (CSRs) to other CAs (not just Sixscape Certificate Manager).
So far, we have created a version that works with EJBCA. We can make it work with any CA that allows submission of a CSR to the CA, and retrieval of the signed certificate, via protocol (e.g. WebAPI). SixWallet allows you to post your certificate to LDAP (or otherwise manage your LDAP entries), as well as a powerful hardware token manager. With IRP Proxy, you can even create key material inside a hardware token, then retrieve the signed certificate and reintegrate it with the private key inside the token. If you would like to add IRP to your existing CA, contact us for details.
It also supports any other IRP-enabled client, such as our SixChat secure instant messaging client, SixMail Addin for Outlook, etc.
The IRP Front End consists of several components from Sixscape Certificate Manager – the PKI Database, the IRP Server, and a trimmed down version of the Management Console and Services Console.
In effect, the IRP Front End can graft the IRP protocol onto any existing CA to provide a secure protocol in addition to any existing mechanisms (e.g. web) for submitting CSRs and retrieving certs.
IRP clients (including SixWallet) support both Username/Password Authentication (UPA) and Strong Client Authentication (SCA). This authentication is based on accounts created in the PKI DB and managed by the Console Management Tool.
Adding IRP Proxy to your existing CA makes it far simpler for you to create secure decentralized deployments, for example, securely submit CSRs and retrieve certificates from a SixWallet client running in a bank branch, against the CA at HQ. You could also allow your customers or employees to use SixWallet directly to manage their own certificates, for Strong Client Authentication, Windows Smartcard Login, IPsec authentication, etc.
Your existing CA still provides approval (or rejection) of CSRs by a Registration Authority (RA Admin), and signing of the approved requests by a Certification Authority (CA Admin). Any automation your backend supports is still fully functional. Your CA provides revocation checking via OCSP and/or CRL as before. Certs chain up to your root cert as before. IRP Proxy just allows a far more powerful and secure way to request certificates, retrieve them, and publish them in LDAP and/or load them into hardware tokens. If your CA is CC or FIPS-140-2 certified, this will not change that. It basically replaces the old way of requesting certs and retrieving them with a browser with a much more secure and powerful scheme, based on our IRP protocol.
IRP supports backup and recovery of key material in PKCS12 form. Those are kept in the PKI_DB on the IRP Front End, not relayed to the back end. Most CAs do not have any way to store key material for users, especially if the key material is created on remote clients. Note that this is not applicable if you create the key material directly into hard tokens (no way to back up private key).
It is also possible to copy the real CA root and intermediate certs to the PKI DB, to allow IRP clients to obtain and install CA certs via IRP.