There is a (no-so-) subtle difference between one originator signing
twice, and two originators signing in some groupware application.
I can see the difference. I maintain that two signatures by the same
entity introduce the possibility of semantic confusion; one need not
consider the more complicated case of multiple signers.
that there are two bit strings to
facilitate two levels of system assurance, or to cater for two
different crypto communities is not an issue.
But the very fact that there are two bit strings leads to the possibility
that the verifications of the two may not have the same result. Hence
the possibility for confusion, for ambiguity in the result.
There must be only one
DN, only one identity and therefore only one I&A decision for use by
authorization enforcement logic.
The I&A decision is based (not solely) on the MIC information. The
fact that there may be two different MICs on which an I&A decision can
be based provides for ambiguity, whether or not there is just one DN.
(To be truthful, from discussions on this list in the past, I think
your "one DN, one identity" statement is contraversial -- there are others
who may speak to that (surely Bob Jueneman has spoken about DN's for
different roles?) better than I -- and does not consider mailing lists, for
one).
If your signer spans multiple authentication domains, then obviously
any one recipient may as well. There may be two MICs which the recipient
can verify. What does the recipient do if the results are different?
Like Ned, you are redefining terms, and of course can then find
contradiction in the meaning.
I don't know what you mean here. What in my posting do you believe
redefines some term? (And which term?)
You played with the authentication
semantics; now you are getting burned.
I played with no semantics; I only pointed out a feature that is
provided in the RFC 1421 spec. And I assure you that I do not feel
heat in the least.
--Sandy