[Servercert-wg] Ballot SC 13 version 3

[Tim Hollebeek]

Yeah, I’m not trying to be difficult, I’m just not seeing the ambiguity you do, and I appreciate the discussion.  I don’t think there’s actually much if any disagreement about what we want to say and how it should be interpreted, just disagreement about what readings are or are not sensible.  Which is of course the entire point of the discussion period.

 

In fact I personally think “the ADN” is much more likely to be misinterpreted than “a ADN”, as it mistakenly implies that there is only one ADN that can be used.  So I think that makes things worse, not better.

 

Maybe “one of the Authentication Domain Names” ?  I think that makes it unambiguously clear that you’re supposed to select a single item from the set of potential candidates.

 

-Tim

 

From: Ryan Sleevi <sleevi at google.com> 
Sent: Tuesday, November 27, 2018 3:03 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 Tue, Nov 27, 2018 at 2:10 PM Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> > wrote:

First, regarding your last point, thanks for pointing out the potential issue and I’ll take a look at it and see if there is indeed some improvements that need to be made to the language to make it clearer and more parallel.  If there is actually a problem there, I may be more willing to allow other clarifications to slip in as well.  But this process does need to come to a conclusion soon.

 

Thanks.

 

However you haven’t yet convinced me that there is any lack of clarity with respect to ADNs.

 

It’s “an Authorization Domain Name” because there are multiple ADNs that can potentially be chosen.  That’s always been true for ADNs.  I disagree that there is anything unclear about ADNs as currently specified in the BRs.  The definition is clear.  CAs MAY remove zero or more components from the left side of the FQDN, and use that as the starting point for validation. 

 

I would use the simpler terms “right” and “wrong” to describe the interpretations you describe as “maximally conservative” and “tortured”.  In my mind, the “re-use” issue doesn’t come up for a single FQDN because in that case there’s only one ADN (“an ADN”, singular, and not “the ADNs”, plural).

 

I've tried to productively engage here to help you understand. I don't think viewing it as "right" or "wrong", when discussing a draft ballot, is at all a productive use. You can discuss what you meant or intended, but I don't think it's fair to say that it's "right" or "wrong". The goal is to make sure your intent is clearly captured in the ballot, and well-understood - and to that end, discussing the multiple interpretations is important and critical, and ensuring that there are not other reasonable interpretations that can be offered. I've tried to offer several reasonable interpretations here, because I don't think this ballot is, at present, sufficiently clear to avoid the mistakes that I regularly see CAs making.

 

The notion that the singular noun phrase “an Authorization Domain Name” refers to multiple inputs doesn’t make sense to me.  Clearly from the definition, there are multiple choices (“zero or more”), but clearly it has a single value (“an”) for a particular validation.

 

So I don’t think you can validate a single FQDN with multiple ADNs.  I’m not aware of any reason why you’d want to, either.

 

We have, to date, heard CAs discuss several times performing multiple validations for a single domain name. To date, this has been in the context of performing multiple (different) validations of domains, but there's no reason to think that performing multiple validations using the same validation method, but different ADNs, is somehow less valid than performing multiple different validations.

 

To this end, you end up with a single FQDN being validated. One interpretation is that each validation is a distinct and independent operation - I think this is the most conservative and sensible. However, I see no language that would prohibit thinking of these multiple validations as something to be collected in a 'single' operation.

 

I hope you can see how this shows a reasonable interpretation of aggregating multiple ADNs into a single FQDN validation. I mentioned it in previous messages, but perhaps phrasing it differently will make it clearer. The goal here is to clarify whether "an authorization domain name" is one out of the possible set, or whether it is the singular ADN chosen by the CA 'prior' to beginning the validation method. This may be as 'simple' as changing the article attached from "an Authorization Domain Name" to "the Authorization Domain Name" if that is what you meant, but that's exactly the kind of subtle-but-significant language change that a ballot discussion is about.

 

This language regarding ADNs is actually a clarification from Doug; I seriously doubt he disagrees with this interpretation (he can speak up for himself), which is how ADNs have worked since they’ve been introduced. 

 

I'm not trying to put Doug into the middle of an unnecessarily escalating disagreement, but I do hope others can see how this question - about who you can send the same Random Value to - has still not been clearly answered. I can understand if you disagree with the interpretations offered, but I'm still at a loss for what you see as the correct and expected results.

 

We are not changing, and I do not support changing, how ADNs work as part of this ballot.

 

I did not ask this. I've asked for clarifications for intent, because right now, it's ambiguous. And that's exactly the kind of situation that does not help CAs, auditors, and root store operators. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181127/174e322e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181127/174e322e/attachment-0001.p7s>