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

[Dimitris Zacharopoulos (HARICA)]

On 7/1/2022 5:43 μ.μ., Ryan Sleevi wrote:
>
>
> 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).

That was a suggestion, and to avoid being misunderstood on my follow-up 
email I asked for better and more reasonable numbers from members. It's 
not even necessary to select 10% and instead follow the browser 
practices (for example measure 3 months as 92 days, 1 year as 367 days, 
etc).

> I'm not sure specific language for durations would be appropriate.

Not even to introduce a certain "slack" to resolve any ambiguity? I 
thought you would be ok to update the documents for time interval cases 
like for example "at least every 3 months" and specify them as "at least 
every 92 days".

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

Yes, agreed.

>       * 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?

The 10% was just a suggestion. Later down the thread, I asked for 
members to provide more reasonable slack. Judging from the earlier 
discussions, it would make sense to update 3 months to 92 days, 6 months 
to...  (2x92)=184 days??? and so on. However, if the intent of the 
ballot proposers is only to touch upon "hours" and "days", then we can 
clarify and move on leaving the week, month, year for another ballot.
>
>     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?

I believe it will help, because we continue to see CAs choosing to 
implement the absolute minimum despite having discussed the risks in 
mailing threads, teleconferences and F2F meetings. They usually learn it 
the hard way through security incidents and feel "surprised" that 
missing 1 second can be taken so seriously. Had they known how serious 
this is from the very beginning of reading these standards, some things 
would probably be designed differently. This also applies to software 
engineers that implement CA software.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20220107/f18b6a4c/attachment-0001.html>