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

[Ryan Sleevi]

On Tue, Oct 22, 2019 at 2:46 PM Tim Hollebeek via Servercert-wg <
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/772b7058/attachment-0001.html>