Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: custom Common Name #362

Open
dhouck opened this issue Aug 14, 2024 · 6 comments
Open

Feature Request: custom Common Name #362

dhouck opened this issue Aug 14, 2024 · 6 comments
Labels
enhancement New feature or request

Comments

@dhouck
Copy link

dhouck commented Aug 14, 2024

A common name of just Platform Key, Database Key, or Key Exchange Key isnʼt very descriptive. If you might have multiple sets of keys for some reason (multiple computers, different levels of trust, etc.), it can get confusing which keys are which. It looks like this could be worked around with the import-keys option, but it would still be useful to be able to pass an option to create-keys that provides a more detailed name.

@Foxboron Foxboron added the enhancement New feature or request label Aug 21, 2024
@servies
Copy link

servies commented Nov 13, 2024

Isn't that already possible by means of the config file?

@dhouck
Copy link
Author

dhouck commented Nov 13, 2024

I donʼt think so. If you generate keys some other way you can then use the config file to point sbctl at them (or put them in the directory sbctl expects), but if you use sbctl to generate keys they will have the same common name every time.

@servies
Copy link

servies commented Nov 13, 2024

look at the function CreateKeys(...) in backend.go.
The description per key is being used (c.Keys.PK.Description etc). If it is empty the default name is eventually being used in createKey(...)
My sbctl.conf looks like this:

keydir: /var/lib/sbctl/keys
guid: /var/lib/sbctl/GUID
files_db: /var/lib/sbctl/files.json
bundles_db: /var/lib/sbctl/bundles.json
landlock: true
db_additions:

  • microsoft
    keys:
    pk:
    privkey: /var/lib/sbctl/keys/PK/PK.key
    pubkey: /var/lib/sbctl/keys/PK/PK.pem
    type: file
    description: My Company Platform Key
    kek:
    privkey: /var/lib/sbctl/keys/KEK/KEK.key
    pubkey: /var/lib/sbctl/keys/KEK/KEK.pem
    type: file
    description: My Company Key Exchange Key
    db:
    privkey: /var/lib/sbctl/keys/db/db.key
    pubkey: /var/lib/sbctl/keys/db/db.pem
    type: file
    description: My Company Database Key

The result after generation is something like:
the result from openssl x509 -in PK.pem -text:

Certificate:
Data:
Version: 3 (0x2)
Serial Number:
ed:be:eb:35:7c:50:27:d5:72:6a:3f:c9:d0:aa:06:cd
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = My Company Platform Key, CN = My Company Platform Key
Validity
Not Before: Nov 5 14:43:43 2024 GMT
Not After : Nov 5 14:43:43 2049 GMT
Subject: C = My Company Platform Key, CN = My Company Platform Key
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
....

@Foxboron
Copy link
Owner

Ah, so I did wire this up. I probably forgot to add this to the readme.

@dhouck
Copy link
Author

dhouck commented Nov 13, 2024

It isnʼt in sbctl.conf(5); I did try to look at the code but must have missed that. Is there also a command line option to sbctl create-keys? It seems like it might be useful there instead of a config file.

@Foxboron
Copy link
Owner

It isnʼt in sbctl.conf(5); I did try to look at the code but must have missed that. Is there also a command line option to sbctl create-keys? It seems like it might be useful there instead of a config file.

No, not yet. I need to consider how metadata around keys should be exposed as flags in the CLI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants