SPKI Requirements Carl M. Ellison
INTERNET-DRAFT CyberCash, Inc.
Expires: 22 September 97
17 March 1997
SPKI Requirements
---- ------------
Status of This Document
This document is a compilation of the requirements for SPKI [Simple
Public Key Infrastructure] certificates gathered from the discussion
on the SPKI Working Group mailing list.
Distribution of this document is unlimited. Comments should be sent
to the SPKI (Simple Public Key Infrastructure) Working Group mailing
list <spki@c2.org> or to the author.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (East USA), ftp.isi.edu (West USA),
nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe),
munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa).
Ellison [Page 1]
INTERNET-DRAFT SPKI Requirements 17 Mar 1997
Abstract
The IETF Simple Public Key Infrastructure [SPKI] Working Group is
tasked with producing a certificate structure and operating procedure
to meet the needs of the Internet community for trust management in
as easy, simple and extensible a way as possible.
The SPKI WG first established a list of things one might want to do
with certificates (attached at the end of this document), and then
summarized that list of desires into requirements. This document
presents that summary of requirements.
Charter of the SPKI working group
Many Internet protocols and applications which use the Internet
employ public key technology for security purposes and require a
public key infrastructure to manage public keys.
The task of the working group will be to develop Internet standards
for an IETF sponsored public key certificate format, associated
signature and other formats, and key acquisition protocols. The key
certificate format and associated protocols are to be simple to
understand, implement, and use. For purposes of the working group,
the resulting formats and protocols are to be known as the Simple
Public Key Infrastructure, or SPKI.
The SPKI is intended to provide mechanisms to support security in a
wide range of internet applications, including IPSEC protocols,
encrypted electronic mail and WWW documents, payment protocols, and
any other application which will require the use of public key
certificates and the ability to access them. It is intended that the
Simple Public Key Infrastructure will support a range of trust
models.
Ellison [Page 2]
INTERNET-DRAFT SPKI Requirements 17 Mar 1997
Table Of Contents
Status of This Document....................................1
Abstract...................................................2
Charter of the SPKI working group..........................2
Table Of Contents..........................................3
Background.................................................4
General Requirements.......................................6
Keyholder..................................................7
Validity and CRLs..........................................7
Implementation of Certificates.............................8
List of Certificate Uses..................................10
Open Questions............................................16
References................................................17
Author's Address..........................................17
Expiration and File Name..................................17
Ellison [Page 3]
INTERNET-DRAFT SPKI Requirements 17 Mar 1997
Background
The term certificate traces back to the MIT bachelor's thesis of
Loren M. Kohnfelder [KOHN]. Kohnfelder, in turn, was responding to a
suggestion by Diffie and Hellman in their seminal paper [DH]. Diffie
and Hellman noted that with true public key cryptography, one no
longer needs a secure channel over which to transmit secret keys
between communicants. Instead, one can publish a modified telephone
book -- one with public keys in place of telephone numbers. Diffie
and Hellman went on to propose that such a directory could be on-line
and maintained by a trusted source. One could then look up his or
her desired communication partner in the directory, find that
person's public key and open a secure channel to that person.
Kohnfelder took that suggestion and noted that an on-line service has
the disadvantage of being a performance bottleneck. To replace it,
he proposed creation of digitally signed directory entries which he
called certificates. Because these had the same content as the
original proposal, they were limited to name and public key. In the
time since 1978, the term certificate has frequently been assumed to
mean a binding between name and key.
The SPKI team directly addressed the issue of <name,key> bindings and
realized that such certificates are of extremely limited use for
trust management. The problem is that the original telephone
directory model is inappropriate for a public key infrastructure
[PKI]. What a telephone directory tells you is the number for each
person of a given name who desires to be listed. Imagine entering a
small town where your old friend, Bill Smith, once lived. The phone
book of that small town might list 5 people of that name. In order
to find if your old friend is one of those and, if so, which one, you
must call them all. The phone book never claimed to list your old
friends. That is a function for your personal address book. In
general, the relationships between people are not listed in a phone
book because there are too many possible relationships. Neither does
a phone book list a person's credit cards, or checking account, or
habit of paying bills on time, or permission to telnet in through a
firewall, or any other attribute which might be important to an on-
line entity engaged in trust management. Some such information is
confidential besides and therefore something the subject would not
want to have published. On the other hand, the announced purpose of
a PKI is to give someone the information needed to permit the
extending of trust without resorting to on-line exchanges. The
telephone book model does not satisfy that announced purpose. The
more global the directory, the more ambiguous its names become and
therefore the less well it performs.
More to the point for SPKI is that for many areas of trust management
a person's name is irrelevant. A user of a certificate needs to know
Ellison [Page 4]
INTERNET-DRAFT SPKI Requirements 17 Mar 1997
whether a given keyholder has been granted some attribute and that
attribute rarely involves a name. Names are frequently considered
necessary because of the habit in the physical world of granting
trust to people one knows and not to strangers. However, knowing a
person's name is not the same as knowing the person. These used to
be equivalent, in days when communities were small and rarely
changed, when a person could live an entire lifetime and not meet
anyone who had changed names, when everyone a person would meet would
know the same other people and know them by the same names, etc. In
that kind of world, the one in which our social habits evolved,
knowing someone's name was roughly equivalent to knowing the person.
In the global world of the Internet, there is no such equivalence.
Ellison [Page 5]
INTERNET-DRAFT SPKI Requirements 17 Mar 1997
General Requirements
The main purpose of an SPKI certificate is to authorize some action,
give permission, grant a capability, etc. The first requirement for
an SPKI certificate is then to bind a meaningful or useful attribute
to a public key (and therefore to the keyholder of the corresponding
private key). In many cases, the attribute would not involve any
recognizable name.
The definition of attributes or authorizations in a certificate is up
to the author of code which uses the certificate. The creation of
new authorizations should not require interaction with any other
person or organization but rather be under the total control of the
author of the code using the certificate.
Because SPKI certificates might carry information which the
certificate holder might not want to publish, we assume that
certificates will be distributed directly by the holder to the
verifier. If the holder wishes to use a global repository, similar
to the global PGP key server or the DNS database, that is up to the
certificate holder and not for the SPKI WG to specify.
Because SPKI certificates will carry information which, taken
together over all certificates, might constitute a dossier and
therefore a privacy violation, each SPKI certificate should carry the
minimum attribute necessary to get a job done. The SPKI certificate
is then to be like a single key rather than a key ring -- a single
credit card rather than a whole wallet. The certificate holder
should be able to release a minimum of information in order to prove
his or her permission to act. When possible, all certificates should
be anonymous.
Because one use of SPKI certificates is in secret balloting and
similar applications, an SPKI certificate must be able to assign an
attribute to a blinded signature key.
For SPKI purposes, a certificate is a digitally signed testimony to
whom it may concern, stating some fact or granting some permission.
It is specifically not limited to a binding between name and key.
However, one attribute of concern, especially for encrypted e-mail
uses, is a keyholder's identity. Since humans are required to use
names for things in order to think about them, people use names to
think about other people. However, each person has his or her own
names for friends and therefore his or her own, local namespace. For
the sake of brevity, let us call names in a local namespace
nicknames.
An SPKI certificate must be able to bind a key to a person's
Ellison [Page 6]
INTERNET-DRAFT SPKI Requirements 17 Mar 1997
nickname.
The SDSI work of Rivest and Lampson has done an especially good job
of defining and using local namespaces, therefore if possible SPKI
should support the SDSI name construct.
Keyholder
Central to the SPKI effort is the notion of a keyholder. A keyholder
is a person (or device) which possesses (can use) a private key. The
keyholder is intended to be a single person or entity.
The SPKI certificate should be designed to encourage keyholders never
to share their private keys. Therefore, a certificate holder should
be able to delegate permissions he acquires through the certificate.
Although we humans are fond of our common names, a common name is not
appropriate as a name for a keyholder. A common name does not
uniquely specify most keyholders. A common name must be extended to
make it unique, e.g., via a unique number. One unique number
especially appropriate for identifying a keyholder is the public key.
Another unique number for identifying the keyholder is a
cryptographic hash of the public key. From the point of view of a
verification task, the combination of common name and public key is
no more unique than the public key alone, so the common name can be
eliminated from this pair, leaving just the public key as the name of
the keyholder.
Each keyholder must be identified uniquely, with the public key
itself a strong possibility for that identification.
Validity and CRLs
An SPKI certificate, like any other, should be able to carry a
validity period: dates within which it is valid. However, the notion
of a CRL has been extended by the SPKI working group. In particular,
the CRL and KRL of other certificate designs speaks in the negative.
The same information can be delivered in a positive statement: a
periodic revalidation of a certificate or a key. Similarly, such
information can be generated periodically and broadcast or made
available on request and given a limited lifetime.
It must be possible to specify, for each certificate, not only
activity dates but also conditions which must be tested on-line or
Ellison [Page 7]
INTERNET-DRAFT SPKI Requirements 17 Mar 1997
through other signed instruments. These might include lists of
revoked certificates [CRLs], lists of compromised keys or periodic
re-validation of certificates or keys.
Any CRL, KRL or revalidation instrument must have its own lifetime.
A lifetime of 0 is not possible because of communication delays and
clock skews, although one can consider an instrument whose lifetime
is "one use" and which is delivered only as part of a
challenge/response protocol.
Implementation of Certificates
The authorization certificates which are envisioned for SPKI (and
needed to meet the demands of the list given at the end of this
document) should be generated by any user of certificates and
potentially any holder of certificates. The code to generate
certificates should be written by many different developers,
frequently persons acting alone, operating out of garages or dorm
rooms. This leads to a number of constraints on the structure and
encoding of certificates. In addition, SPKI certificates should be
useable in very constrained environments, such as smartcards. The
code to process them and the memory to store them should both be as
small as possible.
An SPKI certificate should be as simple as possible. There should be
a bare minimum of fields necessary to get the job done and there
should be an absolute minimum (hopefully 0) of optional fields. In
particular, the structure should be specific enough that the creator
of a certificate is constrained by the structure definition, not by
complaints (or error messages) from the reader of a certificate.
An SPKI certificate should be described in as simple a method as
possible, relating directly to the kind of structures a C or PASCAL
programmer would normally write.
No library code should be required for the packing or parsing of SPKI
certificates. In particular, ASN.1 is not to be used.
A certificate should be signed exactly as it is transmitted. There
should be no reformatting called for in the process of checking a
certificate's signature (although one might canonicalize white space
during certificate input, for example, if the format is text).
For efficiency, if possible, an SPKI certificate should be encoded in
an LR(0) grammar. That is, neither packing nor parsing of the
structure should require a scan of the data. Data should be read
Ellison [Page 8]
INTERNET-DRAFT SPKI Requirements 17 Mar 1997
into the kind of structure a programmer would want to use without
touching the incoming bytes more than once.
For efficiency, if possible, an SPKI certificate should be packed and
parsed without any recursion.
Ellison [Page 9]
INTERNET-DRAFT SPKI Requirements 17 Mar 1997
List of Certificate Uses
The list below is a brainstorming list, accumulated on the SPKI
mailing list, of uses of such certificates.
- I need a certificate to give me permission to write electronic
checks.
- 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.
- 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.
- 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.
- I might have a certificate giving my security clearance, signed
by a governmental issuing authority.
- 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. [Douglas Barnes <cman@communities.com>]
- I need certificates to bind names to public keys:
- [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.
- [direct certificate] binding a name to a key, implying "I
(the person who is able to use the associated private key
Ellison [Page 10]
INTERNET-DRAFT SPKI Requirements 17 Mar 1997
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.
- [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.
- 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. [Ben Laurie <ben@gonzo.ben.algroup.co.uk>]
- I want to sign a contract to buy a house. What kind of
certificate do I need?
- 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?
- 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.
- Can I have a digital marriage license?
- Can I have a digital divorce decree?
- ..a digital Voter Registration Card?
- There are a number of cards one carries in a typical wallet
which could become certificates attached to a public key:
Ellison [Page 11]
INTERNET-DRAFT SPKI Requirements 17 Mar 1997
- health insurance card
- prescription drug card
- driver's license (for permission to drive)
- driver's license (for permission to buy alcohol)
- supermarket discount card
- supermarket check-cashing card [I know -- anachronism]
- Blockbuster Video rental card
- ATM card
- Credit card
- membership card in the ACLU, NRA, Republican party, Operation
Rescue, NARAL, ACM, IEEE, ICAR....
- Red Cross blood donor card
- Starbuck's Coffee buy-10-get-1-free card
- DC Metro fare card
- Phone calling card
- Alumni Association card
- REI Membership card
- Car insurance card
- claim check for a suitcase
- claim check for a pawned radio
- authorization for followup visits to a doctor, after surgery
- Better Business Bureau [BBB] style reputation certificates
[testimonies from satisfied customers]
- BBB-style certificate that no complaints exist against a
business or doctor or dentist, etc.
- LDS Temple Recommend
Ellison [Page 12]
INTERNET-DRAFT SPKI Requirements 17 Mar 1997
- Stock certificate
- Stock option
- Car title
- deed to land
- proof of ownership of electronic equipment with an ID number
- time card certificate [activating a digital time clock]
- proof of degree earned [PhD, LLD, MD, ...]
- permission to write digitally signed prescriptions for drugs
- permission to spend up to $X of a company's money
- permission to issue nuclear launch codes
- 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. [marcus
(m.d.) leech <mleech@bnr.ca>]
- 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... [marcus (m.d.) leech <mleech@bnr.ca>]
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. [Bill Sommerfeld
<sommerfeld@apollo.hp.com>]
- 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. [marcus (m.d.) leech
<mleech@bnr.ca>]
- 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
Ellison [Page 13]
INTERNET-DRAFT SPKI Requirements 17 Mar 1997
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!]. [marcus
(m.d.) leech <mleech@bnr.ca>]
- "This signed-key should be considered equivalent to the
certifying-key until this certificate expires for the following
purposes ..."
[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.
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..].
[Bill Sommerfeld <sommerfeld@apollo.hp.com>]
- "I am the current legitimate owner of a particular chunk of
internet address space."
[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]
[Bill Sommerfeld <sommerfeld@apollo.hp.com>]
- "I am the current legitimate owner of a this DNS name or
subtree." [Bill Sommerfeld <sommerfeld@apollo.hp.com>]
- "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.]
[Bill Sommerfeld <sommerfeld@apollo.hp.com>]
- Encryption keys for E-mail and file encryption [Tatu Ylonen
<ylo@cs.hut.fi>]
- Authentication of people or other entities [Tatu Ylonen
<ylo@cs.hut.fi>]
Ellison [Page 14]
INTERNET-DRAFT SPKI Requirements 17 Mar 1997
- Digital signatures (unforgeability) [Tatu Ylonen
<ylo@cs.hut.fi>]
- Timestamping / notary services [Tatu Ylonen <ylo@cs.hut.fi>]
- Host authentication [Tatu Ylonen <ylo@cs.hut.fi>]
- Service authentication [Tatu Ylonen <ylo@cs.hut.fi>]
Other requirements: [Tatu Ylonen <ylo@cs.hut.fi>]
- 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).
- Some applications (e.g., notary services) require highly
trusted keys; generation complexity is not an issue here
- Some applications (e.g., host authentication) require
extremely light (or no) bureauchracy. Even communication with
the central administrator may be a problem.
- 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.
- 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.
- 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.
Ellison [Page 15]
INTERNET-DRAFT SPKI Requirements 17 Mar 1997
Open Questions
Given such certificates, there remain some questions, most to do with
proofs of the opposite of what a certificate is designed to do.
These do not have ready answers. [Some people believe that a global
namespace and traditional ID certificate might answer some of these
needs, but that assumes a single, unique name assigned to each
individual with no possibility of name change. A traditional ID
certificate structure does not answer these needs if names are not
permanent, unique and limited to one per person. For example, that
unique name might be a number tattooed on a person -- or the moral
equivalent. It is unlikely that any democratic government would
approve the creation of such names.]
- 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?
- Can certificates help do a title scan for purchase of a house?
- Can a certificate be issued to guarantee that I am not already
married, so that I can then get a digital marriage license?
- 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.]
Ellison [Page 16]
INTERNET-DRAFT SPKI Requirements 17 Mar 1997
References
[DH] Diffie and Hellman, "New Directions in Cryptography", IEEE
Transactions on Information Theory IT-22, 6 (Nov. 1976), 644-654
[KOHN] Loren Kohnfelder, "Towards a Practical Public-key
Cryptosystem", Bachelor's thesis, MIT, May, 1978
Author's Address
Carl M. Ellison
CyberCash, Inc.
207 Grindall Street
Baltimore MD 21230-4103 USA
Telephone: +1 410-727-4288
+1 410-727-4293(fax)
+1 703-620-4200(main office, Reston, Virginia, USA)
EMail: cme@cybercash.com
Expiration and File Name
This draft expires 22 September 1997.
Its file name is draft-ietf-spki-cert-req-00.txt
Ellison [Page 17]
