Re: OPENPGPKEY RRTYPE review - Comments period ends Aug 6th

The text contains this specification element:

	 3.  The string "_openpgpkey" becomes the second left-most label in
       the prepared domain name.

without any explanation (that I can see) of a) why it is needed and b) why openpgpkey has been chosen.  

The only reason I can see is to support partitioning these RRs into a separate zone but then if an admin wanted to do that they might also want to put lots more email records there and so maybe _email would be better.  But then what about other personally identifying URIs like those used in SIP endpoints?  Umm.

The rest seems like a good idea.

Jay

On 24/07/2014, at 9:34 am, Frederico A C Neves <[email protected]> wrote:

> Dear Colleagues,
> 
> Bellow is a completed template requesting a new RRTYPE assignment
> under the procedures of RFC6895.
> 
> This message starts a 2 weeks period for an expert review of the DNS
> RRTYPE parameter allocation for OPENPGPKEY specified at:
> 
> http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00#section-2
> 
> If you have comments regarding this request please post them here
> before Aug 6th 21:00 UTC.
> 
> Best Regards,
> Frederico Neves
> 
> --begin 6895 template TLSA--
> A. Submission Date: 23-07-2014
> 
> B.1 Submission Type:  [x] New RRTYPE  [ ] Modification to RRTYPE
> B.2 Kind of RR:  [x] Data RR  [ ] Meta-RR
> 
> C. Contact Information for submitter (will be publicly posted):
>    Name: Paul Wouters         Email Address: [email protected]
>    International telephone number: +1-647-896-3464
>    Other contact handles: [email protected]
> 
> D. Motivation for the new RRTYPE application.
> 
>    Publishing RFC-4880 OpenPGP formatted keys in DNS with DNSSEC
>    protection to faciliate automatic encryption of emails in
>    defense against pervasive monitoring.
> 
> E. Description of the proposed RR type.
> 
>    http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00#section-2
> 
> F. What existing RRTYPE or RRTYPEs come closest to filling that need
>    and why are they unsatisfactory?
> 
>    The CERT RRtype is the closest match. It unfortunately depends on
>    subtyping, and its use in general is no longer recommended. It
>    also has no human usable presentation format. Some usage types of
>    CERT require external URI's which complicates the security model.
>    This was discussed in the dane working group.
> 
> G. What mnemonic is requested for the new RRTYPE (optional)?
> 
>    OPENPGPKEY
> 
> H. Does the requested RRTYPE make use of any existing IANA registry
>    or require the creation of a new IANA subregistry in DNS
>    Parameters?  If so, please indicate which registry is to be used
>    or created.  If a new subregistry is needed, specify the
>    allocation policy for it and its initial contents.  Also include
>    what the modification procedures will be.
> 
>    The RDATA part uses the key format specified in RFC-4880, which
>    itself use https://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtm
> 
>    This RRcode just uses the formats specified in those registries
>    for its RRdata part.
> 
> 
> I. Does the proposal require/expect any changes in DNS
>    servers/resolvers that prevent the new type from being processed
>    as an unknown RRTYPE (see [RFC3597])?
> 
>    No.
> 
> J. Comments:
> 
>    Currently, three software implementations of draft-ietf-dane-openpgpkey
>    are using a private number.
> --end 6895 template TLSA--
> 
> _______________________________________________
> dnsext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsext


-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840
linkedin: www.linkedin.com/in/jaydaley

_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext