Relax EKU requirements on signing certificates#167
Conversation
|
Thanks @ianjmcm |
|
Thank you @ianjmcm. Need to sign your commit so it passes DCO check steps to resolve there. |
Signed-off-by: Ian McMillan <54679711+ianjmcm@users.noreply.github.com>
|
@priteshbandi @iamsamirzon @gokarnm - this is ready for merge now passing DCO checks upon one of your approvals. |
|
@ianjmcm the change you are proposing allows Notation to support different types of signed artifacts in a registry, which may have certificates with different EKUs (for code, document, or supply chain metadata like SBOMs). The proposed solution relaxes the code signing EKU check to "MAY" which means it won't be enforced. This can still allow misusing EKU intended for one set of artifacts to be used for other. A longer term solution which will require some standardization may be to derive the enforced set of EKUs based on media type of the artifact being signed. |
7 participants
Softening the requirement on the "signing" certificate (not "codesigning") for the signing of content in the registry to "MAY" contain the codeSign EKU ('id-kp-codeSigning') is the best way to allow for a wider variety of existing certificates and new EKUs to be defined for the signing of content types that are not "software" as defined in RFC 4949. Using code signing certificates (with the codeSign EKU) for signing data objects that are not software or directly related to the execution of software can lead to unintended trust by existing code integrity implementations that rightly require the codeSign EKU. As such, Private PKI owners may want to NOT issue code signing certificates to entities that are signing content in the registry that is not code (e.g. Container descriptors), not requiring the codeSigning EKU allows them to create the right controls on entities allowed to use codesigning certificates vs. entities that should/must not use codesigning certificates.