3. <authorization,key> (as an authorization certificate or ACL
entry)
These entities are processed in three stages.
1. Individual certificates are verified by checking their
signatures and possibly performing other work. They are then
mapped to intermediate forms, called "tuples" here.
The other work for SPKI or SDSI certificates might include
processing of on-line test results (CRL, re-validation or one-
time validation).
The other work for PGP certificates may include a web-of-trust
computation.
The other work for X.509 certificates depends on the written
documentation for that particular use of X.509 (typically tied
to the root key from which the certificate descended) and could
involve checking information in the parent certificate as well
as additional information in extensions of the certificate in
question. That is, some use X.509 certificates just to define
names. Others use X.509 to communicate an authorization
implicitly (e.g., SSL server certificates). Some might define
extensions of X.509 to carry explicit authorizations. All of
these interpretations are specified in written documentation
associated with the certificate chain and therefore with the
root from which the chain descends.
If on-line tests are involved in the certificate processing,
then the validity dates of those on-line test results are
intersected by VIntersect() [defined in 6.3.2, below] with the
validity dates of the certificate to yield the dates in the
certificate's tuple(s).
2. Uses of names are replaced with simple definitions (keys or
hashes), based on the name definitions available from reducing
name 4-tuples.
3. Authorization 5-tuples are then reduced to a final authorization
result.
6.1 5-tuple Defined
The 5-tuple is an intermediate form, assumed to be held in trusted
memory so that it doesn't need a digital signature for integrity. It
is produced from certificates or other credentials via trusted
software. Its contents are the same as the contents of an SPKI
certificate body, but it might be derived from another form of
certificate or from an ACL entry.
The elements of a 5-tuple are:
1. Issuer: a public key (or its hash), or the reserved word "Self".
This identifies the entity speaking this intermediate result.
2. Subject: a public key (or its hash), a name used to identify a
public key, the hash of an object or a threshold function of
subordinate subjects. This identifies the entity being spoken
about in this intermediate result.
3. Delegation: a boolean. If TRUE, then the Subject is permitted
by the Issuer to further propagate the authorization in this
intermediate result.
4. Authorization: an S-expression. [Rules for combination of
Authorizations are given below.]
5. Validity dates: a not-before date and a not-after date, where
"date" means date and time. If the not-before date is missing
from the source credential then minus infinity is assumed. If
the not-after date is missing then plus infinity is assumed.
6.2 4-tuple Defined
A <name,key> certificate (such as X.509v1 or SDSI 1.0) carries no
authorization field but does carry a name. Since it is qualitatively
different from an authorization certificate, a separate intermediate
form is defined for it.
The elements of a Name 4-tuple are:
1. Issuer: a public key (or its hash). This identifies the entity
defining this name in its private name space.
2. Name: a byte string
3. Subject: a public key (or its hash), a name, or a threshold
function of subordinate subjects. This defines the name.
4. Validity dates: a not-before date and a not-after date, where
"date" means date and time. If the not-before date is missing
from the source credential then minus infinity is assumed. If
the not-after date is missing then plus infinity is assumed.
6.3 5-tuple Reduction Rules
The two 5-tuples:
<I1,S1,D1,A1,V1> + <I2,S2,D2,A2,V2>
yield
<I1,S2,D2,AIntersect(A1,A2),VIntersect(V1,V2)>
provided
the two intersections succeed,
S1 = I2
and
D1 = TRUE
If S1 is a threshold subject, there is a slight modification to this
rule, as described below in section 6.3.3.
6.3.1 AIntersect
An authorization is a list of strings or sub-lists, of meaning to and
probably defined by the application that will use this authorization
for access control. Two authorizations intersect by matching,
element for element. If one list is longer than the other but match
at all elements where both lists have elements, then the longer list
is the result of the intersection. This means that additional
elements of a list must restrict the permission granted.
Although actual authorization string definitions are application
dependent, AIntersect provides rules for automatic intersection of
these strings so that application developers can know the semantics
of the strings they use. Special semantics would require special
reduction software.
For example, there might be an ftpd that allows public key access
control, using authorization certificates. Under that service,
(ftp (host ftp.clark.net))
might imply that the keyholder would be allowed ftp access to all
directories on ftp.clark.net, with all kinds of access (read, write,
delete, ...). This is more general (allows more access) than
(ftp (host ftp.clark.net) (dir /pub/cme))
which would allow all kinds of access but only in the directory
specified. The intersection of the two would be the second.
Since the AIntersect rules imply position dependency, one could also
define the previous authorization string as:
(ftp ftp.clark.net /pub/cme)
to keep the form compact.
To allow for wild cards, there are a small number of special S-
expressions defined, using "*" as the expression name.
(*)
stands for the set of all S-expressions and byte-strings.
In other words, it will match anything. When intersected
with anything, the result is that other thing. [The
AIntersect rule about lists of different length treats a
list as if it had enough (*) entries implicitly appended to
it to match the length of another list with which it was
being intersected.]
(* set <tag-expr>*)
stands for the set of elements listed in the *-form.
(* prefix <byte-string>)
stands for the set of all byte strings that start with the
one given in the *-form.
(* range <ordering> <lower-limit>? <upper-limit>?)
stands for the set of all byte strings lexically (or
numerically) between the two limits. The ordering
parameter (alpha, numeric, time, binary, date) specifies
the kind of strings allowed.
AIntersect() is normal set intersection, when *-forms are defined as
they are above and a normal list is taken to mean all lists that
start with those elements. The following examples should give a more
concrete explanation for those who prefer an explanation without
reference to set operations.
AIntersect( (tag (ftp ftp.clark.net cme (* set read write))),
(tag (*)) )
evaluates to (tag (ftp ftp.clark.net cme (* set read write)))
AIntersect( (tag (* set read write (foo bla) delete)),
(tag (* set write read) ) )
evaluates to (tag (* set read write))
AIntersect( (tag (* set read write (foo bla) delete)),
(tag read ) )
evaluates to (tag read)
AIntersect( (tag (* prefix http://www.clark.net/pub/)),
(tag (* prefix http://www.clark.net/pub/cme/html/)) )
evaluates to (tag (* prefix http://www.clark.net/pub/cme/html/))
AIntersect( (tag (* range numeric ge #30# le #39# )), (tag #26#) )
fails to intersect.
6.3.2 VIntersect
Date range intersection is straight-forward.
V = VIntersect( X, Y )
is defined as
Vmin = max( Xmin, Ymin )
Vmax = min( Xmax, Ymax )
and if Vmin > Vmax, then the intersection failed.
These rules assume that daytimes are expressed in a monotonic form,
as they are in SPKI.
The full SPKI VIntersect() also deals with online tests. In the most
straight-forward implementation, each online test to which a
certificate is subject is evaluated. Each such test carries with it
a validity interval, in terms of dates. That validity interval is
intersected with any present in the certificate, to yield a new,
current validity interval.
It is possible for an implementation of VIntersect() to gather up
online tests that are present in each certificate and include the
union of all those tests in the accumulating tuples. In this case,
the evaluation of those online tests is deferred until the end of the
process. This might be appropriate if the tuple reduction is being
performed not for answering an immediate authorization question but
rather for generation of a summary certificate (Certificate Result
Certificate) that one might hope would be useful for a long time.
6.3.3 Threshold Subjects
A threshold subject is specified by two numbers, K and N [0<K<=N],
and N subordinate subjects. A threshold subject is reduced to a
single subject by selecting K of the N subjects and reducing each of
those K to the same subject, through a sequence of certificates. The
(N-K) unselected subordinate subjects are set to (null).
The intermediate form for a threshold subject is a copy of the tuple
in which the threshold subject appears, but with only one of the
subordinate subjects. Those subordinate tuples are reduced
individually until the list of subordinate tuples has (N-K) (null)
entries and K entries with the same subject. At that point, those K
tuples are validity-, authorization- and delegation- intersected to
yield the single tuple that will replace the list of tuples.
6.3.4 Certificate Path Discovery
All reduction operations are in the order provided by the prover.
That simplifies the job of the verifier, but leaves the job of
finding the correct list of reductions to the prover.
The general algorithm for finding the right certificate paths from a
large set of unordered certificates has been solved[ELIEN], but might
be used only rarely. Each keyholder who is granted some authority
should receive a sequence of certificates delegating that authority.
That keyholder may then want to delegate part of this authority on to
some other keyholder. To do that, a single additional certificate is
generated and appended to the sequence already available, yielding a
sequence that can be used by the delegatee to prove access
permission.
6.4 4-tuple Reduction
There will be name 4-tuples in two different classes, those that
define the name as a key and those that define the name as another
name.
1. [(name K1 N) -> K2]
2. [(name K1 N) -> (name K2 N1 N2 ... Nk)]
As with the 5-tuples discussed in the previous section, name
definition 4-tuples should be delivered in the order needed by the
prover. In that case, the rule for name reduction is to replace the
name just defined by its definition. For example,
(name K1 N N1 N2 N3) + [(name K1 N) -> K2]
-> (name K2 N1 N2 N3)
or, in case 2 above,
(name K1 N Na Nb Nc) + [(name K1 N) -> (name K2 N1 N2 ... Nk)]
-> (name K2 N1 N2 ... Nk Na Nb Nc)
With the second form of name definition, one might have names that
temporarily grow. If the prover is providing certificates in order,
then the verifier need only do as it is told.
If the verifier is operating from an unordered pool of tuples, then a
safe rule for name reduction is to apply only those 4-tuples that
define a name as a key. Such applications should bring 4-tuples that
started out in class (2) into class (1), and eventually reduce all
names to keys. Any naming loops are avoided by this process.
6.4.1 4-tuple Threshold Subject Reduction
Some of a threshold subject's subordinate subjects might be names.
Those names must be reduced by application of 4-tuples. The name
reduction process proceeds independently on each name in the
subordinate subject as indicated in 6.3.3 above.
One can reduce individual named subjects in a threshold subject and
leave the subject in threshold form, if one desires. There is no
delegation- or authorization-intersection involved, only a validity-
intersection during name reduction. This might be used by a service
that produces Certificate Result Certificates [see 6.7].
6.4.2 4-tuple Validity Intersection
Whenever a 4-tuple is used to reduce the subject (or part of the
subject) of another tuple, its validity interval is intersected with
that of the tuple holding the subject being reduced and the
intersection is used in the resulting tuple. Since a 4-tuple
contains no delegation or authorization fields, the delegation
permission and authorization of the tuple being acted upon does not
change.
6.5 Certificate Translation
Any certificate currently defined, as well as ACL entries and
possibly other instruments, can be translated to 5-tuples (or name
tuples) and therefore take part in an authorization computation. The
specific rules for those are given below.
6.5.1 X.509v1
The original X.509 certificate is a <name,key> certificate. It
translates directly to a name tuple. The form
[Kroot, (name <leaf-name>), K1, validity]
is used if the rules for that particular X.509 hierarchy is that all
leaf names are unique, under that root. If uniqueness of names
applies only to individual CAs in the X.509 hierarchy, then one must
generate
[Kroot, (name CA1 CA2 ... CAk <leaf-name>), K1, validity]
after verifying the certificate chain by the rules appropriate to
that particular chain.
6.5.2 PGP
A PGP certificate is a <name,key> certificate. It is verified by
web-of-trust rules (as specified in the PGP documentation). Once
verified, it yields name tuples of the form
[Ki, name, K1, validity]
where Ki is a key that signed that PGP (UserID,key) pair. There
would be one tuple produced for each signature on the key, K1.
6.5.3 X.509v3
An X.509v3 certificate may be used to declare a name. It might also
declare explicit authorizations, by way of extensions. It might also
declare an implicit authorization of the form (tag (*)). The actual
set of tuples it yields depends on the documentation associated with
that line of certificates. That documentation could conceptually be
considered associated with the root key of the certificate chain. In
addition, some X.509v3 certificates (such as those used for SET),
have defined extra validity tests for certificate chains depending on
custom extensions. As a result, it is likely that X.509v3 chains
will have to be validated independently, by chain validation code
specific to each root key. After that validation, that root-specific
code can then generate the appropriate multiple tuples from the one
certificate.
6.5.4 X9.57
An X9.57 attribute certificate should yield one or more 5-tuples,
with names as Subject. The code translating the attribute
certificate will have to build a fully-qualified name to represent
the Distinguished Name in the Subject. For any attribute
certificates that refer to an ID certificate explicitly, the Subject
of the 5-tuple can be the key in that ID certificate, bypassing the
construction of name 4-tuples.
6.5.5 SDSI 1.0
A SDSI 1.0 certificate maps directly to one 4-tuple.
6.5.6 SPKI
An SPKI certificate maps directly to one 4- or 5- tuple, depending
respectively on whether it is a name certificate or carries an
authorization.
6.5.7 SSL
An SSL certificate carries a number of authorizations, some
implicitly. The authorization:
(tag (ssl))
is implicit. In addition, the server certificate carries a DNS name
parameter to be matched against the DNS name of the web page to which
the connection is being made. That might be encoded as:
(tag (dns <domain-name>))
Meanwhile, there is the "global cert" permission -- the permission
for a US-supplied browser to connect using full strength symmetric
cryptography even though the server is outside the USA. This might
be encoded as:
(tag (us-crypto))
There are other key usage attributes that would also be encoded as
tag fields, but a full discussion of those fields is left to the
examples document.
An ACL entry for an SSL root key would have the tag:
(tag (* set (ssl) (dns (*))))
which by the rules of intersection is equivalent to:
(tag (* set (ssl) (dns)))
unless that root key also had the permission from the US Commerce
Department to grant us-crypto permission, in which case the root key
would have:
(tag (* set (ssl) (dns) (us-crypto)))
A CA certificate, used for SSL, would then need only to communicate
down its certificate chain those permissions allocated in the ACL.
Its tag might then translate to:
(tag (*))
A leaf server certificate for the Datafellows server might, for
example, have a tag field of the form:
(tag (* set (ssl) (dns www.datafellows.com)))
showing that it was empowered to do SSL and to operate from the given
domain name, but not to use US crypto with a US browser.
The use of (* set) for the two attributes in this example could have
been abbreviated as:
(tag (ssl www.datafellows.com))
while CA certificates might carry:
(tag (ssl (*))) or just (tag (*))
but separating them, via (* set), allows for a future enhancement of
SSL in which the (ssl) permission is derived from one set of root
keys (those of current CAs) while the (dns) permission is derived
from another set of root keys (those empowered to speak in DNSSEC)
while the (us-crypto) permission might be granted only to a root key
belonging to the US Department of Commerce. The three separate tests
in the verifying code (e.g., the browser) would then involve separate
5-tuple reductions from separate root key ACL entries.
The fact that these three kinds of permission are treated as if ANDed
is derived from the logic of the code that interprets the permissions
and is not expressed in the certificate. That decision is embodied
in the authorization code executed by the verifying application.
6.6 Certificate Result Certificates
Typically, one will reduce a chain of certificates to answer an
authorization question in one of two forms:
1. Is this Subject, S, allowed to do A, under this ACL and with
this set of certificates?
2. What is Subject S allowed to do, under this ACL and with this
set of certificates?
The answer to the second computation can be put into a new
certificate issued by the entity doing the computation. That one
certificate corresponds to the semantics of the underlying
certificates and online test results. We call it a Certificate
Result Certificate.
7. Key Management
Cryptographic keys have limited lifetimes. Keys can be stolen. Keys
might also be discovered through cryptanalysis. If the theft is
noticed, then the key can be replaced as one would replace a credit
card. More likely, the theft will not be noticed. To cover this
case, keys are replaced routinely.
The replacement of a key needs to be announced to those who would use
the new key. It also needs to be accomplished smoothly, with a
minimum of hassle.
Rather than define a mechanism for declaring a key to be bad or
replaced, SPKI defines a mechanism for giving certificates limited
lifetimes so that they can be replaced. That is, under SPKI one does
not declare a key to be bad but rather stops empowering it and
instead empowers some other key. This limitation of a certificate's
lifetime might be by limited lifetime at time of issuance or might be
via the lifetime acquired through an on-line test (CRL, revalidation
or one-time). Therefore, all key lifetime control becomes
certificate lifetime control.
7.1 Through Inescapable Names
If keyholders had inescapable names [see section 2.5, above], then
one could refer to them by those names and define a certificate to
map from an inescapable name to the person's current key. That
certificate could be issued by any CA, since all CAs would use the
inescapable name for the keyholder. The attribute certificates and
ACLs that refer to the keyholder would all refer to this one
inescapable name.
However, there are no inescapable names for keyholders. [See section
2.5, above.]
7.2 Through a Naming Authority
One could conceivably have a governmental body or other entity that
would issue names voluntarily to a keyholder, strictly for the
purpose of key management. One would then receive all authorizations
through that name. There would have to be only one such authority,
however. Otherwise, names would have to be composed of parts: an
authority name and the individual's name. The authority name would,
in turn, have to be granted by some single global authority.
That authority then becomes able to create keys of its own and
certificates to empower them as any individual, and through those
false certificates acquire access rights of any individual in the
world. Such power is not likely to be tolerated. Therefore, such a
central authority is not likely to come to pass.
7.3 Through <name,key> Certificates
Instead of inescapable names or single-root naming authorities, we
have names assigned by some entity that issues a <name,key>
certificate. As noted in sections 2.8 and 2.9, above, such names
have no meaning by themselves. They must be fully qualified to have
meaning.
Therefore, in the construct:
(name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) jim)
the name is not
"jim"
but rather
"(name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) jim)"
This name includes a public key (through its hash, in the example
above). That key has a lifetime like any other key, so this name has
not achieved the kind of permanence (free from key lifetimes) that an
inescapable name has. However, it appears to be our only
alternative.
This name could easily be issued by the named keyholder, for the
purpose of key management only. In that case, there is no concern
about access control being subverted by some third-party naming
authority.
7.4 Increasing Key Lifetimes
By the logic above, any name will hang off some public key. The job
is then to increase the lifetime of that public key. Once a key
lifetime exceeds the expected lifetime of any authorization granted
through it, then a succession of new, long-lifetime keys can cover a
keyholder forever.
For a key to have a long lifetime, it needs to be strong against
cryptanalytic attack and against theft. It should be used only on a
trusted machine, running trusted software. It should not be used on
an on-line machine. It should be used very rarely, so that the
attacker has few opportunities to find the key in the clear where it
can be stolen.
Different entities will approach this set of requirements in
different ways. A private individual, making his own naming root key
for this purpose, has the advantage of being too small to invite a
well funded attack as compared to the attacks a commercial CA might
face.
7.5 One Root Per Individual
In the limit, one can have one highly protected naming root key for
each individual. One might have more than one such key per
individual, in order to frustrate attempts to build dossiers, but let
us assume only one key for the immediate discussion.
If there is only one name descending from such a key, then one can
dispense with the name. Authorizations can be assigned to the key
itself, in raw SPKI style, rather than to some name defined under
that key. There is no loss of lifetime -- only a change in the
subject of the certificate the authorizing key uses to delegate
authority.
However, there is one significant difference, under the SPKI
structure. If one delegates some authorization to
(name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) carl)
and a different authorization to
(hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|)
directly, both without granting the permission to delegate, that key
can delegate at will through <name,key> certificates in the former
case and not delegate at all in the latter case.
In the case of key management, we desire the ability to delegate from
a long lived, rarely used key to a shorter lived, often used key --
so in this case, the former mechanism (through a SDSI name) gives
more freedom.
7.6 Key Revocation Service
In either of the models above, key |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|
will issue a certificate. In the first model, it will be a
<name,key> certificate. In the second, it will be an authorization
certificate delegating all rights through to the more temporary key.
Either of those certificates might want an on-line validity test.
Whether this test is in the form of a CRL, a re-validation or a one-
time test, it will be supplied by some entity that is on-line.
As the world moves to having all machines on-line all the time, this
might be the user's machine. However, until then -- and maybe even
after then -- the user might want to hire some service to perform
this function. That service could run a 24x7 manned desk, to receive
phone calls reporting loss of a key. That authority would not have
the power to generate a new key for the user, only to revoke a
current one.
If, in the worst case, a user loses his master key, then the same
process that occurs today with lost wallets would apply. All issuers
of authorizations through that master key would need to issue new
authorizations through the new master key and, if the old master key
had been stolen, cancel all old authorizations through that key.
7.7 Threshold ACL Subjects
One can take extraordinary measures to protect root keys and thus
increase the lifetimes of those keys. The study of computer fault-
tolerance teaches us that truly long lifetimes can be achieved only
by redundancy and replacement. Both can be achieved by the use of
threshold subjects [section 6.3.3], especially in ACL entries.
If we use a threshold subject in place of a single key subject, in an
ACL (or a certificate), then we achieve redundancy immediately. This
can be redundancy not only of keys but also of algorithms. That is,
the keys in a threshold subject do not need to have the same
algorithm.
Truly long lifetimes come from replacement, not just redundancy. As
soon as a component fails (or a key is assumed compromised), it must
be replaced.
An ACL needs to be access-controlled itself. Assume that the ACL
includes an entry with authorization
(tag (acl-edit))
Assume also that what might have been a single root authorization
key, K1, is actually a threshold subject
(k-of-n #03# #07# K1 K2 K3 K4 K5 K6 K7)
used in any ACL entry granting a normal authorization.
That same ACL could have the subject of an (acl-edit) entry be
(k-of-n #05# #07# K1 K2 K3 K4 K5 K6 K7)
This use of threshold subject would allow the set of root keys to
elect new members to that set and retire old members. In this
manner, replacement is achieved alongside redundancy and the proper
choice of K and N should allow threshold subject key lifetimes
approaching infinity.
8. Security Considerations
There are three classes of information that can be bound together by
public key certificates: key, name and authorization. There are
therefore three general kinds of certificate, depending on what pair
of items the certificate ties together. If one considers the
direction of mapping between items, there are six classes: name->key,
key->name, authorization->name, name->authorization, authorization-
>key, key->authorization.
The SPKI working group concluded that the most important use for
certificates was access control. Given the various kinds of mapping
possible, there are at least two ways to implement access control.
One can use a straight authorization certificate:
(authorization->key)
or one can use an attribute certificate and an ID certificate:
(authorization->name) + (name->key)
There are at least two ways in which the former is more secure than
the latter.
1. Each certificate has an issuer. If that issuer is subverted,
then the attacker can gain access. In the former case, there is
only one issuer to trust. In the latter case, there are two.
2. In the second case, linkage between the certificates is by name.
If the name space of the issuer of the ID certificate is
different from the name space of the issuer of the attribute
certificate, then one of the two issuers must use a foreign name
space. The process of choosing the appropriate name from a
foreign name space is more complex than string matching and
might even involve a human guess. It is subject to mistakes.
Such a mistake can be made by accident or be guided by an
attacker.
This is not to say that one must never use the second construct. If
the two certificates come from the same issuer, and therefore with
the same name space, then both of the security differentiators above
are canceled.
References
[Ab97] Abadi, Martin, "On SDSI's Linked Local Name Spaces",
Proceedings of the 10th IEEE Computer Security
Foundations Workshop (June 1997).
[BFL] Matt Blaze, Joan Feigenbaum and Jack Lacy, "Distributed
Trust Management", Proceedings 1996 IEEE Symposium on
Security and Privacy.
[CHAUM] D. Chaum, "Blind Signatures for Untraceable Payments",
Advances in Cryptology -- CRYPTO '82, 1983.
[DH] Whitfield Diffie and Martin Hellman, "New Directions in
Cryptography", IEEE Transactions on Information Theory,
November 1976, pp. 644-654.
[DvH] J. B. Dennis and E. C. Van Horn, "Programming Semantics
for Multiprogrammed Computations", Communications of the
ACM 9(3), March 1966.
[ECR] Silvio Micali, "Efficient Certificate Revocation",
manuscript, MIT LCS.
[ELIEN] Jean-Emile Elien, "Certificate Discovery Using SPKI/SDSI
2.0 Certificates", Masters Thesis, MIT LCS, May 1998,
<http://theory.lcs.mit.edu/~cis/theses/elien-masters.ps>
[also .pdf and
[HARDY] Hardy, Norman, "THE KeyKOS Architecture", Operating
Systems Review, v.19 n.4, October 1985. pp 8-25.
[IDENT] Carl Ellison, "Establishing Identity Without
Certification Authorities", USENIX Security Symposium,
July 1996.
[IWG] McConnell and Appel, "Enabling Privacy, Commerce,
Security and Public Safety in the Global Information
Infrastructure", report of the Interagency Working Group
on Cryptography Policy, May 12, 1996; (quote from
paragraph 5 of the Introduction).
[KEYKOS] Bomberger, Alan, et al., "The KeyKOS(r) Nanokernel
Architecture", Proceedings of the USENIX Workshop on
Micro-Kernels and Other Kernel Architectures, USENIX
Association, April 1992. pp 95-112 (In addition, there
are KeyKOS papers on the net available through
<http://www.cis.upenn.edu/~KeyKOS/#bibliography>).
[KOHNFELDER] Kohnfelder, Loren M., "Towards a Practical Public-key
Cryptosystem", MIT S.B. Thesis, May. 1978.
[LAMPSON] B. Lampson, M. Abadi, M. Burrows, and E. Wobber,
"Authentication in distributed systems: Theory and
practice", ACM Trans. Computer Systems 10, 4 (Nov.
1992), pp 265-310.
[LANDAU] Landau, Charles, "Security in a Secure Capability-Based
System", Operating Systems Review, Oct 1989 pp 2-4.
[LEVY] Henry M. Levy, "Capability-Based Computer Systems",
Digital Press, 12 Crosby Dr., Bedford MA 01730, 1984.
[LINDEN] T. A. Linden, "Operating System Structures to Support
Security and Reliable Software", Computing Surveys 8(4),
December 1976.
[PKCS1] PKCS #1: RSA Encryption Standard, RSA Data Security,
Inc., 3 June 1991, Version 1.4.
[PKLOGIN] David Kemp, "The Public Key Login Protocol", Work in
Progress.
[R98] R. Rivest, "Can We Eliminate Revocation Lists?", to
appear in the Proceedings of Financial Cryptography
1998, <http://theory.lcs.mit.edu/~rivest/revocation.ps>.
[RFC1114] Kent, S. and J. Linn, "Privacy Enhancement for Internet
Electronic Mail: Part II -- Certificate-Based Key
Management", RFC1114, August 1989.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1321, April 1992.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC2045, December 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC2046,
December 1996.
[RFC2047] K. Moore, "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII
Text", RFC2047, December 1996.
[RFC2065] Eastlake, D. and C. Kaufman, "Proposed Standard for DNS
Security", RFC2065, January 1997.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC2104,
February 1997.
[SDSI] Ron Rivest and Butler Lampson, "SDSI - A Simple
Distributed Security Infrastructure [SDSI]",
<http://theory.lcs.mit.edu/~cis/sdsi.html>.
[SET] Secure Electronic Transactions -- a protocol designed by
VISA, MasterCard and others, including a certificate
structure covering all participants. See
<http://www.visa.com/>.
[SEXP] Ron Rivest, code and description of S-expressions,
<http://theory.lcs.mit.edu/~rivest/sexp.html>.
[SRC-070] Abadi, Burrows, Lampson and Plotkin, "A Calculus for
Access Control in Distributed Systems", DEC SRC-070,
revised August 28, 1991.
[UPKI] C. Ellison, "The nature of a useable PKI", Computer
Networks 31 (1999) pp. 823-830.
[WEBSTER] "Webster's Ninth New Collegiate Dictionary", Merriam-
Webster, Inc., 1991.
Acknowledgments
Several independent contributions, published elsewhere on the net or
in print, worked in synergy with our effort. Especially important to
our work were: [SDSI], [BFL] and [RFC2065]. The inspiration we
received from the notion of CAPABILITY in its various forms (SDS-940,
Kerberos, DEC DSSA, [SRC-070], KeyKOS [HARDY]) can not be over-rated.
Significant contributions to this effort by the members of the SPKI
mailing list and especially the following persons (listed in
alphabetic order) are gratefully acknowledged: Steve Bellovin, Mark
Feldman, John Gilmore, Phill Hallam-Baker, Bob Jueneman, David Kemp,
Angelos D. Keromytis, Paul Lambert, Jon Lasser, Jeff Parrett, Bill
Sommerfeld, Simon Spero.
Authors' Addresses
Carl M. Ellison
Intel Corporation
2111 NE 25th Ave M/S JF3-212
Hillsboro OR 97124-5961 USA
Phone: +1-503-264-2900
Fax: +1-503-264-6225
EMail: carl.m.ellison@intel.com
cme@alum.mit.edu
Web: http://www.pobox.com/~cme
Bill Frantz
Electric Communities
10101 De Anza Blvd.
Cupertino CA 95014
Phone: +1 408-342-9576
EMail: frantz@netcom.com
Butler Lampson
Microsoft
180 Lake View Ave
Cambridge MA 02138
Phone: +1 617-547-9580 (voice + FAX)
EMail: blampson@microsoft.com
Ron Rivest
Room 324, MIT Laboratory for Computer Science
545 Technology Square
Cambridge MA 02139
Phone: +1-617-253-5880
Fax: +1-617-258-9738
EMail: rivest@theory.lcs.mit.edu
Web: http://theory.lcs.mit.edu/~rivest
Brian Thomas
Southwestern Bell
One Bell Center, Room 34G3
St. Louis MO 63101 USA
Phone: +1 314-235-3141
Fax: +1 314-235-0162
EMail: bt0008@sbc.com
Tatu Ylonen
SSH Communications Security Ltd.
Tekniikantie 12
FIN-02150 ESPOO
Finland
EMail: ylo@ssh.fi
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.