[cabfpub] Domain validation
Dimitris Zacharopoulos
jimmy at it.auth.gr
Tue May 16 06:07:45 UTC 2017
Jeremy,
This is excellent work and helps people understand each method a lot better.
Some comments:
"The CA MUST record the subsection and version of the Baseline
Requirements used to validate an Applicant’s control over each FQDN
included in an issued certificate"
When is this expected to become effective?
In methods 3.2.2.4.1, 3.2.2.4.2, 3.2.2.4.3, b (2), you say that the CA
must verify that the WHOIS information for the Base Domain has not
changed since the CA performed the verification process. Is this the
WHOIS information record itself or should CAs be looking for the Domain
Contact to appear in the WHOIS record? I'm asking because some WHOIS
databases do not release Domain Contact information and CAs require an
official document from the Domain Registrar that contains information
about the domain owner and contacts for the initial domain validation.
For example, this is the WHOIS record for example.gr:
Domain Name:example.gr
Domain Handle:dr-1234-gr
Protocol Number:1234
Creation Date:24-07-1997
Expiration Date:31-12-2017
Updated Date:05-11-2015
Registrar:FOO
Registrar Referral URL:http://www.FOO.gr
Registrar Email:registrar at FOO.gr
Registrar Telephone:+30.123456
Whois Server:
Bundle Name:example.gr
Name Server:XXXX.example.gr
Name Server:XXXXXX.example.gr
According to your proposal, CAs only need to check if the record above
has not changed?
Also, there is a small typo in the 3rd paragraph of 3.2.2.4.2 a (FQNs
--> FQDNs).
Thanks,
Dimitris.
On 15/5/2017 11:41 μμ, Jeremy Rowley via Public wrote:
>
> While working on implementing the methods defined by ballot 169, we
> noticed a lot of inconsistencies in the language and process. This
> made some of the methods confusing, especially on how they applied to
> reuse of information and verification of subdomains/wildcards.
> Attached is a proposal that we think clarifies the process and
> tightens up the language.
>
> A couple of notes:
>
> 1. The proposal doesn’t intend to substantially change any of the
> methods. However, this is DigiCert’s interpretation of the
> requirements. Given the previous language, disagreement on the
> interpretation is likely and will highlight the need for a
> clarifying ballot.
> 2. This method doesn’t necessarily replace 190. If longer discussion
> is needed (because there are lots of changes), then this could be
> a subsequent revision to the validation methods and include more
> stringent controls (like reverifying WHOIS information within 30
> days and restricting sub-domain methods). For now, I tried to keep
> the process and reuse the same.
> 3. The proposal separates out sub domain reuse, reuse of
> documentation, and splits the longer methods into discrete steps.
> There are lots of redundant sections. This is intentional. The
> goal is to (eventually) talk about each method discretely and
> decide what requirements are tied to document reuse and sub-domain
> validation.
>
> Look forward to your comments.
>
> 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/20170516/e2c9240b/attachment-0003.html>
More information about the Public
mailing list