3
$\begingroup$

I'm confused by the wording of the PKCS#11 v2.40 specification in terms of when CKA_TRUSTED can be set to true on a public key certificate object:

The CKA_TRUSTED attribute cannot be set to CK_TRUE by an application. It MUST be set by a token initialization application or by the token’s SO. Trusted certificates cannot be modified.

I'm trying to reconcile "cannot be set to CK_TRUE by an application" and "It MUST be set [...] by the token's SO". Does this mean a R/W SO session can create (or update) a Public Key Certificate Object (e.g. CKC_WTLS) with CKA_TRUSTED set to CK_TRUE? I feel this doesn't jive well with "cannot be set [...] by an application".

Improve this question
$\endgroup$

1 Answer 1

Reset to default
6
$\begingroup$

In general an application - a program that uses the token for cryptographic operations - is supposed to use CKU_USER, not CKU_SO.

The CKU_SO is supposed to be used by the security officer. Of course, the only way that the SO can generally communicate with the token is through some kind of management application - sometimes combined with an authentication device such as an external PIN pad connected to an HSM. And yes, usually it is possible to write a management application yourself; it is of course dubious at best to mix that into an application that uses the key material stored within the token (especially if you also integrate the login credentials).

And yes, the SO can generally set trust on certificates. The SO is responsible for making sure that they can be trusted after all.

There can be tokens where the trust cannot be set at all. For instance smart cards may have a specific PKCS#11 interface where no management operations are applicable whatsoever.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Thank you. I think my confusion was how PKCS#11 defines what an 'application' is. I took it as anything using the Cryptoki API, which a management application may use but could use other interfaces accessible only to an authenticated CKU_SO user. So I feel in general that: 1.) Support for the CKA_TRUSTED attribute is optional, but if it is supported then, 2.) It can be set but only by a CKU_SO and not through the standard Cryptoki API application. $\endgroup$
    – Mike
    Commented May 23, 2018 at 10:45
  • 1
    $\begingroup$ Being the SO is a question of authenticating as SO, so if the application authenticates as such then yes, it is a cryptoki application and yes, the application can then change the attribute. SO is part of the cryptoki API after all, and you'd use standard calls for it. It would however not be a user application, that fulfills a specific use case. Some HSM's have an admin user on top of an SO by the way, generally those use proprietary API's. $\endgroup$
    – Maarten Bodewes ♦
    Commented May 23, 2018 at 11:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.