Xorble
Public Key Infrastructure as a Service (PKIaaS) - Certificates from the Cloud


Terms and Conditions

Terms and Conditions

Walkthrough Guides

How to Logon to Xorble
How to Enrol and Download an Encryption Certificate
Xorble Web Service Proxy installation


Frequently Asked Questions (FAQ)

Question Answer
What is Xorble? Xorble is a Public Key Infrastructure as a Service provider (PKIaaS) based on a public PKI with a series of Certification Authorities located in the cloud.
What are the aims of Xorble? To provide easy to consume certificates for consumer and enterprise use for a range of authentication, signing and encryption purposes.
How can I use Xorble to secure email? Xorble provides certificates for securing email and these certificates can be used to provide secure email using the S/MIME standard that most devices support.
What is a certificate? Each certificate contains a unique public key together with identity information (usually email address) that allows you to encrypt data, to digitally sign data or to authenticate.
Where is Xorble based? Xorble is based in the UK.
Where are the Xorble servers located? Short answer – In the Cloud. Longer answer, at present, in the Microsoft Azure Cloud in the UK, in the Northern and/or Western UK data centres. See http://azure.microsoft.com/en-us/regions for more information.
What types of certificates can be issued? Initially two main certificates types are available for public consumption, the first of which is a combined authentication and signing certificate and the second is a general purpose encryption certificate.
What types of Cryptography are used? There are two distinct Xorble hierarchies, the first of which uses traditional RSA cryptography (http://en.wikipedia.org/wiki/RSA_(cryptosystem)) while the second uses the more modern, more secure/faster Elliptic curve cryptography (http://en.wikipedia.org/wiki/Elliptic_curve_cryptography). The RSA key hierarchy uses 2048 bit keys with SHA 256 hashes while the ECC key hierarchy uses ECDSA 384 bit with SHA 384.
Should I use RSA or ECC Cryptography? RSA 2048 bits and ECC at 384 bits are both considered strong for most purposes. RSA is somewhat slower/weaker than ECC but has the major advantage of working with most systems. There is still quite patchy support for ECC and hence the use of RSA is recommended at present although this situation should change as ECC support becomes more widespread.
How do I login to the site? Open the www.Xorble.com web site and login by selecting the login button. You will need a cloud based identity from Microsoft, Facebook or Google or an existing Xorble Authentication Certificate.
How do I start using certificates? After login to the site, select “My Certificates”. This will show a list of all your certificates. If there are no suitable certificates in the list simply select one of the create buttons to create a certificate. By default authentication and signing certificates and keys are generated server side and these are then wrapped as a PKCS#12 password protected file (PFX/P12) that can be downloaded to the client. The private keys for these are held for five minutes on the server before being deleted which is normally enough time for users to download them.
How do I get a certificate for authentication or signing? Creating new signing and authentication certificates is typically performed on each unique device that a user owns.
How do I get a certificate for encryption? By default encryption certificates and keys are generated server side and these are then wrapped as a PKCS#12 password protected file (PFX/P12) that can be downloaded to the client. The private keys for these are by default archived permanently so that they can later be downloaded to other devices. A user will generally only have a single encryption certificate that is used across multiple devices. This approach allows the same encrypted content (e.g. email) to be accessed by a user across multiple devices.
Where are my private keys held? Encryption keys are stored as encrypted blob with the CA database.
How can I delete my private keys from the servers? By selecting the “Delete Keys” option, the archived keys for a certificate are deleted from the database. Before doing this make sure you have a backup of the keys stored securely somewhere as otherwise you may be unable to decrypt encrypted data.
How do I delete a certificate? By selecting the Revoke and Delete option beside a certificate, the certificate is removed from the database, the archived keys (if present) are deleted and the certificate is revoked. You cannot delete a certificate without revoking it. After deletion only the serial number and revocation time of the certificate is held in the database and all other information about it is removed.
How do I manage contact encryption certificates? After logon, select the “my contacts” menu option. For each contact that you need an encryption certificate for, enter the contact email address and then select Create. An encryption certificate for the user is automatically generated and the public certificate for the user can downloaded and added to the contact in programs such as Outlook.
How does the Outlook Add-In help? The add-in for Outlook automates most of the configuration of Outlook to allow signing and encrypted email to be sent. The add-in creates an S/MIME profile for the current user and generates and installs two certificates (one for signing/authentication) and one for encryption. The add-in also installs the certificate chain so that the certificates are trusted. Lastly for each contact object, the add-in generates an encryption certificate and associates this encryption certificate with the contact.
What does the organizations menu do? This is for future use and is initially not available.
What is an advanced request? The advanced request allows users to generate certificates based on Base64 encoded PKCS#10 request files. This option allows certificates to be requested where the private keys are created and maintained on the client (and never available on the servers). In future additional certificate profiles will be made available this way.
How is it licensed? Free for consumer use. In future organisations will require a licenses to take advantage of additional functionality.
Why the complex three tier hierarchy? The hierarchy is designed to provide the scalability and flexility required for Internet scenarios. There are two separate hierarchies each with a Root CA, one for RSA and one for ECC certificates. Within each hierarchy, there is at present a single intermediate organizational Certificate Authority but the model allows each multiple intermediate Certificate Authorities with each one dedicated to an organisation. The issuing Certificate Authorities are dedicated to a single DNS namespace and there can be multiple Issuing CAs subordinated below a single intermediate organisation CA. It is believed (and hoped) that this model will scale to almost any conceivable size of organisations, DNS namespaces and end entity certificates.
How does a client chain build to a Root CA Certificate? The system publishes all CA certificates into a publically readable Azure Blob store. This approach allows an almost unlimited number of CAs to be created and still scale.
How does a client obtain an encryption certificate for a user? The system publishes the issued public encryption certificates of users into a publically readable Azure Blob store. The certificates for contacts are downloaded from this store.
How is revocation checking performed? The system publishes an Online certificate Status Protocol (OCSP) service and a Certificate Revocation List (CRL) service. The OCSP service is provided by a web farm of responders. OCSP responses are obtained directly from the CA database and not from CRLs. The CRLs are served from Azure Blob storage and are published on a relatively longer timescale, typically a CRL will be valid for 20 days.
How are the Xorble Object IDs (OIDs) Organised? Xorble has a base OID value of 1.3.6.1.4.1.50589. The Subsidiary OID of 509 is used for all PKI purposes (X509 Certificates) All RSA Certificates are from the OID 1.3.6.1.4.1.50589.509.1 while ECC certificates include 1.3.6.1.4.1.50589.509.2. Root CA Certificates have a Subsidiary OID of 1, Organisation CAs of 2 and Issuing CAs of 3. End Entity (User) Certificates have a Subsiiary OID of 4.
What about Certificate Policies and Practice Statements? There are placeholder URLs defined for CPSs for the root, intermediate and Issuing CAs. These are http://pki.Xorble.com/pki/RootCAPolicy.htm, http://pki.Xorble.com/pki/OrganisationCAPolicy.htm, http://pki.Xorble.com/pki/IssuingCAPolicy.htm and http://pki.Xorble.com/pki/EndEntityPolicy.htm but at present as not populated.
What extensions are included in SMIME Certificates? The SMIME Profile is a general purpose Signing and Encryption certificate. This can be used for encrypted email and signing email. Key Usage (KU) is set to Digital Signature, Key Encipherment (0xa0) Extended (Enhanced) Key Usages (EKU) = { Encrypting File System (1.3.6.1.4.1.311.10.3.4), Secure Email (1.3.6.1.5.5.7.3.4), BitLocker Drive Encryption (1.3.6.1.4.1.311.67.1.1) }
What extensions are included in Encryption Certificates? Key Usage (KU) is set to Data Encipherment (0x10) Extended (Enhanced) Key Usages (EKU) = { Encrypting File System (1.3.6.1.4.1.311.10.3.4), Secure Email (1.3.6.1.5.5.7.3.4), BitLocker Drive Encryption (1.3.6.1.4.1.311.67.1.1) }
What extensions are included in Signing and Authentication Certificates? Key Usage (KU) is set to Digital Signature (0x80) Extended (Enhanced) Key Usages (EKU) = { Client Authentication (1.3.6.1.5.5.7.3.2), Secure Email (1.3.6.1.5.5.7.3.4) }
Certificate SANs? The Subject Alternative Name (SAN) for all Issued user certificates includes the user’s email (RFC822 name) and the email is also set on the User Principal Name (UPN). This allows the certificate to be used for both signing and authentication. This approach also assumes that the email address and the UPN of a user are the same.
User Certificate Subject Name? End entity certificate subject names are derived from the user’s email address. Specifically, the common name is the part of the email before the @ symbol. The Organisation part of the subject name is set to the domain name. The Subject also includes the domain components (DC=). An example subject name would be as follows: CN=jane.doe, O=Xorble.com, DC=Xorble, DC=com
Who is Jane Doe and why is she on all certificate images? Jane Doe is used as an example name - See http://en.wikipedia.org/wiki/John_Doe for more details.
Where is the cloud image from? The cloud image was taken from the Aiguille du Midi in August 2011 - http://en.wikipedia.org/wiki/Aiguille_du_Midi and https://www.Xorble.com/Content/P1000859.JPG