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

Test branch for HSM support #139

Draft
wants to merge 6 commits into
base: main
Choose a base branch
from
Draft

Conversation

kushaldas
Copy link

How to try this branch?

Follow instructions to install the HSM related modules.

ca commands

  • cd ca

Next create a local_settings.yaml file for HSM usage.

DEBUG: true
SECRET_KEY: dummy
ALLOWED_HOSTS:
  - localhost

# django-ca configuration
CA_DEFAULT_HOSTNAME: "localhost:8000"
CA_ENABLE_ACME: true
CA_ENABLE_REST_API: true

# Set to true if you want to use Celery
CA_USE_CELERY: false
CA_KEY_BACKENDS:
  default:
    BACKEND: django_ca.key_backends.hsm.HSMBackend
    OPTIONS:
      storage_alias: django-ca
  • python manage.py migrate
  • python manage.py init_ca --path-length=1 --subject-format=rfc4514 Root CN=Root --key_label root_key_hype --hsm_key_type rsa_4096

Open questions

  • How to reuse the current command line flags for key type and key length?
  • Right now choosing any other key type will trouble in various different commands as the algorithm is wrong. It should be sha256 for RSA20248 and None in other cases. How to fix this?

@mathiasertl
Copy link
Owner

How to reuse the current command line flags for key type and key length?

Two very good questions, with two answers:

  1. The key type: you already can! create_private_key() already receives the key_type parameter. that's exactly that.
  2. The key length: This is the same as for the EC curve and the password. The CLI arguments currently come from the storages backend (unlike key type, which is added by the command class itself). So currently you cannot reuse them!

I'm a bit torn on if I should move key length, EC curve and maybe even password back to the command class. The upside would be a simpler CLI interface. The downside is that you cannot influence the parameters anymore in a custom backend. What if your backend supports a different set of EC curves then cryptography - as seems to be the case here? The "shared" CLI argument would still have to allow all curves (in case you choose the cryptography backend), but of course you could still throw an error in case of an unsupported curve.

What do you think?

Right now choosing any other key type will trouble in various different commands as the algorithm is wrong. It should be sha256 for RSA20248 and None in other cases. How to fix this?

That's easy to fix! raise django_ca.management.base.CommandError in get_create_private_key_options(). Ideally, you also add proper model validation in your Pydantic model.

@mathiasertl
Copy link
Owner

FTR, this is curently blocked by SUNET/python_x509_pkcs11#24 being merged.

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

Successfully merging this pull request may close these issues.

None yet

2 participants