On Fri, Feb 20, 2015 at 03:30:05PM -0500, Warren Kumari wrote:
> Please review this draft to see if you think it is ready for
> publication and send comments to the list, clearly stating your view.
Comments:
* The below does not mention the hex encoding of the digest. Compare with
SMIMEA:
OPENPGPKEY:
3. Location of the OpenPGPKEY record
Email addresses are mapped into DNS using the following method:
1. The user name (the "left-hand side" of the email address, called
the "local-part" in the mail message format definition [RFC2822]
and the "local part" in the specification for internationalized
email [RFC6530]), is hashed using the SHA2-224 [RFC5754]
algorithm to become the left-most label in the prepared domain
name. This does not include the at symbol ("@") that separates
the left and right sides of the email address.
SMIMEA:
The user name (the "left-hand side" of the email address, called
the "local-part" in the mail message format definition [RFC2822]
and the "local part" in the specification for internationalized
email [RFC6530]), is hashed using the SHA2-224 [RFC5754]
algorithm (with the hash being represented in its hexadecimal
representation, to become the left-most label in the prepared
domain name. This does not include the "@" character that
separates the left and right sides of the email address. The
string that is used for the local part is a Unicode string
encoded in UTF-8.
* Grammar nit replace "its" with "their" or rephrase:
5.1. Email address information leak
Email addresses are not secret. Using them causes its publication.
* Forward security vouching for long-term keys
There's a typo in the first word of the highlighted paragraph:
5.2. Forward security of OpenPGP versus DNSSEC
[...]
Therefor, an OpenPGP key obtained via an OPENPGPKEY
record can only be trusted as much as the DNS domain
can be trusted, and are no substitute for in-person key
verification of the "Web of Trust". See [OPENPGPKEY-USAGE]
for more in-depth information on safe usage of OPENPGPKEY
based OpenPGP keys.
An complementary approach is to not use the retrieved OpenPGP
key beyond the signature lifetime of the OPENPGPKEY RRset RRSIG
record. Keys obtained from DNS should be refreshed as often
as is practical (ideally before encrypting each message) and
never used beyond the RRSIG lifetime. Were the RRSIG in question
signed by an attacker, only messages signed before the key is
refreshed are compromised. Of course this requires that PGP
user agent software track the provenance and cache lifetime of
keys obtained via DNS.
* Encoding tools:
Appendix A. Generating OPENPGPKEY records
gpg --export --export-options export-minimal \
[email protected] | base64
the "openssl base64" command is an alternative on many other platforms.
Later the examples don't yet use the newly allocated TYPE61:
These values can then be used to generate a generic record (line
break has been added for formatting):
<SHA2-224(hugh)>._openpgpkey.example.com. IN TYPE65280 \# \
<numOctets> <keydata in hex>
...
~> openpgpkey --output generic [email protected]
8d[...]b7._openpgpkey.example.com. IN TYPE65280 \# 2313 99008d03[...]
the type should of course now be TYPE61. May as well give a
recipe for generating "SHA2-224(hugh)":
printf "%s" hugh |
openssl dgst -sha224 -binary |
hexdump -ve '/1 "%.2x"' -e '/28 "\n"'
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
