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

[Ryan Sleevi]

Kirk,

I appreciate the desire to provide language, but I think we should be
careful not to repeat the same mistakes as Ballot 134.

For example, what does it mean to "provide OCSP responses for
pre-certificates". If you use a Precert Signing CA, what is literally in
that text makes no sense, and will inevitably lead to the "wrong result".
You wouldn't have the Precert Signing CA define an OCSP responder, nor
would the OCSP response be issued from that CA, but would be from the
"Issuer" that would be in the Precertificate associated with the Issuer of
the Precert Signing CA.

This is why it's important not to try for "quick" solutions, but to go for
technical precision.

On Mon, Oct 21, 2019 at 5:53 PM Kirk Hall via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> I agree with Dimitris – the language is too complex, and who knows if
> there will be any unintended consequences.
>
>
>
> I was told a main reason for the ballot is because Rob Stradling thinks BR
> 4.9.10 forbids CAs from doing providing OCSP responses for pre-certificates.
>
>
>
> @Rob – if that’s true, why don’t we just amend BR 4.9.10 to add this:
>
>
>
> “CAs MAY provide OCSP responses for pre-certificates”  or maybe
>
>
>
> “CAs SHALL provide OCSP responses for pre-certificates”
>
>
>
> That’s pretty clear and easy to implement.  Of course, we may want to add
> something about what the correct response should be if:
>
>    - Pre-cert was CT logged, but the production cert has not yet been
>    issued
>    - Related production cert has been issued and is not revoked
>    - Related production cert has been revoked or expired
>    - Related production cert is unknown.
>
>
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf Of *Ryan
> Sleevi via Servercert-wg
> *Sent:* Monday, October 21, 2019 5:53 AM
> *To:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
> *Cc:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg at cabforum.org>
> *Subject:* Re: [Servercert-wg] [EXTERNAL] Ballot SC23: Precertificates
>
>
>
>
>
>
>
> On Mon, Oct 21, 2019 at 3:23 AM Dimitris Zacharopoulos (HARICA) <
> dzacharo at harica.gr> wrote:
>
>
>
> 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> 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.
>
>
>
> Except the proposed text is explicitly intended to exhaustively enumerate
> available options. That this is not clear is a sign that we can improve
> wording, and I'm looking forward to better understanding the concern. I'm
> not sure how best to capture a construct that "This must either be X or Y.
> X means this. Y means that." That is, in my view, quite possibly the
> simplest way to break down the requirements, and I'm not sure how we could
> decompose further, short of
>
> "This must be either:
>   * X - which means this.
>   * Y - which means that.
> "
>
> That's why I asked for your help in formulating something you felt would
> be clearer.
>
>
>
> 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.
>
>
>
> As I've already said, this is not true, and simply repeating it doesn't
> make it any more true. Plenty of standards work this way, and explicitly
> state whether lists are exhaustive or not. My only consideration is that if
> you'd like to propose bullets, as I demonstrated above, you propose it in a
> way that you feel is absolutely clear that only X and Y are permitted, and
> nothing else. Prosasically, this is a bit clearer, because it's easy to say
> it MUST be either X or Y.
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191021/84a69074/attachment.html>