Chunghwa Telecom votes Yes on Ballot SC2
Sincerely Yours,
Li-Chun Chen
_____
De: Servercert-wg [[email protected]] en nombre de Peter
Miškovič via Servercert-wg [[email protected]]
Enviado: miércoles, 25 de julio de 2018 7:30
Para: Tim Hollebeek; CA/Browser Forum Public Discussion List;
[email protected]
Asunto: Re: [Servercert-wg] Voting Begins: Ballot SC2 - version 2: Validating
certificates via CAA CONTACT
Disig abstains.
Regards,
Peter
From: Public <[email protected]> On Behalf Of Tim Hollebeek via Public
Sent: Thursday, July 19, 2018 5:03 PM
To: [email protected]
Cc: CA/Browser Forum Public Discussion List <[email protected]>
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:[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
本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件.
如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
Please be advised that this email message (including any attachments) contains
confidential information and may be legally privileged. If you are not the
intended recipient, please destroy this message and all attachments from your
system and do not further collect, process, or use them. Chunghwa Telecom and
all its subsidiaries and associated companies shall not be liable for the
improper or incomplete transmission of the information contained in this email
nor for any delay in its receipt or damage to your system. If you are the
intended recipient, please protect the confidential and/or personal information
contained in this email with due care. Any unauthorized use, disclosure or
distribution of this message in whole or in part is strictly prohibited. Also,
please self-inspect attachments and hyperlinks contained in this email to
ensure the information security and to protect personal information.
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
