[cabfpub] [EXTERNAL]Re: Pre-ballot for Ballot 190

[Ryan Sleevi]

Kirk

The ISO/DIS 21188 is not part of the normative definition. It sounds like
the concern is that the 'technical language' being used here is the
standard form of unambiguously representing a character (by referring to
its Unicode code point). Is that correct?

If so, this should normally be obvious to a reader of appropriate technical
specifications, since it's a convention used throughout the IETF, the W3C,
ISO documents, etc.

More generally, the language proposed by Peter was illustrative to other
examples of specifications that use this form, but not normative ("in
accordance with"). That is, one could easily substitute your proposed "in
accordance with" with a number of other equivalent specifications, without
changing the semantic or normative meaning.

For this reason, it would be much clearer overall, even if it may be an
unfamiliar approach to you, to adopt Peter's text as written. That would
reduce confusion that might otherwise be introduced by your proposed edit
(particularly, ambiguity as to what it means by "in accordance with" and
why ISO/DIS 21188 is referenced in only this section)

On Sun, Jun 18, 2017 at 2:14 AM, Kirk Hall via Public <public at cabforum.org>
wrote:

> Peter – first, you are so smart I will (almost) always do what you say.
> But here is my concern – when you read your new definition, ("A Domain
> Name consisting of "\*." (U+002A ASTERISK, U+002E FULL STOP) prepended to
> a Fully-Qualified Domain Name.”), it has no meaning to me.  Is this
> actually necessary?  Or, if you think it’s necessary, can we at least add a
> reference to the ISO document where you found it, such as:
>
>
>
> "A Domain Name consisting of "\*." (U+002A ASTERISK, U+002E FULL STOP)
> prepended to a Fully-Qualified Domain Name *in accordance with the
> provisions of **ISO/DIS 21188 section 5.12.3*.”
>
>
>
> At least a reader would have a fighting chance of knowing where the highly
> technical definition came from.
>
>
>
> What do others think?
>
>
>
> *From:* Peter Bowen [mailto:pzb at amzn.com]
> *Sent:* Saturday, June 17, 2017 10:22 PM
> *To:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Cc:* Kirk Hall <Kirk.Hall at entrustdatacard.com>
> *Subject:* [EXTERNAL]Re: [cabfpub] Pre-ballot for Ballot 190
>
>
>
> Kirk,
>
>
>
> Thanks for putting this together.  I have one request; ISO/DIS 21188
> section 5.12.3 makes it clear that a wildcard name is not a Fully Qualified
> Domain Name.  I had started to put together a set of changes to clarify
> this independent of this ballot.  The changes are available at
> https://github.com/cabforum/documents/compare/master...pzb:underscores?
> expand=1
>
>
>
> Would you consider adopting a definition closer to the one I proposed ("A
> Domain Name consisting of "\*." (U+002A ASTERISK, U+002E FULL STOP)
> prepended to a Fully-Qualified Domain Name.”)?
>
>
>
> Thanks,
>
> Peter
>
>
>
> On Jun 17, 2017, at 5:41 PM, Kirk Hall via Public <public at cabforum.org>
> wrote:
>
>
>
> After working with some of the chief drafters of the changes to BR 3.2.2.4
> over the past two years, I am posting this revised Ballot 190 which does a
> number of things:
>
>
>
> 1.       There are changes to two Definitions, and a new definition as
> shown.
>
> 2.       The current language of the domain validation section BR 3.2.2.4
> is what we passed in Ballot 181, and is missing validation Methods 1-4 and
> 7-9 with minor tweaks as indicated.  We are also eliminating Method 11
> (previously Method 7) – “any other method.”  The language you see inserted
> is the same language as we passed in Ballot 169, except for the minor
> changes I specifically call out.
>
> 3.       We clarify that once the requested FQDN has been verified using
> a given validation method, the CA may also issue certificates for higher
> level domains that end in the validated FQDN.
>
> 4.       Finally, in response to the discussion we have had on whether a
> change to a validation method means all prior validations using that method
> are no longer valid, we have made some changes.  In essence, the BRs would
> not state that data, documents, and prior validations can be reused for the
> permitted reuse period under BR 4.2.1, unless the Forum specifically
> requires revalidation in a ballot.
>
>
>
> I have attached the pre-ballot in two formats: (a) one in “track changes”
> from Ballot 181 and including comments (this will be the real ballot once
> we finish discussion and the comments are removed), and (b) the other
> showing how BR 3.2.2.4 and 4.2.1 plus the definitions will read if Ballot
> 190 is adopted.  I am sending the documents in both Word and pdf formats.
>
>
>
> We can discuss the ballot this week and on Thursday at the F2F meeting.
> Next week, we can then file the ballot and start the discussion period (7
> days), followed by the voting period.
>
>
>
> One request – if you have comments or edits to suggest, please be VERY
> clear.  This is a very complex ballot, and we will make the most progress
> if we avoid misunderstanding and talking past each other.  Also, if you
> don’t like a section, please suggest specific alternate wording for people
> to consider.
>
> <Ballot 190 (6-17-2017) showing changes from Ballot 181.docx><Ballot 190
> (6-17-2017) showing changes from Ballot 181.pdf><Ballot 190 (6-17-2017) if
> all changes adopted.docx><Ballot 190 (6-17-2017) if all changes adopted.pdf>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170618/9961d775/attachment-0003.html>