[cabfpub] Ballot 190

[Ryan Sleevi]

On Thu, Apr 27, 2017 at 4:00 PM, Jeremy Rowley via Public <
public at cabforum.org> wrote:

> Ben let me know that there were questions about Ballot 190. The ballot was
> withdrawn and hasn’t gone to vote yet because of Section 2:
>
>
>
> “This provisions of Ballot Section 1 will apply only to the validation of
> domain names occurring after this Ballot 190’s effective date.  Validation
> of domain names that occurs before this Ballot’s effective date and the
> resulting validation data may continue to be used for the periods specified
> in BR 4.2.1 and EVGL 11.14.3 so long as the validations were conducted in
> compliance with the BR Section 3.2.2.4 validation methods in effect at the
> time of each validation.”
>
>
>
> I couldn’t tell if the objection to this section was the section not being
> part of the Baseline Requirements or a general concern that CAs may have
> issued certificates using the “any other method” that will remain valid for
> potentially four years (for a re-issue that relies on a previous
> validation).
>
>
>
>
> Assuming the first issue is the primary concern, the following language
> was proposed in the validation working group for inclusion in the BRs:
>
> “Note: The changes to BR 3.2.2.4.1 through 3.2.2.4.10 will apply only to
> the validation of domain names occurring on or after [insert Ballot 190’s
> effective date if it passes and completes its Review Period].  Validation
> of domain names that occurs before [insert Ballot 190’s effective date if
> it passes and completes its Review Period] and the resulting validation
> data may continue to be used for the periods specified in BR 4.2.1 and EVGL
> 11.14.3 so long as the validations were conducted in compliance with the BR
> Section 3.2.2.4 validation methods in effect at the time of each
> validation.”
>
>
>
> Rather than go through multiple iterations and have this ballot
> potentially fail, can we do a quick straw poll?
>
>
>
>    1. Does the proposed language resolve the previous concern with Ballot
>    190?
>    2. If not, should section 2 be dropped entirely.
>    3. If section 2 remains, would you vote against the ballot?
>    4. If section 2 was dropped, would you vote for the ballot?
>    5. Is there other language you’d prefer to see included instead?
>
> Hi Jeremy,

I'm not sure I fully understand your questions 1/2. It sounds (from Kirk's
reply) that this would go into 3.2.2.4 - is that correct?

And your questions 3-5 relate to adding that to 3.2.2.4.

While I think the introduction of the validation methods is good, I think
we've been quite clear now over several Forum meetings that we desire to
see all new certificates issued using the methods of 3.2.2.4. I think we've
made great progress in the Forum, over the past two years, ensuring that
everyone's use cases are met, but I must say I'm shocked and saddened to
see some members so opposed to the security improvements they bring, since
this would prevent their reliable deployment by at least 5 years.

However, I'm also appreciative that some Browser Members may not share
those concerns about security, or may not be seeing the same level of
misissuance we are from CAs improperly validating, and thus be comfortable
with these lower limits.

I think the general language proposal is a bit awkward - I would rather see
it pegged to an explicit minimum version (for example, BRs 1.4.1) and
explicitly forbid using a previous "any other method" validation. Is that
problematic?

Assuming that some members will be so opposed to transparency and
measurable security that they would oppose requiring basic validation using
the non-"any other method" methods, can we consider requiring that any new
certificates issued expire no later than (effective date + 6 months)? This
would permit CAs who have acted in good faith to adopt the methods of
3.2.2.4, as Google clearly indicated, to be unaffected, while those who
have used the many delays in discussion to postpone security improvements
have time to transition (simply by revalidating their certificates).

I think if we're still unable to agree on a timeline such as that -
requiring revalidation consistent with the current-3.2.2.4 for anything
that was validated under a previous-3.2.2.4 that is no longer permitted -
my only other suggestion would be to require an explicit expression within
the certificate that it complies with the current version of 3.2.2.4 at the
time of issuance. This would help give Relying Parties the necessary
assurances that the CA is committed to security.

Given that the discussions here have gone for so long, I hope that any of
these small tweaks that move us to a more consistent standard, and provide
a strong attestation on the CAs part about their commitment to security,
benefit everyone, and minimize any disruption to CA workflows due to the
improved security.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170427/8efefb74/attachment-0003.html>