In SSL and TLS, the client isn't signing random data provided by the adversary. Rather, the client is signing a value derived from data both the client and server provide as part of the handshake. I do not believe it is feasible for a malicious server to choose its nonces so that the resulting signature be coincide with a valid signature on a delegation cert the client might have constructed.
the issue in the EU FINREAD scenario was that they needed a way to distinguish between (random) data that got signed ... that the key owner never read .... and the case were the key owner was actually signing to indicate agreement, approval, and/or authorization. They specified a FINREAD terminal which supposed met the requirements that the key owner had to have read and to some extent understood .... and approved as to the meaning of the contents of what was being signed.
However, the FINREAD specification didn't define any mechanism that provided proof to the relying party that a FINREAD terminal was actually used as part of the signature process.
Some of the non-repudiation service definitions also talk about processes that would provide high likelyhood that the person performing the signing has read, understood, and agrees with the contents of what is being signed. However, many of them fail to specify a mechanism that proves to a relying party that such a non-repudiation service was actually used.
so the dual-use attack .... is if a key-owner ever, at any time, signs something w/o reading it ... then there is the possibility that the data being signed actually contains something of significant.
if there is never any proof, included as part of the integrity of the message ... that proves to the relying party that some sort of non-repudiation environment was used as part of the digital signing .... then it falls back on requiring an exhaustive proof that never in the history of the private key was it ever used to sign contents that were unread and could possibly be random.
it isn't sufficient that you show there is some specific authentication protocol with unread, random data ... that has countermeasures against a dual-use attack ... but you have to exhaustively show that the private key has never, ever signed any unread random data that failed to contain dual-use countermeasure attack.
the alternative to the exhaustive proof about every use of the private key .... is strong proof (that is built into the integrity of the signed contents) that non-repudiation environment was used for the digital signing (strong implication that the key owner, read, understood, approves, agrees, and/or authorizes the contents of the message).
the NIST scenario for a exhaustive proof ... rather than exhaustive proof about every use of a specific private key .... would be able to show that it is impossible to use the private key in any protocol not written by the people making the presentation
this came up in a SET discussion long ago and far away. it was about whether there was every any SET gateway protocol that could set the "signature verified" bit in the ISO 8583 message. One of the SET vendors claimed that the software they shipped was certified that it would never set the "signature verified" bit in the ISO 8583 message, if the signature hadn't actually been verified (and therefor there wasn't an infrastructure vulnerability). The problem was that they had created an infrastructure that didn't require end-to-end proof of the signature verification ... and they were unable to control that every ISO 8583 generated message .... was certified as only being able to be generated by their code. They had created an infrastructure vulnerability .... that allowed a wide variety of software to be used .... and was only safe if they could prove that every copy of code generating every ISO 8583 messages was their code and it was impossible to modify and/or substitute something else in the generation of an ISO 8583 message.
The countermeasure to the seriously flawed SET design requiring exhaustive proof that every ISO 8583 message that was ever created that carried the "signature verified" bit .... could have only been created by unmodified, certified software .... was to support end-to-end authentication. .And for a slight drift ... that wasn't practical in the SET design because the inclusion of a certificate would have represented horrendous payload bloat of two orders of magnitude (discussed in some detail in recent posts to another thread in this mailing list)
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
