PKCS #7/CMS, PKCS #11 and PKCS #15 support

[spacekitteh]

These three crypto standards define standard message formats, and key usage and identification APIs. This will allow much greater interoperability and flexibility.

CMS:

This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. The CMS describes an encapsulation syntax for data protection. It supports digital signatures and encryption. The syntax allows multiple encapsulations; one encapsulation envelope can be nested inside another.

Likewise, one party can digitally sign some previously encapsulated data. It also allows arbitrary attributes, such as signing time, to be signed along with the message content, and it provides for other attributes such as countersignatures to be associated with a signature.

The CMS can support a variety of architectures for certificate-based key management, such as the one defined by the PKIX (Public Key Infrastructure using X.509) working group [PROFILE].

Currently, Olm defines its own message format. This means its data can only be understood by other Olm implementations, even with knowledge of the key.

PKCS #11:

The PKCS#11 standard specifies an application programming interface (API), called “Cryptoki,” for
devices that hold cryptographic information and perform cryptographic functions. Cryptoki follows a
simple object based approach, addressing the goals of technology independence (any kind of device) and resource sharing (multiple applications accessing multiple devices), presenting to applications a common, logical view of the device called a “cryptographic token”.

Cryptoki isolates an application from the details of the cryptographic device. The application does not have to change to interface to a different type of device or to run in a different environment; thus, the application is portable.

PKCS #15:

PKCS #15 establishes a standard that enables users in to use cryptographic tokens to identify themselves to multiple, standards-aware applications, regardless of the application's cryptoki (or other token interface) provider.

It is widely recognized that cryptographic tokens such as Integrated Circuit Cards (ICCs or Smart Cards) offer a great potential for secure identification of users of information systems. But if this potential is ever going to be fully realized, and users are to receive full benefit of these tokens, there is an obvious requirement of credential portability and interoperability.

Interoperability demands standardization, and this document, PKCS #15, is intended at establishing a standard which ensure that users in fact will be able to use cryptographic tokens to identify themselves to multiple, standards-aware applications, regardless of the application's cryptoki (or other token interface) provider.

Why is PKCS #11 not sufficient?
The PKCS #11 specification alone can not offer this functionality since it is an API specification aimed at offering applications a uniform interface to cryptographic tokens. This means that different tokens requires different PKCS #11 drivers, and unless a user's desktop has the 'right' PKCS #11 driver installed, the user will be unable to use the token on that desktop.

PKCS #11/#15 are what are used by numerous existing applications to manage and use, respectively, crypto tokens (a.k.a. keys), whether they be X.509 certificates or PGP keys on a Yubikey.

For example, in the triple Diffie-Hellman key exchange scheme, Alice and Bob's device keys (A and B in the picture) could be either signed by their respective global identity keys using PKCS #15, or they could use their global identity keys in lieu of device keys (which would, however, mean compromised devices compromise everything much easier). This would be an option to trade deniability for authenticity; however, PKCS #15 isn't limited to global identity keys - it could just as easily be used for accessing a TPM to create both device and ephemeral keys.

From what I understand, OpenSSL and LibreSSL can both support all of these (related: #3). If one of these is chosen to be used for crypto primitives, then it would be fairly straightforward to enable these three standards.

[Ralith]

If #1 is fixed, would it make sense to implement this as a separate layer on top of the core?

[spacekitteh]

I think it would, yes - at least for PKCS #7/CMS, which is just about message formatting.

I'm not sure about 11/15, though. Would it make sense to build on top of them, or would it make sense for them to be on top of the core? Or both?

It definitely makes sense to be able to access crypto tokens in the core, so in that sense the core should be on top of #15, but yeah. Not entirely sure.