On Thu, 10 Sep 2015, Simon Josefsson wrote:
I believe it would be a mistake to publish this document without having it include a discussion of its relationship to RFC 4648. As far as I can tell, the CERT record defined in RFC 4648 solves roughly the same problem as OPENPGPKEY and CERT is already deployed with support in (for example) GnuPG. I believe the community would benefit from sorting out the relationship before publication, not after, when we would have two RFCs describing solutions for what appears to be the same problem.
This issue has also come up several times in the working group discussion. While a paragraph could surely be added to the document, I don't see much value in such historic inclusion to implementors. The CERT record uses sub typing which is (now) considered to be bad in DNS, including by at least one of the authors of the original CERT record RFC-2538. It includes dependancies on other security modules besides DNSSEC (PKIX, CA's, generic URI's dealing with TLS security, etc.) which makes it hard on implementors that only want to implement certain security schemes (eg just OpenPGP and not PKIX, SPKI, X.509 blobs, etc). So that leaves only the PGP and iPGP sub types of the CERT. That also means the DNSKEY algorthm number of the CERT RDATA is always 0 (and really not needed) Indirect URI schemes of CERT can also be used to trick MUA's or MTA's into connecting to random rogue servers, which is both a security and a privacy problem. This makes the CERT sub-type IPGP undesirable. The OPENPGPKEY record uses no sub types, involves no other PKIs, and supports one clear RDATA format to implement. Depending on only DNS(SEC) means that openpgp key data can be distributed easilly and widely, without creating single point of failures or easilly blocked HTTP requests that are indistinguisable from outages. With DNSSEC, tampering is visible because there will be a BOGUS DNS answer when the data is filtered or the data is obtained. Whereas with indirect methods there can be "unknown errors" in reaching the indirectly pointed by resource. The CERT record did not address the local-part lookup problem. So regardless, a new RFC would be needed to specify the local-part lookup. That RFC would than basically have to say "Only use IANA certificate type is 3 (PGP) and algorithm type 0 (not a DNSKEY algorithm). It seems much cleaner to limit the RDATA section to just the OpenPGP key material without unused sub-typing and zero'd algorithm identifiers. The OPENPGPKEY record early code point has already seen more deployment than the CERT record. The SMIME record draft also does not plan on using the CERT record. Paul