At 01:33 AM 7/18/2004, Amir Herzberg wrote: I don't see here any problem or attack. Indeed, there is difference between signature in the crypto sense and legally-binding signatures. The later are defined in one of two ways. One is by the `digital signature` laws in different countries/states; that approach if often problematic, since it is quite tricky to define in a general law a binding between a person or organization and a digital signature. The other way however is fine, imho: define the digital signature in a (`regular`) contract between the parties. The contract defines what the parties agree to be considered as equivalent to their (physical) signature, with well defined interpretation and restrictions. ...
the digital signature laws, for the most part, defined how a certification authority went about binding the owner of a public key (or at least the entity presenting a public key and a digital signature that could be verified by that public key) and some other information ... and presenting that in a certificate. However, I don't remember seeing any of the e-sign laws a) defining a non-repudiation environment that is mandated for signature digital signing environments (indicating that the key owner has read, understood, and approves, agrees, and/or authorizes the contents of the message and b) as part of the integrity of the message, there is proof that such a non-repudiation environment was used.
1)
the relying party being able to certify the integrity level of something like a hardware token .... for use in "something you have" authentication .... aka the relying party verifies a digital signature and that verification may used to imply "something you have" authentication (at this point there is absolutely nothing involving a certificate). However, in order for the relying party to be able to assume or imply what the verification of the digital signature actually means .... and therefor how much it can trust the verification ... it needs to know how the private key is maintained and operated. If the act of "verifying a digital signature" actually means or implies that it is "something you have" authentication ... then it needs to have some certification along the lines that the private key is used and maintained in a hardware token with specific characteristics. It has nothing at all to do with any certificate traditionally mentioned in various kinds of e-sign laws.
2)
during the early '90s, the identity certificates tended to be overloaded with all sorts of identity and privacy information. this was fairly quickly realized to represent serious privacy and liability issues. this was retrenched to things like relying-only-party certificates that basically only had a public key and some sort of account identifier (which could be used by the relying-party to pull up the real information .... w/o having it publicly broadcast all over the world). However, there were also things like "non-repudiation" bits defined in certificates ... that have since been severely depreciated. During the mid-90s there were some infrastructures being proposed that if you had some data which had an appended digital signature and an appended certificate containing a non-repudiation bit .... then the burden of proof (in disputes) could be shifted from the relying party to the signing party.
This was vulnerable to possibly two exploits
a) the digital signer had believed that they had signed random data as part of an authentication protocol ... as opposed to having signed some document contents indicating agreement, approval, and/or authorization (as in real live signature .... aka the dual-use scenario) and/or
b) since the appended certificate isn't part of the signed transaction .... the relying-party might be able to find a digital certificate (belonging to that key-owner for the same public key) that had the non-repudiation bit set and substitute a non-repudiation certificate for the certificate that the key-owner had actually appended (aka the certificate is not part of the integrity of the message covered under the digital signature).
3)
at the NIST PKI workshop a couple months ago .... there were a number of infrastructure presentations where various entities in the infrastructure were
a) signing random data as part of authentication protocol (where the entity performing the digital signature was given no opportunity to view the contents being signed) they were using hardware token implementation .... and they were assuming that the verification of the digital signature implied some sort of "something you have" authentication. however there was nothing in the infrastructure that provided certification and/or proof that the private key was kept and maintained in a hardware token .... so there was no proof as to the level of integrity and/or level of trust that the relying party could place in the verification of that digital signature
b) signing authorization documents (using the same tokens that were used in the authentication protocols)
However, there was no distinguishing and/or provable characteristics that were provided which a relying-party could use to distinguish between (random) contents that were signed as part of an authentication protocol and (authorization) contents that the relying-party could assume to indicate that the signer was agreeing, approving, and/or authorization what was indicated by the contents of the document.
Since there was no proof provided to the relying-party as to the environment and conditions under which the signing actually occurred .... then a dual-use attack is for non-random contents (aka some sort of authorization document) to be injected into an authentication protocol .... under the assumption that the entity performing the digital signature will never look at the contents. Then such digitally signed contents can be used in an approval, agreement, and/or authorization scenario to imply that the entity performing the digital signature was actually approving the contents of the document.
4)
this now verges into various of the non-repudiation definitions and threads that have occurred in the past. in effect, for any kind of infrastructure where the digital signature is being used to imply that the entity responsible for the digital signature agrees, approves, and/or authorizes what is in the content of the message being signed (as opposed to some random data being signed as part of authentication protocol and is never viewed) ... there has to be some additional signing environment (demonstrating that the signer has actually read, understood, and agrees with the contents) ... and the proof of the use of such a signing environment infrastructure has to be carried as part of the integrity of the message .... in order for the relying party to rely on it being a real "signature signing" event ... as opposed to have really originated from a authentication protocol where the person believed that random data was being signed (and never actually viewed the contents being signed). Note that not only does such an non-repudiation signing environment has to have been used .... but the proof of its use has to be carried as part of the integrity of the message (in order for the relying party to distinguish between random data being digital signed and the person having signed after viewing the contents, understanding the contents and approving, agreeing, and/or authorization what was indicated by the contents). So it isn't just that a non-repudiation environment has to be used for signing operations (as in human signature) ...but the proof of such non-repudiation environments have to be carried as part of the integrity of the message .... to differentiate from a dual-use attack where the signing is believed to be random data and the person never views the contents.
5)
other kinds of infrastructure implementations may be to have two completely different hardware tokens with two completely different public/private key pairs.
the hardware token used for authentication protocols doesn't concern itself with the contents of the data ... in fact it always appends a disclaimer to all random data (that it signs) stating that the digital signature cannot be used to imply any agreement, approval, authorization and/or any obligation on the part of the token-owning entity.
the hardware token used for authorization, agreement, and/or approval signing events will never perform a digital signature operation unless it first senses that the token owner has read, understood and approved of the contents.
all protocols indicate as part of the hardware token interaction, which type of digital signature will be performed ... and the owner of the hardware tokens is then instructed appropriately when hardware token swapping needs to occur.
========= random past posts about non-repudiation:
http://www.garlic.com/~lynn/aadsm10.htm#cfppki15 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#cfppki18 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#paiin PAIIN security glossary & taxonomy
http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#8 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#12 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
http://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#15 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm12.htm#5 NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm12.htm#12 TOC for world bank e-security paper
http://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#37 Legal entities who sign
http://www.garlic.com/~lynn/aadsm12.htm#38 Legal entities who sign
http://www.garlic.com/~lynn/aadsm12.htm#59 e-Government uses "Authority-stamp-signatures"
http://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
http://www.garlic.com/~lynn/aadsm14.htm#47 UK: PKI "not working"
http://www.garlic.com/~lynn/aadsm14.htm#48 basic question: semantics of "map", "tie", etc in PKI
http://www.garlic.com/~lynn/aadsm15.htm#32 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#34 VS: On-line signature standards (slight addenda)
http://www.garlic.com/~lynn/aadsm15.htm#35 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm16.htm#11 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm16.htm#13 The PAIN mnemonic
http://www.garlic.com/~lynn/aadsm16.htm#14 Non-repudiation (was RE: The PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm16.htm#17 Non-repudiation (was RE: The PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm16.htm#18 Non-repudiation (was RE: The PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm16.htm#23 Non-repudiation (was RE: The PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm17.htm#3 Non-repudiation (was RE: The PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm17.htm#5 Non-repudiation (was RE: The PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm17.htm#55 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
http://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#43 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#46 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#50 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#51 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#52 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#38 distributed authentication
http://www.garlic.com/~lynn/2002f.html#35 Security and e-commerce
http://www.garlic.com/~lynn/2002g.html#37 Security Issues of using Internet Banking
http://www.garlic.com/~lynn/2002g.html#69 Digital signature
http://www.garlic.com/~lynn/2002h.html#68 Are you really who you say you are?
http://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman schema belong to Public Key schema family?
http://www.garlic.com/~lynn/2002i.html#77 Does Diffie-Hellman schema belong to Public Key schema family?
http://www.garlic.com/~lynn/2002j.html#24 Definition of Non-Repudiation ?
http://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
http://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce using POWF
http://www.garlic.com/~lynn/2002n.html#16 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002n.html#19 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2003.html#19 Message (authentication/integrity); was: Re: CRC-32 collision
http://www.garlic.com/~lynn/2003.html#29 Message (authentication/integrity); was: Re: CRC-32 collision
http://www.garlic.com/~lynn/2003f.html#37 unix
http://www.garlic.com/~lynn/2003h.html#29 application of unique signature
http://www.garlic.com/~lynn/2003h.html#38 entity authentication with non-repudiation
http://www.garlic.com/~lynn/2003i.html#35 electronic-ID and key-generation
http://www.garlic.com/~lynn/2003i.html#36 electronic-ID and key-generation
http://www.garlic.com/~lynn/2003j.html#47 The Tao Of Backup: End of postings
http://www.garlic.com/~lynn/2003k.html#6 Security models
http://www.garlic.com/~lynn/2003m.html#38 Questioning risks of using the same key for authentication and
http://www.garlic.com/~lynn/2003o.html#22 securID weakness
http://www.garlic.com/~lynn/2003o.html#29 Biometric cards will not stop identity fraud
http://www.garlic.com/~lynn/2003p.html#4 Does OTP need authentication?
http://www.garlic.com/~lynn/2003p.html#11 Order of Encryption and Authentication
http://www.garlic.com/~lynn/2003p.html#17 Does OTP need authentication?
http://www.garlic.com/~lynn/2004e.html#20 Soft signatures
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]