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

[Ryan Sleevi]

On Fri, Jan 7, 2022 at 4:53 AM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

>
>    - 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 think this has been expected some time for CAs. That's perhaps why I'm
surprised to hear the suggestion that this may not be well-understood, and
trying to understand how that is.


> 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'm not sure I follow. Your proposal was to significantly change the
margins (by adding 10% slack). I'm not sure specific language for durations
would be appropriate. Perhaps, as a separate ballot and unrelated to this
discussion, it sounds like you'd be amenable to a change that makes it
clear that the Baseline Requirements are the minimum expectations, and that
CAs that perform only the minimum are likely to encounter difficulties, and
thus should meet or exceed? I highlight it, because that statement applies
to *all* of the BRs, and its requirements, while a statement specific to
durations may incorrectly lead folks to conclude, as we've seen in the
past, that it *only* applies to durations, rather than being simply an
emphasis of subtlety.

>
>    - 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.
>
My understanding of your proposal is that the above values be changed to 7
months, 3.3 months, 34 days, 8 days, 3.3 months, 13 months, and 105 hours.
Have I misunderstood, and you're no longer advocating that?

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.
>

I'm not sure I understand the practical problem here? Personally, I would
think any CA that looks at something like the BRs, and sees it as a recipe
to become a trusted CA, is fundamentally flawed and perhaps not worth
consideration. These represent minimum expectations, but just like in life,
doing the absolute minimum possible does not engender a lot of trust, nor
does it necessarily encourage others to enter into business relationships
with you. It sounds like a blanket reminder of that fact, as it applies
holistically to these requirements, and within the scope, may address that
concern more fully though?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20220107/d679ee79/attachment.html>