[cabf_validation] FW: Draft Ballot SCXX: Improve Certificate Lifetimes

Thu Aug 1 11:28:15 MST 2019

On Thu, Aug 1, 2019 at 1:50 PM Doug Beattie <doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com> > wrote:

From: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> > 
Sent: Thursday, August 1, 2019 12:33 PM
To: Doug Beattie <doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com> >; CA/Browser Forum Validation WG List <validation at cabforum.org <mailto:validation at cabforum.org> >
Subject: Re: [cabf_validation] Draft Ballot SCXX: Improve Certificate Lifetimes

On Thu, Aug 1, 2019 at 11:56 AM Doug Beattie via Validation <validation at cabforum.org <mailto:validation at cabforum.org> > wrote:

Ryan,

GlobalSign is not in favor of this ballot for a number of reasons, but maybe some changes or improved reason for your changes will help.

Over the past several years, this topic has come up many times and the proponents have made their cases.  What would help us is a consolidated set of security/ecosystem benefits of this change.  I know you’ve provided lots of reasons in the past, but a static blog or announcement page with the complete set of driving reasons would help everyone understand exactly where you’re coming from.  We can use this as we communicate the change to our customers and then everyone has the same understanding of the importance of this change.

Sure, I can totally appreciate the value in that. Do you want to take the lead on that, to help articulate some of the benefits as you see them?

Not really…  Google, Mozilla and others are leading the initiative to reduce the maximum validity period and data re-use policies, so I think this is best done by those pushing for this change.  I don’t think many/any CAs support this change.

This ballot proposes changes to several components and not just the maximum validity period.  I’d like to understand the reasons for each, perhaps in the above proposed blog.

*	Maximum validity period: Yes, this is the driving reason for the ballot, I understand that.
*	Maximum re-use of domain validation data: Is limiting this to 13 months necessary?  If this is the primary reason for the ballot, then is the reduction in certificate validity necessary?  How do these 2 changes relate to each other?  Do these have to match, and if so, why?

I actually think we need to get this particular bit down as aggressively as possible. From a security point of view, the ideal end state is zero reuse of domain validation data. We already have that for CAA, and it has not caused significant harm.

 It’s not clear how you’re relating CAA and domain validation checks when it comes to realtime checks.  For CAA the domain owner may, at their discretion, may put in a record one time, then CAs check it each time.  Having a challenge response for domain validation is operationally completely different since it requires the domain owner to take action on every request.

Believe it or not, there are a lot of enterprises that manually request certificates and don’t want or use automated systems for domain validation or issuance (2 separate topics).

The reasoning for this should be obvious, as we had an entire presentation about this at a past CA/Browser Forum F2F - BygoneSSL. The attacks demonstrated there are real and practical, and an artifact of the reuse of domain validation data. We've always treated these in lockstep together, and so this isn't a new trend.

While it’s possible for this to happen, I’m suspicious this is a real threat that has, or could be, used to cause real harm on the internet.  The attacker needs to track all domain expiration dates then needs to take control of the abandon service in addition to the domain (so they can access the users private key).  Am I missing the point here?   If this is the basis for moving to shorter validity and shorter domain validation periods, then it’s a very weak case.

A non-trivial amount of the security value of reducing lifetimes is missed if we don't reuse validation lifetimes here. 

OK, I can see that the certificate validity and domain re-use are coupled.

*	Maximum reuse of Organizational data: Is this necessary to be done every 13 months?  Would you accept a proposal of keeping this at 27 months while reducing the above 2 items?

To the extent we believe the organizational information is bound to the domain, it's difficult to treat these independently. That said, I can understand and appreciate the challenges involved with vetting the organization information from a QIIS and QGIS. I think there may be opportunities to improve how CAs monitor QIIS/QGISes for informational changes - similar to how CAs are required to respond to changes in WHOIS information.

As a practical matter, because browsers don't make use of OV-vetted information, I admit, I haven't paid close attention to the validation rules there. I suspect there may be an opportunity to allow reuse of the QGIS/QIIS information, provided the CA vetted it was current, and provided the CA vetted the relationship with the domain operator (i.e. no reuse of validation data for the domain portion). That could allow extended reuse of organization information, while ensuring it's not stale, as we saw with BygoneSSL.

I’m not following this.  Are you saying that you’re open to discussing keeping the reuse of QGIS/QIIS information at 27 months?

*	 
*	What’s special about 13 months, vs, say 20 months (splitting the difference)?  Can we have a more gradual reduction in the validity periods over the next ~3 years to get down to 12 or 13 months?

I think if this is the path CAs wanted to take, it would have been more useful when Gerv and I suggested this as a possible intermediate path. However, I think it's important to highlight that 13 months is the intermediate step - if we treated lifetimes the same way we, as an industry, were able to collectively address the many security holes in existing CA practices around validation, then I think we'd be moving to an end state closer to, say, 94 days.

CA’s prefer not taking a path, of course, but if it was more gradual then we’d be able to get our customers feel the pain more gradually and then make the switch to fully automated domain validation and ordering when they feel sufficient pain.

>From a browser perspective, note that we work dates backwards - trying to figure out what the latest date that insecure method X or insecure certificate Y still needs to be supported by the UA. From that perspective, the current means that it wouldn't be until Fall 2021 that we'd have reasonable confidence in the freshness of the domain information and that certificate lifetimes were bounded. That's on the upper-bound of where I've heard browsers are comfortable with. If that sort of gradual stepdown were proposed, I think it'd have the effect that practical of delaying meaningful improvement to 2024-or-later, and I think that's not really viable.

If/when the changes to domain validation and organizational data re-use go into effect, I hope that domains/organizations verified prior to a certain date can have the data re-use for the full 27 months and that on the effective date, new validations must not be re-used for longer than the new date.  This effective date can even be prior to the reduction of the maximum certificate validity period.  We want to avoid a cliff where customers and CAs have a mass number of domain and OrganizationSSL verifications to do all at once.  Been there, let’s not do that again.

I think that'd undermine a lot of the very real and pragmatic security goals here. Consider how many CAs we've seen have validation issues; if we assume (and I think it's fair to assume) there will be more validation issues in the future that are discovered retrospectively, I don't think we really end up getting much security benefit. Further, as a practical matter because of how and when certificates expire, I don't really see how we'd run into the 'cliff' scenario you mentioned - it'd only apply as people are replacing existing certificates that expired. Have I misunderstood the math? 

We’re heavily focused on the enterprise market where we validate the Organization data and the customer adds domains to that account following one of the supported domain validation methods.  Once this is done, then issuance can happen with just CAA checks since everything is revalidated and re-usable for that Applicant.   Customers replace their certificates any time without needing to do domain validation because it’s being reused.  Moving to domain validation per request would be a serious impact to this class of web site administrators. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190801/ed07713e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5701 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20190801/ed07713e/attachment-0001.p7s>