- ways to implement reputation and accreditation systems
Agree
- message encryption
Agree
- signatures which are intended to make long-term assertions
Agree
- signatures which attempt to make strong assertions of the
real-world identity of any entity
Agree
- duplication of work done by XKMS, PKIX
Strongly Agree
? duplication of other secure mail protocols (S/MIME, PGP)
Disagree:
This is exactly what we are doing in the signature area and we have
already said we will not do encryption so making this statement only
adds confusion
? supporting multiple signatures on single messages
Strongly disagree
It is very clear that there are multiple steps in the signature chain.
The intermediate steps cannot know which signature the relying party
will want.
Removing information from the message means that systems will break in
ways that cannot be fixed by intelligent receivers no matter how smart.
The core purpose of DKIM is to allow parties to accept responsibility
for email. Provided there is a means by which the parties can specify
the role under which they are accepting responsibility (distinguish
originator from forwarder for example) and there is a way to determing
the order in which the signatures were applied multiple signatures are
not a complexity issue.
? 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)
Aggree
However for end-user signing to be possible at any future date the
message infrastructure MUST be capable of accepting messages with
multiple signatures.
?? delegation of signing capabilities
Disagree
This is actually a show-stopper must have for the ESTG group. Most of
the commercial participants in the group use outsourced email senders
for at least some marketting campaigns. Third party signature capability
is actually a differentiator against SPF.
_______________________________________________
ietf-dkim mailing list
http://dkim.org