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

In message <alpine.LFD.2.10.1404221827080.32654@bofh.nohats.ca>, Paul Wouters writes:
> On Tue, 22 Apr 2014, James Cloos wrote:
> 
> > PS> What about CERT RR?
> > PS> http://tools.ietf.org/html/rfc4398#section-2.1 contains this (beside others):
> >
> > Cert uses the user portion of the email address as-is, and therefor only
> > supports usernames which fit unalterred in dns.
> 
> Correct. Although we could have used the openpgpkey style _prefix to
> avoid that, there were more issues with the CERT record type.
> 
> 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.

> 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.  This is independent of the type of certificate
	being encoded.  See RFC 4398 2.2 Text Representation of CERT RRs.
	I think you are confusing wire format and presentation format.

> Having binary in a zone is really a non-starter. Which is why OPENPGPKEY
> uses base64 as the presentation format and the raw binary as the wire
> format.
>
> > Some aspects of the rfc are a bit terse.  Can you tell, for IPGP,
> > whether the length octet is a bit-lenght or an octet-length?  Or
> > which data, exactly, is digested to create the key tag?
> 
> IPGP specifies a URL, so now that url becomes another security hurdle.
> What do you do when it is on https and you don't trust the CA, ignore.
> What do you do when the URL is unreachable - is that censorship/attack?
> With the full key in DNSSEC, you get the entire key using only one DNS
> query without any followup HTTP(S) queries that you might not be able to
> do for various (security/monitoring) reasons.
> 
> It seemed much more desirable to start a fresh dedicated RRTYPE over
> fixing up the CERT RRTYPE and then needing to deal with servers that
> only support the "old CERT type" versus ones that support the "new CERT
> type". In other words, the pain of recycling was worse than just
> starting fresh.
> 
> Paul
> 
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org