[ietf-dkim] Charter bashing...

[Amir Herzberg]

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