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
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
