Hello!
I would like to comment on
http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00
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.
2. The DNS does not allow the use of all characters that are
supported in "local-part" of email addresses as defined in
[RFC2822] and [RFC6530] . The SHA2-224 hashing of the user name
ensures that none of these characters would need to be placed
directly in the DNS.
1) SHA-224 result representation:
IMHO this section should state that SHA2-224 result has to be encoded to
hexadecimal representation.
I know that hexadecimal is a common representation for user interfaces but
please keep in mind that SHA2-224 produces 224 bites of "noise" and
hexadecimal representation is not the only possible.
2) Multiple OPENPGPKEY records for one owner name:
I didn't see a note if OPENPGPKEY is supposed to be singleton or not (and how
it should be processed if it isn't singleton). I'm sorry if I missed the note.
3) Algorithm agility:
It is clear to me that SHA2-224 hashing is there "just" for privacy and
nothing else. Still, I think it would be beneficial to have algorithm agility
built-in.
What about
8d[..]b7.sha224._openpgpkey.example.com. IN OPENPGPKEY <base64 public key>
?
Of course, the client need to know where to look for keys.
I can see two approaches:
- "Dumb" clients will try all supported algorithms starting with the strongest.
- List of available algorithms can be published under _openpgpkey.example.com.
Note that I'm perfectly fine with defining only SHA-224 for now. Basically
this is the same situation as with SSHFP fingerprint types. They started with
SHA-1 only but with the alg. agility built-in.
Maybe we could have yet another IANA registry for this...
A new registry would allow us to do fancy things in future.
E.g. to define "salted-sha-224" algorithm and store salt under
ssha224._openpgpkey.example.com. That still allows you to share _openphpkey
sub-tree between domains...
Or to define "clear" algorithm if deemed.
Or to define a clever way how to cut hash into several labels if we need to do
so ...
Have a nice day!
--
Petr^2 Spacek
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
