Re: [EXTERNAL]-Re: [Servercert-wg] Server Cert WG name

[Pedro FUENTES]

Hi Jeremy,

To fully understand your proposal…

Do you mean that the SCWG (or whatever name it has) should focus only on the “WebPKI” use cases (in short, server certificates that are trusted by browsers)?

If that’s the case, I see evident benefits, but it raises a question… “what happens with the other use cases for server certs?”… who would deal with that so non-browser consumers (i.e. what goes in the operating system trust list) can decide about compliance to include or not a CA?

In point #2, you mention those use cases… typically customers are motivated to get publicly-trusted certificates for their server applications (i.e. an API that is consumed by their users not through a browser) because:

- This gives them confidence that the certificate is issued following audited best practices, and

- They don’t need to distribute the Root to their users

Should exist another working group for non-WebPKI server certs? Should the browsers base compliance criteria on (for example) certain OIDs to differentiate WebPKI certs and other server certs that can have different rules or constraints?

In short… The benefit of your proposal is clear for the WebPKI certs, but I’d like to understand how do you envision the other use cases to be regulated, so can also benefit of “public trust"

BR/P

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,

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

 

-- 
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.

-- 
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/003d01dbcab7%243dfb31e0%24b9f195a0%24%40cersign.com.

-- 
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/PUZPR01MB5335F2BA205EA7CD96429E90A399A%40PUZPR01MB5335.apcprd01.prod.exchangelabs.com.

WISeKey SA

Pedro Fuentes
CSO - Trust Services Manager
Office: + 41 (0) 22 594 30 00
Mobile: + 41 (0) 791 274 790

Address: Avenue Louis-Casaï 58 | 1216 Cointrin | Switzerland

Stay connected with WISeKey

THIS IS A TRUSTED MAIL: This message is digitally signed with a WISeKey identity. If you get a mail from WISeKey please check the signature to avoid security risks

CONFIDENTIALITY: This email and any files transmitted with it can be confidential and it’s intended solely for the use of the individual or entity to which they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. If you have received this email in error please notify the sender

DISCLAIMER: WISeKey does not warrant the accuracy or completeness of this message and does not accept any liability for any errors or omissions herein as this message has been transmitted over a public network. Internet communications cannot be guaranteed to be secure or error-free as information may be intercepted, corrupted, or contain viruses. Attachments to this e-mail are checked for viruses; however, we do not accept any liability for any damage sustained by viruses and therefore you are kindly requested to check for viruses upon receipt.