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

[Kirk Hall]

It’s problematic for the BRs to refer to an external document like an RFC.  Which version of the RFC – the one in effect when the ballot is adopted (that is usually the rule with statutory construction)?  Or would we be saying the BRs will automatically follow any future changes to the RFC – which we may not like?

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Tuesday, October 22, 2019 4:57 PM
To: Wayne Thayer via Servercert-wg <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] [EXTERNAL] Ballot SC23: Precertificates



On Tue, Oct 22, 2019 at 7:44 PM Wayne Thayer via Servercert-wg <servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>> wrote:
I'm posting v2 of this ballot because without it the discussion period will expire and the ballot will fail. V2 adds language required to prevent conflicts with ballot SC24, but does not otherwise change the proposal.

It's not clear to me how to proceed with this. It seems that the endorsers are happy with the current ballot, but others want to limit the change to section 4.9.10. So far, no one has proposed specific language that both accounts for all of the nuances of this issue and is considered to be easily understood. Unless specific alternative proposals are made, I'm inclined to proceed to a vote on the current proposal.

Wayne: Dimitris' change works for me in only tackling the half that CAs were most concerned about.

Rob, Jeremy: Could you check if https://cabforum.org/pipermail/servercert-wg/2019-October/001244.html addresses the immediate concerns raised?


My only concern is whether the "as described in RFC 6962" would be seen as Default-Allow or "Default-Deny". For example, could a CA argue a serial number is associated with a Precertificate that doesn't comply with RFC 6962 is fine? That'd be nonsense, but I'd hate to see that argument made.

I'm not sure if "as specified in RFC 6962" is any more restrictive against that interpretation. A more restrictive requirement would say "The Precertificate, and, if used, the Precertificate Signing Certificate, MUST comply with the requirements defined in RFC 6962.", but then that's awkward as "Note", if someone wanted to argue that "Note's aren't requirements" (despite the MUST).

There are other gotchas, worth identifying but not worth fixing (for example: what if the Precertificate was for a sub-CA? What about returning "good" for non-issued certificates from a Root CA?). The 'intent' is, I believe, that Subscriber Certificates and Subordinate Certificates differ in the timeline, but all OCSP responders have the same expectation. But that's for a different Ballot.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191023/303f6516/attachment.html>