4 Certificate types

4.1.1 Certificate types are characterised by combining a specific but extensible set of qualifiers:

• Certificate class, (cQUALIFIER): PASSPORT or BUSINESS CARD or ASSOCIATE or ANONYMOUS

• Certificate storage (sQUALIFIER): SMART-TOKEN, PROXY

• Certificate purpose (pQUALIFIER): ACCESS or (ID, [SIGN,] ENCRYPT)

4.1.2 Certificates are typically used for ACCESS or ID. An ID certificate may also include SIGN and/or ENCRYPT functionality.

4.1.3 Note that in the context of this document, the term Certificate types is used to differentiate among certificate used for slightly different purposes and which have different rules around their use, issuing and reliance; they are thus formally different certificate policies and will have different Policy OIDs, but will be governed by the same Certificate Policy.

4.2 Qualifier meanings

4.2.1 PASSPORT: As per current Certificate Policy. Individual is identified using Gatekeeper 100 point system and certificate is not tied to a particular organisation - The DN O field is left blank.

4.2.2 BUSINESS-CARD: As per current Certificate Policy. The DN O field is populated with the organisation of the individual, the user is identified in the CN Field by the name they are known to the organisation. Certificate request has been approved by a Sponsor delegated from CE of organisation. Email address can only be issued if domain name in control of organisation. Used to show that the individual represents the organisation - as if they were presenting a business card.

4.2.3 ASSOCIATE: As per current Certificate Policy. The O field must include the name of the organisation but may be different, e.g. Associate of The Treasury. Use of organisation name in O controlled as per BUSINESS-CARD. The OU will typically contain a disclaimer to differentiate it significantly from a BUSINESS-CARD style certificate. Typically used when an organisation wishes to control issuing of certificates to those outside the organisation interacting with it.

4.2.4 ANONYMOUS: A certificate that does not identify its use, e.g. with just a number in the CN field. If a private key is lost together with its certificate, the details of the certificate will give no clue to what it may unlock. May optionally include the organisation name.

4.2.5 SMART-TOKEN: The private key associated with the certificate is stored in a non-exportable form on a hardware token as per Certificate Policy.

4.2.6 PROXY: The private key is stored on a gateway server acting on behalf of the individual, e.g. email gateway signing or proxy authentication to a server.

4.2.7 ACCESS: Grants access to a resource. For example to a particular web based application, or to a laptop.

4.2.8 ID: Specifies that the certificate is intended to be used for identifying the user, for example for authentication to a web based application. The "digital signature" key usage flag should be set.

4.2.9 SIGN: Specifies that the certificate is intended to be used for digitally signing information for long term verification, for example a digitally signed email message or document. The "non-repudiation" key usage flag should be set.

4.2.10 ENCRYPT: Specifies that the certificate is intended for use in encrypting information for the certificate owner. The "key encipherment" key usage flag should be set.

4.3 Alignment with S.E.E. PKI

4.3.1 For the purposes of the S.E.E. PKI, Passport, Business Card or Associate certificates are the same as the first three Certificate types (see Implementation below).

4.3.2 Proxy and Access certificate types typically trade-off reduced trust in identity, for greater flexibility in meeting business needs, for reasons such as automatic on-the-fly certificate generation (proxy e-mail) or wide shared distribution (access to corporate laptops).

4.3.3 Therefore, only Associate certificates are suitable for Proxy and Access uses. To ensure stronger Access security, an Associate private key may be put on a hardware based token.