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

Tue Oct 22 23:22:24 MST 2019

On 2019-10-23 9:15 π.μ., Jeremy Rowley via Servercert-wg wrote:
>
> 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).
>

Thanks for the improvements.

You think this might get confused with the serialNumber (OID: 2.5.4.5) 
subjectDN field? I can't think of anyone reading "Certificate serial 
number" to confuse it with the subjectDN:serialNumber field, but you 
never know :-)

Dimitris.

> *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.
>
>
> _______________________________________________
> 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/20191023/ee194d0c/attachment-0001.html>