[Servercert-wg] Discussion Begins: Ballot SC24: Fall Cleanup

[Tim Hollebeek]

Yes, I’m fine with:



“Test Certificate: This term is no longer used in these Baseline Requirements.”

 

or similar.

 

On the SHA-1 requirement in 7.1.3, let me propose some text which might make the issue clearer:



“CAs MUST NOT issue any Subscriber certificates or new Subordinate CA certificates using the SHA-1 hash algorithm.  This Section 7.1.3 does not apply to Root CA or CA cross certificates. CAs MAY continue to use their existing SHA-1 Root Certificates. Subscriber certificates SHOULD NOT chain up to a SHA-1 Subordinate CA Certificate.”

 

I think this is closer to a minimalist and uncontroversial removal of effective dates, and nothing more.

 

I’d support going farther, but not in this ballot, as I think going farther is an actual substantive change.

 

-Tim

 

From: Ryan Sleevi <sleevi at google.com> 
Sent: Tuesday, October 22, 2019 4:55 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Discussion Begins: Ballot SC24: Fall Cleanup

 

On Tue, Oct 22, 2019 at 4:27 PM Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> > wrote:

The fact that existing Definitions make a mistake is not justification for making that mistake worse, especially not in a cleanup ballot which isn’t supposed to change anything at all.

 

If Test Certificates really is Abandonware, then yes, the appropriate remedy is to remove the definition, not modify it.

 

Let me put forward a different:

- If Test Certificates are Abandonware, do you support adding a statement (in a cleanup ballot) iterating that they're abandonware to avoid confusion?

 

Setting aside whether that statement is in the definition, or elsewhere, I think that's the objective here. Since 3.2.2.4.9 was removed, they're abandonware. Removing the definition makes sense, but the concern is wanting to make sure it's clear that they are, in fact, abandonware.

 

With respect to 7.1.3, this is a difficult topic, which is why I didn’t have language, though I’m happy to try to help craft it.  The existing language has fairly limited (and unfortunately complicated) scope, and for the purposes of a cleanup ballot, I think we should keep those scope restrictions, even if a ballot to simplify the issue by just outright banning the practice might make a lot of sense. 

 

This is all complicated by the fact that SHA-1 certificates are fairly unique in the sense that “the certificate contents that were signed may not be the actual certificate contents that are trusted.”  I probably could be convinced to go along with an expansion of what would normally be allowed in a cleanup ballot, especially if we can come up with clear, concise language that is easy to understand and interpret.  But I think the existing text is overbroad.

 

I'm not fully sure I follow here. What are the scope restrictions that you see are valid with the intersection of the existing requirements?

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