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

[Ryan Sleevi]

On Fri, Feb 10, 2017 at 10:14 AM, Scott Rea <scott at scottrea.com> wrote:

> I think that is a good summary Ryan.
>
> We are essentially weighing up the difference of adding 2 days to the
> minimal possible time for a potential screw up vs a potential
> significant reduction in effort for some CAs who accommodate multiple
> trust communities.
>
> I think the latter outweighs the former, and actually reduces the risk
> of a correct implementation of the former by those who fall into the
> category of multi-trust community support. Lower risk because their
> renewal algorithms only need to accommodate the one value rather than
> having to check which trust community it is, decide which one takes
> precedence if its both, and implement a different value depending on the
> outcome. Simpler algorithm, should be lower risk, faster implementation.
>
> 400 is a win-win, whereas 398 is a win-we-don't-give-a-crap...


Well, there's a critical piece of information still missing - which is
understanding who this _actually_ affects versus _theoretically_ affects.

If it's burdensome to one CA, but that CA is not participating in the
Forum, it's hard to understand what impact or concern it would have on
them, or why their concerns should trump the concerns of "smallest possible
time".

If it's burdensome to all CAs, then I agree, it might be worth
re-evaluating.

However, it also reiterates the point which we seem to have agreement on -
that the Forum exists to set its own rules independent of any other
programs. If anything, as SHA-1 has taught us, it may very well be that the
Forum may occasionally need to be the more 'aggressive' operation. After
all, it's also possible to see the other WebPKIs realize that 398 is better
than 400, or even that 91 or 181 are better than 398, and we can all be
incrementally pushed to improvement.

Or it may just be that we attach differing weight as to the value of
overlap with other PKIs - I might see no value, you might see strong value.
The task for each of us is to help the other understand the why, and if
there's room for compromise. I think we might be on the same page as to why
I view overlap with other PKIs as a negative, rather than a positive, but
I'm still uncertain as to why you see it as a positive.

That said, we may just have to agree to disagree. Not because
"we-don't-give-a-crap", but because our worldview and perspectives
disagree, and I see it as more negative than positive. And this view of
negativity for overlap is not simply because of this matter (which, on its
own merits, is agreeably minor), but to the endemic and systematic attempts
at overlap - which, as we've seen with SHA-1 and we've seen in discussions
such as root direct issuance (for "administrative certificates" or "legacy
certificates"), overlap can be actively harmful. So I take the principled
stance to avoid overlap whenever possible, unless it can be demonstrated
that the value is not from overlap-for-overlaps-sake, but through a natural
and logically sound argument from shared principles.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170210/23f7e9a6/attachment-0003.html>