Le Standard PKCS#11 obtient un RFC: 7512

Un RFC vient de sortir dans la plus grande discrétion sur la norme technique PKCS#11 qui est utilisé sur pas mal de boitiers de cryptographie ou plus connus sous le nom barbare de HSM. Ce RFC vient d’être publier sur le site de l’IETF et il est disponible en téléchargement. Il permet enfin d’avoir un protocole de communication standard sur l’ensemble des HSM ou presque 🙂

Ce standard permet à un logiciel de récupéré une clé publique stockée dans une base de données (HSM dans notre cas). Nous avons enfin un standard/et ou une norme technique. Nous allons pouvoir enfin basculer nos composants sur des HSM standardisés au niveau des protocoles de communications. Fini les HSM BULL, THALES, IBM…avec leurs normes maisons 🙂

Dans le cas des entreprises qui sont soumis à PCI DSS et qui utilisent des HSM nous allons pouvoir utiliser des briques applicatives qui pourront mutualisé leurs demandes sur les clusters d’HSM.

C’est cool..and fun love it this RFS 7512…

Bienvenue à pkcs11:object=cle-de-moi;type=public;id=%69%95%3E%5C%F4%BD%EC%91 et à ses amis.

Un billet très complet sur le blog de Stéphane Bortzmayer

http://www.bortzmeyer.org/7512.html

Le site de l’IETF : https://www.ietf.org/

Le lien du RFC : http://www.rfc-editor.org/rfc/rfc7512.txt

 

L’introduction du RFC en anglais (la traduire serait un gâchis)

PKCS #11 v2.20: Cryptographic Token Interface Standard » [PKCS11] specifies an API, called Cryptoki, for devices that hold cryptographic information and perform cryptographic functions.
Cryptoki (pronounced « crypto-key » and short for « cryptographic token interface ») follows a simple object-based approach, addressing the goals of technology independence (any kind of device may be used) and resource sharing (multiple applications may access multiple devices),
presenting applications with a common, logical view of the device –a cryptographic token.

It is desirable for applications or libraries that work with PKCS #11tokens to accept a common identifier that consumers could use to identify an existing PKCS #11 storage object in a PKCS #11 token, an existing token itself, a slot, or an existing Cryptoki library (also
called a producer, module, or provider). The set of storage object types that can be stored in a PKCS #11 token includes a certificate; a data object; and a public, private, or secret key. These objects
can be uniquely identifiable via the PKCS #11 URI scheme defined in this document. The set of attributes describing a storage object can contain an object label, its type, and its ID. The set of attributes that identifies a PKCS #11 token can contain a token label, manufacturer name, serial number, and token model. Attributes that can identify a slot are a slot ID, description, and manufacturer. Attributes that can identify a Cryptoki library are a library manufacturer, description, and version. Library attributes may be necessary to use if more than one Cryptoki library provides a token and/or PKCS #11 objects of the same name. A set of query attributes is provided as well.

A PKCS #11 URI cannot identify other objects defined in the specification [PKCS11] aside from storage objects. For example, objects not identifiable by a PKCS #11 URI include a hardware feature
and mechanism. Note that a Cryptoki library does not have to provide for storage objects at all. The URI can still be used to identify a specific PKCS #11 token, slot, or an API producer in such a case.

A subset of existing PKCS #11 structure members and object attributes was chosen to uniquely identify a PKCS #11 storage object, token, slot, or library in a configuration file, on a command line, or in a configuration property of something else. Should there be a need for a more complex information exchange on PKCS #11 entities, a different means of data marshalling should be chosen accordingly.

A PKCS #11 URI is not intended to be used to create new PKCS #11 objects in tokens or to create PKCS #11 tokens. It is solely to be used to identify and work with existing storage objects, tokens, and slots through the PKCS #11 API, or to identify Cryptoki libraries themselves.

The URI scheme defined in this document is designed specifically with a mapping to the PKCS #11 API in mind. The URI scheme definition uses the scheme, path, and query components defined in the « Uniform Resource Identifier (URI): Generic Syntax » [RFC3986] document. The URI scheme does not use the hierarchical element for a naming authority in the path since the authority part could not be mapped to PKCS #11 API elements. The URI scheme does not use the fragment component.

If an application has no access to a producer or producers of the PKCS #11 API, the query component module attributes can be used.  However, the PKCS #11 URI consumer can always decide to provide its own adequate user interface to locate and load PKCS #11 API
producers.

Enjoy 🙂