[13768] in cryptography@c2.net mail archive
basic question: semantics of "map", "tie", etc in PKI
daemon@ATHENA.MIT.EDU (Fritz Schneider)
Tue Jul 8 12:50:24 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Tue, 8 Jul 2003 08:45:44 -0700 (PDT)
From: Fritz Schneider <fritz@google.com>
To: cryptography@metzdowd.com
In-Reply-To: <20030702192313.GA5048@pit.databus.com>
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
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
