[cabfpub] Verification of Domain Contact and Domain Authorization Document

Adriano Santoni adriano.santoni at staff.aruba.it
Thu Dec 21 09:00:16 UTC 2017

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 
> (Verification of a Domain Contact) or (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 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 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 at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171221/031a8511/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4025 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171221/031a8511/attachment-0003.p7s>

More information about the Public mailing list