[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

make things as simple as possible

I've been fairly quiet on this list due to
workload, but I've been trying to follow
everything. I think I've spotted a simplifying
assumption that might be useful in our discussion.
This was inspired by Matt, Joan and Jack's
"Decentralised Trust Management", but don't blame
them for my rantings.

Please bear with me through a fairly unstructured
presentation.

There are four kinds of things we are discussing:

1. Keys

2. Active entities (eg. people, computers, smartcards)
   I will use the term Principal (as in kerberos) for
   these things.

3. Certificates (see below for *my* definition of
   a Certificate)

3. everything else (revocation list/certificate,
   validity period, authorisation statement,
   human-readable comment, value, GIF, session key, ...)

Now keys have one important property; they can
be used to create and check signatures on things.
Principals have a corresponding property; they can
*use* keys to create and check signatures.
Everything else (as far as we are concerned) is
passive.

I want to borrow a concept from DCE (don't cringe
-- some smart people put some smart ideas in
there -- this one presumably came from somewhere
else first, but that's where I heard of it).
This is a UUID -- Unique Universal Identifier.  I
don't care about the representation at the
moment. DCE guaranteed uniqueness of these things
somehow.  We've been using MD5 (or equivalent)
hashes of something, effectively as UUIDs, even
though we only have a probabalistic statement of
uniqueness.  Since we really care about the
uniqueness, it must be something cryptographically
unique in this case. Below I use strings like
"Key123", but keep in mind it would more likely be
a representation of a 160-bit hash.

Everything in the list above needs a UUID
associated with it.

Here's the thing I'm trying to get across.

  All relationships can be expressed as a signed
  list of UUIDs. I hesitate to use the word
  "Certificate" for this, because of accrued
  meaning, but that is what I'll use.

Some examples:
Key123: hjfkedwui298342qyuibf...hjfsaew
Key666: iuoptew8934328h5432nj...8985432er
User345: Greg Rose <ggr@usenix.org>
CA987: Australia Post Certification Authority (doesn't exist)
Statement7: "one of our officials saw two forms of picture ID"
Statement10: "Not valid for more than $1000"
PurchaseOrder23: "Agrees to pay for a pair of speakers"
Validity1004: "Valid between February 29 and April 1, 1996" 
Cert1: a UUID for a certificate (certificates are things, aren't they?)

The bit on the left of the ":" represents the UUID
for discussion purposes.

Here is something equivalent to a self-signed PGP
key.
  (Key123, User345) signed by Key123

It doesn't establish much.

Here is another:
  (Key666, CA987) signed by Key666
This certificate just happens to have the UUID
Cert1.

Assume for the moment that we have some other
reason to believe in this certificate (like an MD5
fingerprint of it on a holographic card obtained
from my post office).

Here is a CA's certificate of me:
  (Key123, User345, Cert1, Statement7, Validity1004) signed by Key666
This has the UUID Cert7.

Note again, the use of "Cert1" here is the UUID
of the certificate, not the certificate itself.

If, as I would propose, the UUID of a "thing" is
a message digest of the thing, it makes a great
index into a hash table for fast lookup, as
someone else has pointed out. You can also simply
bundle things together, so I could create a
purchase order:
  (PurchaseOrder23, Statement10, Cert7) signed by Key123
and accompany it with a copy of Cert7.

Since the UUIDs can be created on-the-fly, I could
of course just include a UUID into the certificate
above, which corresponds to something accompanying
the certificate. For example, the e-mail I send to
the Sound Shop might say:

  I want Bose 201 speakers.
  (PurchaseOrder23, Statement10, Cert7, XXXXXX) signed by Key123
  "copies of PurchaseOrder23, Statement10"

where XXXXXX just happens to be the UUID of the
first sentence. The merchant would presumably get
Amex to return a copy of Cert7 from its
credit-card-swiping machine, and would probably
have Cert1 cached (at least in Australia).

I haven't thought much about encoding this stuff,
but that should be simple enough. Either delimited
Ascii (with defined escape codes to represent
extended characters), or type-length-blob binary
representation would be workable in different
situations.

Of course, what was *in* each blob would need to
be interpreted by the application. Only keys and
certificates are actually "understood" by the
mechanism above.

For archival purposes a copy of this mail is
available as
  http://www.sydney.sterling.com:8080/~ggr/spki
and if it seems worthwhile it might even be kept
up to date.

regards,
Greg.
-- 
Greg Rose               INTERNET: greg_rose@sydney.sterling.com  
Sterling Software       VOICE:  +61-2-9975 4777    FAX:  +61-2-9975 2921
28 Rodborough Rd.       http://www.sydney.sterling.com:8080/~ggr/
French's Forest         35 0A 79 7D 5E 21 8D 47  E3 53 75 66 AC FB D9 45
NSW 2086 Australia.     co-mod sci.crypt.research, USENIX Director.