x509-cert: rework certificate builder profiles

baloo commented 9 months ago

I tried to abide by the ETSI policy. https://www.etsi.org/deliver/etsi_en/319400_319499/31941202/02.03.01_60/en_31941202v020301p.pdf

The policy recommends to make KeyUsage bits 0, 1, (2 and/or 4) exclusive. This is meant to avoid making signing of commitments during authentication.

This commit goes a bit further by making bit 2 and 4 exclusive. I don't find a use-case for requiring both at the same time (and I would think only key agreement is required.

Fixes #1281 Fixes #1392

baloo commented 9 months ago

cc @lumag

lumag commented 9 months ago

I took a glance a the GOST certificate which is used in the signature on my Ham license. It has:

        Key Usage (critical):
            Digital signature.
            Non repudiation.
            Key encipherment.
            Data encipherment.

lumag commented 9 months ago

Some justification. GOST is one of 'national' PK schemes. The corresponding X.509 parts are described in RFC 4491 and RFC 9215. Certificates can be used for both digital signatures, key agreement and key transport, see RFC 4490.

carl-wallace commented 9 months ago

I don't think I've seen nonRepudiation and keyEncipherment together before as the latter often is accompanied by escrow of the private key. I've not caught up yet to current release to try it out but the PR looks OK.

baloo commented 9 months ago

We still allow the use to set nonRepudiation and keyEncipherment by relying on the x509_cert::builder::Profile::Manual this is behind the hazmat feature flag.

I think that's in line with the security note from ETSI:

NOTE 2: [security note] Combining the non-repudiation bit (bit 1) in the keyUsage certificate extension with other
keyUsage bits can have security implications depending on the security environment in which the
certificate is to be used.
If the subject's environment can be fully controlled and trusted, then there are no specific security
implications. For example, in cases where the subject is fully confident about exactly which data is signed
or cases where the subject is fully confident about the security characteristics of the authentication
protocol being used.
If the subject's environment is not fully controlled or not fully trusted, then unintentional signing of
commitments is possible. Examples include the use of badly formed authentication exchanges and the use
of a rogue software component.

lumag commented 9 months ago

That note talks about the nonRepudiation bit. However I'm more concerned about mixing of other usage bits. For example RFC 3279 section 2.3.5 (also see errata 6672). It explicitly allows any combination of digitalSignature, nonRepudiation and keyAgreement. Even if we apply the mentioned note from ETSI standard, we should allow digitalSignature + keyAgreement.

This extends to GOST certs which can have digitalSignature + keyEncipherment + dataEncipherment.

lumag commented 9 months ago

Forr the reference, RFC 4055 allows keyEncipherment and dataEncipherment, but explicitly tellls that those two bits SHOULD NOT be used together.

baloo commented 9 months ago

yeaaah, there is more to this story. https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-v2.0.1.pdf#page=80 (7.1.2.7.11 Subscriber Certificate Key Usage)

I'll revisit this.

There are also code signing certificates, with different requirements.

baloo commented 8 months ago

@tarcieri can I ask for your opinion on this trait based approach? I'm not done yet. I'd like to also provide a set of implementation for code-signing profiles and get a PIV profile as well.

tarcieri commented 8 months ago

@baloo as a general direction it looks great!

baloo commented 4 months ago

I intend to merge this tomorrow, unless someone has something to say about it.

RustCrypto / formats

x509-cert: rework certificate builder profiles #1306