On Mon, 28 Jul 2014, Rene Bartsch wrote:
I've three suggestions on draft-wouters-dane-openpgp-02:
1. email domain providers MUST provide a secure API/interface to customers to
provide a personal OpenPGP public key
The draft document is the "secure API" to obtain records. The IETF is
not an organisation that can tell domain providers what they must
provide to their customers.
2. MTAs/SPAM detection systems MUST check if the tupel "sender email address"
<-> "sender OpenPGP public key" matches and MUST reject the email in case it
does not match with signed messages to prevent address forgery and SPAM.
These are security considerations that should be discussed for
http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-usage-00
Note that I don't agree with the check you propose. I might be using a
different key for my "default email" protection, versus a manually
verified web of trust key. That is, my "default email" key might be
online and auto-decrypt on my own server, while my "web of trust" key
is completely offline- and I might not even want to publish it in DNS
or elsewhere. Although I agree that anti-spam based solutions could
surely taking signing into consideration in their determination of spam
versus ham.
3. Security considerations: The IANA has control over the DNSSEC root keys.
As the IANA is bound to US law, US government agencies probably have access
to the DNSSEC root keys and are capable to manipulate the OpenPGP keys signed
with DNSSEC.
There is currently a first attempt at specifying transparancy for
DNSSEC for those who want to audit/track the DNSSEC root or parent
domain holders:
http://tools.ietf.org/html/draft-zhang-ct-dnssec-trans-00
Paul
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
