[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
current list of certificate uses
I had a couple of people ask that I mail this file to the whole SPKI list,
not just leave it on the web [http://www.clark.net/pub/cme/html/cert-use.html]
so that it gets archived. Contributions seem to have fallen off, so here
it is:
<html>
<head>
<title> Uses of Certificates </title>
</head>
<body>
<center><h1> Uses of Certificates </h1></center>
[Page last modified: February 29, 1996]
<hr>
For the purpose of this list, a <a href="cert.html"><b>certificate</b></a>
is not a binding between a public key and an individual, as is commonly
assumed. That is an <i>identity-based certificate</i>.
<P>
A certificate here is some signed object having at least the following
fields: a Certifying-key, a Signed-key, a Meaning and probably a Validity
period. It is a digitally signed testimony to whom it may concern, stating
some fact or granting some permission. The list below is a brainstorming
list, being accumulated on the SPKI mailing list, of uses of such signed
statements -- such certificates.
<ol>
<P><LI>I need a certificate to give me permission to write
electronic checks.
<P><LI>My bank would need a certificate, proving to others that it is a
bank capable of cashing electronic checks and permitted to give permission
to people to write electronic checks.
<P><LI>My bank would issue a certificate signing the key of a master bank
certifier -- perhaps NACHA -- so that I could follow a certificate chain
from a key I know (my bank's) to the key of any other bank in the US and,
similarly, to any other bank in the world.
<P><LI>I might generate a certificate (a ``reputation voucher'') for a
friend to introduce him to another friend -- in which certificate I could
testify to my friend's political opinion (e.g., libertarian cypherpunk) or
physical characteristics or anything else of interest.
<P><LI>I might have a certificate giving my security clearance, signed by
the governmental issuing authority.
<P><LI>I want a certificate for some software I have downloaded and am
considering running on my computer -- to make sure it hasn't changed and
that some reputable company or person stands behind it. [<a
href="mailto:cman@communities.com"> Douglas Barnes</a>]
<P><LI>I need certificates to bind names to public keys:
<UL>
<P><LI>[traditional certificate] binding a key to a name, implying "all the
attributes of the real person having this name are transferred to this key
by this certificate". This requires unique identification of a person
(which is difficult in non-digital space, as it is) and someone trustworthy
binding that unique name to the key in question. In this model, a key
starts out naked and acquires attributes, permissions and authority from
the person bound to it.
<P><LI>[direct certificate] binding a name to a key, implying "I (the
person who is able to use the associated private key to make this
signature) declare that I go by the name of XXXXXXX." The unique
identification of the key is automatic -- from the key itself or a
cryptographic hash of the key. The binding is done by the key itself -- in
a self-signed certificate. In this model, a key is loaded with attributes,
permissions and authority directly by other certificates, not indirectly
through some person's name, and this certificate declares only a name or
nickname by which the key's owner likes to be addressed.
<P><LI>[personal binding] binding a key to a nickname. This kind of
certificate is signed by me, singing someone else's key and binding it to a
nickname by which I know that person. It is for my use only -- never given
out -- and is a signed certificate to prevent tampering with my own private
directory of keys. It says nothing about how I certified the binding to my
own satisfaction between the key and my friend.
</UL>
<P><LI>I might be doing geneology and be collecting what amounts to 3x5
cards with facts to be linked together. Some of these links would be from
one content to another reference [e.g., indexing and cross-referencing].
Others might be links to the researcher who collected the fact. By rights,
the fact should be signed by that researcher. Viewing only the signature
on the fact and the link to the researcher, this electronic 3x5 card
becomes a certificate. [<a href="mailto:ben@gonzo.ben.algroup.co.uk">
Ben Laurie</a>]
<P><LI>I want to sign a contract to buy a house. What kind of certificate
do I need?
<P><LI>I have found someone on the net and she sounds really nice. Things
are leading up to cybersex. How do I make sure she's not really some
80-year-old man in a nursing home?
<P><LI>I have met someone on the net and would like a picture of her
and her height, weight and other measurements from a trustworthy source.
<P><LI>Can I have a digital marriage license?
<P><LI>Can I have a digital divorce decree?
<P><LI>..a digital Voter Registration Card?
<P><LI>There are a number of cards one carries in a typical wallet which
could become certificates attached to a public key:
<OL>
<P><LI>health insurance card
<P><LI>prescription drug card
<P><LI>driver's license (for permission to drive)
<P><LI>driver's license (for permission to buy alcohol)
<P><LI>supermarket discount card
<P><LI>supermarket check-cashing card [I know -- anachronism]
<P><LI>Blockbuster Video rental card
<P><LI>ATM card
<P><LI>Credit card
<P><LI>membership card in the ACLU, NRA, Republican party,
Operation Rescue, NARAL, ACM, IEEE, ICAR....
<P><LI>Red Cross blood donor card
<P><LI>Starbuck's Coffee buy-10-get-1-free card
<P><LI>DC Metro fare card
<P><LI>Phone calling card
<P><LI>Alumni Association card
<P><LI>REI Membership card
<P><LI>Car insurance card
<P><LI>claim check for a suitcase
<P><LI>claim check for a pawned radio
<P><LI>authorization for followup visits to a doctor, after surgery
</OL>
<P><LI>BBB-style reputation certificates [testimonies from satisfied
customers]
<P><LI>BBB-style certificate that no complaints exist against a
business or doctor or dentist, etc.
<P><LI>LDS Temple Recommend
<P><LI>Stock certificate
<P><LI>Stock option
<P><LI>Car title
<P><LI>deed to land
<P><LI>proof of ownership of electronic equipment with an ID number
<P><LI>time card certificate [activating a digital time clock]
<P><LI>proof of degree earned [PhD, LLD, MD, ...]
<P><LI>permission to write digitally signed prescriptions for drugs
<P><LI>permission to spend up to $X of a company's money
<P><LI>permission to issue nuclear launch codes
<P><LI>I'm a sysadmin, I want to carry a certificate, signed by SAGE, that
says I'm good at the things sysadmins are good at.
[<a href="mailto:mleech@bnr.ca"> marcus (m.d.) leech</a>]
<P><LI>I'm that same sysadmin, I want an ephemeral certificate that grants me
root access to certain systems for the day, or the week, or...
[<a href="mailto:mleech@bnr.ca"> marcus (m.d.) leech</a>]
<P>
Certain applications *will* want some form of auditing, but the audit
identity should be in the domain of the particular application...
For instance an "is a system administrator of this host" certificate
would probably want to include an audit identity, so you can figure
out which of your multiple admins screwed something up.
[<a href="mailto:sommerfeld@apollo.hp.com"> Bill Sommerfeld </a>]
<P><LI>I'm an amateur radio operator. I want a signed certificate that says
I'm allowed to engage in amateur radio, issued by the DOC. [I currently
have a paper version of one]. This would be useful in enforcing
access policies to the amateur spectrum; and in tracking abuse of
that same spectrum. Heck! extend this concept to all licensed
spectrum users.
[<a href="mailto:mleech@bnr.ca"> marcus (m.d.) leech</a>]
<P><LI>I'm the a purchasing agent for a large corporation. I want to
posses a certificate that tells our suppliers that I'm authorized
to make purchases up to $15,000. I don't want the suppliers to know
my name, lest their sales people bug me too much. I don't want to
have to share a single "Megacorp Purchasing Department Certificate"
with others doing the same job [the private key would need to be
shared--yuck!].
[<a href="mailto:mleech@bnr.ca"> marcus (m.d.) leech</a>]
<P><LI>"This signed-key should be considered equivalent to the certifying-key
until this certificate expires for the following purposes ..."
<P>
[This is desirable when you wish to reduce the exposure of
long-term keys. One way to do this is to use smartcards, but
those typically have slow processors and are connected
through low-bandwidth links; however, if you only use the
smartcard at "login" time to certify a short-term keypair,
you get high performance and low exposure of the long term
key.
<P>
I'll note here that this flies in the face of attempts to
prevent delegation of certain rights.. Maybe we need a
"delegation-allowed" bit -- but there's nothing to stop
someone who wishes to delegate against the rules from also
loaning out their private key..].
[<a href="mailto:sommerfeld@apollo.hp.com"> Bill Sommerfeld </a>]
<P><LI>"I am an administrator of this host/service"
[<a href="mailto:sommerfeld@apollo.hp.com"> Bill Sommerfeld </a>]
<P><LI>"I am the current legitimate owner of a particular chunk of internet
address space."
<P>
[I'd like to see ipsec eventually become usable, at least for
privacy, without need for prior arrangement between sites,
but I think there's a need for a "I own this address"/"I own
this address range" certificate in order for ipsec to coexist
with existing ip-address-based firewalls]
[<a href="mailto:sommerfeld@apollo.hp.com"> Bill Sommerfeld </a>]
<P><LI>"I am the current legitimate owner of a this DNS name or subtree."
[<a href="mailto:sommerfeld@apollo.hp.com"> Bill Sommerfeld </a>]
<P><LI>"I am the legitimate receiver of mail sent to this rfc822 email
address. [this might need to be signed by a key which itself had been
certified by the appropriate "DNS name owner" certificate]."
[This is in case I know someone owns a particular e-mail address
but I don't know their key.]
[<a href="mailto:sommerfeld@apollo.hp.com"> Bill Sommerfeld </a>]
<P><LI>Encryption keys for E-mail and file encryption
[<a href="mailto:ylo@cs.hut.fi">Tatu Ylonen</a>]
<P><LI>Authentication of people or other entities
[<a href="mailto:ylo@cs.hut.fi">Tatu Ylonen</a>]
<P><LI>Digital signatures (unforgeability)
[<a href="mailto:ylo@cs.hut.fi">Tatu Ylonen</a>]
<P><LI>Timestamping / notary services
[<a href="mailto:ylo@cs.hut.fi">Tatu Ylonen</a>]
<P><LI>Host authentication
[<a href="mailto:ylo@cs.hut.fi">Tatu Ylonen</a>]
<P><LI>Service authentication
[<a href="mailto:ylo@cs.hut.fi">Tatu Ylonen</a>]
</ol>
<P><HR><P>
Other requirements:
[<a href="mailto:ylo@cs.hut.fi">Tatu Ylonen</a>]
<UL>
<P><LI>Trust model must be a web (people want to choose whom they trust).
People must be able to choose whome they trust or consider
reliable roots (maybe with varying reliabilities).
<P><LI>Some applications (e.g., notary services) require highly trusted
keys; generation complexity is not an issue here
<P><LI>Some applications (e.g., host authentication) require extremely
light (or no) bureauchracy. Even communication with the central
administrator may be a problem.
<P><LI>Especially in lower-end applications (e.g. host authentication)
the people generating the keys (e.g., administrators) will change,
and you will no longer want them to be able to certify. On the
other hand, you will usually also not want all keys they have
generated to expire. This may imply a "certification right
expiration" certificate requirement, probably to be implemented
together with notary services.
<P><LI>Keys will need to be cached locally to avoid long delays fetching
frequently used keys. Cf. current name servers. The key
infrastructure may in future get used almost as often as the name
server. The caching and performance requirements are similar.
<P><LI>Reliable distribution of key revocations and other certificates
(e.g., the ceasing of the right to make new certificates). May
involve goals like "will have spread everywhere in 24 hours"
or something like that. This interacts with caching.
</ul>
<P><hr><P>
Given such certificates, there remain some questions, most to do with
proofs of the opposite of what a certificate is designed to do.
<OL>
<P><LI>Someone digitally signs a threatening e-mail message with my private
key and sends it to president@whitehouse.gov. How do I prove that I didn't
compose and send the message? What kind of certificate characteristic
might help me in this?
<P><LI>Can certificates help do a title scan for purchase of a house?
<P><LI>Can a certificate be issued to guarantee that I am not already
married, so that I can then get a digital marriage license?
<P><LI>The assumption in most certificates is that the proper user will
protect his private key very well, to prevent anyone else from accessing
his funds. However, in some cases the certificate itself might have
monitary value [permission to prescribe drugs, permission to buy alcohol,
...]. What is to prevent the holder of such a certificate from loaning out
his private key? [Thanks to Bob Jueneman for this one and some of the
others.]
</OL>
<hr>
<address> <a href="http://www.clark.net/pub/cme/home.html"> Carl Ellison
</a> --- <a href="mailto:cme@acm.org"> cme@acm.org </a> </address>
</body>
</html>
+--------------------------------------------------------------------------+
|Carl M. Ellison cme@cybercash.com http://www.clark.net/pub/cme |
|CyberCash, Inc., Suite 430 http://www.cybercash.com/ |
|2100 Reston Parkway PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Reston, VA 22091 Tel: (703) 620-4200 |
+--------------------------------------------------------------------------+