[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
> 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 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