Florian Weimer <fw(_at_)deneb(_dot_)enyo(_dot_)de> writes:
* Simon Josefsson:
Is this correct? Would it be useful to mention other kind of OpenPGP
data packets directly, as well?
Why do you want to duplicate this information?
Are you saying any OpenPGP data in the CERT RR should be permitted?
I think RFC 2538 was unclear on this, but it seems clear that at least
it was intended to store self-signed OpenPGP keys. Given that X.509
CRLs are supported by the same document, one could argue that OpenPGP
revocation certs should be permitted as well. But any OpenPGP data?
The text currently says:
Public keys can use the OpenPGP public key packet (tag 6) or public
subkey packet (tag 14), as described in section 5.5 of [5].
Revocation signatures can use an OpenPGP signature packet with a
revocation signature type, i.e., signature type 0x20, 0x28 or 0x30,
as described in section 5.2 of [5].
It was mostly meant to illustrate that OpenPGP data is sub-typed.
I don't have a preference, but I think the updated document should be
clear on exactly what kind of data may be stored in the RDATA portion.
Permitting any OpenPGP data may a simple solution.
Further, if someone has additional thoughts on he document, now would
be a good time to discuss them.
$ gpg --export "68FD549F" | wc -c
88127
Some OpenPGP certificates may have to be split across multiple
resource records. Maybe DNS isn't such a great place to store them
after all. 8-/
This is certainly a problem. The update should at least acknowledge
this. There are some ideas on how to solve the problem in
draft-josefsson-cert-openpgp.txt, but I'm not sure it is a good idea.
In the URI type, it would be nice if some hashes are included. As a
result, the protection offered by DNSSEC one day would extend to the
referenced document.
That seem to be a good suggestion, I'll add it.
NAPTR records offer an interesting perspective for mapping domains
(and email address) to certificate references. Such records could
look like this one:
_openpgp.example.org IN NAPTR 10 10 "u" "PGP+D2U"
"!^(.*)@example.org$!http://ca.example.org/lookup.cgi?user=\\1!";
Right, but that is out of scope for 2538bis.
Thanks,
Simon