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?
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).
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.
<skip>
This is the relevant paragraph.
The public keys required for signature verification may be stored in, or
sourced via, the responsible identity's DNS hierarchy. In the case where the
keys are not directly sourced from the DNS, the working group will use some
existing key distribution technology (e.g. XKMS, SCVP, or DKIM-in-band key
distribution) and will not otherwise develop new key distribution protocols
for this purpose.
<skip>
The following are out of scope of the working group:
- ways to implement reputation and accreditation systems
Ok
- message encryption
Ok
- signatures which are intended to make long-term assertions
Huh? Maybe `specific support for signatures so they remain valid for
long terms`?
- 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`?
- duplication of work done by XKMS, PKIX
Sure.
? 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)
? supporting multiple signatures on single messages
I already said I support Phil - this should not be excluded, at least
not in charter...
? 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)
Agree
?? 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>
--
Best regards,
Amir Herzberg
Associate Professor
Department of Computer Science
Bar Ilan University
http://AmirHerzberg.com
Try TrustBar - improved browser security UI:
http://AmirHerzberg.com/TrustBar
Visit my Hall Of Shame of Unprotected Login pages:
http://AmirHerzberg.com/shame
_______________________________________________
ietf-dkim mailing list
http://dkim.org