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

[Jeremy Rowley]

Here’s my feedback on the language from Dimitris. To be honest, I’d rather just correct the mistake the CAB Forum made and clarify that a pre-cert is really just a cert and should be treated just like a cert minus the duplicate serial number. That’s a much simpler fix. However, since people seem to have heartburn over that, I guess this language could work:

I don’t really like the “Note” language.  It’s not a note since it contains actual requirements. Also defined terms should be in the defined terms section.

"For the status of Subscriber and CA Certificates issued in accordance
with these Requirements the CA SHALL support OCSP responses using the
GET method.

For the status of Subscriber Certificates:

  * The CA SHALL update information provided via an Online Certificate
    Status Protocol at least every four (4) days. OCSP responses from
    this service MUST have a maximum expiration time of ten (10) days.
  * CAs that are not Technically Constrained in line with Section 7.1.5
    the OCSP responder, MUST NOT respond with a "good" status, unless
    the requested Certificate serial number has been "reserved" or
    "assigned" (see note below). The CA SHOULD monitor the OCSP
    responder for requests that are not "reserved" nor "assigned" as
    part of its security response procedures.


A serial number is considered "reserved" if the serial number is included as a serial number in a Precertificate chaining to an Issuing CA, either directly or via a Precertificate Signing Certificate.

A serial number is considered "assigned" if the serial number is included as a serial number in a Subscriber Certificate chaining to an Issuing CA.

For the status of Subordinate CA Certificates the CA SHALL update
information provided via an Online Certificate Status Protocol at least
(i) every twelve (12) months and (ii) within twenty-four (24 ) hours
after revoking a Subordinate CA Certificate. "

Add to the defined terms:
Precertificate has the meaning defined in RFC 6962.

Precertificate Signing Certificate has the meaning defined in RFC 6962.


I added the language about the serial number needing to be the serial number of the cert in case there’s some weird situation where someone puts something in some other field (why? I don’t know, but we’ve definitely seen weirder things happen).

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Tuesday, October 22, 2019 5: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/22542d89/attachment-0001.html>