bug: Validation weaknesses concerning X.509 Key Usage

[baron0426]

Dear osslsigncode Developers,

We are a research group analyzing the compliance of code-signing certificates and related verification tools. During our empirical study, we identified that osslsigncode seems to have validation weaknesses concerning X.509 Key Usage enforcement.

Summary of Findings

Our findings indicate that osslsigncode:

1. Does Not Verify Presence of the Key Usage Extension
   • Certificates lacking a Key Usage extension are accepted for code-signing verification.
   • This implicitly assumes signing authorization when it is not explicitly granted.
2. Does Not Require Key Usage to Be Marked as Critical
   • The verifier does not enforce the criticality of the Key Usage extension.
   • This allows authorization constraints to be ignored without triggering validation failure.
     These behaviors were observed across multiple real-world certificates from different certificate authorities.

Security Impact

As a result, certificates that are:

• Not intended for code signing
• Issued for identity or authentication purposes
• Missing or misconfigured authorization constraints
  can still successfully pass verification, expanding the potential for certificate misuse and abuse.

These observations are part of an academic study on the code-signing ecosystem and reflect our current understanding of the verification logic. Any clarification or feedback would be greatly appreciated. We would also be happy to provide additional details or supporting evidence upon request.

Thank you for your continued work on osslsigncode.

Sincerely,
Hanqing Zhao and Zi-Quan You

[mtrojnar]

@baron0426

The verifier does not enforce the criticality of the Key Usage extension.

I could not find a normative requirement for a code-signing verifier to reject a certificate solely because the Key Usage extension is not marked critical. Can you point to the specific specification/profile you are relying on (and the exact section), e.g. CA/Browser Forum Code Signing Baseline Requirements, Microsoft Authenticode policy, etc.?

As a result, certificates that are:

• Not intended for code signing
• Issued for identity or authentication purposes
• Missing or misconfigured authorization constraints
  can still successfully pass verification, expanding the potential for certificate misuse and abuse.

Please bear in mind that:

• Certificates used for identity/authentication commonly include Key Usage: digitalSignature (often alongside other bits), so Key Usage alone is not sufficient to distinguish them from code-signing certificates.
• While we indeed do not currently check whether the Key Usage extension includes digitalSignature, we do check whether the Extended Key Usage extension includes id-kp-codeSigning. Consequently, for a “Not intended for code signing” certificate to be accepted, it would need to either (a) include id-kp-codeSigning, or (b) omit the Extended Key Usage extension entirely (and still chain to a trust anchor accepted by the verifier’s configured trust store/policy).

See RFC 5280 for details.

We would also be happy to provide additional details or supporting evidence upon request.

Have you found an actual trusted certificate chain that demonstrates the claimed impact under osslsigncode’s verification settings? A file signed with such a certificate and positively verified by osslsigncode (ideally along with the trust anchors / CAfile used) would be great supporting evidence.

[mtrojnar]

@baron0426
Can you please review our fix (#477)?

[baron0426]

Dear mtrojnar,
Thank you for the clarification.
While RFC 5280 indeed allows keyUsage and extendedKeyUsage to be optional in general, our concern is specific to publicly trusted code-signing certificates, which are subject to additional policy requirements.
According to the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates, Version 3.10.0, Section 7.1.2.3 e.:

The keyUsage extension MUST be present and MUST be marked critical, and the digitalSignature bit MUST be set for code-signing certificates.

While CABF CSBR primarily constrain CAs, from our perspective we are interested in whether verifiers might still surface user-facing signals when certificates deviate from common code-signing practices, similar to the Web PKI ecosystem.
From a relying-party perspective, not checking for the presence and criticality of keyUsage means that certificates that do not meet these code-signing-specific requirements may still be accepted, potentially enabling misuse of certificates that are not intended for code signing. To illustrate this, we have provided a real-world example in the attached signed file (which is a trojan and may pose potential risks; please test it in a controlled environment, with the password "infected" to extract the file). The signature of this file is valid, and the keyUsage field of the signing certificate is set to keyEncipherment, dataEncipherment, without the digitalSignature attribute. The certificate was originally not intended for code signing but was maliciously repurposed by attackers for signing malware. Such certificates are easily obtained (any resident or company in Taiwan can apply for them at a very low cost) ,publicly-trusted and often have long validity periods. We believe that when a validator encounters such obviously abnormal certificates, it would be ideal to issue a warning to the user, even if rejection is not required. We would greatly appreciate hearing your thoughts on this issue.

17ad1735a13898c978cc6bbe6b2056cb8471329b.zip

Thank you for your attention to our issue.
Sincerely,
Hanqing Zhao and Zi-Quan You

[baron0426]

@baron0426 Can you please review our fix (#477)?

Dear mtrojnar,
Thank you for your attention to this matter.
We have reviewed your fix (#477) and believe it addresses the case we raised. However, based on the CSBR standards, it is also required that the keyUsage field be present. We recommend triggering an alert for certificates that lack the keyUsage field entirely.
Sincerely,
Hanqing Zhao and Zi-Quan You