Looking Back at 2023

2023 was a year of change for Public Trust Certificates – discussions on reduced validity periods, approval of new requirements, and significant progress in access to Verified Mark Certificates. Let’s review what happened in 2023 along with a few predictions for what’s to come in 2024.

TLS Certificates

The Google Chrome team was quite active in the TLS ecosystem. They began promoting modernizing PKI infrastructures including reducing the TLS certificate validity period to 90-days. Entrust provided our response to the 90-day proposal. The Chrome team also provided the market with information to help secure TLS PKIs through automation for a safer more reliable internet.” You can then hyperlink the word “information.

The CA/Browser Forum (CABF) published ballots which updated the TLS Baseline Requirements (BRs):

• SC61 – New Certificate Revocation Lists (CRL) entries must have a revocation reason code
• SC62 – Certificate profiles update for the requirements and restrictions of the TLS certificate profiles
• SC63 – Makes OCSP optional, require CRLs, incentivizes automation, and finally approves short-lived certificates, which do not require certificate status using CRL or OCSP

The IETF has published RFC 9345 to support delegated credentials for TLS and DTLS. The delegated credential mechanism allows a server operator to use the private key from their server to issue a delegated credential. The new credential will have a different private key and a validity period of no greater than seven days. Since the delegated credential is only valid for a short period of time, there is no status protocol required to be checked, that is, no CRL or OCSP response.

S/MIME Certificates

The CABF approved the S/MIME Baseline Requirements in November 2022, which provides an S/MIME standard for the public trust CAs. The S/MIME BRs have been effective since the September 1, 2023. ETSI also released standard ETSI TS 119 411-6 to comply with the EU regulation on electronic signatures in email messages and to support the S/MIME BRs. This allows EU CAs meeting the S/MIME BRs to be audited using the ETSI audit criteria. The S/MIME BRs were also required by the Apple and Mozilla policies.

DigiCert provided an S/MIME certificate factory with samples of certificates which meet the S/MIME BRs. They followed up with the pkilint tool, which can be used for S/MIME certificate linting to find errors when a certificate does not meet the S/MIME BRs. Entrust fully supports digital certificate linting  and its deployment.

Code Signing Certificates

The CABF began requiring code signing certificate keys to be generated and managed in a crypto device effective as of June 1, 2023. The goal is to reduce key compromise by removing the option to generate key pairs in software. The CAs must also verify if the keys were generated in a crypto device which would include server HSMs, USB tokens and cloud HSMs.

Ballot CSC68 was issued to update the code signing certificate revocation requirements. The purpose was to tighten up the procedure when a key is comprised, or if a subscriber signs suspect code. If the CA finds out that either of these occurred, then the certificate must be revoked within 24 hours. At a later time the CA may backdate the revocation time before the key was compromised or the suspect code was signed. This will cause signatures after the revocation date to fail.

Verified Mark Certificates

Government organizations can now get Verified Mark Certificates (VMCs) for their outgoing emails. This is equivalent to VMCs issued to companies which have registered marks. Google also strengthened VMCs by adding a blue checkmark which proactively indicates the sender of the email has verified that it owns the domain and the logo displayed in the avatar slot.

VMCR 1.5 was released create Common Mark Certificates. This will allow a certificate applicant to submit either a modified registered mark or a prior use mark to be added to the certificate. The modified registered use mark will allow an applicant with a registered mark to make a change such as removing/moving words or removing a portion of the mark. This may allow the applicant to modify the mark to fit in place with different dimensions or perhaps provide a seasonal change to the mark. For prior use mark, the applicant must have historically displayed the mark for at least 12 months and the mark must be found in an archive webpage source. The Common Mark Certificate beta program has just started in December 2023. Note: we are not sure if both Google and Apple will fully support common marks and emails will not get the blue checkmark.

Mozilla sets Root CA Lifecycles

To support cryptographic agility which Mozilla states is the ability to replace cryptographic primitives, algorithms, and protocols efficiently at reasonable cost with limited impact on operations, Mozilla has set a lifecycle schedule for trusted root certificates. There is a migration plan for existing roots, but the ongoing schedule will be from the date of key generation, a TLS root will be removed after 15-years and an S/MIME root will be removed after 18-years. The lifetime will allow the CA time to get the root embedded and at least 10 years of use. The S/MIME roots have a longer lifecycle as S/MIME certificates are issued with a longer validity period.

To 2024 and Beyond 

Here are some expected changes for 2024.

TLS Certificates

The CABF TLS validation subcommittee is working on multi-perspective issuance corroboration to ensure when verifying a domain name that the determinations made by the primary network perspective is correct before a TLS certificate issuance. Multi-perspective determination will be applied to both domain names and Certification Authority Authorization (CAA)record compliance. We anticipate multi-perspective will migrate to a “must” requirement in 2025.

Code Signing Certificates

The CABF code signing working group is working on updates for Signing Services and high-risk certificate applications. Signing Service will help the certificate subscribers to be complaint and ensure their key pairs are generated in a cryptographic module, the private key is protected, and only the subscriber can activate the private key for signing. The high-risk certificate application has been changed as now all key pairs must be generated in hardware, which mitigates some of the risks that were addressed in the CSBRs.

Key attestation is a method for the CA to verify that the private key was generated in a cryptographic module. There is no standard for key attestation, so this is difficult to implement. Members of the IETF are working on addressing this issue by generation an RFC for CSR attestation and for X.509 based attestation evidence. CSR attestation can be implemented with existing crypto modules and the RFC may be available in 2024. X.509 based attestation will take longer to define and would need to be implemented in new cryptographic modules; as such, we do not expect to benefit from this effort for many years.

S/MIME Certificates

The IETF publish RFC 9485 which supports certification authority authorization (CAA) for S/MIME certificates. This will support domain name owners to provide the CAA record “issuemail” for their authorized CAs. The CABF S/MIME working group is developing on an update for CAA as a recommendation in late 2024 and a “must” requirement in 2025.

And, there you have it – a brief look at an active year in the public trust certificate ecosystem. Find out more about how Entrust can help you manage your digital certificate here.

The post Public Trust Certificates: A 2023 Recap and Projections for 2024 appeared first on Entrust Blog.

*** This is a Security Bloggers Network syndicated blog from Entrust Blog authored by Bruce Morton. Read the original post at: https://www.entrust.com/blog/2024/01/public-trust-certificates-a-2023-recap-and-projections-for-2024/