The CA/Browser Forum released Ballot CSC-18 to update the code signing certificate revocation requirements in the Code Signing Baseline Requirements (CSBRs). The purpose of the ballot is to align the revocation reasons with the TLS BRs and to provide stricter requirements for revocation due to private key compromise and use in suspect code.

Revocation reason consistency will allow the CAs to have the same response and processes for most revocations regardless of certificate type. The revocation reasons are also similar to those with the S/MIME BRs. CAs issuing code signing certificates also need to address where a certificate has an associated private key that has been compromised or where the private key has signed suspect code. Suspect code may contain malicious functionality or serious vulnerabilities, such as spyware or malware. Suspect code may install without the user’s consent or may resist removal. The code may compromise user security or could be exploited in ways not intended by its designers.

The CSBRs will require certificates associated with compromised private keys or suspect code to be revoked within 24 hours. This will stop any future use of a compromised key or signing of more suspect code. The requirements also allow the CA to change the revocation date to a time earlier than when the revocation occurred. The purpose of backdating the revocation date is to choose a time before the key was compromised or suspect code was signed. With the earlier date, any timestamped signature by the compromised key or on suspect code performed after the date would no longer be trusted.

There is an exception to the certificate revocation requirements. This may apply when an application software supplier, such as Microsoft, requests a delay where immediate revocation has a potentially large negative impact to the code signing ecosystem. An instance may occur where revocation of the certificate will also impact good signatures, which will prevent the associated good code from being installed. A delay would allow the good code to be re-signed with a new private key.

The ballot includes reasons for a root CA to revoke a subordinate CA. These reasons are the same as those specified in the TLS BRs.

Entrust will update its practices to reflect the new ballot, which is effective April 15, 2024.