Hi Amir,
Amir Herzberg wrote:
> Stephen Farrell wrote:
>
>>
>>
>> DESCRIPTION OF WORKING GROUP:
>>
>> The DKIM working group will produce standards-track RFCs specifying
>> how to
>> sign message headers based on domain name identifiers.
>
> Comments:
> 1. `sign message headers` - why only headers? don't we sign body anymore?
Yeah - I inherited that phrase from the Aug 22nd version. I tend to
agree, but maybe this is really some weasel words so we don't have
to start on about "l=" yoke up-front of the charter;-)
> 2. I think a main differentiator btw DKIM and S/MIME is that the
> signature itself is included as header fields and therefore transparent
> to non-DKIM recipients. I would actually think we should make this clear
> at this point (if not, later on, but I don't think this point is
> currently made at all).
Fair enough.
> 3. `based on domain name identifiers` - frankly, I'm not sure this is
> meaningful here. In what sense is the signature `based on domain name
> identifiers`? In truth, we plan a default key-lookup mechanisms using
> DNS, and of course DNS lookup is `based on domain name identifiers`, but
> you make this point very clear a few paragraphs below. Don't
> misunderstand: I think using DNS to distribute the PKs is a good thing,
> and should probably be indeed a part of the spec (as in the parag.
> below). But, as also indicated below, there are alternatives; and in
> such alternate cases, the use of domain name identifiers is not clearly
> necessary. In short, I simply suggest removing this suffix (`based on
> domain name identifiers`) as possibly over restrictive and not adding
> useful info beyond what's discussed below.
Good again.
So the opener would end up like:
The DKIM working group will produce standards-track RFCs specifying
how to carry digital signatures in mail message headers. Depending
on the options chosen these signatures can integrity protect (some)
message headers as well as (parts of) the message body.
That better?
Frankly, I think this is a huge step backwards. You're changing the charter
from discussing the goals of the service we're trying to define to discussing
the details of the mechanisms we use to build the service. IMO this is going
down a path that is likely to cause far more problems than it solves, as it
invites confusion with efforts to define very different services using similar
mechanisms.
Like it or not, the mechanisms DKIM is compelled to use have a considerable
degree of overlap with those used to build very different services. (In fact I
have previously remarked that I wish there was some other mechanism than a
digital signature we could use here because of all the semantic baggage that's
attached to the notion of "signature").
The existing charter was careful to distinguish between service and
mechanism. Let's please try and keep that distinction.
>> - signatures which are intended to make long-term assertions
>
> Huh? Maybe `specific support for signatures so they remain valid for
> long terms`?
I think I prefer my version of this. Maybe we could make a reference
to ltans which is exactly the kind of thing we don't want to do?
>
>> - signatures which attempt to make strong assertions of the
>> real-world identity of any entity
>
> Huh? Again, maybe `specific support for signatures so they make strong
> assertions of the real-world identity of any entity`?
Again I prefer mine. Could go with yours too though.
>> ? duplication of other secure mail protocols (S/MIME, PGP)
>
> Well, since DKIM _is_ an alternate signature mechanisms for email after
> all, how about simply adding S/MIME and PGP to the list of groups we
> will try to avoid duplicating their work (previous bullet)? We may even
> want to be again explicit on the main difference (i.e. that DKIM
> signatures are in header fields ignored by non-DKIM mail agents)
DKIM is _not_ an alternate signature service, and that's precisely the point.
DKIM only uses signatures as a means to an end, and the end is not to provide a
nonrepudiatable signature covering the message. Rather, it is to provide a
means whereby someone can assert responsibility for a message. This is a type
of authorization service, not a signature service. We are forced to use digital
signatures as a mechanism because the service has to deal with forgery and
replay attacks, but that's an (unfortunate) implementation detail.
Ned
_______________________________________________
ietf-dkim mailing list
http://dkim.org