[Top] [All Lists]

Re: [Asrg] 6. Proposals - DNS + PKI - Yahoo's "Domain Keys"

2003-12-08 20:59:21
Hector Santos wrote:

Keep in mind that this proposal will only work if the RFC specifications are
clarified due to one its central criteria.  Quoting Yahoo:

"If the receiving system can decrypt that private key with a public key
registered by the Internet's Domain Name System, then it will be assumed the
message is authentic. If it can't, the message is bounced back from whence
it came."

Therefore, like other proposals, if the bounce system is not reliable or
considered or interpreted as "optional", then there can only be one
assumption to be made; throw the message away.

In other words,  what will be the RFC guidelines on handling an unreliable
or incomplete bounce due to a failed decryption of a private key?

I would not rely on their press releases or news stories based on their press releases until concrete specs for their proposal is released. I would assume their "bounce" here is referring to the industry standard way of doing bounces today, not anything esoteric.

In essence, the baseline compliance for this proposal is two MUA systems.
The middle ware is not really required.  However, trust increases as a 3rd
party component is involved in the validation process.

If a compliant MUA sender is used,  does the SMTP route have a role of
validating the key or simply pass it on to the final destination?

If a non-compliant MUA sender is used,  where in the SMTP process does it
add the private key? or does it?

This proposal is specifically geared toward MTA signing messages, NOT MUAs. Trust between the MUAs and MTAs is accomplished via SMTP AUTH, and then the MTA signs the message before it is sent out. While it can be done through the MUAs, based on all information that is available to us, it is done on MTA level.


Yakov Shafranovich / asrg <at>
SolidMatrix Technologies, Inc. / research <at>
"Why are both drug addicts and computer aficionados both called users?" (Clifford Stoll)

Asrg mailing list

<Prev in Thread] Current Thread [Next in Thread>