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?
- 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)
See earlier mail in response to Phill.
? supporting multiple signatures on single messages
I already said I support Phil - this should not be excluded, at least
not in charter...
Done.
>> ?? delegation of signing capabilities
Again, I agree with Phil: delegation may be important for some scenario,
we should not exclude it off-hand at the charter.
<no further comments>
See earlier mail in response to Phill.
Cheers,
Stephen.
_______________________________________________
ietf-dkim mailing list
http://dkim.org