[cabf_validation] Question before we start Ballot 169

Tue Jul 26 16:22:38 MST 2016

Thanks, Doug.  Further responses/questions in red

Given that we are likely to live with this language for several years, I just want to make sure it's clear and makes sense.

From: Doug Beattie [mailto:doug.beattie at globalsign.com]
Sent: Tuesday, July 26, 2016 11:08 AM
To: Kirk Hall <Kirk.Hall at entrust.com>; 'validation (validation at cabforum.org)' <validation at cabforum.org>
Subject: RE: Question before we start Ballot 169

Hi Kirk,

See below.

From: Kirk Hall [mailto:Kirk.Hall at entrust.com]
Sent: Tuesday, July 26, 2016 12:20 PM
To: Doug Beattie; 'Ben Wilson'; 'validation (validation at cabforum.org<mailto:validation at cabforum.org>)'
Subject: RE: Question before we start Ballot 169

Sorry to be slow to respond - I was off for a couple of days.

Doug, I understand the language now, but I have a question.  Under the scenario you list below, a CA could "use" a Random Value generated to authenticate an FQDN and placed by the Applicant in the DNS record for up to 13/39 months (depending on whether the cert is EV or OV/DV) to issue multiple certs over that period for the same authenticated FQDN.  However, you impose limitations: (1) this reuse of the Random Value can only be used if the subsequent certificate requests come from the Applicant (who could be a reseller or hosting company, I suppose), (2) it's for the same FQDN, and (3) the request comes within the 13/39 month limit on reuse of authentication data.
DOUG: Note 1: I don't agree with your item 2, "it must be for the same FQDN".  For each FQDN in the certificate request, this value can be placed on the Authorization Doman Name and used for all subdomains for the Authorization Domain Name for all domains in the certificate request.
That's correct, I was being lazy.  If the RV is placed on an Authorization Domain Name, that will authenticate that particular FQDN plus all "higher" FQDNs containing the ADN for future use for 13/39 months.  But the CA will have to record in its own systems which RV was used for (assigned to ) authentication for which ADN - that was my point.  Otherwise, the CA will not know what RV to look for when going back to the same ADN later to re-authenticate for a subsequent certificate request - right?  And you need to associate a validation start time (13/39 months) for that ADN and that customer in your CA systems (to make sure you are following the limitations in 7.2.2.4(ii)), right?  So you effectively have everything in your system (customer, RV, ADN, and start time for authentication period), so why would you ever go back to the DNS record to see if the old RV is still there when you get a new order from the same customer?
Note 2: We'd want to specifically exclude resellers for this as the CA can't tell who the applicant really is - the applicant/subscriber would be a customer of the reseller so there is no way to verify it's the same application.  I think this is why Robin came up with request token.

Here's my question - if the CA knows facts (1), (2), and (3) - identity of the Applicant, which FQDN is allowed (i.e., the one associated with the old Random Value still shown on the DNS record), and whether the 13/39 month limit on reuse has expired - why does the CA need to look again at the DNS record at all?
It seems the CA already has effectively established and "account"
DOUG: Not necessarily for DV orders, there might not be an established account containing domain info.  See above - the CA has to know all that information in its systems (customer, RV, ADN, and start time for authentication period) to make sure the subsequent certificate request is authorized for issuance without revalidation of the ADN.  There must be the equivalent of an "account" before you can say you are dealing with the same customer.

for the Applicant/Subscriber, and can verify from the information in (1), (2), and (3) that the Applicant can get more certs for the same FQDN - right?  So why do we need the language in (ii) at all - why is the DNS record relevant for the subsequent certificate requests?
Implementations may be different - some CAs might want to keep re-checking the DNS record and others may want to rely on locally stored info.  One advantage is that the applicant can effectively tell the CA to stop using this vetted data if they remove it from DNS where as it might be harder to have them notify the CA and have them update their records if the CA stored and re-used this data for 13/39 months.  Just pointing out that implementations may vary.  Hmmm...  I guess it would add another layer of security - the customer asked for a new cert, but the CA won't provide it because the RV is gone from the DNS record - but otherwise the CA has all the data from the prior request to feel free to issue a new cert for the ADN whether or not the RV is still in the DNS record.
  (I ask this because in general it's not a good idea to actually keep relying on the same publicly displayed Random Value over a three year period.)
DOUG: You could be right, but what's the threat or issue?  If it's public from day 1, why is it worse to re-use this for more than 30 days, it's already public.  True, but I'm having a hard time figuring out if the CA is really using the RV in the DNS record when it reissues under the conditions of (ii) - I don't see what information the CA is getting from the DNS record at that point that it doesn't already have.  So that makes me nervous - if the CA is really relying on it, is the CA effectively ignoring the 30 day limit?

I have a related question - method 7 says the Random Value must be "unique to the certificate request".  If an applicant applies for a cert for foo.com and receives a Random Value (starting the 30 day clock), and 10 days later ask to add bar.com to the certificate - is that still the same certificate request, and can the Applicant use the same Random Value to authenticate bar.com?   If yes, I assume the authentication of bar.com must occur within the original 30 day period - the 30 day period does not get extended to allow a full 30 days for authentication of bar.com, correct?
DOUG: "certificate requests" is not defined.  I agree that you do not extend the validity period another 30 days, it would be 30 days from when you generate the random, number and disclose it.  I'd equate the certificate request to the order, and as long as it's the same (authenticated) applicant, they could add or remove domains from this order using the same random value, as in your example of adding bar.com above.  If there are changes to the subject DN or validity period notAfter date then I'd say it's a new order; otherwise it can be treated as the same order (basically you can do reissues and add/delete SANs).  Right, no problem modifying the initial order (certificate request), so long as the RV given to the customer at the initial certificate request can't be used longer than the original 30 day period (even if the certificate request is modified) - are you agreeing with that?

DOUG: Does this help clear things up?

From: Doug Beattie [mailto:doug.beattie at globalsign.com]
Sent: Friday, July 22, 2016 9:40 AM
To: Ben Wilson <ben.wilson at digicert.com<mailto:ben.wilson at digicert.com>>; Kirk Hall <Kirk.Hall at entrust.com<mailto:Kirk.Hall at entrust.com>>; validation (validation at cabforum.org<mailto:validation at cabforum.org>) <validation at cabforum.org<mailto:validation at cabforum.org>>
Subject: RE: Question before we start Ballot 169

The intent here is that you can use the random value for more than 30 days if the applicant submitted the request (not a reseller for example).  While some CAs might pre-validate domains and store them in the CA system, it's also possible that you could keep relying on a DNS TXT record or web site change for up to 13/39 months for subsequent orders for that domain (probably subdomain SANs) by checking that random value over and over for each order.  This only works if the same applicant is associated with each of the orders. The CA as to know it's the same applicant (which turns into the subscriber), and they will based on the agreement between the CA and the entity placing the orders.

Example: Company X wants a whole bunch of DV orders for their domain example.com.  They order the first one, place the random number in a file on example.com/.well-known... and then the CA and they can keep re-using that for all future orders for the domain and that account so the customer doesn't need to keep posting a new value.

Doug

From: Ben Wilson [mailto:ben.wilson at digicert.com]
Sent: Friday, July 22, 2016 12:05 PM
To: Doug Beattie; Kirk Hall; validation (validation at cabforum.org<mailto:validation at cabforum.org>)
Subject: RE: Question before we start Ballot 169

Before we post this as a ballot, Kirk asked if  someone could explain the meaning of 3.2.2.4.7(ii) - see below.  Otherwise, it's ready to go.

3.2.2.4.7 DNS Change
Confirming the Applicant's control over the requested FQDN by confirming the presence of a Random Value or Request Token in a DNS TXT or CAA record for an Authorization Domain Name or an Authorization Domain Name that is prefixed with a label that begins with an underscore character.

If a Random Value is used, the CA or Delegated Third Party SHALL provide a Random Value unique to the certificate request and SHALL not use the Random Value after (i) 30 days or (ii) if the Applicant submitted the certificate request, the timeframe permitted for reuse of validated information relevant to the certificate (such as in Section 3.3.1 of these Guidelines or Section 11.14.3 of the EV Guidelines).

From: validation-bounces at cabforum.org<mailto:validation-bounces at cabforum.org> [mailto:validation-bounces at cabforum.org] On Behalf Of Doug Beattie
Sent: Thursday, July 21, 2016 1:54 PM
To: Kirk Hall <Kirk.Hall at entrust.com<mailto:Kirk.Hall at entrust.com>>; validation (validation at cabforum.org<mailto:validation at cabforum.org>) <validation at cabforum.org<mailto:validation at cabforum.org>>
Subject: Re: [cabf_validation] Question before we start Ballot 169

Ignore that last email as you have already answered it.  This one appeared as the most recent in my mail client, so it must have been stuck in our mail filter longer than the others....

From: Doug Beattie
Sent: Thursday, July 21, 2016 3:50 PM
To: 'Kirk Hall'; validation (validation at cabforum.org<mailto:validation at cabforum.org>)
Subject: RE: Question before we start Ballot 169

I'd suggest not changing the ballot now, go with it.  GlobalSIgn was one endorser, maybe Trustwave was the other?  DigiCert as the author.

From: validation-bounces at cabforum.org<mailto:validation-bounces at cabforum.org> [mailto:validation-bounces at cabforum.org] On Behalf Of Kirk Hall
Sent: Thursday, July 21, 2016 2:38 PM
To: validation (validation at cabforum.org<mailto:validation at cabforum.org>)
Subject: [cabf_validation] Question before we start Ballot 169

On the call today, there were no objections to starting Ballot 169, so I guess we can.

Ben - the most recent Ballot 169 draft doesn't list the proposer and endorsers.  Do you remember who that was?

Question:  I just noticed that the Ballot (and existing BR 3.2.2.4) uses the term Domain Name System about six times total, but it is not included in our Definitions.  (I see we list DNS as an acronym for Domain Name System, and it's pretty well defined outside of the BRs: https://en.wikipedia.org/wiki/Domain_Name_System )

Do we care?  Or just go with the Ballot as written now?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20160726/bdca1c49/attachment-0001.html 