notation
notation copied to clipboard
Ability to relax CA certificate requirements
Is your feature request related to a problem?
Consider an enterprise code signing scenario with an existing private CA and the CA certificate has the key usage extension that was not marked critical during original generation.
When running notation sign the following error occurs:
Error: generated signature failed verification: certificate-chain is invalid, certificate with subject "CN=CA01 I2,OU=Engineering,O=Acme,L=San Jose,ST=CA,C=US": key usage extension must be marked critical
There are private CA deployments that have been in production for a while, and in many cases it is very difficult to re-issue and deploy the updated trust chain to endpoints. This would impact adoption of the notation tool in these types of environments.
It is much easier to update the leaf certificate template in a customer environment, and hence why the focus is on the Issuing CA certificate.
What solution do you propose?
It would be great to add the ability to relax the CA certificate requirements via some notation parameter(s), such that a consumer can proceed with signing while understanding the requirements were not met.
What alternatives have you considered?
There are no alternatives at the moment given that if a customer's CA doesn't meet notation's requirements, and even if the leaf certificates are compliant, they are unable to sign with notation.
Any additional context?
No response
@zosocanuck Thanks for creating this issue, we discussed this issue in the community meeting on Mar 25, 2024. The conclusion is this issue won't be fixed. The reason is: First, it is a base requirement for code signing certificate, see 7.1.2.1 Root CA Certificate. Second, it is not secure if key usage is not marked as critical, since the root CA certificate can be used for different purposes besides codesigning. However, the use of the same key for two different cryptographic processes may weaken the security provided by one or both of the processes. See NIST 5.2 Key usage for details. /cc @priteshbandi @shizhMSFT to comment if any.
This issue is stale because it has been opened for 60 days with no activity. Remove stale label or comment. Otherwise, it will be closed in 30 days.
Issue closed due to no activity in the past 30 days.
I appreciate the question has already been answered above but I might be forced to abandon the Notary Project due to this issue.
My enterprise has a CA root certificate that expires in 2038. There are several "issuing certificates" (e.g. territory x primary and secondary) issued by the root that expire in ~3 years. I've been issued a code signing certificate + key that's stored in Azure KV and managed by a COTS product (Fortanix) - this is rotated daily (via Fortanix) due to an internal control.
All certs in the chain have a non-critical "Key Usage" section with the flags for Digital Signature, Key Cert Sign etc. I cannot ask the enterprise to make this section critical section given the global impact (~1M devices/virtual machines/containers etc).
(RFC5280 s4.2.1.3)[https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.3] states that conforming CAs SHOULD mark this extension as critical. While I accept other standards, like NIST, impose stricter controls, this is at odds with the real world.
I'm presented with the following options:
- update the root CA and chain to mark the section critical - not going to happen
- obtain a new private CA and signing key chain from my enterprise - internally expensive, difficult to justify and manage
- investigate a different tool - tricky without official Azure endorsement
- fork the project - can't justify due to ownership concerns and internal costs
- use self-signed certificates and publish the public key via a microsite for other teams to validate - acceptable short term but violates others policies against self-signed certs in the enterprise
Today, without a policy setting (CLI flag?) that allows me to ignore critical section requirement, I can't use notation.