At 08:45 AM 7/8/2003 -0700, Fritz Schneider wrote:
        This is possibly a silly question, but here goes.
        Reading something PKI-related the other day I was wondering about
the semantics of different kinds of certificates.  One usually says that
traditional id certs "map names to keys" or "tie keys to names"[1].  This
is usually written:

name -> key

Other certs have similar semantics (they "map" and "tie").  For example,
in order to achieve authorization one could keep an ACL which "maps
permissions to names" ("ties names to permissions"):

permission -> name

Given these two mappings its then possible to get the mapping:

permission -> name -> key

which authorizes the key for the permission.
        I actually have two questions.
        The first is what exactly does "mapping" mean in this sense?  I'm
not sure that it means "mapping" in the sense of the algebraic definition
because for each x that is mapped, there should only be only one value to
which x is mapped, and I think of an ACL or SPKI cert as incompatible with
this notion.  "Tie" and "bind" seemed to be used in to indicate both a
mapping or that something is mapped to.
        My second question is, in mappings like:

permission -> name -> key

why do we think of it as mapping permission to a key and not the other way
around?  The way I typically think about the task of reasoning about
authorization seems to work in the opposite direction.

-- fritz

[1] RFC2693, for example

basic authentication taxonomy is something like:


1) something you have (like a hardware token)
2) something you know (like a pin/password)
3) something you are (like biometrics)

frequently PKIs talk about certifying (aka CA's are certification authorities, certificates represent some certification by a certification authority) some binding between something and a public key.

one could claim that the choice of vocabulary was trying to elevate something from straight-forward authentication to something like identification and non-repudiation ... which would represent much more value and therefor the public key owner buying the certificate might pay more. Note, however, identification and non-repudiation is primarily of benefit to the relying-party that receives the certificate .... but the standard TTP business model has the private key owner paying for the certificate (not the relying party .... which is receiving the primary benefit).

There has been lots of discussion that PKIs don't actually do identification or non-repudiation which requires lots of additional processes.

Certification authorities basically have an entity prove that it can generate a digital signature that can be validated with the supplied public key ..... basically a form of "something you have" authentication ... the entity can prove it has the private key. The certification authority then validates some other piece of information (like the entity's email address); stores the public key and the certified information in a database and then creates a credential/certificate as to the binding between the certified information and the certified public key.

Originally, x.509 specification was thought of as heavily overloading a certificate with lots of identity related information as well as privilege/permission related information ... "bound" to a public key in a certificate. It pretty quickly became apparent that a credential/certificate heavily overloaded with identity and permission information and indiscriminately broadcast all over the world created enormous privacy problems.

Financial institutions in the mid-90s dropped back to relying-party-only certificates which basically contain only account number and the public key because of the enormous privacy and liability problems. However, a standard business process involving certificate has the key-owner 1) creating a transaction/message, 2) appending a digital signature, 3) appending the certificate ... and transmit the "triple" to the bank.

The bank extracts the account number from the transaction/message, reads the account record and validates the digital signature using the public key stored in the account record. The relying-party-only certificate containing only an account number and public key (because of the enormous liability and privacy issues) is never used. It was subsequently observed that such relying-party-only certificates were redundant and superfluous.

The original purpose of certificates were to provide various certified associations for an offline world (something analogous to letters-of-credit from the days of sailing ships). These certificates were a stand-in/substitute for situations where it was not possible to directly access the real information. Most of them are quickly loosing any reason for existence given the extensive proliferation of internet and wireless technologies around the world. It is becoming more and more unlikely that there wouldn't be some form of connectivity .... especially for transactions or authentication events involving anything of value or importance.

The semantics of private key is basically "something you have" .... however given the vagaries of software computing systems, the private key can be stored in a hardware token or in a software encrypted file on a general purpose computer. The software encrypted file is unlocked with a PIN/password ... given some of the characteristics of general purpose computers (like personal computers), any kind of file might be considered publicly copy'able by anybody in the world. As a result, such an encrypted file .... might actually be considered "something you know" authentication (as opposed to something that you "uniquely" have). A hardware token that generates the key in the chip and never allows the private key to leave the chip .... might be considered more representative of "something you have" authentication.

A hardware token that requires a PIN/password to operate can be considered two-factor authentication ("something you have" and "something you know"). Note that in this situation, the business processes of the token and digital signature technology creates an environment that can be used to establish "something you have" (aka the hardware token). The digital signature technology is not an end in itself ... just a method of proving that you posses a specific hardware token (and possibly have knowledge of a specific PIN/password).

As previously noted .... sometimes there is PKI documentation that attempts to grossly exaggerate the meaning of a digital signature and obfuscate the underlying business processes and procedures .... possibly as part of a sales technique to convince public key owners to purchase the certificates (obfuscation that attempts to establish certificates as an end in themselves).

misc. past about relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm



--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to