2015-11-12 Minutes
Minutes of CA/B Forum Teleconference – November 12, 2015
Attendees: Atsushi Inaba, Atilla Biller, Ben Wilson, Billy VanCannon, Bruce Morton, Connie Enke, Davut Tokgoz, Dean Coclin, Dimitris Zacharopoulos, Doug Beattie, Eddy Nigg, Gervase Markham, Kirk Hall, Li-Chun Chen, Neil Dunbar, Patrick Tronnier, Tim Hollebeek, Tim Shirley, Tyler Myers, Volkan Nergiz, Wayne Thayer
Antitrust Statement Read
Roll Call completed
Agenda Reviewed.
Minutes of 29 October meeting: The minutes were approved and will be publicized.
Ballot Status: The policy working group has 2 ballots (154 and 155) which are currently open for voting. Other ballots will be coming from Policy WG. Tim H said we should discuss the policy for what the effective dates of these ballots should be. Ballot 153, short lived certificates, failed earlier in the week.
Proposed Mis-issuance ballot: Sig was unable to join but was encouraged by the discussions on the mailing list. Dean mentioned that he received a message from the public in the UK who stated that the HMRC uses SSL certificates which contain information that should not be public. Gerv questioned how a CA would vet a value belonging to an individual issued by the HMRC. Dean said he had just received the information and hadn’t had time to review carefully but would send the link out to the list so others can review it.
Domain Validation Ballot: Kirk said the Validation Working Group (VWG) had finished its work on the proposed changes to the Domain Validation Methods Ballot, and just had five remaining questions to resolve. The VWG did not meet the prior week, so Kirk wanted to review the five questions with the Forum and bring back comments for the next VWG. He will also pose the five open questions by an email to the Public list so we can have more feedback.
(1) Richard Barnes of Mozilla suggested we make the following change to new validation method No. 9:
Proposal 1: In line L of draft
CURRENT DRAFT:
“9. Having the Applicant demonstrate control over the FQDN by the Applicant requesting and then installing a Test Certificate issued by the CA on the FQDN which is accessed and then validated via https by the CA over an Authorized Port.”
Richard proposes to add: “*** or installing a Test Certificate containing a Random Value or Request Token” as shown:
- Having the Applicant demonstrate control over the FQDN by the Applicant requesting and then installing a Test Certificate issued by the CA on the FQDN or installing a Test Certificate containing a Random Value or Request Token which is accessed and then validated via https by the CA over an Authorized Port.
Richard’s reasoning: “This liberalization would cover the DVSNI proposal being considered in ACME, and seems to offer equivalent protection to the other option. (Either way the cert contains something specified by the CA.)”
Richard’s added language does not specifically say who issues the Test Certificate – the CA or the Applicant – but it implies the Applicant generates the Test Certificate.
As a separate question, it is not clear whether the Random Value or Request Token must come from the CA – Richard’s language does not specify that.
The defined term Random Value says the value must come from the CA. The defined term Request Token says only that the Request Token is a “value derived in a method specified by the CA from the public key to be certified” – here is the current definition:
Request Token: A value derived in a method specified by the CA from the public key to be certified. The uniqueness of the Request Token and the irreversibility of the derivation to be at least as strong as those of the cryptographic signature algorithm to be used to sign the certificate.
It is unclear exactly how an Applicant receives a Request Token from a CA – does the CA calculate the value and transmit it to the Applicant to be used in a practical demonstration? Or does the CA send the Applicant the “method” to be used to calculate the Random Value? There is general agreement that all “practical demonstration” methods like this one should be unpredictable and not able to be copied or used by a hacker.
Questions: (1) Should Richard Barnes’ suggested edit be accepted? (2) Do we need to edit or clarify either Richard’s language or the definition of Request Token?
(2) The second open question for the current Domain Validation ballot also comes from Richard Barnes of Mozilla, and is as follows.
Proposal 2: In line H
CURRENT DRAFT:
“6. Having the Applicant demonstrate control over the requested FQDN by installing a Random Value (contained in the name of the file, the content of a file, on a web page in the form of a meta tag, or any other format as determined by the CA) under “/.well-known/validation” directory on an Authorized Domain Name, that can be validated over an Authorized Port; or”
Richard proposes to add the following language as shown: “*** or any other path under .well-known registered by IANA for this purpose”
- Having the Applicant demonstrate control over the requested FQDN by installing a Random Value (contained in the name of the file, the content of a file, on a web page in the form of a meta tag, or any other format as determined by the CA) under “/.well-known/validation” directory on an Authorized Domain Name, or any other path under .well-known registered by IANA for this purpose that can be validated over an Authorized Port; or
Richard’s reasoning: “For automated systems like ACME, they’re going to want a much more precise definition of the validation process than what’s in this document, and they may want to use different .well-known paths to indicate different methods that are all compliant with this section. Requiring the IANA registration allows these differences to exist, but in a controlled way.”
On the call, it was noted that only a single path “/.well-known/validation” directory on an Authorized Domain Name” was chosen intentionally – so that webmasters could be informed to lock down this path on their websites to avoid allowing a hacker to post a bogus credential (such as a bogus Random Value, etc.) and obtain a cert by practical demonstration for a domain they do not really own or control. The sentiment on the call was against this change. One comment was that if a different path was needed in the future, it could be discussed and added later by a separate ballot if justified.
(3) Peter Bowen of Amazon did not submit specific new language, but posed the following comment about new Method No. 7 shown below:
Proposal 3: In line J of current draft (Method No. 7)
“In Item J, it suggests that the random token is only valid for a FQDN validation.
“I think DNS validation should be allowed for domain hierarchies in addition to specific FQDNs. A domain registrant should be able to choose to approve all FQDNs under [corp.example.com] by adding a record for [corp.example.com].”
Here is the current Ballot language for Method No. 7:
“7. Having the Applicant demonstrate control over the requested FQDN by the Applicant making a change to information in a DNS record for an Authorization Domain Name where the change is to insert a Random Value or Request Token; or “
Kirk noted we had discussed before the problem of “kirkstore.shopping.com” – Kirk might have control over the third level FQDN, but might not have control over the SLDN (Base Domain) of shopping.com, so even though Kirk could demonstrate control for kirkstore.shopping.com, he should not use that to get a cert for shopping.com.
Doug Beattie thought that Peter might be misreading Authorization Domain Name, which is defined as follows:
“Authorization Domain Name: The Domain Name used to obtain authorization for certificate issuance or a given FQDN. The CA may use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation. If the FQDN starts with a wildcard character, then the CA MUST remove all wildcard labels from the left most portion of requested FQDN. 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.“
“Base Domain Name: The portion of an applied-for FQDN that is the first domain name node left of a registry-controlled or public suffix plus the registry-controlled or public suffix (e.g. “example.co.uk” or “example.com”). For gTLDs, the domain [www.[gTLD][2]] will be considered to be a Base Domain. “
Questions for Discussion:
(1) Is Doug correct that the current definition of Authorized Domain Name (see underlined text above) would already satisfy Peter’s suggestion that proving control of any FQDN by making a change to the DNS record for that FQDN is sufficient to get a certificate for any lower level domain it contains, including the SLDN or Base Domain? If yes, are any changes needed?
(2) More generally, do the members agree with Peter’s statement that “A domain registrant should be able to choose to approve all FQDNs under [corp.example.com] by adding a [DNS]record for [corp.example.com].” If not, do we need to change the definition of Authorization Domain Name to delete the language underlined above?
(4) Again, Peter Bowen of Amazon did not submit specific new language, but posed the following comment about new Method No. 8 shown below:
Proposal 4: In line K of current draft (Method No. 8)
“Conversely, in item K, using Authorization Domain seems inappropriate. Just because I control the IP address of [corp.example.com] doesn’t mean I have control [payments.corp.example.com]8.”
Here is the current Ballot language for Method No. 7:
[Current Ballot language]
- Having the Applicant demonstrate control over the requested FQDN by the CA confirming that the Applicant controls an IP address returned from a DNS lookup for A or AAAA records for the Authorization Domain Name in accordance with section 3.2.2.5; or
On the call, Wayne Thayer thought he agreed with Peter’s comment, and offered to come up with revised ballot language on this issue. There was no other discussion.
Question for Discussion: Should proving domain control for an SLDN (Base Domain) or a FQDN by showing the applicant controls an IP address returned from a DNS lookup for A or AAAA records be sufficient to show domain control for all higher level FQDNs also?
(5) Richard Wang of WoSign posted the following comment on the pre-ballot:
“I think the ballot should include some sort of requirement that a Random Value, Request Token, or Test Certificate can only be used once by the CA and customer to validate one domain, and that a new Random Value, Request Token, or Test Certificate must be generated by the CA for the customer for each domain being validated, and each time a domain is validated.”
Currently, there is no limitation on how many times the same Random Value, Request Token, or Test Certificate (call them all “CA markers”) can be used, or for confirming how many domains, or for what period of time.
On the call today, there was general agreement that the CA Markers should not be reused, but that a new CA Marker should be generated by the CA for validation of each new domain. By extension, a CA should also generate a new CA Marker each time the CA re-validates the same domain (every 13 months or earlier for EV domains, every 39 months or earlier for DV and OV domains).
There was one suggestion that maybe a CA could use a single CA Marker for validating all the domains included in a single CSR.
Eddy also suggested there should be a time limit on how long a CA Marker would be valid, as a hacker could perhaps find an unused CA Marker sent to a domain owner and then use it to get a bogus cert. For this reason, if the customer does not use the CA Token in a fairly short period, the CA should generate and send a new CA Marker to the customer for the domain.
Eddy said that applicants are sometimes slow to complete their vetting process, and so any time limit should not be too short. He will explain and offer suggestions in an email.
Question for Discussion
(1) Should all “CA Markers” (Random Values, Request Tokens, Test Certificates) be prohibited from re-use? Should the limitation be one of the following?
(a) CA Markers should only be used one time for one domain being validated for an Applicant
(b) CA Markers should only be used one time, but can be re-used for confirming control of multiple domains so long as they are all contained in one CSR from an Applicant
(c) In any case, no CA Marker may be used more than x days after it has been generated and issued by the CA to the Applicant – if the domain validation is not completed in that period, the CA must generate and give a new CA Marker to the Applicant.
What rule(s) should we set for this?
Dean asked Gerv about the new Firefox for iOS which is reportedly not showing a distinction for EV certs. Gerv was unaware of this and mentioned that it’s a version 1 product and perhaps something was amiss. He will look into it.
Survey results: Dean had sent out a survey to attendees of the Istanbul meeting to gauge their feeling on face to face speakers. Dean provided a summary of the survey which included questions on types of speakers desired and future face to face meetings. He will send out a summary to the management list.
PAG Update: The PAG is almost finished with their task. The PAG did receive some assertions of essential claims by the 31 October deadline. The Forum members may have to sign a new IPR policy. There was some confusion as to the time of the next call and Ben will send out a new invite to clarify.
Validation WG Update: No other updates other than the ballots discussed above
Code Signing WG Update: There will be a call later today to finalize the draft. There were some minor clarifications to resolve.
Policy WG Update: Update already given above in terms of the ballots.
Information WG Update: Meeting canceled for tomorrow.
Other Business: Membership application from Ministry of Interior of Korea: Dean received the application from said entity which appeared complete along with a properly signed IPR. However, no evidence of “actively issuing SSL certificates” was received. Dean will go back and ask for some examples. Kirk suggested that if we receive this information, then they should be approved.
Next teleconference scheduled for December 10th
Meeting Adjourned