Re: [dane] draft-ietf-dane-openpgpkey-00 comments

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Paul Wouters writes:
> On Wed, 23 Apr 2014, Mark Andrews wrote:
> 
> >> CERT also uses sub-typing, so you might end up getting all kind of types
> >> of certificates (like a PKIX cert) that you don't want or need. Granted,
> >> the _openpgpkey. prefix would at least prevent the non-malicious
> >> contamination, but you might still get all kinds of weird stuff. From
> >> what I understood, sub-typing was what really killed the CERT record,
> >> and everyone since has been strongly urged to stay away from sub-typing,
> >> and told to use _prefix. instead.
> >
> > 	Then you have failed to understand RFC 5507.
> 
> Hmm, I read from RFC 5507"
> 
>     When storing data in the DNS for a new application, the goal must be
>     to store data in such a way that the application can query for the
>     data it wants, while minimizing both the impact on existing
>     applications and the amount of extra data transferred to the client.
>     This implies that a number of design choices have to be made, where
>     the most important is to ensure that a precise selection of what data
>     to return must be made already in the query.
> 
> To me that reads as "don't do sub-typing" because the query cannot
> request the single type it is interested it, and can only get the full
> list.
> 
> >> The CERT record also does not offer a nice presentation format for the
> >> zone file. The RFC states:
> >>
> >>        smith        IN CERT PGP 0 0 <OpenPGP binary>

> > 	CERT records have base64 as the presentation format of the
> > 	binary blob.
> 
> The line above here containing "smith" comes straight from that same
> RFC, so that's a little confusing then :P I did not read "<OpenPGP binary>"
> as "base64" :P
> 
> Maybe we should file an errata (if people cared about CERT)
> 
> Paul

As far as I can see you want a new type to save 5 bytes per record.
There is no need for a new type especially as you are using a prefix
to seperate usage.  CERT is quite capable of holding the data.

I can see some use in encoding local part as we don't want case
insensitve local parts.  We also don't want to be able to just list
out the PI data.  Additionally a prefix is useful for seperating
name spaces (people vs machines).  Standard mbox encoding (RFC 1034)
doesn't seperate the name spaces which has always been a problem.

I would recommend changing the draft to focus on why mbox is not a
good format for the DNS keys for email addresses for and just encode
the data using CERTs.

Note ":" + base32hexnp(sha1(utf8(local))) would be sufficient without
the _openpgpkey label to seperate namespaces. (':' could be replaced
with any non LDH character)  Reserve all strings which match that
format for the new mbox format.

base32hexnp = base32hex with no padding as used in NSEC3.

Mark


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]