From Fedora Project Wiki
(Created page with "Category:Packaging_guidelines_drafts For background and motivation please see the [https://fedoraproject.org/wiki/User:Nmav/Pkcs11Status current status of PKCS#11 in Fedo...")
 
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[Category:Packaging_guidelines_drafts]]
[[Category:Packaging_guidelines_drafts]]


For background and motivation please see the [https://fedoraproject.org/wiki/User:Nmav/Pkcs11Status current status of PKCS#11 in Fedora].
This guideline updates the previous [https://fedoraproject.org/wiki/Packaging:SSLCertificateHandling SSLCertificateHandling].
This guideline updates the previous [https://fedoraproject.org/wiki/Packaging:SSLCertificateHandling SSLCertificateHandling].


= Proposal =
= Guideline =


== How to specify a certificate or private key? ==
These guidelines are relevant to packagers which maintain packages which utilize smart cards for loading certificate or private key. Its purpose is to bring a consistency in smart card handling on the OS; for background and motivation see the [https://fedoraproject.org/wiki/User:Nmav/Pkcs11Status current status of PKCS#11 in Fedora].


In April 2015, [https://tools.ietf.org/html/rfc7512 RFC7512] defined a 'PKCS#11 URI' as a standard way to identify such objects. That form should be understood by programs when specified in place of a certificate file. For non-interactive applications which get information on the command line or configuration file, there should not be a separate configuration option to load keys and certificates stored in smart cards, the same option accepting files, should additionally accept PKCS#11 URIs.
== How to specify a certificate or private key stored in a smart card or HSM ==


== How to specify a specific PKCS#11 module ==
In April 2015, [https://tools.ietf.org/html/rfc7512 RFC7512] defined a 'PKCS#11 URI' as a standard way to identify objects stored in smart cards or HSMs. That form should be understood by programs when specified in place of a certificate file. For non-interactive applications which get information on the command line or configuration file, there should not be a separate configuration option to load keys and certificates stored in smart cards, the same option accepting files, should additionally accept PKCS#11 URIs.


Applications should utilize the registered module and MUST NOT require the user to specify a module. See [https://fedoraproject.org/wiki/PackagingDrafts/Pkcs11Support the PKCS#11 packaging information].
== How to specify a specific PKCS#11 provider module for the certificate or key ==
 
Packages which can potentially use PKCS#11 tokens SHOULD automatically use the tokens which are present in the system's p11-kit configuration, rather than needing to have a PKCS#11 provider explicitly specified. See [https://fedoraproject.org/wiki/PackagingDrafts/Pkcs11Support#How_to_specify_a_specific_smart_card.2FHSM the PKCS#11 packaging page] for more information.

Latest revision as of 08:15, 16 December 2016


This guideline updates the previous SSLCertificateHandling.

Guideline

These guidelines are relevant to packagers which maintain packages which utilize smart cards for loading certificate or private key. Its purpose is to bring a consistency in smart card handling on the OS; for background and motivation see the current status of PKCS#11 in Fedora.

How to specify a certificate or private key stored in a smart card or HSM

In April 2015, RFC7512 defined a 'PKCS#11 URI' as a standard way to identify objects stored in smart cards or HSMs. That form should be understood by programs when specified in place of a certificate file. For non-interactive applications which get information on the command line or configuration file, there should not be a separate configuration option to load keys and certificates stored in smart cards, the same option accepting files, should additionally accept PKCS#11 URIs.

How to specify a specific PKCS#11 provider module for the certificate or key

Packages which can potentially use PKCS#11 tokens SHOULD automatically use the tokens which are present in the system's p11-kit configuration, rather than needing to have a PKCS#11 provider explicitly specified. See the PKCS#11 packaging page for more information.