>> If you don't say this what's to prevent someone from writing an
>> implementation that only supports Camilla-MAC hashing and calling it
>> compliant?
I understand this concern but as a practical matter who would create a
signer knowing in advance that it would have trouble inter-operating?
Simple: Someone who wants to promote their private stuff and lock people in to
their solution. This happens all the time, especially in the crypto space.
Snake oil sells, sad to say. Rarely does a month go by that Bruce Schneier has
a "worthy" product to write up in his doghouse section, and often there are
several in there.
That would be silly and such a signer wouldn't be in use for very long
would it?
You'd be amazed at how long this sort of stuff can stick around once
someone commits it and releases it. Our customers often demand that
we support stuff that's in egregious violation of the relevant standards.
Leaving doors open so crap can claim to comply makes matters even worse.
So, I agree with Tony and don't see a particular problem with
adopting Dave's language even though it doesn't have a MUST for signers.
You don't have a problem with having an extremely rough time getting
through the process then, assuming you make it at all.
Isn't the MUST implicit by virtue of the requirements on the verifier
coupled with the assumption that the author of the signing software
desires to create something that's useful? Am I missing the point here?
The real question is why you're so opposed to making it a MUST. If in fact
you're right and every implementor will as a practical matter not create such
things, the MUST will cause no harm whatsoever. If, OTOH, I'm right we'll be
very glad there's a MUST in there.
Ned
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html