Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document
Jeremy, I am not sure I fully understand the problems you describe. Would it be possible for you to provide some concrete example related to method #1, with some details, without of course mentioning specific certificates and/or organizations? Il 19/12/2017 22:30, Jeremy Rowley via Public ha scritto: Hi all, When reviewing the Symantec validation methods and the customers using each method, I found an alarming number of customers verified under 3.2.2.4.1 (Verification of a Domain Contact) or 3.2.2.4.5 (Domain Authorization Document) where the domain is not technically associated with the entity. These two methods need improvement or removal as the way they are currently lacks sufficient controls to associate the domain verification with the actual certificate approver. I’ve had too many calls with customers explaining re-verification where the domain holder didn’t understand that a cert issued for the domain. Although the organization verification was successfully complete, the only tie between the domain and organization is a call to the organization that happened within the last years to approve the account for issuance. I wanted to bring it up here because I’ve always thought these methods were less desirable than others. I think other large CAs use this method quite a bit so I’m hoping to get clarity on why these methods are permitted when the domain verification seems more “hand-wavy” than other methods. Method 3.2.2.4.1 permits a CA to issue a certificate if the certificate is an EV or OV cert. With EV certificates, there is a call to a verified telephone number that confirms the requester’s affiliation with the organization. I can see this method working for EV. For OV certificates, there is a reliable method of communication that confirms the account holder as affiliated with the organization. Unlike EV, for OV certs there is no tie between the requester and their authority to request a certificate. Once the organization is verified, the BRs permit auto-issuance for any domain that reflects an affiliation with the verified entity for up to 825 days. There’s no notice to the domain contact that the certificate was requested or approved. Perhaps this is sufficient as the account has been affiliated with the organization through the reliable method of communication and because CT will soon become mandatory. Method 3.2.2.4.5 permits a CA to issue a certificate using a legal opinion letter for the domain. Unfortunately the BRs lack clear requirements about how the legal opinion letter is verified. If I want a cert for Google.com and the CA is following the bare minimum, all I need to do is copy their letterhead and sign the document. Magically, a certificate can issue. This method lacks a lot of controls of method 1 because there is no requirement around verification of the company. I can list as many domains in the letter as I’d like provided the entity listed in the corresponding WHOIS’s letterhead is used. I’m looking to remove/fix both of these methods as both these methods lack the necessary controls to ensure that the verification ties to the domain holder. These methods probably should have been removed back when we passed 169/182. Would anyone being willing to endorse a ballot killing these or making some necessary improvements? Jeremy ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public smime.p7s Description: Firma crittografica S/MIME ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] Ballot 216: Update Discussion Period Process
Buypass votes YES. Regards Mads From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase Markham via Public Sent: tirsdag 12. desember 2017 19:51 To: CABFPub Subject: [cabfpub] Ballot 216: Update Discussion Period Process [Updated endorsers, 2nd attempt. Timeline unchanged.] Ballot 216: Update Discussion Period Process Purpose of Ballot: The current voting procedures specify a "period of discussion", the duration of which is fixed before the ballot process begins. This ballot updates that to instead have the period of discussion be more flexible, to avoid it expiring while discussion is ongoing and thereby voting on a sub-optimal ballot. The following motion has been proposed by Gervase Markham of Mozilla and endorsed by Tim Hollebeek of DigiCert and Ryan Sleevi of Google: -- MOTION BEGINS -- This ballot modifies the CAB Forum Bylaws. In Section 2.3(c), replace the text: "The discussion period then shall take place for at least seven but no more than 14 calendar days before votes are cast. The proposer of the ballot will designate the length of the discussion period, and each ballot shall clearly state the start and end dates and times (including time zone) for both the discussion period and the voting period." with: "The discussion period then shall take place for at least seven calendar days before votes are cast. At any time, a new version of the ballot (marked with a distinguishing version number) may be posted by the proposer in the same manner as the original. Once no new version of the ballot has been posted for seven calendar days, the proposer may end the discussion period and start the voting period by reposting the final version of the ballot and clearly indicating that voting is to begin, along with the start and end dates and times (including time zone) for the voting period. The ballot automatically fails if 21 calendar days elapse since the proposer last posted a version of the ballot and the voting period has not been started." Similarly, in Section 2.4(b), replace the text: "As described in Section 2.3(c), there will be a discussion period of at least seven but no more than 14 calendar days before votes are cast on a Draft Guideline Ballot, with the start and end dates of such discussion period clearly specified in the ballot." with: "As described in Section 2.3(c), there will be a discussion period of at least seven days before votes are cast on a Draft Guideline Ballot, with the start date of such discussion period clearly specified in the ballot. The discussion period shall end and the voting period shall commence also according to the procedure specified in Section 2.3(c)." In Section 2.3(d) of the CAB Forum Bylaws, replace the text: "Upon completion of the discussion period, Members shall have" with: "Upon commencement of the voting period, Members shall have" Similarly, in Section 2.4(c), replace the text: "As described in Section 2.3(d), upon completion of such discussion period, Members shall have" with: "As described in Section 2.3(d), upon commencement of the voting period, Members shall have" -- MOTION ENDS -- The procedure for approval of this ballot is as follows: Start time (22:00 UTC) End time (22:00 UTC) Discussion (7 to 14 days) 7 Dec 14 Dec Vote for approval (7 days) 14 Dec 21 Dec Votes must be cast by posting an on-list reply to this thread on the Public list. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is shown on CA/Browser Forum wiki. Under Bylaw 2.2(g), at least the required quorum number must participate in the ballot for the ballot to be valid, either by voting in favor, voting against, or abstaining. ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] Ballot 217: Sunset RFC 2527
Buypass votes YES. Regards Mads From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via Public Sent: torsdag 7. desember 2017 17:53 To: CABFPub Subject: [cabfpub] Ballot 217: Sunset RFC 2527 Ballot 217: Sunset RFC 2527 Purpose of Ballot: The Baseline Requirements and Extended Validation Guidelines require that CA's disclosures of the Certificate Policy and/or Certification Practice Statements include all of the material required by either RFC 2527 or RFC 3647 and structured in accordance with RFC 2527 or RFC 3647. RFC 2527 is an obsolete RFC, published in 1999, and replaced by RFC 3647 in 2003. This sunsets the use of RFC 2527, ensuring that CAs' disclosures will follow a consistent pattern across the industry, facilitating easier review by Subscribers, Browsers, and the broader community. Based upon Member feedback, 6 months is provided for CAs to review and update their CP/CPS documents. This motion aligns the language to be consistent between the BRs and the EVGs. For the benefit of minimal changes, this aligns the existing language through duplication, rather than attempting to incorporate the BRs by reference. The following motion has been proposed by Ryan Sleevi of Google and endorsed by Tim Hollebeek of DigiCert and Dimitris Zacharopoulos of HARICA. -- MOTION BEGINS -- This ballot modifies the "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates" as follows, based upon Version 1.5.1: In Section 2.2, replace the text: "The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA's selected audit scheme (see Section 8.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. " with the following: "The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA's selected audit scheme (see Section 8.1). Effective as of 31 May 2018, the Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647. Prior to 31 May 2018, the Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with either RFC 2527 or RFC 3647. The Certificate Policy and/or Certification Practice Statement MUST include all material required by RFC 3647 or, if structured as such, RFC 2527." This ballot modifies the "Guidelines for the Issuance and Management of Extended Validation Certificates" as follows, based on Version 1.6.6: In Section 8.2.2, replace the text: "Each CA MUST publicly disclose their EV Policies through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA is also REQUIRED to publicly disclose its CA business practices as required by WebTrust for CAs and ETSI TS 102 042 and ETSI EN 319 411-1. The disclosures MUST be structured in accordance with either RFC 2527 or RFC 3647." With the following: "Each CA MUST publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA's selected audit scheme (see Section 17.1). Effective as of 31 May 2018, the CA's Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647. Prior to 31 May 2018, the CA's Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with either RFC 2527 or RFC 3647. The Certificate Policy and/or Certification Practice Statement MUST include all material required by RFC 3647 or, if structured as such, RFC 2527." -- MOTION ENDS -- The procedure for approval of this ballot is as follows: Discussion (7 to 14 days) Start Time: 2017-12-07 22:00:00 UTC End Time: 2017-12-14 22:00:00 UTC Vote for approval (7 days) Start Time: 2017-12-14 22:00:00 UTC End Time: 2017-12-21 22:00:00 UTC Votes must be cast by posting an on-list reply to this thread on the Public list. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two
Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document
Adriano,
Do you have an example of how you believe 3.2.2.4.1 can be used correctly?
Specifically, it does not describe the process for validating that the
Applicant is the Domain Contact with the Registrar - this isn't equivalent
to using WHOIS.
Here's just one scenario:
- I ("Ryan Sleevi") apply to Foo CA for example.com, which is owned by
"Andriano Santoni's Lightly Validated Certificates" - you.
- Foo CA decides to employ 3.2.2.4.1, using 3.2.2.4(1)
- Note, as worded, all of 3.2.2.1 can be read as 'optional' for DV certs,
thus automatically met, but lets pretend its OV
- They verify "Andriano Santoni's Lightly Validated Certificates" is a
real company with a real existence using a QGIS. That's all that's needed -
there's no binding to the Applicant, just an existence proof of the data.
- Alternatively, I send a photoshopped letter claiming your company
exists, valid under 3.2.2.1(4)
- Alternatively, the CA declares that "Google Maps" is a Reliable Data
Source (it isn't, but again, underspecified), and verifies that there's an
entry under 3.2.2.1(2) - despite the fact I just added the entry
- They then need to verify whether or not I'm authorized to speak for your
company.
- The information used in 3.2.2.1 doesn't have to be used ("the CA MAY
use ..."), but remember, I may have made it up under 3.2.2.1
- The CA can directly call me, Ryan Sleevi, asking if I'm authorized
("the CA MAY establish the authenticity of the certificate request directly
with the Applicant Representative")
- The requirement to use an RMOC simply means that Foo CA could decide to
call up Jeremy, since Jeremy knows me, and say "Hey, does Ryan work for
Adriano Santoni" - that's all that's required.
- Finally, the CA contacts the registrar, and says "Hey, does Adriano
Santoni's Lightly Validated Certificates own example.com" - and the
registrar says sure
- Note: There's no consensus whether we're talking about the same
organization - perhaps I created a version incorporated in the US, but
you're incorporated in Italy
These are just a few of the legal-but-bad things you can do. I'm sure we'll
see the normal rush from some CAs saying "Yes, but we'd never do that" -
while ignoring the fact that some could, as it's valid under the language,
and we consistently see "That which is valid (or subject to
misinterpretation) is possible to use"
Could you provide an example of how you believe 3.2.2.4.1 "should" work and
offer the same level of assurance as the other methods, without normatively
prescribing the data sources used? From conversations with both current and
past employees of CAs, I am adamantly convinced that there is not a
consistent standard of reliableness being applies. Google Maps being used
as a Reliable Data Source is not a hypothetical, despite it allowing
community edits.
On Thu, Dec 21, 2017 at 4:00 AM, Adriano Santoni via Public <
public@cabforum.org> wrote:
> Jeremy, I am not sure I fully understand the problems you describe.
>
> Would it be possible for you to provide some concrete example related to
> method #1, with some details, without of course mentioning specific
> certificates and/or organizations?
>
>
> Il 19/12/2017 22:30, Jeremy Rowley via Public ha scritto:
>
> Hi all,
>
>
>
> When reviewing the Symantec validation methods and the customers using
> each method, I found an alarming number of customers verified under
> 3.2.2.4.1 (Verification of a Domain Contact) or 3.2.2.4.5 (Domain
> Authorization Document) where the domain is not technically associated with
> the entity. These two methods need improvement or removal as the way they
> are currently lacks sufficient controls to associate the domain
> verification with the actual certificate approver. I’ve had too many calls
> with customers explaining re-verification where the domain holder didn’t
> understand that a cert issued for the domain. Although the organization
> verification was successfully complete, the only tie between the domain and
> organization is a call to the organization that happened within the last
> years to approve the account for issuance. I wanted to bring it up here
> because I’ve always thought these methods were less desirable than others.
> I think other large CAs use this method quite a bit so I’m hoping to get
> clarity on why these methods are permitted when the domain verification
> seems more “hand-wavy” than other methods.
>
>
>
> Method 3.2.2.4.1 permits a CA to issue a certificate if the certificate is
> an EV or OV cert. With EV certificates, there is a call to a verified
> telephone number that confirms the requester’s affiliation with the
> organization. I can see this method working for EV. For OV certificates,
> there is a reliable method of communication that confirms the account
> holder as affiliated with the organization. Unlike EV, for OV certs there
> is no tie between the requester and their authority to request a
> certificate. Once the organization is verified, the BRs permit
> auto-i
Re: [cabfpub] Ballot 217: Sunset RFC 2527
Disig votes „YES“. Regards Peter From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via Public Sent: Thursday, December 7, 2017 5:53 PM To: CABFPub Subject: [cabfpub] Ballot 217: Sunset RFC 2527 Ballot 217: Sunset RFC 2527 Purpose of Ballot: The Baseline Requirements and Extended Validation Guidelines require that CA's disclosures of the Certificate Policy and/or Certification Practice Statements include all of the material required by either RFC 2527 or RFC 3647 and structured in accordance with RFC 2527 or RFC 3647. RFC 2527 is an obsolete RFC, published in 1999, and replaced by RFC 3647 in 2003. This sunsets the use of RFC 2527, ensuring that CAs' disclosures will follow a consistent pattern across the industry, facilitating easier review by Subscribers, Browsers, and the broader community. Based upon Member feedback, 6 months is provided for CAs to review and update their CP/CPS documents. This motion aligns the language to be consistent between the BRs and the EVGs. For the benefit of minimal changes, this aligns the existing language through duplication, rather than attempting to incorporate the BRs by reference. The following motion has been proposed by Ryan Sleevi of Google and endorsed by Tim Hollebeek of DigiCert and Dimitris Zacharopoulos of HARICA. -- MOTION BEGINS -- This ballot modifies the "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates" as follows, based upon Version 1.5.1: In Section 2.2, replace the text: "The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA's selected audit scheme (see Section 8.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. " with the following: "The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA's selected audit scheme (see Section 8.1). Effective as of 31 May 2018, the Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647. Prior to 31 May 2018, the Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with either RFC 2527 or RFC 3647. The Certificate Policy and/or Certification Practice Statement MUST include all material required by RFC 3647 or, if structured as such, RFC 2527." This ballot modifies the "Guidelines for the Issuance and Management of Extended Validation Certificates" as follows, based on Version 1.6.6: In Section 8.2.2, replace the text: "Each CA MUST publicly disclose their EV Policies through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA is also REQUIRED to publicly disclose its CA business practices as required by WebTrust for CAs and ETSI TS 102 042 and ETSI EN 319 411-1. The disclosures MUST be structured in accordance with either RFC 2527 or RFC 3647." With the following: "Each CA MUST publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA's selected audit scheme (see Section 17.1). Effective as of 31 May 2018, the CA's Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647. Prior to 31 May 2018, the CA's Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with either RFC 2527 or RFC 3647. The Certificate Policy and/or Certification Practice Statement MUST include all material required by RFC 3647 or, if structured as such, RFC 2527." -- MOTION ENDS -- The procedure for approval of this ballot is as follows: Discussion (7 to 14 days) Start Time: 2017-12-07 22:00:00 UTC End Time: 2017-12-14 22:00:00 UTC Vote for approval (7 days) Start Time: 2017-12-14 22:00:00 UTC End Time: 2017-12-21 22:00:00 UTC Votes must be cast by posting an on-list reply to this thread on the Public list. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted,
Re: [cabfpub] Ballot 216: Update Discussion Period Process
Disig votes „YES“. Regards Peter From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase Markham via Public Sent: Thursday, December 7, 2017 10:18 AM To: CABFPub Subject: [cabfpub] Ballot 216: Update Discussion Period Process Ballot 216: Update Discussion Period Process Purpose of Ballot: The current voting procedures specify a "period of discussion", the duration of which is fixed before the ballot process begins. This ballot updates that to instead have the period of discussion be more flexible, to avoid it expiring while discussion is ongoing and thereby voting on a sub-optimal ballot. The following motion has been proposed by Gervase Markham of Mozilla and endorsed by Tim Hollebeek of DigiCert and Kirk Hall of Entrust: -- MOTION BEGINS -- This ballot modifies the CAB Forum Bylaws. In Section 2.3(c), replace the text: "The discussion period then shall take place for at least seven but no more than 14 calendar days before votes are cast. The proposer of the ballot will designate the length of the discussion period, and each ballot shall clearly state the start and end dates and times (including time zone) for both the discussion period and the voting period." with: "The discussion period then shall take place for at least seven calendar days before votes are cast. At any time, a new version of the ballot (marked with a distinguishing version number) may be posted by the proposer in the same manner as the original. Once no new version of the ballot has been posted for seven calendar days, the proposer may end the discussion period and start the voting period by reposting the final version of the ballot and clearly indicating that voting is to begin, along with the start and end dates and times (including time zone) for the voting period. The ballot automatically fails if 21 calendar days elapse since the proposer last posted a version of the ballot and the voting period has not been started." Similarly, in Section 2.4(b), replace the text: "As described in Section 2.3(c), there will be a discussion period of at least seven but no more than 14 calendar days before votes are cast on a Draft Guideline Ballot, with the start and end dates of such discussion period clearly specified in the ballot." with: "As described in Section 2.3(c), there will be a discussion period of at least seven days before votes are cast on a Draft Guideline Ballot, with the start date of such discussion period clearly specified in the ballot. The discussion period shall end and the voting period shall commence also according to the procedure specified in Section 2.3(c)." In Section 2.3(d) of the CAB Forum Bylaws, replace the text: "Upon completion of the discussion period, Members shall have" with: "Upon commencement of the voting period, Members shall have" Similarly, in Section 2.4(c), replace the text: "As described in Section 2.3(d), upon completion of such discussion period, Members shall have" with: "As described in Section 2.3(d), upon commencement of the voting period, Members shall have" -- MOTION ENDS -- The procedure for approval of this ballot is as follows: Start time (22:00 UTC) End time (22:00 UTC) Discussion (7 to 14 days) 7 Dec 14 Dec Vote for approval (7 days) 14 Dec 21 Dec Votes must be cast by posting an on-list reply to this thread on the Public list. A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against must indicate a clear 'no' in the response. A vote to abstain must indicate a clear 'abstain' in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted. Voting members are listed here: https://cabforum.org/members/ In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and greater than 50% of the votes cast by members in the browser category must be in favor. Quorum is shown on CA/Browser Forum wiki. Under Bylaw 2.2(g), at least the required quorum number must participate in the ballot for the ballot to be valid, either by voting in favor, voting against, or abstaining. ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
[cabfpub] Results on Ballot 216 – Update Discussion Period Process
Results on Ballot 216 – Update Discussion Period Process The voting period for Ballot 216 has ended and the ballot has passed. Here are the results. Voting by CAs – 13 votes total including abstentions 13 Yes votes: Buypass, Chunghwa Telecom, Cisco, DigiCert, Disig, Entrust Datacard, GDCA, GlobalSign, HARICA, SSL.com, TrustCor, Trustwave, TurkTrust 0 No votes: 0 Abstain: 100% of voting CAs voted in favor Voting by browsers – 4 votes total including abstentions 4 Yes votes: Apple, Comodo Security Solutions, Google, Mozilla 0 No votes: 0 Abstain: 100% of voting browsers voted in favor Under Bylaw 2.2(g), a ballot result will be considered valid only when more than half of the number of currently active Members has participated. Votes to abstain are counted in determining a quorum. Half of currently active Members as of the start of voting is 7, so quorum was 8 votes – quorum was met. Bylaw 2.2(f) requires a yes vote by two-thirds of CA votes and 50%-plus-one browser votes for approval. Votes to abstain are not counted for this purpose. This requirement was met for both CAs and browsers. At least one CA Member and one browser Member must vote in favor of a ballot for the ballot to be adopted. This requirement was met. The ballot passes. Because this Ballot only changes the Bylaws, a Review Notice will not be circulated. ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
[cabfpub] Results on Ballot 217 – Sunset RFC 2527
Results on Ballot 217 – Sunset RFC 2527 The voting period for Ballot 217 has ended and the ballot has passed. Here are the results. Voting by CAs – 15 votes total including abstentions 15 Yes votes: ANF Autoridad de Certificacion, Buypass, CFCA, Chunghwa Telecom, Cisco, DigiCert, Disig, Entrust Datacard, GDCA, GlobalSign, HARICA, SSL.com, TrustCor, Trustwave, TurkTrust 0 No votes: 0 Abstain: 100% of voting CAs voted in favor Voting by browsers – 4 votes total including abstentions 4 Yes votes: Apple, Comodo Security Solutions, Google, Mozilla 0 No votes: 0 Abstain: 100% of voting browsers voted in favor Under Bylaw 2.2(g), a ballot result will be considered valid only when more than half of the number of currently active Members has participated. Votes to abstain are counted in determining a quorum. Half of currently active Members as of the start of voting is 7, so quorum was 8 votes – quorum was met. Bylaw 2.2(f) requires a yes vote by two-thirds of CA votes and 50%-plus-one browser votes for approval. Votes to abstain are not counted for this purpose. This requirement was met for both CAs and browsers. At least one CA Member and one browser Member must vote in favor of a ballot for the ballot to be adopted. This requirement was met The ballot passes. ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document
Ryan,
I think I see what you mean, but I also believe that the problem is not
in method #1 per se, but rather in the "degrees of freedom" with which
it may be implemented, as allowed by the BRs.
In particular, I believe that establishing the authenticity of the
request directly with the Applicant's Representative is a bad practice,
regardless of the DCV method employed.
I'd suggest to try and improve (tighten) the BRs, instead of killing DCV
methods that make sense, per se, but should be implemented in a more
robust way.
For instance, I'd favour zapping the words "directly with the
Applicant's Representative or" from the second paragraph of BR §3.2.5.
Would not that be an improvement?
Adriano
Il 21/12/2017 17:57, Ryan Sleevi ha scritto:
Adriano,
Do you have an example of how you believe 3.2.2.4.1 can be used
correctly?
Specifically, it does not describe the process for validating that the
Applicant is the Domain Contact with the Registrar - this isn't
equivalent to using WHOIS.
Here's just one scenario:
- I ("Ryan Sleevi") apply to Foo CA for example.com
, which is owned by "Andriano Santoni's Lightly
Validated Certificates" - you.
- Foo CA decides to employ 3.2.2.4.1, using 3.2.2.4(1)
- Note, as worded, all of 3.2.2.1 can be read as 'optional' for DV
certs, thus automatically met, but lets pretend its OV
- They verify "Andriano Santoni's Lightly Validated Certificates" is
a real company with a real existence using a QGIS. That's all that's
needed - there's no binding to the Applicant, just an existence proof
of the data.
- Alternatively, I send a photoshopped letter claiming your company
exists, valid under 3.2.2.1(4)
- Alternatively, the CA declares that "Google Maps" is a Reliable
Data Source (it isn't, but again, underspecified), and verifies that
there's an entry under 3.2.2.1(2) - despite the fact I just added the
entry
- They then need to verify whether or not I'm authorized to speak for
your company.
- The information used in 3.2.2.1 doesn't have to be used ("the CA
MAY use ..."), but remember, I may have made it up under 3.2.2.1
- The CA can directly call me, Ryan Sleevi, asking if I'm authorized
("the CA MAY establish the authenticity of the certificate request
directly with the Applicant Representative")
- The requirement to use an RMOC simply means that Foo CA could
decide to call up Jeremy, since Jeremy knows me, and say "Hey, does
Ryan work for Adriano Santoni" - that's all that's required.
- Finally, the CA contacts the registrar, and says "Hey, does Adriano
Santoni's Lightly Validated Certificates own example.com
" - and the registrar says sure
- Note: There's no consensus whether we're talking about the same
organization - perhaps I created a version incorporated in the US, but
you're incorporated in Italy
These are just a few of the legal-but-bad things you can do. I'm sure
we'll see the normal rush from some CAs saying "Yes, but we'd never do
that" - while ignoring the fact that some could, as it's valid under
the language, and we consistently see "That which is valid (or subject
to misinterpretation) is possible to use"
Could you provide an example of how you believe 3.2.2.4.1 "should"
work and offer the same level of assurance as the other methods,
without normatively prescribing the data sources used? From
conversations with both current and past employees of CAs, I am
adamantly convinced that there is not a consistent standard of
reliableness being applies. Google Maps being used as a Reliable Data
Source is not a hypothetical, despite it allowing community edits.
On Thu, Dec 21, 2017 at 4:00 AM, Adriano Santoni via Public
mailto:public@cabforum.org>> wrote:
Jeremy, I am not sure I fully understand the problems you describe.
Would it be possible for you to provide some concrete example
related to method #1, with some details, without of course
mentioning specific certificates and/or organizations?
Il 19/12/2017 22:30, Jeremy Rowley via Public ha scritto:
Hi all,
When reviewing the Symantec validation methods and the customers
using each method, I found an alarming number of customers
verified under 3.2.2.4.1 (Verification of a Domain Contact) or
3.2.2.4.5 (Domain Authorization Document) where the domain is not
technically associated with the entity. These two methods need
improvement or removal as the way they are currently lacks
sufficient controls to associate the domain verification with the
actual certificate approver. I’ve had too many calls with
customers explaining re-verification where the domain holder
didn’t understand that a cert issued for the domain. Although the
organization verification was successfully complete, the only tie
between the domain and organization is a call to the organization
that happened within the last years to approve the account for
issua
