[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Certs // RW vs CS
Here are a few thoughts on certificates. I don't think they are controversial
(let me know if you see problems with them), but they may be clarifying.
I think it is important to carefully distinguish between RW (real world)
concerns and CS (cyberspace) concerns related to certificates.
A certificate is a digitally signed document. Not an arbitrary signed
document, but one that asserts something about some public key.
Let a "principal" be an entity that can make statements. By a
"statement" I mean an "authenticated statement", one that can be
reliably determined to actually have been made by that principal.
(Anonymous statements are not very relevant here.) Examples of RW
principals include people, corporations, agencies, and machines.
We can restrict CS principals to being public keys: a statement by that
PK is one signed by that PK. (A machine can actually make both RW statements
-- e.g. by console display -- and CS statements, but the latter is only
authenticated if signed with some public key, so I will let the PK be the
principal, and treat the machine / PK binding as a RW / CS linkage.)
A certificate is thus a statement by a CS principal (the "issuing PK").
There seem to be two fundamental kinds of certificates:
(I) Those that assert a relationship between a RW principal
and a PK. (Typically the only relationship of interest
is "ownership", which can be more clearly stated as
"This PK speaks for a (particular) RW principal".) Since RW
principals don't have unique ID's, such certificate may give
numerous attributes of the RW principal (name, email address,
phone number, age, sex, place of employment, etc.) yet be
potentially ambiguous. DN's are an attempt to give each
RW principal a unique ID. Type I certificates have been
called "identity-based". They assert a linkage between a PK and
a RW principal.
(II) Statements that are "internal" to cyberspace, and only
talk about PK's, without reference to the RW. Such
statements generally grant (or revoke) authorization in various
ways. (A typical case is that one key may grant another the
authority to make certain kinds of statements, as if the
statements had been made by the first key.)
Note that:
(1) that it is not necessary that every PK have a corresponding type I
certificate; some public keys may not have RW owners.
(2) Permissions are typically granted to PK's, not to RW principals.
An example:
I might have a public key K1 that I use to make statements as a
security officer of corporation X. There might be a type I
certificate that describes me and links me to K1. Similarly there
might be a public key KX that is the public key for corporation X, and
a similar type I certificate linking X to KX. The fact that I am the
security officer of X is modelled by a type II certificate by KX that
asserts that K1 can make certain kinds of statements with the same
authority that KX would have to make those statements. Such a statement
might be of the form, "KY is the PK of (i.e. speaks for) an employee of
corporation X." This is a type I certificate. Another type of statement
by KX might be of the form, "KY is authorized to make statements of the
form, `KY, speaking for KX, says `I order $___ (<$500) worth of ___.' ' "
This is a type II certificate. A supplier receiving an order by KY can
check this type II certificate, and then respond to the order depending
on local policy as to whether KX's orders are to be honored. (Such policy
may depend on a RW principal determining whether X's orders are to be
honored, and determining what public keys are to be believed in determining
the linkage from X to KX via type I certificates.)
In my thinking, I find it these distinctions helpful...
Is this the right conceptual framework for certificates?
Ron Rivest
Follow-Ups: