[cabf_validation] [EXTERNAL]Re: Draft Ballot SCXX: Improve Certificate Lifetimes

[Ryan Sleevi]

Bruce,

Thanks for explaining! It seems like a pre-validation approach like that
will inherently create cliffs, and is a bit of an implementation approach.
Even though half would need to be revalidated, it's not clear to me if
y'all have details about the actual issuance rate; that is, it's not like
all of it would need to be vetted by day 0.

I guess, put differently, is it valid to question whether pre-validation
approaches like that are supportable by the ecosystem? They seem to
externalize the costs (e.g. the cliff we're discussing), while
internalizing the benefits.

That said, I'm curious how you feel about the suggested approach I offered
- ensuring a timely binding of the domain to the organization, ensuring the
organization information is fresh and accurate (e.g. similar to how we
check when the WHOIS information changed), while being less aggressive with
some of the overall validation of that information. Would something like
that work? What would be the challenges there?

On Thu, Aug 1, 2019 at 2:18 PM Bruce Morton <
Bruce.Morton at entrustdatacard.com> wrote:

> Regarding organization validation, there is a cliff scenario with
> pre-validation. In this case, a customer can have an account where their
> organizations are validated and available for use for 825-days. When the
> 397-days of reuse ballot kicks in then about half of the organization data
> would have to be re-validated to allow all accounts to continue to use all
> organization names.
>
>
>
> I assume that if we continue to reduce the validity period, then we would
> create this cliff over and over again. As such, I would agree with Doug’s
> suggestion separate at least the organziation reuse period from the
> certificate validity period.
>
>
>
> Thanks, Bruce.
>
>
>
> *From:* Validation <validation-bounces at cabforum.org> * On Behalf Of *Ryan
> Sleevi via Validation
> *Sent:* Thursday, August 1, 2019 12:33 PM
> *To:* Doug Beattie <doug.beattie at globalsign.com>; CA/Browser Forum
> Validation WG List <validation at cabforum.org>
> *Subject:* [EXTERNAL]Re: [cabf_validation] Draft Ballot SCXX: Improve
> Certificate Lifetimes
>
>
>
> *WARNING:* This email originated outside of Entrust Datacard.
> *DO NOT CLICK* links or attachments unless you trust the sender and know
> the content is safe.
> ------------------------------
>
>
>
>
>
> On Thu, Aug 1, 2019 at 11:56 AM Doug Beattie via Validation <
> 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?
>
>
>
> 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.
>
>
>
> 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.
>
>
> A non-trivial amount of the security value of reducing lifetimes is missed
> if we don't reuse validation lifetimes here.
>
>
>
>
>    -
>    - 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.
>
>
>
>
>    -
>    - 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.
>
>
>
> 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190801/abfa8ff0/attachment.html>