[13771] in cryptography@c2.net mail archive
Re: basic question: semantics of "map", "tie", etc in PKI
daemon@ATHENA.MIT.EDU (Anne & Lynn Wheeler)
Tue Jul 8 13:45:26 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Tue, 08 Jul 2003 11:40:29 -0600
To: Fritz Schneider <fritz@google.com>
From: Anne & Lynn Wheeler <lynn@garlic.com>
Cc: cryptography@metzdowd.com
In-Reply-To: <Pine.LNX.4.51.0307021308490.29084@viola.corp.google.com>
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 majordomo@metzdowd.com
