Thanks for persevering Phill,
Hallam-Baker, Phillip wrote:
From: Stephen Farrell [mailto:stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie]
Hallam-Baker, Phillip wrote:
Your restatement of my point misses the point entirely:
IF there is a signature that the recipient can use
I think you mean "IF there was ever a ..."
THEN the recpient should know that there is such a signature
and s/is such a/was ever such a/
But why? The consensus we have now is that the recipient
alone is able to figure what signatures it can use and that
that's enough. You've not explained why this is insufficient
(or I'm just even dumber than usual;-).
Stephen,
The missing use case here is that we decide to add to the set of algorithms
used by DKIM. Let us imagine that we are proposing a new canonicalization
algorithm. We need to have a use case describing this scenario in the
requirements document and a statement of the architectural and design
requirements that supporting this use case entails. Otherwise we will end up
yet again with another IETF specification that requires us to wait for the
entire installed base to change before we can deploy.
I agree that post-deployment changes to C14N have been common in
signature schemes, so if there're things we can do to make that
transition easier, that is a good goal.
Consider the following two policies:
X: "Every email has at least one signature"
Y: "Every email has a signature of type A and a signature of type B"
Now consider a recipient that only supports verification of signature type A.
Consider the following attack:
Bogus message with signature of type B.
This message is consistent with policy X, it is not consistent with policy Y.
This means that if our policy language can only express policy X it will not be
possible to tell the recipient the information it needs to know in order to
determine that the message is bogus.
Huh? The recipient doesn't support signature type B and will therefore
not consider the message signed. Same as if the message were an unsigned
forgery or a real unsigned message, or has been mangled etc. So I don't
see the benefit in the recipient finding out (via SSP) that the signer
does use B, if the recipient cannot (cryptographically) check that the
message is accompanied by such a signature and not just some random
bits in the correct format.
Furthermore as presently specified SSP means that if there is any key record in
the domain that specifies a signature algorithm that may not be supported by
every recipient it is possible to send forged messages.
It is always possible to forge messages. Our job here is to make
it relatively easy to do a good job verifying real ones.
The point is that the current policy language does not provide sufficient power
to allow a recipient to determine whether there should be a verifiable
signature present.
That is true, but I don't see it as a problem for the reasons
stated above.
The solution is to adopt the selector contraint mechanism I propose. This
allows signers to develop an orderly transition from one algorithm to another
whether it be canonicalization, hash or signature without the need to put any
information of that type into the policy record.
Your solution may be fine, but you've still not convinced me
(chair hat off etc.) about this being an SSP requirement.
Maybe others have thoughts on this, having read this thread?
S.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html