Signing keys

The Serial Vault provides encrypted storage for signing keys for an account. Signing keys can be generated locally and uploaded, or generated within the Serial Vault. However, signing keys cannot be downloaded from the Serial Vault so the unencrypted signing is never available, so the recommended approach is to generate the key locally. The signing key also needs to be registered with the Brand store so it can be used to verify the signature of serial assertions. The Serial Vault holds the private key, whereas the Brand Store holds only the public key as an account-key assertion.

The steps needed with local key generation and registration are:

  1. Generating the key(s)
  2. Registering the key with the Brand Store
  3. Exporting the key as ASCII-armored
  4. Uploading the ASCII-armored key file to the Serial Vault

The Serial Vault will need the private keys uploaded to its database for the following keys:

  • Key for signing serial assertions
  • Key for signing system-user assertions
  • (if model pivoting is needed) Key for signing model assertions

Although one key can be used for each of these three purposes, it is recommended to use a separate signing key for each type of assertion.

Signing keys that are to be uploaded to the Serial Vault need to be passwordless (i.e. keeping a blank password when generating the key). Using a key that has a password results in an error when uploading the signing key.

However, signing keys cannot be downloaded from the Serial Vault so the unencrypted signing is never available, so the recommended approach is to generate the key locally.

This statement doesn’t really make sense. If a signing key is generated within the SV, its true the private component of this key can’t be downloaded. The public portion of the key is registered by the SV to the brand account, and thus is accessible via assertion.

Also I’m not sure why the inability to access the signing key when generated by the SV is reason to suggest that customers generate serial vault keys locally? The whole idea behind auto-generation of the serial signing key, is that there’s one less key for the brand to managed.

The Serial Vault will need the private keys uploaded to its database for the following keys:

Key for signing serial assertions
Key for signing system-user assertions
(if model pivoting is needed) Key for signing model assertions

Again, see my previous comment about use of SV generated keys for serial assertions.

The ability to sign system-user assertions is also quite limited, so not sure it should be included here?

Also, afaik there is no support in the SV for signing model assertions, so that should be removed.