another characteristic of the PKI x.509 identity certificate activity (besides attempting to create mass world-wide confusion regarding the difference between identification and authentication ... and trying to get govs. to mandate that x.509 identity certificates, grossly overloaded with personal information had to be appended to even the most simple of authentication transactions) .... was trying to cause a great deal of confusion about the difference between *digital signatures* and *human signatures*. some of this possibly was semantic confusion because both of the terms; *digital signature* and *human signature* contain the word *signature*.
nominally a digital signature is the use of a private key to encode a message/document hash. the relying party then recalculates the message/document hash, uses the corresponding public key to decode the digital signature, and compares the two hash. if they are equal, the relying party assumes: 1) the message/document hasn't been altered (since the digital signature) 2) "something you have" authentication, aka the originator has access and use of the private key. the base technology is asymmetric key cryptography (what one key encodes, the other key decodes). the business process of public key, identifies one key as publicly available. the other key is kept confidential and never divulged. the integrity of "something you have" authentication can be improved by deploying secure hardware tokens where the key pair are generated in the token and the private key never leaves the token (improving the probability that the private key is never divulged). now, normal *human signature* implies read, understood, agrees, approves, and/or authorizes. The normal *digital signature* is purely a "something you have" authentication process implying none of the characteristics of a *human signature*. In fact, a series of my pasts posts on *dual-use attacks* was specifically with using the same private key to apply digital signatures to random data (as part of authentication operations) and digital signatures to non-random data (assuming human signature characteristics). Somewhat in support of helping create world wide confusion about the differences between *digital signatures* and *human signatures* (in addition to creating world wide confusion about the difference between authentication and identification), the PKI x.509 digital certificate standard also defined a non-repudiation bit. For some number of PKI-oriented payment protocols in the mid-90s, there was the specification of digital certificates with the non-repudiation bit turned on. Supposedly, if a merchant could demonstrated any valid digital certificate with the "non-repudiation" bit turned on (for the customer's public key), then the burden of proof in any dispute would have shifted from the merchant to the consumer. The threat/vulnerability was 1) the PKI-oriented protocols provided no mechanism for proving which certificate had been originally attached to the transaction 2) supposedly the "non-repudiation" bit was capable of turning any digital signature operation (regardless of the environemnt in which the signature had been performed) magically into a *human signature* carrying the attributes of read, understood, agree, approve, and/or authorized. So the PKI x.509 identity digital certificates were targeted at 1) turning every transaction in the world (even the most trivial authentication operation) into a heavy duty identification operation (with attached x.509 identity digital certificates carrying enormous amounts of personal information) 2) allowing anybody that could produce a valid digital certificate (for the associated public key) with the non-repudation bit on, to magically turn all associated *digital signatures* into *human signatures* (even digital signatures that had been presumably been performed on random data for purely authentication operations). since that time, the use of the certificate-based "non-repudiation" bit has been severely depreciated (many people coming to realize that it takes more than magical PKI bits to turn *digital signatures* into *human signatures*). there were some that started to realize that the PKI x.509 identity certificate model represented severe privacy and liability issues. The initial quick&dirty fix were the relying-party-only certificates http://www.garlic.com/~lynn/subpubkey.html#rpo containing just public key and some sort of database lookup index. The issue here is that it is trivial to demonstrate that such relying-party-only certificates are redundant and superfluous .... if the relying party already has all the information, then the relying party can directly look up the necessary information (including registered public key as well as all integrity characteristics that might be associated with that public key ... and the last thing they need are redundant and superfluous relying-party-only digital certificates). --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]