A general question, can this command be used without a HSM? It doesn't seem so as the help is more centered around the HSM and the TOKEN positional argument is mandatory (which doesn't make sense for a file based key).

# tedge cert create-key 
error: the following required arguments were not provided:
--label <LABEL>
--type <TYPE>

Usage: tedge cert create-key --label <LABEL> --type <TYPE> [TOKEN]

For more information, try '--help'.

Indeed this command only operates on the HSM, so we can change the naming to something like create-key-pkcs11 to make it clear.

Though having a command to create a file based private key would be beneficial as it would allow users to integrate more easily into existing PKI services.

Ideally it would be nice to have one single command but given that there are a few pkcs11 only argments, and don't want users to accidentally create a file based key when they were expecting to create a HSM based key...so with that, I'm ok with calling it the following (though I'm not super thrilled about the name, but I don't have a better suggestion).

tedge cert create-key-pkcs11

About the name: create-key-pkcs11:

• Why pkcs11, while elsewhere we use the term cryptoki?
• Wouldn't create-pkcs11-key be better?
• Personally, I would suggest create-hsm-key, but this introduces yet another acronym.

I don’t mind HSM as it is more user friendly (even with the additional acronym)

renamed to create-key-hsm in 458dc11

Why pkcs11, while elsewhere we use the term cryptoki

I've seen both terms used somewhat interchangably and haven't made an effort to only use one of them for consistency and also used both :/
Looking back, PKCS #11 is the name of the standard, and Cryptoki is the name of the interface defined by the standard.

Wouldn't create-pkcs11-key be better?

I view it as create-key-hsm being an HSM-specific variant of create-key, and if we add a generic create-key command in the future, the suffixed version fits better.
So decided to go with create-key-hsm.

This is way too easy to accidentally create too many keys. This will create two private key objects where both have the token=tedge attribute set

tedge cert create-key --type ecdsa --label tedge "pkcs11:token=tedge"
tedge cert create-key --type ecdsa --label tedge "pkcs11:token=tedge"

But if the user tries to prevent duplications by providing an id attribute, the id attribute is ignored.

tedge cert create-key --type ecdsa --label tedge 'pkcs11:token=tedge;id=other'

Is there a way we can prevent the user from accidentally doing this? e.g. can we check if the key_uri already exists or something before creating another key (similar to how the tedge cert create would fail again if you run it twice)?

A random id is generated such that when running the command twice, with the same parameters, the returned URI will be different.

The TOKEN positional argument is a URI identifying the token, while id attribute is related to objects on the token, so it's not relevant and thus ignored.

We could allow user to provide their id attribute for the key via --id flag, but it's not going to prevent them from making duplicates, but will allow them to make duplicates.

Though we're talking about creating a key for tedge to use, so it should check first if the device.key_uri in the tedge.toml exists, and only create a new key if nothing is found (and ideally use the value defined in the tedge.toml)

Would it also make sense to also allow the user to control the private key's id attribute (in addition to the label)? Would this make it easier for user to identify the unique object?

tedge cert create-key --label tedge --id '3'

We could allow the user to set it, but it would allow the user to generate objects that are not unique and have the same id. Handling these object after could get tricky, particularly p11tool gets confused when operating on objects that have the same URI.

What we do now is generate a random id which we include in the URI, so the object is always unique.

So PKCS11 doesn't reject an object which is created with the same ID? I would of expected that the API would fail somewhere. Plus I would assume that the id would not be globally unique, but only unique within the label (or token).

I still think it is worthwhile allow power-users to set the id value, and then use an autogenerated id by default (though something a bit shorter than the current generation would be nice).

One needs to properly handle the case where the server has not been updated and is not able to create a key. Nothing more can be done than failing the command, but the error message must be explicit and not user-puzzling as currently.

This must explicitly be a new version.

This must added into a new Frame::Version1(Frame1) case.