Mozilla abstains on ballot SC2. While I do believe this method is beneficial, I have a few concerns that can be addressed with more time:
- the concerns that Google raised were never clearly resolved on the list. - the reference to “domain being validated” in the appending is unclear. Is that the FQDN or ADN? - I wasn’t yet subscribed to the SCWG list when the review period started, so I and I suspect others were not fully prepared for this voting period to begin. I’d rather take a bit more time and get this right. - Wayne PS - I’m on vacation this week. Apologies if I’m missing some of the nuance of this discussion. > > > From: Servercert-wg <[email protected]> On Behalf Of Tim > Hollebeek via Servercert-wg > Sent: Thursday, July 19, 2018 8:03 AM > To: [email protected] > Cc: CA/Browser Forum Public Discussion List <[email protected]> > Subject: [Servercert-wg] Voting Begins: Ballot SC2 - version 2: Validating > certificates via CAA CONTACT > > > Administrivia: > > This ballot is being cross-posted to the CABF public mailing in line with the > consensus from last Thursday’s call that it is important everyone is aware of > the ballot, and that not everyone is on the SCWG list yet. > I promised an IETF independent stream draft for the same proposal, so it can > get feedback from those at IETF. I still intend to do so, but I am working > with a colleague on setting up a github account for DigiCert IETF efforts to > make it easier for others to collaborate with us on IETF submissions. I > anticipate we will have that set up and the draft submitted some time next > week. The IETF draft will allow IETF to review the method and make suggested > improvements. It should not block adoption of the current proposal by CABF. > DigiCert intends to submit a ballot to adopt IETF’s improvements once the > IETF process is complete. > > 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 Bruce Morton of Entrust and Doug Beattie of GlobalSign. > > --- 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 the 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 the 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 Section 3.2.2.4.15: Domain Owner Email published in TXT record > > 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 the DNS TXT 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. > > ##### 3.2.2.4.16 Domain Owner Phone published in TXT record > > 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 the DNS TXT record 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. > > Schemes other than "mailto:"; or "tel:" MUST NOT be used. Telephone numbers > MUST include the country code and be global phone numbers as defined by RFC > 3966. > > 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:[email protected]” > . CAA 0 contact “tel:+1-310-555-1212” > > ## Support for Legacy Systems > > Some systems still do not have sufficient support for CAA records. To allow > users of those systems to specify contact information, a legacy format using > text records is allowed. The CAA contact property SHOULD be used instead of > TXT records, where feasible. > > The DNS TXT record MUST be placed on the "_caa_contact" subdomain of the > domain being validated. The DNS record MUST be named > "domain-authorization-email" or "domain-authorization-phone". The value of > "domain-authorization-email" MUST contain a valid email address, or it cannot > be used. The value of "domain-authorization-phone" must be a global phone > number, including country code, as defined in RFC 3966 or it cannot be used. > --- MOTION ENDS --- > > A comparison of the changes can be found at: > https://github.com/cabforum/documents/compare/SC2-CAA-Contact?expand=1 > > The procedure for approval of this ballot is as follows: > > Discussion (7+ days) > > Start Time: 2018-07-11 10:30am EST > > End Time: 2018-07-19 11:00am EST > > Vote for approval (7 days) > > Start Time: 2018-07-19 11:00am EST > > End Time: 2018-07-26 11:00am EST > > _______________________________________________ > Servercert-wg mailing list > [email protected] > http://cabforum.org/mailman/listinfo/servercert-wg
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
