Server Cert WG name

631 views
Skip to first unread message

Jeremy Rowley

unread,
May 21, 2025, 3:12:33 PMMay 21
to server...@groups.cabforum.org

Hi all,


I'd wanted to start a discussion on the use of public certs outside of the WebPKI, a topic that frequently arises in the broader industry. I think we could provide better clarity and direction to both relying parties and subscribers on the purpose of this working group with a name change.


The industry has made a lot of changes – such as shorter certificate lifecycles, increased automation, and requiring dedicated TLS hierarchies. These changes are always accompanied by why the CABForum is changing the way this works it its focused on "server certificates."  This usually leads to discussion on the nuanced differences between the WebPKI (publicly trusted certificates for web browsers) and the broader "server ecosystem" which includes a lot of uses cases that should not rely on publicly trusted certificates (especially with the deprecation of clientAuth for public trust).


We might be able to eliminate some of this misalignment by revising the name to be more accurate. The "Server Certificate Working Group" title is too broad and implies a scope that extends beyond the WebPKI, causing misunderstandings about the applicability of our Baseline Requirements and guidelines. We might reduce confusion if this group were named the WebPKI Working Group.


The benefits of such a change, IMO, include:

1. Enhanced Clarity: The name change is a strong signal to the public that the requirement focus is on the publicly trusted PKI ecosystem that secures web browsing.


2. Reduced Confusion:  A name change will reduce repeated conversation about why our rules apply to web servers and not necessarily to other server-side applications (e.g., internal enterprise servers, IoT devices, or other private trust use cases).


3. Accurate Representation: The name WebPKI is more precise on the purpose of the requirements.

4. Future-Proofing: Having the name help define the scope prevent future misinterpretations about server-side use cases that emerge and the applicability of public trust to those use case.


I’m sure there are more reasons, but the overall thought is this: There are many valid use cases for servers to use private trust over public and the name should emphasize that not all server use cases are also WebPKI use cases.


I'm interested in hearing your thoughts on this proposal. Do you see similar confusion? Is there any support for a name change to better represent what this group does?

Thanks!

Jeremy

 

Scott Rea

unread,
May 21, 2025, 3:50:20 PMMay 21
to 'Jeremy Rowley' via Server Certificate WG (CA/B Forum)

I definitely agree that this confusion/concern exists in the community.

 

My only suggestion to Jeremy’s proposal is that the name should still include “server” i.e.WebPKI Server Working Group since folks might potentially still not make an association of which group they are looking for without “server” in the name.

 

Regards,

-Scott

 

 

--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/PH7PR14MB7394905C1A2D5EDF0EB396BB8E9EA%40PH7PR14MB7394.namprd14.prod.outlook.com.

Disclaimer: The email and its contents hold confidential information and are intended for the person or entity to which it is addressed. If you are not the intended recipient, please note that any distribution or copying of this email is strictly prohibited as per Company Policy, you are requested to notify the sender and delete the email and associated attachments with it from your system.

wa...@cersign.com

unread,
May 21, 2025, 9:17:18 PMMay 21
to server...@groups.cabforum.org

Hi all,

 

This is a good topic, but I think name should changed to Web HTTPS Working Group since it only focus on this, no Client Auth, weakening identity info.

 

And I also think CA/Browser Forum should change name to Browser/CA Forum since only browsers can say Yes, No, the CA only can say OOOOOK.

 

Best Regards,

 

Richard Wang

 

 

From: 'Jeremy Rowley' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Thursday, May 22, 2025 3:12 AM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Server Cert WG name

 

Hi all,

--

Hazhar Ismail

unread,
May 21, 2025, 11:31:05 PMMay 21
to server...@groups.cabforum.org
Hi Jeremy and all,

Thank you for starting this important discussion. I find the proposal to rename the Server Certificate Working Group to something like WebPKI Working Group both timely and helpful in better reflecting its actual scope and avoiding recurring confusion in the broader PKI community.

From our experience, we've often encountered questions from customers and relying parties about whether the Baseline Requirements apply to private PKI use cases — including internal servers, IoT endpoints, or enterprise systems. The current name does imply a broader remit than intended, which can lead to misinterpretation. The CA/B Forum Baseline Requirements have, in many cases, become the de facto reference when people look for a standard for X.509 certificates.

On Richard Wang’s point regarding the exclusion of clientAuth in publicly trusted server certificates — I agree that clientAuth is not suitable for server certificates, as it is intended for client certificates in TLS client authentication. However, I do believe there is value in having another working group to address client (or individual) certificates beyond S/MIME. While the S/MIME WG addresses one class of client certificates, we might also want to consider use cases such as document signing, and possibly even establish a TLS Client Certificate Working Group to discuss clientAuth and related standards.

In Malaysia, for example, we have a Digital Signature Act (1997), but there is still a lack of technical standards for document signing certificates. While this thread focuses on renaming the SCWG to WebPKI WG, perhaps it can also prompt a broader discussion — in a separate thread — about forming a Document Signing Certificate WG.

Happy to further discuss, and I appreciate the opportunity to contribute this perspective.


Warm regards,

Hazhar Ismail

 


From: wa...@cersign.com <wa...@cersign.com>
Sent: Thursday, 22 May, 2025 9:17 AM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: RE: [Servercert-wg] Server Cert WG name
 

Michael Richardson

unread,
May 22, 2025, 1:00:26 PMMay 22
to server...@groups.cabforum.org

'Hazhar Ismail' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org> wrote:
> On Richard Wang’s point regarding the exclusion of clientAuth in
> publicly trusted server certificates — I agree that clientAuth is not
> suitable for server certificates, as it is intended for client
> certificates in TLS client authentication. However, I do believe there
> is value in having another working group to address client (or
> individual) certificates beyond S/MIME. While the S/MIME WG addresses
> one class of client certificates, we might also want to consider use
> cases such as document signing, and possibly even establish a TLS
> Client Certificate Working Group to discuss clientAuth and related
> standards.

Client Certificates, when used, are used by things not browsers, and not CAs,
and are usually part of some private PKI. As such, the current (membership)
bylaws of CAForum would likely not permit the parties that care about such
things to properly participate.
(One of the authors of the IETF DANCE WG architecture document)
signature.asc

Jeremy Rowley

unread,
May 22, 2025, 3:36:50 PMMay 22
to server...@groups.cabforum.org
For that exact reason, I think we'd have a really hard time finding an application vendor that actively wanted to participate in a public-trust client Auth working group, which is really required under the CAB/F structure.
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/14835.1747933220%40obiwan.sandelman.ca.

wang

unread,
May 22, 2025, 10:11:47 PMMay 22
to servercert-wg

Hi all,

 

Yes, CA/Browser Forum need to setup more working group to address the following issues:

(1) serverAuth WG: change name from current Server Certificate WG, for TLS/SSL certificate with "id-kp-serverAuth" only.

(2) clientAuth WG: new, for client certificate with "id-kp-clientAuth" only, this certificate common name can be email, domain, IP, phone number, full name, username, any number and digital for authentication username.

(3) Document certificate WG: new, this is for PDF/Word document signing and encryption, it is very popular used but no BR, and no Object Identifiers, urgently need!

(4) Timestamping certificate WG: new, currently it is included in code signing certificate WG, but it is used in document signing and other data signing, it also need a BR.  

(5) IoT certificate WG: new, this is for IoT certificate, also need a international standard.

(6) Intranet Server Certificate WG: new, this is a TLS/SSL certificate that binding intranet private IP address and hostname, intranet security need this, but currently no good solution.

 

Sure, keep the currently code signing certificate WG (7) , and keep the S/MIME certificate WG (8), but remove its multi-purpose policy that focus secure email only.

 

Yes, it will have the full line certificate type WG, total 8 WGs, to make the BR for all type certificates. Sure, keep the other non-certificate WG.

 

I love CA/Browser Forum even it is not 100% perfect, I joined it at 2013, like to do something for above WG, currently my identity is a certificate consumer - ZT Browser that integrate browser, PDF reader and email client into one software.

 

Best Regards,

 

Richard Wang

 

------------------------------------------------------------------
发件人:'Jeremy Rowley' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
发送时间:2025年5月23日(周五) 03:36
收件人:"servercert-wg"<server...@groups.cabforum.org>
主 题:RE: [Servercert-wg] Server Cert WG name

Hazhar Ismail

unread,
May 22, 2025, 10:59:26 PMMay 22
to servercert-wg
Hi all,

I fully agree with Richard Wang’s view.

To address Jeremy’s concern — for clientAuth, the relevant application vendors are clearly the browser vendors themselves. Since clientAuth is being deprecated for server certificates, this strengthens the case for establishing a dedicated BR for client authentication certificates.

Regarding document signing: this is certainly not a private use case. PDF reader applications are natural candidates for application vendors in this context. Today, major browsers can open PDF files, and platforms like Microsoft Word — accessible both via browsers and native applications — are already supporting document signing features. These vendors, by extension, play a role as application vendors for document signing.

Timestamping is also closely related to both document and code signing. The same group of application vendors involved in these domains could naturally support a timestamping standard.

I believe we can apply the publicly trusted CA model across all of these potential new working groups. These are high-assurance, high-sensitivity use cases — not something that should rely on private CAs. For example, under Malaysia’s Digital Signature Act 1997, only licensed and regulated Certification Authorities can issue legally recognized digital certificates to be used for document signing. These requirements ensure public accountability and trust — reinforcing the need for global standards.

Perhaps we can start with one working group or use case at a time and assess priority and impact. From our perspective, document signing is increasingly widespread, and there is a growing need for cross-border and cross-application interoperability. This could be an ideal starting point.

We may also want to consider revisiting the CA/B Forum's charter or by-laws if necessary — to ensure it remains well-positioned to address new trust domains and continues to be a reliable, globally relevant forum for publicly trusted PKI standards.

Happy to discuss further.


Warm regards,

Hazhar Ismail

 


From: wang <wa...@cersign.com>
Sent: Friday, 23 May, 2025 10:11 AM
To: servercert-wg <server...@groups.cabforum.org>
Subject: re:[Servercert-wg] Server Cert WG name
 

Dimitris Zacharopoulos (HARICA)

unread,
May 23, 2025, 7:04:03 AMMay 23
to server...@groups.cabforum.org
Hi Jeremy,

This discussion has somewhat started at the last F2F meeting in Tokyo (check out the minutes), which took place at the Forum-level portion of the F2F.

While this is a very interesting discussion, I believe the proper venue to discuss new Working Groups or the renaming of existing working groups, is the pub...@cabforum.org, at the Forum plenary level.

Would you be ok to move this discussion there?


Best regards,

Dimitris Zacharopoulos
CA/B Forum SCWG Chair
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.

Jeremy Rowley

unread,
May 23, 2025, 7:18:56 AMMay 23
to server...@groups.cabforum.org
Yeah- sounds great. Thanks!


From: 'Dimitris Zacharopoulos (HARICA)' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Friday, May 23, 2025 12:03:52 PM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>

Subject: Re: [Servercert-wg] Server Cert WG name
Reply all
Reply to author
Forward
0 new messages