[Servercert-wg] Discussion Period Begins - Ballot SC-063: “Make OCSP Optional and Incentivize Automation”

[Dimitris Zacharopoulos (HARICA)]

On 3/5/2023 11:41 μ.μ., Aaron Gable wrote:
> Oh wait, I did have one additional thought:
>
> I'm not in favor of allowing CRLs to remain non-updated for 7 days 
> because that is a regression from current OCSP behavior. Section 
> 4.9.10.(4) makes it so that updated revocation information is always 
> available "no later than four days after the thisUpdate". Therefore, a 
> CA operating in a CRLs-only mode should be required to update their 
> CRLs at least once every 4 days.

Sounds good to me. More comments below.

>
> Thanks, and apologies for double-posting,
> Aaron
>
>
> On Wed, May 3, 2023 at 1:26 PM Aaron Gable via Servercert-wg 
> <servercert-wg at cabforum.org> wrote:
>
>     Apologies for how long this has run on, and thank you for the
>     great discussion as well!
>
>     On Wed, May 3, 2023 at 1:49 AM Dimitris Zacharopoulos (HARICA)
>     <dzacharo at harica.gr> wrote:
>
>
>         I explained when the clock starts. A CA would have evidence to
>         show when it marked a certain certificate as revoked, and when
>         the CRL containing that entry was issued.
>
>
>     I guess this is largely a question of semantics, then. I agree
>     that it should generally be possible for a CA to know when it
>     "decided" to revoke a certificate, when it "marked" that
>     certificate as revoked in an internal database, or took some
>     similar action. But I think there's plenty of precedent on this
>     list and in Bugzilla tickets that doing so does not count as
>     "revoking" the certificate -- that doesn't happen until signed
>     statements of revocation (OCSP or CRL) are widely published.
>
>     So if we want to have a requirement like you propose, I would ask
>     that it use some phrasing other than . Perhaps something like "The
>     CA MUST update and reissue CRLs at least 1) once every 7 days; or
>     2) within 24 hours after conclusively determining that a
>     certificate within that CRL's scope must be revoked." I don't love
>     that phrasing, as it introduces a new term of art "conclusively
>     determining" similar to the existing and hotly-debated "becomes
>     aware", but I like it better than "with 24 hours after revoking".
>
>     And yes, I take issue with the way the requirement for Subordinate
>     CA Certificates is phrased today :) I'd like to change both!
>

I support that approach to change both for consistency. Perhaps 
something like:

"The CA MUST update and reissue CRLs at least 1) once every 7 days; or 
2) within 24 hours after conclusively determining *recording *that a 
certificate within that CRL's scope must be revoked."

I prefer to use the word "record" which should leave a trace if needed. 
I also removed "within that CRL's scope" because it seems obvious that 
we are discussing about the CRL associated with a specific CA. Other 
suggestions for the language are welcome :)

>
>
>         This cannot apply in all cases described in 4.9.1.1. It would
>         probably make sense to apply in cases where the Subscriber
>         requests the revocation after proper authentication, in which
>         case the CA probably doesn't need to do any investigation.
>
>
>     Heh, we're in agreement here; that's exactly what I meant by
>     "Paragraph 1", i.e. the enumerated point beginning "1. The
>     Subscriber requests in writing...". I guess "4.9.1.1(1)" is what I
>     should have said.
>     I think that Ryan Dickson's proposed set of ballot updates
>     (https://github.com/ryancdickson/staging/pull/3, from the other
>     thread discussing this ballot) go a long way towards addressing
>     concerns brought up by both of us. I've left specific comments on
>     that PR, as a way to laser-focus this discussion onto specifics of
>     phrasing.
>

I will try to review and respond to Ryan's proposed updates next week.


Thanks,
Dimitris.

>
>     Aaron
>     _______________________________________________
>     Servercert-wg mailing list
>     Servercert-wg at cabforum.org
>     https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230504/cd6290af/attachment.html>