[Servercert-wg] [cabfpub] Voting Begins: Ballot SC2 - version 2: Validating certificates via CAA CONTACT
Dimitris Zacharopoulos
jimmy at it.auth.gr
Sun Jul 22 12:10:17 MST 2018
HARICA votes "yes" to ballot SC2.
Dimitris.
On 19/7/2018 6:02 μμ, Tim Hollebeek via Public 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:domainowner at example.com”
>
> . 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
>
>
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20180722/45de4b20/attachment.html>
More information about the Servercert-wg
mailing list