[Servercert-wg] Voting Begins: Ballot SC2 - version 2: Validating certificates via CAA CONTACT

y-iida at secom.co.jp y-iida at secom.co.jp
Wed Jul 25 03:25:11 MST 2018


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Secom Trust Systems votes Yes.

Best regards,
- --
  iida

From: Public [mailto:public-bounces at cabforum.org] On Behalf Of
 Tim Hollebeek via Public
Sent: Friday, July 20, 2018 12:03 AM
To: servercert-wg at cabforum.org
Cc: CA/Browser Forum Public Discussion List
Subject: [cabfpub] Voting Begins: Ballot SC2 - version 2:
 Validating certificates via CAA CONTACT


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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAltYT+sACgkQYYPdCnCyRyqr/QCfV534sNriRUJwzGHEmifghhkn
JC0AnReYxd1WJ1s+ZDAeg6Tc8Io9a8uZ
=J2Pf
-----END PGP SIGNATURE-----


More information about the Servercert-wg mailing list