Add option for creating code-signing certificates.

[aebruno]

This commit adds support for signing certificates with the codeSigning extended key usage extension. Tried to make this as non-invasive as possible by adding a new function to create host certificates api with an optional array of []x509.ExtKeyUsage. This should allow adding support for other extended key usages in the future. For now, just added a simple boolean flag to the sign command with turns this on.

[CLAassistant]

All committers have signed the CLA.

[mcpherrinm]

What uses this? Is this like, windows kernel driver codesigning? Are there other uses?

Do codesigning certificates need the other options? Like, do you ever want to set --domains and ---ip addresses for codesigning?

[JalonSolov]

Code signing certificates are use to sign Windows drivers, executables, dlls, .cab (archive) files, PowerShell scripts, etc., etc. Also used to sign Java jars, wars, ears, ... you can even sign XML files and other things.

https://en.wikipedia.org/wiki/Code_signing

[aebruno]

@mcpherrinm Apologies for the late reply. I realize this is probably an uncommon use case and may fall outside the scope of certstrap. If so, completely understand not wanting to support this and feel free to close the PR.

What uses this? Is this like, windows kernel driver codesigning? Are there other uses?

For some more background on our specific use case, we're currently using a code-signing certificate to sign binary kernel/initrd images for use with iPXE. We wanted an easy tool to manage certificates and found certstrap to be a perfect fit. For more details on how we use certstrap see here.

Do codesigning certificates need the other options? Like, do you ever want to set --domains and ---ip addresses for codesigning?

I believe what makes a code-signing certificate is just adding the codeSigning extended key usage extension. So could possibly have any options that a normal certificate could have?

[mcpherrinm]

One of the design goals here is to make it hard to misuse certstrap, by only providing common options. While it would be possible to have an IP SAN with codesigning EKU set, is that something that would be done in practice?

I would like to avoid supporting theoretical use-cases so we can focus on proving a sensible set of features, and figure out how to support them.

There's another PR open for supporting setting arbitrary EKUs by name or OID, would that suffice for your use-case?

[aebruno]

There's another PR open for supporting setting arbitrary EKUs by name or OID, would that suffice for your use-case?

Yes, supporting setting EKUs should be sufficient and likely much more generic (assuming you're referring to #57).