I don't think we could support such a ballot, without having an explanation of why you believe method #1 is valuable and equivalent - even if tightened up - to the other methods of validation.
On Fri, Dec 22, 2017 at 2:22 AM, Adriano Santoni via Public < [email protected]> wrote: > 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 < > [email protected]> 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-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 >> [email protected]https://cabforum.org/mailman/listinfo/public >> >> >> >> _______________________________________________ >> Public mailing list >> [email protected] >> https://cabforum.org/mailman/listinfo/public >> >> > > > _______________________________________________ > Public mailing list > [email protected] > https://cabforum.org/mailman/listinfo/public > >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
