Subject: Re: [dnsext] OPENPGPKEY RRTYPE review - [IANA #773394]

From: Frederico A C Neves <[email-masked]>
Date: Fri, 8 Aug 2014 11:58:47 -0300

Dear Colleages,

This message ends the review process for the OPENPGPKEY RRTYPE. Based
on the provided documentation and the list traffic, this request meets
both requirements of RFC6895 section 3.1.1 and none of section
3.1.2. Therefore should be accepted.

Best Regards,
Frederico Neves

On Wed, Jul 23, 2014 at 06:34:03PM -0300, Frederico A C Neves 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-masked]
>     International telephone number: +1-647-896-3464
>     Other contact handles: [email-masked]
> 
>  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-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

---

From: Jay Daley <[email-masked]>
Date: Sun, 10 Aug 2014 20:41:15 +1200

It would be helpful if the draft was updated to reflect the discussion on the list.

Jay

-- 
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

---

From: Paul Wouters <[email-masked]>
Date: Mon, 11 Aug 2014 11:01:34 -0400

> It would be helpful if the draft was updated to reflect the discussion on the list.

I am unsure which discussion items you think should be added to the draft?

- Comments about revoked keys? The draft does not specify anything but the openpgpk key format. Possibly this item could go into the openpgpkey-usage document,
but would have no effect to the OPENPGPKEY record format.

- combining _openpgpkey and _smimecert ? I do not think there is anything gained my merging the namespaces. It would just hinder opengpgp and smime
clients/plug-ins in discarding irrelevant data.

- comments about not using the APEX or justifying the _openpgpkey prefix? I don't think that belongs in the final document.

- referencing 1035's "weak encoding of email address" and explaining why it is unusable. Can be added, although I think the draft already explains the problem
when it states why it is using a sha2-224 hash.

- small textual improvements suggested by Joe Abbley - Can be added to the next draft, but should that hold up this RRTYPE review? I don't think so.

Did I miss anything in particular that you thought needed to be added?

Paul

---

From: Jay Daley <[email-masked]>
Date: Tue, 12 Aug 2014 08:20:34 +1200

> - comments about not using the APEX or justifying the _openpgpkey prefix? I don't think that belongs in the final document.

I do.  Some good reasons were presented on the list and having those in the document provides a significantly better reference than list archives.  Currently there is no explanation at all given of the prefix.

> when it states why it is using a sha2-224 hash.

That would be useful too.

> - small textual improvements suggested by Joe Abbley - Can be added to the next draft, but should that hold up this RRTYPE review? I don't think so.

I don't buy the "none of this is important enough to hold up the process" argument - I see no explanation of an urgent need that overrides doing a quality job.

Jay

---

From: Joe Abley <[email-masked]>
Date: Mon, 11 Aug 2014 17:18:00 -0400

> Did I miss anything in particular that you thought needed to be added?

I think the most important thing that this document can do is present a clear and unambiguous specification, to promote interop between implementations.

Describing the design choices that were made has some value, but mainly for the historical record or to provide input into future design choices that other people might make in similar situations. There's next to no value added for implementors by doing this (note that I'm not saying it has zero value).

Similarly, use cases and examples are great if they provide useful clarity. If they don't (if the specification is clear enough without them), they're not necessary.

A lot of this is subjective.

I think in general the working group should be concerned with whether a document meets its reasonable objectives, and should not attempt to micro-manage the authors into adding orthogonal text if they don't feel like it. In this case, there's no actual need for the wg to be formally involved at all; this could easily progress on its own merits as an individual effort (and it's not a working group draft).

I like what you have done.

Not every RRType specification needs to turn into War and Peace.

Joe

---

From: Joe Abley <[email-masked]>
Date: Mon, 11 Aug 2014 17:32:52 -0400

On 11 Aug 2014, at 17:18, Joe Abley <[email-masked]> wrote:

> In this case, there's no actual need for the wg to be formally involved at all; this could easily progress on its own merits as an individual effort (and it's not a working group draft).

Arrgh, I hit cancel quite a lot after I accidentally hit send, but apparently to no avail. With a name starting with draft-ietf-dane, this seems quite a lot like a wg document, in fact.

Here, let me distract you from the above with this amusing ASCII art, which surely will not render accurately in 98% of the mail clients wishing I hadn't bothered:

  )\._.,--....,'``.
  /,   _.. \   _\  (`._ ,.
 `._.-(,_..'--(,_..'`-.;.'  [Felix Lee <[email-masked]>]

> Not every RRType specification needs to turn into War and Peace.

You're welcome.

Joe