[cabfpub] FW: Extension of period allowing .onion certificates

[Ryan Sleevi]

A special-use domain is a reserved TLD. That was the point in which I tried
to spell out, by pointing to the multiple references that explain that.

You reference "the language IESG actually uses", but you've entirely missed
that they (and IANA) both use reserved TLDs as terms.

Apologies that this isn't clearer, but I think if the confusion is so
fundamental, then I cannot help but doubt using "special-use domain" would
bring any clarity.

On Mon, Nov 23, 2015 at 10:57 AM, kirk_hall at trendmicro.com <
kirk_hall at trendmicro.com> wrote:

> Ryan, you are always the one who holds us to a strict interpretation of
> the Bylaws when some flexibility would be useful: “What do the Bylaws say?”
>  So I would have expected you to take the same position on a Ballot.
> Ballot 144 allows .onion certs to continue if “(and only if) .onion is
> officially recognized by the IESG as a reserved TLD.”  So that was the
> basis of suggesting we conform the language to the term that  IESG
> actually uses, “special-use domains.”
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi at google.com]
> *Sent:* Monday, November 23, 2015 10:08 AM
> *To:* Kirk Hall (RD-US)
> *Cc:* Gervase Markham; CABFPub (public at cabforum.org)
> *Subject:* Re: [cabfpub] FW: Extension of period allowing .onion
> certificates
>
>
>
>
>
>
>
> On Mon, Nov 23, 2015 at 9:39 AM, kirk_hall at trendmicro.com <
> kirk_hall at trendmicro.com> wrote:
>
> Our existing rule only allows .onion certs to be issued “after (and only
> if) .onion is officially recognized by the IESG as a reserved TLD.”
>
>
>
> Here is what IETF did – the RFC makes it pretty clear how the .onion
> domain may be used.
>
> http://tools.ietf.org/html/rfc7686
>
>
> http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml
>
>
>
> However, it is a “special-use” domain.  They also have “Policy Reserved
> Domains”
>
>
>
> https://www.iana.org/domains/reserved
>
>
>
> I know at least one CA was of the opinion that it can no longer issue
> .onion certs.
>
>
>
> Maybe we should add an amendment to a future uncontroversial ballot
> (unless someone objects) to clear this up.
>
>
>
> I'm not sure a ballot is necessary. This seems solely based on a
> misunderstanding of the role of various SDOs and how the IANA process
> works. This is no different than a member misunderstanding RFC 5280 -
> that's not something we generally ballot to 'explain' how RFC 5280 works,
> no more than we ballot to explain RFC 2119 language.
>
>
>
> IANA reserved domains encompasses "Example Domains", "Test IDN top-level
> domains", "Policy-reserved domains", and "Other Special-Use Domains". These
> are all categories of reserved domains.
>
>
>
> As you note, the IANA-managed registry is managed under the terms of RFC
> 6761 - which spells out somewhat unambiguously what it is:
>
>
>
> http://tools.ietf.org/html/rfc6761
>
> "This document describes what it means to say that a Domain Name
> (DNS name) is reserved for special use, when reserving such a name
> is appropriate, and the procedure for doing so.  It establishes an
> IANA registry for such domain names, and seeds it with entries for some
> of the already established special domain names."
>
>
>
> If any such ballot is put forward, I think it would be extremely
> important, if not necessary, for the CA you allude to to step forward and
> explain the reasoning and source of confusion. Otherwise, this feels like
> dealing with an abstract hypothetical, and any changes - positive or
> negative - will merely be debated in the abstract, which would end up
> taking far longer than necessary.
>
> TREND MICRO EMAIL NOTICE
> The information contained in this email and any attachments is confidential
> and may be subject to copyright or other intellectual property protection.
> If you are not the intended recipient, you are not authorized to use or
> disclose this information, and we request that you notify us by reply mail or
> telephone and delete the original message from your mail system.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151123/153aa0f2/attachment-0003.html>