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

Dean Coclin Dean_Coclin at symantec.com
Thu Feb 9 21:41:42 UTC 2017

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?

>>This solely focuses on the technical implementation and unfortunately misses the greater challenges to users, many which have applications outside of the traditional browser-server relationship. I and other members have received a steady flow of emails from customers, partners and organizations concerned about this reduction in validity and especially the corresponding lead time.

What about Managed SSL customers that have prepaid two and three year certs on invoices? What about contracts and the time to renegotiate them? It’s not only the CA’s portal that needs to be updated but perhaps partners and all their contracts that may have commitments.

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Wednesday, February 8, 2017 9:03 PM
To: Dean Coclin <Dean_Coclin at symantec.com>
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates

On Wed, Feb 8, 2017 at 4:17 PM, Dean Coclin <Dean_Coclin at symantec.com<mailto:Dean_Coclin at symantec.com>> wrote:
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 last.

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...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170209/62a19484/attachment-0003.html>

More information about the Public mailing list