Hi Hector,
I *think* I tend to agree with you. Do you have some charter-text
which'd capture that and could replace the delegation bullet? (And
which allows us to get done in <4 years, which is how long it'd
take to define yet another delegation scheme properly:-)
Ta,
Stephen.
Hector Santos wrote:
----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
The following are out of scope of the working group:
? duplication of other secure mail protocols (S/MIME, PGP)
IMO, this is "apples and oranges." While we can learn from similar possible
issues, the "twain shall never meet."
? supporting multiple signatures on single messages
? specifying user level signing and/or verificaiton of messages
(though support for this in future may be a goal of this or some
other working group)
?? delegation of signing capabilities
I am not entirely sure what exactly you have on your mind here, but it
sounds like these three items are all related.
I view the #1 threat to DKIM is having a lack of SSP validation assurance.
A good analog is the #1 problem in SMTP that got the industry into trouble
in the first place; presentation of SMTP process entities where the server
has no requirement for checking. i.e. client domain name (HELO/EHLO) and the
return path (MAIL FROM).
To me, the #1 barrier to DKIM adoption and/or utilization will be the lack
of SSP validation by DKIM verifiers and/or 3rd party DKIM resigners. The
overhead concerns regarding SSP validation should not open a DKIM "loop
hole" threat vector.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org