[cabf_validation] Question before we start Ballot 169

[Doug Beattie]

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)'
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.
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.

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.
  (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.

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).

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>; Kirk Hall <Kirk.Hall at entrust.com>; validation (validation at cabforum.org) <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/c582f38f/attachment-0001.html