[cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates
sleevi at google.com
Thu Feb 9 02:02:38 UTC 2017
On Wed, Feb 8, 2017 at 4:17 PM, Dean Coclin <Dean_Coclin at symantec.com>
> Ryan-your proposal at the time was a 2 year max validity for all certs.
> What specifically has changed your thinking since the meeting? Is it just,
> shorter is better?
I think I've captured many of the reasons why one year is desirable already
on list. I'm not sure that sharing the reasons are particularly necessary
to this thread. If anything, I've tried to focus on the positive benefits
that this brings, rather than the negative aspects, such as the unfortunate
misissuances by a number of members in the Forum we've seen this year and
As we look to find a system where we can still retain trust in some CA
members, and look to the Forum to strengthen and improve the industry
practices, it's increasingly clear that a system that doesn't allow these
to be practically used or enforced for years is unfortunately too long, and
alternatives, such as removing trust or capability for issuance, become
increasingly appealing. I'd like to explore ways to avoid that necessity,
and reducing issuance validity periods is a key way.
> Also, the ballot has an implementation of less than 4 months from now.
> With CAs working on CT for all cert types, vetting changes and likely CAA,
> roadmaps are filled for probably several quarters. Given the prior lead
> time given for CT for EV was longer, I’m surprised that there is a belief
> this can be accomplished in 4 months.
Without discussing product roadmaps or timelines, can you help me
understand what you believe is challenging about such a change or why it
might take anything more than a week or two to implement?
More precisely, this is a change to the profiles that CAs use when
issuance, but does not otherwise require any additional validation (such as
CAA) or integration (such as CT). It fits precisely within the existing
systems that have existed for decades that CAs use. Every major COTS CA
product supports such a limitation capability out of the box, so this is
not a matter of new development, as you might see with CAA or CT.
I can understand and appreciate arguments that it might require additional
testing, but again, this still allows a rather significant amount of time
for CAs to QA their certificates. It also sets an easily enforced,
objective date for which user agents can potentially enforce this, in code,
as several already do for the 39 month period, thereby reducing the risk to
their users for CAs that accidentally misissue 'long lived' certs beyond
their validity period. That's not to say such misissuance is
inconsequential - it speaks rather strongly to the abilities of the CAs to
respond to changes in the landscape - but it's one that allows for a more
reasonable response if it happens, rather than the current unfortunate
situation of needing to assume the worst.
> A major change like this requires a broader user input which isn’t going
> to happen on this list. Several CAs have started polling their customers
> for data and it will take some time to gather and present this. I suggest
> we set as a goal, a presentation at the March F2F by as many CAs that can
> gather data.
Unfortunately, I take this response as "What's the harm of a few more
months, since we've been discussing this for three years?" To which I would
reply: We've been discussing this for three years. You've had the
opportunity to poll and survey your users. You've understood and realized
the changes in the ecosystem. And as we've seen some members continue to
have issues adhering to the BRs in all sorts of new and novel ways, the
need to reduce the scope of such issues so that the most _harm_ that can be
used is 13 months rather than 39 months is ever present. The alternative is
to reduce to 0 months, and I'm sure we might all agree that's undesirable.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public