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

[Tim Hollebeek]

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.

 

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.

 

-Tim

 

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Tuesday, October 22, 2019 4:04 PM
To: Tim Hollebeek via Servercert-wg <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Discussion Begins: Ballot SC24: Fall Cleanup

 

 

 

On Tue, Oct 22, 2019 at 2:46 PM Tim Hollebeek via Servercert-wg <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> > wrote:

Thanks for running with this, guys.

 

This version still has a SHOULD requirement inside of the Request Token definition.  Requirements do not belong within Definitions.  I also think the Note about Request Tokens is more useful in the Validation section rather than the Definitions section, but I feel less strongly about that.

 

Our existing Definitions section is full of normative requirements that exhaustively lists the valid interpretations.

 

Examples include, but are not limited to: Affiliate, Appliant, Applicant Representative, Attestation Letter, Authorization Domain Name, Authorized Ports, Base Domain Name, Certificate Problem Report, Control, Country, Delegated Third Party, Domain Authorization Document, Domain Contact, Domain Namespace, Domain Name Registrant, Domain Name Registrar, Fully-Qualified Domain Name, Government Entity, Internal Name, IP Address Contact, IP Address Registration Authority, Issuing CA, Key Compromise, Legal Entity, Parent Company, Random Value, Registration Authority, Reliable Data Source, Reliable Method of Communication, Relying Party, Repository, Request Token, Required Website Content, Reserved IP Address, Sovereign State, Subject, Subject Identity Information, Test Certificate, Trustworthy System, WHOIS, Wildcard Certificate, Wildcard Domain Name.

  

I don’t think loosening and/or strengthening the requirements on Test Certificates is appropriate in a cleanup ballot.

 

Again, the one method that uses them was removed. That is why it's a cleanup. There is no other use, within the BRs, of this term. It sounds like you're arguing for the wholesale removal, which would be aligned with cleanup.

 

In CAA lookup failures, both “X; Y; and Z” (old) and “X; and Y; and Z” (new) are ungrammatical.  Lists are separated with commas; full clauses are separated with semicolons.  Should be “X, Y, and Z.”

 

7.1.3 improperly broadens the scope of the existing requirement.  The loss of the language related to cross certificates, in particular, is a requirements change, as is the limitation to Subscriber and Subordinate CA certificates.  I’d actually support these changes, but they aren’t cleanups.

 

Could you clarify what your proposed language is? Under what circumstances do you believe the BRs should capture that SHA-1 signatures are acceptable, in order to accomplish the cleanup of removing statements about dates in the past (i.e. 2016).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191022/daecad15/attachment.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/20191022/daecad15/attachment.p7s>