[Servercert-wg] Ballot SC-52 version 2: Specify CRL Validity Intervals in Seconds

Fri Jan 7 09:53:34 UTC 2022

On 5/1/2022 9:31 μ.μ., Ryan Sleevi wrote:
>
>
> On Wed, Jan 5, 2022 at 2:15 PM Dimitris Zacharopoulos (HARICA) 
> <dzacharo at harica.gr> wrote:
>
>     It is not just inconvenient, it is not the expectation of the
>     author. If the author of the document expected an event to occur
>     at least every 1 day, an implementer should be allowed to schedule
>     this event every 24 hours, otherwise it doesn't meet the
>     expectation of the author. Similarly with the annual expectation.
>     If the author wanted a hard limit and "not a second later", then
>     this hard limit should take into account implementation challenges
>     and security risks. If there is a slightly increased hard limit
>     that has negligible security impact but is more convenient for
>     implementation purposes and even readability, then IMHO it should
>     be a preferred option.
>
>
> I think this might be more useful when discussing something concrete. 
> That is, I'm not sure where you believe something is or is not the 
> expectation of the author, and so specific requirements might be 
> useful. I believe all the (BR direct) requirements are very much 
> intended as "hard limit and not a second later", but it sounds like 
> you may still disagree, and so I'm not sure which requirement.
>

  * For Random Values no more than 30 days from its creation
  * For the CAA Records (they MUST do so within the TTL of the CAA
    record, or 8 hours, whichever is greater)
  * 4.2.1 about reusing information no more than 398 days
  * ...

I don't assume every CA has implemented these checks to the accuracy of 
seconds. If days are introduced at the accuracy of 1'', all CA systems 
must be reviewed and possibly updated to ensure their controls are 
measured at this precision level or ensure this is done sooner than the 
maximum, for safety.

I'm merely proposing to add a recommendation for CAs to adopt safer 
margins than the max limits in the BRs to signal this expectation in a 
clearer way.

> I haven't done the exhaustive review of the NCSSRs for this, but it 
> might save time if you have specific examples.
>
> I do think there's a meaningful difference when discussing 366 days vs 
> 402 days though - a full month difference vs a day difference - so I'm 
> not sure the "blanket approach" is really the right way. If we assume 
> everything were to be made abundantly clear about a hard limit, what 
> specifically would need slack (in the NCSSRs)

  * 1l: within six (6) months. This would possibly be affected.
  * 2j: at least every three (3) months. This would possibly  be affected.
  * 3e: at least once every 31 days. That was supposed to be once a
    month. Looks ok.
  * 4c (1): one (1) week of receiving a request from the CA/B Forum.
    That doesn't seem likely to happen but it would possibly be affected :)
  * 4c (3): at least every three (3) months. This would possibly be
    affected.
  * 4d: at least an annual basis. This would possibly be affected.
  * 4f: ninety-six (96) hours. That was supposed to be 4 days max. Looks ok.

I believe that's all but I'd appreciate someone double checking.

>     I understood this ballot to apply to NCSSRs and EV Guidelines as
>     well. Section 5 of the BRs say:
>
>     /"The CA/Browser Forum's Network and Certificate System Security
>     Requirements are incorporated by reference as if fully set forth
>     herein."/
>
>
> Thanks for clarifying where that concern is! That's an excellent 
> point, but if you look at the NCSSRs with respect to the day/hour 
> question, I think you should see it's OK?

Indeed, that's why I asked for a small clarification in the proposal to 
make it unambiguous that this statement affects requirements specified 
in "hours" and "days" only.

>
> That said, there is definitely benefit to looking at converting some 
> of the others to explicit day/hour based periods (e.g. 7/92 days for 
> vulnerability scanning vs one week/three months, 92 days for account 
> deactivation). These are security-critical tasks that you really are 
> capturing an upper-bound on (and the language is fairly explicit on 
> that being the maximum period and an expectation of greater frequency)
>
> Basically, "slack" implies that a CA meeting the level (e.g. 3 months) 
> is acceptable, while the language tries to make clear that's the 
> _longest_ acceptable, with the wording trying to be clear "do it more 
> frequently" ("at least"). But that's worthy of a separate discussion.
>
>>     I highlight this as a disconnect, because the NCSSRs already have
>>     the slack built in (by using the vaguer terms that are subject to
>>     auditor interpretation, rather than consistent interpretation);
>>     "at least an annual basis" is such an example.
>
>     Exactly, and this is resolved by scoping the proposed 1.6.4
>     language to only "hours" and "days" as mentioned in my previous
>     post. I hope you can understand the unnecessary disturbance this
>     ballot would cause it it were applied to "months", "quarters" or
>     "years".
>
>
> I wouldn't say such a disturbance would be unnecessary - I think it'd 
> probably be much clearer what the expectations are. But if you just 
> meant that it was unrelated to the goal of this ballot, I agree, and 
> that's why the language suggestion I made was trying to be scoped 
> narrowly for the immediate goal :) Your (later) reference to my 
> October message is in line with that - if we want something to be 
> calendrically aligned for per-second accuracy, we can build that in, 
> but that's not a 10% slack - that's a much narrower (+1 unit of 
> measure). However, for things that we really /do/ want more frequently 
> then calendrical, specifying something as 90 days perhaps helps make 
> it clearer that a calendrical 3 month approach /wouldn't/ comply, and 
> so CAs would understand the need to do it more frequently if they want 
> calendrical alignment (e.g. the 1st of every month)

Exactly, this was unrelated to the goal of this ballot and was hoping to 
discuss separately. That's why HARICA recommended removing this part 
from the ballot. We could discuss this more general "time alignment" 
issue separately and more holistically by carefully reviewing all 
documents and achieve consistency.

>     Of course, one might schedule things as they like (probably CAs
>     reading this thread :-) but the author of the document doesn't set
>     the expectation for CAs to use limits in the document as the
>     absolute "ceiling", to be on the safe side. It still allows for
>     the bare minimum. If we want to change that, we need to
>     communicate it better in the current BRs.
>
>
> I'm still not sure I understand that. Even if all the periods were 
> changed (e.g. from months to hours), the language of the current 
> requirements is still that it's the absolute longest period you can do 
> something. If I understand your point, it's that if CAs were taking 
> advantage of that (e.g. by scheduling calendars for the longest 
> possible), this would break them, but that seems both acceptable and 
> desirable (as a separate ballot), since the goal, as written, is 
> clearly for these to be upper bounds, with CAs being well within 
> safety margins by doing things more frequently.

We have both been involved in the Forum and its activities for some time 
and we know that the expectation/good practice is to implement controls 
below the upper bounds for safety. Someone who reads the BRs for the 
first time will probably not immediately get that, not with the current 
language anyway, and will likely implement some/all (?) systems/controls 
using the upper bounds. I believe we can make this expectation a bit 
clearer to assist current and future implementations of the BRs. I hope 
this makes my intention a bit clearer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20220107/f36d2d83/attachment.html>