[cabf_validation] Notes of Meeting 27-July-2017

[Rich Smith]

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>; 'CA/Browser Forum Validation WG
List' <validation at cabforum.org>; Ben Wilson <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:

a.	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.
b.	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 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

 

  

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20170801/58df70ef/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5828 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20170801/58df70ef/attachment-0001.p7s>