We confirm that GDCA accept Peter’s sugguested solution on ballot 202.
Thanks.
Yongqiang ZHANG
原始邮件
发件人:Kirk Hall via [email protected]
收件人:[email protected]
发送时间:2017年8月1日(周二) 08:01
主题:[cabfpub] Ballot 202 and Unicode
Thanks for your email, Yongqiang.
It looks like GDCA can accept Peter Bowen’s suggested solution to this issue –
can you please confirm that?
Can the representatives of CFCA and SHECA also review Peter’s suggested
solution below, and let other Forum members know if you can also accept the
suggested solution?
If yes, Peter can then add the language changes to a new ballot he is working
on to update our BR definitions.
Thanks to you all.
Kirk Hall
From: zhangyq [mailto:[email protected]]
Sent: Thursday, July 27, 2017 4:08 AM
To: public [email protected]
Cc: Kirk Hall [email protected]; pzb [email protected]
Subject: [EXTERNAL]回复：Unicode
Hi All,
Thanks for the attention and work on our concerns.
We are deeply sorry for the fact that we have planned to issue certificates
with Chinese Domain Names but not one certificate of this kind has been issued,
and this is also why we failed to notice and raise our concerns during the
discussion period, apart from that, it took us quite some time during the
voting period to discuss these concerns internally, and no consensus was
reached until the last day before the voting period ends. We apologize for the
inconvenience caused to you.
We wish to restate our reasons for voting against Ballot 202 here:
1. From the perspective of certificates localization, most of the Browsers
support certificates in local languages;
2. And from the security point of view, there is not a simple and
straightforward method or mechanism for the Browser users to verify the
consistency between the Domain Names being accessed and Punycode encoded Domain
Names, therefore, it is not possible for Browser users to determine that the
certificate is issued to the Domain Name being accessed, and this will lead to
the distrust from the users;
3. Certificates subscribers may be confused by the Punycode codes in the
certificates converted from their Domain Names.
Regarding the solutions that we think will address these issues:
1. We agree with Peter’s proposal, and we quote from his comments “I saw Ryan’s
response to you and he suggests that "consistent and unambiguous
representation” is needed in the common name. Based on testing the 20,055
certificates, it looks like we can have this by allowing a CA to choose to
either use all LDH labels in a common name or use only NR-LDH labels and
U-labels, where the U-labels are created by converting the A-labels to Unicode.
This would give the option of two consistent and unambiguous representations —
one in punycode and one in Unicode”.
2. Another solution that we propose is that, for Non-English Domain Names, the
CN field of an SSL certificate adopts Unicode, while the combination of Unicode
and Punycode applies to each and every Domain Name in the SAN field, to
consider both machine recognition and recognition by human reading.
Thanks.
Yongqiang ZHANG
原始邮件
发件人:Kirk [email protected]
收件人:'赵改侠'[email protected]; [email protected];
[email protected]
抄送:Chris [email protected]
发送时间:2017年7月27日(周四) 13:30
主题:Unicode
Hi, everyone – as you know, Ballot 202 did not pass, but it will come back.
See the potential solution that Peter Bowen of Amazon has proposed on your
issue. Is this a good idea? Could you live with it in a new ballot? You can ask
questions of Peter if you want to…
Kirk
From: Peter Bowen [mailto:[email protected]]
Sent: Wednesday, July 26, 2017 5:05 PM
To: Kirk Hall [email protected]; CA/Browser Forum Public
Discussion List [email protected]
Subject: [EXTERNAL]Re: [cabfpub] Ballot 202 - Underscore and Wildcard
Characters
Kirk,
In order for any browser to access a website with an Internationalized Domain
Name, it must be able to convert Unicode (i.e. non-English language) to
LDH-labels (i.e. punycode), as it is LDH labels that are sent to the DNS
server. Therefore the situation where a browser can handle Unicode in the
address bar but cannot handle punycode in the certificate should not exist.
In order to address the concerns raised by CFCA, GDCA, and SHECA, I have spent
the last couple of hours processing all the unexpired certificates in CT logs
to quantify the impact of the rule proposed in this ballot and look at
alternatives.
There are currently 385,042 certificates with Internationalized Domain Names
(IDNs), including both IDNs where the ccTLD has non-ASCII characters and ones
where some other portion of the name has non-ASCII characters. Of these, zero
were issued by CFCA, GDCA, or SHECA. So there would be no known impact to these
CAs.
That being said, there are 20,055 certificates which have Unicode in the common
name issued by other CAs. Having Unicode common names is far less prevelant
than punycode common names; 364,987 certificates with IDNs do not have Unicode
common names. In testing in the browsers which I have on my desktop, I don’t
see any difference but it is possible that local browsers may show a difference.
Here are two sites to test:https://会影基地.cnandhttps://城惠网.cn
I saw Ryan’s response to you and he suggests that "consistent and unambiguous
representation” is needed in the common name. Based on testing the 20,055
certificates, it looks like we can have this by allowing a CA to choose to
either use all LDH labels in a common name or use only NR-LDH labels and
U-labels, where the U-labels are created by converting the A-labels to Unicode.
This would give the option of two consistent and unambiguous representations —
one in punycode and one in Unicode.
Adding this option for CAs would all full representation of languages in the
common name.
Thanks,
Peter
On Jul 26, 2017, at 9:41 AM, Kirk Hall via Public [email protected] wrote:
Peter, Ben, and Ryan – do you have a response to the punycode issue raised by
CFCA, GDCA, and SHECA?
From:Public [mailto:[email protected]]On Behalf Of?? via Public
Sent:Wednesday, July 26, 2017 1:44 AM
To:'CA/Browser Forum Public Discussion List' [email protected]
Cc:'赵改侠' [email protected]
Subject:[EXTERNAL][cabfpub] Reply: Ballot 202 - Underscore and Wildcard
Characters
CFCA votes No
we suggestthatthepunycodeshouldn'tbeappliedonSSLcerts in this approach.
Fornon-Englishcountries,thedomainnamemaybedisplayedwrongin
somebrowersinpunycodeandthegovernancepolicyrequiresthat
localCAshouldobeythelawstodisplaylocallanguagewhenccTLDisusedinlocallanguage.
IFpunycodeisusedandthebrowsers(Which I mean any browsers including local
browsers)couldn'ttranslateitintolocallanguage,thewebsitevisitorsmaybeconfused.
Zhang Yi
Business Research Competent
China Financial Certification Authority
Business Department
Address: Bldg. 2，#20，14th Kechuang street, YiZhuang Economic-Technological
Development Zone，Daxing District，Beijing , P. R. China
Postcode: 100176
TEL: +86 010-58903555
Mobile: +86 18510280028
Email:[email protected]
发件人:[email protected][mailto:[email protected]]代表Erwann
Abalea via Public
发送时间:2017年7月26日2:39
收件人:CA/Browser Forum Public Discussion List; Ben Wilson
主题:Re: [cabfpub] Ballot 202 - Underscore and Wildcard Characters
Bonsoir,
DocuSign France votes No.
While there are good clarifications around domain names, FQDNs, wildcards, and
reserved labels, there are a few drawbacks:
1. Underscores in SAN:dNSName entries. It’s not the current BR that disallows
underscores in dNSNames, it’s X.509 and RFC5280 (and current DNS
specifications), and there is no justification about allowing underscores other
than «it’s done by some admins» or «Microsoft allows it». While domain names
can contain anything (even characters such as '[({*$!?" ), dNSName shall
contain a host name, and host names shall only be composed of LDH labels. I’d
prefer the standards to be changed instead of explicitly allowing deviations
from the standard.
2. « Reserved IP address». The new definition now allows a CA to deliver a
certificate for an obviously invalid IP (I doubt anyone could claim «owning»
192.0.0.9 or 192.0.0.10, and I haven’t fully checked the others).
3. « Wildcard Domain Name». The new definition is not robust enough. An FQDN is
a sequence of Domain Labels—which can contain any character—, so «
*.domain.com» is a valid FQDN, so «*.*.domain.com» is a valid Wildcard Domain
Name according to this definition.
Cordialement,
Erwann Abalea
Le 12 juil. 2017à19:24, Ben Wilson via Public [email protected] aécrit :
Ballot 202 - Underscore and Wildcard Characters
The current Baseline Requirements do not expressly allow underscore characters
in Subject Alternative Names. This ballot seeks to clarify that one or more
underscore characters (“_”) are allowed in FQDNs. In many places it also
replaces the term "FQDN" with "Domain Name" because "Domain Name" now means
either "FQDN" or "Wildcard Domain Name". The ballot clarifies validation of
wildcard domain names. It also cleans up some of the language in Sections
3.2.2.4 and 7.1.4.2.1 of the Baseline Requirements.
The following motion has been proposed by Ben Wilson of DigiCert and endorsed
by Peter Bowen of Amazon and Ryan Sleevi of Google to introduce new Final
Maintenance Guidelines for the "Baseline Requirements Certificate Policy for
the Issuance and Management of Publicly-Trusted Certificates" (Baseline
Requirements).
--Motion Begins--
A. In Sections 1.3.2, 1.6 (Base Domain Name), 2.2, 3.2.2.4, 3.2.2.4.5,
3.2.2.4.6, 3.2.2.4.10, 3.2.2.4.11, 4.2.1, 4.9.1.1.6, and 4.9.11 of the Baseline
Requirements, REPLACE the words "Fully Qualified Domain Name" and "FQDN" with
"Domain Name".
B. In Section 1.6.1 of the Baseline Requirements, REPLACE the definition for
"Authorization Domain Name" with the following: The Domain Name used to obtain
authorization for certificate issuance for a given Domain Name. The CA may use
the FQDN returned from a DNS CNAME lookup as the Domain Name for the purposes
of domain validation. If the Domain Name is a Wildcard Domain Name, then the CA
MUST remove “*.” from the left most portion of requested Domain Name. The CA
may prune zero or more labels from left to right until encountering a Base
Domain Name and may use any one of the intermediate values for the purpose of
domain validation.
C. In Section 1.6.1 of the Baseline Requirements, INSERT the following
definition: "Domain Label: An individual component of a Domain Name."
D. In Section 1.6.1 of the Baseline Requirements, REPLACE the definition for
"Domain Name" with the following: A set of one or more Domain Labels, each
separated by a single full stop character (".").
E. In Section 1.6.1 of the Baseline Requirements, REPLACE the definition for
"Fully-Qualified Domain Name" with the following: A Domain Name that includes
the Domain Labels of all superior nodes in the Internet Domain Name System.
F. In Section 1.6.1 of the Baseline Requirements, REPLACE the definition for
"Reserved IP Address" with the following: An IPv4 or IPv6 address that the IANA
has "False" for Globally Reachable in either of the IANA Special-Purpose IP
Address Registries:
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtmlor
https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
G. In Section 1.6.1 of the Baseline Requirements, REPLACE the definition for
"Wildcard Certificate" with the following: A Certificate containing a Wildcard
Domain Name in any of the Subject Alternative Names in the Certificate.
H. In Section 1.6.1 of the Baseline Requirements, INSERT the following
definition: "Wildcard Domain Name: A Domain Name consisting of a single
asterisk character ("*") followed by a single full stop character (".")
followed by a Fully-Qualified Domain Name."
I. In Section 2.2 of the Baseline Requirements, INSERT the word "requested" in
the fourth sentence between the words "processing CAA records for" and "Domain
Names" so that it reads, "processing CAA records for requested Domain Names".
J. REPLACE the second paragraph of Section 3.2.2.4 of the Baseline Requirements
so that it reads, "The CA SHALL confirm that, as of the date the Certificate
issues, the CA has validated each Domain Name listed in the Certificate using
at least one of the methods listed below, or is within the Domain Namespace of
a Fully Qualified Domain Name (FQDN) that has been validated using at least one
of the methods listed below (not including the method defined in section
3.2.2.4.8)."
K. REPLACE Section 3.2.2.6 of the Baseline Requirements in its entirety with:
3.2.2.6. Additional Validation for Wildcard Certificates
Before issuing a Wildcard Certificate, the CA MUST establish and follow a
documented procedure[^pubsuffix] that determines if the FQDN portion of any
Wildcard Domain Name in the certificate is “registry-controlled” or is a
“public suffix” (e.g. “*.com”, “*.co.uk”, see RFC 6454 Section 8.2 for further
explanation).
If the FQDN portion of any Wildcard Domain Name in the certificate is
"registry-controlled" or is a "public suffix", CAs MUST refuse issuance unless
the applicant proves its rightful control of the entire Domain Namespace. (e.g.
CAs MUST NOT issue "*.co.uk" or "*.local", but MAY issue "*.example.com" to
Example Co.).
[^pubsuffix] Determination of what is “registry-controlled” versus the
registerable portion of a Country Code Top-Level Domain Namespace is not
standardized at the time of writing and is not a property of the DNS itself.
Current best practice is to consult a “public suffix list” such
ashttp://publicsuffix.org/(PSL), and to retrieve a fresh copy regularly. If
using the PSL, a CA SHOULD consult the "ICANN DOMAINS" section only, not the
"PRIVATE DOMAINS" section. The PSL is updated regularly to contain new gTLDs
delegated by ICANN, which are listed in the "ICANN DOMAINS" section. A CA is
not prohibited from issuing a Wildcard Certificate to the Registrant of an
entire gTLD, provided that control of the entire namespace is demonstrated in
an appropriate way.
L. REPLACE Section 7.1.4.2.1 of the Baseline Requirements in its entirety with:
7.1.4.2.1 Subject Alternative Name Extension
Certificate Field: extensions:subjectAltName
Required/Optional: Required
Contents: This extension MUST contain at least one entry. Each entry MUST be
one of the following types:
1. dNSName: the entry MUST contain either a Fully-Qualified Domain Name or
Wildcard Domain Name that the CA has validated in accordance with section
3.2.2.4. FQDNs and the FQDN portion of Wildcard DNs must comply with RFC 5280
section 4.2.1.6 with the following exception: underscore characters ("_") are
allowed in Domain Labels such that replacing all underscore characters with
hyphen characters ("-") would result in a valid Domain Label. CAs MUST NOT
include Domain Labels which have hyphens as the third and fourth characters
unless the first character is "x" or "X", the second character is "n" or "N",
and the fifth and later characters are a valid Punycode string. CAs MUST
additionally validate that Wildcard DNs are consistent with section 3.2.2.6.
The entry MUST NOT contain an Internal Name.
2. iPAddress: the entry MUST contain an IP address that the CA has validated in
accordance with Section 3.2.2.5. The entry MUST NOT contain a Reserved IP
Address.
M. REPLACE subsection a. of Section 7.1.4.2.2 of the Baseline Requirements with:
a. Certificate Field: subject:commonName (OID 2.5.4.3)
Required/Optional: Deprecated (Discouraged, but not prohibited)
Contents: If present, this field MUST contain a single IP address or Domain
Name that is one of the values contained in the Certificate’s subjectAltName
extension (see Section 7.1.4.2.1). When including a Domain Name in a common
name, CAs MUST only use LDH labels as defined in RFC 5890 and MUST NOT use
U-labels. When including an IPv6 address in a common name, CAs MUST use a
format conforming to Section 4 or Section 5 of RFC 5952. When including an IPv4
address in a common name, CAs MUST encode the name as an IPv4Address as defined
in RFC 3986.
--Motion Ends--
The procedure for approval of this Final Maintenance Guideline ballot is as
follows (exact start and end times may be adjusted to comply with applicable
Bylaws and IPR Agreement):
BALLOT 202 Status: Final Maintenance Guideline Start time (22:00 UTC) End time
(22:00 UTC)
Discussion (7 to 14 days) July 12, 2017 to July 19, 2017
Vote for approval (7 days) July 19, 2017 to July 26, 2017
If a vote of the Forum approves this ballot, the Chair will initiate a 30-day
IPR Review Period by sending out an IPR Review Notice.
After 30 days of announcing the IPR Review period by the Chair:
(a) If Exclusion Notice(s) are filed, this ballot approval is rescinded and a
PAG will be created; or (b) If no Exclusion Notices are filed, this ballot
becomes effective at end of the IPR Review Period.
From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final Maintenance
Guideline, such ballot will include a redline or comparison showing the set of
changes from the Final Guideline section(s) intended to become a Final
Maintenance Guideline, and need not include a copy of the full set of
guidelines. Such redline or comparison shall be made against the Final
Guideline section(s) as they exist at the time a ballot is proposed, and need
not take into consideration other ballots that may be proposed subsequently,
except as provided in Bylaw Section 2.3(j).
Votes must be cast by posting an on-list reply to this thread on the Public
list. A vote in favor of the motion must indicate a clear 'yes' in the
response. A vote against must indicate a clear 'no' in the response. A vote to
abstain must indicate a clear 'abstain' in the response. Unclear responses will
not be counted. The latest vote received from any representative of a voting
member before the close of the voting period will be counted. Voting members
are listed here:https://cabforum.org/members/
In order for the motion to be adopted, two thirds or more of the votes cast by
members in the CA category and greater than 50% of the votes cast by members in
the browser category must be in favor. Quorum is half of the number of
currently active Members, which is the average number of Member organizations
that have participated in the previous three Forum-wide meetings (both
teleconferences and face-to-face meetings). Under Bylaw 2.2(g), at least the
required quorum number must participate in the ballot for the ballot to be
valid, either by voting in favor, voting against, or abstaining.
Ballot 202.pdf_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
