[cabfpub] Draft Ballot 186 - Limiting the Reuse of Validation Information
S.Davidson at quovadisglobal.com
Wed Feb 1 10:05:37 UTC 2017
I agree with Peter's point: a revocation should not automatically require a re-vetting of Org or Domain details as most revocations occur from "good housekeeping" with keys rather than a failure of underlying vetting.
I also point out that this ballot - and the corresponding limit on validity - represent fairly radical changes to the SSL market, particularly for better validated classes such as EV (where most issued certs have two year validity). Without falling afoul of the CABF's membership restrictions on talking price, I think it's fair to note that the proposed restriction will, in effect, drive up the "cost per year" of EV and limits the ability of CAs to differentiate their offerings.
From: Public [public-bounces at cabforum.org] on behalf of Peter Bowen via Public [public at cabforum.org]
Sent: Wednesday, February 01, 2017 1:36 AM
To: Ryan Sleevi
Cc: Peter Bowen; CABFPub
Subject: Re: [cabfpub] Draft Ballot 186 - Limiting the Reuse of Validation Information
On Jan 31, 2017, at 9:00 PM, Ryan Sleevi <sleevi at google.com<mailto:sleevi at google.com>> wrote:
Similarly, I'm looking for two endorsers to publicly endorse this ballot.
This Ballot is complementary to, but distinct from, Ballot 185, but itself represents a significant impediment towards improving online security. The Baseline Requirements only require that a CA validate a domain name once every 39 months, and that presently (notwithstanding Ballot 185), such certificates may have a validity period of up to 39 months. This effectively means that a CA may validate a domain once, and issue any number of certificates for an effective validity period of 74 months, minus a day.
To prevent further misissuance for domains in the event of transfer of control, whether through sale or the registration lapsing, as well as to ensure that newly issued certificates reflect industry best practice for domain validation, rather than reusing information from insecure or forbidden validation methods, this Ballot significantly reforms the reuse of validated information.
Notably, the modifications to the EV Guidelines fully removes the ability to simply use the mere existence of a certificate to justify issuance; instead, it reforms the domain authorization to allow the use of information from Section 11.14.3, subject to the existing lifetime concerns. In practice, this should cause no issues and be indistinguishable from a sunset date, but has the added benefit of resolving the ambiguity for EV certificates for domains which do not provide accessible WHOIS datasources.
The following motion has been proposed by Ryan Sleevi of Google, Inc and endorsed by ___ of ___ and ___ of ___ to introduce new Final Maintenance Guidelines for the "Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates" and the "Guidelines for the Issuance and Management of Extended Validation Certificates"
-- MOTION BEGINS --
Modify Section 4.2.1 of the "Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates" as follows:
Replace the following paragraph:
Section 6.3.2 limits the validity period of Subscriber Certificates. The CA MAY use the documents and data provided in Section 3.2 to verify certificate information, provided that the CA obtained the data or document from a source specified under Section 3.2 no more than thirty‐nine (39) months prior to issuing the Certificate.
Section 6.3.2 limits the Validity Period of Subscriber Certificates.
For certificates issued prior to 1 May 2017, the CA MAY use the documents and data provided in Section 3.2 to verify certificate information, provided that the CA obtained the data or document from a source specified under Section 3.2 no more than thirty‐nine (39) months prior to issuing the Certificate.
For certificates issued on or after 1 May 2017, the CA MAY use the documents and data provided in Section 3.2 to verify certificate information if the documents or data meet all of the following criteria:
1. The CA obtained the data or document from a source specified under Section 3.2 no more than thirteen (13) months prior to issuing the Certificate.
2. The method used to obtain the document or data was acceptable under Section 3.2 at the time the document or data was obtained.
3. The method used to obtain the document or data is acceptable under Section 3.2 at the time the documents or data is used to verify certificate information.
4. The CA has not revoked any certificates which contain certificate information verified using the document or data.
This appears to be problematic. If a customer asks the CA to revoke the certificate due to key compromise, this prevents the CA from issuing a new certificate immediately. It also creates large problems for customers that have a policy to request revocation of old certificates once they are no longer in use, as that action invalidates their validation data.
Modify Section 11.14.1 of the "Guidelines for the Issuance and Management of Extended Validation Certificates" as follows:
Delete the following item:
(6) The Applicant's right to use the specified Domain Name under Section 11.7, provided that the CA verifies that the WHOIS record still shows the same registrant as when the CA verified the specified Domain Name for the initial EV Certificate.
Modify Section 11.14.3 of the "Guidelines for the Issuance and Management of Extended Validation Certificates" as follows:
Add the following item:
(5) The CA MUST ensure that any documents or data used to support the issuance of an EV Certificate complies with the requirements and limits set forth in Section 4.2.1 of the Baseline Requirements.
-- MOTION ENDS —
This change seems to remove a key bit of EV. Unlike non-EV certs, for EV certs the CA has to check that domain has not changed registrant before issuing each certificate. Maybe this is something that is good to do across the board, but removing it from EV seems undesirable.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public