[ietf-dkim] list expanders (was Re: chained signatures, was l= summary)
gmail.sant9442 at winserver.com
Tue Jun 16 13:28:21 PDT 2009
MH Michael Hammer (5304) wrote:
> So you are absolutely against 3rd party signatures unless the
> 3rd party broke a first party signature?
I have an long ethical engineering problem with designing and dealing
with any mail mover software that alters and/or the original intent of a
message. The 1986 US EPCA provisions help model the guidelines for
hosting systems. Keep in mind my view point is purely based on security
and technical consistency and the expectations of the message
author/owner. If the intent of the originating author and copy right
holder of the message was mail integrity and not necessarily message
owner authenticity, then I see less of a concern with a 3rd party (relay
or hop) changing the intent and final status as long as its persistent
and consistent. The chain of trust applies.
But if the intent of the originating author was both mail integrity and
authenticity, then I see a really high potential for security and
technical problems when there is no "Helper" involve to assist the 3rd
party and it just blindly alters the mail.
Assuming the status quo and direction of DKIM-BASE sans policy, I see a
less security problem when the original mail was signed and valid and
because of the inherent nature (BCP) of list servers today to alter the
messaging layer (presentation), it keeps the integrity of the altered
message intent intact by resigning. I see problems when the 3rd party
signs non-signed original mail when policy is still in the mind of this
project. If policy was completely out of the picture, then DKIM becomes:
A system and core protocol allowing a MTA domain (domain) take
responsibility for the
transportation of a message to the next MTA (Hop) .
The model is less focus on the Original Domain expectations for the
authenticity of the transport. The facebookemail.com post is a prime
example of the situation with blind list server or middle ware signings.
> My understanding has always been that anyone who handles a message can
> sign and thereby take responsibility (whatever that might mean) for the
> message they are signing.
Although this mindset has prevailed, it was not always like that Mike.
If it was the primary focus (i.e. policy was never a consideration and
out of the picture), then I believe we would long finished this project
. In the same vain, if people respected the charter out of scope
guideline for reputation, then possible Policy would of been resolved
and project over long again. :)
> I have to disagree Hector. For better or for worse, SSP was never
> an integral part of DKIM. It is layered on top of DKIM.
It was what sold us to even get involve. All original marketing and
presentations had SSP as a integral part of the framework. It was part
of the charter and and DKIM/SSP original specs was ONE document
(following Yahoo's Domainkeys specifications) before it was split.
> I'm surprised Hector. It really took you a second to decide it wasn't
Is 1 second good or bad? I did hit 1/2 century mark this year so I am
bit slower. :-)
No honestly, I wondered there for a moment if this was a new WG
participant organizing a wiki/social network DKIM resource. I just came
back from a NYC trip visiting daughter and attending Yankees/Mets game,
and all I heard this weekend was FACEBOOK this, FACEBOOK that. :-)
So I wondered if this was an spambot and if so, why wasn't it trapped
with the list subscription confirmation process.
More information about the ietf-dkim