Perry E. Metzger wrote: > Far better would be to have a token with a display attached to the > PC. The token will display a requested transaction to the user and > only sign it if the user agrees. Because the token is a trusted piece > of hardware that the user cannot install software on, it provides a > trusted communications path to the user that the PC itself cannot.
this is also the EU finread standard http://www.garlic.com/~lynn/subpubkey.html#finread which has a certified display and certified pin-pad. it was for token reader external to the PC ... so that what is displayed is what gets signed ... and the PIN entry isn't easily compromised. This still somewhat assumed standard 7816 card w/o its own display and pin-entry. the issue in x9.59 design http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/subpubkey.html#privacy was that it was possible for the relying party to get certified integrity information about the hardware token at the time the public key was registered .... and recheck that certified integrity information (binding to the public key) on every digitally signed transaction ... the EU finread standard didn't provide for the similar level of assurance. x9.59 allowed (but didn't mandate) that the environment, in which the signing took place, could also digitally sign the transaction. this could provide the relying party a binding not only between the integrity of the token doing the digital signing .... but also a binding between the environment that the digital signing took place and the integrity of that binding. The base EU finread terminal scenario provides for a standard for high integrity digital signing environment. However, it doesn't provide for any proof to the relying party that such a terminal was actually used for any specific transaction. Having the public key of the EU finread terminal registered along with the associated certified integrity level of that environment .... then if such a terminal was also to digitally sign the transaction, the relying party could do some risk assesement both on the integrity of the token performing the digital signing (for authentication purposes) and the integrity of the signing environment (terminal). If the display, pin-entry, and authentication token were tightly bound in the same device .... then when the relying party registered the public key for authentication purposes .... they would also register the associated integrity characteristics of the hardware token (for authentication purposes) as well as the display and pin-entry (for integrity related to the signing environment). The issue here is that the relying party is fundamentally interested in the overall risk of the transaction ... which is composed of a lot of individual integrity characteristics. Relating this to the old style x.509 identity certificate .... grossly overloaded with personal information .... a relying party ... can have done an authentication binding regarding the public key (i.e. don't necessarily need to have the identity of the person .... such know that the authentication indicates the entity is the one that is authorized to performed the related operations .... w/o having across the line from auhentication into identification and grossly confusing the difference between the two). One the relying party has done the straigth-forward authentication binding for a hardware token and a public key .... the really interesting charactistics for the relying party is all the integrity characteristics surrounding a transactions. To some estent, the PKI identity-centric focus have tended to distract relying parties from the more fundamental risk issues regarding integrity characteristics of performing the transaction. One an entity is registered as enabled for performing valid transactions (which can be a purely authentication operation w/o getting grossly confused about the difference between authentication and identification), then issues of certification interest to a relying party are the integrity characteristics of the authentication events (and the enormous concentration by PKI bodies on confusing identification with authentication tends to be a pure distraction to the risk assesement of the operations). --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
