[cabfpub] Ballot 194 – Effective Date of Ballot 193 Provisions

[Doug Beattie]

Ryan,

Ballot 194 allow for a temporary roll-back on the use of certificate data (back to 39 months) until March 1, 2018. No other changes are being included.  The “security” reverts back to what it was prior to the ballot and we’re not introducing any loopholes or new Renewal processing.

Here are a couple of challenges the CAs face:

-        Updating all managed service Org and Domain information that is older than 27 months is a big task.  We normally do this at some point just before expiration (prior to 39 months), but now we need to do an entire year’s worth of customer data in a month.  That’s a big task.

-        For all certificates we’ve issued, we typically like to allow customers to receive replacements (reissue).  Since the BRs, unlike the EVGLs, do not have a concept of reissue, CAs are forced to 1) disable reissue after 27 months of cert validity for customers with 3-year certificates, 2) come up with a process by which reissues go through the initial reverification process again, or 3) keep updating all cert data proactively for all customers for all orders so that none of them is ever older than 27 months.

Given enough time, neither of these are big problems.  The issue is doing them in a month.

I won’t comment on GlobalSign detailed product plans, but we’ll be compliant by April 22nd one way or the other.  Our customers are hating us already, but that’s life.  Having the ability to re-use the data for 39 months will help  relieve some of the pain even if it comes a month after ballot 194 becomes effective.

When March 1 comes around, I have no issues with 27 month cert data or max validity periods, although having the concept of reissue would be significant benefit.  We’ll probably  ballot the concept of reissue in the BRs later this year to align with the EVGL concepts where you can reissue a certificate using the original cert data as long as the DN and expire date do not change.  It was in a draft of 193 but got removed.

Doug


From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi via Public
Sent: Monday, April 10, 2017 11:00 AM
To: CA/Browser Forum Public Discussion List <public at cabforum.org>
Cc: Ryan Sleevi <sleevi at google.com>
Subject: Re: [cabfpub] Ballot 194 – Effective Date of Ballot 193 Provisions

Prior to finalizing our vote, which is strongly inclined to vote against this as actively harmful to security, I want to make sure there's no other additional data that CAs wish to share.

To date, the only information that's been shared is that it makes renewing a certificate - or changing its default values - "as burdensome" as getting a new certificate. It's been suggested that CAs need time to tell their customers about this, but no information has been given about what the customer could or would do differently with that information. It's unclear if CAs are suggesting they can verify information absent a certificate request (which I would argue is not consistent with the Baseline Requirements), but otherwise, it would mean customers would use this 'advance notice' to make an application. Since this only provides value if the 'fake' application (nor production blocking) happens before the 'real' application, delaying the date would provide no benefit to those users if the 'real' application happens first, which is the shared case so far.

This is a unique opportunity for CAs to actually clarify the business operations and expectations to browsers, so that we can be appropriately sensitive to the impact of changing requirements. However, no such details have actually been shared yet, and so that makes it difficult to understand the value here.

Privately, I've heard that some CAs have customers who 'expect' to be able to issue certificates for the lifetime of a single validation (3 years). That's an unreasonable expectation, not guaranteed by the Baseline Requirements, and more importantly, still impacted by this Ballot, so an unreasonable objection on CAs parts.

As this most definitely weakens security - by allowing parties to obtain certificates well beyond the domain registration or beyond the reasonable time of care a CA must take to ensure information is correct, and because the current "solution" to that problem is contractually require the subscribers (who may be malicious) to notify the CA if things change or they lose the right to the domain name, this seems actively harmful to support. Again, if there are perspectives that can explain why this is good or necessary, they would be most welcome, as the goal is to find a balance between improving security and avoiding unrealistic expectations (on browsers part) about CAs' abilities.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170410/5b50625f/attachment-0003.html>