PIV: X.509 key usage option for certificates and CSRs

[episource]

Adds a key usage option to PIV self-signed certificates and CSRs, in both the GUI (dropdown in the slot's Certificate section) and keyroostctl (--key-usage on piv self-sign and piv request-cert). The selection is written as a X.509 keyUsage extension.

• Choose any of the X.509 usages, several at once, or undefined, which writes no extension (just like current KeyRoost does unconditionally)
• Slot default selects the PIV profile for the slot (CLI: default).
• Warns about key usages incompatible with the slot's key.

[n0xena]

according to 5280 section 4.2.1.9 Basic Constraints

Conforming CAs MUST include this extension in all CA certificates that contain public keys used to validate digital signatures on certificates and MUST mark the extension as critical in such certificates.

So if we start to play around with extensions it becomes quite more complicated quite fast.
I'm playing around with certificates for years know and hence read through 5280 and its updates many times about what to include where.
The above quote requires for basicConstraints be present if keyUsage is set to keyCertSign. Also: In such context both extensions should be critical as well.

I do appreciate the work and it makes it simple to play around with tokens even more by introducing x509 - but should keyroost really become some gui certificate manager? If at all I would put this as some form of external like an extension or plugin or even its own application.

[episource]

To test PIV, support for some extensions is crucial. Key Usage is just a prominent example I've started with, as this is evaluated by my KeePass plugin. Indeed, supporting all PIV-mandated extensions makes the UI more complex. Not all extensions are of practical relevance, though. To keep the UI lean, only a practical subset may be incorporated.

Supporting certificate extensions in the PIV module would not be specific to Key Roost; HID's Crescendo Manager has nicely implemented this as well (screenshots in section New Keys & Self-Signed Certificates).

The "Basic Constraints" extension you've cited is optional for PIV, as ordinary PIV certificates are commonly end-entity certificates. The PIV standard document FIPS201 referenced/required Federal PKI policy therefore marks "Basic Constraints" as optional and requires CA=false if it is present (see e.g. worksheet 6). But using a PIV key as an lightweight/minimal HSM for a CA might be a tempting and valid use case outside the strict PIV certificate profile. But how far KeyRoost wants to support this is a different question. The FIPS201 required strict Non-CA profile is effectively relevant/required for US government applications only.

[n0xena]

Oh, wasn't aware of PIV specifics when it comes to x509 - but since I started to play around with PIV I somewhat phased out this whole "US" stuff - as I don't care about such over here in europe (and in fact, if at all, would rather focus on europe specifucs if such exists).

[framefilter]

Thanks @episource! I do have a couple thoughts, welcome your input:

1. You have the GUI pre-select "Slot default" while the CLI defaults to no extension. I'd like them to function same/similarly. I think both should default to "Undefined" so a GUI self-sign matches the CLI, unless there's something I'm missing. Are you okay with that or should we go a different direction?
2. For an Ed25519 key in 9D or the retired slots, "Slot default" sets keyAgreement, which Ed25519 can't do. Should it fall back to no usage there?

We'll add the changelog entry when we merge, and will hold and rebase #165 once #163 and #164 are merged in to avoid causing you a bunch of pain.

[episource]

Thanks for catching the ED25519 issue. I've just relied on the PIV defaults, but missed that there is one specific ECC algorithm not supporting Key Agree. I've fixed this.

Regarding the CLI's default: I'd rather prefer default here too. I did not go that way already, because it would change CLI semantics of existing scripts with the next release. Don't know if you care while keyroost is still in the v0-era.

[framefilter]

Thanks @episource! You convinced me: "Slot default" will be the default everywhere.
I’ll make that change once it’s merged in, along with the migration note, so nothing more needed from you here. Regarding changing CLI semantics in the v0.x era, I’m still trying to find the correct balance between letting the user scriptify things, good manual UX, feature parity between CLI and GUI, and having as much consistency as possible between the features. EG if features are similar I don’t want one model to use —disregard when others use —ignore (made up illustrative example). With the breadth of devices keyroost is attempting to support, I’d rather break things now to get them right, and get feedback from supportive early adopters. If I just bandaid everything now and then make massive changes later, that seems like a pretty frustrating thing for an established user base.