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.
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).
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"
3.Chapter with "minimal changes deemed useful to improve the viability
of services that are based on these specifications" is not acceptable
to me. 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.
Removing this sentence all together or removing word "minimal" and
replacing it with "all necessary" would help.
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".
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.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net