non-repudiation key usage for sub ca

[jwh]

Hi guys,

I'm trying to sign a sub-ca (for freeipa) that includes non-repudiation key usage, but I can't figure out what the correct string is (if not I guess I need the ID but have no idea what that is either) - how can I go about including that in my existing IPA template?

thanks

[tashian]

Hi @jwh,

You'll want to use the key usage called "contentCommitment" for this.
It's the same bit flag as "non repudiation", it's just been renamed in the X509 spec.

I love that you're using step-ca with FreeIPA. When you get it all working, would you be willing to post your certificate template(s) and any caveats / gotchas here for posterity?

Carl

[jwh]

Hi, awesome thanks - when I get it working I'll absolutely post it here, I think we're almost there bar this flag which I'll fix when I'm in the office tomorrow - just out of curiosity, is it possible to force signing with the root instead of intermediate in a template to avoid increasing the pathlen?

Thanks!

[tashian]

Hi @jwh, step-ca never touches the root key; it can only sign with its intermediate. So, you will need to bump the path lengths if you're minting CAs.

[jwh]

Thought as much, I'll bump pathlen too and give it another go later, thanks!

[jwh]

Just a random thought, might it be worth adding pathlen args to step cli ca init (assuming some dynamic variable can be injected into the template definitions in crypto/x509util/templates.go)? It's kinda hacky doing it manually, or am I missing something?

[maraino]

The maxPathLen can be edited in the templates and they can be increased or set to unlimited -1 (for roots mainly). I think it makes sense to add the --path-len to step certificate create imitating the flag in step certificate sign.

I don't see the point of adding it to step ca init as it is quite easy to replace the roots/intermediates with one created using the above commands, which can also use templates for extra configuration options.

[jwh]

True, just for create will probably be useful enough

[jwh]

Just as a follow up, I ended up deploying step-ca with FreeIPA sub-ca using the following:

root.tpl

{
        "subject": {"commonName": {{ toJson .Insecure.CR.Subject.CommonName }}},
        "issuer": {"commonName": {{ toJson .Insecure.CR.Subject.CommonName }}},
        "keyUsage": ["certSign", "crlSign"],
        "basicConstraints": {
                "isCA": true,
                "maxPathLen": -1
        }
}

intermediate.tpl

{
    "subject": {"commonName": {{ toJson .Insecure.CR.Subject.CommonName }}},
	"keyUsage": ["certSign", "crlSign"],
	"basicConstraints": {
		"isCA": true,
		"maxPathLen": 2
	}
}

ipa.tpl

{
    "subject": {{ toJson .Insecure.CR.Subject }},
    "keyUsage": ["keyEncipherment", "digitalSignature", "contentCommitment", "certSign", "crlSign"],
    "extKeyUsage": ["serverAuth", "clientAuth"],
    "basicConstraints": {
        "isCA": true,
        "maxPathLen": 1
    }
}

As this is deployed via Ansible, it made sense to use a JWK provisioner, which I amended with the following:

        "options": {
          "x509": {
            "templateFile": "templates/ipa.tpl"
          }

Hope this helps someone else!

[tashian]

Thanks @jwh for sharing! Glad you got it working.

[jwh]

Yup, overall there weren't any caveats other than FreeIPA external CA support being a bit lacklustre, thanks for your help!