[cabf_validation] Outline of Method 1 Replacement

[Dimitris Zacharopoulos]

BTW, I forgot the disclaimer that there was no recording and these
minutes came from my notes and memory to the best of my knowledge.
Please offer updates to the minutes if I missed or misunderstood
something :)

Dimitris.


On 12/3/2018 5:14 μμ, Dimitris Zacharopoulos via Validation wrote:
>
> Here are my notes for the discussion during the Validation WG Summit
> regarding Method 1. Attached is the presentation by Bruce and Mads
> (posting with their permission).
>
> Tim, Wayne, feel free to spawn a new thread with this information if
> you think it is best for the discussion.
>
>
> Dimitris.
>
>
> --- BEGIN MINUTES ---
>
> Presentation from Bruce Morton and Mads Egil Henriksveen
>
> - The terms "Ownership" and "right to use" are in several sections of
> the BRs and EVG.
> - Minimum requirements for this validation method is typical OV
> validation.
> - Require Organization Contact who must be an employee of the
> Organization. This Contact will sign the Subscriber Agreement. This
> Contact is considered an Applicant Representative. This person also
> approves the issuance of certificates.
>
> For ALL OV Certificates you need the following 3 steps:
> - Domain Validation
> - Identity Validation
> - Authorization to issue
>
> Sometimes, Registrant Name might be incomplete (missing "Inc.") or a
> parent, subsidiary or affiliate.
> QGIS, QIIS, QTIS are used to verify the Organization.
> Registrant name must be validated using address or other unique
> information from registry
>
> Buypass uses the following validated information about the Applicant:
>
> - Organization Name
> - Registration Number
> - Organization address
> - Phone number
> - Email address
>
> This information is validated against the National Registry.
>
> Then, they try to match "Applicant" information to the "Domain Name
> Registrant" information.
> Example: National Registry of Norway --> Domain Name Registrant
>
> They do not allow Applicant's parent, subsidiary or affiliate for
> Domain Validation
>
> Wayne: By manipulating the WHOIS entries, an Applicant Representative
> could get authorization to issue a certificate for a different company.
>
> Domain Ownership is proved for OV/EV.
>
> Threats exist in Domain ownership which are different from Domain control
>
> Ryan Sleevi: We need to understand what we are validating and Mads
> answered that we are validation "ownership" with 3.2.2.4.1.
>
> Geoff: A domain owner could add an arbitary organization name. Wayne:
> If I register an irrelevant domain and include an arbitrary
> organization name, "who cares"?
>
> The ultimate goal is "if the domain owner has approved the request"
>
> Mozilla Survey Feedback
> - 26 of 54 CAs use Method 1
>
> Threats:
> - The Applicant is not the Registrant
> - The Applicant Representative is not permitted to approve domain use
> - Applicant has not proven to be the owner of the domain
>
> If a Registrar required complete EV-type Registrant information in the
> WHOIS entry, one-to-one mapping, we would have a clear view of the owner.
>
> In the Norway case where the Registrant information is one-to-one, we
> need to solve the "Authorized Representative" if that contact
> information is authorized to approve the issuance of a certificate.
>
> If we had assurances for the Domain Ownership, we would still need
> something better to determine the "Authorized Representative". The
> other methods have "Authorized Representative" in the form of email
> addresses and other contact information (telephone number, address) of
> the Domain Contact.
>
> Geoff: Proposal to ICANN to include EV-information in the Registrant
> information.
>
> Sleevi: The Applicant needs to be treated as "hostile" party until you
> verify. CAs must bind the Public Key with the Domain, not the
> Organization.
>
> All information in the Registrant Information (email, phone, postal
> address) is treated as "Authorized Representative". Even if the
> Contact Person is "IT Center", a call to this number and a dialog like
> the following should suffice for the verification and authorization.
>
> - CA: "I need to reach the IT Center to verify a Certificate Request"
> - Domain Owner: "Yes you have reached the IT Center"
> - CA: "We have received a Public Key (blah blah, hash of the key) for
> Domain example.com. Can you confirm the request and authorize issuance?"
> - Domain Owner: "Yes"
> That's all. Similar to email aliases where we don't know the exact
> Natural Persons in the recipient list, the same applies to the
> telephone number or if using the postal address.
>
> If the WHOIS information is unambiguous (one-to-one) between the
> domain and the domain owner, we could use strong Applicant
> Representative authentication to get Certificate issuance approval
> (like "EV Level" authentication, but authentication of methods 2, 3, 4
> would suffice as well).
>
> The only "true" source of information to be treated as "Valid" is the
> WHOIS (or Registrar/Registry information). This is true because the
> Domain Owner makes sure that the information listed in the
> Registration Entry is accurate and dependable.
>
> To summarize (Dimitris):
>
> - CAs must treat the Applicant as hostile.
> - CAs must trust the Domain Registrant information as the only
> accurate information related to the Domain.
> - CAs must treat the Domain Contact information as a way to contact
> the Authorized Representative that will approve the Request.
>
> - If the Registrant information in the WHOIS data by the Registrar is
> one-to-one with Organizations in a particular jurisdiction (as it
> happens for some ccTLDs), it is a reliable method to establish
> ownership for the Domain.
> - By using the Organization's "Registration Number" in the Domain
> Registrant information for a particular Domain, the CA can find
> "Authorized Representative" for that Organization by looking up
> Qualified Information Sources such as National Company Registries to
> contact the Domain Owner.
> - Since this is not a globally enforced requirement for Registrars, a
> possible improvement for this method to the level of assurance of
> methods 2, 3, 4, would be to require the Domain Owner to list
> Registration Number, Jurisdiction of Incorporation and address (as
> required for EV) IN THE DOMAIN REGISTRANT record. Therefore, this
> validation method would ONLY BE USED if an unambiguous representation
> of the Domain Owner was included in the Domain Registrant information.
> The CA would then need to contact the Domain Owner by using
> QGIS/QIIS/QTIS by using the Registration Number and Judisdiction of
> Incorporation (one-to-one mapping with the Domain Owner) and use this
> information to contact the "Authorized Representative". This is an
> auditable criteria as CAs that use this method to validate domains
> will need to prove to their auditors how they ensure the one-to-one
> mapping between the Domain and the Domain Owner.
>
> --- END MINUTES ---
>
>
>
>
>
> On 12/3/2018 12:45 πμ, Dimitris Zacharopoulos wrote:
>> Hi Wayne,
>>
>> I am still compiling the minutes on the Method 1 discussion we had
>> during the Validation WG Summit. Please allow 1-2 days to get all my
>> notes straight. I just received the presentation from Mads. I think
>> the minutes will be useful to the WG and this thread. I was also left
>> with the impression of a way to improve method 1 and turn it in a
>> robust new method which will have at least the same (if not better)
>> level of assurance than the existing methods.
>>
>>
>> Thanks,
>> Dimitris.
>
>
>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180312/c9f3b96c/attachment.html>