Re: [DNSOP] Looking for IANA registry for --xn

2016-10-07 Thread Robert Edmonds
Jim Reid wrote:
> > On 7 Oct 2016, at 03:33, Phillip Hallam-Baker  wrote:
> > 
> > Protocol matters. And just because IANA does 'assignments' that are not 
> > 'registrations' doesn't mean that is right or should continue.
> 
> I’m sure the RIRs and the hundreds of millions of people who are using IP 
> addresses because of IANA ‘assignments’ will be delighted to hear that.

Is the "IANA IPv4 Address Space Registry" not a registry?

http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml

http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml

-- 
Robert Edmonds

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Looking for IANA registry for --xn

2016-10-07 Thread Jim Reid

> On 7 Oct 2016, at 03:33, Phillip Hallam-Baker  wrote:
> 
> Protocol matters. And just because IANA does 'assignments' that are not 
> 'registrations' doesn't mean that is right or should continue.

I’m sure the RIRs and the hundreds of millions of people who are using IP 
addresses because of IANA ‘assignments’ will be delighted to hear that.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Looking for IANA registry for --xn

2016-10-06 Thread Phillip Hallam-Baker
No it is not a pedantic difference.

If it isn't in a registry it didn't happen.

It is like when someone decided to do an April Fools RFC which used a code
point in PKIX space that wasn't actually registered with IANA. That caused
some real chaos.

Protocol matters. And just because IANA does 'assignments' that are not
'registrations' doesn't mean that is right or should continue.


On Thu, Oct 6, 2016 at 9:56 PM, Paul Hoffman  wrote:

> On 6 Oct 2016, at 18:09, Phillip Hallam-Baker wrote:
>
> On Thu, Oct 6, 2016 at 5:13 PM, Jaap Akkerhuis  wrote:
>>
>>> RFC 3490 does say something about the ACE prefix.
>>>
>>> ​It says it has been registered but not where and there is no IANA
>>>
>> registry that references RFC3490​
>>
>
> It does not say it was "registered", it says that it was "assigned":
>
>11. IANA Considerations
>
>   IANA has assigned the ACE prefix in consultation with the IESG.
>
> This is not a pedantic difference: IANA keeps registries for things it has
> registered. This prefix was assigned by IANA as a neutral body that helped
> determine a prefix that was unlikely to have been used in public domain
> labels; you can read the mailing list for why that came about that way.
> There was no registry for prefixes because it was a one-off for this RFC
> only. That can change in the future, of course.
>
> --Paul Hoffman
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Looking for IANA registry for --xn

2016-10-06 Thread Paul Hoffman

On 6 Oct 2016, at 18:09, Phillip Hallam-Baker wrote:

On Thu, Oct 6, 2016 at 5:13 PM, Jaap Akkerhuis  
wrote:

RFC 3490 does say something about the ACE prefix.

​It says it has been registered but not where and there is no IANA

registry that references RFC3490​


It does not say it was "registered", it says that it was "assigned":

   11. IANA Considerations

  IANA has assigned the ACE prefix in consultation with the IESG.

This is not a pedantic difference: IANA keeps registries for things it 
has registered. This prefix was assigned by IANA as a neutral body that 
helped determine a prefix that was unlikely to have been used in public 
domain labels; you can read the mailing list for why that came about 
that way. There was no registry for prefixes because it was a one-off 
for this RFC only. That can change in the future, of course.


--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Looking for IANA registry for --xn

2016-10-06 Thread Phillip Hallam-Baker
On Thu, Oct 6, 2016 at 5:13 PM, Jaap Akkerhuis  wrote:

>  Robert Edmonds writes:
>
>  > Donald Eastlake wrote:
>  > > Sure, you can consider the root zone to be the registry for TLDs but
> the
>  > > point is the xn-- labels are recommended to be interpreted specially
> at the
>  > > user interface at all levels...
>  >
>  > Nor would this say anything about "CCHH" prefixed labels in general.
>  >
>
> RFC 3490 does say something about the ACE prefix.
>
> ​It says it has been registered but not where and there is no IANA
registry that references RFC3490​
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Looking for IANA registry for --xn

2016-10-06 Thread Jaap Akkerhuis
 Robert Edmonds writes:

 > Donald Eastlake wrote:
 > > Sure, you can consider the root zone to be the registry for TLDs but the
 > > point is the xn-- labels are recommended to be interpreted specially at the
 > > user interface at all levels...
 > 
 > Nor would this say anything about "CCHH" prefixed labels in general.
 > 

RFC 3490 does say something about the ACE prefix.

jaap

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop



Re: [DNSOP] Looking for IANA registry for --xn

2016-10-06 Thread Robert Edmonds
Donald Eastlake wrote:
> Sure, you can consider the root zone to be the registry for TLDs but the
> point is the xn-- labels are recommended to be interpreted specially at the
> user interface at all levels...

Nor would this say anything about "CCHH" prefixed labels in general.

At the TLD level there seems to be an agreement at least(?) for new
gTLDs to reserve all "CCHH" prefixes in delegated names other than
xn--:

SPECIFICATION 6

REGISTRY INTEROPERABILITY AND CONTINUITY SPECIFICATIONS

1. Standards Compliance

1.1. DNS.  Registry Operator shall comply with relevant existing
RFCs and those published in the future by the Internet Engineering
Task Force (IETF), including all successor standards, modifications
or additions thereto relating to the DNS and name server operations
including without limitation RFCs 1034, 1035, 1123, 1982, 2181,
2182, 2671, 3226, 3596, 3597, 4343, and 5966.   DNS labels may only
include hyphens in the third and fourth position if they represent
valid IDNs (as specified above) in their ASCII encoding (e.g.,
“xn--ndk061n”).


https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-09jan14-en.htm

-- 
Robert Edmonds

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Looking for IANA registry for --xn

2016-10-06 Thread Donald Eastlake
Hi,

On Thu, Oct 6, 2016 at 3:14 PM, Jim Reid  wrote:

> > On 6 Oct 2016, at 18:59, Donald Eastlake  wrote:
> > I don't believe there is a registry.
>
> Actually there is. Sort of:

% whois -h whois.iana.org テスト
> % IANA WHOIS server
> % for more information on IANA, visit http://www.iana.org
> % This query returned 1 object
>
> domain:   テスト
> domain-ace:   XN--ZCKZAH
> ...
>

Sure, you can consider the root zone to be the registry for TLDs but the
point is the xn-- labels are recommended to be interpreted specially at the
user interface at all levels...

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com


> It should be a no-brainer for IANA to publish and maintain a list of these
> IDN encodings for delegated TLDs.
>
> ISTR IANA's Root Zone Database web page used to contain the punycode
> representation for the non-ASCII TLDs. Though I could well have imagined
> that.
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Looking for IANA registry for --xn

2016-10-06 Thread Jim Reid

> On 6 Oct 2016, at 18:59, Donald Eastlake  wrote:
> 
> I don't believe there is a registry.

Actually there is. Sort of:

% whois -h whois.iana.org テスト
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object

domain:   テスト
domain-ace:   XN--ZCKZAH
...

It should be a no-brainer for IANA to publish and maintain a list of these IDN 
encodings for delegated TLDs.

ISTR IANA's Root Zone Database web page used to contain the punycode 
representation for the non-ASCII TLDs. Though I could well have imagined that.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Looking for IANA registry for --xn

2016-10-06 Thread Paul Hoffman

On 6 Oct 2016, at 10:08, Phillip Hallam-Baker wrote:

I have been looking for the IANA registry in which the IDNA prefix 
xn-- is

allocated and have not been able to find it. I can see the following
possibilities

1) There isn't such a registry. The allocation is purely ad hoc

2) There is a registry but none of the IDNA RFCs bother to list it as 
a

normative reference.


It is #1. It is defined in the IDNA RFCs as a single value. If you want 
to change IDNA, you need to update the RFC.


--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Looking for IANA registry for --xn

2016-10-06 Thread Donald Eastlake
I don't believe there is a registry. It would seem reasonable to reserve
labels starting with all other [a-z][a-z]-- besides xn-- and establish a
registry. (To avoid people trying to squat on names in advance, the "xn"
was selected by the same sort of publicly verifiable random process as
nomcom voter selection.) Especially if there are any other DNS parameter
registration things that need to be tweaked, I think the best thing might
be an update of RFC 6895.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

On Thu, Oct 6, 2016 at 1:51 PM, Phillip Hallam-Baker 
wrote:

> ​​
>
>
> On Thu, Oct 6, 2016 at 1:24 PM,  wrote:
>
>>
>> >I have been looking for the IANA registry in which the IDNA prefix xn--
>> is allocated and have not been able to find it. I can see the following
>> possibilities
>>
>> >1) There isn't such a registry. The allocation is purely ad hoc
>>
>> >2) There is a registry but none of the IDNA RFCs bother to list it as a
>> normative reference.
>>
>> >Either one would be bad. The existence or non existence of a registry,
>> the allocation or non allocation of a code point is not going to cause me
>> to decide whether or not to use functionality. All that the registry
>> achieves is to avoid collisions.
>>
>> Phil, this is very interesting.
>>
>> The 'xn--', of course, is the prefix for punycode used for International
>> Domain Names.   I have seen it used for DNS resolution quite a bit in the
>> last couple of months.   So, it is certainly used.   In fact, that appears
>> to be the only way one can do DNS resolution (at least in my experience).
>> That is, do the translation from IDN to punycode.   Then, it seems to work
>> like a charm.
>>
>>
> ​I am not looking to extend the xn-- system, I have another parallel
> application.​
>
> Imagine for the sake of argument that someone who was a VIP (VERY VIP)
> needed a secure email system and imagine that they wanted something that
> was completely compatible with the existing email infrastructure. ​
>
>
> ​A UDF fingerprint MAY be encoded as a DNS label by prefixing the Base32
> text representation with the string ‘zz--‘.
>
> A DNS name that includes a UDF fingerprint as a DNS label carries the
> implicit assertion that the interpretation of the address MUST be
> authorized by a security policy that is validated under a key that matches
> the corresponding fingerprint.
>
>
> Placing such a DNS label as the top level (rightmost) label in a DNS
> address creates an address that is not legal and thus cannot be resolved by
> the Internet DNS infrastructure. Thus ensuring that the address is rejected
> by applications that are not capable of performing the associated
> validation steps.
>
>
> For example, Alice has the email security key with fingerprint
> MB2GK-6DUF5-YGYYL-JNY5E. She uses the following email addresses:
>
> ​* ​
> al...@example.com
>
> Alice publishes this email address when she does not want the other party
> to use the secure email system.
>
> ​* ​
> al...@zz--mb2gk-6duf5-ygyyl-jny5e.example.com
>
> Alice publishes this email address when she wants to give the other party
> the option of using secure email if their system supports it.
>
> The DNS server for example.com has been configured to redirect requests
> to resolve zz--mb2gk-6duf5-ygyyl-jny5e.example.com to the mail server
> example.com.
>
> ​* ​
> al...@example.com.zz--mb2gk-6duf5-ygyyl-jny5e
>
> Alice uses this email address when she wants the other party to be able to
> send her email if and only if their client supports use of the secure
> messaging system.
>
> While there should never be a DNS label of the form zz--* in the
> authoritative DNS root, such labels MAY be introduced by a trusted local
> resolver. This would allow attempts at making an untrusted communication
> request to be transparently redirected through a locally trusted security
> enhancing proxy.​
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Looking for IANA registry for --xn

2016-10-06 Thread Phillip Hallam-Baker
​​


On Thu, Oct 6, 2016 at 1:24 PM,  wrote:

>
> >I have been looking for the IANA registry in which the IDNA prefix xn--
> is allocated and have not been able to find it. I can see the following
> possibilities
>
> >1) There isn't such a registry. The allocation is purely ad hoc
>
> >2) There is a registry but none of the IDNA RFCs bother to list it as a
> normative reference.
>
> >Either one would be bad. The existence or non existence of a registry,
> the allocation or non allocation of a code point is not going to cause me
> to decide whether or not to use functionality. All that the registry
> achieves is to avoid collisions.
>
> Phil, this is very interesting.
>
> The 'xn--', of course, is the prefix for punycode used for International
> Domain Names.   I have seen it used for DNS resolution quite a bit in the
> last couple of months.   So, it is certainly used.   In fact, that appears
> to be the only way one can do DNS resolution (at least in my experience).
> That is, do the translation from IDN to punycode.   Then, it seems to work
> like a charm.
>
>
​I am not looking to extend the xn-- system, I have another parallel
application.​

Imagine for the sake of argument that someone who was a VIP (VERY VIP)
needed a secure email system and imagine that they wanted something that
was completely compatible with the existing email infrastructure. ​


​A UDF fingerprint MAY be encoded as a DNS label by prefixing the Base32
text representation with the string ‘zz--‘.

A DNS name that includes a UDF fingerprint as a DNS label carries the
implicit assertion that the interpretation of the address MUST be
authorized by a security policy that is validated under a key that matches
the corresponding fingerprint.


Placing such a DNS label as the top level (rightmost) label in a DNS
address creates an address that is not legal and thus cannot be resolved by
the Internet DNS infrastructure. Thus ensuring that the address is rejected
by applications that are not capable of performing the associated
validation steps.


For example, Alice has the email security key with fingerprint
MB2GK-6DUF5-YGYYL-JNY5E. She uses the following email addresses:

​* ​
al...@example.com

Alice publishes this email address when she does not want the other party
to use the secure email system.

​* ​
al...@zz--mb2gk-6duf5-ygyyl-jny5e.example.com

Alice publishes this email address when she wants to give the other party
the option of using secure email if their system supports it.

The DNS server for example.com has been configured to redirect requests to
resolve zz--mb2gk-6duf5-ygyyl-jny5e.example.com to the mail server
example.com.

​* ​
al...@example.com.zz--mb2gk-6duf5-ygyyl-jny5e

Alice uses this email address when she wants the other party to be able to
send her email if and only if their client supports use of the secure
messaging system.

While there should never be a DNS label of the form zz--* in the
authoritative DNS root, such labels MAY be introduced by a trusted local
resolver. This would allow attempts at making an untrusted communication
request to be transparently redirected through a locally trusted security
enhancing proxy.​
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


Re: [DNSOP] Looking for IANA registry for --xn

2016-10-06 Thread nalini.elkins

>I have been looking for the IANA registry in which the IDNA prefix xn-- is 
>allocated and have not been able to find it. I can see the following 
>possibilities

>1) There isn't such a registry. The allocation is purely ad hoc

>2) There is a registry but none of the IDNA RFCs bother to list it as a 
>normative reference.

>Either one would be bad. The existence or non existence of a registry, the 
>allocation or non allocation of a code point is not going to cause me to 
>decide whether or not to use functionality. All that the registry achieves is 
>to avoid collisions.


Phil, this is very interesting.   
The 'xn--', of course, is the prefix for punycode used for International Domain 
Names.   I have seen it used for DNS resolution quite a bit in the last couple 
of months.   So, it is certainly used.   In fact, that appears to be the only 
way one can do DNS resolution (at least in my experience).  That is, do the 
translation from IDN to punycode.   Then, it seems to work like a charm.
Certainly sounds like an update somewhere is needed.
People may be interested in a draft that Harish and I have just posted:

https://datatracker.ietf.org/doc/draft-elkchow-iea-deploy

>From our section 1.1 which explains punycode:

"Languages not based on the Latin script (A, B, C, etc) use unicode to 
represent the letters in their alphabet rather than ASCII. Punycode is used to 
show unicode characters in ASCII format. It is used in the transport of email. 

For example: 
English: NehruHindi: नेहरूPunycode: xn--l2bq0a0bw 

Punycode will start with the prefix: "xn--". An application handling IDN 
domains has to reference an IDN repository to know how to display them. Emails 
add to the complication since many email systems pre-date the introduction of 
IDNs. These systems often simply reject emails that don't work within the old 
domain name model. 
Nalini Elkins
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


[DNSOP] Looking for IANA registry for --xn

2016-10-06 Thread Phillip Hallam-Baker
I have been looking for the IANA registry in which the IDNA prefix xn-- is
allocated and have not been able to find it. I can see the following
possibilities

1) There isn't such a registry. The allocation is purely ad hoc

2) There is a registry but none of the IDNA RFCs bother to list it as a
normative reference.

Either one would be bad. The existence or non existence of a registry, the
allocation or non allocation of a code point is not going to cause me to
decide whether or not to use functionality. All that the registry achieves
is to avoid collisions.


Phill
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop