[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Certs // RW vs CS
- To: email@example.com
- Subject: Re: Certs // RW vs CS
- From: "marcus (m.d.) leech" <firstname.lastname@example.org>
- Date: Fri, 1 Mar 1996 09:22:07 -0500
- Cc: email@example.com
- In-Reply-To: <199603010320.AA26259@swan.lcs.mit.edu>
- Organization: Nortel Technologies, System Security Services
- Sender: firstname.lastname@example.org
- X400-Content-Type: P2-1984 (2)
- X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;<199603011422.AA220040128@bcarh6]
- X400-Originator: email@example.com
- X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 1 Mar 1996 09:23:56 -0500
- X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 1 Mar 1996 09:22:09 -0500
- X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 1 Mar 1996 09:22:08 -0500
- X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 1 Mar 1996 09:22:07 -0500
-----BEGIN PGP SIGNED MESSAGE-----
> 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.)
I tend to think of PKs, and the certificates that go with them as
"proxies" that speak for me in the cyberspatial world.
Your purchasing agent example is one that I have used to describe the
difference between what you call "Type I" and "Type II". In my
scenario, a "Type I" certificate is used to acquire a "ticket"
(and ephemeral Type II certificate), that allows me to enter into
transactions of a specific type, without having to use my Type I
certificate. In many cases (the purchasing example being one),
your identity matters only to your immediate environment. In this
example, the outside entity cares only that the entity issuing the
request has the appropriate authorization.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
Marcus Leech Mail: Dept 4C16, MS 238, CAR
Systems Security Architect Phone : (ESN) 395-4901 (613) 763-9145
Systems Security Services Fax : (ESN) 393-7679 (613) 763-7679
Nortel Technologies firstname.lastname@example.org
-----------------Expressed opinions are my own, not my employers------