notaryproject
id-kp-codeSigning EKU restriction for signing certificate.
Discuss if we need to enforce id-kp-codeSigning EKU restriction for signing certificate.
Recommend removing this requirement, as not all signed artifacts will be "code".
Originally posted by @briankr-ms in https://github.com/notaryproject/notaryproject/pull/122#discussion_r798210495
id-kp-codeSigning OID is for "signing of downloadable executable code" per RFC5280, we extend this definition to all signable code (contiguous bits) that is executable code or directly impacts executable code (e.g. XML config file is "executable code"). Supply chain metadata claims or additional artifacts that are not executable code must not be signed with certificates that include the id-kp-codeSigning OID.
@shizhMSFT we might need to bring this issue up during the call. It hasn't seen much traction.
@FeynmanZhou We missed this today, and need to bring this up in the next meeting.
latest spec: https://github.com/notaryproject/notaryproject/blob/main/signature-specification.md#certificate-requirements
I just checked and see here that notation-go is enforcing a check for the signing bit set.
When I try to go through our tutorial and create a certificate without any EKU set, then I get the error message from there:
notation sign --key $KEY_NAME $IMAGE
2022/06/24 11:54:11 signing certificate in generateSignature response.CertificateChain does not meet the minimum requirements: extKeyUsage must contain 3
IMO - We should remove this requirement per @ianjmcm comment above.
One valid comment which came up during the community call yesterday... is if someone wanted to use notation to sign documents, there is another valid EKU for document signing.
Per the discussion on the last call, I believe we came to a consensus that if PR #167 would be implemented, then we could close this out. Then we'd need to fix any place(s) in the code where we enforce the MUST have code signing EKU...
@dtzar - This is a duplicate of #157 . We can close one of them. We need to close out bout #166 and #167 to close both #157 and this one #130
157 is a superset including 130. It seems that everything minus 130 has been resolved in 157. I would propose to close 157 and keep this one open.