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
