These are comments in regards to chapter version posted at
http://www.mipassoc.org/mass/mass-charter-05dc.txt
I believe chapter should address dns and other issues raised, in
particular I think as part of the chapter you need to have:
1. DNS
I prefer to have sentence "Keys will be stored in the responsible
identity's DNS hierarchy." removed.
I prefer for it to be retained.
Whether or not it is removed I think a separate document is necessary
to address dns associated issues, threats and impact of proposal on dns
operations. I believe this should be spelled out something like "DNS
operations threats and impact on dns infrastructure will be added by
separate document worked in consultation with DNSOP and DNSEXT WGs"
(sorry, I'm not good at wording it into proper ietf-chapter language).
A separate document might be appropriate if the amount of material involved
is sufficiently large. I have seen no indication that it is of sufficient
size. Regardless, this can be dealt with in due course, there is no need
to add a requirement for a separate document to the charter.
2.Chapter says that the only interest is to address signing of message
header fields (BTW - you need to replace "headers" with "header
fields" if you want to be consistent with usage in other IETF
documents). You also say nothing about identity that you want to
have authorized. I think you need to mention that specification will
"address signing of message data and its header to permit authorization
of message sender's identity fields based on their domain values"
Both of these changes seem appropriate IMO.
3.Chapter with "minimal changes deemed useful to improve the viability
of services that are based on these specifications" is not acceptable
to me.
I, OTOH, find it totally unacceptable to remove this language entirely. Without
this language the chances are excellent the group will rathole and never
produce anything. Of course I'm biased about the current language since I'm the
one who came up with part of it, but I think it strikes the right balance
between allowing necessary changes and disallowing superfluous introduction of
unnecessary alternatives.
This is almost same as before before and is basically "stamp of
approval" type of chapter and does not leave much for IETF WG to do.
Well, I for one would love it if there was little to do. I don't think
that's the case, however. Mind you, I think the DKIM specs are already
a lot better than what most WGs start with, but a fair amount of work
is still needed.
Removing this sentence all together or removing word "minimal" and
replacing it with "all necessary" would help.
I guess I could live "all necessary", but I much prefer "minimal".
4.I believe you need to permit working on multiple authorization
protocols. Make it something like "The group will look at multiple
authorization methods including dns and http based key retrieval
or key authorization methods and choose minimum list required for
initial deployment. Additional optional methods may also be addressed
by separate documents to be completed after initial specification."
Possibly also add "The group will look into interaction of proposed
authorization methods with deployed PKI X.509 and OpenPGP
infrastructures".
I am sympathetic to wanting to define additional mechanisms, if only to
insure that implementatiosn actually allow for them in the future. However,
the proposed text here goes much, much, much too far.
5.You need to make sure that signature would survive during mail transport.
I'm not entirely sure of the text but something like that the signature
will use form and develop canonicalization method that allows it to
survive during email transport from sender to recipient would help.
This is sensitive issue, but I do not believe what you have right now
is good as for example DKIM signature would not survive if original
email message already had PGP/MIME or S/MIME signature and the message
went through mail list. This must be addressed.
I support noting this as a WG meta-deliverable in the charter.
Ned