3

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".

StackzOfZtuff
  • 265
  • 2
  • 8
Mike
  • 85
  • 6

1 Answers1

6

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.

Maarten Bodewes
  • 96,351
  • 14
  • 169
  • 323