OK, Peter, if you think you can draft further tweaks to Methods 1-10 to eliminate any doubt about a CA’s ability to choose an FQDN to validate for a customer, and then use it to issue for that FQDN and other FQDNs with additional nodes that end in the validated FQDN (which was the reason for the part of the Note that I added after this was questioned on the list) – please do so.
I don’t think we should do amendments on the fly, meaning I don’t think the Forum members can analyze and evaluate your suggestions below without seeing them in a full mark-up of a revised Ballot 190. In the new markup, you can delete the Notes if you think they are no longer needed. The current discussion period for Ballot 190 ends tomorrow, July 8, at 18:00 UTC. I will RESET the discussion and voting periods for Ballot 190 as follows: Discussion Period: July 7 to July 14 at 16:00 UTC Voting Period: July 14 to July 21 at 16:00 UTC Peter – thanks for your help. If we can make these fixes so there is no possible ambiguity, let’s do it. Ryan and Geoff – if you want to work with Peter on getting the revised language right (per Peter’s suggestions below), please do. From: Peter Bowen [mailto:[email protected]] Sent: Friday, July 7, 2017 6:41 AM To: Kirk Hall <[email protected]> Cc: CA/Browser Forum Public Discussion List <[email protected]> Subject: Re: [EXTERNAL]Re: [cabfpub] Updated Ballot 190 v5 dated July 6, 2017 On Jul 6, 2017, at 11:09 PM, Kirk Hall <[email protected]<mailto:[email protected]>> wrote: Peter, you may be right, but you had to work really hard to reach all your conclusions – as I said, over the past many weeks there were various comments and interpretations of the rules that questioned whether a confirmed FQDN could be used to issue for other FQDNs with nodes to the left of a validated domain. The term “Authorization Domain Name”, for example, only shows up in 5 of the 10 methods (by my quick count), the term “Base Domain Name” only shows up in 2 of the 10 methods, the term ”Domain Namespace” only shows up in 1 of the 10 methods. Plain language is always the best for important matters like this. That’s why Gerv added his 10 comments about whether each method could, or could not, be used to issue wildcard certs – same issue. Plain language also forces people to state their objections to the language up front, if they have any. Doug today asked for verification that CAs could, in fact, do what they and their customers have been doing for many years - issue for other FQDNs with nodes to the left of a validated domain (except for Method 8). Kirk, I am stating my objection to the language proposed. The validation working group was very deliberate and specific about the situations when this practice is acceptable. Based on some recent experiences, CAs feel somewhat hesitant about the possibility of differing interpretations of ballot language after they vote for the ballot, and in this case CAs want certainty before they eliminate “any other method” – which we all want to do. Also, the BRs have world-wide scope, including for non-native English speakers, so we need absolute clarity in simple language, not complex applications of defined terms that require careful parsing, etc. It sounds to me like the fact that we put “Base Domain Name” into the Domain Contact definition is the major sticking point. Do you feel it would be clearer if we altered the definition to read: Domain Contact: The Domain Name Registrant, technical contact, or administrative contract (or the equivalent under a ccTLD) as listed in the WHOIS record of the Base Domain Name or in a DNS SOA record. and then modified every usage of “Domain Contact” in the text to says “Domain Contact of the Base Domain Name”? This might be an easy solution as the Domain Contact is only used in the 3.2.2.4 sections, so would not impact any other part of the BRs. It would put the words “Base Domain Name” or “Authorization Domain Name” in each method directly and not require any referencing of the defined terms. No one has actually given any examples of how the Notes as they exist in Ballot 190 will do any harm – if they are surplus to the existing language there is no real problem. So the Notes will stay in Ballot 190 for certainty, BUT no one will be happier that I if the Validation WG goes back through Methods 1-10 and applies the standard terms Authorization Domain Name, etc. consistently to all 10 validation methods for a new ballot that eliminates the Notes. The note may directly conflict with the long standing requirements for Domain Authorization Documents. Since BR version 1.1, the rules for a domain authorization document have stated: "The CA MUST verify that the Domain Authorization Document was either (i) dated on or after the certificate request date or (ii) used by the CA to verify a previously issued certificate and that the Domain Name’s WHOIS record has not been modified since the previous certificate’s issuance.” This was in the errata to BR v1.0 and has continually been present to current day where it is in section 3.2.2.4.5. This makes is very clear that the CA MUST, for each certificate request, recheck WHOIS if they are going to reuse a Domain Authorization Document. For example, if an applicant who previously received a certificate for “www.example.net<http://www.example.net>” by providing a Domain Authorization Document comes in and requests “beta.www.example.net<http://images.example.net>”, then the CA cannot simply issue this certificate by reusing the existing domain validation. They have to check that the WHOIS record is unmodified compared to what was there when they issued for www.example.net<http://www.example.net>. The BRs have, since at least June 2012, had this requirement. This is a specific example of how the Notes as they exist in Ballot 190 do harm. The language is not “surplus” as it suggests a process is allowed which is not currently allow, has not been allowed for more than five years, and was not intended to be allowed as part of Ballot 169/191. Would you accept my proposal of moving “Base Domain Name” from the definition of “Domain Contact” into each usage of that term in lieu of the Notes? Thanks, Peter From: Peter Bowen [mailto:[email protected]] Sent: Thursday, July 6, 2017 6:26 PM To: Kirk Hall <[email protected]<mailto:[email protected]>>; CA/Browser Forum Public Discussion List <[email protected]<mailto:[email protected]>> Subject: [EXTERNAL]Re: [cabfpub] Updated Ballot 190 v5 dated July 6, 2017 Kirk, I think there might be some misunderstanding about how the validation methods covered in Ballot 169 work. Each method, with one exception, already includes either Base Domain Name, Authorization Domain Name, or Domain Namespace. This was extremely intentional when the Validation Working Group was drafting the methods. The only place where there is any possible confusion is whether a confirming response received within 30 days of creation of a Random Value can be used after 30 days. As a member of the WG, I am confident that the intent was the answer is yes; the 30 day clock stops once the response is received and that received response (including the timestamp when it was received) can be used for the 4.2.1 duration. Below are all methods and where Base Domain Name, Authorization Domain Name, or Domain Namespace come into play (or don’t). In putting this together, one thing that stood out is the 3.2.2.4.5 has specific requirements for reuse that seem to conflict with the added “Note”, which seems to be a problem. Hopefully this helps explain why the Validation WG didn’t include the type of “note” language in 169 that is proposed here. Thanks, Peter 3.2.2.4.1: Validating the Applicant as a Domain Contact "validating the Applicant is the Domain Contact”: the definition of Domain Contact is "the Domain Name Registrant, technical contact, or administrative contract (or the equivalent under a ccTLD) as listed in the WHOIS record of the Base Domain Name or in a DNS SOA record.” This clearly calls out Base Domain Name. If the CA has previously obtained documents and data that shows that the Applicant is the Domain Contact, then they can reuse these to confirm the new request, as long as the documents and data were obtained within the period specified in 4.2.1. For example, an applicant requests www.example.com<http://www.example.com/>, the CA confirms the application is a domain contact forexample.com<http://example.com/>. Later the same application applies for shop.example.com<http://shop.example.com/>, and the CA uses the documents and data from the first verification to again verify the applicate is a domain contact for example.com<http://example.com/>. 3.2.2.4.2: Email, Fax, SMS, or Postal Mail to Domain Contact “MUST be sent to an email address, fax/SMS number, or postal mail address identified as a Domain Contact.” Again, uses Domain Contact which explicitly invokes Base Domain Name. In this case the CA would likely use record of a timely confirming response as documents and data to reuse. This is one where the working group may want to consider making it clear that the 30 days is only when the response must have been received, not when it was used to complete the verification. 3.2.2.4.3: Phone Contact with Domain Contact "MUST place the call to a phone number identified by the Domain Name Registrar as the Domain Contact” Again, uses Domain Contact which explicitly invokes Base Domain Name. As before, the CA would likely use record of a timely confirming response as documents and data to reuse. 3.2.2.4.4: Constructed Email to Domain Contact "sending an email to one or more addresses created by [...] at-sign ("@")<mailto:%22sending%20an%20email%20to%20one%20or%20more%20addresses%20created%20by%20[...]%20at-sign%20(%22@%22)> followed by an Authorization Domain Name” This explicitly calls out Authorization Domain Name. As with 3.2.2.4.2, the CA would likely use record of a timely confirming response as documents and data to reuse. This is another one where the working group may want to consider making it clear that the 30 days is only when the response must have been received, not when it was used to complete the verification. 3.2.2.4.5: Domain Authorization Document "Documentation [...] attesting to the authority of an Applicant to request a Certificate for a specific Domain Namespace” This explicitly uses Domain Namespace and has an explicit reuse provision "the WHOIS data has not materially changed since a previously provided Domain Authorization Document for the Domain Name Space” Unlike some of the other methods, the CA is explicitly required to recheck whois each time a certificate is issued. 3.2.2.4.6: Agreed-Upon Change to Website "Authorization Domain Name” is directly called out in the validation method. 3.2.2.4.7: DNS Change "Authorization Domain Name” is directly called out in the validation method. 3.2.2.4.8: IP Address Intentionally does not use Base Domain Name, Authorization Domain Name, or Domain Namespace 3.2.2.4.9: Test Certificate "Authorization Domain Name” is directly called out in the validation method. 3.2.2.4.10: TLS Using a Random Number "Authorization Domain Name” is directly called out in the validation method. On Jul 6, 2017, at 4:25 PM, Kirk Hall via Public <[email protected]<mailto:[email protected]>> wrote: We have had this same conversation several times now, and yet keep coming back to the same points. As I and others have said, including on today's call, without the Note there is uncertainty as to whether there is specific authorization for CAs who have validated a domain ("example.com<http://example.com/>") using Methods 1-7 and 9-10 to then issue certs to the same customer for domains that include additional nodes to the left (www.example.com<http://www.example.com/>, mail.example.com<http://mail.example.com/>) based on the prior validation of example.com<http://example.com/>. I think some have even questioned whether or not CAs can do this (a common practice today among CAs and their customers) in the various email strings we have had over the past few months. That's the only reason we have felt the need to add specific provisions like the Note to what was in Ballot 169 - these questions were raised, and the interpretations were offered on existing language. Some CAs in the past relied on Method 7 "any other method" as authority to issue for an FQDN that was a validated FQDN plus nodes to the left. The terms Authorization Domain Name and Base Domain may be a good way to go in the future, but they are only found in a few of the ten validation methods - maybe they should be added to the other methods by the Validation Working Group in the follow-up ballot to come, but we can't rely on those terms today. If you look at the discussion of the past two weeks alone, we have had multiple formulations of the best language to explicitly allow CAs to do this, and finally I picked the most recent one - Gerv's - because it seemed to be well stated and do what we all want to do. While you indicated on the call today that the Note at the end of each validation method could introduce uncertainty and also IP risk, you did not elaborate or provide details. I don't agree with you, but if you have additional details and examples to support your conclusions I'll be happy to review them. Even better, if you want to draft replacement language that accomplishes what we are trying to accomplish, please do and we can take a look. For all these reasons (as we have discussed before), we will keep the Note in the Ballot 190 as shown in v5, but if you want to draft an immediate follow-on ballot that addresses your concerns, we can take that up immediately after Ballot 190 passes. The most important thing now is to try to get this ballot enacted, get the new validation methods in the BRs, and eliminate "any other method" for user security. -----Original Message----- From: Ryan Sleevi [mailto:[email protected]] Sent: Thursday, July 6, 2017 12:29 PM To: Kirk Hall <[email protected]<mailto:[email protected]>>; CA/Browser Forum Public Discussion List <[email protected]<mailto:[email protected]>> Subject: [EXTERNAL]Re: [cabfpub] Updated Ballot 190 v5 dated July 6, 2017 Kirk, Just because it's important to capture for those who were not on the call - since it's likely this ballot will proceed to voting before such minutes are available, a few thoughts from the call to be captured: 1) At least one member highlighted the concern that, by making modifications to this ballot, as proposed, this introduces additional IP risk that the Forum was specifically trying to address with Bylaws 1.6. The best path to address this risk is to remove the "Note" 2) At least one member highlighted that the Validation WG, with the proposal of Ballot 169, spent considerable time trying to address the ambiguity problem that the "Note" is trying to address (but does so incompletely). 3) At least one member highlighted that the "Note", by being non-normative, is neither urgent nor essential to resolve in this version. However, by introducing the currently proposed language, it creates potential issues that there is no guarantee will be able to be resolved easily or in a timely fashion. As the Forum already has methods to address ambiguity - both through the questions@ list and through subsequent ballots - it seems far more appropriate to remove the proposed text, thus aligning with Ballot 169, and thus resolving a significant objection towards forwards progress. I do not understand, nor agree with, the proposal to force a vote on this, when concerns have been repeatedly raised, and which are trivial to address in a way that allows us to make forward progress on the far more substantive aspect. Further, I have not seen any attempt to address and/or resolve the concerns highlighted inhttps://cabforum.org/pipermail/public/2017-July/011492.html As the ballot proposer, can you please make an effort to address and/or respond to these concerns, which introduce substantially new risk and confusion? I have hopefully provided clear suggestions about ways to resolve, and it's unclear whether your lack of acknowledgement represents a need for additional time to review (in which case, we should stop the discussion period), a disagreement on principle (in which case, I hope you can clearly state so), or if my concerns are unclear (in which case, we should stop the discussion period, and I'm more than happy to work with you to explain them). I understand and appreciate your eagerness to see this through to conclusion, but believe it at least deserves some response and engagement on the substance of these real and pressing security concerns, rather than dismissing them as fixing them after. After all, it is worth noting that it has taken us nearly a year to get to this point in which we're somewhat close to a ballot, so you can understand why I am quite troubled by the suggestion that we can somehow quickly fix these real security issues after-the-fact. On Thu, Jul 6, 2017 at 2:39 PM, Kirk Hall via Public <[email protected]<mailto:[email protected]>> wrote: Based on the CABF teleconference discussion today, it’s clear there is still a difference of opinion on the best way to express the ability of a CA to re-use the validation of an FQDN and issue certs for other FQDNs that include additional nodes to the left (except for validation Method 8). Jeremy and Ben are collecting all the suggestions for how to express this, and once Ballot 190 is adopted will immediately consider appropriate edits. But we need to get Ballot 190 done in order to end the “any other method” authorization and meet Mozilla deadlines as well. For now, we have this formulation of the rule posted by Gerv last Friday, which looks good to me: “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 and have more labels than it.” I have dropped in that language in the attached Version 5 of Ballot 190 (and specified this is not true for Method 8). Otherwise, the ballot is the same as v4 which was previously circulated. Ballot 190 v5 (6-30-2017) is now the official Ballot 190 under consideration by the Forum. The discussion period ends on July 8 at 18:00 UTC, after which voting will start. _______________________________________________ Public mailing list [email protected]<mailto:[email protected]> https://cabforum.org/mailman/listinfo/public _______________________________________________ Public mailing list [email protected]<mailto:[email protected]> https://cabforum.org/mailman/listinfo/public
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
