OpenPGP extension for PKCS #11

This is a technical proposal for an extension of the Cryptoki or PKCS #11 specification with OpenPGP support. Although anticipating inclusion in the real specification, it is described below as a bottom-up movement, that any HSM vendor can easily implement today. Might it end up in the formal standard, then the transition will be very easy to make.

Why support OpenPGP in Cryptoki?

Specifications exist to unleash OpenPGP-based TLS and thus to secure Internet connections in another way than throught the PKIX. It could be said that we have X.509 PKIs and that these suffice to secure the Internet. In practice, this is not the case. A large part of that is the complexity of a full-blown PKIX:

OpenPGP is complex to get into when the Web Of Trust is used. For people understanding these principles, the OpenPGP system has always been preferred on account of its direct, personal approach to security. However, perfectly viable approaches to validate OpenPGP keys are possible now that we can assume that everything that requires transport security is connected to the Internet. The new system envisioned here is about checking identity at the time a secure connection is required, so in realtime rather than use the "batch processing" one-time checks that are performed with a PKIX.

Such a system requires good security support, and can do with hardware acceleration. These are two reasons to improve OpenPGP support in HSMs and, therefore, in the PKCS #11 API that defines them. The work is not even so difficult — there merely is a need for an extra certificate type that can be stored together with the private keys; existing private key facilities suffice. Given that, and the ability to validate OpenPGP certificates in realtime, there are no more disadvantages:

The code implementing Cryptoki support for OpenPGP Public Key Objects overlaps can be completely the same as the code for X.509 Certificate Objects; we do suggest a few optional changes that might be enforced in a formal extension to the Cryptoki specification.

This specification exists to permit HSM vendors to jump on board. The changes are extremely straightforward – and the potential benefits are enormous.

Compatibility Guaranteed

The proposal made here uses vendor extensions, so it will never conflict with the Cryptoki specification. In addition, it chooses a value that is highly unlikely to already occur in any current numbering or naming plan of cryptographic token vendors, so it would be possible for each of them to adopt this specification without modification.

The last 3 bytes spell out "PGP" in ASCII characters, and are not likely to be in use anywhere. The inclusion of the Vendor Defined mask is the formally permitted way to extend the formal Cryptoki definitions.

Using the same value across HSM implementations makes it possible for implementations to start using HSMs for OpenPGP. It is quite possible that servicing this profile would be considered quality mark or even a selection criterium for your HSM when this situation arises.

In short, this specification is kind to HSM vendors, as well to application programmers.

Minimal changes to existing Cryptoki implementations

There hardly is a thing to change for cryptographic token vendors who wish to embrace this specification.

Might this specification end up in Cryptoki specification, then treating it would merely be a matter of accepting two identifiers for the OpenPGP certificate type. Being fully in charge of the internals of the HSM, it would be possible to keep the internal state in some form, while accepting two identifiers for certificate searches.

Supporting Implementations

The intention here is, in true PGP style, to work bottom-up in a co-operative manner, gearing towards a specification that is widely implemented in HSMs and then incorporated into the Cryptoki standard with a new tag.

Extensions to the Cryptoki specification

Below are the changes to the sections and appendices of Cryptoki. We use section names instead of numbering to be less dependent on versions of the specification. Editorial comments are printed in italics.

Certificate Objects / Definitions / Overview

One kind of certificate should be mentioned in the overview.

The CKA_CERTIFICATE_TYPE attribute may not be modified after an object is created. This extension of Cryptoki supports the following certificate types:

X.509 public key certificate
WTLS public key certificate
X.509 attribute certificate
OpenPGP public keys (with user identities and certificates)

Certificate Objects / Definitions / OpenPGP public key objects

This is a completely new section, heavily inspired by the "X.509 public key certificate objects" section and on the to date most recent OpenPGP specification, RFC 4880.

OpenPGP certificate objects (with certificate type CKC_OPENPGP) hold an OpenPGP public key, defined as a Transferrable Public Key in section 11.1 of RFC 4880. Future specifications may expand on the permitted structures, which must than be incorporated into a future version of this specification.

The OpenPGP standard packets that are concatenated to form a Transferrable Public Key are, in terms of RFC 4880:

one Public Key packet
zero or more Revocation Signatures
one or more UserID packets
- zero or more Signature packets on each UserID packet, following it directly
zero or more User Attribute packets
- zero or more Signature packets on each User Attribute packet, following it directly
zero or more Subkey packets
- one Signature packet on each Subkey packet, following it directly
- zero or one Revocation Signature packet on each Subkey packet, following directly after its Signature packet

The byte-level formatting is defined in RFC 4880. Note however, that this specification advises to use modern versions of the byte format for new keys, and that the prominent advantage of PKCS #11 is private key shielding, which is only possible for newly generated keys; for that reason, applications of this profile may limit themselves to just these new binary representations:

Applications may choose to not interoperate with the Old Format Packet Lengths of section 4.2.1 of RFC 4880;
Applications may choose to not interoperate with the Version 3 Signature Packet Form of section 5.2.2 of RFC 4880;
Applications may choose to not interoperate with the Version 3 Public-Key Packet Format specified in section 5.5.2 of RFC 4880.

Finally, the transport of OpenPGP Public Key material between an application and an implementation of this Cryptoki extension is in binary format; the Conversion to radix-64 speficied in section 2.4 of RFC 4880 is not applied.

The following table defines the OpenPGP certificate object attributes, in addition to the common attributes defined for this object class:

Table: OpenPGP Certificate Object Attributes

Attribute	Data type	Meaning
`CKA_SUBJECT`^[1]	Byte array	One of the User-ID values enlisted in this public key
`CKA_ID`	Byte array	Fingerprint value for this key, in binary format (default empty)
`CKA_ISSUER`	Byte array	One of the User-ID values signing for the `CKA_SUBJECT` User-ID (default empty)
`CKA_SERIAL_NUMBER`	Byte array	Binary representation of the Key ID as specified in section 12.2 of RFC 4880 (default empty)
`CKA_VALUE`^[2]	Byte array	Binary representation of a Transferrable Public Key conforming to section 11.1 of RFC 4880 (default empty)
`CKA_URL`^[3]	RFC 2279 string	If not empty this attribute gives the URL where the complete certificate can be obtained (default empty)

[1] Must be specified when the object is created.

[2] Can only be empty if CKA_URL is empty.

[3] Must be non-empty if CKA_VALUE is empty.

The following specifications for X.509 Certificate Objects are not needed for OpenPGP Certificates, and may not occur in them:

CKA_HASH_OF_SUBJECT_PUBLIC_KEY would hold the same information as the CKA_ID
CKA_HASH_OF_ISSUER_PUBLIC_KEY is a quick index term designed for X.509's single-signer model
CKA_JAVA_MIDP_SECURITY_DOMAIN is part of an infrastructure has not been specified for OpenPGP

Only the CKA_ID, CKA_VALUE, CKA_ISSUER, and CKA_SERIAL_NUMBER attributes may be modified after the object is created.

The CKA_ID attribute is intended as a means of distinguishing multiple public-key/private-key pairs held by the same subject (whether stored in the same token or not). (Since the keys are distinguished by subject name as well as identifier, it is possible that keys for different subjects may have the same CKA_ID value without introducing any ambiguity.)

The CKA_ID attribute is also intended to couple one Private Key Object with multiple OpenPGP Certificate Objects that may be used as separate User ID representations. It is important that the Public Key packet incorporated with such separate User IDs is not modified, not even the timestamp, as that would lead to a different fingerprint and thus a different CKA_ID value. In normal use, the CKA_ID cannot be set until the Private Key Object has been established.

When multiple Public Key Objects representations are created to distinguish User ID values, then the subject names of those representations are going to differ between the Private Key Object and (some of) the Public Key Objects. Cryptoki does not enforce these to be the same, and it is possible that the Private Key Object leaves the CKA_SUBJECT attribute empty.

The CKA_URL attribute enables the support for storage of the URL where the certificate can be found instead of the certificate itself. Storage of a URL instead of the complete certificate is often used in mobile environments.

The CKA_ID attribute is used to store the fingerprint of the Public Key Object. This is particularly important when only the URL is available to be able to correlate a public key with a private key and when searching for the certificate of the issuer.

Appendix. Manifest Constants

One new definition is added, for now as a vendor-defined constant with high probability of being globally unique across implementations.

The following definitions can be found in the appropriate header file.

#define CKC_X_509           0x00000000
#define CKC_X_509_ATTR_CERT 0x00000001
#define CKC_WTLS            0x00000002
#define CKC_VENDOR_DEFINED  0x80000000
#define CKC_OPENPGP         (CKC_VENDOR_DEFINED|0x00504750)

Author, copyright

Various useful suggestions to early versions of this specification were made by Rickard Bellkrim, who originally developed SoftHSM for the OpenDNSSEC project.

Work at OpenFortress centers around the introduction of cryptography in mainstream usage patterns of the Internet, and the approach is to exploit cryptographically strong primitives in ways that are intuitive to end-users. Technologies serving such needs include OpenPGP, PKIX, OpenSSH, Kerberos. Samples of past work are the development of PKCS #11 based tooling and services, for instance our work with SURFnet on their DNSSEC infrastructure and the OpenDNSSEC project.

Permission is hereby granted to use this text under a Creative Commons License, however your are kindly requested to not modify the part "Certificate Profile".

Parts of this specification were based on the public versions of the standards PKCS #11 and RFC 4880. They were made in the spirit of these standards, and are therefore assumed to be within the intentions of these publications.

OpenPGP extension to PKCS #11