[cabf_validation] Notes of Meeting 27-July-2017
Doug Beattie
doug.beattie at globalsign.com
Tue Aug 8 05:36:06 MST 2017
I agree with Wayne on the reasons that reusing random values for 6, 7, or 10 will result in less customer confusion. Would it help if we said if you deliver the random value via a different means when “resending” the random number for that request, it must be a new value? I could agree with that, but purely re-sending or re-delivering the random value for a request via the same means as the first one should allow reuse of the same value.
In that same regard I don’t see an issue with resending an email with the same random number to the same recipient list. Peter said this:
· For methods that involve sending a value to someone (e.g. the registrant) in a way that needs to be identifiable, then we could reasonably prohibit reuse. This looks to be methods 2 & 4.
I agree, it needs to be identifiable. I don’t think resending the same email to the same recipient list is an issue – forwarding to different recipients, sure, we need to know who it was sent to so we know who might have approved it.
Doug
From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of Jeremy Rowley via Validation
Sent: Monday, August 7, 2017 5:33 PM
To: Wayne Thayer <wthayer at godaddy.com>; CA/Browser Forum Validation WG List <validation at cabforum.org>; Peter Bowen <pzb at amzn.com>
Subject: Re: [cabf_validation] Notes of Meeting 27-July-2017
That assumes the CA is showing the Random Value on their website for 6, 7, and 10. It could still be emailed, phoned in, or something else. I don’t see where it’s specified in the Requirements how this Random value is delivered.
From: Wayne Thayer [mailto:wthayer at godaddy.com]
Sent: Monday, August 7, 2017 12:18 PM
To: Jeremy Rowley <jeremy.rowley at digicert.com>; CA/Browser Forum Validation WG List <validation at cabforum.org>; Peter Bowen <pzb at amzn.com>
Subject: Re: [cabf_validation] Notes of Meeting 27-July-2017
For methods 6, 7, or 10, the benefit to reusing the value is that it’s less confusing for the customer. They are likely to check their account, retrieve the value, go do whatever they need to post it, then go back and confirm the value is correct. If the CA generates a new value in this last step, or of the customer ends up with a bunch of random values, that will be confusing. I don’t think anyone is arguing that the CA needs to immediately invalidate older random values when a new one is generated, so I guess the CA could just show the customer all of the values that have been generated for the request, but I still think reuse makes sense in this case.
I support Peter’s comments on methods 2 & 4 because a specific risk was brought up somewhere in the discussion: Assuming that the CA uses a standard format for the link sent to domain contacts for verification with a form of ‘www.ca.com/verify/<random value>’, then if the CA sends the same value via email for method 2 or 4 and to the requestor for method 6 or 7, then an attacker could request a cert for a domain name they don’t control, take the random value they receive for methods 6 or 7, and use it to construct the URL for method 2 or 4 to approve the request.
Thanks,
Wayne
From: Validation <validation-bounces at cabforum.org<mailto:validation-bounces at cabforum.org>> on behalf of Jeremy Rowley via Validation <validation at cabforum.org<mailto:validation at cabforum.org>>
Reply-To: Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>>, CA/Browser Forum Validation WG List <validation at cabforum.org<mailto:validation at cabforum.org>>
Date: Monday, August 7, 2017 at 10:57 AM
To: Peter Bowen <pzb at amzn.com<mailto:pzb at amzn.com>>, CA/Browser Forum Validation WG List <validation at cabforum.org<mailto:validation at cabforum.org>>
Subject: Re: [cabf_validation] Notes of Meeting 27-July-2017
What’s the benefit of showing the random value multiple times? It’s not a cost savings or complexity issue. It also doesn’t change the expiration date of that value.
From: Peter Bowen [mailto:pzb at amzn.com]
Sent: Monday, August 7, 2017 11:55 AM
To: Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>>; CA/Browser Forum Validation WG List <validation at cabforum.org<mailto:validation at cabforum.org>>
Cc: Rich Smith <richard.smith at comodo.com<mailto:richard.smith at comodo.com>>; Ben Wilson <ben.wilson at digicert.com<mailto:ben.wilson at digicert.com>>
Subject: Re: [cabf_validation] Notes of Meeting 27-July-2017
I agree with both of you.
For methods that involve sending a value to someone (e.g. the registrant) in a way that needs to be identifiable, then we could reasonably prohibit reuse. This looks to be methods 2 & 4.
For methods where the CA fetches the value, showing the expected value to the applicant multiple times seems fine. It also seems fine to say the same random value can come back via any of the methods. E.g. CA provides value to applicant then uses 6, 7, or 10 to check it.
Thanks,
Peter
On Aug 7, 2017, at 10:26 AM, Jeremy Rowley via Validation <validation at cabforum.org<mailto:validation at cabforum.org>> wrote:
I don’t disagree. I think we are talking about two different things. I don’t think the Random Value should be tied to any specific method. Instead, the Random Value should be tied to a single communication. The request for a random value should be a separate issue than whether the random value can be used across multiple nethods.
From: Rich Smith [mailto:richard.smith at comodo.com]
Sent: Tuesday, August 1, 2017 11:36 AM
To: Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>>; 'CA/Browser Forum Validation WG List' <validation at cabforum.org<mailto:validation at cabforum.org>>; Ben Wilson <ben.wilson at digicert.com<mailto:ben.wilson at digicert.com>>
Subject: RE: [cabf_validation] Notes of Meeting 27-July-2017
But then that creates a problem for Applicants/Subscribers. It’s much easier and less confusing for everyone if we can supply a single random value that can at least be used across methods 6, 7 and 10.
You can leave out 2 and 4 as those are both email based, and so sending a new random value each time is not a big deal, and neither is not being able to use that random value for any other method. Even though it doesn’t lessen security to allow a value from 2 or 4 to be used for 6, 7 or 10, it doesn’t make a lot of practical sense anyway because if you can get the email to give you the value you should also be able to get to the weblink to confirm it, so why apply it elsewhere.
From: Jeremy Rowley [mailto:jeremy.rowley at digicert.com]
Sent: Monday, July 31, 2017 1:04 PM
To: Rich Smith <richard.smith at comodo.com<mailto:richard.smith at comodo.com>>; 'CA/Browser Forum Validation WG List' <validation at cabforum.org<mailto:validation at cabforum.org>>; Ben Wilson <ben.wilson at digicert.com<mailto:ben.wilson at digicert.com>>
Subject: RE: [cabf_validation] Notes of Meeting 27-July-2017
Right – I’m saying just not allow reuse. One Random Value per call/communication. Then they are all secure.
From: Rich Smith [mailto:richard.smith at comodo.com]
Sent: Monday, July 31, 2017 12:01 PM
To: Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>>; 'CA/Browser Forum Validation WG List' <validation at cabforum.org<mailto:validation at cabforum.org>>; Ben Wilson <ben.wilson at digicert.com<mailto:ben.wilson at digicert.com>>
Subject: RE: [cabf_validation] Notes of Meeting 27-July-2017
Jeremy,
Your note (2a) below doesn’t quite address the whole problem. As has been pointed out, reuse of random value from 2 and/or 4 for 6,7, and 10 is still secure, but the reverse is not true. We need to make sure we clarify that in the language.
-Rich
From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of Jeremy Rowley via Validation
Sent: Thursday, July 27, 2017 7:46 PM
To: Ben Wilson <ben.wilson at digicert.com<mailto:ben.wilson at digicert.com>>; CA/Browser Forum Validation WG List <validation at cabforum.org<mailto:validation at cabforum.org>>
Subject: Re: [cabf_validation] Notes of Meeting 27-July-2017
I think the minutes describe the issues well and the confusion surrounding the issues. I’m proposing that we craft a ballot subsequent to 190 that:
1. Clarifies that CAs may use a re-direct on a permissible port for validation but may not use a re-direct to a new domain. If the re-direct is to an authorization domain, the CA is verifying the authorization domain, so there isn’t a problem in simply stating that domain re-directs from an authorization domain do not verify the authorization domain. Let’s Encrypt’s answer on the general mailing list made the issue more confusing and increased questions about whether re-directs are allowed. I think we should put the issue to rest with clarifying requirement language.
2. Clarifies reuse of Random Values between methods and within methods. I don’t think the language is clear on when a Random Value can be reused. May a CA send a Random Value to WHOIS contacts and then find the Random Value in a DNS record? What does the 30 day requirement mean (when does it start and end)? Lots of questions on what this entails. I propose:
* Random values may be reused across methods (for example, an email to the WHOIS contact may reuse the same random value as the constructed emails). This makes sense as the guidelines do not require the CA to specify the validation method being used at the time of Random Value generation.
* Random Values may only be sent in a single communication. Let’s get rid of this reuse stuff and require the CA to only send the Random value as part of one communication. Random Value generation is cheap. Why do we need to reuse them? Communicating the Random Value over and over again amplifies the risk of loss and misuse.
From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of Ben Wilson via Validation
Sent: Thursday, July 27, 2017 3:49 PM
To: validation (validation at cabforum.org<mailto:validation at cabforum.org>) <validation at cabforum.org<mailto:validation at cabforum.org>>
Subject: [cabf_validation] Notes of Meeting 27-July-2017
Notes of teleconference meeting of the Validation Working Group
27 July 2017
In attendance: Ben Wilson, Rick Andrews, Kirk Hall, Steve Medin, Rich Smith, Robin Alden, Li-Chun Chen, Peter Bowen,
Agenda Topics: (1) Redirects to Ports and (2) Reuse of Random Value.
Redirects to Ports
Ballot 190 and the BRs are silent on redirects, and it appears that it is open to interpretation. It’s unclear whether / how Let’s Encrypt allows/prohibits the use of redirects. Companies often redirect from http to https.
Kirk asked whether Jeremy had a solution in mind, or was he seeking clarity on redirects, or was he seeking a restriction in some cases and allowing it in others. He also asked whether redirects are prohibited under the rules today. Ben said this would be for ports, but not domains. Steve asked whether there was a justification for not allowing domain redirects. Ben said that the use of a CNAME should be allowed, but he was unclear on why domain redirects wouldn’t be allowed. Steve said that http redirects use the response codes. Rick said that there are several ways to create redirects—e.g. error code 301, inside web pages with a meta tag refresh, etc. Steve said that instead of looking at redirects, we need to look at whether or not the ability to do the redirects is too weak. If it takes a reasonable degree of control over a web server to redirect port 80 to port 443, then because both are Authorized Ports under the BRs, that would be an acceptable/permissible redirect. Then, you’ll usually also be redirected from a base domain to a base domain prefaced by www. Then the question arises whether that redirection with the well-known validation information present also is sufficiently secure. The question is whether there is too much risk in the control of the redirects?
Rich said that he wasn’t comfortable yet on allowing a redirect in this latter scenario. He felt there is ambiguity and uncertainty about the scope of authorization if we allowed redirects from domain.com<http://domain.com/> to www.domain.com<http://www.domain.com/>, then what also might be considered approved. He’d like to obtain more information from those in the Forum who are more technically expert. Steve asked Rich how he’d feel if we followed a redirect, and given that, we established that as the Authorization Domain Name (ADN) rather than the base domain name? For example, if we go to the base domain name, and it redirects to something on www that establish, then that as the ADN, and any subdomains below it, have been validated—we don’t pop up to the base domain. Rich said he would be OKO with that approach.
Ben said that with all of the permutations that could be made and without a proposed method it seemed like the broad question of do we allow redirects was a hard one to resolve and that maybe we need more discussion of this on the list. For instance, is redirect an add on to an existing method or is it a whole new method? Steve said it isn’t another method, it’s an influence to the existing methods where we go and look at content on the server. We used to call it an agreed upon change to a website.
Kirk wondered whether Jeremy could restate the issue, and where he sees the dangers, and we could ask Let’s Encrypt about their point of view on redirects. We can put this on next Thursday’s phone call, but it would be better if we first had more discussion of this on the list.
Random Value Reuse
Jeremy raised this issue in an email dated July 25th. He said, “Methods 2, 4, 6, 7, and 10 permit use of a random values. Methods 2 and 4, require a unique random value per email. Methods 6, 7, and 10 do not require unique random values per request for the random value.” Peter responded that you cannot share the random value across all five methods. You could send the random value to one or more addresses allowed by 2/4 and then look for the value in a location allowed by 6/7/10, and that maybe section 3.2.2.4 should be clarified along those lines.
Kirk asked whether the issue was whether you could use a random value under a method like method 2 and then reuse it later with method 7, or was the issue that in some methods you can reuse and in some you can’t. Peter and Ben thought that it was the first issue. Ben said he thought it was about reuse, not about the methods. Peter said he thought the issue was about using it with other methods. Ben said he thought that the main question was about reuse in general. Peter said he thought it was about a customer saying, “just give me a random value and I’ll choose one of the methods.” So the issue is whether it is reuse at a later date or reuse with another method. Ben said that the BRs would benefit from some clarification on these issues. Peter said that the random value cannot just be given right back to the CA, that would not establish domain control—it has to be one of the methods.
Jeremy’s email also said, “Some customers would like to use the same random value across multiple methods (method 2, 6, and 7), having us look for the first instance of the random value, or across multiple domains. Method 6 and 7 require a unique random value per certificate request, not per domain. This means, that the same Random Value can appear in multiple DNS records at once to confirm control.” So, you could have a single request with the same random value used with multiple domains (on the multi-domain side), but you cannot send the same random value to ten different domain owners.
Jeremy’s email asked:
1. Should the random value be unique per verified domain name instead of per certificate request? With email methods, use of a single email to verify multiple domain names with the same email address makes sense. I’m not sure this makes as much sense for DNS records.
2. Can multiple methods use the same random value? Can you request a random value and then the CA just scour the permitted locations to find it? This seems okay to me as nothing requires the CA to specify the method of validation associated with the Random Value, but thought I’d get other opinions.
Kirk said he would like to know what Jeremy wants – just a clarification or a modification? Peter said he wanted to ask a similar question, do we think we need this for Ballot 190? Kirk has held off on discussing Ballot 190 in order to allow Ballot 202 to clarify the definitions. Now with a Ballot-202 replacement ballot nearly ready to go, Jeremy may have time to address this issue, whether it is in an overall note, a suggestion to the content of Ballot 190, or whether he just wants to know an interpretation.
I haven’t written up minutes of the discussion regarding the replacement for Ballot 202, except that Peter reviewed his recent responses to the opponents of Ballot 202.
The group then talked more about Ballot 190. Authorization Domain Name needs to be clarified as part of Ballot 190. The order of the process (receipt of a certificate request) should not be dispositive (CAs should be able to do validation B, C, A). Other points made: 1 – we need to put in place methods 1-10, 2 – we need to eliminate “any other method”, 3 – validation done previously can be used, and 4 – ensure we do not run into this again (allow reuse).
There was a discussion of “validation” vs. “validation data” (e.g. “documents, data and existing validations”). A CA might want to reuse corporate registration data across several domain validations. That shouldn’t have to be repeated. To make this easy, let’s say that reuse is capped at 6 months, and let’s say you get the document on January 1, 2017, and that the customer requests a new domain on June 15. If domain validations are also good for 6 months, then that domain validation will be good until December 15, but the entire window is more than the 6 months that was intended.
Meeting adjourned due to time.
Next meeting: 10 August 2017
_______________________________________________
Validation mailing list
Validation at cabforum.org<mailto:Validation at cabforum.org>
https://cabforum.org/mailman/listinfo/validation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20170808/649f450d/attachment-0001.html>
More information about the Validation
mailing list