[Servercert-wg] Spring is here. So is a cleanup and clarification ballot

[Doug Beattie]

Ryan,

 

If we add every possible requirement into the BRs the auditors will find non-compliance to some requirements for those roots in root programs that do not mandate that check. How do we then determine and manage which findings are really findings?  Does this place a lot of work on the auditors to know which checks are except from certain Root programs and map that to the root programs that the root is embedded in?

 

 

 

 

From: Ryan Sleevi <sleevi at google.com> 
Sent: Thursday, April 2, 2020 11:16 AM
To: Doug Beattie <doug.beattie at globalsign.com>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Spring is here. So is a cleanup and clarification ballot

 

 

 

On Thu, Apr 2, 2020 at 9:12 AM Doug Beattie <doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com> > wrote:

Ryan,

 

The clean-up ballot is a good idea and I agree with the vast majority of your changes.

 

For the Browser Alignment ballot, we need to be careful that we don’t apply rules to all Roots which are only driven by one Root program.  CAs may have roots embedded into a subset of all programs and we don’t want one Root program’s rules to necessarily apply to all roots in all programs. 

 

One example is ECC P-521.  This is permitted in Microsoft but not by Mozilla, so it should not be added to the clean-up” ballot unless MS changes their program.  Even then, some other programs may permit this and depend on it in some cases (although I have no proof this is the case).  Same goes for changing the maximum validity period to 398 days.  We might consider pulling a root from the Apple trust store to permit issuance of 2 year certificates for customers that don’t need to support Apple products. 


The same goes for signing algorithms.  It might be the case that some regions (China?) wants to use different algorithms not permitted by Google and Mozilla, but that other root programs do support and where a WT audit is needed.  Again, I don’t know of a specific case, but let’s be careful about which items we pull from the root programs and make mandatory for ALL root programs.

 

I can understand and appreciate your point, although isn't this a question for the other Root Program(s)? That is, by having this in a Ballot, and having it in the BRs, we can allow Root Programs to decide whether or not they want to align. I think we've heard plenty from CAs where having alignment is beneficial and useful, especially for audits.

 

I think the goal here should be to pull every individual item from individual root programs, and look to make mandatory in the BRs. If there are Root Programs who disagree, then certainly, removing from the BRs is possible. However, that does run the risk that such requirements won't be audited, and thus we will continue to see bifurcation of the requirements and the potential introduction of additional audit obligations (for example, a CA needing to provide both a WT audit and an AUP audit in order to satisfy a Root Program)

 

In that sense, the best way to avoid that scenario is to place the most stringent requirements within the BRs themselves, and allow individual Root Programs to identify exceptions. That's because, as you note, a CA can't comply with all members' Programs if using P-521, so it makes sense to highlight that in the common profile.

 

In any event, I'm definitely looking for feedback from other Root Programs regarding this. My goal is to ensure that the WebTrust for CAs / SSL BRs+NetSec and that the DVCP profiles continue to be useful across the industry, and to provide the necessary assurance (by themselves) for as many root programs as possible.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200402/1533897a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5701 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200402/1533897a/attachment-0001.p7s>