[dane] draft-ietf-dane-openpgpkey-00 comments

[Petr Spacek <[e-mail]>]

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