����TV

An has been proposed to the Internet Engineering Task Force (IETF) to . If accepted, for the first time, there will be a specific EKU for the important use case of digital signatures.

There is an accelerating trend in public trust PKI to separate issuing Certificate Authorities (CAs) by the types of digital certificates they create. This is typically accomplished by the EKU extension included in end entity certificates.

The focus began in the work of the CA/Browser (CA/B) Forum, whose standards for TLS/SSL and code signing certificates dictate the separation of those use cases by CA. The trend gained additional emphasis alongside a recent Mozilla request that CAs plan to replace their existing Root CA certificates with new versions reflecting current community standards. In response, many CAs are moving away from the “general use” hierarchies of the past and separating CAs by their use case.

While this housekeeping is widely considered beneficial from a compliance and standards perspective, it has highlighted an issue. General purpose EKU for x.509 certificates are defined by the IETF in RFC 5280 and include general purpose EKU such as id-kp-serverAuth and id-kp-clientAuth for TLS, and id-kp-codeSigning for code signing. However, there has never been a defined EKU for document signing.

As a result, the majority of document signing certificates have adopted the general purpose id-kp-emailProtection EKU, which is properly intended for S/MIME certificates, even if the certificates do not include an email address. Alternatively, CAs may use private EKU such as provided by individual signing platforms.

The issue is coming to a head due to two forces. First, the burgeoning popularity of platforms like AdobeSign, DocuSign and ����TV’s Document Signing Manager are driving mass market adoption of document signing. And second, industry efforts to standardize CA practices and certificate profiles may create compliance issues for “multipurpose” certificates which span use cases (and their divergent standards requirements).

One specific example is the , which is working on a new S/MIME Baseline Requirement focused on certificates that include the id-kp-emailProtection EKU. While the group is making every effort to avoid unintended adverse effects on other areas, such as document signing which leverage the EKU, it clearly would be beneficial for those certificates to have an “EKU home of their own.”

Similarly, in the signing sector, through efforts such as the Adobe Approved Trust List and the Qualified regimes of Europe’s eIDAS, there are evolving standards and certificate profiles for signing certificates which may one day conflict with the S/MIME use case.

As such, Tadahiko ITO of SECOM and Tomofumi Okubo of ����TV have proposed an Internet-Draft to the IETF named General Purpose Extended Key Usage (EKU) for Document Signing X.509 Certificates. The document clearly lays out the need for a dedicated id-kp-documentSigning EKU to become part of the core standards for x.509 digital certificates.

If the draft is adopted by IETF, the Internet Assigned Numbers Authority (IANA) will allocate an Object Identifier (OID) for the EKU, which will then be available to be used in certificates. Existing and future document signing standards, root programs and products will then be able to use the EKU to determine whether a particular certificate is intended for use for document signing or not.

����TV is attentive to ensure that customers with document signing certificates are not unduly affected by this evolution in standards. ����TV supports the Internet-Draft and encourages other interested parties in the CA, document signing and digital transformation sectors to equally voice their support for creating a dedicated general-purpose EKU for document signing and digital signatures. The adoption of a documentSigning EKU is in line with industry trends for separation of certificate use cases and will facilitate the continuing development of industry standards for document signing and S/MIME.

Learn more about Document Signing Manager at digicert.com/signing/document-signing or email docsigning@digicert.com.