[Servercert-wg] [EXTERNAL] Ballot SC23: Precertificates

Dimitris Zacharopoulos (HARICA) dzacharo at harica.gr
Mon Oct 21 00:23:50 MST 2019

On 2019-10-18 4:51 μ.μ., Ryan Sleevi wrote:
> On Fri, Oct 18, 2019 at 3:10 AM Dimitris Zacharopoulos (HARICA) 
> <dzacharo at harica.gr <mailto:dzacharo at harica.gr>> wrote:
>     I believe this language is very difficult to understand, at least for
>     me. 
> Any other context to help understand the difficulty or confusion?

I had to read it 5 times and was still confused about how to implement 
it. This tells me that the language is complicated and needs more work 
:-) Short sentences in "simple" English will get us there.

>     Perhaps we should break down these sentences defining what it means
>     for a serial number to be "reserved" or "assigned" (we don't need
>     to add
>     in section 1.6.1) and then state the requirements. I think it
>     would be
>     easier to read.
> Any suggestions for how to accomplish this?

I will try to find some time this week to propose a little simpler text 
that maintains all the requirements of your text.

> That's what the text currently does, so I'm not sure if I'm 
> understanding the concern correctly. Is it to move from prose, as it's 
> currently written, into something like enumerated bullet points? I 
> avoided that because a number of CAs shared concerns with expressing 
> requirements like this during the F2F (during the discussion about the 
> difficulty understanding the BRs), and I was trying to respect that 
> view. I'm fully supportive of trying to make sure requirements are 
> listed directly as that, with the exception of the interpretation 
> issues they create ("Default-Deny" being expected, "Default-Allow" 
> being the interpretation)

Bullet points help break down long sentences. They are not meant to 
exhaustively enumerate available options so IMO this is not related to 
the "Default-Deny", "Default-Allow" discussion. In the past, I have 
indicated some paragraphs of the BRs that are difficult to understand, 
especially for non-native English speakers. Breaking down these 
paragraphs with simple English, listed items, bullets etc, might make 
them easier to understand and implement.

As far as the "Default-Allow", "Default-Deny" discussion, as others have 
already indicated, this is how standards work. I cannot recall seeing 
blanket statements about the default interpretation of "allow" or "deny" 
in international standards. I appreciate the goal but until we reach a 
conclusion in that discussion, the best thing we can do is to write 
clear rules going forward for what is allowed and what is not. Going 
over the Guidelines from this perspective and try to pin-point places of 
possible mis-interpretation and "abuse" will be a pretty long process, 
which should probably be the goal of a specialized subcommittee (reminds 
me of the work done in the "policy review working group" before the new 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191021/4ebd6215/attachment.html>

More information about the Servercert-wg mailing list