[cabf_validation] Draft ballot from London on CAA Contact
Moudrick M. Dadashov
md at ssc.lt
Sun Jul 8 04:04:53 MST 2018
Hi Tim, ok, maybe Francisco could update us more on the recent
developments..
Thanks,
M.D.
On 7/7/2018 1:36 AM, Tim Hollebeek wrote:
>
> Thank you, Moudrick.
>
> We’re aware of and continue to support efforts to provide access to
> WHOIS information by those with a legitimate need in a secure manner.
> I know the topic is still very active at ICANN and at various
> deliberative bodies within Europe. This proposal is in no way intended
> to replace solutions like authenticated RDAP or publication of masked
> emails by registrars/registries.
>
> However, given the decision of some registrars/registries to
> unilaterally implement full redaction instead of more reasonable
> solutions, workarounds like this are unfortunately necessary, and I
> hope we can make them available to customers who need them.
>
> -Tim
>
> *From:*Moudrick M. Dadashov [mailto:md at ssc.lt]
> *Sent:* Friday, July 6, 2018 5:47 PM
> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>; CA/Browser Forum
> Validation WG List <validation at cabforum.org>
> *Subject:* Re: [cabf_validation] Draft ballot from London on CAA Contact
>
> FYI https://www.icann.org/resources/pages/gtld-registration-data-specs-en
>
> Thanks,
> M.D.
>
> On 7/7/2018 12:04 AM, Tim Hollebeek via Validation wrote:
>
> I’d like to get endorsers and start discussing this. It will
> allow DNS-savvy customers to get around registrars/registries that
> redact contact information due to an overly-broad application of GDPR.
>
> I’m leaving SC1 available for a ballot on elections, etc.
>
> Draft text:
>
> Ballot SC2: CAA Contact Property and Associated Validation Methods
>
> Purpose of Ballot: Increasingly, contact information is not
> available in WHOIS due to concerns about potential GDPR
> violations. This ballot specifies a method by which domain
> holders can publish their contact information via DNS, and how CAs
> can use that information for validating domain control.
>
> The following motion has been proposed by Tim Hollebeek of
> DigiCert and endorsed by ??? and ???.
>
> --- MOTION BEGINS ---
>
> This ballot modifies the “Baseline Requirements for the Issuance
> and Management of Publicly-Trusted Certificates” as follows, based
> on Version 1.5.7:
>
> Add Section 3.2.2.4.13: Domain Owner Email published in DNS
>
> Confirm the Applicant's control over the FQDN by (i) sending an
> email to a DNS domain name holder, (ii) including a Random Value
> in the email, and (iii) receiving a confirming response utilizing
> the Random Value. The CA MUST send the email to an email address
> found in:
>
> 1. DNS TXT record specified as
> "domain-authorization-contact" (e.g.,
> domain-authorization-contact=domainowner at example.com
> <mailto:domain-authorization-contact=domainowner at example.com>), or
>
> 2. CAA Contact property record as defined in Appendix B.
>
> Each email MAY confirm control of multiple FQDNs, provided the
> email address used is a DNS contact email address for each FQDN
> being confirmed.
>
> The Random Value SHALL be unique in each email. The email MAY be
> re-sent in its entirety, including the re-use of the Random Value,
> provided that its entire contents and recipient SHALL remain
> unchanged. The Random Value SHALL remain valid for use in a
> confirming response for no more than 30 days from its creation.
> The CPS MAY specify a shorter validity period for Random Values.
>
> Note: Once the FQDN has been validated using this method, the CA
> MAY also issue Certificates for other FQDNs that end with all the
> labels of the validated FQDN. This method is suitable for
> validating Wildcard Domain Names.
>
> Add Section 3.2.2.4.14: Domain Owner Phone published in DNS
>
> Confirm the Applicant's control over the FQDN by calling the DNS
> domain name holder phone number and obtaining a response
> confirming the Applicant's request for validation of the FQDN. The
> CA MUST place the call to a phone number identified in:
>
> 1. DNS TXT record specified as
> "domain-authorization-contact" (e.g.,
> domain-authorization-contact=+1 310 555 1212), or
>
> 2. CAA Contact property record as defined in Appendix B.
>
> Each phone call SHALL be made to a single number and MAY confirm
> control of multiple FQDNs, provided that the phone number is
> identified by the DNS contact as a valid contact method for every
> Base Domain Name being verified using the phone call.
>
> Note: Once the FQDN has been validated using this method, the CA
> MAY also issue Certificates for other FQDNs that end with all the
> labels of the validated FQDN. This method is suitable for
> validating Wildcard Domain Names.
>
> Add Appendix B: CAA Contact Tag
>
> The syntax for the contact property is similar to the iodef
> property. It allows domain owners to publish contact information
> in DNS in addition to WHOIS for the purpose of validating domain
> control.
>
> CAA contact Property
>
> contact <URL> : The contact property entry specifies the
> authorized means of contacting the holder of the domain or another
> party who is authorized to approve issuance of certificates for
> the domain.
>
> The contact property specifies a means of contacting the domain
> holder, or another party that is authorized to approve issuance of
> certificates for the domain in question.
>
> The contact property takes a URL as its parameter. The following
> URL scheme types SHOULD be implemented:
>
> mailto: An SMTP email address where the domain holder or other
> authorized party can be contacted.
>
> tel: A telephone number where the domain holder or other
> authorized party can be contacted.
>
> The following is an example where the holder of the domain
> specified the contact property using both an email address and a
> phone number.
>
> $ORIGIN example.com
>
> . CAA 0 issue “ca.example.net”
>
> . CAA 0 contact “mailto:domainowner at example.com”
> <mailto:domainowner at example.com%E2%80%9D>
>
> . CAA 0 contact “tel:+1 310 555 1212”
>
> The CONTACT tag will also be registered with IANA as a reserved
> CAA tag, and will be submitted for inclusion in a future version
> of RFC 6844.
>
> --- MOTION ENDS ---
>
> A comparison of the changes can be found at:
> https://github.com/cabforum/documents/commit/d71fea31b69d5541cb34b9c2cae567d6ade7e3a2#diff-7f6d14a20e7f3beb696b45e1bf8196f2
>
> The procedure for approval of this ballot is as follows:
>
> Discussion (7+ days)
>
> Start Time: TBD
>
> End Time: TBD
>
> Vote for approval (7 days)
>
> Start Time: TBD
>
> End Time: TBD
>
> -Tim
>
>
>
>
> _______________________________________________
>
> Validation mailing list
>
> Validation at cabforum.org <mailto:Validation at cabforum.org>
>
> https://cabforum.org/mailman/listinfo/validation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180708/8ebb6289/attachment.html>
More information about the Validation
mailing list