pkcs15-init: no support for CKA_CERTIFICATE_CATEGORY

[minfrin]

Problem Description

The PKCS11 standard defines CKA_CERTIFICATE_CATEGORY to allow certificates to be marked as user tokens, ca certs, or other certs.

pkcs15-init does not set this attribute, which creates interoperability problems.

Any software that is looking for certs with CK_CERTIFICATE_CATEGORY_TOKEN_USER (for example) won't find anything, and certs are weirdly missing.

Proposed Resolution

Allow the CKA_CERTIFICATE_CATEGORY to be specified / calculated (user token if public/private key is present, CA if this is a CA, to be decided exactly how this works), end entity if it's someone else's cert.

Steps to reproduce

Add a certificate with:

pkcs15-init --store-certificate intermediate.crt

See that CKA_CERTIFICATE_CATEGORY is missing for this cert.

[dengert]

The closest thing PKCS#15 has is:

"6.1.14 CommonCertificateAttributes
CommonCertificateAttributes ::= SEQUENCE {
iD Identifier,
authority BOOLEAN DEFAULT FALSE,
...

The authority field indicates whether the certificate is for an authority (i.e. CA or AA) or
not."

pkcs15-init could have another parameter to set the authority Boolean. The certificate and private key can be written in either order.

Many cards supported be OpenSC are not PKCS#15 cards. So in this case the certificate would need to be parsed to set the the CKA_CERTIFICATE_CATEGORY.

"user token if public/private key is present"

Should be: "user token if private key is present".

The x509v3 basicConstrant: CA:true and X509v3 Key Usage: Key Cert Sign would indicate a CA.
https://stackoverflow.com/questions/5795256/what-is-the-difference-between-the-x-509-v3-extensions-basic-constraints-and-key

Pull requests are welcome.

[frankmorgner]

This sounds like a useful feature. @minfrin feel free to provide a pull request!

[frankmorgner]

Closing this issue due to inactivity. Please re-open the ticket if more input is available.