Hi,
Hallam-Baker, Phillip wrote:
I don't think that we are re-opening anything here.
That's still not clear to me. But let's thrash it out..
I am not proposing to re-open base or to place any algorithm identifiers in the policy record.
But then you also say that you want the policy language to include
statements like "There is a signature present of type A", so how is
"A" not an algorithm identifier?
> In fact quite the opposite. My reading of the requirements as written
is that they suggest that the policy record should enumerate the
acceptable signature algorithms. That is the opposite of what I want.
My position is that every key record, by its very existence indicates an
acceptable signing profile.
Sure. Acceptable to the signer.
Where we disagree is that I believe that it is necessary for the policy
language to specify that multiple signatures are present meeting different
selector matching criteria.
I don't see that yet.
This is not a repeat of any closed issue since the response each time in the past has been 'this is not currently in scope because it is policy'. Ergo the issue cannot be closed because it was never open.
Sophistry. Whatever.
The requirement is that the policy language be able to state:
"There is a signature present of type A" AND "There is a signature present of type
B".
Give me an example of "A"?
If a verifier finds a signature present that is 1) valid and 2) meets their
security requirements the message is considered to be authentica and no further
checking is required.
Yes. I think that that's clearly agreed.
Where a difference is made is in the behavior when a signature is found that
does not meet the verifier's security requirements, either because the
algorithm is unsuported (upgrade attack) or because the algorithm is considered
compromised (downgrade attack). In these cases the verifier MUST pull the SSP
record even though a signature is present because the signature that is present
is not one that the verifier can use.
I believe that the rough, (not total), consensus now is that the
verifier treats that as if no signature were ever present.
I do not believe there is anything like consensus that verifiers
should/must have a list of downgraded algorithms, or that verifiers
should/must remember algorithms that they used to, but no longer,
like. So I don't see that verifiers see upgrade/downgrade
distinctions - they just see some nonsense bits that are not a
signature (from the verifier p-o-v).
So the verifiers pulls SSP because there is, effecively, no
signature present.
And then the signer's SSP (if it exists) says whatever it
says.
And I don't see the threat resulting - what exactly is it?
Since we will not be specifying compromised algorithms initially the only code
path that requires implementation is what to do when you have a signature
present that you do not support. We absolutely do need to have a mechanism that
allows the verifier to know that it should expect there to also be a signature
that it can use.
Again, I'd like to see the threat called out. I don't sse it.
The spec is broken without this.
That's not clear to me,
Stephen.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html