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

[Petr Spacek <[e-mail]>]

On 22.4.2014 10:43, Petr Spacek wrote:
> 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 ...

Hmm, I have even more controversial idea:

What about CERT RR?
http://tools.ietf.org/html/rfc4398#section-2.1 contains this (beside others):

2.1. Certificate Type Values

    The following values are defined or reserved:

          Value  Mnemonic  Certificate Type
          -----  --------  ----------------
              3  PGP       OpenPGP packet

I wasn't around when CERT was designed and I haven't seen it in wild, so 
please bear with me if I'm totally wrong :-)

http://tools.ietf.org/html/rfc4398#section-3.3
seems to define basically the same thing as draft-ietf-dane-openpgpkey-00 - 
except usage of hashing for owner name derivation.

What is the advantage of using OPENPGPKEY RR instead of CERT RR?

Can we use CERT and drop OPENPGPKEY RR definition from 
draft-ietf-dane-openpgpkey and define "Location of the OpenPGPKEY record"?

Also, RFC 4398 mentions OpenPGP revocation certificates. It sounds like an 
interesting idea... I can imagine using DNS for key revocation in the same way 
as for key distribution.

-- 
Petr^2 Spacek