I think this mail from Phill captures most of the comments on
the scoping list:
? 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
Fair enough. My wording wasn't great. Maybe if we said something
like: "definition of signature data structures which are passed
in the body of the message" or something better.
? supporting multiple signatures on single messages
Strongly disagree
I'm convinced! But the spec (and threat analysis) then will then
have to explicitly cover this and it'll be a tricky feature to
get right to everyone's satisfaction so it could cause delay.
?? 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.
Well, in that case I want to see some charter text which stops us from
defining a full-blown authorization infrastructure. My intent was to
stop us from defining such a protocol to allow one to authorize
delegation, but that verifiers could of course recognize a delegation
if they so choose - its just that the protocol which informs the
verifier about the delegation wouldn't be part of dkim.
Delegation has always been a really, really tricky thing to get
right - how do I issue & revoke these delegations and who says
I'm allowed do so in any case? Do we really have an answer that's
in the end simpler than AAA or SAML or X.509 PMI? I doubt it. Can
we accept bare unsigned assertions about who should be signing
messages? I doubt that too. My answer: punt - have this feature
use some other authorization infrastructure.
How about something like this then, [...out of scope is:]
- protocols which securely provide information to verifiers
about valid delegations - where such functionality is needed
it should use local configuraiton or an existing authorization
infrastructure like AAA, SAML, or even X.509 based PMI, the
duplication of which will not happen in dkim
Stephen.
PS: Later today I'll try put together another version of a draft
charter which incorporates comments on that to date. We can merge
the various versions later in the week to get the best of the
bunch.
_______________________________________________
ietf-dkim mailing list
http://dkim.org