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

[Ryan Sleevi]

On Mon, Apr 10, 2017 at 11:48 AM, Doug Beattie <doug.beattie at globalsign.com>
wrote:

> 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.
>

Yes, the security reverts to the insecure and undesirable behaviour, which
was fixed.

The distinction is not subtle. It would be like arguing allowing SHA-1 just
"reverts" the security to the previous Forum documents. Same with allowing
internal server names. The point is that it was changed to fix the security
issue, and so reverting _reintroduces_ it.


>
> 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.
>

That's interesting. Could you clarify where you believe the Baseline
Requirements permits what you described?

Specifically, Section 4.2.1 of the Baseline Requirements only permits reuse
of information pursuant with Section 3.2 ("The CA MAY use the documents and
data provided in Section 3.2 to verify certificate information")

Section 3.2 consistently describes the documents and data obtained as
pursuant to processing the Applicant's request.

The term "Applicant" is explicitly defined in Section 1.6.1 as "The natural
person or Legal Entity that applies for (or seeks renewal of) a
Certificate. Once the Certificate issues, the Applicant is referred to as
the Subscriber."


As such, I don't believe it's valid to do so prior to expiration unless and
until there has been an explicit customer request, thereby making them "An
Applicant", and thereby triggering the verification process of Section 3.2.
As such, what you've described does not sound consistent with the Baseline
Requirements, but perhaps there's a section or qualification within them
that I've missed.

Assuming I'm correct, and no such section exists, then the process you've
described - updating managed Org and Domain information - only triggers
once the Org requests a new certificate. Since that happens regardless of
expiring this year or next, I fail to see how that reasonably represents a
significant hurdle, although I would be happy if you could describe how it
is.

It seems that, effectively, regardless of _when_ the deadline is set, at
some point, a customer is going to request a certificate (thereby becoming
an Applicant), and you're going to have to reobtain the data, so that you
can use it to reverify every request (as you're required to do, since
verification is different than obtaining data and documents, and you MUST
reverify the Applicant using those documents for every request).


> -        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.
>
It is questionable as to whether #3 is permitted under the Baseline
Requirements today (see above, Section 1.6.1)

#1 and #2 are correct. It is important and useful that you've identified
that #2 is no different than new certificate issuance. Are you suggesting
it's too difficult to obtain certificates today for new customers? That
it's easier, and desired, that customers face greater difficulty changing
CAs?

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.
>

My lack of understanding is why customers are hating you, or more aptly,
why you believe they would hate you less in a year, given that you'd be
undergoing the same process today. If it's because you need time to tell
them it's coming, and that is the only reason they wouldn't hate you, it'd
be useful to understand how or why that changes anything. If there's
something the customer can or should be doing, which so far is unclear to
me, it'd be useful to understand how foreknowledge changes things.

I can buy that customers don't like change. But that's not an argument
against change.

I can buy that customers don't like surprises. But that's an argument
against making sure ballots are carefully reviewed if they're put forward
for serious adoption. Ballot 193 unquestionably was not.


> 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.
>

Right, I'd rather see it removed altogether. It has undesirable properties
that result in such certificates being less secure.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170410/e272e031/attachment-0003.html>