[cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates: User input

Scott Rea scott at scottrea.com
Fri Feb 10 17:23:24 UTC 2017

Ryan, I think I may have missed something in your earlier argument
because I don't agree that 398 is an "...objective technical value".
Isn't 398 just your representation of an upper bound on 13 months?

My point is, that 13 months itself is arbitrary, so any pontificating on
why someone's calculation of 13 months is better than someone elses is
not objective even though it may be technical.

To be sure, there is no mandate that WebPKI needs to consider the
policies of other trust communities, and vice versa. My point was that
there are CAs who are common to both communities, and having an aligned
value in this instance should lower the impact on these CAs in
maintaining compliance with both - that is all.

When introducing new policies, doesn't it behoove us to take a look at
other trust communities who may have already tried to solve the same
issue to see if there is anything we can learn, rather than reinventing
the wheel every time?

Your 398 is NOT objective, its arbitrary, just as 400 is arbitrary.
Choosing 398 increases the burden of implementation for some CAs,
choosing 400 reduces the burden for some CAs, as such, I don't see 398
as the best choice.


On 2/10/2017 8:44 PM, Ryan Sleevi wrote:
> On Fri, Feb 10, 2017 at 8:25 AM, Scott Rea <scott at scottrea.com
> <mailto:scott at scottrea.com>> wrote:
>     The reasoning behind the 400 vs some other derivative of 13 months was
>     the 398 was an upper bound (per the logic you have described) plus 2
>     extra days were given to account for 398-day anniversary falling on a
>     week-end, so that the key holders and CAs could address any change
>     during normal business hours.
> Can you explain to me how the exact same problem is not present for 400
> day certificates as it is for 398 day certificates, as you advocate? You
> can quickly find that any addition of "plus 400 days" to a particular
> start date will inevitably fall on a weekend. Should we then argue for
> 402 days, using this same logic?
> I suspect you realize that would be silly, and hope your answer would be
> that "This would be solved via policy" - that is, the CA can determine
> whether or not expiration would fall on a weekend, and thereby reduce
> the validity period (to less than 398 days) to accommodate this case.
> Indeed, this very suggestion was already put forward that 398 is not the
> MINIMUM validity, but the MAXIMUM validity - allowing member CAs, for
> example, to define their policies in terms of "13 months", without any
> possibility of accidentally violating the Baseline Requirements due to
> poor date calculation.
> I appreciate you bringing this use case forward, but hopefully the above
> answer satisfactorily shows why 400 days does not solve it, and thus
> again, appears to just be about aesthetics.
>     So to summarize, my request to consider 400 as the upper limit was to
>     reduce the potential burden on WebPKI CAs who also operate
>     simultaneously in other PKI based trust communities that have already
>     set this bound, and also to allow flexibility for anniversaries that
>     fall on a week-end, so that they can instead be dealt with during normal
>     business hours - this lowers the impact on the CA and on the customer
>     key holders.
> Would you be arguing that if these other PKI based trust communities set
> 800 days as their upper bound, the Forum should consider it as such? If
> not, why not?
> As you have highlighted, different communities have different
> expectations about security. 398 days may (and I advance, is)
> appropriate for the Web PKI. If other PKIs wish to use 400, 600, 800
> days, or even more novelly, define things in other units, such as
> 31415926 seconds, then more power to them. But the alignment you
> advocate does not have practical advantage for the Web PKI or its
> consumers and relying parties, sets unfortunate expectations, and
> ultimately, is purely for aesthetics, rather than objective technical value.

Scott Rea, MSc, CISSP
Ph# (801) 874-4114

More information about the Public mailing list