Hi Tim, Can you please indicate where the Redline Copy is available? As you can see from https://cabforum.org/pipermail/servercert-wg/2018-July/000021.html , it's rather difficult to understand what is actually proposed by this ballot and review it accordingly, due to the substantial formatting issues.
On Thu, Jul 19, 2018 at 11:02 AM Tim Hollebeek via Servercert-wg < [email protected]> wrote: > > > Administrivia: > > > > 1. 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. > 2. 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
