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