Allow greater configurability of X.509 Certificate attributes

[dopey]

Allow greater configurability of X.509 Certificate attributes

Many attributes of X.509 Certificates are hardcoded when creating a new cert. e.g. key usage, path len, signature algorithm, etc.

The primary reason for hard-coding sane values was to make the cli easy to use and hard to misuse (by selecting attributes that could weaken the effectiveness of the certificates).

However, another important goal is to have a product that has sane defaults but is highly customizable. So, to make the selection of attributes for an X.509 certificate customizable we propose using a JSON template for Certificates and CSRs as input to the step cli that would allow granular configurability.

Let us know if you think this is a good idea or a bad idea; if you have suggestions or apprehensions; or if you'd like to propose a different idea that addresses the problem.

We'll update this issue once work on this ticket begins and we begin thinking about how to structure the JSON.

[ericnorris]

As a specific example, I would be interested in using step certificate create to create a root certificate with the X.509 Name Constraint extension set. It would be much easier than remembering the openssl incantation.

[mmalone]

@ericnorris cool! Yes! This is high on our priority list. We're definitely going to do it... at some point :)

The bulk of the work for us here is doing the research and deciding what the best interface is for specifying certificate details. Our best idea at this point is to use a JSON-based representation of a certificate that can be passed in from file via the --profile flag. We'd probably also support something like --profile - so you can pipe stuff in.

Then the question is: what should that JSON representation be? There's nothing standard here, as far as I know. There are two existing implementations of similar ideas we've found. One is cfssl, which implements basically the same thing and has their own JSON format. Another is zcertificate, part of the bigger collection of zmap tools. We're using the zmap-based format when you do step certificate inspect --format json foo.crt, so I'm a bit biased in that direction. I think it's a more complete representation, but it's also a little more verbose and probably harder to grok.

Any thoughts on this stuff would be appreciated!

I'm also super interested in your use of name constraints. Name constraints seem super useful for building complex PKIs with multiple intermediates that can only sign for subsets of names. But do existing libraries enforce this? Or are you rolling your own code to enforce this stuff?

[ericnorris]

That's great to hear! I spent at least a couple hours figuring out / recalling how to get openssl to do this.

I don't have any strong opinions to the JSON configuration, but I can answer the following:

I'm also super interested in your use of name constraints.

Happy to share - my immediate use case would be for creating a CA that can only issue certificates for our development VMs. This would make the root CA private key much less sensitive, as now you could only impersonate another development VM as opposed to bank.com.

Re: enforcement, I would be relying on browsers to enforce this, as that would be the primary attack vector if you were to MiTM another developer. My understanding (based on the results of https://nameconstraints.bettertls.com/) is that modern browsers have this built in, but I would be happy to be corrected.

[mmalone]

I spent at least a couple hours figuring out / recalling how to get openssl to do this.

Heh. Sorry :(

for creating a CA that can only issue certificates for our development VMs... make the root CA private key much less sensitive...

What a responsible thing to do! I hope the devs appreciate you :)

I would be relying on browsers to enforce this... My understanding (based on the results of https://nameconstraints.bettertls.com/) is that modern browsers have this built in

Huh. TIL. That looks credible. I'm pretty surprised by the level of support! Thanks for the tip!

For your use case it definitely makes sense. Even if some clients don't enforce correctly you'll get some benefit from the ones that do.

FYI... I'm sure you've realized this already but you can definitely generate a root & intermediate key pair / cert using some other tool (e.g., openssl) then switch to step & step-ca for generating the leaf certs. Obviously this is not ideal and we need to add the --profile stuff, but figured I'd mention it.

[strausmann]

can we expect progress here again? We are considering changing our Windows CA to smallstep.

[maraino]

@strausmann @dopey I believe certificate templates addressed this issue.

On step-ca you can configure templates by provisioner. On step you cannot use a template on step ca init, but you can use them on step certificate create and step certificate sign. And then replace the ones created by step ca init with the new ones.

There is some docs about Name Constraints in templates here https://smallstep.com/docs/step-ca/templates#adding-name-constraints

[dopey]

@maraino Can we close this?

[maraino]

Closed with certificate templates. See https://github.com/smallstep/cli/issues/110#issuecomment-1449131088