On August 10, 2005 at 07:32, Dave Crocker wrote:
DKIM violates basic software design principles.
As noted, DKIM is a protocol specification, not a software design.
Same engineering patterns apply to both.
For example, computing a cryptographic hash of mail message data (includin
g
canonicalization methods) in itself is a useful capability.
Since DKIM has a number of parametric components, including canonicalization
and
signature algorithm choices, I do not understand what additional factoring yo
u
are concerned about.
Why should the generation of a message-header-based signature be
tied to a key management system? The cryptographic standards do not
do this. The method for creating digital signatures is independent
of any key management system.
RFC-1847 is good example of what I am talking about, and I
think any header-based signature effort could follow the same
pattern.
It sounds as if the main concern is about splitting things into separate
documents, rather than changing the architecture or specification.
Splitting things up is a nicety, but not essential (as I noted in my
previous message).
Resolving the charter and producing a threat analysis are our tasks right now
A diversion, necessary diversion, but a diversion from the arguments
I am attempting to make.
--ewh
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim