[mailto:owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Arvel
Hathcock
Separately we need to modify the policy document so
that the signing policy can state the q= options that
may be contained in a signature.
Here you are moving beyond the realm of the optional I think.
Making the extension mechanism work is not an optional work item for the
WG as the AD has already stated in the security review:
"Neither DomainKeys nor IIM makes use of certificates. The goal is
to
start with something simple; something that does not dependent on the
deployment of an infrastructure. The question is: what is simple
enough? The solution needs to be complex enough to support the
evolution to a supporting infrastructure; however, there are also
concerns with incrementally adding things. One must ensure that the
final architecture is not more complex than deploying an
infrastructure from the beginning."
"Overall complexity must be considered. Enhanced deployment may be a
reasonable justification for incrementally developing technology.
Minimizing specification time at the cost of deployment complexity is
not such a justification."
Additionally, this move would require a policy lookup on each
signature
check in order to determine what q= values were acceptable
wouldn it not?
No, the rules are just the same as before. You ONLY need to check the
policy record if:
* There is no signature on the message
* None of the signatures present can be verified by the receiver
* The message has been modified
* The signature format is not supported
The last condition could be because:
* The signature uses an unsupported algorithm
* The signature uses an unsupported key retrieval mechanism
* The signature uses an unsupported canonicalization mechanism
These are all problems that the policy mechanism MUST solve. Consider:
"Nieither DomainKeys nor IIM does a good job specifying the
Cryptographic algorithms. Both require RSA (probably the PKCS#1
version 1.5 variant) and SHA-1. This is a fine choice, but the
specification needs to handle other algorithms too. It is not clear
how one would migrate to ECDSA with SHA-256, for example."
The policy record needs to allow the sender to describe their signature
policy in sufficient detail that the lack of a signature header that
complies with the policy can be understood to indicate a forgery.