[Servercert-wg] Ballot SC 13 version 3
Doug Beattie
doug.beattie at globalsign.com
Tue Dec 4 12:27:44 MST 2018
I was out last week, so sorry for not commenting.
1. There is only one ADN per validation, but there may be multiple ADNs candidates for any specified FQDN. There are 2 in Ryan’s example and a CA might let the user select which one they want to use per FQDN.
2. The validation done on the ADN is reusable (per the note) for other domain validations for that Applicant.
3. There is no relationship or processing of issue or issuewild CAA records when performing domain validation defined in method 13 or 14.
Is this accurate?
Doug
From: Ryan Sleevi <sleevi at google.com>
Sent: Wednesday, November 28, 2018 3:25 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com>
Cc: servercert-wg at cabforum.org; Doug Beattie <doug.beattie at globalsign.com>
Subject: Re: [Servercert-wg] Ballot SC 13 version 3
On Wed, Nov 28, 2018 at 1:41 PM Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> > wrote:
That matches my reading. The question is how to say it. That’s why I suggested “one of”, which I think captures the fact that the individual validation uses exactly one ADN from the potential ADNs.
I’m open to other suggested text that says the same thing if you don’t think that’s clear.
To be explicit, my problem with “the” is that it would need a qualifier to unambiguous identify that only one of the a number of potential ADNs is being referred to. E.g. “the chosen ADN” or “the ADN selected to validate the FQDN”. Otherwise it is prone to misinterpretation.
Thanks! I think either of those would potentially minimize the confusion, and helps clarify that the act of "performing" a validation is based on selecting an ADN (out of the set of valid ADNs) for the FQDN, running the steps, and seeing if you get a yes/no result.
The consequence of this means the following, which I think we're in agreement, but explicitly stating (for the archives):
Given:
* An FQDN of "a.b.example.com <http://a.b.example.com> "
* Where a.b.example.com <http://a.b.example.com> has a TXT/CAA email association of "john at example.com <mailto:john at example.com> "
* And b.example.com <http://b.example.com> has a TXT/CAA email association of "jane at example.com <mailto:jane at example.com> "
* And example.com <http://example.com> has no TXT/CAA email association
Then:
* The valid ADNs are "a.b.example.com <http://a.b.example.com> ", "b.example.com <http://b.example.com> ", and "example.com <http://example.com> "
* The act of performing validation is done by selecting one of those ADNs and performing a validation method for a given FQDN & ADN
You MAY:
* Send an email to john at example.com <mailto:john at example.com> with Random Value 1 (and an ADN of "a.b.example.com <http://a.b.example.com> ")
* Send an email to jane at example.com <mailto:jane at example.com> with Random Value 2 (and an ADN of "b.example.com <http://b.example.com> ")
You MUST NOT
* Send an email to john at example.com <mailto:john at example.com> AND jane at example.com <mailto:jane at example.com> with Random Value 3
* This is because the email address associated with each ADN is different.
That is, the Random Value sent to John MUST be different than the Random Value sent to Jane and you MUST NOT send the same email/Random Value to both addresses.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181204/072c468c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5716 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181204/072c468c/attachment-0001.p7s>
More information about the Servercert-wg
mailing list